#ubuntu-devel 2005-07-25
<comadreja> mjg59 : ping
* terrex se va a ver la tele // is going to watch tv
<mjg59> comadreja: Hi
<comadreja> mjg59 : I've been told that I should contact you regarding the laptop support
<comadreja> mjg59 : I'd like to help on that for breezy
<Burgundavia> ogra_, afaik, there are no mediawiki debs, anywhere on the internet
<Burgundavia> ogra_, if you had read planet.ubuntu a while back you might have learned that, as I blogged about it
<herzi> hmm, new libxrender-dev doesn't include /usr/lib/libXrender.la anymore
<herzi> :(
* pitti -> sleep, cu tomorrow
<Burgundavia> ogra_, apparently I was wrong. Try here http://meta.wikimedia.org/wiki/Running_MediaWiki_on_Debian_GNU/Linux
<Burgundavia> ogra_, and http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=276057
<srbaker1> yo
<srbaker1> i'm trying tog et fox compiled, from the debian source package (and frmo source) but it's not working, i keep getting:
<srbaker1> ../src/.libs/libFOX-1.2.so: undefined reference to `XF86VidModeQueryVersion'
<srbaker1> ../src/.libs/libFOX-1.2.so: undefined reference to `XF86VidModeGetModeLine'
<srbaker1> anyone know anything about this?
<calc> how do you make xlibs -42 install with xkeyboard-config ?
<calc> it keeps failing for me saying the dir isn't empty
<calc> if xkeyboard-config isn't already installed it just fails with an error 1 in postinst
<calc> hmm i don't need to have xlibs installed apparently though stuff depends on it
<calc> so its breakage is still not too good
* calc found the bug 12743 about it
<schweeb> calc: rm /etc/X11/xkb/*
<mdke> calc, there is a bug which explains how
<mdke> ah
<mdke> yeah i think its 12743
<mdke> comment 1
<calc> schweeb: that isn't how to fix it, but it tells how in the bug report
<lupus1010> dbus package maintainer here?
<lu|away> hrm
<lu|away> daily liveCDs hosed?
<lu|away> the report looks like it is testing ia64, but only amd64 is on the ftp server, and no x86
* davyd wanders in
* davyd polls Mithrandir 
<daniels> doko: calm down dude, it['s in the process of being fixed, mmmkay?
* davyd bings at daniels 
<infinity> daniels!
<daniels> infinity: bing
<infinity> bong
<daniels> bung
<infinity> You know what would make me the happiest boy on earth?
<lu|away> o/~ all you need is love o/~
<infinity> Love and millions of dollars, sure.
<infinity> But, barring that, installible xbase-clients would be swell.
<lu|away> heh
<lu|away> love is better than X
<infinity> Sure, but I /have/ love.
<infinity> And, much like X, love can sometimes be a drag.
<lu|away> I do too, though admittedly she is pretty sure I prefer X to her
<daniels> infinity: actually, installable is bad for the time being
<daniels> infinity: i need to get everything building externally and then replace it.  which I'm working on.
<infinity> Oh, fine, be picky.  Go for installible and functional, then.
<daniels> at least the FTBFSes are more obvious this way
<infinity> Rather, yes.
<daniels> do you have a list handy of how many packages are stalling on xbase-clients and xutils
<daniels> ?
<infinity> Anything vaguely GNOME-related.
<daniels> cock.  seriously?
<davyd> I'm sure most of it shouldn't be
<infinity> Yeah.  No big deal, though.  It's no more than a few hours of backlog once you get fixed packages uploaded
<daniels> daniels@brainfreeze:~/canonical/xorg/monolith/xorg-6.8.2% dpkg-deb -c ~/mirror/ubuntu/pool/main/x/xorg/xbase-clients_6.8.2-10_amd64.deb | grep bin/ | wc -l 91
<daniels> i'm working on it
<infinity> Cool.
<infinity> I'll go work on something else while I wait.  Lord knows my TODO is longer than my available time anyway.
<lu|away> if your TODO isn't longer than your available time, you're not interesting ;)
<daniels> heh
<bddebian> aye
<bddebian> daniels: You know much about qmake?
<mgalvin> dang it, the most recent updates cause totem hang, i can't watch marks talk at debconf :(
<daniels> bddebian: mercifully, no
<daniels> i'm battling the build system to build imake now
<daniels> most arcane thing I've ever seen
<daniels> and I've seen the X build system using imake
<mgalvin> nevermind, i think i found a matching bug, 12584
<bddebian> Ugh. :-(
<bddebian> I need to patch the Makefile but cdbs-edit-patch doesn't expand enough to run qmake to get the make file and if I run it manually it diffs against an empty Makefile :-(
<wasabi> Hmm odd.
<wasabi> THis new box is locking up on Starting hotplug subsystem.
<blueyed> I need to recompile suexec2 (because of mod_chroot) for Apache. How would I do that?
<bddebian> apt-get source suexec2 ?
<infinity> s/suexec2/apache2/
<bddebian> heh, whooops
<blueyed> apache2-common is the package, yes. But then? Do I have to apply the patches before?
<infinity> blueyed : If you have patches to the source, drop those patches in debian/patches, add a new entry to debian/changelog, then run 'dpkg-buildpackage -rfakeroot -uc -us'
<infinity> blueyed : That will give you your custom build of apache2.
<blueyed> Thanks a lot, infinity. I'll try it.
<infinity> And yes, making suexec build out-of-tree is on my TODO for apache 2.2 packaging.  It gets requested constantly.
* infinity wonders if "-uc -us" will every become the default for dpkg-buildpackage.
* infinity stares at Keybuk.
<infinity> s/every/ever/
<blueyed> infinity: could I also edit the file in the upstream tarball and add a changelog entry, without the patch. would be easier. I need another docroot for suexec only anyway..
<bddebian> infinity: I use them but doesn't us have issues with -S -sa?
<infinity> bddebian : No.  Why would it?
<infinity> bddebian : It just means "unsigned changes, unsigned source"... You can sign them later with debsign.
<bddebian> I dunno, I had a problem recently when combining them.  I used to always use -us -tc
<infinity> I use "-uc -us -S -sa" with many Ubuntu builds, then debsign when I'm ready to upload.
<bddebian> Oh, you sign them after the fact then
<bddebian> Ahh
<infinity> Makes no sense to sign everything you build, just stuff you plan to distribute.
<bddebian> Aye
<blueyed> Can I just edit /debian/rules ?
<bddebian> Sure
<infinity> blueyed : If all you need to "patch" is debian/rules, then yes, edit that.
<infinity> blueyed : debian/patches is just for patches against the upstream source.
<infinity> blueyed : Anything under debian/ is fair game to edit directly.
<bddebian> infinity: Do you know qmake?
<infinity> bddebian : Even if I did, I wouldn't admit to it.
<bddebian> Gah
<infinity> (Also, no, I don't, thankfully)
<bddebian> Dang it.  It's a simple patch
<blueyed> Great. What is the changelog entry for? Will the version number be taken thereof? I once build openssh-server patched and apt keeps asking me to update to the same (original) version.
<infinity> blueyed : The package version is taken from the changelog, yes.
<infinity> blueyed : In 99% of packages, anyway.
<blueyed> So I add "-myname" at the end?
<bddebian> blueyed: dch -i
<infinity> Avoid dashes.
<infinity> + would be good.
<infinity> 2.0.54-2ubuntu1+blueyed (or whatever)
<blueyed> Thanks, infinity. What do you mean, bddebian?
<infinity> More than one dash in a version number could cause undefined behaviour with some package managers, since it's not valid.
<infinity> blueyed : If you install "devscripts", "dch -i" will start up a new changelog entry for you automagically.
<bddebian> blueyed: dch is a debhelper script to edit the ChangeLog.  -i increments the version by 1
<abarbaccia> hey guys - whats the status of breezy - useable?
<bddebian> Of course
<bddebian> :-)
<bddebian> As long as you don't mind a little bit of pain now and again ;-)
<abarbaccia> better question - 
<abarbaccia> i have a rio carbon and its saying it doesn't like the USB port in hoary - think it'll work in breezy
<blueyed> Thank you guys, it builds. infinity: please think about a solution to not have to (patch and) compile it everytime from source when you need another docroot (like with mod_chroot).
<bddebian> abarbaccia: That, I don't know.
<lupus1010> it's kernel depended thing?
<carstenh> how do I escape ^ in the ubuntu-wiki?
<carstenh> maybe it it possible to use its ASCII-code?
<bddebian> infinity: Well do you at least know in a cdbs package, if I diff the Makefile manually will it be created by the time patch runs?
<robitaille> carstenh: just type ^   It seems to work for me...
<robitaille> but wiki questions are probably better on #ubuntu-doc
<carstenh> robitaille: does not work for me :/ i will just add a note like "imagine /\ as what you get when you press shift-6" ;) thanks 
<robitaille> carstenh: https://wiki.ubuntu.com/TestTitle
<robitaille> and probably not everyone in the world  gets ^ with shift-6.
<carstenh> robitaille: strange, thanks :)
<carstenh> robitaille: then it should work on my wiki too. i'll test it again :)
<daniels> infinity: when are we transitioning?
<daniels> infinity: i'm ready to do my part of it (and fix xlibs as part of the bargain) whenever
<carstenh> robitaille: https://wiki.ubuntu.com/TestTitle <- my problem were two ^ one one line
<mrd`> I'm sure the devs are working on it, but is there any update (or anywhere I can check) on the status of fixing xbase-clients?  (The bugzilla report doesn't have much info.)
<lu|away> daniels: you should put xbase-clients info in /topic ;)
<ajmitch> bddebian: /win 36
<ajmitch> gah
<bddebian> Uh?
<TerminX> rol, I see people do that so many times a day..
<ajmitch> bddebian: mistake, don't worry :)
* ..[topic/#ubuntu-devel:daniels] : Ubuntu Development | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://www.ubuntulinux.org/wiki/DeveloperResources | If you have unexpectedly lost editbugs privileges, talk to mdz/ogra/kiko | Colony CD 2 released | yes, X is broken.
<daniels> mrd`: 'i'm packaging like a monkey on speed'
<TerminX> you should append a "shut up and deal with it" to the end of the topic ;)
<mrd`> daniels: I figured as much. :)
<mrd`> TerminX: I'm dealing with it, I'm just interested in the status of things.
<TerminX> mrd`: oh, I wasn't aiming that comment at you specifically
<TerminX> I just imagine people have been asking 24/7
<mrd`> TerminX: Ah, yeah.
<lu|away> I demand #daniels
<mrd`> lol
<lu|away> with a bot echoing his every terminal command
<mrd`> Excellent.
<daniels> haha
<daniels> lu|away: come up with a g-t patch to facilitate that and it will be done
<lu|away> haha
<mrd`> Or just setup vnc so that everyone using breezy can connect and watch. :)
<TerminX> somebody should come up with a g-t patch to make the tabs wrap around (so when you hit next tab on the last tab, it goes to the first tab.. you know, like every other tabbed application anyone uses ;)
<daniels> lu|away: you're an engineer, aren't you?
<daniels> TerminX: you're telling me
<daniels> and to allow you to move tabs around
* mrd` prefers to just use multiple terminals instead of tabs.
<TerminX> it's probably shit simple to do
<mrd`> But, that's just me. :)
<TerminX> I mean, Gaim can do it.. surely hacking it into g-t couldn't be /that/ difficult
<lu|away> daniels: so I hear
<lu|away> daniels: some day I plan to engineer the notetaking app I just blogged about
<daniels> heh
<daniels> enginamaneer
<lu|away> daniels: and then I will be done forever, vanishing in a dark cloud of social science
<blueyed> Now I've build my own Apache2 package (with another configure docroot option for suexec2), but the error stays the same: "cannot get docroot information (/var/www)". "suexec2 -V" says: "-D AP_DOC_ROOT="/"" - but thats probably another issue then.. :/
<blueyed> it's with mod_chroot and mod_fastcgi
<fabbione> morning
<daniels> infinity: ?
<trulux> morning
<trulux> fabbione: hey
<fabbione> hey trulux 
<trulux> fabbione: how's it going?
<trulux> fabbione: do you mind if I /query you?
<fabbione> trulux: just woke up
<Kosai> Hello.  I'm running a hoary install on powerpc, and I mistyped the first screeen of "set new root password".  Now, every time I go back into that menu, it prompts me to retype the password (which I don't know, because it was mistyped) correctly, and won't let me give an initial password again.
<Kosai> Has anyone seen this before/does anyone have a suggestion for what I can do?
<trulux> fabbione: heh, I woke up one day ago ;)
<sfvt> Kosai: that question would be more appropriate on #ubuntu... that said, from what you've said I'm not sure what you're talking about :) 
<pef> hi
<trulux> pitti: heya!
<pitti> Good morning
<trulux> pitti: what's up?
<trulux> pitti: just woke up? :)
<pitti> trulux: yes, I slept far too long today
<trulux> pitti: argh, not my case. I needed to do some work
<trulux> I will go to sleep in a few hours
<trulux> like the Cookie monster :)
<trulux> JaneW: morning!
<JaneW> hi trulux
<trulux> JaneW: how's it going?
<JaneW> trulux: good thanks and you?
* davyd pokes Mithrandir gently
* highvoltage pokes Mithrandir too
<highvoltage> davyd: i think he's dead.
<davyd> understood
<sladen> he might be too busy poking samira
<jsgotangco> JaneW: hi!
<jsgotangco> lol
<Mithrandir> davyd: pong?
<davyd> Mithrandir: I'm told you're the man to talk to with regards to amd64
<Mithrandir> davyd: that's correct
<davyd> Mithrandir: have you spent much time doing dev in a chroot?
<Mithrandir> well, it depends on what I'm doing.  I've used them a fair amount, sure.
<davyd> do you know why gdb wouldn't work?
<davyd> I get a 'generic error' and gdb has to be killed from the command line
<Mithrandir> hm, sounds weird.
<Mithrandir> is proc mounted?
<davyd> yes
<JaneW> hi jsgotangco 
<davyd> (gdb) r
<davyd> Starting program: /bin/ls
<davyd> [Thread debugging using libthread_db enabled] 
<davyd> Error while reading shared library symbols:
<davyd> Cannot find new threads: generic error
<JaneW> why so much poking? ;)
<infinity> daniels : I'm ready anytime this evening to make everything happy.
<Mithrandir> davyd: kernel version?
<davyd> 2.6.12-3-amd64-generic
<Mithrandir> davyd: hm, weird.  My amd64 development system still isn't unpacked after I moved, so I don't have a full breezy devel system (that is, breezy base system ++), so it might be kernel-related.  I've never seen it before, at least.
<davyd> Mithrandir: I'm running my chroot with `linux32 dchroot -d`
<davyd> everything else seems to be working sanely
<davyd> except for gdb
<Mithrandir> it's a 32 bit chroot?
<davyd> indeed, I installed 32-bit breezy into it
<davyd> [davyd@floyd-chroot shading-scale] $ file /bin/ls
<davyd> /bin/ls: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.0, dynamically linked (uses shared libs), stripped
<Mithrandir> try LD_ASSUME_KERNEL=2.4.1 gdb /bin/ls (inside the chroot)
<daniels> infinity: now?
<davyd> Mithrandir: neat
<davyd> that worked
<Mithrandir> davyd: it worked?
<davyd> hang on, I'll try something more involving
<infinity> daniels : The sooner, the better.  What do you have for me?  glu shlibs changed back to libglu1, provides changed to libglu1, libclu1c2, and fixed xbase-clients?
<Mithrandir> davyd: ok, then you've either tickled a bug in the 32 bit emulation in the kernel or a bug in glibc.  Congratulations. :-)
<daniels> infinity: glu shlibs changed back to libglu1, provides changed to libglu1, libglu1c2
<daniels> infinity: xbase-clients love is progressively slamming into NEW
<infinity> daniels : Rock.
<daniels> infinity: and I don't have anything better to do with my life tonight, so hopefully I'll get it done
<Mithrandir> davyd: to be honest, I don't care _too_ much about the 32 bit support on amd64, but it should be fixed, I agree
<infinity> Life is overrated.
<daniels> inf	uliits aren't
<davyd> Mithrandir: well, at least it works now
<davyd> I can get some work done ;)
<infinity> davyd : What happens if you chroot into your 32-bit chroot without invoking linux32 first?
<Mithrandir> davyd: it looks like a kernel bug.
<infinity> davyd : It could just be a personality bug.
<daniels> infinity: -43 uploaded
<davyd> infinity: same issue
<davyd> Mithrandir: will you put that upstream for me? you seem to have some better idea of what's going wrong here
<Mithrandir> infinity: I can reproduce it on a completely different system with kernel.org 2.6.10 and debian's userland
<infinity> Mithrandir : Joy.
<Mithrandir> infinity: which is why I jumped to the conclusion "kernel bug".
<Mithrandir> davyd: I can see what I can do.
<davyd> Mithrandir: cheers, dude
<davyd> you've saved me having to reinstall 32-bit on my machine
<Amaranth> http://moon.google.com
<Amaranth> zoom in all the way on that :D
<jsgotangco> lol
<Mithrandir> davyd: it seems related to the NPTL (a new thread library which was added support for in 2.6) support, which is why using the LD_ASSUME_KERNEL trick fixes it.
<Mithrandir> or "fixes"
<jsgotangco> Amaranth, oohh it even had landing spots
<carlospc> there is anybody who knows what happens with the udebs in arch?
<carlospc> they go to universe/debian-installer or directly to main/debian-installer?
<jsgotangco> Amaranth, bwahahaha
<j^> this is cool http://liihs.irit.fr/dragice/foldndrop/
<infinity> Kamion : ping.
<infinity> Kamion : How much do I have to slip you under the table to do some NEW processing? (specifically gcc-4.0 binaries, and anything daniels will/has upload(ed) today)
<Mithrandir> infinity: two cases of beer
<infinity> SOLD!
<daniels> Kamion: please don't NEW anything I've uploaded until xorg 6.8.2-43 is safely in the archive
<daniels> otherwise its binaries will get rejected
<infinity> daniels : Some of your NEW stuff replaces stuff built by -43?
<daniels> and ... I think people want xlibs fixed
<daniels> infinity: yeah
<infinity> daniels : <stare>
<daniels> infinity: annoying, but the fastest way to actually end up with a fixed x{libs,base-clients}
<daniels> infinity: need to kick more libraries out in order to build more apps in order to make xbase-clients actually contain stuff
<infinity> daniels : Sure, but why have the xorg source building stuff that you're also building in new sources?
<Mithrandir> infinity: because he likes smoking crack.
<daniels> infinity: because it takes time to split it out
<Mithrandir> infinity: and rene is going to go mad about it, I guess.
<daniels> and I'd rather not wander further behind :P
<infinity> daniels : Doesn't take much time to remove stuff from debian/control. :)
<daniels> infinity: eww.
<infinity> Mithrandir : Yes, things go insane when you try to upload a package that produces binaries with older versions than what's already in the archive.  We had this problem last week. :)
<Mithrandir> infinity: I'm one of the amd64 ftp-masters in debian, I know. :-)
<Mithrandir> sladen: where is your thinkpad accelerometer love?
<sladen> Mithrandir: http://www.paul.sladen.org/thinkpad-r31/aps/
<sladen> Mithrandir: mjg59 sent me a pathc to do mlocking and daf some stuff to fix up a glut difference between libraries versions
<Mithrandir> sladen: it only requires userspace support?
<sladen> Mithrandir: and I need to add caliation (robot101's laptop happened to sit around zero anyway)
<sladen> Mithrandir: kernel space good, user space better
<Mithrandir> sounds good.  Planning on ITP-ing it?
<sladen> Mithrandir: could do.  Oh, the stuff to park the heads needs some kernel space as the ATA queue needs to be locked as well as just parking the heads so that other commands don't poceed to unpark it
<Mithrandir> that sounds like something which should go in there in general, though
<fabbione> hey seb128 !
<fabbione> seb128: https://bugzilla.ubuntu.com/show_bug.cgi?id=12822 <-
<seb128> hi
<pitti> hi seb128
<fabbione> hey pitti
<seb128> hey pitti 
<seb128> fabbione: Debian has the same issue?
<fabbione> seb128: yes..
<fabbione> i could reproduce it with the new binutils
<fabbione> it will come up as soon as you will start uploading to debian
<seb128> so the new uploads on Debian are silently fucked too?
<Kamion> infinity: well, I can do, but elmo should be around soon ...
<fabbione> there is no silently fuckage..
<seb128> how great
<fabbione> seb128: it has always been working that way on sparc
<fabbione> seb128: it's --as-needed that is fucked in binutils on sparc.. a corner case i would say
<seb128> fabbione: it builds fine but it's broken and you have no idea of what package are b0rked then, no?
<fabbione> seb128: the libs on sparc always had that extra info `_PROCEDURE_LINKAGE_TABLE_'
<fabbione> seb128: except that with the old binutils it was linking corrently
<fabbione> with the new ones it fails with that error
<Kamion> daniels: (similarly, if you want stuff not NEWed until xorg's in, best tell elmo)
<fabbione> it's a regression
<fabbione> the libs are all ok
<infinity> Kamion : Well, the X stuff needs to be done in a specific order anyway, so we can wait for elmo, but gcc-4.0 would be nice, so it's no longer blocking doko doing another upload (the current one needed some bootstrapping love, and I'd like to get over that hump)
<daniels> elmo: please don't NEW anything of mine until xorg 6.8.2-43 hits, tkhx
<daniels> er, 'kthx'
<Kamion> infinity: ok, one sec
<seb128> fabbione: hum. Fixing binutils will fix the issue for everything or we will have to rebuild the packages which have not built correctly?
<Amaranth> daniels: waiting to finish everything once and for all before doing a -43?
<fabbione> seb128: it will fix for everything. no need to rebuild. just kick back the FTBFS
<seb128> k
<Kamion> ---- copyright of lib32gfortran0_4.0.1-2ubuntu2_amd64.deb ----
<Kamion> WARNING: No copyright found, please check package manually.
<fabbione> seb128: basically there is no lib breakage.
<doko> Kamion: gcc-4.0 should beNEW'd (32/64 bit objc/gfortran runtime libs)
<Kamion> doko: ^-- yo, fix that dude
<doko> ouch
<seb128> fabbione: so we "just" have to fix binutils :p
<fabbione> seb128: exactly :)
<Kamion> oh, hmm, its doc dir is a symlink to gcc-4.0-base
<fabbione> doko: can you fix that in the next upload?
<Kamion> doko: never mind, I think fernanda/whatever is just confused
<daniels>  * Copyright 1993 by Sun Microsystems, Inc. Mountain View, CA.
<daniels>  *
<daniels>  * SUN DISCLAIMS ALL WARRANTIES WITH REGARD TO  THIS  SOFTWARE,
<daniels> [...] 
<daniels>  * Author:  Chris D. Peterson, MIT X Consortium
<daniels> THANKYOU, SUN
<daniels> it's ok
<daniels> we didn't want to distribute it anyway
<doko> Kamion: ehh, there's nothing to fix. /usr/share/doc/lib32gfortran0 -> gcc-4.0-base
<Kamion> doko: yeah, as I just said ...
<daniels> Amaranth: nope, but -43 builds some stuff still that has been uploaded in subsequent modular packages
<doko> ahh, ok, was checking this in another window ... ;)
<daniels> Amaranth: so -43 will get automatically rejected if it gets processed after the modular stuff
<Kamion> doko: hmm, looks like installing just libgfortran0-dev will leave you with a dangling symlink in /usr/lib32/ (since it doesn't depend on lib32gfortran0) - not sure if that's the right thing to do
<Kamion> then again I don't really know the lib32/lib64 standards
<Kamion> doko: rest looks fine, accepted
<doko> Kamion: old problem. yes, maybe I should have a lib32gfortran-dev package to compete with the count of xorg's binary packages.
<Kamion> doko: heh, yeah, I'm not sure that alternative's any better. :-)
<daniels> hey, xorg doesn't have many binary packages
<daniels> doing an ls in xorg-6.8.2/debian/ now fits in my screen
<daniels> doko: did you get to look at that patch?
<doko> Kamion: currently you have to know what to install for biarch builds. maybe gcc64-4.0 / gfortran64-4.0 dependency packages would work
<doko> daniels: s/packages/packages anymore/ ;)
<doko> which one?
<doko> depends on the font size and the resolution
<daniels> doko: the one to fix the optimising away of volatile accesses
<daniels> doko: 208 files
<doko> yep, it's not in mainline, not even proposed as a patch. I did a test build on i386, but have to the same on our other architectures as well.
<daniels> 'kay
<doko> daniels: wait, it was committed to 4.0 tonight, so the next upload should have it
<daniels> doko: alright, sweet deal, thanks
<daniels> jesus
<daniels> I don't know why I just tried to increment 1:3.5.2-1 to 1:3.5.2-38
<sivang> daniels: what was that Sun software you were turned off by? :-)
<sivang> seb128: anything new re lp integration? did you check my patch?
<daniels> sivang: that's not a licence.  it's a copyright statement and a warranty disclaimer.  i.e., no grant of rights.
<sivang> daniels: bah, but what does it copyright?
<daniels> sivang: part of libXt
<seb128> sivang: I'll do that this morning
<daniels> god I hate libXaw
<TerminX> daniels: libxrender-dev seems to be missing libXrender.la
<daniels> anything where configure runs an ed script on the local copy of libtool to fix it ...
<Treenaks> daniels: let's just drop it then
<daniels> TerminX: it's deliberate
<daniels> Treenaks: good plan!!
<TerminX> where is libXrender.la then?
<daniels> TerminX: /dev/null
<daniels> i can't even remember why I'm packaging libXaw
<Treenaks> daniels: who needs it anyway, in this age of GTK
<TerminX> er
<daniels> some app wanted some library which wanted libXaw which wanted libXPm which wanted something else
<sivang> seb128: sure, just wanted to know if there anything wrong with the patch so I could fix it up quicky, I know we are in a hurry with this
<daniels> TerminX: if anything in /usr/lib still contains references to it, it needs a bug filed on it and a rebuild
<TerminX> gnome-terminal tries to link against it.
<daniels> TerminX: so you need to find out what's causing that (hint: grep -r libXrender.la /usr/lib) and file bugs
<infinity> TerminX : Where is it doing so?
<seb128_> elmo: gcalctool (incoming) sync please
<seb128_> sivang: I'll do that this morning
<TerminX> infinity: I dunno, I tried to build it and it has -lXrender in its Makefile
<Amaranth> TerminX: get rid of it? :)
<infinity> Nothing inherently wrong with -lXrender.
<TerminX> /usr/lib/libXft.la:dependency_libs=' -lfontconfig /usr/lib/libfreetype.la -lz -L/usr/X11R6/lib /usr/lib/libXrender.la -lX11'
<infinity> It's libtool that's off looking for sily .la files.
<TerminX> and a whole bunch of KDE shit.
<infinity> TerminX : Which architecture?
<TerminX> i386
<fabbione> ah finally.. scsi-modules status starts to look much better :)
<infinity> TerminX : Are you up to date?
<TerminX> not on libxft2, actually
<sivang> seb128_: sure, let me know if you need any fix on the first gedit patch
<TerminX> I have it held because the new version fucks up my fonts on /.
<TerminX> ;p
<infinity> TerminX : I think I may have uploaded a fixed libxft very recently. :)
<daniels> i also hate autoconf
<Treenaks> daniels: do you know of a better alternative?
<sivang> does anybody know if I can use plain patch to apply a debdiff ?
<sivang> (that is, the plain patch program)
<seb128_> sivang: k, thanks
<Treenaks> sivang: of course
<daniels> and Xaw
<daniels> Treenaks: that's the tragedy -- no
<TerminX> infinity: fixed in what way?  I just don't like how 2.1.7 renders fonts opposed to 2.1.2 I think
<infinity> TerminX : I didn't touch rendering stuff, I mean I fixed the build issue.
<sivang> Treenaks: thx
<daniels> TerminX: in that case, you lose
<Treenaks> daniels: "drcar" (Daniel's Really Cool Autoconf Replacement)
<TerminX> blah
<daniels> i may be stupid, as evidenced by the fact I'm maintaining X
<daniels> but I'm not *that* stupid
<TerminX> oh well, /. sucks anyway
* TerminX upgrades
<infinity> daniels : Did xorg have NEW binaries?
<daniels> infinity: nope, it got ACCEPTED directly
<daniels> should have landed by now
<infinity> I said binaries, not source.
<infinity> NEW binaries get hung up after the buildds upload.
<infinity> So, did anything in debian/control get added? :)
<infinity> (The builds are suspiciously hanging out in "Uploaded", despite a cron.daily run since they were uploaded...)
<Kamion> no xorg in NEW
<Kamion> xserver-xorg-core |   6.8.2-43 |        breezy | amd64, i386, powerpc
<infinity> Oh.  Guess it's just taking its sweet time jenniferring everything.
<infinity> Or, katie and wanna-build aren't on speaking terms about what "installed" means.
<Kamion> cron.daily's still running
<trulux> JaneW: fine too :)
<infinity> Kamion : That'd explain it. :0
<Kamion> unless you mean the :33 cron.daily, which is well finished
<infinity> Kamion : Hard to say.  I /think/ they were uploaded before :33, but maybe I'm on crack.
<infinity> No big deal.  They'll get in sync again soon.
<infinity> And I need ia64 anyway, before we start asking for other stuff to be NEWed.
<Kamion> amd64 was accepted at :45, i386/powerpc at :50
<Kamion> so all's fine
<infinity> Ahh, kay.
<infinity> Cool.
<infinity> I just have poor time-keeping skillz.
<infinity> And ia64's just fnishing up now.  Yay.
<fabbione> infinity: i guess i should skip xorg build on sparc until -44.. right?
<fabbione> it won't manage to build that fast
<infinity> <shrug>
<infinity> If you don't build any of daniels' other new uploads, xorg is fair game.
<fabbione> infinity: what's the new stuff?
<fabbione> (i can temporary mark it as N-F-U)
<infinity> More stuff broken out.  I'm sure Kamion could give you a list. :)
<infinity> I have no such list myself.
<Kamion> umm ... looks like: imake libxt xsetmode iceauth libxmu libxkbfile xhost xdpyinfo libxpm
<Kamion> at the moment
<fabbione> Kamion: thanks
<fabbione> i guess i will have to see them first...
<infinity> daniels : You're breaking out imake?  Dear god.
<fabbione> otherwise w-b will complain about packagename/version
<infinity> fabbione : No, take name_1, then -n name_1
<fabbione> infinity: that's the easiest one to do :)
<daniels> Kamion: sounds about right
<infinity> fabbione : Then later, just --forget them all, and they'll come back with the right versions in the next cron.daily.
<fabbione> infinity: right :)
<fabbione> done
<fabbione> thanks
<infinity> There, and ia64 uploaded.  Yay.
<daniels> also libxaw libxtrap libxxf86{dga,misc,vm} libdmx libfs
<infinity> Stupid slow Itanics.
<Kamion> hmm, need d-i byhand to fix some localechooser issues so I can test a tzsetup fix so ...
* Kamion starts at the beginning of the chain
<doko> daniels: which part of xorg needs the fixed gcc?
<daniels> doko: xserver-xorg-core, xserver-xorg-driver-i810 (both still part of the xorg source package)
<daniels> infinity: i thought ia64 was a port?
<doko> ok, so you will wait on the next gcc?
<fabbione> daniels: danke
<infinity> daniels : Yes, but it's handled in the DC, so it's mine anyway.
<infinity> daniels : If I can avoid screwing it over by waiting 20 minutes before doing something, I will.  If I have to wait a day, screw it.
<doko> daniels: when is imake uploaded/available?
<infinity> doko : When Kamion/elmo pushes it through queue/NEW.
<infinity> doko : Which can happen any time after the next cron.daily.
<infinity> (Well, I guess imake could go now, since it's completely new, but may as well wait for the other pseudo-new stuff to be ready)
<fabbione> Kamion: a udeb growing from 1.2M to 1.4M is acceptable?
<Kamion> fabbione: should be ... which one?
<fabbione> Kamion: scsi-modules on i386
<fabbione> sparc is from 300K to 900K. but it's unsupported so you don't care :)
<fabbione> the others are still unknown
<infinity> Damn those upstream fellows writing new drivers.
<infinity> How dare they?
<fabbione> they fail later at net modules (cleaning it up now)
* daniels frowns.
<daniels> Permission to use, copy, modify, and distribute this software for any
<daniels> purpose and without fee is hereby granted, provided that the above
<daniels> copyright notice appear in all copies and that both the copyright notice
<daniels> and this permission notice appear in supporting documentation.
<daniels> is that acceptable?
<daniels> doko: note that I haven't done xmkmf yet; xbase-clients is far more high-impact
<infinity> daniels : It's free.
<Kamion> fabbione: that's fine, the only initrds it's in are cdrom and hd-media
<daniels> doko: -44 will wait on the next DFSG, right
<daniels> er, next gcc.  christ.
<infinity> daniels : The documentation clause is just slightly less irritating than the advertising clause.
<daniels> infinity: thanks
<daniels> oh my god
<daniels> /* Copyright 1991 NCR Corporation - Dayton, Ohio, USA */
<daniels> WOW, USEFUL
<infinity> daniels : Unless you consider "supporting documentation" to mean "the palce where you'd put the license", then it's not even irritating, just poorly worded.
<fabbione> Kamion: ok thanks
<fabbione> Kamion: if the same % of growing/shrink will be achieved on ppc and amd64, i will kill scsi-common-modules and scsi-extra-modules
<Kamion> fabbione: argh
<fabbione> Kamion: it's so MUCH easier with one list!
<Kamion> fabbione: make me completely upend debian-installer/build/pkg-lists/, why don't you
<Amaranth> daniels: it doesn't have a license?
<fabbione> Kamion: why don't I ??
<fabbione> for that size i could kill scsi-core-modules too.. 
<Amaranth> daniels: is /usr/X11R6/lib/libXxf86vm.la going to exist anymore?
<doko> daniels: just wanting to have something to build OOo2 with. I can avoid xbase-clients, disabling KDE, but imake is somewhat needed.
<Amaranth> daniels: err, just libXxf86vm.la in any location
<daniels> Amaranth: ... it has never existed, and never will.
<daniels> Amaranth: nope, just a copyright statement, i.e. all rights reserved
<Kamion> fabbione: the udeb names are hardcoded in debian-installer. If you remove udebs, I have to mess with its build system
<daniels> at least, to the parts of that file that NCR wrote, and christ only knows what that is
<daniels> hooray for opaque development processes!
* daniels <3 tog
<Amaranth> heh
<fabbione> Kamion: *SHRUGS*
<Amaranth> daniels: ok, i was told it was needed for wxwidgets2.6 :/
<mjg59> daniels: So, dude, i810 EXA?
<Kamion> and PLEASE LEAVE SCSI-CORE-MODULES ALONE :-)
<daniels> Amaranth: if wxwidgets did it, they're on crack and they were just making crap up
<Kamion> other stuff depends on that, like cdrom-core-modules
<daniels> mjg59: haven't had time to redo it, no
<Kamion> and firewire-core-modules, usb-storage-modules, sata-modules
<daniels> mjg59: every waking moment has been either work, modular server to get ready for r7rc0, or, on some rare occasions, beer
<fabbione> Kamion: i was kidding about scsi-core :)
<Kamion> good ;-)
<mjg59> Haha
<Kamion> scsi-common-modules isn't that bad
<Kamion> at least other stuff doesn't depend on it ...
<fabbione> Kamion: i might have to keep scsi-common-modules, but scsi-extra will go away 99,9%
<Kamion> ok
<fabbione> i can only complete the check once i can build udebs everywhere
<Kamion> I can cope with that
<fabbione> but at least we:
<fabbione> a) get less udebs around
<fabbione> b) i gain more sanity points keeping stuff alligned
<Kamion> fair enough
<fabbione> c) i will not get disqualified trying to kill the d-i allmighty
<fabbione> d) the size is approx the same
<daniels> REALLY HATE XAW
<Kamion> fabbione: that said, it probably kills any possibility of floppy builds ever
<Kamion> fabbione: the point of scsi-extra-modules is that it doesn't go on the cd-drivers floppy
<Kamion> but is available for cdrom etc.
<fabbione> Kamion: we can reevaluate the floppy thing later on.. right now i need to get this thing a bit more clean..
<Kamion> mm, right
<fabbione> Kamion: if your floppy plan is for breezy+1 we can certainly improve the situation  A LOT
<fabbione> starting from a root problem of unalligned kernel configs
<fabbione> -> ~ same drivers all over
<fabbione> -> ~ same udebs set
<fabbione> at that point splitting for size becomes easier
<Kamion> floppy for 2.6 probably requires initramfs, which I doubt I'll have time to do before breezy
<fabbione> brb
<Kamion> so breezy+1 sounds reasonable
<fabbione> Kamion: that too..
<infinity> daniels : How long until -44?
<Amaranth> we don't even have -43 yet, do we?
<Amaranth> i mean, it's been uploaded
<infinity> daniels : If it's more than a day or two, feel free to remove any reference to libglu1c2 in your debian/control, I'll get everything rebuilt ASAP. :)
<infinity> Amaranth : It's in the archive.
<daniels> xaw is made of stupid
<daniels> infinity: yeah
<daniels> infinity: did we come to a consensus on whether or not we could kill it?
<infinity> daniels : Or, don't worry about tweaking it at all, if you're just going to remove it completely and move mesa to main.
<daniels> infinity: (kill libglu1-xorg* altogether)
<daniels> infinity: is it feasible?
<daniels> i mean, did we end up agreeing sbuild would die, or what?
<daniels> i can't remember
<infinity> daniels : Oh, right.  THe sbuild case.  Well, if libglu1-xorg is COMPELTELY gone, we might be okay.  I'd have to either look at the code and refresh my memory, or do a test run, to be sure.
<daniels> infinity: 'kay
<daniels> infinity: your wish is my command
<infinity> daniels : Does anyone have versioned build-deps on libglu1-xorg-dev?
<infinity> daniels : If not, we can just cheat and make mesa-dev provide xorg-dev
<Kamion> gah, the apt-cdrom breakage is reproducible once per install only
<daniels> infinity: i don't see why they would have
<infinity> Don't see any.
<infinity> For that matter, I see almost no build-deps on libglu1-xorg-dev anyway.
<infinity> And I guess that makes sense, since you just recently renamed it, didn't you?
<infinity> So, what the heck.  Drop it on the floor, before more poeple decide to put it in their build-deps.
<siretart> debian is using libglu1-xorg-dev as build dependency, I think
<daniels> infinity: four of them, in universe.  it's fixable.
<infinity> daniels : Yeah, exactly.  No big deal.
<infinity> siretart : THat's a case that only concerns us for sync and merges, which are all by-hand right now anyway.
<Lathiat> bleh, your breaking all the gl build-deps again?
<infinity> siretart : And by breezy+1, maybe we'll be pushing modular X into Debian..
<infinity> Lathiat : No, very few, and I'll fix them myself.  Shh.
<infinity> daniels : I'm with you on the "multiple libglu packages must go" front.  Convince Kamion to promote mesa to main, and I'll do the package fixes from there.
<daniels> Kamion: what do I need to do to get mesa into main?
<daniels> infinity: GET OUT OF MY HEAD
<siretart> infinity: you are the gurus, I trust you are deciding what's best for us
<infinity> Kamion : Note that we already support mesa in main anyway, built from a copy of mesa kept in the Xorg source package, so that probably shortcircuits about 99% of the main inclusion policy.
<daniels> yeah.  the only difference between Mesa in xorg and its own source package is DRI support, which has been fixed upstream.
<daniels> unfortunately the monolithic build process is very, very attached to an internal copy of GL if we want to have DRI support, so that'll have to go last.
<daniels> *cough*mesawillneedtoprovideacopyofitssourcetreeforxorgtoabuseanywaywhenwegomodular*cough*
* daniels waves his hands and steers the conversation somewhere else.
<daniels> hopefully my previous statement vanishes into scrollback and no-one notices my gross hacks when it comes time to build the server out-of-tree
<infinity> daniels : You need the mesa source to build against?.. Can't we just get it to export everything you need and love?
<infinity> daniels : Do you statically compile some small chnks of mesa into the server?
<daniels> infinity: no
<daniels> infinity: the GLcore module is the Mesa software render, retargeted at the server by some horrendously gross hacks
<daniels> infinity: it needs deep knowledge of the server and Mesa alike
<daniels> it needs *significant* code work to be split up for 7.1; we just can't do it in the 7.0 timeframe, regrettably
<infinity> daniels : Well, that's a whole lot of ick, isn't it?
<daniels> infinity: you're telling me
<Kamion> daniels: is it urgent (i.e. before mdz gets back)?
<daniels> holy SHIT xpaint is slow
<infinity> Kamion : No, it can wait a few days.
<infinity> root@lucifer:~ # grep-dctrl -sPackage -FDepends libglu1c2 /var/lib/apt/lists/*Packages | wc -l
<infinity> 42
<infinity> Well, that's not much work.
<daniels> hint: if you're lagging behind five second on a beefy athlon64, you have already lost
<daniels> stupid bloated xaw apps
<infinity> Kamion : NEWing all of daniels's other uploads (since xorg is installed everywhere now) would be more urgent, though.  Means I can fix a hojillion FTBFSs, and xbase-clients might actually work again.
<fabbione> infinity: like ghc6?
<daniels> infinity: hold your horses, eh
<infinity> daniels : My horses are impatient, yo!
<infinity> daniels : They're got the attention span of a herd of gnats.
<daniels> they'll end up as glue regardless of what happens, so tell them to chill
<infinity> They've, too.
<tseng> daniels: there's always room for jello
<daniels> tseng: you're not allowed to talk about jelly unless you're bringing me a cup of absinthe jelly
<Kamion> infinity: my parents have just shown up, so I'll be out for a bit, but I'll do them when I get back
<infinity> Kamion : Alright, cool.  I can work later tonight, so that works for me.
* fabbione -> food
<Nafallo> Kamion: say hello from me :-)
<Amaranth> gamin is supposed to be using inotify now, right?
<tseng> yes
* mdke nods
<Amaranth> "Inotify device not opened"
<Amaranth> :/
<Amaranth> this is from the log i get when sending SIGUSR2 to gam_server
<Treenaks> Amaranth: ls -l /dev/inotify
<Amaranth> crw-rw-rw-  1 root root 10, 63 2005-07-20 02:03 /dev/inotify
<Amaranth> could it be because muine is using it?
<tseng> no
<tseng> its not locking
<Amaranth> lsof says mono is the only thing using it
<pitti> Hi shackan 
<Amaranth> looking at this debug log it looks like libgnome-menu or whatever sets up gamin to watch for menu changes isn't working either
<Amaranth> i've got something watching ~/.config/ but i think it's supposed to be watching ~/.config/menus/
<Amaranth> something is watching ~/.local too, should be ~/.local/desktop-directories/ and ~/.local/applications/
<Amaranth> *groan*, i'm going to have to dive into C code
<daniels> infinity: you don't happen to have to hand a list of everything stalled on xbase-clients, do you?
<Saba_Z> fa
<Amaranth> Reze_M: Didn't like Saba_Z?
<doko> elmo: please sync gmp from unstable
<doko> elmo: then promoting libgmpxx3 to main
<Amaranth> syscall(INOTIFY_INIT) is failing, somehow
<fabbione> Amaranth: what apps is failing?
<Amaranth> fabbione: anything that uses gamin
<fabbione> no.. gamin is failing..
<Amaranth> well, yeah
<Amaranth> Could not open /dev/inotify <--because syscall(INOTIFY_INIT); returns -1
<fabbione> well is /dev/inotify there?
<Amaranth> yeah
<fabbione> what version of the kernel and what version of gamin?
<Amaranth> crw-rw-rw-  1 root root 10, 63 2005-07-20 02:03 /dev/inotify
<Amaranth> latest kernel and gamin in breezy, let me check the versions
<Amaranth> kernel: 2.6.12.3 gamin: 0.1.2-1ubuntu1
<fabbione>         * server/gam_inotify.c server/local_inotify.h: the inotify API
<fabbione>           changed from file based to syscall, patch from John McCutchan
<fabbione> you need to wait for the next kernel
<fabbione> i have these changes already merged
* Kamion plies his parents with an Ubuntu CD
<Kamion> worth a go
<Nafallo> Kamion: I told mine they wouldn't get free support if they didn't switched from XP anymore. didn't work ;-).
<Nafallo> that "anymore" should be inserted after "support" instead ;-)
<Amaranth> err
<Amaranth> i'm looking at that patch
<Amaranth> oh, you mean gamin already has that patch
* Amaranth will back it out for now
<sivang> Treenaks: so, how do I apply a debdiff to a source package? (I tried using plain poatch, but it asks all sorts of irritating questions)
<sivang> s/poatch/patch/
<Treenaks> sivang: cd package-version; zcat ../package.diff.gz | patch -p1
<daniels> Kamion: thanks for NEWing me up
<sivang> Treenaks: thanks, I will try that now
<ogra_> W: gnome-humility-icon-theme: extra-license-file usr/share/icons/Humility/scalable/mimetypes/gnome-mime-text-x-copying.svg
<ogra_> i hate it if lintian is this silly :-/
<Kamion> no worries
<Kamion> that's why we don't implicitly trust lintian output
<Kamion> it's meant to be run through a sensible human filter
<Kamion>    * blah blah xpmutils Replaces: xbase-clients (<< 6.8.2-38) blah blah
<Kamion> that's a changelog entry? :P
<ogra_> lol
* ogra_ ponders... "to override or not to override..."
<Kamion> +Maintainer: Daniel Stone <daniel.stone@ubuntu.com> Build-Depends: debhelper (>= 4.0.0), libx11-dev (>= 1:6.2.1+cvs.20050615-1), x11proto-core-dev, pkg-config Standards-Version: 3.6.1.0
<ogra_> do i want a clean package ... hmm
<Kamion> daniels: fix that, kthxbye. ;-) (libxpm)
<Amaranth> all gnome things are using about 15% CPU now that gam_server has died :)
<doko> seb128: I'm told that cairo 0.5.2 requires glitz 0.4.4, but ubuntu only has 0.4.0
<daniels> Kamion: yearg, thanks
<daniels> Kamion: -3 and -sa?
<seb128> doko: yeah, we don't build it with glitz atm because of that, that's a build option
<seb128> doko: is glitz useful?
<doko> ah, ok, thanks
<doko> seb128: I don't know, nor do I care ;)
<seb128> k
<seb128> so why do we ask? We already have 0.5.2 built :)
<seb128> and they didn't break the API between 0.5.1 and 0.5.2
<doko> just debian sync, but maybe 0.6.0 will be out soon
<seb128> there is some new functions but no removal
<doko> seb128: could you tell that dajobe?
<seb128> doko: 0.6.0 this week
<seb128> k
<seb128> and we don't sync on Debian
<Kamion> daniels: no -sa, -1's still in queue/new
<seb128> we don't want to mess the soname as they did
<Kamion> daniels: at least I think no -sa
<daniels> 'kay
<daniels> uploading now with no -sa
<seb128> do we build with -Wl,-O1 by default?
<Kamion> I only looked at -2 first by accident actually
<daniels> heh
<sivang> bah, xlibs seems troubled
<daniels> xlibs is fine
<sivang> Setting up xlibs (6.8.2-42) ...
<sivang> rmdir: `/etc/X11/xkb/geometry': Directory not empty
<sivang> dpkg: error processing xlibs (--configure):
<sivang>  subprocess post-installation script returned error exit status 1
<sivang> eh right, I can remove this dir by hand
<\sh> daniels: u made it actually...u r my hero
<daniels> sivang: WAIT
<daniels> sivang: can you please give me a listing of stuff in there before you do?
<seb128> fabbione: do you build with -Wl,-O1 on sparc?
<sivang> daniels: hrm, I can give you file list of other dirs there that still cause this error O:-)
<sivang> daniels: basically I see it does that for stuff under xkb/ 
<fabbione> seb128: i build like everybody else...
<fabbione> seb128: no overrides...
<seb128> fabbione: do we build with that as standard on Ubuntu?
<sivang> daniels:  is complains about xkb/rules/ now, want a file list?
<seb128> fabbione: I flood you by query with #debian-glibc discussion
<daniels> sivang: find /etc/X11/xkb -type f would be very useful, yes
<daniels> sivang: have you customised it at all?  which version are you trying to upgrade from?
<mdke> there is a bug on this right?
<mdke> #12743?
<sivang> daniels: sec
<daniels> mdke: lots of them
<fabbione> seb128: i don't believe it's a -O problem
<seb128> yeah
<fabbione> seb128: specially because i can reproduce it in sid
<seb128> <vorlon> ok, I can reproduce the problem using fabbione's test case, on an alpha running sid with the current binutils and gcc-4.0.
<mdke> daniels, ok, i added my problem to 12743. the install it totally default, I haven't changed any links or removed anything by hand
<seb128> <vorlon> and it's invariant wrt the use of -Wl,-O1
<mdke> it/is
<fabbione> seb128: exactly :)
<seb128> fabbione: maybe /j #debian-glibc if you are interested to the issue
<mdke> daniels, lemme know if you want any more info posted on that bug
<daniels> mdke: will do, thanks
<sivang> daniels: 6.8.2-42
<sivang> daniels: havn't customized it
<sivang> daniels: file list:
<daniels> sivang: you're upgrading from 6.8.2-42 to 6.8.2-42?
<daniels> that code path won't even *run* in that case :P
<sivang> daniels: no, to 6.8.2.-43
<daniels> ok
<daniels> try this
<daniels> sudo dpkg --purge --force-depends xkeyboard-config xlibs
<daniels> sudo apt-get install xlibs xkeyboard-config
<sivang> daniels: working...
<sivang> Unpacking xlibs (from .../xlibs_6.8.2-43_all.deb) ...
<sivang> rmdir: `/etc/X11/xkb/geometry/digital_vndr': Directory not empty
<sivang> dpkg: error processing /var/cache/apt/archives/xlibs_6.8.2-43_all.deb (--unpack):
<daniels> mdke: ok, looks like you just need -43
<sivang>  subprocess pre-installation script returned error exit status 1
<sivang> Errors were encountered while processing:
<sivang>  /var/cache/apt/archives/xlibs_6.8.2-43_all.deb
<sivang> E: Sub-process /usr/bin/dpkg returned an error code (1)
<daniels> sivang: ok, that gives me an idea, thanks
<mdke> daniels, i will test and report on that bug
<sivang> daniels: would you midn explaining the problem ?
<daniels> sivang: that codepath shouldn't even be being run
<daniels> sivang: since $2 should be empty, so dpkg --compare-versions should bomb
<daniels> actually, no, dpkg sucks
<daniels> daniels@brainfreeze:~/canonical/xorg/app/xsetmode/xsetmode-1.0% dpkg --compare-versions "" lt "6.8.2-43" && echo yeah, definitely a bug
<daniels> yeah, definitely a bug
<sivang> daniels: so I thought so :-)
<sivang> mdke: are you going to open that bug?
<mdke> sivang, i have one open already on my problem
<mdke> reported by someone else
<Amaranth> yeah, -42 had the same problem
* Amaranth hacked his away around it and reinstalled xkeyboard-config
<sivang> mdke: cool
* mdke refuses to hack around things
<sivang> Amaranth: what did you do to make it work?
<daniels> ok, think I found the problem(s)
<sivang> daniels: oh, goody
<Amaranth> sivang: removed whatever it couldn't
<daniels>   * Protect against $2 being empty in xlibs.preinst.in, which would cause it
<Amaranth> sivang: it was a very involved process
<daniels>     to bomb when we were installing from scratch.  Don't make failures to
<daniels>     remove directories hard failures.
<sivang> daniels: but wouldn't I be left with those dirs when I should really be removing them?
<Amaranth> no, i'm pretty sure the stuff in those dirs is owned by xkeyboard-config now
<daniels> YEEEARGH
<sivang> Amaranth: yep, just did a check, seems very much so
<\sh> daniels: i just started dist-upgrade...
<\sh> *shiver*
<mdke> the reason I'm against removing things by hand and linking and stuff is that if everyone does that, the problem doesn't get fixed, then problems occur when people wanna dist-upgrade
<Amaranth> \sh: we still don't have xbase-clients, you're nuts
<sivang> \sh: you are supposed to have the same thing, I also just did dist-upgrade
<daniels> Amaranth: ideally, xbase-clients wouldn't install at all
<mdke> it keeps back xbase-clients
<daniels> Amaranth: so you're stuck back at an older version
<daniels> Amaranth: this is one of the reasons why I haven't uploaded xdpyinfo
<daniels> mdke: fortunate thing
<mdke> :)
<Amaranth> daniels: it doesn't but i don't think -10 is new enough
<mdke> the computer is smarter than it looks
<\sh> Amaranth: -36 here
<Amaranth> \sh: oh, you're already on breezy
<\sh> Amaranth: yesterday I was...yesterday afternoon on hoary...
<\sh> now back to breezy
<\sh> \sh 0 xorg 5
<Amaranth> Amaranth 20 xorg 0
<daniels> Amaranth: -10 is better than -x, x >= 38
<Amaranth> >= 38 won't install at all :)
<\sh> but I'm bullheaded
<daniels> Amaranth: this is partially intentional
<daniels> Amaranth: the plan was to not build it at all for a while, so -36 was the newest version in the archive until we could finish everything
<daniels> Amaranth: but I buggered that up good and proper, so now I have to finish all the modularisation stuff (libs then programs).  oh well.
<Kamion> daniels: you know about lt-nl, right?
<Kamion> daniels: should use that rather than checking manually whether $2 is empty
<Kamion> daniels: err ... you have uploaded xdpyinfo, I just newed it earlier
* daniels violently introduces his head to his desk.
<Kamion> binaries aren't newed yet though
<mdke> lol
<doko> Keybuk: sent you an email for MOM
<seb128> mdke: you are working with it translators, aren't you?
<mdke> seb128, yes
<seb128> mdke: https://bugzilla.ubuntu.com/show_bug.cgi?id=12815
<mdke> ty
<mdke> looking
<seb128> mdke: can you get that fixed? The it.po has a list separated by spaces instead of '\n'
<mdke> seb128, will have a look.
<seb128> mdke: thanks
<mdke> seb128, is that something I am able to fix directly in rosetta?
<seb128> mdke: just change "item1 item2 item3" by "item1\nitem2\nitem3"
<Nafallo> Simira: ! *hug* LTNS :-)
<Simira> good morning all
<mdke> seb128, ok done for hoary. will that be sorted for breezy? also, should I send it upstream?
<Simira> Nafallo : bad internet connection. I think Tollef is on the case right now.
<Keybuk> doko: am sorting stuff out before my flight right now, will try and get your list in before I leave
<Keybuk> will take a few hours, and just appear as ordinary MOM output
<Nafallo> Simira: easy solution would be to add a couple of rules to his laptop firewall and route stuff wireless -> lan :-)
<Nafallo> Simira: anyway. OT here. #norsksvenskar ? :-)
<seb128> mdke: already fixed as said on bugzilla
<mdke> seb128, oh sorry misunderstood that, great.
<seb128> mdke: np, thanks for fixing it
<seb128> mdke: ups, not, it's not, I forward upstream
<mdke> thanks
<mdke> daniels, #12743 not fixed in -43
<daniels> mdke: yeah, -44
<doko> Keybuk: thanks
<daniels> Kamion: right, done with libraries now
<jamesh> daniels: btw, the X library packages in breezy have been causing some Gnome compile problems due to their pkg-config files
<daniels> Kamion: at least, until I get to packaging the modular server.  but that's not going to be tonight, realistically.
<daniels> jamesh: the -D_XOPEN_SOURCE stuff?
<jamesh> daniels: yeah
<daniels> jamesh: yeah, we fixed that upstream a week and a half ago or something
<daniels> jamesh: i'll merge it down as soon as I get time
<daniels> got to make xbase-clients installable first
<jamesh> daniels: it looks like xproto.pc still defines _XOPEN_SOURCE
<jamesh> daniels: is there any reason why the flag is in the .pc file at all?
<daniels> jamesh: yes, because headers installed by xproto do very bad things to fds_bits
<daniels> jamesh: which has different behaviour between various _SOURCE flags
<daniels> jamesh: we fixed it so the _XOPEN_SOURCE was internalised within the header
<daniels> jamesh: difficult problem to solve, since you couldn't guarantee that Xpoll.h would be included before <sys/select.h>, so you need to have it in cflags
<jamesh> daniels: it still looks like it is there in CVS: http://cvs.freedesktop.org/xlibs/Xproto/xproto.pc.in?view=markup
<jamesh> daniels: are the xproto headers included by the libX11 headers?
<daniels> jamesh: we don't use xlibs anymore
<Kamion> try xorg/proto/X11/
<daniels> jamesh: /xorg/proto/X11
<daniels> jamesh: in any case, it's a multi-setp fix
<jamesh> ah.
<daniels> jamesh: it also involves deliberately not exposing xproto's cflags through its users
<daniels> i sense this has to be fixed again later, and it'll be me that fixes it
<daniels> (it doesn't pass any cflags through -> xproto headers off in some random prefix won't work)
<jamesh> daniels: the new pkg-config releases have the ability to list "private" dependencies which might be useful here
<daniels> there's an interim fix now, will be totally sorted out later
<jamesh> daniels: useful if you depend on a library but don't expose any of its interfaces through your own
<daniels> http://cvs.freedesktop.org/xorg/xc/include/Xos.h?r1=1.4&r2=1.5
<Kamion> pitti: fixed that apt-setup breakage, I think
<pitti> Kamion: you mean the "that's not an ubuntu cd" issue?
<pitti> cool
<pitti> because a manual apt-cdrom add worked after a reboot
<daniels> yo pitti
<Kamion> pitti: yes, it was reversed logic in apt-setup, I'm not actually sure how it used to work
<Kamion> because it succeeded if and only if apt-cdrom failed
<pitti> lol
<schlomo> Hi
<pitti> well, I manually managed to install it anyway, I even managed to fix X. But I gave up when gnome freezed
<schlomo> is it plan to add a script to ubuntu that mount automatically other OS partition  ?
<daniels> pitti: seb is responsible for all of breezy's breakage
<pitti> schlomo: this happens in the installer now (and in the live CD, too, I think)
<schlomo> it would be great so that people with multi OS can access directly to their parition
<schlomo> pitti : Ubuntu Breezy so ?
<Kamion> it's already done in the installer dude
<pitti> daniels: nope, ubuntu-desktop was just uninstallable due to some X breakages, but I was able to fix that (don't ask me how)
<Kamion> http://udu.wiki.ubuntu.com/MountingHDDFilesystems
<Kamion> still need to poke at the live CD a bit, but it's fairly straightforward
<daniels> pitti: yeah, seb's fault
<\sh> brb
<pitti> daniels: I don't actually care, I just care that it's fixed eventually :-)
<schlomo> cool
<schlomo> that's a great feature ;-)
<Amaranth> seb's fault? you mean because of libXrender.la?
<daniels> err, yeah
<daniels> that too
<seb128> what I have done again ? :p
<pitti> seb128: broke gnome, what else :-)
<seb128> no way
<pitti> seb128: I installed daily/amd64 yesterday, and gnome just froze
<seb128> I blame AudioInfrastructure
<seb128> who is in charge of that?
<pitti> dunno, but I'd kick the guy very hard
<Treenaks> pitti: LOL
<seb128> pitti: I talked with upstream, the A/V sync issues we have with totem-gst are due to esdsink, BBB strongly recommend to use alsasink
* pitti starts yet another thunderbird build and crosses fingers
<pitti> seb128: hm, with polypaudio being too unstable, and alsasink not being appropriate for every machine, only esd remains...
<pitti> seb128: btw, does it work better with polypaudio?
<pitti> seb128: after finishing the mozilla mess I might have time to fix polypaudio
* sivang is glad he is not responsible for that
<seb128> pitti: polypaudio sink is not maintained, don't count on using that
<seb128> polypaudio works quite fine here, but I don't use sound stuff a lot
<daniels> seb128: dude, VideoPlayback is causing all the problems with xlibs
<daniels> and xbase-clients
<daniels> seb128: fix that!
<pitti> seb128: no, we won't change esdsink by default, I just mean, does esdsink+polypauido work better than esdsink+esound`
<pitti> ?
<seb128> daniels: speaking about that, I've updated the wiki 2 days ago and pinged you here but you were away ... what have you done on the xine split for main? :)
<seb128> pitti: both work fine for me ....
<pitti> well, I use totem-xine, but it works fine
* seb128 kicks pitti
<daniels> seb128: er, last I checked most of the patent-screwed stuff already got fixed up by haggai
<seb128> we can't ship xine
<pitti> well, I could actually try gst again, now that I have a super fast new box
<pitti> seb128: hm?
<daniels> seb128: but I think it crept back in via a sync
<daniels> seb128: so I'll check it back out once xbase-clients is installable once more
<seb128> k
<seb128> pitti: xine has ffmpeg, is that good for main? I thought there is patents issues
<pitti> seb128: libxine1 | 1.0-1ubuntu3 |         hoary | amd64, i386, ia64, powerpc
<pitti> seb128: it was just kicked out of Breezy as it seems
<shackan> hi pitti
<Kamion> libxine1c2 | 1.0.1-1ubuntu5 |        breezy | amd64, i386, ia64, powerpc, sparc
<pitti> Hi shackan
<seb128> pitti: libxine1c2
<pitti> oops, right
<pitti> seb128: so why we have totem-xine in universe? the real stuff is in the lib anyway...
<seb128> pitti: because the lib is no meants to be to main
<pitti> seb128: well, it is since warty and we support it (I even did security updates for it)
<seb128> pitti: it was universe for warty, and k* moved it to main silently for hoary
<pitti> seb128: so either we throw it out completely, or we can as well ship totem-xine, which usually works much better...
<daniels> i think we agreed that xine wasn't the best long-term option
<seb128> pitti: when I spoke with jdub about it during .au conf he said libxine should be moved back to universe
<daniels> and that we were best sticking with gstreamer, especially with its dll loader?
<daniels> (every time I go to type that, my fingers make me type dl loader)
<seb128> daniels: the spec they "evaluate the best option for 5.10", gstreamer beeing the long term option for sure
<seb128> but gst 0.9 will not be here for GNOME 2.12
<daniels> seb128: how about we just decide that gstreamer's the best option for breezy because it's less work for me and more for you
<pitti> seb128: ok, /me installs t-gstreamer now
<seb128> daniels: fine with me, it's better than the warty/hoary version and there is pitfdll now
<daniels> haha
<daniels> so seriously
<daniels> it looks like it comes down to good av sync vs crappy av sync
* Nafallo will use totem anyway ;-)
<daniels> as well as not having to do all this work on xine shortly before we throw it away
<Nafallo> dooh!
* Nafallo will use totem-xine anyway ;-)
<pitti> seb128: well, right now its a b-dep of totem, so you'd need to split the totem package (or disable xine entirely)
<seb128> hum, right
<seb128> daniels: what has a crappy av sync?
<daniels> how bad are the a/v sync issues?
<daniels> seb128: gstreamer, according to the wiki page
<daniels> i mean, if I want to watch DVDs, I have a DVD player downstairs
<seb128> daniels: yeah, turned out this is due to esd/esdsink
<Nafallo> daniels: you has that. not everyone ;-).
<seb128> use alsasink and you will be happy
<daniels> and radeon DRI doesn't work on my card (because it's PCIE, so r300 doesn't support it), so my Xv looks like shit at high resolutions
<seb128> but according to pitti can't use alsasink
<daniels> 'cause it can't do DMA
<daniels> seb128: oh
<daniels> pitti: how come you can't use alsasink?
<pitti> daniels: you can
<pitti> daniels: if it works for you, that's the best option
<seb128> <pitti> seb128: hm, with polypaudio being too unstable, and alsasink not being appropriate for every machine, only esd remains...
<daniels> pitti: how's it broken for you?
<pitti> daniels: the problem is that dmix doesn#t work for many people, so we can't set it as default
<Treenaks> I use "autodetect".. which sink is that?
<pitti> daniels: works perfectly for me
<seb128> Treenaks: as the name say, it's an autodetection
<seb128> Treenaks: and it's not recommended yet
<Treenaks> seb128: yes, but it must have a gstreamer sink name
<daniels> meh
<Treenaks> seb128: (autodetectsink?)
<sivang> seb128: last gedit update, on what account was it? (trying to build from getting source and failing)
<seb128> sivang: "what account"? of what?
<sivang> seb128: gedit, last update, I am getting source and trying to build (without any patches) and getting this:
<seb128> sivang: who wants to know who did the previous upload? probably me
<daniels> pitti: maybe it's worth disabling dmix by default
<seb128> Treenaks: autoaudiosink
<sivang> seb128: egg-recent-model.c:903: error: 'F_TLOCK' undeclared (first use in this function)
<sivang> egg-recent-model.c:903: error: (Each undeclared identifier is reported only once
<daniels> pitti: i mean, doing alsasink by default without setting dmix up
<daniels> pitti: because esd is arguably as bad as not having simultaneous sound
<seb128> sivang: that's not a gedit change for sure
<pitti> that would be even worse than in warty - we wanted to improve it
<sivang> seb128: k, I'll do a couple of more retries
<seb128> daniels: the issue is if you use sound events
<daniels> seb128: oh, those
<pitti> seb128: ok, totem-gst with gst-ffmpeg works fine for me
<pitti> seb128: it didn't on my old box
* ..[topic/#ubuntu-devel:Kamion] : Ubuntu Development | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://www.ubuntulinux.org/wiki/DeveloperResources | If you have unexpectedly lost editbugs privileges, talk to mdz/ogra/kiko | Colony CD 2 released | yes, X is broken. | deadline for outstanding merges is 2005-07-21
<Kamion> that's tomorrow
<Kamion> so if you're like me and have loads left to do, best hurry up ;)
<ogra> Kamion, universe ??
<sivang> Kamion: that's the merge from debian you're talking about?
<Kamion> sivang: yes
<daniels> gar
<Kamion> ogra: what about it?
* ogra throws a worried look towards Kamion
* daniels stares at Kamion.
* Kamion throws a worried look towards http://udu.wiki.ubuntu.com/BreezyReleaseSchedule
<ogra> what about universe merges ?
<daniels> sweet, no MOM bugs
<daniels> phew
<Kamion> we may give universe more slack, but this is not a licence to fail to hurry up
<Kamion> we have a release to get out
<ogra> Kamion, i know but universe has a bunch more to merge ...
<Kamion> so get people to hurry up :)
<Kamion> the release schedule is not a secret
<sivang> Kamion: Do you think launchpad integration can fall under UserIntefaceFreeze ?
<Kamion> sivang: it certainly should
<Kamion> it should fall under feature freeze, for that matter
<Kamion> which is two weeks before UI freeze
<Kamion> sivang: UI freeze is so that the doc team have time to update documentation (including screenshots, etc.) before release
<seb128> there no real interface change
<seb128> only 2 menu items
<sivang> exactly
<Kamion> that's an applicable UI change
<sivang> cool
<Kamion> assuming it appears in any screenshots
<seb128> yeah
<seb128> I doubt many screenshot will have the help menu open
<seb128> anyway apps will be patched before the freeze so no worries
<seb128> I've uploaded launchpad-integration this morning, it's waiting on elmo
<daniels> maybe you could just patch in all the UI changes beforehand but make them completely non-functional
<seb128> then we can start patching apps
<daniels> and sneak in functionality after that
<Kamion> seb128: no it's not, it was rejected
<Kamion> Rejected: Unknown distribution `unstable'.
* daniels giggles.
<seb128> Kamion: grah, I use the debian dh_make changelog again?
<seb128> grrrr
<daniels> good to know I don't have a monopoly on REJECTed packages
<seb128> Kamion: thanks for pointing it
<Kamion> Maintainer: Sebastien Bacher <seb128@debian.org>
<Kamion> (usual reason why you didn't get the notification ;))
<seb128> Kamion: yeah, I use dh_make which use my Debian infos
<seb128> not the first time I make the mistake
<sivang> hehehe
<daniels> i swear I'm going to smash the next person who reports a duplicate of 'oh my god xkb wont someone think of the children'
<daniels> coc or not
<sivang> lol
<Nafallo> daniels: would be fun to report it just to see what you really would do :-)
<daniels> don't make me come over there
* pitti wants his keyboard back *duck*
<sivang> seb128: what version of automake does the builldd use?
<pitti> sivang: whatever version you depend on
<pitti> sivang: it's not installed by default
<Nafallo> daniels: well, you got half the world to travel. I'm will not be here this weekend ;-)
<Nafallo> /\'m//
<Nafallo> :-)
<seb128> sivang: what you specify from the control file?
<\sh> \sh 1/2 xorg 5 1/2
<daniels> pitti: should work with latest (-43) xlibs and latest xkeyboard-config
<sivang> seb128: I don't, I will check the gedit control file, I think that's the problem - that I use 1.7 on my machine now, and it won't build using it (it worked with 1.4)
<Nafallo> daniels: anyway. you're free to come visit if you would like to. not just this weekend :-).
<daniels> i'll leave a present on your doorstep instead
<Nafallo> we! presents! :-D
<sivang> daniels: how can I quick workaround the xlibs mess?
<daniels> sivang: er
<daniels> sivang: it should install and stuff
<daniels> if not, add exit 0 to the end of the preinst
<sivang> daniels: k
<\sh> i have -43 running, only putting a link to /usr/lib/X11/fonts/misc
<daniels> i wonder why you need that link
<daniels> oh
<daniels> maybe because I'm stupid
<daniels> yeah, woo
<\sh> daniels: without it, it won't find fixed font => fatal error
<daniels> yeah
<\sh> but: in gdm/xdm keyboard is working (actually falling back to pre-keymap) and entering gnome, no keyboard anymore...
<\sh> logging out from the session, keyboard is responding..logging in, no keyboard..will try it with kde
<\sh> now
<daniels> iz gtk bug
<\sh> hmm...
<\sh> Riddell: ping:
<\sh> ok...lemme check out kde ,-)
<Riddell> \sh: hmm?
<infinity> Kamion : Can I get mesa NEWed?
<sivang> I suppose NEW is another acronym from yet one of elmo's gf's :-) ? (like MOM, etc..)
<sivang> pitti: gedit doesn't seem to depend on a specific version of automake
<pitti> sivang: that's a bug then
<daniels> sivang: nope, it just means 'new' :P
<infinity> No, NEW is queue/new, where new binaries and/or sources get dumped.
<daniels> sivang: a package (be it binary or source) that hasn't been seen yet
<ogra> btw, could anybody wave the new icon package through that sits in NEW ? 
<Mez> are there any plans for something similar to jigdo for ubuntu
<ogra> Mez, we have jigdo files
<daniels> Mez: it's called 'jigdo'
<daniels> it's actually very similar
<ogra> as in "the same" :)
<Mez> ah i didnt know there were jigdo fiels for ubuntu
<sivang> daniels: so why is new written as NEW ? :-)
<sivang> Mez: I think you can choose them from cdimange.u.c
<\sh> Riddell: kubuntu-desktop depends on openoffice-org2*
<\sh> ?
<daniels> sivang: all katie states are
<daniels> sivang: NEW, ACCEPT, REJECT
<daniels> etc
<sivang> daniels: ah, thanks for the info about her
<daniels> any time
<Riddell> \sh: yep
<Mez> Riddell, why does it depend on openoffice - I thought you'd be shipping koffice as default for kubuntu?
<zyga> where is the appropriate place to ask about running colony cd 2 ?
<\sh> Riddell: sry..say again?
<Mez> zyga, it depends what you want to ask
<Mez> Riddell \sh: yep
<Riddell> \sh: yes, kubuntu-desktop depends on openoffice-org2*
<ogra> Riddell, except on amd64 i hope :)
<sivang> pitti: so a good idea would be to test with what version of automake it builds, and change it ? :-)
<\sh> Riddell: ok..cause it's refusing from install...when u do apt-get install kubuntu-desktop
<Riddell> Mez: that's to be decided http://udu.wiki.ubuntu.com/KubuntuOfficeSuite (but KOffice 1.4 wasn't stable enough for real use)
<pitti> sivang: yes
<zyga> Mez: installer hangs after copying and extracting packages
<\sh> Riddell: forceing it by hand..works
<zyga> Mez: box responds to ping but is otherwise, dead
<pitti> sivang: however, since that very likely already destroyed the diff.gz, please look at configure.in/automake.am in the orig.tar.gz
<\sh> and THIS is funny
<\sh> starting gnome-terminal running kde..keyboard works..
<\sh> fine :)
<\sh> hooray
<\sh> sh 1 1/2 xorg 5 1/2 gnome 0 ,->
<seb128> grumpf
<seb128> gaim CVS packages
<seb128> WTF
<daniels> seb128: given that most of xorg is from CVS atm, gaim isn't all that bad
<mpt> seb128: Did you finish the LaunchpadIntegration app-choosing tool?
<seb128> mpt: no, I've not started with that, the current plan is to patch for menu entries for main
<seb128> mpt: the picker is not a priority
<mpt> ok
<seb128> daniels: sure, but you don't have xorg and xorg-cvs
<seb128> grumpf
<mpt> seb128: So did you remove the existing "Submit Bug Report" menu item from Evolution, so that it doesn't end up with two items for doing the same thing?
<sebest> hello, is there any project to reorganize the menu, (system -> preferencies, system -> administration, applications -> system tools) ?
<seb128> mpt: no, launchpad-integration package (which is required before starting patching apps) has been uploaded this morning, there is no application patched atm
<seb128> sebest: hi, not really
<\sh> seb128: *lol*
<seb128> sebest: you can read desktop-devel-list
<seb128> what is funny?
<sebest> seb128, they talked about it?
<\sh> seb128: your "grumpf" about gaim cvs
<seb128> why people keep sending crap mails
<seb128> yeah, sure
<seb128> beeing flooded by CVS bugs, that's funny
<mpt> sebest: http://live.gnome.org/PreferencesRevisited
<sebest> because there are some annoying things in how things are organised
<Mez> hmmles
<Mez> jigdo = bad for Colony CDs
<Mez> seeing as anything thats been update gets poked top the morgue and is no longer availabl
<Nafallo> Mez: why? :-)
<seb128> sebest: there is some discussion about it on lists, feel free to read them and contribute
<Nafallo> Mez: hehe, oki :-)
<bddebian> Howdy
<thom> they get bitten by having a short SOE
<daniels> seb128: well, yeah
<Mez> so I'm getting lots of 404's
<sivang> seb128: let's concetrate on apps that appear straight in the desktop, and have a menu bar system
<sivang> seb128: thought I havn't figured what shall we do regarding stuff, like gnome-system-tools which are part of the desktop ship, and do not have a menu bar at all
<sivang> (i.e. wizard based)
<mpt> sebest: See also https://wiki.ubuntu.com/CollapsedPreferences
<seb128> mark said we can ignore these to start
<sivang> seb128: cool
<sivang> seb128: makes it a lot simpler
<sebest> seb128: would it be possible to have the "new connection" in the "system" submenu near logout instead of applications -> system tools ?
<sebest> mpt: thanx for the links, i'm reading it
<seb128> sebest: everything is possible, fill a bug upstream on gnome-panel/gdm to discuss it
<seb128> or mail desktop-devel-list
<sebest> seb128: oki
<seb128> sebest: I think the idea was to not put here as long as there is no easy way to switch back to your user
<Mez> so do the colony releases actually work?
<sebest> seb128: i think that suse get it working, maybe we should have a look at how they did it
<ogra> seb128, when do you switch your user if you make a "new connection" ?
<seb128> sebest: there is fast-user-switch-applet, but it's not installed by default and not optimal for some situations
<seb128> ogra: I don't get the question
<mpt> In what bizarre localization is it called "New Connection"??
<ogra> <seb128> sebest: I think the idea was to not put here as long as there is no easy way to switch back to your user
<seb128> ogra: have you already used windows XP?
<seb128> you can switch between users
<\sh> seb128: just like the kde switch user?
<ogra> seb128, yes, as you can with the new lock screen in xscreensaver now...
<seb128> \sh: I don't use KDE
<daniels> seb128: you should
<\sh> seb128: so it is this function ... 
<sivang> pitti: bah, that xlibs mess is preventing me from installing automake1.4 to check for the bug
* seb128 kicks daniels 
<ogra> seb128, but i dont get the point where you need to switch users for making a network connection with nautilus ? 
<seb128> ogra: who spoke about a network connection? He spoke about a gdmflexiserver new login
<seb128> it's called "new connexion" on the menu
<seb128> connection
<ogra> seb128, oh... damn, i need to switch to french to understand you :-P
<seb128> what is not clear?
<Kamion> Mez: yes
<ogra> new connection isnt the right term for that
<seb128> gdmflexiserver?
<Kamion> Mez: I don't release them until they work.
<seb128> ogra: as I understood it, he was speaking about gdmflexiserver
<mpt> seb128: In which localization?
<seb128> ogra: maybe I'm wrong
<seb128> mpt: what which localization?
<ogra> seb128, calling "new login" a "new connection" is heavly confusing
<sebest> yes i was :)
<lupus1010> is the new xorg version 7.0 ?
<mpt> seb128: <mpt> In what bizarre localization is it called "New Connection"??
<daniels> lupus1010: it will be, eventually
<ogra> mpt++
<seb128> mpt: why do you ask to me, I've no clue
<sebest> in french it's "nouvelle connection"
<lupus1010> daniels is there a list with an overview off what is new?
<seb128> "nouvelle connexion" rather
<mpt> seb128: Because you said 'it's called "new connexion" on the menu'
<lupus1010> or is the only biggest thing that you are going to a modular build system?
<daniels> lupus1010: probably on the xorg.freedesktop.org wiki somewhere
<sebest> seb128: yes
<seb128> mpt: I was saying again what sebest said
<daniels> mpt: maybe he was transliterating from French and not word-perfect on what native English speakers would call it?
<sebest> sorry to confuse everyone :s
<seb128> or I mixed
<mpt> Rosetta needs a search field
<seb128> mpt: "nouvelle connexion" is french correct version
<seb128> <sebest> seb128: would it be possible to have the "new connection"
<seb128> and I was just quoting this one
<sebest> anyway i thought it should go in the system menu
<seb128> I've not english menu to get the original version
<sebest> neither do i
<seb128> sebest: better to keep it hidden if people click on it and don't know how to get back to their desktop
<Keybuk> doko: uh, dude. your list is bogus :)
<sebest> seb128, yes i see
<mpt> Shut Down
<Keybuk> the second field has to be main or universe, not "breezy" :)
<mpt> Log in as Someone Else...
<mpt> Log Out
<sebest> there is also this "add/remove software" in application->system tools that doesn't seem to work and duplicate synaptic that is in system -> administration
<dave> highvoltage, is anyone experienced with preseeding the installer and a custom boot cd ?
<dave> *hi*
<Mez> Kamion - and do the live CDs for the colonys swor=k?
<doko> Keybuk: sent you an update
<daniels> Mez: dude, there's an archive of the lists online.  this is all documented on the lists, there's no need for all the spam in the channel.
<highvoltage> dave: sorry, i'm probably not the best person to ask.
<dave> didnt mean you - my xchat expanded hi, to hivoltage!
<seb128> sebest: it's bugged but will be fixed, and it's much simpler than synaptic and a cool tool
<comadreja> what's the official position regarding slang2 ? should it be removed ? substituted by slang1 ?
<Amaranth> i have a feeling i should look at debian-legal
<Keybuk> doko: hmm, mom is up to date for everything in that list?
<Keybuk> am I missing something?
* mpt starts translating GDM from English into English
<pitti> mpt: sounds like a lot of work
<doko> Keybuk: it's fine, if it's up to date, I couldn't check that easily.
<Keybuk> it still runs daily, just doesn't file bugs
<mpt> pitti: only 707 strings
<pitti> mpt: but en -> en???
<seb128> pitti: a way to say that upstream sucks apparently :p
<mpt> :-)
<mpt> Next I'll translate Evolution into English
<seb128> mpt: http://bugzilla.gnome.org/show_bug.cgi?id=310453
<mpt> that's a good start
<seb128> yeah
<doko> Keybuk: can you check that bug reports are filed for these packages?
<mpt> Though renaming "superuser" to "root" is rather crab-like
<daniels> you're bagging other people for their use of English while you're busting out gems like 'crab-like'?
<infinity> Word.
<Keybuk> doko: no
<mpt> Obscure Analogies 'R Us
<daniels> mpt: you've convinced me, you're totally the right person to rewrite all the strings :P
<mpt> daniels: I'm just as capable of switching between en-IRC and en-GUI as I am of switching between en-US and en-UK
<Amaranth> seb128: firefox 1.0.6 is out ;)
<sebest> mpt: i read the 2 links that you sent, there are a lot of good ideas in it.
<sebest> They are focused on organizing the current tools, that's nice
<sebest> But thing, like changing the hostname or adding fonts still remains complex/hidden on ubuntu/gnome
<seb128> Amaranth: is there security fixes or what?
<Amaranth> adding fonts?
<Amaranth> seb128: there was an API regression in 1.0.5 that broke some extensions
<daniels> dude
<daniels> my mum does not want to change her hostname
<Amaranth> seb128: and 1.0.5 isn't gettting translated upstream
<seb128> Amaranth: k, I'll update later
<sebest> amaranth: yes adding fonts
<mpt> sebest: Agreed, I was surprised at how nice Fontilus was, but it's very non-obvious how to get to it
<daniels> i don't even want to change my hostname
<Amaranth> sebest: go to fonts:/// in nautilus?
<sebest> amaranth: should users guess it? :)
<seb128> sebest: who wants to change his hostname and why, oh why?
<Amaranth> someone slap a capplet around that
<sebest> and in spatial mode how do you go there?
<Amaranth> OS X users seem to have no problem learning all these shortcuts :)
<seb128> sebest: there is a button on the font capplet
<Amaranth> and that is considered the holy grail of usability
<sebest> seb128, i know that these action are possible but there are hidden
<seb128> sebest: system, preferences, fonts is the capplet
<Amaranth> ah, someone beat me to it
<mpt> Amaranth: In OS X, Fonts/ is a real folder that you can find by starting at the root level
<seb128> sebest: there is already a bug about putting font to the nautilus places menu, but who needs to install fonts by hand?
<seb128> better to package them and to install the package
<Amaranth> yeah, but we don't have the luxury of coming up with cracktastic directories and making everything use them :)
<sebest> seb128, many people as they ask me how to do this
<mpt> Amaranth: and whether it should be "fonts:" or "fonts:/" or "fonts://" or "fonts:///" or "fonts:////" isn't exactly obvious
<Amaranth> mpt: fonts capplet
<sebest> people writing documents, doing gimp work and so on
<seb128> anyway I've to run
<seb128> bbl
<seb128> sebest: as said there is already a bug saying it should be listed with the nautilus places
<mpt> Amaranth: I know that now, but I'd used that "capplet" several times before someone pointed out the button hidden therein
<sebest> mpt: i think we could also have a font dir, as user fonts should go in .fonts as far as i remember
<seb128> fonts:/// is a collection of user and /usr fonts
<seb128> and install fonts to ~/.fonts
<sebest> can user drop a font in it?
<seb128> sure
<sebest> great
<Amaranth> mpt: file a bug report to get someone to make it more obvious inside the capplet
<sebest> so it's just a matter of accessing it
<mpt> sebest: Sure, but the second most common use case for managing fonts is probably "That font sucks and I don't want any program to use it, I want to delete it", and ~/.fonts wouldn't help there
<mpt> because it would be in (one of) the system-wide fonts folder(s) rather than the user's own one
<Amaranth> I have _never_ seen someone want to delete a font.
<mpt> I wanted to do that last week
<infinity> s/delete/hide/ then.
<mpt> so I'm biased
<infinity> If you're none too sure how the system determines what the default "Fixed" or "Serif" is, you may just want to remove (hide) the offending default.
<infinity> Or something like that.
<daniels> it's just a matter of patching ~/.fonts/local.conf
<daniels> it's a stupendously powerful system
<daniels> it can make all your I WANT IT TO LOOK LIKE THAT dreams come true
<Amaranth> does the gnome-vfs layer do that on delete?
<daniels> so if some UI genius is bored and wants to come up with a UI for fontconfig configuration (even just 'hide this font from view'), go nuts
<daniels> it's not hard
<infinity> That would be fantastically slick.
<Amaranth> i've had enough of coming up with UIs to do things like that :P
<sivang> daniels: what is the real meaning of stupendous ? that's how they described deep thought s:-)
<Amaranth> i'll stick to smeg
<daniels> it's even XML, so it's not like you have to write a difficult parser for some obscure syntax
<daniels> sivang: stupendous -> amazing, the best
<infinity> Even better if one wrote a "suitcase" replacement that could juggle fontconfig configs, so you could manage fonts in groups, etc, without touching the installed fonts on the filesystem.
<Amaranth> sounds like a bounty
<daniels> infinity: it's only one file to juggle
<infinity> daniels : Can fontconfig group fonts and turn groups on and off with ease?
<daniels> infinity: iirc, yes
<infinity> daniels : I assumed you might need to juggle configs in and out to achieve groups.
<Amaranth> someone remember all this for breezy+1 goals :)
<infinity> Bounty it now, and let someone actually have some code by the time breezy+1 opens.
<infinity> Bountying 3 months before feature freeze sucks.
<daniels> well, have your groups in ~/.fonts/group/foo.conf, and have ~/.fonts/local.conf include a different configuration depending on which group you want, if I remember wrongly and it doesn't have that sort of grouping functionality
<Amaranth> who sets up the bounties? :)
<infinity> daniels : That would work well, yes.
<infinity> The GIMP and Inkscape users would love us for that level of font handling.
<infinity> Every graphic artist I know (and oddly, that's a lot), likes to have hundreds/thousands of fonts installed, but only use them a few dozen at a time.
<Amaranth> someone needs to spec it and make it a goal
<mpt> Ubuntu doesn't *have* enough fonts for anyone to want to juggle subsets of them :->
<daniels> fonts are shit anyway
<infinity> mpt : Those sorts of users would toss a few gigs of fonts in ~/.fonts/
<sebest> on accessibility i think that "Removable Drives and Media" should be accessible from the right click menu on device themselves
* infinity glances at his girlfriend.
<daniels> infinity: i can prove she doesn't exist
<sivang> LOLs
<infinity> daniels : That would lose you your most attractive drinking buddy.
<sebest> and the "floppy formater" should dissappear from application-> system tools , and only be accessible from the right clik menu on a floppy device.
<sebest> anyway who use floppy anymore? :)
<Amaranth> bad name anyway, iirc that thing can format usb sticks and such too
<daniels> infinity: damn, good point.
<mpt> sebest: Having something only in a right-click menu makes it non-existent to a large proportion of people
<sebest> Amaranth, for me it doesn't even start: error message saying it doesn't find any device 
<sivang> sebest: hey, I needed it to fix my dead sarge router :-)
<daniels> infinity: but, in any case.  she's intelligent and from cairns, and intelligent : cairns :: matter : antimatter.  so, if she did hypothetically exist, she'd immediately undergo a total existence failure.  and thus be non-existent.  qed.
<mpt> sebest: but yes, I've already reported a bug on moving it into a Nautilus menu
<mpt> with the same menu item for formatting a floppy or a memory stick or a Zip disk or whatever
<sebest> mpt: maybe "media" instead of floppy would be more generic?
<sebest> or "removable media"
<mpt> sebest: "Format Disk..." or "Format Volume..."
<mpt> or "Erase Volume..."
<mpt> or something like that
<sivang> pitti: what's the AM_* that specifies the automake version?
<pitti> sivang: no idea, I don't use autofoo myself
* infinity -> bed.
<sebest> mpt: i think that's why ms put a visible contextual menu, it's because the right click menu is not obvious to user
<pitti> sleep well, infinity 
<infinity> kamion / elmo : It would be swell if xbase-clients's deps were all NEWed and waiting for me when I wake up.
<sebest> because this "format" action could appear in the right pane of nautilus, with thing like eject
<sebest> mpt: how people that don't konw about the right click menu can eject a media??
<zyga> does dpkg-deb -b rebuild md5sums?
<mpt> sebest: I assume that they just unplug it
<sebest> mpt: i mean a cdrom, you can't unplug it 
<mpt> http://mail.gnome.org/archives/usability/2005-May/msg00028.html
* mpt hands mdz a pair of gumboots
* fabbione hands mdz a bathsuite
<sebest> mpt: talking about ejecting, it's annoying that sometimes, nautilus complain that he can't eject a device because "it's busy" without even telling the user, which programs are accessing the drive
<fabbione> hey not everybody is so lucky to have a swimming pool in an apparment :)
<mpt> sebest: Have you reported the bug?
<sebest> mpt, should i report it to gnom, or ubuntu?
<mpt> bugzilla.gnome.org
<sebest> mpt, i didn't report it mainly because it's not a bug but a usability problem
<mpt> sebest, a usability problem is a bug
<sebest> i read the code that did this, and basically it just call system("eject /dev/hdx") and then display to the user the output of the system()
<mpt> 'The disk "Sebest's Photos" cannot be ejected, because some items on it are being used (including "dsc0079.jpg", in use by "F-Spot"). Try closing these applications before ejecting.'
<sebest> in my opinion the correct way to fix it would be to have a libeject instead of calling eject as you can't really interpret errors of programs that you call with system()
<sebest> mpt, yes that's what i would expect :)
<sebest> he could even propose to stop these programs by himself
<sebest> (that's what i do using lsof :))
<sebest> kill `lsof -t /dev/hdx`
<pitti> lifeless: here?
<sebest> mpt: nautilus Bug 148121: can't eject removable media on mac (1 button mouse) 
<\sh> is somebody working on libopenexr? it needs some glu love
<siretart> \sh: glu transition has stopped and needs probably be reversed. update from the xorg guru's pending
<\sh> siretart: dependencies problem :( since a week
<\sh> or more
<siretart> \sh: i know :(
<\sh> siretart: and I wanted to do some of the remaining MOM stuff
<Kamion> infinity: libglu1-mesa doesn't actually contain a library
<Kamion> infinity: it only has the /usr/share/doc directory
<ogra> \sh, remaining.... ahah
<\sh> ogra: not so much ,-)
<\sh> ogra: fleissarbeit ,-)
<ogra> 230 packages for universe
<ogra> http://tinyurl.com/apx5k
<ogra> and about 100 for main...
<\sh> ogra: well...long night ,-) short day ,-)
<ogra> heh
* Kamion fixes
<bddebian> Eeks
<wasabi_> http://www.cnn.com/2005/SHOWBIZ/TV/07/20/obit.doohan.ap/index.html
<bddebian> wasabi_: :-(
<lifeless> pitti: yes
<lifeless> elmo: ping - I'd like a ls report from bazaar.ubuntu.com if you are around
<pitti> lifeless: is it possible to import upstream mozilla cvs to arch.ubuntu.com?
<pitti> lifeless: right now I'm collecting patches from the cvs, but that is sooo painful...
<pitti> lifeless: does the import preserve branches?
<lifeless> pitti: we don't do branches yet, but we will be doing them
<lifeless> pitti: has their CVS structure improved, they used to be insane.
<pitti> lifeless: it's still insane, that's why I'm spending hours for grabbing patches out of it
<lifeless> pitti: then its likely a blackhole for us to import ast this point.
<pitti> lifeless: ... and why I'm pestering you
<pitti> lifeless: it would be really cool to have the various firefox/mozilla/tbird etc. branches 
<lifeless> pitti: see if you can fill out sensible details on launchpad for it 
<Lathiat> pitti: my usb drive stopped mounting again
<pitti> Lathiat: D'oh, the last version still didn't build - thanks to x...
<Lathiat> pitti: oh, right
<Lathiat> pitti: <3 xorg
<jammcq_ols> mdz: hey, any chance we can get the FUSE driver into the kernel pkg?  it's shipped with hoary as a stand-alone module
<jammcq_ols> and we use it for ltsp local device support
<mdz> jammcq_ols: fabbione / #ubuntu-kernel would be the people to talk to
<jammcq_ols> ah, thanks
<mdz> jammcq_ols: note that feature freeze is coming up (August 11th or so)
<jammcq_ols> yep
<jammcq_ols> I just heard this morning that FUSE is likely going into the official kernel soon
<jammcq_ols> mdz: also, we're planning our 3rd LTSP dev conf for Nov 3-6, and you are welcome to come
<mdz> jammcq_ols: that sounds very close to the next ubuntu developer summit, but if it doesn't overlap, that sounds like fun
<jammcq_ols> yeah, i tried finding out when the next ubu meeting was, but no answers yet
<Kamion> daniels: shouldn't iceauth, er, have some dependencies?
<Kamion> daniels: never mind, I think either I'm insane or fernanda is
<Kamion> oh, my terminal's insane, that's it
<carstenh> apropos feature freeze: if a package requiers other packages to include a simple textfile to work correctly, can this be done after the feature-freeze?
<carstenh> s/requiers/requires/
<Kamion> sheesh, xsetmode is like a 5KB package
<Kamion> was that really the most sensible split?
<seb128> Kamion: do you know if launchpad-integration is still NEW or has been dropped for an another reason?
<Kamion> still NEW
<Kamion> you could have fixed the maintainer address, then you'd know ;)
<ogra> heh
<Kamion> yay for debcommit that supports arch
<Kamion> (devscripts development trunk)
<sivang> seb128: don't worry, I'm sure it will be out of new by tommorow :-)
<sivang> seb128: btw, what do you think of the gedit source pkg? it doesn't have build-depends on an automake version, pitti said this is a bug
<fabbione> Kamion, mdz: could you be so kind to NEW aalib for sparc? i know that elmo should, but it will unblock quite a bunch of pkgs in Dep-wait
<seb128> Kamion: I don't consider my @debian.org as a wrong email :p 
<seb128> thanks 
<seb128> pitti: ping ?
<seb128> sivang: let me figure what pitti has to say against my package
<sivang> seb128: sure, I don't think it's your fault - probably the upstream maintainer's 
<seb128> sivang: k, just want to point to them errors
<seb128> tseng: have you planned to upload pitfdll to universe?
<tseng> seb128: hm i thought I gave it to you  :)
<seb128> tseng: oh, I was supposed to upload?
<seb128> I thought you gave it to play with it but that you planned to  upload
<Kamion> seb128: heh
* sivang wonders if it's possible to use pbuilder's chroot to test apps that use X
<sivang> (not just build them)
<Kamion> fabbione: I'm slightly concerned about aalib; Debian used the aalib1 -> libaa1 renaming as an excuse to switch to building against slang2, and I'm not sure I'm happy about us reverting that - it seems like it'll cause a lot of hassle
<Kamion> fabbione: I'm thinking just doing the slang2 transition might be easier, since after all it did beat UVF
<Kamion> although it is a bit more work
<sivang> seb128: I have to leave now, when lpint is out of new, test my patch for gedit let me know of any problems, thanks
<ogra> Kamion, err, isnt the one with changed deps and name already uploaded ? 
<Kamion> ogra: it's in NEW
<ogra> ah
<Kamion> that being the whole point of the conversation
* ogra just saw it on breezy-changes some hours ago
<sivang> night all!
<jp_> hi all
<sabdfl> mjg59: given that breezy is so close, we'd like to ask LaptopMission participants to commit to three releases in this first round. any objections?
<pitti> seb128: pong
<pitti> seb128: if you play evil and call automake in debian/rules, then your package should depend on and call a specific version
<pitti> seb128: I guess that was the thing sivang was up to
<mjg59> sabdfl: Nope, that's fine
<\sh> sounds really good 
<sabdfl> mjg59: ok cool, looking forward to seeing how this works out
<ogra> sounds like usplash becomes possible then... if mjg59 has more time for it ;)
<mjg59> ogra: Well, it'd be good if some other people can hack on it as well
<dilinger> mjg59: will usplash require initramfs?
<mjg59> dilinger: Yes
<mjg59> To work properly, anyway
<ogra> mjg59, would a package of it make sense ?
<ogra> (some users asked for ne)
<ogra> s/ne/one
<mjg59> Possibly
<mjg59> It's not likely to do much at the moment, though
<mdz> jbailey,fabbione: what's the word on initramfs-by-default?
<\sh> thom: ping
* pitti kills firefox with a huge patch club
* dilinger grunts happily at the sight of a dead firefox
<Amaranth> it would be so much easier if they just _stopped making new releases_
<Amaranth> :)
<\sh> universe/sound/alsaplayer_0.99.76-6ubuntu1: Dep-Wait by buildd+terranova [optional:out-of-date]  Dependencies: alsa-headers
<\sh> what is this?
<\sh> there are no deps to alsa-headers...
* pitti finally fixes hoary's firefox - YAY
<mdke> nice :)
<pitti> mdke: the patches broke the middle mouse button, it took me 3 hours to fix that :-(
<seb128> pitti: I'll update breezy one to 1.0.6
<pitti> seb128: thanks, I didn't dare to ask ... :-)
<seb128> pitti: anyway, some news on eggcups
* pitti makes a wild gesture that thunderbird and mozilla need upgrades, too
<ogra> seb128, and dont forget to make the package backportable to hoary ;)
<Amaranth> pitti: hehe, i asked earlier
<pitti> seb128: does it produce eggs now?
<Amaranth> mozilla is dropping to universe isn't it?
<seb128> pitti: no yet :p
<mdke> Amaranth, really? :(
<pitti> Amaranth: I'd like to see it there, yes
<ogra> pitti, easter is still way to go ;)
<seb128> pitti: the upstream discussion turns to "drop gnome-cups-icon from gnome-cups-manager and use eggcups for that, since dbus is much nicer than pulling"
<pitti> seb128: sounds sane
<seb128> pitti: so we would ship gnome-cups-manager as the UI for printers and eggcups as the systray notification
<Amaranth> eggcups only shows jobs in the queue from your user, right?
<seb128> pitti: so I need you to upload a patched cups before FeatureFreeze ... :)
<seb128> Amaranth: yep
<pitti> seb128: no worries, the cleanup shouldn't take that long
<pitti> seb128: also, I finally see light in the mozilla mess - only 2 hours of fighting with upstream's cvs and 4 hours of patching/building/testing, then it should be fine
<seb128> that's doesn't look to be a cool job :/
<pitti> seb128: so I can return to langpacks and cups by friday
<\sh> can someone check on his/her breezy if libgtkhtml3.1 /3.2 is in their cache?
<pitti> seb128: 
<pitti> $ cvs log -rMOZILLA_1_7_8_RELEASE: > /tmp/mozilla-1.7.8-cvs.log
<pitti> pitti@chinstrap:~/moz/mozilla$ ls -l /tmp/mozilla-1.7.8-cvs.log
<pitti> -rw-rw-r--  1 pitti warthogs 538656354 Jul 20 17:26 /tmp/mozilla-1.7.8-cvs.log
<pitti> seb128: nice changelog volume, isn't it? :-)
<seb128> yeah
<seb128> \sh: we have asked the removal of versions < 3.6
<\sh> nice
<\sh> now I need them
<\sh> or I should drop mysql-query-browser-1.1.12
<pitti> \sh: what for? does a package not work with 3.6?
<\sh> no
<\sh> without heavy patching no 
<\sh> pitti: it wants gtkhtml3.1/3.2 and gtkmm2.0
<\sh> gtkhtml3.6+gtkmm2.4 is the right combination, but the source refuses to build...
<seb128> drop it
<seb128> if it's used versions for ages ago it's not a maintained piece of code
<\sh> seb128: mysql.com ,-)
<pitti> Hi jdthood 
<jdthood> pitti: Hey there
<\sh> but it should work
<\sh> damn
<jbm_> Is it necessary to install a cpu-specific kernel to get powernowd to support frequency scaling on amd64?
<\sh> no i drop it
<\sh> damn
<Nafallo> jbm_: no. and that really is a question for #ubuntu
<mdz> doko: do you know about this already?
<mdz> dpkg: error processing /var/cache/apt/archives/openoffice.org2-common_1.9.114-1ubuntu3_all.deb (--unpack):
<mdz>  trying to overwrite `/usr/lib/openoffice2/share/registry/data/org/openoffice/Office/UI/DbuCommands.xcu', which is also in package openoffice.org2-base
<Kamion> mdz: for the GraphicalInstaller spec, do you think I can get away with only including minimal on the live CD, not bothering with standard?
<Kamion> would alleviate space problems somewhat
* Kamion -> dinner, pub, etc.
<mdz> Kamion: I think at this point I would consider base-on-live to be approximately optional
<Kamion> night folks
<Kamion> mdz: hmm, ok
<pitti> night Kamion 
<mdz> Kamion: how is OEMinstaller, btw?
<Kamion> mdz: well, I just added support to cdimage for it, we can stick it on if it fits
<Kamion> mdz: I just updated BreezyGoals with status for that
<mdz> I think it doesn't fit
<mdz> oh, thanks
<Kamion> I think I may need help, we'll see
<mdz> just = within the past couple of hours, presumably
<Kamion> yeah
<Kamion> why is alsa-base in minimal, anyway?
<Kamion> ok, really gone
<\sh> can anyone explain the dep-wait for alsaplayer? it waits for alsa-headers, but there is no build-depends on alsa-headers...
<seth_k> \sh, http://yggdrasil.sytes.net/files/debdiff/alsaplayer_0.99.76-0.2ubuntu4.debdiff
<mdz> \sh: that'd be a lamont or infinity question
<seth_k> it looks like slomo has edited this package and posted a debdiff at UniverseUnmetDeps
<\sh> no...i'm with 6ubuntuX
<\sh> seth_k: there is a MoM ongoing
<\sh> MoMmerge
<seth_k> \sh, ah, sorry
<\sh> mdz: i wonder where this comes from
* lamont__ looks
* pitti waves to lamont__ 
<lamont__> seth_k: because alsaplayer_0.99.76-0.2ubuntu3 had such a build-dep, and dep-waits do not automatically clear - someone has to poke infinity or me
<seth_k> cheers for the explain, lamont__ :)
<lamont__> seth_k: btw, -0.2ubuntu3 was the last build that was attempted, as well.
<lamont__> mdz: did you see my email on package promotion?
<mdz> lamont__: yes, but I am buried right now, both work-related and not
<lamont__> ok
<\sh> lamont__: hmm..I thought they buildd are parsing build-dep and pulling the right packages in?
<lamont__> \sh: yep
<\sh> lamont__: but?
<\sh> ;)
<lamont__> Build-Depends: libasound2-dev, libgtk1.2-dev, debhelper (>= 4), libesd0-dev, alsa-headers, ...
<lamont__> but once a package is dep-wait, it's ignored until the depwait is met
<\sh> ah u mean, even if the new package has different build-deps it goes into dep-wait cause of the old one
<Amaranth> hrm
<lamont__> \sh: no.  it _STAYS_ in dep-wait
<lamont__> package is never even looked at.
<Amaranth> bug in pyxdg moves to bug in gnome-menus moved to new proposal for freedesktop.org menu spec
<\sh> lamont__: ok..understand...
<ogra> mdz, ping
<ogra> hmpf
<\sh> lol
<\sh> ogra: bad luck
<ogra> yep
<ogra> but he has worse things to solve then answering my questions...
<\sh> ogra: yeah, me too..my ex was contacting me after 4 weeks of refusing and not knowing where she is :(
<ogra> mdz, ping
<mdz> ogra: pong
<ogra> mdz, we committed to ship mediawiki in edubuntu... 
<ogra> there is no package yet, an ITP from 2002 is in debian, but not much has happened...
<ogra> do i make an ubuntu package or do we switch to moin ?
<ogra> ITP: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=276057
<mdz> ogra: mediawiki is a PHP application?
<\sh> ogra: I would like to see mediawiki as package ,-)
<ogra> yep 
<ogra> there has been some action from andreas tille yesterday... but i doubt they will produe anything in time for breezy we could use
<ogra> http://alioth.debian.org/projects/pkg-mediawiki/
<ogra> produce even
<ogra> we'd need mediawiki for the wikipedia contents too...
<mdz> how many other items on the list are not packaged yet?
<ogra> only mediaiki...
<ogra> other packages are waiting for glu and X transitions to finish...
<seb128> mediawiki will be packaged for sure
<seb128> french DD were speaking about it yesterday
<ogra> seb128, yes, but i need to tweak the config etc... will it be in time ?
<ogra> i need some extra time for it
<seb128> I can try to figure tomorrow when they will have a package
<ogra> seb128, that'd be awesome :)
<ogra> if they cant make one i'll look into it... but it semms not trivial to get it right...
<ogra> so it will draw some time ....
<seb128> bounty?
<ogra> hmm
<ogra> it'd be a very quick one... i'll need it soon for the config tweaks and testing...
<\sh> what is debian webapps group saying}
<\sh> ?
<ogra> \sh, there is an ITP since 2002 not much has happened
<ogra> they seem to start somethig more since beginning of the week
<\sh> ogra: well...actually...if you need it for edubuntu package it...but don't package for a common server use :( webapps group doesn't have a good solution for webapps right now (imho)
<ogra> \sh, if i package it, i'll package it for common server use... and make edubuntu config tweaks at installtime....
<ogra> it would be silly to have a mediawiki that can only be sed in edubuntu
<ogra> s/sed/used
<ogra> but there was a big demand among the summit attendees... so we shouldnt leave it out...
<\sh> hmmmm...
<\sh> does it depend on stuff from PEAR?
<\sh> i can't remember
<ogra> nope
<ogra> not as far as i've seen yet
<ogra> php4 and mysql....
<ogra> you can plug in ocaml stuff....
<\sh> php5 works as well in php4 compat mode..
<ogra> \sh, i wont introduce php5 in edubuntu now :-P
<ogra> its worse enough to have php..... i dont want untested packages of php5 there
<\sh> I just think about some constrains between mediawiki+pear...ah w8 ,-)
<\sh> yes
<\sh> PHPTAL
* shaya looks at topic?
<shaya> X is broken?
<shaya> seems to work for me
<\sh> ogra: PHPTAL comes from pear
<\sh> it's distributed with mediawiki
<ogra> i dont see references to it on the page....
<ogra> but i see: PHP 5.1.0beta3 is known to be incompatible at this time.
<\sh> i was using 1.3.10 of mediawiki
<\sh> but 5.0.x was working ,-)
<ogra> i'm looking at 1.4.7 (current stable release)
<\sh> no PHPTAL anymore? 
<ogra> i see no reference... but i didnt look closer for now....
<ogra> \sh, lets see what seb128 finds out tomorrow... and either we'll bounty it or i package it, or mdz decides to drop it :) lets wait for tomorrow
<\sh> ok...
<\sh> last package for today...
#ubuntu-devel 2005-07-26
<cartel_> morning all
<jp> guys, how can I order my mails accoutns mail at evo? Somethign like this: http://www.gnomejournal.org/images/30.png
<jp> an style of: > me@me.com
<pitti> good night everybody
<jp> guys, how can I order my mails accoutns mail at evo? Somethign like this: http://www.gnomejournal.org/images/30.png
<jp> please I was trying to get it about 1 hour :/
<jp> on #ubuntu and #evolution en gnome irc nobody wants to helpme
<jp> there's no doc for that :(
<HrdwrBoB> jp: that is a #ubuntu question, not an #ubuntu-devel question
<mdke> ogra, around?
<jp> how can I excplain you that I've been waiting too much, nobody responds my question
<robitaille> jp....maybe nobody knows?
<jp> robitaille HrdwrBoB is helping me at #ubuntu
<jp> tahnks for your help dude
<jp> robitaille and he really knows it :)
* terrex nanit // good nigth
<calc> daniels: erm did you test the xlibs install?
<calc> daniels: -43 is just as broken as -42 was
<doko> mdz: fixed and updated OOo2 packages are in the archive since Mon 11th of July. until now, they could not be built for various archive breakages
<calc> perhaps for different reasons though?
<calc> Preparing to replace xlibs 6.8.2-42 (using .../xlibs_6.8.2-43_all.deb) ...
<calc> rmdir: `/etc/X11/xkb/geometry': Directory not empty
<calc> when xbase-clients and xkeyboard-config are already installed
* calc also notices xbase-clients still can't upgrade since it depends on stuff not yet available
<mrd`> xbase-clients is a known b0rkage---it's on bugzilla.
<calc> geometry however is in current xkeyboard-config and is where xlibs is bombing now
<mrd`> In the xorg maintainers defense, don't you still need to force xkeyboard-config to install?
<calc> no
<calc> you do have to force xlibs to install though since its still fucked up
<mrd`> When I installed it, it conflicted with xbase-clients -3something.
<calc> by creating those empty dirs like it says in the bug report
<calc> eg if you purge xkeyboard-config and xlibs then create the needed dirs you can then install xlibs and then xkeyboard-config (or you could yesterday when i did it)
<calc> since yesterday -43 was released which still doesn't fix the xlibs bug though
<calc> from reading 12707 it seems that xorg is being snapshotted once a day regardless if it is in a usable state though
<calc> so perhaps that is the cause
<daniels> calc: yes I did, actually
<daniels> calc: and how do you get the 'snapshotted once a day' thing?
<daniels> calc: someone helped me track down what was going wrong and I've already fixed it
<carstenh> jbailey: ping
<fabbione> morning
<bddebian> Hello fabbione 
<trulux> fabbione: heya
<fabbione> hi trulux 
<trulux> fabbione: I'm having trouble with some patches of the breezy sources, could I /query you?
<fabbione> trulux: stop flooding me!
<fabbione> you are using 12-rc5
<fabbione> try on 2.6.12.3
<fabbione> the kernel ABI changes
<fabbione> and that's easily the reason why you get these errors
<trulux> hey, I've said I'm using a newer milestone. the name of directory doesn't matter when you stack patches. I've removed all stacked patches except .13 and also tested on mm
<trulux> I keep track of all the ABI changes
<trulux> fabbione: where can I find the list of patches applied to breezy sources? I see many changes relevant to the LSM framework
<trulux> either introduced by an upstream patch (strange) or a milestone mixed with third party patches which could be a royal pain
<fabbione> trulux: in the source package but i have no changes to LSM specific to breezy
<trulux> fabbione: well, none introduced by you if that's what you want to say
<trulux> lorenzo@estila:~/breezy-kernel$ zcat linux-source-2.6.12_2.6.12-3.3.diff.gz | grep security | wc -l
<trulux> 491
<trulux> some are upstream introduced, of course
<fabbione> trulux: dude.. listen.. unpack the source..
<fabbione> and check there..
<fabbione> that grep is bogus
<trulux> fabbione: I've done that, it's a matter of time to know what are this errors about. They can't be there because of the last Suse patch upstreamed
<trulux> in any case, I'll solve this out. it's just too disappointing to ingore what's the root of the problem
<fabbione> trulux: "ingore"?
<trulux> typo
<trulux> ignore
<fabbione> trulux: let's put it this way.. you want to build an externa module.. if it errors blame the module.. all the rest of the modules in this world build against our kernel other than that one
<fabbione> trulux: so now.. it's my problem or the external module problem?
<trulux> fabbione: it can't be of the external module but I need to check further
<trulux> no worries
<fabbione> so go and check.. you know where everything is
<fabbione> sources and patches
<trulux> do you mind If I ask you any question about this in the next 2 hours?
<fabbione> abbione@gordian:/usr/src/wartydevel/kernel/breezy/linux-source-2.6.12-2.6.12$ lsdiff -H debian/patches/* | grep security | wc -l
<fabbione> 0
<trulux> I need to couple this with other stuff ;(
<fabbione> nothing in security has been patched in breezy so far
<trulux> right, I was wrong. they are upstream bits, Suse ones
<fabbione> so this is like your vanilla 2.6.12.3
<trulux> nothing wrong
<trulux> fabbione: compiles fine against 2.6.12.3
<trulux> *shrug*
<sivang> morning all!
<trulux> heya sivang 
<sivang> hey trulux 
<sivang> trulux: 'sup?
<trulux> sivang: doing some Ubuntu work :)
<sivang> trulux: selinux related?
<sivang> Doh!
* sivang reads the backlog
<sivang> :-)
<trulux> sivang: more or less :)
<comadreja> good morning all
<sivang> morning comadreja 
<comadreja> sivang : do you know anything about kdelibs and its transition ?
<sivang> comadreja: not really , I'm still fighting with xlibs mess :-)
<Micksa> okay, so if xkbcomp or whatever screws up and your alt key stops working
<Micksa> is there some command you can run to fix up X
<Micksa> (while it's running0
<Micksa> )
<Burgundavia> Micksa, that is a question for #ubuntu
<Micksa> ow
<Micksa> watch this then ;)
<grahame> hey all
<grahame> davyd told me asking in here about having ftp.uwa.edu.au become an official ubuntu push mirror was a good idea..
<grahame> we're a well-connected australian university and all :)
<\sh> can someone with main rights take care about http://bugzilla.ubuntu.com/show_bug.cgi?id=12842
<daniels> Kamion: kaping
* sivang wonders how he can make pbuilder keep files he installs there and builds between invokations.
<sivang> or should I set up a regular chroot other then the pbuilder's one to work on?
<Burgundavia> daniels, for Main inclusion stuff, can I safely assume anything that has been packaged by Debian passes debian policy and the FHS?
<infinity> daniels : Hrm.  xbase-clients is still missing 4 dependencies...
<daniels> infinity: which ones?
<daniels> Burgundavia: if it doesn't have RC bugs open on it, yeah
* davyd bings happily at grahame 
<Burgundavia> daniels, ok
<infinity> daniels : Lessee... xhost, which is dep-wait on a newer libxmuu, xranrd, which I have no idea which source package it's coming from now, xsetmode, which has NEW binaries, and xsetpointer which I also have no idea where it's supposed to build from.
<infinity> daniels : So, I guess I'm only missing two (cause I don't know where they build from)
<daniels> xrandr and xsetpointer
<daniels> what happened to libxmuu, though?
<daniels> i thought kamion newed that yesterday
<fabbione> maswan: ping?
<daniels> infinity: what version is it d-wing on?
<infinity> daniels : The version that, on closer examination, may be FTBFS.  Let me go look. :)
<daniels> infinity: xsetpointer is sitting in NEW now
<daniels> oh, yay
* sivang if launchpad-integration was not rejected last night eventually and is out of NEW
<sivang> :-)
<daniels> infinity: needs to d-w on new libxt-dev
<infinity> daniels : That'll bring it SMlib.h?... Transient dependency?
<daniels> infinity: ... which is now in the archive.  so looks like it either needs binaries NEWed, or to get kicked.
<daniels> infinity: hm, SMlib.h is in libsm-dev, which it also deps on
<daniels> ah, I see
<daniels> was looking at the wrong build log
<daniels> d-w it in libxt 1:0.1.5-4
<sivang> morning pitti
<daniels> oh, argh
<daniels> jesus I hate generated headers
<pitti> Morning everybody
<daniels> no wonder grep -r '#include' include didn't catch it
<bob2> sivang: I believe you can use 'pbuilder login' to modify it
<\sh> hey pitti
<sivang> bob2: yes, but every change I do, doesn't persist for the next time I login
<sivang> bob2: (including installation of additional packages)
<bob2> why would you install extra packages?
<pitti> sivang: that's the purpose of pbuilder
<pitti> sivang: if you want sth permanent, use dchroot :-)
<sivang> pitti: thanks, now I got an answer backing my current setup process of a dchroot.
<carlospc> That's anyone knows if the dbus will be upgraded to 0.35.2 or it will stay at 0.34?
<carlospc> i was reading the ubuntu-devel list, and i'm not sure about what will happen
<Burgundavia> pitti, can you give me some feedback (on the creation of the page, not the actual package itself) https://wiki.ubuntu.com/MainInclusionReportGcompris
<pitti> Burgundavia: just copy the raw source of an already existing one
* grahame bings at davyd
<pitti> carlospc: no, we have upstream version freeze, and dbus would break *everything*
<Burgundavia> pitti, I already did. I wanted you to check over the page I just created
* davyd bings at grahame 
<pitti> Burgundavia: can you please hide the debbugs URL and/or shorten it to bugs.debian.org/gcompris?
<Burgundavia> sure
<pitti> Burgundavia: use  [http://b.d.o/gcompris Debbugs] 
<Burgundavia> done
<pitti> Burgundavia: thanks, looks fine now
<pitti> Burgundavia: standard debhelper or cdbs packaging? or anything weird?
<fabbione> daniels: once i build xorg -43 i can unleash the other pkgs, right?
<fabbione> actually.. i did build..
<Burgundavia> pitti, I will add that and start on the rest of the edubuntu stuff. I need to create a seperate report for svgalib and howl?
<pitti> eek, svgalib???
<Burgundavia> yes
<Burgundavia> gcompris has some nasty deps
* pitti runs away screaming
<pitti> I thought it was a gnome program=
<pitti> ?
<Burgundavia> it sort of is
<pitti> make that go away *sob*
<Burgundavia> ok
<pitti> Burgundavia: we already discussed howl, there were some patent issues AFAIK
<pitti> Burgundavia: we had it in main once, then dropped it
<Burgundavia> yes
<Burgundavia> if there are patent issues, why is it in universe and not multiverse?
<pitti> infinity: guess what I spent three hours on yesterday - fixing the middle mouse button of the firefox security update :-/ deja vu?
<infinity> pitti : !
<Burgundavia> pitti, thanks for the help
<infinity> pitti : How did you lose yours?
<daniels> fabbione: yeah
<pitti> infinity: I applied a security patch that just broke it (a "compare localName" -> "use instanceof" patch)
<\sh> hmmm...who can i bribe, to have a look on https://bugzilla.ubuntu.com/show_bug.cgi?id=12842 , and to fix it? actually I would send a sixpack of good'ol'german beer
<infinity> pitti : Do you vaguely recall where in the code the breakage was?
<pitti> infinity: yes, I know it exactly
<infinity> pitti : If it's within 50 lines of where I broke things, your fix may point me at my error.
<infinity> pitti : Mail me?  Upstream patch and your final patch, to compare?  Or something?
<infinity> The bit that sucks is that initially I lost everything but the left click.  Got back the right mouse button, but could never find the middle again.
<infinity> Event handling in Mozilla makes me want to cry.
<fabbione> daniels: done :)
<pitti> infinity: for a start you might wanna try using 1.0.6's browser.js
<pitti> infinity: if it works then, you can diff them and apply the checks one by one
<pitti> infinity: I did that directly in the chrome/browser.jar in the installed system, so you don't need a rebuild for every change (yay javascript)
<daniels> fabbione: cool
<\sh> hope I fixed now mysql-query-browser for amd64 
<Amaranth> yay for KDE circular dependencies
<Amaranth> kdelibs-bin: Depends: kdelibs4c2 but it is not going to be installed
<Amaranth> kdelibs4c2: Depends: kdelibs-bin but it is not going to be installed
<\sh> Amaranth: update your pbuilder
<\sh> libopenexr-dev is now build stopper
<Amaranth> \sh: this is coming from the archives
<Amaranth> dunno about the circular dependency but it all seems to be because of iceauth and xbase-clients
<\sh> Amaranth: i just updated this morning my breezy and it worked.
<Amaranth> so it should resolve itself soon
<\sh> Riddell changed xbase-clients deps to iceauth
<Amaranth> i just updated 10 minutes ago and it didn't
<Amaranth> that xbase-clients run FTBFS then
<\sh> Amaranth: yeah..I just came along with install xbase-clients -36 ,-)
<daniels> infinity: do we have a clear list of packages which are stalled on xb-c?
<\sh> but for pbuilding only liopenexr-dev is a stopper...filed a bug already because it needs glu love...
<daniels> infinity: i'd rather prioritise which packages to build by what actually needs them
<Amaranth> \sh: that's building, not installing and using :)
<\sh> Amaranth: as i said: xbase-clients -36 ,-) and apt-get -f install ,-)
<\sh> actually u have to reinstall kdm or gdm...with dpkg --force-all -i /var/cache/apt/archives/kdm*.deb ,-)
* Amaranth is not a KDE user
<\sh> we're tough guys, u know ;)
<\sh> but i'm missing gdal-1.2.6-1ubuntu1 which I uploaded yesterday...:(
<infinity> daniels : Hold your horses.  libxmu is still unhappy.
<infinity> daniels : X11/ICE/ICElib.h.  Should libxt be bringing that in too, or...?
<infinity> daniels : As for priorities, there isn't more than an hour or two backlog anyway, so I'm not sure it's worth the brainpower to do anything other than just retry the lot.
<\sh> jesus...i forgot to upload *grmpf*
<daniels> infinity: libsm-dev should probably be bringing it in
<daniels> infinity: yeah, fixed in libsm-dev 1:6.0.3-2
<daniels> infinity: i did libsm before I started checking every library for its includes
<pitti> Mithrandir: ping
<Mithrandir> pong
<fabbione> Kamion: ping?
<Kamion> daniels: pong
<Kamion> fabbione: pong
<fabbione> hey Kamion
<fabbione> Kamion: a couple of things if you are not too busy...
<Kamion> daniels: xsetmode binaries NEWed, despite it being an incredibly tiny package; xsetpointer source NEWed
<fabbione> i did seed the rh cluster suite a few days back, but it hasn't move to main yet.. can you give it some love?
<Kamion> nothing else Xish in NEW
<infinity> Kamion : Huzzah!
<Kamion> fabbione: does it have one of those main inclusion report things?
<fabbione> Kamion: yes and it has been approved by pitti
<pitti> ack
<Amaranth> hey, does that mean we're halfway to xbase-clients? :)
<Kamion> fabbione: https://wiki.ubuntu.com/UbuntuMainInclusionQueue does not list it under "approved but not yet promoted"
<Kamion> is this ocfs2-tools?
<daniels> Kamion: thanks.  i was very tempted to combine xset*
<daniels> Kamion: arsed if I can remember what I pinged you for, though
<fabbione> Kamion: ocfs2 has been promoted. I need the redhat-cluster-suite
<infinity> daniels, Kamion : Wait, is there not a NEW source for xrandr?
<fabbione> Kamion: i did add it to support seed last friday i think
<daniels> infinity: not yet
<Kamion> fabbione: can you stick it on the queue for my reference, please?
<fabbione> Kamion: sure..
<Kamion> we're not supposed to promote non-obvious things without those hoops nowadays
<infinity> daniels : Ahh, well then that's the only missing package (barring fxing build failures on the ones we have)
<fabbione> Kamion: ok.. is it enough i add ColinQueue in that page?
<Kamion> fabbione: nooooooooo
<fabbione> hmmm i see what you mean.. somebody did mess up the 2 things...
<Kamion> do what everyone else is doing on that page ...
<fabbione> there are 2 separate reviews for ocfs2 and rhcluster
<fabbione> but ocfs2 is already in main...
<fabbione> but according to the page is deferred
<fabbione> rhcluster needs to go in main
<fabbione> but it is listed as Approved and Promoted
<Kamion> oh, FFS, I'll just edit the damn thing myself
<fabbione> Kamion: dude.. i didn't edit anything yet..
<fabbione> i was trying to understand from where your OCFS2 comment come from
<Kamion> oh, hang on, I see, it's listed as approved and promoted, hmm
<daniels> infinity: right
<Kamion> ocfs2 was just me being confused and looking around for cluster stuff
<fabbione> Kamion: that's what i mean.. it has been approved but not promoted
<Kamion> ok, yeah, somebody screwed up, I'll promote that now then
<Kamion> thanks
<fabbione> Kamion: thanks to you :)
<Kamion> ah, somebody promoted the source but not the binaries
<fabbione> yes.. the source was mandatory promotion
<fabbione> now we need to promote the binaries
<fabbione> (that are already seeded)
<\sh> infinity: could u do me a favour and check where gdal_1.2.6-1ubuntu1 is? I uploaded it yesterday evening, but I didn't get any reply from katie nor some changes mail from b-c
<Kamion> fabbione: ok, done
<fabbione> Kamion: thanks
<infinity> \sh : Hasn't come near me yet, so I assume the source was slaughtered by katie.  Are you sure you didn't get a REJECT mail?
<fabbione> Kamion: the next 2 things are very low priority.. :)
<infinity> \sh : Or accidentally upload to the wrong queue? (*cough*Debian*cough*)?
<fabbione> Kamion: if you can kindly NEW aalib on sparc since it's stalling a bunch of pkgs..
<\sh> infinity: i triple checked
<Kamion> \sh: Rejected: Unknown distribution `unstable'.
<\sh> infinity: nono ;) i have the proove
<infinity> Bing.
<fabbione> Kamion: and if we can make d-i access to universe non-fatal.. for sparc i don't really need it
<\sh> gdal (1.2.6-1ubuntu1) breezy; urgency=low
<\sh> * Resynchronise with Debian.
<Kamion> \sh: you should have got a mail; the changed-by address in that .changes is on the whitelist
<fabbione> Kamion: and it sorts of FTBFS because the local cache has no universe repo
<Kamion> fabbione: I answered your aalib query last night, saying I wasn't comfortable with doing that, sorry
<fabbione> Kamion: tho it's not a big deal
<\sh> the information is not correct...
<Kamion>  gdal (1.2.5-1ubuntu2) unstable; urgency=low
<fabbione> Kamion: oh i missed that.. ok.. that's fine.
<Kamion>  .
<Kamion>    * Renaming libgdal1 to libgdal1c2
<Kamion>    * Adjusted build-deps to xerces26
<Kamion> \sh: that's in the .changes file
<Kamion> oh, different version?
<\sh> that is 1.2.5-1ubuntu2
<\sh> i just merged yesterday to 1.2.6-1ubuntu1 
<\sh> Successfully uploaded /home/shermann/packages/breezy/gdal/gdal_1.2.6-1ubuntu1_source.changes to upload.ubuntu.com.
<\sh> and the rest as well
<Kamion> gdal_1.2.6-1ubuntu1_source.changes
<Kamion> ERROR
<Kamion> I don't get it
<Kamion> it must have been malformed somehow; did you remember to sign it?
<\sh> it's signed everything...
<Kamion> fabbione: hmm, ok, I'll have a look at the d-i/universe thing
<Kamion> well, jennifer barfed on it
<Kamion> i.e. it took some exception
<\sh> Kamion: can I try to reupload? I don't really know, cause since 24:00UTC the merge time ended and I don't have any infos about increasment of the deadline :(
<Kamion> \sh: yes, please reupload
<\sh> ubuntu2 or just upload again?
<Kamion> the deadline is fairly soft, end of today I'd like to see all of main done
<Kamion> just upload again
<fabbione> Kamion: it's more to cope with my local setting tbh.. so don't spend time on it...
<fabbione> Kamion: if it's easy = good.. otherwise still good :)
<Kamion> *shrug* it's pretty trivial to drop sparc from the list
<Kamion> just make it main-only
<fabbione> ok :)
<fabbione> thanks
<\sh> done
<Kamion> Maintainer: Silke Reimer <silke.reimer@intevation.de
<Kamion> \sh: malformed Maintainer, check debian/control
<\sh> oh nice one...why no reject mail?
<Kamion> the Debian version has a correctly-formed Maintainer address, so it was broken by the merge
<\sh> yeah..see it here :(
<Kamion> \sh: because jennifer totally fell over, evidently that trips some python library and it forgets to check
<\sh> ok..fixing and reupload...should i do a source upload again, or only -S?
<Kamion> use debdiff on the two .dsc files before uploading, to check that there aren't any other differences
<Kamion> source upload *is* -S
<\sh> -S -sa (including orig.tar.gz) -S only signed without .orig.tar.gz
<\sh> debuild ,-)
<Kamion> -S -sa please
<Kamion> I've removed the files from queue/unchecked/, reupload at your convenience
<seb128> Kamion: do you know if launchpad-integration still sit in NEW or has been rejected (and yeah next time I'll change my email)
<Kamion> it's still in NEW
<Kamion> give me a moment, I'll process it
<seb128> thanks
<\sh> Kamion: thx
<Kamion> done, should be building now
<Kamion> s/now/soon/
<\sh> there it is
<daniels> infinity: xrandr uploaded.  i've been doing apps while battling libX11 as well.  who needs other locales, anyway?
<seb128> Kamion: thank you
<fabbione> infinity: /j #u-k ?
<daniels> infinity: right.  xrandr is in NEW, and you can kick libxmu as soon as libsm is rebuilt.
<trulux> JaneW: hey
<JaneW> hey trulux - sorry we keep missing each other - I hear now
<JaneW> here even
<trulux> JaneW: hehe, no worries
<\sh> damn damn damn more fixes to go
<ogra> mdke, around ?
<mdke> ogra, yeah
<ogra> mdke, we committed to use mediawiki at the summit, because there was consensus among the attendees that they dont want something else ... :(
<Burgundavia> ogra, mediawiki is nicer from a pure user perspective
<ogra> mdke, and i have to have php anyway because of moodle...
<mdke> ogra, i don't mind! I just wanted to make you aware of the non-php faster alternatives :)
<mdke> ah ok, if you have php already...
<ogra> mdke, look at tiddlywiki ;)
<ogra> its the cooles standalone wiki idea imho :) pure javascript in a single local html file no engine at all
<mdke> ogra, i'll check it oput, i love my moin-desktop tho
<pitti> Hi shackan 
<seb128> doko: around ?
<doko> yep
<ogra> pitti, so you have fun with the edubuntu main inclusions ? :)
<seb128> I've some such FTBFSes:
<pitti> ogra: not yet, I still have fun with patching hole
<pitti> s
<seb128> doko: 
<seb128> egg-recent-model.c:903: warning: implicit declaration of function 'lockf'
<seb128> egg-recent-model.c:903: error: 'F_TLOCK' undeclared (first use in this function)
<seb128> egg-recent-model.c:903: error: (Each undeclared identifier is reported only once
<seb128> doko: the package use the build fine and has not changed, any chance that's a gcc bug?
<seb128> doko: "egg-recent-model.c:#include <fcntl.h>"
<doko> F_TLOCK looks like glibc ...
<seb128> right, but it's declared by /usr/include/fcntl.h
<Kamion> only under certain circumstances
<Kamion> #if !defined F_LOCK && (defined __USE_MISC || (defined __USE_XOPEN_EXTENDED \
<Kamion>                                                && !defined __USE_POSIX))
<ogra> pitti, i just saw your comments about gcompris on the edubuntu list :)
<seb128> Kamion: libc bug so?
<seb128> jbailey: around? :)
<Kamion> more likely something got stricter
<doko> no, jbailey is in vacation
<seb128> gnome-utils, galeon, anjuta2, etc FTBFS on that
<seb128> gar
<Kamion> or some library stopped #define'ing _FOO_SOURCE underneath you
<seb128> yeah, something broke under me for sure
<seb128> I've uploaded gnome-utils to fix the debian/control description
<Kamion> I suspect in fact something unbroke but you were relying on the breakage
<seb128> and it built fine previous time
<sivang> seb128: bon jour , is launchpad-integration out of new already?
<seb128> now it FTBFS
<doko> add -stdc=something ?
<Kamion> Xproto.pc used to set -D_XOPEN_SOURCE=500
<seb128> though it's no the same error for gnome-utils
<Kamion> or thereabouts
<sivang> seb128: should I take a look in build log?
<Kamion> so you could #define _XOPEN_SOURCE 500 at the top of your file to restore the old behaviour
<seb128> sivang: of what?
<sivang> seb128: lp-int pkg
<seb128> fdformat.c: In function fdformat_disk:
<seb128> fdformat.c:175: erreur: W_OK undeclared (first use in this function)
<seb128> for gnome-utils
<sivang> seb128: ah sorry, I thought you were talking about lp-integration pkg
<seb128> Kamion: hum, I would rather know why this got changed than workarounding a pile of GNOME packages, libegg is used all over the place
<seb128> Kamion: hum, the new build has -D_XOPEN_SOURCE, the previous succesful build log doesn't
<Kamion> I'd start by running it through gcc -E and seeing exactly what's being defined
<seb128> Kamion: I'll try to look in this way, thanks
<seb128> sivang: launchpad-integration built
<aigarius> fabbione, ping
<sivang> seb128: cool, is it in the repo already?
<fabbione> aigarius: pong
<seb128> sivang: apt-get update and you can try yourself
<aigarius> fabbione, should we discuss my SoC task here or in private?
<fabbione> aigarius: i would prefer mails to keep references, but short questions are ok here :)
<sivang> seb128: cool, now there are a couple of fixes need be done there, so as usuall I'll post you a source pckage for review when done
<fabbione> aigarius: it gives the option to NOT forget stuff :)
<aigarius> fabbione, regular backups to a directory and backups to removable media are completly different - implementing both would require almost doubling the amount of work
<Kamion> comment on debian-devel saying that tsqllib was unnecessarily C++-transitioned
<Kamion> sorry, tqsllib
<fabbione> aigarius: yes, but backups on a non-media device don't save you from an HD crash
<Kamion> (it only exposes a C ABI)
<fabbione> aigarius: they can save you only from user foo deleting file bar
* sivang is out for 1 hour
<aigarius> fabbione, it is easy to make a backup to ssh:// of ftp://
<fabbione> aigarius: yes, but you don't have to convince me. There might be no other machines around or the admin has no ssh/ftp access to remote servers or backing up 4GB via modem isn't an option
<aigarius> fabbione, as an alternative, means to write a backup snapshot to CDs/DVDs/floppys *after* the backup is done, can be made quite easily
<fabbione> aigarius: i don't think we care 100% on the backend.. but keep in mind the limits of such operations...
<fabbione> aigarius: like you need enough space to create the ISO's
<aigarius> fabbione, true, but otherwise I see no feasible way to unify the system
<fabbione> aigarius: i *think* that for the first release would be ok...
<aigarius> good. note: I will mail you the summary after the chat, to keep the record :)
<fabbione> aigarius: did you consider to use already existing tools as backend?
<fabbione> instead of rewriting what's already there
<aigarius> fabbione, yes I did. I looked at few of them and they were too complex and fragile to setup
<fabbione> ok
<aigarius> now, about user overriding admin's preferences...
<fabbione> aigarius: i think a user has no need to backup anything outside ~/
<aigarius> that is only needed if there are many knowledgable users on one desktop computer
<fabbione> the admin should have full power.. that's clear :)
<fabbione> aigarius: i can agree, but we can't assume...
<aigarius> fabbione, adding overrides complicates both the structure of the system and the user interface (on both admin and user sides)
<fabbione> aigarius: as above *i think* for the first release it's ok without
<aigarius> very good
<fabbione> it's a feature that could be implemented according to user respons
<aigarius> thanks, that's my thoughts exactly
<fabbione> no problem
<aigarius> last question - isn't there a Ubuntu SVN/Baz/Baz-ng repository I can use for code?
<Kamion> with baz/baz-ng, there's no need for a single repository, so no
<fabbione> aigarius: you can just use baz/baz-ng and share your repo via http...
<aigarius> fabbione, ok, will do that
<fabbione> aigarius: cool
<aigarius> fabbione, thanks. writting summary mail.
<pitti> \sh: just reading your changelog, if you need a manual amd64 build, just ask
<seb128> DAAAANIIIIIEEEEEEEEEEEEEEEEEEEELLLLLLLLSSSSSSSSSSS
<seb128> why why why
<seb128> $ grep XOPEN_SOURCE /usr/lib/pkgconfig/*
<seb128> /usr/lib/pkgconfig/x11.pc:Cflags: -I${includedir} -D_XOPEN_SOURCE
<seb128> /usr/lib/pkgconfig/xext.pc:Cflags: -I${includedir} -D_XOPEN_SOURCE
<seb128> /usr/lib/pkgconfig/xproto.pc:Cflags: -I${includedir}  -D_XOPEN_SOURCE
<seb128> 
<seb128> why does these define -D_XOPEN_SOURCE now?
<seb128> IT BREAKS MY PACKAGES
<seb128> daniels !!
<fabbione> seb128: or add -D_BSD_SOURCE
<maswan> fabbione: pong
<seb128> fabbione: hum?
<chmj> umount tried to eject my harddriver 
<fabbione> maswan: buttercup died again :(
<seb128> fabbione: I don't want to change anything, this is going to break half of GNOME (it already does) ... these packages used to build fine as they are
<fabbione> seb128: eehe it took me a while.. but if you check the man pages of the stuff that is failing, some of them are deprecated code in gnome that should be either replaced or reenabled in the main headers via _BSD_SOURCE :P
<maswan> fabbione: any luck in stabilizing the kernel?
<seb128> fabbione: F_TLOCK is deprecated code ?
<fabbione> maswan: no.. we will have to try 2.6.12 sometime...
<vuntz> fabbione: I don't think using a library should force you to not use deprecated code...
<fabbione> seb128: no idea.. i found that in gnome-session with struct timezone tz (gnome-session/util.c)
<seb128> fabbione: anyway putting half on GNOME on FTBFS is not an option
<fabbione> seb128: i know :)
<maswan> fabbione: ACK. I'll reboot it in a while. 
<fabbione> seb128: and don't tell me.. for me it was FTBFS before that :P
<fabbione> maswan: thanks a lot
<seb128> bah
* seb128 goes to do some syncs, there is no way to work on GNOME atm with xorg b0rking everything all the time
<ogra> seb128, any word abut mediawiki =
<ogra> ?
<seb128> I've not asked yet
<ogra> ah, ok
<Kamion> fabbione: is there a sane way to blacklist systems known to have trouble with vga16fb?
<fabbione> Kamion: hmmm let me check...
<jsgotangco> mediawiki...yuuummm
<Kamion> fabbione: (c.f. #canonical)
<ogra> jsgotangco, *shudder* 
<jsgotangco> ogra, packaging for edubuntu?
<ogra> jsgotangco, edubntu carries a lot of nightmares for me :)
<ogra> jsgotangco, yes
<jsgotangco> hahaha
<Burgundavia> ogra, the mediawiki people welcome anybody who develops for them. They are even talking of shifting languages
<ogra> but we do everything for our users :)
<fabbione> Kamion: nope..
<ogra> Burgundavia, great, but we have feature freeze soon, i doubt i'll shift mediawiki to python and postgres in two weeks ;)
<fabbione> Kamion: a dmesg would be useful tho
<Burgundavia> rofl
* jsgotangco still likes the idea of mediawiki on edubuntu
<fabbione> Kamion: the driver initialize the board in different steps and if there is a failure it jumps out cleaning behind it.. a blank screen MIGHT mean that they missed a cleaning step
<doko> daniels: should kdelibs-bin be installable again?
<Kamion> fabbione: the particular thing I'm thinking of is to make debian-installer/framebuffer=false unnecessary by blacklisting systems that are known to require it
<Riddell> doko: works for me
<Kamion> fabbione: I could do it in d-i, but usplash is going to need something similar, and it would involve less code duplication to have the kernel know
<Riddell> doko: s/xbase-clients/iceauth/ has been fixed
<jsgotangco> ogra, omg edubuntu will be able to get the ubuntu-calendar archives har har har
<fabbione> Kamion: yes i got that, but vga16fb has no check of what kind of card is there
<fabbione> Kamion: it attempts to init everything that's the primary VGA (according to the BIOS)
<fabbione> and fails if it can
<fabbione> so it can also be the card that has wrong specs
<Kamion> Right, I'm wondering if such a check could be added
<ogra> jsgotangco, i didnt exclude them yet :) to entertain our testers *g*
<fabbione> Kamion: probably it is.. not sure how simple it is
<ogra> jsgotangco, but they wont be in the default install :)
<Burgundavia> ogra, you are boring but probably correct
<ogra> Burgundavia, :p
<fabbione> Kamion: i will let you know within today.. is that ok for you?
<fabbione> Kamion: i will need a PCI_VENDOR_ID and PCI_PRODUCT_ID to create the black list
<Kamion> sure
<Kamion> thanks
<fabbione> that's the minimum i can think of
<fabbione> right now i am enjoing a little script to create shared/modules/$foo-modules
<fabbione> :)
<fabbione> it's an horrible hack that parses the output of N images with a combined $foo-modules from arch specific and create the proper shared file...
<infinity> Kamion : Another round of NEW, pretty please.  Binaries for libxmu, xrandr, and xsetpointer.
<infinity> Kamion : Then the only one left will be xhost (which is waiting on libxmu)
<\sh> jesus...i fixed mysql-query-browser
<seb128> pitti: don't cry, but I've a french user saying than your firefox/hoary update (1.0.2-0ubuntu5.4) crashes when closing tabs
<pitti> hm, worked for me...
<pitti> only with the french langpack?
<ogra> seb128, make him switch to german then :p
<Kamion> xsetpointer> sigh, another tiny package
<Kamion> daniels: I think combining xset* might well make sense, if it's doable upstream
<seb128> pitti: he uses it with english
<pitti> me too
<pitti> seb128: maybe he can talk to me directly and/or mail me?
<Kamion> infinity: done
<fabbione> Kamion: there is only one problem that i can see...
<fabbione> Kamion: is that i can do blacklisting only for PCI devices..
<fabbione> that will exclude ISA..
<fabbione> or any other kind of video bus (proprietary)
<fabbione> and the patch is not that straight
<fabbione> there are quite a bunch of stuff that needs to be changes
<fabbione> changed even
<Kamion> hmm, ok
<seb128> pitti: http://pastebin.com/317686
<Kamion> could be worse, the main use case is a bunch of laptops that fall over painfully with vga16fb
<Kamion> they're probably generally PCI
* fabbione thinks....
<seb128> pitti: he's on #ubuntu-fr, do you have any specific question?
<pitti> seb128: I joined, who is it?
<seb128> poor pitti 
<\sh> thom: ping
<pitti> seb128: does it work for you?
<doko> pitti, seb128: is somebody of you addressing the libnss and libnspr stuff, currently built from mozilla sources?
<pitti> doko: no time for that ATM
<seb128> pitti: 1- I don't use firefox, 2- I don't use hoary ...
<seb128> doko: same
<pitti> doko: are ffox's and moz's libraries compatible to each other?
<doko> pitti: heh, you have to find out ... that's the problem, see my reply on #u-d. so we have to keep mozilla sources in main
<fabbione> ~
<sivang> back
<sivang> seb128: I'm doing file-roller, just notifying you so we won't step on each other's toes
<seb128> k, thanks
<seb128> Kamion, fabbione: for information https://bugs.freedesktop.org/show_bug.cgi?id=3797 ... that's an xorg upstream issue
<ogra> Kamion, the verdict from sabdfl for squeak is more then a week ago...
<ogra> after i already lost a week discussin it with elmo
<elmo> ogra: err, what?
<ogra> Kamion, its a important part for edubuntu and should go to multiverse...
<ogra> elmo, oh, you rejected it ?
* ogra already got used to Kamion
<ogra> elmo, didnt sabdfl tell you he approved it at beginning of debconf
<elmo> no, he didn't
<ogra> elmo, i'll poke him if br wakes up
<ogra> elmo, sorry for the hassle...
<seb128> elmo: gcalctool sync please
<elmo> apparently the email I sent got bounced - resending
<Kamion> ogra: I'm not processing squeak; what anyone else does is their business
<seb128> elmo: can you sync gaim-meanwhile too, mdz said he has no objection for new universe packages
<ogra> Kamion, yes, just recognized
<davyd> so is X.org -43 sane?
<elmo> ogra: and I'd appreciate it if you toned down the language.  I have genuine concerns with squeak's license, and I've been told, by Mark, to check licenses
<elmo> so describing me as "wasting your time" isn't helpful
<ogra> elmo, i'v been told by him it should go in and he thinks its ok for us...
<Kamion> furthermore if you've been having a disagreement with elmo about a new package, please don't ever try to do an end-run around him by asking me
<ogra> elmo, nope, but i'll clearify the license stuff before i package next time... sorry wasnt meant personally...
<elmo> seb128: done
<seb128> elmo: thanks
<ogra> elmo, (i should have written i lost a week because of the licensing issues.... no matter whom i talked to)
<fabbione> hey elmo.. thanks for NEW'ing aalib
<Kamion> elmo: hmm, I'd been concerned about aalib because I'm not sure reverting the slang2 change is the right thing to do
<elmo> Kamion: oh, crap, sorry
<Kamion> nm, should've mentioned it or left a note or something
<Kamion> mdz: slang2?
<mdz> Kamion: slang2?
<Kamion> arrived well before UVF, but requires various transitional measures in other packages, including installer fixups
<pitti> elmo: If I want a mere rebuild of dpkg without source changes, uploading dpkg 1.13.10build1 would be the right thing?
<elmo> pitti: why do you want that?
<Kamion> various MOTUs have been asking about it for a while, but I don't think anyone's answered
<pitti> elmo: fixed two vulns of zlib recently (one today), and it's possible that it can be used for code execution
<pitti> elmo: this is not an issue for installing packages, but for dpkg-source -x on unknown sources
<elmo> oh, right.  yeah, I guess that's fine
<pitti> elmo: pretty small attack vector, but since it doesn't cost much to fix it, I'd like to do it
<pitti> ok, thanks
<bob2> dpkg compiles in zlib statically?
<pitti> yes
<bob2> ah
<pitti> bob2: I asked Keybuk whether dynamic linking would be possible, but it broke at least in earlier times
<pitti> actually it should be possible now
<bob2> `anthony: the "ethel the frog" link on the shtoom site is 404
<bob2> pitti: ah, right
<Kamion> having dpkg depend on too many other libraries complicates things
<pitti> yes, right
<lifeless> elmo: hello?
<sivang> bob2: who's ethel the frog ? ;)
<Kamion> daniels: around? xhost ftbfs, build-depends: libxau-dev
<sivang> seb128: I don't want to nag too much, and I may be dumb, but are you sure launchpad-integration is in already? ;)
<seb128> sivang: grrrrrrr
* sivang hides
<seb128> sivang: it's probably NEW 
<seb128> it has built, look the build log
<seb128> but the binaries are new, so ...
<Kamion> elmo only processed the binaries a little while ago
<seb128> sivang: see, no need to be that impatient 
<sivang> Kamion,seb128 : k, sorry, <mental note>have to work on may patience some more</mental note>
<Kamion> they're in universe, propagating to the archive
<Kamion> elmo: how do you do that NEW-straight-to-universe thing, anyway?
<seb128> can you move them to main ?
<Kamion> main inclusion report, blah, etc.
<seb128> graaah
<seb128> "trivial lib made by jamesh for LaunchpadIntegration spec, kthxbye"
<sivang> hehe
<seb128> k, I'll
<seb128> s/trivial// maybe :p
<Kamion> also, seeds, kthxbye. :-)
<sivang> hehehe
<seb128> yeah
* davyd embraces daniels 
<sivang> Kamion: do we also need a security review for it?
<Kamion> I think the requirements page is clear
* sivang offs and read that page
<ogra> davyd, did it work without tweaks ?
<davyd> ogra: I have a sanely installed -43
<ogra> yay
<davyd> and my Xvideo is working it seems
<ogra> yay++
* sivang goes  to try -43  on the other test box
<fabbione> Kamion: i am afraid we can't ban devices in vga16fb
<fabbione> Kamion: the struct that tells me what device (given there might be more than one) is filled only after the fb has been initizialized
<fabbione> Kamion: basically too late
<Kamion> ah
<fabbione> the PCI only approach won't work.. not with the logic we need
<fabbione> of banning a device instead of probing on it
<fabbione> i am sorry. that code is a real mess...
<Kamion> maybe I'll just have to blacklist it in rootskel, then. ugh.
<Kamion> thanks anyway
<mjg59> Can't it be done based on dmi information?
<mjg59> Are there any desktops where it fails to work?
<Kamion> don't know
<mjg59> It tends to be integrated chipsets, in which case it could just be done with DMI information
<fabbione> mjg59: well i have no idea how to do that..
<fabbione> mjg59: if you know a way i welcome crack and patches.. specially the former :)
<mjg59> fabbione: See arch/i386/kernel/dmi_scan.c
<fabbione> mjg59: mjg59: i am not exactly sure how that can help me....
<fabbione> or i just don't understand the code
<mjg59> fabbione: That lets you run code on machines that have specific DMI entries. Use that to set a global variable that disables vga16fb on load.
<mjg59> The problem is generally per machine, not per chipset
<Mithrandir> daniels: could I please have my dead keys back?
<fabbione> daniels: same here please.
<fabbione> mjg59: ah ok.. 
<ogra> Mithrandir, hygienic feature ;p
<fabbione> mjg59: ahh i see.. basically it scans the DMI for blacklisted devices and execute code in case of matching...
<fabbione> mjg59: seems interesting...
<mjg59> fabbione: Yup
<fabbione> for that i will need a global var....
<fabbione> pain!
<fabbione> Kamion: i guess it's possible than...
<fabbione> but i think userland blacklisting is faster to start to test with...
<fabbione> specially because updating the kernel for a blacklist isn't exactly fast
<Kamion> elmo: please sync hfsutils 3.2.6-9
<Kamion> (ok to override)
<elmo> Kamion: done
<Kamion> ta
<|rockinnerd|> Is there a ubuntu option for debootstrap?
<Kamion> er, yeah, we use debootstrap in our installer
<tseng> |rockinnerd|: you just debootstrap an ubuntu dist from the ubuntu archive
<tseng> same as any other debian dist
<|rockinnerd|> ah. 
<|rockinnerd|> tseng, where is the archive>
<infinity> elmo, Kamion : One left.  Can I get the xhost binaries NEWed?
<tseng> archive.ubuntu.com?
<|rockinnerd|> ah
<tseng>  /ubuntu
<Kamion> |rockinnerd|: it's the default in the Ubuntu debootstrap package
<Kamion> infinity: elmo is either faster than you or faster than me or both
<thom> elmo: ping? (yes, this is related to the stories currently bouncing on news.bbc)
<elmo> thom: ?
<thom> elmo: more bombs in london
<elmo> thom: yah :(
<bob2> unconfirmed report of a bus, too
<pitti> even more? damn
<elmo> we're all fine and in the office, FWIW
<thom> reports of nailbombs going off on buses
<|rockinnerd|> thom: s/buses/underground
<bob2> |rockinnerd|: no, both
<|rockinnerd|> #kubuntu was talking about it
<thom> |rockinnerd|: no, buses too now
<davyd> oh, what?
<havoc> people suck
<|rockinnerd|> bob2, oh i thought it was gunshots on buses
* davyd observes there is currently very little news on the topic
<havoc> |rockinnerd|: they're saying that it may have been the detonators going off without detonating the main explosive, which would sound like a gunshot
<jordi> elmo: good to know |:
<havoc> but I heard it on FOX News, and we all know how "reliable" they are
<|rockinnerd|> btw, its the 2 week aniversery of the london bombings again
<|rockinnerd|> havoc, same here, but at least its better than M$nbc
<havoc> if you have cable you can see the same friggin shots on 6 different news channels
<Amaranth> US news hasn't picked up on the bus yet
<Treenaks> Amaranth: Dutch news has
<thom> all of london underground is at code amber, all stations evacuated
<Treenaks> Here we go again...
<Amaranth> haha
<Amaranth> US news is saying that it might not actually be bombs
<Amaranth> stupid people
<Treenaks> Amaranth: it might be a quantum-anomaly cap'n
* sivang hopes UK police and special forces take hold of the people casuing this
<Treenaks> I hope the people causing this stop causing this in the first place
<havoc> as I said, people suck :(
<Treenaks> havoc: </oldnews>
<havoc> yeah :(
<pitti> havoc: well, people do their best efforts to clean away that "people" problem :-/
<pef> hello !
<bddebian> Morning
* sivang high fives bddebian 
<bddebian> Hmm, thanks. :-)  What is that for? :-)
<ogra> stimulatin the blood circulation in your hand, very healthy ;)
<sivang> hehe
<sivang> bddebian: ogra explained it rather funny
<bddebian> heh
<Burgundavia> pitti, I now have someone on #ubuntu complaining about the latest hoary ff being unstalbe
<bddebian> Hello mgalvin, sabdfl
<pitti> Burgundavia: answered
* bddebian is vying for "Official Ubuntu Greeter" :-)
<Burgundavia> pitti, cheers
<Burgundavia> pitti, I don't envy you, but nice work
<mgalvin> hi bddebian
<mgalvin> hi all
<sabdfl> hi all
<pitti> Hi sabdfl
<ogra> hey sabdfl 
<bddebian> ogra: So the deadline is still today?
<ogra> bddebian, for main at least....
<bddebian> ogra: Oh aye, I meant Universe.  Sorry, wrong channel :-)
<bddebian> tritium!!
<tritium> hello, bddebian :)
<Kamion> elmo: please sync tla
<ogra> Kamion, mdz can we extend the deadline fo universe merges some days (sunday would be ok according to the MOTU)
<ogra> we face a lot of problems... with X, GLU etc ...
<infinity> ogra : "Finishing merges" doesn't mean "Everything must be in tip-top shape".  We have 3 months to clean up broken library transitions and make sure nothing is FTBFS, etc.
<infinity> (Also, rejoice, xbase-clients is installible again)
<pitti> \o/
<ogra> infinity, yes, but we only have a handfull actively working MOTUs currently (lots of exams everywhere) and randomly changing build depndencys though several transitions...
<ogra> s/though/through
<ogra> and MOTU has more then 200 merges to handle...
<seb128> pitti: 
<seb128> $ gnome-sound-properties
<seb128> ALSA lib pcm_dmix.c:841:(snd_pcm_dmix_open) unable to open hardware
<seb128> 
<seb128> known issue?
<seb128> and the soundcard selector is empty
<pitti> no, actually not
<seb128> k, I'll bugzilla it
<pitti> it is empty when it can't open the sound device
<seb128> yeah, that's what the error says :p
<tseng> seb128: should we still be disabling pango in /usr/bin/firefox?
<seb128> tseng: nop, I've fixed firefox for that before uploading the new GTK
<tseng> seb128: awesome :)
* Diziet `adjusts' a PC case with a bike tyre lever.
<Amaranth> seb128: you 'fixed' firefox?
<ogra> Amaranth, for this special incident
<bddebian> Diziet: :-)
<seb128> Amaranth: what's the matter with that?
<Amaranth> seb128: well, it sounded like fixing that problem was going to be a PITA
<seb128> Amaranth: I've just patched the package, not made the patch ... and the patch is quite short, that's just a matter to no use the wrong stuff with pango
<Amaranth> ah
<thom> just a matter of changing the pango calls to be generic rather than xft specific
<seb128> thom: please take firefox back, I'm sure you love hacking on it :p
<thom> hahah
<sivang> is thom back? ;)
<Treenaks> was he gone? :P
<thom> seb128: my spare time is too precious for firefox :P
<sivang> lol
<Kamion> fabbione: I'm merging silo, and the new Debian version explicitly sets CC=gcc-2.95. Should I revert that?
<Kamion> fabbione: (I'm assuming you checked it out with newer gcc etc.)
<fabbione> Kamion: new silo is FTBFS with gcc-4.0
<fabbione> Kamion: i did check with upstream, and they didn't work that out yet..
<fabbione> Kamion: if you want to merge make it build with -3.3
<fabbione> i think it build with 3.3,,,
<Kamion> fabbione: I'll just reassign the merge to you instead, I think ;-)
<Kamion> (since you can test it ...)
<fabbione> Kamion: that's fine...
<Burgundavia> pitti, are you pilling the .6 extensions fixes?
<pitti> Burgundavia: I try whether they help
<Burgundavia> ok
<Kamion> elmo: please sync net-tools
<seb128> elmo: and mpfr, thanks :)
<mantas> which package contains mkfontdir?
<ogra> mantas, use apt-file
<Kamion> mdz: you made this change in tftp-hpa for hoary:
<Kamion> +  * debian/tftpd-hpa.init: be silent if running from inetd rather than
<Kamion> +    init, and coincidentally fix operator precedence problems
<seb128> elmo: xosd too please
<Kamion> mdz: The operator precedence problems have been fixed in Debian. Are you particularly bothered about the first half of that change? It seems wrong to me - I'd rather the init script told me when it wasn't doing anything.
<elmo> B-A-N-A-N-A-S
<thom> nooo
<ogra> ??
* thom beats elmo until he stops
<bddebian> elmo is listening to Gwen Stefani?
<thom> worse, he spent all of debconf singing that
<elmo> seb128/kamion: done
<Treenaks> elmo is dating Gwen Stefani?
<seb128> thanks
<\sh> siretart: please make a note...elma should play mp3s during compiling...streamed to the net ,-)
<pitti> \sh: he's still male (AFAIK :-) )
<\sh> pitti: u don't know elma :)
<Kamion> elmo: also cfengine
<\sh> pitti: elma is our MOTU Automated elmo ,-)
<pitti> oh, I see
<\sh> short form of: elmo automated
<azeem> is it a very small shell script?
<bddebian> heh
<elmo> Kamion: done
<\sh> azeem: actually it will be the sister of elmo, working for sbuilds, ftp and keyrings but she's contracted to MOTU only ... she doesn't like to work for main ,-)
<sivang> automake1.7 is considered the "right" version to use?
<mdz> Kamion: I can see the utility of it printing a message in that case if run manually, but it's useless during boot
<mdz> and I don't know of a reasonable way to make the distinction
<Kamion> mdz: [ -t 0 ]  ?
<\sh> thom: ping
<Kamion> mdz: can't remember if stdin is a tty during boot, but I suspect not
<jan1> elmo do you know what happens with packages synced from sid that are new in ubuntu?
<infinity> I'm pretty sure it is.
<jan1> mercurial seems to be missing although it is in debian
<thom> \sh: nack
<infinity> Kamion : Otherwise, all those people who insist on having encrypted apache certs couldn't type in passphrases, could they?
<Kamion> infinity: hmm
<\sh> thom: damn..i need a short info ,-)
<infinity> (Of course, I do my best to discourage that practice by making it rather tough for them to do so)
<jan1> is there an up-to date baz archive of apt?
<Kamion> damnit, we need bug-resolution-by-resolver stats. :)
<thom> infinity: let's not mention it's pointless anyway
<thom> \sh: ask, but you may not get an answer
<infinity> thom : That's why I discourage it.  Heartily.
<infinity> thom : I'm sure you've seen me engage in lively "debates" about it on the lists and in bugs before.
<\sh> thom: netapplet...you rewrote half of the source
<thom> yes, and it should be thrown away
<\sh> thom: I have to merge it now with netapplet-1.0.0
<thom> \sh: bin it
<\sh> thom: so I can use the upstream source
<Kamion> seb128: want to resolve #9501, since you just requested the sync?
<fabbione> hey thom
<\sh> k
<\sh> thom: thx 
<thom> infinity: indeed
<infinity> Hrm.  Speaking of throwing things away...
<infinity> thom : What if we just patched apache to no longer provide a passphrase prompt, but just error out with "your certs are encrypted and we can't do that, decrypt them or suffer."?
<infinity> THat would solve the issue once and for all.
<Kamion> \sh: could you close merge bugs when you perform the merges, please? (python-fuse)
<\sh> Kamion: yes...I'm just working..most of mine are closed...
<thom> infinity: very, very evil
<Kamion> \sh: ok, cool, thanks
* Kamion is working his way through the list of unassigned merge bugs
<thom> infinity: co-admins here approve ;-)
<thom> infinity: although we might want to work on the text of the error
<infinity> Kamion : Feel free to reassign a bunch of pending ones to me.  I'm going to be up for a while.
<infinity> thom : To make it more insulting?
<thom> absolutely
<infinity> thom : (alternately, to point at documentation about why encrypted certs are useless, I suppose, but that's less fun)
<infinity> thom : I say we check perms on the cert, make sure they're only readable by root, die if not (a la SSH), and die if they're encrypted.
<thom> +1
<fabbione> infinity: -1
<fabbione> i did that patch.. it works fine..
<fabbione> and makes (not so clever) admins happy
<lamont> elmo: please sync palo_1.9 and palo-installer_0.0.7
<lamont> hrm... palo is still just in accepted
<infinity> fabbione : What patch is this?
<lamont> (both differ from breezy version only in that they fix the FTBFS that breezy has...)
<zyga> hello
<zyga> is everyone okay?
<fabbione> infinity: the one for apache 1.3
<fabbione> infinity: that caches the passphrase.. to handle the reload of otherwise encrypted certicates
<jan1> elmo,kamion: in principle can we sync XFCE4.2.2 packages from os-work.com repository instead of debian/unstable?I am currently checking but we synced from ther for hoary too and they incorporated some of our ubuntu1 changes
<jan1> whereas the debian packages are more divergent and caused lots of merge failures
<jan1> http://os-works.com/debian/ actually not os-work
<jan1> there are two groups working and while reconciling them we want to chose what's best right now forubuntu
<Kamion> infinity: great, I'll give you a batch of the older ones then
<Kamion> any other volunteers for a batch of main merges?
* ogra is busy with xscreensaver.... 
<doko> elmo: please sync binutils from unstable
<fabbione> doko: does it fix the sparc problem?
<\sh> me is busy with universe merges..we can talk about main merges next year? ,-)
<mdz> Kamion: yeah, that's probably reasonable
<doko> fabbione: no, that sync is a no-op for our architectures
<fabbione> doko: ?
<Amaranth> it fixes something on an arch we don't care about but it's good to have the same version?
<fabbione> doko: please define our architectures :)
<fabbione> doko: does that include sparc or not? ;)
<doko> that change was mips only
* pitti hits thunderbird very hard
<doko> afaiu seb128, the sparc link issues should be solved in pkg-config, please nag the package maintainer ...
<doko> elmo: please sync build-essential from unstable
<elmo> why is everyone suddenly doing syncs?
<elmo> did MOM not get the message about UVF, or is it just catchup?
<ogra> elmo, manual merge deadline (see topic)
<Kamion> FSVO "dead"
<fabbione> doko: ok thanks
<doko> elmo: yes, outstanding syncs. I'm unsure, if I can get all of them done today ...
<zyga> did anyone notice firefox's latest update started crashing from time to time?
<elmo> doko: done
<Burgundavia> zyga, yes
<pitti> zyga: YES *whine*
<fabbione> Kamion: is the merge deadline today?
<fabbione> or tomorrow?
<pitti> zyga: it seems to happen for everybody but me
<zyga> pitti: I'm sure it's related to extensions
<pitti> zyga: it is, I now found one extension which makes it crash
<Kamion> fabbione: today. I don't know what happens if main merges are incomplete after today; it's never happened before
<fabbione> Kamion: i think i have only silo to merge...
<zyga> pitti: It crashes all the time when I press ctrl+w to close a tab
<Kamion> there are 62 unassigned main merge bugs
<zyga> pitti: there should be firefox-gdb 
<elmo> lamont: palo-installer done, remind me about palo later?
<Kamion> fabbione: good, that means you can have some more?
<fabbione> Kamion: no, because i am working on the kernel
<fabbione> i am busy and it's driving me nuts...
<pitti> zyga: can you try to uninstall extensions one by one and look when it doesn'T crash any more?
<Kamion> everyone has their own targets as well, I know
<Kamion> but we are behind
<fabbione> Kamion: i am already a week late with this kernel..
<zyga> pitti: sure
<doko> mdz: I'd like to sync/merge the packages from the CxxLibraryList if possible, but looking at the length of the list, I won't finish this list today. Can we delay syncs from this list over the weekend?
<Amaranth> fabbione: That'll be the one with the inotify that matches the new gamin, right?
<fabbione> and if the deadline is today, i won't manage.. it's already 10 hours i am here around working
<mdz> doko: how many packages?
<zyga> btw where can I look up the reason for new packages in -security and what they are fixing?
<zyga> changelogs in debs?
<mdke> zyga, the security mailing list
<Amaranth> zyga: hopefully
<Amaranth> and that
<mdz> doko: apt doesn't need a transition, btw
* zyga needs to sign up on that one
<zyga> okay let's kill those extensions
<pitti> zyga: also on http://www.ubuntulinux.org/support/documentation/usn/
<fabbione> Amaranth: yes.. i already told you
<Amaranth> fabbione: yeah, just making sure i understood you
<lamont> elmo: ok
<mdke> zyga, http://lists.ubuntu.com/archives/ubuntu-security-announce/2005-July/thread.html
<zyga> pitti, mdke: thanks
<mdz> bugzilla seems very confused
<doko> mdz: 315 according to the list, minus those with new upstream versions in unstable. 71 in main
<thom> mdz: any chance you can remove me from being assaulted by firefox bugs when it becomes less confused? :-)
<zyga> why doesn't firefox's --help message include the plethora of options it really accepts, *sigh*
<mdz> thom: stand by while firefox renders a few megabytes of HTML in order for me to do that
<thom> sure :-)
<doko> mdz: yes, apt was already done. btw, is apt built by g++ 4 in unstable?
<Amaranth> zyga: 'plethora of options' sounds like a good reason why
* mdz makes a note to add support for this to debzilla.py
<zyga> Amaranth: like really needed --debugger 
<mdz> I am going to strangle whoever came up with these ridiculous keyboard shortcuts
<Amaranth> heh
<zyga> does anyone need a backtrace? 
<carstenh> ogra: ping
<mdz> doko: apt generates its provides based on the g++, glibc, libstdc++ versions
<ogra> carstenh, pong ?
* Amaranth tries to remember which one mdz hit on accident in xchat
<thom> mdz: heh
<fabbione> hmm wierd
<carstenh> ogra: that was very fast :)
<thom> ctrl+w i guess?
<fabbione> i never got a notification of kernel-package merge!
<ogra> carstenh, :)
<Amaranth> ctrl+w is close tab in lots of apps though :P
<mdz> thom: no, I've crippled ^W
<carstenh> ogra: do you have some kind of naming-convention for you graphical config tools?
<mdz> thom: but shift+ctrl+w apparently still works
<davyd> I patched Ctrl-W out of my X-chat
<mdz> and I hit that by accident sometimes
<ogra> carstenh, nope
<Kamion> fabbione: um ... you did it
<davyd> which I think Ubuntu should do by default
<Amaranth> why do you guys hit ctrl-w so much?
<Kamion> fabbione: seems you're not the default assignee for kernel-package bugs though
<zyga> pitti: no luck, removing extensions SIGSEGV's too
<Kamion> Amaranth: delete word
<thom> Amaranth: delete word
* fabbione sighs
<carstenh> ogra: what are the names of those that are finished?
<Amaranth> oh, terminal freaks :)
<pitti> zyga: I hate you all
<pitti> ;-)
* carstenh needs a  name for his firewall-gui
<Kamion> mdz: could you assign kernel-package to fabbione by default while you're at it?
<fabbione> Kamion, mdz: can i have tomorrow morning to complete my merges?
<Amaranth> ctrl-w is standard for close tab in GUIs though
<Amaranth> patching it out by default is a bad idea
<Kamion> Amaranth: we were here first :-P
<davyd> Amaranth: perhaps your GUI
<zyga> pitti: don't loose hope yet
<Amaranth> Kamion: you're outnumbered
<fabbione> given i was checking the merges via emails and not got the right notifications...
<Amaranth> davyd: gedit, firefox, and xchat
* davyd has a GTK keyboard theme that implements the standard GNU Readline keystrokes
<Kamion> doesn't stop us configuring you out of existence ;-
<Kamion> )
<mdz> Kamion: it's actually not any easier while I'm at it; it still takes about 30 seconds per change
<Amaranth> davyd: haha, i'm talking about standard configs
<Kamion> mdz: ugh
<ogra> carstenh, ndisgtk (a frontend to select dlls in ndiswrapper) and the second my bountier is just working has no name yet....
<davyd> Amaranth: it comes with I rsync my home directory
<ogra> carstenh, just pick something descriptive
<carstenh> ogra: ok, thanks
<davyd> that's pretty damned standard
<zyga> pitti: -safe-mode does not crash
<mdz> Kamion: and so of course I wander off and do something else while waiting for the page to load and render
<mdz> and then forget about it half the time
<Amaranth> davyd: Your config is installed by default on every machine with Ubuntu installed? :)
<davyd> Amaranth: and every other machine
<carstenh> ogra: i like the way how fedora names it's config-tools. just system-config-tab and you see all that are installed :)
<zyga> pitti: but opening the extenions menu does, darn
* Kamion discovers that lftp supports 'cd -', yay
<davyd> my scripts are filled with lots of random stuff to check uname and hostname and all sorts
<Amaranth> davyd: I don't mean your machines
<Amaranth> davyd: You're outnumbered, give it up. :)
<Kamion> Amaranth: why do you dislike people changing their configuration?
<davyd> pfft, ctrl-w is sensible
<davyd> unlike ctrl-backspace
<Amaranth> Kamion: I don't, I dislike suggesting ctrl-w be removed from xchat.
<ogra> carstenh, but is the target of a gui tool to be started from commandline ? :)
<davyd> which is something I couldn't get used to
<carstenh> ogra: if i use them, yes. but normally not
<davyd> ctrl-w and ctrl-u are the most useful ones
<ogra> carstenh, for me a working .desktop file or the button to start the app in the right place are more important ;)
<Amaranth> davyd: backspace deletes one char, ctrl-backspace deletes an entire word, it makes sense here
<davyd> closely followed by ctrl-a, ctrl-e and alt-d
<davyd> Amaranth: but you have to stretch for it
<Amaranth> reaching for ctrl all the time gives you RSI anyway
* carstenh doesn't use menus or such things. only xbindkeys and xterm
<davyd> I rest a finger on the control key pretty much
<davyd> but yes, I'm sure I'm doing my left hand damage because of it
<mdz> Kamion: right, now you have editcomponents privileges. enjoy :-)
<mdz> Kamion: I did kernel-package
<davyd> but commonly, rather then backspace mistakes, I just ctrl-w them
<davyd> this is why I will keep vanishing on unpatched X-chats
<davyd> until I find my xchat debs
<Amaranth> perhaps the real solution is to make xchat use the default GTK shortcut?
<Amaranth> err, not default
<mdz> Amaranth: the problem is that the default gtk shortcut is stupid
<davyd> the solution to do it properly is to make X-chat have remappable shortcuts
<ogra> carstenh, but you would set your firewall rules without gui anyway ;) 
<davyd> but that looked rather hard
<Amaranth> davyd: why not make it use whatever GTK uses?
<ogra> carstenh, so youre not really the target audience ;)
<davyd> Amaranth: the problem is that X-chat basically has it's own menuing code
<davyd> and doesn't use any of the nice APIs
<davyd> plus, because of all that customisable menu bollocks, it is hard to use the nice APIs without overhauling large chunks of it
<Amaranth> heh
<davyd> plus I'm not sure if I could get it upstream
<davyd> so I don't care enough
<Amaranth> oh well, xchat will be replaced with xchat-gnome in the end
<thom> hahaha
<davyd> sure, if it ever gets off the groun
<davyd> *ground
<zyga> pitti: okay I had a clean firefox envinronment
<zyga> pitti: installing adblock (which I assume you have too) kills firefox instantly
<pitti> zyga: I do have adblock
<pitti> works like charm
<Kamion> mdz: d00m
<Kamion> mdz: but ok, thanks
<zyga> pitti: can you open your extensions menu?
<fabbione> Kamion, mdz: there is no need to merge kernel-package. the last upload was done yesterday. Way after UVF
<pitti> zyga: what shall I do in it?
<mdz> Kamion: I wouldn't want to keep all the fun for myself
<zyga> pitti: I can't open it ;)
<Kamion> fabbione: that's why I closed the bug saying "later versions fail UVF"
<zyga> pitti: if you have any idea about how I can help you, please let me know
<ogra> fabbione, the last merges i see in MOM happened on the 17th
<ogra> s/merges/merge attempts
<Amaranth> davyd: they had a release recently
<pitti> zyga: I'm currently doing 123123 test builds of thunderbird to isolate the patch which causes the crash; I'll do the same for firefox
<davyd> so did gnome-applets
<davyd> and it's still a piece of shit
<ogra> fabbione, so MOM ran after UVF
<Kamion> yes, it did, briefly
<Diziet> Mutant.  This n-m source needs (setq tab-width 5)
<Diziet> (to look right)
<fabbione> ogra: that merge specifically is from yesterday/today
<fabbione> Kamion: thanks
<Kamion> mdz: I don't see why it takes 30 seconds per component, though; if I middle-click on each component's link, that displays quite quickly
<doko> mdz, Kamion: I'd like to update the current doxygen package from CVS to the final 1.4.4 release, known fixing formatting bugs. would that be ok?
<doko> elmo: please sync python2.4 from unstable
<ogra> fabbione, just to tell you it went on ... dunno if you have other packages in the merge buglist...
<mdz> fabbione: if you don't need the new version, go ahead and close the bug
<mdz> Keybuk: please disable bug filing in MOM if you haven't already
* Kamion goes through and assigns himself as default for the installer and for stuff he maintains in Debian
<Keybuk> mdz: I did, ages ago
<fabbione> mdz: no i don't..
<fabbione> +need it
<Keybuk> when Colin said "I bet mdz has forgotten to tell you to disable mom bug filing" :)
<fabbione> YAY....
<fabbione> finally... nic-*-modules first cut down is down
<fabbione> done even
<tseng> daniels: where is my xrdb
* pitti does some merges to do sth else than mozilla for now
<pitti> Kamion: did you assign some merging bugs? or do we just pick from the unassigned list?
<Kamion> do you want some?
<Kamion> but picking from the unassigned list is fine, yes, just assign it to yourself before starting work
<pitti> sure
<pitti> well, "want" is too much, but it needs to be done, so we should share the work
<bddebian> Heh
<Burgundavia> what time is it in Aussie?
<pitti> should be around midnight
<Burgundavia> crap
<Burgundavia> ok
<seb128> pitti: what about cups/dbus to do something else than mozilla? or launchpad-integration for main? :)
<pitti> we can do both also later, right?
<fabbione> Kamion: ok.. dude.. i got to a nice point now... i manage to build all the udebs (scsi and nic) with the cleanup...
<pitti> what shall we do with a merge bug that is not of interest to us? (Debian only fixed type-handling, which we elimintated anyway)
<pitti> close the bug?
<fabbione> Kamion: and killing scsi-extra and nic-extra (for now)
<fabbione> Kamion: does that create you big problems?
<Kamion> pitti: should do the merge anyway, or sync, so that it doesn't keep cropping up
<fabbione> Kamion: and scsi-common
<pitti> Kamion: we can't sync, otherwise we'll get back type-handling
<pitti> ok, merging is easy, so I'll just do it
<Kamion> pitti: the merge should be pretty quick to do, then
<daniels> seb128: there's already a bug open about _XOPEN_SOURCE, I have a fix, but I've been too busy trying to fix libx11 and xbase-clients :P
<Kamion> fabbione: it's some work, but not disastrous
<seb128> daniels: easy fix I guess? Can you push it with one of the next upload, I've stopped to work on GNOME for the moment, I don't want to workaround all over the place for that
<fabbione> Kamion: i am checking the size of the udebs now...
<fabbione> Kamion: this is a "first cut"..
<seb128> daniels: that's https://bugs.freedesktop.org/show_bug.cgi?id=3797 upstream, but you probably know about it
<daniels> seb128: yeah, we've already fixed it indeed :P
<daniels> seb128: i'll do it tomorrow, but it involves rebuilding x11proto-core, and all the libraries that picked up dependencies on it
<daniels> seb128: -> pain
<fabbione> Kamion: size wise it adds +15/20% on nic-modules and scsi-modules
<seb128> daniels: but waiting is extra pain, now gdk.pc is b0rked
<fabbione> Kamion: that's the average.. ppc64 looks bloated but modules were completely missing from the previous udebs
<Kamion> ok
<fabbione> i don't know about amd64..
<fabbione> it's FTBFS on concordia
<fabbione> due to other problems....
<fabbione> i hope it will build...
<daniels> seb128: right.  there's a lot of X stuff affected as well, so rebuilds will take a little while.  in the meantime, just DON'T BUILD ANYTHING which uses pkg-config for X.  if you do, make very sure it doesn't contain XOPEN_CONFIG.  it's 0141 here, so I'm crashing, but I'll sort it first thing tomorrow when I get up/
<seb128> daniels: ok, thanks. There is a new GNOME upstream version next week, so if we can fix it before that would be great, or that's going to be a mess
<daniels> seb128: give me 12 hours
<seb128> sure, you have the rest of the week :)
<seb128> sleep well, you will need it :p
<daniels> seb128: (sleep, shower, breakfast, builds)
<daniels> hah
<zwnj> why there's no bash-completion in repos?
<zwnj> where can i find a deb package?
<zyga> zwnj: it's already there - this question probably belongs in #ubuntu
<Amaranth> what?
<zyga> zwnj: locate completion | less
<Amaranth> yeah, please ask again in #ubuntu
<zwnj> i used #ubuntu, but nobody answered me.
<zwnj> """dpkg -l | grep completion""" has no output
<fabbione> zwnj: it's already there.. you only need to edit your .bashrc, logout and login again
<fabbione> but the other guys are right.. this is an #ubuntu question
<zwnj> thanks, sorry for the noise
<pitti> elmo: strace sync, please
<pitti> elmo: forget that, MOM was not up to date
<highvoltage> elmo: hi elmo. JaneW said you called?
<seb128> elmo: sync from "gnome" please
* fabbione goes offline for a bit
<pitti> elmo: gnutls11 sync, please
<elmo> pitti: done
<elmo> seb128: eh?
<pitti> thanks
<seb128> elmo: meta-gnome2 sorry
<seb128> "gnome" is a binary of this one ...
<elmo> done
<seb128> thanks
<seb128> elmo: lam sync too
<Riddell> daniels: is xmkmf going reappear at some point?
<pitti> Mithrandir: here?
<elmo> seb128: done
<elmo> argh, two 'seb*' nicks
<daniels> Riddell: yes
<Riddell> daniels: groovy.  in a package called xmkmf I assume?
<daniels> yeah
<daniels> or maybe xbuildutils or something
<daniels> haven't quite decided, will ping you when I do
<Riddell> thanks
<doko> daniels: please ping me about xmkmf as well
<daniels> doko: yes, will do
<\sh> jesus what happed to firefox?
<\sh> with kde it doesn't show any fonts
<\sh> no text no menus nothing
<zyga> \sh: at least it doesn't crash for you ;)
* zyga is starting to wonder if backporting changes to high-profile stuff like firefox makes sense
<\sh> lamont: please kick netapplet again...:)
<fabbione> elmo: can we get concordia to run 2.6.10 for a few hours?
<ogra> \sh, make sure cairo is installed... might be its a missing dep and kde doesnt have it
<\sh> ogra: no complaints about the deps at all
<\sh> dist-upgraded
<elmo> fabbione: sure?
<ogra> \sh, dpkg -l |grep libcairo
<ogra> ?
<elmo> but if it dies, I won't be able to recover it till later this evening
<fabbione> elmo: 2.6.12 is segfaultorama in 64bit userland and i can't testcompile the kernel
<elmo> fabbione: how about I downgrade to 2.6.8?
<elmo> it's what I've done to the buildds already
<fabbione> elmo: that's fine for me.
<fabbione> the problem is:
<elmo> ok
<fabbione> 2.6.10 introduced a security fix that is very strict
<fabbione> the same change is in 2.6.12
<fabbione> apparently (i can't stress test) .12 doesn't freeze
<fabbione> but in the dmesg you can see the same errors
<fabbione> so it is something that needs to be addressed (i believe) in userland
<elmo> jbailey: ping?
<fabbione> like Kamion had to do with cdebootstrap or something
<fabbione> elmo: he is at OLS
<fabbione> with almost 0 network
<elmo> he's building something ..
<elmo> hum, and has been for like 2 weeks
<fabbione> it has been doing tar for a few days...
<Kamion> eh, cdebootstrap?
<Kamion> oh, you mean cdebconf
<fabbione> Kamion: i can't remember the pkg name
<elmo> jbailey  15429 98.8  0.0   1572   340 pts/6    R+   Jul12 12547:37  |                           \_ tar -xkf -
<fabbione> sorry .. that one :)
<elmo> go tar
<elmo> fabbione: it's back up with 2.6.8.1
<fabbione> elmo: thanks
<Keybuk> pitti: pmount/g-v-m is still busticated
<pitti> Keybuk: g-v-m failed to build due to X breakage, I uploaded a fix ages ago... (not sure whether that was for your bug, though)
<Keybuk> mine is that hal seems to work (cause jamesh's applet-of-love shows the icon)
<pitti> Keybuk: I'll ask lamont/infinity to try a give-back when I reach any of them
<Keybuk> but then the disk isn't actually mounted
<Keybuk> I need to manually $ pmount /dev/sda1 usbdisk
<pitti> Keybuk: g-v-m in the foreground barfs about a mount hint?
<Keybuk> dunno, not tried that
<fabbione> elmo: can we plan a time next week to dig into the kernel problem?
<fabbione> elmo: i will be available almost 24/7 next week
<Burgundavia> pitti, FF bug reports are filling the forums
<pitti> :-(
<Amaranth> and #ubuntu
<Amaranth> they're going apeshit
<Amaranth> pitti: you were backporting from 1.0.6, right?
<pitti> I took only the patches for the bugs
<pitti> and took some patches from cvs head
<Amaranth> I know but 1.0.6 was rushed out because a security fix broke API stability, at least that's what we're told.
<infinity> pitti : g-v-m is built and uploaded on all arches.
<infinity> pitti : Err, make that all but ia64.  So, all that matter. :)
<pitti> infinity: cool, thanks (I didn't expect you to be awake)
<infinity> pitti : Neither did I.
<pitti> infinity: are you sleepwalking? :-) I hope you are still conscious enough for buildd stuff :-)
<infinity> pitti : I don't suppose you care enough about gnome-vfs2 to look at why it's FTBFS?
<pitti> infinity: *sigh* I'll have a look, but not before in ~ 1 hour
* pitti blinks at seb128 
<Diziet> Blimey.  hoary's debian-installer made an dos extended partition that woody's cfdisk thinks is invalid.
<Amaranth> woody? wow man, that's old :P
<Kamion> Diziet: Wow. Could I get a partition table dump?
<Kamion> as in, dd
<Diziet> k: Sure.
<Kamion> thanks
<Amaranth> do windows machines recognize this partition?
<Diziet> k: chiark:~ijackson/junk/d/broken-table
<Diziet> am: I have no idea.  There's no 'doze on this machine.
<Diziet> Well, there might be a 'doze but I'm not booting it for fear of what it might do.
<Diziet> I ought to dd it away really.
<infinity> Kamion : Also, make up your mind.  Assign me grep, take it away again, feh.
<infinity> Kamion : ;)
<Kamion> infinity: I assigned you grep?
<Diziet> k: Can I fix it now or do you need more data ?  I'm about to blow away hoary and reinstall with breezy colony 2.
<Kamion> meh, confused
<seb128> pitti: what?
<seb128> oh
<pitti> seb128: <infinity> pitti : I don't suppose you care enough about gnome-vfs2 to look at why it's FTBFS?
<seb128> gnome-vfs2
<infinity> Kamion : You assigned me the grep merge, then assigned it to yourself about 30 seconds later. :)
<ogra> Diziet, good luck ...
<pitti> seb128: I can take a look at it, nevermind; just kidding :-)
<infinity> seb128 : Actually, any number of a few dozen things with gnome in the title, want them all?... I shoved them all back when xbase-clients was unbroken.
<pitti> seb128: it's just another lousy gtk bug anyway
<seb128> pitti: don't touch my GNOME :p
<Diziet> k: If you want more info I can wait.
<pitti> seb128: well, it built on ia64 at least
<Diziet> Actually, it might be the primary partition that they disagree about and it might be the weirdshit IBM recovery area they disagree about.
<Diziet> Well, I didn't care about that anyway :-).
<pitti> infinity: http://hwdb.ubuntu.com/buildlogs/?show=http://people.ubuntu.com/~lamont/buildLogs/g/gnome-vfs/1.0.5-5.2/gnome-vfs_1.0.5-5.2_20050721-1713-ia64-failed.gz - WHOA!
<pitti> erm, seb128^ 
<seb128> infinity, pitti: this one is "upstream has rolled a tarball with ORBit2 CVS installed, and an autogenerated .h got some stuff not defined with the current version", I'll fix it
<pitti> seb128: does that mean libgnome-dev is uninstallable?
<Kamion> Diziet: I can't remember right now if just the first 512 bytes will be enough to investigate breakage in an extended partition
<Kamion> it's been a while since I took one of these apart :)
<pitti> seb128: look at above URL, it rather seems to be a buildd fault
<seb128> pitti: that's GNOME1
<pitti> infinity: W: Couldn't stat source package list http://jackass.ubuntu.com breezy/main Packages (/srv/hooker.ubuntu.com/home/buildd/build-breezy/chroot-breezy/var/lib/apt/lists/jackass.ubuntu.com_dists_breezy_main_binary-ia64_Packages) - stat (2 No such file or directory)
<seb128> pitti: gnome-vfs != gnome-vfs2
<pitti> ^ from gnome-vfs2 build log - WTH?
<pitti> seb128: ah, sorry, but still...
<infinity> pitti : Those get given back.  Ignore them.
<pitti> ok, thanks
<seb128> pitti: I'll have a look after dinner, dinner time now
<pitti> for me, too :-) enjoy
<infinity> pitti : Well, not technically given back, but they tend to get completely bogus dep-wait on stuff like "debhelper" which get autocleared.  I was going to look at that bug later...
<seb128> thanks, you too :)
<Diziet> k: No, if the bug is in some of the things _inside_ the extended partition then it won't.
<Diziet> But cfdisk is complaining about `primary partition 3'.
<Kamion> Does hoary's cfdisk complain? (For comparison.)
<\sh> Kamion: can u have a look what's up with kover? no mail, nothing..and I'm sure, debian/control is right ;)
<Diziet> Just a mo, I'll reboot and find out.  (It seems my main kernel has no ext3 support ...)
<\sh> argl...forget it
<\sh> i need new glasses and a new mouse
<Kamion> infinity: oh, oops
* Kamion digs through the code in woody's cfdisk
<Kamion> Diziet: what exactly is the message it prints?
<Diziet> k: hoary's is fine.
<mdz> Diziet: what's the word on network-manager?
<Diziet> Um, woody's cfdisk works when run from the chroot with hoary booted.
<Diziet> mdz: I'm looking at the code as well as the other two sortings out.
<Diziet> We're going to make it use dnsmasq, 'cos that's sensible.
<Diziet> In fact, I think I've read the code enough now to know where to hack it.
<Diziet> It's pretty strange inside.
<mdz> dnsmasq is sensible?  I've never used it myself
<Diziet> But I want to install dnsmasq on a test box first and my test boxes are all strange or broken atm.
<Diziet> Well, I don't know if it's actually any good.  But it's the right kind of thing and we can probably fix the bugs well enough.
<Diziet> Failing that we can replace it with some trivial thing hacked up in an hour or two.
<Diziet> k: FATAL ERROR: Bad primary partition 3: Partition ends after end-of-disk  //  Press any key to exit cfdisk
<Diziet> fdisk doesn't seem to mind but it does seem to know hda4 being too big.
<Kamion> Oh God, this is some horrific CHS calculation thing.
<Kamion> the kernel certainly plays a part
<Kamion> (specifically whatever ioctl(HDIO_GETGEO) returns)
<Diziet> Yers, I suspected something like that.
<Diziet> hda: 110194034 sectors (56419 MB) w/7877KiB Cache, CHS=65535/16/63, UDMA(100)
<Diziet> hda: Host Protected Area detected.
<Kamion> both hda3 and hda4 on your partition table have head 0xef, sector 0xff, cylinder 0xff
<Diziet> sfdisk (woody) says Warning: The partition table looks like it was made for C/H/S=*/240/63 (instead of 109319/16/63).
<Diziet> (woody with my stock 2.6.9 that is)
<Kamion> Right, 2.6 is returning geometry information that woody's tools can't cope with, I think.
<Diziet> Lovely.
<zyga> pitti: can I help you in any way in ff nightmare?
<Diziet> I'll make the partitions with woody under 2.6 I think then.
<Diziet> I mean, for my reinstall.
<doko> elmo: please sync isdnutils from unstable, approved by Kamion yesterday (IIRC)
<elmo> uh
<elmo> pls verify the IIRC? :p
<Kamion> 19:02 < Kamion> doko: isdnutils looks fine, provided that you/somebody goes over everything that cares about the libcapi soname change
* Kamion debates with himself whether to ask for a UVF exception for parted
<Kamion> pro: Mac RAID and LVM support, HFS/HFS+ shrinking
<Kamion> con: well, it's a new parted upstream ...
<fabbione> Kamion: go for it
<fabbione> i will help you testing on i386
<Kamion> Partition table bugs are all awful. We should go back to decks of punched cards
<ogra> Kamion, dont be to nostalgic here
<ogra> Kamion, punched tape will do...
<fabbione> elmo: morgue is still stalled at 2005-03-29....
<ogra> oh, the german parliament was just dissolved....
<zyga> ogra: why?
<ogra> they want new elections...
* zyga thought only polish politics suxx
<ogra> we have a 50/50 situation here, so the government cant move at all...
<zyga> we have 20/20/20/20/20 situation here and people can't decide
<ogra> but if two of the 20/20/20/20/20 work together, they can move .... our 50/50 wont be able to work together, they have poven it the last years...
<zyga> the problem is that no-one likes to work with anyone else and that everyone has already been in all other groups
<zyga> it's a sick situation that only new generations can heal
<ogra> yes, but since the last municipal elections here in germany all government decisions get negated by the municipality council... so the government is hepless...
<ogra> s/council/councils
<highvoltage> that's very interesting.
<Amaranth> ogra: err, does dissolved not mean what i'm thinking or is this really bad?
<ogra> since our governmnt is the left party and the municiaplitys are the right party
* zyga wishes that craziest mindless people don't get elected here in poland
<Amaranth> ogra: does it just mean he fired them all and new ones will get elected or he fired them all and the lower parliament is gone?
<ogra> Amaranth, its actually good in one view, since we get new elections... otoh we'll probably get a german maggie thatcher this woman is totally crazy and has no clue, that scares me
<highvoltage> frau maggie.. hehe
<ogra> Amaranth, it means we'll have new elections soon... until then the old government stays in place
<mantass> ogra: isn't she better than schoder?
<ogra> mantass, not at all
<infinity> I don't recall anyone ever claiming Maggie "had no clue"... Just that half the world hated her point(s) of view.
<Amaranth> Schroeder forced this?
<infinity> Also, this is all wildly off-topic here.
<Amaranth> hehe, sorry
<ogra> infinity, yes, but our angie *additionally* has no clue 
<ogra> infinity, and youre right... OT
<ogra> sorry for the noise
<Amaranth> ogra: angie == Angela Merkel?
<ogra> yep
<Amaranth> ok, i'm done then
<mantass> ogra: do you like putin's and schroder's big friendship? 
<Amaranth> just trying to figure out wtf this news story is talking about
<ogra> mantass, its historical based politics ...
<Amaranth> pitti: It's sounding more and more like the problems people are having are the same problems people had with 1.0.5
<Amaranth> pitti: err, problems with firefox
<pitti> Amaranth: I did try 1.0.5, and that one doesn't crash with e. g. the HTML validator extension
<Amaranth> ok, so it's worse than 1.0.5
<Amaranth> yay!
<Amaranth> :)
<pitti> EWRONGSMILEY
* infinity grumbles about file overlaps.
<Amaranth> pitti: ubernostrum in #ubuntu claims he can reproduce some segfaults that happen without any extensions installed
<zyga> pitti: can I help you anyway?
<pitti> zyga: yes, fix firefox, kthxbye
<pitti> :-)
<pitti> infinity: given that mess, we should just demote firefox and promote lynx
<zyga> pitti: yeah, sure - wait 10 months till I know the code like my onwn and it's done
<zyga> pitti: I mean *now* can I help you anyway?
<pitti> zyga: well, it is necessary to isolate the patch that causes the crash
<pitti> unfortunately firefox has a really crappy build system without proper patches
<pitti> but first I need a recipe how to get the crash
<infinity> pitti : Why do we not staple a patch system on the side, just for us?
<zyga> pitti: I hope that apt-get source gives correct version
<zyga> pitti: did you try to debug the problem as any normal problem?
<zyga> pitti: like checking why it breaks in that JS_xxx function?
<doko> mdz: do you know how compatible rrdtool 1.2 is (compared to 1.0)?
<pitti> zyga: I compiled a debugging version of thunderbird and got a nice stack trace, but still it is rather useless without proper code knowledge
* Diziet is victorious.  The computers have been defeated!  Now I have a breezy install on liberator and a working desktop testbed too.  Just a shame it took most of the day.
<pitti> infinity: we should do this in breezy at least
<Amaranth> Good thing a major goal of gecko 1.9 is to make the whole thing a lot simpler
<ogra> doko, any opinion on #11761 ? how did this lib get into the Cxx list ?
<infinity> pitti : File a bug and assign it to me.
<infinity> pitti : Pretty please.
<zyga> pitti: do you have the trace anywhere around?
<pitti> infinity: will do :-)
<Amaranth> pitti: ubernostrum is the one that can crash without extensions. :)
<highvoltage> hmmm.. they're talking about the german politics on bbc-world now. germany has strange politics.
<zyga> pitti: it crashes on JS_GetClass here
<zyga> in libmozjs
<pitti> zyga: http://people.ubuntu.com/~pitti/shots/tbirdcrash.txt
<zyga> checking
<zyga> ...
<zyga> okay
* zyga *really* needs to set default browser to something other than *ff* now
<doko> ogra: false positive
<pitti> unfortunately I didn't get debug symbols from the library
<ogra> doko, yes :( 
<ubernostrum> pitti: as Amaranth said, I got crashes on theme and extension installs w/no extensions installed. What info do you need from me?
<ogra> doko, but now we need o transition it back i guess ....
<doko> resync it back from debian, and add provides
<Amaranth> ubernostrum: Oh, it was on theme/extension installs?
<pitti> ubernostrum: I was able to get a crash when installing the HTML validator extension, but that's it; it even works after restarting; same for you?
<ubernostrum> Amaranth: yeah. Crashes on install with the same errors people are getting from plugin tab stuff.
<Amaranth> ubernostrum: bleh, i thought you had something different :P
<ubernostrum> pitti: yeah. It crashes on install, then when restarted it works. Unless it's one of the extensions that causes other crashes.
<ubernostrum> Amaranth: sorry :(
<zyga> pitti: I'll build ff with debug in a moment
<Amaranth> ubernostrum: It's ok.
<ubernostrum> Amaranth: if there's anything I can do to help, though, let me know.
<pitti> infinity: bug filed
<infinity> pitti : Danke.
<zyga> pitti: how the hell do you build this stuff with debug?
<pitti> zyga: that's pretty complicated, right. Lemme dig it up
<zyga> pitti: I've found this
<zyga> http://www.mozilla.org/build/configure-build.html
<zyga> pitti: it tells how to enable debug amongst other things 
<desrt> who is the ubuntu bugmaster?
<pitti> zyga: oh, for firefox it is already done
<pitti> zyga: DEB_BUILD_OPTIONS=nostrip,noopt debuild should work
<pitti> zyga: it requires debian/rules hacking in tbird
<ogra> desrt, take me as a interim... we currently have none... 
<highvoltage> is it safe to upgrade to breezy at this stage?
<desrt> ogra; can you increase my bugzilla capabilities?
<OddAbe19> no
<mdke> highvoltage, you can hack around any problems, but if you want a clean upgrade, wait a bit more
<ogra> desrt, yes, as the topic here says ;)
<highvoltage> mdke: that's the kind of answer i was looking for, thanks.
<mdke> ogra can do anything
<desrt> ah.  awesome :)
<mdke> highvoltage, np
<desrt> email is desrt@desrt.ca, if you please :)
<ogra> desrt, you will handle the power carefulla and know when to assign bugs and when not ? 
<desrt> ogra; i don't usually assign bugs unless i'm doing it to myself :)
<mdke> desrt, there is a nice page on the wiki HelpingWithBugs
<pitti> zyga: hm, that builds without -g
<ogra> (and dont raise/lower severity randomly) ;)
<zyga> pitti: check .mozconfig
<zyga> pitti: --enable-debug in particular
<desrt> ogra; k.  i promise i'll only raise/lower the priority for good reasons... like if it's a rainy day
<pitti> zyga: above DEB_BUILD_OPTIONS is the way Debian Policy mandates for building a debugging version; unfortunately many packages break that
<ogra> desrt, ha ha :)
<zyga> pitti: well standards are great, so many to choose from
<pitti> zyga: adapt OPTFLAGS in debian/rules (where it says -O0)
<ogra> desrt, editbugs enabled... have fun
<desrt> thx.
<zyga> pitti: thnx
<pitti> testing new X, brb (hopefully :-/ )
<ogra> highvoltage, but we're near ;) 
<mdke> hey ogra, that evolution notify package on your website, is that still the best way to get a notify icon or are there "official" ways yet?
<ogra> mdke, there is an applet, but it doesnt compile with the current dbus version
<ogra> mdke, i already tried to build it...
<mdke> ogra, k, your package then?
<mdke> (i haven't tried it yet)
<ogra> mdke, this has issues since its built for gnome 2.8 ....
<mdke> gah
<ogra> i can send youa patched binary once you have it installed... currently i'm missing the time to care for it
<ogra> i.e. to build a new tarball
<mdke> ogra, dude don't take up valuable time over it :D
<mdke> i can check my email normally
<mdke> i don't get that much anyhow >_<
<ogra> mdke, its a 2 line patch... i just always forget about it or remember it if I'm busy :)
<mdke> ogra, maybe post the patch on your site, would be quicker than rebuilding package
<ogra> mdke, install from the tarball and i'll send you the binary with instructions
<mdke> ogra, ok that's very nice of you, thanks
<pitti> dudes, I thought X keyboard would work now?
<mdke> ogra, installed, it also has a nice setup program :)
<ogra> yep, that was my pre ubuntu time.. there i had to care for such stuff :)
<Amaranth> pitti: ha
<Amaranth> pitti: sudo ln -s /etc/X11/xkb/xkbcomp && sudo apt-get install --reinstall xkeyboard-config
<Amaranth> err
<seb128> grumpf
<Amaranth> pitti: sudo ln -s /etc/X11/xkb/xkbcomp /usr/bin/xkbcomp && sudo apt-get install --reinstall xkeyboard-config
<seb128> anybody knowns a nice text mode software to get the download rate of an interface ?
<tseng> seb128: like ntop?
<ogra> seb128, did you come round to ask the mediawiki guy ?
<highvoltage> seb128: ethstatus
<seb128> tseng, highvoltage: thanks
<seb128> brb
<zyga> pitti: there's --disable-debug somewhere in default settings, add ac_add_options --enable-debug
<zyga> pitti: there's --disable-debug somewhere in default settings, add ac_add_options --enable-debug to your ~/.mozconfig
<pitti> Amaranth: /etc/X11/xkb/xkbcomp doen't exist
<Amaranth> pitti: i know, you need to create it
<Amaranth> did i put those arguments backwards?
<zyga> pitti: it still adds -DNDEBUG thoigh
<mdke> ogra, cheers dude
<ogra> heh, people complain on ubuntu-users they cant file firefox bugs without a browser
<zyga> maybe you could roll those changes back
<zyga> untill ff works fine
<pitti> Amaranth: yes, and I overwrote the one in /usr/bin
<Amaranth> err
<infinity> Is anyone taking care of the aalib/slang/libsdl mess?
<Amaranth> ln tells you the file exists
<Amaranth> at least it does here
<pitti> Amaranth: dpkg -S /usr/bin/xkbcomp ?
<Amaranth> pitti: I guess. :)
<Amaranth> pitti: Although I have a feeling it's xbase-clients
* Amaranth isn't on Ubuntu right now, if you wanted me to do that
<m0rphx> it is in xbase-clients
<Amaranth> Firefox won't get fixed because I broke pitti's X. ;)
* Amaranth hides from users
<Treenaks> Amaranth: YOU broke it?!
<ogra> infinity, was there a final decision by Kamion/mdz ?
<pitti> guys, what is "dpkg -S /usr/bin/xkbcomp" for you?
<pitti> it is NOT xbase-client
<tseng> pitti: all the xbase-clients stuff seems to have gone poof
<infinity> ogra : No idea, I just know a mess of stuff is in a wonderful limbo of FTBFS while we're sort of half-transitioned.
<tseng> pitti: i miss xrdb
<pitti> I need xkbcomp back...
<infinity> mdz, Kamion : Is there some sort of technical decision being made in regards to the situation with aalib/slang/libsdl?  A large chunk of main (and a much larger chunk of universe, I'd suspect) is currently FTBFS while we're in a half-broken transition state.
<ogra> infinity, this morning it seemed not decided... but i didnt follow further
<Amaranth> Can someone run dpkg -S /usr/bin/xkbcomp? Please?
<Amaranth> Firefox can't get fixed until someone does this. :)
<ogra> would be pretty useless, my X install is 3 weeks old here
<tseng> ogra: anyone up to date doesnt have it
<ogra> tseng, thats why my main machine isnt up to date :)
<pitti> ogra: better leave it like that - daniel said to me that it was fixed now, so I upgraded
<tseng> ogra: my desktop doesnt have breezy :)
<pitti> but xbase-clients is EMPTY
<Amaranth> -42 is, yeah
<Amaranth> you need 036
<tseng> it has docs :)
<ogra> pitti, older version ?
<Amaranth> err, -36
<Amaranth> if morgue worked i'd point you there, as is i dunno
<pitti> I can't even type a pipe
<Amaranth> you can from a console...
<aigarius> what is the "events/0" process (pid=3)? why does it eat my CPU? any ideas?
<Lathiat> be nice if xkb started workign again
<Amaranth> aigarius: IRQ handler?
* Amaranth has no idea
<tseng> Lathiat: ive been through so many hacks to make things work, i feel like doing a clean install when X stops being broken
<pitti> $ sudo dpkg -i --force-conflicts --force-overwrite /var/cache/apt/archives/xbase-clients_6.8.2-32_i386.deb
<pitti> *grumpf*
<Amaranth> fun
<Amaranth> you'll probably have to ram xkeyboard-config back through too
<Lathiat> so what is xbase-clients supposed to have in it
<Lathiat> ah, thaose
<Amaranth> Lathiat: eventually it's just going to be a dummy package that depends on other modules
<Lathiat> oh well, i dont seem to need them
<Lathiat> everythings working as of now :)
<TerminX> wait, X isn't broken anymore?
<Lathiat> depends on your value of broken
<Lathiat> i think if you dont want xkb stuff
<Lathiat> and your keyboard is us english
<Lathiat> and you dont want various xbase-clients programs
<Lathiat> your ok? :)
<TerminX> well, xkb works in -36
<TerminX> is it broken in -43?
<pitti> doesn't work
<pitti> bah, I'm going to sleep now
<pitti> keyboard is f**ed, both with xbase-clients 32 and 42
<pitti> night, dudes
<doko> devmapper ist not in the archive anymore?
<doko> crap, should stop working
<rubenv> is it a known fact that firefox segfaults?
<rubenv> after the security upgrade
<spacey> rubenv, i got problems with adding a bookmark
<spacey> atm
<spacey> probably since security update
<rubenv> it completely doesn't start here
<spacey> bug which occurred before
<spacey> oh t works now
<spacey> so i have to take that back
<spacey> i still works
<spacey> but i'm at amd64
<rtcm> rubenv: yes it seems like it is a known issue, better to ask on #ubuntu-users
<zyga> rubenv: it's broken
<zyga> rubenv: wait till it's fixed or use other package
<rubenv> ok, just wanted to be sure it's known broken
<doko> elmo: please sync libgdchart-gd1 from incoming (unstable tomorrow)
<lifeless> Keybuk: what should I call that option - or just make it an automatic optimisation ?
<ogra> lifeless, you scared him :)
<zyga> darn firefox builds looooong
<TerminX> zyga: 20-40 minutes isn't it?
<zyga> TerminX: well it's more like an hour 
<TerminX> what hardware?
<zyga> athlon mobile, 2000 (1.6GHz) 512 megs
<TerminX> mobile in a laptop or mobile in a desktop board?
<zyga> laptop
<TerminX> ah
<TerminX> I was going to say.. ramp up the clock speed ;)
<zyga> actually a hot piece of plastic now ;] 
<TerminX> they were quite good overclockers when it came to Athlon XPs
<TerminX> a $100 Athlon XP that hits 2.5 GHz on air cooling isn't too shabby IMO
<zyga> TerminX: any decent 1GHz box that is fanless is better IMHO
<zyga> ;)
<zyga> fanless - mind the noise
<TerminX> it's not bad as long as you aren't using tiny little whiny fans
<TerminX> heh
<zyga> (or a cluster of noisy monsters two buildings away)
<TerminX> the A/C drowns out any and all sound from the fans in here anyway
<TerminX> and the stereo drowns out the A/C (and the little brats running around outside)
<zyga> TerminX: ac on laptop... not there ;] 
<TerminX> heh
<TerminX> A/C in room :p
* zyga wants popular arm based boxes :/
<jp> wtf :( http://restrex.host.sk/demos/evolution/
<TerminX> so that's what evolution is like, huh?  (never used it personally, been using Thunderbird for a long, long time)
<TerminX> that vnc2swf thing is pretty sweet though
<zyga> fresh ff build
<zyga> s/d/t/
<mdke> jp, post that to a bug report, that is some conscienscious bug filing
<mdke> obligatory swf demo with every bug!
<jp> ok mdke  thanks :)
<jp> !
<jp> yeah! that would rock jeje
<jp> I'll bug it, thanks.
<mpt> The LaunchpadIntegration client should have a checkbox for taking a screenshot of the bug
<mpt> (idea shamelessly copied from Safari)
<mdke> mpt, demos too
<mpt> "demos"?
<ogra> mdke, istanbul ;)
<mdke> is that packaged for breezy?
<ogra> its in the queue
<mdke> awesome
<ogra> for universe
<mdke> what is the probability of it being ready?
<ogra> i'd love it for edubuntu.... and a patch to kino for ogg... then you could directly edit the movies
<seb128> it should have been uploaded for 1 month imho
<seb128> but this rules of 3 reviews block it
<ogra> seb128, dholbachs package had issues...
<ogra> seb128, he did include a wrong copyright ...
<seb128> easy to fix
<ogra> yep
<ogra> but he didnt yet
<seb128> yeah, he's waiting for reviews
<ogra> seb128, why should i review something that has bugs... ? he should upload an update
<seb128> you want to keep packages out of the distro, fine
<ogra> seb128, i will get it in universe...
<seb128> it should be here for 2 months
<ogra> seb128, nope, but we want a minimal quality assurance
<ogra> seb128, btw, any news about mediawiki ?
<seb128> it take 10 min to fix and upload
<seb128> I've already said that to daniel, but he wants his 3 reviews anyway
<seb128> nop
<ogra> seb128, i know... he could easily overrule it
<seb128> they made an alioth project this week
<seb128> he doesn't want
<ogra> i know
<ogra> i do this too
<seb128> and nobody review packages
<seb128> that doesn't work
<ogra> for stuff thats for my breezy goals i have to
<zyga> who has experience with building firefox around here?
<ogra> yes, we have notenough MOTUs yet
* seb128 hides
<ogra> heh
<mdke> hehe
* mdke points
<infinity> zyga : What problems are you having?
<zyga> I'm trying to get debug working but debuild always makes some magic that I don't understand (that effectively makes debug go away)
<zyga> I'm doing a ./configure based build but that won't include building pretty .debs and all
<ogra> zyga, is it a config option ?
<seb128> DEB_BUILD_OPTIONS="debug" 
<zyga> ogra: I tried that
<ogra> yeah
<seb128> so, what's the issue?
<zyga> it doesn't work 
<seb128> DEB_BUILD_OPTIONS="debug noopt nostrip" 
<ogra> zyga, edit the rules file 
<seb128> NO
<seb128> don't edit the rules file
<ogra> seb128, ?
<seb128> that's not needed
<seb128> I've already built debug firefox
<ogra> oh, a global var then :)
<zyga> I did edit the rules file to add -ggdb3 
<seb128> build with DEB_BUILD_OPTIONS="debug noopt nostrip"
<zyga> I'll try
<ogra> zyga, the hoary version with pittis patches ?
<zyga> ogra: yeap
<ogra> great :)
<zyga> btw: I can give you polish .desktop translations 
<zyga> it's a real shame they're not there
<seb128> give them to rosetta 
<ogra> zyga, rosetta ?
<zyga> rosetta will include them in 100 years ;]  but okay
<zyga> btw how does that work, debulid ... it seems to extract everything all over again, right?
<zyga> (if I want to patch something I need to make a patch against something and add it to ./debian/ubuntu-patches?
<infinity> zyga : ubuntu-patches is just there for reference, you have to apply them yourself (the rules file doesn't do any patching)
<ogra> zyga, http://tseng.ath.cx/log/?p=7 ;)
<infinity> zyga : Anything shipped in ubuntu-patches is already applied to the source tree.  If it's not, pitti messed up. :)
<ogra> and add a build dep on dpatch ... (its missin in this howto
<ogra> )
<infinity> ogra : ?
<infinity> ogra : firefox doesn't use dpatch.
<ogra> infinity, oh
<infinity> Or anything even remotely resembling it.
<infinity> It doesn't use a patch system at all.
<ogra> how odd
<zyga> ok I'll keep trying
<infinity> The Debian maintainer is a bit strange, yes.  We've suggested a patch system, he "doesn't see the point".
<zyga> hmm pretty site :)
<zyga> style wise :>
<infinity> pitti's just recently filed a bug and assigned it to me to add a patch system to firefox in Ubuntu.
<zyga> really clean and everything ;] 
<ogra> infinity, pfft... do we really care if its such a important piece we have to touch anyway ?
<ogra> not usiong a patchsystem for such a big piece of SW is silly
<infinity> Agreed.  Hence why we'll add our own before breezy releases.
<ogra> yay
* ogra would love to see that for xscreensaver too
<ogra> but that will require some discussions with the DD i havent started yet
<doko> daniels: imake automatically adds support for selinux. is there a way to avoid that?
<mdke> argh! the trash applet is single click to open the trash
* mdke goes to gnome bugzilla
<seb128> as every launcher
<seb128> don't put that as a bug
<mdke> seb128, is it a launcher? it doesn't have the launcher behaviour when clicked on
<seb128> trash "applet"
<schweeb> anything on a toolbar except for in the system tray is single click afaik, mdke
<seb128> that's a panel element
<seb128> what on your panel require a double click?
* mdke nods
<mdke> even so, i like the way the launchers tell you they are opening something when you click on them
<seb128> that's not true
<seb128> systray are single click too
<seb128> ie: gaim
<schweeb> hrm
<seb128> gossip
<seb128> rhythmbox
<schweeb> you're right
<mdz> infinity: how much time/work would it be to carry out the transition?
<schweeb> goddammit
<schweeb> err wrong window
<infinity> mdz : TBH, I haven't looked deeply into it, I just know that at least one or two packages have been merged in already, causing everything else in the dependency chain to FTBFS.  So we have to hunt down the broken ones and revert them, or fix the rest.
<mdz> infinity: given roughly equal effort, I'd prefer to go forward than to go back
<infinity> mdz : Is that equal effort for main, or for main+universe?
<mdz> infinity: for main, universe can lag behind if necessary
<infinity> mdz : If the former, I'm sure it's about there.  If the latter, I'd have to see how much stuff in universe is currently broken.
<mdz> infinity: notify MOTU of what needs to be done for universe
<ajmitch> if it's just fixing build-depends, then it shouldn't take too long
<infinity> ajmitch : Should be.  If anything really is severely broken, there should be pretty easily-extractable changesets/patches from Debian already.
<ogra> ajmitch, we still have nearly 200 merge bugs open and about 500 packages that need a rebuild for the Cxx stuff...
<ogra> ajmitch, in MOTU land
<\sh> we need a wonder
<infinity> mdz : Will do.
<ajmitch> ogra: ok, that is still a few
<ogra> \sh, (miracle) ;)
<infinity> ogra, \sh : You guys need to recruit some DDs with too much spare time.
<ogra> infinity, haha
<\sh> infinity: lol
<\sh> easier is it, to go to the netherlands and get a clone of ogra and me 
<ogra> infinity, i'm trying to apply to utnubu, lets see if they let me in as non DD
<azeem> ogra: cool
<ogra> :)
<ajmitch> ogra: I'll try & set aside some time after my work deadline next week :)
<ajmitch> there's a spare DD, come & join us azeem :)
<ogra> hehe
<ajmitch> he spends far too much time on the hurd anyway
<azeem> ajmitch: fix gcc for me and I might consider it
<infinity> azeem : Fix gcc for me and I'll fix gcc for you, and you can go work for MOTU.  Deal?
<ajmitch> still FTFBS there?
<seb128> infinity: don't bother if half of GNOME FTBFS for the moment
<azeem> infinity: and you work on my Ph.D.? ;)
<seb128> infinity: daniels is going to fix xorg issues, then I'll fix the GNOME FTBFSes
<infinity> seb128 : Way ahead of you.  You should be able to build against Xorg again (and, in fact, many packages have, while many others are still failing for their own special reasons)
<seb128> infinity: nop, https://bugs.freedesktop.org/show_bug.cgi?id=3797
<seb128> infinity: xorg .pc files mention -DXOPEN_SOURCE which has screwed gtk on the way
<seb128> which breaks every GNOME package using libegg, which is a pile of packages
<seb128> infinity: xorg need to be fixed, then I can rebuild GTK, then GNOME
<infinity> seb128 : Ahh, yes.  I recall you talking about that bug earlier today.
<seb128> infinity: daniels said he'll fix his part when he wakes up
<infinity> seb128 : I'll pester daniels about it when he wakes up. :)
<seb128> he said he'll fix it, so should be fine ... but yeah, if he's lazy kick him :p
<infinity> Lazy's not the word I'd use.  But his focus isn't always on being my bug-hunting slave, unless I bribe him with copious amounts of alcohol.
<infinity> (Without the alcohol, he may *gasp* do other parts of his job... Jerk)
<ogra> infinity, you should have a high prio to fix gtk since its a build-dep of gcc ;)
<infinity> ogra : That's another bug altogether, and I need to figure out how to bribe doko to fix it.
<ogra> hehe
<ogra> infinity, sigle malt helps a lot there ;)
<infinity> (The "extra compilers" and "system compilers" should be in at least 2 source packages, ideally many, many more, so we can do rapid rebuilds of gcc/g++, without worrying about the rest...)
<ogra> 30years+
<azeem> infinity: word
<doko> infinity: what bug?
<doko> the gcc split won't be there for 5.10
<ogra> infinity, you see, mentioning 30year+ single malt works ;)
<infinity> doko : A wishlist bug that I don't think needs to be filed as you're well aware of it (the split)
<mdz> is anyone else's workrave applet busted?  mine just displays a sheep all the time
<doko> ogra: you still owe me a bottle, dude!
<infinity> doko : And yes, I know it won't make it for 5.10, but it might be nice to work on it in Etch and see it in 6.04
<ogra> doko, if we meet next time, promised :)
<doko> infinity: lamont already filed one
<infinity> doko : If I have to courrier you a few single malts, let me know. :)
<mdz> odd, removing and re-adding fixed it
<ogra> gtk bug ...
#ubuntu-devel 2005-07-27
* infinity wonders how Apple can claim the PowerPCs aren't scaling fast enough when our ppc buildds just blew through a 600 package backlog faster than amd64 and i386...
<robertj> infinity: since when has actual performance mattered one lick to Apple?
<robertj> My Dual  2.5 G5 and 1.4 ghz Celeron feel about the same unless I'm doing 3d stuff
<robertj> which err, I'm not (although I would if the laptop had decent on-board video)
<mpt> Most people using OS X probably aren't spending most of their time compiling stuff
<mpt> AndyFitz!
<mdz> daniels: is xauth coming soon?
<infinity> doko : Does zlib still need that (temporary) build-dep on lib32gcc1?
<infinity> doko : If not, we can sync back up with Debian and stop forking zlib (yay)
<AndyFitz> 20 points to who ever is responsible for nvidia-glx finally working
<AndyFitz> booyah
<AndyFitz> mpt!
<doko> infinity: it installs in /emul/ia32-linux/usr/lib/ so, you have to nag the maintainer to make the installation direcory unconditionally
<AndyFitz> mate,  I've got to go.    doing an typeface.. and then headed to http://www.splendourinthegrass.com/lineup/
<seth_k> AndyFitz, but we have no l-r-m, so does nvidia-glx actually provide 3d?
<AndyFitz> seth_ok  I havent restarted X.      ah well my hopes arent up
<AndyFitz> restarting x ciao
<infinity> doko : Erm, come again?.. It looks like it installs to /usr/lib32 to me...
<Nafallo> hmm, what shall I do to X -43 to get my xkb back? :-)
<\sh> mc -> xbase-clients -> and move xmodmap to /usr/bin
<\sh> install xkeycaps
<\sh> create a xmodmap file...trick a bit
<\sh> you'll be fine ,-)
<\sh> and forget all about altgr and stuff like this...
<\sh> use only shift mappings
<Nafallo> hehe
<\sh> that reminds me to buy a plain american keyboard the next time
<Nafallo> \sh: /usr/X11R6/bin/xkbconf is a symlink to itself. where should that point to? :-)
<\sh> Nafallo: ask daniels pls :)
<\sh> I'm lost with X right now ;)
<Nafallo> daniels: ping :-)
<doko> infinity: debian/rules:119: install -m 644 $(BUILD_TREE)/libz.a debian/nopic-tmp/emul/ia32-linux/usr/lib/libz.a
<doko> zlib (1:1.2.3-1) unstable; urgency=high
<infinity> doko : Ahh, wasn't looking at the nopic target.
<\sh> Nafallo: actually: i have xkbcomp in /usr/bin
<\sh> but no link in /usr/X11R6/bin or /etc/X11/xkb
<Nafallo> \sh: I don't. I don't have that one at all ;-)
<\sh> Nafallo: as I said I had some manual adjustments with mc and xbase-clients ,-)
<Nafallo> \sh: I also have /etc/X11/X pointing to /usr/bin/X11/Xorg, which point to /usr/X11R6/bin/Xorg ;-)
<\sh> yay
<Nafallo> and /usr/bin/X11 points to .. btw :-)
<Nafallo> \sh: do you have mkfontscale somewhere? :-)
<Nafallo> I have a broken link from /usr/X11R6/bin/mkfontscale to /usr/bin/mkfontscale
<infinity> Is it sane and/or reasonable for thunderbird to be taking 3 gigs of memory?
<bob2> haha
<infinity> 11955 adconrad  16   0 3035m 1.7g  14m S  2.0 84.1  76:39.53 mozilla-thunder
<infinity> Frightening.
<\sh> infinity:
<mrd`> Why does 'dpkg -L xkeyboard-config' list /etc/X11/xkb/geometry/microsoft (for example), but the file doesn't actually exist?  I've reinstalled it and even forcefully removed and then installed it again, but only the directory structure gets recreated---none of the files do.
<\sh> it would swap here like hell
<infinity> \sh : I noticed it when it started hitting swap (I only have 2 gigs of RAM)
<\sh> infinity: do u have actually some text to read in firefox? ,-)
<thom> infinity: there's a reason it's called chunderbird
<mdz> mrd`: they're conffiles
<mrd`> mdz: How do I get them back?  (Do I even need to?)
* xhaker is away (Away, bnc logging)
<mdz> mrd`: happy to talk you through it on #ubuntu
<mrd`> Why aren't the binary packages from the xorg source package transitioning into Breezy simultaneously?  e.g. there's xbase-clients from -42 and xserver-xorg from -43.  (Or is this another question for #ubuntu instead of here?)
<tseng> mrd`: that one is pretty complicated.
<tseng> part of it was that the amd64 builders have been down recently
<tseng> but also some weird corner cases in the build/mirror scripts
<tseng> that i dont really care to understand :)
* infinity hasn't noticed any of xorg being out of sync...
<mrd`> tseng: But when a source package is done compiling, doesn't it upload either all or none of the binaries from it?
<tseng> no
<tseng> if its a new binary name, it goes in a queue
<mrd`> infinity: http://packages.ubuntu.com/xbase-clients and http://packages.ubuntu.com/xserver-xorg
<infinity> tseng : Erm, the whole upload goes to queue/NEW, not just the one binary.
<Nafallo> infinity: xbase-client=6.8.2-42 on amd64
<mrd`> xbase-clients is -42 on i386 too.
<daniels> right.  it won't get newer in a hurry.
<tseng> infinity: its best to leave these things to you :)
<Nafallo> daniels: there you are. I'm missing binaries ;-)
* daniels notes that xorg was meant to stop building xbase-clients around -32 or so, but actually did it at -42.
<Nafallo> daniels: mkfontdir, mkfontscale, xkbcomp is gone.
<daniels> Nafallo: this is why I didn't want to make xbase-clients installable until I'd modularised all the binaries in it ...
<mrd`> daniels: Are the executables that used to be in there available anywhere else atm?
<Nafallo> daniels: hehe, is there a workaround somewhere? :-)
<daniels> Nafallo: they sure are
<daniels> Nafallo: downgrade if you need to
<daniels> mrd`: not at the moment
<daniels> startx/xinit should come in short order (when I get out of bed), then the rest sorted roughly by importance.
<mrd`> If we downgrade xbase-clients, what version do you recommend?
<Nafallo> and where to find older versions? :-)
<mrd`> D'oh, no xset now either.
<mrd`> Better yet, is this something that patches can be provided for easily?
<infinity> daniels : Can I bug you to fix seb128's -D__XOPEN_SOURCE bug before diving back into xbase-clients?  The half of GNOME that wasn't fixed by xbase-clients is broken with that instead.
<infinity> ... maybe I should start running kubuntu.
<infinity> Okay, that mental fit has passed.  Phew.
<\sh> lol
<daniels> infinity: 'kay
<daniels> mrd`: not hugely easily, no
<mdz> daniels: this seems to be getting out of control
<mdz> daniels: I can accept your rationale for splitting the drivers, but having a separate package for every X client binary seems like madness
<trulux> heya
<daniels> mdz: not *every* X client binary
<daniels> mdz: but, by the same token, not 91 binaries in a single package
<mdz> daniels: xhost, for example?
<daniels> er, 95
<mdz> and xdpyinfo
<daniels> mdz: ... was done early because people need it there.  it may get rationalised later.
<mdz> how do you meanL
<mdz> s/L/?/
<daniels> mdz: xbase-clients was either uninstallable or empty for a while, depending on your point of view
<daniels> mdz: so I've been prioritising what needs to be available for people to use or build-depend on, and doing that as I go
<daniels> mdz: it may happen that some of these get rationalised into larger source packages as I go
<daniels> i have no intention of turning xbase-clients into 95 separate source packages, if that's what you mean
<mdz> daniels: what are you using as upstream source for these?
<daniels> mdz: ... x.org?
<mdz> daniels:  x.org is releasing separate tarballs for xhost and xdpyinfo now?
<daniels> mdz: yes
<mdz> ...
<daniels> mdz: i had nothing to do with the autotooling of the apps.  it's not my structure.
<mdz> I can't think of a rationale for that
<daniels> mdz: as I said, it's not my structure
<daniels> the rationale used in splitting packages seems to be 'start with one per package, and consolidate from there if they're quite obviously similar'
<mdz> so in order to get a sane number of .orig.tar.gzs, you're going to need to create source packages containing multiple upstream tarballs?
<daniels> yes
<mdz> ick
<daniels> yes
<daniels> i could avoid that and just have a large number of .orig.tar.gzs if you want :)
<lamont> daniels: he _did_ use the word 'sane'.
<daniels> well, it avoids having multiple upstream tarballs in the one .orig.tar.gz ...
* lamont grumbles and wonders what parts of kde _weren't_ uploaded this week
<Nafallo> who shall I hug for the improved gui? is it gtk's or xorg's fault? :-)
<daniels> gtk
<mrd`> Cairo.
<Nafallo> kewl. it's almost worth the upgrade to broken keyboard ;-)
<ogra> #tsk
* ogra happily kept away from upgrading and realizes that it was worth it :)
<Nafallo> ogra: baah ;-)
<ogra> heh
<Nafallo> ogra: nothing was wrong with -36 :-)
<ogra> my pbuilder is up to date though
<lamont> ogra: yes there was
<lamont> specifically, you couldn't build things with -36
<Nafallo> lamont: but I had a full-fledged working environment ;-)
<lamont> well, there is that
<daniels> building things is for sissies
* lamont throws 3 sissies at daniels
<Nafallo> lol
<ogra> hehe
<Amaranth> That's funny, I'm fully upgraded and everything works perfectly well.
<Amaranth> Well, except for the _ENTIRE TOP ROW_ of my keyboard... :/
<Amaranth> esc, f1-f12, print screen, etc
<daniels> superfluous keys
<Amaranth> hehe
<lamont> gcc-4.0_4.0.1-2ubuntu3_20050721-1530     08:08:44 (5 entries, sigma 06:26:08)
<lamont> that just plain _hurts_
<Amaranth> changing to a console from a broken X is kinda important
<schweeb> Amaranth: you can use sysrq r, then change
<schweeb> in my experience
<daniels> Amaranth: sudo chvt 6
<Amaranth> sounds like a dirty hack
<lamont> Amaranth: does ctl-[ work?
<mrd`> Amaranth: Yeah, I've got that problem too... that and I can't swap caps lock/ctrl.
* Amaranth isn't on ubuntu right now
<Amaranth> meh, Sun users
* mrd` hates Sun.
<Amaranth> well, probably emacs users now
<mrd`> Yeah.
<Amaranth> stupid emacs, why won't you die?
<schweeb> lol
* lamont notices that his mirror-freshening attempt is now over 1GB
<Amaranth> and no, i don't like vi either
<Amaranth> <--gedit :D
<schweeb> ugh
<schweeb> how functionally impaired that program is
<lamont> damn.  threw all the sissies at daniels, or I'd have some to chuck at Amaranth 
<Amaranth> heh
<Amaranth> gedit is a _text editor_
<Amaranth> it's not an operating system
<schweeb> vi is far from an operating system
<lamont> 1114440 pool
<lamont> and that's just the files that are _missing_ on my real mirror
<Amaranth> vi is shit :P
<lamont> sneaker-net rulez!
<lamont> we need ccache bindings for gcj
<Amaranth> nothing beats the bandwidth of a station wagon loaded with tapes
<lamont> 747 loaded with dvd's might be better bandwidth
<Amaranth> hmm
<Amaranth> but 747s crash
<lamont> anyway, time to go home and do the push half of the mirror freshening.
<lamont> so do station wagons
<schweeb> gedit is designed for useability... vi is designed for power and functionality
<lamont> iz just a dropped packet
* Amaranth likes that usable part
<Amaranth> hehe
<Amaranth> ooh, pigeons
<Amaranth> dropped packet == hunting season
* Amaranth should have been in bed 5 hours ago and is running on pure caffeine and sugar
<Amaranth> so i probably sound stupid
<schweeb> lamont:  747 with LTO2's
<ogra> Amaranth, you wrote smeg in gedit ?
<Amaranth> yep
<Amaranth> entirely
<ogra> wow
<Amaranth> my first text editor was notepad
<schweeb> fairly sure a LTO-2 tape has more storage per square inch than dvd
<lamont> schweeb: have to take into account mastering time, as well as load/unload time for the transport
<Amaranth> gedit is a step up
<lamont> anyway, later.
<schweeb> heh
<HrdwrBoB> schweeb: why not LTO3
<Amaranth> emacs is a leap sideways into hell
<HrdwrBoB> schweeb: well the data density is much higher
<schweeb> HrdwrBoB: I've not used them yet :p
<HrdwrBoB> in terms of physical space
<schweeb> I use LTO1 and virtual LTO2
<HrdwrBoB> ah
<HrdwrBoB> we're getting an LTO3 8 changer
<schweeb> 8 tape changer, or 8 drive changer
<Amaranth> anyone remember when a 1GB tape was huge?
<schweeb> Amaranth: yep
* Amaranth points and laughs at the old geezer
<schweeb> I had a 200MB drive in 1994
<HrdwrBoB> 8 tape changer
<Amaranth> dude, the first tape i saw was 80GB
<ogra> Amaranth, late guy :p
<schweeb> hah
<Amaranth> i think that was 1998
<HrdwrBoB> I had a 2gb tape drive at one stage
<Amaranth> it was really 40GB but they claim 2:1 compression (pure text)
<HrdwrBoB> yeah they all do that
<schweeb> HrdwrBoB: my libraries have ~ 5000 slots, iirc
<schweeb> Amaranth: every tape claims 2x compression
<HrdwrBoB> yeah we had a library at the place I used to work, had two drives in it up to a maximum of six
<schweeb> LTO-1 is 100/200, etc...
<HrdwrBoB> LTO-2 is 200/400 LTO-3 is 400/800
<schweeb> HrdwrBoB: EMC makes this great product... CDLs... Clariion disk library... they emulate a library, and store to a SAN
<HrdwrBoB> why would you want to do that?
<HrdwrBoB> surely the point of a san is random access
<schweeb> tape management is incredibly expensive
<schweeb> and time consuming
<schweeb> and slow
<schweeb> you can offsite a virtual tape over IP
<schweeb> plus, with RAID, CDLs are faster, more reliable, and easier to expand
<schweeb> (they're built on a Clariion CX chassis)
<daniels> infinity: any new FTBFSes I should know about?
<bddebian> licq :-)
<bddebian> But then again I'm sure you don't care about that one :-)
<daniels> right
<infinity> daniels : Just the __XOPEN mess, afaik.
<daniels> infinity: 'kay
<daniels> sorting that out now
<infinity> daniels : I don't intend to peruse build logs in depth until that's fixed, since it's killing a fair number of packages and is nonintuitive to sift through.
<daniels> infinity: mainly interested in ^libx
<infinity> daniels : Once that's fixed, I'll do yet another mass give-back (I wonder if lamont's INBOX hated me for the last 1600 messages he got..), then we'll go from there.
<calc> is the firefox totem plugin already in ubuntu?
<daniels> heh
<lamont> infinity: hrmpf
<infinity> elmo : Please sync foomatic-filters-ppds from unstable, our only patch at this point is the changelog.
<lamont> elmo: and palo should be sync-able now. thanks
<infinity> Hey, ia64 has almost caught up witht he give-back backlog.  Finally.
<infinity> I wonder if I should go to bed today...
<daniels> infinity: bed is a sign of weakness
<infinity> Sure, but staying awake for more than 26 hours is probably a sign of stupidity.
<infinity> lamont : Do you want to find a home in buildd-config for ~buildd/bin/checkchroot and ~buildd/build-breezy/ref-breezy (you'll find those files just sitting on all the buildds right now)?
<lamont> infinity: it's good to go to bed _every_ day
<infinity> lamont : ref-breezy is arch-speccific (though only ia64 currently differs, due to libc6.1 and libunwind7)
<infinity> lamont : Yes, dad.
<daniels> linfs/stupidity/maniless/
<daniels> er
<daniels> infinity: s/stupidity/manliness/
<lamont> ref-breezy?
<lamont> infinity: I'll add them
<infinity> lamont : I use them on the m68k buildds to check for unclean chroots (of which we had many)
<infinity> lamont : ref-$dist is just a simple list of "packages we like", while checkchroot is a lazy man's script to diff that against the installed list.
<lamont> got some trivial glue to generate ref-breezy as part of build-chroot?
<infinity> lamont : Lots of give-backs in the last week were due to packages in weird states that should have been removed but weren't.
<lamont> yeah - np./
<lamont> just tell me when and I'll do all the give-backs this time... :-)
<infinity> lamont : If build-chroot gives us the "right packages" when it's run, then said glue is simple.
<lamont> actually, if we just do it in coordinated time, then I can just flush the mailbox at the same time as the --give-back is happening in the DC
<infinity> lamont : Look at how checkchroot generates its list for diffing, and do that. :)
<lamont> build-chroot gives you a virgin chroot
<lamont> well, modulo udev :-(
<infinity> udev, module-init-tools, a few other ueless things were installed on all the machines.
<lamont> yes. because if udev ever gets installed, it totally screws the chroot.
<infinity> But none of those are a big issue compared to the several hundred packages some chroots had. :)
<lamont> so build-chroot installs
<lamont> it
<lamont> build-chroot actually installs it and unborks it.
<infinity> Oh, udev needs to be there?  See, someone should tell me these things. :)
<infinity> (I pulled it out of all the machines.. Feh)
<lamont> well, either udev needs to be there, or we need to have something essential that conflicts withi it...
<infinity> Easy enough to just put it back, and add it to the list so I don't go removing it again.
<lamont> it trashes /dev when it gets installed, since obviously you'd only install it if you wanted udev to run /dev for you.  But oops, udevd won't run in a chroot
<lamont> look at build-chroot... "easy" isn't really quite exactly the right term.
<infinity> Right, well, I'll fix that up when I wake up then.
<lamont> enjoy. :-)
<lamont> I'll tweak build-chroot to generate ref-$dist, and include checkchroot in the tree, too.
* daniels stares at the extent of the XOPEN_SOURCE damage, weeps.
<lamont> daniels: as well you should, you murderer
<daniels> isn't the FDS_BITS macro infinitely more portable?
<infinity> daniels : There's a bug filed at fd.o too, I'm assuming you've visited.
<daniels> in passing, yeah
<lamont> 16221 buildd    35  10  203m 201m 1036 R 98.9  2.5   8:53.79 ld                 
<lamont> and that's not even a test...
<infinity> Pfft.  Your ld has nothing on my thunderbird.
<infinity> 17:20 <infinity> 11955 adconrad  16   0 3035m 1.7g  14m S  2.0 84.1  76:39.53 mozilla-thunder
<daniels> eh, my *panel* leaked 2GB once
<lamont> infinity: but that's just linking one *(^_)*^_ shlib
<lamont> and for the record, java sucks
<infinity> I just like how it took me 76 CPU minutes to notice my machine was spinning out of control.
<lamont> 11 minutes 
<lamont> sigh
<infinity> Proof I don't actually use the CPU for much of anything else most of the time.
<lamont> lol
<lamont> feh - thunderbird was only getting 5/6 of the CPU - you still had room.. :0)
<infinity> It was too busy swapping to think about anything like using the last 16% of the CPU.
<daniels> ARGH XPOLL.H
<infinity> (That was when it was munging all the build logs from the mass give-back...)
<lamont> infinity: so is the plan to give _everything_ (state==building) back?
<lamont> because if it is, I'll just flush my mailbox now...
<daniels> right, let's rewrite a bunch of obscure TOG code from 1994 that reimplements half of select.h
<daniels> what could possibly go wrong?
<infinity> lamont : That's what I did last night.
<infinity> lamont : And yes, I'll do the same thing tonight.
<lamont> infinity: woot
<infinity> lamont : I think the buildds have proven they're up to it.
<lamont> ---Mutt: =buildd/universe [Msgs:3384 New:930 Post:3 198M] ---(subject/date)-(0%)-
<infinity> Anyhow, I think I'll go catch a nap before I come back, do scary aalib/slang things, verify daniels has fixed X defines, and give back the world again.
* lamont wanders too
<daniels> bloody hell
<daniels> it seems that this code is psychotic enough that all I can do is rewrite it to use glibcisms
<daniels> MY EYES, THEY BLEED
<bddebian> hmm
<lamont>  /bin/bash: line 0: cd: build-tree/im-sdk-r11_4-1870/iiimgcf: No such file or directory
<lamont> wth??
<fabbione> morning
<trulux> hey fabbione 
* lamont throws mono-rocks at daniels
* lamont tests a new dbus before uploading it
<daniels> lamont: you have no idea the pain I'm going through
<daniels> lamont: http://home.fooishbar.org/~daniels/Xpoll.h
<daniels> lamont: that's my current workings, having rewritten practically everything inside #ifndef WIN32
<lamont> daniels: when you added [arch]  lists to dbus, you missed mono-mcs. :-)
<daniels> lamont: oh, cool
<daniels> worked for me, my architecture has mono :P
<lamont> yeah.  dbus is blocking kde on hppa
<lamont> so once sbuild finishes purging gcc-4.0's build-deps, it gets to take a stab at mono
<lamont> er, dbus
<lamont> sigh. dbus is #20 or so of 20.  I'll look at it in the morning, and upload it then if it passed.
<lamont> g'night
<bob2> 'night lamont
<daniels> night lamont
* davyd wanders in drowned rat style
<Burgundavia> does the hoary ppc cd burn with Mac os X disk utility
<davyd> from memory... no
<davyd> I seem to recall running into this problem
<davyd> and having to use my PC to do it
<Burgundavia> ouch
<Burgundavia> is there a workaround?
<davyd> burn on Linux?
<davyd> or perhaps Roxio Toast might handle it... I don't know
<Burgundavia> is FirestartFX free?
<Burgundavia> and is this a bug in DU or in hoary?
<davyd> I don't know what that is
<davyd> Burgundavia: well, it seems to be a real burnable CD image from other applications
<davyd> Burgundavia: so go figure...
<pitti> Good morning
<sivang> pitti: Morning martin
<pitti> daniels: is there any fix for the keyboard suckage? I can't work like this, and downgrading to a previous xbase-clients or s/keyboard/kbd/ in xorg.conf doesn't help
<trulux> pitti: Hua!
<trulux> pitti: :)
<pitti> daniels: I also tried the xkbcomp symlink
<fabbione> morning pitti
<fabbione> hi trulux 
<pitti> Hi fabbione 
<daniels> pitti: you have xkeyboard-config installed?
<fabbione> pitti: afaik it's a known upstream bug...
<pitti> daniels: yes
<daniels> pitti: /etc/X11/xkb seems to be reasonably populated/
<pitti> yes
<daniels> pitti: and /usr/lib/X11/xkb and /usr/X11R6/lib/X11/xkb are symlinks to /etc/X11/xbk?
<pitti> I created the xkbcomp symlink
<pitti> no?
* pitti tries
<daniels> that would explain a lot ...
<pitti> daniels: what is the correct driver now, kbd or keyboard?
<daniels> pitti: kbd
<pitti> no fun
<pitti> still broken
<daniels> what does setxkbmap -print say?
<pitti> daniels: shall I upgrade to the empty xbase-clients again? right now I have -32
<daniels> pitti: no, the old one is fine
<daniels> pitti: try setxkbmap -print | xkbcomp - :0
<pitti> $ setxkbmap -print
<pitti> Couldn't interpret _XKB_RULES_NAMES property
<pitti> Use defaults: rules - 'xorg' model - 'pc101' layout - 'us'
<pitti> crashrep: Attempting to get a stacktrace for crashed process /usr/bin/setxkbmap(8742)
<pitti> whoa
<pitti> it crashes in XFree() -> free()
<pitti> but setxkbmap prints the wrong one
<daniels> try setxkbmap -layout de -model pc105 -print
<pitti> $ setxkbmap -layout de -model pc105 -print
<pitti> Couldn't interpret _XKB_RULES_NAMES property
<pitti> Use defaults: rules - 'xorg' model - 'pc101' layout - 'us'
<pitti> crashrep: Attempting to get a stacktrace for crashed process /usr/bin/setxkbmap(11193)
<pitti> anyway, I'm switching to my laptop now
<pitti> thanks so far
<daniels> no worries.  i need to go pick up my little sister, but I'll go check it out.
<daniels> itmt, try -rules xorg also
<daniels> or -rules base
<sivang> woops:
<sivang> Unpacking replacement openoffice.org2-common ...
<sivang> dpkg: error processing /var/cache/apt/archives/openoffice.org2-common_1.9.114-1ubuntu3_all.deb (--unpack):
<sivang>  trying to overwrite `/usr/lib/openoffice2/share/registry/data/org/openoffice/Office/UI/DbuCommands.xcu', which is also in package openoffice.org2-base
<sivang> and there's another file with the same output
<sivang> ah that's nice , firefox is empty of strings when fired up :-)
<doko> sivang: known, work around with dpkg --unpack --force-overwrite /var/cache/apt/archives/openoffice.org2*
<sivang> doko: ok, I just did it for -common, and continues dist-upgradeing. Let's see how bad I can break my system :-)
<sivang> doko: oh good that you told me, I forgot --unpack..
<sivang> doko: what's the connection between mozilla and firefox?
<doko> ?
<sivang> doko: < sivang> ah that's nice , firefox is empty of strings when fired up :-)
* Treenaks just walked by a store which had a "LEET ELMO" graffity "tag" on it
<doko> sivang: hmm, didn't look
<sivang> doko: well, it also didn't help :)
* sivang wonders where firefox lost his ability to write string
<sivang> has anyone else bumped into a stringless firefox? (i.e. window fires up, besides icons nothing textual is display byt blank spaces)
<pitti> sivang: me, just right now; after yesterday's dist-upgrade
<sivang> pitti: I already workarounded that, but not sure if it's a good one :-)
<sivang> pitti: apt-get remove --purge mozilla-firefox, then it removed, and installed "firefox"
<sivang> pitti: do we have a new firefox package? (not mozilla-firefox)
<pitti> sivang: oh, you have to do that anyway, mozilla-firefox is old
<pitti> sivang: yes
<sivang> pitti: all the other dependencies are fixed already? (Stuff that depend on moz-firefox)
<sivang> dpkg: mozilla-firefox: dependency problems, but removing anyway as you request:
<sivang>  mozilla-mplayer depends on mozilla-browser | mozilla-firefox; however:
<sivang>   Package mozilla-browser is not installed.
<sivang>   Package mozilla-firefox is to be removed.
<pitti> well, that's multiverse, but should be fixed nevertheless
<Treenaks> sivang: it's called "firefox" now
<sivang> pitti: ah ok, thanks
* sivang goes for hopefully the last round of dist-upgrading
* Treenaks learns to read
<sivang> lol
<sivang> pitti: -restricted-modules-686 are ok to upgrade? dist-up holds them back
<pitti> they don't work right now
<pitti> we don't have r-m for 2.6.12
<Treenaks> they should be fixed soon, now X is getting less broken by the day
<sivang> yeah, so I noticed
<Treenaks> [finally] 
<sivang> Treenaks: you have any idea what to do when this happens:
<sivang> Treenaks: make[2] : *** No rule to make target `/config.status', needed by `Makefile'.  Stop.
<sivang> Treenaks: I've run autogen.sh , ./configure , make --> error
<Treenaks> uh
<Treenaks> Some rule requires config.status to exist, but it doesn't
<Treenaks> I think usually configure generates it
<Treenaks> so you should figure out why it doesn't
<sivang> Treenaks: I also figured that out, not the hard part :-)
<\sh> morning
<fabbione> pitti: ping+
<pitti> Hi fabbione 
<fabbione> pitti: are you aware that the latest security fix for firefox is broken?
<pitti> fabbione: yes, 10.000 users knocking on my door can't be ignored :-/
<fabbione> ik5pvx just told me that using ctrl+t makes baby jesus cry
<fabbione> pitti: ehehe ok :)
<pitti> fabbione: it seems to crash for everybody but me
<pitti> fabbione: I'm using it for three days now (including extensions) without problems...
<fabbione> pitti: you can borrow the sodomotron if you need ;)
<pitti> fabbione: that'd be very welcome :-)
<fabbione> pitti: arch specific problem?
<pitti> fabbione: anyway, I'm doing half a thousand different test builds to isolate the problem
<ik5pvx> middle-click doesn't work anymore either. using tab-extensions here
<fabbione> pitti: is it reproducible in breezy?
<fabbione> or is it a hoary thing only?
<pitti> fabbione: breezy has 1.0.6, it works there 
<fabbione> ok
<\sh> actually I don't have any fonts for firefox running with kde
<pitti> fabbione: I guess some/one of the patches were just broken
<pitti> \sh: that's really a breezy thingy
<fabbione> pitti: ok.. how many patches did you apply? ;)
<fabbione> pitti: perhaps trying one at a time
<\sh> pitti: any workaround known, or is it just xorg? ,-)
<pitti> fabbione: hm, 10 maybe, some of them > 20 kB
<\sh> s/xorg/broken/ 
<pitti> fabbione: that's what I did, but it worked for me, so I released it
<fabbione> pitti: no i mean.. to try to isolate the problem
<pitti> fabbione: now I roll back the patches until the extensions the folks out there want work again
<pitti> yes, thats what I do since yesterday
<fabbione> pitti: if you publish the temp debs i am sure ik5pvx can test them for you
<ik5pvx> yup, I'd be happy to
<pitti> hm, they are 100 MB each (with debug symbols)
<fabbione> pitti: btw.. ik5pvx meet pitti.. pitti meet ik5pvx :)
<pitti> anyway, I can reproduce the problem with one extension
<pitti> so I can test :-)
<fabbione> pitti: ik5 was the man that converted me to linux
<pitti> Hi ik5pvx :-) sorry for the inconvenience
<\sh> mkfontdir will be after the xorg transition in /usr/bin/ ?
<fabbione> ik5pvx: pitti is our security god
<ik5pvx> pitti you're making me unable to work today so I'm not really sure it's an inconvenience ;-)
* pitti really learned to hate mozilla code in the last week
<\sh> ik5pvx: use konqueror ,-)
<pitti> ik5pvx: just install the previous version or 1.0.6 from breezy for now
<pitti> ik5pvx: or just remove those damn extensions
<pitti> I can't work very well either since I don't get fonts in firefox and my keyboard is broken
<pitti> I just downloaded the hoary CD and will install it now to be able to work sanely
<\sh> pitti 0 firefox 1 / sh 1 1/2 xorg 5 1/2
<pitti> hm?
* fabbione fires up the GodFather theme
<pitti> ok, going offline for installing hoary, now I can give some love to my neglected inbox in the meantime
<fabbione> we are almost ready to release the new kernel
<pitti> cu later
<ik5pvx> withouth the tabextensions it works
<ik5pvx> oh... he left
<fabbione> ik5pvx: yeah.. like fsck.. superfastquitter
<ik5pvx> no problem, just ping me on the other chat when he's back with something to test. 
<fabbione> ok
<daniels> god
<daniels> i'd forgotten just how much building the monolithic tree to test stuff sucked
<daniels> like, a full build, not our mickey-mouse mesa-and-servers build
<Treenaks> there still is one?
<daniels> sadly, yes
<daniels> and I have to stop breaking it
<daniels> i figure smashing Xpoll.h in the monolithic tree would make me none too popular
<Treenaks> ah who uses that anyway ;)
<daniels> (given I've already broken the monolithic build to make the modular build work about five or six times now)
<davyd> so Breezy now ships GTK+ 2.7
<davyd> are icon theme packages still coming or something?
<ogra> davyd, ?
<\sh> did anybody made a decision about the merge freeze? do we have more time?
<davyd> it seems that things like GtkFileChooser can't find icons it wants
<\sh> morning ogra
<ogra> hey \sh 
<ogra> davyd, which icon theme ?
<ogra> default ?
<davyd> I guess gnome-icon-theme
<davyd> yeah, I'm using stock icons
<bob2> 2.7 with cairo?
<davyd> whatever ships in breezy, it would seem to be cairo-backed
<bob2> rock
<ogra> davyd, so probably we get new icons then :) 
<davyd> I don't understand what you mean
<ogra> <davyd> it seems that things like GtkFileChooser can't find icons it wants
<davyd> I know what I said ;)
<pitti> yay! an X and a mozilla-firefox that actually work :-)
<fabbione> elmo: please sync fuse 2.3.0 from Sid. ok to override
<ik5pvx> pitti, removing tabextensions gave me back a working firefox in hoary. for what is worth, the dreaded combination doesn't work in breezy either
<pitti> ik5pvx: you mean the tabextensions extension fails with 1.0.6?
<ik5pvx> yes, but they work with plain mozilla
<davyd> also, has libc changed in such a way that strdup is now deprecated?
<ogra> davyd, huh ? doesnt it work for you ?
<ogra> (works fine here)
<davyd> ogra: it wants me to define __USE_BSD to get it
<ik5pvx> pitti, I know it's in universe and they are not supported, but they are sooo useful :)
<ogra> davyd,  #define _GNU_SOURCE ??
<ogra> (wuld be the common way)
<davyd> why is that required?
<pitti> ik5pvx: if it doesn't work with 1.0.6, then at least I didn't fuck up the security patches so badly
<ogra> dunno, but man strdup says so ;)
<pitti> ik5pvx: I guess these extensions just need to be adapted to the new API
<daniels> davyd: just remove _XOPEN_SOURCE from your cflags
<davyd> daniels: aah
<daniels> davyd: this is what I've spent most of the day fixing in a way that works for both the modular and monolithic trees
<\sh> mako: pingeling
<daniels> committed just a couple of minutes ago: http://lists.freedesktop.org/archives/xorg-commit/2005-July/004512.html
<davyd> daniels: is there a sane thing I can remove it from?
<davyd> where am I picking it up from?
<daniels> davyd: sudo sh -c 'for i in /usr/lib/pkgconfig/*.pc; do sed -i $i -e "s/ -D_XOPEN_SOURCE//;"; done'
<daniels> now it's time to update x11proto-core to CVS
<daniels> what could *possibly* go wrong?
<davyd> daniels: your sed fu is apparently not strong enough
* jordi tickles davyd; jumps onto daniels' back.
<davyd> ack
<daniels> davyd: hm?
<daniels> jordi: too tired
<jordi> daniels: dude, channel for silly x questions? fdo?
<jordi> well, it's not silly.
<jordi> it's about getting rid of The Evil .
<davyd> the what?
<daniels> jordi: #freedesktop, I suspect
<jordi> davyd: /, otherwise known as L STRIKE
<davyd> ok, so I did get the right character
<davyd> what is it used for?
<jordi> It's a letter in Polish. Nothing useful in a Spanish keyboard though.
<Treenaks> jordi: wasn't there something like that in Catalan?
<jordi> So my great plan is to replace that  and , which is like ll but composed, and leet.
<jordi> replace that with, that is
<jordi> This is nothing I would have even dared to propose in the dark Dawes era.
<jordi> But now that X is populated with cool people..
* jordi licks daniels.
<daniels> ll is rad
<daniels> parallel
<daniels> daniels@brainfreeze:~/canonical/xorg/proto/x11proto-core/x11proto-core-6.8.99.15+cvs.20050722% grep _XOPEN_SOURCE obj-x86_64-linux-gnu/xproto.pc
<daniels> zsh: exit 1     grep _XOPEN_SOURCE obj-x86_64-linux-gnu/xproto.pc
<daniels> <- winner
<jordi> daniels: yeah man
<jordi> ok, so who should I talk to in order to get a *rocking* change to the Spanish X keymap?
<daniels> jordi: xkeyboard-config
<jordi> hmm, this is not #fd
<daniels> nope
<jordi> paralel
<jordi> now, when we get a non suck Vera font that includes it
<daniels> whatever's the default monospace font in hoary has it
<jordi> xkeyboard-config. Is there a specific list for this?
<jordi> vera does not.
<daniels> jordi: yeah, xkb@lists.bat.ru, I think
<jordi> daniels: I believe fontconfig is falling back to freefont
<jordi> does it suck? Or do you see it nicely?
<jordi> daniels: uuuh, russian mailing lists.
<jordi> daniels: ooh, lovely!
<jordi>   * Do "sleep 2" to wait daemon's wake up. (this is just workaround...
<jordi>     needs better solution, for #309794 and #315017)
<jordi> I know little daniel loves these
<daniels> huh?
<daniels> is this dbus?
<daniels> oh, cupsys
<daniels> that's not my package :P
<daniels> jordi: i see it, but it looks weird
<daniels> jordi: i think parallel looks better than paralel
<jordi> with a decent font, paralel is nice.
<jordi> it's the "right thing"
<seb128> it sucks
<daniels> i'm with seb
<daniels> as much as it pains me to say that
<seb128> ah ah
<seb128> hey daniels :)
<daniels> morning sebolino
<daniels> i fixed the _XOPEN_SOURCE braindamage, it was harder than I thought
<daniels> now to clean everything up
<daniels> daniels@brainfreeze:~/canonical/xorg/app/xrandr% grep _XOPEN_SOURCE /usr/lib/pkgconfig/*.pc | wc -l
<daniels> 25
<seb128> cool
<seb128> utch, lot of stuff to rebuild
<daniels> yeah
<daniels> and libx11 needs to be updated from cvs for some losers with dead keys or non-english locales or something equally stupid
<jordi> not your package, but didn't you work on speeding the boot of ubuntu?
<daniels> yeah
<daniels> oh, I see
<daniels> cupsys starts after gdm, anyway :P
<daniels> i think
<jordi> nod
<jordi> huh
<jordi> OVER MY DEAD CORPSE xmms is getting installed
<bob2> mplayer started depending on xmms for some reaon lately
* jordi swiftly purges mplayer.
<JaneW> any idea why my sound vanished yesterday? I can't find anything wrong...
<Treenaks> mplayer can now use xmms plugins.. so it should probably Recommends:
<jordi> hi jane!
<JaneW> hi jordi :)
<Treenaks> JaneW: it's pitti's fault :)
<JaneW> must be
* jordi didn't upload any alsa related package lately. Not me. :)
<bob2> Treenaks: ah
<pitti> JaneW: I didn't touch your box, promised
<JaneW> hmmm
<pitti> JaneW: vanished in the sense that it can't open the sound device, or it does open it and you can't hear anything?
<JaneW> everything appears noraml, but no sounds comes out
* seb128 kicks pitti 
<jordi> JaneW: all sound levels at max?
<seb128> pitti: this CVS packages stuff is worst idea grrrr
<JaneW> whether on e-mail or a sounds or video files etc, no sounds come out the machine now (and it;s not muted and the volume is on full)
<JaneW> and I have rebooted
<JaneW> I tried to show the UN inspector some of the Mark video from Debconf, and it was silent, and since then I noticed no sounds are working, but they were yesterday am...
<pitti> seb128: hm?
<seb128> pitti: we get enough bugs without starting packaging gaim CVS or whatever else
<daniels> JaneW: try running killall esd
<pitti> seb128: I never proposed to do that
<JaneW> daniels: really? Sounds dangerous
<pitti> seb128: I just followed up with I'd rather see separate archives than cluttering up universe
<seb128> pitti: you should have rejected the idea instead of proposing an another solution
<seb128> pitti: I've a feeling on where the gaim bug from "experimental" will fall ....
<seb128> pitti: anyway just joking, your reply has nothing wrong, but for my part I'm against this stuff :)
<pitti> seb128: that's what grumpy was all about :-) for the crazy COTM folks out there
<ogra> seb128, its a sabdfl solution....
<seb128> no
<ogra> yes
<ogra> :)
<seb128> grumpy is an automatic stuff, doesn't use ressources from maintainers
<seb128> ogra: NO
<ogra> seb128, grumpy will provide the lates stuff as source and autobuilt binary
<seb128> grumpy is an automatic build of CVS packages
<seb128> yeah
<ogra> so if it builds it might be installable
<seb128> we don't intend to support bugs for it
<ogra> and you could use gaim-cvs
<ogra> nope
<seb128> k, but we do support for universe
<ogra> eeek, no !
<seb128> so gaim-cvs to universe will have support
<seb128> hum, why people keep putting bugs to malone so?
<ogra> not for this stuff... (as long as its in a external repo)
<seb128> read again the original post
<ogra> i know it...
<seb128> they want to upload to universe
<ogra> yep
<seb128> so we will get bugs
<seb128> I can bet on that
<ogra> so pittis suggestion isnt the wrongest
<seb128> nop
<seb128> but what the interest of packaging the CVS
<daniels> and another CVS snapshot of libsm \o/
<seb128> there is enough of nice stuff not packaged and packaged bugged
<ogra> seb128, ask \sh 
<ogra> it wasnt my idea... but i understand they want to be able to play with such stuff.... grumpy is still a bit far out...so either they do something interim or are patient... patient semms not to work as you can see :)
<ogra> s/semms/seems
<seb128> people always want the day version
<seb128> they don't care about upstream version freeze
<seb128> they don't care about stability
<\sh> seb128: no...it has something to do with actual released stable protocols in jabber ,-)
<seb128> that does mean that's a good idea to ship it
<seb128> what stable protocols?
<\sh> seb128: XMPP 1.0 SRV Records recognition etc. in gaim, psi etc. 
<\sh> seb128: there r some things u have to test to get a good environment for XMPP/Jabber IM services 
<seb128> it's a gaim 2 stuff, or a current gaim feature?
<\sh> seb128: a gaim patch
<seb128> so why not patching the official package?
<ogra> backported from gaim2 ?
<seb128> instead of duplicate packaging work
<\sh> seb128: actually...you can throw a patch in a stable package without knowing what will happen later...but it's not good..so to have a wider range of people testing important features for the next release...should be valuable. I don't want to screw stable releases
<seb128> don't use universe for that
<seb128> other people put their package on a webpage, people.ubuntu.com or other
<seb128> do the same
<\sh> seb128: that's why I asked
<ogra> and wait for grumpy ;)
<seb128> grumpy will have upstream CVS
<ogra> then you'll have it automatically 
<seb128> no patches
<daniels> seb128: so I'd better stop packaging CVS x11proto-core/libx11-6/libsm, then :P
<seb128> daniels: no, you don't have 2 packages
<daniels> hmm?
<seb128> daniels: I package GNOME 2.11 with some CVS snapshot too, but not gnome-stable and gnome-cvs
<seb128> daniels: they want to do gaim and gaim-cvs packages
<daniels> ugh
<\sh> seb128: no...actuall gaim + special patches
<\sh> not cvs
<thom> _SPECIAL_
<\sh> s/special/backported stuff/
<\sh> forget aboutit ,-)
<seb128> anyway 2 different packages for the same upstream stuff ...
<\sh> seb128: hmmm... sylpheed and sylpheed-claws? 
<daniels> get ready for XORG and XORG-CVS
<seb128> bah, no reason to discuss that for hours, I've said what I have to say on the topic, let's do some work
<\sh> seb128: yeah..
<seb128> they are upstream changes no?
<seb128> upstream versions, I mean
<\sh> seb128: sylpheed-claws is normally the latest bleeding edge..but I'm not into this gnome stuff ,-)
<seb128> that's an upstream stuff or a packaging specific one?
<\sh> seb128: upstream stuff
<seb128> what I thought
<seb128> so it makes sense
<ogra> they are two different things
<\sh> ogra: actually -claws is testing new features
<daniels> i've got this great idea
<daniels> i'm going to package metacity cvs
<ogra> the sylpheed author doesnt want to clutter his code and hasnt the time to develop additional features...
<\sh> which will become stable after some time in sylpheed...anyways..stop talking about this
<daniels> and put in some totally sweet patches of my own
<daniels> to change how focus works
<daniels> it'll be great
<ogra> -claws is totally separate and only uses sylpheed as a base
<ogra> its like mutt and mutt-ng
<thom> dude, just upload a gnome-crack package that uses luminocity as the default WM
<thom> it'll kick ass
<\sh> then I misinterpretated the targe
<\sh> t
<\sh> ogra: so a fork 
<seb128> daniels: you will have to hit a ftpmaster before doing that :p
<ogra> they are two projects :)
<\sh> doesn't matter now...
<\sh> topic ended...
<ogra> i wouldnt call it a fork, since they always use the latest sylpheed... its a spoon :)
<jordi> knife
<\sh> finally a knife
<ogra> heh
<\sh> because there is no spoon
<seb128> anybody has an opinion on anjuta/anjuta2 ?
<seb128> Debian has anjuta 2.0.1
<ogra> anjuta2 is stable enough ? 
<seb128> that's my question
<seb128> it's unstable version according to upstream
<ogra> i dont use it... i frequently install it and look at it ...
<seb128> so we better keep anjuta1 for now
<ogra> but thats all
<seb128> and get anjuta2 after 5.10
<ogra> yep
<jordi> according to the bugs in the bts, it doesn't seem to be too bad
<ogra> leave it in universe for now
<seb128> jordi: /me slaps jordi
* jordi uses his eyes laser beams against seb128.
<seb128> jordi: it's available for like half of a day, I would not expect people running on it that fast
<jordi> oh, I thought it had been around for like a week
<seb128> jordi: gnome-build has accepted yesterday
<jordi> maybe it went through exp
<seb128> it went through NEW
<jordi> shrug
<jordi> maybe they talked about it in planet :)
<seb128> we talked about it on #gnome-debian
<seb128> maybe you read that here ? :p
<jordi> maybe
<jordi> I'm sleepy
* jordi curls in his corner.
<daniels> thom: xgl is now far more crack than luminocity
<daniels> thom: but in the good way!
<doko> fabbione: the competition for cpu power is unfair on davis :-/
<daniels> \o/ davidr
<fabbione> doko: eheheh i am almost done :)
<ogra> doko, did he use extensive -j5000 switches again... ? :)
<pitti> fabbione: I tracked down the ffox patch at least
<fabbione> ogra: i have it in my .bashrc to export -j300 :)
<ogra> lol
<fabbione> pitti: ik5pvx was talking about the tabextensions
<fabbione> ogra: much easier than having to set it up each time :)
<ogra> hehe, yes
<pitti> fabbione: since that one doesn't work in 1.0.6 as well, it's not the thing I should hunt down now; I'd rather fix the other common crash
<fabbione> pitti: right..
<pitti> ik5pvx: okay, I installed mozilla-tabextenstions and started ffox. What now?
<pitti> fabbione: I'll try it nevertheless :-)
<pitti> ik5pvx: I can create new tabs, close them, duplicate them without crash (at least on the patch-reduced ffox I'm using now)
<pitti> ik5pvx: ah, I can reproduce the crash with the fully patched version :-)
<elmo> infinity/fabbione/lamont: done
<azeem> did anybody check whether 'utnubu' means something nasty in whatever language Ubuntu is from?
<fabbione> elmo: thanks
<fabbione> Kamion: new kernel on the way soon (waiting the porting boxes to finish the last testbuild)
<chmj> azeem, no it doesn't 
<Kamion> fabbione: ok - ABI change or not?
<fabbione> Kamion: yup
<Kamion> ok
<fabbione> Kamion: i had rather wait for monday or tuesday before you upload a new d-i if that's possible
<fabbione> i have other changes coming in, but i need to make a release.. and they will mostlikely change the ABI again
<fabbione> Kamion: just tell me what you prefer and it is perfectly fine for me (either way i mean)
<fabbione> pitti: sparc just hooked up mozilla security update.. can i just kill it?
<Kamion> I'd rather keep d-i working even if that involves multiple uploads
<fabbione> Kamion: sure.. it was only to spare you time..
<Kamion> broken d-i doesn't save me time. :-)
<fabbione> Kamion: why not? you have an excuse to blame the kernel :P
<ik5pvx> pitti, here it crashes when doing ctrl-t to open a new tab, and the middle click to open a new link in background (guess you have to tune the configuration since I don't think it's in the default tabextensions config) it does nothing
<pitti> fabbione: if you want to, yes; I won't release it for sparc anyway for now
<pitti> ik5pvx: <pitti> ik5pvx: ah, I can reproduce the crash with the fully patched version :-)
<ik5pvx> pitti, ok
<fabbione> pitti: ok :)
<fabbione> doko: i have done on davis (for today)
<niran> renaming directories under baz control is a bad idea, right?
<bob2> nope
<bob2> it's fine
<niran> oh, cool
<Treenaks> niran: s/baz/cvs/ and you're in CVSROOT hell
<niran> ha, yeah
<seb128> pitti: any chance you comment on launchpad-integration for main today? This spec needs to move, it's on the top specs for 5.10
<pitti> seb128: can you nag me this afternoon again? I'd like to settle that firefox crap before
<seb128> sure
<seb128> thanks
<JaneW> has jammcq been around recently?
<Kamion> infinity: I think we should just do the slang2 transition
<ogra> *shudder*
<zwnj> hi all,  why don't build mozilla-thunderbird in single-profile mode?
<zwnj> also mozilla-firefox
<zwnj> not builing in single-profile mode causes to get a new profile (profile-manager) dialog with every execution
<zwnj> user cannot use firefox's send mail button to send a new mail with thunderbird, blah blah...
<mdke> i don't get a new-profile with every execution
<mdke> it just opens
<pitti> works for me, too
<pitti> it reuses the already running instance
<Kamion> elmo: could you sync in slang2 2.0.4-4 from unstable, please? (it's not in Ubuntu at all for some reason)
<JaneW> does anybody have a working email address from tseng?
<JaneW> tseng: ping (maybe you would know) ;)
<daniels> tseng@ath.cx, IIRC
<Kamion> lamont: ping, re util-linux and slang2
<Kamion> lamont: (#315634)
<zwnj> mdke, pitti: do you have any idea what the problem is?  i get a new profile windows on my friends system too
<bob2> presumably you have a lock file left over
<JaneW> daniels ack that doesn;t work either *sighe*
<daniels> JaneW: no idea, sorry
* pitti does ~/mozilla-firefox-1.0.2$ patch -R -p1 < debian/patches/break-the-world.patch
<pitti> ik5pvx: good news
<pitti> ik5pvx: you don't have an amd64 by any chance? otherwise I'd like to send you a test deb
<pitti> zyga: ping
<ogra> elmo, ping
<pitti> seb128: here?
<seb128> pitti: pong
<pitti> seb128: you are using ffox 1.0.6, right? could you do a small test for me?
<ogra> zwnj, make sure there is no instance running anymore and look if you find a file called "lock" in a subdirectory below ~/.mozilla ... remove it...
<seb128> pitti: sure
<pitti> seb128: could you please install mozilla-tabextensions, restart ffox and try to open a tab?
<seb128> it hangs
<ogra> has anybody an idea what katie means with: found duplicate status token ('KEYEXPIRED'). ??
<pitti> seb128: ok, thanks; so this is not my fault
<seb128> pitti: it doesn't hang but clicking on tabs doesn't work
<ik5pvx> pitti, no only a lousy x86, and an old one too
<pitti> seb128: it just crashes for me
<pitti> ik5pvx: well, tabextension still doesn't work, but other things (like the html validator) do work now
<seb128> pitti: I can use the first tab, enter an URL
<pitti> Hi carlos
<Kamion> mako: ping, re most and slang2 (#315639)
<carlos> hi
<seb128> pitti: k, the first tab works fine but I can't switch tabs or use others
<bob2> is the segfault present 1.0.6 or an artifact from cherry picking?
<pitti> seb128: ok,thanks for testing
<seb128> np
<pitti> bob2: as seb128 just tested, it's just the new API as it seems
<pitti> I verify that the new patch is better in thunderbird
<bob2> ah, nice
<ogra> JaneW, tseng = brandon@smarterits.com
<Kamion> elmo: thanks
<mako> Kamion: oh right..
<JaneW> ogra: yay thanks!
* JaneW bows down to ogra - all knowing being
<mako> Kamion: i think that might fix another most bug.. i'll try it out today
<ogra> JaneW, heh
<mako> Kamion: was planning on just uploading into debian.. want me to also upload it into ubuntu?
<Kamion> mako: just to Debian please, we'll sync it to Ubuntu without requiring a separate upload
<Kamion> thanks
<mako> Kamion: nogreat
<fabbione> Kamion: new kernel is on the way now
<fabbione> it will need some NEW love
<herzi> where did xauth go?
* Amaranth cheers
<daniels> it went to a better place
<Amaranth> heh
<daniels> it'll be happier there
<mdz> ogra: so about mediawiki...
<Amaranth> we're not going to have xauth?
<mdz> ogra: how much work would it be to package?
<ogra> one day of work i assume...
<Amaranth> autopackage uses xauth... :/
<ogra> probably less
<mdz> ogra: ok, let's do it then.  it will make the teachers happy
<ogra> yay
<ogra> :)
<ogra> but first i have to know why katie doesnt like me today...
<ogra> Kamion, help ? 
<JaneW> .
<fabbione> ogra: did you send her flowers?=
<fabbione> she still loves me tho ;)
<fabbione> linux-source-2.6.12_2.6.12-4.4_source.changes ACCEPTED
<ogra> fabbione, hmm that might be it... but i suspect she's angry now and would reject them too
<ogra> Rejected: internal error while performing signature check on pymad_0.5.4-1ubuntu2.dsc.
<ogra> found duplicate status token ('KEYEXPIRED').
<JaneW> ogra: what have you done?
<elmo> will you guys stop bugging kamion in the first instance - I'm pretty sure he has better things to do with his time
<JaneW> oh dear
<ogra> elmo, could you have a look at pymad, i dont understand whats going on with it
<fabbione> ogra: KEYEXPIRED smells of gpg :)
<ogra> fabbione, but non matching md5 sums and filesizes too ?
<fabbione> humpf.. only 14K of changes
<ogra> i did only one upload and there already seems to be something in the queue
<ogra> its a bit confusing...
* fabbione switches ClusterFileSystem to DEployed
<ogra> ...locally everything seems right...
<daniels> Amaranth: xauth is coming back, but there are more important things to do
<Amaranth> whew
<daniels> like rebuild all of the libraries
<Amaranth> TD didn't like me much when I made him put in a new path for xauth last time, I think he'd kill me if I told him it didn't exist anymore ;)
<fabbione> Kamion: did you decide to import the new partman, or we will stick with the old one?
<daniels> Amaranth: /usr/bin/X11/xauth is guaranteed to exist across every version of Ubuntu and every UNIX ever
<daniels> Amaranth: /usr/bin/xauth is where it actually lives
<Amaranth> daniels: appearently not, autopackage has a dozen places it has to look to make sure it finds it
<daniels> wot crap
<Amaranth> people don't always follow the rules ;)
<Kamion>    partman |         68 |      unstable | source, i386, powerpc
<Kamion>    partman |  68ubuntu1 |        breezy | source, amd64, i386, powerpc
<Kamion> fabbione: ^--
<Kamion> fabbione: why?
<JaneW> fabbione: you are a rock star. kthnxbye
<Kamion> elmo: could you make sure not to promote libaa1-dev to main until -28ubuntu3 is built? I don't want the old one sneaking into main builds
<JaneW> fabbione: but can I set the status indicator to 'implemented'?
<JaneW> for ClusterFileSystems
<fabbione> JaneW: eheh ok :)
<elmo> Kamion: k
<elmo> ogra: I'm looking into it
<ogra> elmo, thanks a lot :)
<fabbione> Kamion: because i need to modify partman-auto-lvm to cope with the special extra partition required on ppc to boot
<elmo> meh
<elmo> ogra: you only resigned the .changes
<fabbione> Kamion: nothing too complex.. but needs to be done :)
<ogra> elmo, oh, sorry... is there an app to perform such a check locally ? and should i reupload ?
<JaneW> fabbione: HUG
<Kamion> fabbione: so do you mean the new partman, or the new partman-auto-lvm, or what?
<fabbione> JaneW: :)))
<fabbione> Kamion: you said that the new partman supports LVM on ppc, right?
<Kamion> fabbione: DUDE, stop confusing partman and parted, you're confusing the hell out of me :)
<fabbione> Kamion: if so i need to update partman-auto-lvm to work on ppc
<fabbione> argh
<Kamion> fabbione: probably not importing it
* fabbione goes and sits in a corner for 5 minutes
<Kamion> fabbione: aren't you using partman-auto recipes, anyway? those should deal with the newworld boot partition on powerpc/powermac_newworld
<Kamion> you need to be careful about subarchitectures ...
<fabbione> Kamion: yes i am using the recipes and i know about subarches.
<Kamion> ok, then it should just work?
<fabbione> Kamion: that's why i am saying that ppc needs extra love if we enable LVM
<Kamion> oh, I guess you need to keep it outside LVM
<elmo> ogra: nm, I updated the keyring so crimsun's key is considered valid
<elmo> ogra: so either reupload as was, or upload entirely resigned
<fabbione> Kamion: there is one design problem that needs to be address with special partitions
<fabbione> Kamion: exactly.. they need to be outside LVM
<fabbione> so there are 2 solutions:
<ogra> elmo, resigning, thanks again... sorry for the noise
<fabbione> 1) add a $can_be_lvm flag or $cant_be_lvm inside all receipes
<fabbione> 2) special case in partman-auto-lvm
<fabbione> now
<Kamion> I certainly prefer 1)
<fabbione> given that p-a-l was born out of crap code... and ppc is the only special case for our 6 arches..
<fabbione> and that parted doesn't support LVM, i didn't bother too much
<fabbione> i also prefer 1 clearly
<fabbione> but that requires a certain delta with the debian version of partman
<fabbione> meh
<fabbione> partman-auto
<fabbione> for a release that we agreed to send out for testing, i am happy as it is..
<Kamion> let's leave it alone for now, and add it to partman-auto upstream
<fabbione> there is generally a lot that needs to be redisegned to implement p-a-l properly
<fabbione> also lvg-cfg needs to be changed.. and export lvm access functions as a lib (duplicated code that i cleaned in pal)
<fabbione> yeah exactly...
<pitti> elmo: please sync postgresql-common 
<Kamion> pitti: could you upload your newt merge (#9516), please? slang2 source is in the archive now and should be built soon
<pitti> oh, cool
<Kamion> pitti: might want to grab the newest version for that bidi fix
<Kamion> in fact, definitely want that, because we have current slang2 which doesn't have the fribidi patch at all
<pitti> ok
<pitti> *sigh* this was a terrible merge
<pitti> but the this one should be much easier
<Amaranth> holy shit xbase-clients installed
<Amaranth> :)
<[SemTeX] > hehe
<daniels> yes, but it won't contain any binaries
* [SemTeX]  too
<daniels> but xhost, xdpyinfo, xsetmode, xsetpointer, and xrandr will be installed separately, if that's any consolation
<Amaranth> err
<Amaranth> you mean i just totally screwed up my X? :P
<daniels> probably, yeah.
<mdz> Amaranth: yes
<Treenaks> will it be fixed soonish?
<Amaranth> well, i guess windows isn't _that_ bad...
<[SemTeX] > in my case, it could only get better ;)
<daniels> Treenaks: i'm hoping so.  i've spent the day rewriting stupid obscure macros from 1994 that have to work across every platform X ships on and trying to rebuild practically every library we ship as a consequence.
<Treenaks> Amaranth: what was that quote from the MS person again, about breaking?
<Treenaks> daniels: yikes.. good luck with that then
<\sh> Amaranth: Ubuntu Hoary 504 is stable....don't complain if you decide to use breezy ,->
<Amaranth> so, uh, how important is it to have something in the desktop seed translated?
<[SemTeX] > daniels: good luck ;)
<Riddell> Kamion: http://cdimage.ubuntu.com/cdimage/kubuntu/daily-live/current/  has only amd64 CDs
<Kamion> presumably the others failed to build
<Kamion> hm, nohttp://terranova.buildd/%7Ebuildd/livecd/kubuntu/current/livecd.kubuntu.cloop:
<Kamion> 06:30:27 ERROR 403: Forbidden.
<Kamion> http://royal.buildd/%7Ebuildd/livecd/kubuntu/current/livecd.kubuntu.cloop:
<Kamion> 06:30:27 ERROR 403: Forbidden.
<Kamion> Riddell: almost certainly bitten by X trouble or similar
<pitti> Kamion: newt uploaded  (I also submitted the Xhosa translations to Debian)
<Kamion> you can check out the log files from those builds if you use w3m on chinstrap
<Kamion>   ubuntu-live: Depends: language-support-en but it is not going to be installed
<Kamion> ^ i386
<Kamion> similarly poweprc
<Kamion> infinity: why's the kubuntu live filesystem build trying to use ubuntu-live?
<Kamion> ok, I think that's enough slang2 stuff done for d-i to basically build again once the buildds get out the other side
<Kamion> I'll upload libsdl1.2 once aalib's done
<daniels> seb128: 
<daniels> daniels@brainfreeze:~/canonical/xorg/lib/libx11% pkg-config --cflags x11
<daniels> daniels@brainfreeze:~/canonical/xorg/lib/libx11%
<ogra> Kamion, if you touch libsdl, please have a look at #11761
<seb128> $ pkg-config --cflags x11
<seb128> $
<seb128> me too :p
<daniels> i hate deadkeys
<daniels> fabbione: deadkeys are working fine now, or at least when Ie uploaded it
<daniels> argh
<daniels> ive uploaded it
<daniels> damnit
<daniels> i've uploaded it
<Kamion> ogra: that's from a different source package
<fabbione> daniels: ok.. i will upgrade later sunday...
<ogra> Kamion, ok... ijust saw it in te rdepends of slang1
<fabbione> i am close to start emptying the office in preparation for tomorrow
<daniels> deadkeys are also COMPLETE CRACK
<Kamion> ogra: that should go away with a simple rebuild, as will a lot of slang2 deps; wait a bit for the library chain to arrive
<Kamion> ogra: http://wiki.debian.net/?EtchSlang2upgrade has details; I've been making notes based on that
<ogra> Kamion, yep... i'm not in a hurry, we have enough other transitions going on in MOTUland
<ogra> ok... putting into #ubuntu-motu topic
<Kamion> I really only care that d-i keeps building, but doing aalib and libsdl1.2 as well 'cos they're in a confused state
<daniels> wow
<daniels> speaking of crack, german kezboards
<daniels> pitti: ive fixed zour german thingz
<daniels> when i press ralt and q i get @
<pitti_> daniels: \o/ :-)
<pitti_> sounds right
<daniels> wheres the plus kez on this thing_
<daniels> setxkbmap is broken
<daniels> so i need to write xkb lazouts bz hand to xkbcomp to get out of this godforsaken mess
<siretart> daniels: left of enter
<pitti> daniels: two keys to the left of P
<daniels> thanks
<daniels> pitti: ps right
<pitti> daniels: so you get the setxkbmap segfault, too?
<ogra> daniels, learn tzping man !
<ogra> :)
<daniels> ah, much better :)
<pitti> hhhhh
<daniels> pitti: not the segfault, it's just that the server can't seem to invoke xkbcomp
<daniels> either that or I'm missing my compiled directory
<\sh> i thought I smoke crack all the time...
<pitti> daniels: I installed hoary for the moment :-) but I'll dist-upgrade my breezy later today
<daniels> aha
<daniels> daniels@brainfreeze:~% setxkbmap -layout de
<daniels> daniels@brainfreeze:~% setxkbmap -layout us
<daniels> daniels@brainfreeze:~%
<\sh> daniels: u mean, after zour upload mz germanz kezboard is working again?
<daniels> \sh: yeah.  i'll post a set of instructions on ubuntu-devel on how to make X work again.
<\sh> daniels: u ruly
<\sh> +e even ,-)
<Kamion> mdz: ok to promote slang2 to main? since it's just a new upstream I imagine it doesn't need a main inclusion report
<mdz> Kamion: yes
<Kamion> ok, done; I left slsh alone, not sure anything uses that
<CarlFK> due to bandwidth and no blank cd's, I am trying to use a thumb drive as a little apt-get repository - I have the .deb's - is there a command/guid for what I need to do to create Packages.gz and whatever else is needed?
<CarlFK> https://www.bioinformatics.uwaterloo.ca/~tvinar/wiki/index.php?DebianLinuxPackaging
<\sh> https://wiki.ubuntu.com/LocalAptGetRepositories
<\sh> something like this?
<CarlFK> yeah - thanks
<CarlFK> that page seems overly complicated
<mdz> daniels: hey, no fair, you have setxkbmap??
<\sh> i don't know...I wrote this page ;9i
<\sh> for me it's totally clear and easy ;)
<CarlFK> i know how that goes... 
<infinity> daniels : Do I have my _XOPEN fixes?
<CarlFK> doesn't help that I don't know what is needed yet, so let me look this over and I'll figure out what I am talking about 
<daniels> infinity: yes
<daniels> mdz: yeah, I'm cheating
<Amaranth> cheater!
<daniels> mdz: i'm smart, and haven't upgraded my xbase-clients or xutils :)
<infinity> daniels : \o/
<Amaranth> gah
<daniels> infinity: x11proto-core and libx11 need to be the first to go
<daniels> infinity: i'm working out the dep chain for the rest
<daniels> infinity: so we can do this thing in less than six brute-force rebuild cycles :P
<infinity> Picky, picky.
<fabbione> daniels: mind to mail me the details on what orders they need to be built?
<lamont> Kamion: util-linux/slang2: want me to upload ftbfs source, or want to get libc6-dev to actually build with gcc-4.0?
<lamont> Kamion: for debian, that is.  builds fine for us
<daniels> fabbione: um, can't tell you off the top of my heads, but I can tell you I'll have strict B-Ds
<daniels> fabbione: if you build with my B-D chain, you won't be in any kind of trouble
<fabbione> daniels: so you are versioning the B-D ?
<infinity> fabbione : Yes.
<fabbione> ok
<fabbione> than i don't need to worry
<fabbione> thanks
<infinity> fabbione : He's doing it because he loves me almost as much as he loves the long island iced tea he'll get for doing so.
<fabbione> ahaha
<daniels> infinity: plus the one I'm going to get for xbase-clients.  a bonanza awaits me.
<fabbione> perfect.. i am off for one hour so.. -> unmelting brain
<infinity> I'll need to negotiate a raise.
<daniels> man, my friday night is *so* happening.
<ogra> party !
<infinity> daniels : Suck it up, tomorrow night's going to be filled with drunken shenanigans.
<thom> what are you crazy kids planning?
* ogra goes out for a dogwalk
<pitti> Hi thom
<daniels> infinity: ... maybe not so much.
<infinity> thom : I'm planning on coming through with all my bribery promises if Daniel fixes X for me, s'all.
<thom> heh, heh
* pitti grabs thom and pours a can of mozilla code over him
* thom dodges
<infinity> daniels : Ack!  <3samXXX will be <3brokenXXX
* thom then saves himself with his shield of infinite not caring
<daniels> infinity: have to travel to mum's in bendigo for some big farewell bbq she's having, and then have a 21st I have to go to sunday afternoon/evening/night; I'm going straight there from Bendigo.
<CarlFK> \sh - can we talk about building repos here or should you join #ubuntu (where the 2 that actually need this is)
<daniels> infinity: DAMNIT
<daniels> infinity: look, we're going to tgi's next friday night
<daniels> possibly before then also
<CarlFK> \sh - er, the first Q shoudl be: do you have some time?
* infinity was just there for breakfast...
<daniels> infinity: you taunt me
<Kamion> lamont: what's the libc6-dev problem?
<lamont> Kamion: Sid's /usr/include/rpc/xdr.h is ftbfs with gcc-4.0 (2.3.2-ds1-22)
<lamont> hence nfsmount fails
<lamont> it has lvalue casts in it
<Kamion> oh
<\sh> CarlFK: right now no...
<elmo> are we shipping with both oo2 and oo1 in breezy?
<TWD> elmo: isn't oo2 supposed to be put off till november? or is that just to be in sink with soN+1?
<CarlFK> \sh - no prob
<mdz> elmo: oo1 should move to universe
<\sh> CarlFK: I'm working just now on the rest of merges for breezy...and some sources needs more love then others...
<TWD> mdz: what's the status of oo2 wrt breezy?
<mdz> TWD: oo2 has been the default in breezy for months
<Kamion> although not for amd64
<ogra> sadly
<mdz> hmm, speaking of which...
<mdz> Mithrandir: ping
<pitti> jbailey: ping
<Amaranth> whew, PyXDG backend ported to the new API and it works
* Amaranth goes for coffee
<lamont> Kamion: and if there is no livecd rootfs for an arch, but there is a base rootfs, could we just flag that loudly (diff iso name?) and build a base iso?
<lamont> e.g.: breezy-live-ia64-BASE.iso ?
<lamont> otoh, when Mithrandir makes oo.o2 love amd64, it should be really close for ia64
* ogra pretends to be seb128 and writes to ubuntu-devel
<infinity> daniels : Did you miss the versioned build-dep on libxfixes?
<infinity> daniels : It got built and uploaded, rather than dep-waited on the new libx11..
<daniels> aFL:K#$#@R@#$OJU*@#$@#$
<daniels> can you influence the outcome of libx{damage,composite}?
<daniels> if they can be held until such a time as a new new libxfixes is in the archive, it'd be a great help
<infinity> Yup.  I think.  if I'm fast enough.  'Sec.
<daniels> they should be d-w on new libx11-dev and libxext-dev (which is itself d-w on new libx11-dev) anyway
<infinity> So, if I just make xext dep-wait on the new xfixes, we're set.
<daniels> but xfixes needs to itself be d-w on the new xext
<daniels> make libxdamage and libxcomposite d-w on libxfixes n
<daniels> where n is the next revision from whatever it is that I just uploaded
<elmo> WTF?!?!
<elmo> how did sparc beat powerpc?
<elmo> fabbione: did you cheat? :P
<daniels> infinity: 1:3.0.0-3
<daniels> infinity: which is now uploaded
* dilinger laughs
<infinity> You got lucky.
<fabbione> elmo: ccache++
<infinity> xdamage was built on 3 of 4 arches, but not uploaded yet.  Deleted the binaries.
<infinity> Incidentally, I think that proves that it didn't have a proper build-dep on xext-dev, if you say it should have...
<fabbione> elmo: i told you had to build the same way as buildd do before upload..
<fabbione> elmo: so i just did sbuildded it twice in a raw = ccache is the winner
<daniels> infinity: oh, right
<daniels> infinity: libxdamage is one of the thpethul ones that doesn't use libXext
<daniels> infinity: what about libxcomposite?
<lool> Hi.  Is there anything I should initiate right now for the inclusion of a package in Ubuntu that I'm preparing for Debian?
<infinity> daniels : You didn't upload composite...
<fabbione> elmo: ain't my fault that ppc without ccache is slow
<ogra> lool, #ubuntu-motu is the right place :)
<elmo> fabbione: I know, just kidding dude
<lool> ogra: okay, thanks.
<fabbione> elmo: eheheh
<fabbione> elmo: it's a weird feeling.. isn't it :P
<lool> 16:57 -!- Cannot join to channel #ubuntu-motu (You have joined to too many 
<lool> channels
<lool> damn
* Amaranth giggles
<daniels> infinity: err. 
<Amaranth> /part #debian ;)
<daniels> infinity: ... yes I did.
<infinity> daniels : breezy-changes and wanna-build are both pointing at you and screaming "LIAR!"
<daniels> infinity: my inbox says it's you that's lying
<infinity> daniels : ACCEPTED?
<infinity> daniels : 1:0.2.0-3, I assume?
* infinity does an end-run around lying software.
<daniels> infinity: yeah, that
<daniels> infinity: see?  right all along.
<pitti> brb
<pitti> oh, btw, daniels 
<pitti> daniels: when you said "you fixed the keyboard", does this mean that a mere dist-upgrade heals everything?
<daniels> yeah?
<pitti> cool
<pitti> I have to boot into breezy anyway
<pitti> brb
<daniels> oh
<daniels> not yet
<daniels> shit
<Amaranth> hahaha
<daniels> maybe cvd was right int elling me I should go to bed
<Amaranth> that's ok, i broke pitti's X yesterday
<daniels> cool
<daniels> share the love
<Amaranth> what the shit, my X still works
<Amaranth> gdmflexiserver does, anyway
<daniels> Amaranth: i'll have to take care of that, then
<Amaranth> haha
<Amaranth> so, does this mean i'm the only one fully upgraded that has a working X? :)
<daniels> yeah, probably, given I'm not fully upgraded
<Amaranth> you don't count
<Amaranth> you cheat
<Kamion> fabbione: shall I do linux-meta?
<fabbione> Kamion: yes please..
<fabbione> i just started dismounting the office for the planned we operations
<Kamion> fabbione: done
<fabbione> Kamion: thanks
<pitti_> daniels: still no luck, btw
<Kamion> fabbione: whereabouts is aalib in sparc's queue?
<Kamion> and slang2, for that matter
<daniels> pitti: yeah
<daniels> 16:03 < daniels> oh
<daniels> 16:03 -!- pitti [~pitti@195.227.105.180]  has quit [Remote closed the connection] 
<daniels> 16:03 < daniels> not yet
<daniels> 16:03 < daniels> shit
<Kamion> fabbione: please dep-wait libsdl1.2 on libaa1-dev (>= 1.4p5-28ubuntu3); it needs to not build with ubuntu2
<daniels> pitti: i meant I've fixed it over here, but it's not all been uploaded
<pitti> daniels: ah, ok :-)
<pitti> daniels: I'm back in hoary for the mozilla stuff anyway
<fabbione> Kamion: done thanks
<pitti> Kamion: btw, the hoary-amd64 installer did not create a grub entry for my i386/breezy partition - already fixed or shall I file a report?
<Kamion> pitti: hmm, curious, please file that; component grub-installer for now, although it may well be os-prober
<fabbione> Kamion: sparc is on a round of hoary-security
<fabbione> not sure about the breezy queue...
<fabbione> Kamion: has libsdl1.2 been uploaded?
<lamont> checking for SXPM... configure: creating ./config.status
<lamont> config.status: creating Makefile
<lamont> hrm.. now what's wrong with that picture, I wonder?
<fabbione> lamont: checking for SXPM... configure: creating ./config.status <- one line
<fabbione> something wrong in detecting SXPM?
<Kamion> fabbione: just doing so now
<daniels> lamont: it's just a simple missing echo
<fabbione> Kamion: ok.. in what version?
<daniels> lamont: let me guess -- you're trying to build -1 or -2 or whatever
<Kamion> (1.2.7+1.2.8cvs20041007-5.3ubuntu1)
<lamont> daniels: well....
<daniels> the one I didn't upload about half an hour ago
<fabbione> ok thanks
<lamont> -3
<daniels> lamont: i.e. without libxt-dev installed
<daniels> hmm
<lamont> dh_install --sourcedir=debian/tmp
<lamont> cp: cannot stat `debian/tmp//usr/bin/sxpm': No such file or directory
<lamont> dh_install: command returned error code 256
<lamont> that's where the error manifests itself
<daniels> oh.
<daniels> s m r t.
<daniels> yeah, I solved that in -3
<daniels> and now I will re-solve it in -4
<lamont> dude... that's -3... :)
<Kamion> s m r t?
<lamont> "see me re-tard"?
<daniels> er
<daniels> re-solve it in -5
<daniels> since libxext-dev doesn't get installed by libxt-dev
<daniels> Kamion: simpsons, i think.  someone going 'because i'm s-m-r-t smart'
<Kamion> aha
* lamont screams.
<infinity> It's a Homer quote, yes.
<lamont> kdelibs is d-w dbus which is d-w kdelibs.  gonna have to bootstrap the bastard
<daniels> look, I just threw libxpm -5 at the archive
<daniels> anything further is infinity's problem
<Amaranth> did it bounce off?
<infinity> Lucky me.
<lamont> right.  /me -> office
<daniels> oh christ
<daniels> another, completely different, DEC licence
<daniels> this one's really stupid
<daniels> but entirely DFSG-free
<Amaranth> damn, how many different licenses does X have?
<infinity> Anything like the "do whatever the fuck you want with this" license?
<lamont-away> Applying patch debian/patches/037_check-var ... failed! (check
<lamont-away> yeah krb4
<dverzolla> Hi, I want port the openoffice of Ubuntu-hoary to my default language (pt_BR). I find openoffice in the /pool/main/o/ directory. If I change the .deb's from default openoffice to my openoffice version this will work? My idea are do a CD for some students with total pt_BR support.
<daniels> there you go
<daniels> as a special bonus extra, I just uploaded xkbutils
<daniels> which features random crappy useless xkb utilities
<daniels> and xkbcomp and setxkbmap
<daniels> cheers
<lool> fabbione: ping?
<Amaranth> daniels: i love you
<daniels> i love me too
<siretart> :)
<thom> ... every night?
* Amaranth gags
<daniels> thom: watch it
<fabbione> lool: pong?
<infinity> Kamion : Does this mean I should take the sdl/aalib/slang stuff off my TODO for the evening? :0
<infinity> Kamion : Looks like you've taken it well in hand.  (when you're ready to retry all the transient deps that are FTBFS due to said transition, let me know)
<\sh> guys...whoever fixed firefox :) I bless you :)
<pitti> \sh: the font issue?
<dverzolla> I'm doing a Ubuntu-version for some students of my company. And I need to change the openoffice that come with hoary version, to openoffice.org.br (Brazilian Version). I want to know if I just change the packets in the /pool/main/o directorys will work in the installation. Or have some install-script that need to be changed too? 
<\sh> pitti: yes
<daniels> pitti: here's the deal
<daniels> pitti: if you have the latest xlibs and the latest xkeyboard-config, and coming from hoary, things should Just Work
<daniels> pitti: if files in xkeyboard-config are not installed, run dpkg -i --force-confmiss over it, but that should only happen with breezy->breezy upgrades, not hoary->breezy
<pitti> daniels: that sounds good. In the last weeks I hacked up my X installation so much, I don't remember any more what I changed anyway
<daniels> pitti: then make sure you have xkbutils installed, when it passes NEW
<daniels> pitti: and make sure you have libx11 1:6.2.1+cvs.20050722-1
<daniels> pitti: and you should have your stupid keyboard working
<pitti> daniels: I think I'll just install the next colony CD
<daniels> heh
* daniels vanishes.
<pitti> night daniels, and thanks
<\sh> cu daniels
<Kamion> infinity: basically I just wanted to get the core of it over and done with as fast as possible so that d-i was buildable again on the other side
<Kamion> (currently refreshing my mirror so that I can test that)
<infinity> Kamion : Fair enough.  I don't generally complain when someone else steals items from my TODO.
<Masoud> Hello
<Kamion> infinity: so the guts are done, but I don't want to spend much more time on the rest, so if you could take over chasing down stuff that needs to be retried and such, I'd be very grateful ...
<infinity> Kamion : No problem.
<infinity> Kamion : I was shocked to see anyone doing anything about it, TBH. :0
<\sh> guys...nice evening / day /morning /afternoon ... i have an appointment with some nice bottles of beer ;) cu tomorrow
<mdz> highvoltage: did you have a chance to test ThinClientHowto yet?  I'm desperate for feedback
<CarlFK> mdz - even my feedback?
<CarlFK> ;)
<mdz> CarlFK: any and all feedback
<CarlFK> point me somewhere and I'll give it a spin
<ogra> CarlFK, http://wiki.ubuntu.com/ThinClientHowto
<CarlFK> thaks
<ogra> CarlFK, needs breezy and its ltsp package 
<CarlFK> orga - I have all the requirements - espicaly the "sense of adventure"
<dilinger> hrm, so the upstream firefox 1.0.6 release broke the abi/api for extensions?
<ogra> dilinger, yes :(
<dilinger> lovely
<ogra> CarlFK, hehe, go ahead then, test extensively ;)
<Amaranth> wth
<Amaranth> 1.0.6 was released to fix an abi/api break that was on 1.0.5
<pitti> Amaranth: yes, but still 1.0.6 breaks with some extensions (like mozilla-tabextension)
<CarlFK> ogra - that same nuttiness lead me to make this page https://wiki.ubuntu.com/LocalNetInstall
<pitti> dilinger: I'll try to put some 1.0.6 patches on top of the current ones to improve it a bit
<Amaranth> anyone file a bug in b.m.o?
<ogra> CarlFK, cool !
<ogra> CarlFK, but isnt that covered by kickstart ? 
* dilinger is reminded of a certain php4 release that did similar things
<CarlFK> orga or mdz - given that  /opt/ltsp wont exist before "...install ltsp-server", shouldn't the install come first?
<dilinger> pitti: does upstream plan to release 1.0.7 to fix it, or are they leaving it to distributors to fix?
<pitti> dilinger: I'm not aware of any pending upgrade, but I didn't actually ask for it
<TWD> dilinger: does upstream even know about the problem?
<dilinger> TWD: you're asking me? :)
<dilinger> i don't use firefox, but some of my coworkers were whining about it
<TWD> dilinger: I use firefox on XP @ work, haven't experianced any brackage on 1.0.6
<Kamion> infinity: er ... newt/i386 build looks hosed through no fault of the package - can you fix?
<TWD> my firefoxes @ home are all <=1.0.4 so...
<CarlFK> ogra - the LocalNetInstall thing is the only one I have seen that is 100% lan - no CD's, floppys, thumbdrives, etc.
<ogra> CarlFK, hmm, i would assume kickstart can do the same (i never tried it though)
<seb128> pitti: still working on firefox I guess?
<CarlFK> but kickstart doesn't do the dhcp/pxe stuff, so I rolled it all into one page
<pitti> seb128: I finished fixing mozilla, it has the same issues; works, but crashes with extensions
<Kamion> ogra: you need 90% of that howto to get kickstart-over-network up and running anyway
<pitti> seb128: I'll try to get the API changes from 1.0.6 on Monday, I'm too tired now
<ogra> Kamion, ah, i didnt know that... (as i said, only assumptions)
<pitti> seb128: now I fix the remaining zlib issues, then I'll look at your package
<seb128> pitti: k, let me know if you can have a shot on launchpad-integration, the code is quite small and from jamesh, should not be a lot of work to you ...
<seb128> pitti: k, thanks
<seb128> pitti: no hurry, I'm blocked by xorg b0rkages atm to build GNOME stuff
<pitti> seb128: oh, I didn't actually plan to audit the code - is there anything we need to be scared of? setuid and the like?
<seb128> pitti: no, but what are reviewing so? 
<seb128> s/are/are you/
<pitti> seb128: security and bug history, and packaging normally
<pitti> seb128: for this package it is quite pathetic
<seb128> pitti: it's 0.0, jamesh made that for the spec
<pitti> seb128: if jamesh wrote it and you packaged it, then there's not much I need to do
<CarlFK> Kamion - hi.  has the number of chars that can be passed as kernel parameters to the .. um... setup kernel? been expanded yet?  - it causes me headaches
<seb128> and I've packaged it using CDBS, I don't expect big issues
<seb128> pitti: yeah, that's why I think too
<seb128> s/why/what/ grrr
<pitti> seb128: the review is actually meant for people who want to include external security-relevant software, it doesn't really fit here anyway
<pitti> seb128: so just have it promoted then
<seb128> pitti: I've asked if we can push directly, Kamion said to pass the review process ... so here we go
<Kamion> CarlFK: yes, it was expanded in 2.6.9 so it shouldn't be causing you trouble in hoary
<pitti> seb128: ok, I take a look at it, shouldn't be much work anyway
<seb128> thanks
<Kamion> if there's no set-id code involved it shouldn't be a problem, but since it clearly talks to the network I thought it was worth checking over
<pitti> seb128: http://archive.ubuntu.com/ubuntu/pool/main/l/launchpad-integration/ -> no debs
<pitti> seb128: and it is already in main
<pitti> ??
<pitti> ah, the debs are in universe
<seb128> ups, sorry, I've filled the page while it was building
<pitti> oh, gf alert
<infinity> Kamion : Fixed.
<highvoltage> mdz: lots of things have come in the way, but i'm also eager to see how it works (sounds quite different to a normal ltsp install), so i'll try it tonight.
<pitti> seb128: I reviewed the code (wasn't that much), looks fine
<seb128> pitti: cool, thanks
<seb128> pitti: I didn't expect jamesh's code to be bad anyway :p
* pitti neither
<infinity> Kamion : Thanks for the heads-up.
<Kamion> infinity: cool, I see it in accepted now, thanks
<Kamion> that should be enough for d-i to build properly
<elmo> lamont/infinity: {hoary-cat,breezy-{auto,}test} should be up, and breezy-autotest has a test package in it; please kick the buildds to know/care at your convenience
<infinity> elmo : hoary-cat?
* infinity missed that memo.
<lamont> elmo/infinity: I'll kick them
<elmo> infinity: local suite for looocaaaal people
<lamont> infinity: admin crap
<infinity> elmo : Oh, CAT, right, brain fart.
<infinity> elmo : Why do we not have that in Debian for DSA as well?... DSA builds being done by hand is lame.
<elmo> infinity: probably should
<lamont> infinity: fwiw, -cat requires editing buildd.conf to not exclude it, -autotest requires building the chroot.  that's in progress now
<lamont> elmo: if you send me info on the upload queue for hoary-cat, I'll upload some pristene source.
<elmo> lamont: same as breezy-{auto,}test ?
<elmo> tho, hum, I wonder what keyring it's using
<lamont> elmo: was hoping for somewhere outside the DC that would accept the uploads and forward them happily along
<lamont> but that's because I'm lazy
<elmo> I could probably open port 21 to rockhopper
<elmo> I'll need to keyring-ize you
<elmo> and fix breezy-test to use the normal keyring too - meh
* lamont decides to ignore hoary-cat until breezy-*test are happily running everywhere
* lamont grabs gcc-4.0 and beats it against the wall
<lamont> time to fix the breezy.buildd file...
<lamont> Kamion: or did you already do that?
<Kamion>       base="apt binutils cpio cpp cpp-4.0 dpkg-dev g++ g++-4.0 gcc gcc-4.0 ${LIBC6}-dev libdb4.2 libgdbm3 libstdc++6-4.0-dev linux-kernel-headers make patch perl perl-modules"
<elmo> is our debootstrap using priorities yet?
<Kamion> is that right?
<Kamion> elmo: yes
<elmo> k
<lamont> Kamion: I think so...
<Kamion> elmo: although I'd still like Build-Essential: yes headers like Debian has, then the hardcoded buildd list could go away too
<Kamion> lamont: (breezy.buildd is rolled into breezy now, btw)
<fabbione> Kamion: wooo... neat d-i upload..
<fabbione>    * build/pkg-lists/cdrom/sparc.cfg: Use dependency resolution for
<fabbione>      nic-modules.
<fabbione> what does that mean?
<fabbione> (if you have time to explain)
<Kamion> most of the other pkg-lists did that already, it was just tidying up really
<fabbione> hmm ok
<server> hmm
<fabbione> Kamion: was it painful the udeb cleanup?
<Kamion> so it means that util/pkg-list will go off and fetch dependencies of nic-modules if they aren't explicitly listed, rather than going "duh, can't install that"
<lamont> Kamion: ok
<fabbione> ahh nice :)
<Kamion> fabbione: relatively straightforward, although I haven't looked at the initrd size changes yet
<server> just upgraded breezy and I got /usr/bin/startx doesn't exit :-)
<fabbione> Kamion: ok.. we will see it tomorrow i guess
<Amaranth> server: Time to downgrade. :)
<Kamion> I hope before that, I'd like to get a functional 2.6.12-4 CD set today
<server> Amaranth cool =)
<fabbione> Kamion: ok. but if they become too big there is nothing i can do till monday
<Kamion> sure
* fabbione starts dismounting the 5+1 speakers
<fabbione> i am left with one machine up only...
<lamont> Kamion: please add libstdc++6 to the package list... :-(
<lamont> right next to libstdc++5
<fabbione> lamont: and gpg
<fabbione> we need that too now in the buildd for apt auth
<Kamion> lamont: er ... no libstdc++5 there
<Kamion> lamont: adding libstdc++6, though. ack gnupg?
<Kamion> gnupg has a big wodge of dependencies which are kind of unpleasant to add
<lamont> no gnupg
<lamont> apt's management of the chroot is done outside the chroot --> gpg in the real root
<Kamion> ok
* lamont just looked and couldn't see where libstdc++5 was getting pulled in...
<lamont> but after the debootstrap fails, I have libstdc++5, but not 6.  (ppc)
<Kamion> --resolve-deps?
<lamont> on the debootstrap command?
<Kamion> beats me, though
<Kamion> yeah
* lamont tries
<Kamion> 0.3.1.4ubuntu2 should fix, anyhow
<Kamion> lamont: what's the priority of libstdc++5 on your local mirror?
<Kamion> libstdc++5 is in section 'base' at priority 'optional'
<highvoltage> will the hoary firefox package be called "mozilla-firefox" or "firefox"? I see it's currently "firefox" in breezy?
<lamont> Kamion: this is in the DC
<dieman> hmm
<dieman> firefox 1.0.6 supposedly disables all extensions
<dieman> on upgrade
<lamont> Kamion: but --resolve-deps seems to be a good thing to have anyway
<Kamion> yeah
<seb128> hum
* infinity -> bed.
<lamont> Kamion: so I depend: >=0.3.1.4ubuntu2, or just >0.3?
<lamont> for --resolve-deps that is
<seb128> what is the right seed for launchpad-integration? desktop?
<Kamion> lamont: 0.3.0
<Kamion> seb128: yes, I think so
<seb128> thanks
<Kamion> won't other things in desktop depend on it anyway though?
<seb128> yeah
<seb128> so no need to seed it?
<Kamion> nope
<seb128> k
<seb128> thanks
<Kamion> np
<fabbione> Kamion: slang2 transition is only d-i and aalib for main, right?
<Kamion> libsdl1.2 too
<fabbione> yes that one too
<Kamion> possibly a few other things, I didn't check exhaustively
<fabbione> ok
<fabbione> no i remember no more than 3
<lamont> util-linux
<Kamion> oh yes, that too
<fabbione>   slang2_2.0.4-4
<fabbione>   aalib_1.4p5-28ubuntu3
<fabbione> ok.. they are queued in the right order
<fabbione> libsdl is not even here yet
<Treenaks> fabbione: libsdl1.2debian 1.2.7+1.2.8cvs20041007-5.3ubuntu1 you mean?
<infinity> daniels : What happened to the libxt and libxpm uploads that a bunch of your other stuff seems to dep-wait on?
<fabbione> Treenaks: i am talking about sparc and my local mirror.. don't worry
<Kamion> libcaca could probably do with an upload soon too
<Treenaks> fabbione: *phew* ok :)
* fabbione goes and cook dinner
<fabbione> it's so weird to sit in an almost empty office :)
<Kamion> ah, I think libcaca is dep-wait
<Kamion> yeah, it's building against slang2 now
<Kamion> then there's some gstreamer and xine stuff, and kdeaddons
<infinity> daniels : Make that just libxt, libxpm is just waiting on that.
<Mithrandir> mdz: pong?
<Keybuk> grr @ strange 2.6.12 bug where machine dies during acpi events
<mdz> Mithrandir: wanted to talk about oo.o2-amd64
<Mithrandir> mdz: hmm, I'm on my way out the door, can we do it a bit later?
<Mithrandir> or tomorrow or something?
<Keybuk> Jul 22 12:13:37 localhost kernel: [4307811.360000]      ACPI-1172: *** Error: Method execution failed [\_TZ_.C1E8]  (Node df9c3ec0), AE_AML_PACKAGE_LIMIT
<Keybuk> Jul 22 12:13:37 localhost kernel: [4307811.360000]      ACPI-1172: *** Error: Method execution failed [\_TZ_.C1E7]  (Node df9c3ee0), AE_AML_PACKAGE_LIMIT
<Keybuk> Jul 22 12:13:37 localhost kernel: [4307811.360000]      ACPI-1172: *** Error: Method execution failed [\_TZ_.TZ2_._TMP]  (Node df9c1760), AE_AML_PACKAGE_LIMIT
<Keybuk> ^ hmm, that looks evil
<mdz> Mithrandir: soon, we're running short of time (feature freeze)
<Keybuk> Thermal Zone not-working-ness
<Treenaks> Keybuk: scary.. which manufacturer? did it work before?
<Mithrandir> mdz: hmm, I can make one, similar to ooo1-amd64
<Keybuk> Treenaks: HP, yes
<mdz> Mithrandir: right, how much time do you think it will take?
<dverzolla>  I'm burning a CD with Ubuntu-Hoary, but I need to change de default xorg.conf file that come with installation. Anyone knows how I can do this?
<Treenaks> Keybuk: Strange... but AE_AML_PACKAGE_LIMIT looks  like the kernel now has better bounds-checking or something like that?
<Keybuk> no idea
<Mithrandir> mdz: with kde and gnome support libs or just gnome?
<mdz> dverzolla: there is no default; it's created dynamically based on hardware detection
<mdz> Mithrandir: preferably both
<Keybuk> wonder whether that's related to the "SYSTEM HAS REACHED SILLY TEMPERATURE" errors that were causing people's machines to be shutdown
<mdz> Mithrandir: want to send me quotes for both scenarios?
<dverzolla> mdz: I need change a configure, because all my monitors are 17". I need put 2 lines in Monitor Section. How I can do it?
<Mithrandir> mdz: I'm starting to work full-time mid of next week, do you still need a quote? :-)
<Kamion> (hooray)
<mdz> dverzolla: please ask in a support channel, mailing list or forum
<dverzolla> support are #ubuntu?
<mdz> Mithrandir: oh, I thought it wasn't until mid-august for some reason. cool.
<mdz> dverzolla: yes, see /topic
<dverzolla> ok thanks
<Mithrandir> mdz: I think it'll take a day or so, but I'm not sure about the kde stuff, so that's an unknown factor.
<infinity> daniels : Ahh, I see, xt's upload is waiting on a libsm upload, which may or may not require a libice upload, and so on.  I'll catch up with you in the morning about it.
* infinity would like to take this moment to declare that pkgconfig is almost equally as irritating as libtool.
* infinity -> bed, for real.
<Mithrandir> infinity: how so?
<jsgotangco> man i gotta sleep too
<jsgotangco> heh
<Mithrandir> well, off.  See you around.
<infinity> Mithrandir : One define, deep in a core X header is bubbling up to everything under the sun, causing half of GNOME to FTBFS.  We're cleaning it from the ground up, which takes some dependency wrangling and very tight build-deps to make sure it's reproducibly sane.
<lamont> Kamion: fyi: I: Resolving dependencies of required packages...
<lamont> I: Resolving dependencies of base packages...
<lamont> I: Found additional required dependencies: binutils cpio cpp cpp-4.0 dpkg-dev g++ g++-4.0 gcc gcc-4.0 libc6-dev libdb4.2 libgdbm3 libstdc++6 libstdc++6-4.0-dev linux-kernel-headers make patch perl perl-modules
<Kamion> infinity: is evolution-exchange really being rebuilt? it's been in Building state for a day or so
<Kamion> sorry, that's on amd64
<infinity> Kamion : No, but that's easy to solve.
* infinity pokes it with a stick.
<Kamion> lamont: odd, most of those are there already
<Kamion> infinity: thanks
<lamont> infinity: ls build-breezy-autotest/
<lamont> chroot-breezy-autotest  ref-breezy-autotest
<lamont> Kamion: thats debootstrap --resolve-deps --include=fakeroot,build-essential, ...
<lamont> s/, / /
<Kamion> lamont: --variant=buildd?
<lamont> yea
<lamont> debootstrap --resolve-deps --arch ${arch} --include=fakeroot,build-essential --variant=buildd $rel $root $MIRROR
<lamont> to be completey truthful. :-)
<hub_> hey bradb-lunch 
<lamont> I: Base system installed successfully.
<lamont> grep: build-breezy-autotest/chroot-breezy-autotest/etc/shadow: No such file or directory
<lamont> giggle
<Kamion> I don't think the base system has ever enabled shadow ...?
<lamont> could be my script
<Kamion> there was talk of putting 'shadowconfig on' in passwd.config or passwd.postinst or something recently
<lamont> yep
<Kamion> hmm, gcc-4.0-base missing too, whoops
<lamont>     f=${root}/etc/shadow; grep -q "^${U}:" $f 2>/dev/null || echo ${U}:\*:$(getent shadow ${U} | cut -d: -f3-9) >> $f
<lamont> is what it says _now_
<Kamion> what's that supposed to do?
<lamont> clone the shadow entry for $U into the chroot
<lamont> unless he already exists there
<lamont> well, with no password
<Kamion> ah
<lamont> otherwise, you get this:
<lamont> su: Authentication service cannot retrieve authentication info.
<siretart> Does anyone know how many participants the Laptop Testing program has?
<bradb> hey hub_ :)
<hub_> siretart: how can one apply ?
<lamont> Kamion: and thanks for making me look - reminded me why I was getting that error in the user chroots I just built...
<Kamion> elmo: are you around to do d-i byhands, or shall I do it?
<elmo> I was waiting for ia64
<elmo> but I can do it now if you like
<Kamion> ah, fair enough, that's fine
<Kamion> oh, ia64 failed
<Kamion> dep-wait newer kernel I think
<Kamion> elmo: yeah, if I could have them now that'd be good, so I can do an amd64/i386/powerpc CD build
<dverzolla> Anyone knows a good developer maillist from canonical?
<elmo> Kamion: done
<Kamion> thanks
<lamont> infinity: installing new buildd-config on all the buildd's and restarting, btw
* lamont makes the assumption that infinity really went to bed
<Kamion> mdz: so, as far as I can tell, we included alsa-base in the base system in order to get hotplug blacklisting
<Kamion> mdz: however, almost all of the hotplug blacklisting functionality has moved to linux-sound-base, with the exception of three remaining entries in /etc/hotplug/blacklist.d/alsa-base that aren't shipped in our kernels anyway
<Kamion> mdz: alsa-base pulls in alsa-utils, which is pretty big for minimal (1MB), and also libasound2 (300KB or so). Can I move it to standard and just leave linux-sound-base in minimal?
<lamont> I want an option to apt that says 'and mark _everything_ new you install as pending-purge
<Kamion> mdz: hmm, although I'm not sure whether installing alsa-base will be enough to load modules listed in /etc/modprobe.d/alsa-base
<Kamion> that's annoying, 1.5MB of stuff just for some modprobes
<doko> daniels: regarding 10946, are the .png icons still be built from the xorg source?
<Kamion> ah, that explains why fresh installs are utterly broken - missing mkfontdir => X can't find fixed font => falls over
<doko> elmo: please could you update the breezy-ppc64 chroot, install davis:~doko/gcc/snap/gcc-snapshot_20050722-2_powerpc.deb, and libpng3's and xorg's build-deps?
<doko> mdz: can you investigate the grave rrdtool bug reports, or should somebody else do this? needed for sensord and python-rrdtool
<mdz> Kamion: yes, I believe that was the rationale (hotplug blacklisting)
<mdz> Kamion: is the modprobe stuff actually required?
<mdz> Kamion: its only purpose seems to be to run /etc/init.d/alsa start when a card is detected
<Kamion> mdz: that does stuff like setting default levels, which I guess we want
<mdz> Kamion: our strategy for base had been that it should include hardware detection bits
<Kamion> god, this is such a twisty little maze of scripts
<mdz> Kamion: but perhaps we should split that into "minimal hardware detection bits" and "standard hardware detection bits"
<Kamion> well, the relevant distinction for me is that standard is installed after the first reboot
<Kamion> also, base == minimal + standard, so ...
<Kamion> how come alsa-base.postinst doesn't run /etc/init.d/alsa-base start?
<Kamion> if it did that, it could equally well be installed before or after the first reboot, I think
<highvoltage> mdz: any way to make ltsp-build-client more verbose?
<highvoltage> it's really boring on slow connections ;)
<mdz> highvoltage: it should be possible to use a CD to bootstrap it
<mdz> (a breezy CD, of course)
<surfdue> wow
<surfdue> fancy
<surfdue> is there is UBUNTU witha K gets developed?
<surfdue> sweeet
<highvoltage> surfdue: who are you talking to?
<highvoltage> and what are you actually asking? perhaps you want #ubuntu?
<tseng> #kubuntu, rather.
<highvoltage> ah, ok. now the question makes more sense :)
<surfdue> nah
<surfdue> i want to watch development
<surfdue> is there where you watch it?
<Riddell> surfdue: myscreen.org/riddell
<tseng> Riddell: hardcore
<surfdue> im sorry is there where i watch ubuntu development
<surfdue> it would be correct?
<highvoltage> watch -n 0 #ubuntu-devel ?
<surfdue> hey do you sell popcorn?
<surfdue> its getting very intersting
<highvoltage> surfdue: what is your first language?
<surfdue> and may i ask, how can X be broken?
<surfdue> chinese
<surfdue> chow ming, 
<tseng> support questions are in #ubuntu please.
<highvoltage> surfdue: rm -Rf /etc/X11/xorg.conf
<surfdue> nah :D
<surfdue> id rather not
<surfdue> it may mess up my chee
<tseng> highvoltage: i dont think that would break it very hard
<surfdue> wha what highvoltage ?
<surfdue> how doi do that
<highvoltage> tseng: enough to get rid of surfdue 
<surfdue> can u say it in chinese i dont speak english
<lamont> make[4] : Entering directory `/build/buildd/firefox-1.0.6/security/nss/cmd/lib'
<lamont> Creating ../../../../dist/public/seccmd
<lamont> /bin/sh: ../../../coreconf/nsinstall/Linux2.6_hppa_glibc_PTH_OPT.OBJ/nsinstall: No such file or directory
<lamont> yea firefox!
<surfdue> im not on ubuntu
<surfdue> im on windows
<surfdue> ubuntu is on my desktop
<surfdue> im on my laptop
<smurfix> lamont: looks like you're having fun
<surfdue> highvoltage,  do you know what a henway is?
<tseng> surfdue: please direct support questions to #ubuntu, and leave chatter out of -devel
<lamont> smurfix: just trying to build stuff
<lamont> surfdue: last warning.
<surfdue> ok
<surfdue> im sorry sir
<surfdue> or madam
<surfdue> ill leave now i gess
<surfdue> um on xchat where is the close cutton?
<surfdue> hehe i cant find it
<surfdue> :|
<surfdue> u should just kick me
* lamont helps
<surfdue> i think it will work
<surfdue> ty in advanced
<surfdue> hehe where is the popcord again?
<lamont> btw, the X in the top left
* mode/#ubuntu-devel [+o lamont]  by ChanServ
* mode/#ubuntu-devel [-o lamont]  by lamont
<lamont> hrm.. now where was that auto-identify howto hiding?
<tseng> irssi?
<tseng> nope, sorry.
<lamont> xchat
<lamont> google to the rescue
<elmo> doko: breezy-ppc64 is obsolete?
<doko> yes, I did want an install of a hand-built gcc-snapshot and libpng3 in the chroot, so I think it's better not to use the standard chroot?
<elmo> oh, ok, meh
<herve> hello
<herve> could we sync devscript from debian?
<herve> ouch, have seen the ftbfs on some archs
<elmo> doko: should be done
<doko> elmo: thanks
<seb128> elmo: can you move "launchpad-integration liblaunchpad-integration0 liblaunchpad-integration-dev" to main? It has been approved by pitti
<elmo> is it seeded or depeneded on by something?
<doko> elmo: last install for today in the breezy-ppc64 chroot: davis:~doko/png/libpng12*deb and the build-deps for linux-source-2.6.12 and xcursorgen
<herve> guys, just to be sure, I can upload packages to universe when a bug for merging was open?
<elmo> doko: done
<elmo> seb128: ?
<siretart> herve: sure!
<herve> siretart, hehe :-)
<seb128> elmo: it's going to be a depends for other packages ... should I upload (which will go to a FTBFS) before moving it?
<elmo> seb128: I've moved it, but if it shows up in my to-demote list, I'll send the gtk-bug poliz after you :p
<dilinger> mm. xorg and firefox are driving my load up to 6
<elmo> OPERATION BREEZY-AUTOTEST IS AT MAXIMUM THROTTLE.  THAT IS ALL.
* Mez lols at elmo
* Mez wonders how backports are going
<lamont> Mez: they're totally dead in the water until breezy-autotest catches up.
<lamont> since autotest gets priority over backports on the buildds
<Mez> ah
<Mez> :P
<doko> elmo: you're going to test-compile the archive?
<elmo> lamont: oh, it does?
<elmo> err, we should fix that
<lamont> elmo: it does
<elmo> knocking backports off for a week is harsh
<lamont> # The order is as follows (as present):
<lamont> #  *-security
<lamont> #  *-updates
<lamont> #  ${current} == development release
<lamont> #  *-cat
<lamont> #  *-test
<lamont> #  *-autotest
<lamont> #  *-backports
<elmo> can we reverse the last two?
<elmo> sorry, I know I oked that list, but I was wrong
<elmo> it doesn't have to be all buildds, just one per arch will do for now
<lamont> yeah - I'll give backports at least one per arch
<Mez> elmo, have you poked anything to build for backports yet (and have you gotten rid of dpkg from them!)
<elmo> mez: killed dpkg yes
<Mez> but not poked anything yet :D (even with my MASSIVE list :P)
<elmo> will do the others in a bit, sorry, really had to get breezy-at started
<Mez> elmo, no worrys
<Mez> just poke me when they're started, so i can publiceise the new apt sources
<elmo> ok
<Mez> o_O
<Mez> I'm getting major issues on security.ubuntu.com
<lamont> -backports gets priority on the left hand column. (rothera, floe, adare, crested)
<elmo> merci
<lamont> bitte
<lamont> :-)
<Mez> Err http://security.ubuntu.com hoary-security/restricted Packages
<Mez>   This HTTP server has broken range support [IP: 82.211.81.151 80] 
<Mez> w00t :D 
* terrex se va a cenar // is going to dinner
<mdz> jbailey: ping?
<Mez> wtf @ backports.archive.ubuntu.com
<elmo> mez: that sounds like a broken transparent proxy
<Mez> huh ?
<elmo> 22:13 < Mez>   This HTTP server has broken range support [IP: 82.211.81.151 80] 
<elmo> ^-- that
<Mez> oh... lol :D I dont use a proxy elmo :d
<elmo> that's why I said transparent ...
<Mez> oh lol
<elmo> ISPs often proxy port 80 traffic without your knowledge/consent
<Mez> didnt see that
<Mez> elmo, all the others work fine though
<elmo> all the other what?
<Mez> servers
<elmo> archive.ubuntu.com == security.ubuntu.com
<Mez> lol
<elmo> security changes more frequently, so it's likely you're just seing the problem there because it's actually changed
<Mez> that's annoying
<Mez> http://siretart.tauware.de/revu/details.py?upid=164
<Mez> grr
<Mez> Failed to fetch http://archive.ubuntu.com/ubuntu/dists/hoary-backports/Release.gpg  Bad header line [IP: 82.211.81.138 80] 
<siretart> Mez: try using a proxy
<Mez> lol, to be fair though - it's weird
<Mez> I'm getting some hits on security.u.c but some errors
<Mez> Ign http://security.ubuntu.com hoary-security/restricted Packages
<Mez> Hit http://security.ubuntu.com hoary-security/universe Packages
<Mez> Err http://security.ubuntu.com hoary-security/restricted Packages
<Mez>   This HTTP server has broken range support [IP: 82.211.81.151 80] 
<siretart> Mez: try using a proxy
<Mez> siretart, I cant be arsed to find one
<Mez> hmm,
* Mez is still scared from WH Smith's marketing
<Amaranth> shit
<Amaranth> i lost my hoary CD and i'm out of blanks
<Amaranth> so i really am stuck on windows
<xhaker> you? this must be a dream
<xhaker> lol
<Amaranth> my linux HD crashed
<Amaranth> overheated during a fsck
<xhaker> i know.. the 17 error in grub and al
<xhaker> all
<Amaranth> yeah
<xhaker> you shoudl have some cdrw in there
<xhaker> rewritable media i mean
<Amaranth> i guess this means smeg 0.8 is on hold indefinitely
<xhaker> is it really that hard to get media 
<Amaranth> when i have zero money, yes
<xhaker> can your pc boot from usbdisks?
<Amaranth> don't have one :P
<xhaker> pen drive
<xhaker> :P
<xhaker> me neither
<xhaker> i'm out of options
<xhaker> or should i say.. you're out of options
<xhaker> luis_, are you portuguese?
<luis_> no
<luis_> sorry
<xhaker> your name is
<luis_> name is cuban/spaniard, technically
<xhaker> Amaranth, you can always try your neighbours..
<Amaranth> ha
<Amaranth> i've never met them
<xhaker> so today is a good day to meet them
* Burgundavia was about to say that
<xhaker> :P
<xhaker> "Hi, i'm your neighbour from upstairs. I run out of blank media."
<hub_> Amaranth: just order some ubuntu cds from the website
<xhaker> hub_, i think he would like to have it before october
<xhaker> lol
<hub_> xhaker: can't get Warty anymore ?
<Amaranth> hub_: ha, i've had those on order since before hoary shipped
<Amaranth> s/shipped/released/
<hub_> Amaranth: can you wait a few days ?
<mdke> i know this is OT but is anyone available to help me debug why a cronjob is not working on our docteam linode server?
<hub_> Amaranth: 'cause I can ship you one if want. a burnt one
<Amaranth> hub_: i can wait however long it takes :)
<hub_> Amaranth: mail your snail mail to hub@figuiere.net
<xhaker> Amaranth, i received mine, took awhile but i got them. all the way to Portugal
<hub_> Amaranth: I'll send you a hoary
<hub_> Amaranth: tell me wish arch you want
<hub_> which
<Amaranth> hub_: x86
<hub_> k
<Amaranth> colony 2, if you could
<hub_> okay
<hub_> put that in the mail
<hub_> I'll just download and burn
<hub_> and send it to you by snail mail
<xhaker> communities rock
<xhaker> lol
<hub_> you want the install, right ?
<xhaker> yes.. he wants the install media
<hub_> just to make sure :-)
<xhaker> :)
#ubuntu-devel 2005-07-28
<Keybuk> ok, how does one install mozilla extensions ?!
<hub_> I don't find Colony
<hub_> am I blind ?
<hub_> found it
<hub_> Amaranth: given the time, it won't be mailed before monday
<Amaranth> hub_: i don't need it anymore, thanks anyway
<hub_> Amaranth: okay. good
<Amaranth> i called someone, they'll have it to me on sunday
<Amaranth> i just hope i don't lose /home
<Amaranth> i don't have another copy of smeg 0.8 anywhere
<hub_> :-/
<Amaranth> oh shit, i don't have another copy of my work on pymusique anywhere either
<Amaranth> jlje reminded me :/
<xhaker> i was going to make room to install in another partition hoary server install
<xhaker> i'm starting to think i will b0rk my stuff
<xhaker> i did it once and Amaranth is not really helping 
<xhaker> lol
<Amaranth> heh
* Amaranth will upload everything to his server the second it's working again
<Amaranth> if it works again
* lamont ->home
<Gnobody> hey
<Gnobody> is X *still* broken?
<lamont-away> Gnobody: you have reminded me of one of my favorite answers
<lamont> "yes, signals are broken.  But not that way."
<lamont> I think it generally applies to X as well.
<Gnobody> damn
<lamont> as for whether or not X is sane again, I couldn't say.  But that's a #ubuntu question
<daniels> doko: nope
<daniels> errr
<daniels> infinity: libxt b-ds on libsm >= 1:6.0.4-2, and -3 is in the archive
<daniels> infinity: right, I see what happened now.
* bddebian thinks daniels is talking to himself
<CarlFK> hey daniels
<CarlFK> you do anything with preseed files?
<daniels> CarlFK: nope, sorry
<CarlFK> no prob
<zwnj> where i can find a package building (from scratch) manual from?
<bddebian> zwnj: The Debian New Maintainers Guide
<zwnj> seems building debian packages is harder that rpm
<bddebian> Nah
<zwnj> bddebian: thanks :)
<bddebian> Anyone know what is up with debdiff all of the sudden???
<fabbione> mornign
<bddebian> Morning fabbione 
<trulux> heya guys
<trulux> fabbione: morning
<bddebian> Hello trulux 
<trulux> bddebian: hi :)
<trulux> anyone knows the time when Jane joins the channel?
<bddebian> Not me sorry
<Burgundavia> trulux, she is UTC or UTC+1
<trulux> Burgundavia: many thanks, I just need to show some more stuff to pitti and her
<davyd> daniels: not to sound like a naggy mc nag nag, but what is holding linux-restricted-modules back?
<fabbione> davyd: a few things..
<fabbione> it will be around soon again
<fabbione> 2.6.12 prior the last upload was not exactly stable
<fabbione> and adding more instability due to binary driver was going to be only an extra mess for me to get stuff fixed
<davyd> so -4 is the go?
<fabbione> davyd: it did close a lot of bug...
<davyd> rock and roll
<davyd> does it look like the home stretch now?
<fabbione> i might have to break it again to get some ipw2x00 extra love, but i can do it outside the archive to test
<davyd> or is there a heck of a lot of work remaining?
<fabbione> it's half way
<fabbione> in theory there is a lot of packaging work
<fabbione> but the code seems to be pretty stable
<fabbione> and in the beginning i had to focus on that
<fabbione> (reason why l-r-m isn't around yet)
<fabbione> + we had slightly less time than usual to work on l-r-m due to C++ and X transitions all together
<fabbione> that clearly are higher priority
<fabbione> (if X doesn't work.. you can play pingpong with l-r-m ;))
<daniels> yeah, it's just been full-on, and l-r-m hasn't been on my radar due to not being 'urgent holy shit needed last week'
* davyd nods
<davyd> I don't mind rebuilding the nvidia packages as required, I was mostly wondering if it was a time problem or a technical problem
<davyd> I get the impression it's been a time problem
<davyd> incidently, "libsexy" now has a spellchecking entry widget
<davyd> I wonder how that would look in X-Chat
<fabbione> davyd: it's both actually..
<fabbione> because X is removing /usr/X11R6
<fabbione> or anyway killing part of it
<fabbione> that reflects on nvidia and ATI too
<fabbione> the gcc transition made impossible to build them
<fabbione> + the time
<davyd> ok, I didn't notice that compiling nvidia-glx, but ok
<davyd> is it going to break with -43?
<fabbione> but given that main needs to be stabilized first to build l-r-m properly...
<fabbione> i dunno...
<fabbione> i didn't upgrade X for a while
<davyd> I guess I'll find out the hard way
<fabbione> (btw i do compile nvidia myself too...)
<fabbione> but to have a stable desktop to work on the kernel i had to stop upgrading X
<fabbione> so i dunno
<davyd> I picked the wrong day originally to install breezy on my new machine
<davyd> and it took until X -43 to get Xv working on my laptop
<daniels> well, to be fair, that bug was present in warty and hoary also
<davyd> yes
<davyd> but that's why I took to upgrading X
<daniels> lamont: ... which headers disappeared from dbus, exactly?
<lamont> daniels: <sys/signal.h>
<lamont> fd_set et al
* lamont needs to file the bug
<lamont> pretty sure I called it dbus-signal.patch
<lamont> and -ubuntu6 had the arch spec on mono-mcs
<daniels> so you added some missing #includes
<lamont> I added one missing include
<lamont> and all was right with the world again
<lamont> clearly it included something that _used_to_ include sys/signal.h
<lamont> http://people.ubuntu.com/~lamont/buildLogs/Test/byDate/today.html
<lamont> enjoy the pain that is breezy-autotest, folks
<lamont>  interesting, amd64 is kicking butt
<daniels> heh
<lamont> buildLogs/Test/Lists/breezy-autotest.all.amd64:Total 159 package(s) in state Installed.
<lamont> buildLogs/Test/Lists/breezy-autotest.all.i386:Total 97 package(s) in state Installed.
<lamont> buildLogs/Test/Lists/breezy-autotest.all.ia64:Total 53 package(s) in state Installed.
<lamont> buildLogs/Test/Lists/breezy-autotest.all.powerpc:Total 96 package(s) in state Installed.
<lamont> hrm... maybe that was semi-spewage
<fabbione> does the latest kdelibs fix the uninstallable problem?
<fabbione> or do we need to do some kind of magic?
<lamont> still no clue... dbus was blocking kdelibs for me
<lamont> but that's built now.  cool
<fabbione> it's the other way around for me..
<fabbione> dbus can't build because of kdelibs..
<daniels> fabbione: yeah, you need to break the loop there
<fabbione> daniels: how?
<bob2> autotest = randomly rebuild already built source packages?
<fabbione> daniels: or better.. in what order?
<lamont> bob2: use the debs from breezy, and a snapshot of the source from same.  build, and then throw away (well, notreally, but effectively) the resulting debs
<bob2> ah, neat
<daniels> fabbione: i assume disable dbus support in kdelibs, build dbus off that, and rebuild kdelibs off dbus
<daniels> that's if you're bootstrapping
<lamont> daniels: or find an older, installable kdelibs
<daniels> right
<fabbione> hmmmm
<fabbione> ok
<fabbione> giving the morgue is broken, it's going to be difficult
<lamont> my issue right now is that it still isn't installable, since libopenexr-dev isn't available from breezy
<lamont> daniels: anything wrong with this list for an xorg-split kind of world??  autotools-dev cdbs debhelper libfltk1.1-dev xlibmesa-gl-dev xlibmesa-glu-dev
<daniels> lamont: xlibmesa-gl-dev | libgl-dev, libglu1-xorg-dev | libglu-dev
<lamont> ok
<lamont> that's openexr, fwiw
<daniels> must, must provide alternatives
* lamont goes to bed
<fabbione> night lamont
<daniels> night dude
<lamont> daniels: and feel free to look at all the missing X* symbols in imlib2 if you're really looking for something to distract you from xorg proper. :)
<daniels> ot
<daniels> er
<daniels> it's saturday
<daniels> lamont: example build log though?
<fabbione> 
<herve> hello
<herve> who can I see for bugzilla rights?
* #ubuntu-devel  [freenode-info]  why register and identify?  your IRC nick is how people know you.  http://freenode.net/faq.shtml#nicksetup
<Mithrandir> is the morgue broken?
<fabbione> Mithrandir: yes.
<fabbione> i told elmo already
<highvoltage> the morgue?
<fabbione> Mithrandir: are you going to be around monday?
<Nafallo> highvoltage: morgue.ubuntu.com
<Mithrandir> fabbione: sure
<fabbione> Mithrandir: we need to talk about Xen, but not now. i am moving al the stuff around the office today and reconfiguring tomorrow
<fabbione> Mithrandir: i am on a 80x24 12" monitor atm :)
<fabbione> and can't really do much
<Mithrandir> fabbione: heh, ok.
<fabbione> ok.. i am offline again.. time to switch my ws to 3x21" :)
<fabbione> i wonder what resolution can handle the Sun monitor...
<siretart> I'd like to have piuparts from unstable included in ubuntu. it seems useful for doing qa of packages. who do I need to ask?
<siretart> in universe, that is
<ogra> Mithrandir, there obviously is no limit on 65000 files in a ext3 directory ;) 
<ogra> Mithrandir, (as you told me)
<ogra> see http://hwdb.ubuntu.com/
<tseng> siretart: email elmo to sync it
<tseng> it would be nice if pbuilder could do the same things
<tseng> or piuparts use the pbuilder chroot
<bob2> (sbuild)
<Mithrandir> heh:
<Mithrandir> find: WARNING: Hard link count is wrong for .: this may be a bug in your filesystem driver.  Automatically turning on find's -noleaf option.  Earlier results may have failed to include directories that should have been searched.
<seb128> hi
<seb128> daniels: around?
<siretart> tseng: piuparts can use the base.tgz of pbuilder
<Mithrandir> ogra: sorry, 32k directories. :-)
<tseng> siretart: rock.
<Mithrandir> ogra: try seq 40000 | xargs mkdir 
<bob2> seb128: ELATEONASATURDAYNIGHT
<bob2> hah, nice that find can work around some disk corruption
<seb128> bob2: just trying to make sure to not conflict with his uploads before upload a xft to drop XOPEN_SOURCE from here
<seb128> bob2: if he's away that's fine :)
<ogra> Mithrandir, seriously i wont try it on *this* PII 233 ;)
<bob2> ah :)
<Mithrandir> ogra: get a real computer. ;-)
<ogra> Mithrandir, thats a *server* *g*
<ogra> Mithrandir, but once i mived all this crap to the DC i'll upgrade the machine ;)
<ogra> moved even
<Mithrandir> ogra:  :-)
<ogra> opteron !
<thom> tseng: dude, beagle appears to ftbfs here...
<Amaranth> thom: libgmime-cil is out of sync with the thing it's binding
<tseng> yes
<tseng> gmime 2.1 is a hard dep for 0.12
<tseng> 0.12 is not uploaded because it does nothing but explode here
<tseng> stay tuned
<tseng> thom: want to look at blam/mozilla bug?
<thom> tseng: not really :-)
<tseng> meh
<tseng> sounds like we are at a stand-off
<Amaranth> If my HD worked I'd look at blam :)
<Amaranth> If grub spits out Error 17 when it's supposed to load the menu of choices it can't read /boot, right?
<tseng> can anyone tell me why mono isnt building
<slomo> fabbione: will the kernel be built with gcc 3.4 until breezy release?
<fabbione> slomo: probably
<slomo> fabbione: ok, thanks
<bddebian> Morning
<highvoltage> morning, bddebian 
<highvoltage> (or good afternoon, from my timezone)
<bddebian> Heya highvoltage 
<highvoltage> bddebian: do you think canonical/ubuntu will support the hurd kernel and release a ubuntu gnu/hurd, once it hits v1.0?
<thom> i doubt canonical will, but ubuntu might if there's community interest
<infinity> seb128 : Looks like XOPEN_SOURCE still hasn't been completely purged from the X dependency chain, so you should probably stop uploading things to "fix" it...
<seb128> infinity: hum? what package has been b0rked?
<HrdwrBoB> not sure there will be interest though
<seb128> infinity: xft?
<infinity> seb128 : pango still has it in its .pc file.
<seb128> infinity: yeah, due to xft
<seb128> infinity: that's why I've uploaded xft ... should be fine now
<seb128> then I can upload gtk
<seb128> then I can work :p
<infinity> seb128 : Ahh.  Hrm.  Kay.  Of course, several X libs here still show it as well (sm, xmu, xt, xtrap)
<seb128> infinity: pango don't use those
<infinity> Heh.  Kay. :)
<bddebian> highvoltage: I doubt it but I am working on creating an Ubutnu Hurd derivative
<infinity> So, xft, pango, gtk, gdk, PROFIT?
<highvoltage> bddebian: ah, that will be nice (at least for testing)
<seb128> infinity: that's the plan :)
<infinity> And I can sort out the rest of the X libs that still look goofy later.
<azeem> bddebian: cool, send me the gcc-4.0 fixes if you do so, then :)
<infinity> seb128 : Once you've done those uploads, are we ready for me to do a mass give-back to the buildds again, and see what blows up?
<seb128> infinity: do you know how is xorg/xkb nowadays?
<seb128> infinity: I still have -33 here
<bddebian> Hey any chance one of you "main" types can sync devscripts from Debian unstable?  It's broken in breezy atm
<seb128> infinity: yeah
<infinity> seb128 : Not sure, I run X in hoary still, my breezy stuff is all chrooted.  Probably should switch this month, though.
<infinity> bddebian : Yeah, I was goign to request that sync once the Debian uploads settled down a bit (there've been a few in a row)
<tseng> infinity: could you perhaps tell me why mono isnt building?
<infinity> bddebian : I assume it's the breakage of "debdiff" you want fixed (same as me)?
<bddebian> infinity: Ah, OK, thx
<bddebian> infinity: Yes, debdiff :-)
<tseng> infinity: or, seeming hasnt entered buildd more specifically
<infinity> tseng : Specific package(s)?
<tseng> infinity: mono 1.1.8.2
<infinity> tseng : dep-wait on mono-classlib-1.0... I assume this is incorrect? :)
<tseng> infinity: yes, that must be from my previous upload
<tseng> infinity: we managed to get it bootstraping internally
<infinity> tseng : Freed up, shold build shortly.
<infinity> should, too.
<tseng> infinity: cheers
<tseng> mdke: you should be able to access my server on port 22 now
<infinity> tseng : Built.
<mdke> tseng, ah cool, i was just uploading now :D
<mdke> tseng, btw we have a docteam linode set up now so as soon as we have a subdomain pointing at it, i'll let you know and you can close our account on your server
<tseng> mdke: ok, rock on
<tseng> infinity: thanks dude
<tseng> wth
<Nafallo> http://www.magicalforest.se/tmp/libxaw_7.0.2-3.diff
<tseng> infinity: if you still have a few moments, could you look at that buildlog
<tseng> infinity: apt cache troubles
<Nafallo> builds cleanly on amd64 and should fix xkbutils ftbfs
<Nafallo> :-)
<herve> Nafallo, my hero!
<hunger> Is xkb broken again?
<bob2> yup
<hunger> bob2 What is the workaround this time?
<bob2> I dunno if there is one
* hunger sighs.
<Nafallo> hunger: to dep-wait on xkb-utils :-)
<bob2> my work around was "not upgrade until breezy went a week without being fucked"
<hunger> breezy is basically unusable most of the time:-(
<Nafallo> bob2: what's the fun in that? ;-)
<tseng> funny that ive been using it the entire time
<hunger> bob2: Can't do that... I need the new kernel.
<fabbione> is there some known problem with udev?
<bob2> tseng: proof that I'm lazier than you
<fabbione> bob2: ^^
<hunger> bob2: Actually rebuilding the kernel a couple of times would have saved lots of time.
<fabbione> it seems that it doesn't start here at all..
<hunger> fabbione: Yeap. It does not create /dev/input/mice for me anymore.
<fabbione> hunger: exactly...
<fabbione> and /dev/input/mice
<hunger> fabbione: run udevstart manually and it will be there.
<herve> ha, that's why my usb mouse stopped to work some times
<herve> I unplugged and replugged it and it was ok
<fabbione> hmm
<fabbione> no 
<fabbione> no luck
<herve> or maybe that was a X issue
<hunger> fabbione: I talked to someone here about that two weeks ago... said it worked for him and that I should debug myself.
<Nafallo> dang. does not fix xkbutils *goes back to hack on it*.
<fabbione> it's definetely a udev problem
<hunger> Any change of getting a xkb fixed soonish? And a "startx" would be nice to have at some point, too;-)
<bob2> X will be fixed in the next few days, hopefully
<hunger> fabbione: Yeap, that was what we found out 2 weeks ago, too:-)
<Nafallo> hunger: installed xinit?
<fabbione> mousedev is not modprobed.. so it could either be udev or hotplug
<fabbione> if i modprobe that manually.. everything works
<hunger> Nafallo: There is no xinit... startx used to be part of xbase-clients, but that is basically empty nowadays.
<Nafallo> hmm, xinit has to be NEWed ;-)
<Nafallo> hunger: yea, daniels is spliting it.
<ogra> hunger, xbase-clients is split
<hunger> fabbione: mousedev is loaded here... I do have /dev/input/mouse*, but no /dev/input/mice.
<ogra> hunger, it will disappear completely or get converted to as metapackage eventually
<ogra> s/as/a
<hunger> ogra: Thanks for the info!
<infinity> tseng : Which build log?
<ogra> hmm, #12888 is a very interesting big
<ogra> bug
<lamont> buildLogs/Test/Lists/breezy-autotest.all.amd64:Total 729 package(s) in state Building.
<lamont> buildLogs/Test/Lists/breezy-autotest.all.amd64:Total 138 package(s) in state Dep-Wait.
<lamont> buildLogs/Test/Lists/breezy-autotest.all.amd64:Total 1 package(s) in state Failed.
<lamont> buildLogs/Test/Lists/breezy-autotest.all.amd64:Total 618 package(s) in state Installed.
<lamont> buildLogs/Test/Lists/breezy-autotest.all.amd64:Total 13 package(s) in state Uploaded.
<lamont> buildLogs/Test/Lists/breezy-autotest.all.amd64:Total 1499 package(s)
<lamont> oops.
<lamont> anyway, it's < 50% of main that has actual build failures on amd64...
<tseng> infinity: it worked itself out
<lamont> and < 10% that are missing build-depends
<ogra> sounds good..
<ogra> how is this compared to the other arches ? 
<Nafallo> ogra: care for a couple of uploads to main? ;-)
<ogra> Nafallo, not now... i'm currently busy with other stuff... can you send me a list ?
<{Seb}> how is Xorg looking in Breezy?
<{Seb}> Broken?
<hunger> sebest: yes.
<Nafallo> ogra: sure, either that or I nag Tollef after dinner :-).
<ogra> Nafallo, youre already there ? 
<Nafallo> I shall probably test the packages first :-)
<ogra> Nafallo, great idea ;)
<Nafallo> ogra: yepp, since yesterday evening  :-)
<ogra> nice :)
<Nafallo> he's hacking dinner, while I'm hacking Xorg ;-)
<{Seb}> Nafallo: can you tell me if there are any outstanding issues with Xorg?
<HiddenWolf> I'd rather do dinner, really
<Nafallo> Seb: xkb is broken.
<Nafallo> Seb: hopefully not long though ;-)
<{Seb}> when i'm upgrading - what do i need to be careful of then?
<{Seb}> upgrading from Colony 2 install i mean
<Nafallo> xorg
<{Seb}> i guessed that :-)
<{Seb}> i mean which packages are broken?
<HiddenWolf> seb128, he said, xkb
<{Seb}> Nafallo: how do you mean xkb is broken?
<Nafallo> Seb: keyboard doesn't work?
<HiddenWolf> seb128, I'd imagine it doesn't work without user-side hacking
* HiddenWolf grumbles at autocompletion, sorry seb128 
<{Seb}> dang
<{Seb}> Nafallo: will Xorg -44 sort it>
<{Seb}> *it?
<davyd> /set completion_amount 0
<Nafallo> yay! keyboard works again :-)
<Nafallo> Seb: dunno, ask daniels :-)
<Nafallo> daniels /away socializing
* HiddenWolf wonders how you hack to fix a broken keyboard, since you obviously can't use the keyboard
<davyd> HiddenWolf: assuming you're talking about broken X-chat completion, that was for you
<davyd> the option is persistant, and will switch back to the old "readline" style completion
<Nafallo> hmm, gone :-)
<HiddenWolf> davyd, yeah, xchat seems to autocomplete sometimes without my pressing <tab>
<hunger> Nafallo: What do I need to do to get it working here, too?
<davyd> HiddenWolf: you may have an autocompletion character set
<HiddenWolf> davyd, in english that means?
<davyd> which allows you to type dav: and it expands to davyd:
<Nafallo> hunger: http://www.magicalforest.se/tmp/libxaw_7.0.2-3.diff
<Nafallo> hunger: http://www.magicalforest.se/tmp/xkbutils_7.0-3.diff
<Nafallo> now, I'm really gone :-)
<davyd> that'd be the second most annoying feature, right after the one where tab matches the first option, rather then matching as much as possible
<HiddenWolf> davyd, how do I kill this? I'd rather not have my pc think for itself
<davyd> HiddenWolf: the completion character is in the preferences
<HiddenWolf> annoying feature -> bug
<davyd> for the dumb tab completion you'll need to give the command I gave originally
<HiddenWolf> Nah, I like tab completion, it just has to do it when I want to, not at random
<davyd> it doesn't turn off tab completion
<davyd> it just goes to the old gnu-readline style
<davyd> like it used to be
<davyd> like it is in zsh
<HiddenWolf> nafallo, how soon do you think it'll be before xorg is unbroken?
<infinity> HiddenWolf : A week would be a good estimate for X to be mostly happy for most users.
<robertj_> after X is happy, is there going to be another colony release/
<infinity> You'd have to ask Kamion, who appears to be having himself a weekend away from IRC.  Something I should also do.
<HiddenWolf> infinity: thank you. I really need to upgrade to breezy, but I don't feel like messing a lot. :(
(CarlFK/#ubuntu-devel) if i hit Scroll lock just right, I can get it to stop with: tail /var/log/syslog - no such file
<CarlFK> it seems like the install is still progressing, but the console is just being flooded with that error so I can't see the status of the install
<bytee_> hi ubuntites! casper does liveCDs, has anyone thought of, or is anyone working on making it so that casper does USB thumb drive installs ?
<thesaltydog> does anybody know if there is a patch available to let gnome-app-install working on Hoary?
<lamont> dpkg-shlibdeps: warning: could not find path for libhal.so.1
<lamont> bad hal
<fabbione> hey lamont 
<fabbione> lamont: there was no need to bootstrap dbus <-> kdelibs
<fabbione> kdelib first, than dbus did it
* Mez downgrades dpkg
<lamont> fabbione: that's because you had a dbus to install
<fabbione> hmm yes, but it was a very old version
* lamont had no version
<lamont> well, maybe in hoary
<fabbione> meh
<lamont> and what I did was install kdelibs4-dev (with hoary allowed), and then built dbus
<fabbione> yeah gotcha
<fabbione> food is ready
<fabbione> later
<thesaltydog> does anybody know if there is a patch available to let gnome-app-install working on Hoary?
<scorpix> is there any news about Colony 3?
<hunger> scorpix: From what I understand the next colony will be released once xorg gets somewhat more stable.
<hunger> scorpix: Someone mentioned something about it being ready in a week or so...
<carl> has anyone tried todays install?  mine errors near the beginnig
<mdz> seb128: are we going to see xchat-gnome for breezy?
<{Seb}> mdz: what advantages does xchat-gnome have over plain xchat?
<chrissturm> seb: xchat-gnome is a new frontend for the popular X-Chat IRC client  targeted towards the GNOME platform. Our eventual goals include full desktop integration and HIG compliance.
<{Seb}> great
<{Seb}> hope it gets into Breezy
<chrissturm> doesnt build for me :( 
* chrissturm tries the svn version
<Amaranth> anyone know of a way i can fsck my linux HD from windows?
<Amaranth> i know this isn't a -devel question
* Amaranth is desperate
<carl> Amaranth, #ubunto
<hunger> Amaranth: Knoppix springs to my mind there...
<Amaranth> No CDs.
<zyga> Amaranth: ntfs or fat?
<Amaranth> hmm, i think fat32
<zyga> Amaranth: belay thay---- I've got reading problems
<carl> ext2 (/boot part
<carl> huh?
<Amaranth> i'm on windows
<Amaranth> i need to read linux fs
<Amaranth> well, fsck it
<zyga> Amaranth: that's fscking difficult 
<Amaranth> no shit
<carl> Amaranth, i think you should describe the symptoms
<Amaranth> error 17 on grub load
<Amaranth> HD overheated, humorously enough, during a fsck
<chrissturm> Amaranth, i repaired my hd with spinrite
<chrissturm> but its commercial
<Amaranth> the other drive was got even hotter and is fine now so i'm hoping its just a silly error like a corrupt superblock
<zyga> Amaranth: 1) cool your drive with a good fan 2) put the drive in a linux box 3) don't mess with it on windows, it's difficult already
<Amaranth> chrissturm: needs a CD and/or floppy anyway
<Amaranth> zyga: 1) i seperated the drives, won't be a problem anymore 2) not possible, this is the only box 3) it's either that or stay on windows
<carl> Amaranth, yeah - if you really want to fix it, don't mess around with a win solution - figue out how to get some sort of Linux
<Amaranth> i will hopefully have a hoary CD late tomorrow night but i really need to get back to work on smeg
<zyga> Amaranth: it's either that or go to a internet caffe and convince the owner to allow you to attach your drive and boot from *nix live cd
<Amaranth> I don't have any CDs...
<zyga> Amaranth: any friends that can help you?
<Amaranth> yeah, late tomorrow night
<chrissturm> Amaranth, can you boot over pxe?
<carl> Amaranth, what do you use for dhcp?
<Amaranth> 34 hours from now
<Amaranth> my cable modem
<carl> rats.  no pxe stuf then
<Amaranth> it's admin interface has one thing on it: a reset button
<zyga> Amaranth: hmm
<zyga> Amaranth: what about colinux?
<zyga> Amaranth: co-something-linux - it boots form windows and uses disk image as it's / fs
<Amaranth> will colinux be able to see the drive if windows itself can't?
<zyga> Amaranth: maybe it could fsck your partition
<zyga> Amaranth: I'm not sure - it has a tiny gentoo image available - it's worth checking
<zyga> Amaranth: it does run some windows driver stuff so it *might*
<zyga> Amaranth: alhough you'd need admin privilidge on your box
<Amaranth> i have that :P
<Mez> erm
<Mez> keybuk/elmo/lamont ping
<sladen> Mez: you could always just ask the question
<Mez> Preconfiguring packages ...
<Mez> dpkg: configuration error: unknown option log: Success
<Mez> it b0rked cause of those test packages
<Mez> :D
<Mez> from backports
<Mez> and /me slaps sladen round a bit
* lamont has no clue what Mez should do with that
<Mez> lamont, you can poke backports to start right?
<seb128> mdz: I've not really played with it, but yeah, would be nice to get. No objection to package it for universe now with the UVF?
<Mez> it doesnt neccesarily need to be elmo
<mdz> seb128: no objection, no
<lamont> Mez: I can upload source, I can make buildd's build, but I can't muck with the archive
<Mez> fair enough
<Mez> buggery
<Mez> dpkg = b0rked
<mdz> Mez: ?
<Mez> sorry - my dpkg = b0rked
<Mez> (as in I cant install anything
<mdz> then I recommend installing one of the working versions available in the archive
<Mez> mdz, that's the problem I can't - i need dpkg to install it
<fabbione> Mez: use a livecd to boot and use chroot
<mdz> Mez: unpack the .deb with dpkg -x and use the dpkg binary contained therein
<fabbione> hi mdz
<Mez> ah, good idea
<fabbione> mdz: how is going today?
<lamont> fabbione: your way is so new-school. :-)
<mdz> fabbione: much like yesterday
<mdz> only I got a good night's sleep
<fabbione> lamont: ain't my fault if you are over 40
<mdz> which was nice
<fabbione> mdz: sounds good
* fabbione starts to think that 3heads on a ws is a bit too much
<Mez> mez@apathy:~/dpkg$ dpkg -x *
<Mez> dpkg: configuration error: unknown option log: Success
<Mez> looks like I'm gonna have to do it manually
<fabbione> Mez: dpkg -x dpkg-balbal .
<fabbione> it will unpack the dpkg in there...
<fabbione> * is not an option
<Mez> I'm getting an error with the extracted dpkg too
<mdz> Mez: edit /etc/dpkg/dpkg.cfg and comment out the 'log' line
<mdz> it sounds like you ended up with a dpkg.cfg written for a newer version of dpkg
<Mez> most likely, was downgrading it
<mdz> don't do that
<mdz> downgrades in general are untested and unsupported; not something to try with an essential package
<Mez> mdz, I had an untested version from backports :D
<Mez> but hey
<Mez> that seems to have fixed it
<ogra> Mez, any reason why you backport dpkg ?
<Mez> thanks for your help
<Mez> ogra - it was lamont's "acid test"
<ogra> wohoo... acid test...
<Mez> I had the "official" backports repository in my apt list :D
<Mez> lol
<Mez> and managed to upgrade to that
<Mez> once it was purged, I still had it and wanted to know i had a safe version, so tried to downgrade :P
<lamont> Mez: not my acid test - I just build stuff
<zyga> Mez: could you elaborate on that acid test :> ?
* lamont is still trying to understand the logic of creating -backports...
<Mez> well, someone used dpkg as the "test" backported package
<lamont> zyga: it's good to build some package in a suite before declaring it ready for prime time
<ogra> Mez, you should create a chroot for your package tests to not break your system every time
<lamont> some days it's dpkg, other days it's ed
<ogra> lamont, dont forget the kernel :)
<Mez> ogra - I do have a chroot....
<Mez> but I had the "official" repository added, and in there was a backport of dpkg (now re-reading the email, it was elmo who used that as the test, so apoliogies lamont)
<mdz> lamont: what's difficult to understand about -backports?
<mdz> lamont: elmo would have used ed, but it was the same version in hoary and breezy ;-)
<Mez> lol
<mdz> the next logical candidate was a core piece of package management infrastructure, of course
<Mez> anyway, i fixed that now :D
* Mez reminds himself not to use repos in the testing stage
<Mez> mdz, is it only elmo who can start packages being backported?
<mdz> Mez: yes, please be patient, as he has weekends off
<Masoud> Hi
<Mez> mdz, I wasn't moaning, was just asking :d
<mdz> it will be more automated in the future, but for now this is the most effective way
<pitti> Hi
<seb128> hey pitti 
<seb128> pitti: what do you do here on a saturday night? :)
<pitti> seb128: we were hiking and on the fair all the day, so my gf fell asleep 1 hour ago :-)
<seb128> ah ah
<pitti> so I wanted to do some postgresql hacking
<pitti> (I can't see Firefox today)
<pitti> seb128: and you?
<zyga> hey pitti
<zyga> pitti: what's up with firefox?
* ogra thinks its funny how hackers spend their spare time... i was discussing touring machines/the halting problem with petter this evening :)
<pitti> zyga: YOU SAID THE WORD!!!
<pitti> ogra: oh, did he solve it? :-)
<ogra> lol
<seb128> pitti: just coming back from dinner and having a look on my mail and this XOPEN_SOURCE issue
<fabbione> WOW
<fabbione> i still had receipts from Oxford's meeting in my wallet!
<zyga> pitti: relax it's not like 10^5 users are complainig or anything
<pitti> oh, me too :-) some taxi bills
<fabbione> no wonder it was so heavy
<pitti> zyga: I'll look into the 1.0.6 patches today, but after 60 hours of ffox hacking last week I need a break
<pitti> s/today/at monday/ of course
<lamont> pitti: it just _feels_ like monday, eh?
<zyga> pitti: I'm done working on $$$ apps today, I could help you review those patches tommorow (not on monday)
<herve> hey, my firefox works like a charm
<pitti> mine too :-)
<Mez> backported firefox = uber too
<pitti> but nice that there is at least one other person it works for
<pitti> well, it does run very well without those damn extensions
<Mez> pitti, which extensions?
<ogra> bah, extensions
<pitti> Mez: well, most
<pitti> Mez: I use AdBlock, that works fine
<zyga> pitti: /topic #ubuntu extensions are bad, don't use them, simplicity is bliss ;)
<zyga> pitti: but really I'd like to help
<seb128> bah
<herve> hu? I have a dozen extensions
<Mez> google toolbar works fine too (well in backported version)
<seb128> people you should all use epiphany
<seb128> it works fine
<ogra> herve, and up to date hoary ?
<pitti> zyga: well, I wrote to ubuntu-security-announce, u-devel, and u-users, explaining the issue and workarounds
<herve> ogra, s/hoary/breezy
<zyga> pitti: checking
<ogra> herve, ahh
* zyga does not sign to any mailing lists - it's evil and always too much to read 
<pitti> zyga: I extracted the ffo 1.0.5 -> 1.0.6 changes, I will port them at Monday (half of the patch doesn't apply)
<Mez> pitti: are these problems likely to affect the backport?
<Mez> and if so, should I pull the backport
<pitti> Mez: yes, one of the patches apparently broke the API
<Mez> pitti: does that apply to hoary though? seeing as it has a different API?
<pitti> Mez: no, actually all the 1.0.x versions should have the same api
<ogra> pitti, ha ha ha
<Mez> grr
* Mez read taht as ABI
<Mez> nopt API
<pitti> yes, right, sorry
* Mez goes and pills the backport
<Mez> pulls
<pitti> yeah, typos :-)
<Mez> so, pull it or not?
<pitti> Mez: if you want to...
<zyga> pitti: hmm did you post that mail as someone else? i can't find it i u-d
<Mez> pitti: if the problems are gonna ffect hoary too... then I should
<Mez> I was about to ask the same thing zyga 
<ogra> zyga, he crossposted to -users.... if your filters are as silly as mine, you'll find it there
<pitti> zyga: no, as Martin Pitt <martin.pitt@canonical.com>
<Mez> ah
* Mez found in -users
<zyga> it seems that whatever makes u-d archives is equally silly or I'm blind because it's not there
* zyga found in -users
<zyga> just a side note, firefox really kills the CPU when it's trying to /search for something that does not exist, evey keystroke laggs begind gui
<Mez> pulled from backports
<Mez> I couldnt find it in the archive either
<{Seb}> after upgrading to the latest Xorg, i get an Xsession box when i login with nothing it in
<{Seb}> is this a known bug?
<Treenaks> yes
<Treenaks> or, you could look on bugzilla.ubuntu.com :)
<{Seb}> any way to remove it?
<zyga> pitti: is it possible to keep the same API as 1.0.2 had?
<zyga> pitti: api/abi whatever's changed?
<pitti> zyga: no, one vulnerability really was an API flaw, so it needed to be changed
* fabbione heads to bed
<zyga> pitti: what about api wrapper? I'm not familiar with that flaw so I'm shooting blanks here?
<zyga> pitti: that's c++ code change, right?
<pitti> zyga: yes
<ogra> {Seb}, try to explicitly select a gnome session from gdm 
<zyga> pitti: did you extract the changes from ff repository or are they availiable somewhere?
<pitti> zyga: I took the patches from bugzilla, extracted them from cvs, compared them to each other, and then backported
<pitti> zyga: the mozilla advisories point to bug numbers
<{Seb}> do you know which bug it is?
<{Seb}> there are so many bugs for Xorg (129 actually)
<seb128> try #ubuntu maybe?
<ogra> {Seb}, no idea... did it work ?
<{Seb}> Xorg works yes, and the whole desktop infact
<{Seb}> just this annoying box which i have to click OK for GNOME to load
<zyga> pitti: okay thanks, I'll talk to you tomorrow
<herve> {Seb}, all keyboard keys too?
<{Seb}> think so
<herve> I had to say gnome to use its layout instead of X's
<herve> but now it runs fine
<trulux> pitti: nite man :)
<pitti> Hi trulux 
<trulux> pitti: how's it going?
<pitti> fine, and you?
<trulux> pitti: tired, went out with friends for watching the Four Fantastic
<pitti> ah, btw, ajmitch: what's the selinux status? do we still need patches to be applied?
<tritium> hi trulux
<trulux> hey tritium 
<lamont> hehe xfree86 is ftbfs: can't find -lXext
<lamont> but fixing that probably wants to wait for daniels to finish breaking things...
* tritium wonders if this email from Claire Davis is for real...
<ogra> tritium, likely, yes
<tritium> ogra, seems too good to be true :)
<ogra> laptop misson ?
<tritium> yes
<ogra> enjoy ;)
<ogra> (and test indeed)
<tritium> Absolutely!
<crimsun> ogra: thanks for fixing pymad; I had uploaded -1ubuntu1 and -1ubuntu2, but my key expired. I kept Debian's packages, though, for python2.2 and python2.3.
<ogra> crimsun, yes, it caused some confusion, since i suspeted mine was expired (which is impossible) :)
<carl> when is the next time breezy/daily will be refreshed?
<herve> we should find some solution about those acpi issue
<herve> I have to patch the initrd each time I update the kernel
#ubuntu-devel 2005-07-29
<OddAbe19> so, exactly, HOW broken IS X, right now?
<mdz> daniels: what's the name of the window manager that keith used for his demo?
<mdz> daniels: and is there any video or such of it available online?
<ogra> mdz, do you mean luminocity ?
* ogra thinks the guys in #ubuntu-artwork are quite crazy
<ogra> <dwarvenblade> they say i must make a wallpaper for ubuntu of a piece of celery with peanut butter on it sitting on a plate overlooking a moon which drops down beneath a celestrial waterfall of stars, each running into each other 
<ogra> but great !
<dwarvenblade> ogra, yes the deliverer of eternal brillance from the planet peanut gave me this vision
<ogra> hehe
<ogra> dwarvenblade, PAINT IT !
<ogra> :)
<dwarvenblade> I will paint it with my tongue ring, a good idea
<carl> can initrd.gz be mounted?
<carl> or... where can I see how the installer's is built?
<carl> got it
<carl> there is a version mixup wiht the breezy installer 
<carl> or did I fumble again...
<CarlFK> yup.
<marcin> hi all 
<whiprush> mdz: http://www.gnome.org/~seth/blog-images/monkey-hoot/WobblyWindowsIntro.ogg
<bob2> (fridge)
<whiprush> fridge!
<ogra> FRIDGE !
<marcin> I got a question about emacs packages for ubuntu - something related with debian policy 
<marcin> can I talk here with someone who maintains these packages or is this wrong channel?
<bob2> best to just ask
<CarlFK> what kernel param do I pass the setup to specify the language and keyboard?
<CarlFK> it seems to have changed in the last month or so
<CarlFK> because this usedto work, but now I am being prompted: preseed/locale=en_US kbd-chooser/method=us 
<marcin> bob2, ok then my question is - why you guys follow debian policy for emacs and use these emacsen-common scripts while you provide only one "flavor" of emacs (emacs21)
<marcin> bob2, and why just not to provide really binary packages for emacs with byte-compiled files (.elc only) for emacs21 ?
<marcin> bob2, for example emacs21-gnus, emacs21-cedet, emacs21-nxml and so on
<bob2> I see at least emacs21-nox
<ajmitch> marcin: following debian is a good idea usually because it /win 35
<ajmitch> sigh
<ajmitch> because it minimises the maintainence we have to do
<marcin> ajmitch, ok, but these emacsen-common scripts are overcompilcated and buggy
<bob2> if they're buggy, please file bugs
<marcin> ajmitch, and while you want to provide things that just work than maybe this policy is not so good?
<ajmitch> marcin: if someone has time to sit down & improve things then they can be fed back to debian as well
<marcin> ajmitch, hmm ok then for now - I found a bug (problem when trying to install some emacs packages on hoary) what should I do with this?
<ajmitch> file bug at the moment
* ajmitch is an emacs user, hasn't looked at the packaging
<marcin> you can try yourself - remove all emacs packages (and config files too - remove totally) and then apt-get install bbdb ecb (for example)
<marcin> ajmitch, it should install emacs21 first and then install these packages but it doesn't - you will get an error because there is no emacs flavor available 
<marcin> ajmitch, you need to install emacs21 first and then these packages - this is not the way apt and dependencies should work - right?
<ajmitch> iirc, emacs21 shoul get installed first, but won't be configured when the packages that depend on it are unpacked
<mdz> whiprush: thanks
<lamont> emacs21: error while loading shared libraries: libXaw3d.so.6: cannot open shared object file: No such file or directory
<lamont> how very interesting and annoying
<fabbione> morning
<fabbione> hmmm
<bddebian> Hello fabbione 
<fabbione> hi
<fabbione> daniels_: ping?
<fabbione> can somebody be so kind to write a pipe ?
<fabbione> because keyboard is doomed
<fabbione> or tell me what pkg has xmodmap
<schweeb> fabbione: appears as though none of my installed packages have xmodmap included in them
<fabbione> i got owned by X upgrade
<Aegir> fabbione, |
<Aegir> :)
<fabbione> my keyboard is basically useless
<Aegir> That sucks
<jsgotangco> heh
<fabbione> bah
<schweeb> fabbione: supposed to be included with xbase-clients though
<fabbione> and a dollarsign please :)
<fabbione> crap
<fabbione> pointless
<fabbione> i can't copy paste
<fabbione> even the mouse is doomed
<fabbione> DANIELS?
<schweeb> I don't even have the binary installed anymore
<schweeb> want an old deb of xbase-clients ?
<schweeb> I have -34 -36
<fabbione> do they work?
<fabbione> let's try...
<schweeb> but I think those are both the broken ones
<schweeb> I seem to remember -32 as the last working one
<fabbione> i am not even sure i have enough keys to even install
<schweeb> lol
<fabbione> bah i guess i will have to dig in console mode
<schweeb> -34 has it
<fabbione> given that i can't even switch...
<fabbione> = reboot
<schweeb> gimme a sec to upload it
<fabbione> thanks
<fabbione> hmm
<schweeb> http://www.schweeb.org/~chris/xbase-clients_6.8.2-34_i386.deb
<fabbione> schweeb: i can't make a tilde..
<fabbione> can you move it somewhere else?
<schweeb> haha
<schweeb> yea, gimme a sec
<fabbione> thanks
* schweeb is cracking up
<pinhead> DANIELS YOU WILL ENJOY SOON THE PLEASURE OF PAIN!
<fabbione> the problem seems that xkbutils didn't build yet
<fabbione> because it's depwaiting on libxaw7
<schweeb> http://www.schweeb.org/xbase-clients_6.8.2-34_i386.deb
<fabbione> thanks dude
<schweeb> no prob
<fabbione> let see first if building libxaw and xkbutils will make it
<fabbione> libxaw is FTBFS on some arches, probably due to wrong headers that are ok here
<fabbione> infinity: can you take a look at it?
<fabbione> it looks like it has been attempted with old headers or something
<fabbione> (because ia64 managed it)
<fabbione> hmmmm
<fabbione> now i got an half working us keyboard
<fabbione> AHHH
<fabbione> got it i think
<fabbione> MUCH better
<fabbione> schweeb: the new xkbutils (that aren't built yet) use the wrong path to the keyboards layout
<fabbione> and at the same time xterm is doomed
<schweeb> hahah
<schweeb> so daniels will be getting flamed more when they actually build
<fabbione> well.. let see if i can manage to use gnome-terminal
<fabbione> well i guess i can use gnome terminal
<fabbione> but it's slow to death
<fabbione> i need xterm back
<schweeb> yea, isn't it wonderful how gnome-terminal managed to make terminal emulation slow
<fabbione> hell if it's slow.. i can type and chars appears with 1 sec delay
<schweeb> geeze
<schweeb> what kinda hardware?
<fabbione> P4 2GHZ
<schweeb> odd
<fabbione> it's mostlikely the font rendering
<fabbione> swithing to a static font is slightly faster
<fabbione> hmm not even that
<fabbione> it's the text parser for URL's and stuff that's dog slow
<fabbione> i wonder if i can disable that somehow
<fabbione> daniels_: libx11-6 is borked..
<fabbione> daniels_: you are shipping a lib in /usr/share/X11/locale/lib/common/ that should really really really be in /usr/lib equivalent
<fabbione> sorry i meant...
<fabbione> xterm tryes to open /usr/lib/X11/locale/common/
<fabbione> when the stuff is in /usr/lib/X11/local/lib/common
<fabbione> that solves the xterm input method problem
<fabbione> --- SIGCHLD (Child exited) @ 0 (0) ---
<fabbione> this trying to change the xterm font using  ctrl+rightmousebut
<fabbione> the xterm doesn't die, but it doesn't switch fonts
<fabbione> and that's because xterm is searching app-defaults/XTerm in /usr/lib/X11/ instead of /etc
<fabbione> (and deadkeys are still dead)
<Aegir> :O
<Aegir> Ouch, Im certainly glad I chose not to upgrade to breezy just yet.
<[SemTeX] > on my box, x dies after login
<[SemTeX] > "gdk-warning: locale not supported by xlib"
<[SemTeX] > better than last week though
<[SemTeX] > x didn't even start then :)
<Aegir> My experiance with Breezy was everything hanging during graphical login. Well, not hanging, I could still swap to virtual terminals, print screen, ctrl-alt-backspace, etc... Just couldnt log in, or use failsafe gnome either.
<Aegir> I think Ill wait a little longer to be on the cutting edge :)
<infinity> fabbione : libxaw FTBFS was due to a bug in libxmu.  Uploading a fix now, thanks for the catch.
<fabbione> infinity: it did build fine after a dist-upgrade
<fabbione> i think kicking back is enough...
<infinity> I already kicked it back.  The new build logs were where I noticed the problem.
<infinity> If it worked for you, you has libxext-dev installed, despite the fact that nothing in libxaw's build-deps depends on it.
<fabbione> so how come it did build here... *shrugs*
<infinity> s/has/had/
<fabbione> mostlikely yes
<fabbione> daniels_: where did you hide the v4l module for X?
<zwnj> Reze_M: howdy?
<Nafallo> fabbione: could we have latest CVS synced for rt2400 and rt2500 in the next kernel?
* terrex is away: Alimentndome // I'm eating st
<\sh> hmmm...
<lamont> dh_install -pgstreamer0.8-swfdec
<lamont> cp: cannot stat `./debian/tmp/usr/lib/gstreamer-0.8/libgstswfdec.so': No such file or directory
<lamont> grumble
<\sh> lamont: can u have a look on http://people.ubuntu.com/~lamont/buildLogs/o/oo2c/1.5.9-4ubuntu1/oo2c_1.5.9-4ubuntu1_20050724-1250-powerpc-failed.gz
<lamont> \sh: in something more than 10 hours, sure
<\sh> lamont: strange that the other archs are building
<\sh> lamont: hehe :)
<lamont> off to church meetings
<trulux> morning
<TD> hi - i'm not sure if this is the right place to ask, but the gtkmm-2.4-dev packages don't seem to include static archives anymore. i'm trying to figure out why, but i can't locate the changelogs for the -dev version of the package.
<TD> where am i going wrong?
<bob2> sure you can
<bob2> but it doesn't mention the word "static" at all
<TD> i looked on the changelogs.ubuntu.com site, but that seemed to be only for the gtkmm2.4 package, not gtkmm2.4-dev
<TD> and yeah. no mention of static libraries anywhere
<bob2> changelogs are for source packages
* TD is at a loss then
<TD> there's no mention of them in the bug tracker either. hmm
<ogra> TD, the -dev packages are generated by the gtkmm2.4 source package
<TD> ok
<infinity> lamont : *WARNING* *WARNING* about to do another mass give-back, mail flood imminent.
<ogra> infinity, i'll have some fun stuff for you soon... edubuntu will use mediawiki in main... that brings a lot of your php universe package into the supported seed :)
<jsgotangco> weee
<ogra> s/package/packages
<infinity> ogra : Yeah, I need to get on my hands and knees and beg for a UVF exception to finish off ServerRoadmap.
<infinity> ogra : php4 is supposed to go wholesale to universe, while php5 comes into main.  In theory.
<ogra> for breezy already ?
<jsgotangco> wow php5 in main
<infinity> ogra : I'm going to talk to Kamion and mdz about it in the next day or so, since php5 is being uploaded to Sid as soon as ftp-master comes back online.
<ogra> oki... keep me updated on this please... i have a mountain of php apps in edubuntu and i'm not sure if everything is php5 compatible
<ogra> i.e. moodle
<fabbione> infinity: why is libxfixes in universe?
<fabbione> isn't supposed to be in main?
<ivoks> hi
<fabbione> the source in universe is problematic
<ivoks> moodle sucks :)
<infinity> ogra : It all SHOULD be (though not necessarily at the packaging level)... One motivation for holding off so long on shipping php5 was to make sure that all apps were okay upstream.
<ogra> ivoks, i know.... but we committed to ship it
<infinity> fabbione : Uhm.  That's just plain wrong.  Since when?
<fabbione> dunno
<fabbione> i just noticed due to gtk+2.0 FTBFS on sparc
<ivoks> ogra: uh... well, ok
<fabbione> http://www.fabbione.net/new_office.jpg <- phear my 3 heads workstation
<infinity> fabbione : Shows as being in main here...
<fabbione> the source is in universe
<infinity> Oh, I see.  Source in universe, binaries in main.  That's not even supposed to be possible.
<mdz> infinity: what are the upgrade issues around php4->php5?
<fabbione> well i just did an ls
<fabbione> hey mdz
<infinity> mdz : For end users, probably none.  For administrators, there's have to be a conscious decision made to switch, as I'm not comfortable with forcing an upgrade with a metapackage or any such thing.
<mdz> infinity: pushing php4 into universe is tantamount to forcing an upgrade
<infinity> mdz : Similar to apache -> apache2, but without the configuration headaches (as php4and php5 share nearly identical configurations)
<ogra> fabbione, about time for some flatscreens :)
<fabbione> ogra: i don't like them
<fabbione> and the one i saw is too expensive
<fabbione> the one i really really like
<fabbione> + these 3 were for free :)
<ogra> oh... but they save a lot of space and are good for your eyes
<infinity> mdz : Well, I meant forcing an upgrade without them knowing about it.  Pushing to universe to force a conscious upgrade is intentional (as was the case with apache)
<fabbione> space is no problem. i am still not happy with the quality of the pic they deliver
<mdz> infinity: we never shipped apache 1.x in main
<ajmitch> hi all
<infinity> mdz : Oh, not even in warty?  So we didn't.
<ogra> nope
<mdz> it's a tricky situation; if we demote php4 we'll probably need to add an upgrade note or something to tell the user what is happening
<infinity> mdz : At any rate, nothing in main currently depends on php4, so dropping it back out doesn't suddenly make anything break.
<mdz> infinity: but there are quite a lot of installed systems which are using it
<ogra> infinity, as i said i'll have a lot of stuff depending on php soon for edubuntu
<ogra> (in main that is)
<infinity> ogra : Right, but those will all be new for breezy.
<mdz> ogra: those should use php5 from the start
<ogra> nope, not all...
<ogra> oki
<mdz> assuming we get it in
<mdz> infinity: I assume you're planning to land it RSN if it's intended for breezy?
<infinity> mdz : Yes, this is true.  I'm not sure if there is a sane way to force that sort of thing, though.  We can't have fake php4 packages in main that tell people to upgrade to php5, that's just icky.  Do we not consider documentation in upgrade notes to be "good enough"?
<ogra> i cant promise that all are compatible already... i have to research that first
<infinity> mdz : I can land it tomorrow (my Monday)... The sid upload was pretty much waiting on newraff coming back to life.
<mdz> ogra: better to just do it, and see what breaks
<ogra> ok
<infinity> ogra : I can help you test easily enough.  Nothing should break, though.
<ogra> infinity, if upstream says its ready i'm fine... and suspect it to work then... its just some minutes of browsing through the upstream pages :)
<infinity> mdz : We really have no way to force upgrades of anything outside the scope of ubuntu-desktop.  Server users are generally left on their own for these sorts of things.
<mdz> infinity: we've never had to handle this situation before; there isn't a general precedent yet
<infinity> Fair enough.
<ogra> what i'm worried about is he upgradeability php4->5 if people already using something i switch to 5
<mdz> infinity: is upstream dropping support for php4 within breezy's lifetime?
<infinity> mdz : That's my fear, yes.  php4 will EOL fairly soon, AFAICT, and I don't want to be stuck being upstream for it, as I am for php3 in Debian.
<mdz> infinity: php5 would be a major UVF exception, and create a lot of additional transition work for MOTU
<infinity> (By "fairly soon", I mean "within a year or so")
<infinity> mdz : I know.  I let the dates slip by while working on X.  I suck.
<infinity> mdz : I can work with MOTU to make sure everything's happy there.  In most cases, it's just a question of s/4/5/, or adding alternate dependencies to things.
<mdz> it might be feasible to allow it into main, but I'm not sure that we can demote php4 this late in the game
<infinity> mdz : We could ship both for this cycle, but we definitely don't want to ship php4 for our big "supported for 5 years" breezy+1 release.
<mdz> that's 9 months away yet
<infinity> mdz : I'd be happy enough shipping both right now (though pitti was really keen on dropping php4 to universe)
<infinity> Dropping php4 to universe also gets rid of the Debian->Ubuntu diff, which makes life easier.
<ogra> infinity, how that ?
<infinity> But, how bout we get php5 in, I try to help people migrate stuff, and if it looks demoteable later, we try then?
<ogra> it just moves the work to the (overworked) MOTU
<infinity> ogra : php4's packaging in Ubuntu is different solely because of the main/universe split.  If it was in universe, it could have the Debian sources unchanged.
<tseng> mdz: do you have a moment to talk about gkt-sharp next?
<mdz> infinity: is the infrastructure side of SoundEvents completed?
<mdz> tseng: ok
<ogra> infinity, that would break a lot of setups that still want to run 4 i guess, no ?
<infinity> mdz : I'll upload whatever changed need to be made there tonight and update the wiki.  Deal?
<infinity> ogra : Not sure how it would break anything.
<mdz> infinity: ok, please update status for anything with your name attached
<ogra> infinity, me neither, i'm no php guy at all... 
<mdz> <date>: <text>
<infinity> ogra : Anyone running packaged php4 apps with Ubuntu is doing so from universe (there are none in main), so moving php4 doesn't hurt them.  Anyone running unpackaged stuff would just continue using php4 packages from hoary until they upgrade.
<ajmitch> ogra: I know of a number of packages that won't run on php5, but that's no big problem as they're not in main
<ogra> infinity, but if the possibility exists, it would geerate a ton of bugreports we (MOTU) had to deal with
<tseng> ogra: do you have an email for Unfrgiven
<ogra> tseng, nope
<infinity> ogra : Just cause I wear a big hat with "main" on it doesn't mean I can't handle php4 bug reports for universe as well.  I do maintain it in Debian, afterall.
* infinity needs to go help his girlfriend cook.  Back in a bit.
<ogra> infinity, i'll qoute you on that !
<lsuactiafner> seems nobody in #ubuntu can remember, but once in this channel i was told how to create a fake packacge so that apt-get ignores certain updates? i dont want apt-get to download and upgrade to new kernels
<bob2> lsuactiafner: dude, I told you, put the kernels on hold if you really don't want updates
<mdz> lsuactiafner: if someone mentioned it here before, you can search the online logs for this channel
<lsuactiafner> bob2 : there is no hold option i found, lock didnt work
<tseng> mdz: ok so, im not really thrilled about where gtk-sharp2 has gotten upstream compared to what was projected (final release in Sept, assuming freezes sooner)
<ogra> oh, btw, fabbione, could you add edubuntu to the logbot ?
<bob2> lsuactiafner: this isn't development-related, #ubuntu
<ogra> s/edubuntu/#edubuntu
<tseng> mdz: there still is no real plan, and the options upstream gave me I'm not a big fan of. might be time to talk about demoting things before we get into breezy release crunch
<mdz> tseng: I'm not entirely clear what you mean...we need to back out on mono-in-main for breezy?
<ogra> mdz, only certain apps
<tseng> mdz: mono itself isnt in bad shape, but we are justifying main status by the gtk-sharp2 apps
<mdz> ogra: we have no apps in main so far, and gtk-sharp2 is in the dependency chain for the one app we have seeded
<tseng> mdz: gtk-sharp2 still isnt in a state that id be happy pushing off on canonical for support
<mdz> tseng: what are the issues?
<tseng> mdz: there is no plan for releasing a stable api
<ogra> mdz, we had at least two i can remember, tomboy and beagle
<tseng> which wasnt really noticeable at any point in development
<tseng> because there are backwards compat hooks
<ogra> while only beagle is gtk.shrap2 afaik
<tseng> most stuff works on rebuild
<mdz> ogra: and tomboy doesn't depend on gtk-sharp2?
<tseng> but thinking about supporting a release for 6 months.. our stuff will work, people building apps from tarball/cvs (common) will probably break
<ogra> mdz, not on 2 iirc
<mdz> tseng: they'll have the same problem if it's in universe
<mdz> tseng: I'd like to have beagle
<tseng> mdz: beagle is a different story, amd64 guys say is unstable across the board
<ogra> yep, it is... i'd put more tim in it if i had it
<tseng> i cant get anyone to go upstream and work it out, thought
<tseng> mdz: if the api breaks in universe, canonical support isnt holding the bag
<tseng> its about supporting something upstream doesnt want to still
<tseng> sorry for mixing in two issues now.
<mdz> tseng: if beagle is a bust, it needs to be removed from the supported seed
<Yann2> hi
<tseng> yes, id like to call that one for sure. if its going to explode on amd64 we cant have it in main
<Yann2> i'm willing to create an Ubuntu-europe foundation... who should I discuss that with?
<tseng> Yann2: how do you mean by foundation?
<tseng> Yann2: right now we have a number of "local teams" in eurpoe
<Yann2> the same as the mozilla europe foundation
<Yann2> tseng > I know, i'm leading the french one
<Yann2> we currently are working together with the german team
<mdz> tseng: if it's solid on i386 but flaky on amd64, that isn't necessarily a show-stopper
<Yann2> to buy a new server for both websites
<mdz> so long as it builds
<Yann2> we got many, many more monney as expected
<tseng> mdz: hm then we can keep tracking beagle a little longer
<Yann2> in fact we got 1200e on one day, and 1500 have already been promised
<ogra> mdz, most other mono stuff works fine on amd64... its only beagle that behaves _this_ bad
<Yann2> as that monney basically is for french and german teams
<Yann2> we thought it could maybe be useful to other locoteams
<bddebian> Hello
<{Seb1> hey bddebian
<ogra> Yann2, smurfix is the lead of the loco team administration, you should probably talk to him if he's around
<bddebian> Morning {Seb1 How goes it?
<Yann2> ogra > we already are working together
<{Seb1> bddebian: it is going great - i'm just creating a GPG key
<Yann2> we just want to officialize it
<bddebian> Cool
<{Seb1> bddebian: so i can sign the Code of Conduct and the NuN Code of Conduct
<bob2> NuN?
<{Seb1> New Users Network
<{Seb1> i'm joining (hopefully)
<{Seb1> since i'm pretty rubbish at everything else but I should be able to give something back to Ubuntu by helping w/ documentation etc...
<{Seb1> i just killed gnome-panel which also killed Gaim
<ogra> {Seb1, NuN has a own CoC ?
<bob2> erk
<bob2> ogra: https://wiki.ubuntu.com/NewUsersNetworkGuidelines, it seems
<{Seb1> ogra: Guidelines even
<ogra> eek
<ogra> ah, ok
<Yann2> you're right i'll talk about that to smurfix :)
<ogra> Yann2, yep, that'd be best... he is already tightly connected with ubuntu and knows where to go with this request
<Yann2> ok
<{Seb1> yay! made my key with Seahorse
<bob2> hm, I thought they'd fixed the '"New User Mentors" are people who dedicate at least 10 hours per week to helping new Ubuntu users.' thing
<tseng> mdz: ok, gtk-sharp2 isnt going to explode if we ship as is. ill update status and try to get beagle 0.12 working (should fix a few peoples issues)
<{Seb1> bob2: i can do that :-)
<jsgotangco> {Seb1: if you're interested in documentaiton, you can join the docteam we need all the help we can get
<mdz> tseng: yes, beagle 0.12 can have an exception to UVF ;-)
<{Seb1> jsgotangco: what does that entail?
<\sh> hmmm..i should have a shower..that I forgot during the day...and the buildds are busy as hell
<jsgotangco> {Seb1: wiki work, docbook work
<jsgotangco> (although docbook knowledge iis not necessarily required welcome nonetheless)
<trulux> heya pitti 
<pitti> Hi
<{Seb}> who are all these pople?
<{Seb}> *people?
<{Seb}> i wonder if brown.freenode.net has gone down....
<trulux> {Seb}: Lost in Plug
<daniels_> mdz: http://live.gnome.org/Luminocity
<davyd> yo yo, it's Stone
<tseng> +r
<davyd> or stoned
<fabbione> daniels_: hey kid
<fabbione> daniels_: i suggest you read a bit of the scrollback in here
<fabbione> daniels_: next step is you sending me 10$ for beer
<HWolf> fabbione: what did he do? ;)
<fabbione> LOVE LOVE LOVE...
<fabbione> all i need is lovee...
<fabbione> papparapaaaa
* HWolf loves everyone
<OddAbe19> when is X expected to be straightened out, out of couriosity?
<HWolf> OddAbe19: join the legions of people who want to know that. ;)
<fabbione> OddAbe19: never.. that will be the surprise feature for breezy
* davyd laughs
<OddAbe19> lol
<davyd> no software will compile
<daniels_> fabbione: i read the scrollback, yeah
<daniels_> fabbione: i'll look into libx11 tomorrow
<OddAbe19> I know i'm not the only one that wants to know, i was just wondering if it's going to bee soon?
<daniels_> it's 0122 on a sunday night, been tied up with family stuff all weekend
<fabbione> daniels_: and xterm please
<HWolf> OddAbe19: knowing X, it'd not hold my breath. But we all know the X team are hardworking and competent. ;)
<fabbione> xterm should point to /etc/X11/app-defaults and not /usr...
<chrissturm> is there a workaround to the X keyboard problems?
<OddAbe19> HWolf, yeah, praise the X team
<OddAbe19> :-D
<ogra> yeah, find the easter egg in breezy.... get your x working ;)
<\sh> hmmm
<\sh> something went wrong
<HWolf> s
<HWolf> \sh: what else is new ;)
<\sh> HWolf: ah no...I just saw a package which wasn't for ubuntu..but accepted by the buildd...strange...
<infinity> \sh : ?
<\sh> infinity: rezound
<\sh> infinity: i386 list says: not for us..but katie accepted and changes as well
<infinity> \sh : not-for-us is just for the buildds, not for the archive in general.
<infinity> \sh : katie will still accept source uploads, but the buildds won't ever touch it until it's not not-for-us.
<\sh> infinity: but it's in the archives ;)
<infinity> \sh : Then it was built before I NFU'd it.
<infinity> \sh : And it's was later NFU'd to prevent autobuilding of new ujploads until its dependencies were ready.
<\sh> infinity: the last version actually..not the new one
<infinity> \sh : I'm assuming it was tied up in the C++ transition (or still is)?
<\sh> infinity: merge
<infinity> \sh : NFU has nothing to do with the archive, only buildds.  Does that clear it up?
<\sh> infinity: all deps are there and it build fine here
<\sh> infinity: yep
<infinity> \sh : So, are you saying I should clear the NFU? :)
<\sh> infinity: please :)
<infinity> \sh : You sort of stopped communicating with me about frozenapps a few weeks ago, so anything still frozen has been that way for a while.
<infinity> Which appears to be 12 packages, still.
<\sh> infinity: pls give me the url again...I just lost everything since my breezy adventure xorg failures 
<infinity> \sh : http://cerberus.0c3.net/~adconrad/frozenapps.txt
<infinity> \sh : Let me go over it really quickly here.
<\sh> libace is not transitioned...new upstream and really crappy rules :( UNfrgiven and I are lost with this...
<ajmitch> libcrypto++ has a number of issues, being discussed on debian-devel
<\sh> gfccore is in NEW queue...I asked for NEW love, but actually...it looks like it's stucked there
<\sh> mpqc (libsc6c2) looks like ready to go
<infinity> gfccore looks like it made it in, to me.
<ajmitch> what about libcln? I thought that was in?
<\sh> libcln3c2 is also ready to go
<ajmitch> yes, it is in universe
<ajmitch> as are libfox1.0c2 & 1.2c2
<\sh> yepp
<bddebian> Is there a reason we don't have libdebtags1-dev ?
<\sh> yehia is a stopper...will have a look right now :(
<\sh> openvrml..stopper
<ajmitch> bddebian: perhaps it went into debian after UVF?
<\sh> tse3 (libtse3-0.2.7c2) is ready to go
<ajmitch> bddebian: it was uploaded to unstable on 1st july
<\sh> libginac1.3c2 as well..go
<\sh> libxdb1 i can't find
<\sh> libsigcperl1c2 not finished
<bddebian> ajmitch: Ahh
<\sh> ok...let me quick fix this
<\sh> infinity: give me one hour at last 1 1/2 hours...to get the rest != ace
<\sh> and aqsis
<infinity> \sh, ajmitch : When you guys are telling me stuff is "in", you're making sure it's built on all arches, right?
<jsgotangco> good night everyone, pleasant sunday to all
<infinity> \sh : I'm going to be for 6 or 7 hours, can you just ping me in /msg with a list of what is and isn't ready later tonight?
<infinity> \sh : s/going to be/going to bed/
<\sh> infinity: normally yes....I just check again all stuff..cause some are missing bugzilla entries :(
<\sh> infinity: I'll mail u the list of finished libs ..
<bddebian> So what is the appropriate method to request a synch (new package) from Debian upstream?
<pitti> lamont: here?
<\sh> ok...sigcperl uploaded ...
<pitti> bddebian: ask elmo to do it
<bddebian> pitti: OK, thanks
<pitti> bddebian: however, we have upstream version freeze now
<bddebian> pitti: I know but packagesearch in merge now build-depends libdebtags1-dev and we don't have it.
<pitti> bddebian: ah, for universe?
<pitti> Hi ogra 
<bddebian> pitti: Well packagesearch is in universe but I would expect libdebtags1-dev would be in main??
<pitti> bddebian: if we don't have it at all ATM, it should go to universe
<ajmitch> no good reason for it to go into main
<pitti> ajmitch: hi!
<pitti> ajmitch: what's new in SELinux land?
<ajmitch> hello pitti 
<ajmitch> not terribly much
<pitti> ajmitch: are there still outstanding SELinux patches in breezy?
<ajmitch> yep 
<bddebian> pitti: OK.
* ajmitch is currently trying to get some code in shape for work this morning :)
<pitti> see you tomorrow
<zyga> daniels_: what is luminocity?
<{Seb}> luminocity is a window manager
<{Seb}> with lots of eye candy
<\sh> mdz: ping
<HWolf> {Seb}: Is it usable? 
* zyga will wait until it's packaged by someone
<HWolf> And will anything of it ever reach mainstream, as usefull UI enhancements
<{Seb}> HWolf: good question
<HWolf> zyga: it won't be packaged, it's a testcase, to show what is possible with 'next-gen' things that are considered good should be merged into metacity
<HWolf> gen'. T
<HWolf> {Seb}: I think we'll agree that wobbly windows are fun, but I don't see any possibility of them making live easier. :)
<{Seb}> true - it shows that Linux has the potential to do cool stuff with graphics
<{Seb}> like OS X
<siretart> is there some possibility to make metacity resizing on alt+dragwithrightbutton?
<mdz> \sh: ?
<zyga> HWolf: maybe someone will package the testcase for average person to see?
<\sh> mdz: any objections to overwrite UVF for universe for a new lib? openvrml-0.14.3 doesn't build with gcc4 and is not maintained anymore by upstream...debian is old...and I'm just trying 0.15.9
<zyga> siretart: itsn't it already resizing with meta+dragwith3rdbutton :)
<mdz> \sh: shouldn't we wait to decide that until you know if it fixes the problem? ;-)
<\sh> mdz: this lib isn't transitioned at all...so I need to do it in any way ,-)
<HWolf> zyga: don't hold your breath, mostly internal technologies developed by hackers, hackers don't care much for an audience, usually. 
<mdz> \sh: if it has a manageable number of reverse depends, and you update them accordingly, it's OK with me
<\sh> hmm...gtklookat ,-)
<\sh> i think I will manage
<siretart> zyga: err, not for me :(
<ogra> siretart, alt+middlemouse works here 
<siretart> woah. neat!
<ogra> mdz, are you aware making all my stuff depend on php5 will defer everything... i dont even know the package names for depends yet
<mdz> ogra: explain?
<HWolf> ogra, are there even php5 packages?
<ogra> mdz, we have no php5 packages yet.... so how should i create depends lines for moodle or mediawiki ? 
<HWolf> ah
<HWolf> nm
<mdz> ogra: we have no php5 packages yet, so why would you do that?
<mdz> ogra: do they require php5?
<ogra> mdz, because you said above that i should :) ?
<ogra> <mdz> ogra: those should use php5 from the start
<mdz> ogra: only the ones which aren't packaged yet
<ogra> i.e. mediawiki :)
<mdz> ok.....
<mdz> so everything for edubuntu is finished except packaging those two?
<mdz> if so, it shouldn't be a problem to wait until tomorrow when infinity said he would upload php5
<ogra> mdz, i'm not sure this includes all my needs, but we'll see ( php-gd and php-imagemagick or -mysql for example)
<mdz> ogra: presumably he would tell you if you asked
<ogra> heh, yes :)
<mdz> or, you could just package them for php4 and consider transitioning them later
<ogra> mdz, i would prefer that, since i'm not sure i want both php's in edubuntu....
<ogra> mdz, the classroom management tool juan promised to send never arrived (i'm just writing another mail to him) that would be the last missing bit... then i can start building a custom config for edubuntu...
<ogra> ...and hope we get a working CD soon :)
<mdz> it seems unlikely that we would be able to get the classroom management tool into good shape in time for feature freeze anyway
<ogra> mdz, yes... i'm looking into alternatives...
<ogra> worst case i'll tweak teachertool, but thats not the nicest app...
<ogra> ... but will be a quick solution
<mdz> I haven't looked at teachertool, but it didn't seem very quick to me
<mdz> how does the authentication work?
<ogra> its only 348 lines of code... but lacking security...
<ogra> it works along the output of "ps --User" 
<ogra> and runs as root/sudo as far as i can tell
<mdz> if it's insecure, then part of the process of integrating it would be securing it
<ogra> i havent looked to deep into it, since i already discarded it in favor of the promised tool...
<ogra> eeek 
<ogra> os.system("export DISPLAY="+computer+":0.0 && su "+user+" -c '"+command+" &'") 
<ogra> ok, it needs a bit of concept work i would say *g*
<HWolf> ugh, who came up with that?
<ogra> HWolf, its a classroom management tool for ltsp... 
<HWolf> ogra, yeah, i've been reading along
<HWolf> ogra, just amazed at that line of code
<ogra> HWolf, there are more of them ...
<HWolf> ogra, i'm not that smart, but if that line works as I think it does, that's pretty dumb. :P
<\sh> hmm..who broke the buildds ?,-)
<ogra> yep... especially since our ltsp shouldnt use "export DISPLAY" at all...
<ogra> but i'll have to play in a real environment... to make this better...
<ogra> (which i'm currently assembling here)
<HWolf> ogra, cool
<fabbione> crimsun: ping?
<fabbione> crimsun: unping
<Mez> jdub: ping
<CarlFK> apt-get install curl = "Package curl is not available, but is referred to by another package."
<CarlFK> (breezy)
<CarlFK> it was a month ago.. should I file a bug report
<ogra> CarlFK, installng curl works flawless here
<CarlFK> ah - I bet it isn't on the CD
<CarlFK> I was onluy using the CD as a repo
<CarlFK> yup.  nm
* schweeb weeps
<schweeb> daniels_: in case you didn't know, there's no xauth binary in -42... I can't start an NX session :(
* schweeb looks for a older version of the package
<tseng> fabbione: did you notice that inotify is broken in last upload?
<tseng> fabbione: i get no device
<seb128> is gamin working for anybody?
<seb128> dpkg: error processing /var/cache/apt/archives/mono-utils_1.1.8.2-1ubuntu1_i386.deb (--unpack):
<seb128>  trying to overwrite `/usr/share/man/man1/mono-find-provides.1.gz', which is also in package mono-mcs
<seb128> dpkg-deb: subprocess paste killed by signal (Broken pipe)
<seb128> grumpf
<seb128> daniels_: xrdb FTBFS, should build-deps on libxt-dev
<HWolf> seb128, have pity, poor daniels...
<seb128> ?
<seb128> that's just information, I'm happy to upload to fix it if he wants
<HWolf> :)
<{Seb}> is the kernel 2.6.1 2 going to be updated with the latest inotify update?
<{Seb}> which uses syscalls instead of /dev/inotify
<Yann2> http://www.ubuntu-fr.org/ubuntu-eu/
<Yann2> tell me what you think... 
<Yann2> mmh, ok, sorry for the poor english, i'm doing my best :/
<\sh> ok..I patched openvrml_0.14.3
<\sh> 0.15.9 is totally crappy source
<zyga> hmm
<zyga> I'm going thru python-gtk-tutorial
<zyga> I've noticed that some examples are using deprecated API
<zyga> and I've fixed them of course
<zyga> does anyone think that patches would be usefull?
<zyga> s/ll/l/
<Amaranth> my windows HD broke too :/
<zyga> python-gtk2-tutorial is a supported package
<Amaranth> so now i've lost everything i've written, all my saved games, all my email, and my GPG key
<Amaranth> yay
<zyga> Amaranth: did you follow gpg tutorial and printed your revocation certificate?
<Amaranth> no
<gnobody> does X work yet?
<Amaranth> why do i need to revoke it? it doesn't exist anymore
<gnobody> does X work yet?
<Amaranth> Please don't repeat yourself.
<Amaranth> That's an #ubuntu question.
<gnobody> nobody on #ubuntu would answer me
<schweeb> Amaranth: have you tried the freezer trick on it
<Amaranth> schweeb: it's not a crashed head
<gnobody> please just answer me amaranth
<zyga> Amaranth: good point... 
<tseng> he did
<Amaranth> gnobody: No.
<tseng> the answer is no
<gnobody> ahh
<gnobody> ty
<schweeb> Amaranth: what's the problem then?
<tseng> last warning.
<Amaranth> schweeb: It overheated.
<seb128> zyga: this kind of patch is nice to send upstream
<zyga> seb128: I'll finish the tutorial (I know nothing about gtk2) and compile a patch
<Amaranth> That guy is pretty annoying about things not working on the forums too. :/
<seb128> zyga: thanks
<schweeb> Amaranth: sounds like someone needs to learn some manners then
* bddebian checks to make sure they aren't talking about him.. :-)
<tseng> {Seb}: new beagle up
<{Seb}> thanks tseng
<\sh> *yawn*
<\sh> good night gentlemen...enough of patching, uploading and merging
<Riddell> what's the gnome package manager called which isn't synaptic
<Amaranth> gnome-app-install?
<Riddell> no
<Riddell> the one that's like synaptic
<Amaranth> doesn't exist
<Riddell> I'm sure there is one
<infinity> There've been several, but I don't know if any ever went anywhere.
<infinity> gdpm comes to mind.
<infinity> Oh, and gnome-apt.
#ubuntu-devel 2005-07-30
<tseng> infinity: evolution-sharp ftbfs is some fault of mine? it pbuilds locally
<infinity> tseng : Looks like unhappy/confused build-deps, or a dirty chroot.  I'll play with it in a sec.
<tseng> infinity: my hero.
<infinity> Very broken build-deps.
<tseng> huh.
<infinity> From a clean chroot (ie: debootstrap --variant=buildd), try "apt-get -o Debug::pkgProblemResolver="1" -s build-dep evolution-sharp" and watch the pain...
<tseng> id be happy to fix a problem, but pbuilder had no complaints
<infinity> A dirty pbuilder chroot.  That's clever... I thought the whole point of it was to avoid that. :)
<tseng> hm its not dirty
<tseng> it has like.. apt and build-essential
<infinity> What arch are you using?
<tseng> x86
<infinity> Oh, of course that's where it's failing too, so that doesn't help.
<infinity> (I guess it's an arch:i386 package?)
<tseng> should be arch:any
<tseng> i can log pbuilder happily resolving the build-dep
<infinity> Oh, it's arch:all, not any.  That's why it only builds on i386.  Phew.  Thought I was going insane.
<tseng> oh yes, im a tool and still get those mixed up
<tseng> because they are so distinctive :)
<infinity> Yeah, that's one you just need to hammer into your skull.  I'm not sure there's any sane way to remember which means which.
<infinity> I guess "this can build anywhere" makes more sense than "this can build allwhere"... :)
<tseng> http://tseng.ath.cx/pbuilder-log
<infinity> Oh, I believe you, it still doesn't explain why both sbuild and apt think something's wrong, unless you have a local package cache or something.
<tseng> nope thats feeding off just archive.u.c
<infinity> Join #flood
<tseng> ill happily fix my bug, just dunno where it is :)
<infinity> Flood protection in #flood.  How cute.
<infinity> Clearly a new feature meant to irritate me.
<tseng> yeah that was a real winner
<infinity> tseng : http://cerberus.0c3.net/~adconrad/feh.txt
<tseng> why the hell cant i paste out of urxvt, i wonder
<tseng> getting a 404 on that
<tseng> oh
<tseng> a*d*conrag
<tseng> d
<tseng> Package cli-common has broken dep on mono-utils
<tseng> feh indeed
<infinity> Note that "broken" from apt's point of view just means "doesn't work with everything else I'm trying to do"... So, finding the one culprit requires a bit of digging at times.
<infinity> Of course, I assume you know the mono dependency chain better than I.
<tseng> unfortunately.
<tseng> im guessing either mono-jit or mono-utils
<mdz> infinity: is sbuild still using its own logic rather than apt-get build-dep?
<mae> hur hur.
<tseng> as libg*-cil is one source package
<infinity> mdz : Yes, some days I think that's a pain, other days I think it's a feature.  I'm undecided which direction to go with that.
<mae> is it likely that beagle/howl/tomboy will be included in breezy?
<ajmitch> I don't see any obvious breakage in the build-deps there
<tseng> mae: howl? no
<tseng> mae: beagle, yes
<infinity> mdz : The feature aspect is where it blindly ignores alternate dependencies, thus forcing consistent builds.
<mdz> infinity: I think apt-get build-dep is the way to go.  at one point, elmo switched one of the Debian buildds to use it as a test; not sure what eventually happened with that
<infinity> mdz : Something you really don't want on your home machine, but comes in handy for buildds.
<mae> tseng, no rendezvous?
<mdz> infinity: surely it doesn't completely ignore them, and will fall back if the first one is not available?
<tseng> mae: the current implementation of howl is restricted by apple patents
<tseng> mae: its being rewritten
<mae> tseng, i see :)
<infinity> mdz : It used to have a conniption fit if the first was unavailable.  If that's since been fixed, then sbuild's dependency handling is basically identical to apt-get, and we should just switch.
<infinity> mdz : I haven't looked at that part of the code for a while, TBH.
<mdz> infinity: perhaps we should give that a try for the breezy full test rebuild
<infinity> mdz : I'm game for that, but it means pulling one buildd out of the rotation (like that's an issue anyway.. We can rebuild the whole archive on the fast buildds in a couple of days..)
<infinity> mdz : elmo and I have other tests (kernel stress-testing and such) scheduled around pulling a buildd out of rotation too, so perhaps we should tweak sbuild there as well and see how badly it goes.
<mdz> sounds good
<mae> python or ruby?
<tseng> mae: python has always been a main target. ruby is in universe
<tseng> mae: could you please consult packages.ubuntu.com for this sort of thing?
<ajmitch> infinity: could the mono problem be mono-jit depending on a virtual package provided by mono-classlib-1.0?
<mae> tseng, that wasn't meant to be a question about breezy, I was just wondering what your thought were on the two languages? :)
<tseng> mae: canonical development is all python-centric.
<tseng> but please, this channel is for development work. we like to offload general questions to other channels
<infinity> ajmitch : I'd have to do more digging to really know for sure what the issue is.  I assumed tsend already had a handle on things, so I stopped wasting cycles on it. :)
<tseng> im looking at it, i dont see anything obvious so far
<ajmitch> if it is, then it should be easily fixable
<ajmitch> in mono
<tseng> besides that I ruled out libg*-cil
<tseng> as its all one source package
<tseng> and sbuild liked it just fine when it build beagle
<ajmitch> time for lunch :)
<tseng> hm.
<infinity> tseng : Uhm, mono-classlib-1.0-1.1.8.2 just plain doesn't exist.  That's not THAT hard to find.
<tseng> ii  mono-classlib-1.0 1.1.8.2-1ubuntu1
<tseng> hm?
<tseng> oh
<infinity> Is it in universe, perchance?
<infinity> Cause evolution-sharp isn't. :)
<tseng> how the hell did he manage that
<tseng> oh
<infinity> Time to set your pbuilder up for the main/universe split.
<tseng> yes it was NEW the other day
<tseng> good one..
<tseng> mdz: can we fix that? NEW bins from mono need seeded
<mdz> tseng: why?
<mdz> is this mono-gmcs?
<mdz> oh, mono-classlib*
<tseng> Package: mono-classlib-1.0
<tseng> mono-classlib-1.0-dbg
<tseng> mono-classlib-2.0
<mdz> nothing depends or build-depends on it?
<tseng> mono-classlib-2.0-dbg
<tseng> classlib-1.0 is a move from mono-assemblies-arch
<tseng> er, -assemblies-base
<tseng> the 2.0 stuff has no build-deps
<tseng> and -dbg is just debug, naturally
<mdz> these are the binaries built from mono which are currently in breezy/universe:
<infinity> mdz : Oh, that could be an argument for not using apt-get build-dep.  If I resolve the build deps myself, then do "apt-get foo bar baz" I get informative messages about baz being uninstallable or foo not existing.
<mdz> mono-classlib-1.0 | 1.1.8.2-1ubuntu1 | breezy/universe | all
<mdz> mono-classlib-1.0-dbg | 1.1.8.2-1ubuntu1 | breezy/universe | all
<mdz> mono-classlib-2.0 | 1.1.8.2-1ubuntu1 | breezy/universe | all
<mdz> mono-classlib-2.0-dbg | 1.1.8.2-1ubuntu1 | breezy/universe | all
<mdz>  mono-gmcs | 1.1.8.2-1ubuntu1 | breezy/universe | all
<tseng> yes, exactly
<infinity> mdz : If I use apt-get build-dep, I just get "E: build-dep can't be satisfied, you suck."
<infinity> mdz : And most people can't read pkgProblemResolver output to save their lives (as evidenced here)
<mdz> tseng: so mono-gmcs should be in main, too?  no new/unwanted deps?
<mdz> infinity: still, it seems a bit silly to have two implementations of this
<mdz> infinity: it wouldn't be hard to add an sbuild-bug-compatible mode to apt-get build-dep
<infinity> mdz : Agreed.  Could we get more informative error reporting, then? :)
<mdz> infinity: that's Hard
<mdz> except in the case where we just emulate sbuild
<mdz> infinity: I don't have access to my key at the moment, please add the mono-classlib-* stuff above to the supported seed
<tseng> mdz: gmcs shouldnt pull anything else to main, no.
<infinity> I've not mucked with seeds before.  Where do they live?
<tseng> mdz: and none of that stuff has things build-dep on it for breezy
<tseng> mdz: *2.0* is non-critical, for the same reason.
<mdz> infinity: has been documented on https://wiki.ubuntu.com/SeedManagement forever
<infinity> mdz : Ahh, will go ive myself a crash course.  I've not ever had cause to edit seeds before.
<infinity> s/ive/give/
<tseng> hm, then I think we can promote just mono-classlib-1.0* without anything else complaining.
<tseng> 2.0 stuff wont be used until breezy+1 at least
* infinity taps his foot waiting for baz to ... do something useful.
<tseng> dude, its merging
<tseng> :)
<infinity> Yes, I know.  Doesn't mean I have to appreciate it.
<infinity> Alright, which packages specifically?  mono-classlib-1.0{,-dbg}?
<tseng> infinity: yes
<tseng> infinity: do you see mono-classlib-1.0-1.1.8.2?
<tseng> hm oh
<tseng> it just drops to mono-classlib-1.0
<tseng> or, apt does. ill not speak for sbuild
<daniels> schweeb: sudo apt-get install xauth
<schweeb> daniels: is it in now? I searched apt for it earlier
<daniels> schweeb: should be
<daniels> ah, it's waiting for the binaries to be NEWed
<daniels> it'll probably happen in about 10h when the UK's awake
<schweeb> k
<schweeb> I downgraded to -34 or -36 and managed to get NX working
<infinity> tseng, mdz : done, btw.
<spacey> will (Free)NX be available in breezy?
<tseng> infinity: thanks muchly
<daniels> spacey: probably not
<daniels> spacey: its build system is bizzare and horrible, it's not at all obvious what changes they've made, and, most importantly, their modifications are GPL rather than MIT/X22
<daniels> er, mit/x11
<toresbe> ugh, I read FreeVAX
<toresbe> I need sleep.
<spacey> daniels, GPL is ok right?
<spacey> seems ok for ubuntu
<HrdwrBoB> spacey: yes but it can't go back upstream
<spacey> HrdwrBoB, ah, you mean from freenx -> NX
<spacey> ?
<spacey> or am i missing a step
* spacey pretty tired
<schweeb> they mean upstream to X, I believe
<spacey> ah
<spacey> didn't know it NX affected the X codebase
<HrdwrBoB> well it's based off X
<HrdwrBoB> NX, while when it's working is good, is still incredibly arcane
<spacey> :)
<HrdwrBoB> I have it working here, and it's not really ready for the wide world of installation and use by J random user
<spacey> but its pretty nice for terminal server project
<schweeb> HrdwrBoB: I have it working on solaris *shudder*
<HrdwrBoB> schweeb: ouch
<spacey> anyway i will have to implement it on a hoary install
<HrdwrBoB> spacey: it's not very hard
<schweeb> hrdwrbob: (desktop system at work)
<spacey> HrdwrBoB, good, saves me some time :)
<HrdwrBoB> schweeb: ah, we have two solaris machines here which are on a list for being removed and replaced with linux :)
<schweeb> good deal.
* spacey will migrate few primary schools from windows to linux
<schweeb> if I had the time to try to get debian or ubuntu on my blade 100 at work, I would
<spacey> pretty fun job
<spacey> we want to use a ubuntu hoary terminal server with freenx
<spacey> should be a nice result
<HrdwrBoB> based on my (limited) experience with it, it should work nicely
<spacey> time for bed, goodnight
<mae> hmm. is breezy going to have some sort of clipboard manager?
<daniels> spacey: nx changes all the X libraries
<daniels> spacey: it has its own libX11, branched from some ancient X version
<daniels> spacey: and they've made a heap of really weird changes, not all of which make any sense
<daniels> and since then we've also changed a lot about libX11
<daniels> the resulting diff would be a nightmare
<daniels> and I refuse on principle to support two completely different X codebases in main
<mae> hmm.. never heard of nx :)
<sladen> daniels: IIRC, a huge amount of the diff is doing things like zero'ing unused struct fields to aid transmission
<daniels> sladen: and also a whole bunch of other weird stuff.  the diff is big and ahiry.
<sladen> maybe I need to revisit it, it's been almost two years to the week since Fabionne(?) presented it at UKUUG
<daniels> it's also all-GPL, and there's no way I'm going to ship a partially-GPL libX11.
<sladen> ahhh.
<daniels> since, y'know, people seem to enjoy running X apps with non-GPL-compatible licences.
<eazel7> hi ppl
<bddebian> Hello eazel7 
<eazel7> hi bddebian
<eazel7> is breezy usable right now?
<bddebian> Works for me(tm)
<mdz> so long as you don't need, say, X
<Aegir> Heh
<eazel7> X is broken?
<mdz>  /topic
<Amaranth> well, xbase-clients is installable now, but it lost about 40 binaries
<poningru> anyone discussed the day light savings thing yet?
<Amaranth> which might come in handy :D
<eazel7> damn...
<bddebian> Hmm, maybe it's be quite a while since I upgrade then.. :-)
<Amaranth> i dunno how anyone working on breezy goals has managed without X
<ajmitch> Amaranth: selective upgrading helps
<Aegir> Amaranth, I read on Planet GNOME that their is a fix for the broken X issue.
<infinity> Lots and lots of chroots.
<Aegir> But I still dont have the balls to upgrade to Breezy
<Amaranth> heh
<Amaranth> i've always just made X work
<Aegir> Breezy bucked me off last time, it was probably easilly fixable, but eh, I like stability
<Amaranth> why chroot or hold back packages when you can hack it into working mode? :)
<eazel7> hope it works here 'cause I need it
<Aegir> eazel7, I doubt it will.
<Amaranth> It's guaranteed to not work if you're not already on it.
<Aegir> Make sure you have lynx and irssi installed though, you may need them
<eazel7> anyway, I'll try to get back to hoary's X if it doesn't work
<eazel7> but I need the latest dbus
<infinity> Going back is probably rather... Difficult.
<eazel7> yes, Marti McFly noticed me
<eazel7> ;)
<tseng> infinity: so did evo-sharp go to dep-wait now?
<infinity> tseng : I was just going to retry it later.  I'm up all day anyway.
<shackan> Amaranth, those 40 binaries include useless stuff like xcalc and xeyes ?
<Amaranth> shackan: probably
<Amaranth> shackan: and mkfontdir
<daniels> and xedit oh my god won't somebody think of the children
<daniels> the major ones are waiting on binary NEWing
<Amaranth> or was that xutils?
<daniels> Amaranth: mkfontdir came from xutils, iirc
<Amaranth> daniels: cool
<shackan> Amaranth, I hope we will get rid of them eventually :D
<daniels> apparently people still want to use xterm also
<crimsun> I haven't found a terminal emulator with better UTF-8 support than xterm
<Amaranth> err
<Amaranth> you mean uxterm?
<tseng> urxvt > *
<daniels> crimsun: g-t's utf8 support seems to be fine
<Amaranth> gnome-terminal works fine for me
<crimsun> daniels: I gave up with double-width Japanese characters some time ago and haven't tried again.
<crimsun> Amaranth: no, I mean xterm, though uxterm the shell script is fine.
<shackan> crimsun, just asking, what's the *.pdpc TLD your connection comes from ?
<Amaranth> shackan: it's a cloak
<crimsun> shackan: it's just a cloak signifying donation to PDPC. There's more info at www.freenode.net
<Amaranth> like mine is amaranth.user
<shackan> oh, ok sorry
<Burgundavia> have we reverted to the default upstream spatial?
<HrdwrBoB> I hope so
<Burgundavia> the latest nautilus changelog seems to indicate that
<infinity> \sh : 5 hours is not "sleep".  What's wrong with you?  Go back to bed.
<\sh> infinity: only 4
<shackan> you're definitely hurting yourself
<\sh> but it's ok...coffee is on its way
<\sh> my internal clock said: get up get up get busy ;)
<shackan> uhm, it's 4 am, I ought to go to sleep as well...
<\sh> infinity: u received my mail?
<infinity> \sh : Yeah, and I assumed I'd have about 8 hours to worry about acting on it.
<infinity> \sh : So, go back to bed.
<\sh> I will go to the shower after I had some coffee and go to the office :) 
<infinity> Deal.  frozenapps will be tidied up in a few minutes.
<\sh> hahaha..don't worry..take your time :) 
<\sh> but I see, riddell was also busy last night 
<Riddell> morning \sh 
<\sh> hey riddell..u should go to bed as well :)
<Riddell> yes, I should
<\sh> just updated the kde stuff from your buildd run...lets see what kdevelop is saying
<\sh> infinity: what was wrong with the buildds yesterday during business hours ,-)
<infinity> \sh : You may have to elaborate.
<tseng> mako: three brilliant posts in a row. new record?
<infinity> \sh : I can think of a number of things that have been wrong, owing to a few whacky transitions, and some mesa badness.
<infinity> \sh : Also, frozenapps updated, the unfrozen ones are on their way to the buildds.
<\sh> infinity: suddenly it was complaining about: please apt-get update ,-)
* infinity -> breakfast, lunch, and maybe dinner too.
* \sh is serving a nice freshly brewed coffee :)
<infinity> \sh : Yeah, there are some buggy packages in the archive I need to smack around with a big stick.  Just ignore build logs like those, they'll get retried when I find the right number of round tuits.
<\sh> good, so it wasn't me hitting the daemons to bad ,-)
<daniels> infinity: yay food
<bob2> oh, lunch time
* bob2 can thusly justify oporto
<HrdwrBoB> ooh oporto
<HrdwrBoB> I think I will have some
<daniels> hm
<eazel7> breezy is expected for september?
<daniels> it's almost tempting to pass through oporto on my way through today
<daniels> since I'll be within a block or two of QV (thus, Oporto)
<bob2> eazel7: 5.10 = october 2005
<daniels> but I have homemade steak and mushroom pie in the fridge, so
<eazel7> aah
<bob2> do it, do it
<eazel7> I didn't know that!
<bob2> ah
<tseng> is that a british thing?
* eazel7 's crossing fingers
<tseng> pies with meat
<bob2> they stole it from us
<bob2> in 1788 or so
<tseng> i found the ones in sydney quite unappetizing
<daniels> hah
<daniels> tseng: yeah, because you don't have jesters in sydney
<bob2> it's hard to find a good pie
<daniels> tseng: come down to melbourne and I'll show you a proper pie
<bddebian> Uhm
<tseng> the only similar thing in the states is chicken pot pie
<tseng> which can be excelent
<eazel7> I wouldn't take that suggestion
<eazel7> sounds me strange
<daniels> food can be either excellent or bad, news at 11
<tseng> i would simply postulate that strange aussie meat pies are more likely to be bad than not
<daniels> the ones you can get in milkbars and stuff are terrible
<bob2> perhaps you accidentally bought a "praerie oyster" pie
<daniels> they're literally made from random offcuts
<daniels> what you need to do is get a steak pie
<daniels> which actually has real chunks of beef in it
<daniels> and preferably also with mushroom
<bob2> and onion
<bob2> and red wine
<daniels> yeah
<daniels> this one's just steak + mushroom + carrots + thyme + puff pastry
<ajmitch> sounds interesting
<tseng> potentially edible
<HrdwrBoB> wtf? you don't have pies with meat?
<daniels> HrdwrBoB: only chicken pot pies
<HrdwrBoB> daniels: esp one that is upside down in peas
<daniels> but, I fear we've wandered far into the domain of off-topicness
<daniels> HrdwrBoB: UGH
<tseng> sorry, its nearly 11pm here
<\sh> ah yes..A nice 500gramm steak from a corn-fed beef....medium for me pls...and a nice mushroom sauce with some (what a culture) french fries + a heavy dark red wine from france or za...yes...welcome to the real world, neo
<tritium> daniels, every chicken pot pie I've ever ordered had no pot in it...
<bddebian> hahaha
<tseng> good night australia
<tseng> (and crazy european types)
<\sh> I heard that ,-)
<\sh> infinity: if you have time...please get rezound into the buildd run :) thx
<bob2> wtf
<bob2> someone posted to ubuntu-devel, via the forums, asking for help with some other distribution
<tritium> we get the occasional debian question in #ubuntu
<sladen> bob2: (a) all Linux is good Linux, (b) they may be so impressed with the service as to choose Ubuntu next time
<`anthony> bob2: crap. it used to work. oh well, will fix later.
<fabbione> morning
<bddebian> Morning fabbione 
<infinity> God, I want to pass out in the worst way..
* bddebian hands infinity some Nytol
<\sh> now I know how I can remember bddebians first name Barry...Barry "TheFlash" Allen ,-)
<bddebian> Heh
<bddebian> Just please, anything but Brian :-)
<\sh> I think I'd uploaded a sponsored by message with brian this morning..i'm not sure...
<bddebian> No worries
<\sh> no lucky ,-)
<\sh> infinity: thx btw for rezound...just fixed the last bit of crap in it..now it's building nicely
<infinity> \sh : NP.
<doko> good morning
<\sh> re
<pitti> Good morning
<\sh> hey pitti...so early? ;)
<pitti> \sh: why, that's my usual time :-)
<pitti> Hey JaneW 
<\sh> pitti: And mom Infinity tells me I have to go to bed at 2amUTC 
<\sh> lol
<\sh> good morning jane :)
<JaneW> morning pitti
<JaneW> hi \sh
<jsgotangco> hi JaneW 
<JaneW> hi jsgotangco 
<\sh> that was it for breakfast...3 bread rolles with chocolate pieces inside and another coffee...I'm happy...now I can work 
<\sh> elmo: please sync vflib3 from debian pls (see Ubuntu #12267)
<fabbione> mdz: ping?
<JaneW> fabbione, he doesn;t seem to be on-line...
<fabbione> JaneW: yup.. no biggie...
<Burgundavia> fabbione, is midnight here
<pitti> elmo: please sync krb5 (override ok)
<fabbione> Burgundavia: yup.. i know.. but sometimes he is awake longer
<Burgundavia> pitti, how would I go about requesting a uvf breakage? 
<pitti> Burgundavia: ask Kamion and/or mdz; if it's universe, ogra's ack is probably sufficient
<Burgundavia> pitti, tis main, Inkscape and Screem
<pitti> elmo: please sync cacti
<pitti> elmo: please sync bugzilla (new upstream microrelease with two security fixes, universe)
<{Seb}> now the feature freeze has occured, will the kernel be updated again?
* mode/#ubuntu-devel [+o fabbione]  by ChanServ
* mode/#ubuntu-devel [+b *!*@196.36.161.*]  by fabbione
* mode/#ubuntu-devel [-o fabbione]  by fabbione
* mode/#ubuntu-devel [+o fabbione]  by ChanServ
* chmj was kicked off #ubuntu-devel by fabbione (Banned)
* marilize was kicked off #ubuntu-devel by fabbione (Banned)
<fabbione> ops
* mode/#ubuntu-devel [-b *!*@196.36.161.*]  by fabbione
* mode/#ubuntu-devel [+b *!*@195.137.120.*]  by fabbione
* mode/#ubuntu-devel [-o fabbione]  by fabbione
<Treenaks> ride the channelmodes
<fabbione> i realized 2 secs too late i added the wrong ban :)
<Treenaks> "oops"
<Treenaks> oh well
<\sh> fabbione: whats up with seb?
<fabbione> constantly off-topic
<fabbione> harassing devels
<\sh> well yes
<fabbione> he has been warned tons of times
<Burgundavia> in other news, Hosting Geek got banned from another channel I follow
<fabbione> in several polite ways
<Treenaks> \sh: read Planet Suse for his opinions on Ubuntu :)
<fabbione> gotta go
<fabbione> bbl
<thom> fabbione: dude, that's a very global ban...
<\sh> Treenaks: planet.suse.?
<\sh> com?net?org?
<Treenaks> \sh: planetsuse.org
<fabbione> thom: nah.. it's a C class
<pitti> elmo: Hey seb128 
<Treenaks> the original seb :)
<fabbione> thom: welcome to refine it if you like :)
<fabbione> i am not jalous of my bans
<fabbione> i realy gotta go
<fabbione> later
<pitti> elmo: I collected the bunch of syncs requests: squirrelmail, cacti, krb5 (override ok), bugzilla (new upstream microrelease with two security fixes, universe); thanks 
<\sh> Treenaks: lol...this guy is 16 ,-) no wonder
<\sh> Treenaks: and he'
<\sh> 's sitting without some pants on in front of a camera...*lol*
<Treenaks> \sh: 8-|
<seb128> pitti: hi :)
<\sh> oh sorry..short pants..but anyway
<Treenaks> \sh: *shudder*
<\sh> well...lets see if in #kde-devel some kwave guys are
<trulux> \sh: who?
<trulux> \sh: that's scaring
<\sh> trulux: i have some asm bugs in kwave on amd64...and the supplied patch doesn't work
<\sh> http://www.voresoel.dk/ <- the beer for oss hackers *lol*
<marcin> hi developers
<marcin> I have pretty simple question
<marcin> I would like to create package with single .el file (for emacs)
<marcin> and my question is - do I need to put this single .el file into tar.gz
<marcin> because when trying dh_make with -f ../somefile.el then I got error on dpkg-buildpackage (empty somefile.orig.tar.gz)
<Treenaks> yes
<JaneW> any idea what if anything has happened to the BreezyGoal ServerInstallation?
<marcin> Treenaks, hmm then howto create package with files from cvs are there any docs/samples how to do this?
<Treenaks> marcin: there's cvs-buildpackage
<Treenaks> marcin: maybe it can help you?
<marcin> Treenaks, hmm maybe
<marcin> Treenaks, but first I need to understand how this guy: http://usefulinc.com/edd/notes/CVSEmacsOnDebian builds snapshot packages with regular dpkg-buildpackage
<Treenaks> marcin: you can do that too
<Treenaks> marcin: there is a lot of packaging HOWTOs etc. on debian.org
<marcin> Treenaks, yes I know - reading maint-guide now but propably the best learning path is by reading some code from existing packages
<Treenaks> marcin: apt-get source a lot :)
<marcin> Treenaks, sure... in fact I didn't know that packaging for debian/ubuntu is so complicated :/
<marcin> Treenaks, and especially _overcomplicated_ for emacs packages...
<Treenaks> it's not really complicated.. all you need is a directory with source and a debian directory with ruled, changelog and control files (and maybe some more if you need them)
<Treenaks> marcin: emacs is overcomplicated anyway :)
<Treenaks> ruled=rules
<marcin> Treenaks, control,changelog etc are pretty simple 
<marcin> Treenaks, the only thing that is pretty scarry for me is this 'rules' thing
<Treenaks> marcin: it's just a makefile
<marcin> Treenaks, 'just'... oh how much I hate autotools ;)
<Treenaks> marcin: that's why it's not an autotools makefile ;)
<Treenaks> marcin: (no rules.am/rules.in/rules crap ;))
<marcin> Treenaks, right it look simmilar to garnome scripts
<marcin> s/look/looks
<Treenaks> marcin: the make infopages might be helpful
<marcin> Treenaks, well syntax is pretty simple but I don't like it anyway, it is hard to understand
<Treenaks> marcin: it's makefile syntax.. it's not very hard.. it's "target: depends1 depends2 [etc] ", and those depends should be filenames and/or other target names
<marcin> Treenaks, yes as I said - syntax is simple
<marcin> Treenaks, but things are complicated when you have a lot of targets etc.
<marcin> Treenaks, anyway I'll try to deal with it
<marcin> Treenaks, there are perl/autotools/m4 lovers and xml/xslt/ant/python lovers too ;)
<\sh> hmmm...any asm guru online? :)
<Treenaks> \sh: mov ax, 0x1234; int 0x21
<\sh> Treenaks: ok..please fix http://people.ubuntu.com/~lamont/buildLogs/k/kwave/0.7.3-2ubuntu3/kwave_0.7.3-2ubuntu3_20050725-0819-amd64-failed.gz
<\sh> ;-)
<\sh> it should be easy
<\sh> not for me, he :)
<\sh> Treenaks: but what u wrote is a DOS interrupt...
<Treenaks> \sh: yeah, last time I asm'ed was in DOS
<seb128> daniels: hey. Have you read what I said yesterday about xrdb ?
<\sh> I tried to avoid asm..but not on 6502/6510
<daniels> seb128: i think it just needs a newer libxmu-dev
<seb128> k, just pointing it FTBFS
<daniels> yeah, ta
<sivang> seb128: Hello
<seb128> I got a complain from a GNOME guy, he was getting an empty warning dialog
<seb128> he fixed it by building xrdb and installing it
<seb128> daniels: should an upgrade  from -33 to current xorg go fine? I've not updated since it's b0rked 
<seb128> hi sivang
<sivang> seb128: an news for lp integration?
<daniels> seb128: you could do wonders for my productivity by fixing rhythmbox:
<daniels> daniels@brainfreeze:~/canonical/xorg/app/xrdb/xrdb-7.0% rhythmbox
<daniels> rhythmbox: error while loading shared libraries: libtotem-plparser.so.0: cannot open shared object file: No such file or directory
<daniels> zsh: exit 127   rhythmbox
<daniels> seb128: yeah, provided you reinstall xkeyboard-config with --force-confmiss once you're done
<daniels> seb128: and bah, dude, I already fixed that empty warning dialog on gdm
<seb128> daniels: apt-get install libtotem-plparser0 ?
<seb128> how did you do that?
<daniels> seb128: quote your arguments to zenity
<daniels> i've just fixed it *again*, uploading now :P
<seb128> yeah
<seb128> the "how did you do that" was for rhythmbox, but thanks, this one is useful too :)
<seb128> rb depends on totem-gst | totem-xine
* seb128 kicks himself, need to dropped
<seb128> and those should Depends on libtotem-plparser0
<seb128> daniels: dpkg -l rhythmbox totem\* libtotem\* ?
<seb128> sivang: current baz doesn't build here and is required to get working patches, there is some new functions
<sivang> seb128: ah ok, I think I saw that build error, are you referring to make[2] : *** No rule to make target `/config.status', needed by `Makefile'.  Stop.
<daniels> dpkg: dependency problems prevent configuration of totem-gstreamer:
<daniels>  totem-gstreamer depends on xlibs (>= 4.2.1-9); however:
<daniels>   Package xlibs is not configured yet.
<sivang> ?
<daniels> SEB
<daniels> seb128: please just drop that xlibs Depends *entirely*
<seb128> daniels: k, will do
<seb128> sivang: correct
<sivang> seb128: k
<daniels> seb128: thanks
<seb128> np
<ogra> does anyone know a source for pxe/etherboot images that can boot pcmcia cards ?
<daniels> oh seeeeebbbbbbbb
<daniels> seb128: rhythmbox segfaults in g_main_context_iterate
<seb128> grumpf
<seb128> please open a bug with the full bt 
<daniels> moving ~/.gnome2/rhythmbox out of the way fixes it
<daniels> the full backtrace is useless, the stack is smashed to buggery
<daniels> unless it really does make calls 2000-odd deep and malloc really does invoke g_main_context_iterate :P
* Kamion pokes siretart for uploading -build1 rather than just requesting a sync
<seb128> nop :p
<daniels> segfault in g_main_context_iterate -> iz gtk boog :P
<ogra> Kamion, at least it will be overridden with the next sync...
<Kamion> I know
<ogra> so its just ugly but not evil :)
<Kamion> \sh: please use the -v option to dpkg-buildpackage/debuild to include full changelog information since the last Ubuntu upload in your .changes file
<Kamion> when merging
<infinity> \sh : Care to hazard a guess as to why cln is FTBFS on ia64?
<Kamion> (probably goes for most people but I particularly noticed it today from \sh because he uploaded lots of merges over the weekend :))
<mdke> [OT]  question, but has anyone tried to send their laptop testing agreement by fax? I tried but there was no fax machine on the other end...
<siretart> Kamion: this is evil after all? I asked twice if this was ok
<daniels> siretart: if you just need a version from debian, ask elmo to sync it
<siretart> Kamion: I wanted to reduce load from elmo. But will poke elmo in future if that's the correct procedure. ok
<siretart> daniels: he must have a biiig backlog, I didn't mean to do any harm
<Kamion> siretart: as ogra says it's not evil, but it makes life harder for people trying to see what our diff against Debian is
<Kamion> so it's somewhat better to just sync
<daniels> siretart: no harm done
<siretart> Kamion: ah, I see. ok. will do in future. That must have only been one or two uploads, I think..
<Lathiat> mdke: hrm no havent tried yet
<Kamion> yeah, didn't see a lot of them
<Lathiat> mdke: email claire and ask?
<mdke> Lathiat, i got an answerphone at the other end over the weekend
<mdke> Lathiat, will do
<Lathiat> mdke: i nearly deleted that email
<Lathiat> mdke: it just said "Congratulations" with a person i'd never heard of 
<Lathiat> mdke: something made me stop and check it.. who knows what.
<siretart> mdke: the number on the agreement pdf was a phone line, in the email the number given is indeed a fax
* infinity wonders if perhaps he got one and deleted it as spam..
<Lathiat> perhaps someone should suggest to claire to send a confirmation email
<mdke> siretart, ah great, thanks!
<Lathiat> with a better subject 
<mdke> siretart, i'll retry that then.
<Lathiat> mdke: ah yeh, there was a fax in her signature
<Kamion> mdke: she's not typically in the office over the weekend ;-)
<mdke> Kamion, well i thought she might leave the fax machine there tho
<mdke> Kamion, np, siretart has cleared it up
<Kamion> ah, well, true, I'd expect so
<sivang> Kamion: do you know if the laptop testing (or could get the info) team decision are over by now? (I apologize in advance if you have nothing to do with it)
<Kamion> sivang: I've nothing to do with it and have no idea. :-)
<sivang> Kamion: kthxanyway :)
<daniels> infinity: could you please kick xrdb when the new libxmu is in the archive?
<infinity> daniels : Sure.  I'm guessing we've hunted down most of the obvious missing deps by now, but maybe it'd be good to go back over every lib you've modularised at some point and make sure they're all san
<daniels> infinity: i did that for a few of them before I went back to beating the monolith up
<ogra> infinity, hey
<ogra> infinity, will your php5 packages already contain gd and imagemagick bindings ?
<infinity> ogra : gd, yes, imagemagick, no.  imagemagick isn't shipped in the upstrfeam tarball.  It's trivial for me to package it out of PECL though, if we need it.
<ogra> i'm still pondering if i package mediawiki with 4 or 5 .... imagemagick is a dependency...
<infinity> ogra : Packaging PHP extensions takes a matter of minutes, so don't let that stall your decision.
<ogra> oki
<ogra> thanks :)
<sivang> ogra: are you preparing PHP5 pakcages? :-)
<ogra> nope
<ogra> sivang, infinity does....
<sivang> infinity: right, considering they are mere .so right?
<infinity> sivang : Well, simple build system, well-established debian/ dir I can poach from my other packages, that sort of thing. :)
<sivang> infinity: nice, so are there already php5 pakcages?
<infinity> sivang : Will be uploaded tonight, right after I catch up on a few other breezy goals I promised mdz.
<infinity> I think I'll just sleep right through Wednesday to make up for it.
<ajmitch> infinity: it's planned for main?
<daniels> infinity: gasp!  missing a day?
<daniels> infinity: slacker.
<sivang> infinity: cool
<infinity> ajmitch : If I talk fast enough.
<HiddenWolf> infinity, daniels, sivang, LOL
* ogra reboots to a ltsp thin client... (hopefully)
<HiddenWolf> I guess it didn't go well for ogra
<infinity> \sh : ghemical and gtklookat are FTBFS on all arches, looks like they need some gcc-4.0 love.
<siretart> Kamion: could you have a look at http://bugzilla.ubuntu.com/show_bug.cgi?id=12536 ? I think only you can fix this (but I may be wrong)
<Kamion> siretart: in general please ask elmo about such things first; I only do it when he's away
<Treenaks> is anyone in The Netherlands this week (before WtH)?
<siretart> Kamion: ah, I didn't know. Will do in future. sorry for the noise
<Kamion> I've reassigned to him
<siretart> ok
<mako> Treenaks: i'm there now
<mako> Treenaks: in eindhoven
<Treenaks> mako: cool
<Treenaks> mako: though I'm in Amsterdam :)
<siretart> hi mako 
<mako> Treenaks: well, i'd like to see amsterdam
<Treenaks> mako: When are you coming? :)
<mako> Treenaks: coming where?
<Treenaks> mako: to Amsterdam :)
<mako> to amsterdam? no idea yet
<Treenaks> mako: tell me when you know :)
<mako> Treenaks: i went to utrecht yesterday
<mako> tonight there is a free software eindhoven meeting
<HiddenWolf> mako, utrecht, of all places? :)
<HiddenWolf> managed to get lost in the train station? ;)
<mako> HiddenWolf: there was a debian meeting in utrecht.. i quite enjoyed the city actually
<pitti> l
<pitti> sorry, EWINDOW
<HiddenWolf> mako: the city is nice, the station is horrific. :)
<mako> HiddenWolf: yes, this is true.. but i met locals in the station :)
<HiddenWolf> mako, where else are you going?
<ogra> yay, my mediawiki package works ! :)
<sivang> ogra: cool
<ogra> there is one drawback .... you still have to copy the config to the wiki dir manually... but i'll leave it this way so debian can use the package too :)
<sivang> ogra: does it depend on php5 or 4 ?
<ogra> sivang, the current package is php4 ... depending if i can switch moodle to php5 too it will be 5 ... i just dont want two php versions in edubuntu.... so it will depend on moodle...
<sivang> ogra: sure, that figures
<mako> HiddenWolf: well, i don't know.. i'm going to what the hack this week
<HiddenWolf> mako, way cool. 
<Treenaks> HiddenWolf: with this weather?
<HiddenWolf> Treenaks: As long as you stay inside a city, yeah. Nice and cozy. I wouldn't want to be managing a lan somewhere in the middle of nowhere, no. ;)
<infinity> kamion, elmo : Whoever pushed the xkbutils binaries through NEW first will probably have the undying love of everyone here.
<daniels> (and xauth, and xinit)
<eazel7> I have a doubt, why ubuntu doesn't optimize all it's packages?
<daniels> (and xrdb still, I think)
<daniels> eazel7: it does
<eazel7> daniels, I mean, for 586
<Treenaks> daniels: not Gentoo-ishly so though :)
<eazel7> I see the kernel, and the libc, and mplayer
<eazel7> but not all the packages, is that useless?
<Treenaks> eazel7: Ubuntu packages are (afaik) still optimized for P4 CPU's, but work down to i486 CPUs
<HiddenWolf> Treenaks: why put in the extra effort for no reasonable gain.
<Kamion> infinity: wasn't me
<eazel7> aha, didn't know that was possible
<Treenaks> eazel7: man gcc :)
<eazel7> I'd rather to solve a maze... 
<Kamion> we don't create separate packages for them because that really *is* detrimental (significant extra index file download time for users)
<Kamion> and we don't rename them because (a) it's confusing and (b) it would be very significant desynchronisation with Debian that ... well, would be confusing
<infinity> Kamion : s/pushed/pushes/  See the bit about me needing sleep.
<eazel7> ah, ok
<eazel7> is redcarpet open source?
<daniels> yes
<eazel7> I can't find the client source
<daniels> ... how is this relevant to #ubuntu-devel?
<eazel7> well, I'd like to try to adapt redcarpet to apt
<Kamion> infinity: NEW's empty, so same answer applies :)
<tseng> eazel7: look for open carpet
<tseng> iirc it already did apt at some point in time
* jortega is back (gone 231:06:10)
<trygvebw> Oo
<tseng> infinity: any idea why libapache2-mod-auth-kerb exists in debian for some time but seemingly not ubuntu?
<hadess> yup
<hadess> pitti: around?
<pitti> Hi hadess 
<pitti> nice to see you again; what's up with storage management?
<hadess> storage management? :)
<hadess> i think you have the wrong guy there
<pitti> oh, sorry
<pitti> mixed that up
<hadess> no worries
<hadess> i wanted to know whether the guy responsible for the bluetooth support SoC bounty came back to you
<pitti> hadess: Pablo Durante? well, he reported back recently, but he didn't have something to present so far
<eazel7> tseng, I've been in open carpet
<eazel7> tseng, I was looking for the client
<pitti> hadess: however, chmj handles the technical side now since I don't have bt
<hadess> pitti: ha, ok
<hadess> pitti: good to know he reported back, i haven't seen activity from him on any mailing-lists, apart from him asking for C++ API docs for bluez back in june
<daniels> Kamion: both -2 and -3 built successfully (xkbutils), and -2 some time ago, but the archive's still empty ...
<daniels> Kamion: they got source-NEWed in one big hit, but don't think they got binary-NEWed
<hadess> chmj: do you know how far pablo (or is it paolo) durante got with his bluetooth work?
<Kamion> daniels:   xkbutils |      7.0-3 |        breezy | source, amd64, i386, ia64, powerpc
<Kamion> daniels: cron.daily's still running
<chmj> hadess: he is busy with dbus at the moment, so he still doesn't have much
<pitti> hadess: I saw him asking for hal stuff on the utopia list
<pitti> oh, that reminds me of something
<pitti> ogra: hal+hwdb? :-)
<ogra> pitti, yes.. this week (apparently, since we have freeze on Aug 11th)
<ogra> pitti, i had still some outstanding edubuntu stuff in the way
<jani> elmo you know what the status of the mercurial package is? It is in sid but not in breezy.
<ogra> jani, are you aware of the xfce4 merge bugs ? 
<jani> Yes I am, I am talking to os-works upstream and debian folks
<jani> to see which one to sync
<jani> we synced from os-works for hoary
<jani> they are taking our ubuntu1 changes
<ogra> jani, please close them after the sync... the merges were supposed to be finished on Jul 21st
<jani> but the debian folks started diverged
<jani> ogra, I know, I'll close them but still didn't decide which source to sync from
<jani> need to talk to crimsun, and to settle with the debian xfce team
<ogra> jani, yes, i understand this.. just wanted to point out the bugs, so they dont stay open... 
<jani> We have to mediate between two non-communicating upstreams duplicating work
<ogra> heh
<ogra> no fun i guess
<jani> sure, thanks, in fact I didn't know there were bugs
<jani> I was only aware of ongoin-merge on scott's page
<jani> malone?
<ogra> nope MOM bugs are in bugzilla... see the topic in #ubuntu-motu ... there is a link
<jani> ok, thanks
* netjoined: irc.freenode.net -> kornbluth.freenode.net
<pitti> seb128: ximian-connector and evolution-exchange both ship the translation domain evolution-exchange-2.4. Shall I just ignore ximian-connector?
<carstenh> we have freeze in two weeks. it it possible that firewall-rules, which should be added to every package that provide a daemon will be added after the freeze?
<pitti> that's pretty intrusive
<pitti> carstenh: how many packages would this actually affect?
<pitti> carstenh: and wouldn't it be better to ship the rules in the firewall package itself?
<carstenh> pitti: didn't count them
<carstenh> pitti: good point
<pitti> so you could adapt them more easily
<pitti> and in theory other firewalling systems are possible
<carstenh> pitti: but it wolud make configuration more complex, as there are many packages listed that are not installed
<pitti> carstenh: it's easy to determine whether a daemon is actually installed
<carstenh> pitti: sure, so this should not be a problem
<pitti> carstenh: eventually it could make more sense to ship the policies in their respective packages
<pitti> carstenh: but not for breezy, I guess
<seb128> pitti: ximian-connector is to drop from the archive
<pitti> seb128: thanks
<seb128> pitti: evolution-exchange is the new name of the package
<carstenh> pitti: ok, thanks
<carstenh> pitti: what about universe, should packages in universe also provide rules in breezy+1?
<fabbione> hey jbailey 
<pitti> Hi jbailey 
<pitti> carstenh: there comes your primary mentor :-)
<carstenh> hi jbailey 
<fabbione> jbailey: #12942. kthxbye :P
<jbailey> Heya Fabio!
<jbailey> Hi Martin
<jbailey> carstenh: =)
<jbailey> Carsten. =
<jbailey> )
<fabbione> jbailey: back from OLS?
<jbailey> fabbione: Yup.
<carstenh> jbailey: should I paste you the last logs of the last few minutes?
<jbailey> Finished my morning apt-get, beating X into working again, and ready for work. =)
<fabbione> jbailey: did you have fun?
<jbailey> carstenh: Ummm.  Depends.  Do you think it would be interesting to me? =)
<carstenh> jbailey: yes :)
<jbailey> carstenh: Then yes. =)
<seb128> jbailey: hey
<jbailey> fabbione: Lots.  Learned alot as always.  Now I'm just hoping that the alcohol didn't kill *those* cells.
<jbailey> M. seb
<fabbione> jbailey: ehehehehe
<jbailey> fabbione: On Saturday night, the last person left my room at 04h50. =)
<carstenh> jbailey: http://paste.debian.net/1313
<seb128> jbailey: do you still have your evince bug on ppc? could you rebuild poppler without cairo and note if that fixes the issue?
<doko> seb128: do you have an estimate for cairo 0.6?
<carstenh> jbailey: so what do you think about a) shipping rules in ubuntu-firewall for breezy b) rules for packages in universe?
<jbailey> carstenh: It might make sense to put the firewall rules in your package for breezy and push them out after that.
<jbailey> Just that way you remove some of the time crunch.
<seb128> doko: really soon
<seb128> doko: this week
<seb128> doko: why? any issue with 0.5.2 ?
<jbailey> seb128: The bug appears to still exist, yes.
<jbailey> seb128: Which evince 0.3.2-0ubuntu1
<jbailey> s/Which/With/
<seb128> jbailey: k, can you rebuild poppler without cairo ? :)
<carstenh> jbailey: what about restarting the firewall if a package is installed?
<seb128> jbailey: just change the debian/rules cairo option
<carstenh> jbailey: if i provide the rules and don't touch i.e. apache i don't think it is possible
<jbailey> seb128: Yes, dear.
<seb128> jbailey: thanks
<jbailey> carstenh: Right, that sucks.
<doko> seb128: just to have only one gcc-4.0 upload
<jbailey> carstenh: I think it  would be sad to shove that into the 'futures' category, but it might be necessary.
<jbailey> We need a google 'spring of code' =)
<carstenh> jbailey: we could use /etc/apt/apt.conf.d/, but only if packages are not installed with dpkg -i
<jbailey> Right.  Using apt configs are really an option there.
<jbailey> I don't think dpkg has hooks.
<jbailey> Keybuk: *poke* ?
<carstenh> jbailey: just for breezy, will be fixed in breezy+1
<jbailey> seb128: Have to upgrade my build-machine, it'll be a moment.
<carstenh> jbailey: what about universe, should it be supported too?
<seb128> jbailey: no hurry, that's just to know if building without cairo fixes the issue
<jbailey> carstenh: No, not if you're taking on all the packages.
<jbailey> It would be something that advertise that universe could support, but it's a rats nest you really don't want to chase.
<eazel7> gonna test breezy with the downgraded X
<eazel7> bbl
<jbailey> I'd say far better to take the top 5 or 6 most popular packages in universe and do them up as an example.
<ogra> carstenh, at least provide a HOWTO for MOTU to adjust the universe packages if desired
<carstenh> ogra: good idea, thanks
<ogra> :)
<carstenh> jbailey: ok, lets go to the next point :) what about the service-config-tool?
<carstenh> jbailey: should i be integrated in firewall-gui or should it be an  extra tool
<sivang> carstenh: do you mean services-admin?
<carstenh> sivang: yes
<carstenh> sivang: writing one is part of my bounty
<sivang> carstenh: ah :) Well, I thought you were referring to the already available one
<carstenh> sivang: no :)
<sivang> carstenh: take a look at it, might get you some ideas maybe, run services-admin and see
<carstenh> jbailey: if it shuold be extra, would services-admin adequate, should i try to port confiog-system-services or write a new one?
<carstenh> sivang: yes, looks good :) i will have a closer look at it at least because of their database, imho all services-config-tools in ubuntu should use the same
<sivang> carstenh: yes, it also follows a "role
<sivang> carstenh: based approach, rather then specific program approach
<sivang> carstenh: you might want to use the backends as well, if only to provide a better GUI
<sivang> carstenh: (that would enable you to have unified control)
<carstenh> sivang: originally i planned to use the backend from rcconf, but that was before i knew that ubunutu now has servicees-admin
<sivang> carstenh: It was a more maintained module of the gnome system tools once, and now regained life due to it's maintainer putting some work into
<sivang> carstenh: so it went under code cleaning, role based configuration and I *think* modularization of the backends
<carstenh> sivang: oh, did not know that it existed before :)
<sivang> carstenh: neither did i :-)
<sivang> carstenh: I worked before hoary on the users-admin module, and so got to know the principle maintainer (you can meet him at #gst in the gimp net) so I know *bits* of stuff about g-s-t and the backends
<sivang> carstenh: if you need anything, please feel free to ask me :)
<carstenh> jbailey: s/confiog-system-services/system-config-services/
<mdz> morning
<jsgotangco> morning mdz
<ogra> hey mdz 
<pitti> Hi mdz 
<sivang> hey pitti , morning mdz
<carstenh> sivang: ok, thank you very much. i don't think i will need something, because i dropped all plans about integrating my gui in gst
<ogra> mdz, mediawiki packages are ready and running... but i'll wait for infinity to see if i can move them to php5 before uploading to the archive
<sivang> carstenh: ok, np :)
<mdz> ogra: ok
<jsgotangco> mdz: about pda testing, i'd rather settle for what's in main now for lack of time, a good baseline support for us though...
<mdz> jsgotangco: what's in main now? not much
<mdz> basically gnome-pilot, no?
<jsgotangco> mdz: sync to evolution as well...but multisync holds promise but may have to test for other possible dependencies that won't be able to go to main for lack of time..
<azeem> multisync never worked reliably, AFAICT
<jdthood> carstenh: I just saw the discussion about a service manager.  I have just spent two weeks working with the author of the "bum" package.  It is a GNOME services manager.
<jsgotangco> azeem: right...
<jdthood> carstenh: It is in Debian NEW and will also be included in Ubuntu.
<carstenh> jdthood: ok, thanks
<carstenh> jdthood: do you know if it uses the same database as services-admin?
<jsgotangco> azeem: weird though, is that 2 of my PPC devices get to sync with multisync albeit bad output
<jsgotangco> azeem: while the rest of my palms dont
<azeem> I'm not sure multisync works with PalmOS4 devices
<Treenaks> azeem: I have a PalmOS 4 palm
<jdthood> carstenh: I am pretty sure that it does not.
<Treenaks> so I could try
<azeem> or whenever the new set of apps (Contacts vs. Adresses) got introduces
<carstenh> jdthood: a SyS-V service configuration tools nneds to store something like 30 20 cfsd
<azeem> introduced, even
<carstenh> jdthood: if it does not imho one of the two tools should be dropped from ubuntu
<jdthood> carstenh: Yes, and bum uses its own files.  Likewise sysv-rc-conf uses its own files.
<carstenh> jdthood: users may use one tool to disable a service and the other one to enable it
<carstenh> jdthood: this really sucks :(
<Keybuk> jbailey: 'sup?
<azeem> 15:19 < jbailey> I don't think dpkg has hooks.
<carstenh> jdthood: users will be very confused about it
<Keybuk> "hooks" ?
<ogra> jdthood, its more likely we'll use the g-s-t tool then bum...
<azeem> triggers, I guess
<Keybuk> no, it doesn't have anything like that
<jdthood> Everything I have ever tested in g-s-t sucks and suck hard.
<ogra> jdthood, as long as bum offers opportunitys like shutting down udev, hotplug and other essential services its not really feasable...
<carstenh> jdthood: :-)
<jdthood> ogra: I doesn't allow shutting off scripts in rcS.d any more.
<sivang> jdthood: is BUM going to be the *official* service tool?
<ogra> oh, thesaltydog refused to change to a dumbed down interface last time we spoke
<jdthood> sivang: I don't know.  I just worked with the author to make sure that bum works correctly.
<jdthood> Most service configurers will mangle one's sysv-rc runlevel configuration.
<sivang> jdthood: as far as I know (which ma not be much all in all :) ) g-s-t is the official most-of-tasks gui admin tool :-)
<sivang> jdthood: (for gnome upstream)
<jdthood> GNOME upstream is geared toward a distribution that isn't Debian.
<ogra> jdthood, the author worked thight with mvo iirc... they had some long discussions at guadec
<jdthood> The author of g-s-t service-admin?
<ogra> jdthood, yes
<ogra> jdthood, canacho iirc
<ogra> or garnacho
<azeem> the latter
<Treenaks> gaspacho?
<ogra> haha
<ogra> good appetite :)
<Kamion> carstenh: why does *either* of them need a database? The "database" should be the positions of the rc symlinks in /etc/rc?.d, or the corresponding file-rc configuration, or whatever.
<jdthood> The very _first_ operation I attempted using g-s-t services admin did not work properly.   https://bugzilla.ubuntu.com/show_bug.cgi?id=12776
<ogra> Kamion, for descriptions
<ogra> Kamion, like "a powerful webserver" for apache ...
<ogra> :)
<jdthood> Kamion: If you disable a service you need to remember its "start" sequence number somehow.
<carstenh> Kamion: this is imho not possible. cfsd is started in something like /etc/rc2.d/S30cfsd, if i disable it where shuold the priority "30" be stored?
<Treenaks> ogra: isn't that part of the LSB-comment thingies in the first part of the file?
<ogra> Treenaks, yup... but not all services have this yet....
<Amaranth> hrm, i should have had hubWE send that CD after all
<jdthood> Besides, the idea of storing sequence numbers in the initscripts is braindamaged.
<Kamion> jdthood: It would be trivial to invent a way to store that in the filesystem too.
<Amaranth> the one i was supposed to be getting last night didn't come through and now i'm without my computer for at least a whole week
<carstenh> imho there should be a database that all service-config-tools use, i.e. /var/lib/services/database
<Kamion> Only if it's accessible from the command line too.
<jdthood> Kamion: However the information is stored, the problem is that different tools do it differently.
<carstenh> Kamion: it is so trivial, that everyone which writes such a tool invents a new way :/
<Kamion> jdthood: sure. All I'm asking is what the point of a separate database (that one needs special tools to edit, etc.) is.
<jbailey> azeem: Thanks, had to run to a phone call.
<jdthood> Kamion: You are suggesting using parallel rc.d directories as a way of remembering the sequence numbers?
<Kamion> jdthood: no?
<jbailey> seb128: Do I just remove  --enable-cairo-output  ?
<Kamion> some other letter would do just fine
<jdthood> Kamion: I am sure it would be possible.
<Kamion> but in any case I wasn't suggesting any particular implementation, just anything that doesn't involve another silly hard-to-edit database
<seb128> jbailey: yeah, that should do the trick (look for the ./configure summary to be sure)
<carstenh> Kamion: you just found the reason why System V sometimes sucks :/
<Kamion> carstenh: no I didn't
<fabbione> mdz: yo
<fabbione> hey Kamion 
<carstenh> Kamion: ok, if you have a good solution for this i will be glad to hear it :)
<Kamion> carstenh: I just suggested one above
<fabbione> Kamion: can you please new libaio ?
<Kamion> fabbione: is elmo not around? he's been NEWing stuff today.
<fabbione> oh..
<fabbione> haven't noticed
* Kamion does not want to turn into the regular ftpadmin
<fabbione> i come back 30 minutes ago from a lot of Ubuntu love
<fabbione> Kamion: yes i understand.. 
<fabbione> don't worry and sorry
<fabbione> elmo: ? :)
<jdthood> Kamion: It's not a bad idea.  Something like?:  For service foo, update-rc.d would install both "start" and "stop" symlinks for services with the right sequence numbers.  Enabling a symlink would consist of unhiding it (removing initial '.').
<carstenh> Kamion: oh, you are right, i did not see this. using lowercase letters is common for this way disabeling services
<jdthood> ... or would consist of capitalizing its first letter.
<Kamion> jdthood: that would be reasonable, yes (or lowercase letters, as carstenh suggests). As you point out, the problem is much more one of getting everyone to use the same scheme than of inventing a workable scheme.
<jdthood> Kamion: Right.
<marcin> hi all where can I find help for jde package (java development environment for emacs) it's not installable on hoary
<ogra> jdthood, i dont think such a UI is something we want http://www.marzocca.net/Immagini/bum2_new.jpg its terribly confusing...
<Kamion> alternatively, for rc[0-6] .d packages you could just s/S/K/ to enable and s/K/S/ to disable?
<Kamion> er, "initscripts", not "packages"
<fabbione> carstenh: ping?
<carstenh> fabbione: pong
<fabbione> carstenh: can i bother you a few minutes?
<jdthood> ogra: TMI, eh?
<carstenh> fabbione: sure
<eazel7> got into breezy, with X downgraded, but latest 686 kernel didn't boot
<ogra> jdthood, TMI ?
<fabbione> carstenh: thanks
<jdthood> ogra: "too much information"
<jbailey> carstenh: I'm not sure how the existing services-config-tool works, so I don't have an idea off hand,  What are your thoughts so far?
<ogra> jdthood, if my mother can start/stop a service with such a tool without getting scared away its fine...
<jdthood> ogra: There is less detail on the "Summary" tab which is what is shown by default.
<ogra> jdthood, the fact that there are tabs at all is what i'm criticizing... and that one tab talks about "runlevels" 
<ogra> jdthood, this tool might be ok for a admin, bu not for a standard user
<jdthood> Anyway, I was only involved in critiquing the correctness of the program, not as a usability guy.
<carstenh> jbailey: the main advantage of a own service-config-tool would be a proper integration in the firewall
<carstenh> jbailey: but we dropped such plans (at least for now)
<jdthood> ogra: g-s-t's interface is indeed simpler.
<ogra> yep
<carstenh> jbailey: so what you you want to archieve with a own service-config-tool?
<ogra> jdthood, thats my concern :)
<jdthood> However, I don't trust g-s-t.  Every time I try it it screws up my configuration files.
<carstenh> jbailey: if you can answer this question i could suggest something :)
<jdthood> Look at all the bug reports filed against the network-admin component.
<jdthood> The authors don't respond to bug reports in a timely fashion.  They seem to have no clue.
<carstenh> jbailey: just implementing another one does not really make sense. and we had to use the database from the standard srv-cfg-tools
<jbailey> carstenh: You mean from the introduction of http://udu.wiki.ubuntu.com/Firewalls ?
<carstenh> jbailey: yes
<carstenh>  potentially extend the network tool or create another tool to allow services to be activated or deactivated <- this is already in ubuntu now
<marcin> hi I'm just looking on your conversation for a few minutes and I think that you touch extremely important problem
<carstenh> jbailey: but i can write or port another one, if you think it makes sense
<marcin> the problem is that there are nice tools for network management, firewall etc.
<marcin> but they don't work together in the way people want to
<carstenh> marcin: Unix philosophy: Write programs that do one thing and do it well.
<marcin> carstenh, yeah
<carstenh> marcin: i don't really see this problem. if we will have a few tools that to their job right it would be great
<marcin> carstenh, then I'll give you an example of 'real life' philiosophy
* carstenh listens
<jdthood> In my experience with GNU/Linux the administration tools have always sucked.  The reason is that the people who write the tools don't understand the subsystems that their tools configure.  The people who do understand the subsystems don't use configuration tools.
<ogra> marcin, we wont use yast *g*
<marcin> carstenh, imagine yourself an user with laptop - this guy just switched from windows - he is not an advanced one but he uses his laptop very often - at home and at work
<carstenh> marcin: ok
<sivang> ogra: you heared there are people trying to port yast to debian ? =)
<ogra> sivang, old news :)
<marcin> carstenh, at home he has DSL and he connects his laptop directly to internet (untrusted connection) and he also uses his laptop at work
<sivang> ogra: did they make anything out of it? 
<ogra> sivang, no idea, i lost my interest in yast with suse 4.2 :)
<jbailey> carstenh: Well, it's not so much "my" wants as it is the bounty.  If it doesn't make sense because the functionality is better done another way, it's not written in stone.
<\sh> re
<carstenh> marcin: ok, at work he has a system-admin which helps him and at home he has dhcp
<\sh> elmo: thx for the syncs :)
<carstenh> marcin: firewall will be enabled per default in future
<marcin> carstenh, where he has LAN with good firewall so he feels himself pretty secure and he also needs to use samba shares and he needs to use shared printers and so on
<carstenh> marcin: and every service he has installed should be enabled per default
<marcin> carstenh, and sometimes he needs to use his laptop on presentations while he doesn't have eth connectivity - so he uses wi-fi connection in work
<carstenh> jbailey: it is not that it is better done in another way, it is more that it is already there
<jdthood> marcin: You are describing a system that is not the one for which Debian was designed.
<marcin> carstenh, and finally on weekend he goes to his home on the country side where an only ability is to use gprs connection via bluetooth and his cell phone
<carstenh> jbailey: so if there a reason to implement a new one i can to this
<jdthood> marcin: Debian was designed for server boxes sitting on the floor with screwed-in network cards and static network addresses.
<marcin> jdthood, are we on debian-devel channel or another one?
<marcin> jdthood, I thought that we are on ubuntu-devel and we are talking about new tools for network/firewall/services management - right?
<carstenh> jbailey: and if i will implement one, i'm open for ideas that i.e. bum or services-admin don't have
<jdthood> marcin: To my knowledge, Ubuntu doesn't yet differ from Debian in any significant way as regards dynamic network configuration.
<ogra> jdthood, does debian use NM ?
<ogra> would be news to me
<pitti> well, do we?
<jdthood> ogra: No, NM is not yet available for Debian.  It is available for Ubuntu but it is still in an alpha state.
<ogra> pitti, we will :) 
<carstenh> marcin: is it more easy on mac os x, beos or windows?
<marcin> jdthood, I agree and all I want to tell to you guys is that you don't need yet another GUI frontend to /etc/init.d/someservice start|stop
<pitti> ogra: who cares for it? It's still horribly broken (well, it was two weeks ago)
<carstenh> marcin: you just explanined a very complicated setup
<ogra> jdthood, this will change soon, NM is a brezy goal
<ogra> pitti, Diziet 
<marcin> carstenh, absolutely - I don't know about mac/beos but it is very easy on windows
<pitti> ah, cool (that's Ian's new nick, interesting :-) )
<ogra> heh
<marcin> carstenh, this laptop is dualboot
<marcin> carstenh, and in fact this is a main problem - this guy expects ubuntu to work simmilar to winXP
<carstenh> marcin: what is missing is a frontend for /etc/network/interfaces
<carstenh> marcin: ... at least if i understand the problem
<marcin> carstenh, and I don't agree with you at this point
<marcin> carstenh, you don't need frontend  for /etc/network/interfaces in fact for /etc/something at all
<sivang> pitti: were you referring to Ian Murdock? :)
<ogra> marcin, do you know how NM works ? it is supposed to detect networks automatically and configure them...
<pitti> sivang: no, Ian Jackson
<marcin> ogra, yes I know NM
<ogra> marcin, there is no user interaction needed as long as a dhcp server is available
<marcin> ogra, it is pretty cool idea
<sivang> pitti: ah , ok, I saw this name also one many of the debian manuals :)
<marcin> ogra, but at it's current state it doesn't work with ppp connections (AFAIK)
<ogra> marcin, so if we get it as planned in breezy, do your objections still apply ?
<ogra> marcin, thats true...
<carstenh> jbailey: but at least it is ok to write two tools, one for firewall and one for services?
<pitti> brb, rebootin
<marcin> ogra, yes because NM is pretty cool 
<marcin> ogra, but it should work with all kinds of connections
<ogra> yep..
<ogra> but it will evolve over time :)
<marcin> ogra, and another thing is that it should work nice with firewall
<sivang> carstenh: why not using the renewed services-admin and putting effort into more of the firewall work?
<jbailey> carstenh: The biggest appeal is, like you mentioned last week, that the Max OS/X firewall is *really* pretty for doing firewall services changes.
<jbailey> carstenh: My ideal dream is that they're as integrated as possible.
<ogra> marcin, thats what carstenh is working on :)
<jbailey> carstenh: So we're just poking what the limits of that are, really.
<marcin> ogra, cool
<carstenh> jbailey: it has a few limitations
* jbailey nods
<mjg59_> Oh ungh.
<carstenh> jbailey: and i hope to write something that is as simple as the mac os x thing and more configurable (only if you enable expert-mode)
<mjg59_> Is -devel *still* bidirectionally gated to the forums?
<ogra> mjg59_, yes
<carstenh> jbailey: so in my current plans the services-part does not fit in the firewall gui (at least one button more :()
<mdz> Riddell: you've added some things to the kubuntu seeds which need main inclusion reports
<mdz> Riddell: see http://people.ubuntu.com/~mdz/anastacia.txt
<pitti> seb128: I'm back in breezy; what do I have to do again to get my fonts back in mozilla-firefox?
<jbailey> seb128: Should just replacing libpoppler0c2_0.3.3-0ubuntu1_powerpc.deb
<jbailey>  and libpoppler0c2-glib_0.3.3-0ubuntu1_powerpc.deb be enough, or should evince need to be  rebuilt too?
<jdthood> pitti: Do you have firefox with no words?
<pitti> jdthood: with no fonts (just some dashes)
<jdthood> I solved the problem by purging mozilla-firefox and installing "firefox".
<pitti> jdthood: right, firefox works fine
<mdz> mjg59_: iirc there is an informational note there which says "don't post"
<pitti> jdthood: but I'd like to test the hoary package
<ogra> pitti, mozilla-hangman ? 
<pitti> jdthood: and up to some days ago that worked fine
<mjg59_> mdz: This doesn't seem to stop random forum spam stuff
<ogra> yes, its annoying
<ogra> mjg59_, i'm just packaging the last gnome-power, do you think its good enough for us ? (since i'll already have to break UVF for it)
<siretart> elmo: did you get my sync request for piuparts?
<pitti> seb128, jdthood: nevermind, my fault. I installed firefox in my breezy system instead of in the hoary dchroot. works now
<pitti> sorry for the noise
<Riddell> mdz: ok, I'll try and write those up today
<jdthood> pitti: Note that alsa-base and alsa-utils don't Depend on each other any more.  I don't know whether or not this has any consequences for seeding in Breezy.
<mdz> Riddell: I'm not too fussed about the stuff which comes from KDE upstream if they're known to be good folks, but there are at least some additional dependencies too which should be sanity-checked
<Riddell> sure
<mdz> Riddell: https://wiki.ubuntu.com/UbuntuMainInclusionRequirements if you didn't have that already
<mjg59_> ogra: I think so, yes
<ogra> mjg59_, ok, then its worth it :) thanks
<bddebian> Howdy
<pitti> jdthood: good point, thanks. we should just add them to ubuntu-desktop then, I guess
<ogra> haha, funny... as soon as i posted m blog entry about mediawiki packages debian steps up and presents some to me... i wonder why they dint promote them yet
<sivang> hey bddebian 
<bddebian> Hello sivang
<sivang> bddebian: how are you? what are you hacking on these days? 
<bddebian> sivang: Just trying to help with Universe merges from Debian.  Causing others more work. ;-)
<sivang> bddebian: heh, I feel the same :)
<\sh> daniels: when can we expect xmkmf?
<carstenh> who decides if bum or services-admin becomes the ubuntu standard service-config-tool?
<sivang> carstenh: I think jdub can help you
<carstenh> sivang: thanks
<carstenh> jdub: ping
<carstenh> jdub: who decides if bum or services-admin becomes the ubuntu standard service-config-tool? and if you are the one, do you already know which one will become standard?
<sivang> seb128: http://muse.19inch.net/~sivan/lpint/launchpad-integration/ , new lpint package that builds now :) (thanks to jamesh fix)
<trulux> anyone experienced problems importing a GPG key into launchpad?
<bddebian> trulux: Haven't tried it yet.  I sent it to mako
<trulux> bddebian: it just doesn't work for me
<bddebian> Hmm, maybe I should check it out
<warty_> hi
<warty_> i need help please
<warty_> toshiba portege 3440ct whitou cd rom
<warty_> How can I install ubuntu
<carstenh> warty_: this channel is for development only, please try #ubuntu, thanks
<warty_> im sorry
<bob2> user support is in #ubuntu, not here
<warty_> sorry
<warty_> thanks , bye
<marcin> jbailey, hi
<jbailey> marcin: Hello
<marcin> jbailey, I got a question about calendaringSynchronization
<marcin> jbailey, could you tell me what is the status of this goal?
<jbailey> marcin: I need to check to see whether or not the evolution bounty has been satisfied yet.  I expect that it probably has not.
<marcin> jbailey, afaik it isn't
<hub_> guys, for synchronization, have a look at OpenSync
<jbailey> marcin: Evolution and  Sunbird are probably the only reasonable targets for this, largely dependant on upstream.
<hub_> it might provide the needed infrastructure
<azeem> hub_: is it mature?
<jbailey> hub_: Cool, thanks for the tip.
<hub_> azeem: it is being developped and used
<azeem> it's written by the same guy as multisync, AFAIK
<hub_> yep
<hub_> multisync end up being the gtk/gnome frontend
<hub_> and opensync being the framework
<mae> what is opensync/multisync
<hub_> I wish we had iSync functionnality, but more open
<hub_> mae: a framework to synchronize PIM data
<mae> ahh
<hub_> mae: from devices like cell-phones, PDA
<hub_> and from apps like Evo, Korganizer, sunbird
<hub_> etc
<mae> nice
<hub_> I have 3 address book currently, and would like to keep them synced
<hub_> 1 in the Palm, 1 on the cell phone, and 1 in Evo
<hub_> :-/
<azeem> same here
<hub_> opensync is supposed to fullfill this need
<azeem> except I never got multisync to work properly with my S55
<Amaranth> hub_: can you still send that CD? :)
<Amaranth> hub_: my source fell through
<hub_> Amaranth: sure. mail me your snail-mail address 
<hub_> Amaranth: hub@figuiere.net
<marcin> jbailey, so,. you need synchronization support for evo and sunbird - ical or something more?
<marcin> jbailey, and what about syncml etc ?
<jbailey> I think we were mostly looking at caldav for those.
<hub_> opensycn as all of that in some state
<jbailey> It looks like the most sane protocol for managing this.
<Amaranth> hub_: sent, thanks
<marcin> jbailey, ok then you expect evo as caldav client - then what about cadav server?
<fabbione> daniels: ping?
<hub_> Amaranth: got it
<hub_> Amaranth: will be mailed tomorrow
<hub_> Amaranth: colony 2 ?
<jbailey> marcin: It's too much to cover for breezy.  That's why the spec basically just covers evolution right now, with a note saying redo this after breezy.
<marcin> jbailey, ok
<marcin> jbailey, and how this goal is related with gnome bounty?
<carstenh> jbailey: should things like forwarding, enable logging or ssh=eth1 be possible with the gui?
<Amaranth> hub_: if you can, otherwise hoary works
<jbailey> marcin: The gnome bounty is to implement caldav in evolution, I think ideally for use with hula.
<jbailey> marcin: I haven't looked at it in several weeks.
<hub_> Amaranth: getting colony 2
<marcin> jbailey, well there is no word about caldav in evo bounty
<jbailey> carstenh: forwarding, no - I tend to think of the gui as being desktop not router.  Logging:  Sure.  But probably nothing that can't be expressed by adding a checkbox next to a rule (And where do the logs go?).  ssh=eth1?  Hmm..  Harder question.
<jbailey> carstenh: Depends how easy it is to express.
<jbailey> carstenh: My mother won't know what an eth1 one is, and probably shouldn't need to.
<siretart> jbailey: any problems with the javahl in subversion thingy?
<jbailey> marcin: I'll have to revisit it.
<jbailey> siretart: I don't remember off hand what the blocked was before.  I'll have to look at my logs.  I've been away for the past week.
<jbailey> blocker, rather.
<carstenh> jbailey: all these things would be more easy if we move services to a new tool, but the the firewall-gui would not look like the mac os x equivalent. so i will skip these parts (including independent configuration of different interfaces) and orientate my gui more on the mac os x thing
<siretart> jbailey: ah, no problems. I sent you a patch against the subversion package to enable building javahl with gcj-4.0. this is needed for subclipse
<carstenh> jbailey: is this ok?
<siretart> jbailey: you said you will look at it after finishing some java policy...
<jbailey> siretart: Ah right.  I need to sync with wasabi on that and get it written.
<carstenh> s/but the/but then/
<jbailey> carstenh: It's not necessary that it be identical in look, but with the similar goal of "it should be this easy"
<jbailey> carstenh: I'm not terribly good at GUIs, so there's a limited amount of advice I can provide there.  I can ask our gui expert for time if you'd like.
<carstenh> jbailey: i think this is not nessessary, thanks :)
<ogra_> grmblfjx
<ogra_> carstenh, did you get my last sentence ?
<jbailey> carstenh: 'kay.  If it comes down to it, it's a resource we can get.
<jbailey> ogra: "<ogra_> grmblfjx" isn't a sentence...
* jbailey hides.
<jbailey> =)
<ogra_> carstenh, how easy will it be to disable your firewall.... i.e. i'm developing edubuntu currently and will have a ltsp thin client environment based on our default desktop.... can i disable it easily (i.e. by a debconf option)?
<ogra_> jbailey, :p
<wasabi> hi
<jbailey> Heya Jeremy.
<bddebian> Hell wasabi
<wasabi> Who?
<carstenh> ogra_: just edit /etc/default/firewall
<bddebian> Err Hello wasabi.. :-(  SOrry :-)
<jbailey> wasabi: bah, Jerry, sorry
<wasabi> =)
<carstenh> jbailey: what about debconf?
<bddebian> Oh, that was to Jeff.. 
<wasabi> I saw my name but that's all.
<ogra_> carstenh, ah, ok... thanks ( i dont want it to run on the thinclient as you might understand ;) )
<mdz> ogra: of course we do, only with a different configuration
<jbailey> carstenh: What do you think is the right answer?  Debconf could twiddle something in /etc/defaults that says "Get out of the way and stay there"  Debian policy says that ltsp packages shouldn't touch other packages' configs, though, and the priority option shouldn't be high.
<mdz> ogra: fabbione has been discussing the firewall needs of thinclient with carstenh, I believe
<jbailey> wasabi: The Java policy that we need to throw together to make sure that Java apps are consistant.
<carstenh> mdz: ack
<ogra> mdz, ill run it on the server, which also is my gateway... but not on te thin client at all...
<fabbione> ogra: yes i did a few minutes ago...
<seb128> pitti: k
<ogra> fabbione, ??
<seb128> jbailey: yep
<seb128> sivang: k
<fabbione> ogra: firewall talking on the server...
<ogra> ah... sorry ... to slow with scrollback here
<seb128> jbailey: does it work with it?
<marcin> jbailey, http://www.gnome.org/bounties/Calendar.html#127538 there is about .ics file upload - not about caldav
<carstenh> jbailey: should not touch other packages config means that it is not possible for them to add a profiles or something similar?
<carstenh> jbailey: does not sound good :(
<fabbione> ogra: but only about the NAT part of the server...
<fabbione> no more than that.
<carstenh> jbailey: i think we can skip debconf if we have a sane default-config
<carstenh> jbailey: but it is your decision
<carstenh> ogra: why do you need to disable the firewall? every installed service is accessable from outside per default
<ogra> mdz, btw i had some strange issues with nfs when testing ltsp on the weekend it couldnt mount right away... only on the second or third attempt... i founr nothing in the logs and it works now on every attempt... any hints where else beside the logs i could look if it occurs again ?
<carstenh> ogra: ethereal?
<ogra> carstenh, its no necessary to run it on the thiclient
<fabbione> ogra: i did open a bug right this morning 
<carstenh> ogra: ok
<ogra> carstenh, good shot
<fabbione> ogra: it's nfsmount timeout issue
<ogra> fabbione, ah...
<elmo> fabbione: does libaio really not work on amd64?
<fabbione> instead i am having problems.. my client doesn't get a proper hostname
<fabbione> elmo: i am waiting for the oracle guys to show up...
<ogra> it didnt occure today anymore though... might be caused by the network cable temperature or cosmic rays...
<fabbione> elmo: for now leave the arches as they are.. i hope it was only a mistake
<carstenh> jbailey: so should we use one debconf-question "Should the firewall be started?"?
<siretart> elmo: did you get my email about puiparts? I'd like to see that package in ubuntu...
<fabbione> ogra: do you know what assign the hostname to the thinclient?
<fabbione> ogra: i keep getting a mere (none)
<fabbione> and as a consequence everything else fail
<ogra> oh... i cant get this far, since my login keeps just flashing...and there are no consoles :)
<jbailey> seb128: Whups, looks like configure picked it up anyway because of the build-deps, redoing the test.
<ogra> X breakage :)
<fabbione> ogra: ah ok
<jbailey> ogra: Should there always be no firewall on the thin client?
<fabbione> ogra: but if you don't get the hostname, you won't be able to login anyway
<carstenh> fabbione: did you read jbaileys comment on 17:46:49?
<fabbione> so that needs to be investigated first
<ogra> jbailey, my server is the default GW and my transparent proxy, if i run a FW it will be there
<fabbione> carstenh: no... sorry...
<jbailey> ogra: Part of the idea is that there's a deny all until a service is installed, at which point the needed ports are openned, to help protect against trojans.  (The user can't install their own listener)
<ogra> jbailey, the pupils wont be able to install anything on their thin client , thats done on the server by the teacher/admin only
<fabbione> carstenh: can you please quote? i don't have timestamps
<carstenh> fabbione: -> query
<fabbione> carstenh: sure..
<jbailey> ogra: Right click download off a webpage will be disabled?
<ogra> jbailey, the server has the firewall, all traffic gets routed through the server
<ogra> jbailey, nope...
<jbailey> ogra: Sure, but that's a hard outside, squishy-inside model of firewall.  
<jbailey> ogra: Part of this is supposed to be to firm up the workstations individually so that the internal network isn't automatically assumed to be trusted.
<marcin> jbailey, anyway I would like to work on this CalendaringSynchronization - if you could then please think about it and ping on this channel and we could talk about it ok?
<ogra> jbailey, WS != thin client
<jbailey> marcin: Yes.  What timezone are you in?
<mdz> ogra: I am pretty sure we will want to run custom firewall rules on the client as well
<ogra> jbailey, i dont want to disable it on a workstation install
<mdz> thin clients should generally be blocked inbound, unless they're running a print server or such
<jbailey> ogra: I don't understand the distinction you're making then.  To me a thin client is essentially a worstation that happens to use a remote harddrive.
<ogra> mdz, ok...
<mdz> jbailey: not exactly; a thin client is a system whose user processes run on a remote server
<ogra> jbailey, edubuntu will have a ltsp install by default and a optional standalone workstation install...
<jbailey> mdz: Ah, that makes quite a bit more sense then.  I wasn't thinking in terms of just being a X term.
<marcin> jbailey, Poznan, Poland it is DST +1
<ogra> jbailey, i dont consider firewalls necessary on a thin client... but you heard mdz's word ... so i'll follow ;)
<marcin> jbailey, but currently I'm online from 10 am to... about 3 am so just try
<jbailey> marcin: Okay, I'm (-0400) right now.  Will you be online in a few hours?  I haven't though about this.  Either that or I can try and make sure I have time for you tomorrow morning.  This is my first day back right now, so I'm still building up my worklist right now.
<jbailey> marcin: Right. =)
<marcin> jbailey, sure 
<marcin> jbailey, there is 6pm now - I'm going to stay online till 3am (or something like this)
<jbailey> Sounds lovely.
<jbailey> Blue wizard needs food, badly.
<carstenh> jbailey: we need to talk about how ltsp can add profiles to the firewall
<jbailey> carstenh: Yeah.  It's a case I hadn't though about.
<carstenh> jbailey: and assign interfaces to them
<jsgotangco> later guys
<carstenh> jbailey: adding profiles should be possible (it does not change exiosting files)
<ogra> carstenh, feel free to bug me for tests as soon as X is in shape to use ltsp again
<carstenh> jbailey: but assigning interfaces to them forces them to change /etc/firewall/conf
<carstenh> ogra: X?
<ogra> carstenh, yes, X is totally broken... thin clients have no console...
<mdz> fabbione: did you have issues with X and ltsp?
<ogra> carstenh, i cant test it in the current state
<carstenh> ogra: ah, ok. i thought you expected me to fix some things in X ;)
<ogra> carstenh, go ahead if you want to, daniels will surely accept patches :) 
<carstenh> ogra: i think i have enought work with my firewall :)
<ogra> heh
<jbailey> carstenh: I'm going to run off for food so I can think clearly, bbiab. =)
* fabbione mumbles at hostname
<ogra> fabbione, do you get to the point where it tries to start X ?
<fabbione> ogra: yes.
<ogra> does it start ?
<fabbione> no
<fabbione> ogra: if you can switch to console.. check what's in /var/log/ldm.conf
<ogra> hmm, so my issue might be the same... how do you know its the hostname ?
<fabbione> it will tell you what is failing
<carstenh> jbailey-lunch: if we would provide a tool that alters the configuration of ubuntu-firewall and they use it, would that be ok?
<fabbione> ogra: i have root@(none): <- no hostname
<ogra> i cant switch to console...
<ogra> hmm
<mdz> the hostname is ugly, but doesn't break anything and so I haven't bothered to fix it yet
<fabbione> ogra: than you still have a borked X
<ogra> yep
<fabbione> mdz: how can it work for you???
<carstenh> jbailey-lunch: is firewall-gui allowed to change the configuration of ubuntu-firewall?
<ogra> mdz, but it should work with hoary, shouldnt it ? 
<fabbione> here it fails miserably...
<mdz> fabbione: if it fails, it is not because of the hostname
<ogra> mdz, hoary in /opt/ltsp i mean
<mdz> at least, that worked fine a couple of weeks ago when I last tried it
<fabbione> mdz: it fails because of the call to hostname
<fabbione> mdz: i have the entire zone in the dns
<mdz> ogra: hoary doesn't have ltsp-client
<fabbione> nslookup gets to it
<mdz> ogra: or initramfs-tools
<mdz> probably others
<ogra> grmpf... true
<mdz> fabbione: what call to hostname?
<ogra> i was just thinking about a hoary CD since the ltsp install script will need tweaks for CD installation anyway
<carstenh> jbailey-lunch: if not, could we merge those packages? (sounds ugly, i know)
<fabbione> mdz: /etc/init.d/ltsp-client-setup
<fabbione> configure_resolver() {
<mdz> fabbione: $(hostname) works fine, it just returns "(none)"
<mdz> for me anyway
<fabbione> correct
<fabbione> it returns (none) here too
<ogra> fabbione, thats just ugly, but why shouldnt it work ?
<fabbione> but the point is that the hostname value is used to export the display towards the client
<ogra> fabbione, its ssh
<ogra> there are no display exports
<mdz> fabbione: where?
<fabbione> ogra: well tell it to gnome or whatever fails with (none)
<fabbione> let me grab the logs again..
<fabbione> hold on a sec
<ogra> fabbione, gnome needs a working loopback, but can live without hostname afaik
<ogra> as long as any value (even (none) gets returned)
<fabbione> env LTSP_CLIENT=(none) x-session-manager;
<fabbione> AHHH
<fabbione> DAMN
<fabbione> it's missing xauth
<ogra> heh
* fabbione sighs to death
<mdz> fabbione: :-)
<fabbione> sorry..i start to feel sort of tired...
<ogra> wow, it seems i really kicked off something with my mediawiki packages... debian starts getting really busy
<fabbione> now...let's find xauth
<ogra> :)
<mdz> it probably ought to set a hostname of ltsp<ip address in hex> or such
<mdz> fabbione: xauth is nonexistent in breezy right now
* fabbione compiles
<fabbione> mdz: i had to build other packages too manually to get X working on my ws yesterday.. one more one less makes no difference :)
<Kamion> xauth is there as source, but FTBFS
<fabbione> the usual missing B-D
<fabbione> it builds fine here.. but it's not exactly what i would call a minimal system :P
* fabbione hits xauth with a cluebat
* \sh needs xmkmf
<zul> oh be nice
<fabbione> it doesn't recognize unix: connections anymore....
<zul> gah?
<lamont__> seb128: any librsvg2 uploads in the near future?
<fabbione> bad display name "unix:10.0" in add command
<seb128> lamont__: not planned
<lamont__> seb128: OK.  means I have to actually test things..
<fabbione> xauth is busted
<fabbione> mdz: i am sorry.. but i don't think i can go any further for today
<fabbione> i really don't feel lucky to fix xauth
<lamont__> mdz: thoughts on the evilness of binNMU's of -ubuntuN packages?
<fabbione> ogra: the nfsmount bug is #12942
<ogra> fabbione, hmm, i always tested with the same single client on a idling server....
<fabbione> ogra: i experienced in both situation
<ogra> and i'm not sure there is any negotiation done in my network....
* lamont__ mumbles a "never mind"
<ogra> as i said, i had this yersterday while testing... but it disappeared today, with the same setup
<JaneW> time to go
<JaneW> bye
<ogra> bye Jan
<ogra> bye JaneW 
<JaneW> bye ogra
<lamont__> ENOPITTI
* mjg59_ finds a laptop with a very broken BIOS
<mjg59_> Is there any way to start an install from DOS?
<bddebian> Eeks
<fabbione> ogra: http://people.ubuntu.com/~fabbione/xauth
<fabbione> ogra: grab that binary to have ssh -X to work
<fabbione> just copy it in /usr/bin on the server
<fabbione> the others should stay away from it
<lamont__> mjg59_: hrm.. copy a disk image to the hard drive while booted from a dos floppy???
<ogra> fabbione, in /usr/bin or in /opt7ltsp/usr/bin ?
<ogra> s/7/\//
<mjg59_> lamont__: Are they included on the CD?
<carstenh> mjg59_: loadlin and debootstrap?
<lamont__> mjg59_: they?
<mjg59_> lamont__: The disk images
<lamont__> no.  can you boot a CD at all?
<mjg59_> carstenh: Well, yeah, I know how I /can/ do it, I was wondering if there was actually a mechanism provided :)
<mjg59_> lamont__: Nope
<Kamion> no supported method
<lamont__> PXE boot?
<mjg59_> isolinux chokes and dies
<mjg59_> No built-in networking
<Kamion> there's some random untested stuff in tools/ IIRC
<lamont__> mjg59_: there's always that ultimate fallback of "install the hard drive in a usable computer and do the install there"
<carstenh> put the hd in a pc with cd-rom?
<Kamion> oh, no, we took that out 'cos it was random and untested
<lamont__> mjg59_: I was starting from the expectation that _you_ were doing this...  for joe-random-user, uh... scary
<mjg59_> lamont__: Oh, yeah, I'm doing it
<mjg59_> Hmm
* mjg59_ wonders which machine would be easiest to remove a disk from
<lamont__> debootstrap may be your friend... mjg59-the-human-installer
<fabbione> ogra: /usr/bin
<ogra> oki
<fabbione> AHHH
<fabbione> here is the issue..
<lamont__> mjg59_: you could clone the existing root to the laptop-hardrive-in-a-USB-enclosuer...
<fabbione> UNIXCONN and LOCACONN are not set...
<fabbione> = unix: is not recognized..
* fabbione felt lucky anyway
<ogra> fabbione, but my xauth in /usr/bin on the server is just working fine, i still run -34 there...
<mjg59_> lamont__: Would require a USB enclosure :)
<fabbione> ogra: mostlikely yes
<lamont__> mjg59_: well, yes.
<fabbione> but i think the breakage goes more deep down than just xauth
<ogra> yep
<mjg59_> Ouch!
<mjg59_> This think is stupidly hot
<lamont__> mjg59_: find a laptop that doesn't have the HD under the keyboard, k?
<ogra> fabbione, since you are able to switch consoles on the thin client and i'm not, i would also suspect xkb ....
* lamont__ needs to swap hd's on the vaio and give it to his wife.
<fabbione> ogra: xkb is doomed to another degree...
<ogra> yep
<fabbione> ogra: i will give you the fix for that in a second...
<fabbione> i think libx$(something) is not exporting UNIXCONN and LOCALCONN to pkg-config stuff = xauth and others might be broken
<fabbione> ogra: grap xkbutils from people.u.c if it's not in the archive yet
<fabbione> ogra: and you need to add 2 symlinks...
<fabbione> nah binaries are in the archive
<fabbione> don't take mine
<fabbione> ogra: first thing check that you have no /opt/ltsp/etc/lts.conf
<fabbione> if you do be sure that the SCREEN_01=ldm and not startx
<fabbione> (that hangs the keyboard for me)
<ogra> i dont
<fabbione> ok
<ogra> its a fresh ltsp env in /opt
<fabbione> ok
<fabbione> install xkeyboard-config in the /opt/ltsp/$arch chroot
<fabbione> (that's required to set the keyboard properly)
<fabbione> edit /etc/init.d/ltsp-client-config (still in the chroot)
<fabbione>       preseed xserver-xorg xserver-xorg/config/inputdevice/keyboard/rules "xfree86"
<fabbione>       preseed xserver-xorg xserver-xorg/config/inputdevice/keyboard/layout "$XKBLAYOUT"
<fabbione>       preseed xserver-xorg xserver-xorg/config/inputdevice/keyboard/model "$XKBMODEL"
<fabbione> add the first line with preseeding "xfree86"
<fabbione> the default is xorg but xkeyboard-config is missing some of the symlinks
<fabbione> so revert to xfree86 (it's the same file... different name)
<fabbione> still in the chroot...
<fabbione> cd /usr/X11R6/lib/X11 && ln -sf /etc/X11/xkb
<fabbione> cd /usr/lib/X11/locale && ln -sf lib/common
<fabbione> that should make the keybaord working again
<fabbione> (if i haven't forget any of the symlinks)
<fabbione> doko: ping?
* fabbione is finally running a thinclient
<lamont__> fabbione: coolness
<lamont__> that's on my list
<Kamion> mdz: shouldn't ldm use subprocess' stdin=, stdout=, and stderr= keyword arguments rather than os.dup2?
<fabbione> lamont__: let me give you a friendly hint.. wait for X to be fixed :P
<lamont__> it's not on my list for before 15 aug or so
<Kamion> mdz: I'm borrowing bits from ldm for oem-config, and when I did it your way stderr wasn't going anywhere; I straced and found that python was doing dup2(2,2)
<fabbione> i guess i am done for today..
<fabbione> tomorrow we will scratch everything and start again
<fabbione> Kamion: btw.. did you check the initrd images?
<Kamion> mdz: can I have a UVF exception for kbd-chooser 1.16? fixes FTBFS
<Kamion> fabbione: for what?
<fabbione> Kamion: are they ok or are they too big?
<Kamion> oh
<fabbione> Kamion: for the installer
<Kamion> fabbione: powerpc netboot is too big, I think
<Kamion> 802851 6216 -rw-rw-r--   1 katie    katie     6352893 Jul 22 18:18 installer-powerpc/20050317ubuntu11/images/powerpc/netboot/initrd.gz
<Kamion> yaboot can't deal with >6MB
<fabbione> humpf..
<fabbione> that's like 6.05M
<Kamion> hmm, but it was too big before as well
<fabbione> Kamion: can you try to boot it?
<fabbione> perhaps they fixed it
<Kamion> not sure what was up there
<Kamion> fabbione: yaboot hasn't changed since I last read the source
<bddebian> Try grub2? :-)
<Kamion> bddebian: I did, it doesn't work yet.
<bddebian> Oh.  I'll kick Marco for you :-)
<Kamion> I sent Jeff a bug report
<Kamion> fabbione: all the initrds grew by about a megabyte
<ogra_d> fabbione, now my nfs tiems out again :(
<Kamion> except for powerpc netboot I think, which seems to have stayed about the same; I guess it was inefficient before
<ogra_d> damned, it worked all day
<fabbione> ogra_d: run tcpdump -i $interface on the one supposed to be the server..
<Kamion> bddebian: even with that, grub2 is still a bit too raw and untried
<fabbione> ogra_d: that's the workaround i used
<Kamion> bddebian: I'd like to use it eventually, but I don't want to be hurried into it
<bddebian> Kamion: True and it's so sad because Marco and Okuji (and others of course), have done some good stuff
<ogra_d> fabbione, wow, coolness :) thanks !!!
<Kamion> we'll probably want it for initramfs
<ogra_d> now to see if X comes up
<Kamion> bddebian: well, when one decides to rewrite a project from scratch, one can hardly be surprised when people are a bit conservative about switching over to it. :-)
<fabbione> Kamion: yes i expected them to grow a bit...
<bddebian> Kamion: Ay
<bddebian> +e
<fabbione> Kamion: but initramfs is not going to be any smaller...
<Kamion> fabbione: initramfs was an unrelated side comment
<fabbione> Kamion: yes.. i am thinking for the switch later ...
<ogra_d> hmm, no X ... 
<Kamion> joeyh seems to think it can be smaller for the installer actually, but I haven't worked out exactly what he's talking about yet
<fabbione> initramfs has less control over the amount of modules you grab..
<Kamion> isn't that only for init*-tools? there's no difference in that regard for d-i
<Kamion> fabbione: 1MB is definitely well above the size increase I had hoped for
<fabbione> Kamion: just one sec... can you give me some pure numbers?
<seb128> gnome-screensaver rocks
<fabbione> on what % did they increase+
<fabbione> ?
<seb128> the user switching is integrated to the lock screen
<seb128> and it works fine
<Kamion> 48169051 2684 -rw-rw-r--   1 katie    katie     2742339 Jul 20 10:49 installer-amd64/20050317ubuntu10/images/cdrom/initrd.gz
<Kamion> 540738 3772 -rw-rw-r--   1 katie    katie     3858245 Jul 22 18:18 installer-amd64/20050317ubuntu11/images/cdrom/initrd.gz
<Kamion> 43909126 3144 -rw-rw-r--   1 katie    katie     3211448 Jul 20 10:48 installer-i386/20050317ubuntu10/images/cdrom/initrd.gz
<Kamion> 245790 3932 -rw-rw-r--   1 katie    katie     4019311 Jul 22 18:16 installer-i386/20050317ubuntu11/images/cdrom/initrd.gz
<Lathiat> seb128: nice
<Kamion> 48381985 3356 -rw-rw-r--   1 katie    katie     3429967 Jul 20 10:50 installer-powerpc/20050317ubuntu10/images/powerpc/cdrom/initrd.gz
<Kamion> 1179777 4624 -rw-rw-r--   1 katie    katie     4722225 Jul 22 18:17 installer-powerpc/20050317ubuntu11/images/powerpc/cdrom/initrd.gz
<Kamion> fabbione: I cannot give you a single number across the board; it varies by architecture and media type
<fabbione> Kamion: yup.. i can see.. we are between 25% and 50%
<fabbione> way too much
<fabbione> i guess we will have to split some modules out again...
<ogra_d> seb128, so you mean i can drop the work i did for xscreensaver ?
<seb128> dunno what you did
<seb128> but gnome-screensaver is pretty
<seb128> it lists users
<ogra_d> seb128, i spent about 4 days to write a new lock screen 
<seb128> you just have to pick one, it switches to the opened session on the unlock dialog
<seb128> or open a new gdm login screen if the user is not logged
<ogra_d> seb128, http://www.grawert.net/xss_mockup.png
<ogra_d> seb128, with gdmflexiserver integration... like mpt designed it
<seb128> grumpf
<ogra_d> we designed it in udu
<seb128> I would rather push gnome-screensaver ...
* fabbione -> dinner
<ogra_d> it didnt work on my amd64 alst time i tried... i'll try again... but loosing this work is sad... its my absoluetly favoirite project :(
<seb128> duplicating efforts is not nice neither
<ogra_d> and only needs some code cleanup
<mdz> Kamion: re: kbd-chooser, yes
<ogra_d> seb128, while we were at udu and while talking with vuntz at guadec i was told by all of you that gnome-screensaver isnt feasable
<ogra_d> because not mature enough
<Kamion> mdz: thanks
<ogra_d> seb128, but i agree that gnome-scrennsaver is the way to go... sadly :'((((
<seb128> hum, are you sure I said something about that? I didn't use gnome-screensaver before guadec
<mdz> lamont__: binNMUs == evil
<seb128> I just say that today version kicks asses
<seb128> the gtk dialog are really nice
<seb128> it lists users
<ogra_d> seb128, when we sat together with jdub, vuntz and davyd
<seb128> allow to switch between opened sessions, etc
<mdz> Kamion: I think it was using dup2 because it was using fork before moving to subprocess
<ogra_d> yes v:8
<ogra_d> :(
<seb128> not sure if we should consider it for 5.10 though
<seb128> mdz: any opinion on that?
<mdz> Kamion: changesets welcome; my development environment is sort of hopelessly broken until this evening
<lamont__> mdz: yeah, was pretty much a given
<ogra_d> seb128, if its stable and secure we should... 
<ogra_d> seb128, dont worry about my frustration... i was prepared for my patch to disappear... just not this soon
<mdz> seb128: gnome-screensaver vs. xscreensaver?
<lamont__> elmo: ping
<ogra_d> mdz, yes
<seb128> mdz: yep
<mdz> I haven't looked at gnome-screensaver at all
<mdz> what are the tradeoffs?
<ogra_d> mdz, its integrated
<seb128> gnome-screensaver has user switching integration now
<seb128> lock screen list users, and allow to pick one
<seb128> you are send to the "unlock" dialog for this user if he has a session running
<seb128> or on gdm login if he hasn't
<seb128> it speaks with dbus
<seb128> uses gconf
<ogra_d> mdz, we just said its not mature enough, last time we met in person... thus i wrote a new xcreensaver patch :8 but seb is right to promote it
<mdz> sounds nice.  what's the downside?
<seb128> lack some user feedbacks, it's quite young
<seb128> but works fine here ...
<seb128> out of the no real issue
<ogra_d> mdz, for me, only that my favorite pet project has to die... and i cant rant about jwz anymore :(
<mdz> ogra_d: jwz will always give you more reasons to rant
<ogra_d> hehe
<mdz> sounds like we should give gnome-screensaver a try
<ogra_d> yep
* ogra_d will try to offer his patch to debian.... then he can rant about the debian xscreensaver maintainer :) 
<ogra_d> mdz, what was the default user for the ltsp client ? 
<seb128> mdz: I'll mail the list this week to get user feedback on it
<mdz> ogra_d: there is no default user; one must be entered into the ldm dialog
<mdz> seb128: ok
<ogra_d> mdz, heh, thats hard with only console login :)
<seb128> just need to sort what to do with screensavers list before, gnome-screensaver can use xscreensaver's one, but doesn't use the same folder by default
<mdz> ogra_d: the console is secure by default
<mdz> ogra_d: if you need console access, either a) set a root password, or b) add a 'shell' screen to lts.conf
<\sh> hmm...libdebtags > 1.0.3 .. can we break UVF for it and getting it from debian?
<Kamion> mdz: ok ... I'll have to get to a point where I can test ltsp first
<bddebian> \sh: libdebtags1 :-)
<mdz> Kamion: likewise, only s/get to/get back to/
<ogra_d> mdz, i dont need it... i'll try to get X running... 
<\sh> bddebian: it will get libdebtags1c2
<ogra_d> Kamion, wait for X to be ready, its a PTIA to get it working currently
* Kamion prefers s/wait for/help/ personally
<ogra_d> Kamion, yes, but concentrate on X rather then fiddlig with single binarys in the ltsp chroot :)
<elmo> lamont__: ?
<lamont__> elmo: was going to have you nuke something, but then my test finished... nuking won't help
<seb128> hum, dinner time
<venda> hi, I am here on behalf of {Seb} who it seems has been banned from this channel for a reason unknown to him. Could anyone tell me why he was banned?
<mdz> venda: fabbione
<venda> mdz: venda == froud, hi
<mdz> hi
<venda> mdz: fabbione has the reason?
<venda> {Seb} is asking why he was banned on #ubuntu-doc 
<mdz> venda: presumably; he set th eban
<venda> fabbione: ping
<Treenaks> venda: see pm
<mdz> doesn't the IRC server tell someone who banned them when they are banned?
<mdz> presumably he is capable of asking fabbione himself
<venda> Treenaks: thanks
<venda> mdz: no it doesn't it just says you're banned :-) OK Treenaks has given the answer. Later
* mode/#ubuntu-devel [+o fabbione]  by ChanServ
* mode/#ubuntu-devel [-b *!*@195.137.120.*]  by fabbione
* mode/#ubuntu-devel [-o fabbione]  by fabbione
<ogra_d> mdz, got a running ldm now, but it doesnt let me in.... i give up for today... am i right that the part you need beautified is /usr/lib/ltsp/greeters/gtk ?
<mdz> ogra_d: yes, that's it
<mdz> I would be happy if it were centered on the screen, and the text entry boxes focused without moving the mouse :-)
<ogra_d> oki... so i'll move my xscreensaver motivation over to this one :)
<Kamion> mm, I will need beautification on oem-config in a week or two's time, probably ...
<ogra_d> probably a default theme would also be an option...
<ogra_d> Kamion, since you just stle from ldm you'll be able to do it again ;)
<Kamion> true
<Kamion> well, I don't use anything like the greeter in ltsp
<ogra_d> is there a baz archive for oem-config ?
<ogra_d> or a source package or something ?
<Kamion> colin.watson@canonical.com--2005/oem-config--mainline--0
<Kamion> (http://people.ubuntu.com/~cjwatson/archives/colin.watson@canonical.com--2005)
<ogra_d> oki, i'll check it out... is this affected by feature freeze (i.e. has it a near deadline ?)
<Kamion> it's a feature freeze item, yes
<ogra_d> ok
<Kamion> not all the UI is ready for review yet though, which is why I suggested a week or two's time; it would probably be more productive then
<ogra_d> Kamion, isnt two weeks == feature freeze ??
<Kamion> yes well *cough*
<Kamion> user interface freeze is two weeks after FF
<ogra_d> heh, ok
<ogra_d> ah, yes... four weeks from now
<[SemTeX] > als ik een dir fotos op dvd fik, neemt die dan de thumbs mee of niet?
<[SemTeX] > sorry, wrong chan :)
<carstenh> jbailey: did you already think about the policy and configurations-changes?
<Kamion> ogra_d: how does one set a default theme?
<ogra> hmm, i have to look it up, but i did it in the hwdb.client... you can force gtkrc values
<Kamion> <cjwatson@cairhien ~/src/ubuntu/hwdb-client/hwdb-client-0.6>$ grep -ir gtkrc .
<Kamion> <cjwatson@cairhien ~/src/ubuntu/hwdb-client/hwdb-client-0.6>$
<Kamion> hmm
<ogra> from gtk import RcStyle
<ogra> from gtk import Settings
<Kamion> aha
<Kamion> thanks
<ogra> gtk.rc_parse_string('gtk_font_name = "Sans 8"')
<ogra> sets a default font and overrides the actual theme 
<ogra> should also be possible for widget theme settings
<lamont__> jbailey: looks like klibc needs to be reved to match the current linux-headers-2.6.12 abinumber
<jbailey> lamont__: Thanks.
<Kamion> ah, gtk-theme-name and gtk-font-name properties
<carstenh> jbailey: a simple "no" would suffice a answer
<carstenh> s/a/as/
<jbailey> carstenh: Eh?
<jbailey> carstenh: Oh, sorry, had missed the nick highlight.
<carstenh> 20:38:24 < carstenh> jbailey: did you already think about the policy and 
<carstenh>                      configurations-changes?
<carstenh> no problem
<mdz> carstenh: this channel is busy and we all miss messages sometimes; it's nothing personal
<carstenh> mdz: ok
<jbailey> carstenh: No, I haven't, sorry.  
<carstenh> jbailey: ok, then we will talk about it later :)
<jbailey> carstenh: Thanks, sorry, a bit swamped on the first day back.
<mdz> has someone uploaded xauth with better build-deps already?
<ogra> mdz, fabbione has a single xauth binary compiled against recent X on p.u.c but there is no new package yet
<mdz> ok, I'll have a look
<ogra> seb128, didnt you say you wanted to make gnome-screensaver conflict with xscreensaver ? i can still install both
<mdz> of course, I can't upload anything for at least another 4 hours
<jbailey> seb128: Disabling cairo on ppc *does* fix the problem.
<jbailey> seb128: Strange that it doesn't show up in the built-tests.
<seb128> ogra: no, I don't want too, the screensavers are here
<seb128> jbailey: yeah, according to upstream evince doesn't use the same API set
<ogra> seb128, xscreensaver stops working if gnome-screensaver is installed
<jbailey> seb128: Ah, one of those overtesting applications... ;)
<seb128> jbailey: k, so the bug is with the cairo part and we can roll back on splash if required
<Kamion> oh, it's probably not a default theme I need, it's a window manager
<seb128> ogra: don't install gnome-screensaver if you intend to use xscreensaver
<ogra> seb128, ha ha
<seb128> or split xscreensaver
<ogra> seb128, and obviously gnome-screensaver doesnt work for me
<seb128> to make a package with the screensavers and one with the binary
<seb128> what version and what doesn't work?
<ogra> i get a flickering mouse cursor on black screen and cant unlock or do anything
<Kamion> ah, yes, much better once I start metacity first
<seb128> that's a 0.0.7 bug fixed with 0.0.8
<seb128> are you sure you have 0.0.8 ?
<ogra> the current version, i installed it a minute ago
<seb128> yeah, I've uploaded 0.0.8 1 hour ago
<seb128> maybe it FTBFS or has not built yet
<seb128> dpkg -l it
<ogra> yep 0.0.7
<ogra> hmpf
<seb128> k, wait for 0.0.8
<seb128> it has built
<ogra> ... updating ....
<tseng> anyone want to test beagl
<tseng> ee
<ogra> phew
<ogra> ** (gnome-screensaver-dialog:8085): WARNING **: Screen locking disabled: error getting password
<ogra> (gnome-screensaver:8077): GLib-CRITICAL **: g_hash_table_destroy: assertion `hash_table != NULL' failed
<Treenaks> tseng: with Office file support?
<Treenaks> tseng: ;)
<tseng> Treenaks: no?
<Treenaks> tseng: why not?
<tseng> because i didnt add it
<Treenaks> tseng: hm, good point :)
<tseng> gsf-sharp is using the old mono policy
<tseng> i have not updated it
<Treenaks> tseng: does gsf-sharp do Word docs as well?
<ogra> seb128, it crashes reproducable
<Treenaks> tseng: anyway.. where do I get the packages?
<seb128> amd64?
<tseng> Treenaks: i thought it used libwv1 for that
<ogra> seb128, yep
<tseng> Treenaks: its in the archive
<Treenaks> tseng: (and will you eventually port it to the new policy?)
<tseng> Treenaks: but you need to build latest evolution-sharp from apt-source
<seb128> can you open a bug on bugzilla.gnome.org?
<ogra> seb128, but i doubt its arch specific... 
<tseng> Treenaks: because buildd ate it
<seb128> upstream is quick to reply
<seb128> ogra: it works fine here
<ogra> ** (process:8118): WARNING **: Couldn't get password of "ogra"
<pitti> yay, network back
<seb128> wb pitti :)
<tseng> pitti: wb :)
<marcin> jbailey, there is another thing I would like to talk about later - Java
<HiddenWolf> ogra. show it to him!
<jbailey> marcin: Cool.  Do you mind doing that on #ubuntu-java so that others interested and see it easily around the noise of this channel?
<seb128> ogra: have you restarted the daemon after the upgrade?
<marcin> jbailey, sure I didn't know about such channel
<marcin> jbailey, joining
<ogra> seb128, es i run it from a terminal manually to see the errors immediately
<ogra> s/es/yes
<seb128> ogra: cat /etc/pam.d/gnome-screensaver ?
<ogra> @include common-auth
<seb128> ogra: and no other error?
<ogra> ** (gnome-screensaver-dialog:8258): WARNING **: Screen locking disabled: error getting password
<ogra> thats all
<ogra> only these two lines
<seb128> ogra: the sources have a test-passwd binary, can you open a bug upstream with a copy of what it says?
<ogra> yep
<ogra> seb128, is it enough if i run it in the source tree after compiling ? 
<seb128> yeah
<ogra> seb128, seems t work finte with this tool
<ogra> fnie even
<ogra> ergh
<ogra> fine :)
<seb128> usually upstream reply to such errors according to bugzilla is that you don't have the privilege required
<seb128> but with the pam file that works fine here
<seb128> any just fill the bug, he bet you'll get a quick reply
<ogra> i think i'll restart my session first any try again....
<ogra> hmm, no difference, except that all my fonts are a point smaller suddenly... strange...
<carstenh> jbailey: JYFI: I started to create a glade-file for the firewall-gui, here is a screenshot: www.fh-trier.de/~heyc/fwgui.jpg
<HiddenWolf> who is thunderbird's maintainer?
<Treenaks> HiddenWolf: apt-cache show tells
<jbailey> carstenh: Cools.  What's "sharing"?
<carstenh> jbailey: internet connection sharing
<carstenh> jbailey: a bit to long to write it in a tab
<carstenh> jbailey: do you have a better name? :)
<carstenh> jbailey: properties is something like: repond to ping or logging
<carstenh> or better: will be
<jbailey> carstenh: Ah, right.  No, sharing's probably enough.
<HiddenWolf> Treenaks: it shows the debian maintainer only
<ogra> seb128, i think i'll wait with the bugreport there are other weird things going on here since i installed gnome-screensaver... my fonts are nearly unreadable tiny... (i guess its a cairo issue which got upgraded for gnome-screensaver)... and i dont want to upgrade X now...
<ogra> ergh and firefox stopped working... 
<ogra> pitti,  what was the fix for the hangman effect in firefox ? 
<pitti> ogra: just install firefox, not mozilla-firefox
<ogra> pitti, i have firefox installed since weeks
<ogra> (not mozilla fiefox)
<pitti> hm, still m-f should disappear from breezy entirely to lower confusion
<pitti> ogra: with firefox it just works for me
<ogra> pitti, not up to date here... upgrading
<pitti> ogra: I am (although with broken keyboard, but that works as long as I only type English text)
<ogra> pitti, i refuse to upgrade any X stuff until i hear its fixed
<Burgundavia> seb128, I am going to close that Spatial Breaks Usability bug, that ok with you?
* \sh just uses xmodmap ,-)
<pitti> ogra: right now I'm usually running m-firefox in a hoary dchroot for testing :-)
<ogra> ahh, tiny fonts... but fonts at least
* pitti uploads mozilla-firefox_1.0.6-0ubuntu0.1_source.changes to hoary-security
<pitti> PHEAR
<ogra> heh
* ogra consider setting up a mailfilter for all the ff complaints in -users
<pitti> I'm not feeling good about breaking our backport policy, but ffox is already broken, can't possibly get worse anyway
<\sh> pitti: w8 until tomorrow..I'm pushing the queues ,-)
<pitti> shackan: I can't answer you directly (no backslash, aargh), but I WANT MY BUILDD! :-)
<ogra> meh 
<pitti> ^ sh
<pitti> shackan: sorry, that wasn't for you
<ogra> i can either select huge fonts (9+) or unreadable tiny ones (8)
<Burgundavia> seb128, never mind
<ogra> pitti, same to you...
<\sh> pitti: hehe :)
<ogra> :)
<ogra> (mehwant for you)
<ogra> wasnt
<seb128_> if somebody said something for me repeat
<\sh> pitti: xmodmap + xkeykap ,-)
<seb128_> Burgundavia: what?
<pitti> backslashsh: easy recipes appreciated
<Burgundavia> seb128, I asked if I could close that nautilus spatial bug I opened, but you already closed it
<ogra> seb128_, why are my fonts so freaky since gnome-screensaver pulled in cairo ?
<pitti> seb128: oh, do we have the old behavior now, or did you close it because it ain't going to change anyway?
<seb128_> ogra: dunno, you are the first to have an issue
<seb128_> ogra: it ignores the DPI setting
<ogra> seb128_, oh
<Burgundavia> pitti, we have changed to the broswer mode, with path bar and places side bar
<pitti> really? cool
<seb128_> Burgundavia: k, right
<\sh> pitti: xmodmap from -36 + xkeycaps...
<seb128_> pitti: yeah
<\sh> xkeycaps -> pc105 keyboard and put \ []  {} on the umlaut keys save it as .xmodmap in your home and xmodmap /home/pitti/.xmodmap
<\sh> there u r
<pitti> thx
<ogra> i want my beautiful fonts back ! cry ...
<ogra> ahh... 8.5 pt looks like 8 looked before :)
<tseng> ogra: it doesnt respect DPI
<tseng> ogra: there is a bug
<ogra> tseng, yes... but for now i'm fine with a workaround... as long as my eyes dont hurt i'm fine
<tseng> haha
<ogra> seb128, what about notification-daemon and libnotify ? 
<ogra> seb128, i will package the latest gnome-power this week, it uses them....
<seb128> I've pinged the libnotify guy on IRC like 1 hour ago
<ogra> (upstream made a lot changes for us in gnome-power to make it easier to integrate it in ubuntu)
<seb128> he's quite busy
<ogra> hmm
<seb128> he'll try to roll a libnotify tarball this week
<ogra> ok
<\sh> hmmm
<\sh> libxaw8 is missing while xorg trans?
<pvanhoof> when is the kernel upgrade to 2.6.13 for breezy planned?
<pvanhoof> thread tracing seems broking in the current 2.6.12-4 one, therefore UML ain't working
<pvanhoof> s/broking/broken
<AndyR> lo all
<AndyR> is anyone working on gaimvv packaging?
<ogra> seb128, since when do the scrollbar arrows have sound events ? 
<ogra> thats a bit annoying... 
<pitti> ogra: accessibility spec, you don't need to look at the screen at all any more :-)
<ogra> pitti, hmmm apparently also the scrollbar itself makes *plop* if i grab it :/
<ogra> thats sooo KDE *shudder*
<ogra> seb128, gnome-screensaver works if locally compiled... so its not a bug, only inconsistency of my outdated system... but i'm not at all convinced by the lockscree ... could we disable the timer ? 
<seb128> sure we could
<ogra> great :)
<seb128> better to bug upstream about that though rather than forking
<ogra> yep
<ogra> i'll do
<lamont__> ah, iz pitti!
<\sh> ogra: tsts
<ogra> seb128, we should put a review on mpt's todo list ;)
<Riddell> ogra: huh?
<ogra> Riddell, yes ?
<ogra> ahh... heh
<ogra> Riddell, putting sound events on every move you make is a typical KDE thing... that makes up the cluttered feeling i have using KDE
<ogra> s/that/one of the things/
<pitti> elmo: could you remove mozilla-firefox from breezy? it causes some confusion and we should generally use firefox
<AndyR> im interested in packaging gaimvv is there anywhere i should post my intentions to save duplication of work?
<ogra> Riddell, personal thing... nothing against KDE *g*
<\sh> ok...
<\sh> no objections if I go to bed? ,-)
<pitti> good night!
<\sh> pitti: the buildd are yours :)
<pitti> great work, Stefan
<\sh> pitti: only jobs to be done...
<\sh> ok...off to bed...night guys..
* icaro prova script xchat
<Mez> hows the auto-test for breezy going
<sivang> Mez: what sort of auto-test infra is there? 
<Mez> sivang, no idea :D I just know it was delaying backports :P
<sivang> Mez: hehe, good night btw
<Mez> night sivang 
<Mez> mdz: ping
<mdz> Mez: yes?
<Mez> just to let you know, John and I have agreed that I should be the SPOC for backports
<sivang> Mez: what's a SPOC ?
<\sh> Single Point Of Contact
<\sh> sorry..can't sleep...need food ,-)
<sivang> \sh: thanks :)
<sivang> \sh: go get some sushi, it alwasy helps
<\sh> uhhh..raw fish...no ways
<Mez> what \sh said
<\sh> I'm not eat fish even in cooked state
<\sh> or fried
<sivang> \sh: ah then sorry, what's your fancy?
<\sh> dead cows ,-)
<\sh> no joke...a good steak or tasty vegetables
<sivang> \sh: cool :)
<sivang> \sh: steaks are fine, as long it's not too fat
<\sh> sivang: no...nice filet steaks from corn-fed cows :) actually I like the taste of ZA cows...really.here in germany u won't taste the corn.
<Burgundavia> sivang, \sh, please go and eat somewhere else
<sivang> Burgundavia: hehehe
<sivang> Burgundavia: that was hilaroius, albeit in place, remakr :)
<Burgundavia> it is not only off topic, you are also making me hungry
<\sh> hahaha
<\sh> sh+***
<\sh> i just blown away some glowing ashes from my cigarette..somewhere..I don't find it
<sivang> Burgundavia: I always you deep inside you lies a true comedian :)
* sivang will go to sleep smiling after having a good laugh, and finishing file-roller launchpad integraiton patch :)
<\sh> so I'm waiting until it's burning *holycow*
<mdz> Mez: ok, sounds good
<mdz> Mez: do you have a wiki page set up?
<Mez> for the old one :D yes
<Mez> for the new one no
<Mez> cause we dont know how the new stuff is going
<sivang> hmm, mine was just automatically moved I think
<Mez> I'm just like - registering stuff in launchpad for bugs and stuff
<sivang> Mez: wasn't yours?
<Mez> sivang wasnt my what ?
<Mez> oh
<Mez> no I'm on about old backports
<Mez> "unofficial"
<Mez> vs "official
<sivang> eh
<Mez> 2
#ubuntu-devel 2005-07-31
<Mez> mdz: https://wiki.ubuntu.com/UbuntuBackports
<Mez> doesnt mention official stuff yet
<mdz> jordi.
<sivang> mdz: you'd be happy to know that we are making some progress on lpint, the helper lib is more improved in making the patches less intrusive now, I already have a gedit patch pending and now posting file roller, jamesh has evince and gucharmap ones and seb takes care of packaging the lib and providing me guidance where needed :)
<mdz> sivang: in the end, how many packages do we need to patch?
<Mez> mdz: I think backports is ready to go our end - as soon as things start getting shoved into the official repositories
<sivang> mdz: well, as a basic estimate (give or take a couple more) we start we the ones at http://udu.wiki.ubuntu.com/LaunchpadIntegration
<Burgundavia> seb128, are you removing the root terminal launcher soon?
<Mez> mdz: how do we go about getting some sort of "official" website for it
<Mez> or do we just use the wiki?
<sivang> mdz: but, given we now have one function to enable both UIManager and glade/manual created menus apps in the code, and in UIManager there's 1 line to patch in the xml ui specification, + 1 line to patch the configure script, it's not impossible to manage to finish this in time, excluding complicated non standard stuff like firefox or openoffice (which I havn't yet looked into)
<seb128> Burgundavia: with the next upload of g-t probably, any hurry?
<Kamion> \sh: wow, dude, you need to get access to an amd64 box rather than using the bogoupload strategy :)
<sivang> mdz: so you get about ~3 lines of meaningful patch per app, approx.
<Burgundavia> seb128, just looking at my old bugs, clearing some out
<\sh> Kamion: well actually I would like to have a HP bladecenter ,-)
<seb128> there is no doubt lpi patches will be here soon
<sivang> mdz: oh, and one expection to that is bonnobu ui , which requires some more love..
<seb128> Burgundavia: thanks
<seb128> Burgundavia: I've closed your trash one, that would break the coherence with the rest of the desktop
<sivang> mdz: (although gedit as an example, wasn't hard to do at all)
<ajmitch> \sh: so you don't have to abuse the buildd repeatedly? :)
<\sh> Kamion: I hope it's the last one...
<\sh> ajmitch: come on...one source out of .... I didn't count
<ajmitch> heh
<ajmitch> it probably takes only less than a minute to break anyway
<Kamion> and again, using debuild -v would be really really nice
<Kamion> (on merges)
<\sh> come on...wings3d is not my fault ,-)
<Kamion> wings3d?
<Mez> Kamion, bogoupload?
<|rockinnerd|> hello all
<\sh> yes..strange output of the buildd
<Mez> whata  cool word, whats it mean? :P
<Kamion> Mez: throw packages at the buildd until one sticks
<Kamion> I made it up
<Mez> Kamion, hehe :D I like the terminology - I thought that was what it meant :D but had to be sure :D
<Mez> hehe
<Kamion> \sh: I was talking about all your merges; MOM's REPORT file recommends that you use -v in order to make -changes mails informative
* Mez doesnt know how to use MOM
<jordi> mdz_
<Burgundavia> seb128, yes, I noticed that
<Kamion> Mez: the REPORT file tells you
<Kamion> it is linked to from the bugs that MOM files
<Burgundavia> seb128, probably need to have a better dicussion of that sort of behaivour upstream
<Mez> Kamion, REPORT file?
<\sh> ok..after breezy..christmas is coming and if you want to do something good...send all your old amd64 hardware to me ,-)
<Burgundavia> seb128, where is the breakage for this bug? https://bugzilla.ubuntu.com/show_bug.cgi?id=11908
<Kamion> Mez: if you don't know, you don't need to know. ;-)
<\sh> Kamion: ok..from tomorrow on
<Kamion> \sh: thanks a lot
<\sh> today I mean ,-)
<Kamion> those of us who read all of breezy-changes will thank you :-)
<Mez> I dont read breezy-changes
<Mez> I collect it
<\sh> Mez: u r missing something :)
<Mez> hmm?
<Mez> I collect it :D hehe
<ajmitch> it's entertaining reading
<Mez> It jsut gets sent to a folder and marked as "read"
<seb128> Burgundavia: all the notification stuff are b0rked atm
<Mez> so I can refer to it if need be
<Burgundavia> seb128, ok, that as much
<\sh> yeah..daniels poetry is really interessting to read...laughing, crying, screaming whatever mood u like :) it's all in there
<Mez> poetry?
<\sh> my patch dances are nothing ;)
<Mez> * Set DFLT_XKB_CONFIG_ROOT to /etc/X11/xkb. ???
<Mez> ah yes,
<seb128> elmo: python-gtk2-doc sync please
<Mez> I see how the metaphor counterpoints the surrealism of the underlying humanity of the author
<Mez> :-"
<Burgundavia> seb128, hal-device-manger stuff should be pushed upstream to freedeskop.org?
<HrdwrBoB> counterpoints the surrealism? death's too good for them
<\sh> Mez: no u get it :)
* Mez slaps \sh
<\sh> * Make relationship with xbase-clients a little less rocky by removing Conflicts and just use Replaces.  Share the love, people.
<\sh> this is poetry
<Mez> lol
<Mez> MOM's scott's auto merge thing isnt it?
<seb128> Burgundavia: it's a freedesktop stuff, no?
<\sh> Mez: yes
<Burgundavia> seb128, is the gui application freedesktop stuff as well?
<Mez> \sh yeah I remember getting a few of those bugs for k3b
<Mez> until we overtook debian
<\sh> * Add a Build-Depends on libxext-dev.  For my next stunning move, I'll actually pay attention to what I'm doing.
<seb128> Burgundavia: afaik yep
<Burgundavia> seb128, ok
<Mez> \sh Daniel Stone?
<\sh> Mez: yep
<Mez> "THANKYOU LIBTOOL.  YOU MAKE WAKING UP IN THE MORNINGS WORTHWHILE."
<\sh> u see...laughing, crying, screaming..everything is in breezy-changes ;)
* Mez sighs at the " 0 (0)"'s next to his packages in MOTU
<Mez> REVU *
<\sh> STRIKE!
<Mez> o_O
<\sh> kamion: u never see an upload of ire again :) 
<carstenh> jbailey: should {en,dis}abeling of inetd based services possible?
<ajmitch> Mez: we'll get to them..
<jbailey> mdz: I remember you mentioning that in breezy, services might be tweaked to not use inetd by default.  How much should the firewall manager try to get inetd right?
<carstenh> s/possible/be possible/
<Burgundavia> seb128, we are going with 00.o2 for Breezy?
<pitti> Burgundavia: yes
<tseng> we already have it?
<hub_> bah
<hub_> and abiword 2.4 ?
<Burgundavia> pitti, ok
<hub_> not yet released :-/
<sivang> pitti: nice to see you up to late :)
<sivang> pitti: 'sup?
<pitti> sivang: I waited until ffox finished on the buildds, now I'm releasing it
<pitti> I can't let the folks out wait any longer 
<pitti> the world just got a working hoary firefox again
<sivang> pitti: wow, thanks , I didn't know hoary's friefox didn't work :)
<sivang> pitti: (I will thank you tommorow at work, where I Have hoary)
<pitti> sivang: well, it worked reasonably without extensions
<Mez> pitti: hows FF going?
<pitti> Mez: just released it, typing the advisory now
<Mez> kk
<mdz> jbailey: does it matter to the firewall manager?  either there is a port listening or not, right?
<carstenh> mdz: the firewall-gui has an integrated services-configuration-tool
<carstenh> mdz: should this tool support enabeling or disabeling inetd based services at your opinion?
<mdz> carstenh: as long as it is possible to filter the port, it's not important to me whether it can enable/disable the service also
<carstenh> mdz: ok, those two parts are independent. thanks.
<Burgundavia> carstenh, how does your services disabling interact with the gnome-system-tools one?
<MishaS> hi. i just read /topic. :)) any eta for the fixed X? :)
<Burgundavia> MishaS, October 13, 2005 at the latest
<carstenh> Burgundavia: i pinged $some_dd_which_name_i_forgot and asked him which one will be default, the one in gst or bum
<carstenh> Burgundavia: depending on his answer i will use either the database from gst or bum
<Burgundavia> ok
<Burgundavia> are you going to use the UI from either as well?
<MishaS> Burgundavia: that's fair enough :)
<\sh> cheers people off to bed
<Burgundavia> MishaS, to truly answer your question, mileage varies between people
<sivang> seb128: take it while it's hot :) http://muse.19inch.net/~sivan/lpint/file-roller/
<sivang> seb128: good night now, see you tommorow
<sivang> night all!
<carstenh> Burgundavia: i will write my own gui, maybe i can reuse some code. i will know this after i had a closer look at the one which will be default
<Burgundavia> carstenh, the current g-s-t gui is a very nice one, simple and easy. Don't see why you would need to write another one
<carstenh> .oO(chkconfig in redhat is a really nice tool)
<carstenh> Burgundavia: 'cause it is part of my bounty :)
<Burgundavia> grr...
<Burgundavia> having two seperate and different UI's to do the same thing is very non-Ubuntu/Gnome
<seb128> sivang: thanks
<carstenh> Burgundavia: you could disable one per default
<carstenh> Burgundavia: kubuntu-users normally don't have gst, right?
<carstenh> Burgundavia: i really don't know, but i guess it
<Burgundavia> no
<carstenh> not right?
<Burgundavia> kubuntu users have their own kde stuff
<carstenh> ok, does it provide a service-config-tools?
<MishaS> Burgundavia: do you know if there were any changes in xkb between xfree86 and xorg?
<Burgundavia> just looking at the mac os x firewall tool, it only seems to lock down the port, not disable the service
* MishaS is trying to convert his config and fails as certain files are just missing...
<Burgundavia> MishaS, no idea, I don't code
<Mez> am i ok shving MOM stuff in revu? seeing as I dont have upload (and markit as PEND and link to it in the bug)
<MishaS> Burgundavia: sorry.
<carstenh> Burgundavia: it disables services too, it has three tabs, one for en-/disableing services
<Burgundavia> ok
<Burgundavia> what about merging the services stuff into your code then, and do a tabbed interface?
<carstenh> Burgundavia: the problem is that i did not know about services-admin when i wrote my proposal and it was in the original bounty
<Burgundavia> ok
<carstenh> Burgundavia: ubuntu-development is python-centric, services-admin is written in c + glade + perl
<Burgundavia> yes
<carstenh> Burgundavia: so this would be very hard, but maybe i can reuse the glade-part
<carstenh> Burgundavia: JFYI: the gui will look like this: www.fh-trier.de/~heyc/fwgui.jpg
<Burgundavia> I saw that earlier
<carstenh> ok
<Burgundavia> what goes under sharing?
<carstenh> hmm, same question the second time :/ i should find another name
<carstenh> Burgundavia: internet connection sharing
<Burgundavia> ok
<Burgundavia> sharing to me means p2p and other things
<Burgundavia> no ics
<Burgundavia> s/no/not
<carstenh> Burgundavia: do you have a better name for it?
<carstenh> Burgundavia: many people will not understand masqerading or snat
<Burgundavia> yes
* MishaS . o O (non-p2p internet connection sharing :)))
<carstenh> Burgundavia: mac os x calls this internet
<carstenh> MishaS: too long :)
<Burgundavia> not ideal either
<MishaS> npics :)
<carstenh> npics?
<MishaS> just first letteers :) sorry,could not resist...
<carstenh> ah, most people would not understand it ;)
<Burgundavia> what about network?
<carstenh> Burgundavia: sounds really good, thanks :)
<pitti> night guys
* pitti falls into bed
<carstenh> night pitti 
<carstenh> Burgundavia: i have also space for two rows
<pitti> and if anybody yells "Firefox" at me tomorrow, I'll do something very bad to him
<pitti> I have 8 hours of sleep to think about what in particular :-)
<pitti> night everybody
<carstenh> .oO(Internet Sharing or Connection Sharing?)
<TerminX> blah.. synaptic locks up X and apt-get --build source synaptic fails :(
<carstenh> .oO(... or Network Sharing)
<Burgundavia> carstenh, network sharing is the most clear, but I don't know about length
<carstenh> Burgundavia: wait a minute
<carstenh> Burgundavia: www.fh-trier.de/~heyc/fwgui.jpg
<Burgundavia> what goes under properties?
<carstenh> Burgundavia: should be enough space
<Burgundavia> yes
<carstenh> Burgundavia: respond to pings, logging...
<Burgundavia> hmm
<Burgundavia> can you provide me a list of exactly what you are planning to put under there?
<Burgundavia> just looking for a more descriptive name
<elmo> seb128: done
<carstenh> Burgundavia: ok, i don't have decided what to put there
<Burgundavia> oh
<carstenh> Burgundavia: but i will think about it and contact you
<carstenh> Burgundavia: or i could think about it now and ping you when finished
<Burgundavia> another point, there is no indication of whether or not the firewall is currently running
<Burgundavia> maybe add a Status section on the first tab would be good
<Burgundavia> with a clear icon showing the current status
<carstenh> Burgundavia: there is a label "Firewall started" or "Firewall stoppen"
<Burgundavia> it needs to be more clear, IMHO
<seb128> elmo: thanks
<carstenh> Burgundavia: i don't want too much tabs
<Burgundavia> seperated and made bigger
<Burgundavia> not another tab, just above the current rules stuff
<carstenh> Burgundavia: a red or a green light?
<Burgundavia> green check and red x
<carstenh> Burgundavia: sound really good, thanks :)
<Burgundavia> with the words: Started
<Burgundavia> and Stopped
<Mez> makefile.in's shouldnt be shipped with a package should they?
<Mez> (source) they should be built in debian/rules right
<Burgundavia> and then a button with a stop sign that says "Stop all traffic"
<Burgundavia> carstenh, I have to run. PM me with anything new.
<carstenh> Burgundavia: ok, thanks a lot :)
<Burgundavia> carstenh, np. I can't code worth a dman, but I think I can help you with your interface
<carstenh> Burgundavia: stop firewall != stop all traffic
<Burgundavia> yes
<carstenh> Burgundavia: should both be implemented at your opinion?
<Burgundavia> but the most common thing people are going to be doing is to stop all traffic
<Burgundavia> stopping the firewall is less likely and possibly shoulnd't be implemented, due to security issues
<Burgundavia> I would leave it out for now, and see if we get bug reports about it
<carstenh> Burgundavia: if a service is not working imho users should be able to disable the firewall to find out if the firewall is the reason for this
<Burgundavia> true
<carstenh> Burgundavia: leave out "stop firewall"?
<Burgundavia> there are also risks that the user might be just disable the firewall and forget about it
<shackan> maybe you know zone alarm on windows, it has a special "lock all internet activity" button (apart from enable/disable the firewall)
<Burgundavia> yes
<shackan> maybe that's what you want
<Burgundavia> you need to have it in a place and worded that it does not get confused with the lock firewall option
<Burgundavia> how about lock firewall
<Burgundavia> and turn off firewall
<carstenh> shackan: i will search a screenshot of it on google :)
<Burgundavia> don't bother
<Burgundavia> zone alarm has a crap ui
<Burgundavia> firestarter has something similar
<Burgundavia> but I really do have to go
<shackan> carstenh, I have to install it everytime I'm asked to do a windows reinstall, that's why I know it
<carstenh> Burgundavia: ok, thanks. i will ping you when i have results :)
<carstenh> shackan: :)
<Mez> why is my automake in breezy using 1.4-p6 ?
<bob2> because the packages are versioned now
<bob2> if you want a more recent one, install and call it explicitly
<Mez> ah fair enough
<seb128> update-alternatives --config automake 
<Mez> it's ok just updating a Makefile.in and stuff
<sabdfl> lamont: ping... do you have a firm date for that conf?
<Mez> for a package
<Mez> lol
<Mez> morning sabdfl
<sabdfl> hey Mez
<Mez> nother late night eh?
<sabdfl> Mez: not in brazil it isn't, *yet* ;-)
<Mez> ah, didn't know you were over there
<Mez> lucky you
<Mez> if you ever find spare room in your suitcase, feel free to shove me in there :P
<Amaranth> so, did you guys finally give up on firefox and just put 1.0.6 in hoary?
<tseng> Amaranth: :/
<Amaranth> tseng: bad subject? :)
<tseng> users will consider that a precendent
<Amaranth> well, i just got mozilla-firefox-1.0.6-0ubuntu0.1 from hoary-security
<tseng> so did I
<mdz> sabdfl: hey, how goes the battle?
<Amaranth> oh, and i lost _EVERYTHING_
<sabdfl> mdz: one small victory at a time. yours?
<Amaranth> smeg 0.8 is set back about another month... :/
<Amaranth> and that's only if i can get breezy running
<Amaranth> how is breezy today, anyway?
<tseng> Mez: will the new backports infrastructure start for hoary or breezy?
<Amaranth> it's already setup for hoary, just needs the script run
<tseng> Mez: it will potentially simplify mono-live cd development quite a bit
<Mez> as Amaranth said
<Mez> er...
* Mez yawns and pokes stuf
<mdz> sabdfl: likewise.  house is now officially dry as of an hour ago.
<Mez> Failed to fetch http://security.ubuntu.com/ubuntu/dists/hoary-security/main/binary-i386/Packages.gz  MD5Sum mismatch
<sabdfl> mdz: officially dry, as in, you've drnk the last of your bourbon?
<mdz> sabdfl: I think that would have left me in a significantly worse position than I currently am
<mdz> it has been >40C inside the house through the weekend due to the machines, and is only just returning to a livable environment
<mdz> I am also able to read email again for that and related reasons
<mdz> I had to shut down my server here due to heat and electrical overload
<mdz> sabdfl: anyway, it looks like the worst is over, and it's relatively straightforward repair work from here
<sabdfl> cool. we made good progress today with soyuz, though scott was ill and we didn't get much further on hct
<sabdfl> night all
<lexhider> can I get someone to confirm a firefox bug for me before a file it on bugzilla?
<Amaranth> uh oh
<Amaranth> yeah, i just found a firefox bug too :)
<Amaranth> what's yours?
<lexhider> running firefox hoary, open a couple of tabs and select any tab but the 1st one. Preferences->HomePage "set to current page".
<lexhider> It then puts in the url for the 1st tab not the curren tab.
<infinity> lexhider : Is this with the 1.0.2 in hoary, or the 1.0.6 in hoary-security?
<infinity> With 1.0.6, I see a "Use Current Pages" button (yes, that's plural), and clicking on it gives me the URLs from all 3 tabs, seperated with pipes.
<lexhider> 1.0.2, the one from hoary-security made it so I couldn't use or make bookmarks.
<infinity> And then clicking on the Home button opens 3 tabs with all three pages.  Neat.
<infinity> lexhider : That was the 1.0.2 security update that broke bookmarks (I think), try upgrading again.
<lexhider> infinity: will do.
<lexhider> D'oh, my behaviour is the same as yours, I didn't realize that it had done it for all open tabs because you can only see the start of the 1st url.
<lexhider> I might file an upstream bug about being able to set to single current page without setting to all open tabs, thanks.
<Amaranth> yay
* Amaranth is fully upgraded on breezy and has a working X
* Amaranth cheats
<Amaranth> update-fonts-dir, mkfontdir, mkfontscale copied from hoary before upgrading :D
<rob^> Amaranth, does this mean X is fixed?
<Amaranth> rob^: no, it means i cheated
<rob^> heh
<rob^> still using a few old packages?
<Amaranth> no
<Amaranth> read what i said earlier
<rob^> yes, you got horay versions of those packages
<infinity> s/packages/binaries/
<rob^> ah
<eazel7> anybody knows why all gnome apps crashes when gtkfilechooser dialog is shown?
<calc> anyone happen to know if mozilla-thunderbird is ever going to get recompiled?
<calc> it still needs the old libstdc++6-0
<fabbione> morning
<lexhider> .
<bddebian> Hello fabbione 
<WebWiz> is there a way to fix x... i can't test my breezy packages b ecause when i apt-get upgraded X broke.. something about fixed font dir missing
<daniels> WebWiz: #ubuntu is a better channel to ask that sort of thing in
<WebWiz> they told me to talk in #%devel since its breezy
<bob2> when did anyone say that?
<WebWiz> last time i was in there ealier today
<tritium> bob2, daniels should we have an onjoin message pointing to commonly referenced documentation?
<bob2> ha ha ha
<bob2> like putting it in the /topc? or the faq?
<bob2> ;-p
<tritium> yeah, lot of good it does, huh?
<daniels> i think onjoin messages are way too intrusive
<tritium> okay, fair enough.  Just thought I'd ask your opinions.
<TerminX> tritium: maybe one of those onjoin chanserv notices
<tritium> That's what I was asking about.  I think bob2 and daniels are right in vetoing the idea, though.  My bad.
<daniels> mmm
<daniels> the problem with notices is they go to the status window, half the time
<TerminX> I thought you meant actual message, personally
<daniels> so they sort of end up getting read less than the topic
<TerminX> like where it pops up a window and generally annoys the piss out of people
<daniels> but yeah, I thought you meant /msg
<tritium> sorry, I wasn't very clear about what I meant
<infinity> Notices are next to useless in most IRC clients.
<infinity> Unless you're like me, and you just toss all your messages in your active window, thus causing you to contemplate suicide each time you use freenode.
<TerminX> heh
<daniels> tritium: no worries
<tritium> It was just an idea...but I do retract it :)
<TerminX> it wasn't a bad idea... hell, if just one person reads it and it answered their question so they don't end up bothering folks then it was a good idea :p
<tritium> :)
<TerminX> s/answered/answers
<infinity> Assuming that anyone will read anything, when they've clearly skipped the google step to come bother people on IRC, is a bit optimistic.
<infinity> (Well, okay, some perform the Google step, but most prefer to just ask someone directly for All The Answers)
<TerminX> infinity: ugh, all of my "friends" do that to me.
<TerminX> I don't see what's so hard about Googling.. meh, some people
<infinity> My friends once nicknamed me "The user-friendly interface to Google", because I could always find the answer faster than them, using the same methods I kept insisting they should use.
<tritium> heh
<infinity> Eventually, I just started ignoring questions for a day or two, until I was pretty sure they'd have found the answer already.
<TerminX> that sounds about like the situation I often find myself in, yeah
<HiddenWolf> infinity, I hear you
<infinity> Then, shortly after that, I drifted off-topic in a devel channel, aplogised profusely, and went back to work.
<TerminX> hah
<HiddenWolf> I'm known as a news junkie. Whenever they want to know something, it's "Wolf will know" :P
<HiddenWolf> And I went to such pains to break my addiction to cnn. :P
<TerminX> I have /., Y! news, CNN and BBC RSS feeds.. and I check them all ;_;
<bob2> tritium: oh, no veto, I'm just cynical about how well it would work
<HiddenWolf> I'm old school, I actually browse there, to check it out, or turn on tv.
<tritium> bob2, with good reason, I'd say.
<bob2> daniels: does http://www.cse.unsw.edu.au/~timl/ubuntu/README look like it'll at least somewhat unbreak X?
<tritium> ah, you got the same query from timl?
<bob2> yaeh
<daniels> bob2: one case, yeah
<daniels> but not comprehensively
<daniels> and mkfontdir will be going in an hour or two
<bob2> ah, rock
<tritium> nice work, daniels :)
<daniels> ta
<TerminX> will X work after that, or is there even more?
<daniels> x will generally work after that, in the right set of circumstances
<daniels> e.g. fresh upgrades from hoary
<TerminX> how about upgrades from -36? :p
<daniels> people who have tracked breezy get a whole new world of pain because of some misguided attempts by xlibs to delete XKB data
<daniels> right
<daniels> see: world of pain
<daniels> i'm going to send out a pretty comprehensive email covering how to unscrew yourself
<highvoltage> daniels: as I've just learned :)
<TerminX> daniels: to ubuntu-devel I assume?
<highvoltage> actually, it complained that the directories weren't empty, so i manually deleted all the directories (obviously a bad idea)
<daniels> TerminX: -users and -devel
<daniels> highvoltage: heh, right
<daniels> highvoltage: sudo dpkg -i --force-confmiss /var/cache/apt/archives/xkeyboard-config_0.5-3_all.deb
<highvoltage> daniels: thanks!!!
<infinity> I think I'm going to have children with ccache.
<infinity> Yessir.
<bob2> hot infinitytridge babies
<infinity> No, no, not with Tridge, with ccache itself.
<infinity> I sent Tridge a pizza back in 1996, he's not getting more from me.
<clerax> #securityhack big french hacking community alsoo www.securityhack.net FRENCH p0w@ =)
<Aegir> Hmm
<trulux> ah, he left by himself. N1c3
* trulux grins
* Aegir prods the space clerax used to occupy
<highvoltage> cool. now i only have the mkfontdir problem.
<daniels> 'french powat'?
<Burgundavia> indeed
<Aegir> That powat! Fear the powat!
<tritium> night
<Burgundavia> funny wiki page, what mark wanted for Hoary --> https://wiki.ubuntu.com/MarksHoaryGoals
<trulux> Burgundavia: I find the "makes me very nervous" bit about SELinux deployment funny indeed
<bob2> did kinnison/thom/scott's init speedups go into hoary?
<Treenaks> bob2: a few did, I guess
<highvoltage> would it work if i copy the mkfontdir script from a hoary system?
<pitti> Morning
<pvanhoof> highvoltage, yes
<Burgundavia> pitti, you are the talk of the town on the forums. And the .6 security release breaks all those fancy backports
<pvanhoof> I did this, and it worked .. highvoltage 
<highvoltage> pvanhoof: kewl, i'll try that. thanks
<pitti> Burgundavia: it's not my fault that the backport guys messed up the package name
<pvanhoof> highvoltage, just dpkg-reconfigure xfonts-base once mkfontdir is installed
<Burgundavia> pitti, hey, no skin off my back
<pitti> Burgundavia: btw, I didn't know about this, otherwise I had warned them
<pvanhoof> note, however, highvoltage, that the keyboard settings will not work. It always fallsback to "us"  here (whereas I have us_intl)
<pvanhoof> other than that I don't have a lot problems with current X11 in breezy
<pitti> Burgundavia: how did that break in particular? I mean, it's just a new version of the same package, same dependencies, etc
<Burgundavia> pitti, the security package will not install without removing the backport and then reinstalling the secuirty package
<Burgundavia> nothing you could have done by telling them about it
<pitti> Burgundavia: but if you have the backport, why would you want the security update?
<pitti> it shouldn't be automatically installed?
<Burgundavia> the system forces the security update upon you
<Burgundavia> personally, i would want offiical packages to override backports even if they are the same versin
<pitti> Burgundavia: hm, I still not understand. The problem is that the hoary-security version overwrites the backport, or that it doesn't?
<Burgundavia> pitti, the security version does not overwrite the backport
<bob2> and the backport is called firefox
<daniels> facepalm
<pitti> bob2: that's what I meant by "screwed up" 
<bob2> ah
<thom> bob2: all the useful ones did
<bob2> thom: ah, cool
<daniels> yeah
<daniels> a lot of stuff got its order shuffled around
<daniels> and X's loader is 27% less crap
<Treenaks> \o/
<thom> plus readahead
<thom> which we need more magic for at some point
<daniels> yeah
<daniels> getting the list of files opened at boot from a wide range of desktops would rock
* pitti goes offline for a while since his main network is broken
<sivang> mornig all
<Treenaks> hey siv
<sivang> yo Treenaks :) funny how you know the shortcut name of mine, just like people say it in hebrew 
<\sh> morning 
<Treenaks> sivang: heh.. it just seems natural :)
<doko> daniels: any estimate for a working xmkmf ?
<thom> daniels: being able to configure it automagically per machine would rock harder
<\sh> doko: u need it as well..good ;-)
<\sh> infinity: ping 
<infinity> pong.
<daniels> doko: not hugely, have other stuff on my TODO ahead of it
<\sh> infinity: please check xchm...it's depwait on libwxgtk2.5-dev but I've uploaded with libwxgtk2.4-dev...
<daniels> since relatively little stuff uses xmkmf these days
<daniels> maybe you could take this opportunity to kick your build system into 1983 ;)
<infinity> \sh : Okay, will check it in 5 minutes.  Just doing some hardware maintenance.
<\sh> infinity: take your time...I just saw the mess..thx :)
<ogra> seb128, http://lists.ubuntu.com/archives/ubuntu-users/2005-July/043841.html
<doko> daniels: please make it high priority. it's a build dependency for OOo2, and for breakages, we could not build OO for the last three weeks
<doko> s/for/for other/
<ogra> seb128, isnt thekey set in the breezy package ? i wonder where they backport from ...
<daniels> doko: sorry, but getting upgrades and from-scratch installs working is more important, to be honest
<daniels> doko: if you need to build it locally, use an old version of xutils
<daniels> getting it working on the buildds is very, very difficult
<daniels> and it also only affects one or two packages, rather than everyone using it
<j^> daniels why dont you change the default background of X to be black(or some solid gray)? adding -br to gdm.conf would also help, but that does not happen eather.
<doko> well, maybe I just include xutils in the oo2 source then
<daniels> doko: how rampant is xmkmf usage? usually it's only invoked to get one variable or so
<daniels> j^: -br works fine, I just tested it then.
<bob2> black would be pretty obnoxious when trying to debug if it's starting or not
<daniels> as for gdm.conf, I don't know as I don't maintain gdm
<seb128> ogra: this mail says that the key is not set
<daniels> but ISTR it was at some point
<j^> daniels right it works fine, but why is it not the default,
<j^> or a gray
<ogra> seb128, yes, i thought thats done in postinst of our package 
<daniels> also, the stipple is a fantastic calibration pattern for monitors
<daniels> j^: i don't know; as I said, I don't maintain gdm.
<j^> but this zigzag thing hurts
<seb128> ogra: what? the postinst register the schemas, but serpentine has no schemas
<seb128> gdm uses -br
<ogra> seb128, err... ok....
* ogra remembers we had this discussion before...
<j^> seb128 right now it did not, i had to add that again to gdm.conf
<seb128> j^: it does
<j^> ok
<ogra> seb128, do you already have a plan how to bring all the xscreensaver hacks into gnome-screensaver ?
<seb128> j^: you probably have changed your file and since that's a conffile keep your changes rather than the package ones
<seb128> ogra: what hacks?
<j^> seb128 gmdconfig changes that file
<seb128> j^: the correspond patch is debian/patches/01_xconfigoptions.patch
<ogra> seb128, they (or jwz) call ll the screensavers "hacks" sorry for th term :)
<seb128> j^: whatever change the file, once changed you use your version and not the package one
<seb128> ogra: the plan would be to split xscreensaver to a binary and a sreensaver package
<ogra> seb128, hmm, i'm not sure if thats easily possible
<seb128> why?
<infinity> ogra : Sure it is.
<seb128> that's trivial
<ogra> oh, ok... 
<seb128> just have to update the debian/control and make a .install 
<ogra> i just thought you had to put tem all in the src dir...
* infinity blinks.
<ogra> since single screensavers require single compile oiptions that should be makefile fun ...
<doko> daniels: used in some third party sources, which are unpacked, patched and built during the ooo build
<seb128> ogra??
<daniels> doko: which ones?
<seb128> ogra: there is no change to make to the source package, just to the binaries ...
<ogra> seb128, ah, it just grabs the binarys ? 
<seb128> grumpf
<ogra> ok..
<seb128> basically you make install to debian/tmp
<seb128> and move file with .install files
<seb128> you move them wherever you want
<doko> daniels: I have to work around the primary configure checks to see which ones ...
<sivang> seb128: is it true that /tmp represents the to be installed on system's / ?
<sivang> seb128: (I read that somewhere)
<seb128> I don't get the question
<daniels> doko: grep -r xmkmf?
<daniels> sivang: not quite
<ogra> seb128, sure, but we either need a dumbed down xscreensaver package that only contains the "hacks" or put them into gnome-creensaver
<bob2> sivang: in the installer, or do you mean debian/tmp during a package build?
<sivang> seb128: /tmp inside the .deb maps to / on the system the binary pkg is being installed on
<seb128> ogra: split xscreensaver to -bin and -data
<sivang> bob2: inside a binary package that was built
<thom> sivang: NO
<ogra> seb128, ah... that was the question...
<seb128> sivang: I've not tried to put /tmp to a package yet
<seb128> sivang: that doesn't seems to be a good idea
<daniels> seb128: better than /usr/sbin
<bob2> sivang: no, data.tar.gz is relative to /
<sivang> daniels: could you please explain?
<daniels> sivang: debian/packagename/ contains all the files (relative to /) for packagename
<daniels> the special case is that debian/tmp is read if there's only one binary package
<thom> (if you're using debhelper)
<sivang> thom: what happens if I'm using cdbs, for instance? does it act differently?
<daniels> thom: let's assume that everyone except piotr is
<infinity> cdbs uses debhelper.
<thom> sivang: you burn in the utmost fire of hell
<daniels> sivang: the usual mode of cdbs involves using debhelper, but thom has a point also
* sivang screams infront of the hellfire.
<sivang> come to think of it, almost all the gnome pkgs in ubuntu use cdbs...is it that bad?
<infinity> thom : To be fair, I think the "utmost fires of hell" are reserved for yada usage.  cdbs is probably somewhere slightly less deep, but still uncomfortably hot.
<thom> sivang: seb128 signed a pact in blood
<sivang> hehehe
<thom> infinity: no, yada is a personal meeting with the Shrike
<sivang> thom: why is it so bad?
<bob2> unfucking yadaed packages is painful, too
<doko> daniels: As I said, the tarballs are unpacked and patched by the upstream build process
<daniels> doko: zgrep -r :)
<daniels> otoh, dbs is love
* sivang wonders what yada packages are
* bob2 quotefiles daniels 
<doko> that does work recursivly and and zip files?
* thom makes whig+pen gang signs
<bob2> sivang: e.g. lyx
<daniels> doko: zgrep xmkmf $(find ./ -name \*gz)
<bob2> sivang: everything is in debian/package, which gets untangled by yada at build time
<sivang> bob2: hmm, no man for yada, is yada a tool?
<bob2> yes
<bob2> of the devil
<thom> sivang: DON'T EVEN LOOK AT YADA
* sivang starts to think this is not a joke
<Treenaks> apt-get install yada
* sivang installs the tool of the devil
<sivang> ah! so that's the DBS, without the C :)
<daniels> dbs is love
<thom> dude. it's all about whig+pen
<sivang> daniels: pretty cool, everything clutters up in debian/packages and you are free of writing a rules file?
<daniels> sivang: err ... dbs is nothing like either of those two
<Treenaks> sivang: daniels apparently has a strange definition of "love"
<thom> sivang: no, that's yada. DBS is entirely different
<daniels> thom: meh, I can't get past the ability to throw away and reconstruct my build tree without touching debian/ etc for the monolith
<daniels> for more sensibly-sized packages I just use dpatch
<daniels> which will become W&P when it's feasible
<sivang> thom: so DBS is plain debhelper stuff with a regulra debian/ structure?
<daniels> sivang: yes, except the source gets unpacked from a tarball in the source package and patches applied from debian/patches
<daniels> so your actual code is in build-tree/xc/, for example
<Treenaks> so your tarball just contains a directory of upstream tarballs
<daniels> right
<daniels> and the debian/ directory
<sivang> ah, that is one approach pitti really likes
<azeem> surprisingly, that's the same for gcc, though it uses dpatch
<seb128> you can also use cdbs and tarball.ml
<sivang> seb128: hmm, I think that's what his using acutally IIRC :)
<thom> pitti has been known to patch debian/ so he doesn't count :-)
<daniels> seb128: yes, but that involves using cdbs
<daniels> yeah, patching debian/ from debian/patches -> total crack
<sivang> daniels: how should one go about patching debian/ ?
<sivang> daniels: (or should he not ??)
<daniels> sivang: DON'T
<daniels> EVER
<thom> sivang: one shouldn't. EVER
<azeem> just do debian/control.in and use sed
* azeem hides
<daniels> i think pitti patched debian/patches from debian/patches once
<daniels> that was crack
<daniels> azeem: i know! then we could automatically generate build-depends
<daniels> azeem: THAT WOULD BE SO AWESOME
<bob2> hahahaha
* thom puts azeem on the elevator straight down to HELL too
<ogra> lol
<sivang> heheh 
<sivang> thom: however, cdbs allows seb to do gnome packaging in remarkable timeing, isn't that a plus?
<daniels> sivang: he can do it just as fast with a normal debian/rules
<daniels> sivang: it's just that seb really likes pain
<sivang> LOLs
<sivang> daniels: but he would have to replicate file all over and over again, no?
<daniels> he has to copy a template debian/rules anyway
<daniels> doesn't make much difference whether or not it's cdbs
<daniels> trust me, I will end up maintaining more packages than Seb before breezy's out
<sivang> daniels: using plain DBS ? (and using upstream tarballs)
<azeem> DBS should be outlawed, Ubuntu missed a great opportunity here
<daniels> sivang: nope, just normal debhelper with dpatch
<sivang> daniels: eh, I like dpatch, it's nice for keeping order in patches
<daniels> that's what I'm using atm
<seb128> simple-patchsys rock :)
<seb128> daniels: I will help you to win on the packages game ... do you want to maintain gtk ? ;)
<daniels> simple-patchsys killed and ate my dog
<daniels> it slit its throat and turned it into a pez dispenser
<daniels> simple-patchsys has no mercy
<ogra> yes, cdbs is a great frontend to cp if you want to package icon themes.... (i never use it for anything else, are there other usecases ?) :)
<daniels> seb128: no way dude
<daniels> seb128: the whole plan behind modularisation is that I can make you maintain half the crap in the client-side libraries
<Burgundavia> seb128, ogra you in contact with rodigo?
<ogra> Burgundavia, which rodrigo ?
<Burgundavia> ogra, rodigo moya, of gnome fame
* seb128 kicks daniels
<seb128> Burgundavia: not a lot, standard IRC, why?
<ogra> Burgundavia, seb128 rather then me
<Burgundavia> seb128, ogra planet.gnome.org has somethign about gnome-screensaver right now from him
<seb128> so the code is fine according to suse guys, nice
<sivang> suse suppports gnome now? interesting :)
<seb128> that's not news
<seb128> ximian, gtk#, etc
<sivang> eh right
<ogra> seb128, haha.... werent they the guys that just stuck gtk on top of the xscreensaver lock dialog ignoring the security problems ?
<Treenaks> sivang: well, in 9.3 it still really feels like the "second choice"...
<pitti> daniels: patching debian/patches from debian/patches was not really intentionally :-)
<sivang> daniels: anyway, after I finish with patching desktop apps for lp integration, I will seek the ways of the holy ones, for now I will continue to change cdbs packages :)
<azeem> sivang: cdbs is the way of the holy ones
<sivang> azeem: hehe
<thom> cdbs will be the way of the hole-ey ones after i finish with them
* ogra dosnt trust the suse security team, they are not half as smart as pitti :)
<pitti> ogra: they are really smart, believe me
<\sh> ogra: that u can't say...is it not "good quality german work"? ,-)
<ogra> pitti, they found putting gtk on top of the lock dialog secure... ignoring all voices that said different...
<daniels> \sh: s/work/engineering/
<ogra> pitti, thats not really trustable imho... if even upstream warns you all the time
<\sh> daniels: "work" cause the germans are workers ,-) the german engineers are all US guys now ,-)
<infinity> \sh : Dude, do you only have one eye?
<\sh> grmpf..I'm too sarcastic this morning ,-)
<pitti> ogra: ok, that's crack; my experience is wrt their vuln patches
<\sh> infinity: looks like...why?
<infinity> \sh : Pure curiosity, based on your smiley.
<\sh> infinity: it's "ironic smiley" 
<\sh> or was it sarcastic, with one eye totally gone? 
<daniels> it's a sarcastic pirate
<daniels> AHR
<ogra> heh
<\sh> i should clean my laptop keyboard...with this tobacco inside, I can role a cigarette *shrugs*
<mvo> is nautilus supposed to come up in browser mode now? it does that for me after a dist-upgrade 
<Burgundavia> mvo, yes
<lexhider> mvo: yeah
<infinity> Changing nautilus behaviour with every release is the Way and the Light.
<HrdwrBoB> haha
<ogra> *shudder*
<lexhider> mvo: http://bugzilla.ubuntu.com/show_bug.cgi?id=8516
<daniels> infinity: s/with/immediately before/
<infinity> Hey, Microsoft managed to make Explorer scarier every time I opened it, surely we can one-up them.
<HiddenWolf> infinity: they just announced they'd lock upgrades to illegal users. Get your cd's out.
<daniels> infinity is not short of CDs.
<seb128> mvo: hi. What about reading the changelog stuff? It's made for that ... :p
* infinity scratches his head.
<infinity> How did I manage to debootstrap a hoary chroot with no apt-get binary in it?
<infinity> No apt package at all, in fact.
<infinity> Neat.
* HiddenWolf pionts and chuckles softly
* HiddenWolf hides
<daniels> infinity: special
<mvo> seb128: heh :) who needs changelogs when there is a fine channel like this available (/me ducks)
* seb128 wonders why he bother to document change for every single upload :p
<daniels> me too
<daniels> '* New xorg upload.'
* Mez tries to sneak into the conversation
<daniels> '* Fixed some shit.'
<infinity> daniels : Too verbose.
<daniels> '* <3samxxx'
<infinity> Something more like "package (1.2.3) breezy; urgency=low\n\n * Take it\n\n Adam Conrad <adconrad@ubuntu.com> `date --rfc`" is what's going in all my packages from now on.
<[SemTeX] > daniels: does it fix the "crash after login" thing?
<Mez> daniels, arent changelo entrys like " THANKYOU LIBTOOL.  YOU MAKE WAKING UP IN THE MORNINGS WORTHWHILE." vague enough for yo
<daniels>    * New upstream version:
<daniels>      - More work on Win32 support.
<daniels> seb128: your changelogs are the suck
<daniels> [SemTeX] : the what now?
<daniels> Mez: that wasn't vague, it was accompanied with a full description of what I changed before the expression of love
<Mez> hush
<Mez> lol
<Mez> I did have to stop myself laughing when I saw this though
<Mez> "  * Fix cat-walks-across-keyboard attack in debian/control."
<[SemTeX] > daniels: i had an error about xlib not supporting my locale and x died after login
<Burgundavia> seb128, because it is useful
<infinity> Mez : Whose was that?
<daniels> [SemTeX] : then that's GNOME being crap, but likely you just need to install xrdb
<Mez> infinity - guess :D
<seb128> daniels: ah ah, yeah, upstream suck :p
* fabbione -> food
<[SemTeX] > daniels: ok, i'll try that, thx
<daniels> i bet they assume xauth will be available everywhere, too
<daniels> [SemTeX] : in future, please use #ubuntu for that sort of thing
<daniels> /* sorry, streams support does not really work yet */
<daniels> #if defined(STREAMSCONN) && defined(SVR4)
<daniels> #undef STREAMSCONN
<daniels> #define TCPCONN
<daniels> #endif
<daniels> seb128: you think YOUR upstream sucks?
<bob2> haha
* Mez starts up "Campaign for Real Changelogs"#
<daniels> and are there Unix systems out there without SIGHUP or SIGPIPE?  FFS.
<daniels> Mez: which would you prefer, that, or 'Fix typo in debian/control'?
<daniels> Mez: if you want more details, debdiff is for you
<Mez> daniels: I find your style of changelogs more "real" than any other :P
* infinity is hurt.
<Mez> they're more honest, and less boring
* HiddenWolf hugs infinity
<daniels> infinity: i'm representin' the man on the street
<infinity> And the cat, apparently.
<daniels> infinity: i hate my cat.  yours if you want it.
<infinity> Really?... Sold.
<HiddenWolf> daniels: how can you hate a cat?
<daniels> HiddenWolf: it breaks my debian/control files
<daniels> cat + vim -> stabbings
<Treenaks> daniels: use ed
<daniels> Treenaks: much less obscure
<infinity> Man, if your cat can use a modal editor, I'd be giving it extra treats, not stabbing it.
* HiddenWolf laughs
<infinity> I've seen grown men break down and cry because they couldn't figure out how to exit vi.
* Treenaks waits for REJECT mail so he can poke elmo
<ogra> daniels, get a dog for you keyboard that drives away the cat :)
<pitti> Treenaks: what did you upload?
<daniels> infinity: my little sister can use vim
<infinity> daniels : As a bonus, dogs are too stupid to even figure out nano.
<daniels> infinity: as in, she can make things happen.  but not usefully.
<Treenaks> pitti: build-dep fix for lirc (add libusb-dev)
<daniels> infinity: my dog now prevents my cat from using vim.  that's far better than breaking my packages.
<HiddenWolf> ogra, sudo apt-get install watchdog ?
<ogra> heh
<Burgundavia> is someone going to fix bogofilter, so you don't waste more cpu cycles on it?
<ogra> Burgundavia, cpu cycles on buildds are cheap
<infinity> Burgundavia : The thought had crossed my mind, but first I want to print all the failed build logs and make a mud hut out of them.
* Burgundavia can imagine this poor buildd going, "You again? You failed last time, but lets try again"
<infinity> I started with smaller ambitions (a hat), but they keep coming...
<infinity> I may just write a procmail recipe to drop the build logs on the floor, rather than fixing the package.  It is the path of least resistance, afterall.
<infinity> Also, some of this may be sarcasm.
<Treenaks> infinity: why not write a script that goes out and fixes the package for you?
<infinity> procmail's even worse at fixing debian/control than daniels's cat is.
<infinity> And buildd admins only know procmail, so I guess I'm screwed.
<bob2> you use procmail to generate debian/control?
<daniels> bob2: lamont probably does
<daniels> somewhere in there
<infinity> Wouldn't be surprised.
<bob2> after running rcs with some undocumented option over it all
<daniels> nothing wrong with running rcs over your repository
<infinity> ... If it's an RCS repository.
<bob2> there is to the people who have to then import it
<infinity> I've seen people use RCS to do some pretty weird out-of-the-box things.
<ogra>  dh_make -c gpl
<ogra> Option c is ambiguous (cdbs, copyright)
<ogra> huh ???
<ogra> grmpf... someone should fix that
<Kamion> mvo: did that aptitude progress patch ever get uploaded?
<mvo> Kamion: the progress reporting for apt? it's part of libapt and needs approval from mdz. otherwise I think it's ready
<Kamion> mdz: over to you :)
<mvo> Kamion: I'll have a look at it again today just to be certain that the code is ok. how urgent is it?
<Kamion> well, I'd like to do stuff that depends on it for feature freeze
<daniels> The X.Org monolithic tree
<daniels> Lead Maintainer:
<daniels> Robert Collins 
<daniels> if launchpad has done one thing for me
<daniels> it's been to allow me to assign all my bugs to lifeless
* pitti blinks
<bob2> hahaha
<bob2> I get gftp bugs emaield to me
<pitti> Hi jdthood 
<sivang> Hey pitti 
<pitti> Hi sivang 
<daniels> argh, god I hate libXfont
<daniels> if you're building a client library, build a client library
<daniels> if you're building modules for the Xorg server, build modules for the Xorg server
<daniels> combining the two, with a healthy dose of internal FreeType headers stolen from their tree, SUCKS
<ogra> hmm, sounds like the xpm situation in xscreensaver :)
<daniels> WHAT?
<infinity> Please tell me xscreensaver doesn't statically link to a private xpm...
<ogra> daniels, jwz puts xpm functions into xscreensaver to not depend on libxpm, because he considers this unsafe
<ogra> the fun stuff is, that debian changed the logo and just enabled a libxpm dep again... now both is in
<bob2> hahaha
<daniels> COCK COCK COCK
<ogra> but the packae misses the dep apparently see #12888
<Mez> o_O
<daniels> libxpm.  the library with the secutity vulnerabilities.
<TerminX> is the Ubuntu style unlock screen going to be patched back into xscreensaver?
<Mez> daniels, after those mle prostitues again?>
* daniels attempts to breathe deeply.
<ogra> TerminX, we seem to switch to gnome-screensaver
<TerminX> hmmm
<pitti> Hi ajmitch 
<TerminX> version 0.0.8-0.. how reassuring ;\
<Mez> is breezy safe to use yet ?
<bob2> no
<Mez> whats wrong with it atthe moment then
* ..[topic/#ubuntu-devel:daniels] : Ubuntu Development | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://www.ubuntulinux.org/wiki/DeveloperResources | If you have unexpectedly lost editbugs privileges, talk to mdz/ogra/kiko | Colony CD 2 released | X is a little bit less broken. | deadline for outstanding merges is 2005-07-21
<TerminX> ogra: why would there be a switch to something which appears featureless?
<\sh> *phew* that was a lunch
<ogra> TerminX, it integrates with the desktop and has a11y and i18n support... something you will never see in xscreensavers lock screen
<TerminX> it's not even in main..
<ogra> TerminX, we'll make a post to -devel to discuss its default inclusion soon
<TerminX> it only has one screensaver!
<ogra> that will change quickly
<ogra> it will use all xscreensaver hacks that are here now... its just a change of the frontend
<ogra> so all functionallity wil stay as in xscreensaver
<TerminX> will this new frontend actually have configure buttons?  it certainly doesn't have them now
<ogra> good question
<TerminX> it's funny, gnome-screensaver-preferences.. has no preferences
<ogra> seb128, whats planned in this direction ? most of the single screensavers have additional options
<\sh> this is annoying..I'm typing sql statements in orcale sql plus console...but why do we have such nice frontends...when they don't work properly..sometimes I'm wondering about my company..:(
<ogra> \sh, there is tora and toad....
<ogra> depending on yourOS
<\sh> ogra: it's CSR
<sivang> \sh: you ate a good steak? ;-)
<ogra> \sh, heh
<\sh> ogra: and it's more broken then Xorg in breezy..no joke...artyom don't do anything at all to prevent leaving username fragments inside of oracle...
<ogra> \sh, yes, i know...
<ogra> \sh, it's always beeen like that... live ith it or get a better job ;)
<sivang> \sh: you work for oracle?
<sivang> ogra: what's tora?
<ogra> sivang, nope, he works for my ex company...
<sivang> ogra: eh :)
<ogra> sivang, a oracle gui tool
<sivang> and CSR?
<ogra> sivang, a oracle gui tool
<ogra> :)
<\sh> a oracle web gui tool company developed by Java Architect (tm)
<ogra> inhouse developed
<ogra> by cluesless people
<sivang> lol
<\sh> by a java architect ,->
<ogra> but thats OT here :)
<sivang> \sh: I got the point :)
<\sh> ogra: no not OT..we will switch our ISP DNS servers to ubuntu :)
<sivang> ogra: we made Burgundavia really  hungry last night (ne abd \sh)
<ogra> really ??? 
<\sh> ogra: and kicking solaris + sparc out of the halls
<ogra> \sh, youre joking...
<\sh> ogra: nope
<ogra> WOW
<\sh> ogra: it's on the todo of steven carr and he requested my help :)
<ogra> heh
<ogra> \sh, tell him about canonical support contracts ;)
<seb128> ogra: that would be a question for upstream
<\sh> ogra: i did :) and I think ralf is interessted :)
<ogra> thats awesome news...., germanys second biggest cable provider switching to ubuntu is worth a headline ;)
<ogra> \sh, point rim to me if he needs a point of contact, i know he trusts me
<ogra> s/rim/him
<\sh> ogra: *psshht*
<ogra> :)
<\sh> ogra: this won't be a big deal :) 
<\sh> ogra: and the guys upstairs, no they can kick me, when something's not working ;(
<\sh> s/no/know/
<ogra> i know, but they always want support contracts :)
<ogra> as fallback... they are "managers" you know... i sat in this office long enough to know the politics :)
<\sh> ogra: they bought because of your system a full redhat enterprise edition with 3 years support contract...they didn't get one perl package running on your old machine *lol*
<ogra> lol
<\sh> ogra: and believe me, when I heard this, I was falling from my chair...
<mvo> \sh++ for ubuntu :)
<ajmitch> hi mvo, ogra, \sh :)
<mvo> hey ajmitch
<sivang> hey ajmitch 
<sivang> \sh: that's pretty cool to hear, Stephan
<\sh> hey mvo :) ajmitch :)
<ogra> they wanted to write ma a unique trouble ticket system for them, to save money... than they bought HW for 10000 and decided debian was not good enough as base *grin* now they have a system that they could even have bought cheaper for the price of oracle/readhat/HW support licenses
<ogra> s/they wanted to write ma/they wanted me to write a/
<fabbione> pitti: ping?
<pitti> fabbione: here
<fabbione> pitti: i am checking that patch
<fabbione> and there is a possible flow in it
<fabbione> basically pid = last + 1; always ensure that the next pid is different from one already allocated.
<fabbione> the check is simple..
<pitti> trulux: ^
<fabbione> with pid = random()
<fabbione> there is no such check
<\sh> can somebody kick wings3d again to the buildds? thx :)
<fabbione> so i might have process foo with pid X
<fabbione> after N randomization i can get that pid again
<fabbione> but nothing is protecting it
<fabbione> the pid reusage is based on a 16bit rotation
<fabbione> if there are more than 2**64 pids the kernel refuses to start the process
<fabbione> so last + 1 is always safe
<fabbione> +if (pid == pid_max)
<fabbione> +pid = pid_max - 1;
<fabbione> should really be:
<seb128> infinity: could you push the buildds to retry file-roller sound-juicer zenity with gnome-doc-utils 0.3.1-0ubuntu2?
<fabbione> ops
<fabbione> if (pid >= pid_max)
<fabbione> pid = RESERVED_PIDS;
<fabbione> it's a duplicate check
<trulux> fabbione: you're missing the check in get_random_id()
<trulux> fabbione: slow down, and read twice :)
<infinity> seb128, \sh : In the words of daniels, "I live to give."
<fabbione> there is no call to get_random_int()
<fabbione> id
<fabbione> it calls _int()
<seb128> infinity: thanks :)
<trulux> fabbione: pid = 1 + (get_random_int() % pid_max);
<\sh> infinity: *hugs* 
<trulux> fabbione: are you sure you don't miss something?
<trulux> fabbione: I've tested it, and nayone using grsecurity has tested it
<daniels> AUTOCONSDF SDFl;km,asdrw3e446
<fabbione> trulux: what if in 2 different calls get_random_int will return the same value?
<fabbione> and pid from first call is still running?
<trulux> fabbione: check the source of get_random_int
<jmore9> OIN #ubuntu-devel
<pitti> fabbione: how is that check performed without the patch? merely incrementing it by 1 doesn't gurarantee that the pid is still free either
<fabbione> trulux: it's one line...
<fabbione>         return secure_ip_id(current->pid + jiffies);
<pitti> fabbione: or is "last" always guaranteed to be the highest pid ever?
<fabbione> pitti: reading pid.c there is no obvious check to me
<trulux> fabbione: "it's one line", that's a smart statement about it. it returns a value returned by another function mixing jiffies with the current pid
<trulux> fabbione: check RESERVED_PIDS source
<trulux> fabbione: also check the TCP ISN and ID randomization used for it
<trulux> also, last but not least, thinkign about the resfreshing time of get_random_int()
<fabbione> trulux: given your patch is based on .11 and i am looking at .12, i sort of need to make sure we are reading the same code
<trulux> another wrong thing
<pitti> trulux: what does the refreshing time have to do with that?
<trulux> I'm using a staked patches directory
<trulux> the directory name means nothing
<pitti> trulux: the point is, at some time somebody has to check that the pid is not already allocated
<fabbione> trulux: and how am i supposed to know that?
<trulux> get_radom_int(9 is part of Arjan van de Ven's ASLR infrastructure
<trulux> merged since 2.6.11-mm1
<fabbione> trulux: i don't have access to your hd
<fabbione> nor to your mind
<fabbione> start naming the patches correctly like everybody else does
<trulux> fabbione: man, you maintain kenrel packages. you should know what akpm's says about patches.... what about his patches named a/... b/...?
<fabbione> and i won't have the issue of digging into details
<daniels> autoconf has a really strange metric for 'unchanged'.
<daniels> i.e., 'exists'.
<trulux> fabbione: sincerously, it's a dead end
<fabbione> trulux: that's why people write [PATCH 2.6.12]  foo bar
<fabbione> and seriously.. i am questioning to understand
<trulux> fabbione: sure, read akpm's guide to patches submitting
<pitti> trulux: anyway, how can you guarantee that the returned pid is not already allocated?
<fabbione> given that you didn't answer any of my questions with more than RTC..
<fabbione> i am not sure i want the patch..
<trulux> pitti: check the pid allocation function
<pitti> trulux: does it check the pid after the point you patched?
<pitti> and gets a new one if it is already taken?
<pitti> trulux: I won't read the kernel code just to get that answer
<trulux> pitti: the kernel itself performs the snaity checking, read the comments in the kernel/pid.c header
<trulux> and the pidmap data structure
<trulux> also how free'ing works upon it
<trulux> pitti: an old approach which explains it basiccaly, just to not repeat myself: http://marc.theaimsgroup.com/?l=linux-kernel&m=94759469431344
<trulux> fabbione: for you, you can find a pretty good explanation on how it works: http://lwn.net/Articles/10238/
<trulux> fabbione: I'm sure you'll find that article useful for your needs
<trulux> fabbione: BTW, if you think you can dmeonstrate that you can generate a collision in get_random_int() on-demand by trying to allocate all the possible process ids on the system (whhich is nothing but a result of what you were talking aout), you have found also a flaw in the TCP ISN and packets ID random generation. In such case, report to vendor-sec or ecurity@kernel.org.
<trulux> ,-)
<pitti> trulux: that wasn't the point
<daniels> fabbione: 
<daniels> xauth> add 127.0.0.1:1 MIT-MAGIC-COOKIE-1 f503d037e92cbc07a27c9da4a30c384f
<daniels> xauth> list 127.0.0.1:1
<daniels> localhost.localdomain:1  MIT-MAGIC-COOKIE-1  f503d037e92cbc07a27c9da4a30c384f
<fabbione> daniels: add unix:10.1
<fabbione> it's the unix extension missing
<daniels> fabbione: unix works also
<daniels> fabbione: TCPCONN was also #ifdef'ed
<fabbione> daniels: ok
<daniels> xauth> list unix:0
<daniels> brainfreeze/unix:0  MIT-MAGIC-COOKIE-1  [...] 
<fabbione> daniels: try to add/remove
<daniels> fabbione: works fine
<fabbione> daniels: perfect
<daniels> fabbione: all the code will be #ifdef'ed by the same stuff
<daniels> if listing works, adding/removing will work
<seb128> daniels: is #10601  fixed for you?
<daniels> seb128: guess so
<daniels> seb128: much as I hate to admit it
<seb128> cool, thanks :)
<Mez> thnks \sh
<Mez> hmm
<Mez> we dont do native debian stuff do we?
<bob2> you shouldn't be making debian-native packages, no
<bob2> not unless you have a very good reason
<ajmitch> hey jbailey 
<Mez> bob2, my reason for asking is I just found a debian native package in MOM
<bob2> which is
<Mez> http://people.ubuntu.com/~scott/ongoing-merge/debtags-edit/
<ajmitch> Mez: that one is specifically debian-related
<Mez> so, what should be done with it ?
<jbailey> Heya Andrew (and everyone)
<daniels> Mez: ... merge it?
<Mez> daniels, it's already merged is it not?
<Mez> (unless you're on about shoving it up - and then well, I'll check first (and I dont ahve upload accesS)
<Kamion> if you don't have upload access, there's probably not a lot of point looking at MOM
<\sh> Kamion: we will sponsor
<Kamion> IME it's more work to review somebody else's MOM output review than it is to just review the output and upload it myself
<\sh> Kamion: we're too less people for all...actually it means: I need helping hands...and I double check right now
<\sh> cigarette time
<Kamion> well, I think it's either going to take you longer or you're going to make mistakes
<Kamion> but up to you
<Mez> libdebtags needs merging from debian, but MOM hasnt picked it up
<ogra> Kamion, most of the mergers are one line changes in the deps.... its easy to review and a goo task for beginners to get familiar with the package structure
<ogra> good even
<Kamion> ogra: I'm just telling you my experience, that's all
<Kamion> libdebtags |      0.9.9 |      unstable | source
<Kamion> libdebtags | 0.9.9ubuntu4 | breezy/universe | source
<ogra> yep.. i agree for the "real" merge stuff
<Kamion> Mez: no, it doesn't need merging
<Mez> Kamion: debtags-edit depends on libdebtags1-dev
<Kamion> libdebtags1 |      1.0.6 |      unstable | source
<Mez> from libdebtags1
<Kamion> different source
<Kamion> MOM doesn't merge across source package name changes
<Mez> lol - so I got confused, but still ... it needs the new version ;)
<Kamion> Mez: ask elmo to sync it in
<Mez> Kamion: ack
<lamont> bob2: it was a _DOCUMENTED_ rcs option
<bob2> pity it wasn't a CVS repository
<lamont> bob2: s/n't//
<bob2> er, yeah
<Mez> pitti: ping
<mpt> yo carstenh
<carstenh> hi mpt 
<mpt> carstenh: I saw the work you were doing on the firewall GUI - it looks pretty cool
<mpt> Do you have screenshots of the other three tabs?
<mpt> (or the glade file public anywhere)
<pitti> Hi Mez 
<carstenh> mpt: thanks, i'm mainly working on the backend at the moment, so there is not  really much on the other tabs
<carstenh> mpt: but i can provice a screenshot of the services-part
<ogra> mpt, if you're bored you could have a look at gnome-screensaver ;)
<carstenh> mpt: even if there is not much
<mpt> ogra: Why, are you considering shipping it? :-)
<Mez> pitti, currently the backports verison of FF 0.6 overrides the security updatre
<mpt> ogra: The good news is "screensaver prefs" is on my to-do list for today. The bad news is "screensaver prefs" has been on my to-do list every day for the past couple of weeks
<pitti> Mez: the backports maintainer already wrote me, he'll sort tht out
<Mez> pitti: John wrote you ? fair enough (and theres more than one backports maintainer - hence why I'm talking to you)
<Mez> he shoulda cc'd ubp-devel
<ogra> mpt, seb128 has packaged it and we consider shipping it... (sadly, since my patch was nearly ready)
<pitti> Mez: yes, John
<pitti> Mez: it was an unfortunate decision to name the backports package firefox, not mozilla-firefox
<mpt> ogra: ouch
<ogra> thats life
<Mez> pitti: we did that because of the transition in breezy ;)
<Mez> pitti: I'm assuming I couold just rebuild and make pseudo packages to point back ?
<mpt> ogra: Would gnome-screensaver be shipped unmodified, or does it need work?
<pitti> Mez: well, in hoary it is mozilla-firefox and should stay like that
<pitti> Mez: sure, if you upgrade the backport 
<carstenh> mpt: www.fh-trier.de/~heyc/fwgui-srv.jpg, i just copied this part from services-admin
<pitti> Mez: then this should be fine
<ogra> mpt, look at the ui... i dont like the timer ;)
<mpt> heh
<mpt> carstenh: thanks
<ogra> mpt, but it offers user selection with a userlist for example... that looks pretty sweet...
<Mez> pitti: I can make firefox be a backport that depends on the security.u.c version of firefox
<Mez> just have a "pseudo" package
<carstenh> mpt: after finishing the backend i will have more time to work on the gui
<mpt> ok
<Mez> as we did for the name transitions
<pitti> Mez: that would be even better and avoid redundancy
<azeem> wouldn't it make more sense to add a checkbox "Let through firewall" or similar to the services-admin dialog?
<Mez> pitti: now if only I could work out how to make a package with nothing in it
<pitti> Mez: that's easy, just look at any transition package in breezy
<Mez> pitti: any examples
<Kamion> it's really not hard
<Kamion> you just don't install anything in the package
<Kamion> it's kind of the opposite of rocket science
<pitti> there is even a package which creates such packages
<pitti> if I could only remember its name
<Mez> yeah i remember coming across that
<Lathiat> ooh ooh
<Lathiat> i rmemebr
<carstenh> eq..
<Lathiat> it was hard to find
<azeem> equivs
<pitti> right
<pitti> thanks
<Lathiat> !! thats the one
<Lathiat> that thing needs some better keywords to make it easily findable in an apt search
<Kamion> equivs isn't for packages to be uploaded to the archive
<Lathiat> right
<Kamion> it's for local packages
<pitti> Mez: ok, so you need an empty package "firefox" that depends on "mozilla-firefox"?
<Mez> yeah basically :D
<Kamion> all the binaries generated by ubuntu-meta are empty
<Mez> so i shouldnt use equivs?
<Kamion> it has a fair amount of extra stuff to do dependency autogeneration; just rip it all out
<Kamion> no, please don't
<Kamion> it's SO EASY
* Mez has never done it before
<Kamion> you really don't need weird helper stuff
<azeem> dh_make should have a equivs mode
<Kamion> you've written a debian/control file, right?
<Kamion> there is hardly any more
<Mez> yeah
<pitti> Mez: or just use dh_make and remove everything in debian but changelog, rules, control, compat, copyright
<Mez> so i dont need a rules file?
<pitti> Mez: you do, but the standard debhelper one should suffice
<azeem> Mez: if you use CDBS, debian/rules is a one-liner
<daniels> but cdbs is satan
<pitti> yay, internal compiler error
<Mez> o_O
<Mez> bash: dh_make: command not found
<azeem> daniels: you highlight on cdbs, right?
<ogra> lol
<azeem> Mez: there are tools to tell you which package contains which files
<pitti> daniels: cdbs is TEH LOVE! :-)
<Mez> I was going to use dh_make :D
<daniels> azeem: actually I just highlight on azeem and jump on whatever you say.  close enough. :)
<azeem> heh
<pitti> Dear doko, please fix gcc so that I can build mozilla 1.7.10; love, pitti
<doko> ?
<chmj> heh 
<doko> Dear pitti, please fix mozilla, that it can be built with a recent compiler ;)
<azeem> you forgot the bit about "love"
<pitti> doko: debian/patches/gcc4-build-fixes
<pitti> doko: it's not that
<pitti> doko: it was the "internal compiler error" I worried about
<pitti> doko: well, cool, it seems to build with LANG=C. Great...
* daniels giggles.
<daniels>  /m doko our plan to get rid of languages other than english is totally working.  first the keyboards, then xlib locales, now this.  genius.
<pitti> I hate you all.
* pitti takes a 3 year vacation to teach his grandmum English
<ogra> pitti, why english ? teach her C if you set LANG=C :)
<mpt> C !== English
<pitti> mpt: close enough
* mpt started translating GDM into English for fun
<pitti> daniels: add the rosetta delays of langpack tarball export to the list :-)
<carstenh> discussion about debian-policy should take place in which channel?
<daniels> pitti: to quote a certain person: 'i have a six-month policy of ignoring launchpad, renewable every six months'
<daniels> carstenh: #debian-devel?
<mpt> daniels: Great, we can use that certain person for usability tests
<carstenh> daniels: and discussion about makeing ubuntu-packages that does not conflict with the debian-policy?
<daniels> mpt: you'll have to drag him kicking and screaming
<daniels> carstenh: whereever seems most appropriate for you that's not #ubuntu-devel
<carstenh> daniels: ok, thanks
<daniels> er
<daniels> that's not #debian-devel
<daniels> cock
<mpt> Hmm, usability tests of tranquilized persons might not be representative
<mpt> (-llized?)
<mpt> ((-llised?))
<Kamion> any of the above
<Kamion> standard en_GB would be -llised
<Kamion> but -llized is also acceptable in en_GB, I believe
<fabbione> Kamion: is there any chance that foo-modules-2.6.12-4-foo is installed in parallel with -bar ?
<fabbione> Kamion: if so, if they share a file, are they going to conflict?
<fabbione> or udpkg just override same files in multiple pkgs?
<Mithrandir> fabbione: udpkg doesn't so silly stuff like conflicts and such, iirc
<Kamion> it can happen, but as Mithrandir says udpkg doesn't actually keep a record of files installed by a package
<fabbione> ok, does the first case ever happen instead?
<Kamion> actually it shouldn't happen anyway if they have correct Subarchitecture fields
<Kamion> fabbione: can you give me concrete examples?
<seb128> daniels: should gnome-session depends on xrdb now, or is that pulled by some other package from xorg?
<fabbione> Kamion: sure.. i need to ship an sh script in nic-modules-2.6.12-4-powerpc and nic-modules-2.6.12-4-powerpc64
<fabbione> it will land in /bin
<Kamion> fabbione: oh that's fine, those have XB-Subarchitecture: fields in their control files, so anna will only install the one that matches
<fabbione> Kamion: perfect! thanks
* doko considers his us keyboard as a dual-use product
<ogra> doko, for splatting mosquitos ?
<doko> use it peaceful if xorg is broken, or hit daniels if xorg is broken :-)
<ogra> heh
* Treenaks fills doko's kb with concrete
<ogra> wow, daniels gets a lot of love in here today :)
<Aegir> I dont see how people can like SuSE... Its poo *checks to see how much of the colony 2 CD is written to disc*
<daniels> seb128: make it dep on xrdb
<daniels> seb128: it'll be pulled in by xbase-clients later on
<daniels> and ubuntu-desktop when I get Kamion sufficiently drunk to mutilate the seeds with lots of tiny packages
<jdthood> Ah, so THAT's where xrdb is hiding now.
<daniels> jdthood: inconspicuous name, is it not
<jdthood> hidden in plain sight
<daniels> i like to keep it hidden
* Aegir ejects the burnt disc and goes to bed
<jdthood> Can one of the GNOME connaisseurs present tell me why GNOME demands that the system hostname be resolvable?
<seb128> daniels: k, thanks
<daniels> seb128: i love it that you thank me when I break stuff
<daniels> seb128: you should be more of my users
<\sh> hell
<\sh> we have a problem
<ogra> \sh, we call it "challenge" in here :)
<\sh> ogra: in here, but not where I came from
<\sh> right now
<carstenh> jdub: ping
<seb128> daniels: yeah, I'm too nice, I should work on that :p
<carstenh> jdub: did you get my hilight yesterday?
<seb128> he's away this week
<carstenh> seb128: he was here 2 hours ago, but maybe too busy to answer my question
<seb128> oh, k
<Mez> :d
<ogra> carstenh, are you sure you mean jdub ?
<carstenh> ogra: yes
<carstenh> ogra: 16:59:59 < sivang> carstenh: I think jdub can help you
<ogra> hmm i havent seen him since days in here
<Kamion> sivang was wrong anyway
<ogra> yep
<carstenh> ogra: but he was active on freenode today, but as i already said, he was probably busy
* Mez just read 2 lines at once and saw the nickname "onion"
<Kamion> at the moment the buck stops with mdz, but it's much better to get consensus among the people doing the work rather than having to resort to getting somebody to make a final decision
<Amaranth> jdub idle 03:05:17
<Kamion> and if GNOME adopts something as standard then it's more likely that we will; that decision *is* more with jdub
<fabbione> elmo: please sync nvidia-kernel-common (contrib)
<elmo> hum, does that not clash with our lrm stuff?
<fabbione> no..
<fabbione> it's needed
<fabbione> it's a common package with an init script
<fabbione> nothing fancy
<fabbione> elmo: i will soon need a bunch of B-D around :/
<elmo> nvidia-kernel-common | 1.0.7174+1 | breezy/restricted | source, all
<elmo> that's newer than unstable
<fabbione> nvidia-kernel-common_1.0.7667+1_all.deb ?
<Kamion> that's experimental
<fabbione> i just installed it.. probably experimental?
<fabbione> yeah that's fine..
<elmo> pull it from experimental?
<fabbione> yup
<fabbione> good to go
<carstenh> Kamion: so i should ask mdz about which service-config-tool will be standard in breezy?
<elmo> fabbione: done
<Kamion> carstenh: you should try to get consensus first
<carstenh> Kamion: between whom?
<fabbione> elmo: thanks
<Kamion> carstenh: 14:47 < Kamion> at the moment the buck stops with mdz, but it's much better to get consensus among the people doing the work rather than having to resort to getting somebody to make a final decision
<ogra> elmo, ping :)
<Kamion> carstenh: I thought that was quite clear
<carstenh> Kamion: work is already done
<elmo> ogra: ?
<carstenh> Kamion: only my part not
<Kamion> yet there is no consensus or you wouldn't be asking the question
<seb128> carstenh: what is service-config-tool?
<ogra> elmo, here will be a mediawiki upload in debian the next days, i'll need t synced to ubunu as soon as possible... could you dircetly move it through ? its approved by mdz
<mdz> seb128: e.g. services-admin
<carstenh> seb128: system v linke servioce en/disabeling tool
<pitti> Morning mdz
<mdz> pitti: morning
<pitti> ogra: are debian uploads possible again?
<seb128> what is the difference with services-admin? why picking this one rather the other one?
<seb128> hey mdz :)
<ogra> pitti, dunno, didnt they work ?
<pitti> ogra: ftp-master is down for some days
<carstenh> seb128: they all use a different database
<pitti> (it's moving)
<Kamion> --- ftp-master.debian.org ping statistics ---
<Kamion> 3 packets transmitted, 0 received, 100% packet loss, time 1999ms
<seb128> is there a package somewhere to try?
<ogra> pitti, ouch
<carstenh> seb128: i could invent a new one
<elmo> ogra: please ping me when it's in debian
<mdz> carstenh: we're likely to stay with what we have unless there is a compelling reason to change
<pitti> Kamion: it works again? great
<ogra> elmo, ok...
<Kamion> pitti: read more carefully
<carstenh> seb128: but users may be very confused
<pitti> Kamion: oh, right, sorry
* elmo fears pitti's ping parsing skillz
<carstenh> mdz: ok, thanks
* pitti fetches brown paper bag
<seb128> carstenh: a new what? there seems there is 2 interfaces to do the same thing, that's already duplicated
<carstenh> seb128: such a tool is part of by bounty
* ogra draws a smiley on pittys paperbag
<carstenh> seb128: so i have to write one
<seb128> carstenh: hum
<seb128> who is your mentor for that?
* pitti nudges ogra to get the nick right
<ogra> heh
<ogra> it was intentional ;)
<seb128> what is the rationnal to duplicate work?
<mdz> carstenh: I'm not convinced by that part of the spec
<carstenh> seb128: and if i disable apache with bum and enable it with gst, gst will not know the start-sequenz-number
<seb128> rather than working with upstream on their solution
<ogra> carstenh, why should you do that ? if system-manager is in main you dont need bum
<mdz> we already have a tool for init configuration, and firewall config and init config are fundamentally distinct
<seb128> and bum is ... ?
<mdz> ogra: because it was written in the spec
<carstenh> mdz: i think we should talk about that when my mentor is here again
<seb128> who is the mentor?
<mdz> carstenh: jbailey?
<ogra> seb128, the tool thesaltydog wrote
<mdz> I don't think he was present at the spec bof
<carstenh> mdz: yes
<carstenh> ogra: that i way i asked which one will be default
<carstenh> bof means?
<seb128> ogra: and who does it do?
<ogra> carstenh, yes, and thats why i told you yeserday that bum is unlikely to be in main
<mpt> carstenh: "Birds of a Feather" meeting at the UDU conference
<carstenh> ogra: i did not get that
<carstenh> mpt: thanks
<ogra> seb128, thesaltydog, he bugged us a lot because he wants it in main
<seb128> carstenh: which one of what? for services that would be services-admin, no reason to duplicate that ...
<seb128> ogra: s/who/what/
<ogra> seb128, bum
<seb128> "what does it do"
<mdz> ogra: "what does bum do"
<Treenaks> mdz: well, what do bums generally do?
<ogra> mdz, the same as services-admin but to much options ...
<carstenh> seb128: ok, that was my question. so _if_ i will implement a service-config-tools it will use the database from gst
<seb128> there is no apt-cache show bum 
<ogra> seb128, its not in yet
<seb128> carstenh: why do you have to implement one rather than working on the existant one?
<mpt> Anything called "Services" is random junk to Aunt Tillie, so the more we can provide specialized GUIs for subsets of them, the better IMO
<ogra> seb128, he wants to bring it to debian, so we (MOTU) decided to wait
<mdz> carstenh: if you have not already started on it, please leave out that feature
* ogra looks up the site
<carstenh> seb128: because it is in my bounty, but i have to talk about that with my mentor
<mpt> A "Services" menu in a firewall tool would not be a meaningful subset
<carstenh> mdz: ok, thanks
<mdz> carstenh: it does say "potentially", and my feeling is that it should not be part of the final spec
<ogra> mdz, seb128: http://www.marzocca.net/Immagini/bum2_new.jpg
<ogra> mdz, seb128: http://www.marzocca.net/Immagini/bum1_new.jpg
<seb128> yeah, I've googled for it, thanks
<mdz> carstenh: I've updated it accordingly
<carstenh> mdz: it was also part of my proposal, but many this have changed since then
<carstenh> mdz: thanks :)
<seb128> looks a bit complicated as an UI
<ogra> seb128, thats why i dont like it
<ogra> seb128, in the last version you even could shutdown udev and hotplug....
<mdz> ogra: EVIL
<ogra> he disabled that as i heard
<ogra> yep
<mpt> I don't understand why I'd want to turn any of those things on or off
<mdz> you wouldn't, indeed shouldn't
<ogra> mpt, mostly because you can... 
<mpt> They should be on if they're needed by actual checkboxable features, and off if they're not
<ogra> mpt, little boys need to touch switches, you know ;)
<ogra> (and press buttons)
<Mez> elmo: the buildd's dont seem to have picked the backports up at all
<seb128> hey jbailey
<carstenh> jbailey: hi
<carstenh> jbailey: we talked about the service configuration tool
<elmo> Mez: cron.daily is still running
<jbailey> Heya seb
<jbailey> Heya Carsten
<jbailey> carstenh: Which we? =)
<Mez> elmo: ah, didn't think of that :P looked like they were done!
<doko> elmo: please sync libgdchart-gd1
<jbailey> carstenh: Thanks.
<elmo> doko: nothing to sync?
<doko> huh?
<doko> elmo: ahh, ok, not yet on the mirror
<carstenh> fabbione: ping
<carstenh> fabbione: i put new information for you in the query
<siretart> elmo: did you get my email about piuparts?
<doko> mdz, Kamion: what is our policy for new upstream versions, for which merge reports were filed before the UVF? in this case: curl
<mdz> doko: is it needed for any reason other than being newer?
<doko> I'm going through my list of merge reports. in this case, I cannot find another reason
<mdz> doko: if it isn't needed for some other reason, it should probably be deferred for breezy
<doko> mdz: otoh, it would be nice to have recent versions for the packages, that distrowatch lists on the page
<mdz> ouch, 209 merge bugs still open
<doko> exactly ...
<mdz> 116 of >= normal severity
<mdz> there were many universe bugs in there
<doko> yes, these are mostly C++ libs and GCC issues
<doko> mdz: will you go through this list, which ones should be merged for breezy?
<mdz> doko: am already doing so
<siretart> mdz: I'd like to see piuparts in ubuntu, it seems that it was introduced in debian after UVF. does this package need approval?
<mdz> doko: a large number of them seem to have been assigned to you; were there problems meeting the deadline?
<mdz> siretart: for universe?  that's fine
<siretart> ok
<siretart> elmo: could you please sync piuparts from unstable? thanks in advance!
<doko> yes, I delayed the python reports, assigned additional ones to me (GCC 4.0), or I missed the merge deadline.
<doko> mdz: the openoffice merges are for oo1, which we will probably update until 2.0 anyway, the python modules should be uncritical
<\sh> woo...89 merge bugs for universe ,-)
<doko> mdz: isdnutils is uplaoded, so there are missing: moin, lintian, hplip, ccache, libxalan2-java
<seb128> elmo: can we get gdl gnome-build from Debian?
<nomed^> hi 
<nomed^> i'm trying to set up an apt mirror .. but during apt-get update i have this error
<HiddenWolf> Someone in #ubuntu still has problems with the fixed FF version
<nomed^>  The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 524AB1D180B70AA5
<nomed^> do you know how i can solve this?
<siretart> nomed^: this is an #ubuntu question. please ask there (short answer: look at the manpage of apt-key(8))
<nomed^> ok thanks
* maswan nudges elmo and the other admins: rsync: failed to connect to syncproxy.ubuntu.com: No route to host (81)
<sivang> seb128: how's lp-integration uploads comeing ? ;-)
<seb128> sivang: I'm looking at file-roller atm, some notes on it: 1- patches start by numbers usually, that's just a convention but that gives some order
<seb128> 2- do separate patches for the code/configure.in and configure changes
<Mez> o_O
<seb128> the code/configure.in is not likely to change
<Mez> http://people.ubuntu.com/~lamont/buildLogs/Lists/
<seb128> 3- don't bother doing configure changes by hand, run autoconf
<Mez> hasnt updated for over an hour now... 
<Mez> is there something up
<sivang> seb128: I followed pitti's suggestion to keep everything related to achiving the same functionality in the same patch file
<seb128> pitti: ?
* pitti looks up
<sivang> seb128: ah, right, numbers since it's simple-patchsys.mk
<seb128> pitti: any objection to separate the code changes and the autoconf patch?
<sivang> pitti: they are used to achive a single bigger goal :)
<seb128> sivang: no, just because that's cleaner
<pitti> sivang, seb128: that depends
<sivang> pitti: toegther
<pitti> if you have several patches modifying autotools files, then an extra patch is easier
<seb128> pitti: I do 01_codechanges.patch which is not likely to change, and 02_autoconf.patch 
<pitti> but if you have only one tiny change, you can as well stuff it into the patch itself
<pitti> matter of common sense and taste, mainly
<sivang> pitti: it's ~1 line change
<seb128> yeah
<sivang> pitti: PKG_CHECK_MODULES(........ launchpad-integration)
<sivang> seb128: do you think it may change int he future? (the PKG_CHECK.. directive)
<pitti> sivang: I guess that should go into a separate patch then since it likely produces more than one changed line in the configure
<sivang> pitti: hrm, about the configure that's true
<seb128> that's what I was saying
<pitti> sivang: you can certainly trust seb128's advice :-)
<sivang> seb128: ok, sorry for arguing, I will make you a new one - by evening ok?
<seb128> 1 patch for the code/configure.in changes, one for autoconf
<seb128> sivang: np
<sivang> seb128: cool :)
<seb128> I'll upload file-roller now
<sivang> seb128: with the combined patch?
<seb128> fix it for next packag
<sivang> seb128: cool, thanks!
<seb128> np
<seb128> yeah, as you have uploaded it
<sivang> seb128: that's why I'm so excited :)
<sivang> seb128: did you update the helper lib already as well?
<seb128> yesterday yep
<sivang> seb128: k
<sivang> seb128: did mdz told you a dead line for finishing this?
<seb128> jamesh: thanks for launchpad-integration work!
<sivang> seb128: (I want to plan my time)
<mdz> sivang: launchpad-integration?  due by feature freeze
<sivang> mdz: k, thanks
<mdz> sivang: 2005-08-11
<seb128> jamesh: dunno if you have noticed, you gucharmap does these warnings:
<seb128> (gucharmap:7173): Gtk-CRITICAL **: gtk_accel_label_set_accel_closure: assertion `gtk_accel_group_from_accel_closure (accel_closure) != NULL' failed
<seb128> s/you gucharmap/your gucharmap patch/
<seb128> ogra: have you bugged upstream for your gnome-screensaver password issue?
<ogra> not yet
<Amaranth> i suppose i'd better start working on smeg 0.8 again, from scratch :/
<ogra> err. passwd issure ?
<seb128> the warning you had yesterday
<ogra> seb128, i told you its caused by my not up to date system yesterday... it worked after i complied it locally
<ogra> seb128, i.e. i'm looking at a lockscreen now and it unlocks fine
<ogra> seb128, btw, how do i save my screen without locking it ? is there an option ?
<seb128> gnome-screensaver-command -activate ?
<seb128> --activate
<ogra> locks :/
<eazel7> hi ppl
<ogra> ah, there is a gconf option for it
<ogra> hughsie_, ping 
<sivang> seb128: btw, just realized, did you add the build-dep for file-roller on lpint-dev ?
<sivang> seb128: and, don't patched apps need depend on lpint to be able to do the lp helper lib invocation ?
<seb128> sivang: no, I've not uploaded yet, did you screw you package?
<sivang> seb128: seems so, I've forgot to add the build-dep :-..(
<seb128> right, you did
<seb128> I've fix the packages
<seb128> don't worry, I'll mention you for the patches
<seb128> or do you want to fix it tonight?
<sivang> seb128: yes, I will , thanks 
<seb128> np
<hughsie_> ogra: pong
<bddebian> Howdy
<ogra> hughsie_, did you have a look at gnome-screensaver already ? 
<ogra> hughsie_, it has gconf keys for the screen powermanagement ;)
<bddebian> Uhm, somehow I think we missed the deadline for outstanding merges
<hughsie_> ogra: yes, I've been looking at how p-m can intergrate with g-s
<sivang> seb128: yet, don't we need to make all binary packaes depend on lpint (non dev) package to operate?
<ogra> hughsie_, would it be possible to get such a functionallity integrated before 11th of august ? 
<hughsie_> sure, you definatly shipping g-s?
<Nafallo> Simira: morning
<seb128> sivang: no
<ogra> hmm, i'm not sure about definately , but its very likely... seb128 is very convinced...
<hughsie_> ogra: okay, i'll make sure that the integration work is done this week.
<Mithrandir> why is there a 2.05 in http://archive.ubuntu.com/ubuntu/pool/universe/liba/libapreq2-perl/ but no .diff.gz or .dsc?
<ogra> hughsie_, so it would be preferable to have it in on your side rather then patching around ourselves in the source
<hughsie_> sure
* ogra hugs hughsie_ :)
<ogra> hughsie_, youre a star :)
<ogra> thanks so much
<hughsie_> lol, what version of dbus you guys shpping?
<sivang> seb128: ok, sorry for asking this, but how come? :) (after all, we call functions from the .so of the helper lib, and if it's not installed..crash will happen..etc)
<ogra> 0.34 is currently installed on my system.... but i'm outdated... wait a sec
<ogra> hughsie_, yes, 0.34
<hughsie_> 0.35 should be your answer
<Kamion> the problem with testing stuff that changes your keyboard layout is that attempting to maintain sanity while typing is tricky ...
<seb128> sivang: the apps will Depends on the lib, and the lib will Depends on l-i
<ogra> pitti, any chance this will happen before breezy ? ^^^ (dbus 0.35 ?)
<Kamion> whoa, I think it just changed my layout to Byelorusian or something
<ogra> hughsie_, i doubt we'll upgrade this
<Simira> Nafallo : hi there. Well back home?
<pitti> ogra: nope, AFAIK it changes the API again
<ogra> ah
<Nafallo> Simira: yepp. much easier to get home than to get there actually ;-)
<hughsie_> ogra: 0.35 has the dbus bindings. 0.35 is being BACKPORTED into FC4 as it's going to be the base for all the dbus programs.
<ogra> hmm
<Nafallo> Simira: even though we still speak norsk now and then ;-)
<hughsie_> ogra: no api change, just glib bindings
<Simira> Nafallo : hehe. How's Flekken?
<ogra> pitti, ^^ ?
<Mithrandir> Kamion: can you check why there is libapreq2 in breezy?
<Kamion> Mithrandir: was there supposed to be a "no" in that sentence?
<ogra> hughsie_, is 0.35 absolutely needed  ? or would 0.34 work too (probably with less functionality )
<Mithrandir> Kamion: yes. :-)
<Nafallo> Simira: he's fine. cleaning himselves atm :-). he will get a friend on monday or earlier :-).
<doko> mdz: the new rrdtool version supports amd64 better, do you know how compatible this version is compared to the current unstable/breezy version?
<hughsie_> ogra: 0.35 is supposed to be near 1.0
<Nafallo> Simira: dep-wait on money ;-)
<ogra> hughsie_, yes, but we're near feature freeze here in ubuntuland :)
<hughsie_> ogra: yes, because 0.34 does not have glib bindings that are useable. 0.35's bindings are complete
<seb128> pitti: upstream and GNOME people recommand to use 0.35 and daniels said on #gnome-hackers we will update afaik
<Kamion> Mithrandir: I'm confused. It *was* there.
<hughsie_> 0.35 seems to be defacto-standard
<Nafallo> Simira: we shall probably move this to #norsksvenskar :-)
<Mithrandir> Kamion: yes, it was.  And the pool has a 2.05 orig.tar.gz but no .dsc, no .diff.gz
<hughsie_> ogra: sorry for the spanner
<pitti> seb128, ogra, hughsie_: ok, fine for me if mdz approves and this doesn't break hal, gnome-vfs, gnome-volume-manager, update-notifier, etc.
<hughsie_> g-p-m can run with 0.34, but the cvs currently uses the glib bindings
<hughsie_> i'm running 0.35 now (FC4)
<Kamion> Mithrandir: I'm confused, sorry - best ask elmo
<ogra> hughsie_, i'm packaging the 0.1.0 version of gnome-power currently
<hughsie_> gotcha. That will work with 0.34
<Mithrandir> elmo: any idea what's up with libapreq2 and why it's not in the pool?  That is, anything more than .orig.tar.gz
<hughsie_> the cvs uses libnotify and lots of cool new stuff
<ogra> hughsie_, i'm not sure if i want to package CVS for our stable release
<Kamion> Mithrandir: libapreq2 or libapreq2-perl?
<ogra> hughsie_, and we have no libnotify yet
<Mithrandir> Kamion, elmo: libapreq2-perl, sorry.
<ogra> hughsie_, waiting for a upstream tarball according to seb128 who will package it
<ogra> hughsie_, so its depending on upstream if we'll have libnotify
<hughsie_> ogra: 0.1.0 doesn;t handle libnotify
<hughsie_> 1.1 (cvs) needs it as a dep
<hughsie_> *0.1.1
<ogra> yep, thats what i mean... so it would have to wait for it... but we (mjg59 and me) still have to do integration work.... and time's getting short
<hughsie_> ogra: cool. Let me look more at g-s and I'll give you a patch
<ogra> yay
<ogra> hughsie_, many many thanks :)
<sebest> hello does the standart ubuntu kernel can boot on nfs (nfsroot) ?
<jbailey> sebest: I don't think so.  It's a feature we're adding for Breezy, though.
<hughsie_> ogra: n/p
<sebest> jbailey: oki, diskless is a breezy goal?
<ogra> sebest, look at the ltsp packages in breezy... the ydo souch fun stuff :)
<ogra> sebest, edubuntu will release with breezy, the default install will be ltsp based
<sebest> ogra, but ltsp, in more than nfsroot, it terminal/server?
<jbailey> sebest: Well, nfsroot anyway.  From there, ltsp I think has some diskless options, but I'm not involved in that part, so I don't know the details.
<sebest> i mean process are running on the server not on the client (like nomachine nx)
<ogra> sebest, it will install a ltsp terminal server and educational apps...
<ogra> yep
<sebest> does ltsp use standart X protocol, or can it use also nx ?
<ogra> its ssh based
<ogra> at least as edubuntu will ship it
<sebest> ogra nx is also ssh based
<shaya> anyone know how one is supposed to rebuild linux-restricted-modules?
<Amaranth> seb128: do you know if gnome-session 2.11.90 has gnome-smproxy removed?
<ogra> sebest, as opposed to X display exports
<shaya> dpkg-buildpackage doesnt work
<shaya> trying to play w/ some patches for it
<Amaranth> ooh, xauth
<sebest> i'm wondering about the compression protocol, if it's vanilla X or use optimised nx library
<sebest> ogra, you mean "ssh -X" ?
<ogra> sebest, we dont use NX yet
<bddebian> shaya: What doesn't work?
<ogra> sebest, yes similar ...
<sebest> ogra, would it be possible to use nx in ltsp?
<ogra> s/smilar/along these line/
<shaya> bddebian: apt-get source linux-restricted-modules-2.6.10-5-686 ; cd linux-restricted-modules-2.6.10-2.6.10.6/ ; dpkg-buildpackage
<shaya> as the control file is empty
<ogra> sebest, if we had a NX we were happy with, we could use it..
<bddebian> shaya: The control is empty?
<ogra> sebest, Mithrandir is working on a sane NX implementation, but not for breezy (and to be honest i dont know if he dropped it)
<sebest> is it maturity that made u choose ltsp over freenx?
<shaya> dpkg-checkbuilddeps: error: syntax error in control file debian/control at line 1: empty file
<shaya> well not exactly empty "# THIS IS AN AUTO-GENERATED FILE.  DO NOT EDIT."
<shaya> and there's a control.stub
<shaya> but dont know how to generate the control file from it
<ogra> sebest, nope, the usecase.... we will comply very tight with the k12ltsp distro which uses ltsp
<Mithrandir> ogra: I haven't dropped it, but I've been entirely too busy lately.  Hopefull, it'll be one of the things we'll see for breezy or breezy+1
<sebest> ogra: oki, it make sense
<ogra> Mithrandir, feature freeze i in less then two weeks... say breezy+1
<ogra> :)
<shaya> hmm
<shaya> never mind, seems something got messed up
<Simira> Ubuntu t-shirts (shipping to Europe): http://wiki.ubuntu.com/t-shirt
<bddebian> shaya: OK
<sebest> Mithrandir, what is the scope of your work on Nx ?
* ogra takes a break....
<ogra> bbl
<Mithrandir> sebest: I'm part of the packaging team for nx in Debian and am working on something which is a replacement for nxserver and nxclient.
<sebest> Mithrandir: is it related to freenx?
<Mithrandir> sebest: freenx is trying to be compatible with the proprietary nxclient and nxserver.  I don't.
<sebest> Mithrandir, what's the plus of not being compatible?
<Amaranth> Mithrandir: What do you gain/lose because of that?
<Mithrandir> sebest: I don't like or trust the design based around abusing ssh with shared private keys for setup.  I would also like to be able to use smart cards or other devices supported by pam to authenticate.
<seb128> Amaranth: yep it has (read the changelog?)
<seb128> Amaranth: why?
<Amaranth> you can get changelogs now?
<Amaranth> seb128: just wanted to see if i could things that break
<seb128> what do you say about the changelog?
<sebest> Mithrandir, oki you'd like to fit it in ltsp?
<seb128>  gnome-session (2.11.90-0ubuntu1) breezy; urgency=low
<seb128>  .
<seb128>    * New upstream version:
<seb128> ...
<seb128>      Misc:
<seb128>      - Remove gnome-smproxy.
<seb128> changelog ...
<Mithrandir> sebest: personally, I don't care too much about ltsp, but I imagine it might be used by the ltsp project, yes.
<Amaranth> seb128: how can i get that without downloading the source package?
<seb128> read -changes
<seb128> or gnome-ftp list
<sebest> is it possible to mount initrd?
<sebest> i tried
<sebest> mount -o loop /boot/initrd /mnt
<sebest> But i don't know the filesystem type and -t romfs doesn t work
<infinity> cramfs
<jbailey> cramfs
<sebest> thanx!
<mdz> doko: go ahead and close the oo1 bugs; we're not going to bother with that
<mdz> doko: if there's no pressing need to update the python modules, close those as well
<mdz> doko: if there is anything on the list which justifies an exception, please tell me
<marcin> hi all
<marcin> I got a question about packaging tools
<Mez> marcin, then ask :D
<marcin> I would like to know if are there any tools for maintainers to detect new versions
<infinity> uscan
<Mez> elmo: ping
<marcin> infinity: thanks
<marcin> infinity: apt-getting devscripts package
<Mez> mdz: we have our first successful backport :D
<mdz> Mez: congratulations!  which package?
<Mez> wesnoth
<Mez> http://people.ubuntu.com/~lamont/buildLogs/w/wesnoth/0.9.3-1~hoary1/
<bddebian> Heh
<ogra> Mez, great :)
<mdz> Mez: looks pretty good, all the binaries seem to be in the archive
<Mez> yeah, they are :D
<Mez> they're all there with their unsigned .dsc:P
<Mez> weirdness
<mdz> interesting
<Mez> It's showing up as being in universe AND multiverse
<mdz> now that I don't see; I only see it in universe
<marcin> infinity: this uscan tool works only for released sources 
<ogra> Mez, why is jdong still promotig firefox on the mailing list ?
<Mez> mez@apathy:/backports/arena/k3b-i38n/k3b-i18n-0.12.2$ apt-cache madison wesnoth
<Mez>    wesnoth | 0.9.3-1~hoary1 | http://archive.ubuntu.com hoary-backports/universe Packages
<Mez>    wesnoth | 0.9.3-1~hoary1 | http://archive.ubuntu.com hoary-backports/multiverse Packages
<Mez>    wesnoth | 0.9.3-1~5.04ubp1 | http://ubuntu-backports.mirrormax.net hoary-backports/universe Packages
<Mez>    wesnoth |   0.8.11-1 | http://archive.ubuntu.com hoary/universe Packages
<Mez> ogra - he is?
<marcin> infinity: is there something simmilar which could work with cvs?
<ogra> Mez, he wrote some posts today, yes
<mdz> mizar:[/space/video/tv]  apt-cache madison wesnoth | grep hoary
<mdz>    wesnoth |   0.8.11-1 | http://us.archive.ubuntu.com hoary/universe Sources
<mdz>    wesnoth | 0.9.3-1~hoary1 | http://us.archive.ubuntu.com hoary-backports/universe Sources
<mdz> deb-src http://us.archive.ubuntu.com/ubuntu/ hoary-backports main restricted universe multiverse
<ogra> hmm, this path of mdz looks like we'll have a new mythtv soon :)
<Mez> weird mdz
<Mez> and ogra - where ?
<ogra> Mez, ubuntu-users
<ogra> there was a ff thread
<Mez> yeah
<Mez> looking now
<Mez> that's weird
<Mez> but, I spoke with pitti earlier
<ogra> looks like he's still goig his own way...
<Mez> and we decided that the best way would be to make a transitional package back
<Mez> firefox: Depends: mozilla-firefox
<ogra> Mez, yes, i saw this
<Mez> a pseudo package
<Mez> oh, fair enoguh
<Mez> well, John doesnt know about all this, I tried to talk to him on AIM with no repsonse
<ogra> ah, ok
<whiprush> I've been trying to get ahold of him as well
<Mez> though to be fair, for some reason I cant make a dummy transitonal package
<Mez> they dont like to build for me
<Mez> whiprush, what about
<whiprush> I need to sign his key.
<Mez> o_O
<Mez> in person
<ogra> whiprush, oh, you met hi ?
<whiprush> yeah
<Mez> ?
<ogra> him
<whiprush> he lives like 5 minutes from where I live.
<whiprush> er, work.
<doko> mdz: some of our printing packages are outdated. i.e. hplip (recent printers), gs-gpl (8.0 -> 8.16). which ghostscript version should be recommended? currently we do have gs-esp and gs-gpl in main
<whiprush> Keep inviting him to LoCo activities buy never get a response. :-/
<mdz> doko: we agreed on gs-esp
<mdz> that's our current default
<Mez> he always said he didnt have anyone near him
<infinity> Has gs-esp been updated and brought in sync with gs-gpl recently?
<mdz> I had planned to do some work on hplip because we need to de-root it to put it in desktop
<ogra> Mez, intresting...
<whiprush> Mez: we got over 20 people in our loco.
<infinity> gs-gpl had some updated drivers that gs-esp was lagging on.
<mdz> but my hplip-compatible printer is...somewhere else for the moment
<Mez> whiprush: weird, he didnt know about it - he said signing his key was a massive issue for him
<doko> mdz: I'd like to update hplip to 0.9.4 for newer hardware support, released on July 20
<whiprush> Mez: odd.
<mdz> doko: do you have test hardware?
<doko> gs-esp is at version 7.07
<Mez> or maybe none of you are in strong set
<whiprush> we're all in the strong set.
<doko> mdz: an office jet
<ogra> Mez, whiprush is signed by a lot of us
<Mez> fair enough
<Mez> ogra, you remember john saying about getting his key signed being a PITA right?
<ogra> Mez, yes
<whiprush> Mez: have him contact me if you talk to him, jorge@ubuntudetroit.org
<mdz> doko: ok, could you give a try at de-rooting it at the same time?
<whiprush> maybe I've been sending emails to the wrong john dong. :p
<bddebian> heh
<mdz> it should only need lp and scanner privileges or so
<Mez> whiprush, john.dong@gmail.com
<pitti> doko: look at hpoj, there you'll find the hotplug map and stuff (for derooting)
<ogra> whiprush, if your spam factor raises in the near future you know it was the wrong one ;)
<whiprush> heh
<doko> mdz: ok, I'll consult pitti :)
<Mez> did jabber.org just go down
<Mez> elmo: ping
<ogra> Mez, yep
<mdz> Mez: that would not be at all surprising
<Mez> first time it's done it on me for a year or so
<mdz> Mez: you already pinged elmo 20 minutes ago
<Mez> did i?
<Mez> :O
<bddebian> wb \sh :-)
<Mez> elmo: unping one of those
<Mez> :P
<bddebian> Hey, now that I think about it, I never heard back from mako about my CoC
<Mez> (sorry - my minds a bit of a mess at the mo - I just got accosted half way through doing somehting and i dont know what I'm doing now)
<ogra> bddebian, mako is travelling a lot reently... he may laga bit behind with email
<ogra> recently even
<doko> mdz, elmo: I did upload moin 1.3 as source moin1.3
<\sh> re
<bddebian> ogra: Bah, you all just don't love me :-)
<Mez> grr
<Mez> since I've moved to this house I just get godamn errors on everythnig
<bddebian> Where do I upload my key on launchpad??
<\sh> yay...I just read on heise.de: "Countdown for Shuttleworth-Start" .. but there is written "Countdown for Shuttle-Start"
<bddebian> \sh: :-)
<Mez> bddebian, you goto your page on launchpad, and click on GPG keys at the side
<\sh> bddebian: u see...never start with this packaging stuff..it makes u stupid ,-)
<bddebian> \sh: Amen to that :-)
<bddebian> I don't have a page on Launchpad
<Mez> \sh: yeah, it's like doing higher maths makes you forget how to add up
<Mez> bddebian, then register
<bddebian> Ohh, never mind.. Man I am getting more st00pid :-)
<hub_> Amaranth: your CD is being burnt right now
<Amaranth> hub_: err, ack
* Amaranth is sort of already running the latest breezy again
<hub_> I had none here, so I have to get some from my personal stach ;-)
<hub_> Amaranth: ah ? 
<\sh> Mez: hehe :) 
<Amaranth> hub_: yeah, i found a hoary install CD in my stack of discs
<Amaranth> hub_: sorry, should have told you sooner
<hub_> yeah
<hub_> I'll find a use for it anyway
<Mez> lol
* Mez imagines hub_ trying to sell a "coaster" to his LUG
<bddebian> OK, damnit launchpad sends me an e-mail back saying Validate Your Fingerprint but doesn't tell me what to do with it?
<bddebian> Ohh, darn it.  NM again
<seb128> infinity: could you kick sound-juicer gnome-desktop zenity gnome-panel to build with gnome-doc-utils 0.3.1-0ubuntu3? thanks
<Mez> click... the... link
* seb128 bbl
<ogra> <-- dinner
<Mez> bddebian, I think you should go drink some coffee, you seem half asleep :D
<infinity> seb128 : That sounds very familiar, except for the version number..:)
<Kamion> bddebian: #launchpad might be a better place to ask for Launchpad help
<Mez> ogra, whose dinner are you
<ogra> my GFs ;)
<bddebian> heh
<bddebian> Mez: No kidding
<Mez> ogra: I knew I should never have asked :D
<seb128> infinity: yeah, another Depends missing, but I didn't get the issue with my pbuilder this morning, weird ...
<ogra> Mez :)
<Mez> :P
<bddebian> Kamion: Should I ask a question about a problem signing the CoC in #launchpad too?
<Kamion> bddebian: if it's a technical problem with operating Launchpad, yes
<bddebian> Kamion: What if it's an ID10T error? :-)
<doko> mdz: there is a reason for a curl update: get rid of the libcurl2 and libcurl2-dev packages built from the current 7.12.3 sources
<Kamion> bddebian: well, most people here won't know offhand how to help you, either way :)
<mdz> \sh: I imagine others have said this already, but remember to use -v<version> when resynchronizing with Debian (the MOM output includes a pre-generated command line to make this easy)
<mdz> doko: don't some things still use libcurl2-dev?
<doko> Reverse Depends:
<doko>   libdiscover2
<doko>   libcurl2-dev
<doko>   grip
<doko>   fbi
<doko>   discover
<doko>  all are built against libcurl3 in unstable
<doko> mdz: ^^^
<mdz> doko: ok, let's do the update then
<doko> fine, I'm updating the rdepends as well
<fabbione> doko: my brain is melting...
<fabbione> can you help me 2 secs?
<mdz> seb128: I can't get the launchpad integration in gucharmap to work
<doko> fabbione: yes
<mdz> seb128: the menu items are there, but they do not do anything
<mdz> seb128: ah, apparently I need launchpad-integration installed.  shouldn't liblaunchpad-integration0 depend on it?
<sivang> mdz: that was my question exactly
<sivang> seb128: could you please xplain again why apps do not need to depend on launchpad-integration ?
<sivang> seb128: (I must be brain dead or something, but I couldn't understand your previous explenation)
<\sh> mdz: sorry..wasn't with you...
<mdz> sivang: apps shouldn't need to depend on it, but it seems like the library should, since it doesn't work without it
<sivang> mdz: ok, but then which package would pull the lib in ? ubuntu-desktop? some package must depend on it in order for it to be installed, no?
<mdz> sivang: the applications depend on the lib
<sivang> mdz: ah ok, that what I was trying to make sure :)
<mdz> sivang: the library being liblaunchpad-integration0.  I am talking about launchpad-integration which contains the external program used to do the lookup
<sivang> mdz: ah, you mean the python-fu which looks it up by pid, or filename or desktop file.
<mdz> sivang: yes
<mdz> sivang: without which it fails silently
<sivang> mdz: right, becasue the eventual firefox dispatching occurs by that helper python scripts using gnome-open
<sivang> seb128: sorry for the previous comment, I now know what you were talking about.
<seb128> mdz: yeah, that's planned for next upload as said here this afternoon
<sivang> seb128: just sometime I have hard time udnerstanding you :)
<seb128> mdz: I was not sure if the lib should depend on it or some desktop package, the lib is probably the best place
<seb128> sivang: what did I say?
<sivang> seb128: you explained it to me breifly enough, that I got confused all over :) mdz straightened that now :)
<sivang> seb128: but you were correct, as alwasy
<mdz> seb128: ok, I was probably asleep at the time
<sivang> seb128: 17:29 < seb128> sivang: the apps will Depends on the lib, and the lib will Depends on l-i
<sivang> seb128: so I missed the fact you the source pakcage produces two pkgs, one for the python scripts, and the other for the lib .so
<seb128> that's it
<sivang> s/missed/overlooked/
<mdz> sivang: this is necessary, in order to allow for the library to change its soname later
<sivang> mdz: for instance, to reflect version changes?
* Kamion runs into a fun showstopper bug in debconf
<Kamion> sivang: yes, life is much easier (for upgrades, etc.) if liblaunchpad-integration1 and liblaunchpad-integration2 are installable at the same time
<Kamion> sivang: so you don't want them to contain the same files
<sivang> Kamion: sure, to be able to accomodate two apps using different version installed at the same time on one system ?
<Kamion> indeed
<Kamion> and because otherwise upgrades from libl-i1 to libl-i2 are very painful because you can't do them gradually
<sivang> Kamion: cool, thanks for the knowledge
<mdz> sivang: yes
<doko> infinity: please teach the buildd's to choose libcurl3-dev, when seeing libcurl-dev or libcurl-ssl-dev
<infinity> doko : If you drop libcurl2-dev, they will automatically anyway, but I can hardcode it.
<doko> ok, then I wait, until they are in the archives
<jan1> elmo, keybuk around?
<Keybuk> jan1: I'm around, round, round, round, I get around
<jan1> keybuk, cool, can you automatically override some MOM merges, and drop ubuntu changes to a list of packages?
<jan1> the xfce4 merge has a lot of fallouts mostly because
<jan1> the hoary merged happened from a non-debian upstream
<jan1> it would be easier for the xfce-motu theam to just start from a base that is known to work on sid
<jan1> I'll just do the merge by hand if it can't be don automatically, but I thaught I'd ask
<jan1> there are two repos currently offering xfce4.2.2, hoary synced from os-works , than MOM from sid and there are silly conflicts in the debian/ dir
* jan1 wonders if he should have answered keybuk using lyrics too
<ogra> jan1, nope, bt Keybuk is the wrong person to poke for that... even i'm sure he's happy you talk to him :)
<jan1> isn't he scott of the MOM?
<mdz> jan1: yes, he is
<ogra> jan1, yes, but he doesnt do the syncs you want ;)
<jan1> so is elmo the sync-master
<jan1> ?
<ogra> yep
<mdz> jan1: yes again
<ogra> jan1, just let elmo do the syncs where you want them from and close the MOM bugs... you can ignore them in this special case
<jan1> I don't seem to find elmo on IRC :)
<siretart> he is quite busy
<Mez> sudo: cannot get working directory
<Mez> weird
<zyga> hello
<zyga> does anyone know of a simple way to create deb's from python's distutils
<zyga> ?
<\sh> hmmm...
<siretart> zyga: cdbs, I used that in the package londonlaw
<zyga> siretart: thanks, I'll google it :)
<siretart> zyga: no need to google, apt-get source londonlaw is sufficient
<\sh> zyga: w8 before u use cdbs
<\sh> please have a look on python-gtkextras
<zyga> hmm
<\sh> this is plain debhelber and python-distutils
<zyga> I'll do both
<\sh> python ./setup.py install --root=$(CURDIR)/debian/python-gtkextra
<\sh> u mean this, right?
<zyga> I want to use distutils because that's how it'll work on windows but I want to support debian too
<\sh> u mean this setup.py bla thing?
<zyga> siretart: apt-source doesn't know that package, are you sure you've spelled it right and it's in the default repos?
<siretart> zyga: http://packages.ubuntu.com/breezy/games/londonlaw
<zyga> siretart: http://packages.ubuntu.com/hoary/games/londonlaw 404 ;]  - Okay I'll fetch it from breezy ;] 
<zyga> pitti: hello!
<ogra> hey sabdfl :)
<sabdfl> hey guys
<sabdfl> Viva brazil!
<ogra> hehe
<\sh> sabdfl: ola :)
<Mez> hey sabdfl 
<Treenaks> hi sabdfl 
<Mez> can someone answer me - is brezy in a usable state, I've been itching to use it for like a week now :d
<Mez> lol
<\sh> Mez: until 2005-10-13 latest
<Treenaks> Mez: if you're VERY brave, and promise not to complain if we're wrong.. go ahead & try :)
<camilotelles> Mez, we are using it here, the live CD version.
<Treenaks> Mez: otherwise, just wait a few months
<Mez> Treenaks, I dont mind if things break, but as long as they dont break too badly
<Mez> and I have a complete backup of my filesystem :D
<Mez> but how am i to confirm bugs
<Mez> if i cant test
<Mez> oh, and the LiveCD version = uber slow for me
<lu|lunch> maybe I'm looking in the wrong place, but the only recent livecds I see are for amd64
<camilotelles> Mez, hacked an install script for the live cd version. We are using the live cd installed.
<Mez> lol
<camilotelles> Mez s/hacked/We hacked
<Mez> camilotelles, that sounds... scary
<camilotelles> Mez, it's working.
<Mez> camilotelles, it still sounds scary
<camilotelles> Mez, maybe it is. 
<\sh> Mez: make sure...u have us keyboard layout
<mdz> luis_: non-amd64 live CD builds have been failing recently
<\sh> Mez: and don't use german or kyrillic
<luis_> mdz: OK, so not just me looking in the wrong place then
<Mez> what about UK?
* luis_ waits patiently
<\sh> mdz: thx for the lesson :) 
<mdz> \sh: no problem
<camilotelles> Mez, FYI we are using the 2005-06-28-breezy-live.iso version from cdimage.ubuntu.com
<\sh> actually..I should avoid to ignore my own words
* Mez tries not to shudder
<ogra> luis_, just get some "real" hardware :)
<luis_> heh
<luis_> I'm trying to market gnome to real people
<luis_> that means real common hardware
<luis_> which, uh, amd ain't ;)
<ogra> luis_, hey, i run a laptop with amd64 .... its the future in cold countries :)
<luis_> haha
<luis_> my poor little pentium M is perfectly sufficient today
* luis_ turns up air conditioner
<\sh> infinity: ping
<\sh> somethings messed up....
<\sh> The following packages have unmet dependencies: xlibmesa-gl-dev: Depends: x11proto-gl-dev but it is not going to be installed
<\sh> on i386 buildd..but not in my pbuilder 
<doko> elmo: please sync python-numeric. this is a new upstream version, however the changes are build and bug fixes only
<doko> elmo: please sync python-reportlab from unstable. it's a new upstream, but I'm fairly sure I did ask for the sync before the UVF
<jan1> doko, do you think wxwidgets and wxpython remain frozen at 2.5 the current state?
<jan1> There's 2.6.1 in experimnental I know python had special treatment in hoary
<doko> jan1: thanks for reminding me ... have to write an email
<jan1> doko, so you want 2.6?
<dholbach> hellas
<jan1> hi daniel!
<pitti> dholbach:!
<doko> dholbach: finished your thesis? 
<dholbach> hey pitti, hey doko
<dholbach> doko: nearly :)
<doko> dholbach: then GO AWAY!
<doko> :)
<dholbach> doko: i'll attend the TB meeting and will be off after that :)
<elmo> doko: please get UVF approval from mdz
<elmo> err, UVF-violation approval, YKWIM
<jan1> elmo, I just sent you a mail asking for a sync of xfce4 at your nocrew address
<jan1> please override all ubuntu changes in the hoary version
<mdz> elmo: ok with me
<elmo> mdz: which?
<jan1> xfce4 is in universe so hopefully both :)
<mdz> elmo: python-numeric
<mdz> is there another request on the table?
<jan1> mdz, xfce4 a few lines above
<mdz> xfce4 is universe, implicitly OK at this point
<seb128_> elmo: can we get these packages from debian exp: gdl gnome-build?
<TerminX> ugh.. every time I right click a package in synaptic in breezy and click mark or unmark, X locks up entirely
<elmo> python-numeric |     23.8-3 |        breezy | source, all
<elmo> doko: nothing to sync
<mdz> Mez: er, ltsp backport?
<ogra> lol
<jan1> elmo, sorry _now_ I sent the mail - originally was elmo at nocrew :)
<elmo> jan1: please use james@ubuntu.com for ubuntu email
<elmo> seb128: can't see gnome-build ?
<Burgundavia> mdz, Inkscape .42 was released today. When it hits debian unstable, can we sync it?
<mdz> Burgundavia: any reason other than "it's newer"?
<doko> elmo: I see, old package on the system :-/
<Burgundavia> mdz, there an annoying usablity bug in .41 that causes it to launch an error screen at startup, when if fact there is no error (it is just telling you about missing extra functions)
<Mez> mdz: what ?
<Burgundavia> mdz, the inkscape team also describes this as their biggest release yet, in terms of new features
<mdz> Mez: Subject: ltsp_0.43~hoary1_source.changes ACCEPTED
<seb128_> elmo: it has been upload some days ago, I got it from incoming ... maybe due to ftp-master move? Just gdl for now so, that's fine. Thanks
<jan1> elmo, ok re email, do you know where the mercurial package is stuck on the way from sid?
<Mez> mdz: I sent elmo a list of whatever was already in repos
<mdz> Burgundavia: "biggest release" and "new features" are not what we want to hear when making an exception to the freeze :-)
<Mez> i believe people wanted it fror the client
<mdz> "minor release" and "bugfixes only" are strong candidates
<mdz> Mez: it's not going to be installable at all
<Mez> mdz: our backport works fine
<mdz> it requires breezy versions of other packages
<Mez> ah, fair enough - Well as I said - I just got a list of packages from current backports
<Mez> feel free to pull it
<Burgundavia> mdz, inkscape is only supported seed and no other packages depend on it
<mdz> Mez: I'd like to see that list, if you could mail a copy to mdz@ubuntu.com
<mdz> Burgundavia: another way to put it would be this...the current version is at least known to build and work.  if the new one doesn't, who will fix it?
<Mez> mdz: sent
<mdz> Burgundavia: if you'll take responsibility for it, that would be fairly convincing
<elmo> seb128: ok, pls re-ping me when it arrives (or mail)
<Burgundavia> mdz, several of the inkscape deveopers already run Ubuntu, so there is a pretty high indication that it will work
<Mez> elmo, if you havent already done the list, then just poke me if you see anything you thing shouldnt be in there
<elmo> mez: I've done the list
<Burgundavia> mdz, I will try out the new release and report back
<mdz> Mez: the client side can't possibly work; it depends on initramfs-tools which is neither in hoary nor backports
<Mez> ah, ok thanks!"
<Mez> hmm: mdz - I've not used ltsp :D so I wuldnt know
<Mez> lol but, yeah, pull it
<mdz> the server side will soon become uninstallable on hoary too
<Mez> mdz: to be fair, looking at the backports changelog, It doesnt seem to have been added.
<Mez> oh, no, it's showing now
<Burgundavia> mdz, shall I email you?
<Mez> John did it, but feel free to pull from the official
<Mez> I dont know why it's in there
<Mez> is there anything else on the list that should be pulled?
<mdz> Mez: nothing else that I noticed immediately
<mdz> they are mostly safe app-level stuff
<Mez> ok, good :D
<mdz> but ltsp is tightly integrated infrastructure
<Mez> Johns gonna have a nother list after that's all gone through
<mdz> elmo: can you kick ltsp from hoary-backports, or do we need to wait for it to build?
<elmo> I can make it disappear altogether even
<mdz> Mez: don't you usually do a test build and make sure that the resulting package installs and works?
<ogra> elmo, only from backports please :p
<jan1> elmo, should I mail the xfce request at you ubuntu address as well or it's fine where I sent it initially?
<pitti> elmo: a propos disappear, could we remove mozilla-firefox from breezy?
<elmo> jan1: it's fine there, I mean for future ref
<Mez> mdz: usually, but thats because we have to build the debs
<Mez> mdz: but those shoudl build fine, unless they're a slightly higher version from wheere we previously backported
<Mez> mdz, we backported ltsp 0.1
<elmo> pitti: meh, yeah, stupid disappearing sync blacklist
<Mez> so that's probably why it worked
<mdz> Mez: yes, ltsp will build, but the packages it builds will not install (at least ltsp-client)
<pitti> elmo: I'm not sure, lots of packages depend on it, but actually they should depend on firefox now
<jasoncohen> USN-155-1 says that " We apologize for the huge delay of this update; we changed our update strategy for Mozilla products to make sure that such long delays will not happen again." Does this mean hoary & warty will now get new upstream firefox/mozilla releases? the security team has been unable to keep up with mozilla & firefox updates on warty and has only been decent on hoary
<mdz> Mez: do you have a mailing list where you discuss these things?
<pitti> elmo: I'll fix the langpacks soon (they depend on mozilla-firefox)
<pitti> jasoncohen: yes, we ship new upstreams now
<jasoncohen> hurray- it took long enough ;)
<pitti> jasoncohen: we tried very hard with backporting fixes, but it took weeks and weeks, it broke things and we couldn't keep up
<Mez> mdz: http://groups-beta.google.com/group/ubuntu-bp-devel
<jasoncohen> pitti, i understand- look what happened to mozilla in debian woody
<jasoncohen> they just gave up
<jasoncohen> it's just not worth the effort
<mdz> Mez: any problem with moving that to lists.ubuntu.com?
<pitti> jasoncohen: I researched a bit, we seemed to be the only ones who actually tried backporting
<Mez> mdz, if you wanna provide the list, I shouldn't see why not
<jasoncohen> pitti, not true- mandrake tried that as well
<pitti> jasoncohen: well, RH did it in the past as well, but not any more
<mdz> Mez: certainly
<pitti> jasoncohen: they updated to 1.0.6 in their enterprise distro...
<whiprush> I believe they went to far as to do a new mozilla release for all their old RHEL releases.
<jasoncohen> pitti, it seems like firefox has too many security fixes and too much changes over time to allow backporting fixes to be a viable option
<Mez> mdz: we'll talk after meeting - k?
<pitti> jasoncohen: backporting worked for like 1.0.2 -> 1.0.3, but 1.0.5 was a mess
<jasoncohen> pitti, i'm talking about when i used mdk 10.1
<pitti> jasoncohen: that's what we learned the hard way now; it's just against our normal policy
<jasoncohen> pitti, i got sick of the wait - it was over 2+ weeks to get all the security updates on hoary so i just used the official binary
<jasoncohen> i did that after 1.0.4
<jasoncohen> updated to 1.0.5 and then 1.0.6 the next day
<mdz> Mez: Mez yep
<pitti> jasoncohen: yes, with new upstreams updates will be very fast now
<jasoncohen> pitti, well, thank you for making this step. I've been arguing for it for a while now. I was upset by the non-existent security updates on warty, the long waits on hoary and even after all that there were more problems then just using the upstream version (like the mozilla extensions issues and now with the 1.0.5 fixes
<pitti> right
<jasoncohen> pitti, and i bet you'll find an unintended positive consequence- less newbie backport users!
<pitti> now I hope that the new upstreams don't cause too much trouble
<doko> 1.0.6 FTBFS on amd64
<jasoncohen> newbies just don't get the concept of backporting security updates. Now that hoary has the latest firefox, a lot less new users are going to immediately add backports to their systems which in my opinion is a good thing
<Mez> thanks jason :D
<jasoncohen> backports is definitely useful, but too many users add it when they don't know what they're doing
<whiprush> People like their crack-of-the-day.
<pitti> doko: will look at it soon
<jasoncohen> Mez, don't misunderstand me- i really like backports, and i have helped you guys fix problems from staging (firefox dependencies of libgcc1 4.0, konversation that broke kubuntu-desktop etc.)
<Mez> yeah I know :D
<jasoncohen> Mez, i just don't think most new users really need backports. they think they are vulnerable because firefox says 1.0.2 and immediately add backports
<Mez> at least now it's official there's less problems with stuff
<jasoncohen> Mez, and i supported it going official- i can't wait until you get backports on the official ubuntu servers
<Mez> jasoncohen, they're building as we speak :D
<jasoncohen> Mez, did you read my post on providing a mozilla-mplayer package with gtk2 support?
<jasoncohen> Mez, i packaged one and can give you the source
<Mez> jasoncohen, no I didnt
<Mez> jasoncohen, after the meeting
<jasoncohen> ok
<hughsie> ogra: ping?
<jasoncohen> Mez, the default mozilla-mplyer is built with --enable-x rather than --enable-gtk2 and because of that there's no menu/button support. it's much more attractive with gtk2 and you can now download the stream & watch full screen like you can with quicktime/windows media player
<Mez> It's done that way in hoary I presume? or just bp?
<ogra> hughsie, sorry meeting... (but you might like to join #ubuntu-meeting)
<hughsie> ogra: will do
<jasoncohen> Mez, it's done in hoary because it's done that way in debian
<Mez> jasoncohen, and is it the same in breezy?
<jasoncohen> Mez, i contacted the debian developer (submitted a wish list) and he didn't respond
<jasoncohen> Mez, it's the same in breezy- debian users are anti-gui and i got a lot of flac on #debian so i'm not surprised he didn't respond
<jasoncohen> basically, mozilla-mplayer is taken straight from debian w/o modifications. the change is trivial
<Mez> jasoncohen, ad a bug on malone, and poke me to it :D
<Mez> I'll see what i can do
<jasoncohen> thanks, will do
<jasoncohen> Mez, thanks for the great work on backports
<Mez> np :D
<Mez> wish me luck - I'm up nextish in meeting
<jasoncohen> i'll continue to test staging and post problems when i find them
<Mez> jasoncohen, we're moving to official Very soon
<jasoncohen> awesome...hey, did you remove 1.0.6 from backports-staging?
<jasoncohen> there's no need for it now. i saw you removed 1.0.4
<Mez> lol
<Mez> I know
<Mez> problems talk later bout
<jasoncohen> ok
<jasoncohen> heh, i guess that's a no- it's trying to install 1.0.6 from backports (after i removed it to go to hoary version)
<Mez> lol
<jasoncohen> oh, i didn't notice that in the SVN changelog firefox 1.0.6 was upgraded to backports from staging
<Mez> yeah
<Mez> grr
<jasoncohen> mistake?
<jasoncohen> pitti, so i take it, we can expect firefox 1.0.6 in warty shortly?
<pitti> jasoncohen: I'm already at it
<jasoncohen> great
<pitti> jasoncohen: the package is a mess (lots of patches and no proper patch system), I have to sort that out, but it should be there by tomorrow
<jasoncohen> so, firefox will be the one exception, correct?
<jasoncohen> can we expect thunderbird patches in the near future. it's been a while
<siretart> elmo: ping
<pitti> Hi shackan 
<shackan> hi
<shackan> sorry for not making often contact
<shackan> I'm there coding nevertheless
<spacey_ki> mako_, at wth yet? :)
<mako_> spacey_ki: yes.. the network *just* came up.. we'll how long it stays up :)
<luis_> hey, mako_ 
<luis_> sounds like you're having fun ;)
<mako_> i am.. i'm in ascii's tent
<mako_> in the wireless village.. where wireless is not working and i'm connecting over a wire
<luis_> haha
<luis_> there is a separate wireless village?
<mdz> mako_: the wirey village?
<opi> mako_: sould like my paid ISP to me ;)
<Mez> mdz: poke me when ready to carry on our chat
<mdz> Mez: just finishing up
<Mez> yeah, I saw, hence the nudge
<jan1> now that ogra mentions is: is shtoom/voip still on the breezy schedule
<Mez> wb slomo 
<Mez> SloMo_, *
<SloMo_> thanks Mez :)
<mdz> Mez: right, so I'm all set to create this mailing list.
<mdz> Mez: will you be the list owner?
<Mez> might as well be :D
<mdz> Mez: do you have an ubuntu.com email address yet?
<Mez> mdz: no I don't - apparently they're not ready for members yet
<Mez> but if you want to create me one, feel free,
<mdz> Mez: ok, I'll use your sourceguru.net address then?
<Mez> It'd be useful
<Mez> mdz: if you have to, though if it's possible to create me an ubuntu.com email, that'd be better for me
<mdz> Mez: that's not my department; I was under the impression that @ubuntu.com was up and running for members
<Mez> mdz: when I got my membership I spoke to James and he said it wasnt
<mdz> sabdfl,elmo: what's blocking that?
<ogra> mdz, thats a laubchpad issue as i understood it...
<ogra> launchpad...
<Mez> that he's only added from the main DC so far
<mdz> ogra: sabdfl told me the launchpad side was done
<ogra> mdz, it should work automatically then.... hmm
<Mez> keybuk, can you am yourslef with another roll ? :P
<Keybuk> Mez: I'm a bit too far away from elmo (some 9,000 miles) to get him
<Mez> ah, fair enough
<spacey_ki> mako_, yes :)
<spacey_ki> mako_, come have a beer with us
<hughsie> ogra: got a minute?
<ogra> yep
<ogra> hughsie, how did you like our meeting? :)
<Mez> mdz: I'll get to setting that up now...
<hughsie> ogra: I've made the gnome-screensaver changes you wanted to CVS, and made libnotify a configure argument.
* Mez adds another mailing list
<hughsie> ogra: it looked good. community spirit
<ogra> :)
<luis_> libnotify in gnome-screensaver?
<luis_> what for?
<mako_> spacey`wth: where are you?
<hughsie> luis_: no libnotify for gnome-power-manager
<luis_> (just curious, not like accusatory or anything)
<luis_> hughsie: ah
<ogra> hughsie, ok, so i'll drop the packages i made today (noit everything though) and package CVS
<luis_> hughsie: cool
<hughsie> gnome-power.sf.net for screenies
<mako_> spacey`wth: i'm in the ascii tent tent with a pirate hoodie
<spacey`wth> mako_, ok
<spacey`wth> mako_, want a beer?
<hughsie> ogra: hang fire, i havn;t committed them
<spacey`wth> i will come to you
<mako_> spacey`wth: i would love to have a beer :)
<hughsie> ogra: give me 5
<mako_> spacey`wth: can you come meet me here?
<spacey`wth> i'll bring one for you
<spacey`wth> mako_, yes 
<ogra> luis_, hughsie does an awesome work for us, making gnome-power ready for ubuntu ;)
<mako_> spacey`wth: awesome :)
* ogra gives hughsie ^5
<luis_> coolio
<\sh> hey mako_ where r u just now? :)
<hughsie> thanks ogra :-)
<mako_> \sh: some field in the netherlands :)
<luis_> so you guys will be shipping g-p-m and screensaver in breezy?
<ogra> hughsie, i work since 9:00 today (same TZ) i wont package anything today anymore ;) take your time ;) 
* luis_ is running breezy, but sort of crippled ATM
<\sh> mako_: visit ogra when u have time...will join u for some beers :)
<ogra> luis_, thats the plan :)
<luis_> coolio
<hughsie> ogra: two ticks g/f
<sabdfl> ogra, mdz: https://launchpad.ubuntu.com/distros/ubuntu/
<sabdfl> you can click on "Ubuntu Members" to see the current list
<sabdfl> clearly, it's a little short :-)
<ogra> sabdfl, it was about the mail adresses
<ogra> (@ubuntu.com for members)
<Nafallo> sabdfl: that list is not current ;-)
<Mez> yes, it was about the @ubuntu.com email for memebrs
<Nafallo> atleast I'm not on it :-P
<Mez> oh, and there are quite a few people on the pending list for that group, who are already members :D
<Mez> but havent beel "accepted" by mako yet.
<Mez> Due to his time limitations
<ogra> Mez, i guess mako_ has to approve them 
<Mez> :P
<\sh> and thx to infinity or lamont (one of the two) for fixing the buildds :) 
<lamont> \sh: what was broken?
<bddebian> Does the launchpad CoC signing automate the process or does Mako still have to approve?
<Mez> pitti: you still around?
<lamont> sabdfl: it's missing all the original crowd, for example...
<Mez> bddebian, mako still needs to approve
<bddebian> OK
<Mez> lamont: I believe mako's got that on his "to do" list :d
<\sh> lamont: some glu magic...didn't get the right build-deps
* mvo goes to bed now
<lamont> \sh: ah, ok
<\sh> lamont: it's fixed now..only ia64 ftbfsing but this has to do with some other things..
<\sh> (for GLU.h)
<ogra> night mvo
<Mez> \sh here?
<\sh> yes no yes no yes :)
<Mez> gonna need a main package updated so it can be bckported
<dholbach> good night everybody :)
<\sh> Mez: run...as fast as u can :) 
<Mez> \sh - why ?
<ogra> night dholbach 
<\sh> g'night dholbach and thx :)
<dholbach> night you two :)
<Mez> \sh it's just a change on a Build-Dep
<Mez> which shouldnt be set to what ti is :D
<Mez> lol
<\sh> Mez: yes ask ogra :) I don't have the right now :)
<Mez> \sh, but it's a KDE package
<Mez> :-"
<\sh> Mez: yes ask ogra ;)
* ogra hides
<\sh> ogra: that's for your firefox...
<Mez> ogra :D It's a pretty simple one
<Mez> kde/konversation_0.18-1ubuntu2~hoary1: Dep-Wait by buildd+rothera [optional:uncompiled] 
<Mez>   Dependencies: cdbs (>= 0.4.27-3)
<Mez> should be a dep on cdbs (>=0.4.21)
<Mez> I believe
<ogra> hmm
<Mez> unless of course I changes something else
<Mez> lemme see in a debdiff
<ogra> man, thats 7MB big... isnt that a IRC client ? 
<Mez> yeah
<Mez> weird huh
* ogra shakes head
<Mez> lol
* Mez does a debdiff on his old backport to the breez\y version (I packaged both so their shouldnt be much)
<ogra> Mez, are you sure it will compile with the change ?
<Mez> I'm just checking what I changed
<Mez> yeah, thats the only change thats been picked up (well, lots of changes but they just seem to be bad packaging :D
<Mez> lol
<Mez> changes from 0.16 -> 0.18
<Mez> oh
<Mez> crap
<\sh> lamont: can I bug u again? 
<Mez> libxi-dev isnt in hoary is it
<lamont> \sh: that's a kinda personal question, doncha think? :-)
<lamont> sup?
<\sh> lamont: hehe:) o
<dholbach> Mez: http://packages.ubuntu.com knows :)
<\sh> lamont: xchm...it's in dep-wait with wrong build-dep on libwxtk2.5..I uploaded yesterday the same version with libwxgtk2.4 build-dep...(didn't see that xchm was already in the queue)
<ogra> Mez, it is, accorrding to http://packages.ubuntu.com/hoary/libdevel/libxi-dev
<Mez> it was rhetorical
<Mez> ogra: then why is there a dep-wait on it
<Mez> oh
<Mez> nvm
<Mez> I'm an idiot
<Mez> lamont: unknown/gtk-sharp2-unstable_1.9.5-1ubuntu2~hoary1: Dep-Wait by buildd+vernadsky [-:uncompiled] 
<Mez>   Dependencies: cli-common
<\sh> lamont: should I upload it with a different version and u fix the dep-wait manually? ;)
<lamont> \sh: once it's depwaited, it takes a buildd admin to un-depwait it, unless the d-w is resolved....
<Mez> It just built cli-common, cna you clear the depwait once it's installed?
<ogra> Mez, err, konversation is dep wait because of cli-common ?
<lamont> so it sounds like you want the buildd's to pretend that libwxtk2.5 is available, and that cli-common is as well?
<Mez> ogra: konv = dep-wait because of cdbs
<lamont> Mez: the archive install includes clearing dep-waits... that's what they're fore
<lamont> s/e$//
<Mez> ah, ok lamont
<ogra> Mez, so the fix i make her is valid ? should i upload or not ?
<ogra> here even
<Mez> yeah, upload to main :D
<\sh> lamont: no..I want the build-dep to be removed, cause the merge comes from debian and it's wrong, cause 2.5 is not in our archives right now...and doko will send 2.6 in ...so 2.4 is good for now...and I uploaded with 2.4 build-dep
<Mez> that'll make it backportable
<Mez> though I think I'll have to poke elmo to get it to build again
<ogra> Mez, i'll point complaintments to you then...
<ogra> uploaded
<Mez> ogra: make the changed-by as me :D
<Mez> lol
<Mez> then you dont get complaintments to me :D
<hughsie> ogra: sorry about that. i can't type and tealk to my g/f *she knows*
<Mez> you *
<lamont> \sh: the package will remain dep-wait: libwxtk2.5 until either that package exists, or we pretend it's available
<ogra> to late, i made some notes in the changelog ;)
<Mez> ogra :D fair enough
<\sh> lamont: so pretend it...let 2.4 be 2.5 :)
<ogra> hughsie, its ok :)
<Mez> ogra, got a new mailing list for ya :D
<lamont> uploading packages to change build-deps doesn't make things automatically leave dep-wait
<\sh> lamont: i didn't see that xchm was in the queue :(
<lamont> \sh: is there source in the archive (accepted and visible) that says 2.4? or does it still say 2.5?
<ogra> lamont, but fixing the issue before giving back helps ;)
<\sh> before I uploaded better to say
<Mez> lamont :D I know that - hence I'll have to poke elmo :D
<\sh> lamont: yes
<hughsie> yes, ogra, the only non-ubuntu dep at the moment is dbus 0.35 - was there any decision on that?
<lamont> \sh: so if I make it try to build the current source, it should work?
<lamont> ogra: yes. there is that...
<\sh> lamont: yes 
<\sh> Accepted xchm 2:0.9.8-5ubuntu1 (source)
<\sh> Date: 
<\sh> Yesterday 20:50:02
<ogra> hughsie, nope, pitti and mdz will have to decide that
<lamont> \sh: ok.  so I'll tell wanna-build to pretend that libwxtk2.5 is available, and that'll clear the depwait, and let xchm try to build
<\sh> lamont: rocking :)
<hughsie> ogra: g-p-m aside, most apps are using 0.35 as the "standard" you'll have to do a lot of patching when ppl start converting to glib/qt/python bindings
<pitti> hughsie: as I said, if 0.35 breaks any of our existing dbus clients, it'll be hard
<hughsie> pitti: Give it a go, i can knobble g-p-m to not use the bindings, but i did want to do the main program at some point
<ogra> hughsie, the prob is that we are in upstream version freeze already... changing such a essential package is hard
<hughsie> ogra: appreciated.
<pitti> hughsie: can you please ask daniels about it? he maintains dbus
<ogra> hughsie, i will hav bloody knees from begging to get even g-p-m in ;)
<hughsie> ogra, pitti, dbus0.35 is being backported to FC4, I'm sure they didn;t take that decision lightly.
<hughsie> ogra :-)
* lamont notes that it's libwxgtk2.5-dev, considers larting \sh for effect
<hughsie> pitti, when's daniels about?
<pitti> hughsie: he's in Australia, so in a couple of hours
<Burgundavia> ogra, after I try and get inkscape and screem, I might be joining you in that category
<\sh> *ugh* I'm not pulling in non -dev packages most of the time for build-deps
<hughsie> pitti, typical!
<lamont> \sh: WTH???
<Mez> lamont, you have access to kill things from the buildd's right
<ogra> Burgundavia, mine is a breezy goal where upstream made very ubuntu specific changes, i guess its easier for me to convince mdz or that then for new features in inkscape
<hughsie> ogra: is libnotify likely?
<Mez> I've noticed things going into archives that shouldnt be - (my stupidity for now knowing what the packages were)
<lamont> \sh: rather more to the point, the package was dep-wait libwxgtk2.5-dev.
<Burgundavia> ogra, yes, that is true
<hughsie> if not I can made the messageboxes prettier than they are
<ogra> hughsie, depends on upstream... 
<lamont> Mez: I have the ability to make architecture foo never ever ever build package bar again
<hughsie> ogra: you mean you're waiting for a 0.0.1 release?
<ogra> hughsie, if he gets a tarball out in time, seb128 will package it he said...
<\sh> lamont: yes it was/is...I should say, that I'm refering in 99% to *-dev packages
<lamont> Mez: but I have to be convinced to wield that sledge hammer
<ogra> hughsie, yes, he apparently said he would package one for getting it in ubuntu
<Mez> lamont: ah - well we shouldnt be backporting mono stuff
<hughsie> ogra: I'm on it
<Mez> and I didnt realise some stuff was mono stuff
<lamont> Mez: what's in the archive is an elmo issue, not me
#ubuntu-devel 2006-07-24
<slomo> damn... does someone know how to workaround a bzr bug with unicode chars in the name? :(
<lifeless> slomo: whats the bug
<lifeless> slomo: also, #bzr is MUCH more likely to have an answer.
<karim18> hey guys, how are you all doing today?
<bddebian> Hello karim18
<infinity> karim18: Do you really want to know? :)
<karim18> do you guys know where I can get GOOD technical documentation on Ubuntu?
<karim18> infinity: Sure, why not :P
* infinity is grumpy about waking up at 6am on a Monday morning -- Not a good start to the week.
<karim18> in Asia infinity?
<HrdwrBoB> karim18: 'on ubuntu' ?
<infinity> karim18: Australia.
<karim18> yeah, i.e. Docs on Development, etc..
<tritium> infinity: is this not something you do every week day?
<bddebian> Well good morning then infinity :-)
<infinity> tritium: I tend to roll out of bed at 9 or 10 most days. :)
<karim18> Mornin infinity, well then, I'm drinking at 6 am in mornin australia time
<tritium> infinity: wow!  I envy you :)
<infinity> tritium: Combine that with the fact that I didn't get to sleep until about 3am, do the math, and you can understand the grump.
<infinity> karim18: It's 9am, now.
* tritium understands
<karim18> lol, ok, So I'm sipping some red wine at 9 am australia time
<infinity> tritium: Don't envy too much.  I may roll out of bed at 10, but then I work until 2am.
<karim18> ;)
<tritium> infinity: fair enough :)
<bddebian> Hmm, third time in a row, no response from infinity, maybe I'm on ignore..
<infinity> bddebian: Hrm?  No, not intentionally at any rate.
<infinity> bddebian: Also, hi.
<bddebian> :-)
<tritium> hi bddebian 
<bddebian> Heya tritium
<LaserJock> karim18: help.ubuntu.com has a Packaging Guide and wiki.ubuntu.com also has a fair amount of development related documentation
<karim18> LaserJock: Thanks ;)
<tritium> karim18: also http://www.debian.org/devel/
<tritium> handy for policies, etc.
<LaserJock> yes that is also very good, especially the Debian Policy
<karim18> tritum: thanks man ;)
<karim18> I appreciate the help guys :)
<tritium> :)
<jadaz87> tritium: may i pm you?
<tritium> jadaz87: okay
<lprofil> good evening
<lprofil> i have a small prob with compiling cinelerra from cvs-sources 
<crimsun> please ask in #ubuntu
<lprofil> ok
<lprofil> actually there is a dependecy prob with the libaries i try to install 
<lprofil> i think this is developer related
<lprofil> isn't it ?
<LaserJock> not particularly
<LaserJock> if it's a bug it should probably be filed on Launchpad
<lprofil> i filed it allready
<LaserJock> ok
<lprofil> i have trouble to install "libfaac-dev:"
<lprofil> "libfaac-dev"
<lprofil> can you merge it into your dapper system ?
<crimsun> please, this is not Ubuntu-centric. I'm happy to help in either #ubuntu or #ubuntu-motu.
<lprofil> via apt-get ...
<lprofil> ok
<lprofil> i'll try there
<lprofil> anyway, thank you for beeing kind if i might have annoyed you 
<lprofil> bye
<fabbione> morning
<Hobbsee> hi fabbione!  you're on early!
<fabbione> Hobbsee: same reason as last week
<Hobbsee> fabbione: hmmm okay, your wife, or something else?
<fabbione> heat
<Hobbsee> ahh...
<Hobbsee> yes, right, i remember now :P
<bddebian> fabbione: Do you care if I hit afbinit merge?
<fabbione> bddebian: is that the sparc fb fw loader?
<bddebian> 3D Framebuffer Firmware INitializer, but it FTBFSs anyway
<fabbione> go ahead and fix it if you know how
<fabbione> it might be because of l-k-h
<fabbione> why should be FTBFS?
<fabbione> i don't see any build log
<fabbione> (from edgy at least)
<bddebian> fabbione: No, the Debian package FTBFSs
<bddebian> afbinit.c:272: warning: incompatible implicit declaration of built-in function 'exit'
<bddebian> as: unrecognized option `-Av9a'
<bddebian> make[1] : *** [afbinit]  Error 1
<fabbione> that's broken toolchain
<fabbione> or broken B-D
<fabbione> bddebian: if you don't have a sparc to test, don't bother. i can take it
<bddebian> OK, sorry, I was just trying to clean up the manual merges :-(
<bddebian> I wish I had a sparc
<fabbione> nothing to be sorry
<pitti> Good morning
<ajmitch> morning pitti 
<Hobbsee> hi pitti 
<joejaxx> Hobbsee: :)
<fabbione> feh
<Hobbsee> fabbione: hmmm?
<dholbach> good morning
<pitti> hey dholbach, moin mvo
<mvo> good morning pitti, *
<dholbach> hey pitti
<dholbach> ogra: a new gnome-power-manager for you!
<pitti> moin ivoks 
<ivoks> hi pitti 
<ivoks> greettings from adria :)
<dholbach> hey ivoks
<dholbach> you're having a good time? :)
<dholbach> hellas seb128!
<seb128> hey dholbach
<ivoks> well, not this week, i'm babysitting my little sister
<ajmitch> morning seb128 
<seb128> still sleeping in front of IRC? :)
<pitti> bonjour monsieur seb128
<dholbach> sleeping?
<seb128> hi ajmitch pitti
<dholbach> not really :)
<seb128> dholbach: it takes your about 4 seconds to notice when I join
<seb128> so my bet is that your spend your time in front of IRC waiting for me to join :p
<dholbach> i just waited for you :-p
<seb128> what I was saying :p
<Hobbsee> seb128: irc client notifications?
<seb128> Hobbsee: he's not using that
<Hobbsee> ha
<seb128> Hobbsee: that's sort of "private joke", don't bother
<Hobbsee> *ah.  right
* Hobbsee actually takes her work stuff to work tonight.   bye all1
<ivoks> pitti: i see you have plans for cups web interface
<pitti> ivoks: yep
<ivoks> pitti: how?
<pitti> ivoks: I'll add a sgid shadow helper program 'check_user_password' (or so) to passwd or whereever
<pitti> ivoks: and cups will use that instead of directly reading /etc/shadow
<pitti> ivoks: this might be useful to other programs as well
<ajmitch> pitti: yes, Amaranth was asking about something similar for his proxy
<ivoks> pitti: i see...
<ivoks> pitti: that would solve other problems in cups too
<pitti> ivoks: wait for the next edgy release, this will be a bug killer :)
<ivoks> :)
<Amaranth> pitti: heh, i was just looking for a sane way of doing something like the cups web interface
<pitti> ivoks: and 1.2.2 will go into dapper, too, unless it shows regressions
<ivoks> pitti: sorry, i'm on vacation, so i didn't do any work these days :/
<pitti> ivoks: heh, no need to excuse :)
<ivoks> pitti: well, i'll work on gtk interface
<Amaranth> verify a login against the system account info and check to see if the user is either root or has sudo access
<ivoks> pitti: but i doubt there will be anything for edgy
<Amaranth> would your stuff work for that?
<pitti> ivoks: there will be *definitively* nothing to check if an user is a sudoer
<Amaranth> <--
<pitti> Amaranth:  'groups | fgrep -w admin' must be a good enough approximation
<Amaranth> so i should just check to see if they're in the admin group like you do in gnome-menus?
<Amaranth> yeah
<Amaranth> that's what i have written down in my "how to make this work" note
<ivoks> bye all
<pitti> ivoks: bye, enjoy your holiday
<ivoks> thanks
<mvo> pitti: will a new main inclusion report for libgksu2 be required? it is in universe right now and blocks the build for the latest gksu
<pitti> mvo: is that just a renamed source pacakge from libgksu? (since that already builds libgksu2-0)
<mvo> pitti: yes, renamed+new features+api change
<pitti> mvo: then I don't need a MIR
<mvo> pitti: thanks, then I will ask kamion to promote libgksu2 to main
<Kamion> pitti: check_user_password> surely unix_chkpwd
<pitti> Kamion: the latter only checks for the current user
<Kamion> pitti: or PAM, but I guess you don't want to go to that much effort
<Kamion> oh
<pitti> Kamion: but we need to check the password of an arbitrary user
<pitti> Kamion: and do that in a sane way, e. g. with a mandatory sleep(1) or so
<Kamion> perhaps it could be executable only by CUPS
<pitti> Kamion: for now I think I'll just add that to cupsys itself, and make it executable only for cupsys
<pitti> heh, right :)
<Kamion> I'd be concerned about the new ability for a user to just set a job going for monts
<Kamion> months
<pitti> Kamion: if we notice that it will be useful for other daemons, we can still extend it
<pitti> Kamion: cupsys:shadow 2744 should be okay for now
<dholbach> Kamion: did you have the time to check jokosher?  if so, I hope it was ok this time :)
* Kamion introduces dholbach to the concept of a weekend :-P
<Kamion> I've only just "got in"
* dholbach hugs Kamion
<dholbach> i know... you said "tell me, when you uploaded it again" and i didn't notice you vanishing on friday, that's why i asked -- take all the time you need :)
<slomo> dholbach: do you also plan to update the gstreamer python bindings? iirc jokosher wants something from the 0.10.5 release
<imbrandon_> weekend ? they have those in FOSS ? /me ducks ( just kiddin guys )
<dholbach> slomo: it wants the new gnonlin and new gstreamer - i didn't look at pygst yet
<slomo> dholbach: ok, if you look at it merge with debian... they have a different source package name than we have (but fortunately the same binary package names)
<dholbach> grrrrr :(
<dholbach> seb128: did you know about pygst having a different source package name in debian and all?
<seb128> any reason to keep it different?
<seb128> dholbach: nop
<seb128> we packaged it first
<slomo> seb128: nope... it only happened because we pacakged it first
<seb128> and the maintainer didn't care looking at what we did :p
<slomo> i already requested a sync and removal of our old one but if daniel wants to update to 0.10.5 the sync could just be skipped ;)
<dholbach> i didn't intend to do the update (i didn't even know it had an update)
<Kamion> imbrandon_: it's a bit different if you're employed to work on it ...
<Kamion> happy to do the sync/removal shortly
<Kamion> (gst)
<slomo> Kamion: thanks :) regarding the removal requests of the several, old binary packages... mplayer is another case where and older version is superseded but not removed although newer ones were removed correctly
<Kamion> slomo: we have a report listing all of those automatically - no need to tell us about them unless they're urgent for some other reason
<Kamion> (which it sounds like the python2.4-* ones are, so thanks, but it doesn't sound like mplayer is)
<slomo> Kamion: ok... i guess i misinterpreted your comment to the bug yesterday then :) i thought you meant it was confusing because it should've already been removed because newer "old" version were already
<Gloubiboulga> Kamion, could you please reject the colorscheme package in the NEW queue (maybe you already read the logs, but we never know)?
<Kamion> slomo: no, I meant your bug was confusing because you were talking about removing old sources whereas what's actually needed is for the NBS binaries to be removed (and then the old source versions will be automatically garbage-collected)
<pitti> moin mdz
<Kamion> Gloubiboulga: would be done except that Launchpad hates me
<Kamion> (i.e. bug)
<Gloubiboulga> Kamion, ok :)
<Kamion> bug 53871
<Ubugtu> Malone bug 53871 in soyuz "can't reject source package from NEW" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/53871
<Arbiter> o.O
<mdz> pitti: morning
<ogra> morning Keybuk 
<Kamion> TheMuso: lsr needs to be fixed to follow the new python policy
<Keybuk> morning
<Kamion> TheMuso: see http://people.debian.org/~piman/python-policy/ and http://wiki.debian.org/DebianPython/NewPolicy
<TheMuso> Kamion: Ok thanks for the heads up.
<mdke> Znarl: around?
<Znarl> mdke : Hi.
<slomo> infinity, Keybuk: please give-back service-discovery-applet. builds fine now :)
<ogra> dholbach, seb128, is it allowed for gnome people to rewrite half of the code during a freeze ? g-p-m changed majorly ...
<seb128> ogra: what freeze?
<seb128> ogra: ABI, API, UI and feature freezes start after 2.15.90
<ogra> ah, k
<ogra> so i dont have to expect that i have to rewrite all patches after this time ? 
<seb128> correct
<ogra> ok
<dholbach> ogra: you don't want to set upstreams rules :)
<ogra> dholbach, i want to know what they mean :)
<ogra> i dont want to set them ...
<ogra> i thought i had seen the announcement for the freezy on friday already ... but the release schedule proves me wrong :)
<seb128> announcement yep
<seb128> tarball are due on monday
<ogra> yup
<seb128> and the freeze take effect from that
<seb128> after, not before 2.15.90
<ogra> got it now ... i'm so spoiled with our announcement policy to send them afterwards :)
<seb128> that's like "if you have changes you want to ship do them before rolling your tarball because freeze is coming"
<ogra> (or at the day it takes effect)
<seb128> k
<ogra> yup, i understand ...
<ogra> Keybuk, Kamion, can either of you un-NEW wilowng please ?
<ogra> *willowng
<Kamion> ogra: rejecting, it's using DEB_AUTO_UPDATE_DEBIAN_CONTROL; see http://ftp-master.debian.org/REJECT-FAQ.html
<Kamion> it also doesn't appear to be following the new python policy
<ogra> oki, i'll tell Amaranth 
<ogra> Kamion, thanks
<Kamion> I'll mail hiim
<Kamion> him
<ogra> thanks again :)
<geser> does anybody know if the Teardown spec will also support file-rc? or is sysv-rc the only supported package?
<Keybuk> geser: file-rc has never been supported on Ubuntu
<geser> it is in universe and it could be installed till now
<Keybuk> in universe => not supported
<Keybuk> it's your machine, and obviously you can install anything you like on it; but if it breaks, you need to support it yourself
<geser> it's clear
<geser> but now file-rc isn't installable anymore as some packages depend on sysv-rc and file-rc and sysv-rc conflict
<Keybuk> right, that's not surprising
<geser> so I have to switch back to sysv-rc?
<Keybuk> you could also patch file-rc to support the changes to update-rc.d
<Keybuk> though if you're going to give it love, you should almost certainly also patch it to support things like usplash
<Keybuk> packages could then Depend: sysv-rc (>= 2.86.ds1-14ubuntu2) | file-rc (>= 0.8.10ubuntu1)
<geser> I will see if I can produce a patch for file-rc for the recent changes in update-rc.d
<StevenK> Keybuk: I noticed your latest upload of n-m failed to build, so I've gone ahead and pulled it up to 0.6.4 along with fixing the patch so it applies.
<Keybuk> StevenK: no, please don't
* Keybuk explains "Upstream Version Freeze"
<StevenK> 0.6.4 is a bugfix release, and I suspect the patch I had to fix will apply to 0.6.3 anyway.
<Keybuk> if it's a bug fix release, provide the changelog and diff to the release team
<StevenK> Aye
<shenki> on the subject of networkmanager, I would like to see the vpn plugins make it into edgy (they're a part of n-m, but not the main tarball, and hence weren't in dapper)
<shenki> I had no idea about how to go about it, so I wrote https://wiki.ubuntu.com/CompleteNetworkManager - any hits/tips/go-aways?
<Keybuk> shenki: all suitable for universe
<ogra> its already on revu since some time iirc
<shenki> Keybuk: yep, that's what I thought. who would be a good person to talk to about it? I've brought it up in -motu a few times, but no one was around who could give me the right kind of advice
<Keybuk> what do you need to talk about?
<jono> hey
<Keybuk> hey jono
<ogra> looks like the package was never finished and has only one advocate yet
<jono> hey Keybuk :)
<shenki> Keybuk: doing whatever needs to be done to make sure it gets in edgy
<Keybuk> shenki: do it then ;)
<ogra> shenki, http://tiber.tauware.de/details.py?upid=2283
<shenki> heh
<shenki> that's the plan
<shenki> lacking a little on the knowhow at this point though
<ogra> best to talk to tonio i guess
<shenki> okay. thanks
<shenki> had no idea about how/what/where revu was before a few minutes ago
<shenki> so cheers for the pointers
<shawarma> shenki: I'm going to  work on networkmanager, too.
<shawarma> shenki: I hope to fix it enough to even make Keybuk happy. :-)
<shenki> shawarma: what aspect of it? did you read the wiki page I wrote?
<shenki> heh, what will that take?
<shawarma> shenki: Yes.
<shawarma> shenki: voodoo.
<shenki> intresting
<Keybuk> shawarma: in what kind of direction, ooi?
<shawarma> shenki: Well, mostly it has to do with the way it handles DNS.
<Keybuk> my thoughts have been to make network-manager conflict with ifupdown entirely, so once you install it, it forces you to rely on it
<shenki> shawarma: well, let me know if you want any help or testing. also, Fujitsu mentioned to me he's going to package pam_keyring
<shawarma> shenki: Right now, it doesn't, but I'd like it to.
<Keybuk> which takes away a lot of the interaction bugs
<Fujitsu> Keybuk, that's probably a good idea.
<shenki> Keybuk: you'd really need to wait until 0.7 to do that, because what you're suggesting would make the system unable to be online without logging into your desktop
<shawarma> Keybuk: IIRC your main concern was how to deal with network manager changing resolv.conf, but applications not knowing about it.. The NM guys "fix" this by depending on bind, which sucks.
<shawarma> Keybuk: What if we made it depend on one of the DNS proxies already in main. One of the tiny ones, of course.
* Mithrandir thinks NM shouldn't touch resolv.conf directly.
<shawarma> shenki: the pam_keyring thing is totally separated.
<shawarma> Mithrandir: well.. It'd make sense for the networkamanger daemon to set it to point at 127.0.0.1 at boot and then never touch it again.
<shenki> shawarma: seperated from networkmanager? yeah, i realise that. but it's essential for making network manager user friendly, unless 0.7 makes it into edgy (haha)
<Mithrandir> shawarma: why do you think so?
<shawarma> shenki: i suppose. I've never found that particular part very annoying. :-)
<shenki> shawarma: do you have to type your password into that bloody login box every time you turn on your laptop?
<Keybuk> shawarma: then n-m would end up in universe
<shawarma> Mithrandir: Well, that way there can be a dns proxy (whose settings can be altered at any point in time by nm), and we won't need to notify any apps of any change.
<Keybuk> why do you need to notify apps of the change to resolv.conf?
<Mithrandir> shawarma: we don't need to notify apps anyway.
<Keybuk> we patch libc so that apps reload resolv.conf if it changes mtime
<shawarma> Keybuk: Because some apps don't use libc for doing dns lookups and not all of them are clever enough to notice when something changes in resolv.conf
<Keybuk> shawarma: *shrug*
<Mithrandir> shawarma: then they should be patched.  *shrug*.
<shawarma> Keybuk: firefox springs to mind..
<Keybuk> Mithrandir++
<Mithrandir> shawarma: firefox handles resolv.conf changing just fine.
<Keybuk> we're not putting any kind of DNS daemon in ubuntu-desktop
<shawarma> Mithrandir: ok.
<Keybuk> it'd conflict with people running their own DNS server of choice
<shawarma> Mithrandir: But it's one of those apps that doesn't use libc for it.
<shawarma> Keybuk: Sure. But those people are probably not the people using networkmanager.
<Kamion> oh, BLOODY HELL, dash as /bin/sh breaks debconf escaping
* Kamion dives down yet another rabbit hole
<Keybuk> shawarma: but that'd prevent anyone from using n-m
<Keybuk> Kamion: eww, I assumed at least that debconf was bashism free
<Kamion> uses echo
<shawarma> Keybuk: Huh? What would?
<Mithrandir> shawarma: can you come up with an app that breaks?
<shawarma> Mithrandir: I can make on in a few minutes. :-D
<Keybuk> shawarma: depending on a DNS daemon prevents people from installing their own DNS daemon without uninstalling n-m
<Keybuk> shawarma: thus if n-m was in ubuntu-desktop, people with an ubuntu desktop can't run a DNS daemon
<Keybuk> we don't want that
<shawarma> Mithrandir: but fine, let's leave the dns proxy out then. Why would it not be alright for nm to edit resolv.conf?
<Keybuk> so if n-m depends on a DNS daemon, n-m cannot be installed by default
<Kamion> Keybuk: ("echo 'foo\nbar'" behaves differently in bash and dash)
<Keybuk> shawarma: dhclient edits resolv.conf already
<shawarma> Keybuk: Yes, you've mentioned. :-) However, other things might have valuable information that belongs in there. In particular the vpn plugins.
<Keybuk> shawarma: those things can edit resolv.conf
<Mithrandir> shawarma: there's no more reason for it to edit resolv.conf than there is for it to edit /etc/passwd.
<Keybuk> tbh, my ideal n-m situation would be:
<Keybuk> - conflicts with ifupdown
<shawarma> Keybuk: If THEY can why can't nm?
<Keybuk> shawarma: why does nm need to?
<shawarma> because you often use different DNS settings when you're on VPN.
<Keybuk> shawarma: right, I just said the vpn plugins could cause resolv.conf to change ...
<Fujitsu> We need a resolve.conf.d :P
<ogra> eek
<shawarma> If each vpn plugins implements it's own, that's (currently) three extra places things can go wrong as opposed to one if we let nm do it.
<Keybuk> Fujitsu: tbh, we need resolv.conf to be a symlink to /var/run/resolv.conf or something
<Keybuk> to stop people thinking that they can edit it and have their chnages saved
<StevenK> Keybuk: If n-m conflicts with ifupdown, what do you do about people who use n-m to run the ifupdown hooks?
<Keybuk> shawarma: I don't care where the function itself goes
<Fujitsu> Keybuk, yeah, that's a bit of a danger.
<Keybuk> StevenK: n-m runs them itself using run-parts
<Keybuk> /usr/share/NetworkManager/dispatcher.d/01ifupdown
<StevenK> Oh, duh, so it does.
<shawarma> Keybuk: So the function can be in nm, but the vpn plugins should call it? That's the way it works if we let nm change resolv.conf.
<Keybuk> shawarma: indeed
<shawarma> Keybuk: but.. ?
<Keybuk> but nothing
<Mithrandir> shawarma: apart from the fact that the backends will have to be able to edit resolv.conf _anyway_ if they're to function without NM?
<shawarma> Mithrandir: The backends? the VPN plugins?
<Mithrandir> shawarma: the VPN plugins probably talk to openvpn or similar, right?
<shawarma> Mithrandir: Well... Yes.
<Mithrandir> shawarma: and openvpn (or whatever) will have to be able to edit resolv.conf whether you use NM or not, right?
<Keybuk> and openvpn/pppd/etc. usually write resolv.conf themselves anyway
<shawarma> Keybuk: But nothing? Then why have we set it to NOT allow it to edit it?
<Keybuk> shawarma: because then it does something very stupid
<Keybuk> dhclient writes resolv.conf from the DHCP response
<Keybuk> n-m parses dhclient's log, and overwrites resolv.conf again
<Keybuk> which is just wrong
<Keybuk> n-m doesn't need to do anything!
<Keybuk> likewise for things like openvpn and ppp, they write resolv.conf themselves *anyway*
<Keybuk> n-m shouldn't get involved
<Mithrandir> Keybuk: NM also changes my domain search path, which is wrong.
<shawarma> Keybuk: Right, in the case of dhclient. 
<Keybuk> shawarma: it's true in the case of almost everything n-m uses
<Keybuk> Mithrandir: right, it rewrites it wrong
<shawarma> Keybuk: vpnc for instance only alters resolv.conf if resolvconf is installed (the package).
<Keybuk> shawarma: that sounds like a bug in vpnc
<Keybuk> it should write resolv.conf anyway
<Mithrandir> Keybuk: yes and no.  There's no way for me to tell it to keep away from changing that part of the file.  It's trivial to get dhclient to behave correctly.
<zul> hi
<Keybuk> Mithrandir: to be fair, if you're using n-m, you shouldn't care what's in that file
<Keybuk> which is why I want n-m to cause the removal of anything you had to care about
<shawarma> Mithrandir: Will that be any better if we let the different vpn backends change resolv.conf?
<pitti> Riddell: does Kubuntu use libnotify?
<pitti> Riddell: (and notification-daemon)
<Riddell> pitti: nope
<Kamion> Keybuk: it's Debian #306134, if you're keeping bashism score
<Ubugtu> Debian bug 306134 in debconf "Subject: /usr/share/debconf/confmodule usage of echo to communicate with debconf breaks values containing \\" [Normal,Open]  http://bugs.debian.org/306134
<Mithrandir> Keybuk: domain search path is a completely legal thing for the user to change, IMNSHO.
<pitti> Riddell: I will start our mini-frontend for crash reports soon and pondered about a simple inotify -> libnotify app (just to display that there's a new report, asking to file a bug)
<pitti> Riddell: so we'll need a -gtk and a -kde version
<Mithrandir> I like "ssh aine" and "http://aine" to go to the right box no matter what network I'm on.
<shawarma> Mithrandir: What if network-manager had a configuration option to let you prepend certain things to your domain search path?
<Mithrandir> shawarma: I don't want to prepend.  I want to keep my search path in a particular way.
<shawarma> don't get me wrong here guys. I'm not a nm fan boy. :-) I just think nm does exactly what most of our potential users want it to and I want to give it to them. If that steps on someone else's toes, I'll try to fix it as best I can. I just need to know.
<shawarma> Mithrandir: Ok.. so if you could do that, would you be a happy man?
<Mithrandir> shawarma: mostly, yeah.
<shawarma> So.. I agree that the different vpn backends probably know how to fix resolv.conf themselves, but in order to ensure a consistent handling of it (e.g. keeping the right search path) it's a helluva lot easier if only ONE thing changes it (e.g. network manager).
<Riddell> pitti: gnome-cups-manager needs to depend on gksudo
<pitti> Riddell: oh, good point; Recommends: at least
<Riddell> pitti: I'd say depends, it's quite disconcerting clicking a menu item and nothing happening unless you look at stdout
<pitti> Riddell: true
<pitti> Riddell: ok, I wanted to apply an old patch anyway, good opportunity to fix this as well
<Riddell> pitti: are you going to add an Enable Sharing option?
<pitti> Riddell: exactly that
<Keybuk> going into vmware for a bit to test migration and resume-by-uuid
<infinity> slomo: Done.
<ogra> seb128, do we have the pango ottest tool packaged anywhere or do i need the source ? (gvim is complaining a lot about GPOS table)
<seb128> ogra: "ottest"?
<ogra> a tool to parse the OpenType tables in all fonts ... it should be in the pango source
<seb128> it's not packaged afaik
<ogra> thanks ...
<ogra> hmm, locate doesnt show any .otf fonts either ... i wonder why it complains then
<seb128> ogra: the static build has it apparently but it's not shipped
<ogra> well, the GPOS error should only show up for otf fonts, which i dont even have ... weird
<seb128> ogra: on what font do you want to run ottest?
<ogra> seb128, i'd run it over all of them to find the gulty one ...
<ogra> *guilty
<ogra> but i dont have any otf fonts installed ... so that error is nonsense
<seb128> why do you look for an otf?
<seb128> "(vim:378): Pango-WARNING **: Error loading GPOS table 4097"?
<seb128> you get that?
<ogra> GPOS is a class of tables in OpenType fonts
<ogra> yes
<ogra> pitti, did you think about adding a requirement for lsb_init to the MIR requirements ? for packages with initscripts ?
<pitti> ogra: that is already a requirement, however, not mentioned in the template
<pitti> ogra: good point, I'll add that
<ogra> thanks :)
<tseng> Kamion: is there an official process/queue for proposing changes to the desktop seed?
<tseng> Kamion: I'm aware that I can "just do it", but I'd normal expect to run such things past you/mdz
<schasi> hi there
<mdz_> tseng: hmm?
<mdz_> tseng: oh, yes
<mdz_> tseng: we don't have an official process really, no.  what is it you'd like to discuss?
<tseng> f-spot, tomboy to desktop seed
<tseng> possibly deprecating gthumb
<ogra> ugh
<tseng> with an appropriate migration path.
<schasi> Is there some documentation about /etc/debian_version and why it contains testing/unstable?
<ogra> tseng, any idea how much space that will eat with all its deps ? 
<tseng> ogra: last I looked at f-spot it was about 10mb on x86
<ogra> no way for edubunt then
<tseng> tomboy uses the same deps
<ogra> *edubuntu
<slomo> ogra: including mono runtime etc... with the splitted runtime library it should be even less
<tseng> slomo: thats true.
<ogra> slomo, everything above 1-2M is to much
<seb128> ogra: the python cleanup didn't win you some space?
<ogra> it did ... we've eaten up 10 of the 20 already ...
<seb128> anyway we can't stop on making changes that make sense for Ubuntu because edubuntu has no CD space
* Mithrandir sighs over run-init being such a pile of bad code. :-/
<ogra> seb128, i understand ... but i wont be able to include stuff that makes the CD grow ... which means we need to keep gthumb in main :(
<seb128> ogra: no big deal, that's not a high-maintenance cost package
<ogra> seb128, well, its one more on my plate thats edubuntu specific :)
<seb128> ogra: right
* ogra is going slowly mad with g-p-m here ... *sigh*
* seb128 fights with GTK
* ogra hopes GTK didnt drop all void functions from the code and redefined all core function arguments as g-p-m does ...
<ogra> why the heck cant he do such changes at the beginning of a dev cycle ... grmbl
<Riddell> pitti: could I see your sharing patch?  I was wanting to steal the warning string for KDE
<tseng> mdz: sorry, I didnt address that to you specifically above.. all the recent discussion was related.
<mdz> tseng: I'd like to ship them
<tseng> mdz: cool.. I can edit the seeds when I am at a PC with crypto keys and then heat up the gthumb migration discussion. thanks!
<seb128> tseng: are you subscribed to the ubuntu-desktop list?
<bddebian> Hello folks
<seb128> tseng: there is a discussion about f-spot and gthumb from one week ago on it, maybe you could participate on that one instead of starting a new one?
<seb128> bddebian: hi
<bddebian> Hello seb128
<seb128> bddebian: so, what is your issue with launchpad-integration and what should be better communicated?
<bddebian> seb128: I guess nothing, just my own ignorance
<seb128> bddebian: I would think so but you added a comment saying we could let people know about such changes or something like that
<bddebian> I was having a rough week. Colin had a good point that I should have caught it on the diff.
<seb128> ok, no problem then :)
<bddebian> I do feel like those of us living in Universe are a little in the dark at times.  We really have no centralized "leadership"
<seb128> bddebian: lpi is only used for the desktop, not for universe ... :)
<bddebian> Oh crap, I didn't even catch that gcalctool was main...  Now I feel even worse.. :'-(
<slomo> seb128: oh, shall i remove the lpi patch from xchat then now that it is in universe?
<seb128> bddebian: it's the official GNOME calculator ... :)
<seb128> slomo: it doesn't hurt but I'm not sure there is a real point to keep it neither
<seb128> slomo: we modify xchat anyway for the list of chans, etc so you can as well keep it
<slomo> seb128: ok... it's a fairly small diff anyway and applied the past versions without any necessary changes :)
<Gloubiboulga> slomo, will you package the last xchat release or wait for debian to do it?
<bddebian> Congrats Gloubiboulga :)
<Gloubiboulga> (I've quickly packaged it for me using libsexy, it works fine :) )
<Gloubiboulga> hi bddebian, and thanks... but congrats for what? :)
<seb128> co-leading xubuntu probably
<Gloubiboulga> oh yes...
<mdz> Mithrandir: ping
<Mithrandir> mdz: hi
<Gloubiboulga> I need to become a core-dev first ;)
<seb128> Gloubiboulga: you already forgot about it? :p
<Gloubiboulga> seb128, no I didn't ;)
<bddebian> Gloubiboulga: Aye, xubundu
<bddebian> Gloubiboulga: Well you get a +1 from me.  Unfortunately my opinion is worthless around here :-)
<Gloubiboulga> bddebian, thanks :)
* Hobbsee kicks bddebian.  dont think that.
<Kamion> schasi: no documentation as far as I know, but for Ubuntu you should use lsb_release; the reason we keep /etc/debian_version is that it means that code that looks at the version of the distribution to try to figure out how to behave will generally do roughly the right thing if it doesn't specifically know about Ubuntu
<pitti> Riddell: we still have to dig it out again
<bddebian> Hobbsee: I dont think it, I KNOW it :)
<Hobbsee> bddebian: dont know it either.  it's stupid to believe things that are wrong.
<schasi> Kamion:  Thx. Someone guessed it was for compatibility reasons
<schasi> And someone else guessed it was just forgotten by the developers
<Kamion> the first person is correct; the second person is wrong
<slomo> Gloubiboulga: i've already updated it... :P
<Gloubiboulga> slomo, xchat 2.6.6?
<slomo> Gloubiboulga: yes
<Gloubiboulga> nice :)
* Hobbsee wonders when keybuk will be bakc.
<Hobbsee> *back
<tseng> seb128: i am not on that list
<tseng> seb128: corey told me about it when he posted and i read it, no one was saying anything useful at the time
<Kamion> slomo:  cli-common (0.4.3ubuntu1) unstable; urgency=low
<Kamion> ^-- wrong distribution
<seb128> tseng: not sure of what would be "useful" to a discussion about changing the default software, that's sort of people arguing
<slomo> Kamion: oh, thanks for noticing :)
<HiddenWolf> You'd always be bogged down in "I like X vs I like Y"
<Hobbsee> HiddenWolf: you forgot the "BUT I LIKE Z, GIVE IT TO ME NOW!!!!!"
<HiddenWolf> Hobbsee or "I'll run screaming to gentoo if you don't do it!"
<Hobbsee> HiddenWolf: true
<mdke> elmo: around?
<Kamion> Seveas: could you please mark bugs "Needs Info" when you're asking for more information on them (you always seem to forget to do that with ubiquity bugs)?
<ThunderStruck> is there any plan to update "reportbug" to stop using ubuntu-users?
<Kamion> yeah, there's an xmlrpc filebug API to Malone now, so reportbug can be fixed
<ThunderStruck> Kamion: im looking at a bug on it right now
* Hobbsee notes that reportbug seems to be working very nicelly.
<ThunderStruck> thats why i asked
<elmo> mdke: ?
<mdke> elmo: the doc-commits email list doesn't seem to be working
<mdke> any ideas?
<Kamion> ThunderStruck: there are several very old bugs about it, yes
<ThunderStruck> ok ty Kamion 
* Hobbsee waves to Kamion and says thankyou for yet more merges.  You're going to get sick of my requests for merges, arent you?  :P
<bddebian> Hobbsee: Can't be any worse than mine :-)
<Hobbsee> bddebian: i meant in number.
<elmo> mdke: when was the last commit you know off?
<bddebian> Hobbsee: I know
<Kamion> Hobbsee: they're called syncs :-)
<Hobbsee> Kamion: oh bleh.  i blame the incredible amount of boring material to be read at work.  i do know they're syncs, really...i think...
* Hobbsee wonders who stole her brain.
<bddebian> Wasn't me or I'd have one now ;-)
* Hobbsee politely requests that they GIVE ME MY BRAIN BACK!!!!!!!!!!!!1
* Mithrandir gnaws a bit on Hobbsee's brain.
<Mithrandir> oh, sorry
<ogra> yippidy ... finally a g-p-m build that survived ... now ... may it not crash ...
* Mithrandir gives Hobbsee her brain back
* Hobbsee smacks Mithrandir 
* Mithrandir runs
<Hobbsee> Mithrandir: oh thankyou.  much appreciated.
* maswan cackles madly: I will create life! Life itself! Muahahaha!
<maswan> oh
* Hobbsee trips Mithrandir, and watches as he goes sprawling in the dirt.
* maswan goes back to tinkering with his "experiment"
<Mithrandir> maswan: more brane for me to eat?  yummy.
<Hobbsee> hehe
<Hobbsee> Mithrandir: how'd my brain taste?
<maswan> Mithrandir: I saw two zombie movies last night. :)
<Mithrandir> Hobbsee: a bit spongy.
<Mithrandir> maswan: I saw Grease and Dirty dancing last night. :-)  Also quite good.
<Hobbsee> Mithrandir: heh.  what, that means they're stuff there, or not?
<Mithrandir> Hobbsee: absolutely.  Lots of stuff in your brain.
<maswan> Mithrandir: Did they eat lots of braaaains?
<Mithrandir> maswan: no, no brains, but lots of cool dancing which is good too.
<Hobbsee> Mithrandir: ahh..good...interesting stuff?
<Mithrandir> Hobbsee: I wouldn't know when I'm just chewing.
<Hobbsee> Mithrandir: heh
<maswan> Mithrandir: Ah, I guess that could work, if you swing that way.
<pitti> can some ftp master please free cupsys and apport from NEW?
<mdke> elmo: yesterday, rev 3183
<mdke> elmo: Last Changed Date: 2006-07-23 04:47:23 +0100 (Sun, 23 Jul 2006)
<elmo> mdke: hmm, no can't see why offhand - can you mail it to rt, and I'll get someone to investigate?
<mdke> elmo: certainly, thanks.
<bddebian> Did ivman get demoted to Universe in Edgy?
<bddebian> Never mind
<mdke> elmo: done, ticket #15016
<mdke> jdub: can you re-add me to planet ubuntu? I'm not in the list of feeds
<Hobbsee> mdke: he's likely to be asleep, FYI
<mdke>  /away is so underused nowadays
<mdke> Hobbsee: thanks
<Hobbsee> mdke: heh, true.  it's almost 1am here
<bddebian> So what the heck do with do with a package that looks like it has been completely maintained seperately in Ubuntu?
<tseng> bddebian: talk to the person in ubuntu who ddi that?
<tseng> and find out why.
<bddebian> tseng: Several people have touched it.  Riddell, janimo, and others
<zul> who was the last one?
<bddebian> Someone I have never heard of: Daniele Favara
<tseng> maybe thye packaged it first for ubuntu, and debian came later
<tseng> like happened with Beagle
<tseng> I have since reconciled these changes
<bddebian> I would have thought so too but every release in ubuntu seems to be an ubuntu one
<tseng> only persons who know are in that changelog
<Riddell> bddebian: what's the package?
<bddebian> Riddell: ivman :-)
<bddebian> Looks like it was kubuntu, now xubuntu
<Riddell> bddebian: that was used in the first kubuntu, then kde didn't need it any more but it get used by xubuntu
<Riddell> Gloubiboulga: do you know if xubuntu still uses ivman?
<Gloubiboulga> Riddell, it doesn't
<bddebian> Gloubiboulga: So you think we can just sync from Debian?
<Gloubiboulga> bddebian, I'll look at this
<Gloubiboulga> but I think that it can be synced
<bddebian> Gloubiboulga: Well I can test the package to see if it can build
<Gloubiboulga> bddebian, actually I've already tested the build a few days ago nad it FTBFSed, but it should be fixed with the last debian package
<bddebian> Oh, hmm
* bddebian just crawls back to his hole
<wasabi_> I guess swapd isn't really maintained actively anymore.
<iwj> Can anyone here tell me this, in pitti's absence: if I upload to hoary-security, I trust someone will get a chance to review and perhaps ditch my upload, if they feel like it ?
<pitti> iwj: not ditch, but I can decide to not upload it
<pitti> iwj: s/upload/publish/
<iwj> Right.
<pitti> iwj: so if you do another upload with a higher version number, all will be fine
<iwj> Since you're here, see my comments in msg.
<Spads> mdke: ping
<LaserJock> iwj: have a sec to discuss developer's reference?
<iwj> LaserJock: Sure, but it'll have to be very quick.
<iwj> I have to go for dinner within a few minutes ...
<Petaris> ajmitch: ping
<Petaris> ajmitch: Have a minute to talk about AD integration?
<Hobbsee> Petaris: wrong time of night, i expect
<Petaris> Hobbsee: darn, your right
<Petaris> I forgot that its insanly early there
<Hobbsee> :P
* Hobbsee is in that timezone.
<Hobbsee> well, 2 hours behind
<Petaris> Is there anyone else working on the AD integration that you know of?
<mvo> Kamion: can you please promote libgksu2 to main?
<Hobbsee> Petaris: no idea
<Petaris> Hobbsee: bummer
<Petaris> maybe ogra knows
<ogra> nope ... only ajmitch is working on it afaik...
<Petaris> :/
<mdke> Spads: pong
<Spads> oh hey, mdke 
<mdke> howdy
<mdke> doc-commits seems to be catching up, thanks!
<Spads> well
<Spads> I have bad news for you
<mdke> ah
<Spads> those are being manually run by us to test things
<mdke> fine, fine.
<Spads> mdke: so i'd like it if you could make a test commit
<mdke> hang on
<Spads> just make a whitespace change or something
<mdke> Spads: right, done
<Spads> thanks
* Spads goes forraging
<Spads> https://lists.ubuntu.com/archives/ubuntu-doc-commits/2006-July/002700.html <-- is this it?
<mdke> Spads: yep :)
<Spads> marvelous
<mdke> Spads: thanks! And nice to meet you, virtually speaking
<Spads> mdke: the pleasure is mine!
<Spads> happy to be of service
<Spads> mdke: do you want me to run the missing commits so that they appear in the list?
<mdke> Spads: if it's easy to do so, that would be great. Otherwise, don't worry
<Spads> yeah, it's pretty easy
<Spads> hangon
<linuxboy> highvoltage
<highvoltage> :)
<Vhata> why has Ubuntu (or did it come from Debian?) filled up /etc/skel/.bashrc with so much cruft?  Surely the skeleton files should be kept to a bare minimum so that sysadmins can override them from /etc/{profile,bash.bashrc}, and then ricer users can override *those* settings in their own files if they want?
<Vhata> PS1, for example, shouldn't be set in there
<crimsun> that's irrelevant in Edgy, since bash is no longer the system shell.
<Vhata> I'm more questioning the policy, I suppose
<mjg59> Because applications should have sensible defaults
<Vhata> and those defaults should be set system wide in /etc/whateverrc, not per-user in ~/.whateverrc
<mjg59> I guess you could argue they should be in /etc/profile or whatever instead, but then upgrades would change behaviour for users and scripts may break
<mjg59> Bash should just use gconf for settings. Then the world would be better.
<Vhata> that's true.  But surely pushing the behaviour to the edge (i.e. per-user) isn't a good way to solve that?
<Vhata> heh
<mjg59> Making it per-user means that the experience for any one user is consistent, which is arguably the lesser of two evils
<mjg59> Traditional unix config doesn't really deal with this sort of situation terribly well
<Vhata> *nod*
<Keybuk> crimsun: umm, bash is still the default user shell
<crimsun> Keybuk: right, but I don't think that's much of an issue for users, no?
<Keybuk> crimsun: everything Vhata said only affects users
<crimsun> ok, I concede that
<Keybuk> so, question time
<Keybuk> does anybody here have a Broadcom wireless card and uses the bcm43xx driver?
<slomo> Keybuk: i have one
<Keybuk> slomo: do you use it with ifup or network manager?
<Keybuk> do you find that it doesn't load its firmware until it's ifconfig'd up?
<slomo> yes, that's normal for the driver
<Keybuk> ie. iwlist scan won't work
<Keybuk> *nods*
<Keybuk> right
<slomo> i use it with ifup btw... n-m never worked good for me
<geser> Keybuk: I've prepared a patch for update-rc.d from file-rc. It's bug 53894. Can you give it a look?
<Ubugtu> Malone bug 53894 in file-rc "add support for multiuser in update-rc.d" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/53894
<Keybuk> geser: yup, seems reasonable to me
<Keybuk> did you also patch file-rc to support usplash?
<geser> not yet
<bluefoxicy> Keybuk:  I've noticed weirdness with wireless drivers like that a lot... re http://rafb.net/paste/results/AhgL3X53.html for a linksys WUSB54GC, the machine immediately recognizes it's a wireless NIC but doesn't really know how to operate it.
<bigcx2> hey all
<bigcx2> i have a question about kernel-patch packages in general
<bigcx2> is the running kernel patched by default, on a reboot, or does it have to be manually done?
<Petaris> ajmitch: ping
<tseng> the running kernel is certainly not patched
<Petaris> ajmitch: Have a minute to discuss AD integration?
<bigcx2> alright
<bigcx2> what about the other two tseng
<tseng> what other two?
<tseng> patches are not magic, they apply to a directory full of source code
<bigcx2> does it get patched on a reboot? or does it have to be done manually after package installation
<tseng> you build the patched code and finally run it
<tseng> in the case of the kernel that means booting it
<tseng> this is one of those times when the addage applies
<tseng> "if you don't know what you are doing, you are better off not doing it"
<bigcx2> right, but my question is in terms of packaging
<bigcx2> so
<tseng> the package installs patches to /usr/src or something like this
<bigcx2> for example i install kernel-patch-uml
<bigcx2> correct
<tseng> it doesnt do anything with them.
<tseng> thats up to you
<bigcx2> ok, whats the proper way to go about patching it once its installed
<bigcx2> theres no docs in /usr/share/doc
<tseng> as I said before, if you dont know how to use patch or build a kernel, you are probably going to end up in a bad place
<tseng> if you really want to continue you can read up on man patch
<bigcx2> tseng: i'm doing this on a virtual machine to learn....
<tseng> also look at kernel-package
<bigcx2> look, that has nothing to do with patching in the context of which i'm talking about
<bigcx2> all i want to know is how to enable a patch already packaged under ubuntu
<bddebian> heh
<pygi> rraphink, hey hey
<rraphink> hi pygi
<lucas> who should I bug for a mailing list creation ?
<tseng> jdub
<elmo> no
<pygi> sivang, poke
<elmo> mail mailman@lists.ubuntu.com, not jdub
<bluefoxicy> So you guys read this right  http://lwn.net/Articles/192214/  (yes this is a dumb question)
<tseng> bluefoxicy: I might have read something about if i had any idea what that page is
<lucas> thx
<bluefoxicy> tseng: uh, it's a LWN article about how slow and inefficient crap in userspace is, i.e. hal opening several thousand files, gnome-cups-icon polling cups for new printers multiple times a second, etc..
<tseng> wow, top story
<tseng> strace at 11
<bddebian> hehe
<crimsun> bluefoxicy: (it's subscriber-only presently)
<bluefoxicy> ah
<bluefoxicy> crud.  crimsun:  You're not a Debian developer as well?
<crimsun> bluefoxicy: no.
<crimsun> (I'm an LWN subscriber, so I've read it.)
<bluefoxicy> ok (all those guys have a group account, donated by HP)
<Keybuk> tseng: yeah, it's a nice talk
<Keybuk> it's all irrelevant if you use initng of course, which is TONS FASTER!
<doko> pitti, I'll kill you!
<doko> pkgstriptranslations: The following PO/POT files are empty. This is known to
<doko> cause trouble in the translation importer and generally indicates a package
<doko> bug:
<doko> [...] 
<doko> dh_builddeb: command returned error code 256
<zul> hey
#ubuntu-devel 2006-07-25
<jono> hey
<thiago_>  hi... how can i install all include files, sources, and libs, for develop, like in slackware...???
<cheatersrealm> any ubuntu-gnome developers on? I have a patch that I would like to see rolled into ubuntu on gnome-keyring.  ( http://bugzilla.gnome.org/attachment.cgi?id=66495&action=view )
<gnomefreak> thiago_: please ask that in #ubuntu  this is not a support channel
<pygi> thiago_, all?? #ubunt
<pygi> #ubuntu*
<pygi> cheatersrealm, file a bug and attach patch pls?
<thiago_> ok, thanks :D
<thiago_> sorry too
<cheatersrealm> pygi: I'm having trouble patching against ubuntu (I'm new to it) and the patch linked there (I think) is for another version of gnome
<cheatersrealm> pygi: file a bug and link?
<pygi> cheatersrealm, link to bug report where that patch is attached?
<cheatersrealm> k
<pygi> cheatersrealm, no,no, tell me the link so i could see for which version is it
<cheatersrealm> pygi: http://bugzilla.gnome.org/attachment.cgi?id=66495&action=view
<pygi> cheatersrealm, well, that's the patch :P But the bug report where that patch was attached? :)
<cheatersrealm> ahh
<cheatersrealm> sorry
<cheatersrealm> http://bugzilla.gnome.org/show_bug.cgi?id=331003
<Ubugtu> Gnome bug 331003 in ask dialog "Don't bring up multiple authentication windows for same thing" [Normal,Unconfirmed]  
<cheatersrealm> I was pasting that but I just copied and pasted the patch to a wget so I lost it
<cheatersrealm> :)
<pygi> cheatersrealm, hm, seems that patch would need some modification to work for an applicationa sking for the same resource multiple times
<cheatersrealm> pygi: right, but it would solve my problem
<cheatersrealm> it asks for the master password multiple times
<cheatersrealm> it's on loading up rhythmbox for me
<cheatersrealm> because my library is hosted from a smb share mounted in nautilus
<pygi> also, there is no version of gnome which this patch is applied to
* pygi looks the patch
<pygi> hm, right
<pygi> open the patch on malone, point to patch and see what happens
<pygi> I can't be sure for which version this is
<pygi> altought probably 2.14 as Suse is running that (I think so at least) and they ship this patch
<cheatersrealm> so I'm seeing a similar bug relating to network-manager in the ubuntu bugs  https://launchpad.net/distros/ubuntu/+source/network-manager/+bug/31286
<Ubugtu> Malone bug 31286 in network-manager "Displays repeated keyring dialogs on resume from suspend" [Unknown,Fix released]  
<cheatersrealm> pygi: any ideas on what I should do?
<pygi> cheatersrealm, aha, report a bug :)
<cheatersrealm> pygi: start a new bug?
<pygi> yup
<cheatersrealm> ok
<cheatersrealm> should I also link to the gnome patch as well?
<cheatersrealm> and the 'similar' problem I found in ubuntu's bug repo?
* pygi nods, and to the gnome bug report
<cheatersrealm> ok
<cheatersrealm> I'm searching for more gnome keyring bugs, but if I can't find anything better, that's what I'll do
<ichi> hey, anyone a dev who can help me to try to catagorize this bug? I'm not sure where it belongs in a bugtracker.
<ichi> There is a bug which I'm not sure where it goes under. The bug is, if my first set of bootsectors aren't correct, they need to be zeroed out. When I zero out the drive for a few seconds, then install grub it works. If I don't zero out, I see "GRUB" on boot and nothign happens. installs in the future work fine after its been zeroed out.  So, is this a bug in Grub, or is it marked as a hard drive error? Could Grub be fixed, or co
<ichi> uld tools be requested for inclusion to zero out drive?
<ichi> The install works fine if I install lilo, however I know grub works differently. Or, this could be a grub-install bug.
<ichi> so, what do I file it under in the tracker?
<LaserJock> go for grub then, I guess. it can be moved latter if needed
<ichi> LaserJock: yeah, but is it a grub bug? Should be be detecting if the first boot blocks are screwed?
<cheatersrealm> sigh, launchpad is being slow to e-mail me my registration url
<LaserJock> ichi: I have no idea, but if you put it on Launchpad somebody more knowledgeble than me can take a look
<ichi> mmm, true.
<bluefoxicy> Q:  Should Ubuntu look at mounting /proc nosuid?
<bluefoxicy> (yes this is probably dumb now since the vuln in question has been fixed...)
<_tsume> bluefoxicy: :)
<bluefoxicy> _tsume:  what are you smiling about?  I'm just reading stuff from a few days ago I haven't been paying attention to
<_tsume> bluefoxicy: oh.
<bluefoxicy> (more LWN stuff, I'm subscribed so I might as well use it huh)
<Kamion> bluefoxicy: that's been asked with respect to the Debian installer too; I think it would make sense to do it, but I'm in two minds about whether the change belongs in the installer (writing to /etc/fstab) or in the init script that mounts /proc
<bluefoxicy> Kamion:  I would say in fstab would make most sense.
<bluefoxicy> That's traditionally where such things go.
<elmo> the kernel already marks proc as nosuid and nodev
<bluefoxicy> it's also somewhat easy to update that line if it's the default line using cat, grep, awk, and sed
<elmo> and mounting proc nosuid in fstab doesn't actually work
<bluefoxicy> proc on /proc type proc (rw,nosuid)
<bluefoxicy> elmo:  re doesn't have an effect or breaks mount?
<elmo> doesn't survive reboots on dapper
<Kamion> bluefoxicy: but the problem with fstab is that it doesn't affect upgrades
<Kamion> so I'm sort of inclined towards the two-pronged approach - just do both
<Kamion> elmo: oh
<Kamion> hmm, interestinng
<bluefoxicy> Kamion:  I was thinking some upgrade package would fix the line but *shrug*
<Kamion> I suspect some init script does mount -t proc proc /proc or equivalent
<Kamion> rewriting /etc/fstab on upgrade seems like a bad idea, although of course we're having to do that anyway for UUIDs
<elmo> and like I said, I'm 99% sure it's moot, part of the fix in the kernel was to force proc nosuid and nodev
<Kamion> but I'd like to do as little as possible to it
<bluefoxicy> yeah it is.
<bluefoxicy> like I said, vuln in question has been fixed anyway.
<bluefoxicy> God I'm bored.
<LaserJock> go fix something then
<bluefoxicy> nothing's breaking on my system
<LaserJock> there are a ton of bugs on LP that need to be triaged
<elmo> does someone want to monkey/cowboy a server seed change for me?
<elmo> err, nm
<bddebian> Howdy
<bluefoxicy> hi
<bluefoxicy> Keybuk: Was that you working on a new init?
<bddebian> Hello bluefoxicy
<Keybuk> bluefoxicy: yes
<bluefoxicy> Keybuk:  Any chance there's a good, clean way to get ltrace/strace run on things during boot, or any other generic watch-this-process tool?  Or is there already a quick and dirty way to profile system boot?
<Keybuk> what kind of profiling are you trying to do ?
<bluefoxicy> It'd be nice to push a few buttons, set a few config options, and have the next boot spit out profiled output :>
<bluefoxicy> Keybuk: http://lwn.net/Articles/192214/ if you have a LWN subscription.
<bluefoxicy> I'm looking at repeating that guy's tests in the future, without going in and modifying the kernel or whatever.
<Keybuk> I'd change /etc/inittab so that
<Keybuk> si::sysinit:/etc/init.d/rcS
<Keybuk> becomes strace /stc/init.d/rcS
<Keybuk> etc.
<Keybuk> maybe some thin shell script to log the output somewhere (you'll need a writable space)
<bluefoxicy> ah.  Yeah /tmp is often writable enough, or /var/tmp
<Keybuk> neither is writable that early
<Keybuk> you may need to use /dev
<bluefoxicy> nods.  Now the question is how do I order and cleanly report it.  *reads man pages*
<bddebian> Ack, another sync...
* bddebian wonders about all the xserver-* manual merge packages in Universe
<crimsun> they're not really merges.
<bddebian> They aren't?
<crimsun> no, they're syncs with Debian Sid but retaining our version
<bddebian> So I shouldn't be requesting syncs from Debian?
<crimsun> for...?
<bddebian> Things like trigger
<crimsun> that's fine
<crimsun> why?
<bddebian> Trying to clean up this list: http://merges.ubuntu.com/universe-manual.html
<bddebian> Am I wasting my time as always?
<crimsun> sync looks fine unless the icon wasn't carried over
<bddebian> It was
<crimsun> then it's fine.
<crimsun> -> -motu next time ;-)
<bddebian> OK
<bddebian> Heya Hobbsee
<Hobbsee> hi bddebian 
<tritium> hey folks
<bddebian> Heya tritium
<zul> hey Hobbsee 
<Hobbsee> hi zul, ti
<Hobbsee> hi zul, tritium 
<tritium> hi Hobbsee, bddebian 
<bluefoxicy> wow that's a pain in the ass.
* bddebian holds back his comment to keep from breaking CoC twice in one day
<bluefoxicy> ..... should combining -c, -ff, and -o (specifically) with strace produce null output
<bluefoxicy> -c -ff has output; -ff -o has output; -c -o has output; -c -ff -o creates an empty file.
<_tsume> !op
<_tsume> no op list?
<_tsume> drat :)
<bluefoxicy> yeah I'm gonna file two bugs on this, the first being that strace gives null output when -c -ff -o are combined; the second being that strace -ff -o filename produces a file named filename for whatever process it first traces and filename.pid for all children (the man page says that EACH PROCESS TRACED gets filename.pid)
<bluefoxicy> ARGH *smacks copy/paste for being broken*
<hub> hi
<hub> on #ubuntu-motu I have been told that we no longer ship *.la files in -dev pacakges
<hub> is that true?
<hub> libgk2.0 seems to still have them in the -dev package
<fabbione> morning
<bddebian> Hello fabbione
<Hobbsee> hi fabbione!
<joejaxx> is ther anyone here willing to donate some of their time and talking to me in pm about livecd generation from seeds?
<joejaxx> hmm maybe not then
<LaserJock> joejaxx: it's not a very active time of day for this channel
<joejaxx> yeah i guess not
<pitti> Good morning
<Hobbsee> hi pitti!
<ajmitch> morning pitti 
<desrt> word up, all
<ajmitch> good day, desrt 
<desrt> my feet hurt.
<desrt> but they are happy
* desrt just went on an impressively long hike with a friend
<desrt> including some light rock climbing
<linuxboy_> desrt: sorry, but having sore feet is a support issue. Please ask about it in #ubuntu
<linuxboy_> ;)
<Hobbsee> hehe
<linuxboy> ^^^ that was Vhata's joke
<Vhata> (which I discreetly decided not to make)
<desrt> linuxboy; glare.
<fabbione> is gdb known to be broken in edgy?
<fabbione> Starting program: /usr/bin/gdb 
<fabbione> Failed to read a valid object file image from memory.
<pitti> fabbione: it worked quite well for me recently
<fabbione> pitti: this is as this morning upgrade...
<fabbione> pitti: x86
<pitti> fabbione: ok, I try again after today's dist-upgrade
<fabbione> pitti: thanks
<pitti> fabbione: (however, today's upgrade doesn't bring anything that's related to gdb)
<fabbione> pitti: i know. i didn't point my finger at gdb as root caude
<fabbione> cause
<fabbione> but as symptomps
<fabbione> bah that
* fabbione can't spell
<pitti> fabbione: ah, new libglib2.0 -- iz gtk bug, for sure
<fabbione> LOL
<pitti> elmo: good morning
<bluefoxicy> hmm.  What the hell is spawning 1 process every 2 seconds
<bluefoxicy> the process being spawned is sh... what's spawning it...
<fabbione> quick C question
<fabbione> assuming i have a string that ends in /
<fabbione> if that's true i want to strip /
<fabbione> how can i do that easily?
<fabbione>         if (optind < argc && argv[optind] )
<fabbione>                 strncpy(mo->dir, argv[optind] , PATH_MAX);
<fabbione> mo->dir is a mount point
<pitti> l = strlen(s); if (s[l]  == '/') { s[l]  = 0; }    ?
<fabbione> but i want to make sure that it doesn't end in /
<Lathiat> just cut the last character off set it to null?
<Lathiat> what pitti said :)
<fabbione> perfect :)
<fabbione> thanks
<Lathiat> altho if your doing a strncpy anyway
<Lathiat> you could always just copy 1 char short of strlen()
<pitti> Lathiat: that would miss the test
<fabbione> Lathiat: that will break
<Lathiat> oh sorry i read "assuming.." and assumed the string was already known to have a /
<Lathiat> didnt properly read the next line
<Lathiat> :)
<pitti> fabbione: gdb is still working properly after today's dist-upgrade; however, I'll check again after reboot (new kernel and such)
<pitti> WTF???
<pitti> now /etc/fstab has 10 copies of my environment
* pitti files a grave bug
<Hobbsee> heh
<Hobbsee> how many was it supposed to have, pitti?
<crimsun> /var/lib/dpkg/info/  has a suspicious kernel-image-2.6.8-11-amd64-generic.postinst
<pitti> zzzzzzzzzero
<crimsun> err, sorry, wrong computer
<Hobbsee> pitti: heh...great
<crimsun> right, it's libvolumeid0.postinst
<fabbione> pitti: you win!
<pitti> http://librarian.launchpad.net/3547983/fstab <= *shudder*
<imbrandon> pitti: ouch
<Hobbsee> holy sugar.
<Hobbsee> grumble.  where's keybuk when you need him?
<Hobbsee> ah, it's not late enough in the day.
<bluefoxicy> Hobbsee:  I still think you're strange for being up before noon :P
<Lathiat> pitti: sweet
* bluefoxicy slides Hobbsee a big cup of coffee and heads off to bed himself z.z
<Hobbsee> bluefoxicy: heh.  it's currently 4pm, anyway
<Lathiat> looks like some copies of 'mount' too?
<pitti> Lathiat: 'mount'?
<bluefoxicy> Hobbsee:  oh right.
<Lathiat> oh, dchroot, never
<pitti> Lathiat: I only removed the environment blocks, now it's ok
<Lathiat> just multiple copies of the output
<pitti> Lathiat: well, I hope that'll still boot with the uuid stuff :)
<pitti> Lathiat: no, I have 3 chroots
<Lathiat> oh i see
<Lathiat> before each chroot
<Hobbsee> pitti: machines that boot are so overrated, really.
<Lathiat> is the environment
<Lathiat> when theres so much text its hard to see the dchroot difference
<Lathiat> :)
<pitti> Hobbsee: I boot it every day, so I value it :)
<Hobbsee> pitti: heh.  how boring :P  why not just leave it on, anyway?
<Lathiat> i had a machine upgraded from breezy to dapper that didnt see a reboot for about 2 months ;p
<pitti> Hobbsee: because it would just waste energy for no good reason
<bluefoxicy> pitti:  btw, for problem reports, you should report SIGILL as well, since you can get that if something screws up the instruction pointer and puts you halfway into an instruction in executable memory
<bluefoxicy> (thanks pipacs for that insight)
<pitti> bluefoxicy: I do
<Hobbsee> pitti: that's a point
<pitti> bluefoxicy: in fact, everytime the kernel would dump core, it calls my script
<bluefoxicy> cool.
* bluefoxicy saw a short list on the spec and was just making sure ;)
<pitti> bluefoxicy: right, the spec is pretty outdated wrt to that; thanks for the reminder
* bluefoxicy is still trying to figure out how to categorize problem reports as potential vulnerabilities
<pitti> fabbione: hm, after this dist-upgrade I get strange messages from /bin/pwd; something is corrupted here (my gdb works, though)
<fabbione> pitti: hmmmm it smells like FS corruption to me
<fabbione> none of my dist upgrades are borked that way
<pitti> fabbione: no, chdir'ing out and back into the dir where I was fixed it
<pitti> fabbione: it seems it lost track of inodes in the current dir, or something
<pitti> anyway, I'll check after a reboot
<bluefoxicy> speaking of that, glibc should detect double-free():  http://rafb.net/paste/results/JsrGSo30.html
<bluefoxicy> which is another hack-glibc-to-trigger-problem-reports situation
<bluefoxicy> (it's also got some heap corruption detection so it may scream on malloc() if the allocation chains are damaged)
<fabbione> pitti: 
<fabbione>         if (modir[l]  == '/') {
<fabbione> this one seems to never match
<fabbione> but i did check strlen and the string and it should
<fabbione> but then
<fabbione>         printf("MODIR: %s %s, mo-dir: %s\n", modir[4] , modir[5] , mo->dir);
<Vhata> fabbione: l-1
<fabbione> util.c:168: warning: format '%s' expects type 'char *', but argument 2 has type 'int'
<Vhata> the first character is [0] 
<fabbione> oh feh
<fabbione> right
<fabbione> thanks
<Vhata> ell minus one
<pitti> fabbione: fabbione you use strncpy(), right? do you make sure that the string is properly 0-terminated?
<pitti> fabbione: argh, indeed, l-1; my bad
<fabbione> pitti: yes i do use strncpy for that too
<dholbach> good morning
<highvoltage> good morning, dholbach 
<dholbach> hey highvoltage
<pitti> moin dholbach 
<dholbach> hey Martin!
<sivang> morning
<Vhata> hi
<Hobbsee> hi sivang!
<sivang> hey Hobbsee :)
<Vhata> is it morning?  what's average([ member.getTimezone() for member in channels["#ubuntu-devel"] .getMembers() ] )   ?
<Hobbsee> Vhata: 42.
<Vhata> morning, then.
<pygi> sivang, yay :)
<sivang> pygi: hey dude
<pygi> sivang, hey, glad to hear from you :)
<pygi> I already started to worry :P
<sivang> pygi: check your email :)
<pitti> hi sivang 
<pygi> sivang, I already did :)
* sivang hugs pitti 
* pitti hugs sivang back
<pygi> sivang, we've got some very nice ideas for libburn :)
<sivang> pygi: cool, do you have a wiki or some sort of shared editing space so folks can read about it ?
<pygi> sivang, not yet really, I got the trac thingy, I lack domain and then all will be ready
<pygi> The trac have built-in wiki, so ... :)
<ajmitch> are people working on code yet?
<pygi> ajmitch, which code? :P
<ajmitch> you mentioned libburn
<pygi> currently, we are evaluating code, getting bugs, bla,bla :)
<ajmitch> so that's a no :)
<pygi> :P
<dholbach> ogra, infinity, pitti: the 'select text from the terminal' but should be fixed with the new version, enjoy :)
<infinity> dholbach: Is htis a bug I reported months ago, or one I never reported at all, cause I don't rememebr it. :)
<infinity> Also, lag is horrible for typos.  Ugh.
<dholbach> infinity: oh - a couple of people complained that they could not do selections bigger than one screen - I thought you complained about it too
<infinity> Oh, I might have.  I just got bitten by that (repeatedly) last night.
<infinity> Yay for fixing it.
<dholbach> new vte should make you happy
<infinity> You are my hero, as always.
<infinity> Well, mvo is my hero, but he hasn't done anything for me lately, so you're the new mvo.
<dholbach> gracias - but your hero should be behdad :-)
<ajmitch> evening infinity 
* mvo hugs infinity
<pitti> dholbach: which particular one? the small size limit or the breakage with non-ASCII chars?
<pitti> hey infinity 
<dholbach> pitti: selections bigger than one screen
<pitti> ah, that one. nice
<infinity> Hey pitti, mvo.
<dholbach>  /v<tab>/c<tab>  is not  /var/cache  any more *whine* - it will take me ages to get used to that
<Vhata> what is it?
<Lathiat> use zsh and make it complete with the first match (with 'ca' likely to be the first match) :)
<infinity> Why did we invent another top-level in /var, instead of using something like /var/cache/crashdata or something?
<dholbach> infinity: good question
* infinity stares at mvo, since /var/crash claims to be owned by update-notifier.
<pitti> infinity: it's FHS
<infinity> pitti: Oh, FHS defines /var/crash?  Whack.
* mvo points infinity to the AutomatedProblemReporting spec
<infinity> Ahh, so it does.  I take it back, then.
<Mithrandir> they should rather go to /var/cache/crash or something, IMO.
<pitti> I don't mind the particular path, I just thought it would be nice to follow FHS
<hungerW> Why is there SHELL='/bin/sash' in fstab now?!
<hungerW> Or TERM='xterm'?
<Lathiat> hungerW: its a bug
<pitti> hungerW: bug 53991
<Ubugtu> Malone bug 53991 in udev "uuid conversion writes environment into fstab" [Critical,Unconfirmed]  http://launchpad.net/bugs/53991
<hungerW> Ah, thanks. I was seriously confused:-)
<Lathiat> hrm this UUID conversion stuff
<pitti> hungerW: me too
<hungerW> Should it use UUID for LVM volumes, too?
<hungerW> Is the UUID generated while formating? I am asking since I format /tmp on each reboot...
<Lathiat> why dont you just use tmpfs for /tmp ?
<hungerW> Lathiat: Why should I?
<hungerW> Lathiat: I have 10G tmp, I doubt that I can stuff that into ram.
<Lathiat> heh
<Lathiat> what on earth do you do in /tmp? :)
<Lathiat> plus it can swap out :)
<hungerW> Lathiat: Store DVD images of linux distros that I did not manage to burn yet, etc.
<Lathiat> and so the power spontaneously goes and you have to redownload it? :)
<pitti> Lathiat: I often use /tmp for temporary stuff which requires lots of disk space
<hungerW> Lathiat: Well, basically my /tmp is encrypted with a random key. So I have to format it on reboots to make it useable.
<pitti> Lathiat: in order to avoid getting cruft in my backups (and DoSing my network connection)
* Lathiat nods at pitti
<hungerW> pitti: Same reasoning here:-)
<pitti> Lathiat: something like 'check if our current kernel or OpenOffice has a patch
* hungerW changes his fstab back to non-UUID form.
<hungerW> I do not have any non-LVM volumes in fstab, so I should not need that stuff.
<Lathiat> does it hurt?
<hungerW> Lathiat: I think it will.
<Lathiat> howso?
<hungerW> Lathiat: I use lots of encrypted partitions, so I doubt that the UUID will work with that.
<Lathiat> then you should file a bug? :)
<fabbione> hunger: no it won't change
<hungerW> Lathiat: Some of those are encrypted with random keys and reformated on reboot. I am very sceptical that this will work with UUIDs.
<fabbione> oh well reformat yeah
<fabbione> that will make problems
<fabbione> hungerW: file bugs
<Lathiat> its hard to know what your customly reformatting tho
<hungerW> plus it is not needed since LVM does make sure that the drives "match".
<Lathiat> but i mean thats a pretty side case
<Kagou> hi
<hungerW> LVM uses its own UUID stuff to find its PVs.
<fabbione> hungerW: there is a difference between volume id and fs id
<fabbione> but yes, it is still pretty pointless with LVM
<hungerW> fabbione: What is the UUID anyway? A volume ID or a FS ID?
<fabbione> you have uuid for both
<fabbione> but the one in fstab is clearly the fs id
<fabbione> lvm uses volume id to rebuild the vg
<hungerW> fabbione: Thanks.
<hungerW> fabbione: Yeap. But it does make sure that the LVs show up with a well defined name... which is pretty similar to the by-uuid stuff udev does.
<fabbione> hungerW: yes exactly, but the UUID is nothing more than a symlink that is resolved at mount time. so it doesn't change anything for you
<fabbione> there is no performance hit or stuff like that
<hungerW> fabbione: agreed.
<hungerW> fabbione: It is just that /dev/mapper/vg0-ubuntu_usr is way better to recognise as my ubuntu /usr than UUID={someNumbersAndLetters}.
<fabbione> hungerW: i don't disagree but you are not taking into account a few things
<fabbione> this is just an upgrade path and you can just revert the change in fstab (it's all commented)
<fabbione> when you start doing manual lvm stuff, you don't use UUID by default
<fabbione> you do it.. well manually
<fabbione> and the conversion script did run once...
<fabbione> it won't or shouldn't run again
<hungerW> fabbione: You are right, I will still write a bugreport about this.
<hungerW> fabbione: Especially since no fstab.dpkg-old is left around:-(
<fabbione> hunger: right, there are still the comments inline tho (when it works.. hi pitti!)
<hungerW> fabbione: Yeap. It was not hard to get back to the original state:-)
<ogra> dholbach, yippie, thanks
<Kamion> joejaxx: we don't generate the live filesystems directly from the seeds - we generate metapackages from the seeds (see the ubuntu-meta source package) and build live filesystems basically by just installing the appropriate metapackages in a chroot and calling mksquashfs
<ogra> YAAY .... upstream included nearly all of our gnome-screensaver patches ... !
* ogra dances
<ajmitch> excellent
<fabbione> not bad
<ajmitch> less work for you in the future :)
<ogra> yup
<pygi> ogra, nice nice :)
<fabbione> pitti: https://www.redhat.com/archives/cluster-devel/2006-July/msg00212.html
<fabbione> pitti: ^^ 2 days of debugging to get tehre
<fabbione> and reboot
<fabbione> +s
<fabbione> i don't think i did EVER rebooted a machine so often
<infinity> Okay, WTF?  Why is my fstab sprinkled with random junk from my environment?
<fabbione> bug 53991
<Ubugtu> Malone bug 53991 in udev "uuid conversion writes environment into fstab" [Critical,Unconfirmed]  http://launchpad.net/bugs/53991
<infinity> Ahh, special.
<fabbione> infinity: aren't we all?
<fabbione> special..
<infinity> Somehow I doubt any effort will be made to clean that up, so I guess I'll just fix it by hand.
<pitti> fabbione: ah, nice
<fabbione> now... time to add gfs/gfs2 support to mount to call the proper helper
<fabbione> or mount /dev/foo /mnt will be.. disastrous
* Kamion is looking into that udev bug now
<Kamion> it's due to set $LINE with accidentally-empty $LINE
<Kamion> right, udev fix uploaded
<shawarma> Keybuk not around today?
<fabbione> shawarma: he went to sleep around our 3am
<mvo> Kamion: can I nag you with the promotion of libgksu2? it blocks the build of the new gksu
<shawarma> fabbione: So did I. :-)
<fabbione> shawarma: and i woke up at 4am...
<fabbione> did you? :P
<shawarma> fabbione: Not entirely. Has the baby arrived?
* pitti waves to slomo
<slomo> hi pitti :)
<shawarma> fabbione: Or are you just the kind of person who gets up at 4 voluntarily?
<mvo> hello slomo
<Hobbsee> shawarma: the heat :P
<slomo> hi mvo 
<shawarma> Hobbsee: Oh, right.
<Kamion> mvo: does it not need a main inclusion report?
<shawarma> ARGH! Totally lost track of time. gotta run!
<fabbione> shawarma: no baby yet... i have to wake because of the heat :)
<Kamion> pitti: ^-- ?
<sivang> hey slomo 
<mvo> Kamion: no, I talked to pitti, its just a renamed libgksu1.2 with a changed api
<pitti> Kamion: it's merely a new version of libgksu (renamed source package)
<Kamion> oh ok
<Kamion> mvo: promoted
<mvo> Kamion: thanks!
<sivang> pygi: http://bazaar.launchpad.net/~ubuntu-dev/hubackup/ubuntu
<sivang> pygi: ^^ use this instead.
<sivang> pygi: that's a fresh branch, without all the ~300 revisions
<sivang> pygi: can you branch from there ?
<seb128> does somebody knows about "cdrecord needs to be runned with sudo to blank a CD"? is that a linux issue?
<Kamion> sivang: (not that it's any of my business, but why create a fresh branch? deliberately killing off history is usually bad)
<stub> Launchpad will be going down in 15 minutes for its regular code update. Estimated downtime will be 10 mins.
<sivang> Kamion: I have the history in another branch backed up in 3 different locations, I did that to split up load when branching, pushing an dpulling (it's still much faster that way, even from supermirror)
<sivang> Kamion: I realize it's a bad thing to do, but also the long revision is due to me commiting between very small changes, to be able to go back when I Started development
<Kamion> sivang: that means you will be unable to merge from the branch on the supermirror to your private branch, surely
<sivang> Kamion: I feel this history is not needed anymore for further development, and if we need it we can always poke the other branches, what do you think?
<lifeless> sivang: many small changes is good, why do you say its a problem ?
<ogra> seb128, no, that behavior was patched out long ago from the debian package ... if it does that, its a bug
<Kamion> I think it's crazy and wrong
<Kamion> and I think you'll regret it later
* sivang goes to change that ASAP :)
<Kamion> as will people trying to work out why changes were introduced
<sivang> lifeless, Kamion : it felt wrong, but it made bracnhing and pushing to supermirrors fast fast
<Kamion> bzr's performance will improve
<sivang> (I started with pushing the whole history, then gave up as it wanted to do it for several hours)
<lifeless> sivang: upgrade to knits
<lifeless> sivang: nothing should take hours with knits
<sivang> lifeless: okay, the branch was already in knits, let me retry and try work with you performance issues I encounter.
* sivang goes to retry
<pygi_> sivang, please post me branch again
<pygi_> I got dc/ed
<sivang> pygi_: use the other one, it's okay
<pygi> sivang, just post it pls :)
<seb128> ogra: what do you mean? that was an Ubuntu patch?
<sivang> pygi: http://mercury.linuxguru.net/~sivan/hubackup--main
<sivang> ogra: it's set suid or something to make it work no?
<pygi> that's old one :-/
<sivang> pygi: no that's okay, the ubuntu-dev one is wrong
<sivang> pygi: I need to fix it 
<pygi> sivang, ok, branching
<sivang> stub: LP going offline means supermirror as well ?
<ogra> seb128, it was a debian patch, short before warty ... that was when upstream abandoned linux 
<ogra> seb128, i'm pretty sure pitti knows more ...
<seb128> ogra: so that's likely to be due to the sync with Debian?
<seb128> the package didn't change to Debian for ages apparently
<ogra> i guess so ... probably they dropped the patch
<ogra> hmm
<pygi> sivang, do we want QT interface for edgy?
<pygi> or rather do we have time?
<sivang> pygi: if you're interested in working on it, you can start, following the new dsign ofcourse in the wiki page, if you can make it work as expcted and to good degree until September 7th , we might be able to put it in I think.
<pitti> I have to reboot, brb
<sivang> pygi: fallbaking to edgy+1 if it's not satisfactory until then
<pygi> sivang, right, but most of the current codebase will be in second plan if we are to implement our -ng stuff
<pygi> and if we're lucky, the cdrecord wrapper and dependency will also be dropped
<sivang> pygi: I can't think of -ng stuff at the moment, just to get something slicketr and friendlier as per the new design + notifications. That's enough for a release and a half so it seems. I also lost A week already, which makes things a bit tighter. 
<sivang> pygi: I think it'd be even better to concentrate efforts on getting in syn cwith the new spec, rather then working on QT version.
<pygi> sivang, hm,ok, agreed
<ogra> seb128, Thu May 20 15:35:52 2004 Joerg Schilling <joerg@schily.isdn.cs.tu-berlin.de>
<ogra>         * cdrecord.c 1.286
<ogra>           Bessere Kommentare gegen SuSE die cdrecord nicht als root laufen lasse
<ogra>  wollen
<ogra> seb128, seems it originaly was a suse patch 
<ogra> hmm
<ogra> seems i uploaded g-s-s at a bad time :/
<mdz> ogra: ?
<ogra> mdz, ?
<mdz> <ogra> hmm
<mdz>  seems i uploaded g-s-s at a bad time :/
<mdz> please explain
<ogra> yep, LP was in maintenance and i was wondering where my accepted mail wnet
<ogra> queue is processed now ... just got the mail
<janimo> infinity: hi, IIRC there were some explicit dependencies added on the CD build host to override some apt choices for xubuntu meta packages. Was libgoffice one of them?
<janimo> now the desktop CD has both libgoffice-0-3 and libgoffice-gtk-1-2 pulled in and I wonder if the latter is left from the dapper setup
<infinity> janimo:             LIST="$LIST ubuntu-base xterm libgoffice-gtk-1-2 xubuntu-desktop"
<infinity> janimo: So, "yes".
<janimo> infinity: thanks, could you change that to libgoffice-gtk-0-3 ?
<janimo> as the package got renamed/updated
<myki> Hi. AFAIK ubuntu uses udev instead of regular devfs. How is that sort out, there are just used ttys on dev instead of all pty[a-e] [0-f] , etc?
<Vhata> ain't nothing regular about devfs
<myki> Vhata: whatever, on debian it's default on etch.
<ogra> myki, devfs was dropped from the kernel ... i doubt debian can use it ...
<janimo> ogra: not until 2.6.18
<Kamion> myki: not any more it's not
<Kamion> pty* are handled by the /dev/pts filesystem
<Kamion> (and /dev/ptmx) - Unix98-style
<myki> ogra: I'm on 2.6.16-2 actually
<ogra> janimo, hmm, i thought i saw a changelog entry in a 2.6.17 
<ogra> or *16 even
* zul is on 2.6.16-1.686
<zul> *cough* xen *cough*
<Kamion> myki: it's definitely no longer the default on fresh installs. For upgrades, sure, you'd have to install the udev package to migrate to it.
<myki> Kamion: OK. I know, I'm already on udev. Any advice how do I remove about 600 tty and pty devices?
<Kamion> myki: don't
<myki> I'm using 12 ttys, I don't need 325
<Kamion> if udev is managing /dev, it'll do its thing from scratch every boot - don't go through removing stuff by hand
<myki> Kamion: I'm not that daft ;] 
<Kamion> a udev rule like KERNEL=="tty[a-z] [0-9] *", OPTIONS+="ignore_device" would suppress the creation of those devices
<Kamion> and similarly for pty
<Kamion> I don't really see the point of worrying about it though
<myki> Kamion: ls /dev takes 3 whole screens. I got used that on ubuntu it's cleaner
<ogra> easy to fix, use ubuntu on that machine ;)
<myki> ogra: debian netinstaller has that advantage, to me, that it installs just what I exactly want, instead of whole dummy package
<myki> ogra: and even on stable badger I had problems with packet dependencies (all from official repos)
<Kamion> myki: Ubuntu creates /dev/[pt] ty[a-z] [0-9a-f]  too
<myki> no can be
<Kamion> (er, so yeah, the rule above should be KERNEL=="[pt] ty[a-z] [0-9a-f] "
<Kamion> )
<Kamion> myki: how often do you type 'ls /dev', exactly? :-)
<ogra> ogra@edubuntu:~/packages/willowng-0.2$ ls /dev/tty*|wc -l
<ogra> 325
<ogra> ;)
<Vhata> Kamion: <something> /dev/<tab><tab> is not uncommon ;-)
<Kamion> Vhata: I don't know about you but I usually have a marginally clearer idea of what device I want than that, enough for the first character at least
<ogra> myki, ubuntu-minimal is not *that* big :)
<myki> Kamion: So I don't know what I did, but I had just ttys, I've been using actually. However, ignore rule works well.
<infinity> janimo Fix committed.
<janimo> infinity: thanks
<ogra> is there any ETA when the build logs will be available again ? 
<ogra> https://launchpad.net/distros/ubuntu/edgy/+builds gives me an oops
<rodarvus> ogra, maybe people in ##soyuz1.0 can help you with that?
<shawarma> Anything using python2.3 currently FTBFS. Is anyone working on that?
<ogra> well, its not urgent or something ... but i'll ask there, probably they are not aware
<doko> shawarma: we'll drop python2.3 soon
<shawarma> doko: Uargh... There's like a million packages depending on it, is there not?
<Kamion> shawarma: example?
<shawarma> doko: dak
<shawarma> Kamion: dak
<Kamion> shawarma: https://launchpad.net/distros/ubuntu/+source/dak/1.0-8ubuntu2 built fine
<ogra> ogra@edubuntu:~/packages$ apt-cache rdepends python2.3|grep -v python2.3|grep dak
<ogra> ogra@edubuntu:~/packages$ 
<ogra> and dak seems not to be in the rdepends
<Kamion> ogra: rdepends doesn't show build-deps
<shawarma> Does that show build-depends as well=?
<Kamion> Build-Depends: debhelper (>= 4.1.65), python2.3-dev (>= 2.3-1), [...] 
<ogra> Kamion, well, bu dh_python should have added the right deps
<shawarma> Kamion: Maybe it was built before all this python-central funny business was introduced?
<thom> doko: any chance you'll fix buildbot soon, btw?
<Kamion> ogra: *sigh* just go look at the build-deps
<ogra> Kamion, yes, i see
<Kamion> shawarma: it doesn't build-depend on python-central or python-support so it's probably just broken
<Kamion> shawarma: also there really shouldn't be a million packages build-depending on python2.3-dev directly any more
<shawarma> Kamion: Anything build-depending on python2.[34] -dev should also build-dep on python-central?
<Kamion> most of them should be using python-all-dev
<Kamion> shawarma: not that simple, see http://people.debian.org/~piman/python-policy/ and http://wiki.debian.org/DebianPython/NewPolicy
<doko> thom: yes, will be synced
<shawarma> Kamion: Oh... the infamous new python policy.
<shawarma> Kamion: well, I'll look at it. Thanks.
<shawarma> Kamion: Just as I thought. The dak revision currently in edgy FTBFS.
<shawarma> Is this new python policy in effect in Debian?
<ajmitch> doko: we will drop zope2.8 very soon, right?
<doko> ajmitch: yes, did you prepare the new plone? ;-p
<ajmitch> hah
<Kamion> shawarma: yes
<ajmitch> kobold was doing that :)
<shawarma> Kamion: Ok, thanks.
<thom> doko: also, /var/run/buildbot is probably not the idea place to put the buildbot user, fwiw
<doko> thom: hmm, I used another package as an example ... what would you recommend?
<thom> doko: somewhere that won't get blown away every reboot
<thom> since it's plausible that people will set up their buildbots in the users homedir
<doko> hmm, then /var/lib/buildbot ...
<thom> i think that makes more sense yes
<zul> hey
<tseng> there is only zul 
<zul> its true
<Hobbsee> hi zul, tseng 
<tseng> hi.
<zul> hi 
<joejaxx> Kamion: oh ok thanks i will try and find more information on that
<bddebian> Heya
<bddebian> Hi Gloubiboulga
<Gloubiboulga> hi bddebian, hi all
<Mithrandir> seb128: want to answer bug 54024?
<Ubugtu> Malone bug 54024 in xkeyboard-config "WIN key <SUPER_L> should be mapped to Applications menu" [Untriaged,Confirmed]  http://launchpad.net/bugs/54024
<StevenK> I'd like to teach Xemacs that my Windows key is Super.
<seb128> Mithrandir:  I'll reply to that one, reassigning (and maybe close, not sure yet). Do you have any opinion on the request?
<Mithrandir> seb128: not really -- I'd be fine with it, but it's a "default keyboard binding" request/bug, not an XKB bug and since you're master of Gnome I figured getting you to look at it made sense.
<seb128> Mithrandir: yeah, agreed, that's why I said I'll reply and reassign :)
<seb128> Mithrandir: I think we already have a request to make win key = compose
<Mithrandir> seb128: I map caps lock to compose on my machine anyway. :-)
<seb128> I map the win key :)
<Mithrandir> most of my machines doesn't have windows keys, so.. but yeah, it should do something useful.
* Hobbsee wonders what compose is
<seb128> Hobbsee: what you use do do  or  or  by example :p 
<Hobbsee> seb128: right...okay then...
<fabbione> seb128: you don't need them.. 
<fabbione> :)
* Hobbsee notes that kde was planning to map the windows key to the kmenu.
<Riddell> Hobbsee: there's no easy way to do that in kde
<fabbione> seb128: there are enough chars when typing [a-z] [A-Z]  ;)
<Hobbsee> Riddell: hmm okay - lure's the one who knows all about it, not me
<fabbione> seb128: everything extra is a bonus :P
<seb128> fabbione: and next you will say that azerty is not a good keymap? :p
<fabbione> seb128: there is only one layout.... that's qwerty :P
<Mithrandir> seb128: I use alt-gr+[zxo]  for  :-P
<ogra> fabbione++ 
* Mithrandir gives ogra an 
<seb128> altgr-o =  
<Mithrandir> seb128: no,  = . :-P
* Mithrandir hugs his layout.
<seb128> ah, right, not everybody is using azerty (yet) :p
* ogra trabsforms the  and gives Mithrandir a 
<seb128> wait we switch to french as universal language
<Mithrandir> ogra: we seldom use  in Norwegian.
<rodarvus> seb128: altgr-o is  on br-abnt2 too
<iwj> Anyone interested in the fact that dapper doesn't install on my testbed ?
<Hobbsee> iwj: no, dapper's so last month :P
<iwj> I'll burn a copy of knot-1 but I'm pretty sure that won't work either.
<ogra> Mithrandir, bah, i bet if i look at some dissertations of the uni oslo i'll find some
<ogra> :)
<fabbione> iwj: what about explaining at least the problem? perhaps it's a known issue or something...
<ogra> and did you try the common suspects like noacpi, pci=noacpi, nolapic etc ... ?
<iwj> Install appears to work properly, but after the first reboot, at the point where grub should show its menu, the machine reboots.
<iwj> I thought at first it was because I was installing the new grub in /dev/hda8 and chaining it so I let it put it in the mbr and now I have to rescue the whole machine :-).
<fabbione> iwj: could you try an installation in expert mode and slam lilo in there?
<fabbione> iwj: just to make sure we isolate the problem to grub 100%
<iwj> dapper can boot on this machine.  The existing dapper install still works.
<iwj> But I haven't rerun grub-install recently.
<iwj> phone
<fabbione> well if you did an install, grub-installer would have run that for you
<fabbione> but i don't think from the previous instance
<ogra> nope, it adds a new one ...
<iwj> back now
<iwj> IBM++  (they're really good with their laptop warranties)
<iwj> Yes, so the new install's grub didn't work and the old ones do.
<mdke> jdub: ping?
<ogra> seb128, "- Use gnome-power-manager to implement suspend/hibernate" is that using the gconf key now ? 
<ogra> (re: gnome-panel)
<Hobbsee> mdke: [00:11]  [Whois]  jdub has been idle for 12 hours, 57 minutes and 52 seconds.  midnight here
<seb128> ogra: we don't care, we are not using upstream session dialogs but the special dapper one
<seb128> ogra: for 2.14 they have no suspend or hibernates option from GNOME
<allee> Keybuk: ping.
<Keybuk> allee: hello
<allee> Keybuk: I've seen you synced digkam from debian
<mdke> Hobbsee: thanks again
<Hobbsee> Keybuk: you're back!  now, what did i have to tell you?
<ogra> seb128, yes, but is the 2.15 version using them ? 
<Hobbsee> mdke: :)
<allee> Keybuk: unfortunetely digikam 0.9 was upload to unstable instead of experimental
<seb128> ogra: looks like, but we patch the panel to not use their session code
<allee> Keybuk: 0.9 beta is not ready for a stable release
<Hobbsee> Keybuk: StevenK's done some nice work on network manager - sources are likely still on his hard drive, but i386 binaries for testing are at http://wedontsleep.org/~steven/nm/ if you're interested.  getting various -motu people to test
<allee> Keybuk: any idea how we can sync 0.8.2-1 into edgy (when 0.9 trouble is sorted out in debian)
<ogra> seb128, oh, so such a patch would be required for our logout dialog then ... now i understand 
<Keybuk> allee: you'd have to epoch it and upload manually *shrug*
<Keybuk> Hobbsee: does it fix the problems with madwifi?
<Hobbsee> Keybuk: no idea, we're still having trouble with testers who actually have dapper
<Hobbsee> Keybuk: it was more a FYI, we're working on this
<allee> Keybuk: epoch is easy to and impossible to get rid off :(   AFAIK Mark talks with ftp-masters to remove digikam 0.9-beta1 from unstable
<Hobbsee> Keybuk: and i'll be able to test out madwifi stuff on friday-ish, when i nick StevenK's wifi card that doesnt require ndiswrapper :P  shhh... :P
<Keybuk> allee: of course, I could just not push this button
<Keybuk> if you beg <g>
<Keybuk> (it hasn't gone in the archive yet)
<Hobbsee> Keybuk: s/dapper/edgy/
<Keybuk> Hobbsee: I don't have dapper on my laptop -- it runs edgy
<Keybuk> there's no source at that URL
<Hobbsee> Keybuk: my error, i cant keep the distrobutions straight :P
* allee fells on his knees.  Praises keybug to everyone and kindly wisters to the master:  please don't add digikam-0.9-beta to edgy :)
<Hobbsee> Keybuk: yes, i know, i'll bug him again about putting pu the sources.
<seb128> ogra: the session dialog use g-p-m since before dapper ...
<geser> Keybuk: bug 54036 contains a patch to add usplash support in file-rc
<Ubugtu> Malone bug 54036 in file-rc "add support for usplash" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/54036
<seb128> ogra: remember you complained because on ltsp it acts on the server?
* iwj rescues the machine.
<Keybuk> geser: ok, so now you need to find a motu to upload a new version of file-rc
<allee> Keybug I'll add a note to bug 53534 about the issue.
<Ubugtu> Malone bug 53534 in digikam "[Edgy MoM]  Please sync digikam 0.8.2-1 from Debian" [Untriaged,Fix released]  http://launchpad.net/bugs/53534
<Keybuk> Hobbsee: 'cause I ain't touching binaries -- and I can't see the source differences
<ogra> seb128, yes, it doesnt hide the suspend/hibernate options if the can_hibernate/suspend keys are unset
<Keybuk> allee: should I also not sync the -doc and imageplugins-doc packages?
<Hobbsee> Keybuk: yeah, of course - if he doesnt have them up by friday, i'll attack him with a long pointy stick in person, okay?  it's more a message of "hey, he's working on it, dont bother duplicating the work"
<Hobbsee> hi sabdfl 
<ogra> seb128, the easy fix is to remove g-p-m but i'd rather keep it and have gnome-session react on the gconf keys
<sabdfl> hey hey Hobbsee
<allee> Keybuk: all digikam*-0.8.2* are fine.  Only the 0.9-beta1 are not ready for release
<sabdfl> good work guys, i just jumped to edgy and all went basically smoothly
<jsgotangco> nice
<seb128> ogra: I don't understand what you are talking about and about what you reactionned to that panel change
<Hobbsee> sabdfl: (quick!  everybody break something!)
<zul> hi sabdfl 
<Arbiter> :)
<seb128> ogra: they did for the upstream panel what we did before dapper: make the session dialog use gpm
<seb128> ogra: nothing new for Ubuntu
<Keybuk> sabdfl: it boots?
<Vhata> Keybuk: try not to sound so surprised ;-)
<sabdfl> Keybuk: it does indeed. it socks and trousers, too
<ogra> seb128, yes, and gpm's hibernate and suspend functions depend on the /apps/gnome-power-manager/can_hibernate and /apps/gnome-power-manager/can_suspend ... if i unset these, the suspend and hibernate options still show in the logout dialog
<Hobbsee> come on...compile kdenetwork...i want to go to bed at some point...
<Hobbsee> sabdfl: hehe - but does it shirt too?
<ajmitch> Hobbsee: I hope not
<jsgotangco> haha
<ogra> seb128, i think they just shouldnt be shown, thats all
* Hobbsee wonders where mdz is.
<ogra> Hobbsee, uk
<seb128> ogra: that's a g-p-m bug then
<Hobbsee> ogra: ie, is he here to be able to upload an update to dapper (assuming it compiles/installs) or what?
<mdz> Hobbsee: London
<ogra> Hobbsee, no idea if he's hot on uploading stuff :)
<ogra> seb128, *should* the dialog pick these keys up ? 
<Hobbsee> mdz: heya, didnt see you on the list.  
<Hobbsee> ogra: lets hope he is.
<seb128> ogra: the dialog ask to g-p-m if suspend and hibernated are activated
<Hobbsee> ogra: it's kinda bad when about 1/5 of an app suddenly stops working.
<ogra> seb128, aha, ok, i'll look why that doesnt work then ... thast a dbus request it sends i guess ?
<seb128> ogra: gpm_dbus_interaction ("Suspend"); and gpm_dbus_interaction ("Hibernate");
<ogra> seb128, ta
<seb128> np
<ogra> Hobbsee, you still have 4/5 left :)
<Hobbsee> ogra: hah, yeah, and personally i dont care, cos i'm not on dapper, but i can see why the users are whinging
<Hobbsee> ogra: and besides, i'm on kde 3.5.3 anyway, so a 3.5.2 bugfix wont effect me.
<iwj> Hmm, if I use the stage1 from the old dapper release it gets as far as loading the new install's stage2 and _then_ reboots.
<Kamion> allee: BTW, in future, an epoch is not that bad, and is the right solution
<gnomefreak> is it just the uk mirrors that are messed up?
<gnomefreak> im gettng a malformed release file error
<Chipzz> Failed to fetch http://archive.ubuntu.com/ubuntu/dists/edgy-updates/Release  Unable to find expected entry  main/binary-i386/Packages in Meta-index file (malformed Release file?)
<Chipzz> Failed to fetch http://security.ubuntu.com/ubuntu/dists/edgy-security/Release  Unable to find expected entry  main/binary-i386/Packages in Meta-index file (malformed Release file?)
<gnomefreak> Chipzz: that would be the one
<elmo> it's a launchpad bug, being worked on 
<gnomefreak> elmo: ty
<iwj> grub not working for me is bug 54041
<Ubugtu> Malone bug 54041 in grub "grub does not boot for me (!)" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/54041
<Arbiter> mvo, ping
<mvo> hello Arbiter
<Arbiter> hello mvo
<Arbiter> i've just noticed your email about smartpm
<Arbiter> :)
<Arbiter> package is on REVU
<mvo> Arbiter: ah, nice. can you give me a direct link? 
<Arbiter> yep
<Arbiter> wait a sec
<Arbiter> i've patched __init__.py a bit
<Arbiter> mvo, http://revu.tauware.de/details.py?upid=2709
<slomo> Arbiter: it's already in edgy
<slomo> Arbiter: or is this only an update?
<Arbiter> alredy splitted?
<mvo> Arbiter: nice, thanks. I look over your changes in a bit 
<mvo> Arbiter: no, not splitted yet
<mdz> Keybuk: would be a good idea to refrain from syncs for the next while
<mdz> soyuz un-meltdown is in progress
<Arbiter> mvo, __init__.py is patched to warn the user that smartpm is splitted in smartp && smartpm-gtk (if smartpm-gtk is not installed)
<Kamion> Arbiter: (FYI the English word is just "split", not "splitted")
<Kamion> and "split into" probably
<Arbiter> Kamion, hehehe :D
<Arbiter> english is not my mother tongue
<Arbiter> :D
<Keybuk> mdz: I'm not doing any injection, just clearing the bug queue
<Hobbsee> bah.  let's all switch to german or something.  maybe japanese.
<Keybuk> what did they do to soyuz this time?
<Arbiter> Hobbsee, lol
<Kamion> sure, I'm not criticising you, just offering an improvement
<mdz> Keybuk: bug 54037
<Ubugtu> Malone bug 54037 in launchpad-publisher "Release files broken for pockets" [Critical,Confirmed]  http://launchpad.net/bugs/54037
<Arbiter> Kamion, yup
<Keybuk> mdz: ah, that one
<mdz> I subscribed ubuntu-archive
<Kamion> mdz: but launchpad has full test coverage, that can't happen
<mvo> Arbiter: if you update it again feel free to send a debdiff directly to me
<Arbiter> mvo, sure
<mdz> Kamion: I don't think anyone has ever claimed "full test coverage" for any non-trivial piece of software
<Keybuk> mdz: doesn't tridge for samba4?
<mdz> I doubt it; he's generally sane
<Arbiter> can someone reject the colorscheme package (NEW queue)?
<mdz> it may have tests which exhibit full code coverage, but that isn't the same thing
<Keybuk> mdz: well, yes
<Keybuk> but launchpad doesn't even have 10% code coverage for its tests
<Arbiter> upstream changed the program name -.-
<Keybuk> Arbiter: gone
<Arbiter> thanks
<jono> hey
<tseng> hiya
<bddebian> Keybuk: Thanks for the syncs.  trigger and trigger-data may need to be fakesysncs because of different orig.tar.gz ?
<Hobbsee> bddebian: that's what i had to do before, eah
<Keybuk> bddebian: correct
<bddebian> OK, so how do I do that properly?  Pull the source and add a build1 version?
<slomo> bddebian: ubuntu1... otherwise it will be tried to be autosynced next release and it could fail because of changed tarball
<Kamion> no, build1
<slomo> hm... won't that break?
<Kamion> if an autosync fails, big deal, if it succeeds, we don't want to be bothered by a manual sync
<Kamion> bddebian: build1, build with -sa plus -v<whatever>
<bddebian> Kamion: OK, thx
<bddebian> Heya ivoks
<ivoks> hey everybody
<slomo> Kamion: thanks
<bddebian> Why would an autosync fail?  Isn't it posting the new orig.tar.gz with -sa?
<Kamion> bddebian: for the same reason that Keybuk's sync attempt failed
<bddebian> OK
<Kamion> bddebian: if there hasn't been a new upstream, but just a new Debian version
* bddebian crawls back to his hole
<mdz> Keybuk: can you get MOM to pull a version from experimental?
<Keybuk> mdz: yes.
<Keybuk> one-off or ongoing?
<bddebian> Oh crap, kiki too?
<mdz> Keybuk: ongoing (firefox)
<Keybuk> dholbach: do you not also want the other telepathy packages from the same site?
<Keybuk> gst-plugins-farsight, specifically
<dholbach> Keybuk: i'll continue to get them included with daf (maybe they weren't there at that time or i uploaded some of them myself already) - i'll have another look
<Hobbsee> mdz: ping?
<mdz> Hobbsee: ?
<Hobbsee> mdz: can we get http://revu.tauware.de/details.py?upid=2786 uploaded to dapper-updates please?  it fixes a couple of rather crucial kopete bugs.
<Hobbsee> mdz: i can pastebin a diff if you want to eyeball that instead.  (both patches are in kde svn)
<mdz> Hobbsee: is http://revu.tauware.de/revu1-incoming/kdenetwork-0607251125/kdenetwork_3.5.2-0ubuntu7.diff the diff from the previous version? it's huge
<mdz> it looks like just an uncompressed version of the diff
<mdz> Hobbsee: what's most helpful for me is a debdiff from the old version to the new version so I can see what's changed
<lamont> Keybuk: not sure what the issue was with 2.3.0-2
<Hobbsee> mdz: yeah.  bleck.  that diff's completely crazy.
<lamont> mdz: postfix 2.3.1 has some more minor fixes from wietse, yada yada.. I assume that's syncable....
<lamont> or do you want email and such?
<Hobbsee> mdz: i havent found a way to get debdiffs onto revu :P  here you go: http://rafb.net/paste/results/bbzm1N35.html
<Hobbsee> mdz: argh!!! it mangled my patch!
<mdz> Hobbsee: you should delete kdenetwork-3.5.2.orig/debian/changelog.dch.save
<Hobbsee> mdz: yeah, it's mangled it.  /me pokes it with a stick and makes it save.
<Hobbsee> it was looking well behaved before!
<Hobbsee> s/save/behave/
<mdz> 19_icq_version_too_old.diff looks fine
<Hobbsee> mdz: yeah, it's just that, and the 18 one, and the changelog entry.  but i'm still trying to figure what borked.
<mdz> the other patch is a bit of a hack
<Hobbsee> mdz: it's how kde's done it, and how they've done it in 0.12.1 (this patch is for 0.11 packages)
<Keybuk> INFO:root:Trying to merge firefox: 1.5.dfsg+1.5.0.4-1ubuntu2 <- 1.5.dfsg+1.5.0.4-1 -> 1.99+2.0b1+dfsg-1
<Keybuk> mdz ^ those are the right version?
<seb128> ogra: the pango message you were looking at was due to "empty GPOS table" and fixed with the new version
<ogra> ah, cool
<ogra> so it wasnt even a font :)
<seb128> it was a font with an empty GPOS table
<seb128> which apparently is allowed
<mdz> Keybuk: yes
<ogra> ah
<Hobbsee> mdz: http://rafb.net/paste/results/52Bz3522.html looks like the proper, sane, debdiff - sorry for the other dodgy ones.
<mdz> Hobbsee: how does Riddell feel about it?
<Keybuk> mdz: ok, that'll merge from experimental from now on
<mdz> Keybuk: thanks
<ogra> seb128, i read GPOS is only used in otf ... that was what cnfused me, i have no open type fonts installed
<Hobbsee> mdz: he knew i was doing the patch, i dont think i've spoken to him since i made it work.  he accepted those two patches for the 0.12 branch, which is what we ship with edgy.
<seb128> ogra: http://bugzilla.gnome.org/show_bug.cgi?id=347073
<Ubugtu> Gnome bug 347073 in general "Allow empty GPOS table" [Normal,Resolved: fixed]  
* ogra reads
<seb128> ogra: the freedesktop bug speaks about dejavu
<ogra> oh
<mdz> Hobbsee: it looks like it has a race condition
<mdz> it's trying to implement a mutex without actually using one
<mdz> it'll be a smaller race than the old code, but it's still buggy
<Hobbsee> mdz: uh, okay.
* Hobbsee feels like the village idiot.
<mdz> Hobbsee: I don't see that it can do any harm, but it isn't correct and the author should be informed.
<Hobbsee> mdz: want to get Riddell to eyeball that when he comes back?
<Hobbsee> mdz: okay, so i'll bug the upstream people about it?
<Hobbsee> mdz: seeing as that svn commit is where i got the patch from.
<mdz> Hobbsee: Olivier Goffart seems to be the author of the bit that I find weird
<Riddell> mdz: what seems wrong with it?
<mdz> Riddell: it's racy
<mdz> there's a race between checking and setting "rentrency_protection"
<mdz> the idea seems to be mutual exclusion, in which case it should use a mutex
<Riddell> mdz: I've pinged Olivier Goffart to see if he can explain it but he's not responding, I'll get back to you when he's around
<lfittl> mako: ping
<mdz> Riddell: thanks
<bddebian> I haven't gotten anything back on kiki and trigger.  Should I, or do they end up in NEW ?
<slomo> bddebian: seems like uploads are not processed atm
<Kamion> damnit, I'm going to have to write something that checks out all four sets of seeds
<Keybuk> bddebian: "anything back" ?
<Keybuk> bddebian: soyuz isn't well, it may take time
<bddebian> Keybuk: Oh, OK, sorry
<bddebian> doko: still around?
<doko> bddebian: ?
<bddebian> doko: Know/remember anything about azureus? :-)
<Gof> mdz: ping
<doko> bddebian: can't you just ask what you do want to know?
<bddebian> doko: Well for one, the Debian package builds deps: sun-j2sdk1.5 | java2-compiler  and you changed it to java-gcj-compat-dev
<mdz> Gof: yes?
<Gof> mdz: Riddell said you have something to ask me about a kopete patch
<doko> bddebian: we do want to have azureus in main
<mdz> Gof: yes, the one here: http://bugs.kde.org/130630
<mdz> Gof: er, sorry ,wrong url
<bddebian> doko: Oh, so it is going to be promoted?
<slomo> bddebian: iirc the debian changelog mentioned that they switch to java-gcj-compat-dev too in the latest upload
<mdz> Gof: http://bugs.kde.org/show_bug.cgi?id=127749
<Ubugtu> KDE bug 127749 in general "kopete freezes on desktop right click" [Crash,Resolved: fixed]  
<bddebian> slomo: Not that I can see, unless I'm not getting the latest?
<mdz> Gof: if the goal is to avoid concurrent execution of that block, then the fix looks incomplete
<ajmitch> bddebian: http://packages.qa.debian.org/a/azureus/news/20060717T064745Z.html
<slomo> bddebian: http://packages.debian.org/changelogs/pool/contrib/a/azureus/current/changelog
<slomo> bddebian: * Build using java-gcj-compat-dev and debhelper 5.
<mdz> Gof: there is a race between testing the value of the variable and setting it
<ajmitch> slomo: or that :)
<Gof> mdz: there is not
<Gof> mdz: this is not a thread stuff
<slomo> bddebian: maybe we can just sync it... thanks for looking at it, i had it on the bottom of my list too :)
<bddebian> slomo: That's what I am trying to determine :-)
<mdz> Gof: ok, so it's only trying to prevent the situation where the DCOP call causes another call into the same method from within the process?
<Gof> the problem is a recursive call due to a call to the main event loop in  DCOPRef::callExt
<Gof> mdz: exactly
<mdz> Gof: ok, I understand, thanks
<bddebian> Ah damnit, I got 2-1 from packages.d.o.. Grr
<slomo> bddebian: use packages.qa.debian.org... it's much more uptodate most of the time and has more useful information :)
<bddebian> slomo: OK, thx
<mdz> Hobbsee: debdiff is OK for -updates
<Riddell> thanks mdz, Gof
<Hobbsee> mdz: heh, so you're not going to eat me now?  oh good.
<Hobbsee> mdz: thanks :)
<Riddell> can Hobbsee upload to -updates in main?  I presume not
<Hobbsee> Riddell: ah...well, i cant upload to main normally, so i assume not
* Hobbsee tried :P
<doko> bddebian: it *is* in main in dapper/edgy. what's your problem?
<mdz> Hobbsee: not unless you're a fish
<ogra> Hobbsee, are you a vegetable ?
* Hobbsee checks
<bddebian> doko: Then why is it on the Universe merges page?
<mdz> Riddell: not unless Hobbsee is in -core-dev; would you sponsor it?
<Riddell> mdz: will do
<mdz> thanks
<Hobbsee> mdz: i only went for MOTU last week - sheesh :P
<doko> bddebian: sorry, *universe*, not *multiverse*
<bddebian> C'mon Hobbsee, get with the program :-)
<Hobbsee> i dont think i'm a fish or a vegetable...
<Hobbsee> bddebian: heh
<bddebian> doko: I'm sorry, you lost me there?
<doko> it won't be in main, we do have another torrent in main
<bddebian> Oh, OK.
<ogra> Hobbsee, then you are not among the endagered species 
<bddebian> Hobbsee: Oh, so you are a mineral?
<Hobbsee> ogra: i'm looking around for more hobbsee's, or more female linux people, and i'm not seeing many!
<bddebian> Hobbsee: There arent many.  You could look in #debian-women
<ogra> not seeing them doesnt mean they dont exist ;)
<Hobbsee> ogra: women dont exist in the internet.  cue appropriate link.
<Hobbsee> :P
<Hobbsee> ogra: now who's to get with the program?  :P
<ogra> heh
<bddebian> hehe
<bddebian> Ack, azureus, FTBFSs anyway: E: Package libswt-gtk-3.1-java has no installation candidate
<hungerW> Hobbsee: No women on the net? I keep stumbling over pictures of nude ones all the time:-)
<bddebian> "stumble over.." ;-)
<hungerW> Hobbsee: So they must exist;-)
* Hobbsee rolls her eyes.  hungerW: i meant tech women.
<bddebian> slomo: No synce ^^ at least not yet :-(
<hungerW> Hobbsee: I did get that, was just pulling your leg.
<Hobbsee> hungerW: yes.  rather crap form of a joke too, but....
<Hobbsee> oh well.
<bddebian> Hobbsee: Just don't mention ponies and alcohol
<hungerW> Hobbsee: I know:-( But it is too hot here to come up with better jokes:-(
<mdz> Keybuk: MOM seems to flag conflicts in binary files even when they are identical in Debian and Ubuntu
<Hobbsee> bddebian: i've already heard.  and if it doesnt sound good in your head, it certainly doesnt sound good in IRC.
<Hobbsee> anyway...
<bddebian> pfft
<Hobbsee> mdz: i think Keybuk was aware of that, same with some of the .po files.
<bddebian> I give up
<gnomefreak> looks like a conflict in latest gksu packages or its just me but libgksu wont overwrite /usr/share/gconf/schemas/gksu.schemas
<LaserJock> Keybuk: thanks for my silly little section bugs
<bddebian> LaserJock!
<bddebian> LaserJock: Hey, can you regen your packages list for me please?
<LaserJock> sure
<bddebian> Hobbsee: kvpnc can be synced.  I'm not sure why they did automake1.7 instead of 1.9 but whatever :-)
<Hobbsee> bddebian: oh cool, want to request it?
<bluefoxicy> lol, libgksudo2 broke
<bluefoxicy> failed to completely install and update-manager didn't try again.  ('apt-get install' fixes)
<slomo> bluefoxicy: already fixed
<bddebian> Hobbsee: Oh sure, you want me to take the blame eh? :-)
<bluefoxicy> slomo:  yeah, the problem fixes itself :p
<Hobbsee> bddebian: sure, it's pitch black in here, except fo rthe computer screen.
<Vhata> what's the canonical (ahaha, I slay me) way to run an instance of edgy within a dapper machine?
<slomo> bluefoxicy: yes but a fixed package was uploaded too :P
<bluefoxicy> slomo:  ah.
<Amaranth> Vhata: vmware-server is a good choice
<bluefoxicy> wtf.  bluefox@icebox:/tmp/x$ gksu synaptic  -> glibtop: This machine has 1 CPUs, 1 are being monitored.
<Vhata> Amaranth: so, full on virtualisation?
<mvo> bluefoxicy: see, it does not only gets your passwort but it also checks your cpus :P
<Amaranth> Vhata: either that or give it it's own partition
<Vhata> Amaranth: i.e. dual boot?
<Amaranth> yeah
<Vhata> let me see if vmware-server is in the hypertimetransmetroverse
<bddebian> Hobbsee: Sent
<Hobbsee> bddebian: thanks
<bluefoxicy> also has anyone looked in /etc/ld.so.conf.d/ ?  I just want to make sure what I'm seeing is correct.
<Kamion> Vhata: use edgy's debootstrap to create an edgy chroot, if you don't care about the kernel changes
<Vhata> Kamion: that sounds like more fun
<Vhata> (not that ubuntu development is fun of course.  deadly serious stuff, this.  straight face, stiff upper lip, what, what?)
<Vhata> Kamion: I need debootstrap 0.3.3.0ubuntu3, not 0.3.3.0ubuntu2, yes?
<Vhata> Vhata: work it out for yourself
<Vhata> sorry.
<zul> right...im ready to release havoc on the world..
<LaserJock> noooooo
<HiddenWolf> zul: In which fiendish way?
<zul> xen/xen-linux image
<HiddenWolf> nice
<mc44> I guess someone knows the irclogs are broken
<tseng> unlikely to be much of a priority, unfortunately
<mc44> I'm guessing fabbione has gone off to do something important like have a baby instead :)
<tseng> the bot is still here
<bluefoxicy> wow that's new.  I can't triage my own bugs.  :P
<iwj> knot-1 seems to take a lot longer to install than dapper.
<iwj> At least I've managed to defeat my recalcitrant CD writer and my workstation isn't mumbling BIOS messages out of its PC speaker any more.
<iwj> Yep, knot-1's grub can't cope either.
<iwj> zul: Excellent.  I was going to try it out ASAP but as you can see I don't have a working edgy install atm :-/.
<zul> well you should really wait for a kernel as well ;)
<iwj> *snort*
<fabbione> yes the irclogs are not working because one of the machines at the datacenter is broken
<iwj> I have a kernel or two I could play with.
<iwj> They don't quite work right but they'd let me try out your xen.
<zul> well you dont need me then ill just go home and pout :)
<iwj> :-P
<zul> heh
<iwj> (Just doing your pouting for you too.)
<zul> brb...need to reboot
<zul> er...nevermind
<bluefoxicy> hmm... now all I need to do is fix #49283 and none of the apps I'm running most of the time should have an executable stack.
<tseng> "Another quick fix is to add the following block to the end of each .nasm file in src/libFLAC/ia32/"
<tseng> wish you'd quit that
<zul> brb...for real this time
<tseng> have you talked to upstream?
<hub> damn
<hub> I dist-upgraded to edgy and X no longer start
<hub> is there a way to ensure that I have all the packages?
<tseng> apt-get install ubuntu-desktop helps
<mvo> hub: is ubuntu-desktop installed? [hello btw]  :)
<hub> kubuntu-desktop is up to date
<tseng> did you look at the X log?
<iwj> Aha!  If I trim my menu.lst, it works!
<Vhata> sabdfl at work:  grep -- -- /var/log/messages
<Vhata> that's got to be old.
<tseng> yeah that was not remotely funny
<hub> could not open default font 'fixed'
<hub> *sigh*
<tseng> man
<tseng> they should really roll that into the core server one of these days
<hub> xfonts-base is there
<hub> and I did a reconfigure of X
<slomo> you have to run mkfontdir or something in one of the font directories
<zul> super..http://70.29.57.2/ubuntu/xen/dmesg-xen.out
<hub> slomo: works better
<slomo> hub: mkfontdir in /usr/share/fonts/X11/misc
<hub> thanks
<slomo> np :)
<rodarvus> Kamion, Keybuk: I'd like to have source package 'mesa' rejected from the Accepted queue (mesa-swx11-source is causing xorg-server to FTBFS)
<Kamion> too late
<rodarvus> :/
<rodarvus> no worries then, thanks anyway :)
<Kamion> if this is 6.5.0.cvs.20060524-1, it's being munched on by the publisher right now
<rodarvus> yep, this is it
<Kamion> if you're quick, you might be able to supersede it with a new source upload before the binaries get there, though
<lamont> why would a laptop that booted in ~1 min on breezy take 10 min to boot dapper???
<rodarvus> I'll upload a new release of Mesa later tonight
<Kamion> lamont: probably hit the bad-luck side of the wait-for-root-device-to-appear code in initramfs-tools
<Kamion> (at a guess ...)
<rodarvus> Kamion, it won't break runtime - the only problem is xorg-server builds, it seems
<Kamion> cool
* Kamion pushes revive-tasksel another step up the hill
<lamont> he says it first shows up loading restricted drivers, and then everything goes more slowly - X startup takes about 5 of those minutes...
* lamont bets something is going cpu-bound
<Kamion> oh, nothing I know about then ...
<tseng> udevstart used to hang for some minutes
<tseng> but im sure that was fixed
* lamont wonders what that fun trick Keybuk et al were using for instrumenting startup times and such....
<fabbione> lamont: i have heard something like and there is a bug with a workaround in LP
<tseng> lamont: bootchart?
<fabbione> something to do with speedstep
<lamont> fabbione: 10x??? 
<lamont> tseng: could be
<fabbione> lamont: can't remember.. but pretty slow
<lamont> fabbione: if you happen across the bug, that'd beat me reading the entire pile looking for it....
<fabbione> lamont: let's ask on -bugs
<bluefoxicy> tseng:  I just sent a patch to upstream.
<tseng> bluefoxicy: goodness.. ok
<tseng> something rubs me wrong about firing up vi and sticking your own elf headers in an asm file
<bluefoxicy> and told them how to fix PPC because I don't feel like trying to tweak the build system to use .S instead of .s for a single file.
<bluefoxicy> vi?
<tseng> but its your soul, not mine :)
<bluefoxicy> I write a small shell script to do it.
<hub> did something change with the locales again?
<crimsun> what's the context of "again", i.e., between what periods?
<crimsun> my dapper->edgy dist-upgrade didn't preserve my selected locales, but I worked around it by regenerating them via locale-gen afterward
<Kamion> pitti: I'd appreciate a tasksel MIR review when you have time; I've written the report
<Keybuk> lamont: hmm?
<lamont> Keybuk: when you were playing with boot times on the thinkpads...  what were you using to make those pretty graphs, etc.
<lamont> although it looks like maybe speed step is to blame in this case.
<Keybuk> lamont: apt-get install bootchart
<Keybuk> then boot, and look in /var/log/bootchart for the pretty graphs
<neom> What nick does Mark use if he comes by?
<Keybuk> neom: sabdfl
<neom> k
<neom> Just found out my doctor is his uncle. O.o
<AlinuxOS> mjg59, ping
<Treenaks> neom: cool :)
<Vhata> perl: warning: Setting locale failed.
<Vhata> perl: warning: Please check that your locale settings: LANGUAGE = "en_ZA:en", LC_ALL = (unset), LANG = "en_ZA.UTF-8" are supported and installed on your system.
<Vhata> that's after an edgy debootstrap
<Kamion> debootstrap doesn't generate locales for you
<Kamion> 'locale-gen en_ZA.UTF-8' in the chroot
<Kamion> or 'apt-get install language-pack-enn'
<Kamion> er, -en
<Vhata> right ta
<pitti> "Committed revision 666."
<pitti> woo! :)
<pitti> the release of the devil
<LaserJock> yikes, that's an interesting statment coming from the security guy ;-)
<pitti> MUHAHAHA
<pitti> I wish I would release this as postgresql-common 66, unfortunately it's only 58 so far :)
<Mithrandir> pitti: just bump the debian version number, then.  Nobody says they have to be sequential
<slomo_> pitti: or split the changelog into 8 versions ;)
<pitti> heh
<Keybuk> when totem crashes every time it's opened, what's the fix?
<slomo_> Keybuk: totem-gst or totem-xine?
<Keybuk> gst
<slomo_> how does it crash? anything useful on the console?
<Keybuk> The error was 'BadAlloc (insufficient resources for operation)'.
<Keybuk>   (Details: serial 57 error_code 11 request_code 140 minor_code 19)
<slomo_> Keybuk: hm, i only knew that one from totem-xine until now... since when do you have this?
<Keybuk> isn't me, it's a new user
<Keybuk> has it since installing dapper at the weekend
<Keybuk> definitely totem-gstreamer
<slomo_> you could tell him to try renaming /usr/share/totem/totem_logo.png to something else... at least for totem-xine it is caused by the logo which would need more X memory then available. maybe not enough video ram or something...
#ubuntu-devel 2006-07-26
<Keybuk> he'd already tried that
<Keybuk> seems to be an output plugin problem
<Keybuk> set to ximagesink it's fine, xvimagesink isn't
<slomo_> no idea then :(
<Riddell> hi hub, did you get sorted?
<hub> Riddell: my upgrade?
<hub> Riddell: yeah it sort of work
<Riddell> hub: what was up with X?
<hub> mkfontdir
<hub> as hinted by slomo_ 
<hub> I still have a couple of issues like Perl disliking the locale and an artsmessage poping up
<hub> (KDE)
<neom> Hub. :o)
<slomo_> hub: you use kde?
<hub> slomo_: it depends of the machine
<hub> slomo_: that machine has Kubuntu Dapper upgraded to edgy
<hub> the laptop is still Gnome + KDE apps
<hub> other work machine run another distro for dogfooding
<slomo_> hub: oh, i expected you beeing a pure gnome guy :)
<hub> slomo_: i'm not pure
<neom> Linus said gnome sucks. :o
<hub> even more given my paycheck
<hub> neom: who cares
<neom> linus, apparently. 
<Keybuk> frankly, who'd go to a kernel engineer to write a desktop environment?  words like "usability" just aren't in their dictionary
<Riddell> "Gnome + KDE apps" sounds like the edubuntu approach :)
<hub> Riddell: or some other people. I just migrated to KMail
<hub> even if it annoys me sometime
<hub> it just provide better feature than Evo and T-bird
<Riddell> what feature won you over?
<LaserJock> Riddell: well, it's hard to overcome kalzium ;-)
<hub> apply filter manual that t-bird do not do
<hub> and keyboard navigation that evo do not to
<hub> and the  bloat as is missing ;-)
<Riddell> right
<hub> some bugs or missing things though
<hub> like the notification icon that bugs with gnome-panel
<Riddell> I just use mutt, but people say that KMail has good features. Until they find it deleting their inbox
<hub> Riddell: I use IMAP over several accounts
<hub> Riddell: that's why I stopped using mutt
<hub> still love it
<johanbr> I tried KDE for a while, before switching back to Gnome. KMail played a large part in making me switch back, with the weird contortions you have to go through just to get KMail to read a spool file filtered by procmail.
<hub> Riddell: the worse is that $COMPANY will want us to move to use Evolution on top of our KDE desktop because of the groupware solution
<Burgwork> hub, you telling me Xandros uses exchange?
<Riddell> hub: really?  but KMail has pretty decent groupware support, what's the server that's needed?
<hub> Burgwork: no. Scalix
<hub> Burgwork: we ship it
<Burgwork> ah
<hub> Riddell: Scalix
<hub> Burgwork: between you and me, I wouldn't have been surprised to see exchange coming at one point
<Burgwork> ugh, you poor man
<hub> Burgwork: but at least it is the product we ship with out server solution
<hub> I'll see. If I lose server side filtering, I'm not gonna be happy
<bluefoxicy> anyone know if I should have a file '/etc/ld.so.conf.d/$machine-$os' ?
<hub> Burgwork: at my previous company they wanted to sell and ActiveX based webmail solution
<slomo_> bluefoxicy: yes, should be there
<hub> Burgwork: with all the engineering running Linux
<bluefoxicy> slomo_:  should it have dollar signs in the file name?
<bluefoxicy> that's a really strange name for a file o.o
<hub> Burgwork: like there were using Flash at one point for engineering tools....
<zul> hey
<Kamion> libc6: /etc/ld.so.conf.d/$machine-$os
<Kamion> bluefoxicy: ^-- look for bugs filed there, I guess
<bluefoxicy> nope, seeing no bugs filed. slomo_, Kamion:  So I'm guessing $machine and $os WERE supposed to expand to something?  (i386-pc and gnu-linux probably)  Or should I not file a bug?
* bluefoxicy curiously wonders what Ubuntu PPC is ... ppc-mac-gnu-linux?
<Keybuk> powerpc-unknown-linux-gnu ?
<bluefoxicy> Keybuk: powerpc-overheating-linux-gnu if you have a Macbook Pro
<Kamion> bluefoxicy: file the bug, I'm sure it's something obvious in the glibc build system
<bluefoxicy> kay.
<Kamion> and yes it's powerpc-unknown-linux-gnu
<Kamion> (or so saith config.guess)
<bluefoxicy> bug filed.
<Kamion> ta
<zul> gah i suck at documentation
<ehazlett> hey all...  im trying to install software in a chroot env via python.  i keep getting dpkg exiting with errors, but installs find when i manually chroot... any ideas?
<sladen> ehazlett: pbuilder maybe what you're after?
<ehazlett> im not sure...  i am trying to use   chroot <root> apt-get install packageA
<ehazlett> i dont want to build a .deb, i want to install via apt
<johanbr> ehazlett: Some python component that's not in the chroot, maybe?
<ehazlett> could be... although everything works fine if i just chroot from the shell.  when i try it from python, i get E: Sub-process /usr/bin/dpkg exited unexpectedly for every package...
<infinity> ehazlett: environment breakage?  Lack of a controlling TTY?
<ehazlett> infinity: maybe.  any ideas for fix?  would that error happen if there was no console to output to?
<infinity> ehazlett: I'd need more to go by than just that error.
<ehazlett> ok. here's what im doing.  i have a selection of packages in a pygtk gui.  once selected, i chroot into the environment (which is the ubuntu live cd) and do apt-get install
<ehazlett> i mount /proc and copy dns info.  the debs are there in the cache, but i can't get them to go...
<ehazlett> i know ubuntu doesn't need another customization kit, but i started this project to learn pygtk, and decided to finish it... ive got it done except for this stage...  any help would be much appreciated... :)
<bddebian> Hello
<Hobbsee> hi bddebian 
<bddebian> Hi Hobbsee
<Hobbsee> has anyone done the mesa updates, and lived to tell the tale?
<crimsun> what do you mean by 'done'?
<rodarvus> Hobbsee, me :)
<Hobbsee> crimsun: sorry, done as in upgraded
<rodarvus> twice today :D
<Hobbsee> rodarvus: did you break anything?
<rodarvus> but I packaged mesa, so I might be biased :P
<rodarvus> Hobbsee, X (and Mesa) has no bugs
<rodarvus> it always the kernel, Gnome, KDE or some other package
<rodarvus> its
<Hobbsee> rodarvus: rofl!  right.
<Hobbsee> rodarvus: sure sure.
<Hobbsee> rodarvus: then surely you should fix all those bugs then too :P
<zul> rodarvus: yay blame us ;)
* Hobbsee blames zul.
<rodarvus> I would fix X bugs if there were any
<bddebian> sweet
* Hobbsee has to stay away from the internet connection, before we hit the bandwidth limit for the month.  i'm still wondering whether it fixes things though.
<rodarvus> Hobbsee, btw, if you wait for another hour or so, another (better) mesa update is already underway
<rodarvus> so, don't waste your bandwidth with this update
<rodarvus> (now, I mean)
<Hobbsee> rodarvus: but whyever would you need one?  you just said it contained no bugs, so therefore should need no fixing?
<Hobbsee> :P
<rodarvus> its not bugfixing
<rodarvus> its a new upstream release (Mesa 6.5)
<mjg59> AlinuxOS: I've just uploaded a new ttf-bpg-georgian-fonts to Debian
<rodarvus> needed for X.Org 7.1
<Hobbsee> ooh...fun :)
<mjg59> AlinuxOS: I'll get it synced over to Ubuntu once it's in the archive
<Hobbsee> when's xorg 7.1 coming in?
<johanbr> rodarvus: Have you seen the bug where emacs, xfontsel, among other programs, claim there are no fonts present?
<mjg59> rodarvus: Score
<rodarvus> Hobsee: a very large part of it is already installed on your machine, if you have edgy
<mjg59> rodarvus: Are you going to build with aiglx by default?
<Hobbsee> rodarvus: nick completion is good, and okay.
<mjg59> (Even if you do, I believe it's disabled unless the user enables it in xorg.conf)
<rodarvus> mjg59, not right now (it wasn't specced), but I plan to, if time allows
<rodarvus> not sure if its going to happen for Edgy, though
<rodarvus> (I'd really like to, if possible)
<Hobbsee> rodarvus: just dont eat or sleep, you'll be fine :P
<mjg59> rodarvus: Ok. I'll look into what's needed
<rodarvus> mjg59, thanks - really appreciated!
<mjg59> rodarvus: If all else fails, and the build-depends are there, I'll just update the source package in universe
<rodarvus> build-deps are supposed to be there
<ajmitch> wonderful
<ajmitch> more shiny stuff
<mjg59> rodarvus: Yeah, mesa was the main sticking point
* Hobbsee coats ajmitch in shiny confetti.  yep, shiny stuff!
<ajmitch> mjg59: do you plan to update the xgl package, or should we do it (before the horde of users comes down on us)?
<mjg59> ajmitch: Is Xgl in the main xorg tree yet?
<bddebian> Are we still not including GLw libs?
<ajmitch> probably not
<ajmitch> I haven't checked lately
<rodarvus> bddebian, yes, we are not including GLw
<mjg59> If not, just greab the source package, do cvs update and make it use the new mesa
<rodarvus> we have a policy of not supporting motif/lesstif on main
<bddebian> rodarvus: Great, since I removed them from grass.  Thanks :-)
<mjg59> Then someone needs to sort compiz
<ajmitch> that could be thorny
<rodarvus> I still have about 50 drivers I want sorted out before even thinking of any other package :/
<Hobbsee> rodarvus: where are you?  isnt it 3 am or something there?
<ajmitch> go with upstream, or go with the fork on compiz.net?
<crimsun> 11:03 P.M.
<rodarvus> Hobbsee, no, its 11 PM here
<rodarvus> (UTC-3)
<Hobbsee> rodarvus: ah ok, US somewhere.  i thoguht you were in europe
<rodarvus> actually, Brazil somewhere :)
<Hobbsee> rodarvus: ahhh...nice!  :)
<mjg59> ajmitch: I don't care, as long as we don't ship with the Novell logos...
<mjg59> ("oops")
<bddebian> heh
<Hobbsee> hehe
<Hobbsee> please tell me we didnt do that.
<ajmitch> nice, cvs update, half the makefiles conflict
<ajmitch> do I care enough to fix it?
<Hobbsee> ajmitch: yes, you do.
<mjg59> Hobbsee: Nope
<mjg59> ajmitch: For xgl?
<ajmitch> yes
<mjg59> Makefiles, or Makefile.am?
<mjg59> (or Makefile.in, etc)
<ajmitch> Makefile.am
<mjg59> Oh, that's a bit of an arse
<ajmitch> all in the GL dir
<mjg59> Oh, hrm. I may have done horrible sed shit all over them at some stage
<mjg59> Ah, right
<ajmitch> so it may not matter
<mjg59> Just nuke them and pull the upstream ones
<mjg59> The changes shouldn't be needed with new mesa
<ajmitch> going back to cvs after using bzr is an experience
<mjg59> Yeah, it's like having a leg cut off
<mjg59> You want to roll back one changeset, but...
<ajmitch> right, seems to be in order now
<mjg59> Cool
<ajmitch> I really shouldn't do this on the laptop, it's got a much slower disk for building
<mjg59> Haha
<Hobbsee> hehe
<mjg59> Wow
<mjg59> That's a point
<mjg59> I don't have a single machine with a 3.5" drive
<mjg59> Except the TV
* mjg59 really needs to sort out a zeroconf distcc laptop farm
<rodarvus> ajmitch, mjg59: if you plan on build anything Mesa-6.5-dependant right now, please wait another hour or so (an even newer version of mesa was uploaded 1.5 hours ago)
<mjg59> Doing dist-upgrades at night is noticably faster
<ajmitch> rodarvus: I can wait, I've got far more important things to do :)
<mjg59> Wow.
<mjg59> I've finally found time to do Debian maintenance, and I suddenly feel so much better
<zul> got the monkey off your back?
<LaserJock> mjg59: did Ubuntu on intel macs sort of die out? I was looking around on the web and most of the stuff is a few months old
<mjg59> LaserJock: Erm.
<mjg59> LaserJock: Dapper should pretty much just work
<mjg59> Only problem is that you have to do the partitioning under MacOS
<LaserJock> mjg59: how do you boot it. I've seen bootcamp + rEFit + lilo
<mjg59> Skip the refit stage, just use lilo
<mjg59> Holding down alt lets you choose
<LaserJock> ok, so use bootcamp to set stuff up, boot up an Ubuntu cd and use lilo?
<mjg59> Yeah
<bddebian> Do the Smashintels use OpenFirmware?
<LaserJock> hmm
<mjg59> I'll try to sort out parted in time for edgy
<mjg59> At the moment it's irritatingly spec-compliant, which isn't what you want here
<mjg59> And a small patch for grub, then everything'll be fine
<zul> mjg59: debian already has the patch for macintel which got synced for edgy
<mjg59> In grub? Cool.
<zul> yep
<vignatti_> Greetings
<mjg59> So just parted to "fix"
<vignatti_> What is the name of the disk partition on ubuntu?
<Hobbsee> mjg59: hah.  love your reply w.r.t. suspend2 on ubuntu-devel mailing list :P
<jsgotangco> heh
<bddebian> Heya jsgotangco
<bddebian> Someone please kill me
<bddebian> Ah, LaserJock will do it
<LaserJock> mjg59: do I want to create a Drivers CD in bootcamp or is that only for Windows?
<LaserJock> bddebian: I'll do what?
<bddebian> LaserJock: Kill me
<LaserJock> oh, sure, no problem ;-)
<bddebian> Fire up one of your lasers and saw me in half
<mjg59> LaserJock: Just for Windows
<LaserJock> unfortunately none of mine will saw people in half
<bddebian> Or better yet, burn my eyes out so I don't see axiom anymore
<zul> night
<bddebian> Gnight zul
<LaserJock> however, I think the mechanical engineering dept. has one
<LaserJock> cya zul 
<LaserJock> mjg59: still around?
<dieman> nice. digg effect on wiki.ubuntu.com
<pitti> Good morning
<Hobbsee> hi pitti 
<Vhata> Some mornings, it's just not worth chewing through the leather straps.
<pitti> hi Hobbsee 
<pitti> rodarvus: btw, urgency field does not matter at all for Ubungu
<pitti> rodarvus: Ubuntu, too
<Vhata> why does edgy tell me I have 0 packages upgraded, 1 newly installed, 79 to remove and 3 not upgraded.
<Vhata> I'm okay with it removing nano, but not postfix etc.
<Hobbsee> Vhata: cos you're system's in serious trouble?
<Vhata> that's the first install I do after install ubuntu-standard
<Hobbsee> what's the one newly installed one?
<Vhata> Hobbsee: that was me about to install joe
<Vhata> I haven't actually done anything serious to put my system into trouble... except a dpkg-reconfigure -a ?
<Vhata> this is what I get for installing joe.
<Hobbsee> likely
<Hobbsee> if it hasnt been updated
<pitti> Kamion: tasksel approved; will this be used in the first-stage installer, or only in the installed system? in the former case, I should add it to the striptranslations blacklist
<dieman> wow, thats cute.
<dieman> if your background image is missing and it shows back up, i guess nautilus gets an notification and updates the background
<bluefoxicy> sweet.
<bluefoxicy> I reduced gettimeofday() calls on an order of 500 times.
<bluefoxicy> now all I need is something faster than gettimeofday() (I used posix timers to do interval timing, except it's about 25-50% slower than gettimeofday())
<bluefoxicy> the code handles skew to a configurable accuracy with automated drift checking on a sliding window; but it's pretty useless without some method that's faster than gettimeofday() to replace it with.
<lifeless> bluefoxicy: what ya working on?
<bluefoxicy> lifeless: http://lwn.net/Articles/192214/  "X is a big offender, apparently because the gettimeofday() call is still too slow and maintaining time stamps with interval timers is faster."
<bluefoxicy> lifeless:  I'm trying to maintain timestamps on a gettimeofday() type interface, in the background, automatically
<bluefoxicy> pretty much I initialize a timer to gettimeofday() and set up a posix timer that's set to 999999999 usecs (1 second - 1 microsecond), and then when asked the time of day check the posix timer.
<bluefoxicy> if it's disarmed (i.e. time ran down), I use gettimeofday()
<bluefoxicy> if it's armed, I add the amount of time that's passed on the timer to my stored timeval; incriment a 'drift' on my timer; and copy my timeval into the target
<bluefoxicy> If my 'drift' reaches a 'dcheck' value, I check for drift and reinitialize from gettimeofday(); if there is drift (i.e. I'm more than (accuracy) off from gettimeofday()), I decrease 'dcheck' so that drift is checked for more often (more gettimeofday() usage)
<bluefoxicy> if there's no drift and I'm less than 95% of (accuracy) away from gettimeofday(), I increase 'dcheck' to lower the amount of gettimeofday() usage
<bluefoxicy> lifeless:  the result is that I'm using a target accuracy of 500uS, so I'm probably within 1000uS (actually within 550uS), and using gettimeofday() 1/500 of the time.
<bluefoxicy> the problem is, of course, that checking the time left on posix timers is SLOWER than gettimeofday()
<bluefoxicy> so I'm trying to figure out what this magical "interval timers" thing is.
<lifeless> bluefoxicy: ah
<bluefoxicy> I asked davey jones
<bluefoxicy> since he gave the original "userspace is way too slow" speech.
<lifeless> setitimer ?
<lifeless> http://www.quepublishing.com/articles/article.asp?p=23618&seqNum=14&rl=1
<bluefoxicy> ah
<lifeless> (btw, 'linux interval timer' in google :))
<bluefoxicy> hah
<bluefoxicy> the thing with that is it's signal based, so I can't turn it into a black box
<bluefoxicy> plus there's only 3 interval timers, and I need the realtime one.
<bluefoxicy> so it's not a case of "stick it there, use the interface, it works;" more "don't use this that and the other thing, and this will work"
<bluefoxicy> so much for being generic.
<lifeless> well
<lifeless> I think the point is that if gettimeofday could be made faster the kernel folk would
<lifeless> so, its about doing things differently in the user app
<Amaranth> bluefoxicy: is what you already have better than what X does?
<bluefoxicy> Amaranth:  it's slower by 30% because timer_settime() is slower than gettimeofday()
<desrt> does anyone have a copy of dave jones' slides from ols?
<desrt> sounds like they might be a good read
<Amaranth> bluefoxicy: err, i thought you were using gettimeofday() and a timer
<bluefoxicy> Amaranth:  I want to avoid anything that delivers random signals or spawns threads (I can get the timers to spawn threads to update but then i have to worry about thread safety and such)
<Amaranth> oh
<Amaranth> i see
<Amaranth> so you made something much more complex yet slower than just using gettimeofday() directly :)
<bluefoxicy> yeah
<desrt> heh
<Vhata> is there a better way of doing this?  dpkg-query -W -f '${Package}\n' | xargs debsums -c
<bluefoxicy> I'm going to sleep.
<desrt> Vhata; some sort of tripwire setup?
<Vhata> desrt: that sort of thing, yeah
<bluefoxicy> http://bluefox.kicks-ass.org/stuff/bluefox/timer/ if anyone wants to toy with this junk.
<Vhata> err, debsums probably won't tell me if a package was badly installed, will it?
<dholbach> good morning
<desrt> dholbach; word.
<seb128> hey dholbach desrt
<desrt> dholbach; your ubuntu laptop badges are making the rounds in canada.  mad props.
<dholbach> yo desrt
<dholbach> desrt: coool :-)))
<desrt> oh.  i wanted to upload a picture.
<desrt> action shot.
<desrt> http://desrt.mcmaster.ca/random/dholbach-in-action.jpeg
<ajmitch> impressive
<desrt> thx
<desrt> took me a few tries to get one right on the paddle like that :)
<dholbach> hahahaha :)
<dholbach> that was really nice
* desrt had fun :)
* dholbach too
<Gloubiboulga> hello
<imbrandon> moins fellas
<Fujitsu> Morning, imbrandon.
<desrt> seb128; good day.
<seb128> hi desrt
<desrt> what's up on the crazy continent?
<Hobbsee> desrt: it's now painted purple/
<desrt> that's awesome!
<desrt> those crazy europeans... always doin' something new
<desrt> seb128; where do you live?
<seb128> desrt: France
<desrt> thanks, tips
<desrt> but seriously.. where
<seb128> seriously? France :p
<Vhata> seb128: that's near Kenya, yes?
<seb128> North-East
<seb128> near of Germany
<desrt> near lux?
<desrt> or more east of there?
<dholbach> near lux too
<seb128> desrt: near of Luxembourg and near of Germany
* desrt is planning to be in luxembourg next year
<seb128> like in the north-east corner near of them
<seb128> oh?
<seb128> anything interesting to do there? :)
<desrt> look at the pretty things, i guess
<desrt> and probably spend an awful lot of cash
<desrt> i understand it's an expensive place to be
<seb128> desrt: yeah, luxembourg is sort of expensive ... because they sort of have some money to spend :)
<hungerW> seb128: And they do not even have to spend as much on fuel as i.e. germans:-)
<desrt> hungerW; s/ie/eg/
<hungerW> desrt: What does eg stand for?
<desrt> for example
<hungerW> desrt: Man, your spelling sucks;-)
<hungerW> desrt: There is no e in for and no g in example;-)
<desrt> egsample
<hungerW> desrt: A sample of an egg?
<neuralis> hungerW: exempli gratia
<hungerW> neuralis: Ahhh, thanks.
<hungerW> neuralis: Now I have a fighting chance to remember e.g.;-)
<neuralis> np
<seb128> desrt: is there an easy way to know if gnome-vfs is using inotify or gam,fam?
<desrt> seb128; it's using inotify
<desrt> :)
<desrt> seb128; or is this more like you have to tell something to someone on bugzilla to figure out what the heck is going on?
<seb128> desrt: not, that's like I've gam_server running
<desrt> in that case check if fam or gamserver is running
<desrt> o.
<seb128> and after sending it a SIGUSR2 the log has things like
<seb128> "if that's what you want to ask, what about asking dir"
<seb128> ups
<seb128> stupid copy being b0rked
<desrt> that's an odd log message :)
<seb128> "MONDIR request: from nautilus, seq 3, type 2 options 0
<seb128> nautilus listening for"
<seb128> to /tmp/gamin_debug_QX9zWH
<seb128> and directories like ~/Templates being listed there
<desrt> have you messed around with your kernel and disabled inotify or something?
<seb128> no
<seb128> but maybe the edgy kernel is b0rked
<seb128> that's why I'm asking how I can know if it's using inotify or not :)
<desrt> gnome-vfs will check for inotify and fall back on libfam
<seb128> right, that I know
<dholbach> idiotify! :-)
<desrt> well.  it is clearly using fam :)
<seb128> the question is "how do I make it tell what he figured about inotify"
<seb128> s/he/it
<desrt> strace gnomevfs-monitor ~
<desrt> SYS_291(0xb7fbfb30, 0xb7fb15e0, 0x1, 0xb7fb134c, 0xb7f3ce60) = 9
<desrt> ^ inotify
<seb128> SYS_291(0xb7fd1c70, 0, 0x1, 0xb7fbd7c0, 0xb7f537d0) = 3
<desrt> i wonder where all my fds went
<desrt> holy crap gam_server is running
<seb128> :)
<desrt> wtf!
<Amaranth> i knew something was wrong :P
<seb128> desrt: ok, that's where I wanted to bring you ;)
<seb128> so either linux is b0rked
<seb128> or gnomevfs is
<Amaranth> need a small app that using inotify directly
<dholbach> i think mvo wrote a piece of code that does that.
<dholbach> but he's not here yet
<desrt> it's clearly using inotify directly
<seb128> dholbach: inotify upstream has some code for that, why is mvo reinventing the wheel :)
<ogra> there must be an old inotify bug where he attached it
<desrt> pipe([3, 4] )                            = 0
<desrt> pipe([5, 6] )                            = 0
<desrt> pipe([7, 8] )                            = 0
<dholbach> seb128: he wanted to play with it
<desrt> in the middle of nowhere
<seb128> dholbach: right, that's mvo :p
<desrt> oh.  seb.  do you have very new gnomevfs installed?
<desrt> orbit seems to be making these pipes -- a problem that very new gnome-vfs would not have :)
<seb128> desrt: I've edgy, which has 2.15.90 from yesterday
<seb128> or from monday :)
<desrt> there's a very unhappy darwin user on gnome buzilla
<seb128> dholbach: http://www.kernel.org/pub/linux/kernel/people/rml/inotify/utils/inotify-utils-0.25.tar.gz
<desrt> the whole "just move the symbols from libgnomevfs to libbonobo" thing doesn't work on macos :)
<seb128> desrt: cf ABI breakage and wanting to bump the soname?
<ajmitch> right. xgl updated from git, but will it work?
<desrt> ya.  jerk.
<seb128> desrt: I don't like his tone
<seb128> "Perhaps you need to go and reread the library versioning section of the libtool
<seb128> manual (assuming you read it in the first place)"
<desrt> seb128; i sort of like christian/alex's tones... but for a bad reason :)
<seb128> LART
<seb128> hehe
<desrt> the gnome community is increasingly getting the "if it's not linux, i don't care" attitude
<desrt> which i think is really good
<Amaranth> inotify-test seems to be working
<desrt> inotify is definitely working.  those syscalls are returning good things.
<Amaranth> so i'm thinking something is wrong with gnome-vfs
<seb128> in fact the gam_server log I've about nautilus seems to be for non-existant directories it has to monitor
<desrt> fwiw, i'm using straight inotify here with no gamin
<desrt> i have no idea why gam_server is running
<seb128> like I had no ~/Templates
<seb128> so inotify seems to complain and it falls back using gam_server for polling it
<seb128> or something like that
<Amaranth> hrm
<seb128> $ tail -f gamin_debug_XYpe57
<seb128> Event to /usr/bin/epiphany : 1, 2, /usr/local/share/applications/mimeinfo.cache Deleted
<seb128> Event to /usr/bin/epiphany : 1, 9, /usr/local/share/applications/mimeinfo.cache None
<seb128> ...
<seb128> it has things like that
<Amaranth> inotify-test spit out the fact that someone touched ~/.bashrc but not that i created ~/foo
* desrt gets an evil idea
<seb128> Amaranth: the gnome-vfs code for inotify didn't change a lot recently, if you have issues with it might be inotify itself  
<Amaranth> i dunno if the tool is broken or if inotify is but it's only spitting out the first event
* desrt replaces gam_server with a somewhat more informative shellscript
<dholbach> mvo is here! we're saved!
<desrt> oh that's annoying.
<Amaranth> desrt: ?
<ajmitch> hey mvo 
* dholbach hugs mvo
<seb128> "(evolution-2.8:9185): e-utils-WARNING **: calling e_icon_factory_get_icon_filename with unknown icon_size value (48)"
<desrt> i tried to replace gam_server with a shellscript that didn't deparent itself so i could see in ps who is responsible for spawning it
<seb128> hates evolution
<desrt> dholbach++
* mvo hugs dholbach
* mvo hugs ajmitch
<desrt> turns out the cliend-side library is does the deparenting on fork before execing
* mvo yawns
<desrt> seb128; have you seen daniel's "Evolution GRRRRRRRRRR" icon?
<ajmitch> mvo: about pbuilder slowdowns - it's repeatedly doing apt-get -s install <large number of packages>
<Amaranth> so i'm thinking inotify is b0rked
<mvo> ajmitch: thanks, let me have a look
<desrt> Amaranth; why would you say this?
<Amaranth> desrt: inotify_test only spits out one event
<Amaranth> desrt: after that it shows nothing until i restart it, then it shows one more event
<desrt> uhm
<desrt> are you doing stuff?
<Amaranth> yes
<Amaranth> touch foo && rm foo
<Amaranth> only the touch shows up
<desrt> is it watching foo?
<Amaranth> it's watching ~
<desrt> hm
<Amaranth> and i'm making foo in ~
<desrt> i don't think inotify is "b0rked" enough to cause gnome-vfs to decide to not use it
<seb128> desrt: yeah, and to be honest I did have to --force-shutdown evolution for some time now with edgy because it locked, I'm wondering if they fixed the frequent lock it used to face
<seb128> Amaranth: does gnomevfs-monitor works fine for you? it does on my desktop
<Amaranth> yep
<desrt> seb128; evolution is in a sad state
<desrt> seb128; all of the people who would be good maintainers for it are burned out from it
<Amaranth> gnomevfs-monitor shows creation and removal
<Amaranth> if gam_server would respond to SIGUSR2 i would be able to tell if it was handling those events
<desrt> gnomevfs-monitor does an alarming number of syscalls
<desrt> i think someone ought to talk to john again about how polling inside a filesystem monitor is evil :)
<desrt> seems to wake up every ~100ms
<desrt> no wonder battery life is so poor :p
<desrt> nautilus is doing this 24/7... waking up every 100ms and doing a whack of syscalls
<desrt> holy crap
<desrt> i wonder if anyone knows about this bug
* Treenaks hears the sound of a LART booting up
<desrt> no lart.  just a friendly bug report :)
<seb128> desrt: please open a bug on bugzilla and Cc him ;)
* Spads unsticks planet ubuntu
<desrt> seb128; i think he watches the component
<desrt> http://bugzilla.gnome.org/show_bug.cgi?id=348748
<Ubugtu> Gnome bug 348748 in Monitoring (inotify) "nautilus wakes up about 10 times a second" [Normal,Unconfirmed]  
<seb128> desrt: ok, cool
<desrt> i think i have a new mantra
<seb128> right, it's assigned to him
<desrt> benm can go around yelling at everyone about memory use
<desrt> i'm gonna go around yelling at everyone about syscalls
<desrt> an idle system should be idle, damnit
* dholbach hugs pitti
<desrt> oo.  battery applet is a prime offender
<desrt> i'll have to fix that or have egg on my face!
* pitti hugs dholbach back, any particular cause? :)
<dholbach> you rock, that's why! :-)
<pitti> *blush* you too!
* ogra hugs pitti too ... just because
* pitti hugs ogra
* pitti hugs desrt as well
<pitti> and the whole crowd
<desrt> hello pitti :)
<Amaranth> (btw, inotify_test is indeed broken, things works fine in pyinotify)
<desrt> it'd be cool if you could strace the entire system
<Amaranth> stupid gam_server though, it's killing my battery :P
<Amaranth> desrt: it's funny that a battery applet actually does evil things to (minorly) reduce battery life
<desrt> Amaranth; i noted the irony in my bug report against myself :)
<desrt> i wonder if maybe gvfs falls back to gamin when inotify runs out of handles
<desrt> has anyone heard anything new about that new netlink socket based file notification api?
<desrt> the impression i get is that inotify seriously sucks and that all attempts to improve it are being fiercely faught against by linus
<desrt> (or so john told me over coffee)
<Treenaks> desrt: 
<Treenaks> desrt: does linus give reasons for this fighting?
<desrt> yes.  they're even good reasons.
<desrt> inotify works by you telling the kernel what inodes you want to watch
<desrt> user processes could theoretically fork many many copies of themselves
<desrt> and file many many watches on files belonging to other users
<desrt> causing file IO done by those users to slow to a crawl
<desrt> so there's a per-user watch descriptor limit
<desrt> the problem is that it's very easy to hit that limit
<desrt> if you have beagle running, for example, you're practically guarenteed to hit it
<desrt> so, as a fallback, because you can't always get an inotify handle, you have to resort to polling
<desrt> it's insane
<desrt> also, because inotify is inode based, there is no way to say "notify me when a file called "/home/desrt/foo/bar/baz is created"
<dholbach> can somebody please get jokosher out of NEW?
<desrt> you have to watch /home/desrt and "foo was created" events
<desrt> then watch "foo" for "bar was created events (and hope you didn't miss one in a race), etc
<desrt> so this is another case where the gnomevfs inotify code polls
<desrt> dholbach; is muine-shell in edgy?
<dholbach> desrt: i have no idea
<seb128> dholbach: that's like your daily question :p
<dholbach> seb128: I didn't ask yesterday.
<Mithrandir> desrt: any idea why linus absolutely wants it to be inode-based?
<desrt> dholbach; better ask twice today, then :)
<seb128> ah, sorry, "almost daily" :)
<desrt> Mithrandir; uhm.... as far as i know he doesn't?
<desrt> Mithrandir; inode-based, i think, was john's design decision
<desrt> Mithrandir; linus only insists on the per-user limits
<desrt> Mithrandir; oh.  i think he also disliked the /dev/inotify business and insisted on syscalls, too :)
<desrt> anyway... it's stupidly past my bedtime.. goodnight, all.
<desrt> seb128; good luck to you.
<dholbach> desrt: sleep tight
<desrt> surely will.  i'm spent!
<desrt> so much ranting :)
<seb128> 'night desrt
<Kamion> pitti: first-stage, but by chrooting, not as a udeb - so I think it does need to be added to the blacklist
<Kamion> pitti: (thanks!)
<pitti> ok
<seb128> Kamion: I don't know if you do NEW processing atm or if that's Keybuk, but the new evolution-data-server has libedataserverui1.2-8 libedata-cal1.2-5 libebook1.2-9 libegroupwise1.2-12 as new binaries (soname changes) (dunno if listing new packages make your job easier)
<seb128> would be nice to direct them to main when they are accepted too :)
<Kamion> seb128: I've accepted the ones that are there
<dholbach> ogra: you might want to subscribe yourself or the edubuntu-bugteam to dia - bug 49386 has a patch, that was not responded too
<Ubugtu> Malone bug 49386 in dia "Export to pstricks work not if locale have wrong separator" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/49386
<seb128> Kamion: ok, thank you
<Kamion> seb128: and you forgot about libexchange-storage1.2-2 :-)
<seb128> ups, right ;)
<dholbach> It'd also be nice if libgucharmap5 and libgucharmap5-dev and gtk2-engines could make their way into main and the distro - I'm going to change the seeds afterwards
<ogra> dholbach, thanks for the heads up, i thought edubuntu-bugs is already subscribed to dia
<dholbach> seb128: and I'll add  gnome-keyring-manager  to desktop - it has been reviewed for main inclusion for a while
<Kamion> dholbach: jokosher done, sorry for the delay
* dholbach hugs Kamion
<dholbach> Kamion: YOU ROCK! :)
* dholbach does the jokosher dance
<Kamion> gucharmap binaries accepted
<dholbach> super, thanks
* dholbach reads up on seeds-on-launchpad
<Kamion> should be easier now than it was; the bound-branch thing is more convenient here than having to remember to push
<Kamion> gtk2-engines binaries also accepted
<dholbach> super - thanks a lot
<dholbach> seed changes done
<dholbach> Kamion: I agree, that was absolutely painless
<seb128> dholbach: sure for gnome-keyring-manager, do you do the other updates like pessulus too?
<dholbach> seb128: hm?
<dholbach> seb128: which updates? pessulus doesn't seem to have a MIR
<seb128> dholbach: pessulus is not to desktop but it's a part of the GNOME desktop, I think we should have it
<dholbach> ogra: you will need pessuls, right?
<seb128> dholbach: since you are taking care of having non-listed things listed now, I though you would do it for pessulus too
<seb128> dholbach: like doing the wiki page etc
<ogra> dholbach, yes
<ogra> dholbach, as well as sabayon
<dholbach> super, somebody else who writes the MIR! :-)))))
<ogra> didnt i do that already ? 
* ogra looks
<seb128> Daniel "I read every single wiki commit" Holbach would have noticed
<dholbach> hahahahahahaa
* dholbach hugs seb128
* dholbach hugs seb128
* dholbach hugs seb128
<seb128> :)
* seb128 hugs dholbach
<ogra> lol, ok
<ogra> i really thought i did that last week :)
<ogra> but its actually not there
<pitti> G0SUB: ping
<rodarvus> pitti, oh, good to know
<rodarvus> I didn't knew if urgency was respected on ubuntu, so decided to follow the debian policy on this upload
<pitti> rodarvus: it doesn't hurt at all
<rodarvus> (though I suspect the debian packaging policy would tell me to use urgency=medium)
<pitti> rodarvus: it might just be interesting to you
<Kamion> it affects apt-listchanges sorting, and users who read changelogs might look at it
<pitti> rodarvus: urgency only affects testing migration; since we do not have testing, it doesn't matter for us
<Kamion> (pretty minor really, of course)
<pitti> rodarvus: hm, good point from Kamion, though
* pitti hasn't used apt-listchanges for ages and never noticed
<ogra> ARGH
<ogra> was LP shut down ? i cant authenticate to get to the wiki 
<Kamion> chinstrap being down temporarily might affect things I guess?
<ogra> meh
<Kamion> though I didn't know the authserver lived there
<ogra> luckily i have a preview in my cache
<Kamion> Malone is accessible
<ogra> "The authentication database is temporarily unavailable. Anonymous access only."
<ogra> is what i get from the wiki
<sivang> morning
<jono> hey
<ajmitch> hi jono 
<jono> hey ajmitch
<slomo_> Riddell: why did you add the splash header to libpoppler-dev? we build the cairo version now, not the splash version
<Riddell> slomo_: it's needed for kpdf
<ogra> iwj, hmm, youre right, the SCP spec doesnt say anywhere that the gui is run by gksu, thanks for pointing
<slomo_> Riddell: that sounds more like a kpdf bug... why would it need the splash headers if there is absolutely no splash functionality anymore? do you have the url to a build log?
<Riddell> slomo_: only on my local machine
<pitti> dholbach: how did you manage to upload two different diff.gz/dsc of jokosher with the same version number? :)
<slomo_> Riddell: ok, i'll take a look at it myself then...
<Riddell> slomo_: of course this might explain why people are complaining that kpdf doesn't work
<slomo_> Riddell: hrm, the qt bindings only support splash it seems... so we must enable both probably...
<dholbach> pitti: they were sitting in NEW and soyuz didn't discard one of them
<ajmitch> pitti: I think it's called soyuz being special
<slomo_> Riddell: i'll care for that :)
<Kamion> dholbach: oh I just forgot to reject the other one
<Kamion> shouldn't make any difference to anything in practice
<Kamion> (since the newest version accepted was greater than the duplicate pair)
<dholbach> *happy* beam
<highvoltage> nice beam.
<slomo_> Riddell: yes, the poppler qt bindings are completely broken when only using cairo... will be fixed with next upload :)
<seb128> slomo_: how will it be fixed?
<slomo_> seb128: by enabling splash and cairo... the cairo stuff is only used in the glib bindings anyway and not in libpoppler itself
<slomo_> seb128: but i have to test it before... that's only theory now ;)
<iwj> ogra: Oh, the SCP UI runs as root ?!
<ogra> iwj, yup, it needs to it kills shh sessions of users :)
<iwj> ogra: Right, well, I suppose if it can run commands as anyone then it's root-equivalent anyway.
<seb128> slomo_: you can't build with both
<iwj> If you didn't need to run commands as users you could have a userv service (or sudo config if you must) for killing ssh sessions or whatever.
<ogra> iwj, yup ... i think thats the key  which i missed to write doen ... also the system dbus will only allow access as uid 0
<ogra> so all that auth stuff ist really relevant (a nice add on though)
<Amaranth> ogra: that's fixable (dbus)
<slomo_> seb128: why? at least configure is able to enable both at the same time
<ogra> *isnt
<iwj> Right.  Write down where that's configured, too.
<iwj> I mean, where it's configured who gets access to the system dbus.
<ogra> well, i dbus indeed
<iwj> Or if it's not a matter of configuration, where it's documented.
<seb128> slomo_: how would you have both used together?
<iwj> ogra: Also, what's all that stuff about S/Key ?
<ogra> i dont understand why i should reference to every possible protocol or mechanism here since we only use the implemented one in dbus ...
<iwj> Are you sure you're going to be using that ?
<ogra> i'm using what the dbus spec proposes as default
<iwj> dbus will use a SASL library so it can do everything our SASL can.
<ogra> which is SASL with SKEY
<iwj> I can't see that in the dbus spec you have a reference to.
<iwj> And it seems wrong really.  S/Key is for one-time passwords.
<slomo_> seb128: the glib bindings use cairo, the others use splash. works fine here at least with evince and pdflatex...
<seb128> slomo_: and what is doing atm?
<ogra> but based on the fact that only root can access a dbus service thats run as root (system bus) its not relevant at all i think ... mind if i wipe the auth stuff completely ? 
<iwj> reference to every possible protocol> Obviously you should provide references for the ones you're going to be using, but not others.
<iwj> ogra: I don't know if it's relevant.  How does it work that only root can access the dbus system bus ?
<slomo_> seb128: the current version disables splash and the qt bindings then have undefined references to the splash stuff (which are not noticed at build time because of no -Wl,--no-undefined)
<ogra> but i dont care what dbus uses ... it will use the same auth it uses for all other system services 
<ogra> thats why i rely on a existing framework with proven security
<iwj> If it does it by having some kind of authentication protocol over the connection to the dbus daemon then you should say that and which protocol it's using etc. (probably by giving a reference to the config file or a manpage or something).
<ogra> i *can* find out how dbus does that, but is it really necessary to describe it detailed because i want to use it ?
<iwj> If it does it some other way then surely it must be documented somewhere ?
<ogra> well, it will use the standard dbus innings 
<iwj> Well, if it's a well-known fact that only root can access the system dbus then fine.
<ogra> ok
<iwj> Just state it.
<seb128> slomo_: if the other don't use splash, not cairo what do they use? it's not really clear ...
<ogra> i'll clean up the spec
<iwj> (But then I'm confused as to how the program-running-as-user can get these please-execute-command messages.)
<ogra> the same way nm-applet gets messages from NetworkManager
<iwj> I know nothing about that.
<ogra> the session bus listens for messages on the system bus ... 
<iwj> Doesn't the session bus run as the user ?
<ogra> the tool thats the listener is waiting for specific namespaced messages
<slomo_> seb128: the qt bindings only use splash but as libpoppler-splash is not build and not statically linked against it it has missing symbols. the glib bindings can use splash but use cairo if it is enabled (or did i misunderstand your question?)
<ogra> yup
<ogra> but the session bus can pick up messages from the system bus
<iwj> So if it runs as the user how can it connect to the system bus which you just told me only root can connect to ?
<ogra> i.e. hal, g-p-m or nm do that
<Mithrandir> iwj: look at /etc/dbus-1/system.d/* for various ACLs for different end points on the system bus.
<ogra> it cant *send* 
<ogra> but it can listen for messages
<iwj> Mithrandir: Thanks, that's the information we're looking for I think.
<iwj> ogra: You should provide references to the access control configuration and documentation.
<ogra> ok
<iwj> You don't have to redescribe everything.
<seb128> slomo_: I just find weird to have the glib bindings using cairo and poppler itself using splash, but if you say that works fine ...
<ogra> i think i had a reference to /etc/dbus-1/system.d/ i te first one before i started to change everything :)
<iwj> Your spec can pretty much assume that people know all about the stuff you're using but you have to provide references so that if they don't know they can go and read something to find out.
<iwj> And a reference to which manpage or dbus doc or whatever specifies the meaning of those files.
<iwj> And you should say whether you plan to change them at all.
<iwj> `We will add a new ACL entry so that ...' or some such.
<ogra> iwj, i was falsesly assuming that people know the existing SCP ... so i didnt add the info about gksudo :)
<ogra> *falsely
<slomo_> seb128: libpoppler itself doesn't use splash or cairo. only the bindings use one of the two
<ogra> the initial spec pointed to /etc/dbus-1/system.d/ ad that services files for auth and namespace are added there, but didnt explain it further
<seb128> slomo_: ok, if you don't break poppler-glib feel free to do any change you want :)
<iwj> ogra: Well, if there had been a reference to the existing SCP specification you might get away with that.  But of course the more specific to your project, or the more obscure, the more you might have to state nonobvious things.
<ogra> yep
<iwj> ogra: Do those files contain access control as well as binding information, then ?
<iwj> That wasn't clear to me.
<ogra> it has a <policy> tag in the xml which enables ACLs
<ogra> see /etc/dbus-1/system.d/nm-applet.conf for example
<ogra> hal.conf is even better it has some finer grained stuff there 
<iwj> *vomit*
<iwj> XML configuration files.
<ogra> heh, yes
<ogra> agreed :)
<Treenaks> iwj: sounds like a webbrowser I know
<iwj> That's _not what xml is for_.
<ogra> Treenaks, dbus rather :)
<iwj> Treenaks: Don't get me started.
<Amaranth> so, uh, if a have a ~/.evil/nm-applet can i get on the system busZ?
<Amaranth> -Z
<ogra> Amaranth, nope
<ogra> the system bus wont read from that
<iwj> ogra: Right, I see now.  I think if you include your proposed system.d file in the spec (or an example of it) then things will be much clearer.
<Amaranth> how does it decide what to allow?
<iwj> It's OK to put important interface definitions and so on in specs.
<ogra> iwj, ok, so i'll add a note about uid 0 and attach the xml ...
<ogra> Amaranth, based on /etc/dbus-1/system.d/ .... where users dont have write access :)
<doko> Riddell: kdelibs4-dev is uninstallable on sparc and powerpc?
<iwj> ogra: And get rid of all that sasl stuff if it's not relevant :-).
<ogra> :D
<ogra> will do that happily :)
<Amaranth> ogra: I know that. :P If /etc/dbus-1/system.d/nm-applet.conf exists would it work though?
<Riddell> doko: it was ok last I tried on powerpc, let me look
<doko> Riddell: http://librarian.launchpad.net/3567531/buildlog_ubuntu-edgy-sparc.openoffice.org_2.0.3-3ubuntu3_FAILEDTOBUILD.txt.gz
<ogra> Amaranth, you cant override the system bus in userspace ... 
<Amaranth> *facepalm*
<Amaranth> dbus considers /usr/bin/nm-applet and ~/.evil/nm-applet to be different things and doesn't allow access to the second one?
<ogra> ah, you mean a separate backend binary ... not a services file
<Amaranth> ogra: yeah, i already have nm-applet installed and it has it's .conf file in place, i just want to abuse the .conf file for my own purposes
<Amaranth> how does it tell the difference between the real nm-applet and my fake one that does evil things like flood the bus
<Amaranth> holy shit it doesn't
<Amaranth> oh, duh
<Amaranth> it lets me connect to the bus but not access anything
<Amaranth> i wonder if i can flood it trying to access things or if that's handled in the client libraries
<ogra> Amaranth, work on your SoC project instead of searching dbus exploits :P
<Amaranth> heh
<Riddell> doko: seems like mesa-common-dev and libgl1-mesa-dev are out of sync
<Riddell> libgl1-mesa-dev: Depends: mesa-common-dev (= 6.5.0.cvs.20060725-0ubuntu1) but 6.5.0.cvs.20060524-1ubuntu1 is to be installed
<ajmitch> Riddell: i386?
<Riddell> yes
<Riddell> or do I have to change the gl depends on qt?
<ajmitch> buildds are still catching up, it seems
<ajmitch> blocked by OOo :)
<doko> OOo doesn't block anything, just underpowered buildd's ...
<ajmitch> doko: that's what I meant, really :)
<rodarvus> yeah, why should two 12 hours build block anything? :)
<rodarvus> hmm, strange, vernadsky is idle -> https://launchpad.net/+builds/vernadsky
<rodarvus> shouldn't it pick the next item in the queue automatically? (or openoffice.org build being for dapper has any effect on it?)
<ogra> rodarvus, ist that crontab driven ?
<rodarvus> could be, but the openoffice.org build finished 9 minutes ago.
<ogra> iwj, spec updated .... i added a note about UID 0 and a commented services file ...
<rodarvus> I don't expect the crontab to take so long to pick up
<Mithrandir> iwj: what's a useful way to debug "firefox doesn't load some pages at all" problems?  For instance. www.brygging.no doesn't work from this machine.  I've tried nuking ~/.firefox and ~/.mozilla.  Also, it seems to affect epiphany.
<ogra> sure thats not a network thing ? 
<ogra> i.e. did you try links 
<rodarvus> Mithrandir, might be the same bug I was bitten when trying to access gmail
<Mithrandir> ogra: yes, it works fine with lynx.
<Mithrandir> rodarvus: which bugs is that?
<rodarvus> edgy firefox has a stripped browser id line
<rodarvus> missing Gecko/2006<something>
<iwj> www.brygging.no> WFM
<rodarvus> I reported it to iwj a few days ago
<rodarvus> (didn't open a LP ticket, though)
<crevette> mee too
<ogra> yes, i see a lot of beer too 
<Mithrandir> it seems to hang after loading a bit of data, but I haven't tcpdumped it yet.
<iwj> I don't think the browser string is relevant here.
<crevette> the bug on gmail exist since end of june
<iwj> Mithrandir: PMTU ?
<iwj> I take it you're not knowingly using any kind of proxy.
<rodarvus> Mithrandir, this page loads successfully here
<rodarvus> (with epiphany and firefox)
<Mithrandir> iwj: it seems to load a bit more when I lowered it from 1500 to 500.  No proxies involved and my provider doesn't do transparent proxying.
<iwj> I think links working is probably a red herring as it doesn't load images.
<rodarvus> (returning to the buildd subject) should I worry about vernadski being idle or is it expected?
<iwj> It sounds to me like you have network problems.
<iwj> I suppose you could try wget -p.
<Mithrandir> iwj: well, dillo works.
<Mithrandir> or, "works".  It renders it quite badly, but it loads in no time.
<iwj> If you set network.http.max-connections to 1 in about:config, does it help ?
<iwj> I don't want to rule out ff being at fault but I'm still with the network problem theory.
<Mithrandir> iwj: doesn't seem to change anything, no.
<chris^> Hi
<chris^> I Have an idear for Edgy and XGL, a little FeatureRequest, where shoud i Post this?
<Kamion> links> try w3m with w3m-img installed
<Kamion> oh, if dillo works then I guess that's moot
<ogra> chris^, likely in the motu channel, but probably not even there since intrest in maintaining XGl is very low there 
<Mithrandir> yeah, I doubt it's my network.  It's been like that on some sites for a few days and !gecko browsers seem to work.
<chris^> ogra: well, I have just the idear, that there shoud be an extra loginsession for XGL per default... 
<ogra> chris^, we wont support XGL so "default" is already out of discussion ...
<chris^> ogra: _default_ if you are installing XGL ;)
<mjg59> ogra: ajmitch was looking at updating the Xgl build last night
<mjg59> Now that we have fresh enough mesa
<ogra> mjg59, oh, really ? 
<ajmitch> ogra: yes, I built a fresh Xgl from the git tree
<mjg59> And I'll try to help rodarvus with aiglx
<ogra> mjg59, what for now that we get xorg 7.1 with all the fun in it ?
<mjg59> ogra: xgl works better with some of the binary drivers
<ogra> ah
<Treenaks> just buy intel ;)
* ogra didnt know ... 
<mjg59> Yeah
* mjg59 engages in mad intel pimpage
<ajmitch> Treenaks: that works for my laptop, but not my nvidia-using desktop box
<seb128> we have tried on #ubuntu-desktop to push that guy uslab to get people working on some xgl ubuntu packages out of ubuntu, contributing directly to universe yesterday  
<maswan> Mithrandir: sure it isn't something silly like full $HOME or /tmp or so?
<maswan> Mithrandir: In my experience, mozilla-based stuff gets lots of weird error modes as soon as something like that happens.
<Mithrandir> maswan: 742MB free, so nope.
<rodarvus> 742mb? I would become quite claustrophobic with that amount of free space on any partition :)
<ogra> rodarvus, how much do you need to feel comfortable ? 
<ogra> 1TB ?
<Mithrandir> rodarvus: you're not my web browser. :-P
<rodarvus> I need enough to uncompress/build large stuff without worrying
<rodarvus> 10-20gb is ok
<rodarvus> Mithrandir, :)
<Robot101> 1.4G free
* Robot101 shudders
<hungerW> rodarvus: I have /tmp for that.
<ogra> oh, i just ran df -h for the first time on this knot 1 install 
<ogra> /dev/evms/hda3         46G  1,8G   42G   4% /home
<rodarvus> hungerW, I work all day long doing packaging. I can't risk putting this stuff in /tmp
<ogra> do we default to evms now ?
<ogra> i surely havent selected that during install
<Kamion> no
<rodarvus> my /boot was moved to /dev/evms recently too
<ogra> hmm, how did i get there then ? weird ...
<Kamion> I suspect the fstab migration (libvolumeid0) went a bit nuts
<ogra> heh
<Kamion> look at /etc/fstab
<Kamion> also perhaps mount-by-UUID is getting things wrong
<rodarvus> O_O
<ogra> WOAH
<Kamion> ?
<rodarvus> rodarvus@wakko:~/canonical/code/merges/seven-dot-one/done$ wc -l /etc/fstab
<rodarvus> 71 /etc/fstab
<rodarvus> rodarvus@wakko:~/canonical/code/merges/seven-dot-one/done$
<ogra> # /dev/hda3 -- converted during upgrade to edgy
<ogra> UUID=7c24e63d-e8f7-4738-93f5-a63edd2c641a /home ext3 defaults 0 2
<Kamion> rodarvus: is it full of environment variables?
<rodarvus> yes
<Kamion> rodarvus: if so, delete all those; I fixed that yesterday morning but there's no sane way to deal with people who upgraded through the breakage
<rodarvus> *nods*
<rodarvus> Kamion, thanks
* ogra assumes he should read up about UUID
<Mithrandir> the migration broke for me, but I'm using evms, so.
<Kamion> ogra: UUID= is normal, but try 'blkid -t UUID=7c24e63d-e8f7-4738-93f5-a63edd2c641a'
<Kamion> ogra: it returns stray evms crap for me too
<Kamion> so I suspect something's wonky in libblkid
<ogra> well, it returns two lines for me
<Kamion> bug Keybuk about it when he wakes up
<ogra> one with and one without evms
<Kamion> right, likewise
<Mithrandir> Kamion: for extra winnage::
<Mithrandir> : tfheen@golem ~ > blkid -t UUID=e956b7b4-6ebf-4bd4-98ac-ffa52eb26028
<Mithrandir> /dev/evms/.nodes/lvm/lvm0/home0: LABEL="home0" UUID="e956b7b4-6ebf-4bd4-98ac-ffa52eb26028" SEC_TYPE="ext2" TYPE="ext3"
<Kamion> so, it's probably harmless and will be sorted out once the blkid bug is fixed
<ogra> lol
<Mithrandir> and trying to open that gives an error.
<ogra> seems to be harmless given i didnt recognize it until looking at df
<Kamion> we shouldn't be UUIDing LVM anyway, as some bug report pointed out
<Kamion> that probably goes for EVMS too, not sure
<Mithrandir> on-disk format of LVM and EVMS is the same.
<rodarvus> infinity, ping
<cprov> infinity: buildd-sequencer is stopped, buildds can't resolve librarian name.
<elmo> cprov: that was a temporary thing
<elmo> for like 10-15 mins top, 3 hours ago
<elmo> it should be fine now - can you restart it or otherwise kick it?
<elmo> (or do I need to?)
<cprov> elmo: yes, let's try
<cprov> elmo: looks like happening again, check last lp-error mail.
<elmo> cprov: let's take this to ##soyuz1.0
<cprov> elmo: okay
<infinity> rodarvus: pong?
<rodarvus> infinity, solved now, thanks
<infinity> Okay, good, cause I'm tired. :)
<rodarvus> infinity, buildds were mostly idle
<rodarvus> due to dns failure on the DC
<rodarvus> cprov and elmo fixed it
<rodarvus> infinity, go take some rest :)
<iwj> What happened to the `is the hardware clock set to GMT' question ?
<zul> can someone new xen-source-2.6.16 when they get a chance please thanks
<ogra> iwj, probably dropped for people sitting near greenwitch ? :)
<maswan> ogra: but greenwitch doesn't run on GMT though, right? :)
<ogra> pfft ...
* mdke shivers at the prospect of a green witch
<ogra> :)
<Mithrandir> mdke: you prefer blue witches?
<mdke> Mithrandir: pink
<Vhata> sand witches
<doko> infinity, cprov: are there some estimates/docs, how long it does take from an upload to upload.u.c until the binary packages appear in the archive (ignoring the build times)
<jjesse> mmmmm sandwidch
<pitti> Mithrandir: do you have some time today to peer review a PAM code snippet?
<Mithrandir> pitti: sure.  Now?
<pitti> Mithrandir: I just wrote a setgid shadow helper program for cups pam authentication
<pitti> Mithrandir: whenever you have time
<Mithrandir> pitti: I can do it now; do you have an URL or bzr repo?
<pitti> Mithrandir: http://people.ubuntu.com/~pitti/tmp/cups_check_pam_auth.c
<pitti> Mithrandir: I designed it that way: cups writes 'username\0password' to stdin of that program
<pitti> Mithrandir: and the return code determines whether it's succeeded or not
<joejaxx> haha it seems rm -rf does not work on my system anymore 
<pitti> Mithrandir: gcc -Wall -W cups_check_pam_auth.c -lpam
<Kamion> iwj: it's still asked under many circumstances, but not always
<pitti> Mithrandir: echo -ne "foo\0bar" | sudo ./a.out
<Mithrandir> pitti: this'll be gid shadow and uid cupsys with mode 2750?
<pitti> Mithrandir: of course eventually setgid shadow will suffice (I intend it to be cupsys:shadow 2744)
<Kamion> (it last changed in May)
<iwj> Kamion: May> Hmm.  It seems to be getting the answer wrong for me, eg on a dapper D-I install.
<pitti> Mithrandir: 2754 works too, of course, 2744 is just paranoid
<Kamion> iwj: details?
<Kamion> iwj: the default may be wrong; that's fine as long as it's asked
<Kamion> if Windows or another OS that requires the hardware clock to be in local time is installed, then it defaults to local time and doesn't ask
<Mithrandir> oh, nice, you don't have to be root to mlock any more.  (Up to RLIMIT_MEMLOCK, at least)
<Kamion> otherwise it defaults to UTC and asks
<pitti> Mithrandir: right
<iwj> Kamion: Ah, it's probably seeing the W98SE that's sitting around on this disk.
<pitti> Mithrandir: that's why we could un-setuid gnupg since warty
<iwj> That's unfortunate because the hardware clock is in UTC and obviously I don't care about 'doze's clock.
<pitti> Mithrandir: (some of the sanity checks are not necessary, I just want to be on the safe side)
<Kamion> you can preseed clock-setup/utc=true to work around that
<Mithrandir> pitti: won't sizeof always return something which is ssize_t?
<pitti> Mithrandir: not sure about whether it's size_t or ssize_t
<Kamion> should be size_t
<pitti> Mithrandir: it would be more logical to be size_t
<Mithrandir> pitti: hmm, it seems like you should make sure both input values are null-terminated.  As it is, you can end up not reading all the input.
<pitti> Mithrandir: how so?
<Mithrandir> it's a kinda a contrived case, but it bit us in usplash, for instance.
<pitti> Mithrandir: if I read more than or equal to sizeof(buffer), I abort with 'input overflow'
<bddebian> Hello
<Mithrandir> yes, I'm not talking about that case.
<Mithrandir> pitti: think a program which does write(fd, "username\0", 9); write(fd, "password", 8);
<pitti> Mithrandir: oh, I see
<pitti> Mithrandir: I thought read() would block until eof is reached
<pitti> Mithrandir: as long as the requested size is not yet read
<pitti> if it doesn't, that makes things much more complicated
<iwj> root@samual9:/# wc -l /boot/grub/menu.lst
<iwj> 11028 /boot/grub/menu.lst
<iwj> ROTFL
<Kamion> pitti: it won't necessarily, no
<iwj> Maybe that's why my grub isn't working.
<Kamion> don't tell me grub has a limit?
<Mithrandir> iwj: wow.
<Mithrandir> 11k lines sounds a bit excessive.  Sure you don't hit the 640KB limit?
<pitti> Mithrandir: (I added some documentation bits and re-uploaded)
<ogra> wow, how many kernel entries do you have with 11k lines
<iwj> root@samual9:/media/hda8/boot# wc grub/menu.lst
<iwj>  11028  47216 351671 grub/menu.lst
<Mithrandir> pitti: just require both to be null-terminated and abort if you haven't seen two nulls before hitting the maximum size of your input buffer?
<iwj> title           debian (on /dev/hda5) (on /dev/hda7) (on /dev/hda8) (on /dev/hda
<iwj> 9) (on /dev/hda8) (on /dev/hda7) (on /dev/hda9)
<zul> ogra: migth want to clean that up a bit 
<pitti> Mithrandir: I'd rather read data in a loop until I hit EOF
<pitti> Mithrandir: but your's works as well, of course
<iwj> You are lost in a twisty maze of grub menus all alike!
<pitti> Mithrandir: I think I'll do both
<Kamion> heh, I should really fix grub-installer not to do that
<Kamion> it gets a bit insane after a while
<Kamion> very useful for people who don't have ten installs ...
<iwj> I think this might just possibly be why it doesn't boot.
<bddebian> Kamion: What do I do about the rejects on those fakesysnc because of SHA1 sums?
<Kamion> bddebian: well, you can't get the Debian .orig.tar.gz in the archive; we only ever have one file with a given name
<Kamion> bddebian: so you need to compare the Debian and Ubuntu .orig.tar.gzs
<Kamion> bddebian: it may well be that there are no interesting changes, and the upload will do just fine with the Ubuntu .orig.tar.gz
<Kamion> bddebian: in which case you should upload a build1 built with the *Ubuntu* .orig.tar.gz and no -sa
<Mithrandir> pitti: you're aware that you're disallowing blank passwords?
<pitti> Mithrandir: yes
<Kamion> bddebian: if the .orig.tar.gz files are materially different, that's harder - probably best to apply the relevant differences to the Ubuntu diff in that case
<Kamion> but either way, you must upload with the Ubuntu .orig.tar.gz, and no -sa
<bddebian> Kamion: OK
<bddebian> thanks
<Kamion> (In either case, whoever didn't use the pristine upstream tarball in the first place should be LARTed, assuming there was such a pristine tarball available.)
<bddebian> Gloubiboulga: ping?
<Gloubiboulga> bddebian, pong
<bddebian> Gloubiboulga: You maintain prismstumbler?
<Gloubiboulga> bddebian, not really, but the menu entry needs some love :)
<bddebian> Gloubiboulga: There are a few new upstream releases
<bddebian> I'm trying to build 0.7.3 but the build system has changed quite a bit
<bddebian> I don't even see a make install anymore
<Gloubiboulga> the debian maintainer hasn't updated his package I guess?
<bddebian> Oh sorry, for some reason I thought I saw you as the Debian maintainer.. Duh..
<Gloubiboulga> I don't maintain packages in debian (yet)
<iwj> Kamion: can I chase someone about NEW for zul's xen-source-... et al ?
* bddebian wonders why he cares..
<Mithrandir> pitti: I can't poke any holes in it, I think.  The conversion function's implicit assumption about message styles is a bit unfortunate, but I understand why it's done and agree it's not a problem.
<pitti> Mithrandir: thanks for the review; I'm a bit stunned about read(), though; if I just sit around retrying to read if read returns 0, I'm stuck forever with above test command
<pitti> Mithrandir: either bash does not close stdin when the echo command finishes, or read() does not fail with EBADF if stdin is EOFed
<Mithrandir> pitti: make both be null-terminated, then?
<pitti> Mithrandir: how does that help me?
<Mithrandir> once you read the second NULL byte you know you're done and can continue.
<pitti> hm
<pitti> feels a bit unclean, but I guess I have to live with that
<pitti> it'll mean the process sits around forever if it never receives two NULs
<Mithrandir> why is that a bigger problem than cat sitting around forever unless it receives an EOF?
<pitti> hm, true
<iwj> Kamion: Is there a bug already about the exponentially multiplying menu entries, or should I file one ?
<iwj> I've retitled bug 54041 to be the report that grub crashes if the menu is too long.
<Ubugtu> Malone bug 54041 in grub "grub stage2 crashes if too many menu entries" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/54041
<Kamion> iwj: yes, bug 26031
<Ubugtu> Malone bug 26031 in grub-installer "grub menu contains "combinatorial expansion" of existing installations" [Medium,Needs info]  http://launchpad.net/bugs/26031
<iwj> I'll faff with that then, thanks.
<Kamion> (pointlessly needs-info, -> confirmed)
* StevenK waits for the i386 buildds to catch up.
<Kamion> ok, that's revive-tasksel implemented bar the shouting^Wapplication of Launchpad patch
<Kamion> infinity: you should be able to get going on ubuntu-server-tasks now, if you like; see the existing dns-server and lamp-server examples in the seeds
<thom> Kamion: as an entertaining side note, the partitioner _really_ doesn't like not having any disks
<Kamion> once we've tested the new code I'll remove the LAMP server boot option.
<Kamion> thom: fixed in edgy
<Kamion> we noticed that just before knot-1
<thom> ah, cool
<Kamion> combination of bugs in disk-detect and partman-auto
<thom> heh, right
<thom> i mean, i like blue. but forever is a bit long to stare at it ;-)
<pitti> Mithrandir: new version is up; another look is appreciated
<dholbach> Kamion: hum.... did you make that change to the seeds? i added  gnome-keyring-manager  to it as well (in the same commit), but can't see it in the ubuntu-meta changelog
<pitti> Mithrandir: (echo -ne 'martin\000'; sleep 1; echo -ne 'secret\0') | sudo ./a.out <= works fine now, broke before
<pitti> (yay for my consistent quoting of NUL bytes)
<Mithrandir> pitti: looks correct to me
<pitti> Mithrandir: great; thanks for the review
<Mithrandir> np
* pitti smells the time when he can close all these damn 'web interface iz broken' bugs
<Kamion> dholbach: gnome-keyring-manager hasn't been promoted to main yet
<dholbach> ahhh! ok
<Kamion> dholbach: your change worked fine, but the promotion needs to happen before ubuntu-meta picks it up
<dholbach> can somebody promote it to main please? :)
<Kamion> after this publisher run, yes
<dholbach> thanks a lot
<Kamion> Seveas: please stop rejecting bugs on my packages
<Kamion> thanks
<Seveas> Kamion, err, when did I?
<Kamion> Seveas: bug 53656
<Ubugtu> Malone bug 53656 in user-setup "user-setup insists on creating a user" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/53656
<Kamion> if you do reject them, at least subscribe to the bug so that you can be argued with if you're wrong
<Seveas> Kamion, I read ubuntu-bugs so I don't subscribe to bugs. And I rejected it because the user said "bug is bogus"...
<Kamion> the user was mistaken; deciding whether to reject the bug is best done by somebody who knows the code
<Kamion> and the user himself asked for further action anyway
<Kamion> so basically please don't be so hair-trigger on the reject button
<Lathiat> hrm edgys stuck on 'waiting for root device', any way around that?
<Zdra> seb128: is it normal nautilus doesn't runs bugbuddy when it crash and I want to report the stack trace ?
<seb128> Zdra: "and I want to report the stack trace"?
<seb128> do you get the "app has crashed..." dialog?
<Zdra> I can reproduce a crash, I click on "informer les developpeurs" to start bug buddy but it doesn't start...
<dholbach> Zdra: is that on dapper or on edgy?
<Zdra> edgy
<dholbach> are the versions of libgnomeui-0 and bug-buddy 2.15.90-0ubuntu1?
<Zdra> oh... bug-buddy is taking 100% CPU :p
<seb128> dholbach: no they are not, he would not get that dialog other way
<seb128> dholbach: the "informer les developpeurs" has been dropped with libgnomeui 2.15.90
<seb128> Zdra: ah, not good :)
<dholbach> ah, yes - seb128: i just wanted to know if he has one new version and one old version
<Zdra> bug-buddy-2.15.0-0ubuntu1 and libgnomeui 2.15.2-0ubuntu1
<seb128> bug-buddy 2.15.0 had issue to recognize a bunch of apps, dunno if nautilus if one of them
<seb128> I think it was
<seb128> but you should get a dialog saying the app is not known
<seb128> the upgrade to 2.15.90 should fix that
<seb128> it has been uploaded yesterday, so it should be available now or soon
<Zdra> seb128: ok I upgrade... and I have my call stack of the crash with gdb :)
<seb128> Zdra: according to launchpad it has built everywhere excepted sparc ... what arch do you use?
<seb128> Zdra: ok, good :)
<mdke> Spads: got a mo quickly?
<Spads> mdke: Sure, what for?
<Zdra> seb128: bug-buddy works after the upgrade, thanks :)
<seb128> np :)
<mjg59> rodarvus: Around?
<allee> hi, updating edgy: volumeid, idev initramfs-tools update /boot/initrd.img but only for the running -686 kernel, not the also installed -386 kernel.  Somehow this seem to be wrong
<Zdra> when I "apt-get source nautilus" are ubuntu's patch in debian/patches applied automatically ? Or should I apply them myself ?
<seb128> Zdra: you have to apply them
<mjg59> Zdra: They get applied at build time, not extraction time
<seb128> Zdra: you get the upstream source and a debian dir, the patches are applied when building the package
<Zdra> seb128: ok so https://launchpad.net/distros/ubuntu/+source/nautilus/+bug/54162 is an ubuntu bug
<Ubugtu> Malone bug 54162 in nautilus "Crash when DnD bookmarks in places sidebar" [Untriaged,Unconfirmed]  
<seb128> Zdra: "debian/rules apply-patches" if you want to just apply them
<seb128> Zdra: if you say so
<Zdra> 06_documents_place.patch --> has to be updated
<hungerW> Was gtk2-engines-* removed in edgy or are they just not up to date yet? apt wants to remove them when updating gnome-themes at the moment.
<seb128> Zdra: API change?
<iwj> mvo: Will your dist-upgrader be able to arrange to upgrade dpkg first (or nearly first) during dapper -> edgy upgrades ?
<dholbach> hungerW: it should install gtk2-engines
<Zdra> seb128: I made some changes in nautilus-places-sidebar.c for DnD of bookmarks
<dholbach> hungerW: ubuntu-desktop will pull it in instead
<seb128> -add_place (GtkListStore *store,
<seb128> +add_place (NautilusPlacesSidebar *sidebar,
<seb128> right
<Zdra> I'm trying to update the ubuntu's patch to see if I can solve the problem
<seb128> that's what I call and API change :p
<hungerW> dholbach: Yep and it wants to deinstall gtk2-engines-clearlook and lots of others.
<mvo> iwj: not right now, but if that is a requirement it could be added 
<dholbach> hungerW: that's ok, they were merged
<tseng> removnig gtk2-engines wont break anything for now
<iwj> mvo: OK, yes, it will be a requirement.  So that I can tell people to start using Breaks.
<seb128> Zdra: sidebar->store replaced by "sidebar" then?
<tseng> lots of nice themes left around
<iwj> mvo: Thanks.
<mvo> iwj: ok, please file a but about it and give it some priority - otherwise I may forget about it
<iwj> Willdo.
<seb128> Zdra: what version of Ubuntu do you use (does it apply to dapper too?)? 
<Zdra> seb128: no the change was commited to nautilus 2.15.90
<Zdra> in upstream
<Zdra> see upstream bug linked in my report on lp
<seb128> Zdra: ok, thank you, I'm going to replace "sidebar->store" by "sidebar" now, that's the correct fix, right?
<Zdra> seb128: it should fix, but wait I'm reading it more carefully to be sure there is nothing else to change... sidebar->store may be replaced by sidebar->filter_model in some places
<seb128> ok
<bddebian> Holy crap, there is a 30K difference in orig.tar.gz between Debian and Ubuntu for kiki
* sladen hands bddebian a copy of debdiff
<Zdra> seb128: ok for me, just replace sidebar->store by sidebar in add_place calls
<bddebian> sladen: I know that, I'm just trying to figure out what to do about the SHA1 sums mismatch
<sladen> bddebian: oh, orig.tar.gz ;  how does an md5sum of the /unpacked/ contents compare?  eg.  gunzip -cd foo.orig.tar.gz | md5sum
<seb128> Zdra: thank you for pointing it!
<bddebian> sladen: Compare in what way?  The md5sums are different, if that is what you are asking
<Zdra> np
<sladen> bddebian: I'm asking the md5sums of the /uncompressed/ contents.
<bddebian> sladen: I know
<bddebian> bdefreese@bdubuntu1:~/edgy/kiki$ gunzip -cd kiki_0.5.6.orig.tar.gz | md5sum
<bddebian> ff536c386278040fd51dba12c75621b0  -
<bddebian> bdefreese@bdubuntu1:~/edgy/kiki$ gunzip -cd ubuntu/kiki_0.5.6.orig.tar.gz | md5sum
<bddebian> 2150bc6d2e3b5f21ecc63674cf751d8e  -
<sladen> bddebian: if the tarball has been repacked, then the result file will likely be a differing size
<sladen> bddebian: funky.  What happens if you unzip both of them and do a diff -r between them?
<iwj> mvo: OK, I give up, what's the package name ?
<bddebian> sladen: Thanks, give me a sec
<Kamion> dholbach: gnome-keyring-manager promoted
<dholbach> woohoo! :)
<bddebian> Heya dholbach
<dholbach> hey Barry
<mvo> iwj: file it against update-manager please
<doko> pitti: do you want to get a UVF for blender and merge that one? python policy ...
<pitti> doko: oh, hm, if we need it
<pitti> doko: I don't have time for merging now, but I can do it this week
<doko> pitti: no haste, would be nice ...
<bddebian> sladen: OK, now that's freaky:
<bddebian> bdefreese@bdubuntu1:~/edgy/kiki/temp$ diff -r debian/kiki-0.5.6.orig ubuntu/kiki-0.5.6.orig
<bddebian> Only in ubuntu/kiki-0.5.6.orig: kiki-0.5.6
<bddebian> bdefreese@bdubuntu1:~/edgy/kiki/temp$
<sladen> bddebian: what's in that file?  has somebody unpackaged the package inside itself?
<pitti> YAY @ cups
<iwj> Oh, up_date_ not up_grade_.
<iwj> And there's me searching in LP for `upgrade' and getting >200 hits.
<bddebian> sladen: Yep, in the ubuntu version there is kiki-0.5.6.orig/kiki-0.5.6
<sladen> bddebian: if in doubt, do a fresh upload with the .orig.tar.gz from debian rediff it
<bddebian> sladen: That's what I did but it fails so I am going to upload with our orig.tar.gz but the diff.z and .dsc from Debian.  That is correct right Kamion?
<sladen> bddebian: I would guess that's the opposite way around?
<bddebian> sladen: 
<bddebian> <Kamion> bddebian: well, you can't get the Debian .orig.tar.gz in the archive; we only ever have one file with a given name
<bddebian> <Kamion> bddebian: so you need to compare the Debian and Ubuntu .orig.tar.gzs
<bddebian> <Kamion> bddebian: it may well be that there are no interesting changes, and the upload will do just fine with the Ubuntu .orig.tar.gz
* bluefoxicy clicks on update notification icon and it starts synaptic.  Promptly wtf's at it.
<ogra> dholbach, ubuntu-artwor split ? whats the other package ? 
<ogra> *artwork
<dholbach> ogra: they're in NEW
<dholbach> ogra: the others will be named: edgy-community-wallpapers edgy-gdm-themes edgy-session-splashes edgy-wallpapers gray-theme human-cursors-theme human-gtk-theme human-icon-theme human-theme industrialtango-theme legacyhuman-theme outdoors-theme resilience-theme silicon-theme
<ogra> ugh ... do i need to reflect that in edubuntu-artwork ? 
<dholbach> ogra: that's your decision
<ogra> ok, then its fine ...
<dholbach> your the package maintainer :)
<dholbach> s/your/you're
<ogra> even though i need to know what is in wich package :)
<ogra> but i'll dig through :)
<dholbach> once they're in the archive, i'll link the branches to the packages
<Kamion> zul_: at some point, could you convert xen-3.0 to the new Python policy, please? (Thoough I've accepted the binaries in the meantime.)
<dholbach> they're all in bzr in launchpad already
<ogra> i wonder if using the release name is such a good idea ... that forces us to have a new set of packages in the next release in any case ...
<dholbach> ogra: that will give us the chance to offer people "dapper-artwork" if they like it better
<Kamion> I agree, that seems a dubious design decision
<dholbach> ogra: that was a common request
<ogra> (but this time you're the ackage maintainer indeed ;) )
<ogra> *package 
<Kamion> can't we have distinct names that aren't release names?
<ogra> s/edgy/default/ ?
<dholbach> hmhmhmhmhm, that'd mean inventing package names, hm
<ogra> you could have an edgy artwork metapackage with a versioned dependency ...
<Kamion> ogra: no, that would mean having to rename default to something else in edgy+1 and introduce a new default
<ogra> Kamion, yes, thast the point
<ogra> *thats
<ogra> i'm guessing we'll have new default artwork in edgy+1
<Kamion> ogra: seems undesirable
<Kamion> I'd prefer not designing something that requires packages to be renamed every release
<Kamion> introducing new names is one thing, always having to rename the old thing out of the way first is another
<ogra> thats why i said default-{wallpapers,session-splashes,etc}
<ogra> why do yu need to renale ? 
<ogra> *rename
<ogra> ubuntu-artwork wasnt renamed since warty and always contained the default...
<Kamion> we've never kept the old artwork around before though, at least not in separate packages
<ogra> right 
<Kamion> I have no objection to there being a package that depends on whatever the current default artwork is, obviously
<ogra> so the plan is to kepp the old ones ?
<ogra> *keep
<Kamion> that's what dholbach said
<dholbach> ok, so you suggest, i drop the 'edgy-' bit and preserve changes in a 'dapper-*' package once I do the change?
<Kamion> I don't like having release names in packages at all, personally
<dholbach> hm
<Kamion> what's in edgy-*?
<dholbach> i wanted to server the goal of still "having the old artwork" - since some people wanted to have that.
<Kamion> is it just dependencies on the current default, or does it have artwork in it?
<dholbach> it has artwork
<Kamion> is there no way to give that collection of artwork a name?
<Kamion> or is it really just "The Edgy Artwork"?
<Kamion> if the latter, I guess edgy-* would be ok, I'd reluctantly withdraw my objection
<dholbach> it is the edgy artwork, there was no 'meta name' given to it - ok, there was the 'Human look', but the community artwork stuff wouldn't qualify as Human, and I'm not sure that the edgy artwork will not be 'Human', even if it looks different
<Kamion> ok, I see
<dholbach> I'm happy for suggestions and not insisting on the packaging names, not all.
<ogra> ..." but the community artwork stuff wouldn't qualify as Human" ...
<ogra> call it inhuman then :P
* dholbach strangles ogra in a inhuman way
<ogra> actually shouldnt we just use release numbers and avoid the working names ? 
<ogra> egdy wallpapers .... the nervous backgrounds :)
<dholbach> that's fun, if we delay a release again ;)
<ogra> yeah, indeed
* dholbach -> break
<bluefoxicy> I have a very strange question.  How in the crap does exim keep getting installed
<bluefoxicy> I keep removing it (it never says anything depends on it) and it just comes back on an upgrade several weeks later.
<mdke> bluefoxicy: likely you have something which requires an MTA. Best try #ubuntu for questions like that though
<bluefoxicy> mdke:  apparently I don't because I can just remove it and it doesn't complain about other packages.
<bluefoxicy> (I've already removed it)
<Spads> are you maybe removing the metapackage only?
<bluefoxicy> 'exim' seems to ask to remove undelivered mail when removed and also removes /etc/cron.d/exim
<ogra> dholbach, gtk2-engines "Resynchronized with Debian, no Ubuntu changes." means it doesnt have a "Provides gtk2-engines-clearlooks" ?
<Spads> bluefoxicy: dpkg -l 'exim*' and remove anything you don't want
<Spads> bluefoxicy: but yeah, #ubuntu is better for this
<bluefoxicy> Spads:  none installed.
<bddebian> Yeah, it worked
<bluefoxicy> Spads:  yeah, I'd ask in Ubuntu except nobody there is going to tell me why apt just decides "let's also install this new package on an 'upgrade', and not say it's new"
<ogra> bluefoxicy, still, this isnt a support channel (see topic ;) )
<bluefoxicy> ogra:  nods.  I'll come back when apt spouts half of universe for no reason then.
<desrt> pitti; ?
<ogra> ogra, come back if you have a fix for the prob and provide a patch ;)
<ogra> err
<bddebian> hehe
<ogra> s/ogra/bluefoxicy/ (indeed)
<desrt> pitti; you probably want to look at https://launchpad.net/distros/ubuntu/+source/openssh/+bug/54180
<Ubugtu> Malone bug 54180 in openssh "[rfe]  sshd ought to support 'none' cipher" [Untriaged,Unconfirmed]  
<bluefoxicy> ogra enjoys talking in third person, and should write man pages so that he can write about himself in the AUTHORS section  :)
<ogra> yay
<Kamion> desrt: me
<Kamion> meh
<Kamion> that's an ancient bug which upstream is not interested in doing
<dholbach> ogra: they were merged in Debian. There are no Provides there.
<desrt> Kamion; i know upstream isn't interested
<desrt> Kamion; i was hoping for a vendor patch
<Kamion> re bug, huh? it's not a matter of enabling it, it needs non-trivial code last I checked
<ogra> dholbach, i talked with seb128 about it ... but i can change the ltsp deps ... its just a little unfortunate that i have to install all of them on a extreme low end system
<desrt> Kamion; the current situation forces people to do much less secure things.... like xhosts +
<desrt> Kamion; last time i enabled cipher none it was a switch-flip
<Kamion> blowfish is fast enough for most purposes
* ogra thinks we should patch out xhost of X one and for all
<Mithrandir> ogra: uh, are you on crack?
<bddebian> hehe
<ogra> Mithrandir, who needs that ? in times of ssh X forwarding anyway :)
<Kamion> desrt: see Michael Stone's comment in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=13389
<desrt> ogra; people who want performance
<Kamion> (I realise there's a patch there)
<ogra> desrt, blowfish isnt bad ... we run a full ltsp implementation with it :)
<Kamion> (but it's not just a switch-flip and I'd be surprised if it still applied verbatim)
<Mithrandir> : tfheen@thosu ~ > xhost +SI:localuser:test
<Mithrandir> localuser:test being added to access control list
<Mithrandir> : tfheen@thosu ~ > sudo -u test xdpyinfo
<Mithrandir> Password:
<Mithrandir> name of display:    :0.0
<desrt> hmm.  was a switch-flip back in the day.
<Mithrandir> etc
<desrt> damn upstream ssh.  those cats are getting catty
<Kamion> desrt: I suspect that "back in the day" was SSH1 protocol
<Kamion> SSH2 is completely different
<desrt> you're probably right
<Kamion> desrt: IIRC one of the concerns about none is that it causes authentication to happen in plaintext too
<pitti> re
<Kamion> which is not what everyone expects
<bddebian> wb pii
<bddebian> Err pitti
<pitti> desrt: hmm
<janimo> mvo: hi, which is the best g-a-i bzr branch to base new work on? the ones in LP don;t seem up-to-date
<Riddell> carlos: what's your answer to this? http://lists.kde.org/?l=kde-i18n-doc&m=115313298518227&w=2
<Riddell> how do ubuntu translation teams find out about their upstream
<mvo> janimo: please use http://people.ubuntu.com/~mvo/bzr/gnome-app-install/gai--main/
<ogra> heh, you sill have bazaar urls :)
<carlos> Riddell: let me read the email...
* mvo slaps ogra
<carlos> Riddell: https://launchpad.net/products/rosetta/+bug/87
<Ubugtu> Malone bug 87 in rosetta "Some upstream translators asked for links to GTP, KTP and GNUTP" [Medium,Confirmed]  
<carlos> Riddell: so no, we don't have yet implemented
<Keybuk> *sigh*
<Keybuk> it really occurs that autoconf/make/etc. need to die
<carlos> Riddell: and yes, we should
<Riddell> carlos: good enough answer though, thanks
<Keybuk> KB of foolery just to install a png in the right place
* Riddell knows of a large project that has got rid of autoconf/make/etc
<Keybuk> Riddell: yeah, but they replaced it with unsermake
<Riddell> Keybuk: changed to CMake now (in trunk)
<Keybuk> cmake also replaces make. no?
<Keybuk> which seems foolish
<hub> it does
<hub> replace make
<hub> cmake is aimed at providing a consistent and configurable build system
<Riddell> hub: does it generate Makefiles?
<Riddell> doesn't
<Keybuk> see, that bit I don't understand
<Keybuk> make is well understood, flexible and *works*
<doko> infinity, cprov, whoever: please requeue openoffice.org 2.0.3-3ubuntu3 on amd64, sparc and powerpc; the b-d's should be in place
<hub> Riddell: you probably know better than I do
<hub> maybe I'm wrong
<Riddell> hub: nope, I've not looked at trunk :)
<hub> hold on, I have trunk here
<Riddell> but as far as I know CMake generates Makefiles and uses normal make
<hub> "CMake generates native makefiles and workspaces that can be used in the compiler environment of your choice."
<Keybuk> I've always thought the perfect system would be one written in make
<hub> so yes
<Keybuk> so you don't need to generate anything
<hub> Keybuk: we had a build system entirely based on GNU Make in AbiWord. A huge PITA to maintain
<hub> Keybuk: we now use automake :-)
<hub> and I have ported it 3 or 4 times
<Keybuk> hub: why would it be a PITA?
<Keybuk> you can implement automake using GNU make
<Keybuk> the only difference is the need to include automake.mk or something at the top
<hub> Keybuk: try to build on anything that is not linux
<Keybuk> hub: who cares about building on anything that doesn't have GNU make?
<Keybuk> seriously, when did you last bother with AIX 2 ?
* Spads once wrote a whole packaging system in GNU Make
<hub> Keybuk: in our case we did. We required GNU Make
<Keybuk> the world today is Linux, BSD and Solaris
<ogra> Keybuk, /dev/evms/hda3         46G  1,8G   42G   4% /home are you aware of this ? (i dont use evms, seems a UUID problem)
<Keybuk> ogra: yes, and I don't care <g>
<ogra> oh ? 
<ogra> why that ? 
<hub> Keybuk: the world today is a melting pot of everything
<Keybuk> I know nothing about evms, someone who does can fix that
<Keybuk> hub: disagree
<hub> Keybuk: AIX is painful anyway
<hub> Keybuk: 95% of the world PC run MSFT Windows
<hub> do we bother?
<Keybuk> I'd disagree with that 95%
<cprov> doko: ia64 as well ?
<ogra> Keybuk, i dont think thats an evms problem :)
<Keybuk> ogra: it is
<ogra> ogra@edubuntu:~$ grep /home /etc/fstab 
<ogra> UUID=7c24e63d-e8f7-4738-93f5-a63edd2c641a /home ext3 defaults 0 2
<ogra> there is no /dev/evms but a UUID ...
<sivang> hub: AIX is not too much painful, really, it's more of a bit crippled version of Linnux
<HiddenWolf> crimsun: got a sec?
<hub> sivang: the biggest problem is usually do get you hands on one ;-)
<hub> sivang: I have seen worse: BOSX
<hub> the compiler couldn't even compile gzip
<doko> cprov: yes, please
<sivang> hub: you should have grabbed the AIX Linux Toolbox CD, nothing needs to be compiled from source, almost :p
<dholbach> TheMuso: you know if java-access-bridge is something cool for the a11y team? it was on gnome's release list
<cprov> doko: sparc just failed again -> https://launchpad.net/+builds/+build/231427
<hub> sivang: I haven't touched AIX since 1995
<pitti> lamont: here?
<doko> cprov: hmm, then Riddell's analysis was wrong. will have a look ...
<cprov> doko: right, amd64 and powerpc failed too ... bad day 
<sivang> hub: My last time was about 2 months ago, but let's end this discussion about it now or move to PM :-)
<hub> sivang: sure. Ubuntu does not run on top of AIX, so not an issue :-)
<sivang> hub: well, it actually could (RHEL and SUSE do).
<zul> hi
<doko> cprov: please retry, when mesa-common-dev 6.5.0.cvs.20060725-0ubuntu1 is in the archive
<cprov> doko: will check when the current cron.daily finishes
<cprov> doko: in 5 minutes or so
<doko> thanks
<zul> thanks archive admins :)
<ogra> zul, so we have xen now ? 
<zul> its in the archive as far as i can tell
<Kamion> yes
<ogra> yay
<Kamion> except not xen-source-2.6.16 binaries yet
<ogra> any chance we'll get it for the current kernel at some point ? 
<zul> hehe...
<zul> thats alot of work right now which has to be started again..
<zul> ogra: xen has its own smp_alt which is different from our own
<ogra> meh
<zul> and we have to make sure it doesnt break anything...
<zul> so maybe not for edgy
<ogra> well, at least we have it :)
<zul> amd64 support for next release
<cprov> doko: mesa was already in the archive (at least wasn't touched during the last publisher run)
<madduck> RFC: "Ubuntu, an immensely successful Debian derivative, completely abandoned the notion of package ownership by maintainers and instead practices completely open collaborative package maintenance, meaning that any of the developers are authorised to make changes to any package, on the basis that the developer will act responsibly in each case and confer with colleagues when faced with a non-trivial problem." -- would you say this adequate
<madduck> (sorry for the long post, hope it wasn't cut off)
<Burgwork> madduck, I would avoid the use of abandoned, as it sounds negative
<madduck> abolished?
<madduck> have you got a suggestion?
<Burgwork> "practices completely open collaborative package maintenance, rather than specific package ownership by single maintainers"
<madduck> my goodness, now i notice how it's one big run-on sentence. damn german me.
<madduck> Burgwork: consider it done.
<Burgwork> madduck, cheers
<Burgwork> oh, and you need a few commas in there
<madduck> lemme paste the new thing in a sec, then i'd appreciate if you'd help me. :)
<madduck> any other comments?
<madduck> (anyone?)
<tseng> I can help you rewrite it
<tseng> give me a moment
<madduck> how's this? http://rafb.net/paste/results/5WxiiV67.txt
<johndomero> Hello, I have been working with preseeding the Debian-Installer with Dapper, and I am having some difficulties with "base-config base-config/late_command"
<tseng> madduck: not great :)
<madduck> tseng: :(
<tseng> one moment i need to get it in gedit or so
<tseng> it really cant work in one sentence is all
<madduck> but i put a colon in there. :)
<johndomero> I made an auto-installation CD with Breezy, and "base-config base-config/late_command" worked well; but it refuses to run under Dapper. Has "base-config base-config/late_command" been depreciated in favor of something else?
<tseng> your content is very good
<ogra> tseng, sure it works in one sentence (in german though)
<tseng> ogra: yep :)
<ogra> :)
<madduck> ogra: non-germans just don't have the mental capacity. :)
* madduck runs
<epx> >D
<ogra> madduck, yeah
<madduck> phone...brb
* ogra runs where madduck ran ...
<Kamion> johndomero: yeah - use preseed/late_command and 'chroot /target ...' to do stuff in the installed system
<Kamion> johndomero: base-config's dead, so base-config/late_command no longer works
<Kamion> johndomero: if you give me a little more detail about what you're doing then I'll be happy to try to give you more detailed advice
<tseng> madduck: http://pastebin.ca/101100
<johndomero> Kamion: The Dapper installation documentation from installation-guide-i386 (file:///usr/share/doc/installation-guide-i386/en/apbs04.html) still claims that "base-config base-config/late_command" exists.
<tseng> madduck: this isnt perfect but it breaks it down into bits digestible by us stupid americans
<tseng> in the last sentence
<tseng> fact should be changed to something less firm
<johndomero> Kamion: Could this documentation be updated to reflect this change? ;-)
<tseng> but expectation sounds crap there.
<johndomero> Kamion: I appreciate your help.
<Kamion> johndomero: huh, I thought I'd caught that one
<Kamion> sorry about that
* tseng volunteers Burgwork to give that a final polish.
<Burgwork> hmm?
<Kamion> yes, you're quite right - it will probably be cleared up when I merge installation-guide from Debian in edgy, but I'll file a bug to make sure I remember
<tseng> comma between open and collaborative is really grammatically correct, too.
<tseng> i have to run for a bit.
<johndomero> Kamion: What was the reason for depreciating it? Second of all, are there any limitations in using the chroot method with d-i late command?
<Kamion> johndomero: it was replaced by doing everything in a single stage, which is simpler, easier to maintain, and less buggy
<Kamion> johndomero: about the only awkwardness is that debconf interaction from inside the chroot (either using debconf directly, or installing packages which might use debconf) is a little tricky
<Burgwork> madduck, when you want me to look at it again, just ping me
<Kamion> johndomero: there's an 'in-target' program that you can use in place of 'chroot /target' which knows how to deal with that
<madduck> tseng: very nice. thank you.
<johndomero> Kamion: Where can I get the source for Ubuntu's Debian-Installer? I am working on a deployment scheme for a large university, and I am having to reference things a lot.
<Kamion> note that it also does stuff like diverting away start-stop-daemon, which catches some people by surprise
<johndomero> Kamion: How does this 'in-target' work?
<Kamion> johndomero: in-target> apt-get source debian-installer-utils, it's all in there
<allee> ahhh preseeding! My tonight TODO item ;) Some weeks before dapper I preseeded a dozend hosts successfully.  Now with a new set of hosts, install hangs accessing the archives (hosts are in a priv. net.  So I preseeded my apt-proxy cache)
<doko> Kamion: are some mesa binaries in NEW?
<Kamion> johndomero: the installer is made up of a lot of components, and we don't have a single revision control repository for them all (yet, I'm working on that)
<Kamion> johndomero: for the time being, you need to find which component you're interested in, and 'apt-get source' that
<johndomero> Kamion: I appreciate your help. It has been more useful than you probably realize. ;-) So little of this information is documented online.
<Kamion> doko: not as far as I can see
<Kamion> doko: the NEW queue is publicly-viewable - https://launchpad.net/distros/ubuntu/edgy/+queue
<madduck> Burgwork, tseng: it got a little long now (even before tseng reworked it), so I think I'll just stick with something like http://rafb.net/paste/results/eQ3D1t87.txt -- this is all in the introduction anyway, i'll dig deeper in the following chapters...
<doko> Kamion: nice, didn't knew that
<Kamion> doko: it is possible that Scott processed it recently - the queue is emptier than when I last checked
<Kamion> doko: what version?
<allee> johndomero: you happen to know how to turn off security archive via preseeding?
<Kamion> doko: https://launchpad.net/distros/ubuntu/edgy/+queue?queue_state=3&queue_text=mesa&start=20 - it looks like it's being processed at the moment
<Burgwork> madduck, just a question, before I comment further: what is the target audience?
<Kamion> allee: 'd-i apt-setup/security_host string '
<Burgwork> Kamion, should I bother filing a UI bug on that queue?
<doko> Kamion: mesa-common-dev is needed in version 6.5.0.cvs.20060725-0ubuntu1
<Kamion> Burgwork: it's not my responsibility, so I don't know - go ahead I guess
<Burgwork> can do
<Kamion> doko: I think it got uploaded *just* after the publisher run before this one
<Kamion> doko: and is currently being published
<madduck> Burgwork: academic. this is a revised phd proposal. so probably noone except those unfortunate examiners. :)
<doko> ahh, ok
<Kamion> just after the previous run started, I mean
<Burgwork> madduck, ah, ok. Then they can deal with the technical language
<allee> Kamion: thx I thought I tried this.  Maybe this then not the reason for by problem.  I try it again
<madduck> Burgwork: they'll refuse it if I talk plainly, even. been there, done that.
<Burgwork> Kamion, that is part of soyuz, no?
<doko> Kamion: I do have the impression that the processing of binaries is slower (compared to what we had for dapper), i.e. the time from upload to availability in the archive (without considering the build time)
<Kamion> johndomero: yeah, documentation for people who are kind of half way in between users and developers is a tricky area that we're kind of weak on in the installer
<Kamion> Burgwork: yes
<Kamion> doko: it's not any slower compared to dapper, but it's slower compared to breezy
<Kamion> doko: mesa/i386 managed to hit the worst case this time round, by bad luck
<Kamion> doko: also, the buildds were stalled for a long time today due to DNS problems inside the DC
<doko> Kamion: or I'm more impatient ;)
<Kamion> but there's nothing systemic that I'm aware of to make binary processing generally slower than dapper
<Kamion> allee: depends where it hangs - you might need to preseed mirror/* too
* allee better preseed a PC, server reboot take too long
<johndomero> Kamion: in-target will take all of $* and pass it through to the safe chroot?
<Kamion> madduck: is it worth mentioning the distinction between "core developers" and "developers" at that point, or is that too much detail?
<Kamion> madduck: (core developers => unrestricted upload, developers => universe and multiverse components only)
<madduck> Kamion: probably too much detail. I am really only (ab)using Ubuntu as an extreme here.
<Kamion> johndomero: yes
<Kamion> log-output -t in-target chroot /target "$@" || ERRCODE=$?
<bddebian> What's madduck whining about now? ;-)
<Kamion> (there's lots of setup/cleanup around that, but ...)
* madduck bounces all over bddebian's head.
<bddebian> heh
<madduck> Kamion: my work is still about Debian. i just wanted to make sure i got the Ubuntu description right.
<bddebian> madduck: And here I thought you had come over to the Light side :-)
<Kamion> johndomero: (bug 54185 is the base-config doc bug, in case you want to subscribe to it)
<Ubugtu> Malone bug 54185 in installation-guide "still talks about base-config" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/54185
<madduck> bddebian: there's no dark side of the moon really, as a matter of fact, it's all dark.
<bddebian> Oh, Floyd.. nice
<madduck> Gerry Driscoll actually. :)
<bddebian> Yeah, well..
* madduck pops in the prism album.
<johndomero> Kamion: Where does one get the sources for the various udebs? Does this come debian-installer-utils?
<Kamion> johndomero: no, debian-installer-utils builds some udebs but not all of them
<Kamion> johndomero: unfortunately you sort of have to know the component name; doing 'find /cdrom/pool -name \*.udeb' on an Ubuntu CD and looking at the last directory name in each line of output can help
<Kamion> (the last directory name is the name of the source package)
<Kamion> udebs are like debs in most respects - they just don't follow Debian policy
<Kamion> but they're still built from source packages in more or less the usual way
<Kamion> it's not quite one-to-one from source packages to udebs, but most installer source packages build a handful of udebs at most, often only one
<lfittl> madduck: ping
<madduck> lfittl: boing?
<neoxan> hi Seveas 
<doko> cprov: mesa is now in the archive, please requeue the OOo builds (again)
<cprov> doko: okay
<cprov> doko: 4 archs reset (amd64, powerpc, sparc, ia64)
<neoxan> hi Seveas 
<gnomefreak> Keybuk: you got a sec?
<Keybuk> gnomefreak: sure, what's up?
<Keybuk> Kamion: wasn't me
<gnomefreak> Keybuk: pm?
<Keybuk> Kamion: well, mesa wasn't me -- I did do a NEW blitz recently
<Keybuk> gnomefreak: it's the afternoon here, yes ?
<gnomefreak> may i pm you for a sec? ;)
<neoxan> gnomefreak, do you know why Seveas kicks me in every ubuntu channel and calls me an "loser and asshole"?
<Keybuk> what does "pming" me involve?
* Keybuk hasn't heard that one before
<neoxan> sry, if its offtopic in here
<neoxan> :)
<elmo> Keybuk: private-message
<Keybuk> elmo: ahhh
<gnomefreak> Keybuk: you r/msg ;)
<Keybuk> duh
<Keybuk> gnomefreak: right, sure :)
<azeem> Keybuk: irc newb
<Keybuk> azeem: I think it's more IRC oldb
* mode/#ubuntu-devel [+o Keybuk]  by ChanServ
<neoxan> gnomefreak? :(
<neoxan> nobody wants to help me
* mode/#ubuntu-devel [+b *!neoxan@unaffiliated/neoxan]  by Keybuk
* neoxan was kicked off #ubuntu-devel by Keybuk (Keybuk)
<gnomefreak> ty :)
<Keybuk> no probs
<gnomefreak> that will hold us until k-line
<rodarvus> mjg59, I'm here
* mode/#ubuntu-devel [+b *!*neoxan@unaffiliated/neoxan]  by Keybuk
* mode/#ubuntu-devel [-b *!neoxan@unaffiliated/neoxan]  by Keybuk
* neoxan was kicked off #ubuntu-devel by Keybuk (Keybuk)
* Keybuk leaves to set bans properly
<Keybuk> uh, learns
<elmo> keybuk: yeah, get out
<ogra> ..."HAL 0.5.7.1 "Unmaintained piece of crap" is now available" ...
<ogra> LOOOL
<ogra> i wouldnt have expected him to go that far to ake it a release name :)
<ogra> *make
<hub> LOL
<Keybuk> rofl
<Keybuk> unfortunately, I have to agree with the kernel guys
<ogra> baout h-d-m ?
<ogra> *about
<ogra> well, it works ...
<hub> kernelslacker did put the emphasis on the number of files open by HAL
<Keybuk> HAL is still a solution looking for a problem
<mjg59> Keybuk: I think the problem it solves is pretty obvious
<Keybuk> mjg59: which is?
<elmo> abstracting hardware
<mjg59> Obtaining information about available hardware from userspace
<Keybuk> but that information is already available
<mjg59> Through a variety of entirely different itnerfaces
<mjg59> Which are all entirely Linux-specific
<Keybuk> what's wrong with being Linux specific?
<ogra> Keybuk, pingediping about a udev question ...
<Keybuk> ogra: sure
<mjg59> People want their software to work on mor ethan Linux
<mjg59> Solaris has a not insignificant number of desktop users
<Keybuk> mjg59: the most useful things that HAL could do, it doesn't ... it provides no write access to hardware, for exmaple
<ogra> if you create the hdX devices on boot, you probe the disks for partitions or hw do you do that ? 
<ogra> *how
<mjg59> Keybuk: Increasingly, it does
<Keybuk> ogra: umm, could you be a bit more verbose?
<Keybuk> mjg59: it'd also be vaguely useful for HAL to hold information about devices that have been previously connected, but are not currently
<ogra> Keybuk, the question i'm really after is, would it be possible to have udev tell me that there is a swap partition on a device 
<mjg59> Keybuk: That's trivially layered on top of hal
<ogra> and which device node that would be ...
<Keybuk> mjg59: don't get me wrong ... I don't dislike HAL, or think it has no value ... I just think that it could be SO MUCH BETTER
<Keybuk> ogra: yes
<Keybuk> ogra: now, pitch your question better :p
<mjg59> Keybuk: That's hardly the same thing as being a solution in search of a problem
<Keybuk> do you mean "have udev automatically call swapon for any swap device" ?
<mjg59> The problem that it deals with is clearly defined
<vagrantc> Keybuk: we're looking to enable swap partitions on local drives for ltsp
<mjg59> You may disagree with /how/ it attempts to solve that, but that's a separate objection
<Keybuk> mjg59: yes, perhaps I was a little harsh there
<ogra> Keybuk, we have code for local swap support in ltsp ... but that relies on probing all disks and all artitions ... which slows down boot significantly 
<Keybuk> mjg59: I apologise
<mjg59> Keybuk: No problem :)
<ogra> my idea was to leave that to udev as its faser
<Keybuk> ogra: right ... so, if you can say "here's a swap device on boot", what do you need to do
<ogra> so we can autodetect if there is a swap partition and get rid of a config option
<ogra> swapon indeed ;)
<vagrantc> and mkswap
<ogra> yeah probably too
<Keybuk> SUBSYSTEM=="block", ENV{ID_FS_TYPE}=="swap", RUN+="/sbin/swapon %k"
<ogra> yay, thanks !
<vagrantc> what versions of udev will that work with?
<Keybuk> vagrantc: Ubuntu dapper and edgy
<ogra> oh, right, that might be a prob for debian
<vagrantc> right
<Keybuk> who cares about Debian?
<Keybuk> install the Ubuntu udev on it
<ogra> Keybuk, vagrantc 
<ogra> :)
<vagrantc> well, i can see my time here is at an end.
<ogra> i think you scared him :)
<Keybuk> *shrug*
<Keybuk> I spent ages making the Ubuntu udev work properly precisely so we wouldn't have to support the Debian broken version ;)
<ogra> right ... but i'll need to look into if its possible in debian as well ...
<Keybuk> oh, it's almost certainly possible, just with some pain
<ogra> since we want to be distro independent with the future code of ltsp
<Keybuk> you'd need to make sure that the upstream persistent rules are installed, and before yours
<Keybuk> *shrug* I don't agree that's possible
<Keybuk> or even desirable
<Keybuk> you'll always need a distro-specific layer
<ogra> "* vagrantc is more disappointed in the social aspect than the technical ones"
<ogra> frm #ltsp :(
<Keybuk> *shrug* that's just bullshit
<Keybuk> if he wants to get support with Debian, he should go to Debian
<ogra> well ... he cares about ltsp 
<Keybuk> if he wants support with udev, they'll probably tell him to use Ubuntu instead of Debian
<ogra> hes the best ltsp coder i have in debian and cares to make his stuff work in ubuntu ...
<Keybuk> it's easy to make stuff work in Ubuntu
<ogra> but i wouldnt have expected him being so thin skinned
<Keybuk> I don't see how it's our problem that something is not as easy in Debian
<ogra> the ude stuff was my idea ...
<ogra> *udev
<Keybuk> Debian is intrinsically difficult for things like this
<Keybuk> Ubuntu is easy ... initramfs, udev, etc. all fit together properly
<ogra> yep
<ogra> *i* know that ... and he surely will make the code i submit work in debian ...
<Keybuk> I'd like to see him go and ask the inverse question on #debian-devel
<Keybuk> "how do I make this work in Ubuntu too"
<Keybuk> I suspect he'll get a FAR ruder response
<zul> heh
<LaserJock> mjg59: I installed Dapper on my intel iMac, however it won't boot it. is there some special lilo trick?
<Keybuk> heh, the GPL looks funny if you sort(1) it
<ogra> heh
<ogra> are you bored ?
<elmo> why do I have a /usplash_fifo?
<elmo> and I can rm it?
<Keybuk> no, I'm processing the NEW queue
<Keybuk> elmo: bug, yes
<Keybuk> elmo: usually means you didn't have an initramfs
<elmo> kthx
<elmo> ah, yeah, i use to use monolithic
<Keybuk> I was reading tar contents, then I amended my for/tar to extract the COPYING file to stdout ... but forgot to take out the | sort :p
<ogra> hehe
<Keybuk> excuse me a moment
<Keybuk>      _ _           _ _                _     _
<Keybuk>   __| | |__   ___ | | |__   __ _  ___| |__ | |
<Keybuk>  / _` | '_ \ / _ \| | '_ \ / _` |/ __| '_ \| |
<Keybuk> | (_| | | | | (_) | | |_) | (_| | (__| | | |_|
<Keybuk>  \__,_|_| |_|\___/|_|_.__/ \__,_|\___|_| |_(_)
<Keybuk> there, I feel better now
* Keybuk beats his head against the wall
<ogra> ouch
<Keybuk> I've already rejected these once for having the wrong licence combination
<Keybuk> and again, the same damned thing
<gnomefreak> sweet
<Keybuk> it could be an upstream tarball problem
<Keybuk> the source claims LGPL, COPYING is the GPL
<sivang> Keybuk: you can't go un-noticed like this, you know :)
<Keybuk> sivang: hmm?
<ogra> dholbach isnt online ... so he'll hardly notice it :)
<ogra> sivang, ^^^
<sivang> ogra: right, but it was enough to make me think something is wrong :-)
<sivang> Keybuk: ^^
<bluefoxicy> Keybuk:  you should hack up xchat so that it can highlight on ascii art.
<Mez> bluefoxicy, or not ;p
<bluefoxicy> Mez: http://rafb.net/paste/results/lwfjiz64.html
<Mez> ;)
* Mez slaps keybuk#
<bluefoxicy> Also he's right.
<bluefoxicy> "modifying or distributing the Program (or any work based on the mouse-clicks or menu items--whatever suits your program."
<Keybuk> Mez: for?
<Mez> Keybuk: for buggering off before i got a chance to swap keys with you
<Keybuk> heh, they kicked everybody out
<Keybuk> I didn't bring key stuff anyway
<Keybuk> my passport is being replaced
<Mez> Keybuk: you coulda come back at 8 :P
<Mez> Keybuk: next time eh ? 
<Mez> and /me slaps you again for the microphone comment
<Keybuk> Mez: was too tired, too broke, and stuff
<Mez> Keybuk: *shrugs* I know the feeling
<sivang> Mez: where do you guys unmeet? :)
<sivang> s/do/did/
<Mez> divang: unmeet?
<Mez> s/divang/sivang
<Mez> sivang, we met @ LUG Radio Live 2006 (and at UBZ before that - and at LRL2005 before that)
<sivang> Mez: a, what's LRL ?
<Mez> LUG Radio Live
<sivang> s/unmeet/almost-met/
<Mez> sivang: we did meet - we just didnt sign
<zul_> someone looking for me?
#ubuntu-devel 2006-07-27
<Lie_Ex> I've uploaded kalzium's po(zh_CN) to launchpad.net for three times,but all failed...Could anyone please tell me why?
<crimsun> Lie_Ex: try asking in #launchpad
<Lie_Ex> crimsun: Well...I do.
<wasabi_> zeroconf zeroconf zeroconf.
<wasabi_> *faint*
<Keybuk> mdz: I can't find any evidence of a MoM bug in firefox
<Keybuk> casey firefox-1.99+2.0b1+dfsg-1ubuntu1% md5sum browser/base/branding/about.png*
<Keybuk> 6d3d82c09be331c2378ba8757e3ca3cb  browser/base/branding/about.png.DEBIAN
<Keybuk> 5f7d44ff7cbd1dbccc9dda0bd0a30f5c  browser/base/branding/about.png.UBUNTU
<Keybuk> 0e36645b0e1673028db0c66487ed377f  security/nss/cmd/pk11util/scripts/pkey.DEBIAN
<Keybuk> 6978db5da7e4fd6227dee37e4eacd8cd  security/nss/cmd/pk11util/scripts/pkey.UBUNTU
<Keybuk> etc.
<Keybuk> they really are different in Debian and Ubuntu
<mdz> Keybuk: hmm, perhaps we moved to a new upstream version ahead of Debian?
<Keybuk> that often happens
<mdz> we surely didn't modify those files explicitly
<bddebian> Howdy
<mdz> seems like we should be able to exclude them somehow
<Keybuk> actually, sorry
<Keybuk> we must have modified them
<Keybuk> we have something that claims to be the "2nd ubuntu revision" of a version that exists in Debian
<Keybuk> maybe there is a MoM bug here somewhere
<mjg59> Why has gksu suddenly started offering to save my password?
<mdz> mjg59:that hang on my laptop turned out to be unrelated to vbesave specifically
<Keybuk> oh
<Keybuk> MoM is just entirely missing code to cope with that ;)
<mdz> it just seems to hang most of the time, more often if stuff is running in the background
<ajmitch> mjg59: xgl is built, just can't find font 'fixed' 
<Keybuk> it copes with non-files properly, just not binary files
<ajmitch> even with the right font path given to it
<mjg59> mdz: Fun
<Keybuk> mdz: ok, fixed
<mdz> Keybuk: thanks
<mjg59> ajmitch: It's looking in /usr/share/X11/fonts, rather than /usr/share/fonts/X11
<mjg59> Or something
<mdz> mjg59: it seems to be triggered by something the gdm greeter  does; I can startx without trouble
<mjg59> Probably needs a configure option
<mjg59> mdz: Hrm
<Keybuk> mdz: it was just noticing that debian and ubuntu had different binary files, and not taking the base into account
<mdz> I guess I'll try disabling some acceleration when I have time to play with it
<mjg59> mdz: Why does your machine ahve to have all these weird bugs
<Keybuk> so now it won't conflict if it was only modified on one side
<mdz> mjg59: does it?
<mdz> this is my T42, which is generally well-behaved
<mjg59> There was the laptop-mode crashing madness
<ajmitch> mjg59: yes, --with-fontdir=\$${prefix}/share/fonts/X11, which I have
<mjg59> ajmitch: strace it and see where it's looking?
<ajmitch> setting -fp when running it has no effect either
<ajmitch> will try
<ajmitch> looking in the right place, for the file that's not there. I thought mkfontdir would have created fonts.alias
* ajmitch retries
<mdz> mjg59: a lot of people had that one
<gnomefreak> is there a known issue with latest 2.6.17-5 images/restricted mods?
<bddebian> Does it make sense for us to add a build-dep for sharutils just to get uudecode to add an icon?
<infinity> bddebian: Yes.
<infinity> bddebian: Alternately, distribute the icons as SVGs, and add a build-dep on librsvg2-bin to convert them to PNGs during the build.
<infinity> (Assuming you have SVG originals)
<bddebian> Not xpms?
* infinity shudders.
<whiprush> hey canonical folk, does silbs irc or is she email-only?
<infinity> You could convert to XPM if you want, but they'll end up very ugly.
<infinity> whiprush: She IRCs.  The fact that you named her base don her IRC nick should confirm that. :)
<infinity> s/base don/based on/
<whiprush> infinity: well, last I saw her was like, 2 years ago. :)
<infinity> She's on every day.  She just doesn't stay connected when not at work, like the rest of us freaks.
<whiprush> heh
<whiprush> infinity: welcome back btw.
<infinity> And since it's 3am there...
<fabbione> morning
<fabbione> infinity: could you please give back redhat-cluster-suite ?
<bddebian> Hello fabbione
<fabbione> lo
<mdz> fabbione: the meeting while I was away was 1500 UTC, right? so the next one 2300 UTC?
<fabbione> mdz: yes, so it seemd
<fabbione> seems
<mdz> ok, thanks
<fabbione> mdz: no problem
<fabbione> mdz: how does it feel to be back home?
<mdz> fabbione: tired
<fabbione> mdz: i bet... 
<fabbione> mdz: today might be the day :)
<infinity> fabbione: Sure.
<fabbione> infinity: thanks!
<infinity> fabbione: Appears to have built okay on amd64.  Should build everywhere else if/when doko stops uploading OpenOffice every 20 minutes.
<fabbione> infinity: perfect thanks. I am pretty sure it will build everywhere
<fabbione> it was a matter of other pkgs being broken before
<infinity> ia64 worked too, so yeah.
<fabbione> it might fail on sparc
<fabbione> openais doesn't build because of l-k-h
<infinity> Oh, that's okay, we don't care about sparc, do we? :)
* fabbione larts gently infinity 
* infinity grins.
<fabbione> ;)
<fabbione> speaking of which
<fabbione> somebody will need to look at all recent FTBFS and prepare a collection for Ben
<fabbione> so he can fix stuff up on monday
<fabbione> it's extremely unlikely i will be around from today/tomorrow
<infinity> As in, recent FTBFS that are the fault of l-k-h?
<fabbione> yes
<infinity> I was going to do another mass-give-back after the OpenOffice-fest is over, so I can keep an eye out.
<fabbione> infinity: that would be lovely.
<fabbione> infinity: i expect to be away about 2 weeks
<fabbione> but i need people to look after my stuff while i am away
* infinity nods.
<infinity> Tollef's off too, honeymoon.
<fabbione> i know
<fabbione> poor guy
<fabbione> he is going to eat the most poisoining food in his life ever
<infinity> No, no.  The honeymoon is good.  It's the 50 years after that...
<zul> aka purgatory
<infinity> But I'm not bitter.
<fabbione> 25 years.. you usually don't want to live that long after
<fabbione> zul: it's called hell :)
<zul> fabbione: thats another word for it
<infinity> fabbione: So, are they inducing, or has she finally gone into labour?
<fabbione> zul: in bibble, purgatory is less painful than hell :)
<fabbione> infinity: they are inducing.. in about 3 hours
<ajmitch> when is tollef away?
<zul> fabbione: dont they eat your brains
<infinity> fabbione: Fun.  Good luck!
<fabbione> infinity: thanks mate.
<infinity> ajmitch: From Friday evening until the sprint in Germany.
<bddebian> fabbione: You are having a child? (Well your wife?)
<zul> fabbione: good luck..
<fabbione> bddebian: well as everybody know by now.. only the mother is *always* certain, despites some bad jokes about it
<ajmitch> infinity: right, I'll have to catch up with him asap then
<fabbione> zul: thanks
<bddebian> fabbione: Awesome, congratulations
<fabbione> thanks
<fabbione> infinity: anyway, they start the induction today.. but it might take up till monday
<bddebian> You should have asked, I could have just given you one of my 3 ;-P
<fabbione> infinity: so i might be around a few days more
<fabbione> FANCY! new dlmfs builds!
* fabbione waits for the build to hit gfs2
* fabbione does the cluster dance
<fabbione> infinity: can you also NEW the binaries from the redhat-cluster-suite?
<fabbione> infinity: i would like to upload the new lvm2 to complete the libdlm1 -> libdlm2 transition
<infinity> fabbione: Does it have a proper versioned build-dep, so it'll dep-wait on the arches that don't have the new binaries yet?
<fabbione> it's versioned B-D but just to make sure it foes in
<fabbione> yes it will
<fabbione> and it does
<infinity> Alright.
<infinity> I'll NEW amd64/ia64, then.
<fabbione> just to make sure somebody NEW it
<infinity> gfs2-tools to main?
<fabbione> yes please
<fabbione> it's a redhat-cluster-suite Depends:
<fabbione> and the former is in main
<fabbione> we did kill quite a bunch of binaries
<infinity> Okay, it's in on amd64/powerpc/ia64, apparently.
<infinity> Done.
<fabbione> thanks perfect
<fabbione> oh actually openais did build on sparc
<fabbione> infinity: is there any special reason why lvm2 was never built on edgy since mvo's merge?
<fabbione> it's in needs-build but never scheduled?
<fabbione> no biggie.. new version is hitting archive now, just curious
<infinity> fabbione: I'd assume it's in a dep-wait loop.
<fabbione> ok
<fabbione> let see if it solves itself
<pitti> Good morning
<pitti> infinity: any chance to stop the ruby1.8 breezy-security sparc build?
<pitti> infinity: it keeps spamming me with failed log files
<fabbione> infinity: can you please promote libcman-dev and libcman2 to main? MIR is not required. B-D for lvm2 and source is already in main
<sladen> elmo: /usplash_fifo appears because the return code of chdir() isn't checked to see whether it succeeded.
<sladen> sfllaw: it's important to mention a timezone when stating times!  :)
<pitti> hey md
<pitti> hey mdz
<mdz> morning
<pitti> mdz: ah, back to home, sweet home?
<mdz> yes
<mdz> but not home-sweet-$TZ
<pitti> UnifyWorldTimezonesSpec
<jsgotangco> lol
<mdz> it looks like xserver-xorg-core is out of sync with xserver-xorg-video-*
<bluefoxicy> mdz, pitti:  Any news on if that patch I sent is going to make it to backports or updates?
<pitti> bluefoxicy: patch? sent? me know nothing
<mdz> I replied to you last week
<pitti> ah, gnutls?
<bluefoxicy> mdz:  you said you were going to send it to pitti and go with wherever he sticks it, which is fine with me
<bluefoxicy> I'm just curious as to where it went.
<pitti> bluefoxicy: ah, I see; sorry, I didn't reply yet
<mdz> that isn't quite how I put it, but yes, I asked for his opinion
<pitti> bluefoxicy, mdz: my feeling is that we shouldn't do potentially disruptive changes in such a central library for dapper
<pitti> doing it in edgy is fine
<pitti> but we have seen in SSP that even changes which are meant to be transparent can cause troubles
<bluefoxicy> i.e. it's going nowhere.
<pitti> bluefoxicy: gnutls13 is already fine?
<bluefoxicy> pitti:  libgcrypt11 o.o I never sent a patch for gnutls
<pitti> ah, gcrypt
<bluefoxicy> I sent a dpatch that adds --enable-noexecstack to the ./configure for that
<pitti> bluefoxicy: so, why not apply it to edgy?
<bluefoxicy> it's in edgy
<pitti> ah, indeed
<bluefoxicy> the version in edgy has other changes though
<bluefoxicy> which is why I made a dpatch for just that for dapper; my intent is to get the executable stacks off gaim, thunderbird, firefox, vino-server, and a few other things.  Nothing more, nothing less.
<pitti> bluefoxicy: btw, configure options are in debian/rules and shuold be applied directly, not in a patch
<bluefoxicy> it is in debian/rules
<bluefoxicy> the dpatch patches debian/rules
<bluefoxicy> or something
<bluefoxicy> whatever it's called, debdiff
<bluefoxicy> some command tseng told me to run
<pitti> bluefoxicy: ok, since it is in edgy for a while and apparently didn't break anything, hmm..
<pitti> bluefoxicy: ah, debdiff
<bluefoxicy> I honestly don't remember anymore :)
<pitti> bluefoxicy: debdiff between two .dsc files gives you a diff -Nur between the two sources
<pitti> so you probably mean that
<bluefoxicy> yeah that's what I did
<bluefoxicy> at any rate, I'll leave that up to you to figure out
<bluefoxicy> it's 4am here and I'm going to sleep before my brain asplode.
<pitti> good night, sleep well!
<mdz> a dpatch patching debian/rules generally doesn't do what you want
<pitti> mdz: what was supposed to mean s/dpatch/debdiff/
<mdz> oh
<pitti> I'm a bit nervous about it TBH
<pitti> Kamion: if you have a minute, could you please free apport from NEW?
<jdub> lamont: wow, milter support in postfix!
<Seveas> Kamion, darn, I finally had a reply to  an ubiquity bug correct, turns out you're just ahead of me 
<desrt> Seveas; how do you type that character?
<Amaranth> desrt: it's katakana
<desrt> Amaranth; i know
<Amaranth> desrt: gucharmap :)
<desrt> i want to know how he physically uses his keyboard to produce it
<Amaranth> or a custom keymap
<desrt> since i assume he doesn't use gcharmap every time he wants to smile :)
<Kamion> pitti: apport accepted
<Kamion> Seveas: eh
<Kamion> heh
<Kamion> pitti: there's a random .pyc in the source package - maybe a missing clean rule?
<Kamion> pitti: and a random master-slave.diff too
<pitti> Kamion: oh, I'll clean the .pyc in the next version, thanks
<dholbach> good morning
<Seveas> mornin' dholbach 
<dholbach> hey Seveas
<Seveas> seen Ubugtu's spam feature yet?
<dholbach> ah no, not yet
<Kamion> Seveas: (for the record I would prefer duplicates not to be Rejected as a general rule, just marked as duplicate - marking them Rejected makes it more effort to clean up in the event that a mistake is made)
<Kamion> there's no need to reject them because Malone doesn't show duplicates by default anyway
<Seveas> ack
<Kamion> thanks
<Seveas> sfllaw really should work on collecting such info and making guidelines -- most people reject duplicates and if that should not be done for a subset of packages that should be noted somewhere 
<dholbach> in gnome land we reject duplicates as well
<Kamion> the fad of rejecting duplicates is relatively recent, I think
<Kamion> dholbach: but there's no way to mark a bug as duplicate in bugzilla without rejecting it, is there?
<Kamion> well, resolved/duplicate
<Kamion> bugzilla doesn't have a real mark as duplicate, so the situation isn't comparable IMO
<dholbach> Kamion: in bugzilla, no - it's resolved as duplicate, yes
<dholbach> oh, i meant in "ubuntu gnome" land
<dholbach> "ubuntu desktop... something" land
<Kamion> in a bug tracking system that has a real mark-as-duplicate, it seems odd to me to do further status changes
<Kamion> dholbach: oh, ok
<dholbach> i'll go out to buy a fan later today
<Seveas> the bug tracking system should keep status changes of duplicate bugs in sync imo
<Kamion> it's not so bad if it's the maintainer doing it I guess, but if other helpers are doing it then the chance of incorrect duplicate-markings is higher
<Kamion> Seveas: it would have to remember the original status and snap it back if you unmarked-duplicate
<Seveas> good one
<Kamion> seems like a lot of complexity for not a lot of gain, but shrug
<Kamion> I guess some users do get confused by the status on duplicates - easy bit of education to do though
<sivang> morning
<dholbach> hey mvo!
* dholbach hugs mvo
<dholbach> hey carlos
* mvo hugs dholbach
<sivang> hi mvo 
<mvo> good morning!
<sivang> carlos, et al
<mvo> hello sivang!
<carlos> he dudes!
* sivang hugs carlos and mvo 
<hungerW> Could the damn fstab upgrade script please leave my fstab alone? I have fixed it three times now.
<hungerW> Same is true for my grub settings: I do not have a automatic kernel list, it would be nice if that wouldn't get added all the time behind my back.
<Seveas> hungerW, hack for the latter: update-grub sources /etc/default/grub, put 'exit 0' in there
<Seveas> hungerW, and afaik the fstab update script (I assume you mean the one in edgy) is supposed to be neccessary -- if it fails to do the right thing for you, you should file a bug
<Kamion> it shouldn't upgrade more than oonce ...
<Kamion> once
<\sh> pitti: ping
<Kamion>         if dpkg --compare-versions "$2" lt "093-0ubuntu5"; then
<Kamion>             mount_by_uuid_conversion
<Kamion>         fi
<Kamion> looks right to me
<pitti> \sh: pong
<hungerW> Seveas: I did file a bug about exactly this issue yesterday.
<hungerW> Seveas: Please do not get me wrong: I do not mind fixing something... I am using a unstable distribution after all.
<hungerW> Seveas: But fixing the same thing that break my boot three times in a one day is a bit annoying.
<Seveas> true that
<Kamion> hungerW: where's the bug?
<Seveas> what's the bugnumber -- I don't recall seeing that bug
<Seveas> and I've worked all night (90 minutes sleep) to get over the bug backlog
<cbx33> hi guys, is there a look and feel summary for edgy anywhere?
<hungerW> Seveas: #54002
<Seveas> cbx33, wiki.ubuntu.com/Artwork is what comes closest
<Seveas> bug 54003
<Seveas> bug 54002
<Ubugtu> Malone bug 54003 in udev "fstab conversion uses UUIDs for drives that are formatted on reboot" [Untriaged,Fix released]  http://launchpad.net/bugs/54003
<Ubugtu> Malone bug 54002 in udev "No need to convert LVM volumes to UUIDs" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/54002
<cbx33> Seveas: that's what I thought you'd day
<hungerW> Seveas: Basically a wishlist bug...
<Kamion> hungerW: what did you do in between those three times?
<hungerW> Kamion: Upgrade:-)
<Kamion> hungerW: as in, did you upgrade something that tried to do the conversion again? if so, what?
<Kamion> hungerW: /var/log/dpkg.log may help
<hungerW> Kamion: I did upgrade everything. And I guess that this script did not see any UUIDs in my fstab and assumes it has to build them into my system again.
<Kamion> hungerW: the fact that the conversion is done multiple times would be a dpkg bug
<Kamion> er?
<Kamion> sorry, brain<->fingers disconnect
<Kamion> hungerW: the fact that the conversion is done multiple times would be a separate bug
<hungerW> Kamion: Which breaks the boot as the UUIDs change on reboot!
<Kamion> hungerW: no, the conversion's only supposed to be done once at all
<Kamion> it doesn't check whether there are UUIDs there - it checks whether it's upgraded to the version in which the conversion was introduced
<hungerW> Kamion: Which is the reason I have not used them before:-)
<Kamion> please file a bug about the conversion being done multiple times, and attach /var/log/dpkg.log - try to identify roughly what times the conversion happened
<Kamion> well, the last few days' worth of dpkg.log, anyway
<hungerW> Kamion: Which package has the conversion script?
<Kamion> source package is udev
<Kamion> oh, I see, the conversion script was moved to volumeid
<Kamion> I suppose that would explain it happening twice, but not three times
<hungerW> Kamion: Is there supposed to be data in /var/log/dpkg.log?
<hungerW> Kamion: I should file a bug about that file always being empty then:-|
<Kamion> are you absolutely sure it happened three times? if it was twice, then I know why that happened and it only affects a few people who upgraded through edgy
<Kamion> and it's probably not worth the painful complexity of trying to fix it
<Kamion> -rw-r----- 1 root adm 913817 2006-07-27 08:28 /var/log/dpkg.log
<Kamion> it might look empty if you're not in the adm group
<hungerW> Kamion: I am sure it happened three times. The first was yesterday morning (with a message claiming that it will do so).
<hungerW> Kamion: I fixed it then. In the afternoon I had to reboot and fix the issue again.
<hungerW> Kamion: And when I booted just now I saw the same problem again.
<hungerW> Kamion: I can not garantee that I didn't do something stupid in the meantime;-)
<hungerW> Kamion: Maybe it was my fault. I don't know.
<Kamion> hungerW: I'm not trying to suggest it was your fault, just trying to nail down what happened
<Kamion> hmm, the conversion should exit if there's already an /etc/fstab.pre-uuid
<Kamion> I'll suggest that to Keybuk - that would avoid the problem for most people
<Kamion> bug 54231
<Ubugtu> Malone bug 54231 in udev "skip UUID conversion if /etc/fstab.pre-uuid already exists" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/54231
<hungerW> Kamion: There is one... here. I deleted it:-)
<Arbiter> mvo: ping
<Kamion> hungerW: can't help that :)
<hungerW> Kamion: Well, maybe that was the reason it converted once more. I deleted that file as soon as I roled back the changes done by the script.
* hungerW considers it to be messy to have all kinds of backup files on his system.
<Kamion> hungerW: can't possibly have been the reason it converted once more, because bug 54231 is not implemented at present.
<Ubugtu> Malone bug 54231 in udev "skip UUID conversion if /etc/fstab.pre-uuid already exists" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/54231
<hungerW> Kamion: Well, if you say this conversion will happen only once (or maybe twice for ppl that update too often;-), then it probably is something like that... me deleting/changing something the script needed.
<mvo> Arbiter: pong
<Kamion> hungerW: I've read the code; deleting that file can have no possible effect at present
<Kamion>     cp -a /etc/fstab /etc/fstab.pre-uuid
<Kamion> that's the only line that references it
<hungerW> Kamion: Well, if nobody else has the three time conversion issue but me, then it is most probably me that did something.
<Arbiter> mvo: have you reviewed the smartpm patches? :)
<mvo> Arbiter: yes, a bit. not uploaded yet though
<Arbiter> mvo: yup, do you like the split && patch?
<cbx33> Hi again guys
<cbx33> how deals with sound themes?
<cbx33> s/how/who
<mvo> Arbiter: yes, I will modify it a bit though and make the new __init__.py a proper dpatch
<Arbiter> mvo: well :)
<Kamion> infinity: could you turn the livefs cron jobs back on, please? Knot-1 is kind of out ;-)
<Kamion> ever get that feeling when you want to go back and shake your past self into not being silly?
<ajmitch> too often
<Kamion> bug 40107 is a one-line fix :-/
<Ubugtu> Malone bug 40107 in ubiquity "selects wrong country if selected ll_CC not available" [Medium,Confirmed]  http://launchpad.net/bugs/40107
<tseng> rodarvus: do you happen to know what lib provides ExaDriverRec, trying to rebuild video-ati and I have a feeling I am missing a b-d
<dholbach> tseng: /usr/include/xorg/exa.h from xserver-xorg-dev mentions it
<tseng> dholbach: already have it, thanks.
<rodarvus> ahn, I was late :)
<tseng> (doesn't help)
<rodarvus> I'll be right back, need to logout/logon again
<rodarvus> (gnome theme is fubar, probably needs a restart)
<dholbach> tseng: one of xserver-xorg-dev's build-depends (might be it lacks a depends)
<tseng> dholbach: i bet so
<tseng> gotta go, will look at it after work
<madduck> how many ubuntu developers are there?
<madduck> and how many of those are canonical employees?
<madduck> for core? and for everything?
<slomo> madduck: https://launchpad.net/people/ubuntu-core-dev and https://launchpad.net/people/ubuntu-dev
<slomo> madduck: no idea about employment ;)
<madduck> not a single female core developer. :/
<ogra> madduck, we'll get there ...
<madduck> anyway, what i really want to know is how many maintainers there are i guess.
<ajmitch> madduck: currently there's only 1 female MOTU
<fabbione> ogra: "we" as in when did you change sex?
<fabbione> madduck: ogra will fix the problem soon with a short visit to casablanca
<Riddell> Kamion: what part of ubiquity removes packages (like removing ubiquity) after install?
<ogra> fabbione, :P
<sivang> fabbione: ROTFL
<Kamion> Riddell: scripts/install.py, remove_extras
<Kamion> madduck: I think the current figure is 18 Canonical employees paid to work on the distro
<tseng> there are 34 in coredev, including volunteers, former employees, current distro team
<robertj> Kamion: is there any hope sabdfl might be our thundering voice & decide on Avahi to shut the mailing list up?
<Kamion> madduck: all of those are -core-dev
<tseng> robertj: he doesn't really do that..
<tseng> robertj: (historically)
<Kamion> a technical board decision would involve leaping over fewer layers
<tseng> if you have an issue you cant resolve you schedule it for a hearing from the tech board
<robertj> tseng: is ita "file a request for tech board to look at it" or does there actually need to be someone present & to talk to the board, etc, because if so that shouldn't be me
<tseng> yes, its on the wiki
<tseng> TechBoardAgenda or so, let me find it for you
<tseng> yes, someone definately needs to be present
<tseng> presumably from both sides, on this particular issue
<Lathiat> when is it?
<slomo> and both should better know what they're talking about ;) Lathiat? :)
<tseng> https://wiki.ubuntu.com/TechnicalBoardAgenda?highlight=%28board%29%7C%28tech%29
<Lathiat> in 12 hours
<Lathiat> hrm
<Lathiat> oh no
<Lathiat> 1st aug
<Lathiat> someone remind me? ;)
<madduck> Kamion: much obliged.
<tseng> someone (robertj) needs to add it to the agenda with a short synopsis and names of presenting parties
<Lathiat> tbh i gave up reading the thread
<Lathiat> what *exactly* are they bickering about?
<Lathiat> now?
<robertj> Lathiat: nothing thats why its time for someone to take steps to kill it
<robertj> (the thread)
<Lathiat> imm not sure a TB decision would help that
<Lathiat> a "stfu" might ;p but in CoC-kind words ;p
<ogra> well, "stfu because TB said no" (in a polite tone) has a better chance to be heard :)
<fabbione> Kamion: ping?
<robertj> I think we need some entrails to decide this properly
<Kamion> fabbione: hi
<fabbione> Kamion: hey dude.. could you be so kind to new redhat-cluster-suite binaries for i386/ia64 and move libcman-dev to main? (lvm2 b-d)
<fabbione> there is no need for a MIR. all the sources are already in main
<Kamion> ok, will do
<Kamion> fabbione: it's not in NEW
<fabbione> the source is not new.. there are new binaries
<fabbione> i can only see amd64 ppc asparc debs on archive...
* fabbione wonders if it's another mirror 
<Kamion> like I say, nothing to do with redhat-cluster-suite in NEW
<Kamion> https://launchpad.net/distros/ubuntu/edgy/+queue
<ogra> i see t in "done"
<ogra> *it
<fabbione> oh halt.. ia64 is ok not to be there ... ports
<Kamion> yep, https://launchpad.net/distros/ubuntu/edgy/+queue?queue_state=3&queue_text=redhat
<fabbione> but i386 should be there
<Kamion> fabbione: it's on drescher; dunno why it's not on archive.u.c yet
<fabbione> Kamion: ok thanks.. could you check of libcman-dev is in main on drescher?
<fabbione> this rh-c-s transition has been the most painful EVAR!
<Kamion> fabbione: it's not yet, I'll move it after this publisher run
<fabbione> Kamion: thanks a lot.
<fabbione> Kamion: that will also unleash the new lvm2
<fabbione> that did never build since merge
<Kamion> fabbione: promotd
<Kamion> +e
<fabbione> Kamion: thanks
<Hobbsee> hi Kamion, fabbione 
<Kamion> fabbione: I think the i386 build was in the process of publishing when I looked; that would explain the discrepancy between drescher and archive.u.c
<fabbione> Kamion: perfect. thanks a lot for checking
<Kamion> coo; tasksel basically works
<fabbione> hey Hobbsee 
<fabbione> Kamion: eheh neat
<Kamion> hmm, except it hasn't installed ubuntu-desktop, I wonder why not
<Kamion>   xorg: Depends: libgl1-mesa-glx but it is not installed
<Kamion> s/installed/installable/
<gnomefreak> all kinds of xorg issues in latest updates
<Kamion>         Depends: libgl1-mesa-dri which is a virtual package.
<fabbione> Kamion: might be the new mesa 6.5 transition?
<Kamion> something's installing libgl1-mesa instead
<rodarvus> this hasn't changed in the mesa 6.5 transition
<Kamion> oh, like err ubuntu-desktop
<rodarvus> libgl1-mesa doesn't exists anymore - it was obsoleted by libgl1-mesa-glx
<Kamion> should we be using libgl1-mesa-glx instead?
<Hobbsee> hi rodarvus :)
<Kamion> ok - it does actually exist because I haven't NBS-removed it yet
<Kamion> but right, that answers that question, thanks
<Kamion> I'll go fix the seeds
<rodarvus> Hobbsee, hi!
<rodarvus> Kamion, oh, I forgot to update this in the seeds, sorry :/
<Hobbsee> rodarvus: i hear you broke something.  just when i came home.  shameful :P
<rodarvus> (libgl1-mesa was obsoleted about two or three weeks ago, btw, when we merged our mesa to debian's 6.4.2-something)
<rodarvus> Hobbsee, shame on me :)
<Kamion> oh interesting, lsb now depends: libgl1-mesa | libgl1 - fix that and everything else with similar depends and we could probably get rid of that seed workaround
* Kamion goes to start on that
<ajmitch> rodarvus: xorg drivers will be rebuilt soon?
<sfllaw> Kamion: I prefer Rejecting bugs on Duplicate, because then you can tell the submitter why you've done so.  You can't leave a comment when you mark something Duplicate.  I suspect that recording state changes might make undoing a lot easier.
<rodarvus> ajmitch, they're being rebuilt right now
<Kamion> sfllaw: I always leave a comment explaining the situation and then mark as duplicate
<rodarvus> actually, they're being uploaded today
<ajmitch> ok
<Kamion> which doesn't seem that difficult - ok, one more web transaction, but so what
<ajmitch> so, once OOo gets through :)
<rodarvus> (I've seen bug 54225 this morning)
<Ubugtu> Malone bug 54225 in xorg-server "Dependency relationships allow core and drivers to be out of sync" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/54225
<rodarvus> strange thing is I didn't had this problem locally
<ajmitch> I did on my laptop, but not with the nvidia driver on amd64, strangely enough
<ajmitch> updated Xgl package seems to work alright now
<zul> oh goody...you can test xen on amd64 then ;)
<ajmitch> heh
<ajmitch> that requires rebooting :)
<ajmitch> and going through the pain of getting a root filesystem again
* ajmitch ran hard into the bug with lvm+raid
<madduck> ajmitch: which bug?
<ajmitch> bug 52740
<Ubugtu> Malone bug 52740 in initramfs-tools "[EDGY]  Regression: can't boot from lvm root on raid anymore" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/52740
<gnomefreak> x-window-system-core xorg xserver-xorg  are not being replaced when upgrade removes them (any reason for this) or just broken?
<ajmitch> and it didn't like the UUID conversion in grub, either
<ajmitch> I think I have to file a separate bug on that
<jono> hey
<madduck> ajmitch: which initramfs-tools version? which mdadm?
<madduck> looks like pre-2.5
<ajmitch> initramfs-tools 0.69ubuntu6, mdadm 2.4.1-6ubuntu1
<madduck> ok, so it's not related to my recent changes then
<rodarvus> I'll be back in a few minutes
* pitti sighs at gtk.TreeStore and TreeView
<ajmitch> pitti: hm?
<pitti> ajmitch: it's my first time I (try to) use it
<ogra> yeah, its fun ...
<pitti> ajmitch: and it doesn't work... :)
<mvo_> pitti: its the suck :/ 
<ajmitch> ah, it does take a little bit of work :)
<sladen> wiki is feeling like paint drying today
<Kamion>  * redhat-cluster-suite_2.20060716-0ubuntu4 builds: libdlm-dev, libcman-dev, gnbd-client, libdlm2, rgmanager, redhat-cluster-suite, libcman2, gnbd-server, gfs-tools, cman, gfs2-tools, libccs-dev
<Kamion>       but no longer builds:
<Kamion>         o 1.20060222-0ubuntu5: ccs, fence, fence-gnbd, gulm, libcman1, libdlm1, libgulm-dev, libgulm1, libmagma-dev, libmagma1, magma, magma-plugins, redhat-cluster-suite-source
<Kamion> fabbione: those (in the last line) are fine to rebuild, right?
<Kamion> er, to remove
<fabbione> Kamion: they should disappear automatically.. they are not part of edgy anymore.
<fabbione> Kamion: be careful not to remove them from dapper :D
<fabbione> Kamion: unfortunatly for an amazing endless chains of events, this is the first time that the suite can build on archive and publishes binaries
<Hobbsee> pitti: seeing as you're the maintainer.  why would English_southafrican translations be installed with language-support-en?  is that supposed to happen, or what?
<Kamion> fabbione: "disappear automatically"> the above paste is from the automatic report that needs to be processed manually
<pitti> Hobbsee: which other language pack would you want instead?
<Kamion> fabbione: (not-built-from-source removals are only semi-automatic)
<Seveas> pitti, -za?
<pitti> Seveas: that's a country, not a language
<Kamion> fabbione: it would require deliberate effort to remove them from dapper :)
<Seveas> true
<pitti> it's l-support-$LANG, not -$COUNTRY
<fabbione> Kamion: ah ok.. the list seems about right :) go ahead
<fabbione> Kamion: well sometimes i am scared because you are a damn errorless too-efficent machine
<Kamion> righto, thanks, I just like to check removals
<Hobbsee> pitti: i was under the impression that south african translation stuff fell under it's own category, and thought it was odd.  that's all.
<Kamion> Hobbsee: all the language packs install all variants of the language in question
<ajmitch> Hobbsee: so you even get en_NZ to enjoy
<Hobbsee> Kamion: ah okay.  i'm no speaker of south african
<Hobbsee> ajmitch: enjoy?  more like wince thru.  you and your x-murdering :P
<Kamion> Hobbsee: South African translation> well, en_ZA (English as spoken in South Africa) is rather different from xh_ZA (Xhosa as spoken in South Africa)
<Kamion> doesn't make sense to lump them together
<Kamion> whereas English in different countries is basically more or less mutually comprehensible
<zul> its like colour color
<Hobbsee> Kamion: ahhh...right...okay then
<Hobbsee> fair enough
<pitti> Hobbsee: -en contains the country specific flavours of all ENglish-speaking countries
<Kamion> South Africa has something like a dozen official languages, IIRC
<Hobbsee> was just a curious question - which is why i went to the maintainer, instead of filing a bug report whinging about it :P
<Hobbsee> Kamion: ahh...didnt know that
* Hobbsee wishes she actually learnt something useful in geography.
<Hobbsee> pitti: yep, okay, thanks
<Riddell> Kamion: could you move kopete source to main, the binaries are already in main
<Hobbsee> Riddell: darn you!  :P
* Hobbsee really would like them to stay in universe :P
<Hobbsee> just for a bit.  oh well.
<ogra> Hobbsee, time to go for main then ;)
<Kamion> wow, the temperature here just dropped by several degrees nearly instantaneously
<Kamion> yay storms
<jjesse> ooo big storm
<mjg59> Hm.
<mjg59> Air conditioned here, so I haven't noticed anything...
<Hobbsee> ogra: haha.  well...yeah...but i wouldnt want to be rejected.
<jjesse> Kamion: were is here?
<Kamion> Riddell: done, sorry Hobbsee
<Kamion> jjesse: Cambridge, England
<jjesse> ah
<Hobbsee> Kamion: :'(  okay then.  :P
<Kamion> as Riddell says, the binaries were already in main; it was a bug that the source was in universe
<Hobbsee> Kamion: bleh.  true.  i know it had to be done.  i just liked being able to play with it freely.  :)
<CarlFK> edgy alternate - is this message expected?   "At the moment, only the core of Debian is installed.  To tune the system.... [ ]  Ubuntu desktop" http://dev.personnelware.com/carl/temp/Jul27/a/edgydebian.png
<CarlFK> or should I post it to LP
<Kamion> CarlFK: I just fixed that half an hour ago or so
<sladen> CarlFK: that question shouldn't be seen as the priority should be below the threshold
<Kamion> oh yes, didn't notice the Debian bit there, I'll fix that] 
<Kamion> sladen: check your facts kthxbye :-P
<CarlFK> Kamion: glad I asked :)
<Kamion> db_input high $question || true
<Kamion> this is intentional
<Kamion> my fix was to preseed it on non-server CDs, not to drop the priority
<sladen> oh. I. see.
<djbmister> any powerpc devs here??
<Kamion> djbmister: depends what you're asking
<Kamion> sladen: (see the revive-tasksel spec for more information)
<sabdfl> robertj: the Avahi decision certainly belongs with the tech board, not with me
<djbmister> Well its releated to the kernel 2.6.15 kernel and chrp systems
<djbmister> In particular the 'Pegasos motherboard' or ODW as its known
<bddebian> Heya
<Kamion> I'm not familiar with kernel issues involving the Pegasos, unfortunately
<djbmister> The issue regarding this kernel, is that from a compile from source it just doesn't work. 2.6.17 from edgy does work
<Kamion> best to file a bug on launchpad about it, and/or ask on #ubuntu-kernel
<CarlFK> Kamion: can you take a quick look at bug #53699 - "untriaged" makes me think it stalled :)
<Ubugtu> Malone bug 53699 in Ubuntu "installer - names not resolving" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/53699
<bddebian> Hah, where's madduck
<bddebian> hamlib (1.2.5-7) unstable; urgency=low
<bddebian>  .
<bddebian>    * Update to new python policy
<bddebian>    * Update standards version 3.7.2
<bddebian>    * This work by Barry deFreese of Ubuntu, thanks! Closes: #379191.
<djbmister> ok, thanks
<Hobbsee> bddebian: nice!  does it work?
<Kamion> sorry I can't help more directly
<Kamion> CarlFK: I totally ignore untriaged, unconfirmed, etc.
<djbmister> no probs
<bddebian> Hobbsee: I just got the mail this morning so I haven't built it yet
<Hobbsee> bddebian: okay
<Kamion> CarlFK: in this case though I simply didn't see it because it wasn't filed on the installer
<sladen> Kamion: thanks for picking me up on that :)
<djbmister> Just a quick question, nothing to do with the kernel or anything. I'm creating a custom ubuntu cd for the ppc platform and im just wondering, how do i change the default background wallpaper etc etc??
<Kamion> CarlFK: replied, anyway
<CarlFK> Kamion: thanks
<Chipzz> ugh
<Chipzz> X broken in edgy :(
<dholbach> could somebody add some blurb about X to the topic? :)
<ajmitch> dholbach: like "don't ask, it's being fixed"?
* ..[topic/#ubuntu-devel:ogra] : "Ubuntu Development (not support, even with edgy) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs" |  blurb about X
<dholbach> "it will be broken for a while, stick to dapper" or something
<ogra> :P
* dholbach spanks ogra
* ..[topic/#ubuntu-devel:ogra] : "Ubuntu Development (not support, even with edgy) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs" | yes X in edgy is broken atm
<ogra> :)
<ajmitch> slightly more useful :)
* madduck blinks at bddebian 
<bddebian> madduck: I was just prodding you.  We give back on occasion. ;-P
<sivang> dholbach: rather put a link to a work around? :)
<madduck> bddebian: you got the wrong impression. :)
<bddebian> madduck: About?
<madduck> nevermind.
<Kamion> bddebian: I think he means he's not always as negative about Ubuntu as you thought
<ajmitch> sivang: depends what your breakage is - the most likely cause is needing the video drivers to be recompiled
<sivang> ajmitch: ah, then I'm using FOSS ones all over, hopefully I will be able to reboot after todays' upgrade
<ajmitch> sivang: the FOSS ones are the problem
<sivang> hrm, okay, so no reboot for me for now :)
<bddebian> Kamion: Oh, I didn't mean to imply that madduck is negative about Ubuntu, I was just giving him grief about his blog entry :-)
<madduck> bddebian: because that blog entry was something to give me grief over?
<Chipzz> ok, which version of X broke? with some luck I still have the debs and I can downgrade?
<tseng> Chipzz: see the topic.
<Chipzz> tseng: I know it is broken, I want to downgrade, but in order to do that, I need to know to which version
<thom> Chipzz: check your dpkg log and seee what got upgraded
<Chipzz> thom: I do not reboot after every upgrade; this could have been broken for weeks
* madduck waves to thom
<thom> hey mate :-)
<pitti> hi thom
<tseng> thom: (typo 4.0 weee!)
<madduck> thom: will you be in cambridge on aug26 ?
<bddebian> madduck: Of course. :-)  Actually I wanted to comment on it but didn't get the opportunity 
<thom> tseng: oh really? shiny
<madduck> bddebian: my inbox is oepn! :)
<thom> madduck: um.
<thom> madduck: i moved to .nl recently, so it's possible but dunno
<madduck> thom: sorry. :)
<madduck> thom: http://wiki.earth.li/DebianParty2006
<tseng> thom: http://scottstuff.net/blog/articles/2006/07/22/typo-4-0-0
<thom> tseng: nifteh. /me upgrades
<tseng> thom: ive been using svn all this time.
<thom> i've been on some dubious svn export for a while
<ogra> iwj, would you mind taking a last look at SCPC, as i wrote in y mail from yesterday, i think its all adressed now, i can ask sb. else if you dont have the time, but would like to have it approved before the meeting (promised that to Kamion)
<zul> mvo: do you still have that grub bootsplash patch that you did?
<setuid>  I've put together an advisory council (at IBM). I'm looking to backfill some alternates, and am looking for recommendations for 3 seats. Are there people within Ubuntu/Canonical that I should consider?
<setuid> Its called the Linux on POWER Advisory Council, where we'd be sharing some pre-release info for comments, criticism and other ideas before we release it to the OSS community. 
<mdz> Kamion: do you have a todo list for the dapper point release?
<mdz> Kamion: I think we should do the live CD file order optimization
<Kamion> I wasn't going to attempt optimisations in it ...
<Kamion> that said, it might well fall out of the livefs build script changes anyway
<Kamion> so I don't object if somebody wants to put time into collecting the sort files
<Kamion> mdz: my to-do list is about to be largely cleared by way of the mail I'm about to send you about ubiquity
<Kamion> we should clear out the unapproved queue too - there are half a dozen or so items in it
<seb128> Riddell: around?
<Riddell> seb128: hi
<seb128> Riddell: for https://wiki.kubuntu.org/KubuntuEasyZeroconf, do you use the message mentionned on the wiki page? it doesn't look like according to the patch but I might be looking at the wrong place
<seb128> the "Enabling Avahi Zeroconf will open port..."
<Riddell> seb128: oh I need to add that, thanks for reminding me
<seb128> Riddell: no problem :)
<Riddell> seb128: feel free to edit the wiki page and add the port number, then I won't have to look it up
<seb128> Riddell: ok. I've to run now for an hour but I'll do that later if you didn't do it first, thank you
<Kamion> setuid: might be worth asking the Ubuntu technical board for recommendations, if you have time? http://wiki.ubuntu.com/TechnicalBoardAgenda
<shellsage> Hi, I've been googling for about an hour for this and nothing is coming up. Where might I find the ubuntu livecd/installcd source?
<shellsage> Am I supposed to unpack the ISO?
<shellsage> Or is there an archive of it
<setuid> Kamion, I'm going to explore that now, pygi pointed me that direction
<Kamion> shellsage: source for what exactly? everything?
<shellsage> Kamion, everything one would receive on the livecd/installcd
<shellsage> Including the bootable image
<Kamion> shellsage: http://cdimage.ubuntu.com/releases/dapper/release/source/ has ISOs of the source
<Kamion> shellsage: it's also all in the archive (archive.ubuntu.com), available using 'apt-get source'#
<Kamion> s/#//
<shellsage> Kamion, thanks
<shellsage> Also, should I submit a bounty proposal for my project idea? I want to write a branch of ubuntu called crybuntu, that from installation, uses encrypted partitions via cryptsetup-luks, with some neat features like storing the system key on a usb stick.
<Kamion> shellsage: not to rain on your parade but I suspect we're going to get a lot of that via Debian quite soon ...
<Kamion> (partman-crypto)
<Kamion> dunno where the system key lives, though
<shellsage> Kamion, oh, I thought that it would be great to have it all in one project/installable CD like that
<Kamion> you'd be welcome to help with that in Edgy if you're interested - I just need to put together main inclusion reports and stuff for the new bits
<shellsage> So that people could instantly have an encrypted system
<Kamion> right, I believe we're going to have that in mainline
<shellsage> Oh ok
<Kamion> although I confess to not having looked over the code yet
<Kamion> probably alternate install CD only for now
<shellsage> Yes I'd like to help with that then, I've already done it on my gentoo system, and it works very well
<Kamion> I'm going to try to get the bits into main for Edgy Knot 2
<Kamion> (second milestone release)
<shellsage> right
<shellsage> so is it going to be an option of the installer on the livecd, to encrypt the partitions?
<shellsage> or is it just a separate package that encrypts the partitions post-install
<shellsage> via some secure data displacement
<Kamion> shellsage: an option in the installer's partitioner, not on the live CD, on the alternate install CD
<shellsage> ah ok
<Kamion> the live CD can be done too in the longer term but that's dependent on https://launchpad.net/distros/ubuntu/+spec/ubiquity-advanced-partitioner and I don't have any time to do more than the basics on that
<Kamion> (for edgy)
<shellsage> ah
<shellsage> I'm reading the wiki entry for partman now on the debian installer
<Kamion> shellsage: http://wiki.debian.org/DebianInstaller/PartmanCrypto if you haven't found that
<Kamion> "Keyfiles on removable media" is under future plans I see
<shellsage> Kamion, yeah I'm onto the SVN now, having trouble understanding the heirarchy though
<shellsage> I'm not very familiar with the layout of the final.d stuff
<shellsage> finish.d*
<janimo> infinity: do you know why xubuntu desktop CD still gets older packages? (xubuntu-live 2.4 vs 2.6, libgoffice-gtk-1-2 vs 0-3)
<janimo> results in oversized ISOs
<infinity> janimo: Cause I need to re-enable dailies.  I'll do that now.
<Kamion> shellsage: it does assume general familiarity with partman; 'svn co svn://svn.debian.org/svn/d-i/trunk/installer/doc/devel/partman' and 'make' in the resulting checkout to get the partman documentation
<janimo> infinity: so if a CD gets oversized it is no longer builkt on subsequent days?
<Kamion> shellsage: it's not the clearest documentation in the world, though
<Kamion> janimo: no, all the dailies were switched off for Knot 1 and never reenabled until now
<infinity> janimo: No, the daily livefs cronjobs have never been enabled for edgy.  Doing that right now.
<janimo> infinity, kamion: ok, thanks. Seeing daily isos come out the past days I though they were basedon updated livefs as well.
<shellsage> Kamion, thanks, I'm going to look into it. I thought this was a great idea so hopefully I'll be able to contribute, at least the usb key thing.
<shellsage> It'd be incredible to be able to just up and quickly install encrypted systems
<setuid> Kamion, I can't seem to find the TB mailing list. Any idea? 
<Kamion> setuid: scheduling stuff for discussion is done by adding it to the wiki page and showing up to the next meeting
<Kamion> janimo: nah, I enabled the cdimage cron jobs, but that crontab is independent from the livefs ones on the buildds
<setuid> I want to send a blanket message to the TB members, not spam, but soliciting some input. 
<bddebian> How do most of you main types feel about your Universe merges?  Do you care if I just do them or leave them for you?
* Kamion answers setuid in /msg
<Gloubiboulga> dholbach, seb128, do you know if we'll get the new xklavier in edgy, or if we'll keep xklavier11?
<dholbach> Gloubiboulga: is there a new version of libxklavier?
<Gloubiboulga> dholbach, not a stable one, but Jani told me that the newt one might be part of gnome 2.16
<dholbach> Gloubiboulga: nothing requires it yet and it so that'd only be gnome-control-center
<Gloubiboulga> ok
<dholbach> Gloubiboulga: i'm not familiar enough with that codebase to judge, but as they're in api/etc freeze now, i guess not
<Gloubiboulga> dholbach, ok, thanks :)
<dholbach> Gloubiboulga: we might figure that we'll be happier with 7.1 and a new libxklavier, but i don't know
<dholbach> i mean xorg7.1
<infinity> Kamion: livefs dailes are re-enabled for i386/powerpc/amd64.... I'm not turning them on for the other arches (yet), due to disk space concernes, and a pending move to squashfs for all of them.
<infinity> concerns, too.
<Kamion> infinity: cool, thanks
<wasabi> Hmm. Some update killed alsa.
* wasabi investigates.
<bddebian> Heya LaserJock
<LaserJock> hi bddebian 
<mhb> hello to all
<bddebian> Hello mhb
<zul> hey lj
<mhb> I talked with someone in this channel a few feeks ago about the translations of Edgy in Rosetta
<mhb> (weeks)
<mhb> Well, I was informed it should take no longer than a few weeks, but nothing has happened since then, so here I am again :o)
<mhb> Does anyone know more about the start of Edgy translations?
<LaserJock> mhb: I don't know, but you would probably get a better answer from the translators mailing list (it's on lists.ubuntu.com)
<mhb> LaserJock: you think someone else than translators are signed in it?
<mhb> LaserJock: I read that ML, by the way.
<mhb> LaserJock: because it's not a question exactly for translators
* pygi pokes sivang ;)
<mhb> LaserJock: but okay, I'll try it :o)
<LaserJock> mhb: sorry, was away for a sec. I think that the admins would also read the list so it is probably the most appropriate place to ask. I'm sure other translators are interested too.
<mhb> LaserJock: we'll see :o)
* bluefoxicy watches apt throw fits over upgrading OOo
<seb128> Gloubiboulga: why do you want it?
<Gloubiboulga> seb128, I don't want it, I'll certainly try to write a tool to manage keyboard layouts using xklavier
<seb128> Gloubiboulga: xkb things are usually easy enough to break to not touch them for an unstable version if not required
<Gloubiboulga> seb128, I'm fine with the current xklavier, I just don't want to start something with the new one and have to rewrite everything later :)
<seb128> Gloubiboulga: we have 2.91 which is the new API,ABI one
<seb128> Gloubiboulga: it has been updated during the GNOME 2.15 cycle
<Gloubiboulga> ah right...
<bddebian> bbiam
<lfittl> q
<lfittl> argh, sry
<bddebian> re
<Burgwork> greetings bddebian 
<bddebian> Heya Burgwork
<pitti> Hi
<Burgwork> hey pitti 
<bddebian> Hello pitti
<djbmister> Can anyone answer my question regarding a customised livecd of ubuntu
* Spads looks at the topic
<plastictabs> anyone alive?
<Burgwork> hmm, he stuck around a long time, eh tseng?
<tseng> Burgwork: im home
<tseng> oh, heh
<Burgwork> makes Viper550 seem like a positive elephant
<Amaranth> Burgwork: ?
<Burgwork> Amaranth, viper550 has a habit of flitting in and out of -desktop
<Amaranth> ah
<tseng> Burgwork: viper brings a few more infuriating traits to the table
<pitti> mvo: yay, with the new update manager and my latest package the crash reporting gui now works just wonderfully
* pitti hugs mvo
<Burgwork> tseng, meh
<tseng> posting my ideas as his own, then when flamed claiming I made him say it
<tseng> is the current winner.
<mvo> pitti: great news :)
* pitti uploads a new apport source
<doko> pitti: -> #ubuntu-toolchain ...
<Burgwork> pitti, is apport generic enough to run on other distros?
<pitti> Burgwork: mostly yes
<pitti> Burgwork: the Ubuntu specific bits are (1) our kernel's crash dump helper hook and (2) update-notifier calling apport-gtk when it senses (via inotify) a new report
<pitti> Burgwork: (1) can be solved by using a glibc patch or a preloaded library
<pitti> Burgwork: and (2) needs an alternative implementation, of course
<Burgwork> pitti, just thinking about it, because GNOME is talking about bug reporting currently
<pitti> Burgwork: but the data collection and the frontend are not ubuntu specific
#ubuntu-devel 2006-07-28
<Burgwork> pitti, any reason it uses update-manager for telling it about when a file changes?
<pitti> Burgwork: just to avoid installing yet another daemon into the user's session
<pitti> Burgwork: and u-n was supposed to become a more general 'event-notifier' for a looong time already
<Burgwork> ah
<Burgwork> I remember the specs on that
<pitti> Burgwork: but it's just some inotify -> run apport-gtk glue, nothign more
<Burgwork> pitti, would you mind putting an end to the zeroconf discussion on -devel. You are the security guy, after all
<tseng> Burgwork: we suggested earlier that someone put it on the agenda for tb
<tseng> for a final word
<Burgwork> goodf
<Burgwork> otherwise it will just go around in circles
<mdz> I've been deleting that thread because it didn't seem to raise anything new
<mdz> we decided this ages ago
<mdz> no network services by default, make it easy to enable if the user wants it, kthxbye
<ogra> can we add it to the ML spamfilter ? :)
<Burgwork> heh
<pitti> Burgwork: whoa, right, I need to find time to actually read the mega-thread; I was pretty scared of it when I saw it, I admit
<Burgwork> pitti, you don't need to read it. Just say "not going to happen. kthyxbye"
<pitti> but basically what mdz says, I totally agree
<ogra> i cant remember the last thread that was this noisy on -devel
<pitti> Burgwork: ok, then I read the first mails at least
<pitti> and skim the rest
<mdz> it spirals into lots of off-topic stuff without changing the subject
<pitti> ogra: naked people artwork? or was this sounder? :)
<ogra> nope -users :)
<mdz> mako: any opinion on this gentium update?
<ogra> indeed, thats unbeaten
<Burgwork> how to market your new distro: put half naked people in it
<tseng> it got peoples attention, if nothing else
<ogra> Burgwork, thats so 2004 ...
<bluefoxicy> it got naked people on my screen for a while
<bluefoxicy> wait........
<Burgwork> ogra, damn. Is animal sex 2006?
<bluefoxicy> XD
<ogra> Burgwork !!
<tseng> Burgwork: oh jeez.
* ogra raises a vrow
<ogra> and a brow
<bluefoxicy> Burgwork:  I cannot approve that; it would create unfavorable PR with most people.
<bluefoxicy> Burgwork:  however I'm not on Canonical's staff so :)
<Burgwork> ah, but you forget bluefoxicy, any news is good news
<bluefoxicy> Burgwork:  The news on MSN about the guy who died from ... an interesting encounter with a horse.. was not good news.  It involved death!
<Burgwork> I can see it now: Mark announces edgy+1 as "fucking ferrets" completely with artwork
<Burgwork> anyway, this horribly off topic...
<bluefoxicy> Burgwork:  hey, come on, the mile stone releases are already called KNOTS anyway
<bluefoxicy> yes, yes it is.
<bluefoxicy> Something more on topic than sex with animals:  I agree with mdz, don't turn on random network automagic serverish things by default.  Give me a big red button to click, complete with "this will expose your naked ass to the network, are you sure you want to do this?" warning.
<Burgwork> bluefoxicy, that just got uploaded, by the ever busy seb128 
<bluefoxicy> anyway I should really restart X, I've managed to race GTK+ again and now my themes are broken.
<Burgwork> pitti, congratulations --> http://searchsecurity.techtarget.com/originalContent/0,289142,sid14_gci1202417,00.htm
<bluefox> DAMNIT.
<bluefox> tseng:  remember when i said something about X breaking and you said something about not trolling?
<pitti> Burgwork: oh, wow :)
<bluefox> It's now telling me there's no such driver 'via' or 'vesa' but I have xserver-xorg-video-all installed  ><
<bluefox> oh.  abi version for vesa.  /me grumbles
<Burgwork> pitti, LWN did a survey earlier this year which also praised our security response
<Burgwork> bluefox, this is not a user support channel
<bluefox> Burgwork:  yes I know.
<Burgwork> pitti, which means you. So congratulations
<pitti> joy :)
<tseng> bluefox: most of those have already been fixed
<tseng> bluefox: and if you cant have a broken X without making a fuss, indeed, you should not run development
<Kamion> pitti wins the "works really hard" award
<Mithrandir> Kamion: unlike you, who is clearly a slacker?
<tseng> Kamion trails the desktop team imo
<tseng> :P
* Mithrandir finds a bucket and cleaning stuff and starts cleaning up the irony dripping all over the place.
<pitti> Burgwork: at least today  is the first time when we managed to get a new firefox version out before upstream announced it :)
<pitti> until now we had an average response time of 6 days or so
<Burgwork> is that because mozilla is playing nicer with Linux distros?
<pitti> Burgwork: not, it's just that this time we just started working on it earlier
<pitti> Burgwork: of course hoary and breezy are fucked again
<pitti> and require some weeks of backporting
<pitti> at least in 1.5.0.5, half of the vulns do not affect 1.0.x in the first place
<bluefox> pitti:  Wasn't the policy, for a brief period, "Just upgrade to the new firefox version"?
<pitti> Burgwork: but also the recent microversion updates from upstream are much better than early 1.0.x updates
<pitti> Burgwork: back then, these updates were pretty messy, and so were the advisories
<Burgwork> bluefox, 1.5 breaks api/abi and thus all things needing gecko would need to be recompiled
<pitti> there was much complaint, and now they are doing very good, with embargoed vendor pre-notifictaions and such
<Burgwork> which is a rather large list
<bluefox> Burgwork:  oh right.  I forgot they haven't stabilized their freaking ABI.
<pitti> bluefox: not a policy, it was an option we tested
<doko> is there an applet to watch the cpu temperature?
<pitti> bluefox: we gave up after it broke half of the world and gtkmozembed
<bluefox> pitti:  looking forward to XUL runner?  :)
<pitti> doko: yep, I used this for some time (tied to lm-sensors
<zul> hey
<pitti> bluefox: won't solve the principal problem
<ogra> doko, i have a small python thingie for the notificationn area
<pitti> doko: sensors-applet IIRC
<ogra> want it ? 
<bluefox> pitti:  I guess not.
<aimaz> is there a way to compile just one module?
<aimaz> instead of `make modules` to make them all
<ogra> doesnt module-assistant address that ? or is it only for "not in kernel tree" modules ?
<shawarma> aimaz: Sure. make modules DIRS=/path/to/the/directory/that/holds/the/source/for/the/module
* fabbione yawns
<zul> hey 
<shawarma> fabbione: Hey! Any action today?
<shawarma> aimaz: Something along those lines anyway. Check the top-level makefile. It's got loads of helpful comments.
<aimaz> shawarma, ok, thanks
<fabbione> shawarma: no nothing yet
<doko> 90C CPU ..., then it throttles down 
<shawarma> fabbione: How much overdue is she?
<Kamion> Keybuk: http://librarian.launchpad.net/3581111/buildlog_ubuntu-edgy-i386.debian-installer_20060711ubuntu5_FAILEDTOBUILD.txt.gz
<fabbione> shawarma: 2 weeks
<Kamion> Keybuk: does udev-udeb actually use libvolumeid0? if so, I need to tweak your packaging
<sistpoty> infinity: can you help me with bootstrapping fpc? (bug #2253)
<Ubugtu> Malone bug 2253 in fpc "fpc needs bootstrapping on buildds" [Medium,Confirmed]  http://launchpad.net/bugs/2253
<Keybuk> Kamion: oh, grr
<Keybuk> that's my bad, sorry
<Keybuk> the udeb is supposed to have a statically linked vol_id
<Kamion> ah
<shawarma> fabbione: Gah.. She must be REALLY impatient by now.
<fabbione> shawarma: yeah indeed
<Kamion> Keybuk: can I let you take care of requeueing debian-installer once you've fixed that? I'll be away tomorrow
<Keybuk> Kamion: how do I do that?
<Keybuk> is it just a source package?
<Kamion> yes
<Keybuk> ok, given back
<Kamion> plain and simple - it's only the .changes that is a little odd
<Keybuk> uh, s/given back/fixed udev uploaded/
<Kamion> Keybuk: err, surely only after you've fixed udev? :-)
<Keybuk> I knew what I meant :p
<Kamion> aha
<Keybuk> had removed that by accident while debugging stuff
<bddebian> Heya
<pitti> ogra: new ubugtu feature?
<ogra> pitti, it reports new bugs in lp immediately to #ubuntu-bugs
<pitti> ah, cool
<bluefox> ubugtu's best feature is @chuck
<zul> eh?
<pitti> ogra: DoSing the channel, eh? :)
<ogra> not atm ... but i will part from there during release time :)
<jsgotangco> heh
<pitti> Kamion: dapper point release> we should check whether we got the pbbuttonsd fix in to disable anacron on the live CD; I don't know off-hand whether we did that already
<pitti> but since there's no new version in dapper-updates, I suppose that's still outstanding
<Kamion> pitti: no pbbuttonsd in dapper-updates; can you look at fixing that tomorrow?
<pitti> Keybuk: ^ can you please confirm?
<Keybuk> it wasn't a pbbuttonsd fix?
<Keybuk> it was a casper fix
<pitti> Keybuk: ah, casper
<Keybuk> casper tried to disable anacron wrong
<pitti> Keybuk: do we have the fix in dapper-updates already?
<Keybuk> (given the stupid, pedantic, idiotic, crap way invoke-rc.d works)
<Keybuk> I think so
<Kamion> no, we don't
<pitti> Riddell: some MIR like openct rang a bell, as if I had already seen them in the past and complained about hard supportability
<Riddell> pitti: I could see if gpg2 can manage without it, I've no idea if it can or not
<pitti> Riddell: I'll look at the stuff tomorrow in detail and talk with you
<^ohoel> direct rendering with the ati drivers fail because X is trying to open /usr/X11R6/lib/modules/dri/r300_dri.so (which doesnt exist) instead of /usr/lib/dri/r300_dri.so
<^ohoel> should I file a bug for that?
<mjg59> In what?
<mjg59> Dapper or edgy?
<^ohoel> edgy :)
<mjg59> Ok
<^ohoel> upgraded, though
<mjg59> Mesa's got ahead of X
<Mithrandir> ^ohoel: file a bug, then :-)
<mjg59> I'd check if there's a bug, but it ought to get fixed with the next xorg upload
<^ohoel> okay, I'll do a clean knot1 install and see how things fare first then :)
<crimsun> there's a bug on it already
<crimsun> 54299
<^ohoel> bug 54299
<Ubugtu> Malone bug 54299 in mesa "libGL.so can't find DRI modules" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/54299
<crimsun> the fix is described in the report.
<bluefox> pitti:  I'm still curious as to how packages that break with GccSsp are handled
<pitti> bluefox: there aren't many; we just found glibc so far
<pitti> bluefox: and if there is any, the quick fix is just to build with -fno-stack-protector
<pitti> bluefox: of course it's better to fix the actual bug
<slomo> pitti: don't forget libgcc (or is this now working with ssp?) :)
<pitti> slomo: right, but that has been fixed
<bluefox> pitti:  but no plan on providing a mechanism for reporting, i.e. so the user can easily audit which packages (in main at least) aren't protected?
<pitti> bluefox: reporting?
<Kamion> pitti: yaboot was another; it builds without libc
<pitti> bluefox: I plan to write a script to report packages which aren't yet built with ssp, if you mean that
<pitti> Kamion: right
<Kamion> I made it use -fno-stack-protector
<Kamion> it doesn't use -fstandalone though, not sure what's up with that
<bluefox> pitti:  amortized, it's a big help; strictly speaking, I can't 'rely' on stack smash protection to actually be applied to any package
<Kamion> does -fstandalone imply -fno-stack-protector? If not, it surely should
<bluefox> pitti:  albeit amortized gains are often very, very awesome in practice ;)
<bluefox> Kamion:  any library that doesn't use glibc or libssp can supply __stack_chk_fail() and friends itself ne?
<bluefox> the kernel for example; although this is largely useless according to the hardened gentoo guys.
<Kamion> bluefox: nm -D <binary> | grep __stack_chk_fail could be wrapped easily enough
<Kamion> bluefox: I don't see the point for most standalone things
<bluefox> (I've only witnessed one stack buffer overflow in the kernel ever myself)
<bluefox> Kamion:  Not all programs have __stack_chk_fail() in them, I did write a script to test for it.
<Kamion> aside from the kernel, they're not usually running on security boundaries
<bluefox> there's a few executables and libraries that never use a local char[]  buffer
<bluefox> so they don't get any protection (they don't need it)
<bluefox> thus they don't go looking for the symbol
<Kamion> mdz: do you think we can basically sync oo.o from dapper-proposed to dapper-updates, then? i.e. are you in principle happy with it as it stands?
* Kamion had better go and pack
<Kamion> Keybuk: the archive's all yours for the weekend ;)
<Keybuk> heh
<pitti> Kamion: have fun at the wedding
<Keybuk> I promise not to redecorate while you're away :)
<Kamion> mdz: I've sent mail to Adam about the livefs sorting stuff and asking him if he can do a dapper livefs build
<Kamion> thanks
<Kamion> I bet that's what you say to all the boys
<bluefox> lol
<mdz> Kamion: I haven't even looked at it; was there an email with the changes?
<bluefox> Weddings are nowhere to look for boys.  Try college.
<pitti> good night everyone
<bluefox> later pitti
<Kamion> mdz: https://lists.ubuntu.com/archives/dapper-changes/2006-July/011897.html
<Keybuk> Kamion: only when David's out of earshot
<Kamion> https://lists.ubuntu.com/archives/dapper-changes/2006-July/011898.html
<Kamion> that's the best I can offer at present
* robertj_ nominates Lathiat to attemp to slay the avahi issue at Tuesday's TechBoard Meeting;)
* robertj_ uses his how not to be seen skills
<Keybuk> hmm?
<Keybuk> I thought Lathiat was on the "don't enable by default" side?
<robertj_> sounds good, anything to get my email to go down ;)
<robertj_> I have to stand on it every morning & jump up & down to compress it
<robertj_> otherwise my laptop won't close
<Keybuk> doesn't that void your warranty?
<bluefox> I am on the "don't enable by default" side
<bluefox> these aren't macs
<ohoel> I just love arguments that involve windows or mac :] 
<bluefox> ohoel: don't macs have something like Avahi?
<bluefox> and isn't their security model, "We're not PCs, we don't have any viruses"?
<tseng> bluefox: apple wrote mdnsd
<tseng> "bonjour"
<ohoel> bluefox: yes, but I fail to see the relevancy of those arguments in any case...
<ohoel> not just in this case but on a general basis
<bluefox> tseng:  yes my point though is I'd rather not just one day wake up and find that I have something that magically makes changes to my network "as needed" to "get things working" with my only consolence being a pat on the back from Ubuntu saying, "We're pretty sure we're not exposing you to any security holes automatically"
<mjg59> Oh god can we avoid this discussion *here* as well?
<bluefox> which as I understand is what avahi does-- opens and closes doors on the network for random programs in places where they'd normally just not work
<tseng> you are making things up
<mjg59> tseng: Hush
<mjg59> It's on the tech board agenda
<bluefox> tseng:  no, not really.  Going on broken understanding of the topic maybe.
<mjg59> I intend to spend Tuesday evening with a bottle of whisky and my laptop
<tseng> bluefox: yes, lets all shutup.
<bluefox> oh god no
<bluefox> no coding while you're drunk
<mjg59> bluefox: Oh, I won't be coding
<mjg59> I'll just be making long-term decisions about the Ubuntu network security model
<bluefox> just think about waking up the next day and saying, ".... Jesus, when the hell did I write THAT crap?"
<mjg59> It'll be fine
<mjg59> What could possibly go wrong (other than ANOTHER 10,000 EMAILS)
<bluefox> I hope you're kidding
<tseng> he revesed the macbook pro with a bottle of alcohol
<tseng> he can handle it.
<mjg59> bluefox: If you have any concern over any of the technical justifications I may give at the tech board meeting, please feel free to point them out
<Keybuk> mjg59: we should have had a special emergency meeting of the technical board to discuss it while mdz was in the UK
<mjg59> Keybuk: Yeah, with hindsight
<Keybuk> in a pub
<Keybuk> with an unlimited budget
<mjg59> With Mark buying
<Kamion> mjg59 is more together while drunk than a lot of people are while sober, to be perfectly honest
<mjg59> Should have done it in Wolverhampton
<bddebian> heh
<mjg59> bluefox: I wrote usplash having spent an entire week very, very drunk
<bluefox> mjg59:  I know people who claim they drive much, much better when they're smoking pot in the car; it doesn't make me feel any more secure ;)
<Kamion> right, bed, see you lot on Monday
<Keybuk> bluefox: especially when it's the guy at the front of the bus with the cap?
<Keybuk> Kamion: enjoy
<mjg59> Oh god there's a fruitfly in my beer
* mjg59 cries
<bluefox> eww.
<mjg59> I probably carried it home in my hair
<bluefox> I hate bugs, they're both icky and disgusting.
* Keybuk wonders how far the nearest 24hr licenced shop is
<mjg59> I slaughtered about a thousand of them today
<fabbione> WTF
<fabbione> the house of the neibourg is on fire
<fabbione> and it's burning close to main power lines
<fabbione> if i fall off you know why
<bluefox> I need X so bad.
<bluefox> somebody bash.org fabbione
<rodarvus> bluefox, whats wrong with X?
<bluefox> rodarvus: it seems that half the drivers for the new X in edgy have not been uploaded to the build server, or something.
<rodarvus> bluefox, yes, thats right
<bluefox> including vesa and via (I have a via card), which are both my options; so I can't use X in edgy at the moment.
<rodarvus> and that leads to the next question -> what is your video card?
<rodarvus> ok
<bluefox> rodarvus:  I think for future reference, when X is going to break its driver ABI, vesa should be rebuilt first :)
<rodarvus> bluefox, if I prepare a via package in the next few minutes, and update it to a staging are, would you volunteer to test it?
<bluefox> rodarvus:  Sure
<fabbione> bluefox: nothing to joke about
<fabbione> all the lines pass close to that house
<rodarvus> fabbione, indeed
<bluefox> fabbione:  I know, I'm a bad person.
<fabbione> it's one of the oldest in the area
<mdz> Kamion: can we easily adjust the progress bar in ubiquity for the point release, to account for the langpack changes?
<Lathiat> bluefox, keybuk: while it'd be great if it was enabled by default its clearly not going to happen I don't see the Tech board overriding the decision of the responsible people to grant an extra open port policy in any case so its a moot point really IMHO
<Lathiat> and sounds like the option to enable it is pretty much done in gnome & kde so people can stop arguing a solution is implemented ?:)
<Lathiat> but we can discuss it at the TB if people think it'l help
<mjg59> Lathiat: We're going to discuss it at TB to make the big pile of email go away
<Lathiat> thats what i mean by helping :)
<bddebian> Pleeeaasse :-)
<Kamion> mdz: (still here because I'm INSANE) what langpack changes do you mean?
<Kamion> anyway, yes, it's relatively straightforward to adjust if you just mean changing the waypoint positions
<Kamion> really -> bed now
<bddebian> Gnight Kamion
<rodarvus> bluefox, I've built (and uploaded) xserver-xorg-video-via
<rodarvus> it is also available at the staging repo I told you about -> http://people.ubuntu.com/~rodarvus/packages/xorg/
<rodarvus> I'd appreciate if you could test it.
<bluefox> rodarvus:  will get
<rodarvus> please report as soon as you have results :)
<Hobbsee> rodarvus: broken anything else today?  ;)
<rodarvus> of course.
<Hobbsee> rodarvus: oh dear :(
<rodarvus> if its not broken, then its not interesting.
<Amaranth> broken is fun
<Amaranth> unbreaking binary drivers isn't
<ajmitch> afternoon
<bluefoxicy> well
<bluefoxicy> The good news is, I'm back in X
<bluefoxicy> The bad news is, I'm on a live CD.
<bluefoxicy> rodarvus:  Starting X with that driver makes the system cease to respond
<bluefoxicy> can't kill X, can't sysrequest, can still make the numlock light turn on and off.
<bluefoxicy> I would call that not working.
<rodarvus> hmm
<rodarvus> fun stuff
<rodarvus> bluefoxicy, do you have the rest of the X.Org libraries up-to-date?
<bluefoxicy> yes, I apt-get update/upgrade/dist-upgraded about an hour ago at most.
<rodarvus> *nods*
<rodarvus> bluefoxicy, I uploaded xserver-xorg-video-vesa to the same location, if you're willing to test it
<bluefoxicy> rodarvus:  Sure.  I'll just mount my root and... oh um, what URL again?  I seem to have lost that.  No logs.
<rodarvus> bluefoxicy, also, the logs of the failure using the via driver + xorg.conf would be immensely appreciated (attached to new bug on LaunchPad :) )
<rodarvus> http://people.ubuntu.com/~rodarvus/packages/xorg/
<bluefoxicy> rodarvus:  yeah I should be able to get an xorg.0.log; the system seemed alive, just ill responsive, so it probably made a log.
<rodarvus> indeed.
<rodarvus> bluefoxicy, also, please make sure you (temporarily) add this repository to your sources.list, to make sure the rest of the (input) drivers you might be using are up-to-date too
<Hobbsee> rodarvus: do you happen to know if X is broken for everyone, or just the ATI/Nvidia users?
<bluefoxicy> rodarvus:  deb http://people.ubuntu.com/~rodarvus/packages/xorg/ / main?
<rodarvus> Hobbsee, nvidia binary driver is not affected, don't know about ati
<rodarvus> ati and nvidia opensource drivers are already uploaded (and published)
<rodarvus> deb http://people.ubuntu.com/~rodarvus/packages/xorg ./
<rodarvus> deb-src http://people.ubuntu.com/~rodarvus/packages/xorg ./
<bluefoxicy> ah.   Just ./, ok.
<Hobbsee> rodarvus: right, okay.  any idea on intel cards, specifically (just the default drivers)?
* bluefoxicy reads the release file.. ok got it.
<rodarvus> Hobbsee, i810 is published too
<Hobbsee> rodarvus: cool.  it just might be safe to update then :P
<rodarvus> Hobbsee, http://people.ubuntu.com/~rodarvus/packages/xorg/status.txt always has up-to-date information on what has been uploaded/published
<zul> its always safe ;)
<Hobbsee> zul: well, they havent had apt break dramatically in a while, so i guess you could say that.
<rodarvus> Hobbsee, Edgy is a development version of Ubuntu - if it breaks, you get to ammend the pieces ;)
<Hobbsee> rodarvus: ah, thanks :)
<Hobbsee> rodarvus: i'm aware of that - i'm just not that great a fan of losing X if i dont have to :P
<Hobbsee> seeing as i dont have the expertise to fix it
<fabbione> X is obsoleted :)
<fabbione> who needs X anyway...
<Hobbsee> hehe
* Hobbsee likes X.
<zul> rodarvus is obsolete :)
<rodarvus> actually, if I'm not wrong, Edgy is not upgradeable right now, due to missing update on openoffice.org-l10n-en_gb & openoffice.org-l10n-en_za
<Hobbsee> bit hard to fix kubuntu with no X.
<fabbione> Hobbsee: gtkfb? no qtfb?
<Hobbsee> rodarvus: ah yeah, i noticed that.  i was more concerned with the mesa stuff, that might kill my machine for a while
<Hobbsee> fabbione: er, what?
<sistpoty> Hobbsee: bah... during breezy x was broken for about two weeks (or longer)... ;)
<rodarvus> zul, I'll plant a trojan horse on X - we'll see who's obsoleted :)
<fabbione> Hobbsee: gtk with directfb support :)
<Hobbsee> fabbione: ah.  no idea.
<bluefoxicy> rebooting.
<zul> rodarvus: ill plant a trojan horse in the kernel so there ;)
<rodarvus> (pseudo-code) if username == 'zul' abort();
<fabbione> Hobbsee: so you get rid of X 100%.. tho you need a working fb :P
<Hobbsee> fabbione: haha great.
<rodarvus> zul, we're even, then :)
<zul> rodarvus: damn straight :)
<fabbione> tsk
<fabbione> rodarvus, zul: you have both being owned...
<zul> fabbione: yes my master...
* fabbione makes zul and rodarvus note that he did maintain both X and kernel before... rootkits? obsolete toys
* rodarvus pays respect to master fabbione 
<fabbione> raise young lords of the sith
<zul> heh..
<zul> did i mention that i dont like star wars ;)
<bluefoxicy> rodarvus: upgraded from your repo, via still busted.  vesa works.
<rodarvus> hooray
<rodarvus> bluefoxicy, please report the via brokeness to LaunchPad
<rodarvus> I'll deal with it tomorrow, probably
<bluefoxicy> wow did this get worse since last time I looked at it
<rodarvus> bluefoxicy, ?
<bluefoxicy> rodarvus:  scrolling causes a ripple to start at the bottom of the screen and climb to the top for about half a second; same if I get a message in a channel where the IRC window is full of text
<bluefoxicy> I just don't remember the vesa driver being this slow.
<rodarvus> vesa driver is slow.
<rodarvus> it is not accelerated
<bluefoxicy> so I noticed!  :D
<jsgotangco> isn't that the behavior ever since?
<bluefoxicy> jsgotangco:  I used to watch videos with Vesa.  It'd eat 100% cpu but the video was smooth :)
<jsgotangco> thats why vesa is such a bad way to benchmark right
<jsgotangco> ahh
<bluefoxicy> It was slow, yeah, I just don't remember it being *this* slow :)  At any rate, not important; it works.
<rodarvus> bluefoxicy, don't forget to open the bug on LP :)
<bluefoxicy> rodarvus:  that's what I'm doing :)
<bluefoxicy> #54308
<rodarvus> bluefoxicy, please attach the output of lspci -vv to this bug too
<rodarvus> sorry, forgot to tell you before
<bluefoxicy> done.
<rodarvus> bluefoxicy, thanks
<bddebian> fabbione: You up yet?
<fabbione> bddebian: i never went to sleep
<bddebian> Yikes
<bddebian> fabbione: Any idea why we diverged from Debian for twm?
<fabbione> bddebian: probably because of modular tree hitting Ubuntu a year earlier than Debian?
<fabbione> but otherwise no
<bddebian> Oh, aye, duh.  Probably safe to re-sync back now though eh?
<Chipzz> oh btw
<Chipzz> thx for fixing X :)
<fabbione> bddebian: i assume so...
<Chipzz> (whoever fixed it :))
<fabbione> bddebian: i don't use twm so i really have no idea
* Chipzz actually knows someone who uses twm
<bddebian> fabbione: OK sorry, just the last changelog entry from Daniel Stone says taking maintainership from you..
<Chipzz> on debian though :P
<fabbione> bddebian: i think i did one or two uploads because i was doing the batch of X apps when we went modular
<Chipzz> though I can't really grasp why someone would be as masochistic as to use twm :|
<fabbione> Chipzz: a long time ago, there was no other option...
<Chipzz> fabbione: as in, 15 years ago
<bddebian> fabbione: OK, sorry to bug you just trying to cover my ass before merging/syncing.  Thanks.
<Chipzz> nowadays, computers have more than 4MB of ram :P
<bddebian> Chipzz: Some people don't like all the fluff
<fabbione> Chipzz: when i started using linux on 486, i can tell you that gnome as we know it know, would have never gone so far
<fabbione> Chipzz: and for the use i make of X, openbox is way tooo much for me
<Chipzz> bddebian: yes, but for crying out loud, you even need to position the windows yourself
* fabbione has a scripts that opens a bunch of xterm and he is happy
<angasule> I have a 486 dx2 66 MHz, 8MB RAM, a hercules card and ambar screen (also a 286, but that's in a closet, not working)
<angasule> some guy, somewhere, actually wants to run linux in a toaster
<Chipzz> fabbione: I can understand you don't require much from a window manager, but there are other very simple wm's that do have very few resource requirements, and are easier to use :)
<Chipzz> angasule: do you actually *use* that box? ;)
<fabbione> Chipzz: it's a matter of choise
<fabbione> Chipzz: and i use a similar box as angasule .. m68k 8Mb of RAM
<Chipzz> I have a 486dx2 80Mhz, 24MB ram, and last I used it it was for having a shitload of consoles open at 132x60 ;)
<angasule> hmm, I keep it off most of the time, because it's in my room, but the idea is to use it as a web server, works just fine for that
<angasule> I love the ambar screen
* Chipzz has been a very heavy console user up till a few years ago
<angasule> and what do you use X for, Chipzz?
<Chipzz> firefox mostly
* fabbione radiates a bit less hate towards redhat cluster suite
<Chipzz> and rxvt for ssh'ing to other hosts
<Chipzz> rxvt and gnome-terminal
<infinity> I pretty much just use X as a better way to have a few dozen terminals.
<angasule> what got me in this channel is another piece of old hardware, a Warrior 5
<Chipzz> sometimes evince
<Chipzz> infinity: alt-f[x]  is a very fast way of switching consoles
<fabbione> infinity:  i knew you were going to stick your head out just mentioning m68k
<infinity> Chipzz: I don't have 40+ function keys.
<angasule> Warrior 5 is the typical soundcard joystick, 2 axes, 2 buttons
<Chipzz> infinity: alt-shift-fx will give you 24 :)
<infinity> Chipzz: I know.  That's not quite enough. :)
<Chipzz> infinity: also, there's screen ;)
<bddebian> Heya infinity
<infinity> Of course, now that I'm tied to launchpad, I also need a few billion firefox tabs at any given moment, too.
<infinity> So yay for that.
<bddebian> Oh, infinity, while you are here, are there any of your Universe merges you wouldn't want me to touch?
* infinity checks.
<angasule> I'm using kubuntu, and there is no way to configure a soundcard gameport joystick, I had to resort to modprobe'ing and mknode'ing and sustantivising
<infinity> bddebian: Nope, they're all fair game.
<bddebian> infinity: OK, thx
<bddebian> Oh, fabbione, what about xfs?
<infinity> bddebian: Most of it just looks like small FTBFS tweaks and such.
<bddebian> Aye
<infinity> bddebian: dmraid may be a bit more, but just be careful.
<bddebian> OK, thx
<bddebian> I don't know if I'll hit them all, I just want to make sure I don't step on any toes
<fabbione> bddebian: same as twm
<bddebian> fabbione: Fair enough, thx
<fabbione> bddebian: universe stuff, just do it.. i don't care enough to go and look
<fabbione> bddebian: otherwise it would probably be in main
<infinity> bddebian: As a general rule, unless I'm listed in the Maintainer or Uploaders field (ie: I maintain it in Debian), I don't really maintain anything in universe, beyond random bugfixes.
<infinity> bddebian: So, it's all fair game, IMO.
<bddebian> I know, but it seems as soon as I do something, I get in trouble for a package I shouldn't have touched :-)
<sivang> morning
<sivang> so, X is broken, and I forgot all about it and rebooted last night, what do I do to bring it back? :-)
<ajmitch> upgrade your drivers, they should be built & in the archive by now
<sivang> ajmitch: okay, thanks
* sivang actually needs to switch to the prop. ones
<sivang> ajmitch: what was the bug the prevented them from working?
<ajmitch> driver ABI
<sivang> ah, cool then
<Lathiat> is anyeon else having issues with it not mounting your rootfs?
<Lathiat> sits there waiting forever, but if i boot the oldest dapper kernel i have + set root= back to /dev/md2 it works
<Lathiat> (but neither alone is enougH)
<bluefoxicy> why am I up at 3am still.
<whiprush> Gman: ping
<Gman> hi whiprush 
<whiprush> quick question for you.
<whiprush> I'm giving some talks over the next few months about our gnome deployment, which uses sunrays, I read that sun plans to made their entire 
<whiprush> "middleware" stack OSS.
<whiprush> does this include the sunray server stuff?
<Gman> i honestly don't know
<Gman> though if i could, i'd probably only say that 'all software at sun will eventually be open sourced'
<Gman> which is basically what jonathan has said previously
<whiprush> Gman: any idea where I should look for an answer? corporate websites suck at helping me find an answer. :-/
<Gman> ombudsman@sun.com
<whiprush> Gman: sweet, thanks.
<Gman> which is basically an email for simon phipps
<Gman> our open source officer
<Gman> he's pretty responsive
<whiprush> cool.
<sivang> Gman: that's cool
<sivang> ajmitch: hrm, so that didn't work , what's next? :)
<ajmitch> sivang: can't say, since I don't know what's breaking
<sivang> ajmitch: I get an error about the abi being unmatching
<ajmitch> which driver?
<sivang> ajmitch: module abi is 0, server is 1
<sivang> ajmitch: ati
<ajmitch> updated drivers should fix that, maybe the one you use hasn't been built
* sivang attempts LP browsing with lynx
<sivang> going to check their build status
<Burgundavia> ajmitch: ajmitch: how much is tcl used in the real world? have you ever heard of openacs?
<Treenaks> Burgundavia: TCL is used a _lot_ in the real world
<Burgundavia> Treenaks: how common are open source people who know/use tcl?
<Treenaks> I have no idea
* ajmitch has barely touched tcl, only for a project at uni
<Treenaks> Burgundavia: Everyone who has touched eggdrop :P
<whiprush> tons of TCL in unis
<Burgundavia> just wondering, because my company just opensourced some stuff that runs on openacs
<sivang> ajmitch: do you know which version the driver abi was fixed in?
<Burgundavia> whiprush: is TCL something people are itching to write? or have they moved on to other languages?
<Treenaks> Burgundavia: TCL.. itching.. stop the puns
<crimsun> xserver-xorg-video-ati_6.6.1-0ubuntu1
<Treenaks> :)
<Treenaks> crimsun: ?
<crimsun> ^ sivang 
<whiprush> Burgundavia: it's like cobol and motif, it ain't ever going away. 
<sivang> crimsun: ah, so it's video now?
<sivang> crimsun: I only have driver-ati
<crimsun> sivang: right, xserver-xorg-driver* are now obsoleted
<sivang> crimsun: shouldn't that transition occure automatically through the packaging system?
<ajmitch> sivang: yes, it should
<crimsun> sivang: rodarvus is working on that (it surfaced at the dev team meeting yesterday)
<sivang> crimsun: I see, thanks. I wasn't able to attend the dev meeting :-/
<sivang> crimsun: do I need to install differently names xorg packages altogether? I mean, other then naming changes in the driver packages?
<sivang> mornign dholbach 
<ajmitch> hi dholbach 
<crimsun> sivang: probably not. Do you have 'xorg' installed?
* sivang checks
<dholbach> good morning
<dholbach> hey sivang, hey ajmitch, hey crimsun
<crimsun> hey dholbach :)
<sivang> crimsun: 7.0.22ubuntu7
<sivang> crimsun: yay, thanks, you saved me :-)
<dholbach> can anybody of the archive administrators please look what happened to jokosher? it' in "Needs Build" for three days now
<slomo> dholbach: it was build yesterday
<dholbach> it was?
<slomo> dholbach: yes
<pitti> Good morning
<slomo> dholbach: it's again on NEW for the binary
<slomo> hi pitti 
<dholbach> urg
<dholbach> thanks slomo
<dholbach> i was wondering already
<crimsun> sivang: ah, for it to transition, you need xserver-xorg-driver-all installed.
<pitti> argh, nice to wake up and be greeted with a broken GTK *grump* :)
<pitti> argh, half of my desktop's text lines keep disappearing
<dholbach> pitti: hm?
<dholbach> hey el! how are you?
<crimsun> sivang: sorry, that was poorly worded on my part. I mean that xserver-xorg-video-all (a binary from the xorg source package) Conflicts with xserver-xorg-driver-all.
<pitti> dholbach: dunno, since I booted my box some minutes ago, text from all apps just 'disappears' and reappears when I force the area to redraw itself
<slomo> pitti: a friend of mine has the same problem... we couldn't find the reason :(
<pitti> IZ GTK BUG!
<crimsun> which X driver?
<dholbach> pitti: all apps - that's not just the terminal?
* Lathiat laughs
<pitti> and this time it could even be true
<pitti> dholbach: right, all apps
<pitti> crimsun: nvidia
<sivang> crimsun: yes, however when I willfully installed -video-ati, it install video-all and removed the other one
<pitti> crimsun: it didn't change since yesterday, I believe
<slomo> pitti: does it work with nv for you?
<crimsun> pitti: so binary-only?
<pitti> slomo: will try, but nv has been broken for me since over a year
<dholbach> slomo: does he use 'nvidia' too?
<pitti> slomo: so I do not have that much choice, really
<slomo> dholbach, pitti: yes... but switching to nv didn't change anything
<dholbach> hrm
<pitti> crimsun: yep, but as I said, it's the same driver that has worked perfectly for a looong time
<crimsun> from what I understand the binary-only Nvidia driver does not work with the new xserver-xorg-core (ABI); you have to disable renderaccel
<pitti> ok, I'll try with nvidia, then we can narrow down the cause
<pitti> ah, right, we got a new X server yesterday
<dholbach> anything in .xsession-errors or in the X logs?
<dholbach> strange, I use 'nv' and it's all fine
<dholbach> on an amd64
<pitti> dholbach: logs have nothing interesting
<dholbach> pitti: want to try 'nv' and compare /etx/X11/xorg.conf with me? (as it seems to work for me)
<slomo> hm... does somebody else have the problem that almost all X applications become fairly slow over time? especially firefox when openening a page with many/large pictures
<el> hey dholbach ! fine :) we still didn't have ice cream... ;-)
<dholbach> el: and now it cooled off - strangely enough :)
<Lathiat> slomo: in dapper or edgy?
<desrt> vuntz; poke poke
<Lathiat> slomo: i find my work pc gets pretty bogged up from time to time
<ajmitch> pitti: yes, I've been seeing the same text bug
<Lathiat> especially with firefox
<pitti> dholbach: yep, I cannot work like this; let me restart X
<desrt> oh.  heh
<ajmitch> pitti: it makes using firefox really fun :)
<desrt> the overlap between this channel and #g-hackers is amusing
<el> dholbach, yeah, but good for sleeping
<slomo> Lathiat: edgy... and the problem is fairly new and reproducible ;)
<ajmitch> pitti: I also think it's not gtk, sorry :)
<Lathiat> slomo: ah ok
<Lathiat> slomo: probably completely unrelated then :)
<dholbach> el: absolutely :)
<pitti> ajmitch: it's not confined to ffox, it's everywhere
<ajmitch> pitti: including kde apps
<crimsun> ajmitch: have you tried adding Option "RenderAccel" "0" to the Device section?
<crimsun> ^ also pitt
<crimsun> i
<ajmitch> crimsun: no, I haven't
<ajmitch> crimsun: it doesn't show if I'm running in Xgl, either
<ajmitch> I'm too lazy to fiddle with xorg.conf at the moment
<pitti> argh, argh, I hate such days
<pitti> dholbach: "(EE) module ABI major version (0) doesn't match the server's version (1)"
<ajmitch> pitti: regretting the upgrade?
<ajmitch> pitti: nv driver?
<dholbach> pitti: did you do a complete dist-upgrade?
<pitti> crimsun: ok, what do I have to deactivate again to make it work again with nvidia?
<dholbach> pitti: (newest xserver-xorg-core and video-nv)
<pitti> yes, I have the latest -nv that is available
<pitti> but it's for the old ABI
<crimsun> pitti: you need to add Option "RenderAccel" "0" to the Device section of /etc/X11/xorg.conf, and you need to tell Xorg to ignore ABI
<slomo> pitti: video-nv or driver-nv?
<pitti> (II) Module nv: vendor="X.Org Foundation"
<pitti>         compiled for 7.0.0, module version = 1.0.1
<crimsun> pitti: -ignoreABI
<ajmitch> crimsun: strangely I haven't had to tell X to ignore ABI
<crimsun> ah
<pitti> slomo: I have -driver-nv
<slomo> pitti: you need -video-nv
<pitti> crimsun: ah, I thought something like render_accell
<slomo> pitti: the -driver* are the old ones
<pitti> shouldn't that be upgraded automatically?
<pitti> slomo: thank you
<slomo> pitti: just install xserver-xorg-video-all and -input-all :)
<pitti> yep, doing that ATM
<pitti> crimsun: many thanks
<crimsun> np
<pitti> dholbach: ok, nv does not seem to have this problem; XV is broken with it as usual, but a least I can work now :) thanks
<dholbach> XV?
<crimsun> Xvideo extension
<sivang> pitti: I was also surprised it wasn;t upgraded automatically ;)
<pitti> dholbach: watching videos is impossible with the nv driver, at least for me
<ogra> dholbach, 
<pitti> dholbach: as soon as I scale them to more than 1.5x, I get comb artifacts and heavy distortions
<ogra>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND            
<ogra>  5836 ogra      17   0 1107m 743m 5216 D  5.6 84.2  18:58.94 evolution
<ogra> i have 1G in this laptop !
<pitti> ogra: lucky you, since yesterday evo crashes right at the start
<dholbach> pitti: in gstreamer-properties, i use X11/XShm/Xv - if that helps
<pitti> ogra: I added an echo to my .bashrc to replace my todo list :/
<ajmitch> ogra: ah, that's why I use mutt :)
<dholbach> ogra: what does it do atm? is it hanging?
<ogra> dholbach, it made my system 100% stuck ... 
<ogra> i had to force-shutdown to even write in xchat again
<sivang> pitti: switch to thunderbird :p
<ogra> btw, it would be clever if --force-shutdown wouldnt need $DISPLAY to be set so you can kill from console ;)
<dholbach> ogra: i have a --force-shutdown button on the panel :-(
<ogra> was a bit painful ding that in X if the cursor only moves every 30sec
<ogra> *doing
<dholbach> ogra: although the evolution edgy doesn't hang as much as the dapper one used to
<ogra> it never crashed for me (yet)
<dholbach> "hang"
<pitti> sivang: what would that change? I use mutt for email and evo for calendar, todo, and contacts
<ogra> and this was the first hang...
<dholbach> ogra: remember anything you did before it started freaking out?
<ogra> i answered a mail from mdz
<ogra> ARGH
<ogra> bug buddy !
<sivang> pitti: ah, I see , then nothing.
<ogra> pitti, damned ... im in the same boat now ... evo dies on the start ... 
<pitti> ogra: *hug*
<dholbach> try  evolution -c calendar   and then switch to mail
<ogra> and i have still 75 unread mails :(
<pitti> ogra: if the clock applet's evo integration were less crappy, it would at least help to get my TODO list...
<ogra> dholbach, nope ... bug buddy
<dholbach> ogra: you're uptodate?
<ogra> dholbach, the mail to mdz was unsent ... i guess it has to do something with the recovery dialog that asks you abut open mails ...
* ogra apt-get upgrades to see if there is something ...
<pitti> dholbach: I'm not uptodate, apt-get dist-upgrade wants to remove gnome-applets and gnome-panel
<pitti> but it would install new evolution libraries
<pitti> hey seb128 
<seb128> hey pitti
<seb128> pitti: what about evolution?
<pitti> edgy sucks today
<pitti> seb128: it crashes on startup since yesterday
<ogra> seb128, its broken
<seb128> not it's not
<pitti> and dist-upgrade would remove gnome-{panel,applets}
<seb128> pitti: why?
<ogra> seb128, 
<ogra> <ogra>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND            
<ogra> <ogra>  5836 ogra      17   0 1107m 743m 5216 D  5.6 84.2  18:58.94 evolution
<ogra> <ogra> i have 1G in this laptop !
<ogra> tell me again thats not broken :P
<seb128> ogra: it's broken for you != it's broken
<seb128> ogra: it's not broken
<ogra> and for pitti :)
<seb128> ogra: it's not broken
<seb128> ogra: it's not broken
<seb128> I can say it again if you want :p
<seb128> powerpc?
<dholbach> ogra: which evolution and evolution-data-server version do you have?
<ogra> seb128, could you write it in capitals ? :P 
<ogra> seb128, no amd64 with i386 install :)
<seb128> ogra: you know, that's not the way to act if you want to get something fixed
<ogra> yes, sorry
<seb128> ogra: I'm near to /ignore you
<seb128> I'm fine with debugging, but free rant against me is not useful
<pitti> ok, I manually installed all the evo-related upgrades now
<seb128> pitti: 5 libs changed soname on that update
<dholbach> good morning dear seb128, did you sleep well? :-)
<seb128> pitti: if you could provide some details on upgrade issue
<pitti> yep, that seemed to have helped
<seb128> dholbach: hi dholbach :)
<pitti> seb128: yay, evo works again with the manual upgrades
<seb128> dholbach: not really, too short, 2:30am to 8am
<dholbach> seb128: you uploaded stuff at 8:30? what happened?
<pitti> seb128: shall we look into the broken upgrade of panel and applets?
<seb128> dholbach: there was ready yesterday but I didn't want to upload before going to bed, so I uploaded before going to the supermarket this morning
<seb128> pitti: sure
<dholbach> ahhh ok
<dholbach> seb128: you should sleep more :)
<seb128> pitti: 
<seb128> <seb128> pitti: 5 libs changed soname on that update
<seb128> <seb128> pitti: if you could provide some details on upgrade issue
<seb128> pitti: is that on i386?
<pitti> seb128: amd64
* seb128 looks if panel rebuilt on amd64
<seb128> dholbach: that's planned for saturday and sunday :)
<pitti> gnome-applets-data | 2.15.1.1-0ubuntu4 | http://archive.ubuntu.com edgy/main Packages
<pitti> gnome-applets | 2.15.1.1-0ubuntu3 | http://archive.ubuntu.com edgy/main Packages
<pitti> seb128: ^ I think that's it
<pitti> probably an FTBFS or stalled buildd
<pitti> same for panel
<ogra> seb128, manual upgrade of the evo bits fixed it here as well ...
<seb128> https://launchpad.net/distros/ubuntu/+source/gnome-panel/2.15.90-0ubuntu2
<seb128> failed to build everywhere but on i386
<seb128> pitti, ogra: what did you upgrade to fix it?
<ogra> seb128,  sudo apt-get install evolution evolution-data-server evolution-data-server-common
<pitti> seb128: libebook1.2-9 libedata-cal1.2-5 libegroupwise1.2-12 evolution-data-server evolution-data-server-common libedata-book1.2-2
<seb128> for libs which broke the ABI the soname changed, so there should be no issue
<seb128> ah
<ogra> that pulled in the rest
<seb128> you got evolution updated without evolution-data-server?
<pitti> I don't know, I usually do not pay attention
<seb128> do you have a bt of the crash before updating?
<pitti> unfortunately not :(
<ogra> nope :/
<pitti> bug-buddy intercepted the crash before apport
<ogra> same here 
<pitti> seb128: ok, the ftbfs looks like a give-back issue
<ogra> but i didnt save the bug buddy output with i usually do at least ...
<seb128> pitti: bug-buddy gives bt too
<dholbach> hey mvo
<pitti> hey mvo
<seb128> hey mvo
<dholbach> mvo: ALTER! :)
* mvo hugs dholbach pitti
<seb128> mvo: ALTER! :)
<dholbach> :-)))))))
<ogra> heh
<seb128> mvo: and me?!
* mvo hugs seb128
<mvo> ALTER!
* seb128 hugs mvo
<pitti> seb128: ALTER *hug*
<dholbach> hahahaha :)
<seb128> hehe
<seb128> pitti: speaking about bug-buddy and automatic debug, I wanted to have a discussion with you of what to do, especially if they conflict 
<pitti> seb128: you mean 'conflict' in the sense of which one we want by default?
<seb128> pitti: in sense "should be drop the libgnomeui crash handler so bug-buddy never opens when something crash"
<pitti> if an app intercepts crashes on its own (like gnome and OO.o), apport will not get active
<pitti> seb128: I'm not entirely sure TBH; right now, b-buddy sends to upstream, right?
<seb128> pitti: will apport automatically get a debug bt?
<pitti> so if we switch, we would get more bugs and upstream would get less
<seb128> pitti: right, but we usually encourage people to file bugs on launchpad not upstream
<pitti> seb128: yes, that's one of the biggest reason why we have it in the first place
<seb128> pitti: and to be honest, non-debug bt are mostly noise upstream
<pitti> seb128: and it also collects information about dependency packages and their versions and such
<pitti> seb128: right, and in the future we will be able to generate good backtraces on LP with our ddebs
<pitti> seb128: so, as long as we can handle the additional bug load, it would make sense
<seb128> pitti: rock ... is there anywhere I can play with apport atm? fo you have some bzr for it?
<pitti> seb128: however, the current apport package in edgy doesn't generate backtraces due to a design problem in the kernel crashdump helper; I'll sort that out with Ben next week
<seb128> pitti: do you think we will get automatic debug-bt this cycle?
<pitti> seb128: the source is in edgy (binaries in NEW)
<seb128> ok, cool, I'll play with that later
<pitti> seb128: and there is a bzr branch, see BzrMaintainedPakcages
<pitti> seb128: ddeb generation is now blocked on soyuz, I completed my part; it might not make edgy
<pitti> seb128: however, I want to talk to infinity about installing it on the buildds to sort out the remaining FTBFSes it causes
<seb128> pitti: how will be made the debug bt?
<pitti> seb128: maybe we can cowboy the ddebs from the buildds to people.u.c. or so :)
<seb128> from what I understood at the bof it's possible to create a debug bt from the non-debug one with informations on the source and the binary used, right? 
<seb128> is that going to be made server side?
<pitti> seb128: we take the numeric bt from the user report, then use gdb on the LP server to combine the core dump and the debug symbols to produce a rich bt
<pitti> seb128: yep, I hope we can get this working in the DC
<pitti> seb128: if not, there's still the possibility of generating it on our home computers
<seb128> do you have some notes or code on that?
<seb128> I'm just curious about it
<pitti> as long as the user sends us the core file, we won
<seb128> I used to think you need a coredump or debug symbols on the client to get a debug byt
<seb128> bt
<pitti> seb128: I can show you the process, it's fairly easy
<pitti> seb128: yep, we need the core
<seb128> hum
<pitti> seb128: and apport adds it to the report as long as it's not too big
<seb128> but isn't the coredump something big to send?
<pitti> seb128: (1) I bzip2 it, which helps *a lot* (ratios of 1:100 sometimes)
<pitti> seb128: (2) I'm working on ways to make it significantly smaller
<seb128> pitti: yeah, I'm interested to know about it, but not hurry, when you will not be over-busy is fine :)
<pitti> seb128: in one case I was able to shrink it from 1.5 MB to 40 kB without significant loss for our purposes
<pitti> but I didn't find a general way of doing this so far
<seb128> cool
<pitti> but that's future work
<seb128> but didn't sfllaw and lifeless said at the bof it was possible to get a debug bt without sending a core if you have the non-debug one and enough informations on the binary and the sources for that binary?
<pitti> seb128: in fact we could deal with just saving the stack frame (the top 256 kB are almost always enough), but then we lose the ability of using gdb to do the grunt work for us
<pitti> seb128: yes, that's what I mean with above
<seb128> hum, k
<pitti> seb128: theoretically, the non-debug bt or the stack frame have all information we need
<pitti> seb128: the problem is just that it takes some fiddling to pry out a debug stack trace out of it, and there is no tool ATM which does that
<seb128> as far as we get a debug bt and users don't have to send several MB every time they get a crash, that's fine
<pitti> seb128: my current plan is to just send compressed cores up to a size limit and let the user decide about whether he wants to send it
<pitti> seb128: then I can optimize for size later
<seb128> looks fine to me
* seb128 hugs pitti :)
<pitti> seb128: but that would at least mean that we have a working process RSN
<seb128> right
<pitti> seb128: in fact, after yesterday's work rave, the GUI and the backend now work pretty well
<pitti> with update-notifier integration and all that
<seb128> we "just" need the server part now then? :)
<pitti> seb128: yep, for convenience
<pitti> seb128: however, we can always do the process manually on ronne or our home computers or so
<seb128> right
<pitti> seb128: so, ping me when you want me to show the stuff to you
<seb128> pitti: ping :)
<seb128> as said no hurry, whenever suits you the best
<pitti> seb128: ok, in 20 minutes?
<seb128> works for me!
<seb128> thank you :)
<pitti> seb128: please apt-get source apport in the meantime and build/install the debs
<seb128> yeah, I was going to do that :)
<pitti> seb128: when Keybuk turns up today, I'll ask him to NEW the package
<seb128> k
<seb128> weird
<seb128> I got an "reboot required" icon with "crash detected" tooltip
<pitti> seb128: yes, the icon is not quite the final one :)
<seb128> and clicking on it open the "restart required" dialog
<Treenaks> pitti: make it a bomb ;)
<pitti> it's the reboot icon with some black shading
<pitti> seb128: hm, when I hover on it, I get "Crashreport detected"
<seb128> yep
<seb128> and when I left click I get the restart dialog
<pitti> seb128: you won't get the icon if you do not have reports in /var/crash, of course
<pitti> seb128: hm, funny bug
<seb128> $ ls /var/crash
<seb128> _usr_bin_xprop.1000.crash
<seb128> _usr_lib_notification-daemon_notification-daemon.1000.crash
<pitti> ah, cool
<pitti> seb128: do you have the lastest version of u-n installed? mvo fixed it yesterday
<seb128> no
<mvo> seb128: do it then!
<mvo> :P
<seb128> dholbach told me xorg was b0rked
<seb128> so I didn't upgrade yet
<mvo> just install the new update-notifier
<seb128> I'll install u-n
<pitti> seb128: xorg + nvidia driver = b0rk
<seb128> mvo: yeah, was going to do that :)
<seb128> pitti: I'm using ati
<mvo> dholbach: btw, gnome-control-center is still uninstallable for me on amd64 
<seb128> mvo: what is the issue?
<pitti> seb128: oh, if I'm showing you the debug stuff, maybe I can ask a little favor in return: please complain about all HIG violations in apport-gtk :)
<pitti> moin rodarvus 
<dholbach> mvo: hm
<seb128> pitti: yeah, sure, I might send patch for it :)
<mvo> seb128: it complains that it can't install the correct version of capplets-data
<seb128> mvo: arch any,all diff
<seb128> https://launchpad.net/distros/ubuntu/+source/control-center/1:2.15.90-0ubuntu1
<pitti> seb128: btw, I had much fun with glade and pygtk yesterday; that stuff really rocks :)
<seb128> mvo: needs a retry on !i386
<seb128> mvo: same for gnome-applets too
<pitti> seb128: I just lack UI design experience, but I'll ask mpt, too
<mvo> seb128: well, we have it since yesterday morning - I will ask infinity
<seb128> mvo: have what?
<seb128> mvo: http://librarian.launchpad.net/3561491/buildlog_ubuntu-edgy-amd64.control-center_1%3A2.15.90-0ubuntu1_FAILEDTOBUILD.txt.gz
<mvo> seb128: the uninstallable capplets-data
<seb128> mvo: did you read what I wrote?
<seb128> mvo: it didn't build on !i386
<mvo> seb128: yes, I have read it
<seb128> mvo: needs a retry ... nothing that dholbach or I can fix
<seb128> out of doing a fake upload to trigger a rebuild
<dholbach> seb128: mvo always tends to blame me
<seb128> which should not be required :)
<seb128> dholbach: he's right, usually when things are broken that's due to you :p
* seb128 runs
* dholbach strangles seb128
<infinity> seb128: Retrying.
<mvo> I was not blaming anyone, I just want my gnome back :)
<seb128> infinity: thank you
* mvo hugs infinity
<seb128> mvo: how did he go away? :p
<seb128> mvo: don't say Yes to dist-upgrade before reading what he wants to remove :p
<infinity> mvo: Has anyone whined to you yet about gksu suddenly offering to save passwords?
<mvo> seb128: no, I did some cleanup on my system and it ... went away
<mvo> seb128: and you don't want me to switch to kde, do you?
<seb128> mvo: I see :)
<infinity> mvo: This seems completely counter to the argument that "sudo is there as a warning that you're doing stuff as root", since by default, it offers to save your password for the whole session now...
<mvo> infinity: no, you haven't. I noticed that too, the dialog looks a bit ...
<seb128> mvo: really not, thanks to infinity your GNOME is going to be fixed rsn :)
<infinity> mvo: And worse, it allows you to save your password in the gnome-keyring, so you ever ever get a root prompt again.
<infinity> s/ever ever/never ever/
<seb128> infinity: that's handy :)
<infinity> mvo: I'm pretty sure that's an upstream change we want to revert or patch out.
* mvo thinks we should drop root complettely. uid=0 for everybody!
<ogra> heh
<infinity> seb128: *smack*
<ogra> mvo, and call ourselves linspire ?
<mvo> infinity: it seems to be a new gksu2 feature
<mvo> lubuntu !
<ogra> heh
<mvo> the luser ubuntu :P
<dholbach> dubuntu.com :)
<infinity> mvo: libgsku, even, I think.  But yeah, it's just plain wrong, IMO.
<mvo> dholbach: HAHA
<imbrandon> winbuntu ?
<simira> :)
<mvo> infinity: I take a look
<infinity> mvo: My other bitch (and no, I haven't filed a bug, I'm a bad man) is that apt-listchanges has completely stopped doing anything useful for me in edgy.
<infinity> mvo: It seems to parse the changelogs, then just plow straight on without displaying them.
<mvo> infinity: *hrm* thanks, let me see if I can reproduce it (I'm sure I can :)
<pitti> mvo: maybe /usr/share/icons/gnome/16x16/stock/generic/stock_test-mode.png isn't too bad as an initial icon for a crash report; it looks a bit like the crash test dummy markers :)
<infinity> mvo: Broken in both X (update-notified) and CLI (apt-get).  Has been for weeks, I've just been too lazy to complain.
<infinity> s/notified/notifier/
<hungerW> infinity: Works for me(TM)
<ogra> pitti, thats a cool one, take that ! :)
<hungerW> infinity: It was broken for a couple of days here, too, but it works again for a while now.
<mvo> pitti: yeah!
* ogra lols about bug 54329
<Ubugtu> Malone bug 54329 in Ubuntu "Error when Applications menu item isn't found is highly offensive" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/54329
<pitti> why, does it say 'you suck, you L0SER!!!11!!one!' ??
<ogra> no it says it cant "execute the child"
<pitti> oops :)
<ogra> ..."What you should see: Something that doesn't mention killing children."...
<imbrandon> lol
<simira> I really agree
<pitti> that reminds me of some kernel (?) message I saw a while ago about not being able to rape a child
<ogra> heh
* mvo is shocked
<ogra> luckily normal users seldom see kernel messages
<seb128> bah, users, sometime...
<ogra> seb128, why do you look at me if you say that ? :)
<seb128> ogra: I don't :p
<ogra> :)
<ogra> sorry for earlier, really ...
<seb128> dholbach: better you close that one, I didn't get enough sleep to reply to it correctly ;)
<dholbach> seb128: which one?
<infinity> seb128: You lose.  gnome-applets is still FTBFS.
<dholbach> seb128: ah mpt's bug
<infinity> seb128: Same for control-center, it looks like.
<seb128> dholbach: ah, it's from mpt, why am I surprised
<imbrandon> yea control-senter is ftbs too
<seb128> infinity: still libgnomeui-dev not installable?
<seb128> imbrandon: how do you know?
<infinity> seb128: No, dies in the compile.  Broken headers or some such.  Didn't look that hard.
<infinity> http://librarian.launchpad.net/3601225/buildlog_ubuntu-edgy-powerpc.control-center_1%3A2.15.90-0ubuntu1_FAILEDTOBUILD.txt.gz
<imbrandon> seb128: its uninstallable here () ppc ) so i tried to build it
<seb128> infinity: ok, that's e-d-s API change, I'll fix it ... :)
<infinity> seb128: gnome-applets dies due to python-gnome2-desktop-dev being uninstallable.  That's likely easier to fix.
<seb128> infinity: control-center is easy to fix, that's a few lines patch, going to do that in a min
<imbrandon> yay
<infinity> seb128: Okay, I'm tracking the other thing.
<seb128> infinity: thank you
<infinity> seb128: Okay, the gnome-applets thing seems to be due to gnome-python-desktop having not been built on amd64/powerpc, due to other issues.  It's building now.  Should all sort out in a couple of publisher runs.
<seb128> infinity: cool, thank you
<doko> infinity, Kamion: https://launchpad.net/distros/ubuntu/dapper/+queue doesn't show the OOo uploads, but https://launchpad.net/distros/ubuntu/dapper-proposed/+queue doesn't exist.
<pitti> seb128: ah, ctrl+shift+numbers to enter unicode has been replaced by ctrl+shift+u and then the numbers without modifier keys
<seb128> pitti: ah, good to know. How did you figure?
* pitti  libpils0 and libpils-dev :)
<dholbach> hahaha
<infinity> doko: That's cause that page doesn't show unapproved, I suppose.
<pitti> seb128: I had a faint memory about reading about this in some changelog on edgy-changes
<infinity> doko: Let me poke at it.
<seb128> "
<seb128> * gtk/gtkimcontextsimple.c: Rework the Unicode hex input
<seb128>         code. Now we only steal a single key combination, Ctrl-Shift-U,
<seb128>         instead of sixteen. 
<seb128>         A hex Unicode sequence must be started with Ctrl-Shift-U, followed
<seb128>         by a sequence of hex digits entered with Ctrl-Shift still held.
<seb128>         Releasing one of the modifiers or pressing space while the modifiers
<pitti> seb128: I still knew 'ctrl+shift+numbers blabla replaced with single combination blabla'
<seb128>         are still held commits the character. It is possible to erase
<seb128>         digits using backspace.
<seb128> "
<seb128> right
<pitti> dholbach: I want a libweissbier1, too!
<seb128> "As an extension to the above, we also allow to start the sequence
<seb128>         with Ctrl-Shift-U, then release the modifiers before typing any
<seb128>         digits, and enter the digits without modifier"
<thom> aaargh. g-p-m seems to have decided to notify me that my batter is charged every 30 seconds or so
<dholbach> pitti, seb128: nice :)
<infinity> doko: Err, wait.  What are you looking for, exactly?
<infinity> doko: I see no new OOo for dapper anywhere.
<doko> infinity: dapper-proposed
<infinity> doko: Version?
<infinity> doko: I see nothing newer than openoffice.org_2.0.3-3dapper3_source.changes
<doko> oops, updated the wrong chroot ... and then tried to install in another one
<ogra> seb128, i just upgraded my whole system, now the panel logout button stopped working ...
<thom> ogra! this could get /really/ annoying, fast. bug 40040 is back in edgy for me
<Ubugtu> Malone bug 40040 in gnome-power "Power manager Applet show 100% charged each some secs." [Unknown,Fix released]  http://launchpad.net/bugs/40040
<ogra> thom, i'll look how that was fixed last time
<thom> ogra: last time was an upstream patch
<thom> i wonder if the rewrite of halmonitor mentioned in the changelog has lost the fix
<thom> (no familiarity with the code)
<ogra> the core code was rewritten completely in the last update before the gnome API/ABI freeze ...
<ogra> so its likely that this one was lost upstream (as many other functionallity :/)
<thom> oh lovely
<ogra> yep
<thom> oh well. if i had any clue how to reopen that bug for edgy i would, but i'll leave it for yiu
<ogra> i'll ask upstream ...
<ogra> seb128, did evo change the font for html mails or something ? html looks very blurry with the recent one 
<seb128> ogra: weird for the panel logout, we sometime have bugs about such issue but that's not easy to debug
<seb128> ogra: I had some font issues with it but restarting evo made the trick for me
<ogra> the menu item doesnt react either
<ogra> hmm, actually *no* menu item at all 
<ogra> neither any of my launchers work ...
<seb128> ogra: restart the panel? :)
<ogra> oh
<ogra> a killall doesnt respawn it
* ogra logs out and in again ...
<ogra> seb128, a new login solved it
<seb128> ok
<seb128> it usually does :)
<ogra> infinity, looks like l-r-m could need a rebuild against the new xorg for fglrx ...
<Seveas> dos fglrx support xorg 7.1?
<Seveas> does*
<ogra> no idea
<ogra> al least the current binary doesnt :)
<infinity> Rebuilding won't fix that.
<ogra> ok
<infinity> I'll look at it on the weekend though, I suspect.
<ogra> one has hopes, you know :)
<pitti> doko: what are we supposed to do if our SoC student is MIA and AWOL?
<pitti> doko: report that to google immediately, or just fail him in the final report?
<doko> pitti: but he was reacting for the midterm survey?
<pitti> mvo: ^ (G0SUB didn't do *anything* visible in the last weeks, didn't commit anything to bzr, and doesn't mail)
<pitti> doko: yes, he was; since then he didn't do anything any more
<pitti> doko: at that time he had some trouble with the Indian monsoon, but we agreed to pass mid-term since he promised to catch up and had some uncommitted work
<pitti> but I'm losing my patience now
<ajmitch> reminds me that I should push today's stuff to launchpad..
<doko> pitti: I'll email him
<pitti> doko: 'him' being G0SUB or the Google contact?
<doko> pitti: GOSUB first
<pitti> doko: ok, can't hurt to ping him again (I did two days ago)
<pitti> ogra_: pessulus> is debian bug 377822 solved for us?
<Ubugtu> Debian bug 377822 in pessulus "Subject: Uninstallable due to python transition" [Serious,Open]  http://bugs.debian.org/377822
<rodarvus> good morning
* pitti waves to rodarvus 
<rodarvus> hi pitti!
<rodarvus> pitti, earlier today it was not me :)
<rodarvus> just my dsl resetting :/
<ogra_> pitti, afaik yes
<ajmitch> morning rodarvus 
<pitti> rodarvus: ah, it was the dreaded rodarvusbot, wasn't it? :)
<rodarvus> hi ajmitch!
<ogra_> pitti, erm ... we already ship 2.15.90-0ubuntu1
<rodarvus> pitti, yeah, a python bot configured to 'pass' all input hooks :P
<zul> morning rodarvus 
<ogra_> pitti, and 0.9.1 was shipped in dapper, so it doesnt affect us at all :)
<pitti> ogra_: good
<rodarvus> hey zul :)
<hungerW> Hmmm... strigi looks really nice.
<slomo_> ogra_: any news on the gnome menu bug? the one which makes the menu pop up and close forever
<ogra_> nope
<ogra_> seb128 is aware of it ... but thats all 
<slomo_> is there a bugreport for this somewhere?
<ajmitch> probably one & several duplicates
<ogra_> you can produce a BT with:
<ogra_> gnome-session-remove gnome-panel
<ogra_> GNOME_PANEL_DEBUG=1 BONOBO_ACTIVATION_DEBUG_OUTPUT=1 gnome-panel
<ogra_> but that gets very huge
<ogra_> MENU_VERBOSE=1 might help as well
<ajmitch> slomo_: bug 52405
<Ubugtu> Malone bug 52405 in gnome-panel "gnome-panel eats 50% cpu for half an hour and flickers" [Untriaged,Confirmed]  http://launchpad.net/bugs/52405
<slomo_> ajmitch: thanks :)
<ajmitch> only 6 duplicates, I'm surprised :)
<ogra_> and its even the return of an older dapper or breezy bug
<ogra_> i remember we had probs before with that broken symlink
<sladen> ajmitch: sounds familar, I did some tracing of that for upstream
<slomo_> ogra: there's a fix for it in the bugreport
<slomo_> ogra: removing /etc/xdg/menus/debian-menu.menu
<slomo_> well... workaround :)
<ajmitch> slomo_: which is fine, but I don't have that symlink :)
<ajmitch> ah no, I actually do
<ajmitch> was just looking in the wrong dir
<slomo_> so where does this come from? i don't have that file ;)
<ogra> xdg
<sladen> ajmitch: http://bugzilla.gnome.org/show_bug.cgi?id=323064 , https://launchpad.net/distros/ubuntu/+source/gamin/+bug/5176 , http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=338438
<Ubugtu> Gnome bug 323064 in general "the panel applications menu is displayed empty with gamin 0.1.7/inotify" [Normal,Unconfirmed]  
<slomo_> ogra: i mean... which package put it there ;)
<pitti> ogra: hm, pessulus reminds me of a similar application we once had (if I would only remember its name)
<ogra> menu-xdg
<pitti> ogra: the thing that used xnest and displayed a desktop which you could reconfigure
<ajmitch> sabayon
<pitti> right, thanks ajmitch 
<ogra> pitti, sabayon :) thats next on the list for MIR ;)
* ajmitch was looking at that package  a couple of days ago for some reason
<pitti> ogra: hm? it's in main for ages
<ogra> we want both in edubuntu
<ogra> oh, ok
<ajmitch> I'm sure there was something I had to do to it..
<pitti> ogra: we do need both?
<ogra> they do different things
<ogra> i need pessulus for student-control-panel ...
<pitti> oh, I see
<ajmitch> ah, dholbach updated it
<ogra> as add on
<ogra> pitti, https://wiki.ubuntu.com/StudentControlPanelCompletion see "lockdown n the fly"
<ajmitch> ogra: all this config is just local gconf, right?
<ogra> ajmitch, yep
<ajmitch> maybe something for edgy+1 is gconf using ldap backend :)
<ajmitch> especially for the fat client spec
<ogra> sounds intresting :)
<ajmitch> there used to be a backend, not sure if its been actively developed 
<ogra> we'll revisit the fat client spec next conf anyway
<ajmitch> yep
<ajmitch> was just a thought, been spending too much time around ldap lately :)
<pitti> Riddell: knet> yet another KDE dial application?
<Riddell> pitti: for DSL users
<ogra> one app for every modem brand :)
<pitti> oh, kppp doesn't supprort dsl? I see
<pitti> ogra: pessulus approved
<pitti> Riddell: knet approved
<ogra> thanks mr. "fastest security fixer in the world" :)
<pitti> :)
<Riddell> pitti: thanks
<pitti> Riddell: jasper has been in main for ages
<pitti> Riddell: but it's the same version in hoary as in edgy, thus it seems kind of unmaintained?
<ajmitch> ogra: ah, ldap backend is only partial
* pitti kicks the wiki to go faster
<freeflying> can knot1 be installed on amd64 turion 64x2 notbook?  I've failed to install it using today's install cd
<pitti> slomo_: can you please use the standard template for gsf-sharp and do some more QA research?
<ogra> freeflying, 
<ogra> ogra@edubuntu:~$ cat /proc/cpuinfo |grep "model name"
<ogra> model name      : AMD Turion(tm) 64 Mobile Technology ML-30
<ogra> i have to use nolapc as bootoption though
<ogra> *nolapic
<freeflying> ogra: I used too, also with pnpbios=off
* ajmitch spots libnss-ldap on the queue
<ajmitch> only 5 RC bugs for the version in debian that I wanted to upgrade to
<slomo_> pitti: i can use the template, sure... the current one is only a copy of another MIR with changed text...  but for QA, there's only a SVN and nothing else but everybody uses it for beagle *shrug*
<gnomefreak> was the vesa driver build yet?
<slomo_> pitti: and a debian ITP exists ;)
<pitti> slomo_: ok, well, as long as you verified that it is free of showstopper bugs in Debian and upstream, that's fine
<pitti> slomo_: just a reminder for later to use the current template, it is much better
<ajmitch> slomo_: you haven't got that into debian? :)
<pitti> slomo_: did you get your @debian account yet?
<slomo_> ajmitch: beowulf filed an ITP 12 days ago... and i don't really care about beagle etc so i don't want to maintain it in debian ;)
<slomo_> pitti: not yet... should take ~100 days ;)
<ajmitch> slomo_: fair enough
<rodarvus> 100 days?
<pitti> slomo_: hm, took ~ 30 for me...
<ajmitch> rodarvus: depends on the amount of the bribe
<rodarvus> yeah, but 100 days seems like a lot of slack on my humble opinion :)
<pitti> ajmitch: yeah, the 200 beer boxes and free entry to massage salons for a year hurt my purse a lot :-P
<ajmitch> siretart is also waiting, I think
<slomo_> yes, siretart was already approved by the FD... i'm still waiting for that
<pitti> Riddell: pcsc-lite sounds scary :/
<pitti> Riddell: hm, gnupg2 does not depend on any openct or pcsc-lite library...
<pitti> Riddell: pcsc-lite MIR: "* No binaries running as root or suid/sgid." -> AHEM
<Mithrandir> oh, pcsc-lite going to main?  Nice.
<pitti> Mithrandir: I didn't approve it
<pitti> Mithrandir: if you want to be the maintainer, I'm fine with that, of course :)
<slomo_> pitti: so you're fine with gsf-sharp? (regarding showstopper bugs... i never heard of someone having a bug at all with gsf-sharp ;) )
<pitti> slomo_: ok, I'll review it based on the current report
<Mithrandir> pitti: preferably not; I'm just using it to sign my uploads.
<pitti> slomo_: I take your word that it's sane :)
<Mithrandir> pitti: (that is, I don't want to be the maintainer)
<siretart> ajmitch: I'm currently waiting for DAM, but there are quite some ppl before me in the DAM queue
<_d4vid> hi all
<_d4vid> need help with i810 drivers
<_d4vid> i cant start opengl games.. 
<ogra> _d4vid, see topic
<ogra> please ask in #ubuntu
<_d4vid> :(
<_d4vid> ok
<_d4vid> thnx
<jono> hey all
<jjesse> hello jono
<jono> hey jjesse :)
<Gman> hey paul's minion
<jono> Gman, heh, less of that thanks :P
<Seveas> hi jonokosher ;)
<jono> heya Seveas :P
<bddebian> Hello
<doko> pitti: please join #debian-toolchain on a regular basis (more ssp fallout)
* HiddenWolf hands pitti a helmet
<pitti> doko: #debian-toolchain is empty on both freenode and OFTC ??
<rodarvus> pitti, #ubuntu-toolchain
<doko> pitti, sorry ubuntu-toolchain :-/
<cprov> infinity: ping
<rodarvus> infinity, ping
<infinity> cprov: It's midnight, but pong anyway.
<bddebian> midnight?  Hell, that's early :)
<cprov> infinity: it'll be quick, what's new in lp-buildd_32 ?
<infinity> cprov: No idea, best to ask me when I can actually check...
<infinity> cprov: Or, read the debian changelog...
<cprov> infinity: okay ... point me to the source ;)
<infinity> cprov: I'm pretty sure my branch on chinstrap (though way out of sync with yours by now) is still current comapred to what's running on the buildds, but I should probably double-check that at another time.
<madduck> anyone know where Keybuk is?
<infinity> cprov: But the changelog is here: http://cerberus.0c3.net/~adconrad/foo.txt
<cprov> infinity: fine
<infinity> cprov: But yeah, bug me at a slightly better time, and I'll make sure I have something nicely merged for you to bring back into HEAD.
<mdz> madduck: he's in the UK
<madduck> mdz: just haven't seen him in a while. mdz, could you msg me his mobile number, please?
<mdz> madduck: I don't generally give out that sort of information without permission
<madduck> mh.\
<rodarvus> infinity, we have some (actually, a lot) of new packages on X.Org, for Edgy - I'd like to add them to ubuntu-x-swat on LaunchPad
<mdz> madduck: are you using a dvorak layout now?
<cprov> infinity: okay, see you tomorrow
<madduck> mdz: no, not yet. :/
<rodarvus> infinity, may I send you an email with the list, or you prefer me to add them myself?
<madduck> i didn't round up the patience yet.
<infinity> rodarvus: Either way, doesn't matter much to me.
<rodarvus> ok, I'll send you an email later today, then (I've just checked and I don't have powers on ubuntu-x-swat to do this myself :/)
<rodarvus> infinity, ^^^
<seb128> infinity: could you give a retry to gnome-panel on !i386?
<infinity> seb128: Done.
<seb128> infinity: thank you
<bddebian> seb128: Would you prefer I not touch nautilus-open-terminal merge if I get to it?
<seb128> bddebian: what do you mean?
<bddebian> seb128: http://merges.ubuntu.com/universe-manual.html
<seb128> bddebian: I'll do it if you prefer, that's probably a quick one
<seb128> bddebian: that's probably a simple sync request
<bddebian> seb128: Most of them have just been different orig.tar.gz so I have just been fake syncing them
<bddebian> seb128: I'm happy to do it but I don't want to touch anything I shouldn't
<seb128> no reason to not touch it if you do it right :p
* bddebian feels so loved
<tritium> bddebian is loved by all
<sivang> crimsun: do you know if sounds should be not working in current edgy?
<sivang> crimsun: seems to not be working with skype
<bddebian> tritium: Heya.  Hardly
<tritium> bddebian: hello :)
<Kaleo> Hello
<bddebian> Hello Kaleo
<G0SUB> pitti: please don't lose patience. I am not MIA :)
<G0SUB> pitti: everything is going fine here. you will see the results by Monday, 00:00 UTC
<pitti> G0SUB: oh, hi
<G0SUB> pitti: hello.
<G0SUB> pitti: i apologise for being AWOL, but i asked you for a week remember? I have been working all this while. it should be done by the end of this week (i work more on weekends since I have college everyday)
<Ignite_> will there be a network install image for edgy?
<pitti> G0SUB: hm, I might have mixed it up with this week's Monday
<G0SUB> pitti: probably you did :) I am sorry in any case.
* G0SUB gets back to work
<pygi> G0SUB, while on that point...the UI? :)
<gnomefreak> was the vesa drivers released yet?
<bddebian> Kamion: around?
<bddebian> Heya LaserJock
<bddebian> So how would I merge a debian version for an Ubuntu native package? (I.E. no orig.tar.gz in Ubuntu)?
<LaserJock> bddebian: yucky. is the Debian version native?
<LaserJock> bddebian: hi, btw
<bddebian> LaserJock: No
<LaserJock> bddebian: what package is this?
<bddebian> nautilus-open-terminal
<LaserJock> ah
<LaserJock> bddebian: isn't that even a wrong versioning for a native package in Ubuntu?
<bddebian> LaserJock: I think so but I'm not questioning seb128 ;-P
<LaserJock> bddebian: seb128 uploaded it?
<bddebian> yes
<LaserJock> hmm, well I think I would see if we could sync from Debian, but that's just my opinion
<bddebian> That's what I'm looking at but I assume the upload may fail
<LaserJock> ah, hmm
<LaserJock> I guess you could talk to seb128 about it then
<bddebian> But maybe it won't because there is no orig.tar.gz?
<Zdra> is it planned to switch to dbus 0.70 anytime soon ?
<infinity> bddebian: Untar the Debian orig and the Ubuntu native tar.gz, diff -urN, make sure that we've not patched anything outside of debian/* (if we have, create patches), then merge with the Debian version and upload non-native (ie: with the Debian orig)
<infinity> bddebian: Switching from native to non-native is perfectly legal, and the right thing to do in this case (it should be done anyway, even if we weren't merging)
<bddebian> infinity: OK, thanks
<infinity> bddebian: If you're pretty sure we don't actually want to merge (ie: our packaging or changes are irrelevant), just request a sync, as usual.  It'll work fine.
<bddebian> infinity: Ah, cool
<pitti> infinity: any chance you could free apport from the NEW queue?
* infinity looks.
<slomo_> Zdra: i don't think it is planned to switch to dbus 0.91/dbus-glib 0.71 for edgy... it would cause too much breakage at this point.
<infinity> pitti: main or universe?
<infinity> pitti: Ahh, source is in universe, looks like, so that's where I'll toss the binaries.
<bddebian> Ack, our tar.gz has a debian dir
<infinity> bddebian: Of course it does, it's debian-native.
<pitti> infinity: that's fine for now, we can promote it later
<bddebian> Oh, yeah, duh
<pitti> infinity: thank you!
<Zdra> slomo_: ok, I asked that because I got a dbus crash in a app I'm coding and upstream think it got fixed in 0.70
<bddebian> Seems to be the only diff
<slomo_> Zdra: problem is that the dbus-glib 0.70 has many large, incompatible changes from what i know. what exactly is the crash you get?
<Zdra> slomo_: connect to the bus, disconnect and reconnect again cause dbus to crash
<infinity> pitti: Done.
<slomo_> Zdra: uh... could you paste a small testcase for this somewhere?
* infinity goes to bed.
<slomo_> good night, infinity :)
<bddebian> Gnight infinity, thanks again
<Zdra> slomo_: http://lists.freedesktop.org/archives/dbus/2006-July/005276.html
<slomo_> Zdra: could you please file a bug in launchpad for this and assign it to me? i'll look into it
<Zdra> slomo_: ok, but I think none applications does that, I found that bug for a little code I'm writing for myself
<slomo_> Zdra: it really surprises me that this never happened it any application ;)
<Zdra> slomo_: https://launchpad.net/distros/ubuntu/+source/dbus/+bug/54375
<Ubugtu> Malone bug 54375 in dbus "DBus crash when connecting to the bus, disconnect and reconnect again" [Untriaged,Unconfirmed]  
<slomo_> Zdra: thanks
<LaserJock> elmo, Znarl, Spads: thanks guys. Happy SysAdmin appreciation Day!
<sivang> bah, the zeroconf thread contonues to fill up -devel
<robertj_> sivang: I wish I could find the origonal email I sent that ended with "Please discuss" so I could reply back with "Please close discussion."
<sivang> robertj_: heh
<madduck> is soyuz open source?
<tseng> no.
<madduck> thx
<sivang> robertj_: should prboably a feature of mailman :)
<robertj_> sivang: my other beef is I cant figure out how to do a digest subscription & reply back to a specific message without messing up threading
<robertj_> I assume there is some mail header introduced for threading purposes
<crimsun> sivang: they should work fine; are you using the latest skype beta w/ alsa support?
<sivang> crimsun: nope
<sivang> crimsun: using and older one
<sivang> I should upgrade then
<sivang> crimsun: but also desktop sounds stopped working suddenly
<sivang> (I think after today's upgrade)
<crimsun> sivang: as in Sound Events and/or playing your own music?
<crimsun> (I don't have an Edgy GNOME desktop atm, will have to check tomorrow)
<sivang> crimsun: I can play MP3's using mplayer, but all other progs are stuck
<jono> hey
<sivang> crimsun: desktop sounds, as in notification, gaime sounds etc are not working
<crimsun> sivang: right, perhaps someone else can confirm (I don't have said configuration atm), isn't a core alsa issue.
<sivang> crimsun: kay, I'll invesitage furhter
<sivang> crimsun: I hope it''s no ESD going AWOL as i did in dapper
* jono is really hot
<LaserJock> jono: we know you are good, you don't have to tell us ;-)
<jono> LaserJock, hehe
<jono> I can see how that may have been read thr wrong way :P
<tseng> jono: imagine how hot you'd be with a beard
<tseng> (is it gone yet?)
<LaserJock> hehe
<jono> tseng, yep its gone :P
<tseng> jono: you'll be happy to know that I have been using "bocktoverfest" pretty liberally
<tseng> much to aaron's chagrin
<jono> tseng, hehe
<jono> excellent :)
<dholbach> have a nice weekend everybody!
<jono> bye dholbach 
<highvoltage> bye dholbach! you too!
<sivang> later dh	
<sivang> later dholbach 
<dholbach> if somebody wants to make jono happy, they could try to get jokosher out of binary new (or wherever it's hanging now) :)
<jono> :)
<zul> what is jokosher?
<jjesse> its a music program i think
<dholbach> http://jokosher.org
<dholbach> it ROCKS
<jono> right I am off
<jono> later all, have a nice weekend :)
<robertj> it would almost be worth switching off of digest just so I can killfile this fellow
* robertj ponders actually using his gmail account for something
<bSON> hi
<bSON> is the x.org in edgy a 7.1 build?
<crimsun> it's newer than 7.1.
<bSON> oh, ok
<Zdra> there is still packages missing as I see
<slomo_> Zdra: which ones?
<rodarvus> there are about 10 multiplatform video drivers missing
<rodarvus> and 6 sparc-only video drivers missing
<Zdra> "xorg" for example is still in version 7.0.22
<rodarvus> all of these are being uploaded today
<rodarvus> Zdra, have you seen whats inside pacakge 'xorg'? :)
<Zdra> but I guess it's a meta-packages that just need a version bump...
<rodarvus> its not a meta-package
<rodarvus> and won't be bumped
<rodarvus> (we "share" this package with debian)
<rodarvus> no reason to gratuituously bump its version.
<Zdra> if you say so...
<crimsun> rodarvus: thanks for all your work pushing 7.1+ in, btw.
<rodarvus> crimsun, my pleasure :)
<gnomefreak> rodarvus: xorg is done atm?
<rodarvus> gnomefreak, the package 'xorg' itself is done
<rodarvus> there are a few video drivers still needing updating
<rodarvus> and of course, bugfixing will come, during the next few weeks
<gnomefreak> ok cool
<^ohoel> is there a spec on proprietary graphics driver support ala novell/redhat?
<rodarvus> ^ohoel, what proprietary graphics driver support you mean?
<rodarvus> (just curious)
<^ohoel> rodarvus: they're listed as supported platforms by ati/nvidia(?), and installing+enabling the driver is a one-click operation (plus accepting the license)
<rodarvus> ^ohoel, we already have ati/nvidia binary drivers officially packaged on ubuntu.
<rodarvus> they're even installed by default, I think.
* gnomefreak prays vesa is done
<^ohoel> rodarvus: yes, it seems novell uses a repository located on ati servers for driver updates though
<rodarvus> gnomefreak, vesa is done.
<gnomefreak> ty
<^ohoel> nice, ati released xorg 7.1 drivers
<Fjodor> Sorry for asking, but is there a good reason for linux/autoconf.h to explicitly unset CONFIG_D80211 if not selected instead of not having anything about it? As it is now, and has been for a while, this prevents rt2x00 cvs drivers to build without tinkering
<crimsun> Fjodor: it's modularised in Edgy
<highvoltage> crimsun: do you think it's possible that I'm using the wrong driver? according to http://www.linux-on-laptops.com/forum/showthread.php?t=165, it should use snd-hda-intel
<Fjodor> crimsun: Not sure I understand what you mean?
<highvoltage> crimsun: oops /me > #alsa
<crimsun> Fjodor: I don't see the 'D802' string in Dapper's configs
<Fjodor> As far AFAICT, CONFIG_D80211 is selected by selecting your in-kernel rt2x00 drivers. When those are deselected, however, CONFIG_D80211 is actively unset instead of just not having a value
<Fjodor> Sorry, talking edgy kernel
<Fjodor> crimsun: ^
<crimsun> Fjodor: it'd be best to ping BenC about it in -kernel, though he's away presently
<Fjodor> crimsun: Ok. Thanks
<crimsun> Fjodor: On the other hand, does the default Edgy value (modularised) pose a problem?
<robertj> Dennis Kaarsemaker, whoever you are, you are my hero.
<crimsun> robertj: Seveas.
<slomo_> robertj: Seveas 
<robertj> ahh
<Seveas> robertj, ?
<Fjodor> crimsun: Yes, the default appears to be a specific #unset. rt2x00_compat.h includes linux/config.h, however, thus getting that specific CONFIG_ unset and failing to compile
<crimsun> Fjodor: let's migrate to -kernel
<Fjodor> crimsun: Going there
<ogra> mvo, is update-manager using gksu instead of gksudo known ?
<mvo> ogra: since ages
<mvo> ogra: use et a gconf key in gksu to always make it act like gksudo
<ogra> ah, i see, sudo-mode 
<ogra> ut the password prompt rather looks like its gksu atm
<wasabi> python2.3 looks broken in some fashion. If I try to remove it I get pycentral rtremove: installed runtime python2.3 not found. Same thing when forcing it to reinstall.
<ogra> python2.3 is obsolete
<wasabi> Sure. But I can't remove it. ;0
<wasabi> Heh. My Alsa seems to be morbidly broken. Looks like the configuration files for it disappeared at some point.
#ubuntu-devel 2006-07-29
<gnomefreak> is there a known issue with fonts?
<pygi> sivang, poke
<pygi> sorry to bug at this time, but I need you
<gnomefreak> what is the meta package for Xfonts?
<decrypt> Seveas kontaktgestoort zeker? Problemen thuis of zo? En ik de dupe. Nou je bent een schande voor de community
<decrypt> Seveas ik weet ook wel dat je weet dat je dom reageerd. Maar helemaal zielig dat je het dan ook niet durft toe te geven.
<Seveas> decrypt, stop right here. this channel is not for escalating problems from #ubuntu or other channels. If you want to discuss, calm down and come to #ubuntu-ops
<bddebian> Heya
<^ohoel> does metacity in edgy come with compositor support?
<^ohoel> sorry, wrong channel and bad question
<bluefoxicy> Seveas: You do know that went right over my head, right?
<Seveas> bluefoxicy, ?
<bluefoxicy> Seveas:  <user> @!*# @$*^  some language I don't get !@@^* @^ <Seveas> *says something in english*
<Seveas> bluefoxicy, ah -- that person was just swearing
<Seveas> people tend to think they can be abusive in here after being thrown out of another ubuntu channel for that reason
<bluefoxicy> Ah.   It's amusing though, watching a conversation occur in two different languages is extremely disorienting.
<bluefoxicy> Seveas:  Is it ever too early to open a new spec that builds on an old one?  :)
<Seveas> you can always start a spec 
<bluefoxicy> Seveas:  I'm still working on one that attempts to describe a method for using pitti's AutomatedProblemReports to categorize and tag problems in ways that bring more attention to likely security vulnerabilities; but it feels a little premature because I really have no idea what pitti's stuff is going to do besides collect data and cram it somewhere probably at launchpad
<bluefoxicy> For all I know he could have figured this all out ages ago ;)
* netjoined: irc.freenode.net -> brown.freenode.net
<desrt> anyone played with edgy xen yet?
<crimsun> desrt: zul.
<desrt> zul?
<desrt> oh.  zul.
<desrt> zul; 'sup?
<bddebian> Heya crimsun
<crimsun> heya.
<zul> desrt: hey
<desrt> zul; xen me up, baby
<desrt> how's it working?
<zul> one or two issues that im working with but its cool..
<zul> wait for the upload for monday
<desrt> is it in the stock edgy kernel yet or do you have to install a -xen kernel?
<zul> its not in the stock edgy kernel there is a kernel in universe that needs to be rebuilt because of a ftbfs but i have the kernel-image if you want it
<desrt> i can wait for monday :)
<zul> ok
<desrt> thanks for the info.
<zul> no probs
<desrt> zul; one more question.  2.x or 3.x?
<zul> 3
<bluefoxicy> I love how I'll make a Wiki page, rabidly edit it, fill up my mail box
<bluefoxicy> and there's like 6 more devs that get e-mailed everything
<bluefoxicy> I am waiting for the day I get a bunch of e-mails entailing people being pissed at me and something about full inboxes.
<nictuku> l
<bddebian> m
<bddebian> I thought XbuildX versions got synced automagically?
* pygi pokes sivang 
* bluefoxicy yawns and prods the DrinkingFromTheFirehose spec, and adds stuff to https://wiki.ubuntu.com/DrinkingFromTheFirehose/Talk
<bluefoxicy> big comment at the end.
<bluefoxicy> aww.
<bluefoxicy> My comment didn't dwarf the rest of the content of that page
<bluefoxicy> I'm losing my edge.
<Hobbsee> hi all.  who broke dhclient
* bluefoxicy looks under himself to make sure he isn't sitting on it.
<bluefoxicy> Hobbsee:  wasn't me.  I appear to have sat on somebody's glasses though.
<Hobbsee> bluefoxicy: ah.  great.
<Hobbsee> someone broked my eth0 :(
<desrt> drinking from the firehose?
<imbrandon_> moins Hobbsee, i've almost got a a new box finished up, adding some hardware and such tonight ( bout the only time i've had to work on it the laste few days )
<Hobbsee> imbrandon_: yay!!!
<Hobbsee> desrt: a spec, to do with bug tracking.
<desrt> ah.
<desrt> each bug is a drop of water
<desrt> malone is becoming a firehose
<desrt> got it
<Hobbsee> yeah, there are about that many of them...
<Hobbsee> :P
<bluefoxicy> desert yeah.  I've been working on some stuff and I saw it and was like 'You know you could probably...'
<bluefoxicy> the best part of that comment is "encouraging users to not report crashes may be an option"
<bluefoxicy> ahh screw it
<bluefoxicy> I'll continue butchering pitti's stuff by spawning loads of excessive specifications on top of his barely started specifications XD
<bluefoxicy> memory is what the hell?  I find that hard to believe.  *checks top*
<bluefoxicy> Mem:    970916k total,   924908k used,    46008k free,    15472k buffers
<bluefoxicy> Swap:  4208944k total,    19148k used,  4189796k free,   362060k cached
<bluefoxicy> gnome's multi-load applet says memory is "100% in use by programs, 0% in use by cache"
<bluefoxicy> does 362/970 look like 0%?
<bluefoxicy> (I know what the problem is...)
<bluefoxicy> Fixed.
<bluefoxicy> The applet was 1 pixel high.  I jiggered with it, it fixed itself.  wHy the hell is it basing its calculations on its visual display instead of data from the system
* Yagisan-aWay is Away, Reason: ( "Real life :(" ) | Since: ( Saturday July 29 2006. 13:32:46 ) Xlack v2.1
<bluefoxicy> https://wiki.ubuntu.com/AutomatedProblemReportsTagging is a horrid, ugly brain dump.
<Burgundavia> bluefoxicy: john moser tends to write like that
<bluefoxicy> Burgundavia:  I just wrote that out, AutomatedProblemReportsTaggingForSecurity was a bit cleaner before I started but I'm trying to abstract parts of the spec into other specs to avoid diluting the different bits.
<bluefoxicy> I'm working on cleaning them all up.
<bluefoxicy> ok, I am going to sleep
<bluefoxicy> That stuff looks relatively clean.
* Yagisan-aWay is back ( Away 1 hour 37 mins 31 secs )
<HiddenWolf> Yagisan, please turn of the away-script in this channel, thank you.
<Yagisan> HiddenWolf, thanks I've already been chatised for trying a new client. It should be stopped now
<hunger__> What can I do to debug "Command failed" when running update-initramfs -u
<infinity> hunger__: sh -x /usr/sbin/update-initramfs -u
<hunger__> infinity: Thanks.
<hunger__> infinity: Just wrote a bugreport about initramfs (#54423). It does include that output now.
<infinity> Erm, that's curious...
<infinity> What the heck is giving you that "Command failed" output?
<infinity> Is that from your shell?
<hunger__> infinity: I am in a root shell and enter "update-initramfs -u"
<infinity> Cause it sure doesn't come from either mkinitramfs or update-initramfs.
<hunger__> infinity: I do see that during upgrades sometimes, too.
<StevenK> infinity: It looked to come from mkinitramfs to me.
<infinity> StevenK: it doesn't.
<hunger__> infinity: return code of update-initramfs is 0 by the way, maybe that helps?
<infinity> (Unless it's coming from some random hook script from some package or other I don't have installed)
<StevenK> Could it be a dash thing?
<infinity> hunger__: It will always be 0 if mkinitramfs exited 0, so that's not so helpful.
<infinity> StevenK: My /bin/sh appears to be dash here..
<StevenK> infinity: As in 'Command failed' is coming from dash
<hunger__> infinity: so is mine.
<infinity> StevenK: Oh, possibly, but I wouldn't expect dash to be that verbose.
* StevenK grins.
<infinity> (base)adconrad@cthulhu:~$ dash
<infinity> $ false
<infinity> $ 
<infinity> Nah.  Not verbose at all.
<StevenK> Well, Herbert has certainly left his mark on dash.
<StevenK> infinity: It might be a bashism in mkinitramfs
<StevenK> However, I suspect they have probably been shaken out already.
<hunger__> infinity: Where are those hook scripts?
<infinity> StevenK: Again, not likely, since I'm running dash here too.  And it was always written with dash in mind anyway.
<infinity> (Since half of it has to be able to run in dash in the initrd)
<StevenK> How about we just get hunger__ to run mkinitramfs with -x?
<infinity> hunger__: /usr/share/initramfs-tools
<infinity> StevenK: Yeah, that was my next call.
* StevenK high fives infinity.
<hunger__> infinity: I got cryptroot, evms, kernelextras, lvm, md, thermal, udev and usplash in /u/s/irf-t/hooks.
<infinity> hunger__: mkinitramfs -o /tmp/junk.img 2.6.17-5-686
<infinity> Err, with a "sh -x /usr/sbin/" on the front of that. :)
<hunger__> infinity: Command failed.
<hunger__> infinity: lots of output, last line "Command failed"
<StevenK> Second last line?
<hunger__> initlist= cryptroot evms kernelextras lvm md thermal udev usplash
<hunger__> then
<hunger__> + set - cryptroot evms kernelextras lvm md thermal udev usplash
<hunger__> then Command failed.
<infinity> Right, add a "set -x" somewhere to the top of /usr/share/initramfs-tools/hooks/cryptroot
<infinity> And then try again.
<infinity> And if that's the one bombing, reassign the bug, I don't ship that script. :)
<hunger__> infinity: "Command failed" happens right after "+ dmsetup info -c --noheadings -j 8 -m 4"
<hunger__> infinity: So this is not your bug I think:-)
<infinity> \o/
<infinity> Add that info to the bug report, and reassign like the wind.
<hunger__> infinity: reassign to?
<infinity> dpkg -S /usr/share/initramfs-tools/hooks/cryptroot
<infinity> Whatever paqckage that spits out. :)
<infinity> package, too.
* StevenK kicks Telstra.
* StevenK kicks Telstra again.
* ajmitch joins in & gives them a kick for good measure
<ajmitch> StevenK: what have they done now?
<StevenK> The afl.com.au website is breaking.
<ajmitch> right, so nothing important
<StevenK> Well no, since I'm listening to the streaming audio call.
<hunger__> Is it save to just delete scripts I do not need from the hook dir?
<StevenK> hunger__: You could remove the package in question.
<StevenK> Depends if anything depends on it.
<StevenK> Oh geez, that sentence makes sense.
<hunger__> StevenK: I do need that package or I would not have it installed:-)
<hunger__> I have crypted volumes, but by / is not encrypted.
<StevenK> Ah. I think that script only deals with a encrypted rootfs, so you probably could delete it.
<StevenK> hunger__: Which package is to blame, by the way?
<hunger__> cryptsetup
* hunger__ finds it annoying having to clean up the bootup process regularly because some debs he wants but does not actually need insist on adding them into the boot sequence every time they are updated.
<hunger__> s/them/themselves/
<hunger__> I love that almost as much as -doc debs depending on the executable:-(
* StevenK sighs. 20 minutes investigating a patch and I don't need it.
<jono> hey
<tseng> heya jono 
<jono> hey tseng
<TheMuso> c
<imbrandon> moins TheMuso
<TheMuso> Hey imbrandon.
<cypher1> can i program an application and submit to ubuntu ?
<Zdra> cypher1: if you make a package you can upload it for review on ubuntu-motu
<bddebian> Hello
<cypher1> Zdra, it is not a package..if someone writes a program which he thinks is useful, can he submit to ubuntu..or should he do it to sourceforge or somewhere else similar ?
<cypher1> hi bddebian 
<zul> well i would write the program put it somewhere and then package it and then upload to revu
<Hobbsee> so sourceforge, yeah
<bddebian> Hello cypher1, zul
* pygi pokes sivang 
<Pupeno> Hello.
<Pupeno> is it possible to compile linux-source-2.6.17_2.6.17-5.16 only for my architecture instead of for all of them ?
<lucas> how can I force a package to include a TOC on the ubuntu wiki ?
<wasabi> and the zeroconf thread continues.
<bddebian> wasabi: Continues?  It never ends :-)
<Treenaks> it's like Debian's duelling banjos
<Treenaks> it never stops
<wasabi> No new points have been raised in over 2 weeks on this thread.
<wasabi> But I think, since nobody reads all 2 weeks worth of content before posting, they keep going over the same thing in circles.
* mdz ponders killing the zeroconf thread
<mdz> I stopped reading it on the first day
<Hobbsee> mdz: kill the remains of suspend2 while your'e at it?  although it looks like that has almost died.
<bluefoxicy> mdz:  now that I read it, the spec says it'll be disabled by default and enabled by user action... isn't everyone bitching because they don't want it enabled by default?
<mjg59> Lots of people want it enabled by default
<mdz> I stopped reading it on the first day
<mdz> we took a decision on this about a year ago
<bluefoxicy> mjg59:  ah so instead of "OMFG DON'T TURN IT ON BY DEFAULT *HOLYWAR*" you're getting "OMFG BUT I'M TOO LAZY TO CLICK A BUTTON *HOLYWAR*"?
<shackan> do macs enable it by default or not ?
<slomo_> shackan: they do
<bluefoxicy> Also there should be a "Not a single remote hole in the default installation in 2 years" notice on the front page to mock OpenBSD </OBSD troll>
<mjg59> Can we please not have this discussion here?
<shackan> then why shouldn't you? well, ok, this discussion doesn't belong here
<mjg59> The technical details are well understood, it's a policy decision
<bluefoxicy> shackan:  open by default means a default permit policy for incoming connections or something like that (magical network setup behind the scenes); and also violates the "no ports open by default" policy
<mjg59> bluefoxicy: Ssh
<bluefoxicy> mjg59:  into what?  :)
<angasule> hello, as can be seen in: http://www.ubuntuforums.org/showthread.php?t=55173&   joystick support is close to non-existent, in my case, after plugging an analog joystick to the soundcard gameport, I had to mknod and modprobe to get it to work, the GUI only said it couldn't find a joystick device (and gave no help on how to set it up), I'm using kubuntu, but this is an ubuntu magic issue, so it shouldn't matter, I guess
<madduck> Hobbsee: suspend2 has not died, it's just experiencing name and maintainer change
<mjg59> madduck: Not really
<mjg59> madduck: We're talking about the irritating thread on ubuntu-devel
<mjg59> /That/ seems to have died
<bluefoxicy> heh
<madduck> ah, okay. want me to revive it? :)
<mjg59> madduck: Want me to brutally murder you? :)
<madduck> mjg59: that could be fun. :)
<madduck> mjg59: will you be at the party?
<bluefoxicy> murder-death-kill
<mjg59> madduck: Ought to be
<madduck> sweet.
<mjg59> angasule: Can you file a bug about that, please?
<bddebian> Hey, I want to go to the kill madduck party! :-)
<madduck> bddebian: sorry, only VIPs. :)
<Hobbsee> heh
<bddebian> heh
<mjg59> angasule: The issue is likely to be over how information about joystick ports is actually exposed to the OS
<bluefoxicy> if there's ever a party in baltimore somebody call me
<bddebian> Oh man there is such a wide opening for a joke in that statement
<madduck> bddebian: it's not the killing party, but http://wiki.earth.li/DebianParty2006
<bluefoxicy> bddebian:  this is a family oriented channel, or something.  Despite how many times Keybuk can say 'fuck' in under an hour when something goes wrong.  :)
<angasule> what is the ubuntu bugzilla? bugzilla.ubuntu.com requests a password and recommends going to bugzilla.ubuntu.com ...
<Philip5> hi guys, i have a problem when building a deb package with dpkg-buildpackage and everthing starts fine, gets configed but when dpkg-parsechangelog is to run the debian/changelog have been been deleted somehow... anyone know if there is a comman problem that makes this behaviour?
<mjg59> angasule: launchpad.net
<bddebian> madduck: Oh, cool
<mjg59> angasule: And then if you could let me know the bug number
<bluefoxicy> I should spec that now.  A counter in the bottom right of the status bar in xchat-gnome
<angasule> mjg59: analog joystick on soundcard gameport is too simple, even if the magic can't detect it, there should be an automatic script to enable it on user command
<bluefoxicy> to tally the amount of foul language developers spout off.
<mjg59> angasule: It would be preferable to just make it work all the time
* madduck does not see mjg59's name in the list...
<angasule> yes, of course
<mjg59> madduck: I can't find my wiki password, and the reminder mail thing is broken
<bluefoxicy> mjg59:  this is an issue of "can hal see it"
<bluefoxicy> I think.  You know what I have nfc.
<madduck> mjg59: will add you then?
<mjg59> bluefoxicy: ISA cards provide the information via isapnp
<mjg59> madduck: Sure
<mjg59> bluefoxicy: The issue is PCI cards with legacy gameport hardware
<angasule> also, I have a USB HID-compliant joystick which I'll connect in a week or two when i get the time, those two should cover a lot of ground (although I'm guessing the USB one will work without much trouble)
<mjg59> angasule: Yeah, USB should just work
<Treenaks> mjg59: it does for me (2 logitech pads, one with "feedback")
<slomo_> mdz: are you fine with updating evolution-sharp to a cvs snapshot that works with our latest evolution-data server? (compatibility for this was the only change)
<mjg59> It might well just be a matter of adding the PCI IDs of all the appropriate soundcards to the ns558 driver
<angasule> also, qjoypad or a similar utility is a *must*, since hats have a tendency to be detected as axes, I don't know why
<mdz> slomo_: yep
<slomo_> mdz: thanks
<mjg59> angasule: Or we could try to fix that bug
<mjg59> (to the extent possible)
<angasule> mjg59: well, qjoypad does a lot more than just provide a workaround for that
<mjg59> Then it's somewhat less of a must
<angasule> 52257 and 17245 are related bugs, I'll post a bug now (I was checking existing bugs)
<mjg59> Hang on, just let me check those ones
<mjg59> Ok, file a new one
<bluefoxicy> Slapping the user with a dialog vs. pulsing an icon in the Notification Area
<bluefoxicy> a dialog is annoying and invasive; but an active icon in the notification area may draw excess CPU?
<bluefoxicy> I dunno.
<doko> mdz: openoffice.org-experimental in edgy, it even installs and starts
<angasule> mjg59: bug 54458  https://launchpad.net/distros/ubuntu/+bug/54458
<Ubugtu> Malone bug 54458 in Ubuntu "Analog joystick on soundcard gameport not detected" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/54458
<Ubugtu> Malone bug 54458 in Ubuntu "Analog joystick on soundcard gameport not detected" [Untriaged,Unconfirmed]  
<bluefoxicy> doko:  what is -experimental?
<mdz> doko: neat
<bluefoxicy> hi pitti
<pitti> hi
<mjg59> angasule: Thanks
<mjg59> angasule: What sort of gameport do you have? Is it part of your soundcard?
<doko> bluefoxicy: native build
<angasule> yes
<bluefoxicy> pitti:  I was bored from 2am-4am last night, did you see I forked a bazillion specs out of the automated-problem-reports spec?
<bluefoxicy> doko:  so amd64?
<angasule> it's the old kind, that uses a couple of 100k ohm resistors and such
<mjg59> angasule: Right. But is it part of your soundcard?
<angasule> yes, it's part of my soundcard
<mjg59> What sort of soundcard?
<angasule> it's a Sound Blaster Live (I mentioned it in the report)
<mjg59> Ok
<mjg59> Does the emu10k1-gp driver get loaded?
<angasule> not sure exactly /which/ SB Live, I could find out, if it's important
<bluefoxicy> pitti:  there's one to describe the feedback mechanism ("if it detects a crash report it can read, it creates a notification which points to the file and asks to file a bug." <-- describe this); one on tagging and searching to find similar (likely the same bug) crashes; and one (which may become mainly informational) on using the tagging and sorting to locate likely security bugs
<angasule> mjg59: lsmod says: emu10k1_gp              4224  0
<angasule> mjg59: I currently have the joystick modules loaded, should I remove the script, reboot, and give you clean data?
<mjg59> angasule: Ok. Is the ns558 module loaded?
<angasule> mjg59: no
<mjg59> angasule: Ok
<bluefoxicy> ok I'm going to go take a shower.
<mjg59> How do I add another package to a bug in launchpad?
<zul_> no idea
<bluefoxicy> Is anyone else having gksu problems?
<AlinuxOS> mjg59, ping.
<mjg59> AlinuxOS: Hi
<AlinuxOS> mjg59, I would like to ask you if you have some time to package BPG's new fonts.
<mjg59> AlinuxOS: It's done
<mjg59> Just needs to be synced from Debian
<AlinuxOS> mjg59, I've created georgian users suitable fonts.conf file.
<mjg59> AlinuxOS: Yeah, I've included that
<AlinuxOS> mjg59, :) heh great.
<AlinuxOS> mjg59, and how about if there is more then 1 users ?
<mjg59> AlinuxOS: It's installed system-wide
<AlinuxOS> is fonts.conf installed in each /home/user/.fonts  or there is other way to do this ?
<AlinuxOS> mjg59, ah ok
<AlinuxOS> ttf-bpg-georgian-fonts in 0.2 version there was missed entry in /etc/defoma/hints/ttf-bpg-georgian-fonts.hints, is it corrected in 0.3 version ?
<AlinuxOS> mjg59, and I hope that 0.3 will be available for Dapper too :) not only for Edgy.
* AlinuxOS thanks mjg59 a lot!
<AlinuxOS> ;)
<AlinuxOS> mjg59, http://packages.debian.org/changelogs/pool/main/t/ttf-bpg-georgian-fonts/ttf-bpg-georgian-fonts_0.3/changelog
<AlinuxOS> ok everything is clear now.
<AlinuxOS> I'll test it as soon as possible.
* bluefoxicy blinks at an approved spec that says something about building Firefox for 686 'instead'
<amnezia> hi. when I'm compiling lirc, it needs bttv.h in the kernel sources which is nowhere in dapper. considering the bttv module is in dapper, I don't see why it's headers are missing. is this a bug or intended to be so?
<bmonty_away> amnezia: you need to install the appropriate linux-headers package, but you should really ask this question in #ubuntu
<mikearthur> https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15/+bug/34508
<Ubugtu> Malone bug 34508 in linux-source-2.6.15 "2.6.15 kernel fails to boot on ppc machine" [High,Fix released]  
<mikearthur> was this never fixed?
<mikearthur> I know it says fixed
<mikearthur> but I'm still getting the same problem on the latest linux-image
<carthik> Hi, could someone take a look at Bug 54475 - a cdimage.u.c. bug which I can't seem to find the best way to bring to the notice of whoever manages the site? Thanks.
<Ubugtu> Malone bug 54475 in ogre "cdimage.u.c/daily breezy" [Untriaged,Needs info]  http://launchpad.net/bugs/54475
<infinity> carthik: Oddly enough, filing the bug DOES get it to the right people.
<infinity> carthik: It's not catastrophic, it doesn't need extra enforcement on IRC, we'll poke it when we get to it (ie: when people are at work, rather than 5am on Sunday)
<carthik> infinity, notice that the bug is filed against the wrong "package" and there is no package I could find that was suitable. Sorry if I shouldn't have mentioned it here.
* pygi pokes sivang once again =P
<infinity> Oh, I didn't notice the wrong package.  Should be against ubuntu-cdimage.  I'll reassign.
<carthik> thanks infinity - sorry for any aggravation caused :)
<amnezia> bmonty:  sure thanks. I asked here because I searched for the header file on packages.ubuntu.com and no package provided it
<gnomefreak> amnezia: try linux-headers package
<amnezia> gnomefreak:  no bttv.h there either
<amnezia> thanks for the info, will look deeper into it at a later time
<bluefoxicy> wow.  There's a spec for Fluxbox Ubuntu
* bluefoxicy shrugs and frivolously writes a spec for enlightenment, just because.  Doesn't really care, but it looks to be the cool thing to do now.
<LaserJock> I thought that was already done
<^ohoel> flubuntu?
<pygi> fubuntu
<bluefoxicy> LaserJock:  enlightenment or flux?
<LaserJock> bluefoxicy: both
<bluefoxicy> I don't see an enlightenment one off the top of my head on launchpad
* bluefoxicy stops playing metroid prime and checks the wiki
<LaserJock> hmm, I'm not sure there is a spec on LP for it, but there's stuff out there on it
<crimsun> (ebuntu & flubuntu iirc)
<bluefoxicy> heh
<bluefoxicy> ctrl+alt+delete to launch gnome-system-monitor except I always use ctrl+shift+escape
<LaserJock> I think ebuntu might have died out in favor of something else
<ogra> it never really existed, unless you call something fully based on checkinstall a distro :)
<bluefoxicy> https://wiki.ubuntu.com/CommonCustomizations <-- this thing keeps saying stuff about gnome-app-install
<LaserJock> ogra: well, they did have a website and a livecd ;-)
<ogra> sure
<LaserJock> bluefoxicy: yeah
<bluefoxicy> I am thinking that adding more stuff to g-a-i is not going to help users much; they'll be like "I have a new system-- ooh a jillion kwhatevertheselooklikegamse hey why do they not look like the rest of my GNOME apps?"
<ogra> i could make fedorubuntu based on alien an put that on a livecd :)
<LaserJock> lol
<bluefoxicy> also I still would like to be able to disable KDE/GNOME stuff in g-a-i
<bluefoxicy> so if using Kubuntu (not that I ever would but..) GTK+ apps won't accidentally be installed, and if using Ubuntu KDE apps won't accidentally be installed.
<bluefoxicy> Qt/GTK mix and match UIs look like shit, seriously
<bluefoxicy> at any rate
<LaserJock> bluefoxicy: as usual, file bugs and write patches ;-)
<bluefoxicy> If the solution to "we need X Y and Z easily available to the user because these are common things he will install" is "put it in gnome-app-install," you should probably fix the default page in Firefox to have a link to /usr/share/doc/something/getting_started.html or whatnot, and list the various things the user may like to install
<bluefoxicy> complete with screenshots and step by step instructions of course ;) (if this is legal... is it legal to tell people to go install msttcorefonts?)
<bluefoxicy> LaserJock:  nods.  I probably will.  When I finish searching for the Sky Temple keys.
<pygi> mdz, you here perhaps?
<CarlFK> Should the edgy installer give me fd0 as a install choice?  http://dev.personnelware.com/carl/temp/Jul29/b/EdgyInstallToFloppy.png  
<CarlFK> and is debian-installer the package to bug?
#ubuntu-devel 2006-07-30
<Burgundavia> CarlFK: graphical or text installer?
<CarlFK> text - 
<Burgundavia> then yes
<CarlFK> -server
<CarlFK> yes it should, or yes debian-installer ?
<Amaranth> CarlFK: Yes to file against debian-installer
<mdz> pygi_: a bit
<pygi_> mdz, it's weekend, sorry for bothering
<pygi_> we'll talk on monday
<slomo> infinity: hi... please give-back gnome-python-extras on !i386 and after that build istanbul on !i386. should work now that totem build everywhere
<bddebian> Howdy
<khermans> can someone help me confirm a bug?
<khermans> i see this issue in Firefox on multiple machines in Dapper
<AlinuxOS> khermans, maybe Firefox's localisation problem?
<khermans> this in english
<AlinuxOS> where is the problem?
<khermans> when setting a program to handle downloads
<khermans> this is in dapper
<AlinuxOS> mmm
<khermans> can you try it?
<AlinuxOS> khermans, maybe it's Firefox's problem.
<khermans> umm it might be
<AlinuxOS> so you can try to file the bug here: https://launchpad.net/malone 
<khermans> AlinuxOS, well yeah but i want to see if you can verify it
<AlinuxOS> khermans, I use epiphany
<khermans> AlinuxOS, oh ok
<khermans> so you cant help
<AlinuxOS> I don't use Firefox.
<AlinuxOS> khermans, try to ask on #firefox
<khermans> k
<infinity> Uhh, WTF?  How did linux-headers-686 end up in ubuntu-desktop?
<Burgundavia> morning infinity
<Hobbsee> hi infinity, Burgundavia 
<Hobbsee> someone on drugs, probably
<Burgundavia> Hobbsee: likely a KDE user <ducks> :)
<infinity> And why can't I update the seeds?  THANKS, BZR!
<Hobbsee> Burgundavia: hah.  no, if it was a KDE user, they would have used linux-headers-ppc out of spite.
<Hobbsee> seeing as there are a lot more -686 users than ppc
<Burgundavia> right, I forgot how truly devious playing with all those useless options makes you KDE users
<Hobbsee> Burgundavia: hah.
* Hobbsee can be devious, and highly evil, yes.  fortunately, most of the time, i'm not.
<infinity> Oh, no, thanks to me for removing python2.4-paramiko, and to bzr for not providing a useful error message about it..
<jdub> infinity: headers + gcc -> bits to build kernel modules?
<jdub> (which makes me frown a bit)
<infinity> jdub: Oh, GCC got added too?  Guess I lost that fight, then.
<infinity> jdub: Of course, having it depend on "linux-headers-686" doesn't do much good for people with any of the other kernel flavours installed.
<jdub> bummer
<shenki> oh well, having the headers is better than what it could be... at the novell sled installfest they got us to install all 240mb of the kernel sources just to be able to build the binary drivers
* shenki pats his intel graphics chip
<shenki> apologies, wrong channel
<infinity> 00:44 -!- binaryBlob [...]  has quit
* infinity grumbles at LRM and mutters "if only..."
<nictuku> catalyst is great :-)
<bluefoxicy> what the heck is with the "reach out to women" crap in open source software?
<bluefoxicy> It's a free and open development model
<bluefoxicy> if the girls want to contribute they'll contribute and nobody is going to hurl them back out into a bush and run outside real quick to nail a "NO GIRLS ALLOWED!!!11111 all your base!" sign on the door
<Hobbsee> bluefoxicy: shut your mouth before i violate the CoC, and give you a piece of my mind.
<Zdra> all means are good to have more contributors
<Burgundavia> bluefoxicy: like it or not, women are extremely underrepresented
<Yagisan> Hobbsee, just disable your signature on it for 30 seconds
<Hobbsee> Yagisan: hmm?
<Burgundavia> bluefoxicy: if we are truly to be inclusive, we should be figuring why we are not repsentative and correct the issue. hence why things like debian-women exist
<Yagisan> Hobbsee, on lp. you can "revoke it". have a another sighned one ready to upload, after you offload
<Yagisan> Hobbsee, then technically - it's not violated :)
<Hobbsee> Yagisan: i dont understand why...
<Hobbsee> ohhh...
<Hobbsee> lol
<Hobbsee> bluefoxicy: it's people who say shit like you who discourage women, a lot of the time.
<Burgundavia> bluefoxicy: I suggest you read http://women.debian.org/faqs/
<Burgundavia> Hobbsee: you know argentina has more women DD's than men now?
<Hobbsee> Burgundavia: i heard that, actually.
<Hobbsee> Burgundavia: sounds cool to me - although once you're in, it doesnt make that much difference which gender you are.  if you can cope with a little, or a lot of sexual harrassment, and just ignore it.
<Burgundavia> sadly true
<Burgundavia> I read the comments on the announcement of fedora-women
<Burgundavia> probably shouldn't off, kind of knew it would be dumb
* Hobbsee never did.  got a fairly good idea of what they were though.  probably like bluefoxicy's comments earlier
<Burgundavia> pretty much
<Burgundavia> I think most of it is ignorance, rather than willfull stupidity
<Burgundavia> I just hope it is, at lesat
<Hobbsee> Burgundavia: dont forget idiots who havent learned to grow up yet, and think that being a moron will give them someone to sleep with.
<Burgundavia> right
<Yagisan> Hobbsee, experince tells, being a moron does not get you laid.
<jdub> Yagisan: there are people you can see about that
<Hobbsee> groan.  someone had to point that out, didnt they.
* Burgundavia recommends lobotomy
<Yagisan> jdub, no no need. My wife prefers me to not be a moron
<Yagisan> jdub, just as long as when she says jump, I answer "how high"
<janimo> infinity: ping
<Lathiat> whos the right person to speak to about new kernels initramfs not finding my drives to boot?
<Burgundavia> mdz: "thanks" for making me a moderator of -devel as well :)
<janimo> glatzor: hi
<glatzor> morning janimo!
<janimo> glatzor: the last changelog in g-a-i says something about replacing gtkhtml?
<glatzor> janimo: right. But I only replaced it in the description view.
<janimo> is that throughout g-a-i or in only one place? As I see there's still a gtk referenmce
<janimo> a ok, so it stays?
<glatzor> So we still use it for the third party licences.
<glatzor> :/
<janimo> I could not bzr get to check tha actual logs and changes since bzr hangs after 20-30 minutes
<janimo> glatzor: can/should that be changed?
<janimo> I am looking into g-a-i to see whether it can be made gtk only
<janimo> to add it to xubuntu
<glatzor> Originally we planned to use the firefox python bindings. But they are broken at the moment.
<janimo> ok, thanks :)
<glatzor> Could be doable.
<glatzor> but I think that you have to discuss the replacement of the licence widget with the marketing department
<janimo> right now it's only gconf and gtk-html that are from pygnome as I see it
<janimo> glatzor: ok I'll look at the license widget,I am not familiar with gtkhtml
<glatzor> perhaps we could just write our own html parser for the licences
<glatzor> it is quite simple html
<glatzor> I have already written an advanced textview inherit.
<glatzor> it can handle urls :)
<glatzor> I wrote it for update-manager to show the release notes.
<janimo> so is it used in u-m?
<glatzor> So it is called ReleaseNotesViewer. I reused in gnome-app-install for the description view.
<glatzor> I will take a look at the available licences. We just skip images and only do the bold and italic style of the text.
<glatzor> we could just.. :)
<janimo> would be really nice
<glatzor> or we could just skip the third party stuff in xubuntu in a first step, since it isn't also available in kubuntu and nobody has complained yet :)
<janimo> like realplyaer/opera ?
<glatzor> yes. 
<janimo> that too, but the problem is that the package depends on gnome libraries. Is 3rd party stuff in a separate binary package?
<janimo> or you mean soft-depend on gtkhtml and not show it in xubuntu?
<janimo> like with gconf in u-m?
<glatzor> right.
<janimo> that's a way too. Although the attractiveness of g-a-i to me is the 3rd party packages
<janimo> dunno about users though
<glatzor> one moment, I will take a look at the complexity of the html in the licences
<glatzor> oh, it is really simple at the moment. perhaps beautifulsoup could be a nice solution.
<janimo> it's  in universe though
<janimo> maybe the advantages of using this over gtkhtml are smaller than the drawbacks
<janimo> I am for it of course as it makes g-a-i possible in xubuntu :)
<Zdra> anyone knows if/when metacity will be build with compositor enabled ?
<Burgundavia> Zdra: there is a spificity in the repos
<Zdra> ah ok I see: spiftacity
<ajmitch> Burgundavia: which is old & broken
<Zdra> hum version 2.13, 2.15 has alot of improvements
<ajmitch> yes
<Burgundavia> ajmitch: I made no claim as to function, just to existence
<Zdra> :)
* Zdra will rebuild metacity so 
* ajmitch tried out metacity 2.15 with compositing, it didn't work that well
<ajmitch> Zdra: you have to grab libcm from cvs to do so
<Zdra> ajmitch: I know
<ogra> isnt that already in ? there is a gconf key to enable it
<ajmitch> ogra: no, not really
<ajmitch> metacity isn't built with compositing support by default
<ogra> then i wonder why its in the schema
<slomo> probably because nobody cared enough to leave it out of the schema when compositing support is not compiled in
<pulsar_> Hi.
<hunger> Could ubuntu use some more restrictive mount options for its filesystems by default?
<pitti> hunger: more restrictive in what way?
<hunger> eg. /dev needs no suid, /var/lock could be mounted with nodev,noexec,nosuid as well.
<hunger> lrm could even be ro,nodev,noexec,nosuid.
<azeem>  /dev is mounted?
<hunger> azeem: Yeap. /dev is a tmpfs.
<azeem> ah, right
<hunger> azeem: as is /var/lock, /var/run. /proc and /sys are mounted as well and could probably work with less permissions as well.
* hunger thinks having read about a /proc exploit that could be stopped by mounting proc with proper permissions.
<Nafallo> hunger: refering to debian-administration.org? :-)
<hunger> Nafallo: No. I'd never do that:-) It is just that that article made me wonder how the permissions are set on my ubuntu machines: Everything is a simple (rw) :-(
<hunger> The dirs mounted by the ubuntu system should at least come with settings as restrictive as possible by default IMHO.
<hunger> It is done easily enough by adding a couple of lines to /etc/fstab.
<pitti> hunger: right, that indeed makes sense; new installations can change that easily
<pitti> hunger: can you please file a bug against the installer?
<hunger> pitti: I will.
<pitti> hunger: cool, thanks
<hunger> pitti: #54530 is open and unassigned to a package now (installer is not valid and I did not know what else to use).
<Amaranth> hunger: debian-installer
<hunger> Amaranth: Ok, changed.
<pitti> hunger: argh, I wanted to change it to d-i, but LP oopses
<hunger> pitti: I did already.
* hunger thinks LP sucks.
<pitti> yep, saw it
<hunger> I always think twice before sending a bugreport... LP is so damn confusing that I just do not want to touch it:-(
<Seveas> hunger, http://launchpad.net/products/malone/+filebug if you have concrete gripes 
<sivang> re
<slomo_> hi sivang 
<mikearthur> any of you guys know which package provides the mach64 kernel module?
<azeem> mikearthur: please ask in #ubuntu
<mikearthur> sorry azeem, I have, but no-one seems to know
<mikearthur> I just asked on the off chance someone knew
<Hobbsee> mikearthur: if you know the file path of the module, you can look it up on packages.ubuntu.com
<azeem> mikearthur: sorry, but that is not a reason to ask here
<Hobbsee> hi Toadstool 
<Toadstool> hey Hobbsee 
<mikearthur> Hobbsee: thanks
<mikearthur> laters
<azeem> mjg59: did you take a look at fd.o's pm-utils?
<mjg59> azeem: Yeah
<azeem> does it look like it has potential?
<mjg59> Oh, it's certainly the future
<azeem> ok, cool
<cypher1> any one has any experience with acpi here ?
<azeem> cypher1: possibly, please ask a real, detailed question
<cypher1> how i do interpret /proc/acpi/event file
<cypher1> or the output from acpid daemon when i have connected to it
<mdz> Burgwork: <Burgwork>  if there any other mailing lists, I can do them as well
<mhb> hey everyone :o)
<mhb> A few day ago, I asked here when we (translators) finally get to start translating Edgy ... someone pointed me to the #ubuntu-translators mailing list, but I was sceptical about that ... and I was right.
<mhb> sorry, mailing list is without #
<Hobbsee> any core devs around here?  i'm looking for an uploader
<mhb> so I hope someone is able to answer me today ... or at least point me to a better source
<gnomefreak> Hobbsee: you can only upload universe and multi?
<Hobbsee> gnomefreak: yeah
<gnomefreak> ah
<gnomefreak> :(
<Hobbsee> dunno about multi
<Hobbsee> i wonder if jdub is around....
<gnomefreak> he just joined
<Hobbsee> jdub_ did, yeah.
<Hobbsee> hmmm.
<gnomefreak> did you look at edgy-wallpaper <<thinks thats the name   its a text file :(
<Hobbsee> gnomefreak: nope.  what about it?
<gnomefreak> it doesnt load any edgy wallpaper its the normal dapper ones
* gnomefreak was expecting it to be new wallpapers
<Hobbsee> gnomefreak: it deals in gnome, i take it?  that's the stuff i avoid.
<gnomefreak> i cant remember but maybe just gnome
<HiddenWolf> gnomefreak, they just split it out to avoid having to upload -artwork all the time
<gnomefreak> ah ok
<bddebian> Morning
<gnomefreak> morning
<bddebian> Hi gnomefreak
<gnomefreak> ty Hobbsee i didnt know if libpoppler was fixed or not
<Hobbsee> gnomefreak: :)  looked to be a bad mirror - that issue should never happen - it doesnt hard code the source package version
<gnomefreak> ah
<slomo_> Hobbsee, gnomefreak: what's with libpoppler?
<gnomefreak> slomo_: nothing it was conflicting with kubuntu-desktop per a few bugs
* gnomefreak never had issue with it
<slomo_> ok... i already thought there was something broken with it again for kde :)
<gnomefreak> nope ;)
<gnomefreak> 3.5.4 seems pretty stable here
<Hobbsee> slomo_: heh.  
<Hobbsee> gnomefreak: except arts
<TheMuso> n/c
<gnomefreak> arts as in the sound server?
<Hobbsee> yes
<gnomefreak> hmm
<slomo_> Hobbsee: kpdf is happy too now?
<Hobbsee> slomo_: havent heard about kpdf - obviously no one's filed a bug under kubuntu-meta for it
<^ohoel> how might I debug gksu/do failing to launch a command?
* bluefoxicy wakes up and reads backlog
<bluefoxicy> damn
<bluefoxicy> Hobbsee and Burgundavia are nasty.
<tseng> sigh.
<bddebian> tseng: :-)
<bluefoxicy> All I did was ask why all these open source projects have some specific "open source software for Women" thing to get girls working on open sources software, since you know, we let ANYONE contribute anyway
<bluefoxicy> and they freaking flew off the handle and started being bitchy
<mjg59> bluefoxicy: If you did some basic research, the reasoning might become clearer
<bluefoxicy> mjg59:  that's not the point
<mjg59> bluefoxicy: No, it's precisely the point
<tseng> it is.
<tseng> so let's drop it
<tseng> this isnt even the right place, whether or not you have any idea what you are talking about.
<bluefoxicy> No, the point is that we had a conversation like <me> why do we have a thing for getting girls to be developers when we already don't really do anything to stop them?  <girls> OMFG UR AN ASSHOLE!!!!1111
<tseng> hah I bet that is what they said.
<mjg59> bluefoxicy: Please stop now.
<tseng> please take it.. nowhere.
<bluefoxicy> I got a hostile and very unfriendly response and it was completely unwarranted.
<tseng> maybe because she already has an idea about you
<mjg59> tseng: You too
<bddebian> Yeah tseng you troublemaker ;-)
<bluefoxicy> mjg59:  Fine.  I'll deal with this later, when I can get a hold of both of them and beat them into the ground for being anal.
* bluefoxicy heads off.
<bddebian> bluefoxicy: Oh yeah, that sounds like a great plan
<Yagisan> <sarcasim>just perfect. yes, be more of a pig, lets see if that helps.</sarcasim>
<mjg59> No, really, I was serious about not having this conversation here
<bddebian> Hi Yagisan, Kamion
<Yagisan> mjg59, yep. I'm off. I suspect you (or someone else) may end up moderating it off here anyway
<Yagisan> bddebian, evening
<bddebian> How can I disable GLw building in configure without a specific option?  Can I do something like --without-libGLw ?
<bluefoxicy> mjg59:  and where else is it supposed to be held?  What do you usually do when someone attacks you for no reason?
<bddebian> I can do --without-MESA but do I really want to turn off all of MESA?
* bluefoxicy heads out now for real.
<azeem> bddebian: all the --without-foo flags are package dependant
<bddebian> Crud
<bddebian> So I have to kill MESA support to build xbvl?
<azeem> I do't know
<azeem> why do you want to disable GLw building?
<bddebian> azeem: Because we have removed the GLw libraries
<azeem> then you probably need to hack configure.in or configure.ac
<bddebian> :-(
<azeem> well, perhaps there is a configure option already, did you check configure --help?
<bddebian> Yeah, nothing specific for GLw so I am reading configure and it looks like --with-MESA or --without-MESA are my only options :(
<bddebian> Unless I pull out -lGLw from configure but I'm worried about more downstream affects
<bddebian> Bah, I guess I'll move on to another merge
<siretart> what is GLw after all?
<bddebian> Mesa Open GL widgets of some kind
<wasabi> apt could use some better dpkg healing properties...
<wasabi> like if a package fails, continue trying to set up the rest.
<mdz> wasabi: s/apt/apt-get/
<mdz> other frontends already do a better job of that
<wasabi> k.
<gnomefreak> libpoppler was fixed with the klibs issues right?
<bddebian> re
<bluefoxicy> what?  Tomboy got added to ubuntu-desktop?  Doesn't that mean mono is now in the desktop seed?
<bddebian> bluefoxicy: Do you not read ubuntu-devel ML?
<bluefoxicy> bddebian:  good point.  *C-A-Tabs*
<HiddenWolf> u-devel ML has been extremely tiresome lately.
<HiddenWolf> Can't blame anyone for giving up on it. ;)
<bddebian> HiddenWolf: Aye :-)
<HiddenWolf> It's odd that people can get so emotional over a computer language
<bluefoxicy> virtual machine
<HiddenWolf> bluefoxicy, the stuff it's coded in. :P
<HiddenWolf> I'm a simple old dog, the stuff that it's coded in is the language to me.
<bluefoxicy> HiddenWolf:  it's the virtual machine
<bluefoxicy> a layer between the program and the OS that involves generating code at runtime, completely removing any advantage of a more efficient compiler (aside from that the VM's code, for its 1% of the time spent executing, is faster because of smarter gcc)
<bluefoxicy> They generally waste cycles doing runtime profiling, which is useful for optimizing programs based on use; however, the only optimizations that can be done based on that information are moving chunks of code around to create better cache locality, and reordering conditional branches so the most likely one is evaluated first
<bluefoxicy> It's also just in general hard for me to figure out the security concerns associated with a virtual machine; and just adds an extra layer to that stack (if your OS has a hole in it; if your libs have holes; if your <VIRTUAL MACHINE> has holes in it; if your program has holes in it; then you have an open vuln)
<bluefoxicy> It doesn't really bring ... anything useful.  A couple minor disadvantages, no real advantages (you could always compile to bytecode, then compile the bytecode on the target platform to native, and ship the native code; so the classical 'advantage' is kind of a red herring; also see LLVM)
<bluefoxicy> HiddenWolf:  at any rate, I just hate virtual machines.
<HiddenWolf> bluefoxicy, well, we seem to be stuck with it.
<bluefoxicy> that does not make it any better.
<bluefoxicy> We seem to be stuck with Windows on all computers at Best Buy/Circuit City/etc too.
<bluefoxicy> or if you really want to be a hard-core gamer or whatever.
<HiddenWolf> bluefoxicy I guess it'll only get worse as schools start teaching .net :P
<bbrazil> the java is bad enough as is
<bluefoxicy> HiddenWolf:  I try to equivilate mono with wine.
<bluefoxicy> It's for running Windows crap.
<HiddenWolf> bluefoxicy, tell that to fspot, tomboy, beagle and banshee. :(
<bluefoxicy> My operating system can get any program running that's supposed to run on it kthx.
<jono> hey
<mjr> I try to ignore reality too sometimes :] 
* bddebian kills himself
* HiddenWolf gives bluefoxicy a glass of water and a hug
* bluefoxicy gets sick when he drinks water straight o.o
* HiddenWolf puts switches it for something else
<wasabi> bluefoxicy: There's logically no difference between mono and python and perl and bash.
<wasabi> It's a set of code designed to be resused to solve general computing problems once.
<wasabi> Instead of in each app.
<bluefoxicy> wasabi:  well, there's the difference that python, perl, and bash do not generate native code on the fly
<bluefoxicy> wasabi:  i.e. they don't pretend to be compilers and operating systems
<Chipzz> bluefoxicy: if you want to be pedantic about it, perl also runs on a vm
<wasabi> bluefoxicy: That's not entirely accurate. ;)
<wasabi> Psyco for Python.
* HiddenWolf runs for cover
<bluefoxicy> Chipzz:  perl compiles its scripts to bytecode and interprets that to avoid parsing text over and over.
<bluefoxicy> I'd expect Python to do the same... bash nah.
<wasabi> Blue, I believe perl uses a jit to assembly native instructions.
<wasabi> Am I wrong?
<Chipzz> wasabi: I think not
<wasabi> Parrot.
<Chipzz> wasabi: (that you're wtong)
<bluefoxicy> wasabi:  I've run perl scripts under PaX with full restrictions; this will kill anything that tries to A) create writable, executable memory; B) add PROT_EXEC to non-executable memory
<Chipzz> wrong
<wasabi> or something
<bluefoxicy> wasabi:  in short, I've run this stuff in environments where that's fundamentally impossible.
<wasabi> What's you're point anyways? Heh.
<bluefoxicy> I wouldn't write an office suite or anything big in Python either though, to be fair.
<wasabi> It's the same stuff the linker does.
<wasabi> Take templates of bits of code and assembly them in memory.
<Chipzz> bluefoxicy: to be fair, it wouldn't matter
<bluefoxicy> actually in byte code interpretation it doesn't really assemble them, it just reads them and triggers interpreter functions that carry out their functions
<Chipzz> bluefoxicy: performance is highly bound with underlying GUI libs
<bluefoxicy> like it'll read a bytecode instruction representing 'substr()' and call 'interpret_substr()' with proper args or such.
<wasabi> bluefoxicy: I still don't see your point.
<bluefoxicy> whereas a JIT will generate code that sets up a call frame and does such.
<Chipzz> bluefoxicy: we all know what a frigging interpreter does
<wasabi> Do you have a problem with people coding in new and unique ways to get work done faster?
<wasabi> =)
<Chipzz> it still does not cause much overhead in 99% of all cases
<bluefoxicy> and at any rate, you've still now got another program who's job is to interpret, convert to code, and optimize when you use JIT
<mjr> well, if it's the JITting that you have a problem with, you _can_ always use the mono interpreter...
<wasabi> Are you advocating we all program in raw ASM or what?
<wasabi> mjr: that's unmaintained.
* HiddenWolf remembers the 1950's duck and cover commercials
<bluefoxicy> so when a new optimization goes into gcc, it doesn't go into the JIT; when it goes into the JIT, it doesn't go into GCC
<Chipzz> wasabi: I have when it involves the core gnome desktop
<wasabi> Chipzz: I hate it when it involves the core gnome PLATFORM. Desktop? I don't think anybody really cares about that anyways. ;)
<bluefoxicy> so now what are we doing, duplicating work to waste time making another tool to do the same job, except to do it later?
<mjr> wasabi, is it? ah well, same difference to me.
<Chipzz> wasabi: there's a difference between the apps that go into the core gnome desktop and ubuntu
<bluefoxicy> mjr:  the mono interpreter will have the same problem as using python for a large application:  you'll now be interpreting data, which costs cycles over using native code.
<Chipzz> ubuntu can say: we ship with tomboy installed by default, ergo minimal memory reqs are such and such
<wasabi> Chipzz: Sort of my point. Regardless whether "tomboy" is accepted into the Desktop or some crap won't effect distros... who might distribute it anyways or not.
<mjr> bluefoxicy, indeed, thus the JITting is simply an implementation detail, an optimization
<wasabi> The Platform (the core APIs) should be plain C, because that platform has a requirement of running on embedded devices, and it's not practical otherwise.
<bluefoxicy> mjr:  and JITing involves generating native code from an intermediate representation; interestingly, GCC turns C, C++, ada, etc code into an intermediate representation and generates native code from it.
<Chipzz> wasabi: yes, but as an end-user opensource should enable me to say: fuck what the ubuntu developers think, I apt-get remove tomboy and can run gnome on lower end desktopa
<mjr> indeed it does
<Chipzz> desktops
<bbrazil> virtually all compilers use an intermediate representation
<wasabi> Chipzz: Exactly. 
<bluefoxicy> mjr:  In the process, both of these have to perform some sort of optimization; although I guess in the case of Mono the bytecode is for another processor (which only exists in theory) so it can be pre-optimized by the mono compiler (which is a mono project, not gcc)
<wasabi> Chipzz: And it will regardless whether Gnome "blesses" tomboy or not. Which is why I think this argument is moot.
<Chipzz> wasabi: and really, what the FUCK does gnome gain by 
<Chipzz> "blessing" tomboy?
<bluefoxicy> mjr:  so yeah.  We're back to implementing gcc from scratch, again.  Except we defer the final steps to the user and perform them an infinite number of times instead of doing it once early.
<Chipzz> they pull another app into their release cycle, making it more dificult for theirselves
<wasabi> Beats me. I think there's some concept of a Gnome "Recommended Desktop Bundle" or something.
<wasabi> Which nobody pays attention to anyways.
<wasabi> But Gnome feels is somehow important. :)
<bluefoxicy> .... I still have not settled on a real point in this conversation; I'm just floating between multiple points of reason.  This is getting annoying.
<Chipzz> wasabi: tomboy won't be any less (or any more for that matter) of an app if it isn't included in gnome
<wasabi> Ayup.
<wasabi> I'd say it'll be less, since it's release cycle will be tied. ;)
<wasabi> Depending on who you ask.
<Chipzz> *g*
<wasabi> I sort of think Gnome should constrain itself to "blessing" things which have some relevance in building other applications against.
<Chipzz> that was the point I was trying to make on desktop-devel; gnome doesn't /need/ *to include* these apps
<Chipzz> *to include* being the imperative words
<Chipzz> gnome does need these apps
<Chipzz> but as tomboy and a lot of other apps are evidence of: they DO get written anyway
<bluefoxicy> I wonder if Linus will bless Xen
<Chipzz> weither gnome blesses them or not
<Chipzz> but I do think deskbar was a very dangerous precedent
<HiddenWolf> why is it dangerous?
<bluefoxicy> It's like a ninja
<bluefoxicy> it'll flip out and kill someone.
<Chipzz> because people may start thinking: it's ok to start writing core parts in higher level languages
* bluefoxicy manages to send text while contributing nothing to the conversation
<HiddenWolf> Chipzz I wonder if that can be avoided all that much longer
<Chipzz> HiddenWolf: I wonder if everything that is needed in the core hasn't allready been written
<Chipzz> the reason people don't write stuff in C anymore is more likely that the stuff that does get written in higher languages is non-essential to absolutely everybody
<Sesse> hiya. would anybody mind syncing evms 2.5.5-11 from debian into ubuntu? mdz helped me doing the last bits of the merge, but seems to have disappeared before my upload
<Chipzz> "it's been done"
<Sesse> Chipzz: why the quotes? :-P
<Chipzz> because I consider it more of a fact (or a statemenet) than something I'm saying literally
<Chipzz> we are in a "everything that needs to be written in C *has* been written in C"-situation
<Sesse> oh
<Chipzz> unless you want to start talking new idea's a la "gnome 3.0"
<HiddenWolf> Chipzz, I doubt gnome3 will ever happen, at least in it's current definition
<Chipzz> HiddenWolf: exactly what definition are you referring to?
<HiddenWolf> Chipzz, "stuff that can't happen without breaking gnome2 compatibility" seems to be the general concensus, last I checked.
<robertj> I am, however, looking forward to the day beagle doesn't suck and that it can be used to create a recent files "Place"
<HiddenWolf> robertj, hopefully we'll get tracker for that
<robertj> tracker?
<slomo_> if tracker can do what it promises
<HiddenWolf> slomo_ it appears to do so.
<robertj> URL me please
<slomo_> HiddenWolf: did you already test it? :)
<HiddenWolf> robertj, it's on freedesktop
<HiddenWolf> slomo_: a while back I did
<robertj> thanks, I'm a bit behind on my internet reading
<robertj> there are apprently still parts I have yet to get to ;)
<HiddenWolf> robertj jamiemcc.livejournal too
<slomo_> HiddenWolf: don't understand me wrong, i would like to see something good for searching whether it is beagle or tracker... but nobody i talked to before did actually test it but only said that this thing is perfect ;)
<slomo_> HiddenWolf: but if you tested it... fine :) would you be interested in packaging it maybe? ;)
<HiddenWolf> slomo_, hell no. It's finally getting some pull, let's see a release first. :)
<HiddenWolf> It's still one guy's private baby at this point
<robertj> btw, has there been a jihad yet over whether we should list folders above or intermixed with files :)
<slomo_> robertj: not that i know... but i prefer the first ;)
<HiddenWolf> robertj, please, can there be some things left intact for us old farts?
<robertj> hehe :)
<gnomefreak> slomo_: do you remember the poppler bug?
<slomo_> HiddenWolf: ok, so let's see who wins this race :) i would prefer tracker if it is really what it promises to be and better than beagle...
<slomo_> gnomefreak: which one?
<robertj> HiddenWolf: I'd support moving them back to their own column :)
<gnomefreak> slomo_: kubuntu-desktop wont install due to depends
<HiddenWolf> robertj, I'm used to the explorer/nautilus-browser, and I like it that way
<slomo_> gnomefreak: url?
<slomo_> gnomefreak: or bugnumber? ;)
<gnomefreak> bug 53465
<Ubugtu> Malone bug 53465 in poppler "Cannot be installed. This breaks kubuntu-desktop!" [Untriaged,Needs info]  http://launchpad.net/bugs/53465
<robertj> I actually do to unless im looking by date
<gnomefreak> slomo_: i have thrown everything i can think of at him
<HiddenWolf> Then again, I'm a freak. I put things into their own folders by topic/subject. I like a clean hierarchical filesystem.
<robertj> rare is the day I want to manipulate a file more than an hour old
<robertj> if its more than an hour old its probably been open for the last month
<slomo_> gnomefreak: he seems to have a broken dpkg or apt database or something
<slomo_> gnomefreak: "libpoppler1-qt: Depends: libpoppler1 (= 0.5.1-0ubuntu7)" <--- not true for edgy
<gnomefreak> hes not on edgy
<robertj> HiddenWolf: do you have a /.hidden too ;)
<HiddenWolf> robertj, I just reinstalled my system last wednesday, and have been away from home since thursday. I'll get there. :)
<HiddenWolf> Which by the way fixed a half-dozen bugs I was experiencing. :P
<slomo_> gnomefreak: oh... no idea then...
<slomo_> gnomefreak: but "## Automatix sources.list" looks like the cause
<gnomefreak> i was thinking that too
<robertj> is Uslab showing promise? I haven't given it a try yet
<slomo_> gnomefreak: he probably had the xgl repositories in his sources.list, added by automatix... or automatix broke something else ;) at least all bugs that contained the word automatix i heard of were caused by automatix ;)
<gnomefreak> slomo_: yeah im not a fan of it either ;)  i will wait and see if my sources.list file fixes him
<^ohoel> well he obviously lied when he said he had only used official repos
<robertj> oh dear, google code hosting is horribly slow
<gnomefreak> ^ohoel: yep
<robertj> I'm nearing the 30 minute mark on this 200k, 50 file import
<HiddenWolf> robertj, peanuts. I backed up like 190GB to format last wednesday. :P
<pygi> sivang, poke ;)
<robertj> HiddenWolf: to google code ;)
<robertj> no wonder its slow
<HiddenWolf> robertj, heh
<gnomefreak> slomo_: you here?
<slomo_> yes
<gnomefreak> slomo_: can i subscribe you to this poppler 
<gnomefreak> bug*
<slomo_> hm why? i can't do anything about that bug ;)
<gnomefreak> this guy seems to think its still broken he is not wanting to here its his fault (in a round about nice way)
<gnomefreak> slomo_: oh?
<gnomefreak> nvm i thought you were maintainer
<slomo_> no, i only touched it in edgy so far :) and this is not really a poppler bug anyway
<gnomefreak> oh ok
<slomo_> i don't think it is a bug at all... you could ask him for apt-cache policy on both packages maybe
<slomo_> both should have exactly the same version as installable candidate from official ubuntu repositories
<slomo_> and that some thing thinks that he has 0.5.3-0ubuntu1 is a clear sign that he didn't use official dapper repositories as we got 0.5.3 only a week ago
<gnomefreak> well hes not taking that from me
<slomo_> ok, i answered there
<gnomefreak> ok
<gnomefreak> ty
<slomo_> i bet he had that broken xgl repository ;)
<gnomefreak> that would do it but remember only official repos were used
<slomo_> i think he had them enabled at some point, updated a few packages and switched back then which doesn't automatically downgrade anything
<gnomefreak> read what he last said (something like your blind only official repos were used)
<gnomefreak> i made my final comment on that bug i tried my hardest to help him
<gnomefreak> even hobbsee tried
<slomo_> hehe... i always get a bit angry when i see a bug report where xgl or automatix or compiz is mentioned in ;) seems almost always one of these things is the problem...
<bmonty> bug #?
<gnomefreak> bug 53465
<Ubugtu> Malone bug 53465 in poppler "Cannot be installed. This breaks kubuntu-desktop!" [Untriaged,Needs info]  http://launchpad.net/bugs/53465
<gnomefreak> you mean like xgl screwed up gtk in edgy ;)
<slomo_> or random applications crashes, nobody can reproduce it... and after a few replies the original reporter says he used xgl and tries to disable it and everything is fine again ;)
<gnomefreak> yep
<gnomefreak> ty bmonty maybe he will listen to you
<bmonty> gnomefreak: I'm not going to comment on the bug, I justed wanted to read what you guys were talking about :)
<gnomefreak> someone did
<bmonty> slomo
<gnomefreak> oh ok
<gnomefreak> ok ill brb gotta figure out bug in OOo :(
<gnomefreak> ok found it ;)
#ubuntu-devel 2007-07-23
<kmon> hi
<kmon> is there anyway to replace mactel efi? (with something that doesn't play a sound at start, for instance)
<Burgundavia> kmon: this relaly isn;t a suppor tchannel, but I think there is a project called OpenEFI
<kmon> Burgundavia: thanks
<Kano> hi, why dos: id -u now core dump?
<Kano> (testing amd64 current kubuntu iso)
<s0undt3ch> hello ppl
<s0undt3ch> hello ppl, anyone knows if gtk+2 package ships with it's translations?
<s0undt3ch> aparently not, is this a bug?
<Amaranth> s0undt3ch: translations are stripped out of main packages
<Amaranth> s0undt3ch: we have language packs instead
<s0undt3ch> Amaranth: then their not working
<s0undt3ch> at least for gtk+2 stuff
<s0undt3ch> like it's stock buttons
<s0undt3ch> if you have gimp installed there try this
<Amaranth> gutsy?
<s0undt3ch> LC_ALL=pt_PT.UTF-8 gimp-2.2
<s0undt3ch> or your preferred locale
<s0undt3ch> Amaranth: the stock buttons are not translated
<Amaranth> s0undt3ch: you have the language pack installed?
<ogra> s0undt3ch, do you have language-pack-gnome-pt and language-pack-gnome-pt-base ?
<s0undt3ch> Amaranth: yes, language-pack.pt
<s0undt3ch> Amaranth: I'm on kubuntu
<Amaranth> answer ogra's question :)
<ogra> s0undt3ch, gimp is no kde app ;)
<s0undt3ch> and yes language-pack-kde-pt-base is already the newest version.
<s0undt3ch> language-pack-kde-pt is already the newest version.
<Amaranth> s0undt3ch: gimp is not a KDE app
<ogra> s0undt3ch, do you have language-pack-gnome-pt and language-pack-gnome-pt-base ?
<ogra> kubuntu doesnt install gnome stuff by default
<s0undt3ch> no, not gnome, but gnomew is a gtk2 app right?
<ogra> so no gnome/gtk langpacks
<s0undt3ch> ok, I'm installng the gnome packs
<s0undt3ch> let's see
<s0undt3ch> arrrg, stupid
<s0undt3ch> ogra, Amaranth: I need those gnome packs
<ogra> indeed :)
<s0undt3ch> but while thinking gtk2 only one does not think of gnome
<s0undt3ch> thats' misleading
<Amaranth> basically if it's in main and uses gtk+ it's gnome and if it uses qt it's kde :)
<s0undt3ch> got it
<s0undt3ch> :)
<ogra> you could also install language-support-pt
<ogra> that solves all your probs
<ogra> (installs all -pt stuff )
<Amaranth> it's actually more like gnome == ubuntu-desktop, kde == kubuntu-desktop, and the base stuff is what they share
<Amaranth> iirc, anyway
<s0undt3ch> ogra: that's too many stuff, I like my locale in en_GB, I'm just developing an Irssi remote visual notifier and it's suposed to be translated ;)
<ion_> sundtch: Such a notifier already exists.
<s0undt3ch> ion_: tell me the name of that one :)
<s0undt3ch> ion_: fnotify.pl?
<ion_> sundtch: http://blog.ryanak.ca/archives/13, which i enhanced a bit: http://heh.fi/tmp/fnotify.pl http://heh.fi/tmp/irssi-notify
<s0undt3ch> ion_: that requires ssh at a specified interval, mine is real-time ;)
<ion_> Interval, huh? Its a constant connection.
<s0undt3ch> http://irssinotifier.ufsoft.org
<s0undt3ch> ion_: then I misread, and this is just an alternate one, with a GUI ;
<s0undt3ch> )
<s0undt3ch> ion_: by the way, mine was ispired by those posts ;)
<s0undt3ch> bbl
<wolfe> /wi/win 4
<wolfe> oop
<StevenK> infinity: Still living the LAX layover?
<infinity> StevenK: I've set up a booth where I'm selling charicatures.
<StevenK> infinity: Heh. Still trying to do bend libnss-db to my will.
<infinity> StevenK: You're kidding...
<infinity> StevenK: My opinion of your l33tness is rapidly declining, young man. :)
<StevenK> infinity: I did have eight hours sleep, an hour commute and an hour of other work. :_)
* StevenK glares at po/Makefile.in.in
<StevenK> What is this $(mkinstalldirs) stuff, and why does it fail?
<StevenK> infinity: Oh yes, and I daresay bug 27630 can be nailed shut too?
<ubotu> Launchpad bug 27630 in libcompface "libcompface: FTFBS - make up-to-dateness confusion on fast machines" [Unknown,Fix released]  https://launchpad.net/bugs/27630
<infinity> StevenK: haha.  Probably.  I need to clean my bug list. :)
<StevenK> infinity: I removed a mkinstalldirs = ... line from po/Makefile.in.in, which allows the make to keep going, but then it tries to run '$(BUILD_PATH)/usr/share' and fails miserably.
<infinity> Your autocrapfu is weak, I see.
<infinity> Or, intltool, in that case... But I count it all as being in the same sinking boat.
<StevenK> Yup. I've managed to avoid it all quite neatly...
<infinity> I'd proffer slightly less sarcastic advice, but I can barely think straight enough to do menial tasks like delete spam from my inbox right now.
<StevenK> Being 18 (?) hours into a layover will do that. :-/
<infinity> 19 hours now!
<StevenK> There isn't something like autoupdate (which I don't have much faith in), for intltool?
<infinity> The mangling of intltool madness should happen automagically with all the am/ac business.
<infinity> Assuming intltool itself is installed.
<StevenK> I think it ends up in the Build-Depends..
<infinity> Man, I get a kick out of "what do you do for a living?" ... "write operating systems."
<infinity> Just had some very excited little man run off with an Ubnutu CD, saying "I'm going to install it right now!"
<infinity> here's hoping he doesn't come back for tech support, in the state I'm in...
<Amaranth> wow the 'intel' driver must be _really_ broken
<Amaranth> either that or Matthew Nuzum has the worst luck ever
<xtknight> i'm thinking of implementing (as part of the proposed "Windows" install for Ubuntu) a way of detecting supported devices on the user's pc.  who would be the best person to talk to about that?  (whether it's wanted, what language they need it in, etc)
<StevenK> infinity: Oh my god, the thing builds.
<Amaranth> Who wrote the Kubuntu tribe 3 wiki page?
<Hobbsee> Amaranth: nixternal
<Amaranth> nixternal: "With the merger from Beryl the Compiz team has released a KDE window decorator for Compiz." is incorrect :)
<Hobbsee> hehe
<ajmitch> must be vista kicking in
<Hobbsee> yeah, i thought that was slightly odd
<nixternal> well then fix it..I don't follow that stuff, I was just told to make something up, and I did :)
<Amaranth> kde-window-decorator has sort of existed in some form for awhile, i believe it become usable as of 0.4.0
<nixternal> I went into the fx channel asking for help, and got nothing but a bunch of "i have no clue"
<nixternal> well it just recently got uploaded into the repos maybe?
<Amaranth> find me next time ;)
<nixternal> you just messed up...I am going to bug you non-stop, like I do crimsun about audio
<nixternal> ;)
<Amaranth> hehe
<crimsun> ...yeah, I was just going to say that.
* nixternal runs and hides
<nixternal> hahahahaha
<Amaranth> hmm, looks like kde-window-decorator was in feisty too
<infinity> StevenK: u r a jeneoos lol!
<infinity> StevenK: 2 more hours until I'm in the air!
<Hobbsee> infinity: put *down* the crackpipe now, then.
<StevenK> Hobbsee: He's been at LAX for 22 hours due to a large layover
<Hobbsee> these two statemetns are not mutually exclusive
<Hobbsee> but that's nasty!
<StevenK> infinity: Are you in any state to see a source packages or debdiff, or should I wait until you land and have slightly recovered?
<infinity> StevenK: I'm not sure I understand the question.
<infinity> StevenK: Or how this fancing blinking machine works.
<StevenK> Heh
<infinity> fancy, too
<infinity> fancing!
<StevenK> infinity: I have a non yada infested libnss-db package. Are you in any state to see the source package I have made?
<infinity> StevenK: The above was sarcasm, I didn't need an explanation. :)
<infinity> StevenK: But the point's still valid, I'm in no state.  Mail me, and I'll see it on Tuesday.
<infinity> StevenK: (I land at 8am, go home, nap, then get some work on)
<StevenK> Hrm. I wonder if the two Apache modules that are yada infested have been demoted.
<infinity> Pretty sure they weren't in main.
* StevenK checks again.
<infinity> -- gutsy/main build deps on yada:
<infinity> libapache2-mod-auth-pam
<infinity> libapache2-mod-auth-plain
<infinity> libnss-db
<infinity> I lied.
<infinity> And I kinda like mod_auth_pam, too...
<StevenK> thom said both have no way of working with Apache 2.2, either.
<infinity> Oh, if they're broken, then it's a non-issue.
<StevenK> Oh, so we demote, or break them?
<infinity> mod_auth_pam works, according to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=394097
<ubotu> Debian bug 394097 in libapache2-mod-auth-pam "libapache2-mod-auth-pam: doesnt work with Apache > 2.1" [Important,Open] 
<infinity> (Someone follows up with a working config)
<StevenK> infinity: I had a naughty plan which was to upload yada with a binary package rename to 'broken-piece-of-crap' and then clean out the NBS list of yada.
<infinity> There's a lot of stuff in universe that build-deps on yada.
<StevenK> 24, at last count
<infinity> Removing it form supported is good enough for me.
<StevenK> Agreed. I'd at least like it out of main.
<infinity> Alright, too lazy to plug in the laptop to charge it, so this is where I get off.
<infinity> See you in however many hours it is from now until Tuesday wheneverish.
<StevenK> infinity: Enjoy
<StevenK> Morning pitti
<pitti> Good morning
<pitti> hey StevenK
<Hobbsee> morning pitti!
* Hobbsee hugs pitti 
* pitti hugs Hobbsee back
<Hobbsee> :)
<Hobbsee> pitti: how was your weekend?
<pitti> Hobbsee: great! Katie Melua concert, ice cream, barbecue, and some wedddin preps
<pitti> Hobbsee: how was your's?
<Hobbsee> nice!  :)
* StevenK idly wonders about uploading libapache2-mod-auth-plain
<Hobbsee> pitti: good...had a birthday, have my grandmother over here on a holiday at the moment.  was fun
<Hobbsee> oh, and fixed adept
<doko> good morning
<pitti> hey doko
<Hobbsee> morning doko!
<mvo> hey doko
<Hobbsee> argh!!!  it's mvo!!!!
* mvo hugs Hobbsee
* Hobbsee hugs mvo :D
<pitti> mvo: do you know who is responsible for opera on archive.c.c?
<Hobbsee> pitti: i doubt anyone is, as they havent hired someone for it yet
<Hobbsee> as in, the job is still listed
<mvo> pitti: the last update done by etienneg, but I'm not sure if he is not too busy currently
<mvo> pitti: the 9.22 release should go in asap I guess?
<pitti> mvo: right, I just got a ping about it
<mvo> pitti: I can have a look in a bit
<pitti> mvo: I'll mail Etienne and CC Fabio and you, ok?
<mvo> pitti: yes
<mvo> pitti: I answered to opera now and CCed you. I prepare a new version now
<pitti> mvo: great, thanks!
<StevenK> pitti: Would you mind booting gmp out of NEW, it should halve libgmpxx4's NBS linecount
<saispo> anyone use rt61 driver here ? i can't get working wpa with it
<Hobbsee> oh no, it's Toadstool!
* Hobbsee hugs Toadstool 
<pitti> StevenK: done
<StevenK> pitti: Thanks
<StevenK> Just before a publisher run too, excellent.
<seb128> morning
<seb128> Hobbsee: ping? I don't get your gnome-panel change, the icon cache is generated during the installation
<Hobbsee> seb128: yes, i think i mixed my error messages, and screwed it up.  i thought it was the debhelper thing again, so just needed a rebuild, as ooo did :(
<Hobbsee> seb128: apologies :(
<Hobbsee> morning, btw
<Hobbsee> seb128: then again, it being only a rebuild, it shouldnt have broken anything, as it doesnt seem to have a frankenstinean build system, like apt.
<Hobbsee> (which is why i didnt ask you to check it first_
<Hobbsee> * )
<seb128> k
<seb128> feel free to drop a mail if you have a question and I'm not on IRC next time
<seb128> but right, the upload doesn't break anything, it's just of no use ;)
<seb128> hey carlos!
<carlos> seb128: hey seb!
<Hobbsee> seb128: sure
<seb128> carlos: had a nice end of GUADEC and travel back to Spain?
<Hobbsee> evand: ping
<seb128> Hobbsee: what was the bug about BTW? maybe I know how to fix it ;)
<seb128> you mentioned no LP number in the changelog
<xtknight> seb128, did you get a chance to look at Bug 60258 ?
<ubotu> Launchpad bug 60258 in gnome-art "Ruby crashes while using gnome-art-manager" [Medium,Confirmed]  https://launchpad.net/bugs/60258
<Hobbsee> seb128: let me see...it was a report on irc.  *grabs logs*
<carlos> seb128: yeah, we had a delayed flight so I didn't arrive home until 4:00 AM (instead of 2:00AM) but other than that... :-)
<seb128> xtknight: I didn't look at much bugs recently, I was travelling for 2 weeks and I've back to work on my desktop for 10 minutes
<xtknight> seb128, oh that would explain it :)
<xtknight> no hurry just wondered
<seb128> s/'ve back/'m back
<Hobbsee> seb128: http://pastebin.com/m212262c9
<seb128> xtknight: well, if I don't comment on a bug that's usually that I didn't look at it ;)
<Hobbsee> seb128: was the guy's pastebin
<xtknight> hah
<Hobbsee> seb128: (feisty --> gutsy upgrade)
<Hobbsee> seb128: and there was no bug number, due to it not being filed as a bug :)
<seb128> Hobbsee: I think I know what's creating the problem, I would need informations on the setup though, who is the guy?
<Zic> hmm => question about metacity-theme in Gutsy : Is it normal that the control bar is slimmer than Feisty ?
<seb128> Hobbsee: those are usually created by packages not installing icons correctly
<seb128> or by people installing some out of the packaging system
<Hobbsee> seb128: tatters
<Zic> I can see it very well in a Plasma of 107cm :] 
<Hobbsee> seb128: right
<seb128> would be interesting to know if a package is b0rked or if he installed something out of the packaging system
<Hobbsee> indeed
<Hobbsee> [17:29]  [Notice]  -SeenServ- I last saw tatters (n=test@AC8EB1E5.ipt.aol.com) 14h 6m 45s ago, quiting: "Leaving."
<seb128> anyway he's not on the chan, let's him file a bug if he wants his problem fixed
<Hobbsee> fair enough
<mvo> could anyone with edgy (or a edgy VM) do a quick install/run test for http://people.ubuntu.com/~mvo/tmp/opera_9.22-20070716.6edgy1_i386.deb ?
<Hobbsee> ...edgy?
<Mithrandir> Hobbsee: you know, 6.10. :-)
* Hobbsee doubts anyone runs it, unless they're security people
<Mithrandir> I have servers with edgy on them
<Hobbsee> Mithrandir: but that's...like...old!
<StevenK> I have a chroot here, hold on.
<Hobbsee> Mithrandir: based on the fact that i cant even remember thelast time i had an edgy install, let alone used it for daily use...
<Mithrandir> Hobbsee: I have servers with dapper on them too. :-P
<Mithrandir> I think we got rid of breezy though
<Hobbsee> yeah, but that's LTS, so it's a bit mroe expected
<Hobbsee> heh
<StevenK> mvo: Downloading it now.
<mvo> StevenK: cool, thanks a lot!
<Mithrandir> except it doesn't support the SAS controller in a couple of the machines, so dapper's not really an option there.
<Hobbsee> dapper doesnt support this machine.
<StevenK> mvo: Looks okay to me
<mvo> StevenK: thanks, it looks fine in my vm as well, I will upload now
<mvo> could someone with feisty (or feisty VM) check http://people.ubuntu.com/~mvo/tmp/opera_9.22-20070716.6feisty1_i386.deb please?
<asac> pitti: please give back ffox on sparc.
<pitti> asac: done
<pitti> asac: good morning
<asac> pitti: rock
<mvo> noone here with feisty and a bit of time to test  http://people.ubuntu.com/~mvo/tmp/opera_9.22-20070716.6feisty1_i386.deb ?
<asac> pitti: morning!
<mvo> hey asac!
<asac> hey mvo ... how was your holiday ;)
<asac> mvo: oh wait ;)
<mvo> asac: guadec you mean? very good!
<asac> yeah
<pitti> asac: btw, would it be possible to create midbrowser like epiphany? i. e. building on top of the firefox engine, but having a more lightweight UI, use gettext, etc.?
<asac> only thing i heard was the wifi was bad
<asac> mvo: is that the truth?
<asac> pitti: the idea is to have xul based browser
<mvo> asac: the talks were very good and it was great meeting so many upstream people. but the wifi was terrible
<asac> pitti: so things like extensions et al can be as easily written as for firefox
<pitti> asac: so if xulrunner is the future, and we have to put another mozilla copy into main anyway, shouldn't we rather put xulrunner into main then?
<Chipzz> mvo: it's not easy to offer good wifi with lots of people in a small area
<asac> pitti: xulrunner is not yet ready ... we can start when firefox 3 is out
<asac> pitti: thats what I am talking about ;)
<pitti> asac: so xulrunner wouldn't even work for the midbrowser project?
<mvo> Chipzz: yeah, I understand that. I sounded too negative, its good that we had network, but it was difficult to get on it quite often :)
<asac> pitti: yes and no ... it would be too hacky for now
<asac> pitti: xulrunner on 1.8.0.x branch is just not ready to run full xul apps
<asac> 1.8.x branch i mean
<Chipzz> mvo: just mentioning it because I have first-hand experience with just that ;)
<Chipzz> (providing wi-fi in small area with lots of ppl)
<asac> pitti: xulrunner was never ment to be released from that branch ... it was mike who brought this package up
<mvo> Chipzz: fosdem? that was quite good this year :)
<Chipzz> mvo: idd :)
<Chipzz> because we had some professional grade equipment from greenpeace ;)
<asac> pitti: and it works for gtkmozembed ... and basic chrome apps.
<Chipzz> (plus a shitload of linksys'es ;)
<asac> pitti: my primary goal for gutsy+1 is to make the duplicate sources go away
<asac> pitti: i probably hate it more than you do ;)
<pitti> asac: yeah, for the LTS this is quite important indeed
<asac> hmmm sparc failed again with libgnomeui-dev not installable
<asac> seb128: ^^^ ?
<asac> seb128: http://launchpadlibrarian.net/8547045/buildlog_ubuntu-gutsy-sparc.firefox_2.0.0.5%2B2-0ubuntu2_FAILEDTOBUILD.txt.gz
<seb128> asac: looking
<seb128> I don't know
<seb128> would need a login on a gutsy sparc
<asac> doko: ?
<seb128> to try to apt-get install packages and figure which one is blocking
<doko> asac: !
<asac> doko: can you try?
<doko> asac: try what?
<asac> doko: libgnomeui-dev not installable ....
<asac> on sparc
<asac> < seb128> would need a login on a gutsy sparc
<doko> asac: do you have access to faure in the DC?
<asac> doko: i have no idea :) ... but I doubt that I can install anything
<seb128> doko: you can't apt-get install in the chroots though, can you?
<doko> asac: ohh, then I can fix the xul dependency bullshit for gutsy+1 :-)
<asac> doko: i talked to mike
<asac> doko: the reason is that -common contains lots of xul ...which might break things
<asac> if you soften the dependencies
<doko> seb128: no, trying now on another machine
<seb128> mvo: is there a way to run a "apt-get install -s package" with a normal user?
<doko> asac: sorry, still don't get it, that this stuff changes for a) subsubminor versions, b) for debian release numbers
<doko> asac: but I may consider doing the same for GCC ;-P
<asac> doko: new upstream releases
<asac> doko: can break
<asac> doko: new debian uploads should be fixed now according to mike
<doko> asac: so why does he refuse it to fix it for a) and b)?
<asac> for b) it should be fixed
<asac> for a) its too hard to track
<asac> which i agree 50%
<mvo> seb128: yes -o Debug::NoLocking=true
<seb128> mvo: you are a star ;)
<doko> asac: maintaining the gcc/gcj/gnat split is hard as well. so this is not an argument
<seb128> hum, libgnomeui-dev is already installed on faure so it doesn't work there
<doko> seb128: same for me, so what should be removed?
<asac> doko: personally i would do it as a) is unlikely to break anything imo.
<asac> doko: but i agree that fixing the archive would fix things once for everyone
<seb128> doko: well, asac tries to figure why libgnomeui-dev is not installable on sparc, having a clean chroot or a pbuilder login to try to install it would be nice
<doko> seb128: libgnomecanvas seems to be out of date
<seb128> looking
<asac> seb128: yes " gutsy sparc   Failed to build"
<seb128>   libgail-dev: Depends: libgnomecanvas2-dev (>= 2.4.0) but it is not going to be installed
<asac> yes ... looks like a depend circle?
<seb128> circular depends, not good
<seb128> brb, trying the new glib2.0 update
<asac> seb128: Changes in GAIL 1.19.5 ... - Move gailcanvas to gnomecanvas and remove gnomecanvas dependence [#363103]  (Li Yuan).
<seb128> cool
<mvo> seb128: is bugzilla.gnome.org down?
<asac> seb128: me might have to go through build-rdepends though
<seb128> mvo: looks like
<seb128> asac: why?
<Amaranth> mvo: i hope luis didn't break it again
<Amaranth> :P
<asac> seb128: because there might be packages that miss build-depends on libgnomecanvas2-dev if we drop that from libgail-dev too now?
<seb128> they should not
<seb128> packages should not rely on indirect depends, if they use a lib they should Build-Depends on it
<asac> yes ... ok lets hope then
<asac> seb128: you want me to push that update?
<seb128> what update? you mean the Depends change?
<seb128> go for it, usually dholbach takes care for the a11y stack but he's not around
<asac> seb128: ok
<asac> seb128: done
<seb128> danke
<buxy> do people know if cjwatson is on vacation ?
<Mithrandir> buxy: afaik, he's not.
<buxy> I haven't managed to have a response from him since more than a week... yet I've seen him upload stuff
<Mithrandir> I think he's just been busy.
<buxy> Mithrandir: he told me he had a copy of the dpkg arch repository and I just wanted him to make it available to me :)
<cjwatson> sorry, I'll get back to you in a moment, just trying to look up the details
<cjwatson> I have a nasty suspicion that a mere checkout may not be as useful as I had thought
<buxy> yes, most people only have a checkout
<buxy> just make it available, I'll check for you if there's history in your files or not
<thom> infinity: that hack solution for mod_auth_pam looks like a really bad idea
<iwj> Yikes.  cadmium's disk filled up and I have 1140 mails to tell me about it.
<Amaranth> bryce: can you sync xserver-xorg-video-ati from experimental? it fixes Xv with Composite (video with compiz)
<pitti> Amaranth: please file a sync request bug
<Amaranth> hmm, never done one of those
<seb128> Amaranth: are you requesting a sync or asking bryce if that's ok to do one?
<iwj> Amaranth: Were you asking Bryce for advice whether the sync ...
<iwj> what seb128 said.
<Amaranth> both, i guess
<Amaranth> if it's ok to do one someone else would have to do it :)
<iwj> Right, then bryce would be the person to ask I think.
<seb128> k, let's wait for bryce reply before filling the bug then
<cjwatson> buxy: ok, gluck:~cjwatson/public_html/archives/ and gluck:~cjwatson/public_html/bzr/mvo/ is the best I've been able to dig up, I'm afraid. It's not at all complete but it may help you reinstate a little bit more of the history.
<mvo> buxy: I send you a copy of my old checkout a while ago, but I guess that was not very helpful?
<buxy> mvo: well a checkout without history isn't very useful, in that case I prefer creating fake history with archives of dpkg uploads (i have most of them from that period)
<cjwatson> unfortunately I cleared out my arch revlib a while back
<Amaranth> asac: why do you keep moving bug 113086 back to compiz?
<ubotu> Launchpad bug 113086 in firefox "Enabling Desktop Effects, some part of firefox and thunderbird windows are black for few seconds when I deminimize them." [Medium,Incomplete]  https://launchpad.net/bugs/113086
<cjwatson> upon realising that between it and my arch cache there were 1.5 million files in there
<buxy> ouch, yeah, arch is expensive in files :)
<buxy> cjwatson: what are the bzr repo supposed to be? conversion of old arch repo into bzr?
<cjwatson> buxy: a branch from that, I think. found it in mvo's home directory ... ;-)
* cjwatson apologises for the intrusion implicit in that
<cjwatson> buxy: I take it you've tried Manoj already?
<asac> Amaranth: i want compiz people to investigate
<asac> Amaranth: i don't see that its firefox
<Amaranth> i'm compiz people ;)
<buxy> cjwatson: yes, although he has never formally replied to my email, I need to pester him a bit
<asac> Amaranth: cool ... figure out why it happens in compiz while it doesn't without :)
<cjwatson> the bzr one may not be useful; I just thought the base might provide another interesting point of history
<buxy> during debconf he told me he might have it on his backup server but could only check after his vacation
<cjwatson> buxy: or djpig?
<Amaranth> asac: because lack of support for _NET_WM_SYNC_REQUEST in firefox means compiz doesn't know when the window is ready to be displayed
<cjwatson> I assume you've tried him already since he's current dpkg team
<buxy> cjwatson: djpig hasn't, he's still active in dpkg development and he's involved in that ;)
<buxy> right
<asac> Amaranth: what does that mean? what shall gecko do then?
<Amaranth> asac: trying to find a clear example of how to implement it
<asac> Amaranth: anyway ... compiz shouldn't break applications that don't implement that, right?
<Amaranth> asac: it doesn't 'break'
<Amaranth> you just get a black window during minimize/restore
<Amaranth> because compiz does the animation before the window is ready (since the window doesn't tell compiz when it's ready)
<asac> Amaranth: hmmm ... can't compiz do better? e.g. detect if that feature is supported and otherwise fallback to something else?
<Amaranth> fallback to what?
<asac> i am not into this ... but my guess would be to fallback to "no animation" :)
<Amaranth> that'd look pretty weird
<Amaranth> weirder than having a black window for the 1/4 second the animation is running
<Amaranth> hrm, _NET_WM_SYNC_REQUEST looks hard :p
<asac> Amaranth: why can't compiz fall back to something like what metacity does?
<Amaranth> in that case it's a bug against compiz-fusion-plugins-main but the compiz-fusion guys will just tell you to fix firefox :P
<asac> thats ignorance imo ... but anyway ... at least drop the needed infos to the upstream bug please
<asac> i can then confirm it ... so upstream devs will at least take a look at it
<Amaranth> err, it already has the needed info
<asac> Amaranth: do you have bug id at hand again?
<Amaranth> asac: https://bugzilla.mozilla.org/show_bug.cgi?id=378293
<ubotu> Mozilla bug 378293 in General "Black regions during unminimizing/unshading/opening Firefox/Thunderbird with Compiz" [Normal,Unconfirmed] 
<Amaranth> the link to the mailing list post should explain enough
<cjwatson> soren: an interesting issue has come up with apparmor-utils in standard
<asac> Amaranth: I confirmed that bug ... but honestly, without any compiz people stepping in I doubt that it will be fixed in near future
<Amaranth> asac: the only implementation of _NET_WM_SYNC_REQUEST i can point you to is in gtk+
<Amaranth> which i suppose you could use?
<cjwatson> soren: apparmor-utils Depends: apparmor Depends: apparmor-modules, the effect of which is to make the archive think that a kernel package (it's picked -386) needs to be promoted to Priority: standard
<Amaranth> you can drive it manually
<asac> Amaranth: so is every non-gtk application broken like firefox for now?
<Amaranth> no, Qt stuff works too
<Amaranth> firefox uses gtk+, doesn't it?
<pitti> cjwatson: now that we have the modules in the default kernel, we can drop that dependency IMHO
<cjwatson> soren: I'd much rather that no particular kernel package was Priority: standard. Can we drop that Depends: apparmor-modules to Recommends?
<asac> Amaranth: firefox uses gdk to draw its widgets
<Amaranth> asac: right
<Amaranth> asac: so you can use this :)
<asac> Amaranth: if you come up with the way gtk does it we can probably fix it
<Amaranth> you just have to drive it manually
<cjwatson> pitti: the only use I can see for it is if the kernel/userspace API changes
<asac> Amaranth: do you know how I can drive it with gdk means?
<Amaranth> hold on
<asac> Amaranth: please drop that infos to upstream bug ... and let me know ... I will then look how this might be adapted to gecko
<Amaranth> asac: eh, i don't have an account on that bugzilla
<Amaranth> asac: it's http://developer.gnome.org/doc/API/2.0/gdk/gdk-Windows.html#gdk-window-enable-synchronized-configure
* mvo is off for a bit
<Amaranth> asac: if you use that compiz will wait until you call gdk_window_configure_finished to paint
<asac> Amaranth: hmmm i somehow don't see when I should call finished
<Amaranth> asac: when firefox has finished handling "Configure events"
<Amaranth> i guess once it has the window drawn
<Amaranth> either on map or resize
<Amaranth> asac: apparently it also helps with flicker on resize for regular WMs too
<bSON> seb128: are you involved in the CompositeByDefault spec?
<seb128> bSON: yes
<seb128> why
<seb128> ?
* pitti -> lunch, and hoping that my network connection recovers a bit later
* Amaranth looks around
<Amaranth> bSON: what's up?
<bSON> seb128: i was wondering where it is decided which settings are chosen for the compiz plugins. the spec only lists which plugins should be enabled, not how they should be configured
<bSON> hello Amaranth
<Amaranth> bSON: The guiding principle and 'sleek and unobstrusive'
<Amaranth> Nice to look at but not particularly eye catching or annoying
<soren> cjwatson: Mathiaz is doing apparmour.. I haven't looked at it very much.
<seb128> bSON: https://wiki.ubuntu.com/CompizTeam
<seb128> bSON: changes to do are listed there
<bSON> Amaranth: that's good, but i find it a bit annoying that the last package version's animation settings where pretty miuch modeled after windows vista
<bSON> seb128: thanks
<Amaranth> bSON: How do you mean?
<seb128> bSON: animations didn't change, we use the zoom one
<bSON> strange, they changed when i last updated....
<seb128> looks like a local bug then
<asac_> Amaranth: was offline
<Amaranth> The animations we use have basically existed since the original compiz
<Amaranth> except the open/close animations, those are new
<Amaranth> so not copied from vista ;)
<bSON> then it must be a bug. i was already shocked ;)
<seb128> bSON: what sort of animation do you have?
<StevenK> Amaranth: I don't recall ever seeing Vista with wobbly windows.
<Amaranth> asac_: you just need to call gdk_window_configure_finished after you're done drawing on map or resize
<Amaranth> StevenK: that's not on by default?
<bSON> seb128: i don't know the create animation's name any more, but close animation was glide
<cjwatson> soren: ok, thanks
<Amaranth> bSON: yeah, glide
<Amaranth> those have been the defaults for over a month
<bSON> which looks just like vista
<Amaranth> does it? never seen vista
<seb128> I've not tried vista yet
<StevenK> Amaranth: Not on the Vista machine I've used. Then again, its graphics card is a complete PoS. :-)
<Amaranth> my card isn't powerful enough :P
<bSON> i tried a beta
<Amaranth> which is pretty sad, it's a GeForce Go 7400, haven't found a modern game it won't play at least decently :)
<bSON> well the problem is not that it looks like vista naturally, but for my taste that animation is not _that_ unobstrusive. maybe it just has to be a tad faster, i don't know
<seb128> what animations do you have a problem with?
<soren> cjwatson: What are the priorities used for anyway?
<bSON> seb128: the glide animation. i think it gets nervewrecking after a while
<StevenK> I found the default animations in Tribe 2 (not tried Tribe 3 yet) subtle and unobstrusive.
<Amaranth> bSON: it's already so fast i don't even see the actual animation
<Amaranth> bSON: just a sort of blur and i have my window
<bSON> Amaranth: i mean close
<soren> cjwatson: I know that one can rely on required and essential to be installed, but the others?
<StevenK> Close is fade, I thought
<Amaranth> bSON: close too, but less so
<Amaranth> close is glide 2
<bSON> is there a way to go back to ubtuntu default setttings?
<Amaranth> it folds the window out away from you
<Amaranth> bSON: gconftool-2 --recursive-unset /apps/compiz
<bSON> thanks
<Amaranth> but if you can really get annoyed by 2/10 of a second of animation of any kind i'm impressed
<Amaranth> i can barely even see it :)
<bSON> Amaranth: i don't have a glide, but a zoom-in effect for closing now
<bSON> maybe i'm too sensible ;)
<StevenK> Actually, I did a have a bug about compiz.
<StevenK> s/did a/did/
<StevenK> The alt-tab window switcher in metacity talks if orca is running. compiz under Feisty the window switcher doesn't, does the one Gutsy talk?
<cjwatson> soren: Priority: standard is only really relevant in itself to dselect users, but the same comments apply to the standard task which is installed by pkgsel
<bSON> Amaranth: i think it's not particularly unobstrusive if closed windows jump at you as they do for me now after usettin
<Amaranth> StevenK: ugh, don't want to turn on a11y :P
<cjwatson> soren: required and important correspond to the two stages of debootstrap
<cjwatson> soren: optional and extra are largely undistinguished in Ubuntu
<Amaranth> StevenK: probably not though, compiz just draws the text using cairo afaik
<StevenK> Amaranth: Ah. Shall I file a bug? My (visually impaired) boss didn't mind the animations and wobbly windows, but not talking when alt-tab'ing is a showstopper, and it could be considered a regression, given it may be on.
<Amaranth> yeah
<Amaranth> hopefully just using pango will be enough to fix it
<StevenK> Amaranth: Or shall I be lazy and trust you to remember? :-)
<Amaranth> heh
<Amaranth> i'll forget
<ion_> talk?
<Amaranth> file a bug, mark it triaged and high
<StevenK> ion_: Speak the title of window that will be switched to.
<Amaranth> if using pango is enough i can just snag the cairo context out of pango and not have to redo a lot of code
<StevenK> Amaranth: Against compiz?
<Amaranth> yeah
<StevenK> Oooer, bug 91780 . That's particularly annoying
<ubotu> Launchpad bug 91780 in compiz "Compiz's corner resize grabbers are difficult to get hold of" [Wishlist,New]  https://launchpad.net/bugs/91780
<Amaranth> hopefully the kubuntu guys won't hurt me for making compiz-plugins depend on pango :)
<soren> cjwatson: I see. Thanks for clarifying.
<bSON> Amaranth: after running your command, the settings shown by ccsm and those used don't match anymore
<Riddell> Amaranth: why does it need to do that?
<Amaranth> Riddell: a11y, apparently
<Amaranth> well, and for non-crappy text rendering
<cjwatson> $ wget -q -O- http://people.ubuntu.com/~ubuntu-archive/germinate-output/kubuntu-gutsy/desktop | grep ^libpango
<cjwatson> libpango1.0-0                    | pango1.0                         | libgtk2.0-0                     | Ubuntu Desktop Team <ubuntu-desktop@lists.ubuntu.com>                         |          350176 |             888
<cjwatson> libpango1.0-common               | pango1.0                         | libpango1.0-0                   | Ubuntu Desktop Team <ubuntu-desktop@lists.ubuntu.com>                         |            6666 |             124
<cjwatson> so it shouldn't make any difference to Kubuntu
<Amaranth> no problem then :)
<Riddell> yeah, amarok brings it in anyway
<Amaranth> amarok? weird
<Riddell> for libgpod
<Amaranth> ah, dang those kids and their ipods
* Amaranth hides his ipod
<Riddell> adds a load of stuff to the CD we wouldn't otherwise need
<Amaranth> bSON: bug in ccsm, i guess
<StevenK> Amaranth: Bug filed. bug 127705
<ubotu> Launchpad bug 127705 in compiz "compiz doesn't "talk" when switching windows" [Undecided,New]  https://launchpad.net/bugs/127705
<bSON> Amaranth: is it right that create animation = glide1 and close animation = glide2 ?
<Amaranth> bSON: yes
<bSON> ok
<StevenK> Amaranth: Importance changed like you asked, sorry.
<bSON> seb128, Amaranth: i would propose zoom for window creation because it nicely guides the user's focus without being obtrusive imo
<bSON> afk
<Amaranth> bSON: glide 1 looks like a weird zoom at the speed we have it running
<asac> lunch
<pitti> cjwatson: can you please have a quick look at bug 33249? from Keybuk's comment it sounds like hw-detect should defer modprobing usb-storage until after probing for the fixed disks; but is that really that deterministic in dapper?
<ubotu> Launchpad bug 33249 in hw-detect "root partition once /dev/sdi1 then /dev/sda1" [Medium,New]  https://launchpad.net/bugs/33249
<pitti> cjwatson: i. e. will booting the installed system always initialize the modules for the fixed disks first?
<pitti> cjwatson: (this might be an opportunity for the dapper point release)
* Hobbsee waves
<asac> Hi Hobbsee
<Hobbsee> heya asac :)
<xxxxx1> morning all!
<pitti> mvo: I added a question to bug 47044, can you please have a look?
<ubotu> Launchpad bug 47044 in apt "apt cant work with disable proxy" [Medium,Fix committed]  https://launchpad.net/bugs/47044
* Hobbsee sighs
<Hobbsee> if you dont like the switch in shell, please dont complain about it a full *year* after it's been discussed and implemented.
<pitti> Hobbsee: you mean /bin/sh -> dash?
<Hobbsee> pitti: yeah
<Hobbsee> whinging about bash not being used, so that the bash scripts arent compatible, and it needs to be bash so it can work on all distros, and bsd as well
<broonie> Needs bash so it can work on all distros? Interesting...
<Hobbsee> [22:59]  <slougi> it's just that i want those scripts to work as widely as possible
<Hobbsee> [23:00]  <slougi> currently the BSD's work, solaris works, redhat-derived stuff works, *buntu is broken ;)
<Hobbsee> [22:55]  <slougi> biggest annoyance is that the following breaks: if [ "${dirname:0:1}" != "/" ] ; <-- afaik this is actually standard usage
<Hobbsee> [22:56]  <slougi> and the above is standard POSIX afaik
<Mithrandir> uh, that's quite special, since the BSDs generally have strict-ish /bin/sh-s
<broonie> *Solaris* works. Ah, they're not being completely unreasonable.
<StevenK> That is not standard POSIX.
<evand> Hobbsee: pong
<Hobbsee> evand: did you get my mail?  :)
<Hobbsee> aparently it's an init script, so...
<StevenK> ${variable} will work, ${variable:0} and similar are bashisms
<evand> Hobbsee: indeed, reading it now
<StevenK> Hobbsee: I wonder, given that line if they're trying to determine the directory name is a symlink. If so, there are better ways. :-)
<Hobbsee> StevenK: no idea, ask
<slougi> yeah about the dash thing, i hope it's ok to bring it up here?
<IntuitiveNipple> Are there any ACPI suspend gurus in the Ubuntu devs?
<Mithrandir> slougi: don't ask to ask. :-)
<Hobbsee> IntuitiveNipple: mjg59 iirc
<IntuitiveNipple> Hobbsee: thanks... I'll keep an eye out
<slougi> Mithrandir: have bad experiences from some other distro devel chans ;)
<Mithrandir> slougi: worst case, we tell you something is offtopic here and direct you to some other place.
<cjwatson> slougi: I'd suggest this portable construct instead:
<Mithrandir> slougi: what is it you're really trying to do?
<slougi> right =)
<cjwatson> case $dirname in
<slougi> yeah one second
<cjwatson>     /*) ;;
<cjwatson>     *) do whatever you wanted ;;
<cjwatson> esac
<ion_> case "$dirname" in
<cjwatson> assuming I've read you correctly
<cjwatson> ion_: not necessary.
<ion_> Im paranoid about spaces in variables. :-)
<cjwatson> you're mistaken in the case of "case"
<ion_> Alright, thanks.
<cjwatson> you're right to be paranoid in general
<slougi> we're using a shell script similar to this: http://doc.trolltech.com/4.3/deployment-x11.html#creating-the-application-package
<cjwatson> $ foo='foo bar'
<cjwatson> $ case $foo in foo*) echo yes ;; esac
<cjwatson> yes
<slougi> basically the check for / breaks
<cjwatson> slougi: unfortunately Trolltech made use of a non-portable construct there. See my alternative suggestion above. See also http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_06_02 for the list of things similar to that that you can actually do.
<slougi> yeah i was assured by one of the trolltech support guys that that is posix ;) guess not
<cjwatson> the reference I gave is POSIX; I'd challenge them to provide a reference :-)
<slougi> yeah i just looked there as well =)
<slougi> thanks, i'll switch to the alternative syntax
<Mithrandir> you could also tell them to use "$@", not $* as the latter splits arguments.
<cjwatson> that shell snippet is in general pretty bad
<slougi> cjwatson: yeah, that one line is basically all that is left of that example
* cjwatson writes a better version
<cjwatson> http://people.ubuntu.com/~cjwatson/tmp/trolltech.sh
<cjwatson> untested, but I think that's a faithful translation
<slougi> pretty much, yes
<slougi> why not send it to the trolls?
<cjwatson> will do
<slougi> cjwatson: also i guess you won't mind if i use that ;)
<cjwatson> not at all
<slougi> cheers
* Hobbsee wondres if cjwatson actually wrote parts of the shell.
<StevenK> cjwatson: It passes a sh -n test
<cjwatson> Hobbsee: nope ...
<Hobbsee> cjwatson: ah.  thought you had.  no idea why
<cjwatson> I suppose I should use `` rather than $() to be portable to truly ancient shells
<Mithrandir> `` vs $() is pre-posix, though
<cjwatson> according to 'info autoconf', Solaris 10's /bin/sh doesn't support $()
<cjwatson> (yes, it's pre-POSIX)
<cjwatson> I'll skip the use of ${...%...} too in that case
<Mithrandir> welcome to this century?
<pitti> carlos: ah, seems that your gutsy base refreshment finally succeeded :)
<pitti> carlos: are the delta tarballs now created against 20070722?
<pitti> carlos: I did not build any gutsy updates since the tribe
<slougi> btw, i have to say to all that gutsy is turning out pretty nice, it's been completely bug free for me so far (upgraded from feisty 2 weeks ago). Keep up the good work :)
<slougi> and thanks for the shell help
<cjwatson> ion_: btw, 'info autoconf' mentions the first-argument-of-case special case in its "Shell Substitutions" node
<StevenK> pitti: A few things can be NBS'd after this coming publisher run if you want me to list them
* cjwatson updates his fragment so that it should work on stupid shells too
<pitti> StevenK: oh, please; shall I refresh the list in 15 minutes?
<ion_> cjwatson: Ok, thanks.
<TheMuso> ~/aw Away
<StevenK> pitti: Sorry, was afk. It looks like xen-hypervisor-3.1-{amd64,i386}, libode0c2 and libgmpxx4 can all go.
<pitti> StevenK: then xen hypervisor? why's that?
<StevenK> pitti: It's listed in NBS
<pitti> StevenK: it's probably FTBFS or so
<asac> Amaranth: do you have some spare cycles to test a patch for firefox+compiz?
<StevenK> pitti: Ah
<StevenK> pitti: In that case, kill libode0c2 and libgmpxx4
<asac> Amaranth: i cannot test, but added these gdk_ calls to places that might be suitable.
<StevenK> pitti: Actually, xen-hypervisor-3.1-{amd64,i386} really is NBS. xen-3.1 builds xen-hypervisor-3.1 - The Xen Hypervisor for x86/x86_64
<pitti> StevenK: ah, indeed; now, that makes sense :)
<StevenK> pitti: (And as a consequence, is sitting in NEW)
<pitti> zul: can you please run lintian over the xen packages? there is a lot of stuff, and some serious bugs (soname mismatch, missing Depends:, installing .pyc files, etc.)
<StevenK> zul: And the descriptions spell Xen in two different ways. XEN vs Xen
<zul> pitti: working on it later today
<pitti> zul: thank you
<ion_> libgksu (2.0.5-1ubuntu3) gutsy; urgency=low * debian/patches/17_composited_fade.patch: - Draw a black window and change opacity to fade when we have a compositor. (LP: #126529)
<ion_> Yay!
<Hobbsee> pitti: you oversized the cds again, it looks like
<pitti> Hobbsee: me?
<Hobbsee> #
<Hobbsee> By Martin Pitt <martin.pitt@ubuntu.com> on 2007-07-21
<Hobbsee> add apparmor-utils to standard recommends
<pitti> Hobbsee: ah, I see; those are not too big, but there was very little space left on some CDs
<Hobbsee> i386 is now over.  *shrugs*
<cjwatson> I bet that pulled in the -386 kernel by mistake, as I mentioned earlier
<cjwatson> yep
<cjwatson> mathiaz: would you drop the Depends: apparmor-modules | apparmor-modules-2.0 from apparmor to a Recommends, please? Pulling in the kernel via Depends at that point has undesirable effects on CD images and on the archive.
* Hobbsee hasnt read the backscroll yet.
<pitti> heno: why did you reopen the gutsy task of bug 48848?
<ubotu> Launchpad bug 48848 in quagga "[Dapper SRU]  Assertion failure in OSPF" [Medium,Confirmed]  https://launchpad.net/bugs/48848
<mathiaz> cjwatson: ok. I'll have a look into this.
<cjwatson> thanks
<carlos> pitti: hi
<carlos> pitti: the one generated tomorrow  will be
<carlos> I just cleaned up a bit the directories
<carlos> and fixed the script to stop doing a full export
<pitti> carlos: I don't really want to do a base update right now, can you export the delta tarballs relative to 20070625 again?
<mathiaz> pitti: I've got a question about package maintained in bzr.
<mathiaz> pitti: now that apparmor is maintained in bzr, what's the process to upload a new package %
<pitti> mathiaz: it doesn't chnage
<mathiaz> pitti: ? do I need to upload a new source package every time ?
<pitti> mathiaz: there is no magic (yet) to tell LP that this revision of this branch is a new upload
<mathiaz> pitti: I mean a new tar file.
<mathiaz> pitti: ok. But what about the version numbers ?
<pitti> mathiaz: depends; you should not change the orig.tar.gz unless there's actually a new upstream version
<pitti> mathiaz: and you should use upstream's orig.tar.gz preferably
<mathiaz> pitti: hum. We branched from a specific version from upstream.
<pitti> mathiaz: right, but that shouldn't be a problem?
<mathiaz> pitti: ok. I think I get the process - I'll keep the orig.tar.gz.
<pitti> mathiaz: I guess you don't use a patch system any more, so our changes will be in the diff.gz, but that's what we want then
<mathiaz> pitti: no. I don't think so. I'll give a try.
<mathiaz> pitti: correct. I dropped all the dpatch patches.
<mathiaz> pitti: they are applied directly in the source tree.
* pitti is off for a bit, bbl
<pitti> mathiaz: right
<mathiaz> pitti: thanks.
<bSON> Amaranth: hello again
<bSON> (had to go away for a while)
<carlos> pitti: sure
<carlos> pitti: should I keep the full export there or just remove it to save some space? (I already removed the 20070625 one...)
<carlos> pitti: I'm talking about the 20070722 one
<pitti> carlos: you can ditch it
<carlos> ok
<carlos> pitti: script updated
<bSON> Amaranth: the difference with "zoom" is that the window starts to zoom from the cursor position and flows to it's initial position, so the user always sees when a new window appears even if it's small.
<bSON> Amaranth: also, this gives users a visual relationship between some button/menu entry they click on and and a window popping up as consequence of this. for instance, if clicking the Close button of a gedit window with unsaved changes, the do-you-want-to-save dialog would seem to zoom out of that close button
<heno> pitti: I just moved the milestone, but probably did it on the wrong swivel box
<elkbuntu> grrr... who decided to make rhythmbox open every time i plug my usb key in. vewwwwy annoying
<pitti> heno: thanks; moving back
<cjwatson> elkbuntu: System -> Preferences -> Removable Drives and Media -> Multimedia -> Play music files when connected?
<elkbuntu> cjwatson, only media on the stick is an ogg theora
<elkbuntu> err.. s/media/multimedia/
<cjwatson> I don't know whether it's *correct*, but I suspect that's how you turn it off. *shrug*
<Nafallo> pitti: around?
<elkbuntu> and rhythmbox does not want to play it anyway. it'd be fine if it asked to play/open stuff, but not do it like this... /me skulks off to whinge at LP
<siretart> cprov: is the ppa-beta mentioned on https://launchpad.net/ubuntu/+ppas the same as the dogfood ppa, or do we need to reapply for the beta ppas?
<cprov> siretart: no, old users and/or people who already have the requirements in place in dogfood (GPG, ubuntero, beta-testers) are OK to proceed.
<\sh> who has some more knowledge about landscape? ,-)
<siretart> \sh: http://www.ubuntu.com/news/landscape-system-management-tool has
<\sh> siretart: well, yes, I read this already...but this is, more or less, the same I can read about RHN :) but what I need to know if there are "satellite landscapes" possible, like RHN Satellite servers
<siretart> cprov: so I just ignore https://launchpad.net/ubuntu/+ppas which tells me to write an email to apply, ok
<cprov> siretart: yup
<\sh> siretart: as you know, most servers in a DC are not free to fly around the internet ,-) they are caught by cages like paketfilters, cis ios ip filtering etc. ;)
<tkamppeter> pitti, ping
<pitti> tkamppeter: pong
<tkamppeter> Hi pitti, it is about the printer setup tool
<tkamppeter> WDYT what is more important for having easy printer setup?
<tkamppeter> EITHER:
<tkamppeter> - Plug-n-Print
* Hobbsee attempts to figure out how to reject https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/127748 without breaking the COC, or similar.
<ubotu> Launchpad bug 127748 in debian-installer "typo /usr/lib/debootstrap/scripts/gutsy instead of gusty on alternate CD" [Undecided,New] 
<tkamppeter> - A tool where bugs get regularly fixed by upstream maintainers and also new printing system features get regularly supported
<cjwatson> Hobbsee: I'll do it if you like ...
<tkamppeter> - Some more extra functions
<tkamppeter> OR
<Hobbsee> cjwatson: i'm thinking "you are a muppet, please learn to spell" isnt appropriate either
<tkamppeter> - Printers displayed as icons?
<cjwatson> Hobbsee: it's clearly a user trying to diagnose the bug and getting it wrong, though
<cjwatson> Hobbsee: from the sound of things, *something* went wrong
<Hobbsee> true
<cjwatson> so rejecting would not be appropriate ...
<cjwatson> I'll look at it
<Hobbsee> cool
<pitti> tkamppeter: I didn't take a look at s-c-p recently, I just remember that the version from a few months ago was very complex
<pitti> Amaranth: do you happen to know a page with some gutsy screenshots with compiz enabled?
<spasticteapot> What new features will be added to Ubuntu?
<spasticteapot> Also, who do I thank for the awesomeness that is Feisty Fawn?
<lemsx1> spasticteapot: #ubuntu-offtopic ?
<mathiaz> pitti: I've updated the apparmor packages and published everything in my own branch.
<mathiaz> pitti: can you have a look at it and merge it to the branch in ~ubuntu-core-dev ?
<iwj> Is it dholbach I should be grousing to about Java packages ?
<Hobbsee> iwj: not usually, no.
<elmo> iwj: doko
<iwj> Ah, of course, Ooo.
<Hobbsee> that's who i was after.
<iwj> doko: How much RAM do you think building some random java package should take ?  My 1GB testbed machine failed to build libbsf-java.
<ScottK> iwj: You might also ask man-di on #ubuntu-motu.
<doko> iwj: which architecture?
<iwj> amd64.
<iwj> GC Warning: Out of Memory!  Returning NIL!
<iwj> a couple of times, and also
<iwj> GC Warning: Repeated allocation of very large block (appr. size 131072000) May lead to memory leak and poor performance.
<doko> iwj: yes, known on amd64
<iwj> During javadoc.
<iwj> Ah.
<iwj> So, err, lots of stuff is ftbfs.  Is Something being done ?
<doko> yes, looking for the offending update
<iwj> I don't mind personally - my tester can just carry on and atm I'm reviewing all the reports by hand anyway to get rid of false positives.
<iwj> Right.  Fair enough, I'll not file bugs then.
<iwj> Let me know when you think it's fixed.
<doko> ok
<iwj> Thanks, and good luck.
<elmo> pitti: if you can free up any space on lithium, that'd be nice
<elmo> pitti: e.g. any pre-tribe-3 hardlink trees etc.
<iwj> Hnggg, looks like my testbed machine is broken again.
<iwj> Yes, this install is completely hosed.  No network, can't log in, everything broken.
<iwj> That's development I suppose.  I think I'll leave reinstalling it to tomorrow.
<cjwatson> wow, this machine had kernel packages on it dating all the way back to warty
* cjwatson frees up 1.5GB of disk
<coNP> Is it possible to get hunspell from debian incoming into gutsy? Should I simply file a sync / merge request? Or are there any other requirements?
<geser> coNP: you need an ack from a core-dev (if you aren't one) in the sync request
* coNP is not even a ubuntu member :(
<dholbach> not yet :-)
<geser> and check if it builds else you get a yelling from Hobbsee
<geser> :)
<coNP> "The later you become a Ubuntu Member, the later it expires" (old Hungarian proverb :))
<dholbach> hehehe
<pitti> elmo: there are no copies, so I cannot free anything obvious
<elmo> pitti: ok
<cjwatson> coNP: should be checked/coordinated with the firefox and openoffice.org maintainers, since it's broken those before
<coNP> cjwatson: I see
<xtknight> cjwatson, hello, did you get my PM about the device detection idea?
<cjwatson> xtknight: yes, but I haven't had a chance to think about it yet
<cjwatson> I'm slightly concerned about implementing too much on the Windows side, as it inherently can't be shared with the other supported methods of installing Ubuntu (which are, ultimately, primary)
<xtknight> ah
<xtknight> would making a spec be a good idea for it, at this point, until it is decided on?
<xtknight> it actually came from an idea or a couple in the IdeaPool
<cjwatson> xtknight: I think a mailing list discussion might be more useful to flesh out ideas
<xtknight> cjwatson, any in particular?
<cjwatson> ubuntu-devel-discuss probably
<pitti> mathiaz: bah, this bzr pull is hanging for ten minutes now, I already tried it twice
<pitti> mathiaz: I need to leave for Taekwondo now, maybe you can ask Kees? otherwise I'll do it tomorrow morning
<mathiaz> pitti: tommorow shoud be fine
<mathiaz> cjwatson: I've updated the apparmor package to use Recommends instead of Depends.
<cjwatson> mathiaz: thanks!
<mathiaz> cjwatson: it's published in my bzr tree, but it still needs to be uploaded.
<mathiaz> cjwatson: and merged into the ~ubuntu-core-dev tree.
<cjwatson> mathiaz: URL, and I can do it?
<mathiaz> cjwatson: can this wait until tomorrow ?
<cjwatson> well, CDs are broken partly due to it
<cjwatson> so I would prefer a quick fix
<mathiaz> cjwatson: the thing is that my tree contains more change than the quick fix for the control file.
<cjwatson> I see
<mathiaz> cjwatson: so I'm not sure that merging my branch in ubuntu-core-dev is so simple.
<mathiaz> cjwatson: I'd like to get in reviewed.
<cjwatson> why don't I merge and upload just that one change, assuming it was a separate revision in bzrr?
<cjwatson> bzr
<mathiaz> cjwatson: yop. that's possible then.
<mathiaz> cjwatson: let me give the information.
<alesan> why is there no /usr/include/linux/sys.h in ubuntu? isn't this a bug?
<cjwatson> alesan: you can't rely on being able to include anything in /usr/include/linux. If you need something from there that isn't available, you need to copy it.
<alesan> cjwatson, well I just used to find that file there in any other distro that's why I ask
<cjwatson> alesan: include/linux/sys.h in the current kernel tree says "This file is no longer used or needed"
<mathiaz> cjwatson: the branch is http://bazaar.launchpad.net/~mathiaz/apparmor/ubuntu-mathiaz
<mathiaz> cjwatson: and the revision is 517.
<alesan> cjwatson, good to know :) thenk you
<elkbuntu> eep. whatever that nautilus update was for, it just made bug 119954 worse as it now dies on opening the properties dialog, instead of on closing
<ubotu> Launchpad bug 119954 in gtk+2.0 "Nautilus crashes while looking the partition icon properties" [High,Confirmed]  https://launchpad.net/bugs/119954
<cjwatson> alesan: and include/linux/Kbuild doesn't list it, so even if other distributions include it right now, they probably won't for long
<alesan> cjwatson, you're correct thank you
<coNP> elkbuntu: you mean 2.19.5?
<elkbuntu> coNP, yep
<elkbuntu> anyway. nearly 4am, so i'll debug in th... err, later
<keescook> mathiaz: reading scroll back now.  what broke for cd builds?
<cjwatson> Depends: apparmor-modules pulls -386 kernel into standard because germinate doesn't know which one to pick so CDs get bloated
<cjwatson> keescook: ^--
<cjwatson> keescook: actually, if you'd care to upload just the diff from mathiaz' r517, I'm late for dinner now :)
<keescook> cjwatson: argh.  but apparmor-modules is provided by apparmor-modules-source
<keescook> is apparmor-modules-2.0 safe?  that's the "real" depend
<cjwatson> no it's not ..
<cjwatson> $ apt-cache show apparmor-modules-source | grep Provides
<cjwatson> $
<cjwatson> and in any case germinate wouldn't know which provider was preferred
<keescook> no, I mena after it's built; vi m-a
<cjwatson> germinate *really* doesn't know that!
<cjwatson> honestly, dropping to Recommends is better
<keescook> okay, so I should have apparmor-modules provide apparmor-modules-2.0 as l-u-m does?
<cjwatson> no, just drop the dependency to a recommendation
<cjwatson> it will never matter on standard Ubuntu systems because they'll always have l-u-m installed
<keescook> but I need to make sure l-u-m is installed if someone instlals apparmor
<keescook> ah, okay.
<cjwatson> there's no other way to do it without breaking other things, sorry.
<cjwatson> at least not if you want apparmor in standard
<keescook> right.  okay, fixing, one sec
<cjwatson> ta
<keescook> cjwatson: AA uploaded with Depends adjusted.
<mathiaz> keescook: did you update the ubuntu-core-dev branch for apparmor with the fix you've just uploaded ?
<keescook> mathiaz: pushed it now; still haven't rebased to your svn snapshot
<mathiaz> keescook: thanks.
<mathiaz> keescook: I'll merge ubuntu-core-dev in my branch.
<mathiaz> keescook: I've managed to merge it this morning
<mathiaz> keescook: I came across some issue about no common ancestors between the two branche.
<mathiaz> keescook: do you have sometime to merge my branch ?
<mathiaz> keescook: otherwise I could ask pitti to review the merge tomorrow.
<keescook> mathiaz: I haven't had time (still involved in ubuntu-live and oscon).  My concern is the difference between the orig files.
<mathiaz> keescook: you mean the fact that the orig file was different from the svn version ?
<keescook> right, you mentioned that when you generated a new orig.tar.gz, it was different from what was already in the archive.
<mathiaz> keescook: correct.
<mathiaz> keescook: I've described what I did in the commit log.
<keescook> okay, cool.  I'm pulling your branch now.
<mathiaz> keescook: I can check again to make sure that my tree at revision 514 is the same as the one in the orig.tar.gz
<mathiaz> keescook: the pull may take some time - pitti gave up after 10 minutes.
<keescook> yeah, I've started it now, since I've got netwrok connectivity.  :)
<cjwatson> mathiaz: repacking any .gz file will give you different results every time
<cjwatson> mathiaz: there's a timestamp in the gzip format ...
<cjwatson> mathiaz: you have to actually use the .tar.gz file in the archive, or if there isn't one already then the .tar.gz file shipped by upstream if at all possible
<cjwatson> (there might be other reasons why your .tar.gz was different, such as a different directory name at the top of the tree)
<mathiaz> cjwatson: I was using the tar.gz file.
<cjwatson> so what's the concern about regeneration above
<cjwatson> ?
<mathiaz> cjwatson: this is what I did: I branch from upstream bzr tree (which is an auto import)
<mathiaz> cjwatson: than I untared the orig.tar.gz in another directory.
<mathiaz> cjwatson: that's when I found out that there was some differences between my branch and the content of the orig.tar.gz
<cjwatson> ok, it's not unusual for there to be insignificant but non-zero differences due to 'make release' or whatever
<mathiaz> cjwatson: beside the debian/ dir.
<cjwatson> the "correct" way to deal with that is probably to branch off the release point and apply whatever differences were in the tarball to that branch, and then branch off *that* for the packaging
<mathiaz> cjwatson: well - it turned out that there was some change in the src files (like .c, .h, shell script)
<cjwatson> but it's not always worth that much effort and sometimes it's easier to just commit the differences to your branch
<cjwatson> if there are actual source changes, it may be that upstream actually released off a branch rather than off head?
<mathiaz> cjwatson: hum. That's what I did, except that I didn't branch off for the packaging.
<cjwatson> that's probably ok
<cjwatson> worst case you have a fiddly merge next time round that you need to be careful about
<mathiaz> cjwatson: I just kept using the same branche.
<cjwatson> worth talking to upstream and finding out what their release practices are
<mathiaz> cjwatson: yop. I don't know exactly where the orig.tar.gz came from.
<mathiaz> kees knows more about that.
<keescook> mathiaz: what I did to build it originally is in the debian/copyright file.
<mathiaz> keescook: yeah - I read it and it seems that something doesn't match somewhere...
<mathiaz> keescook: the svn revision doesn't match.
<keescook> mathiaz: yup; this is what I wanted to examine before taking the merge.  I'm still waiting for the branch to finish...
<mathiaz> keescook: for example, apparmor.d/enabled/ has only bin.ping at revision 510.
<mathiaz> keescook: the rest of the profiles, as shipped in the orig.tar.gz were only added at revision 538.
<keescook> mathiaz: okay, I'll check it out.
<mathiaz> keescook: this how I found out that something was wrong because the patches were not applied correctly
<mathiaz> keescook: to clarify what I did on my branch: 510 to 514 are the revision to bring the branch in sync with the content of the orig.tar.gz
<mathiaz> keescook: revision 515 is the actual merge, when I drop all the patches.
<mathiaz> keescook: 516 and + are more packaging bits.
<keescook> branching finished; relocating rooms at ubuntu live...
<cjwatson> oh my, compiz makes vmware sloooooow here
<cjwatson> horribly visible screen redraws in d-i ...
<seb128> cjwatson: weird, I think mvo made it use metacity on vmware
<cjwatson> seb128: compiz in the host not the guest
<cjwatson> d-i doesn't run a window manager ;-)
<seb128> ah, k
<seb128> righ ;)
<Kmos> any kde/kopete user here to test an old bug?
<keescook> mathiaz: I think the svn->bzr import broke revision numbers.
<keescook> bzr r510 != svn r510
<keescook> looks like bzr r489 == svn r510
<mathiaz> keescook: so the content of the orig.tar.gz is the same as bzr r489 ?
<mathiaz> keescook: ok. I get it now. So shoud I redo the branch ?
<Nafallo> could someone reject bacula ubuntu3 from dapper-proposed please?
<seb128> Nafallo: there is 2 of them there, which one?
<Nafallo> seb128: both. this one needs more work :-).
<Nafallo> seb128: thanks
<seb128> Nafallo: done
<seb128> Nafallo: you're welcome
<Nafallo> next LTS is soon enough?
<kevinl--> im sorry to ask here, but i am looking for help with usplash . trying to 0.44 to run on etch .  It seems to me that there is SOMETHING different in ubuntu 7.04 compared to etch (stable) , that makes usplash 0.44 work correctly.  I compiled it from source on etch, everything installs an usplash runs at boot time, but it falls back to the ugly black and white ubuntu graphic, with a messed up progress bar. I think there is something in ubuntu 7.04 tha
<kevinl--> ive even tried downloading all of the development libraries from the ubuntu repos into etch
<kevinl--> and then compiling
<GyrosGeier> hi
<GyrosGeier> I'm hacking a script that auto-backports a cross toolchain for {etch,lenny,sid,dapper,edgy,feisty,gutsy}. Both native and cross builds of gcc fail for me currently because it requires the compiler used during bootstrap to understand -fno-stack-protector
<GyrosGeier> as far as I've understood, the bootstrap compiler is build with really vanilla CFLAGS normally, and the final compiler is built with all the interesting options (since we know the bootstrap compiler handles them)
<GyrosGeier> however it fails on the very first compilation, during the native libiberty build
<GyrosGeier> any ideas?
<ScottK> Try a simpler project?
<ScottK> Maybe ask jdong. He's the king of Ubuntu backports.
<GyrosGeier> well
<jdong> ScottK: this sounds like a job for our GCC deities....
<GyrosGeier> everything else works; http://www.emdebian.org/~sjr/toolchains/pool/main/b/binutils has the evil cartesian cross already
<ScottK> jdong: I heard something about backports crack and I thought of you. ;-)
<jdong> ScottK: lol I'm glad :)
<GyrosGeier> (target runtime is still run through dpkg-cross in a sid chroot, I hope to hack a dedicated tool that doesn't need a chroot soonish)
<GyrosGeier> BTW, are some of the EmbeddedUbuntu guys on IRC?
<mc44> GyrosGeier: #ubuntu-mobile?
<GyrosGeier> mc44, thanks
<cjwatson> ogra: edubuntu intersection> glad to help. Let me know whether it works!
<ogra> i will, (next week)
<ogra> :)
<cjwatson> ogra: the manifest-desktop file looks vaguely OK, at least
<ogra> good, i dont expect issues...
<ogra> but testing will proof :)
#ubuntu-devel 2007-07-24
<Caesar> mdz: ping?
<mneptok> Caesar: it may be tough finding Canonical folks on IRC during Ubuntu Live.
<nixternal> anyone else having issues with the 'notification-daemon' after the gtk+ updates today?
<LaserJock> anybody know of a wiki page/doc that describes how the lang packs work?
<LaserJock> or translation in Main in general?
<Mithrandir> they're stripped out of the package at build time and shipped alongside the deb instead.  That then goes into rosetta which can export langpacks.
<LaserJock> ok, that was my general understanding
<LaserJock> that about as much as I know
<LaserJock> I'm trying to figure out why some people are reporting that tuxpaint doesn't use the translated files
<LaserJock> so I'm trying to work my way backwards
<Mithrandir> does it try to open the files itself?  They're stored in a different directory and glibc is patched to use this other directory too.
<Chipzz> I don't think that has much to do with how they're created
<Chipzz> did you check if they are up-to-date / in the right place?
<Chipzz> and if tuxpaint uses the correct translation domain?
<LaserJock> well, I see on LP that they are getting translated
<Chipzz> yes
<LaserJock> hmm
<LaserJock> let me check the domain
<Chipzz> but packages get rolled only every so often
<Chipzz> so you may need to wait until translations hit the debs, and until these hit the archives
<LaserJock> well, this bug has been since dapper
<LaserJock> the domain should be the source package name, right? not the binary package
<Chipzz> well since a lot of translations actually do get used
<Chipzz> it's most likely not something wrong in the langpacks ;)
<LaserJock> no, I'm guessing not
<Chipzz> I think the domain is unrelated to the package name
<Chipzz> rather, it's how gettext gets initialised
<Chipzz> (from how I understand gettext)
<LaserJock> hmm, I thought the domain in the .desktop told it what package the .pot belongs to
<Chipzz> hrrrm
<Chipzz> form as far as I understand gettext
<Mithrandir> LaserJock: that's just for translating the .desktop file.
<Chipzz> you do something along the lines of init_gettext('foo');
<Chipzz> where foo is the basename of the .po file
<Chipzz> (init_gettext is a made-up function)
<LaserJock> Mithrandir: ah, ok
<Chipzz> LaserJock: this is php, but you get the idea: http://www.phpdig.net/ref/rn26.html
<Chipzz> bindtextdomain ('greetings', './translations');
<Chipzz> textdomain ('greetings');
<Chipzz> http://www.phpdig.net/ref/rn26re450.html
<LaserJock> hmm, so I need to figure out how tuxpaint is looking for translations
<Chipzz> well
<Chipzz> before you dive into the code
<Chipzz> you could try stracing it, and see what files it tries to open ;)
<Chipzz> strace ftw ;P
<LaserJock> oh, good idea
<LaserJock> Chipzz: would I need to use something other than en_US to test it do you think?
<Chipzz> I'd think so ;)
<LaserJock> hmm, maybe en_GB would work
<Chipzz> I have the german language pack installed for testing ;)
<LaserJock> Chipzz: would this be it? open("/usr/lib/locale/en_US.UTF-8/LC_MESSAGES", O_RDONLY)
<Chipzz> no
<Chipzz> something ending in .po I think
<LaserJock> oh nifty, pitti is up :-)
<pitti> Good morning everyone
<pitti> shall I walk away again RSN? :-)
<mvo> if anyone is here with a dapper system or a dapper VM, could you please install/test http://people.ubuntu.com/~mvo/tmp/opera_9.22-20070716.6dapper1_i386.deb
<LaserJock> pitti: I'm trying to figure out a translation problem
<pitti> mvo: I'll try with ia32-libs in my amd64 vm
<mvo> pitti: thanks!
<LaserJock> ok, so a package doesn't need to install a .pot for it to get picked up, right?
<pitti> LaserJock: right; the build needs to create an up-to-date .pot, but .pot files are never installed into .debs
<saispo> anyone know, which soft create this default route "default dev eth0  scope link  metric 1000" (i use eth1)
<pitti> saispo: avahi-autoipd, I figure
<pitti> saispo: it goes through eth1:avahi0, not eth1, I figure?
<saispo> yes
<saispo> it's possible to disable this ?
<pitti> saispo: sure it is, but why would you want to?
<pitti> does it hurt?
<saispo> yes, with strongswan
<jdong> that's what she said?
<pitti> (you can just uninstall avahi-autoipd)
<saispo> strongswan don't want two default routes
<pitti> saispo: but it's metric 1000 only, so it should hardly matter?
<pitti> saispo: or does strongswan use even lower-prio routes?
<saispo> pitti: yes but if i uninstant it, kubuntu-desktop is removed, i think avahi-autoipd is used for something :)
<saispo> s/uninstant/uninstall/
<pitti> Riddell: ^ ah, that should be a recommends for Kubuntu, too, I think
<pitti> oh, it isn't in Ubuntu either, it shuold be
<saispo> pitti: avahi-autoipd is not in a default ubuntu ?
<pitti> saispo: it is, I meant it should be a Recommends:, not a Depends:
<LaserJock> will LANG= work to change the locale on a CLI when starting a program? or is LC_ALL better?
<saispo> pitti: will open a bug for Kubuntu :)
<pitti> LaserJock: depends; usually LANG= works, since by default Ubuntu only sets LANG and LANGUAGE, not LC_*
<pitti> LaserJock: with LC_ALL=C it'll always work
<LaserJock> well, I'm trying to debug a translation problem
<saispo> pitti: thanks :)
<LaserJock> which is off course fun for me the uni-lingual American ;-)
<Mithrandir> LaserJock: pft, it's not hard until you have to use the desktop in with a foreign character set, such as japanese or korean.
<LaserJock> heh, I bet
<Mithrandir> "does this glyph mean yes or no?"
<LaserJock> what is "/usr/share/locale-langpack/en/" for?
<pitti> LaserJock: English translations
<LaserJock> hmm, generic ones? I mean I see en_US, en_GB, etc.
<pitti> LaserJock: although it is common practice, C is not required to be English :)
<LaserJock> so I wonder what just en is
<Mithrandir> it's generic english
<pitti> so I doubt that there's actually a lot of stuff in it
<pitti> I've actually seen software which used French as C
<Mithrandir> that must be hard, given that C is ASCII
<LaserJock> hmm, I just installed the de lang pack, just to be cool
<LaserJock> now de has a lot but de_DE doesn't have so much
<pitti> LaserJock: that's the way it's intended
<pitti> LaserJock: the bulk is usually kept in just the generic po files, and the country specific ones contain just the exceptions
<pitti> LaserJock: de_CH and de_AT have 90%/95% of the strings in common with de_DE, I figure
<pitti> so it would just be unnecessary translation work and duplication
<LaserJock> hmm, what country uses de_AT
<azeem> austria
<LaserJock> ahhh
<LaserJock> ok, well I tried LANG=en_GB and LANG=de_DE and both times strace said tuxpaint is looking for en_US .mo files
<pitti> LaserJock: try setting LANGUAGE=
<pitti> LaserJock: GTK programs prefer $LANGUAGE
<LaserJock> oh wow
<LaserJock> so tuxpaint has tuxpaint itself and tuxpaint-stamps
<LaserJock> with LANG= tuxpaint is still in en but the stamps are in de
<LaserJock> with LANGUAGE= tuxpain is in de but the stamps are in en
<LaserJock> pitti: is ^^ normal?
<pitti> LaserJock: heh, looks like -stamps doesn't use GTK
<ajmitch> hi pitti, LaserJock
<pitti> hey ajmitch
<LaserJock> pitti: so would that be a problem for a normal user? is both LANG and LANGUAGE normally set?
<LaserJock> hi ajmitch
<pitti> LaserJock: yes
<pitti> LaserJock: i. e. both is set normally
<LaserJock> pitti: danke ;-)
<pitti> LaserJock: gern geschehen
<pitti> bonjour, Monsieur seb128
<mvo_> seb128: good morning
<seb128_> re
<seb128_> pitti: I was saying that we can update to dbus 1.1 now
<pitti> seb128_: \o/
<pitti> seb128_: dbus-perl is good now? already uploaded or shall I merge that as well?
<seb128_> pitti: there is a contributor debdiff available for the dbus update I think
<seb128_> pitti: a fixed version has been uploaded yesterday, I'm going to sync it now
<seb128_> pitti: hum, "sync tool currently has some weird bugs"? like what?
<pitti> seb128_: oh, that was sync-source.py (the LP version)
<pitti> seb128_: but it should be fixed now
<seb128_> k
<pitti> seb128_: can you please use sync-source.py instead of sync-source and see how it goes?
<pitti> seb128_: it worked for me yesterday, cprov did some in-place fixes
<seb128_> pitti: k, sure
<seb128_> pitti: should the agg in syncs be flushed?
<pitti> seb128_: hm, please delete it for now, i don't know about the status
<seb128_> k
<pitti> (that was my test package yesterday)
<seb128_> has the dpkg-source version been updated?
<pitti> seb128: not sure, but I doubt it
<seb128> k, so it likely still have an issue with "+"
<pitti> seb128: is bug 84007 fixed in gutsy already?
<ubotu> Launchpad bug 84007 in gnome-media "Cannot edit audio profiles without closing the list" [Medium,Fix committed]  https://launchpad.net/bugs/84007
<seb128> pitti: no
<pitti> $ gcc-4.2 --version
<pitti> gcc-4.2: No such file or directory
* pitti looks at doko
<doko> ?
<pitti> oh, I see
<pitti> that points to ccache, sorry
* pitti stands ashamed in the corner
<pitti> seb128: I commented that bug, as well as bug 112955
<ubotu> Launchpad bug 112955 in vino "vino (vnc) keyboard mapping problem" [High,In progress]  https://launchpad.net/bugs/112955
<seb128> pitti: thanks
<seb128> looking
<doko> seb128: the sparc failures are related to a wrong(?) glib2.0 header file, libgnomecanvas did fail again
<seb128> doko: I'll have a look
* Hobbsee waves
<pitti> Hobbsee!
<Hobbsee> pitti!
<Hobbsee> zomg, shirish crack.
<seb128> hello Hobbsee
<Hobbsee> more to the point, *more* shirish crack
<asisak> Where can you see that, Hobbsee?
<Hobbsee> asisak: ubuntu-devel-discuss mailing list
<Hobbsee> every time i see things with shirish in them, i want to gouge out my eyes.  unfortunately, i cant just block anything with his email in it, as i still get people's replies to him, and if i remove them, i probably miss valid content.
<Hobbsee> asisak: about packages to build binaries from sources.
<Hobbsee> (from within apt)
<ajmitch> surely it's not *that* bad
<Hobbsee> ajmitch: well, it's not crack.  it's more just blatant idiocy, and talking out the back of his head
<Hobbsee> ajmitch: if he had *any* clue about development of ubuntu, and debian packaging, he wouldnt have written that mail.
<Hobbsee> ajmitch: because apparently ubuntu accepts sources that dont build binaries, so you can install this package, to build said binaries for ubuntu.  or something.
<ajmitch> aha
<ajmitch> since we make things fail to build, just for fun & an exercise for the user, right?
<Hobbsee> exactly
* asisak seems to finally start to discover the secrets that stand behind the success of ubuntu
<ajmitch> asisak: bitter rage? :)
<pitti> "Just a little taste of Gentoo"
* asisak did some packages that do not compile
<asisak> but all of them depend on gtk I guess
<Hobbsee> ajmitch: what i *really* dont get though, is that he's a self-declared new user, and a self-declared idiot, yet he regularly spouts off absolute rubbish to multiple mailing lists, bug reports, etc...and apparently thinks he's helping?
<Hobbsee> he is *not* helping as it's almost always absolute crap that someone will take time to reply to, just to tell him how wrong he is.  ubuntu niceness, and all.
<ajmitch> Hobbsee: some people are like that, you have to let it pass & hopefully educate them, if possible
<Hobbsee> ajmitch: education fails.  although, it works *slightly* better when you educate him, while paying him out at the same time.
<ajmitch> even the famous Hobbsee was new once
<ajmitch> though I recall you being awfully shy & not wanting to break anything :)
<Hobbsee> ajmitch: this is indeed true, but i at least shut up and watched what others did, so as not to make a bloody fool of myself at every possible opportunity
<Hobbsee> i'm not having a go at the newness - far from it.  it's the fact that he constantly expresses his idiocy, without a thought about whether his thoughts are logical and correct, or not
<Hobbsee> ajmitch: does this mean that you think i do want to break everything now?  :P
<seb128> asisak: what error do you get?
<ajmitch> Hobbsee: you're far less afraid to
<coNP> seb128: only the sparc build error
<coNP> that is a gtk >= dep error
<ajmitch> Hobbsee: I remember how long it took to convince you to start merging stuff
<Hobbsee> heh.  and you and StevenK teasing me, not letting me leave until id' done one in front of you.
<ajmitch> :)
<seb128> coNP: ah, k, I'm on this one ;)
<coNP_> cool, seb128
<Riddell> pitti: should avahi-autoipd be changed to recommends in the seeds?
<pitti> Riddell: that would make sense IMHO
<pitti> Riddell: I'll do the same for Ubuntu
<Riddell> pitti: what about libnss-mdns?
<pitti> Riddell: the same, I think
<pitti> Riddell: shall I do the change in Ubuntu and you merge it?
<pitti> that's a bit easier for future seed changes with merges
<Riddell> pitti: ok
<Riddell> yes
<pitti> Riddell: committed
<iwj> doko: Is `gcj-4.2: Internal error: Killed (program jc1)' another symptom of the amd64 Java damage or is it something else ?
<doko> iwj: jc1, not ecj1? didn't see this yet. appears to be a problem with glibc-2.6 on amd64
<iwj> I c&p'd that message, so yes.
<iwj> OK, I'll file a bug then with a full transcript.
<iwj> It might not be today, as I have a backlog of 81 of these autopkgtest ftbfs's to eyeball and report and I'm trying to get some other work done too.
<seb128> pitti: bug #84007
<ubotu> Launchpad bug 84007 in gnome-media "Cannot edit audio profiles without closing the list" [Undecided,In progress]  https://launchpad.net/bugs/84007
<seb128> pitti: "whereas feisty has 2.18.1-0ubuntu1", were did you get this version?
<seb128> gnome-media | 2.18.0-0ubuntu1 |        feisty | source, amd64, i386, ia64, powerpc, sparc
<seb128> that's from madison
<pitti> seb128: hm, weird, I used rmadison
<pitti> seb128: oh, gnome-media
<pitti> seb128: I madison'ed vino
<seb128> well, there was one on vino and one on gnome-media
<seb128> k
<pitti> *headdesk*
<seb128> so the version is correct ;)
<seb128> thanks
<pitti> seb128: sorry then :)
<seb128> np
<pitti> seb128: bug updated
<pitti> seb128: so, gutsy and feisty-proposed at the same time are fine, but I won't copy it to -updates before it's fixed and tested in gutsy
<seb128> ok
<pitti> seb128: so I see a bunch of syncs from you, but not libdbus-perl?
<seb128> pitti: no, it's not on the mirror yet, I'll dget and do it by hand now
<pitti> mmm dget; that's news to me, thanks for the hint
<lool> There's a libnet-dbus-perl NMU in Debian unstable pending installation
<seb128> lool: that's what we are speaking about
<lool> Ok; sorry
<seb128> nothing to be sorry about, thanks for the information ;)
<lool> Will you switch to dbus 1.1.1 afterwards?
<seb128> yes
<lool> Cool
* pitti merges dbus in the meantime then
<seb128> pitti: there is a marge patch on launchpad
<seb128> (in case you didn't notice)
<pitti> seb128: I saw, just looking at it
<seb128> k
<seb128> libnet-dbus-perl synced
<pitti> ah-haaaa
* pitti just realized the reason for the 'cannot initialize hal' bug on the live CD
<seb128> ah?
<pitti> seb128: in feisty, hal was started by the dbus script
<seb128> right
<pitti> now it has its own init script at prio 24
<pitti> but gdm is at 13
<seb128> ah
<seb128> gnome-session is starting faster then?
<pitti> I think the correct answer is to move hal's init script before gdm
<pitti> bit tricky, S12dbus and S13gdm
<pitti> S12hal would work due to asciibetical order, though
<pitti> but 12.5 would be better :)
<cjwatson> BASIC disease
<pitti> yeah :/
<cjwatson> d-i did a BASIC-style renumbering exercise a couple of months ago on its installer-menu-item numbers
* pitti thinks back to his ol' C64 BASIC ages
<cjwatson> we just multiplied them all by 100, so should be enough room for a while yet
<pitti> init script prio migration is painful, but I think we have to do it
* pitti files a tribe-4 bug for himself
<cjwatson> I think S12hal would be OK here
<cjwatson> ish
<cjwatson> there's a distressing amount of pressure on the 10-20 range
<cjwatson> I think it was a mistake to have the default be 20 originally
<cjwatson> (rather than 50)
<giskard> morning
<cjwatson> unfeasible to change now, of course :(
<pitti> well, fractionals look terribly ugly, but it'd be a last resort
<pitti> fortunately it's "D"bus and not "X"bus or so :)
<pitti> elkbuntu, Hobbsee: bug 127913 FYI (I think you saw that, but I didn't find a bug report yet)
<ubotu> Launchpad bug 127913 in hal "hal starts too late" [High,In progress]  https://launchpad.net/bugs/127913
<elkbuntu> pitti, yeah, i must have forgotten to report it, sorry for that. testing stuff in the high wee hours isnt always smart :
<elkbuntu> pitti, would it also be why sometimes my networking hasnt started properly?
<pitti> elkbuntu: it's possible
<pitti> seb128: ah, with new dbus network-admin is almost empty
<seb128> "almost"?
<seb128> do you have the new perl package?
<seb128> I mean libnet-dbus-perl
<pitti> seb128: no, I'm going to wait with the upload until it's available and I confirmed it to fix the issue
<seb128> k
<pitti> yeah, s/almost// :)
* Hobbsee comes back, sees red
* Hobbsee comes back, sees red
<Hobbsee> https://bugs.launchpad.net/ubuntu/+bug/127915 ...what?
<ubotu> Launchpad bug 127915 in Ubuntu "c2f87d89633a6ea26a02b23d298543d" [Undecided,New] 
<pitti> Hobbsee: I think this is a hwdb identifier
<Hobbsee> pitti: i'd guess so, but why has the guy filed it in a bug, saying "no sound"?
* Hobbsee wonders about sending that as a support request
<pitti> maybe he really doesn't have no sound? :)
<Hobbsee> i realise that... :P
<Hobbsee> i'm just wondering how on earth the guy expects the sound to be fixed, just like that.
<Fujitsu> Does the hwdb data go anywhere but /dev/null at the moment?
<cjwatson> yes, it lands somewhere on rookery and we can do statistical analysis on it
<cjwatson> certainly not anywhere near as useful as it should be though
<cjwatson> no sound> cf. bug 123126 which I just happened to be looking at
<ubotu> Launchpad bug 123126 in linux-source-2.6.20 "After kernel update to 2.6.20-16 on Acer Extensa 4014 I lost sound" [Undecided,New]  https://launchpad.net/bugs/123126
<Hobbsee> oh fricking....
<Hobbsee> calc: what'd you do?
<elmo> mjg59: ping
<pitti> seb128: I grabbed the new libnet-dbus-perl from accepted, works great
<seb128> pitti: rock on ;)
* pitti uploads new dbus then
<Nafallo> pitti: hello :-)
<pitti> hello Nafallo
<Nafallo> pitti: might want to approve bacula in dapper-proposed :-)
* pitti waves to Keybuk 
* Keybuk waves to everyone
* desrt pokes Keybuk 
* ion_ waves to cosine
<Nafallo> hi Keybuk :-)
<Keybuk> http://people.ubuntu.com/~scott/theme.png
<Keybuk> err, reload that
<Hobbsee> heya Keybuk!
* Hobbsee pokes desrt 
<agoliveira> amitk: ping?
<amitk> agoliveira: pong
<agoliveira> amitk, Hi. I noticed that the kernel on tribe 3 uses a very old version of the asus-acpi module. Do you know why?
<agoliveira> amitk, delay that.
<agoliveira> Hold on
<agoliveira> amitk, My mistake. Actually, I wanted to use asus-laptop and not asus_acpi. It's ok, just that the asus-laptop, in my opinion, should be the default and not asus_acpi.
<amitk> agoliveira: if there is a good reason to switch, make a case and we shall do it.
<agoliveira> amitk, asus-laptop (http://acpi4asus.sourceforge.net/) is already in the kernel and is far more complete than the default asus_acpi.
<agoliveira> Without, I can't, for instance, switch to external monitors.
<agoliveira> or control some fancy leds that models like the G series have.
<agoliveira> but, of course, the external monitor problem is the worse.
<amitk> agliveira: any missing features that you know of in asus-laptop that are present in asus-acpi?
<agoliveira> amitk, none that I'm aware of. It don't see any problem removing it on my Asus G1 and replacing it by asus-laptop.
<zul_> agoliveira: is this the led thing?
<agoliveira> zul_, the leds work with the asus-laptop but the biggest problem is not being able to switch to an external monitor without it.
<zul_> agoliveira: its a usb quirk thing i think, i remember seeing it on the linux-usb-devel mailing list
<GyrosGeier> I use asus_acpi in Debian's 2.6.21, and I can switch just fine
<GyrosGeier> (A series laptop)
<agoliveira> zul_. BTW, I also already can control the OLED display as well. Me and a friend are writting a driver for it.
<GyrosGeier> it doesn't do any good because the native resolution couldn't be handled by anything I had ever connected.
<agoliveira> GyrosGeier: Right now I'm working with an external 20" LCD running at 1658x1024, the same native resolution od the notebook, LCD. I didn't have any problems at all with that.
<agoliveira> s/1658/1680
<GyrosGeier> agoliveira, cool
<agoliveira> sorry I meant 1680x1050
<GyrosGeier> the A series turns the LCD black if you use a non-widescreen resolution
<agoliveira> GyrosGeier: This external LCD is widescreen connected to DVI so I can't say.
<agoliveira> amitk, btw, is the patch to load a custom DSDT already in the gutsy kernel?
<amitk> agoliveira: the CVS version that supports 2.6.22 is far ahead of the in-kernel version
<amitk> agoliveira: yes.. I pushed it in yesterday
<pitti> meh, nautilus crashes all over the place since latest dist-upgrade today
<agoliveira> amitk: Weird... the cvs version shows 0.41 while the in-kernel shows 0.42...
<Hobbsee> pitti: you didnt really *want* nautilus, did you?
<pitti> Hobbsee: occasionally I even use it, just to get used to GUIs a bit more :)
<Hobbsee> haha
<Hobbsee> poor pitti, happy with his console.
<thom> consoles are the future. this GUI stuff will be seen as the fad it is!
<Hobbsee> :P
<Kmos> no console, no future :)
<Hobbsee> no question
<Kmos> bug 127931
<ubotu> Launchpad bug 127931 in f-spot "f-spot.exe crashed with SIGSEGV" [Undecided,New]  https://launchpad.net/bugs/127931
<Kmos> .exe? lol
<Hobbsee> just *only* consoles would get slightly dull though
<Hobbsee> Kmos: there are a fair few like that.
<StevenK> It's mono
<asisak> Kmos: .net has exe
<calc> Hobbsee: huh?
<Kmos> yeah.. mono is like ... (very bad word)
<Kmos> lol
<calc> Hobbsee: you asked what did i do?
<Hobbsee> calc: yes.  ooo is broken again.
<calc> Hobbsee: i didn't do anything at all
<Hobbsee> calc: doesnt start
<calc> Hobbsee: there hasn't been a new upload since last week
<calc> Hobbsee: so someone broke something else in that case
<Hobbsee> well, find them, and yell at them :)
<Hobbsee> (process:17234): GLib-GObject-CRITICAL **: /build/buildd/glib2.0-2.13.7/gobject/gtype.c:2242: initialization assertion failed, use IA__g_type_init() prior to this function
<Hobbsee> (process:17234): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed
<Hobbsee> (process:17234): Gdk-CRITICAL **: gdk_screen_get_font_options: assertion `GDK_IS_SCREEN (screen)' failed
<Hobbsee> is what i seem to get, from a console
<Kmos> http://arstechnica.com/news.ars/post/20070723-ars-at-ubuntu-live-mark-shuttleworths-keynote.html
<Hobbsee> and it sitting there with the splash screen
<Kmos> gtk is broken as seb128 said
<calc> Hobbsee: see what Kmos just said
<amitk> agoliveira: nevermind, the cvs is identical to the in-kernel version. I was looking under drivers/acpi. But it is under drivers/misc
<seb128> hum
<seb128> Kmos: did I say that?
<Kmos> seb128: didn't you?
<seb128> the error mentionned to Hobbsee is new to me
<Hobbsee> i thought he was talking about gtk being broken on sparc.
* asisak is sorry: oo.o works for me
<seb128> doesn't look like the same issue than the nautilus crasher
<seb128> there is a nautilus crasher
<Kmos> 12:41 <seb128> gtk+ didn't build on sparc due to a glib bug
<seb128> and a sparc build issue due to glib
<Kmos> only at sparc?
<Kmos> =)
<seb128> right, that's a build and installability issue
<asisak> yea, and this breaks a lot of packages that depend on glib
<asisak> (only on sparc)
<seb128> the error Hobbsee is mentionning is something else
<asisak> Hobbsee: how did you do this?
<Hobbsee> sarah@LongPointyStick:~$ ooffice -calc
<amitk> agoliveira: nevermind, the cvs is identical to the in-kernel version. I was looking under drivers/acpi. But it is under drivers/misc
* calc updates his desktop to current gutsy
<Hobbsee> someone else mentioned ooo not opening either, but i dont remember who
<agoliveira> amitk: Ah, so I'm not that crazy ;)
<seb128> Hobbsee: crashes the same way here
<Hobbsee> seb128: yay!  let's both blame calc then :P
<calc> there are new glib, gtk, glibc so maybe something will break :)
<asisak> calc works as well
<asisak> I mean oocalc
<asisak> :)
<agoliveira> amitk: You told me that the DSDT patch went to the kernel yesterday so it's 2.6.22-9?
<Hobbsee> calc: sure, but we'll blame you anyway.
<calc> whatever it is it is unlikely to be ooo's fault since it worked until seb updated glib/gtk
<seb128> Hobbsee: downgrading to GTK 2.11.5 make it work, I tend to blame GTK
<amitk> agoliveira: yes. Tribe 4 should have it
<Hobbsee> seb128: great.
<Hobbsee> seb128: seriously, just get rid of gtk...
* Hobbsee ducks
<agoliveira> amitk: So we are not getting a kernel update meanwhile?
<seb128> Hobbsee: what about getting ride of you? ;)
<StevenK> And go back to Athena?
<calc> yea for athena! :)
<seb128> s/ride/rid
<Hobbsee> seb128: i'm sure you wouldnt want to get rid of me...
<Kmos> seb128: hehe
<amitk> agoliveira: we might...
<Hobbsee> would you?
* StevenK murders calc.
<calc> and fvwm for window manager
<seb128> Hobbsee: no I wouldn't ;)
* seb128 hugs Hobbsee
<Hobbsee> oh good
* StevenK double-murders calc.
* Hobbsee hugs seb128 back :)
<Kmos> StevenK: that's a monster kill :D
<calc> heh
<Kmos> calc: not calling you a monster :-)
<Kmos> hehe
<StevenK> seb128: Who else would deal all of KDEs bugs, er, I mean features. :-P
<amitk> calc: you are spoilt. Nothing beats TWM
<StevenK> deal with, even
<calc> amitk: yuck
<agoliveira> amitk: hmmm... can you point me to (or send me) the patch? I will apply myself so. It's anoying having to manually switch to the external monitor manually everytime.
<Kmos> Get ride of kubuntu, like pat do with gnome for slackware :)
<Hobbsee>  /kb kmos
<amitk> agoliveira: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-gutsy.git;a=summary
<Kmos> Hobbsee: :P
<Riddell> !CoC | Kmos
<ubotu> Kmos: The Ubuntu Code of Conduct to which we ask all Ubuntu users to adhere can be found at http://www.ubuntu.com/community/conduct/
<StevenK> Kmos: I don't exactly trust a man whos idea of a package system is one that isn't.
<amitk> agoliveira: git clone git://kernel.ubuntu.com/ubuntu/ubuntu-gutsy.git should get you the latest kernel
<Hobbsee> Riddell: i think seb128 needs to be thrown out into the snow or something, next UDS.
<Kmos> Riddell: i'm just kidding
<calc> StevenK: it worked well in 1995 when heavy package systems would have killed systems
* TheMuso shudders... Slackware....
<agoliveira> amitk: Thanks
<elmo> Riddell: the CoC is not a stick to beat anyone with who expresses any negative view on kubuntu, please stop using it as such
<calc> StevenK: trying to use dpkg/dselect on a pentium 90 with 16mb of ram is not pretty
<Kmos> calc: oh my god
<StevenK> calc: It's useable, just slow. rpm is much worse
* calc used slackware 2.2
<calc> StevenK: i'm not sure that statement is actually true, iirc it swapped like hell even ~ 5 years ago the last time i tried it on my old box
<calc> i think it used a multiple of 16mb at the time, not sure how it has been tuned since then
<calc> but it definitely wasn't a pretty sight
<calc> Kmos: i started out with slackware 2.2 and linux 1.2.4 (from what i recall) debian was around then but i didn't notice it on my infomagic cd's at the time
* Hobbsee wishes the powers that be in ubuntu made the fact that backports is not supported significantly clearer
<agoliveira> amitk: BTW, one more thing, the current kernel wrongly attaches an USB device present in some Asus notebooks (id 0b05:1726) to usbhid. Actually, there is no kernel driver for it. What can I do to help fix this?
<Kmos> calc: i started with rh8..
<Kmos> never tried slack
<ScottK> Hobbsee: Is there an issue that needs dealing with?
<Kmos> after rh, i used ubuntu until now.. and i don't think in change
<calc> Kmos: not much point to try slackware by that point
<StevenK> Hobbsee: We need backports-manager like restricted-manager!
<amitk> agoliveira: file a bug
<Hobbsee> ScottK: just the amount of crack that goes thru, and the bugs
<Kmos> i like to read slack changelogs :D are funny..
<Kmos> lol
<calc> Kmos: i have the old original redhat release with rpp files, heh
<zul> agoliveira: i have a fix for that in my git tree already
<Kmos> calc: that's for museum
<Kmos> :)
<Kmos> lol
<agoliveira> amitk: I was about to :) I was wondering about what kind of information one might need.
<calc> Kmos: yep
<agoliveira> zul: Cool
<ScottK> Hobbsee: OK.  If it was a specific bug, I might look into it.  I'll note for the record that (AFAIK) none of my backports have been particularly crackish.
<StevenK> calc: Surely that disc has started fossilising?
<Kmos> hehe
<calc> Hobbsee: another data point, ooffice -calc works for me after updating gutsy
<amitk> zul: is a quirk fix?
<zul> agoliveira: but please file a bug first
<zul> amitk: yes
<StevenK> Wanting to fix clamav is fairly crack worthy. :-P
<calc> Hobbsee: i haven't restarted gnome but it still works right now anyway
<Kmos> back later guys.. nice work :)
<calc> StevenK: heh probably so
<Hobbsee> ScottK: havent seen anything specific in the past few days
<Hobbsee> just a bug that came in reminded me
<ScottK> OK.
<amitk> agoliveira: just the output of 'lsusb' and pointer to specific device
<Hobbsee> calc: right
<agoliveira> amitk: Ok, will do it.
<agoliveira> Thanks
<TheMuso> c/
<TheMuso> ugh kvm
<calc> Hobbsee: after restarting gnome it still works, interesting bug
<calc> gar!
<calc> metacity lost its snap to window feature?
<calc> now it only can snap to borders of the desktop
<calc> seb128: any idea about that issue?
<StevenK> calc: It isn't using compiz?
<seb128> calc: you are using compiz, aren't you?
<calc> StevenK: it appears my system is using metacity still
<seb128> so no, no idea
<seb128> metacity didn't change recently
<calc> hmm odd then
<seb128> it works fine for me and nobody else mentioned it
<amitk> zul: are you planning to request a pull with other stuff soon?
<calc> maybe i should clean my dotdirs out
<zul> amitk: yes tomororw morning
<calc> seb128: it appears its somewhat more narrow bug, i can't snap a window to a window below it on the screen
<seb128> calc: metacity doesn't do snapping though, only edge resistancy
<amitk> zul: cool. Then it will go in for the next release
<calc> i mean the shift+click
<calc> i mean the shift+click
<zul> amitk: yeppers
<calc> er
<calc> gar my enter keeps getting in the way
<calc> i mean the shift+click+drag
<seb128> ah, still work fine for me
<calc> i have two gnome terminal windows on my desktop
<calc> one in upper left and one in lower left
<calc> if i try to drag the top one down it obscures the bottom one
<calc> but if i drag the bottom one up it snaps to properly
<calc> but it compiz is what should be used i can try to determine why its not on my box
<seb128> compiz is used on new installations only
<calc> when dragging the bottom one down it snaps all the way to the bottom bar in gnome not to the top of the other terminal
<seb128> otherwise you have to enable it in the appearance dialog
<calc> it doesn't work
<calc> errors out
<calc> i'm on nvidia binary driver
<calc> is that a known issue?
<agoliveira> zul, amitk, done. Let me know if you need anything else. BTW, I have userland code that actually drives this OLED display. If you want to make it a kernel driver, let me know.
<seb128> calc: nv or nvidia?
<seb128> ah, binary
<seb128> should work I think
<seb128> mvo_ knows better
<mvo_> calc: can you please put the content of .xsession-errors to a pastebin?
<Hobbsee> mvo_!
<mvo_> hey Hobbsee
<Kano> hi, when will be amd64 current fixed?
<Kano> sudo -i, id does not work
<Hobbsee> "when it's fixed"
<Hobbsee> Kano: bug number?
<Mithrandir> Kano: works fine for me
<Kano> Mithrandir: kubuntu amd64 current not
<pitti> Kano: what does it do for you?
<Kano> segfault
<pitti> $ sudo -i
<pitti> root@donald:~# id
<pitti> uid=0(root) gid=0(root) Gruppen=0(root)
<Mithrandir> Kano: there's no difference between those for ubuntu and kubuntu.
<pitti> Kano: oh, wait
<sbalneav> Hey all, currently looking at squashing Bug #107518.  What would be a "good" way to determine if a given filesystem is "dirty"?
<ubotu> Launchpad bug 107518 in ltspfs "auto filesystem mounting can cause hideous data loss" [Medium,Confirmed]  https://launchpad.net/bugs/107518
<pitti> Kano: does 'id' segfault as normal user, too?
<Kano> id -> Illegal instruction -> core dump
<Kano> yes
<Riddell> Kano: does the md5sum match that in the package?
<pitti> Kano: on the last live CD we had file system corruption which often affected /usr/bin/id
<Kano> Riddell: of course
<pitti> $ md5sum /usr/bin/id
<pitti> b95e1a28e650a12f2d0ec9dd34aab6ab  /usr/bin/id
<pitti> Kano: ^ for you?
<Kano> c1...
<pitti> Kano: I heard many people for whom /usr/bin/id was a fragment of XML, or an MPEG or such stuff
<pitti> Kano: please try 'apt-get install --reinstall coreutils' (from the network source)
<pitti> Kano: just FYI, it's most likely bug 126964
<ubotu> Launchpad bug 126964 in linux-source-2.6.22 "gutsy livefs causes random hangs or modprobe crashes" [Critical,New]  https://launchpad.net/bugs/126964
<Kano> hmm that worked
<pitti> oh, thanks for verifying
<Kano> how about switching to aufs
<pitti> Kano: pkl already fixed the bug, when we'll get a new kernel upload it should be history
<Kano> how to add 2 little id patches to next kernel?
<Kano> i dislike to patch is every time
<pitti> Kano: 'every time'?
<Kano> i have a script to recompile it for etch, but maybe i would base new kanotix directly on gutsy.
<Kano> and i NEED those patches
<Kano> http://kanotix.com/files/kernel/kernel-update-pack/source/
<Kano> the 2 patches
<Kano> very small, just adding ids
<pitti> Kano: looks sensible; please file them as bugs against linux-source-2.6.20
<Kano> the via patch is for the intel via ids of the well known via southbridge bug
<Kano> the other supports the card within the name of the patch
<Kano> patches are for .22 too
<Kano> is it known that the textmode has no german layout only kde when booted with language option
<Riddell> Kano: it's not clear what you mean
<Riddell> Kano: are you saying linux console is in US keyboard layout while X is using german?
<Kano> when you press ctrl-alt-f1
* pitti sighs about yet another automatix-inflicted breakate
<pitti> s/te$/ge/
<Kano> i use live cds for testing my gfx install scripts
<seb128> we should find a way to ban the automatix use ;)
<Nafallo> seb128: please do :-)
<Kano> of course i know us keyboard layout,but i would prefer german as my keyboard is german...
<Mithrandir> seb128: make update-manager and synaptic refuse to touch the system if automatix has ever been installed.
<Mithrandir> or libc fail to install
<Hobbsee> Mithrandir: that's already the plan, isnt it?
<Nafallo> Mithrandir: that would break Jennys box ;-)
<pitti> Mithrandir: I think I should disable apport reports if automatix is in apt sources
<pitti> (I'm serious)
<Nafallo> Mithrandir: but then I think I cleaned out the whole damn mess...
<pitti> it just creates clutter
<Hobbsee> pitti: so's Mithrandir :)
<Hobbsee> pitti: cant see why you arent alraedy, tbh
<Mithrandir> Nafallo: *shrug*; reinstall then.  Or edit the dpkg status file.
<pitti> can someone tell me how to detect it?
<pitti> it's just grep -v on apt sources, I figure?
<Mithrandir> pitti: if dpkg -s automatix shows it?
<Kano> who can show me how these kubuntu current images are built?
<pitti> Mithrandir: ah, there's a proper package? last time I saw it I thought it boiled down to an apt source
<Kano> the live ones
<Mithrandir> pitti: I think it's a proper package now, yes.
<Hobbsee> pitti: you could check the status file too, to see if it was ever installed.
<Nafallo> Mithrandir: I extracted the damn sources through the deb since upstream refused to give me the source in a easier way and read through to be able to revert what it did :-P
<pitti> Mithrandir: great use case for my 'general package hooks' :)
<Mithrandir> pitti: haha. :-)
<pitti> actually designed for apparmor, but would be great for automatix as well
<Kano> btw. i have even more sugestions.... if you like i write em in a textfile
<pitti> Kano: https://help.ubuntu.com/community/LiveCDCustomization
<Kano> my questions is not about modifing, it is to build from scatch
<Kano> i want a clean build
<pitti> "  Michael Dell, Founder and CEO of Dell Inc., uses Automatix2 on his home computer"
* pitti boggles
<Nafallo> pitti: can't you reinstall Ubuntu automagically upon detection? ;-)
<Kano> is there any possiblity to get newer fuse-utils than in sid
<evand> hilarity: http://www.getautomatix.com/wiki/index.php?title=FAQ#Does_Automatix2_break_Ubuntu_upgrades.3F
<Kano> 2.6.5 is faulty
<Kano> 2.7.0 is ok
<Kano> when used with uuids in fstab for ntfs-3g
<pitti> http://www.getautomatix.com/wiki/index.php?title=Installation -> ah, so that package is automatix2 now; I guess I'll check for both
<Kano> i heard that fuse 2.7.x will not enter sid until the other is in lenny, that can take ages
* Hobbsee wonders when the tech board will actually make a statement about automatix.
<pitti> Kano: we can update it in Ubuntu only, if it's important
<stdin> heh "Ubuntu has been notorious for breaking xserver packages several times" <- once != several times
<pitti> Hobbsee: in what way?
<Kano> well i use it a while for my with etch backports, works fine
<pitti> Kano: you should coordinate that with ogra, though, since he's our heaviest fuse user
<Kano> i am a heavy ntfs-3g user ;)
<Kano> speed is really nice
<pitti> Kano: right
<pitti> Kano: I meant, ogra needs it for ltsp and such
<Hobbsee> pitti: about whether it's good or not
<pitti> Kano: maybe you can send him some test packages, and if they work for ltsp, we'll upload it?
<Kano> i would prefer that kde could use it
<Kano> my packages are too simple, just exchanged 2.65 with 2.70, not worth to think about... maybe you want other changes?
<sbalneav> I'd have to check and see if the newer fuse works with the ltsp stuff, but I have no objection to moving forward.
<Riddell> Kano: where did you set the keyboard layout?
<sbalneav> I'm upstream for the ltsp side of things so if something needs to be done for a newer fuse, it's easy.
<pitti> Kano: right, it's mainly to get it verified with the ltsp guys that 2.7 doesn't break anything (or get the necessary fixes into ltsp)
<pitti> hey sbalneav
<sbalneav> Hey pitti!
<Kano> Riddell: well on feisty i think it worked. used the language selection
<pitti> Kano: we are still well before upstream version freeze, so getting it in now is no problem
<Kano> http://kanotix.com/files/thorhammer/updates/
<evand> We should really document the cases where automatix breaks the world and put them somewhere centralized so we can point to it when they start spreading FUD again
<Kano> these are mainly newer packages than in sid
<Kano> maybe except the discover-data, this is a bit specific
<ScottK> evand: I'd say pointing to the line where it sigkills dpgk should be sufficient evidence (with a proper explanation) of why it should not be used.
<Kano> not that many packages
<Hobbsee> evand: ScottK stick the source package somewhere, etc.
<Hobbsee> including the part about the sigkill of dpkg
<ScottK> evand: You don't actually need a source package (and they don't provide it) you can just unpack the .deb.
<Kano> 915res has one added id for intel g33 (needed for vesa basically only but it worked...)
<Nafallo> ScottK: I tried to ask them why they didn't provide that :-)
<Hobbsee> ScottK: evand but they would just whinge about how that's defamation, etc, most likely, and that the ubuntu devs dont try to work with them
<Nafallo> ScottK: apperently it's to hard for them to dput _source.changes to their archive ;-)
<Hobbsee> actually, that X thing probably relates to people who install the binary drivers via automatix, which then get hosed every kernel update
<Kano> Riddell: did you patch your k3b also with the old code for verify? i added it to my package
<ScottK> jdong had said something about talking to them a while ago.
<ScottK> jdong: Did you get anywhere with that?
<jdong> ScottK: no, it stalled after a forum council meeting
<evand> Hobbsee: we could also document past attempts of trying to encourage them to create a team that tests the upgrade path using automatix, if need be
<Riddell> Kano: I'm not sure, I've lost track of k3b patches since other people seem to be maintaining it.  you can check with apt-get source k3b
<Hobbsee> ScottK: he likely got very abused, etc, about how all the MOTUs are crap, etc
<jdong> ScottK: and to be honest I don't think it's going to go anywhere.... :(
<Hobbsee> evand: they wont listen.
<jdong> ScottK: we're getting walked all over by Arnav at the forums.
<elkbuntu> Nafallo, for a brief time they even had a compiled python file or something in their package
<Hobbsee> evand: you'd have to go purely by technical merit, or lack of it
<Kano> Riddell: from changelog i dont think so. i extracted the needed patches from websvn
<cjwatson> Kano: the livecd-rootfs package is used to build the live filesystem
<Hobbsee> evand: hell, they dont even seem to care that they're installing binaries which they cant see the source for
<Kano> cjwatson: thanks
<Riddell> Kano: oh if it's in upstream we'll get it when we package 1.0.3
<Kano> maybe add it... otherwise cd is ejected but not verified
<cjwatson> Kano: was your console keyboard layout issue with feisty or gutsy? (there were two known relevant bugs in feisty)
<Kano> yes it is in upstream. but do you like to wait for 1.0.3 ;)
<Kano> gutsy
<cjwatson> interesting
<Kano> i am testing currently only
* cjwatson tries with an Ubuntu live CD image
<ScottK> jdong: As we discussed before, if they would respect the packaging system, then I don't think we'd say bad things.
<ScottK> jdong: And feel free to tell them you're welcome for fixing the clamav bug they whined about on their web page with no help from them.
<Kano> cjwatson: i want more features in live mode, like possible execution of scripts, more cheatcodes and such things
<cjwatson> there's a bug on casper about providing more hooks; feel free to file additional bugs for specific items
<Kano> i think gutsy could get pretty good when those little things are fixed
<elkbuntu> dear nautilus. please stop restarting, it is awfully counterproductive. love elky
<cjwatson> wow, this live CD is buggered
<cjwatson> booting in vmware, and all commands hang
<Kano> how is packaging the avm drivers?
<pitti>     if apport.packaging.get_version('automatix') or \
<pitti>         apport.packaging.get_version('automatix2'):
<pitti>         report['UnsupportableReason']  = 'You have installed automatix on your \
<pitti> system. This is known to cause a lot of instability, thus problem reports \
<pitti> will not be sent to the Ubuntu developers.'
<elkbuntu> cjwatson, do file /var/usr/id
<pitti> Hobbsee: that should teach them :)
<Kano> have got ideas for those too
<coNP> elkbuntu: did you get seb128's update?
<elkbuntu> errr... /var/lib/id
<cjwatson> elkbuntu: YM /usr/bin/id? (won't help as no external commands return)
<elkbuntu> coNP, dunno
<Hobbsee> pitti: i'd let them file it direct to the automatix bugtracker :P
<pitti> cjwatson: did you try pkl_'s test CD?
<seb128> I doubt it has built yet
<seb128> use the spatial mode as a workaround :p
<elkbuntu> cjwatson, yeah. im muddled tonight. it's a damn mpeg last i checked a livecd :
<Hobbsee> pitti: and you should also mentoin that said instability does not occur on an ubuntu system
<cjwatson> pitti: no. did the bug in question affect vmware?
<coNP> why I only can get source 0ubuntu1.dsc?
<pitti> cjwatson: I never observed it in vmware, but there's no specific reason why it should not affect it
<elkbuntu> nautilus needs to un-break so i can string paths together
<seb128> elkbuntu: use spatial for an hour
<cjwatson> ah, there we go, happier on a second boot
<cjwatson> Kano: as I thought, running 'sudo setupcon' after boot fixes the console layout
<cjwatson> very weird, I was sure I'd fixed that damn bug
<Kano> cjwatson: fine, please start it by default
<Kano> but why are umlauts in white and the rest is light gray?
<cjwatson> Kano: it *is* started. it's a bug that reverts it later.
<cjwatson> if it were that easy it'd be fixed already :P
<cjwatson> I'm looking at it
<Kano> i build live cds since a few years, i know some things about em ;)
<cjwatson> but not about console-setup, apparently ;-)
<cjwatson> it has some messy initramfs interactions
<cjwatson> should have a massive "you are not expected to understand this" sign above it
<cjwatson> ah, could just be that the keyboard layout isn't munged early enough
<cjwatson> this'll be messy
<cjwatson> the basic problem is that you cannot reliably set the keymap once usplash has started; and you can't really do it reliably after it finishes either because X is about to snarf the console
<cjwatson> so you have to set it really really early
<Kano> cjwatson: there most be something else wrong, pos1, end does not work
<elkbuntu> coNP, as for your question, it seems that no, i do not have the nautilus update, or if i do, it didnt work for me
<Kano> cjwatson: livecd-rootfs has an example but the build-$s-live dirs are missing
<Kano> the example is pretty useless without
<gnomefreak> spatial mode is default for nautilus isnt it?
<gnomefreak> if so using spatial mode is closing unexpectedly, how can that be used as a workaround
<seb128> gnomefreak: no, not in Ubuntu
<seb128> gnomefreak: spatial is the mode without decoration, path bar, sidebar
<gnomefreak> ah i went to help and it said it was ok ill see if i can chage it
<cjwatson> Kano: they're just standard debootstrapped chroots with the livecd-rootfs package installed, AFAIK
<seb128> go to preferences and unset the "always use browser windows"
<gnomefreak> ah ok ty
<seb128> or whatever it's called in english ;)
<cjwatson> Kano: "pos1" == home key?
<Kano> cjwatson: yes
<cjwatson> Kano: likely all part of the same bug
<Kano> i think so
<Kano> but i executed your command
<cjwatson> ah
<cjwatson> well, home works for me
<Kano> cjwatson: why is the ramdrive fixed to 1 gb?
<cjwatson> Kano: it's not; it's the kernel default of half your memory size
<Kano> hmm
<zul> someone mention my name?
<Hobbsee> zul: the arrest warrant.
<zul> wohoo..
<wwoods> pitti: ping
<pitti> hey wwoods
<wwoods> pitti: so we're sending some patches upstream that change coredump-to-pipe behavior to work like it does in your kernel
<pitti> wwoods: oh, with the environment variables or with fixed macro handling?
<wwoods> see http://lkml.org/lkml/2007/7/19/521 and http://lkml.org/lkml/2007/7/22/128
<pitti> wwoods: awesome, thanks a lot!
<cjwatson> Kano: ok, so I think I have a horrible hack which will fix the default keymap. at least sometimes.
<wwoods> those two patches ignore coredump rlim for pipes
<cjwatson> can't guarantee the font will be right mind you, but it's correct for German at least
<wwoods> the patch to handle argv[]  for core_pattern is coming later this week
<wwoods> and there's a new format specifier - %c - which expands to the actual core rlim
<wwoods> so probably we'll call apport with --real-rlim %c
<wwoods> get everything else from the headers.. and bob's yer uncle
<Kano> cjwatson: will livecd.sh use it?
<pitti> wwoods: ah, right
<pitti> wwoods: too bad that the macro patch is still necessary then, just for %c
<mathiaz> pitti: I've been working on bug 121441
<ubotu> Launchpad bug 121441 in mysql-dfsg-5.0 "Mysql man pages are non-free" [Unknown,Fix released]  https://launchpad.net/bugs/121441
<mathiaz> pitti: and created a mysql-doc package.
<cjwatson> Kano: what's livecd.sh got to do with it? it's in caspe
<cjwatson> r
<pitti> wwoods: but I figure it would be convenient to have macros work properly for other usages of pipe-in-core_pattern
<mathiaz> pitti: should I upload it to revu ?
<wwoods> pitti: it's the Right Thing To Do anyway
<pitti> mathiaz: hi
<wwoods> so yeah
<Kano> cjwatson: sure, but is it in the repository
<wwoods> it's not the simplest patch, but it's the most correct/useful
<pitti> mathiaz: I don't have a revu account yet, I prefer direct feedback, but if you want to use revu, go ahead
<Kano> i think it works with a chroot envrionment
<pitti> wwoods: I agree
<wwoods> anyway your patch will still work but I'll probably be patching apport in my branch for that
<cjwatson> Kano: I don't understand your question?
<cjwatson> is what in the repository?
<Kano> well is it already in the repository your modified casper version
<wwoods> oh - I've also got the beginnings of a turbogears-based crashdb in my branch, but I don't think we'll use that for the initial fedora release
<mathiaz> pitti: well. I think it should go in restricted - so I'm not sure if revu is the best place to upload
<mathiaz> pitti: I can upload it to p.u.c
<cjwatson> Kano: no, I haven't quite uploaded it yet, but will do
<mathiaz> pitti: and you can have a look at it ?
<Kano> otherwise the created live cds would not use it
<pitti> mathiaz: WFM
<cjwatson> Kano: yes yes I know how to drive the Ubuntu live CD creation process
<mathiaz> pitti: ok. I'll do this then. Thks.
<cjwatson> I wrote fair chunks of it ;)
<pitti> wwoods: once this is adopted upstream, I'm sure that we will replace our patches with upstream's
<pitti> wwoods: and I'll just change apport trunk to work with it
<pitti> wwoods: I see no need to support more than one method
<pitti> wwoods: and your ELF extraction code is really nifty!
<Kano> basically the package selection seems pretty easy in that file...
<wwoods> pitti: cool! yeah, I agree, except for having older branches that support older kernels
<wwoods> not sure which linus kernel this will make it into but I'll keep you posted
<wwoods> I think it's going into andrew morton's tree?
<pitti> wwoods: as it is in trunk right now, it should automatically read from ELF if CORE_SIGNAL etc. is not specified
<Kano> i think i can change it to my needs...
<pitti> wwoods: I shuold really revive preloadlib/ and make it behave like the change you propose, then we have the test suite and can fix it in advance
<pitti> wwoods: oh, I think we'll pull it as soon as it lands in upstream git
<wwoods> pitti: right, I saw that, good stuff
<wwoods> preloadlib/ ?
<pitti> wwoods: it's a small LD_PRELOAD library that simulates the kernel behaviour
<pitti> wwoods: when I wrote the very first line of apport I used this as a very first means to intercept crashes at all
<pitti> wwoods: just look at it, it installs a signal handler and calls apport with the same environment than the kernel would
<Kano> cjwatson: what was tocd?
<pitti> wwoods: later I used it to create a reference implementation of the new environment var passing approach, so that I could write the tests and apport implementation without waiting for the kernel implementation
<wwoods> ahhh
<cjwatson> Kano: http://www.theopencd.org/
<cjwatson> we did a live CD component for that for a while
<pitti> wwoods: if you stop apport (i. e. standard core_pattern), './test-apport lib' will use this
<Kano> i see your code, maybe i adopt that for kanotix...
<Kano> looks easy to add new packages that way
<Kano> but i see nothing that would be like a sortlist
<Kano> ok i see it... you fetch em from the web
<Kano> but as usual every url is down
<pitti> back in 15 minutes
* calc back
<calc> yea i'll clean out .xsession-errors and restart
<calc> seb128: nvidia
<calc> mvo__: a clean xsession-errors is 4.6KB
<cjwatson> Kano: ok, casper uploaded with keymap fix, give it a few hours to build and publish and stuff
<calc> mvo__: its mostly evolution alarm stuff though
<mvo__> calc: it should contain something from compiz as well, please send me the log
<calc> mvo: oh i see you want to compiz error part, i'll do a clean compiz xsession-error log then
<calc> s/to/the/
<mvo> calc: thanks
<calc> brb
<calc> mvo: interesting i see the issue, will put it on pastebin though
<calc> mvo: http://pastebin.com/de07cbb2
<mvo> calc: that is interessting, do you use a dual-head setup?
<calc> yes
<calc> two 23" 1920x1200 displays
<mvo> impressive
<calc> gears seems to work accelerated (i think) > 900fps anyway
<calc> unless that is normal for no hw accel
<calc> so does randr not work for dual head or something else is wrong?
<desrt> randr works rather well for dual-head...
<desrt> it's the mechanism by which  multiple heads are supported :p
<mvo> calc: could you please put you /var/log/Xorg.0.log somewhere?
<calc> desrt: you sure you aren't confused with xinerama? :)
<calc> mvo: ok
<mvo> calc: you do not do anything fancy like "    Option	"RandR" "off"	in ServerFlags ;) ?
<calc> i don't recall doing that
<calc> i'll put both of the files on a server and look at them as well
<mvo> calc: thanks
<calc> http://cheney.ws/debug/
<calc> the config might look a bit strange because i was using info from a nvidia example to setup dual head
<calc> i might need to do enable some other things as well (maybe?)
<calc> mvo: see above ^
<mvo> calc: thanks, I guess "xdpyinfo | grep RANDR" is empty for you?
<calc> mvo: yes
<mvo> calc: that seems to be what compiz is complainging about, but it is strange given that you explicitely enable RandR in your server flags
<calc> mvo: i think that was some fragment from nvidia driver configurator
<calc> mvo: should i remove some of that stuff and add others?
<mvo> calc: libxrandr2 is installed and up-to-date?
<calc> yes 2:1.2.1-1
<mvo> eh... could you please try disabling xinerama ?
<calc> ok, brb
<mvo> calc: sorry, but those seem to be incompatible these days
<calc> mvo: so the default window manager doesn't work with dual head?
<manchicken_> Is anybody following the new issues with OO.o in gutsy?
<manchicken_> ca
<calc> mvo: or just not on nvidia?
<manchicken_> calc: I hear you're the person to talk to ping on this.
<calc> manchicken_: which issue is it?
<calc> manchicken_: from what i hear someone broke something in gtk recently, but i can't reproduce the issue locally
<manchicken_> calc: ooo, with any program, when I start it I get nothing but a splash screen and a maxed out CPU.
<calc> manchicken_: thats probably the broken "gtk" issue but i am not certain since i can't reproduce it here
<manchicken_> Okay... there's a new version of GTK that I believe just came out, too.
<calc> manchicken_: yes which is what broke ooo
<calc> manchicken_: at least from what i have been told by other people
<manchicken_> Naw, there's one that came out after that, too.
<calc> oh interesting
* calc tries to update again so he can break his ooo
<manchicken_> It was broke, so I tried an update, which brought libgtk2.0-0 (2.11.6-1ubuntu1) on here.
<mvo> calc: just not with xinerama
<manchicken_> It's still broken after that update.
<manchicken_> calc: I wonder if it was one of the many gcj updates.
<calc> mvo: is there a way to do dual head without duplication of gnome bars without xinerama?
<calc> mvo: after turning off xinerama i still have dual head working but i have two application and task bars
<calc> mvo: oh nm i have them but i can't get to the other head at all from what i can tell
<calc> mvo: it seems once i started up compiz i can't get to the other head
<calc> mvo: at least by dragging apps over there anyway
<Kano> cjwatson: what tool do you use to create the iso?
<calc> and compiz snap to feature doesn't seem to work or is different from metacity
<Kano> the rootfs is created
* calc disables compiz, yuck
<cjwatson> Kano: http://people.ubuntu.com/~cjwatson/bzr/cdimage/mainline/ plus checkouts of the bits mentioned in configs/devel once you've checked that out
<calc> i don't need eye candy, i just need a working system, seems compiz isn't nearly ready for use for dual head
<cjwatson> (http://people.ubuntu.com/~cjwatson/update-config may help)
<mvo> calc: but compiz works now on both heads?
<cjwatson> it's a bit all over the place because it's grown from code that just built the alternate ISO
<calc> mvo: not sure i couldn't easily get to the second head it was completely separate
<calc> mvo: i can try again if needed
<mvo> calc: you should be able to a single desktop with randr1.2, but I don't know if nvidia supports this yet
<calc> mvo: no it doesn't work
<calc> mvo: without xinerama the second head has no window manager at all
<calc> mvo: and trying to enable it on it has crashed compiz entirely
<calc> mvo: so no compiz on either head right now
<geser> pitti: Hi, can you give-back linuxdcpp, ardour, aqsis?
<calc> mvo: in fact no window manager at all it didn't fall back to anything either (not sure if it should have)
<calc> i still have the compiz effects but no window manager
<calc> mvo: i think i am getting compiz effects on both heads
<pitti> re
<Amaranth> calc: then you have a WM
<Amaranth> calc: that would mean you have no decorator
<calc> mvo: disabled and reenabled got the decorator on the primary head but not secondary
<Kano> cjwatson: is it a mod of live-package?
<calc> Amaranth: ah sorry about that, yes i have no decorator
<Amaranth> calc: multiscreen?
<calc> Amaranth: yes
<calc> Amaranth: mvo and I are looking into compiz dual head issue on my box
<Amaranth> not regular dual head, multiscreen is something different
<calc> Amaranth: it apparently dislikes xinerama and without it does weird stuff
<cjwatson> Kano: no
<cjwatson> Kano: live-package postdates the stuff we did
<pitti> geser: done
<Amaranth> calc: can you move windows between the monitors?
* calc managed to get his snap down working again in metacity though :)
<calc> Amaranth: not with xinerama disabled
<Amaranth> so you're using multiscreen
<Amaranth> you need to start a decorator on the second screen
<calc> Amaranth: yes, that is what mvo requested
<Amaranth> open a terminal over there or something and run gtk-window-decorator from it
<Amaranth> you have two panels, two desktops, etc, right?
<calc> Amaranth: i'm just testing out things for mvo, i have no desire to use multiscreen past just testing
<mvo> Amaranth: it all started to figure what the problem is. and it seems the problem is xinerama , with it, compiz does not want to start (no RandR anymore)
<Amaranth> mvo: right
<iwj> doko: oo.o 2.2.1 seems to need more than 1GB of RAM to build.  I think this is a bug.  Do you agree ?
<Amaranth> don't use xinerama, randr handles this stuff now
<calc> so why doesn't RandR support Xinerama yet?
<calc> Amaranth: how do i get non multiscreen multi head?
<Amaranth> randr has it's own xinerama-like hints for the WM
<mvo> Amaranth: can nvidia do randr1.2 yet?
<doko> iwj: amd64?
<Amaranth> i dunno, actually
<iwj> doko: t
<calc> lol
<Amaranth> i don't have two monitors
<iwj> doko: g++ -Wreturn-type -fmessage......tables.cxx // virtual memory exhausted: Cannot allocate memory
<doko> iwj: that might be the gij prblem
<doko> ohh
* calc notes multihead isn't that uncommon so would be nice to just work
<calc> every place i have worked in the past several years has had multihead for all developers
<doko> iwj: I never used less than 2gb
<Amaranth> calc: tell nvidia to fix their crappy drivers :)
<calc> Amaranth: RandR 1.2 is like 5 months old at most
<iwj> doko: But is it a bug if you can't build it in 1 ?
<calc> Amaranth: its a case of linux changing fast more than a nvidia issue
<iwj> What is textenc/tables.cxx anyway ?
<doko> iwj: please ask our OOo maintainer ;-P
<doko> he's listening ;)
<Amaranth> calc: except randr 1.2 was designed with input from nvidia
<calc> Amaranth: nvidia might support it already but if they do no one knows how to set it up since randr 1.2 is brand new
<Amaranth> they knew it was coming for over a year before it came out
<calc> Amaranth: oh LOL
<Amaranth> calc: i dunno, i think there are a couple GUIs floating around that do randr stuff for you
<Amaranth> actually i thought mvo was working on one
<iwj> calc: Are you ? :-)
<mvo> Amaranth: *cough* ... time ... *cough*
<Amaranth> hehe
<calc> iwj: scrolling up, i was talking about randr issues
<iwj> Sorry to interrupt ...
<Kano> cjwatson: update-config takes ages for debian-cd 1/4. is that normal?
<cjwatson> calc: ooo should probably take priority, though ;-)
<cjwatson> Kano: it's just calling bzr *shrug*
<iwj> cjwatson: This a build failure in test.
<iwj> But I suspect that if it's running out of RAM in g++ when given 1Gb on some file called `tables' it's possible that a small change might make the builds go much faster ...
<calc> cjwatson: sorry i was reading my highlighting so didn't even notice iwj question until he mentioned my nick
<Kano> cjwatson: i would say just the last package build in a repo would be more easy, but ok...
<cjwatson> Kano: not my problem, take it up with the bzr people
* calc looks for the file in question
<cjwatson> Kano: I don't really care anyway, it's just slow for initial checkout over http
<iwj> calc: Full log at http://autopkgtest.ubuntu.com/autopkgtest-output/gutsy/openoffice.org/
<Kano> i thought ubuntu server are faster. at least the one with the isoimages was
<cjwatson> Kano: bzr-over-http isn't all that quick sometimes
<Amaranth> calc: https://launchpad.net/urandr
<cjwatson> Kano: (also if you think about it you might come to the conclusion that cdimage/releases.ubuntu.com receives ever-so-slightly more resources than people.ubuntu.com)
<Kano> cjwatson: maybe suggest a higher bandwidth *g*
<cjwatson> Kano: I don't care and I don't think you should either. it's initial checkout only. please stop bugging me about it.
<Kano> ok
<calc> iwj: i may be looking the wrong area of log but it looks like it is working on java files when it runs out of memory there
<calc> iwj: am i looking in the wrong file?
<iwj> calc: Err, the log in the URL I just gave you and the log in my email do not correspond at all.
<iwj> calc: Let me try to figure out what's going on.
<calc> iwj: fun stuff, let me know when you have it sorted
<iwj> OK, the log in the email is just out of date and the java problem is current.
<calc> ok
<iwj> The log in my email is from when it had only 256Mb.
<iwj> Sorry to bother you.
<calc> iwj: oh ok no problem
<calc> iwj: doko mentioned something about gij having memory issues which might be what is showing up in this log
<iwj> Yes.
<iwj> I've discussed that with doko already.
<calc> ok
<calc> iwj: what is autopkgtest btw?
<iwj> Automatic testing thing.
<iwj> Err, duh.
<iwj> It can run tests you put in your source package.
<calc> Amaranth: that page has a dead link to the software
<calc> iwj: oh ok :)
<iwj> Also, it has the ability to build things (since tests might need a built tree).
<iwj> And when the builds fail it mails me.
<Amaranth> calc: that page has a link to a bzr branch hosted on launchpad
<calc> Amaranth: ah
<calc> btw ooo 2.2.1 should build in 1gb physical ram
<calc> i have done that on my laptop many times
<Kano> cjwatson: bzr-builddeb does not work with bzr 0.18?
<cjwatson> Kano: I have no idea
* cjwatson <- not a bzr developer nor a bzr-builddeb developer
<Kano> well depends are that way
<iwj> IWBNI the timeout on this IRC server were a bit longer than 0.000000001 nanoseconds.
<cjwatson> Kano: file a bug
<Amaranth> is bazaar.launchpad.net down or am i just having weird problems?
<calc> http://us.download.nvidia.com/XFree86/Linux-x86/100.14.11/README/chapter-14.html
<calc> mvo: ^
<calc> mvo: so its a lack of randr not glx that is the issue?
<calc> maybe i need to use twinview to get it all working
<cjwatson> iwj: FYI I've fixed (well, worked around) your exponential growth of menu.lst upstream by making os-prober ignore the (on /dev/blah) entries. It's not at all ideal and there's still more that could be done but it's a reasonably economical workaround.
<Kano> cjwatson: do i see it right, that you upload a rootfs and a cronjob creates the iso images then
<cjwatson> Kano: the way it's set up, the same cron job actually triggers the rootfs build first, but yes that's roughly right
<Kano> i see no exec of livecd.sh
<Kano> seems to be a bit tricky to rewrite the iso generation to be executed with one command without that infrastructure
<Kano> also usually you dont need to do that much...
<cjwatson> Kano: it's done indirectly and you won't see the exact setup as deployed there, but it calls through to BuildLiveCD
<cjwatson> Kano: it can't be done as one command because the CDs are all built on a single machine and obviously the livefses have to be built on one machine per architecture
<Kano> i c, for amd64+i386 it would be possible however
<Kano> but where are the subdirs of BuildLiveCD
<cjwatson> I'm sure it's possible but it's not worth it
<LucidFox> Archive admins, please move https://launchpad.net/ubuntu/+source/videotrans/1.6.0-0ubuntu1 from universe to multiverse
<LucidFox> it build-depends on multiverse packages and thus fails to build
<cjwatson> Kano: I already explained that
<cjwatson> Kano: 15:32 <cjwatson> Kano: they're just standard debootstrapped chroots with the livecd-rootfs package installed, AFAIK
<Kano> hmm
<cjwatson> it's obviously silly to have those in the package
<Kano> ok
<Kano> i guess i write just a differnt code around the rootfs generation
<Kano> have to think about it...
<Kano> bbl
<pitti> wwoods: FYI, I fixed the preload library now, tests pass (./test-apport lib)
<wwoods> oh cool!
* wwoods bzr merges
<pitti> wwoods: so I can now play around with dropping $CORE_SIGNAL etc.
<pitti> wwoods: oh, hmm; naturally, gdb generated core dumps do *not* have a signal in their cores
<dholbach> siretart: can we make it so that bzr-builddeb is installable with bzr 0.18-1?
<mvo_> calc: I don't think that is the issue, http://lists.freedesktop.org/archives/xorg/2007-June/025145.html indicates that xinerma disables randr
<mjg59> elmo: Hi
<wwoods> pitti: why are you using gdb to generate core dumps?
<pitti> wwoods: what else should I use?
<pitti> wwoods: and, even if there is a more efficient program, how would it help to poke a signal number into the core dump?
<wwoods> pitti: I just do kill -SEGV $pid
<wwoods> heh
<wwoods> get a real, live core dump
<wwoods> usually from the commandline I do: sleep 5 & sleep 1 ; kill -SEGV %1
<pitti> wwoods: ah, from the kernel, right; but that doesn't work too well when I want to call apport from a preloaded library, or do you see a good way to do that?
<pitti> wwoods: the idea of that library is to emulate the kernel behaviour and be a reference implementation, so I wouldn't like to bet on kernel behaviour
<pitti> wwoods: also, the test suite exercises different ulimits (including zero)
<wwoods> oh, um. not sure. I'll ask around though. I'm wary of emulating kernel crash dumps, though. seems like just using normal corefiles would be better
<wwoods> even if you're generating them on purpose
<asisak> re phanatic
<pitti> thekorn: here?
<thekorn> pitti: yes
<pitti> thekorn: I played with set_status(), but it doesn't seem to work for me
<pitti> b = Bug('124354', cookie_file='/home/martin/txt/lp-apport.cookie')
<pitti> b.set_status(importance='Medium')
<pitti> thekorn: is that supposed to work like this? the bug is still 'undecided'
<pitti> thekorn: b.importance is now 'Medium', but I guess set_status() just set that member variable internally
<pitti> thekorn: ^ ah, yes, it does
<thekorn> pitti: it should work, the problem are bugs with many tasks
<pitti> thekorn: right, in that case I'd need to specify one, but that bug only has one
<thekorn> but there is a solution in my gsoc branch
<thekorn> k
<pitti>          full_sourcepackage+'.importance': self.importance,
<pitti>          full_sourcepackage+'.importance-empty-marker': '1',
<pitti> thekorn: what does that empty-marker?
<pitti> ... do?
<thekorn> i realy don't know, but without this it does not work
<Kmos> 1 == undecided ?
<pitti> {'ubuntu_apport.status': 'Fix Committed', 'ubuntu_apport.importance-empty-marker': '1', 'ubuntu_apport.importance': 'Medium', 'FORM_SUBMIT': '1', 'ubuntu_apport.sourcepackagename': 'apport', 'ubuntu_apport.status-empty-marker': '1', 'ubuntu_apport.comment_on_change': ''}
<pitti> thekorn: this is the args dictionary; it looks pretty reasonable
<pitti> thekorn: it figured out the source package, task, status, etc.
<thekorn> pitti: what features of py-lp-bugs does apport use? add comments/attachments, set tags, set status, get list of bugs
<pitti> get description, download attachments, add comment, add attachment, delete attachment, add subscriber, get bug list (by tag), get status, set/get duplicate #, add/remove tags
<pitti> thekorn: and now I wanted to use set_status() to make bdmurray happy (bug 106379)
<ubotu> Launchpad bug 106379 in apport "retracer should set importance of bugs" [Wishlist,Confirmed]  https://launchpad.net/bugs/106379
<bdmurray> heh
<bdmurray> thekorn: Is bughelper aware of assignment?
<thekorn> pitti: ah, that's once again a cokkie problem
<thekorn> cookie
<pitti> thekorn: I added a p-lp-bugs task to bug 106379
<ubotu> Launchpad bug 106379 in apport "retracer should set importance of bugs" [Wishlist,Confirmed]  https://launchpad.net/bugs/106379
<pitti> thekorn: oh, it doesn't call self._setup_cookie()
<pitti> thekorn: hmm, I added that, but it still doesn't work
<pitti> thekorn: oh, forget that, it already does call it (/me blind)
<pitti> bbl
<Kmos> ./topic Ubuntu BugSquad | http://wiki.ubuntu.com/BugSquad | https://launchpad.net/distros/ubuntu/+bugs | Documentation: http://wiki.ubuntu.com/HelpingWithBugs | If you have been triaging bugs for a while, please apply to https://launchpad.net/people/ubuntu-qa/ - http://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad - Tomorrow is HUG DAY!
<Kmos> :)
<Kmos> wrong channel
<Kmos> ups
<thekorn> pitti: is the user with this cookie allowed to change the status of the bug?
<thekorn> it works for me with a valid cookie-file
<geser> pitti, Mithrandir: please give-back haskell-configfile. Thanks.
<geser> pitti, Mithrandir: please give-back haskell-hsh. Thanks.
<pitti> thekorn: oh, that might be a point
<LaserJock> after a package has been excepted through NEW does it take a while to get it into the build queue?
<LaserJock> *accepted
<pitti> LaserJock: binary NEW: about an hour, source NEW: needs manual review, thus arbitrarily long
<pitti> bdmurray: could you please add apport to ubuntu-qa? it's only the bot user
<LaserJock> pitti: well, I mean the about of time between when a package is accepted through source NEW and when the binaries get built
<pitti> geser (CC: Mithrandir): done
<pitti> LaserJock: no, there's no human delay
<pitti> LaserJock: and you'll see the binaries in the new queue
<LaserJock> hmm
<pitti> LaserJock: unless they FTBFS, of course
<LaserJock> pitti: edubuntu-addon-meta was accepted through source NEW 40 minutes ago but there are no builds
<LaserJock> not even anything in the queue, that I can see
<pitti> LaserJock: ah; just give it some time then
<LaserJock> pitti: ok, that's all I needed to know ;-)
<pitti> thekorn: confirmed; sorry for the trouble then
<bdmurray> pitti: done
<pitti> bdmurray: yay, thanks
<kmon> Hi. I would like to know if there's any plan in gutsy with regards to intel-mac's
<kmon> I would like to help testing.
<ogra> kmon, so just grab an image and test ;)
<kmon> I've already installed tribe 3
<kmon> and filed bugs
<kmon> :)
<ogra> what else would you want to do ?
* ogra doesnt understand the question there is no difference to any other intel system apart from the bootloader
<ogra> (afaik)
<kmon> that's my main concern, really
<ogra> ah
<ogra> now it makes sense :)
<kmon> the bootprocess on a mac-intel with linux only is a pita
<geser> cjwatson: gutsy has no -lowlatency versions of the kernel anymore and linux-backports-modules-2.6.22 is now stuck in depwait
<kmon> ogra: thanks
<evand> kmon: if you mean native EFI booting, no there are no such plans for Gutsy.
<evand> at least none that I am aware of.
<kmon> grub-efi package doesn't work?
<evand> kmon: well, we don't use grub2 yet.
<kmon> anyone knows when grub2 will replace legacy grub?
<kmon> I think debian is going to do it for lenny...
<kmon> but i could be wrong
<LaserJock> kmon: well, considering when lenny is likely to be released, we have a while ;-)
<kmon> yes, I know...
<evand> kmon: https://blueprints.launchpad.net/ubuntu/+spec/grub2 , I'd guess at Gutsy+1, but it would be stab in the dark.
<kmon> I hate laptops
<kmon> ok, thanks LaserJock
<ogra> evand, well, gutsy+1 being LTS makes that unlikely ...
<evand> ah, good point
<ogra> i doubt we will do stuff that could be risky in any way in gutsy+1
<evand> lets just leave it at "sometime in the future" then
<ogra> heh :)
<kmon> it's a shame
<agoliveira> kmon: I used to hate them too but I bought one beefed enough to use as a desktop and now I'm enjoying the silence :)
<agoliveira> (with external keyboard and 20" LCD)
<kmon> I bought this mac so I didn't buy another pc with windows (to contribute to bug#1 ;)
<kmon> I did it before the dell deal, obiously
<kmon> obviously
<kmon> bye
<cjwatson> geser: thanks, will fix
#ubuntu-devel 2007-07-25
<soren> I have a hunch that it's against policy for a package to alter another package's rc?.d links, but I can't seem to find it in the policy..
<broonie> soren: It's the same thing as touching a configuration file, really.
<soren> broonie: If that's the case, then it's fine for another package to fiddle with it, as per section 10.7.4 about sharing configuration files.
<soren> broonie: And that might be the case. My hunch just told me otherwise.
<Burgundavia> hey soren
<soren> Burgundavia: Hi, Corey.
<ajmitch> hello soren, Burgundavia
<soren> ajmitch: Hey, Andrew.
<Burgundavia> hey ajmitch
<ajmitch> soren: do you know if we have any postgresql load balancing stuff?
<soren> ajmitch: sqlrelay, perhaps?
* ajmitch had a look, but didn't see any of the common ones
<soren> ajmitch: I've never actually used it for load balancing, though.
<ajmitch> hm, that could work
<ajmitch> it'd only be for 2-3 servers for now anyway, as an experiment :)
<soren> ajmitch: Ah, ok. I sed it for connection pooling once. That worked pretty well, afair.
<xnix> does anyone know of issues with nvidia/agp drivers in the latest gutsy gibbon kernel 6.22-8-generic +
<xnix> ?
<doesnothelp> hi
<doesnothelp> how do i devlop trojans for ubuntu suse 7.02?
<desrt> wrong channel, i'm afraid
<desrt> i suggest leaving
<RAOF> !ops
<ubotu> Help! bhale, infinity, Hobbsee, jdub, thom, fooishbar, fabbione, mdz, lamont, or Keybuk
<doesnothelp> you msut know
<doesnothelp> see
<Nafallo> doesnothelp: there is no such thing
<doesnothelp> what you brought upon youself
<doesnothelp>     Nek se ovaj vijek gordi nad svijema vjekovima,
<doesnothelp>     on e era biti strana ljudskijema koljenima.
<doesnothelp>     U nj se osam blizanacah u jedan mah iznjihae
<doesnothelp>     iz kolevke Belonine, i na zemlji pokazae:
<doesnothelp>     Napoleon, Karlo, Bliher, knez Velington i Suvorov.
<doesnothelp>     Karaore, bi tirjanah, i varcenberg i Kutuzov.
<doesnothelp>     Arei je, strava zemna, slavom bojnom njih opio
<doesnothelp>     i zemlju im za poprite, da se bore, naznaio.
<doesnothelp>     Iz grmena velikoga lafu iza trudno nije,
<doesnothelp>     u velikim narodima geniju se gnj'jezdo vije:
<doesnothelp>     ovde mu je pogotovu materijal k slavnom djelu
<doesnothelp>     i trijumfa dini v'jenac, da mu krasi glavu smjelu.
<doesnothelp>     Al' heroju topolskome, Karaoru besmrtnome,
<doesnothelp>     sve prepone na put bjehu, k cilju dospje velikome:
* desrt yawns
<doesnothelp>     die narod, krsti zemlju, a varvarske lance srui,
<doesnothelp>     iz mrtvijeh Srba dozva, dunu ivot srpskoj dui.
<doesnothelp>     Evo tajna besmrtnika: dade Srbu stalne grudi;
<doesnothelp>     od vitetva odviknuta u njim lafska srca budi.
<doesnothelp>     Faraona istonoga pred orem se mrznu sile,
<doesnothelp>     orem su se srpske mice sa vitetvom opojile!
<doesnothelp>     Od ora se Stambol trese, krvoedni otac kuge,
<doesnothelp>     sabljom mu se Turci kunu - kletve u njih nema druge.
<doesnothelp>     . . . . . . . . . . . . . . . . . . . .
<doesnothelp>     . . . . . . . . . . . . . . . . . . . .
<doesnothelp>     . . . . . . . . . . . . . . . . . . . .
<doesnothelp>     Da, viteza sustopice tragieski konac prati:
<doesnothelp>     tvojoj glavi bi sueno za v'jenac se svoj prodati!
<doesnothelp>     . . . . . . . . . . . . . . . . . . . .
<doesnothelp>     . . . . . . . . . . . . . . . . . . . .
<doesnothelp>     . . . . . . . . . . . . . . . . . . . .
<doesnothelp>     Pokoljenja djela sude, to je ije daju svjema!
<doesnothelp>     Na Borise, Vukaine, opta grmi anatema,
<doesnothelp>     gadno ime Pizonovo ne sm'je kaljat mjesecoslov,
<doesnothelp>     za Egista uprav slii grom nebesni, sud Orestov.
<doesnothelp>     . . . . . . . . . . . . . . . . . . . .
<doesnothelp>     . . . . . . . . . . . . . . . . . . . .
<doesnothelp>     . . . . . . . . . . . . . . . . . . . .
<doesnothelp>     Nad svijetlim tvojim grobom zloba grdna bljuva tmue,
<doesnothelp>     al nebesnu silnu zraku to ' ugasit tvoje due?
<doesnothelp>     Plane, grdne pomrine - mogu l' one svjetlost kriti?
<doesnothelp>     Svjetlosti se one kriju, one e je raspaliti.
<doesnothelp>     Plam e, vjeno ivotvorni, blistat Srbu tvoje zublje,
<doesnothelp>     sve e sjajni i udesni u vjekove bivat dublje.
<doesnothelp>     . . . . . . . . . . . . . . . . . . . .
<doesnothelp>     . . . . . . . . . . . . . . . . . . . .
<doesnothelp>     . . . . . . . . . . . . . . . . . . . .
<doesnothelp>     Zna Duana rodit Srpka, zna dojiti Obilie,
<sid> wtf
<doesnothelp>     al heroje ka Poarske, divotnike i plemie,
<doesnothelp>     gle, Srpkinje sada rau... Blagorodstvom Srpstvo die...
<doesnothelp>     Bjei, grdna kletvo, s roda - zavjet Srbi ispunie!
<doesnothelp>     U Beu na Novo ljeto 1847. goda
<doesnothelp>     Soinitelj
<doesnothelp> Lica
<doesnothelp> Vladika Danilo
<doesnothelp> Iguman Stefan
<doesnothelp> Serdar Janko urakovi
<doesnothelp> Serdar Radonja
<doesnothelp> Serdar Vukota
<doesnothelp> Serdar Ivan Petrovi
<doesnothelp> Knez Rade, brat vladike Danila
<doesnothelp> Knez Bajko
<doesnothelp> Knez Rogan
<sid> keybuk lamont mdz fabbione daniels thom jdub Hobbsee infinity bhale Mithrandir Kamion mneptok
<hggdh> just ignore the idiot until we get someone to boot it out
<doesnothelp> Knez Janko
<sid> any ops here?
<doesnothelp> Knez Nikola
<doesnothelp> Vojvoda Drako
<doesnothelp> Vojvoda Milija
<doesnothelp> Vojvoda Stanko (Ljub.)
<doesnothelp> Vojvoda Batri
<doesnothelp> Toma Martinovi
<doesnothelp> Obrad
<doesnothelp> 
<doesnothelp> Vuk Raslapevi
<desrt> sid; just walk away
<doesnothelp> Vukota Mrvaljevi
<doesnothelp> Vuk Tomanovi
<doesnothelp> Mnozina
<doesnothelp> Bogdan urakovi
<doesnothelp> Vuk Miunovi
<doesnothelp> Vuk Mandui
<doesnothelp> Vuk Ljeevostupac
<doesnothelp> Pop Mio
<doesnothelp> Sestra Batrieva
<doesnothelp> Hadi-Ali Medovi, kadija
<doesnothelp> Skender-Aga
<doesnothelp> Mustaj-Kadija
<doesnothelp> Arslan-Aga Muhadinovi
<doesnothelp> Kavazbaa Ferat Zair
<doesnothelp> Ridal Osman
<doesnothelp> Jedna baba
<doesnothelp>     Lica koja pjesnik nije bio unio u spisak:
<doesnothelp>     Vuk Markovi, jedan Cuca, jedan vojnik, drugi vojnik,
<doesnothelp>     svat Crnogorac, svat Turin, ae, aci.
<doesnothelp> Skuptina uoi Trojiina dne na Lovenu
<doesnothelp>     Gluho doba noi, svak spava.
<doesnothelp> Vladika Danilo (sam sobom)
<doesnothelp>     Vii vraga su sedam binjiah,
<doesnothelp>     su dva maa a su dvije krune,
<doesnothelp>     praunuka Turkova s Koranom!
<doesnothelp>     Za njim jata prokletoga kota,
<doesnothelp>     da opuste zemlju svukoliku
<RAOF> Thank you.
<evand> wow
<ajmitch> impressive paste spew, wasn't it?
<evand> it was surely something
<ajmitch> not sure what that something was, but it was something :)
<infinity> Aww, I missed all the excitement.
<infinity> Jetlag's still killing me, that would be why. :/
<StevenK> infinity: Back in sunny downtown Melbourne?
<infinity> Yeah, finally.
<StevenK> Heh
<sbalneav> I'll ask again, just in case any new eyes see this...  I'm trying to squash Bug #107518.  Does anyone know any nice, simple way top detect if a given file system is dirty?
<ubotu> Launchpad bug 107518 in ltspfs "auto filesystem mounting can cause hideous data loss" [Medium,Confirmed]  https://launchpad.net/bugs/107518
<calc> grr tribe-3 cd still has problem connecting to my AP at home :\
* calc wonders why it worked fine at the canonical office but doesn't at home
<calc> feisty works fine at home
* calc is getting worried that gutsy will be released and he won't be able to use it on his laptop
* calc bbl
<LucidFox> Any archive admins in here?
<Hobbsee> LucidFox: probably not at this time of day
<Hobbsee> wait a few hours
<LucidFox> ah
<LucidFox> damn timezones...
<LucidFox> most people here probably don't live in UTC+7
<Hobbsee> no.  nor +11
<cjwatson> LucidFox: if it's the component move you were asking about last night: file a bug on the package and subscribe (NOT assign) the ubuntu-archive team to it, and it'll go onto the archive admin queue
<pitti> Good morning
<StevenK> Morning pitti
<\sh> guys, what do you need to check on bug 127125 ? if it's possible I'll try to get everything you need
<ubotu> Launchpad bug 127125 in linux-source-2.6.20 "2.6.20 in feisty can't mount EIT/GPT Partition Tables with more then 2TB size" [Undecided,New]  https://launchpad.net/bugs/127125
<LucidFox> cjwatson> Ah, all right. I already did that.
<mdke> does anyone know who else is involved in this new training team that was announced besides Billy?
<mdke> hi Burgundavia
<Burgundavia> hey md
<mdke> :)
<Burgundavia> mdke, rather
<Hobbsee> greetings Burgundavia, from the land of the green aliens
<Burgundavia> green aliens?
<mdke> I wish my greeting had been that innovative
* Hobbsee is a green alien.
<Burgundavia> does that mean you have a green card?
<Hobbsee> Burgundavia: wrong country
<Hobbsee> mdke: i actually said "greetings from the queen of the aardvarks", to start a phonecall yesterday - the receiver actually recognised who it was!
* Hobbsee was quite surprised
<mdke> I would have put the phone down
<Hobbsee> hehe
<Hobbsee> not sure if they have number recognition, on that phone, or just recognised my voice
<mdke> or the greeting
* elkbuntu ponders who recognises Hobbsee as the queen of the aardvarks and decides it is probably best to not know
<Hobbsee> elkbuntu: the aardvarks themselves, of course.
<Hobbsee> mdn
<mdke> haha
<Hobbsee> mdke: no, i've never used such a greeting to her before
<elkbuntu> talking aardvarks. now i've heard it all
<Hobbsee> mutation.  evolution.
<cjwatson> so is there a good reason why we bother to SIGTERM the avahi daemon on shutdown?
<Hobbsee> morning cjwatson
<elkbuntu> Hobbsee, oh, you mean like weasleboy?
* elkbuntu finds somewhere to hide
<Hobbsee> elkbuntu: exactly.
<cjwatson> morning
<Hobbsee> poor Burgundavia will probably be psycologically damaged from you calling him that, elkbuntu
<elkbuntu> Hobbsee, i can just blame it on his brother
<Burgundavia> wait a sec
<elkbuntu> he's the rat
<Burgundavia> I will bring you up before teh CC for that!!! ;P
<elkbuntu> is that the best retort you have?
<Hobbsee> Burgundavia: you will have to abstain, though
* elkbuntu huggles Burgundavia
<Mithrandir> cjwatson: could we make build-mobile not fall over if it fails to fetch an image?  Not all of them build yet.
<Hobbsee> morning Mithrandir
<Mithrandir> hiya Hobbsee
* Mithrandir runs away before she stomps his feet
* Hobbsee fires paper bullets at Mithrandir 
<Hobbsee> Mithrandir: does that mean i should stomp on your fingers instead, then?
<Mithrandir> Hobbsee: lala, I can't hear you, 'cause I've run away.
<Hobbsee> Mithrandir: i can yell.
<Hobbsee> Mithrandir: you underestimate how loudly i can yell :P
<seb128> Does anybody has an objection to add xserver-xephyr to "supported"?
<seb128> gdmflexiserver can use it and it's better than xnest
<soren> Can anyone see why libgnutls gets pulled in here? http://launchpadlibrarian.net/8170757/buildlog_ubuntu-gutsy-i386.postfix_2.4.3-1ubuntu1_FULLYBUILT.txt.gz
<soren> Ah, it's Priority: important
<cjwatson> Mithrandir: don't add them to the list if they don't build, then? ;)
<Mithrandir> cjwatson: heh, I could do that.
<cjwatson> Mithrandir: but I suppose I can fix that
<soren> Why would libgnutls13 be Priority: important
<soren> ?
<Mithrandir> soren: no, that's not why it's pulled in.
<soren> Mithrandir: No?
<Mithrandir> soren: it's pulled in by libldap2 which is pulled in by libldap2-dev
<cjwatson> Mithrandir: would you like me to commit the changes on lithium?
<Mithrandir> cjwatson: yes, please.
<Mithrandir> soren: the chroots on the buildds are Priority: required and {Build-,}Essential: yes, not Priority: important.
<soren> Mithrandir: You're right. I got confused because it was already installed in my sbuild.
<cjwatson> soren: http://people.ubuntu.com/~ubuntu-archive/germinate-output/gutsy/minimal
<cjwatson> libgnutls13 <- libcurl3-gnutls <- gnupg <- minimal seed
<Mithrandir> soren: but why do you care about libgnutls?  It's just the library package, not the -dev package.
<cjwatson> (one route, there are probably others)
<soren> Mithrandir: Just looking at bug 81242
<ubotu> Launchpad bug 81242 in postfix "postfix-ldap is linked against gnuTLS" [Medium,Triaged]  https://launchpad.net/bugs/81242
<soren> Mithrandir: And then I got curious.
<soren> cjwatson: Right. Thanks.
<cjwatson> (hopefully this is stating the obvious, but you need explicit --without-gnutls or whatever rather than relying on the library not being installed at build time)
<Mithrandir> cjwatson: the -dev package doesn't seem to be installed, though?
<cjwatson> I know
<soren> cjwatson: Sure. I just couldn't spot why it would get installed anyway.
<cjwatson> soren: postfix Build-Depends: libldap2-dev Depends: libldap2 Depends: libgnutls13
<soren> cjwatson: Got it.
<cjwatson> oh, Mithrandir said that above, whoops :)
<soren> cjwatson: The confusion arose when I ran the apt-get command line from the build log in my own schroot and it didn't pull in libgnutls13.
<cjwatson> right
<cjwatson> Mithrandir: done
<Mithrandir> cjwatson: thanks
<ivoks> should libldap get build against openssl then?
<pitti> ivoks: that would break the world license-wise, I think
<ivoks> well, libldap is under same license as openldap
<ivoks> which is already build against openssl
<pitti> ivoks: right
<pitti> ivoks: but that would mean GPL software couldn't link against our libldap any more
<ivoks> right...
<pitti> $ apt-cache rdepends libldap2|wc -l
<pitti> 147
<ivoks> then libldap2-nongpl?
<pitti> I'm pretty sure that there are some GPL programs amongst these
<ivoks> for postfix and alike...
<pitti> soren: what was the actual problem of libldap linking against gnutls?
<ivoks> postfix-ldap is build against libldap
<cjwatson> I'm not happy either with stuff moving libgnutls -> libssl without a very good reason
<ivoks> that makes ldap->postfix tricky
<Hobbsee> morning pitti :)
* StevenK idly wonders what to do about libdb3-dev disappearing
<pitti> hey Hobbsee
<soren> pitti: Yeah, what ivoks said. :)
<ivoks> pitti: http://archives.neohapsis.com/archives/postfix/2007-01/1351.html
<ivoks> that's our package :)
<seb128> pitti: any objection to have xserver-xephyr listed to supported?
<pitti> seb128: if you give this some testing, sure
<pitti> seb128: will gdmflexiserver automatically use it?
<pitti> seb128: gdmflexiserver -n -l doesn't work, and I don't see an explicit xephyr option?
<seb128> pitti: yes, vuntz nagged me at GUADEC because it's much better than xnest (real grab pointer and keyboard, doesn't crash on workspace switching, etc)
* StevenK tries to make sense of why lib32gcj8-0 appears on the NBS list.
<seb128> pitti: I just merged gdm with debian and there is a gdmXnestWrapper now
<pitti> ah, cool
<seb128> pitti: the wrapper use xephyr if available otherwise xnest
<pitti> whoops, xephyr just crashed
<mvo> calc: I looked at your xinerama issue, it maybe that a new compiz snapshot solves the problem
<pitti> I just started xeyes in it...
<StevenK> pitti: Feel like cleaning up the NBS list by purging a bunch of stuff? :-)
* pitti files apport report
<pitti> StevenK: sure!
<StevenK> pitti: asterisk-app-dtmftotext, libapache-mod-xslt, libgmpxx4, libode0c2 and libspandsp1 can all go.
<pitti> StevenK: I just remove all of the empty files
<pitti> StevenK: I'll also remove the NBS -dev packages, to avoid more packages using them
<StevenK> pitti: Hrm. Don't do that. xen-hypervisor is still listed.
<pitti> StevenK: that's fine, it's really NBS
<StevenK> Yeah, but is the new Xen in yet?
<pitti> no, the packages still have a lot of problems, I mailed zul already
<StevenK> And I'm not sure what to do about lib32gcj8-*
<StevenK> pitti: Speaking of -dev packages, libdb3-dev is NBS'd, and I'm unsure where to go with that.
<pitti> StevenK: I think the reason is to stop packages from using libdb3
<pitti> lib32gcj-bc is the only rdepends of lib32gcj8-0
<StevenK> Sure, but should I look at moving r-build-depends of libdb3-dev to libdb4.x?
<pitti> ah, but lib32gcj-bc is built from gcc-defaults
<pitti> StevenK: that's generally possible if the package does not use on-disk transactions
<StevenK> Yeah, I looked at it earlier and went cross-eyed
<pitti> StevenK: "grep -r TXN" is a good indication
<StevenK> In the source?
<TheMuso> StevenK: Sid has done a lot of packages to libdb4.5, and we haven't.
<pitti> the on-disk transaction format changed in every release, so those pacakges need extra love
<pitti> TheMuso: how did they do the conversion for stuff that does use transactions, like cyrus-sasl?
* StevenK grumbles about bezerkly DB
<TheMuso> pitti: I don'tknow.
<cjwatson> don't you need to run db4.X_upgrade or whatever it is?
<cjwatson> (for stuff that uses transactions)
<pitti> oh, there is an upgrade tool now? shiny
* StevenK has this feeling glade-3 FTBFS on ia64 and sparc
<seb128> StevenK: sparc GTK builds are borked due to glib at the moment
<StevenK> I suspect ia64 is suffering from the same fate.
<pitti> WARNING: package xserver-xephyr-dbgsym not available
* pitti grumbles
<pitti> seb128: ^ no retrace love for my xephyr crash :(
<cjwatson> pitti: always has ben
<cjwatson> been
<seb128> StevenK: not likely
<cjwatson> I've never been involved with a package that uses on-disk transactions though, so I'm not certain
<StevenK> seb128: glade-3 failed to build on both sparc and ia64 with exactly the same spew from apt.
<StevenK> I'm blaming bonobo, but I haven't checked.
<seb128> StevenK: I doubt it's due to bonobo
<StevenK> Like I said, I haven't checked. :-)
<pygi> good morning everyone :)
<seb128> hi pygi
<seb128> I got some upload mails with "Thank you for your contribution to INVALID." some days ago for packages I've not uploaded, I'm wondering why
<kagou> Hi tkamppeter_
<mvo> seb128: I had that too some days ago
<StevenK> pitti: It looks like most of this libdb3-dev stuff can be handled by syncs. I'm up to ten. Do I need to file them all manually?
<seb128> mvo: dunno who did what to create those? ;)
<mvo> seb128: no, I suspect somthing in LP going no, but I do not know
<seb128> k
<pitti> StevenK: it's enough to give me a list
<pitti> StevenK: if there are ubuntu modifications, I'd like to have a bug, though, for a permanent record of why to drop them
<pitti> StevenK: requestsync makes it easy enough after all :)
<StevenK> pitti: I've checked, none of them do.
<StevenK> pitti: 12 sync and 1 removal.
<pitti> cool
<StevenK> pitti: Let me prepare the list and I'll dump it in here
<pitti> StevenK: thanks
<kagou> tkamppeter_, i'v asked for upgrading/sync python-cups Bug #128201 . Thanks for s-c-p 0.7.70
<StevenK> pitti: Sync: apt-rpm dhelp gabber gconf gnome-libs gnucash gtoaster hotkeys libtabe xcin xemacs21 xfmail ; Remove cyrus21-imapd (Debian bug #432576)
<ubotu> Debian bug 432576 in ftp.debian.org "RM: cyrus21-imapd -- RoM; outdated; has newer branches in the archive" [Normal,Open]  http://bugs.debian.org/432576
<StevenK> pitti: Actually, sorry, gnucash and xcin have Ubuntu changes
* StevenK should learn to read at some point
* StevenK ponders dinner
<pitti> StevenK: synced (except gnucash and xcin)
<StevenK> pitti: Great, thanks!
* StevenK will merge/file syncs for both gnucash and xcin tonight.
<seb128> pitti: are you doing syncs?
<pitti> StevenK: there is one reverse dependency left from cyrus21: meta-ul-mail-server
<seb128> k, looks like
<pitti> StevenK: but *shrug*
<seb128> that's why processing backports doesn't work :p
<pitti> seb128: I'm done now, all your's
<seb128> pitti: k, I was just wondering why it refused to do the backports, thanks ;)
* StevenK wonders what meta-ul expands to
<pitti> seb128: btw, last time I cleared NEW for dapper-/feisty-backports, but I didn't manage to clean edgy-backports completely
<cjwatson> backports shouldn't block on syncs ...
<pitti> seb128: maybe some of the stuff shuold just be rejected if it's too intrusive
<cjwatson> unless there's some strange LP lock somewhere
<pitti> cjwatson: process-upload.py lock, I figure
<seb128> cjwatson: the flushing does
<StevenK> UserLinux. Right then.
<cjwatson> ah
<StevenK> pitti: I'll deal with meta-ul-mail-server, too
<cjwatson> fair enough
<pitti> StevenK: I guess it can be just synced, or something
<pitti> meta-ul-mail-server | 0.02-1ubuntu13 | gutsy/universe | all
<pitti> StevenK: erk, 13 ubuntu uploads? whoa
<StevenK> pitti: It's also been killed from Debian
<pitti> indeed
<StevenK> Kill them both?
<pitti> StevenK: looks like it has never actually been in there?
<saispo> hi all
<StevenK> Ah
<saispo> packages.ubuntu.com is down ?
<pitti> http://packages.qa.debian.org/m/meta-ul-mail-server.html doesn't even exist
<pitti> which means it's not even in oldstable
<StevenK> That'd explain the lack of bug against ftp.debian.org :-P
<LucidFox> saispro> yes, it is
<LucidFox> *saispo
<pitti> Source: meta-ul
<StevenK> pitti: mako is the maintainer, maybe we need to ask him nicely
<pitti> StevenK: ^ my bad, sorry
<pitti> StevenK: so none of the old names exist either
<StevenK> Which means we should kill it?
<soren> Question: Does the usual interpretation of the Debian Policy allow for a package to alter another package's rc?.d links?
<pitti> geser: you did the last three uploads of meta-ul; are you actually interested in that package and want to fix it for the cyrus21-imapd removal, or shall I just kill it?
<pitti> soren: erk; I'd interpret the DP as "don't do that"
<geser> pitti: no, please kill it
<StevenK> Hurray!
<geser> pitti: I've only fixed unmet deps in the past
<pitti> soren: once you start doing that, and multiple packages change your rc links, then you'll get mad
<soren> pitti: 10.7.4 speaks of shared configuration files, which this could be interpreted as.
<pitti> geser: thanks
<pitti> soren: right, but that applies to stuff like /etc/modules or /etc/passwd IMHO, which are not clearly tied to a particular package
<soren> pitti: But my hunch says that it's evil.
<soren> pitti: Right, ok.
<pitti> soren: what's the use caes?
<pitti> case, even
<pitti> StevenK: *flush*
<soren> pitti: I'm trying to figure out if there's some policy-abiding way I can make ebox run an ldap server. Right now, it mangles /etc/ldap/slapd.conf and uses the system one, but I'd rather have it create a separate slapd.conf, run a separate instance of slapd and make the "real" slapd not run.
<pitti> soren: but in this case it should also listen to a nonstandard port etc., so it shouldn't actually interfere with the main ldap server?
<soren> pitti: No, it's supposed to listen on the standard ldap port.
<pitti> soren: it would seem quite weird to me if the box which runs ebox couldn't work as an ldap server?
<pitti> soren: let's take a step back
<pitti> soren: is that ldap server supposed to be a private database for ebox internals, or an official ldap server for net auth etc. which is configured by ebox?
<soren> pitti: The latter.
<pitti> ah
<asisak> lionel: concerning bug 119796 you acked the sync. Does this mean you checked there is no necessary Ubuntu diff?
<ubotu> Launchpad bug 119796 in openbox "please sync openbox 3.4.2-1 from Debian unstable (main)" [Wishlist,Confirmed]  https://launchpad.net/bugs/119796
<LucidFox> pitti, can you please look at bug #128145?
<ubotu> Launchpad bug 128145 in videotrans "Please move to multiverse" [Wishlist,Fix released]  https://launchpad.net/bugs/128145
<pitti> soren: hm, so why don't you want to start it at boot then?
<soren> pitti: I do.
<pitti> LucidFox: seb128 did it two minutes ago :)
<seb128> ;)
<soren> pitti: I just don't want to break the existing ldap config.
<seb128> LucidFox: usually no need to ping archive admin, we do look at the bug list often enough
<pitti> soren: do you need to?
<soren> pitti: And the cleanest way to do this, I think, is to create an entirely separate configuration, with an entirely separate ldap database and use that instead of the "real" one.
<pitti> soren: i. e. can't the ldap module read the existing config and mangle it according to the settings you do in ebox?
<soren> pitti: Well, ebox can start it from its init script (which it probably will), but I need the "real" one to not start.
<soren> pitti: in theory, yes. I'm just not very comfortable doing that.
<pitti> soren: TBH, I think we should find a way to configure the real system packages properly; having private instances of everything will be an insane maintenance overhead IMHO
<pitti> soren: as long as ebox doesn't change configuration automatically, only on user's requests, I do not see a conflict with the DP spirit
<pitti> i. e.
<pitti> good: read ldap.conf, present it on GUI, have user change settings, write it back, force-reload
<pitti> bad: ignore ldap.conf, create ldap.conf from scratch according to settings in ebox
<pitti> soren: the current xserver-xorg postinst is a great way how *not* to do it :)
<pitti> it's the prime example of violating the debconf policy (and configuration file clobbering)
<soren> pitti: I'm aware of the maintenance overhead, but doing what you propose requires deep and thorough knowledge of *every* aspect of *every* config file we want to handle.
<pitti> soren: well, you need knowledge about the syntax, the default settings, and the values that you want to change
<soren> pitti: The beauty of having a separate config is: 1Installing ebox is safe and undoable.
<soren> whoops
<pitti> soren: I think it's reasonable for ebox to say "I cannot configure this" if there is a non-default configuration file
<soren> pitti: The beauty of having a separate config is: 1) Installing ebox is safe and undoable, 2) we control the entire new config, so we're sure it works like it's supposed to.
<soren> pitti: And how do you propose detecing "default configurations"?
<soren> detecting..
<pitti> soren: but still, it makes ebox and configuration file management incompatible
<pitti> soren: check if a conffile is unmodified, and keep md5sums of the last version ebox wrote maybe?
<pitti> (conffile unmodified -> if ebox doesn't have its own checksum yet)
<soren> pitti: right. By having a totally separate config, you can choose to go the dpkg way or the ebox way and switch between them safely.
<soren> pitti: I'm not talking about letting the user change configs that ebox has written. I'm talking about installation time.
<pitti> soren: IMHO it would be very sad to make the standard conffiles unusable; admins are used to them, they might be covered in backup software, you break upstream documentation, etc.
<soren> pitti: I've got other plans for changing configurations while ebox is already installed.
<pitti> soren: seems you arrived at one of the core design decisions here; maybe that warrants an u-devel@ thread
<soren> pitti: They are free to change the templates used to generate the configuration files.
<pygi> siretart, poke?
<pitti> soren: if you want to go the 'separate config' approach, I'd prefer changing the affected packages themselves to point to a different configuraion file/dir in their default file
<doko> seb128: glib sparc fix ping
<seb128> doko: not done yet, will have a look this week, is there any hurry?
<seb128> I'm trying to catch up after distro sprint and GUADEC and I've quite a lot to do
<doko> seb128: packages fail to build, including gcj
<seb128> that I know
<soren> pitti: Why? To make it easier for admins to figure out what's going on?
<seb128> but is that blocking you for something you need?
<pitti> soren: rather to keep configuration file locations and the knowledge about them to the packages themselves
<pitti> soren: that way, their init scripts etc. can be modified to use the correct configuration file, and you do not need nasty rc hacks and duplicate init scripts
<doko> well, I have to build things locally for the icedtea bootstrap
<soren> pitti: I still need to remove their rc?.d links.
<pitti> soren: why that?
<soren> pitti: Well.. Not *need*, but it makes other things an order of magnitude simpler.
<soren> pitti: Because, alternatively, ebox will have to stop the service (and dependent services), rewrite the configuration (to make sure it is the way we expect it to be) and start the service (and rdependents) again.
<pitti> soren: hm, I'm not sure whether this is true; you'll end up duplicating all the effort and knowledge that went to the packaging, init scripts, etc., not even mentioning the tools for system checks
<seb128> doko: I'll look at glib after lunch
<pitti> soren: if you change a configuration, then you'll need to force-reload the service anyway
<soren> pitti: huh? Just because I'm removing the rc.?.d lins?
<soren> pitti: Precisely. That's why it's easier if the service isn't started already, but will be started by ebox.
<pitti> soren: no, if you change the server configuration
<pitti> soren: I still don't understand that
<pitti> soren: surely ebox doesn't modify configuration files on startup?
<soren> pitti: How else will it know that the configuration is the way it's supposed to be?
<pitti> soren: you scare me
<pitti> soren: it actually rewrites configuration every time it starts up?
<soren> pitti: Yes.
<soren> pitti: If you stop ebox, break the configuration and start ebox again, and ebox didn't do anything to fix it, how would that be handled if you were to decide?
<pitti> soren: it shouldn't be handled at all
<pitti> soren: if the admin changed a configuration file manually, nothing should clobber that
<pitti> (our "Golden Rule")
<soren> pitti: So just break spectacularly? That sounds cleveR?
<pitti> soren: yes
<pitti> soren: ignoring admin's explicit decisions is really bad
<soren> pitti: The configuration files *clearly* state "DO NOT EDIT THIS FILE! EDIT THE TEMPLATE INSTEAD!"
<pitti> soren: but that doesn't make it much better IMHO
<pitti> soren: if someone restores their machine from a backup, he should get the configuration files he wants, not the ones ebox scribbles over them
<pitti> soren: IMHO *not* respecting the current configuration files is opening a can of worms
<soren> pitti: I respect it by not overwriting it.
<soren> pitti: but *you* want me to overwrite it.
<pitti> which brought SuSE a lot of bashing in the past (and Debian a lot of trust because it didn't do it)
<soren> pitti: You are the one proposing messing with the user's existing files.
<pitti> soren: right
<pitti> soren: I don't want ebox to override the configuration files every time, without question
<soren> pitti: I want to leave them alone, so it's easy to ditch ebox again and not have anything broken by it.
<geser> this sounds like yast in the old days where it didn't honour manual editing of config files
<pitti> indeed
<StevenK> YaST. *twitch*
<pitti> so, there are some cases here:
<pitti> 1) conffile comes as shipped in the .deb (unmodified conffile) -> we should make sure that ebox understands those
<pitti> 2) conffile was manually changed in a way that ebox understands -> I see no problem of changing it again with ebox; if the admin does configuration changes in the ebox UI, he makes an educated decision of configuring his server
<soren> pitti: Doesn't work for slapd. It's altered by debconf magic. Which sort of brings me to my second question, but let's leave that for a bit.
<pitti> 3) conffile was manually changed in a way that ebox doesn't understand -> don't touch it and explain
<tkamppeter> kagou, I have now made another package of s-c-p 0.7.70 and also an update of hal-cups-utils to 0.6.11, because of bug 127841, but it seems that HAL does not trigger the script when plugginh a printer. Any idea?
<ubotu> Launchpad bug 127841 in hal-cups-utils "hal-cups-utils does not auto-setup printers on Ubuntu Gutsy" [Medium,Confirmed]  https://launchpad.net/bugs/127841
<pitti> I don't think that 3) is an use case we need to worry about much
<pitti> people who do that won't need ebox, and if they want it, they can clean up themselves
<tkamppeter> kagou, and thanks for reporting bug 128201.
<ubotu> Launchpad bug 128201 in python-cups "Please update/sync to 1.9.24" [Wishlist,Fix released]  https://launchpad.net/bugs/128201
<soren> pitti: You are answering an entirely different question than I asked.
<soren> pitti: I intended to fix that anyway in a way similar to what you propose. The difficulty is what to do at *install* time.
<pitti> soren: slapd> if it doesn't fall under 2) ATM, then we can still change the slapd package accordingly (or improve the ebox module)
<pitti> soren: hm, so what is your question about install time?
<soren> pitti: Well, one of them was: How do I detect that this is a default install?
<soren> pitti: /win 17
<soren> whoops
<pitti> soren: for conffiles this is easy; you can md5sum the file and compare it to dpkg-query -W -f='${Conffiles}' $PKGNAME
<pitti> soren: for config files this needs to be decided on a case-by-case basis
<pitti> soren: often, config files (not conffiles) are written by debconf scripts
<pitti> in which case they are usually trivial enough to parse and change
<soren> pitti: Does that dpkg-query thing take into account changes made during postinst (debconf stuff)?
<pitti> soren: no, that is independent
<pitti> soren: packages must not change conffiles with debconf
<soren> pitti: No, but I'm dealing with config files.
<cjwatson> s/ with debconf//
<cjwatson> well, s/ with debconf/ in maintainer scripts/
<pitti> the common practice is to have easy config files written by debconf (such as default files) and conffiles which shouldn't usually be touched at all
<cjwatson> soren: with configuration files, dpkg-query -W -f='${Conffiles}' won't return anything ...
<pitti> soren: if you encounter a package which has variable bits in hard-to-parse configuration files, we should fix that package; it'll avoid much trouble and also make admins happier even without ebox
<soren> cjwatson: Sure.
<pitti> soren: conffiles are part of the shipped files in a .deb, configuration files are created on the fly in maintainer scripts
<soren> pitti: I know.
<pitti> ok
<soren> I'll send a mail to u-devel, shall I?
<pitti> soren: sounds good, for more participation
<soren> Right.
<Mithrandir> asac: what's holding the mobile-internet-browser back?
<pitti> Mithrandir: what do you mean?
<pitti> midbrowser | 0.0.070720-0ubuntu1 | gutsy/universe | source, amd64, i386, powerpc
<pitti> isn't it that one?
<Martian67> In #ubuntu-devel someone just asked "what's holding the mobile-internet-browser back?" and I *so* wanted to answer: "no wheels"
<Martian67> thank you for your time
<asac> Mithrandir: took some time to do a thorough new review (given the size of that source tarball its reasonable imo) ... should be in now
<lionel> can an archive admin give back mysql-query-browser on sparc, powerpc, ia64, i386. it would solve #125203
* StevenK watches the buildds get hit up by backport after backport
<pitti> lionel: done
<lionel> thanks asisak for taking care of openbox :)
<lionel> pitti: thanks!
<Mithrandir> asac: you haven't uploaded it
<asac> Mithrandir: what do you mean?
<asisak> lionel: your welcome *cool*
<asisak> I mean openbox is cool :)
<Mithrandir> asac: I am unable to find a mobile-internet-browser package.
<asac> Mithrandir: midbrowser
<Mithrandir> asac: ah, ok.  It would be helpful if you had told you about renames like that. :-P
<cjwatson> lionel: s/archive admin/buildd admin/
<asac> Mithrandir: didn't know about a given name in the first place ... and i pinged you right after the upload
<lionel> cjwatson: you're right :)
<Mithrandir> asac: I don't have any pings from you in the last 24 hours, and it was uploaded 17 hours ago
<asac> Mithrandir: i uploaded last week ... it took a few days for NEW review
<asac> Mithrandir: iirc, i uploaded friday
<Mithrandir> asac: ok, anyway, it's there now
<siretart> pygi: pong
<pygi> siretart, hey
<pygi> siretart, any progress?
<siretart> pygi: I didn't manage to find the time to go through the sourcecode yet
<siretart> :(
<pygi> siretart, k
<geser> pitti: I've seen that Debian tries to get away from libdb3 (universe). Should we try it also and sync those packages? or should it wait for gutsy+1?
<pitti> geser: doing it now is fine; in fact, StevenK already looked at it and I synced a lot already
<StevenK> geser: Beat you. I've dealt with/am dealing with them all already
<geser> good
* #ubuntu-devel  [freenode-info]  please register your nickname...don't forget to auto-identify! http://freenode.net/faq.shtml#nicksetup
(Riddell/#ubuntu-devel) there is no package where the debian/copyright lists the authors of admin/ files
(Tonio_/#ubuntu-devel) seb128: no pb, I'll do a fixed copyright file toonight then
(pitti/#ubuntu-devel) Tonio_: it's not a reason to OMGrepackageeverything, but I agree that new packages shuold do it correctly
(seb128/#ubuntu-devel) Riddell: any reason why those copyright holders should not be listed?
(Tonio_/#ubuntu-devel) pitti: sure ;)
(mvo_/#ubuntu-devel) there is one ... libcompizconfig-backend-kconfig, because I was forced to add it to get it out of NEW :P
(seb128/#ubuntu-devel) Tonio_: ok, thanks
(pitti/#ubuntu-devel) Tonio_: great, thank you for understanding
(pitti/#ubuntu-devel) mvo_: MUAHAHAHA!
(pitti/#ubuntu-devel) erm
(seb128/#ubuntu-devel) Tonio_: I'm rejecting the current kdesudo then
* seb128 hugs mvo_
(pitti/#ubuntu-devel) mvo_: rightly so! :)
* pitti hugs mvo_, too
<mvo_> ...
* mvo_ hugs pitti seb128
<Tonio_> pitti: bah, it is an axiom, no reason to reject it, it *has* to be done ;) just that I think Riddell, I and any other guy just did like any other kde packager and reproduced the error
<lool> seb128: I'm pushing glib2.0 2.13.7-2 with the shlibs bumped to experimental right now
<jwendell> jamesh, is gnome-vfs-obex accepting usb connections?
<Riddell> seb128: debian/copyright will rarely reflect every minor contributor
<mvo_> don't forget to add a COPYING.LGPL to the tarball too because some stuff in admin is LGPL
* Starting logfile irclogs/ubuntu-devel.log
(Riddell/#ubuntu-devel) I'm unsure we gain anything from having stricter New processing than Debian
(Hobbsee/#ubuntu-devel) Riddell: debian accepts the control.in files, though
<Riddell> Hobbsee: they're not entirely daft for the uploaders line, it's the build-deps where they get dangerous
<StevenK> Or package names
<Hobbsee> Riddell: this is true.  still more complex than it should be, and means that the make buildprep stuff doesnt work
<Riddell> StevenK: hmm?
<StevenK> Riddell: I can recall one instance of debian/control.in being used to automatically generate a debian/control to put the version number from debian/changelog into a package name.
<Riddell> now that's nuts :)
<StevenK> Right. :-)
<Riddell> seb128: do you check for new copyright holders with each new upstream version of anything you package?
<seb128> Riddell: no, I usually have a quick look on the diff but that's about it
<seb128> Riddell: I'm pretty sure most of packagers don't update the copyright holders
<seb128> why?
<Riddell> seb128: I disagree with requiring debian/copyright to have every minor copyright holder given that it'll get out of date as soon as there's a new upstream release where someone else has contributed a few lines
<seb128> Riddell: well, I've no strong opinion about it, I just don't want to screw
<seb128> Riddell: if we say that admin directory from KDE packages doesn't need to be listed in debian/copyright that's fine with me
<seb128> having a policy about those would be nice though
<Riddell> well you know my opinion :)
<Riddell> pitti, Mithrandir, cjwatson, elmo: got an opionion on whether debian/copyright needs minor authors such as those in KDE's admin/ directories?
<elmo> what's in the admin/ directory?
<seb128> admin/conf.change.pl is under LGPL also, dunno if it should be listed in debian/copyright
<seb128> elmo: a bunch of build scripts
<seb128> elmo: you can use kdesudo in the NEW queue as an example if you want to have a look
<elmo> seb128: I have no idea how to even look at NEW packages in soyuz and no desire to learn ;-)
<seb128> ;)
<elmo> basically, I'm not sure where the 'must have all authors in debian/copyright' meme came from
<azeem> germany
<elmo> personally, I don't think it's useful or pragmatically enforcable
<pitti> http://people.ubuntu.com/~ubuntu-archive/queue/gutsy/new/kdesudo_1.1-0ubuntu1.dsc
<pitti> (FYI)
<seb128> k
<seb128> so let's not bother
* pitti nods
<seb128> and admin/conf.change.pl being LGPL, should the copyright mention it? (rest of the package is under GPL)
<elmo> LGPL can be promoted to GPL, so again, I think that's moot
<seb128> elmo: thanks
<pitti> you mean 'promoted' == you can treat an LGPL source as if it were licensed under GPL
<pitti> ?
<seb128> Riddell, Tonio_: kdesudo accepted, enjoy ;)
<Riddell> yay, thanks seb128
<Tonio_> seb128: oki :)
<seb128> you're welcome
<Hobbsee> yay!
<Riddell> pitti: main inclusion report pending for kdesudo now :)
<elmo> pitti: yes
<elmo> pitti: section 3 of the LGPL
<Riddell> interestingly it can be changed to GPL 2 or later, even if the LGPL code is LGPL 2 only
<elmo> well, technically you're meant to change the copyright, file, but badger to that
<Riddell> we do include a copy of the LGPL
<seb128> Riddell: small detail, libeigen-dev section should be libdevel
<pitti> seb128: (you can override it in the queue if you want)
<seb128> pitti: still better to fix it in the package though no?
<Riddell> yeah, I'll fix it in the package
<pitti> seb128: of course
<seb128> good ;)
<jamesh> jwendell|lunch: it does not have USB support yet
<jamesh> jwendell|lunch: I've got all the hardware to test USB support though, so it shouldn't be too difficult to implement
* pitti marks apport-crash-duplicates as implemented \o/
<iwj> This is TOTALLY FREAKY.  gdm's greeter loops infinitely generating bogus attempts to log in as user="" password="" but only if the X server is using is not on the currently displayed VC.
<jwendell> jamesh, great news, if i can help by testing...
#ubuntu-devel 2007-07-26
* #ubuntu-devel  [freenode-info]  if you need to send private messages, please register: http://freenode.net/faq.shtml#privmsg
<Kano> btw fuse 2.7.0 is in sid now. please update gutsy too
<Hobbsee> ...how often does google send legit emails to people, vs all the jobspam from people who *arent* google?
<crimsun> I don't believe I've ever received unsolicited email from Google.
<Hobbsee> i more meant people pretending to be google, who actually arent
<ajmitch> google will send *anyone* job spam
<ajmitch> crimsun: that is rather surprising
<Hobbsee> ajmitch: it's targeted.  ish.
<ajmitch> Hobbsee: I know
<Hobbsee> weird.
<jdong> Hobbsee: good evening hobbsee. I am hajan, the deposed prince of nigeria.
* StevenK scoffs
<jdong> Hobbsee: I need your help getting $60,000 out of the country. I'd like to deposit it in your bank account but first need you to wire me $100USD to ensure that it works.
<TheMuso> heh
<Hobbsee> jdong: hahaha
<jdong> lol :)
<Hobbsee> some woman in adelaide actually fell for that recently  30K
<jdong> reading my spam folder is NOT a healthy habit :D
<jdong> Hobbsee: that's NOTHING
<jdong> Hobbsee: the US apparently records like $15million a year in money lost to the nigerian scams...
<jdong> Hobbsee: that statistic amazes me
<TheMuso> ouch
<Hobbsee> jdong: yeah...but by one person?
<jdong> and worst... it's probably those philanthropic older generation people who are falling for this stuff
<jdong> Hobbsee: haha, not by one person :)
<Hobbsee> yeah - that was by one person, which is why i was so surprised
<jdong> Hobbsee: ouch that sucks... and once that money is gone, it's gone.
<Hobbsee> exactly
<jsgotangco> jdong: i've witnessed that too in a former workplace...never asked us before they proceeded
<calc> Hobbsee: hi :)
<Hobbsee> heya calc!
<Hobbsee> calc: how's it going?
<calc> Hobbsee: pretty well
<Hobbsee> calc: is married life fun?
<calc> Hobbsee: got married last saturday
<Hobbsee> i know :
<Hobbsee> * :)
<calc> Hobbsee: ah ok
<calc> Hobbsee: merging bits of ooo 2.3 so i can upload it eventually
<TheMuso> calc: Yet you're not on your honeymoon
<calc> TheMuso: no vacation time available yet
<TheMuso> ah
<Hobbsee> calc: ahhh
<calc> we went off for the weekend, going on a cruise next year when i have some time available
<TheMuso> Nice.
<Hobbsee> yeah, working a new job probably isnt helpful for leave
<ajmitch> calc: oh, congrats & all :)
<calc> ajmitch: thanks :)
* calc been merging some ubuntu stuff back into debian ooo bzr
<calc> hopefully rene doesn't get annoyed, heh
<StevenK> calc: When is OO.o 2.4 due?
<ajmitch> a debian developer, getting annoyed by ubuntu changes? never...
<calc> StevenK: next spring
<Hobbsee> StevenK: soon after he manages to get oo.o 2.3 built.
<calc> StevenK: we are planning to just use 2.3.1 in ubuntu+1
<StevenK> Heh
<calc> so that the LTS doesn't have a potentially buggy version
<calc> or at least less buggy than usual
<StevenK> Ah, so 2.3 isn't a development release?
<calc> no
<calc> at least not that i know of
<calc> i think 2.1 just got skipped due to the timing of releases
<calc> 2.1 dec06 2.2 mar07
<StevenK> Ah. They decided in December to bin 2.1 and aim for 2.2 in March
<calc> 2.3 sep07 2.4 mar08 3.0 sep08
<calc> StevenK: oh ok, didn't know about that
<calc> so we will end up skipping 2.4
<calc> gutsy 2.3.0 gutsy+1 2.3.1 gutsy+2 3.0 is what i am planning on so far
<StevenK> calc: That was a guess, sorry
<calc> StevenK: ah well i don't know anything about 2.1 other than that we skipped it for ubuntu afaik
<calc> StevenK: so you know as much as me about that ;)
<pitti> Good morning
<Hobbsee> pitti!
* Hobbsee hugs pitti 
* pitti hugs Hobbsee back
<Hobbsee> :)
<StevenK> piMorning pitti!
<pitti> hey StevenK
<StevenK> pitti: Can you give back gabber on all arches again?
* StevenK has fixed libglade, so it should actually build this time.
<pitti> StevenK: done
<StevenK> pitti: Thanks.
* StevenK grumbles about gnome-config
<bryce> what does "give back" mean?
<pitti> bryce: try again to build a package if it failed previously
* Hobbsee wonders when ooo, etc, will be fixed
<StevenK> Hobbsee: RSN :-P
<Hobbsee> StevenK: i hearby voluntell you to fix it.
<StevenK> Hah
<ajmitch> morning pitti
<pitti> hey ajmitch
<StevenK> pitti: Would you mind terribly running checkrdepends on drescher for libdb3{,-dev}?
<pitti> StevenK: http://people.ubuntu.com/~pitti/tmp/db3-rdepends.txt
<StevenK> pitti: Thanks!
<pitti> StevenK: thanks to you!
<StevenK> Hrm, no build depends on libdb3-dev.
<StevenK> And a *whole* bunch of libdb3 rdepends. Enough that I don't really want to touch them, it being ~ 53 packages.
<pitti> StevenK: a lot of those packages look like totally unrelated to libdb3
<pitti> StevenK: it seems that the libtool disease is at fault here
<StevenK> Yes.
<pitti> (promoting dependencies to transitive dependencies)
<pitti> I bet that a lot of packages won't depend on any libdb any more with -Wl,--as-needed
<StevenK> Well, do we want to look at killing libdb3 completly for Gutsy?
<pitti> StevenK: while it would be a nice target, I don't think that we should waste much developer time on it TBH
<pitti> StevenK: it'll happen in Debian eventually anyway
<pitti> and us doing the transition in Ubuntu won't even help Debian (much, at least)
* StevenK nods.
<StevenK> pitti: I was curious to see how much did depend on libdb3.
<StevenK> Oh, gah
<StevenK> gabber fails again.
<pitti> bryce: requestsponsor> oh, I didn't touch that for a looong time
<pitti> bryce: and in fact I should rewrite it to use proper attachments instead of pasting the diff into the description (LP allows this now)
<bryce> pitti: ahh.  I thought it was new
<pitti> bryce: replied to your mail with more details
<bryce> cool
<pitti> hi thekorn
<thekorn> hi ptti
<Hobbsee> guten morgen, mvo
<mvo> hey Hobbsee
* Hobbsee beats mvo over the head with the apt bug, as requested.
<Hobbsee> mvo: :)
* mvo understands a hint when he sees one and goes to fix that apt issue
<Hobbsee> mvo: well, in truth, i was going to say hello to you anyway, but that was too good an opportunity to give up.  do you want the number?
<mvo> Hobbsee: if you have it at hand, but I remember what the issue was I think
<Hobbsee> mvo: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/125928
<ubotu> Launchpad bug 125928 in ubuntu-restricted-extras "Recommends in main "metapackages" get installed, but not universe "metapackages"" [Medium,Fix released] 
<Hobbsee> ubotu isnt very smart, when it comes to the same bug effecting multiple products.
<mvo> yep
<mvo> thanks Hobbsee
<Hobbsee> mvo: no problem.  thanks in advance for fixing.
* mvo prepares a cup of tea to prepare
<desrt> mvo; too much preparation
<desrt> mvo; tea isn't something you can think too much about.  it ruins it.  you just have to feel it.
<Hobbsee> desrt!
<pitti> Nafallo: bug 127836 approved
<ubotu> Launchpad bug 127836 in bacula "[SRU]  bacula-director-pgsql not installable" [Medium,In progress]  https://launchpad.net/bugs/127836
<pitti> desrt! *hug*
<desrt> hello hobbsee, pitti
<desrt> pitti; missed you at guadec :(
* desrt is currently experiencing a 3am inability to sleep
<mvo> desrt: friendly-recovery got in :)
<desrt> mvo; nice.  upstart glue yet?
<mvo> desrt: haven't really checked, but it magically worked for me (installing the pkg was enough), so I guess yes
<desrt> spiffy
<mvo> some more plugins and i18n and it rocks the boat
<desrt> ahh.. i18n
<desrt> can you i18nify shellscript? :)
<desrt> gettext(1).  nice.
<mvo> I have never writen a POTFILE.in with shell in it, I'm curious :)
<mvo> desrt: https://code.launchpad.net/~mvo/friendly-recovery/ubuntu (just fyi)
<desrt> how bizarre....
<desrt> (ha ha ha.  i crack me up.)
<StevenK> desrt: Booo, hiss
<Nafallo> pitti: thanks :-)
<Tonio_> seb128: ping ?
<seb128> Tonio_: pong
<Tonio_> seb128: hi ;) sorry for bugging you but I have a little packaging question...
<Tonio_> seb128: in a cdbs packaging how would you perform something before patches are applied ?
<Tonio_> seb128: easy to perform a post-patches or makebuilddir thing, but nothing comes to my mind for "pre-patches" task
<pitti> Tonio_: pre-build::
<Tonio_> pitti: does that exist ?
<pitti> Tonio_: yeah, see /usr/share/cdbs/1/rules/buildcore.mk
<pitti> # This target is called before almost anything else happens.  It's a good place
<pitti> # to do stuff like unpack extra source tarballs, apply patches, and stuff.
<Tonio_> pitti: oki, cdbs doc misses infos on that point
<seb128> Tonio_: what pitti said ;)
<Tonio_> seb128: yeah, I was just lost since there is almost no doc on that point
<seb128> just curious what do you need to do before applying the patches?
<seb128> yeah, better to read the source with cdbs sometimes
<Tonio_> seb128: in fact knetworkmanager was released without the famous admin/ dir
<Tonio_> so mbiebl copies it from a kapptemplate builddep
<Tonio_> seb128: the point is that he copies the files within post-patches
<Tonio_> seb128: and we have to patch admin/ for rosetta :)
<Tonio_> seb128: weird, I know, but that's what I have to in that very specific context..... the issue is btw upstream, they should provide that admin/ dir
<seb128> Tonio_: I would just edit admin directly and get the changes in the diff.gz
<siretart> asac: re bug #121439 with 'toggling' the rf-switch, we meen switch it off and on
<ubotu> Launchpad bug 121439 in network-manager "[Gutsy] Network Manager Applet can't connect wireless with ipw3945 driver" [High,Incomplete]  https://launchpad.net/bugs/121439
<Tonio_> seb128: I would have done that that way, but I want to stay sync with debian :)
<seb128> right
<asac> siretart: how?
<siretart> asac: what do you mean with 'how'? by turning it on and off
<siretart> asac: there is a little slider on the front of my notebook, I switch it to the left and then to the right
<asac> ah ... ok
<asac> nothing i can do then :)
<asac> siretart: are you on feisty?
<siretart> asac: no, I'm on gutsy
<asac> siretart: can you summarize your behaviour? open-network doesn't work, while wpa does?
<asac> siretart: sorry ... but the bug is pretty busted by lots of different symptoms claimed
<siretart> asac: right
<siretart> asac: there are in fact several bugs here
<siretart> asac: let me explain how I connect to my home wifi
<siretart> asac: NM tries to connect to my AP, it takes several secs. In this timeframe, I need to toggle the switch
<siretart> asac: then I get a dialog presented to enter my password. I say cancel here
<siretart> asac: then I try again to connect, this time it works, but disconnects after 0.5 seks
<siretart> asac: then I select my home network a third time, then I have a connection
<asac> siretart: wpa?
<siretart> asac: and I can reproduce this behavior since about 3 weeks
<siretart> asac: yes, this is a WPA2 secured network
<asac> right ... lets try to figure this out
<asac> siretart: ok
<siretart> with open networks, I only get the 2nd bug
<asac> can you post a log in pastebin?
<siretart> which was reported seperately
<Amaranth> dude i gave up on wpa2 and switched to WEP
<asac> ok lets go for wpa first
<Amaranth> figure no one here will be able to get in anyway and i didn't want to mess with wpa_supplicant
<siretart> asac: the 2nd bug is pretty well described in #124706
<siretart> bug #124706
<ubotu> Launchpad bug 124706 in network-manager "NM sometimes drops connection before associating, logfile says assertion `dev != NULL' failed " [Undecided,New]  https://launchpad.net/bugs/124706
<asac> siretart: you have a log for wpa?
<siretart> yes, but its rather long, and I'd rather pass it to you privately via email
<asac> siretart: for wpa: are you asked for passphrase?
<asac> siretart: how long does it take until wpa_supplicant/nm gives up?
<siretart> asac: I guess about 10 seconds
<asac> does it fall back to wired then?
<asac> siretart: ok ... can you see if wpa_supplicant tries ap_scan 2 ?
<siretart> it doesn't fall back to wired, since there I have no wired connected
<siretart> I sent you the log
<asac> ok
<siretart> asac: btw, network manager gives wpa_supplicant the AP_SCAN 1 command
<asac> ok
<asac> can you test without going offline in irc?
<siretart> asac: I suspect I'm presented the dialog because wpa_supplicant didn't associate within some timeout, so nm assumes the key was wrong and asks for a new key. it would help if the dialog would indicate that
<siretart> asac: I'm at work, and have no wireless here
<asac> ok
<asac> let me wait for the log
<siretart> I sent it to asac@u.c
<asac> yes
<asac> now got it
<siretart> asac: the log starts when I got home. The 131.188 ips are my 'universitary' ips, avahi does recognize at once that I'm now at home
<siretart> asac: my home ips start with '192.168...'
<asac> asisak: at first you got an ip?
<asac> Jul 25 21:42:50 faui44a NetworkManager: <info>    address 192.168....
<asac> ?
<asisak> asac: I don't use n-m
<asac> sorry siretart ^^
<siretart> asac: that is step 3 I outlined above. yes
<asac> siretart: i don't see that eth1 is torn down in logs
<asac> siretart: looks like its still up with that ip
<siretart> asac: the applet told me something else
<asac> siretart: ok ... i think we have to test this by using wpa supplicant manually
<siretart> asac: when I use wpasupplicant manually, everything works like expected
<siretart> asac: I'm out for lunch now, I'll ping you when I'm back
<asac> siretart: what do you mean by manually?
<asac> config ?
<asac> i mean by using wpa_cli
<asac> and just inject the commands that nm sends to it
<iwj> seb128: Are you about ?  Would you have time now to talk about my gtk+ problem ?
<seb128> iwj: hey. Yes, I have. I asked you for details yesterday but you didn't reply (or I didn't read it) ;)
<iwj> Yes, I didn't reply yet.
<seb128> ok
<iwj> So: this is for consistent-login-screen.  One thing I'm doing is having gdm prompt for user/pass and then when accepted, start a new X server with the session in it.
<iwj> The original X server goes back to the login screen.
<iwj> This all works fine so far except that the gdm greeter issues the gdm login prompt slave with an endless series of blank usernames and blank passwords.
<iwj> This only happens _while the login X server is not current_.
<iwj> That is, if you switch back to the original VC manually it all works fine.
<iwj> I tore my hair out and added lots of debugging code and I think what is happening is that the switched-away-from X server doesn't generate the key up event for the return key.
<iwj> And in the meantime gtk+ synthesises a whole bunch of autorepeats.
<iwj> My questions are: is this plausible ?  And what would be the best way to deal with it ?
<iwj> My debugging code shows a lot of   Jul 25 17:36:00 samual15 gdmgreeter[15083] : DEBUG: iwj KEY_PRESS 65293 (state=0x0)
<iwj> which is what you see when return is pressed.
<seb128> hum, so that happens when you press enter to validate the password?
<seb128> the VT is switched and it keeps sending key pressed event on the username,password entry?
<iwj> Yes.
<iwj> Well, there is a continuous stream of these key pressed events.
<iwj> I don't know for sure where they're coming from.
<seb128> do you have a callback attached and to what signal?
<Amaranth> couldn't you just wait for a key up event before doing the vt switch?
<iwj> Amaranth: There are (at least) three processes involved.
<iwj> The original code has firstly a callback attached to `activation' of the text entry field.
<Amaranth> yay overdramatic security
<iwj> No, just a complicated job best done in several pieces.
<iwj> And secondly it has an event hook which does some massaging of incoming events, for example to map button 3 to button 1.
<seb128> iwj: does your callback return TRUE to indicate that the event has been handled?
<iwj> It's not my callback.
<iwj> It was there to start with.
<Amaranth> i thought TRUE meant 'pass through to another handler'
<seb128> Amaranth: http://www.gtk.org/tutorial/x1812.html
<iwj> I haven't changed the greeter (which is what's malfunctioning) at all.
<seb128> hum, k
<iwj> Well, I have now, because I've filled it full of printfs.  But apart from that :-).
<mvo> iwj: when you recive the final newline, can you try "whilte gtk_events_pending() gtk_main_iteration(); "?
<seb128> I don't know, it's possible that the key release event goes to the wrong screen
<Amaranth> seb128: oh, pygtk must flip it
<seb128> but that would be weird
<Amaranth> or i've been in compiz and web stuff too long to remember :)
<seb128> Amaranth: that would be a stange idea from them do that
<iwj> seb128: Err, quite possibly but I think not because the repeating stops when I switch VC back.
<iwj> I think the key up event is just delayed.
<iwj> That is the key up X event.
<iwj> Does gtk+ synthesize autorepeat itself ?
<seb128> not sure what you can do out of waiting for the key release event before switching then
<seb128> not that I know, no
<cjwatson_> Amaranth: pygtk doesn't flip it. http://www.pygtk.org/pygtk2tutorial/sec-Events.html
<seb128> Amaranth, mvo: will compiz work on the second X server?
<Amaranth> seb128: not at all
<mvo> no
<iwj> Joy.  I straced the X server to see if it was generating these events and it's wedged.
<Amaranth> not for a few more years, at least
<mvo> and it will not in the near future from all I understand
<seb128> iwj: you have started on it now but I don't think working on it is really useful
<seb128> iwj: compiz will be on by default and only works on the first server
<mvo> iwj: could you try that event-processing thing before switching? I'm curious if that helps
<iwj> seb128: !
<seb128> gdm is being rewritten upstream to use gobject
<Amaranth> iwj: DRI is awesome, no?
<iwj> What's gobject got to do with it ?
<seb128> and fast user switching using consolekit (what FC7 did) works quite fine (don't have to enter a password twice, etc) ... you just have the flickering on VT switch
<seb128> iwj: basically they rewritte most of the gdm internals
<Amaranth> this is why i liked the Xgl/Xnest idea :)
<iwj> seb128: Oh errm.
<seb128> which means the modifications we do will need to be done again next cycle
<iwj> Nice to discover this now :-/
<Amaranth> seb128: afaik it's already done
<seb128> they talked about it at GUADEC
<iwj> Ah.
<Amaranth> gdm3 branch in svn seemed quite complete
<seb128> Amaranth: it's not planned for this cycle and I didn't know there was so much changes
<Amaranth> from what i understood it already worked in some form
<iwj> My changes to gdm are relatively small but if they're completely overhauling the innards (which need it!) then I'm at the very least working on the wrong branch.
<Amaranth> probably not feature complete compared to gdm2 and such though
<iwj> seb128: What's consolekit ?
<Amaranth> iwj: session management stuff
<seb128> iwj: apt-cache show consolekit
<Amaranth> !info consolekit gutsy
<ubotu> Package consolekit does not exist in gutsy
* Amaranth is lazy
<Amaranth> ack
<iwj> seb128: And in gutsy+1 this will work with the then-prevailing gdm ?
<seb128> Amaranth: I've synced it from Debian yesterday, might not be uptodate
<iwj> Amaranth: universe
<Amaranth> seb128: should find the slides :)
<Amaranth> iwj: nah, ubotu is just slow to update (once a week or something)
<seb128> iwj: well, using consolekit will work in gutsy, FC7 already uses it and the code landed to GNOME upstream, it solves the "having to enter several times your password" and other usuability issues
<iwj> Right.
<seb128> it doesn't solve the "flicker and it ugly"
<iwj> The point of consistent-login-screen was to get rid of the hideous useability problems.
<seb128> right
<iwj> Not that I'm really keen on a dbus-based answer.
<iwj> Cont pp.94 etc.
<Amaranth> http://lists.freedesktop.org/archives/hal/2007-January/006996.html
<seb128> I did point you to the fedora spec when we discussed xgl some weeks ago I think, that's basically that they implemented
<seb128> I've seen it working at GUADEC, it works nicely
<iwj> Implemented in the last few weeks ?
<seb128> not to mention that the current Ubuntu spec way conflicts with compiz since compiz will no work on the second xorg server
<iwj> Right.
<seb128> iwj: for fedora 7, not sure for how long it's available, a few weeks now I think
<Amaranth> fedora 7 came out in may, iirc
<iwj> Do you reckon we should try to push consolekit into gutsy instead ?
<Amaranth> that's when i started getting swamped with dupes of a crash for alacarte
<iwj> I mean, gutsy main installed-by-default.
<seb128> iwj: yes, I asked pitti to have a look yesterday
<iwj> pitty: ^
<seb128> to know if he consider it sane to use
<pitti> I didn't look yet
<iwj> Wait a moment, if consolekit does it with VC switching then how does it solve the `compiz on first server only' problem ?
<iwj> pitti: OK, I can.
<Amaranth> iwj: it doesn't
<Amaranth> iwj: only Xgl solves that one
<seb128> iwj: it doesn't, only the first user will have compiz
<cjwatson> I can understand why you can only have compiz on *one* server
<iwj> But doesn't it also do a VC switch between login screen and actual session ?
<Amaranth> cjwatson: the first server to come up grabs the dri/drm lock for itself
<cjwatson> why does it have to be the *first* one? assuming that gdm isn't using DRI that is
<cjwatson> oh, it's at the server level? ok
<seb128> iwj: it's pretty much the current way, the switching logic is better only
<iwj> The current code in gdm is a bit of a mess.
<seb128> iwj: I don't think gdm keeps using a VT, no
<Amaranth> i suppose you could have a custom xorg.conf that disables DRI for the gdm server
<iwj> seb128: Hmm.  Not sure I approve of the lack of trusted path but I don't want to swim upstream.
<Amaranth> but then only the _second_ server will be able to use compiz, even if they actually use metacity or ratpoison
<cjwatson> Amaranth: right, that would be no worse than the current situation though
<Amaranth> cjwatson: sure
<iwj> seb128: So since you're being a mine of information (thanks!) do you happen to know whether Xephyr is at all useful ?
<StevenK> infinity: Ping, re: libnss-db
<iwj> I mean, is it any good.
<iwj> I tried it but it died and I didn't bother debugging it.
<Amaranth> iwj: hey i think xephyr can do glx
<iwj> Amaranth: That's why I'm asking :-).
<Amaranth> with this new aiglx magic
<seb128> iwj: dunno about it
<iwj> seb128: OK.
<infinity> StevenK: pongish.. I'll look at it later tonight, after I've done some lpia and random IS work.
<Amaranth> i saw something on the xorg list about it yesterday
<StevenK> infinity: Okay, cool
<Amaranth> i know it can do Render, not sure about Composite
<iwj> Amaranth: There shouldn't be any difficulty in principle.
<iwj> The question is really code quality.
<Amaranth> well, i think keithp wrote it
<Amaranth> and everyone seems to think it's so great they pretend xnest doesn't exist anymore ;)
<Amaranth> iwj: "Unlike Xnest it supports modern X extensions ( even if host server doesn't ) such as Composite, Damage, randr etc."
<iwj> Oh, bloody hell.
<iwj> Did I mess much ?
<Amaranth> iwj: "Unlike Xnest it supports modern X extensions ( even if host server doesn't ) such as Composite, Damage, randr etc."
<Amaranth> glx doesn't seem to work though :/
<iwj> Hmm.
<seb128> Amaranth: gdmflexiserver --xnest user xephyr now when available
<seb128> I just tried, compiz doesn't start in it
<seb128> "Checking for Xgl: not present."
<cjwatson> compiz 1:0.5.1+git20070725-0ubuntu1 produces uninstallable binaries: * compiz (amd64 i386)
<cjwatson> hmm, that can't be good
<seb128> cjwatson: weird, I've this version installed
<cjwatson> it's the CD health checks
<seb128> ah
<seb128> I depends on compiz-fusion-plugins-extra again
<seb128> which is in universe
<seb128> dholbach fixed it for tribe-3
<cjwatson> has anyone done a MIR for that yet?
<seb128> maybe he didn't commit to bzr?
<cjwatson> I'd rather promote it if we need it than kill the dep
<seb128> mvo: did you revert the change on purpose?
<seb128> cjwatson: https://wiki.ubuntu.com/MainInclusionReportCompizFusionPluginsExtra
<cjwatson> pitti,iwj: could somebody review the above?
<mvo_> seb128: yes
<pitti> yes, can do
<iwj> pitti: You do that, I'll take a look at consolekit.
<iwj> First I think I need a cup of tea.
* StevenK kicks gabber.
<pitti> iwj: ok, thanks
<pitti> StevenK: still no build love?
<pitti> iwj: I'll have a look at CK, too; such kind of software deserves may eyes
<mvo_> seb128, pitti: hm, looking at this again we may not need it in main afterall, -extra was required for trailfocus, but we decided to not use trailfocus later
<StevenK> pitti: Right. I've reproduced it locally, too.
<StevenK> libtool: link: cannot find the library `/usr/lib/libdb3.la' or unhandled argument `/usr/lib/libdb3.la'
<StevenK> Sure, I know exactly why you can't find it. But why are you even looking!?
<iwj> pitti: Sure.
<seb128> StevenK: grep "libdb3.la" /usr/lib/*.la
<pitti> StevenK: ah :) "KILL ALL .la FILES! KILL'EM, KILL'EM!"
<mvo_> seb128, pitti: crap, sorry. extrawm is required for stickiness of wndows
<iwj> I was going to actually install it here and give it a run for its money.
<mvo_> seb128, pitti: so we need it afterall
* mvo_ runs for lunch before he confuses even more people
<seb128> hum, lunch
<seb128> good idea ;)
* mvo_ hugs seb128 pitti and runs off
<pitti> mvo_: looks easy enough
* StevenK does a build in pbuilder so he gets a shell on build failure.
* seb128 hugs mvo_
<Amaranth> iwj: apparently glx in xephyr is a compile-time option
<pitti> seb128: since last dist-upgrade, gdm doesn't load the default theme any more and complains about not finding  some debian/moreblue thing; instead I get the blue theme with the flower
<iwj> Amaranth: Shouldn't we just enable it ?
<seb128> pitti: please open a bug, I merged with Debian and that was not trivial (we had a different packaging for some cycle)
<Amaranth> iwj: indeed
<seb128> pitti: I made have made some mistakes
<pitti> seb128: ok, I'll do that; thank you!
<seb128> you're welcome
<seb128> anyway, lunch time, be back later
<Amaranth> iwj: if i can figure out how :)
<StevenK> pitti: Right, -ldb-3 and /usr/lib/libdb3.la appear in both /usr/lib/libglade-gnome.la and /usr/lib/libgnomemm.la
<StevenK> pitti: At this point I'd like to add "Bloody libtool!"
<pitti> StevenK: evil :/
<pitti> StevenK: yeah, I think those la files contribute a lot to the superfluous dependencies we have in Debian/Ubuntu
<iwj> pitti: consolekit seems to like having a secret in your environment.
<siretart> asac: by manually I mean by using /etc/network/interfaces, which also uses nothing else than wpa_cli to configure wpa_supplicant
<iwj> I haven't figured out what the secret can be used for yet but I'm not sanguine.
<StevenK> pitti: Re-upload gnomemm (whatever package it's in) and glade removing the .la files?
<Amaranth> iwj: all it'll get you is a nice mute signal when the session changes
<Amaranth> or some other sort of pause
<pitti> StevenK: ywah
<pitti> StevenK: s/w/e/
<StevenK> Bloody libtool!
<iwj> Amaranth: So why is it described as a secret then ?  That sounds harmless.
<Amaranth> iwj: it's just a unique identifier
<StevenK> pitti: Do you think I can move gnomemm and glade to cmake from autotools in Ubuntu changes? :-P
<Amaranth> a way of figuring out what processes belong to what session
<cjwatson> Amaranth: what could you do by pretending to belong to a different session?
<Amaranth> cjwatson: like i said, get yourself paused somehow (or unpaused, i suppose)
<cjwatson> what does "paused" mean in this context
<cjwatson> ?
<Amaranth> the idea is when you switch to another user either your sound will get muted or apps playing video/audio will get some sort of signal to pause their playback
<pitti> StevenK: isn't it enough to just remove the .la from debian/*.install?
<Amaranth> i don't think that part is actually implemented yet though
<pitti> StevenK: I wouldn't worry about the packaging a lot
<Amaranth> and i suppose if you got the kernel involved you could increase the priority for the current session (scheduling-wise) and then an app could hog your CPU changing it's cookie to match the current session
<Amaranth> but as of right now another app faking it's in your session doesn't give it anything
<iwj> I see.
<StevenK> pitti: Apparently, libglade doesn't have any *.la files in the source
<pitti> StevenK: they are generated during build
<StevenK> Ah
<StevenK> And no debian/*.install
* StevenK digs in debian/rules
<iwj> Amaranth: Looking at the code I think you are probably right but it shouldn't be described as a secret.
<StevenK> Ah ha, it uses dh_movefiles.
<iwj> Indeed there's special code to check the calling uid in some cases.
* pitti grumbles about so many ImportErrors from python programs; I wish python-{central,support} wouldn't break python modules on every upgrade
<StevenK> pitti:   * Stop the .la files being installed while I'm at it. If I find the libtool authors ...
<Amaranth> iwj: yeah, secret is the wrong word, it's just a cookie
<pitti> StevenK: heh
<iwj> seb128: So this FC7 consolekit demo involved their new gdm ?
<StevenK> C'mon gabber, you want to build sucessfully this time.
<StevenK> Mainly because I'm sick of fixing things you Build-Depend on.
<StevenK> Sigh. Looks like gnomemm needs fixing too.
<geser> mvo_: as you seem to deal with compiz: is there a way to make emerald the default window decorator for me?
<cjwatson> Riddell: kdesudo> note that ubiquity will need changed to use kdesudo rather than kdesu
<Riddell> cjwatson: our kdesudo package currently does dpkg-divert to take over /usr/bin/kdesu
<Riddell> I'm not convinced its the best approach but kdelibs seems to have "kdesu" hardcoded in various places
<cjwatson> oh, it provides the same options?
<Riddell> cjwatson: yes, we've been working on it so it now provides the exact same command line options as kdesu
<Riddell> but without the excessive complexity and asking for passwords when it doesn't need it
* Hobbsee waves
<geser> Hi Hobbsee
<Hobbsee> :)
<iwj> Riddell: diversion doesn't sound like too silly an idea then.
<StevenK> pitti: New libglade and gnomemm uploaded. I've confirmed locally that fixing those two makes gabber actually build.
<pitti> StevenK: you rock :)
<pitti> StevenK: but really, once that's done, maybe just stop worrying about libdb3; it'll sort itself out eventually, and it's not actually prone to a lot of vulnerabilities and such
<StevenK> pitti: I was planning on. :-)
<StevenK> pitti: I was going to polish off libapache2-mod-auth-plain, and then upload libapache2-mod-auth-pam and libapache2-mod-auth-plain, which will drop yada main reverse Build-Depends to one.
<Hobbsee> has someone managed to fix openoffice and friends breaking?
<mvo_> geser: try setting /apps/desktop/gnome/applications/window_manager/default to emerlad
* Hobbsee hugs mvo_ 
<StevenK> pitti: None if infinity approves of my libnss-db repackaging. *hint*
* Hobbsee wonders why gnumeric doesnt cope with .odt
<Hobbsee> sorry, .ods
<cjwatson> mvo_: have you had a chance to look at bug 71483? an acquaintance of mine was asking about it last night
<ubotu> Launchpad bug 71483 in gxine "xine breaks dapper -> edgy dist-upgrade on xubuntu" [Medium,Confirmed]  https://launchpad.net/bugs/71483
<mvo_> cjwatson: let me check
* mvo_ hugs Hobbsee
<Hobbsee> mvo_: thankyou for the bugfix :)
<seb128> Hobbsee: what breakage? the one which is likely due to GTK?
<Hobbsee> seb128: whatever makes it not start.
<Hobbsee> (process:10828): GLib-GObject-CRITICAL **: /build/buildd/glib2.0-2.13.7/gobject/gtype.c:2242: initialization assertion failed, use IA__g_type_init() prior to this function
<Hobbsee> (process:10828): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed
<Hobbsee> (process:10828): Gdk-CRITICAL **: gdk_screen_get_font_options: assertion `GDK_IS_SCREEN (screen)' failed
<Hobbsee> seb128: ^
<seb128> iwj: no, the consolekit code is in the current gdm, the rewrital is likely coming next cycle
<seb128> Hobbsee: not yet, ETOOMANYBUGS
<seb128> Hobbsee: I've fixed the glib2.0 bug which was screwing sparc though ;)
<StevenK> seb128: What about a mass giveback once it publishes?
<Hobbsee> seb128: that's a start :)
<Hobbsee> seb128: working spreadsheets would be nice too though - who runs a sparc anyway?  :P
<seb128> StevenK: already done some hours ago the mass giveback
* Hobbsee ducks
<StevenK> seb128: Cool
<StevenK> seb128: http://launchpadlibrarian.net/8571844/buildlog_ubuntu-gutsy-sparc.gnucash_2.0.5-1.1ubuntu1_FAILEDTOBUILD.txt.gz ; is that due to fallout?
<iwj> seb128: Oh.  OK, I'll try to look where to turn it on then.
<seb128> StevenK: "fallout"?
<seb128> iwj: in gdm/debian/rules, change the --with-console-kit=no
<StevenK> seb128: Something that failed to build earlier not getting published before the build of gnucash was attempted.
<iwj> So I see.
<seb128> StevenK: I think libgnomecanvas needs to be build before, maybe some other libs as well right
<asisak> maybe libgsf, libgoffice (maybe not for gnucash but for other packages)
<seb128> iwj: gnome-screensaver also have code to use consolekit, I think you don't need to rebuilt this one, it's using dbus at runtime
<StevenK> seb128: Which built 2 hours ago, with gnucash being attempted 3 hours ago. Would you mind giving it back on sparc only, and we'll see if it copes now?
<seb128> StevenK: I'm not buildd admin, ask pitti doko infinity
<TheMuso> If anybody could be so kind as to review/upload a new espeak package, as reported in bug 128137, that would be great.
<ubotu> Launchpad bug 128137 in espeak "Please upload new upstream release of espeak." [Undecided,New]  https://launchpad.net/bugs/128137
<Mithrandir> StevenK: given-back
<StevenK> Ah, right.
<StevenK> Mithrandir: Thanks
<seb128> or Mithrandir ;)
<iwj> seb128: Ta.  I'll let you know how I get on.
<seb128> iwj: np, thanks
<StevenK> Mithrandir: Do you have a hilight on 'give back' or something? :-)
<Mithrandir> StevenK: no, but I'm waiting for my slow mail server to get off its lazy backsiden
<StevenK> Heh
<StevenK> My slow mail server needs a good hard Ubuntu install.
<StevenK> I wish I could do the same to my webserver, but it's an EV5.
<Riddell> cjwatson: I've been playing with adding an edubuntu-desktop-kde seed inside the edubuntu seeds, but since it probably just wants to extend kubuntu-desktop I'm wondering if it might be better to do it within the kubuntu seeds and depend on kubuntu-desktop in the normal seed way
<Riddell> cjwatson: http://kubuntu.org/~jriddell/tmp/edubuntu-seed.diff http://kubuntu.org/~jriddell/tmp/edubuntu-meta.debdiff
<cjwatson> it's an awkward case because it's at the intersection of both
<cjwatson> I think on balance though it's better to have it in the Edubuntu seeds because the CD images would be built as Edubuntu
<cjwatson> depending on kubuntu-desktop there is interesting. Will that do the right thing with Recommends? I suspect possibly not
<cjwatson> would be worth running germinate over that to test
<Riddell> I don't plan on having any CD images, that's too much work
<Riddell> package it makes looks like this http://paste.ubuntu-nl.org/31393/
<Riddell> which doesn't look like the right thing for recommends
<cjwatson> that looks OK, it Depends: kubuntu-desktop which Recommends: the rest and is in Section: metapackages
<cjwatson> I was thinking more about what germinate would think for task generation though
<cjwatson> but if the only goal is a metapackage then your solution should work
<cjwatson> somewhere at the back of my mind is figuring out how to express relationships between seeds in different flavours of Ubuntu
<cjwatson> I've been wondering whether it might be better just to merge all the seeds into one big branch and use subdirectories for flavour-specific seeds
<cjwatson> then you could say edubuntu/desktop-kde: kubuntu/desktop
<cjwatson> might be possible to speed up the archive's cron.daily by doing that, too, since it takes a while to run germinate at the end for all flavours and all architectures
<cjwatson> and would save some of the seed merging work we have to do
<cjwatson> but would make it harder to view edubuntu/desktop as a branch of ubuntu/desktop
<Riddell> how would I find out what germinate does to the tasks?
<cjwatson> run germinate on your seeds (see its man page), and look at the resulting 'desktop-kde' file
<cjwatson> you'll want to run it in a scratch subdirectory
<cjwatson> it spits everything out to the cwd
<iwj> seb128: Well, it doesn't seem to work perfectly for me.
<iwj> It's a bit tricky because I seem to have some other problem with this machine.
<seb128> iwj: what doesn't work correctly?
<iwj> I managed to get it to get stuck on a black screen just by switching back and forth between two users.
<iwj> I'm going to try to reproduce it.
<iwj> Now I can't even get a prompt logout dialogue.
<Riddell> cjwatson: seems sane to me http://kubuntu.org/~jriddell/tmp/edubuntu-germinate/desktop-kde
<cjwatson> Riddell: right, that's missing recommends - you'll note it e.g. doesn't include bluez-utils
<cjwatson> missing transient recommends from kubuntu-desktop, I mean
<cjwatson> in practice it'll probably be OK as long as you don't need tasks, it's just something to note
<Riddell> right
<cjwatson> maybe a workaround would be to have germinate honour recommends from section: metapackages
<Riddell> ogra's at ubuntu live isn't he?
<cjwatson> rather a hack though ...
* cjwatson thought ubuntu live was finished, but he might well be travelling home
<Riddell> wonder if I should check it with him first before committing, or commit before he has a chance to complain :)
* cjwatson doubts he'll be all that bothered ...
<cjwatson> I think your diff earlier forgot to make edubuntu supported inherit from desktop-kde
<cjwatson> (makes a difference to anastacia et al)
<Riddell> right, I'll add that
<Hobbsee> mvo_: assuming you know, but compiz still falls over with kde, even with your change.
<Hobbsee> mvo_: oh wait, i think i still need to run compiz --replace
<thom> mvo_: still hiding from me? :-)
<cjwatson> Riddell: http://people.ubuntu.com/~cjwatson/tmp/germinate.recommends.diff - untested patch to make germinate follow recommends in section: metapackages
<Riddell> cjwatson: seems to work http://kubuntu.org/~jriddell/tmp/edubuntu-germinate/desktop-kde
<cjwatson> Riddell: rock on untested patches
<cjwatson> that's a big deb size, probably wouldn't fit on a CD anyway ...
<cjwatson> would anyone cry too much if lithium (i.e. CD image builds) went down for upgrade this weekend?
<cjwatson> cdimage.u.c/releases.u.c will still be available
<Hobbsee> cjwatson: absolutely :P
<cjwatson> absolutely cry, or absolutely upgrade? :P
<Hobbsee> cjwatson: the former.
<Hobbsee> cjwatson: but either works :P
<pitti> mvo_: got a minute?
<Riddell> no tears here
<Mithrandir> cjwatson: would work for me.
<pitti> np for me
<pitti> mvo_: can you please look at bug 123062? python-apt oddity
<ubotu> Launchpad bug 123062 in apport "apport-gtk crashed with AssertionError in __setitem__()" [Undecided,Incomplete]  https://launchpad.net/bugs/123062
<mvo_> thom: yes :P (but I'm back home so the pile gets smaller)
<mvo_> pitti: looking, but I may require the sources.list for this
<thom> mvo_: heh, no worries :)
<lool> doko: It's Aurlien Jarno, not Aurelian :)
<doko> lool: thanks, will fix it
<pitti> mvo_: I hope you don't actually need deb-src lines to determine the source package?
<geser> is there a way to use compiz with emerald without having to start emerald by hand?
<seb128> geser: not sure, you can hack gnome-wm as a workaround
<mvo_> geser: try setting /apps/desktop/gnome/applications/window_manager/default to emerlad
<geser> the current value of that key is compiz, does compiz still start when I change that?
<cjwatson> would somebody in ubuntu-main-sponsors please unsubscribe ubuntu-main-sponsors from bug 119572? reason's given in the bug
<ubotu> Launchpad bug 119572 in iso-codes "wrong English names in iso-codes (dup-of: 124657)" [Medium,Confirmed]  https://launchpad.net/bugs/119572
<ubotu> Launchpad bug 124657 in iso-codes "Candidate Revision for iso-codes_1.0a-1ubuntu1" [Undecided,New]  https://launchpad.net/bugs/124657
<cjwatson> I was about to do it but realised I'm not in the team
<cjwatson> er, yeah, the latter bug
<geser> mvo_: I tried setting /apps/compiz/plugins/decoration/allscreens/options/command to emerald, but the description mentions that it's only used when no decorator is running an the compiz wrapper starts gtk-window-decorator
<geser> mvo_: btw does gnome-compiz-manager still work with compiz fusion? I'm currently using compizconfig-settings-manager to configure compiz as gnome-compiz-manager didn't work on my last test
<StevenK> cjwatson: Unsubscribed
<StevenK> cjwatson: I'm sure if you asked pitti nicely, he'd add you to ubuntu-main-sponsors. :-P
<keescook> I snagged it.  :)
<cjwatson> StevenK: I just requested joining, in fact
<cjwatson> (pitti's membership of ubuntu-main-sponsors is deactivated ...)
<keescook> cjwatson: I've approved you.
<cjwatson> keescook: thanks!
<keescook> no problemo!  :)
<StevenK> Ah, keescook, dholbach and seb128 are admins
<pitti> hey keescook
<StevenK> I thought of pitti because he approved me when I joined
<keescook> hiya pitti
<mvo_> geser: hm, I'm afraid there is currently no easy way to set emerald, that needs to be fixed
<mvo_> geser: I think gnome-compiz-manager would need a update at least (haven't checked though)
<geser> keescook: Hi, is bug #124725 still in your work queue?
<ubotu> Launchpad bug 124725 in fireflier "[CVE-2007-2837]  Unsafe tmp file handling" [Undecided,Confirmed]  https://launchpad.net/bugs/124725
<keescook> say, cjwatson, I'd like to chat about the apparmor bits -- what was added to the seeds?  If we're forcing the apparmor module to load in an install, it will block (future) selinux stuff.  I'd like to avoid that.
<keescook> geser: it is, yes.  let me go comment on it.
<geser> mvo_: should I file a bug about the emerald thing?
<geser> mvo_: do we really need two programs to configure compiz?
<StevenK> geser: It's only that the other four aren't packaged yet.
<geser> StevenK: there exists 6 programs already to configure compiz?
<pitti> keescook: apparmor-utils is standard Recommends: now, i. e. installed by default (with apparmor as dependency)
<StevenK> geser: Joke.
<StevenK> But probably.
* cjwatson wonders why http://daniel.holba.ch/sponsoring/ still lists bug 119796
<ubotu> Launchpad bug 119796 in openbox "please sync openbox 3.4.2-1 from Debian unstable (main)" [Wishlist,Confirmed]  https://launchpad.net/bugs/119796
<seb128> pitti, keescook: should I do something about bug #128159? There is a CVE number mentioned
<ubotu> Launchpad bug 128159 in gaim "Jabber: Client and OS version visible to authorized buddies" [Undecided,New]  https://launchpad.net/bugs/128159
<cjwatson> does it list both main and universe sponsoring requests?
<keescook> pitti: so people wanting selinux will be able to uninstall apparmor (since it's not a depend)?
<cjwatson> ah, yes, apparently so
<cjwatson> oh well, as long as my browser never visits https://bugs.launchpad.net/~ubuntu-universe-sponsors, I can see which is which from the visited-link colour at the right
<keescook> seb128: I'm on the fence about OS version disclosure.  pitti, do you have an opinion about it?
<pitti> keescook: right
<keescook> geser: look good; I will get it spun up.  :)
<seb128> keescook: I'm surprised it got a CVE
* Ng hmms at notification daemon. I was about to file a bug about it crashing, but i think I've been beaten to it ;)
<pitti> keescook: I have no context; a server discloses OS version?
<seb128> Ng: there is tens of crashing bugs about it
<pitti> keescook: doesn't nmap detect this, too, nowadays?
<keescook> pitti: no, the gaim client responds with detailed version info to a query.
<seb128> pitti: you can get OS informations from random contacts (no need to have been accepted in their buddy lists)
<Ng> seb128: yeah. weirdly I didn't get any apport stuff about it
<keescook> pitti: yeah, there are many way to detect such things, but usually with less precision.
<pitti> seb128: you mean gaim sends out that information to anybody? getting them from other clients is hardly a vuln
<seb128> pitti: yes, if I add you to my jabber list and look to your informations I'll know what version of pidgin you run and that you use linux
<pitti> seb128: you know that anyway :-P
<seb128> ;)
<pitti> seb128: joke aside, I'm not terribly scared by it
<seb128> me neither
<seb128> I'm even surprised it's considered as a security issue
<seb128> but it got a CVE number apparently so I was wondering what to do with the bug
* keescook really needs to finish the "what we think security means" wiki page
<keescook> seb128: they'll assigned CVEs for anything.  ;)
<pitti> seb128: it's not a security issue itself, it is just helpful with exploiting them
<seb128> right
<pitti> keescook: so they slowly move towards 'assign a name to every issue and let the vendors decide'?
<Mithrandir> does anybody know what http://err.no/tmp/weird-icon.png is?  (The leftmost).  It doesn't have a tooltip and disappears if I click on it.
<soren> Mithrandir: It's the icon that shows up when the icon the app is trying to show is missing :)
<soren> Mithrandir: So guessing what app is putting it there will be.. Well, a guess. :)
<pitti> Mithrandir: it's the "no icon" icon
<pitti> Mithrandir: i. e. you added something to your toolbar and then uninstalled the package that belongs to it (together with the real icon)
<Mithrandir> that's helpful, especially with the missing tooltip.
<ion_> Yay for a compiz-compatible emerald in gutsy. 
<Mithrandir> it's the notification area, so that'd be quite spectacular.
<pitti> Mithrandir: oh, hm; I was just going to search where gnome saves its custom starters, but that won't help then
<seb128> pitti: .gnome2/panel2.d/default/launchers FYI (in case you need it for something else)
<pitti> seb128: thanks
<soren> Mithrandir: You can try "xwininfo -tree" and click on the panel and see if there's anything that rings a bell.
* StevenK waits for sejong and artigas to catch up
<soren> Mithrandir: Well.. At least you could have before it disappeared :)
<seb128> Mithrandir: does it happen at every startup?
<iwj> seb128: So consolekit definitely doesn't work properly (but also I have some problem with the sound on this machine).
<Mithrandir> seb128: afaik, yes.
<keescook> geser: eww, debian/changelog is a symlink to changelog -- it's confusing diff
<keescook> (or rather, patch)
<seb128> Mithrandir: maybe remove /usr/share/icons/hicolor/icon-theme.cache (and maybe the one for the theme you use and gnome also) and restart
<asac> calc: managed to setup your laptop for testing (with stable wired net) already?
<seb128> Mithrandir: might be a program which install an icon but didn't update the cache
* StevenK twitches at the 538 builds in the queue for sparc
<calc> asac: not yet, we have a meeting in about 5min though
<asac> calc: i know ;)
<calc> asac: i can set it up after the meeting
<asac> calc: i really need you ;) ... you have ipw which appears to be broken for quite some time
<calc> asac: yea its quite odd
<calc> asac: it seemed to work at the sprint when i booted off cd from what i recall, but didn't before or after at home
<asac> calc: lets do it after meeting :) ... at least getting started.
<calc> asac: ok
<pitti> keescook: #ubuntu-meeting
<pitti> tkamppeter: hi
<pitti> tkamppeter: I'm so glad to have finally fixed that cups fd leakage *phew*
<tkamppeter> pitti, did you also fix something with DBUS there or only with the authentication SUID program?
<calc> btw intel q6600 is now ~ $270 for anyone looking for a new system
<pitti> tkamppeter: libdbus only; the auth helper has always been fine
<tkamppeter> So for everyone the problem was in libdbus?
<pitti> tkamppeter: for many at least, and it is very unlikely that the other reporters had this for a different reasons
<StevenK> calc: I would, considering the US dollar is so crap at the moment. :-P
<tkamppeter> pitti, then I think next is to make HAL calling the hal-cups-utils script to set up print queues.
<pitti> tkamppeter: right
<geser> keescook: can bug #124629 be closed for edgy and feisty? packages.u.c lists the security packages already
<ubotu> Launchpad bug 124629 in gsambad "[CVE-2007-2838]  Unsafe tmp file usage" [Undecided,Fix committed]  https://launchpad.net/bugs/124629
<seb128> bryce, Mithrandir: xorg-server with the clipping patch uploaded
<bryce> seb128: excellent, thanks
<seb128> you're welcome, I didn't do much, just tested and uploaded ;)
<keescook> geser: ah, yes.  good catch; thanks.
<geser> can an ubuntu-main-sponsor look at bug #126641 and ACK it (if it's OK)?
<ubotu> Launchpad bug 126641 in apache2 "sync apache2 (2.2.4-2) debian sid main" [Unknown,Fix released]  https://launchpad.net/bugs/126641
<pitti> geser: oh, that's just one new debian revision, should be easy
<pitti> geser: I'll have a look tomorrow at my archive day; please subscribe u-archive
<geser> done
<geser> and thanks
<pitti> geser: thanks to you
<Hobbsee> pitti: i hope you learn to clone yourself around tribe 5 :)
<pitti> Hobbsee: prohibited in .de, sorry :)
<Hobbsee> pitti: haha
<Hobbsee> pitti: or just stop sleeping
<pitti> Hobbsee: my gf already allowed me taking the laptop on honeymoon, but not for working :)
<tkamppeter> pitti, I have e-mailed you my cupsd.conf. See the second of my two e-mails.
<Hobbsee> pitti: oh dear.  you should leave the laptop at *home* for such events.
<geser> Hobbsee: creating a second pitti will take at least 9 months and some years till he can work on Ubuntu :)
* cjwatson was *definitely* not allowed his laptop on honeymoon
<cjwatson> (and didn't particularly want it, either)
<Hobbsee> i'd hope not :P
<Hobbsee> geser: hmmm.  darn
<ScottK> keescook and bryce: I just read the scrollback in #ubuntu-meeting.  That was me that bounced the inkscape backport bug.  IMO, given the backports charter, I shouldn't be backporting stuff as a way to get around an SRU.
<keescook> ScottK: cool by me; it's a bit of a confusing process.  :)
<ScottK> Agreed (about confusing)
<ScottK> I recently got added to ubuntu-backporters and I'm trying to be more rigorous about it than has historically been the case.
<bdmurray> Hobbsee: my clones are almost ready to start working
<Hobbsee> bdmurray: yay!
<Hobbsee> bdmurray: they can do kde's bugs :P
<bdmurray> edubuntu might be more appropriate ;)
<Hobbsee> awww
<bryce> ScottK: ah that's great to hear.  Yes, when I started I found SRUs and backports to be very mysterious, perplexing processes
<Hobbsee> sru's are still a very mysterious, perplexing black art
<ll-cool-jdong> sru's are black art indeed :)
<mathiaz> keescook: did you get a chance to look at my apparmor branch ?
<keescook> mathiaz: not the new one yet; still doing OSCON things.  however, kyle talked with Novell, and seems happy to carry the newer kernel module; so I think we'll be able to merge to a newer release -- I want to get a specific revision number from novell for the branch before finalizing it.
<bryce> scottk, so it's great to have you tending to the backports :-)  Some time I would like to chat with you about backports for X drivers.
<ScottK> bryce: Just convince me it's not scary and I'm all yours.
<bryce> there are many requests for backporting drivers, and it would be nice if we had a smooth accepted process on both ends for handling them
<mathiaz> keescook: ok. I've started to package libaalogparse
<keescook> great!  :)
<mathiaz> keescook: the library to parse apparmor audit messages.
<mathiaz> keescook: I've already updated my branch with the first shot.
<mathiaz> keescook: so if you want to merge my branch you shouldn't take the last revision
<keescook> mathiaz: great; is this related to auditd bits too?
<ll-cool-jdong> bryce: is this about the Xorg intel drivers, or fglrx?
<mathiaz> keescook: you should take version 492
<mathiaz> keescook: everything is written in the changelog anyway.
<keescook> mathiaz: okay, I'll do that and get it started now.  :)
<bryce> ll-cool-jdong: it's a general issue across all drivers, but the two of present interest are -nv and -intel
<mathiaz> keescook: libaalogparse could be used with auditd.
<mathiaz> keescook: at least that's one of the goal from upstream.
<ll-cool-jdong> bryce: both ScottK  and I don't have much knowledge about X, so we are very very reluctant to just flip the build dependencies and ASSUME everything will work under earlier versions of Xorg
<mathiaz> keescook: for now, I want to use libaalogparse with apport
<bryce> the issue is that support for new hardware is often only available in the latest versions of drivers, so after a release (feisty) has been out a while, we start getting users who have difficulty getting things working
<keescook> cool; okay, I'm headed back to OSCON now -- gotta finish up some demos for my "ubuntu security" talk.  :)
<mathiaz> keescook: to be able to include apparmor audit messages in apport report.
<mathiaz> keescook: ok. Thanks for the review.
<ll-cool-jdong> bryce: if you can either test building the packages with build dep modified yourself, or get some X developer around here to tell us it's a reasonable thing to try, then we'd be more than willing to attempt a backport
<bryce> ll-cool-jdong: understood.  This is why I'd like to discuss with you guys about processes and so on - what info do you need, what work should be done to prepare, testing to be done, etc.
<ll-cool-jdong> bryce: furthermore backporting X drivers tends to have more regressions than other types of backports, and we don't have the mass of people to test them
<ll-cool-jdong> bryce: so basically, at this point, I'd like a Ubuntu developer who is familiar with X to tell me "I'm reasonably confident that backporting xorg-driver-whatever by forcing it to build against Feisty X.org will result in a driver at least as functional as feisty's"
<ScottK> bryce: Just to give you an idea, this is what I'm currently working on to get clamav 0.9x backported for Dapper: https://wiki.ubuntu.com/MOTU/Clamav
<ll-cool-jdong> bryce: either that, or around the order of 20 different testers to tell me that soame thing
<ScottK> bryce: And said developers says "And if I break it, I'll fix it" would help a lot too.
<ll-cool-jdong> yeah, that too
<bryce> ll-cool-jdong: good to know.  Yes, I've been having people test the -nv and -intel drivers (which I've built for Feisty for them to test).  So good to hear that having a lengthy testing period is key in the process
<ll-cool-jdong> as it stands now, if a driver backport ends up knocking out 10% of the driver users.... ScottK and I would be clueless as to what to do
<poolie> what sound server is gutsy meant to be using?
<poolie> esound, or polypaudio or something else?
<poolie> hi jdong
<StevenK> Hrm. Where did Launchpad go?
<ll-cool-jdong> hi poolie :)
<ll-cool-jdong> poolie: and the cool people call the latter "pulseaudio" nowadays
<Hobbsee> StevenK: i ate it
<ll-cool-jdong> poolie: apparently the american colonoscopy society complained or something ;-)
<StevenK> Fair enough. Just so I know.
<poolie> heh
<seb128> doko: http://launchpadlibrarian.net/8327874/Stacktrace.txt looks like a ld lookup issue, no?
* Hobbsee idly notes that she's really not succeeding at not being here for the week.
<bryce> keescook: re- the xorg-server sync with debian, I have it on my todo list to review their changes and update the package.  I did xorg yesterday (it's ready to go after I've run some tests on it), and I hope to get xinit and libx11 done as they haven't had a sync in a while.  Then xorg-server after that.
<seb128> doko: and why do you think a crash in /usr/lib/gconv/UTF-16.so is a libgnomevfs bug?
<bryce> and hopefully I can squeeze in another round of driver updates sufficiently before the freeze.
<lool> iwj: I met a lot with gdm folks, Brian Caemron and William John McCann in particular, and I did build a relatively clear idea that the path to reach the ConsoleKit based gdm is still long; basically, the mccann-gobject branch is still very rough
<lool> iwj: mccann did a bunch of other changes such as a new configuration system which is to be integrate with a yet to be released dconf at some point, there's no real support for themes (and of course no compatibility), and many more issues
<doko> seb128: or a followup error, same with the second one. just the crash doesn't help me much. and the reports don't say anything what was done to rule out a bug in libgnomevfs
<lool> iwj: For example the transitions between VTs are expected to work seemlessly without any hardware resolution switch like currently
<lool> iwj: And instantaneously, especially if you want some animation to get you from the login VT to the session VT
<geser> Mithrandir: can you please give-back haskell-http? thanks
<iwj> lool: Right, but what's the situation in gdm2 ?
<lool> iwj: So all in all, you can expect this to take a lot of time to be functional, and I even suggested this might need to be a separate module
<lool> iwj: I think at some point gdm2 will move into a "no new feature" mode and keep the support for legacy things
<seb128> lool: hum?
<iwj> If consolekit isn't supposed to work with fast user switching in gdm2 then ... err ...
<seb128> lool: FC7 already uses consolekit and fast user switching, no?
<iwj> The gdm2 source already has a --with-console-kit option.
<Mithrandir> geser: given-back
<lool> iwj: While discussions at the gdm maintenance meeting were really nice, there were some major issues with the merge plans as Sun relies on plenty of complex features which may not work anymore in the consolekit branch
<seb128> lool: it's a "gobject" branch, not a "consolekit" one, isn't it?
<lool> seb128: I don't know what FC has; perhaps it's consolekit enabled, but I don't know what version mccann pushed there
<lool> seb128: There's a separate pure consolekit branch?
<seb128> lool: 2.19 has consolekit support and same for gnomescreensaver
<lool> Ohhhh
<seb128> lool: I don't think so, you are the one mentionning it
<lool> Then we're not talking of the same thing at all
<seb128> lool: there is a gobject branch
<lool> seb128: I thought consolekit was a pure mccann-gobject thing, but it's not
<seb128> no, it's not
<seb128> it's what FC7 uses for user switching
<lool> Ok, so sorry for dragging irrelevant issues to the discussions
<seb128> that's alright ;)
<iwj> seb128: This gnome-screensaver consolekit support - is it supposed to be in our 2.19.1.1 ?
<lool> iwj: In short then, I think the gdm2 branch and all its features are worthwhile, but the high level features such as power management, screen saver, input methods, nm applet and the like will be 100x times easier to integrate in the next major gdm branch
<seb128> iwj: I think so
<iwj> grep says no but it may be called something else ...
<seb128> lool: in fact gdm 2.18 already has the consolekit configure option
<lool> iwj: So it's better to not develop new major features at this point, but fixes to gdm2 are very worthwhile
<seb128> iwj: src/gs-listener-dbus.c:gs_listener_update_console_kit_idle (GSListener *listener)
<iwj> Oh, sorry, I can't spell `console'.
<asac> calc: there?
<iwj> OK, I'll go back to trying to find out why it's not working.
<iwj> Starting with how it's supposed to work ...
<lool> seb128: You recall that discussion on ugly backtraces we had?
<lool> seb128: There's some discussion on the topic in the OpenSuse BT https://bugzilla.novell.com/show_bug.cgi?id=258433
<ubotu> Novell bug 258433 in Kernel "gdb reports "Failed to read a valid object file image from memory." when debugging" [Major,New] 
<seb128> lool: yes
<lool> seb128: I tried that vdso thing (don't do it live!), and the backtraces truly changed
<seb128> lool: ah, the "Failed to read a valid object file image from memory"
<seb128> lool: that's https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/74691
<ubotu> Launchpad bug 74691 in linux-source-2.6.20 "Unable to debug under 2.6.22 on i386: Failed to read a valid object file image from memory" [High,Fix released] 
<seb128> lool: thanks for the information
<lool> seb128: But the backtraces remain quite ugly nevertheless :)
<lool> seb128: This is a before / after http://bugzilla.gnome.org/show_bug.cgi?id=460513
<seb128> lool: still not good :/
<calc> asac: yea
<calc> asac: sorry i was in another irc client discussing ooo
<calc> asac: i'll go set up my laptop now
<asac> calc: cool
<asac> calc: i will have to go to supermarket in a few minutes ... will be away for 30 minutes or so
<calc> asac: ok that works good for me, about to eat lunch
<calc> asac: ping me when you get back
<asac> calc: fine
<geser> mvo_: are you planing to update compizconfig-settings-manager soon? it's missing a depends on python-gtk2
<mvo_> geser: not soon, but feel free to branch from our compiz repository in launchpad and fix it there. I will be happy to merge. otherwise, please remind me tomorrow (or file a bug) I need to leave now
* mvo_ waves
<EtienneG> hey guys, did anybody know what happened with libapache-mod-security in feisty ?  Did it got deprecated, or rolled into another package ?
<Mithrandir> EtienneG: RoM; undistributable for legal reasons
<Mithrandir> from removals.txt in debian
<EtienneG> Mithrandir, thanks a lot
<calc> asac: should we have wireless-tools pre22 synced from debian?
<calc> asac: er merged (seems there are some ubuntu changes)
<asac> calc: lets first test
<asac> let me create notes for you case
<asac> what info do you have about your chipset?
<calc> asac: 945 chipset with 3945 wireless
<calc> hmm let me move the laptop over near my desktop
<calc> then i don't have to worry about the network going down, heh
<calc> ok i found a table to stick it on
<calc> table in this case is a stool, heh
<calc> it lists the chipset as 945GM/GMS/940GML
<calc> wireless 3945ABG
<calc> rev 02
<geser> has someone an explanation for this build failure http://launchpadlibrarian.net/7726938/buildlog_ubuntu-gutsy-i386.steam_2.2.31-4.1_FAILEDTOBUILD.txt.gz ?
<geser> dpatch deapply-all
<geser> set: 8: Illegal option -o pipefail
<elmo> geser: dash is /bin/sh ?
<iwj> t
<calc> asac: ping
<cjwatson> dpatch here is #! /bin/bash
<cjwatson> -rwxr-xr-x 1 root root 29702 2007-06-11 23:46 /usr/bin/dpatch
<cjwatson> that build log is Last-Modified: Mon, 21 May 2007 16:40:30 GMT
<cjwatson> see dpatch 2.0.25 changelog
<cjwatson> geser: a give-back should do the trick
<Mithrandir> given-back
<geser> thanks
<asac> calc: ok
<calc> asac: what should we test next?
<asac> calc: so ... open network doesn't work for you?
<calc> asac: no
<calc> asac: it does work but only in the wireless-* interfaces file case or dhclient eth1 case
<calc> and it sort of works with wpa-driver ipw
<calc> but it gives ioctl errors
<asac> calc: can you also post your iwconfig --version ?
<calc> wext (using wireless extensions) it never gets an ip
<calc> ok
<asac> for the record
<calc> note its only up to 21 and the driver is 22
<calc> but yea i'll post it up
<geser> and what's the build problem in http://launchpadlibrarian.net/8577358/buildlog_ubuntu-gutsy-i386.apache2_2.2.4-2_FAILEDTOBUILD.txt.gz ?
<calc> that combined with the other findings is why i think going to new debian version might fix it
<geser> it fails nearly at the end with objcopy: debian/apache2-dbg/usr/lib/debug/usr/sbin/apache2-mpm-worker: Invalid operation
<asac> calc: yes i know
<asac> calc: anyway ... please post :)
<calc> ok logged into launchpad about to add it to the bug
<calc> done
<calc> hmm it only recommends v16 or later, hmm
<asac> you have bug id?
<calc> bug 128360
<ubotu> Launchpad bug 128360 in network-manager "nm fails to connect to open network" [Undecided,New]  https://launchpad.net/bugs/128360
<asac> ok i think that wpa-XX will not succeed to connect to open network
<asac> so what happens if you remove every option from that wireless card?
<asac> in interfaces
<calc> asac: its already removed except for the default boot stuff
<calc> asac: i am doing this from the tribe-3 live cd
<calc> for the open ap if i use wireless-ssid foo it works
<asac> calc: ok
<calc> because it bypasses wpasupplicant entirely (and wireless-tools too maybe?)
<asac> pleaes ifdown that interface now
<calc> ok
<calc> done
<asac> then stop network-manager
<calc> asac: how do i stop it normally i have done it before by stopping dbus
<asac> not you won't have net can you still type here?
<calc> i am typing to you from my desktop
<calc> my laptop is right next to it
<calc> so dropping network on the laptop is fine
<asac> /etc/dbus-1/event.d/25NetworkManager stop
<calc> ok
<calc> done
<asac> ifconfig eth1 up
<asac> (if eth1 is your device)
<asac> then open a terminal and start wpasupplicant like:
<asac> wpa_supplicant -g /var/run/wpa_supplicant.global -dd 2>&1 | tee /tmp/wpa.debug.log
<asac> does that block and print ... starting?
<asac> (all this as root)
<calc> sits there and i see nothing
<asac> not even a start message?
<asac> in the beginning?
<asac> ok
<asac> nevermind
<calc> yea nothing at all printed
<asac> now open a second terminal
<calc> its sitting there though
<calc> grr i missed supplicant.global
<asac> start like i said please
<calc> ok i did it exactly spelled right this time, but still no message printed
<asac> thats ok then
<asac> ok
<calc> what should i do in the second window?
<asac> wpa_cli -g/var/run/wpa_supplicant.global add_interface eth1 "" "" wext
<asac> i think
<calc> ok i'll try that
<asac> does that succeed?
<calc> should there be a space after -g?
<asac> calc: sorry
<asac> wrong
<asac> just use wpa_cli -g/var/run/wpa_supplicant.global add_interface eth1 "" "" /var/run/wpa_supplicant.run
<asac> the idea is that driver is automagically detected
<calc> unknown command add_interface
<calc> "Unknown command 'add_interface'" to be exact
<asac> try -p instead of -g
<calc> "Failed to connect to wpa_supplicant - wpa_ctrl_open: Not a directory"
<_wattazoum_> Hello
<calc> asac: do i need a -i before eth1?
<calc> asac: oh i noticed interface is in the manpage but not add_interface, not sure if that is the issue
<asac> no
<asac> wait a second
<asac> the -i comes later
<asac> we first have to initialize the supplicant
<calc> ok
<asac> calc: ok its interface_add :)
<calc> ok with -g that worked
<calc> it printed some stuff out
<asac> ok ... now you should see something going on in wpa_supplicant terminal, right?
<calc> it printed a bit and then stopped printing out more
<asac> find ... next start wpa_cli terminal just like
<calc> about one screen worth (at 1280x800)
<asac> wpa_cli -ieth1
<asac> that should bring you to a shell where you can type help
<calc> says could not connect to wpa_supplicant
<calc> do i need -g/path again?
<asac> no
<asac> interface is added
<calc> ok
<asac> so -ieth1 should work
<calc> last thing it shows is "Could not connect to wpa_supplicant - re-trying"
<calc> and its just sitting there
<asac> please post what supplicant said
<calc> ok
<asac> when you added_interface
<asac> calc: did the interface_add succeed?
<asac> maybe restart supplicant
<asac> then do it again
<calc> not sure if it did
<asac> please redo and look what it prints
<calc> i'll post up the output so you can see what it did
<calc> ok i'll retry it
<asac> no
<asac> please retry
<asac> it should be obvious
<asac> either it says:
<asac> FAIL
<asac> or OK
<asac> or Command timed out
<asac> e.g. the wpa_cli ... interface_add command i mean
<calc> FAIL
<asac> restarted supplicant?
<calc> it looks like it hung on add ealier
<calc> restarting it now
<asac> yes
<asac> restart it
<asac> then try the command
<calc> still can't do connect with wpa_cli -ieth1
<calc> s/do//
<asac> hey
<asac> did it OK
<asac> ?
<calc> yea it ok'd
<calc> it appears to hang during trying to get current scan results first without requesting
<calc> i'll post the log file for you to see
<asac> k
<calc> wow it didn't even print the full message out the second time
<calc> i'll explain once i have it posted
<calc> ok its posted
<calc> where it says:
<calc> Trying to get current scan results first without requesting a new scan to speed up initial association
<calc> the second time it didn't print anything past requesting...
<bigredradio> Anyone here know if "Landscape" is OpenSource? Curious if this is a semi-fork of webmin.
<asac> calc: ok
<asac> lets give supplicant more hints
<asac> please stop things
<asac> start supplicant
<asac> wait a bit
<dsas> bigredradio: unlikely, webmin isn't included in ubuntu repos at all.
<asac> calc: please start supplicant like before ... wait a bit
<asac> then use
<asac> wpa_cli -g/var/run/wpa_supplicant-global interface_add wlan0 \ "" wext /var/run/wpa_supplicant
<asac> aeh s/\\//
<asac> and use the right global filename
<asac> instead of wlan eth1
<asac> of course
<calc> ok
<calc> so wpa_cli -g/var/run/wpa_supplicant.global interface_add eth1 \\ "" wext /var/run/wpa_supplicant.run
<asac> no :=
<asac> remove the \\
<calc> oh ok
<asac> it was a line break here in file :)
<asac> ah
<asac> and remove the .run
<asac> interestingly it worked better that way here
<asac> (e.g. less fail)
<calc> ok
<calc> got further
<calc> want me to do -ieth1 now?
<asac> yeah
<calc> ok it worked
<asac> wow
<asac> please stop everything again
<asac> and try again with wext -> ""
<asac> it should work
<asac> its probably the .run
<asac> :)
<calc> looks bad
<calc> hmm nm
<asac> wait a bit
<calc> it got to command prompt with -ieth1
<asac> great
<asac> so its the .run :)
<asac> funny thing
<asac> ok
<asac> so what does scan_results
<asac> give you
<asac> (at the prompt)
<calc> i see vinther
<asac> ok list_networks ?
<calc> i don't see the wpa access point but thats probably ok?
<calc> vinther is the open ap
<asac> maybe its ok
<asac> we haven't scanned yet
<calc> no networks listed in list_networks
<asac> ok
<asac> then lets get started
<calc> ah ok vinther might be from what was set on the card already
<asac> first lets reproduce that it doesn't work the way network manager does it
<calc> ok
<asac> ap_scan 1
<calc> OK
<asac> (all now at wpa_cli prompt)
<calc> yea
<asac> add_network
<calc> 0
<asac> good
<asac> SET_NETWORK 0 ssid "vinther"
<asac> if thats the name
<calc> OK
<asac> SET_NETWORK 0 key_mgmt NONE
<calc> OK
<asac> enable_network 0
<asac> ... then you should rumbling things in wpa_supplicant
<calc> OK
<asac> and get some output at prompt
<calc> yea
<asac> what happens?
<asac> does it loop?
<calc> trying to associate...
<asac> e.g. does it look like it repeats things
<calc> authen with...
<calc> yea it loops
<calc> authentication times out
<asac> does it name the ap it tries to associate with?
<calc> oh
<calc> it says Authentication with 00:00:00.... timed out.
<shaya> did someone break gtk? :)
<calc> not with the hex of the router
<asac> calc: yeah ok
<asac> calc: disable_network 0
<asac> to stop this garbage
<shaya> just updated and acroread dies w/ a (acroread:7713): Gtk-CRITICAL **: gtk_rc_get_style: assertion `GTK_IS_WIDGET (widget)' failed
<asac> then ap_scan 2
<asac> and enable_network 0 again
<calc> yes it says (SSID='vinther' freq=2437 MHz)
<calc> OK
<calc> shaya: i hear there were issues with ooo as well so probably so
<calc> shaya: talk to seb128
* shaya pokes seb128
<calc> shaya: btw good to see you again, haven't noticed you around in years :)
<seb128> shaya: looks like that's a GTK bug, there is bugs about it, dunno what's causing it though
* calc probably just wasn't looking ;)
<shaya> phd'ing
<calc> asac: still getting time outs
<calc> asac: but without the ssid/freq
<calc> asac: and it seems to take longer to time out now
<seb128> shaya: it's on my list of things to look at, didn't start on it yet though
<shaya> still maintain a single debian package :)
<asac> calc: hmm
<asac> calc: what do you see in scan_results ?
<asac> maybe run scan
<shaya> seb128: do you happen to have the old feisty packages somewhere?
<asac> before
<shaya> are they in launchpad?
<calc> (hex) 2437 201 vinther
<seb128> shaya: launchpad has all the binaries
<seb128> shaya: you can download 2.11.5 from gusty
<calc> after scan i see (hex) 2437 202 vinther
<seb128> shaya: https://launchpad.net/ubuntu/+source/gtk+2.0/2.11.5-1ubuntu1/+build/355090
<seb128> shaya: the left column has the binaries
<seb128> (if you use i386 architecture)
<calc> asac: see above ^
<asac> calc: ok
<asac> do you have an ap id?
<asac> at hand?
<calc> the hex code?
<calc> 00:14:bf:2a:5f:e1
<calc> it shows up in the scan_results
<asac> yes
<asac> ok
<asac> set_network 0 bssid "00:14:bf:2a:5f:e1"
<calc> do i need to disable_network first?
<asac> you can ... not required though
<calc> FAIL
<calc> ah it was the quotes
<asac> without "
<asac> ?
<calc> it worked after stripping
<shaya> danke
<asac> ok
<calc> asac: still timed out
<asac> ap_scan 0
<asac> then disable_network 0
<asac> and enable_network 0 again
<calc> i see wpa_driver_wext_set_drop_unencrypted in the logs that doesn't cause a problem does it (no idea what it does)
<calc> still timing out though
<asac> actually i am really unsure if you can connect to open network using supplicant at all
<asac> when i tried supplicant refused to do that saying that without encryption is not supported
<calc> however feisty is setup i can connect to the open ap using NM
<asac> yes
<asac> but probably not using supplicant
<calc> ah it knows not to try to connect using supplicant then?
<calc> i have a wpa aes router i can try connecting to as well if you want
<asac> i think your bug is that it tries to connect using supplicant
<asac> it should work though the same way we did when you have wpa
<calc> well when i try connecting to the wpa router it didn't work either last time i tried it
<asac> right ... but that can be ap_scan
<asac> ipw needs manual scanning ... and ap_scan 1 is automatic afaik
<asac> do you have the wpa net up?
<calc> yes
<calc> its next to the laptop right now, so strong signal too :)
<asac> ok ... but you didn't see it in scan results?
<asac> scan_results
<asac> in wpa_cli
<calc> i don't see it in the scan results for some reason
<asac> do you see it with
<asac> iwlist eth1 scan ?
<asac> (as root)
<calc> hmm no
<asac> hidden network?
<asac> please make it visible for now
<calc> no it is set to broadcast
<calc> i can reboot and verify if i can see it in feisty if you want
<calc> the ap can see the vinther ap, but can't see the laptop mac
<asac> wierd
<calc> that might be normal if the laptop isn't connected to anything though, not really sure
<asac> maybe scan is better when you stop supplicant?
<asac> iwlist scan?
<asac> calc: no ... lets go and see if latest wireless tools help for that
<asac> or ... please test feisty as well
<asac> calc: maybe set your ap to TKIP (not AES) ?
<calc> ok it still doesn't work i'll reboot into feisty quick and then we can test new wireless tools as well
<calc> hold on this is weird
<calc> i'm going to reboot the router
<calc> it says its not secured
<calc> i don't know if it got disabled at some point or the router is odd
<asac> router crashed most likely
<calc> ok i'm alive now
<asac> you see it?
<asac> in gutsy?
<calc> still don't see it in gutsy i rebooted the router it shows security is disabled right now
<calc> which is interesting
<asac> how can you look at the router?
<calc> i just log into it from my desktop
<calc> i'm rebooting into feisty to see what i can see
<asac> desktop == wired?
<calc> yes
<calc> does wpa_supplicant work with wpa2?
<asac> yes
<asac> depends on driver though
<asac> but should
<asac> at least detect
<asac> i guess your router is broken
<calc> ok
<asac> :)
<calc> i'll see how it goes in feisty
<calc> it still had my password saved maybe i disabled security when i was testing it before going to the sprint
<asac> ok
<asac> enable security ... then scan for it
<asac> with iwlist
<asac> then with wpa_supplicant :)
<calc> after turning on security in gutsy iwlist eth1 scan still didn't see it
<calc> ok it sees both in feisty
<calc> lets see if it can connect to both
<calc> can connect to both on feisty
<calc> hey
<kwah> hi all. is there a policy somewhere about treating BUGs marked as wishlist? For example, is it allowed/necessary to mark duplicates?
<calc> it only shows vinther on iwlist eth1 scan though
<asac> calc: thats really strange
<asac> calc: ok go back to gutsy then
<asac> calc: we should be able to connect using wpa_supplicant
<calc> correction it only shows the one i am connected to
<asac> maybe save the daemon.log
<asac> calc:
<asac> you have to run as root
<calc> after i connected to "calc" the other one it showed that one but only that one
<asac> sudo iwlist scan
<asac> otherwise it will just dump the cache
<calc> oh ok, sorry i forgot to do that earlier
<asac> yeah
<asac> reboot please
<asac> gutsy is more important ;)
<calc> rebooting now
<asac> good
<asac> calc: at best just upgrade :)
<asac> i feel scared about live-cd thing
<calc> heh
<calc> live cd usually works
<calc> except when the fs is broken apparently
<asac> yeah ... but its creeping slow and it might not be the latest
<calc> yea
<asac> anyway ... just reboot and lets see
<calc> almost up now
<calc> i'm going to retry NM for the WPA2 network
<asac> yes do it
<asac> capture log et al as well
* calc has a feeling it will work
<calc> ok iwlist eth1 scan works for both
<calc> doesn't appear to be connecting to the wpa2 network, or takes a long time to do it
<asac> ok ... you should post both a feisty ... and a gutsy log
<asac> to a new bug
<calc> ok once it dies i will post the logs
<asac> ipwXXXX cannot connect to wpa2
<asac> good
<asac> feisty (successful) ones are important as well
<calc> er it connected but doesn't know it has
<asac> why do you think you connected?
<calc> no green dots but ifconfig has an ip
<calc> and NM is still swirling
<calc> it took about 2m to get an address which seems a bit long
<calc> but it worked
<calc> i think it might have taken a while because it popped up a window that got lost behind my full screen console window
<calc> it worked after trying a second time
<calc> and it shows it is connected
<calc> trying to connect to the open ap now
<calc> what the hell
<calc> it connected to the open ap now too
<calc> i am going to power cycle the box and try this again
<asac> hehe
<asac> i think your vinther ap is just broken
<asac> just through it in the bin :)
<asac> throw
<calc> well it could be something changed when i connected to the wpa2 network first
<wwoods> hey dudes - I'm working on getting some apport-related kernel patches upstream. Who should be CCd on these mails, beyond pitti?
<asac> i don't know
<asac> its probably live-cd related
<calc> asac: i had issues before when trying on an installed version of gutsy
<asac> its known to create arbitrary garbage at random places :)
<asac> calc: when was that?
<calc> asac: tribe-2 timeframe before sprint
<asac> i can't tell
<calc> next test i will do is try connecting to open ap, if it fails, connect to wpa2 if succeed attempt to connect to open ap again
<asac> i wish i had such a wireless chipset to test
<asac> ok
<asac> try
<calc> which is roughly what i did before this reboot, but i wasn't paying close attention to what i was doing
<calc> asac: if the live cd creates random garbage is it safe to install using it either?
<asac> no idea :)
<calc> heh
<asac> i would use alternate
<calc> uh
<calc> it looks like it is trying to use wpasupplicant to connect to the open ap
<calc> didn't we determine it shouldn't be doing that?
<asac> dunno .. did it do that when it succeeded?
<calc> not sure, maybe
<calc> its not getting an ip yet this time
<asac> yeah ... would be nice to know
<asac> we already know that it does try that when you didn't go wpa first
<asac> try wpa2
<asac> then open?
<gnilor> can i ask what version of mac80211 subsystem is in the ubuntu packages? i hear people with .20 kernels ... it would help people wanting to try iwlwifi (ipw3945 and 4965) ?
<calc> ok it failed the first attempt on open ap
<calc> now trying wpa2 one
<calc> it asked for the password twice
<calc> 3 times now
<calc> it seemed to ask a lot before but i wasn't sure if i was just messing up
<calc> 4 times now
<calc> 5 times
<calc> ok i think i am going to consider this not working
<calc> its up 6 times now and not connected
<geser> Mithrandir: please give-back lhapdf on amd64. thanks
<calc> guess what
<calc> i tried the open ap after that and it connected
<calc> i'm going to try the wpa2 one again
<Mithrandir> geser: given-back
<calc> asac: after a lot of attempts it finally connected to the secured one this time
<calc> asac: got an updated wireless-tools to test out? ;)
<asac> calc: did you do anything special?
<asac> calc: or did it just succeed at some point?
<calc> whoa when it finally connected NM applet went away
<calc> its not in the bar anymore
<calc> if you want this long log i can put it up on the bug report as well
<calc> not sure if anything in it is useful
<calc> the log shows that NM crashed at roughly the time it connected
<asac> calc: it crashed
<asac> start it with
<asac> nm-applet --sm-disable
<asac> from command-line
<asac> :)
<asac> yeah ... nm-applet has problems
<calc> it looks like it is running at the command line but nothing in the bar
<asac> hmm
<asac> is NetworkManager still running?
<calc> no
<calc> that would be why... heh
<asac> yes
<asac> so NetworkManager crashed as well?
<calc> i guess that is the crash i saw in daemon.log then
<calc> apparently so
<asac> ouch
<asac> but understandable ... NetworkManager has probably lots of places where it uses not instantiated variables
<asac> i already found 2
<asac> by coincident
<asac> you can start it through /etc/dbus*/eve*/25Netwo* restart
<calc> yea it worked
<calc> now it shows like its trying to reconnect to vinther
<calc> (open ap)
<calc> already have an ip though
<calc> asac: what would the next step be?
<calc> asac: i can get it to work but it is very unreliable
<asac> is the ip still usable?
<asac> calc i would like to do the same we did before
<calc> it went away finally
<asac> e.g. using wpa_supplicant only ... to see if that is already instable
<asac> or if its network manager which makes the whole build shake
<calc> the interface is up but no ip
<asac> ok ... stop nm
<asac> /etc/dbus*/eve*/25Netwo* stop
<calc> done
<calc> want me to start up wpa_supplicant like before?
<asac> yes ... first be sure that eth1 is down
<asac> the ifconfig it manually up
<asac> so its in clean state
<asac> look at iwconfig
<asac> and iwlist
<asac> if everything looks good
<calc> its set to vinther in iwconfig
<calc> iwlist can see both networks
<johnnybuoy> hi all!
<asac> calc: ok
<asac> that should be ok then
<calc> should i kill avahi as well
<asac> start wpa_supplicant like before ... with tee to a log et al
<asac> hmm
<calc> it brought eth0 back up by itself
<johnnybuoy> I'm creating a .deb file, and I need to change the PATH environment variable of the system. I was wondering how this is done/what the accepted way of doing this is
<asac> calc: yes eth0 is not a problem
<asac> eth1 ?
<calc> didn't seem to touch eth1
<asac> ok
<asac> start wpa_supplicant and add interface through _cli
<asac> then go to cli console
<calc> i killed it to be certain it doesn't do anything odd
<asac> yes
<asac> if there was an instance running
<asac> kill wpa
<calc> eth1 came up when i shut it down which was odd as well so i downed it again
<asac> et al
<asac> calc: is NetworkManager still running?
<asac> otherwise ifdown eth1
<asac> should down it
<asac> or if it doesn't do
<asac> ifconfig eth1 down
<calc> network manager is down and avahi is as well
<calc> i killed the running wpa and restarted it with the log
<asac> good
<asac> 1. add interface
<calc> scrollback lost the add interface command
<asac> 2. go to wpa_cli
<asac> 3. ap_scan 1
<asac> 3. add_network
<asac> 5. set_network 0 ssid "YOUR ESSID"
<calc> what was the command for interface_add you mentioned before
<asac> wpa_cli -g/var/run/wpa_supplicant.global interface_add eth1  ""  "" /var/run/wpa_supplicant.run
<calc> drop the .run part?
<calc> the .run causes a hang, so i dropped it
<calc> asac: ok trying the open ap now
<calc> asac: still times out
<asac> calc:
<asac> hehe
<asac> i forgot something
<asac> please disable_network 0
<asac> then set your key
<asac> set_network 0 psk "passphrase"
<asac> then enable
<calc> ok for the wpa2 one?
<asac> yes
<calc> i get a key mismatch message in the logs
<asac> what does scan_results show you?
<asac> do you see events on wpa_cli console as well? what do they say?
<calc> 00:0c:41:f7:09:53 2462 220 [WPA-PSK-CCMP] [WPA2-PSK-CCMP]  calc
<calc> 00:14:bf:2a:5f:e1 2437 202 vinther
<asac> that looks not like what i have ... but should be good
<calc> do i need to do something to tell wpasupplicant to use wpa2?
<asac> hmmm ... i think not
<asac> does WPA have a different passphrase?
<asac> list_networks ?
<asac> what does give?
<calc> 0 calc any
<asac> ok
<asac> try ap_scan2
<asac> try ap_scan 2
<asac> then reassociate
<calc> meaning i need to do the add_network/set_network again?
<asac> no
<asac> that is remembered
<asac> maybe disable_network before
<asac> but shouldn't matter though
<calc> add_network returned 1
<asac> he?
<asac> you don't need to add_network
<calc> ok
<asac> just type reassociate :)
<asac> at best remove network 1 now :)
<asac> who knows :)
<calc> 0 calc any [CURRENT] 
<asac> yes
<calc> timed out so far
<asac> ap_scan 2 ?
<calc> scan_results only shows vinther right now
<asac> set ap manually
<asac> disable_network
<asac> set_network bssid AP:AP:AP...
<asac> enable
<asac> calc do you get new scan_results if you run just scan for once?
<calc> yea calc showed up again
<asac> good
<asac> set bssid please then reassociate/enable network
<asac> you sure you have psk set?
<calc> trying again
<calc> i reset the psk again to make certain
<calc> remember when doing this through NM it kept asking for the password over and over and over again
<calc> so it would seem that it doesn't care if i give it a password
<calc> it says No keys have been configured - skip key clearing
<calc> not sure if that means it doesn't like what i tell it for key
<calc> asac: ^
<asac> hmm
<asac> look at help
<asac> there is a capabilities entry
<asac> calc: can you get a few of those?
<asac> e.g. what do you get for key_mgmt?
<asac> and others?
<calc> NONE IEEE8021X WPA-EAP WPA-PSK
<calc> so should it be set_network 0 WPA-PSK "password" ?
<stgraber> asac: if that's his ipw3945 and NM unable to connect, I may have a similar issue (working 1/10 when unloading ipw3945 + reload NM and nm-applet)
<calc> ah ha!
* calc is a bit er slow ;)
<calc> i had set key-mgmt to none earlier
<calc> you have to set key-mgmt and the psk both to use it
<calc> it might have a chance of working now
<asac> stgraber: can you look the log for today for me and calc on this channel?
<calc> still timed out, gar
<asac> bssid is set?
<asac> to ap address?
<calc> asac: is there a way to dump current settings?
<calc> to see what it thinks i have set so far
<asac> dunno
<asac> get_network ssid ?
<asac> get_network 0 ssid?
<asac> no idea if such a command exists
<calc> yea bssid is set along with ssid
<calc> asac: does wpa use wireless-tools for any of this or just its own code?
<asac> it uses wireless-tools
<calc> stgraber: i finally got it to partially work earlier today but its very flakey
<asac> lib
<asac> libwt
<calc> asac: hmm maybe we should try updating that then?
<asac> calc: yes
<calc> it works when it feels like it currently, which isn't often for me, heh
<asac> i hope we have tested enough to say that wpasupplicant as in gutsy is really broken :)
<asac> or wireless tools
<calc> yea
<asac> but i doubt that for now
<calc> it definitely looks broken here
<asac> anyway
<asac> you have to respin wpasupplicant as well iirc
<calc> it works immediately and every time in feisty and about 1% of the time in gutsy so something is broken somewhere
<asac> because its linked against libwt.so.2x which is still old version
<calc> ah
<asac> calc: yes
<asac> calc: it might be that you should use my wpasupplicant
<calc> asac: do you happen to have a way to build amd64 stuff easily? i just have this live cd right now
<asac> e.g. 0.5.8
<asac> calc: what do you want?
<asac> wpasupplicant 0.5.8 (latest stable vs. latest development which we have in gutsy) ?
<calc> asac: amd64 version of whatever is needed to see if the api change is the issue?
<stgraber> calc: ok, I've just read a good part of the backlog and this seems very very similar
<calc> asac: i guess that would be a good place to start?
<asac> stgraber: look how we tried to use the wpa_supplicant
<asac> and wpa_cli manually
<stgraber> asac: ok, I'll give a manual wpa_supplicant a quick try, but I already tried this afternoon without much success
<asac> what waas the problem?
<asac> calc: so what version of wireless tools do you need?
<asac> isn't that in gutsy already?
<calc> asac: well debian has the pre22 version, and the kernel is 22 so would that work?
<calc> asac: oh hmm maybe?
<stgraber> asac: in some case it doesn't even seem to associate with the AP, in some others it does and the key is set (iwconfig) but no green light in NM, in some case it doesn't even try to associate and keeps being connected to another AP ...
<calc> the wireless-tools in ubuntu is pre20 which is from april
<stgraber> asac: I just do this wpa-supplicant test and I'm back here
<calc> is the pre22 the one with 22 api support?
<asac> hmmm there is an outstanding merge for wireless-tools ?
<asac> calc: no idea ... people claim it
<calc> yea
<calc> debian is two rev's newer than ubuntu afaict
<calc> http://http.us.debian.org/debian/pool/main/w/wireless-tools/wireless-tools_29~pre22-1.dsc
<calc> http://archive.ubuntu.com/ubuntu/pool/main/w/wireless-tools/wireless-tools_29~pre20-1ubuntu1.dsc
<stgraber> asac: ok, wpa_supplicant manual test succeded (WPA PSK TKIP), I just had to iwconfig eth3 essid "essid" and it associated, then dhclient3 and everything work. I then tried with NM and it didn't manage to connect (looking at iwconfig, one second it's associated but without the key, next second it's no longer, then it seems to be correctly associated but the second after it switched to another AP and NM ask for the pass (even if already spec
<calc> +wireless-tools (29~pre22-1) unstable; urgency=low
<calc> +
<calc> +  * New upstream release.
<calc> +
<calc> + -- Guus Sliepen <guus@debian.org>  Sun, 01 Jul 2007 18:03:58 +0200
<calc> +
<calc> +wireless-tools (29~pre21-2) unstable; urgency=low
<calc> +
<calc> +  * Don't look at LINUX_VERSION_CODE, only use generic header files in
<calc> +    iwlib.h. Closes: #425485
<calc> +
<calc> + -- Guus Sliepen <guus@debian.org>  Tue, 22 May 2007 10:27:46 +0200
<calc> +
<calc> +wireless-tools (29~pre21-1) unstable; urgency=low
<calc> +
<calc> +  * New upstream release. Closes: #421569
<calc> +
<calc> + -- Guus Sliepen <guus@debian.org>  Thu, 03 May 2007 13:55:01 +0200
* calc hides after flooding
<xxxxx1> ^_x
<asac> stgraber: how did you do manual? with wpa_cli ?
<asac> stgraber: you shouldn't need to use iwconfig at all
<asac> stgraber: e.g. just wpa_cli commands
<stgraber> asac: wpa_supplicant -Dwext -ieth3 -c wpa.conf
<asac> yeah ... thats not that impressive
<asac> start it like in backlog
<asac> and let it detect everything on its own
<asac> :)
<stgraber> wpa.conf being my network config with : ssid, key_mgmt, proto, pairwise, group and psk set
<asac> thats what is needed for entwork manager
<asac> stgraber: wpa_supplicant -g /var/run/wpa_supplicant.global -dd 2>&1 | tee /tmp/wpa.debug.log
<asac> in a second terminal add interface like:
<asac> wpa_cli -g/var/run/wpa_supplicant.global interface_add eth1 "" "" /var/run/wpa_supplicant.run
<asac> then enter wpa_cli:
<asac> wpa_cli -ieth1
<stgraber> Could not connect to wpa_supplicant - re-trying
<stgraber> and other window stuck at half of my MAC address
<asac> hmm
<stgraber> Own MAC address: 00:19:d2:
<asac> maybe try to specify driver
<asac> wpa_cli -g/var/run/wpa_supplicant.global interface_add eth1 "" wext /var/run/wpa_supplicant.run
<asac> bur restart supplicant first
<asac> do you have eth1 ?
<asac> adapt according where your interface is
<stgraber> no, eth3 but I s/eth1/eth3/
<asac> k
<asac> ah
<asac> sorry
<asac> wpa_cli -g/var/run/wpa_supplicant.global interface_add eth1 "" wext /var/run/wpa_supplicant
<asac> use that
<asac> :)
<stgraber> ok, I'm in interactive mode now
<asac> cool
<asac> set ap_scan 1
<asac> e.g.
<asac> ap_scan 1
<asac> > add_network
<asac> > set_network 0 ssid "youressid"
<asac> set_network 0 psk "yourwpapassphrase"
<asac> > enable_network
<asac> and see what happens
<stgraber> no suitable AP found :(
<calc> "The main features of the latest beta is WE-21 support (long/short retry, power saving level, modulation), enhanced command line parser in iwconfig, scanning options, more WPA support, sysfs symlinks and udev compatibility in ifrename and more footprint reduction tricks"
* calc notes WPA support
<asac> stgraber:
<stgraber> it says "ssid missmatch" but the ssid I provided is correct and shown in wpa_supplicant scan results ...
<asac> > scan
<asac> ah
<asac> ok
<asac> what capabilities do you see?
<asac> do they look sane?
<asac> is psk good?
<asac> or isn't there any authentication going on?
<stgraber> it doesn't even try
<stgraber> it simply says : ssid missmatch, pass
<asac> ok
<stgraber> and try with the next one, but ssid matches ...
<asac> thats what client says?
<asac> or supplicant?
<asac> what happens in supplicant terminal?
<stgraber> supplicant
<asac> ah
<asac> do you see anything on client?
<asac> or nothing?
<stgraber> 1: 00:14:d1:c0:39:80 ssid='graber-wifi' wpa_ie_len=26 rsn_ie_len=0 caps=0x11 skip - SSID mismatch skip - disabled
<stgraber> that's in wpa_supplicant
<asac> hmm
<asac> and get_network 0 ssid ?
<stgraber> clients just says OK :)
<asac> is 'graber-wifi' ?
<stgraber> it simply says : ssid missmatch, pass> get_network 0 ssid
<stgraber> FAIL
<stgraber> I hate this copy/paste :)
<stgraber> so, it returns fail
<asac> yeah
<stgraber> even after returning OK after the add_network and psk
<asac> disable_network
<calc> stgraber: which arch are you on?
<asac> then ap_scan 2
<stgraber> calc: amd64
<calc> stgraber: ok
<calc> stgraber: same as me
<calc>  * V21 to V22
<calc>  * ----------
<calc>  *      - Prevent leaking of kernel space in stream on 64 bits.
<asac> stgraber: and in addition set_network bssid "yourap"
* calc has no idea what that means
<asac> its a tiny change afaik
<stgraber> > set_network 0 bssid "graber-wifi"
<stgraber> FAIL
<asac> just different size macros
<calc> stgraber: bssid is hex
<asac> stgraber: bssid is access-pointe address
<asac> not essid
<stgraber> oh, right, sorry :)
<asac> 00:00:00...
<asac> stgraber: do you have a i386 live cd?
<asac> stgraber: to see if it works?
<asac> if that would be the case ... it would almost certainly be tools mismatch
<stgraber> ok, so this time I got a "Trying to associate with ..." from the client and I see unassociated with iwconfig (key is set)
<asac> you are in ap_scan 2 ?
<calc> asac: i'll set up a download for i386 here as well
<asac> stgraber: can you see if the right capabilities are selected?
<asac> get_network 0 key-mgmt
<stgraber> FAIL :(
<asac> thats so crazy
<asac> stgraber: do you have a x86 iso?
* calc will have one for testing in about 35m
<stgraber> asac: only Kubuntu i386 Tribe-3 (the last one I tested last week :))
<stgraber> but I can quickly download an ubuntu one, it'd take something like 10-15 minutes
<asac> stgraber: please try
<asac> i will be awake for another half an hour or so :)
<stgraber> asac: ok, I'm downloading the ubuntu desktop iso on my server so I can test the Kubuntu one now :)
<asac> cool
<stgraber> asac: ok, I'm on a kubuntu livecd now
<stgraber> asac: connecting to an open AP works, connecting to the WPA one keep asking the password
<asac> stgraber: does open work on amd64?
<stgraber> asac: manually yes, not with NM though
<asac> ok nm might be broken still
<asac> and manually wpa?
<asac> e.g. like we did?
<calc> asac: i'll have the cd downloaded in about 17m if you want me to do any i386 testing
<stgraber> calc: looks like wpa_supplicant doesn't see my network now ... I have something like 4-5 networks here but spread on different channels and the network I try to connect to is MIMO so I don't really see why I don't see it now ...
<stgraber> calc: oh, it just managed to connect :)
<calc> stgraber: heh
<stgraber> http://paste.stgraber.org/2257
<asac> stgraber: so what did you do?
<stgraber> http://paste.stgraber.org/2258
<asac> stgraber: cool
<asac> so it works on i386?
<asac> but doesn't on amd64
<asac> cool
<calc> could that be due to the macro thing i pasted about earlier?
<asac> yes
<calc> ok
<asac> its in header ... so its inlined
<asac> afaik wireless tools have a copy of that header for each version they support
<calc> i should know soon if my system works in i386 mode
<asac> calc: nm might be broken
<calc> i was having trouble in the past in i386 but it may be resolved with tribe-3
<stgraber> asac: now it also work with KNetworkManager, so yes that may be an amd64 specific bug
<asac> stgraber: would be great if you could test on gnome nm applet as well
<asac> because thats the code i know
<calc> 6m left then burning
* calc goes to get a cd
<stgraber> asac: I have the ubuntu i386 iso ready, just le met reboot and burn it
<asac> stgraber: great
<asac> i wait another 10 minutes then :)
<stgraber> let's burn this iso :)
<calc> writing cd
<asac> oh we got a race ;)
<stgraber> 1min remaining
<calc> unknown
<calc> nautilus one doesn't say for me
<asac> nautilus doesn't in gutsy ... shame
<stgraber> finished, well the "write disc" option does for me and I think it's nautilus
<stgraber> be back in a minute
<calc> done
#ubuntu-devel 2007-07-27
<calc> booted
* calc kicks the desktop, it should be coming up by now
<calc> takes 2 min to X then another 2 min to gnome startup, lol
<calc> doesn't look like NM wants to connect to the open ap in ubuntu i386 tribe-3
<stgraber> ok, result here are : WPA -> keep asking the key, public -> connected successfully
<calc> stgraber: which did you try first?
<calc> stgraber: open or wpa?
<stgraber> so exact same test results as I had with Kubuntu just before (WPA failed at the beginning and worked after a moment)
<stgraber> calc: wpa, then an open, then another wpa
<calc> when i tried open first then wpa it didn't work for either
<calc> so 1. open (fail) 2. wpa (asked lots of times) 3. open (passed)
<stgraber> so looks like we need to try a WPA before being able to connect to open :)
<stgraber> funny
<calc> yea i think so
<stgraber> but I'd prefer being able to connect to WPA rather than public :)
<calc> if you can reproduce that on yours as well then it is confirmed
<calc> stgraber: i was able to connect to WPA earlier somehow, but not anymore
<stgraber> ok, let's me reload NM (both daemon and applet)
<stgraber> calc: yes, me too :)
<calc> something is really buggy
<calc> er now it worked, wtf
<calc> beat on it long enough and it starts working for no reason
<calc> grr
<calc> looks like i am still stuck on feisty for my dev work in a gutsy chroot
<asac> stgraber: please try manual wpa_supplicant
<asac> stgraber: starting in a fresh state
<asac> thats all i can do for network manager
<asac> if it works that way ... we should be able to get it work in nm as well
<asac> stgraber: you said on amd64 it didn't work at all?
<calc> asac: its probably just so flakey that he thought it didn't work at all...
<calc> asac: that is what i am seeing here on both i386 and amd64, it rarely works
<calc> it seems to somewhat reliably work for open if i try to connect to wpa first
<asac> calc: you get ioctrl warnings?
<calc> 1. wpa (fail) 2. open (work)
<calc> asac: hmm not that i recall, i did get it when trying to force wpa-driver to ipw in network/interfaces before
<asac> ah
<calc> i don't see any ioctl messages in daemon.log though
<stgraber> ok, I had the same behaviour as calc, you can't directly connect to a public AP :)
<asac> stgraber: what ap_scan method does nm use (in syslog)
<elmo> err - I'm confused
<elmo> I just mke2fs'ed a new partition - how do I get it to appear in /dev/disk/by-uuid/ ?
<stgraber> asac: AP_SCAN 1
<asac> stgraber: if you use the sequence in log manually ... does it work?
<stgraber> I just tried with the sequence I pasted before, it works but there is a 2-3 minutes delay before when I try the command and when it finds the AP and connect
<calc> stgraber: when it worked for me earlier when doing the manual way it took several minutes as well
<asac> stgraber: but it connects at some point?
<calc> which seems odd
<asac> stgraber: if you look at syslog
<asac> nm adds more info to wpa_supplicant
<asac> maybe that boosts a bit?
<stgraber> asac: NM gives up before wpa_supplicant manage to connect, I'm currently trying with the syslog sequence
<stgraber> ok, worked as well after two disconnects and a 1-2 min delay
<asac> can you capture a log for that?
<asac> i want to see if i can see in code whats going on with wpa_supplicant ... what is it doing all the time?
<stgraber> http://paste.stgraber.org/2259 <-- this is the used sequence
<asac> line 19-END takes 1+ minutes?
* calc wonders what would happen if the kernel was downgraded to feisty's
<calc> its not doable on a boot cd but would be interesting to see if it was the kernel at fault somehow
<stgraber> asac: nope, line 18 to end
<stgraber> like if it didn't find the AP before
<asac> do you have wpa_supplicant log?
<asac> with -dd ?
<asac> you only see the fall-out on wpa_cli console
<stgraber> asac: http://www.stgraber.org/download/wpa-output
<stgraber> asac: this time went faster, don't really know why though
<stgraber> faster = 40s to associate which is still a lot (I don't know what is the timeout for nm-applet)
<asac> yeah
<asac> what the hell does Wireless event: new AP: 00:00:00:00:00:00
<asac> mean
<asac> stgraber: how many ssids do you have?
<stgraber> asac: receiving 5, sometimes 7
<asac> 00:14:d1:c0:39:80 ??
<asac> thats the one finally connected to?
<stgraber> asac: yes
<asac> its getting blacklisted multiple times
<asac> Added BSSID 00:14:d1:c0:39:80 into blacklist
<asac> everytime before that we get a "Wireless event: new AP: 00:00:00:00:00:00"
<calc> i got some things about all 0's ap in the wpa_cli
<calc> earlier today
<asac> somehow like this events prematurately kills our right association attempt
<calc> when it failed to assoc
<stgraber> yes, I just don't really see where the hell does this 00 AP comes from :)
<asac> welll its really just the 00:00:00:00 ping pong
<asac> that appears to consume that time
<asac> once this ping-pong is stopped by some timeout
<calc> and kills the assoc attempts i think as well
<asac> it directly connectes
<calc> apparently after several minutes
<asac> Removed BSSID 00:00:00:00:00:00 from blacklist (clear)
<asac> Removed BSSID 00:14:d1:c0:39:80 from blacklist (clear)
<asac> i think the timeout is one minute
<asac> maybe if you have bad luck you get multiple runs of these
<asac> stgraber: can you try to get a long of an attempt that takes longer?
<asac> e.g. 2-3 minutes?
<elmo> evand: ping
<stgraber> asac: I think I may get one if I completely reload ipw3945
<calc> asac: i have to leave now :\ but i can work with you more tomorrow if you would like
<asac> calc: right ... i will ping you if i need more info :)
<asac> thanks!
<stgraber> asac: I had a 50s long one with 3 disconnects
<stgraber> asac: maybe using the proto, key_mgmt, pairwise and group params make things a bit faster (no need to detect)
<calc> asac: it sounds like stgraber has the exact same issue as I am having, so between the three of us we should figure it out
<asac> stgraber: ok ... can you try without these details?
<stgraber> sure
* calc bbl
<asac> calc: my feeling is that wpasupplicant is the problem
<stgraber> asac: without the settings, it took much time to try to associate for the first time, then it goes pretty fast (only two disconnects)
<stgraber> so only a bit more than a minute
<asac> you have a log of the long run?
<asac> the first?
<stgraber> asac: http://www.stgraber.org/download/wpa-output1 <-- 3 disconnects (50s)
<asac> stgraber: great
<stgraber> asac: http://www.stgraber.org/download/wpa-output2 <-- 2 disconnects (1m)
<asac> can you keep those files up for a few days?
<asac> i have to sleep now :)
<stgraber> sure
<stgraber> yeah, me too :)
<asac> thanks for your help!
<calc> asac: that would make sense, since open ap with dhclient connects immediately
<stgraber> yes, this association to 00:00:00:00:00:00 seems to be the problem
<stgraber> as blacklisting, unblacklisting and then retrying to connect takes a while
<asac> the problem is that it tries to deal with that imo
<stgraber> so it shouldn't be arch dependant, that's already a good news :), now it's about finding a patch upstream (if any)
<asac> yeah
<calc> we could try downgrading to the version in feisty as well
<calc> to see if that helps
<calc> i tried 0.5.8 which might already have been buggy in that respect
<calc> if 0.5.7 is new enough to work with the current kernel, etc
<calc> 2007-05-28 - v0.5.8
<calc> 	* updated driver_wext.c to build with the current wireless-dev.git tree
<calc> 	  and net/d80211 changes
<calc> one of the modifications in 0.5.8...
<asac> in fact 00:00:00... events are disconnect events from driver
<asac> when looking where those are actually handled i found this ...
<asac> http://pastebin.mozilla.org/178297
<asac> read line 6-10
<asac> apparently we run through this ... and full disconnect is scheduled
<asac> so for our case its not
<asac> wpa_s->key_mgmt == WPA_KEY_MGMT_WPA_NONE
<asac> and neither is:
<asac> #
<asac> wpa_s->wpa_state == WPA_4WAY_HANDSHAKE &&
<asac> #
<asac>             (wpa_s->key_mgmt == WPA_KEY_MGMT_PSK ||
<asac> #
<asac>              wpa_s->key_mgmt == WPA_KEY_MGMT_FT_PSK)
<stgraber> asac: there's also line 25
<stgraber> asac: which seems to be about this 00:00:00:00:00:00 ssid
<asac> yes ... but that is just a rescan scheduling
<asac> in case it was associated
<asac> at least i think it is ... should be ok
<asac> ... though it might consume time
<asac> hmmm ... that is about bssid
<asac> maybe we should just ignore disconnect events when associating
<asac> and instead hope for a timeout to kick in
<evand> elmo: pong
<elmo> evand: unping
<asac> stgraber: can you try this ugly patch for wpasupplicant?
<asac> stgraber: http://people.ubuntu.com/~asac/test_ignore_disconnect.patch
<stgraber> yes
<stgraber> asac: I made a dpatch and I'm currently updating my pbuilder
<asac> ah ok
<asac> i think you could have just patches against unpacked source tree ... but well :)
<asac> its safer this way
<stgraber> asac: compile failed
<asac> can you fix it?
<stgraber> it's about the events.c file
<asac> yeah tell me the line and error
<stgraber> http://paste.stgraber.org/2260
<asac> oh
<asac> yeah ... go to the patch
<asac> add a { at the end of the line
<asac> of the if
<asac> you see that?
<asac> stgraber: should look like the if line below
<stgraber> oh, didn't see it while working on the patch :)
<asac> good
<asac> i updated the patch http://people.ubuntu.com/~asac/test_ignore_disconnect.patch
<asac> in case
<asac> but just edit the patch in place ;)
<stgraber> ok, compiled and installed
<asac> doe it break everything?
<asac> :)
<asac> stgraber: any update?
<stgraber> asac: seems like disconnects has been replaced by timeout
<stgraber> but no association anymore
<stgraber> <2>Authentication with 00:00:00:00:00:00 timed out.
<stgraber> <2>Trying to associate with 00:14:d1:c0:39:80 (SSID='graber-wifi' freq=2412 MHz)
<stgraber> it already did that 8 times
<asac> ok
<asac> what state are you in?
<asac> do you see that in supplicant log?
<asac> is it ASSOCIATING?
<asac> or SCANNIG?
<stgraber> I see that in wpa_cli
<stgraber> it seems to be ASSOCIATING
<stgraber> it does : DISCONNECT -> SCANNING -> ASSOCIATING (looking at the wpa_supplicant window)
<stgraber> then start again at DISCONNECTED (once the MAC is blacklisted)
<asac> stgraber: ok ... i have to go :) ... many thanks.
<stgraber> asac: np :), ping me when you have a new wpa_supplicant to test
<ash211> Can someone please take a look at bug 127551?
<ubotu> Launchpad bug 127551 in Ubuntu "[feisty]  dpkg-reconfigure xserver-xorg: failure because of missing package xresprobe" [Undecided,New]  https://launchpad.net/bugs/127551
<ash211> Why would xresprobe be in the LiveCD but not the Alternate?
<mneptok> because the alternate never invokes X
<mneptok> but it should still install it
<mneptok> [mneptok@set]  mneptok :: which xresprobe
<mneptok> /usr/sbin/xresprobe
<mneptok> ^^ installed from alternate ^^ (but Feisty)
* ryanakca wonders if canonical-sysadmin will mind his advertising the advertising of their channel on the planet
<mneptok> ryanakca: is it necessary?
<ryanakca> mneptok: http://blog.ryanak.ca/archives/40
<ryanakca> Sysadmin Appreciation Day, stop in to say thanks :D
<mneptok> yeah, i don't think making the channel a target of spambots and kids wanting help with Apache is a great way to say thank you ;)
<crimsun> while the thought would be appreciated, I would err on the side of caution.
<mneptok> buy beer. it's meaningful.
<mneptok> :)
<ryanakca> Okies then. *snips it out*
<ryanakca> mneptok: better?
<mneptok> smells like home cookin' :)
* ryanakca checks the box to stick in on planet :D
<wick2o> hello
<wick2o> i have found something missing with the hylafax-server package
<wick2o> I'm not sure who/where would be best to give the info too
<wick2o> in the setup.cache file there is a BASECONFIG='/usr/bin/uunecode'
<wick2o> it SHOULD be BASECONFIG='/usr/bin/uuencode -m ===='
<wick2o> the package wont forward any attachments if this isnt changed
<wick2o> i just spend 8 hours troubleshooting this issue
<soren> wick2o: https://launchpad.net/ubuntu/+source/hylafax/+filebug
* soren falls asleep
<wick2o> thank you soren
<Vorbote> wick2o: as hylafax is in universe, you may find a more sympathetic audience in #ubuntu-motu as as well as filing a bug
<wick2o> k
<wick2o> Just tring to save some other people the hassle of what i had to do today
<calc> i have an issue
<calc> how do i do an and statement in shell
<calc> eg
<calc>  [ -s $$f (and) ! -h $$f ] 
<Hobbsee> calc: it seems [ -s $$f -a ! -h $$f ]  from man test, if i'm reading it right
<Hobbsee> calc: may need to put brackets around each expression, though
<StevenK> -a is frowned upon
<StevenK> [ -s $$f ]  && [ ! -h $$f ] 
<Hobbsee> there you go, StevenK can answer then
<calc> ok
<Hobbsee> i was wondering about that, though
<calc> thanks :)
<calc> i couldn't find -a in bash manpage so that was why i had to ask
<calc> i thought it was something like -a but wasn't certain and didn't want to break this code, heh
<StevenK> calc: man test
<StevenK> not bash
<ajmitch> since [ is special & all
<ajmitch> weird unixy stuff
<calc> StevenK: ah ok
<StevenK> [ is a symlink to test :-)
<ajmitch> StevenK: symlink?
<StevenK> Hrm, I thought it was
<calc> a symlink apparently counts as a regular file as far as -s is concerned
<ajmitch> doesn't appear to be so now
<calc> duh i mean -f
<calc> so i changed it to -s and ! -h to see if that helps
* StevenK wonders where he saw that
<calc> grr it still doesn't do what i want, how is this getting by my test
* calc looks at the code closer
<calc> http://pastebin.com/d5a36c142
<calc> any ideas about how symlinks are getting uuencoded?
<calc> does that code look correct?
<calc> hmm actually it is working i am too tired or something
<calc> its working perhaps too good
<Mithrandir> personally, I much prefer -L to -h, but that might just be me.
* StevenK waits for the sparc buildds to stop getting hit up by gcc and glibc
* Hobbsee stomps on Mithrandir's feet in greeting
<calc> i forgot the thing i was trying to encode was in the orig.tar.gz oops
<Mithrandir> Hobbsee: bad Hobbsee!
<Hobbsee> Mithrandir: i'm not bad!  *looks around innocently*
* Hobbsee couldnt *possibly* be bad.
<ajmitch> Hobbsee: sure, you've convinced me *cough*
<infinity> StevenK: You're lucky they're up at all, don't complain.
<calc> is there a way to use test to check if the beginning of a filename matches some chars?
<calc> eg if filename starts with src680 ignore the file
<StevenK> infinity: :-P
<StevenK> calc: case
<calc> StevenK: http://pastebin.com/d223cfa88
<calc> StevenK: is that what it should look like
<calc> StevenK: i thought it would work like that but for some reason it still ends up encoding the src680 files
<calc> er is what i thought it should look like
<StevenK> $$f might not start with src680
<StevenK> *src680*, perhaps?
<StevenK> Morning pitti
<calc> ah ok, yea it probably starts with src/src680
<calc> thanks for the help! :)
<pitti> Good morning
<ajmitch> hi pitti
<pitti> hey ajmitch
<calc> that worked
<Hobbsee> ajmitch: :P
<Hobbsee> morning pitti
* mneptok falls through the ceiling onto Hobbsee 
<Hobbsee> mneptok!
* Hobbsee shifts to the side, and watches mneptok thud on the ground
<mneptok> where?!
<Hobbsee> @btlogin
<pitti> doko: two glibc uploads every day? :-)
* Hobbsee hugs pitti 
<doko> pitti: fixing bugs at a fast pace =)
* pitti hugs doko 
<pitti> doko: don't feed the buildds too much, lest they get too fat :-)
<kt`> hola!
<kt`> anyone around
<Hobbsee> perhaps
<kt`> :o
<kt`> I have a few questions relating to Pulp.
<\sh> happy sysadmin day to all of you :)
<kt`> heh
<kt`> it is sysadmin day
<stdin> kt`: http://www.sysadminday.com/ :)
<kt`> im there :P
<kt`> i searched it when he said that was there before the link :D
<kt`> anywho, anyone familiar with Pulp?
<asac_> hi all
<kt`> hi
<soren> There's a quite vocal discussion on the ubuntu-server mailing list about people wanting separate repositories for server packages to make it clearer which packages are covered by the 5 years of support in our LTS releases. Could someone who has been around a bit longer than I perhaps shed some light on the issues?
<soren> Is it just the packages in http://people.ubuntu.com/~ubuntu-archive/germinate-output/dapper/server that are covered, or is it "server installations"?
<stdin> soren: all the packages in the "main" repository are covered by the LTS suppost
<ajmitch> afaik, it's the packages in the server seed for the 5 year support
<Mithrandir> stdin: no, that's not correct.
<soren> stdin: Yes, but LTS means 3 years for desktop and 5 years for servers.
<ajmitch> but I don't have any more info than you do, I suspect :)
<Mithrandir> stdin: that is, not all of them are covered with a 5 year support guarantee.
<soren> Mithrandir: It's not?
<soren> Mithrandir: Ah, right.
<ivoks> there is no disctinction betwean server and desktop packages
<soren> ivoks: That's always been my impression, too.
<soren> ivoks: I've always thought it was "server installations".
<ajmitch> ivoks: no visible distinction, but I've consistently heard that it's seed-based - best to ask the canonical support crew
<stdin> Mithrandir: which aren't?  I thought that main was the officially supported repo?
<soren> ajmitch: I suppose.
<ajmitch> soren: "server installations" is suitably vague, as we've seen on the lsit
<ivoks> for next LTS, this could be solved trough 'Section'
<Mithrandir> stdin: firefox for instance is not supported for five years.
<ivoks> or... another header for packages
<kt`> anyone familiar with Pulp?
<ajmitch> ivoks: it wouldn't be hard to do more binary package mangling for selected packages, if it's worthwhile
<ivoks> i think it is
<ivoks> people ask support related questions on mailling list
<ivoks> and with additional header it would be possible to inform admin that packages are not longer supported
<ivoks> just an idea...
<pitti> hey mvo!
<mvo> hey pitti
<soren> pitti: How would you make the distinction between which packages to support (in terms of security fixes) for 5 years vs. 3 years? The server seed?
<pitti> soren: I don't have a very good idea about this ATM; server seed germination is obvious, but there might be more that we need to support
<pitti> soren: pretty bad that we did not talk about this when releasing dapper
<pitti> soren: in theory we could probably demote everything that is not supported any more to universe in dapper, but that would be really hackish
<soren> pitti: Quite. There's a bit of discussion on this subject going on on the ubuntu-server mailing list, and I'd like to be able to give some sort of clear answer, but I haven't got it. :(
<pitti> this deserves an in-depth discussion at next UDS IMHO, since it is not trivial to define and communicate
<soren> Are you subscribed to the ml?
<pitti> no, I'm not
<soren> Ok.
<ivoks> Tonio_: hi
<Tonio_> hey ivoks :)
<Tonio_> ivoks: how are you ? such a long time we didn't discuss ;)
<ivoks> Tonio_: busy as hell :/ finishing my faculty and working \; no time for anything :) how are you?
<Tonio_> ivoks: working as hell, no time for anything :)
<Tonio_> ivoks: welcome to the capitalist world :)
<ivoks> hehe
<ivoks> been there for some time already :)
<Tonio_> well the point is that my new job is based at 200 km from home, so that's kinda hard to loose so much time in the train....
<ivoks> with TGV that's 5mins ;)
<Tonio_> ivoks: dream on, no TGV from Orlans to Paris
<Tonio_> ivoks: just a stupid TER train......
<cjwatson> soren: the clear answer is "if you have doubts, talk to your contacts in the Canonical support department"
<cjwatson> Mithrandir: test -L is clearer, but test -h is more portable (if you care about Solaris, which many people don't; of course then you have to forgo test -e as well)
<infinity> Does anyone actually still care about portability to Solaris's braindead shell?
<Hobbsee> oh uni site, i hate thee...
<soren> cjwatson: Sure, but the perception in the community seems to be that it's the packages on the server CD and nothing else, and that seems to stop them from using Ubuntu (becuase they need software not on the CD).
<ivoks> CD's should be called 'install CD'
<cjwatson> soren: that's certainly incorrect, but I don't think it's up to anyone else to tell the support department what they're going to support, so the right answer's always going to be to contact support in case of doubt
<cjwatson> infinity: I hope not
* Hobbsee rains curses on this uni student portal
<cjwatson> but it's a reason why some people still have the test -h habit
<Hobbsee> clearly they havent heard of the idea of "put the important stuff in bold / bigger / otherwise different" from the help files, and other unimportant stuff.  and actually leaving whitespace on the webpage.
<soren> cjwatson: I agree, but if this perception is as common as it seems to be, it's something we should handle somehow. Just being more clear than "free security updates and commercial technical support
<soren> will be available for three years on the desktop, and five years on
<soren> the server" (From Dapper's release announcement) will help a lot.
<soren> What the..
<soren> will be available for three years on the desktop, and five years on the server" (From Dapper's release announcement) will help a lot.
<soren> ffs..
<soren> cjwatson: I agree, but if this perception is as common as it seems to be, it's something we should handle somehow. Just being more clear than "free security updates and commercial technical support will be available for three years on the desktop, and five years on the server" (From Dapper's release announcement)  will help a lot.
<cjwatson> soren: I don't have a problem with being more specific, but it should be the support team making the statement (preferably in the form of a modified web page on www.ubuntu.com or something) rather than distro team staff
<soren> cjwatson: Good point.
<soren> cjwatson: Well.. It's still going to affect the security team, as I suspect the period of time the support team will support a package will have to correspond to the period of time the security team will support it.
<soren> cjwatson: I'll talk to support about it.
<lifeless> whats the right way to get 'cryptsetup' to work from within a udev rule ?
<siretart> lifeless: there has been a bit of discussion in Sevilla about this
<siretart> lifeless: I think we'll need some password manager frontend (ideally one console only and a graphical one) for secure typing of your password
<siretart> lifeless: the udev rule would detect that it has to mount a crypted device, connects/starts up the password frontend and tries to mount
<siretart> lifeless: In my opinion, (I'm not sure if Keybuk agreed with me here), it should be possible to provide a path to a keyfile in /etc/crypttab, so that you can have your home volume encrypted with a keyfile stored on a usb stick
<lifeless> siretart: well, /etc/crypttab should not be needed
<lifeless> when /etc/fstab is populated with guids
<lifeless> then cryptsetup makes the volid for /home or /root etc appear, so udev rules that mount as volumes become available in fstab, will just work
<soren> How does vol_id make sure that the guid stays the same for encrypted filesystems? With LUKS, there's a superblock with meta-info about the filesystem, but using plain cryptsetup it just looks like gibberish, doesn't it? AFAIK, there's no metainformation about the volume at all.
<siretart> lifeless: err, and how would you specify the path to your keyfile in /etc/fstab?
<siretart> lifeless: and btw, you are aware that the current cryptsetup package in debian/ubuntu already uses a /etc/crypttab?
<lifeless> siretart: I know it claims to use one, however have you looked closely at what it tries to do? its madness
<lifeless> soren: I only care about luks
<lifeless> soren: also, you have two volume ids: the volid of the encrypted partition; and the volid of the decrypted partition
<lifeless> the volid of the former is the volid of e.g. /dev/sda1, AIUI that comes from the partion table no?
<soren> lifeless: No, vol_id looks at the contents.
<soren> lifeless: Otherwise it'd be a bit hard to make i globally unique, I guess.
<lifeless> soren: meh, I'm using the wrong terms perhaps. the GUID - that appears happily stable for luks fs's.
<soren> lifeless: Imagine two users with identical hard drives both selecting "guided partitioning" in the installer. They'd have identical partition tables.
<soren> lifeless: Yes, because LUKS keeps a GUID in the LUKS superblock.
<lifeless> ok, cool.
<soren> lifeless: vol_id first tries to detect what sort of block device it's looking at (disk, generic partition, raid partition, vfat partition, ext3 partition, etc.) and the uses a special GUID generation algorithm based on that.
<lifeless> btw, two users selecting guided partitioning would not end up with the same exact partition table on more exotic disklabels where the whole thing is GUID driven
<soren> lifeless: It has to, really, because it needs to be globally unique, while staying static for a particular block device, and since different types of block devices keep their static bits in different places (ext3 has the superblock in the beginning of the volume (IIRC), while a pv for lvm has its pv superblock at the end.
<lifeless> soren: sure, I can see what vol_id needs to do; I've just never felt the need to read the source.
<soren> lifeless: Probably not, I was just illustrating why basing GUID on partition table info would be insufficient.
<soren> lifeless: I wish I could say the same. :)
<lifeless> a simpler example btw would be to say 'dd /dev/sda1 /dev/sda2 && dd /dev/zero /dev/sda1' is defined as moving where the guid points at
<Mithrandir> (dd if=/dev/sda1 of=/dev/sda2 or dd < /dev/sda1 > /dev/sda2)
<siretart> lifeless: I'm currently using current crpytsetup's /etc/crypttab. for the simple case (luks and password from terminal) it is surely overkill
<siretart> lifeless: I wonder how you want to manage the keyfile case
<lifeless> Mithrandir: meh, I'm still recovering
<lifeless> siretart: the keyfile contains a password right ?
<siretart> lifeless: the keyfile IS the password. only longer
<siretart> (yes)
<lifeless> siretart: well, its either a passphrase, or a private key I guess?
<siretart> lifeless: exactly
<lifeless> siretart: I would suggest /etc/cryptkeys/GUID
<siretart> actually, it can be both. you have up to 8 keyslots IIRC
<siretart> lifeless: and if you want it to place on a removable media?
<lifeless> siretart: so there are two cases here
<lifeless> udev finds the crypted partition before the removable media exists
<lifeless> and thus inserting the removable media needs to trigger decryption of the crypted partion
<lifeless> second case:
<lifeless> removable media is inserted/found first, so udev should decrypt the crypted partition as it finds it
<lifeless> is this for a user partition, or for something for all users
<lifeless> ?
<siretart> I think both crypted  home and crypted shared data volumes are possible here.
<siretart> (with crypted share data might even be the rootfs)
<lifeless> right, my root is crypted
<lifeless> anyhow
<lifeless> cheap answer:
<lifeless> ln -s /media/FOO/keyfile /etc/cryptkeys/GUID
<siretart> well, if we agree that we need a password entering frontend, well, I think that would be the natural place to look for keyfiles on removable media, no?
<siretart> can you ensure that a usb stick gets always mounted on the same mountpoint?
<lifeless> ln -s /dev/by-id/GUID/keyfile /etc/cryptkeys/GUID2
<lifeless> oh, I agree that we need password entry
<lifeless> I don't use external keyfiles myself; just need the ability to enter a password from inside a udev rule
<siretart> the symlinkery should indeed work
<siretart> we 'just' need to make sure that usb sticks get either mounted automatically in initramfs, or make the frontend mount them
<siretart> what would you prefer?
<lifeless> well
<lifeless> for me, I don't care about the external media, so suit yourself.
<lifeless> :)
<siretart> we are talking about breaking users systems, you know?
<lifeless> I'd like to see a simple setup like mine so easy and robust its default in 2 or 3 releases
<lifeless> crypto for all
* siretart as well
<lifeless> external media keyfiles are not simple enough to explain to mom n pop
<siretart> but the symlinkery idea sounds really sane to me.
<lifeless> cool
<lifeless> I'm happy to help you with your preferred setup; just noting its not what I'm actually *aiming at*
<siretart> as said, we 'just' need to make sure it gets mounted in initramfs, I'm not sure how hard that will be
<lifeless> udev rules FTW
<siretart> special rules for initramfs usage only. on a real system, we hal et. al
<siretart> ok, cool. glad to hear you are working on that! :)
* siretart is out for lunch, cu later!
<lifeless> working, well not so much. At this point knowing there is a missing link is useful though;
<Tonio_> seb128, pitti: I'm a bit lost on that build with the buildd... https://launchpad.net/ubuntu/+source/knetworkmanager/1:0.2-1ubuntu2
<Tonio_> seb128, pitti: only fails for i386 for a reason I can figure out....
<Tonio_> seb128, pitti: local i386 build works in pbuilder btw, so it looks like a buildd server config issue, but I'm unsure....
<seb128> maybe give a build retry
<Tonio_> seb128: should I reupload for this or can you or someone else relaunch the build ?
<seb128> pitti can
<Tonio_> seb128: oki ;) lett's wait for pitti then
<infinity> I can.
<Tonio_> infinity: so can you please ?
<infinity> That doesn't look lik a buildd issue to me.
<Tonio_> infinity: well the error is a bit weird, as it just worked with others architectures..... that's why I'm a bit lost....
<infinity> I'll retry it for kicks, but that looks like a bug to me.
<Tonio_> infinity: packaging bug ?
<infinity> Timestamp skew messing with the way autoconf gets run, I suspect.
<Tonio_> infinity: interesting.... so autoconf is only called with i386, causing the issue....
<Tonio_> infinity: then I suspect missing +x flag on scripts due to diff.gz can cause the issue
<Tonio_> infinity: I'll try to chmox +x the scripts within rules and we'll see....
* Tonio_ burns kde upstream that don't provide the admin/ scripts in their tarball..... and burns that rule that said "don't touch upstream tarball" :)
<StevenK> infinity: Ping. Any news about libnss-db?
* StevenK says at 8pm at work, utterly sick of anything to do with routing or fucking ipsec
<infinity> StevenK: lpia's consumed all my time, so far, but I'm stuck in a London timezone still (jetlag and I are having "words"), so I have plenty of workday ahead. :)
<StevenK> infinity: Heh
<infinity> Tonio_: The retry may magically work (it all depends on if one gets the timestamp skew required to force autoconf to run), but the bug will resurface.
<infinity> Tonio_: If you don't want autoconf running, read the autotools-dev readme, and so something about the timstamp skew in debian/rules.
<Tonio_> infinity: well I may try to fix the packaging so that autoconf doesn't crash when called..... I'm pretty sure that's just due to the scripts addition in diff.gz, missing executable flag
<Tonio_> infinity: that weird, but due to tarball issue..... would be easier to rebuild it in fact (what I may do if that still fails after next upload)
<StevenK> Hrm. Hopefully libc6 build sparc the second will finish soonish
<Tonio_> infinity: best is to get the tarball fixed upstream I guess :)
<infinity> Tonio_: Timestamp skew isn't a tarball issue, really (unless you count "not using AM_MAINTAINER_MODE" as a tarball issue)
<Tonio_> infinity: I know, but appart from the Timestamp thing, autoconf shouldn't crash when called right ?
<infinity> Tonio_: Oh, well, yeah, it would be nice if it was executable, I suppose. :)
<Tonio_> infinity: timestamp skew is causing autotools to be called, that's the point, but that doesn't explain the crash...
<Tonio_> infinity: hehe, I just missed that adding admin/ entry in diff.gz would loose the +x flag in fact :)
<Tonio_> infinity: and debian packaging can't be merge due to universe dep to get admin/ entry copied
<Tonio_> infinity: that's why I have to do all that crap to make it to work..... I'll probably just rebuild the tarball and ping upstream for nice tarball in the future, instead of doing crap packaging....
<cjwatson> pitti: bug 62986 is another possible candidate for 6.06.2
<ubotu> Launchpad bug 62986 in debconf "edgy installer randomly hangs on Core 2 Duo, Dell D620" [High,Confirmed]  https://launchpad.net/bugs/62986
<pitti> doko: any idea about the lib32gcj things on http://people.ubuntu.com/~ubuntu-archive/testing/gutsy_probs.html ?
<pitti> cjwatson: indeed, thanks for digging it out; it's the "Retry flock() on EINTR" bit, I assume?
<cjwatson> no
<cjwatson>   * Make sure that apt status commands and debconf protocol commands under
<cjwatson>     debconf-apt-progress are properly interleaved. Closes: #425397
<pitti> ah, that one
<cjwatson> always assuming that it actually works
<pitti> cjwatson: there's no patch attached, I take it it's reasonably unintrusive?
<cjwatson> retry-flock-on-EINTR was for problems I saw occasionally on the live CD
<pitti> cjwatson: I had lots of fun with EINTR in Python programs; that's one of the nasties things I ever saw :/
<cjwatson> but that's in Feisty already
<geser> can someone look at the apache2 build failure? http://launchpadlibrarian.net/8577358/buildlog_ubuntu-gutsy-i386.apache2_2.2.4-2_FAILEDTOBUILD.txt.gz
<geser> it fails nearly at the end with "dpkg-deb: building package `apache2-mpm-worker-dbgsym' in `../apache2-mpm-worker-dbgsym_2.2.4-2_i386.ddeb'.", "objcopy: debian/apache2-dbg/usr/lib/debug/usr/sbin/apache2-mpm-worker: Invalid operation"
<pitti> geser: oh, noes, that one again
<pitti> geser: I'll have a look later
<geser> thanks
<pygi> siretart, poke
<cjwatson> pitti: unfortunately the patch is rather large
<pitti> cjwatson: TBH I don't feel qualified to judge an installer patch; if it backports well and works in gutsy, and you are convinced about it, I take your work for it; it does seem quite nasty, given the server focus
<cjwatson> pitti: http://launchpadlibrarian.net/8582373/debconf.r2214.diff
<pitti> s/your work/your word/
<cjwatson> problem is that I've never been able to reproduce it, so I'm not *giving* my word until I've got some affected people to test it
<cjwatson> just wanted to let you know it was on the radar
<pygi> siretart, going to eat now, but please poke me when you get time
<pitti> cjwatson: ok, thanks for the heads-up
<geser> can an ubuntu-main-sponsor look at bug #128614? this should make libtritonus-java build on amd64
<ubotu> Launchpad bug 128614 in libtritonus-java "[Sync Request]  Sync libtritonus-java_20070428-3 from Debian unstable (main)" [Undecided,New]  https://launchpad.net/bugs/128614
<pitti> geser: it's an universe package, so you can ack it yourself
<geser> pitti: because I only looked at the source portlet in the bug itself where is still main
<pitti> geser: it's new in gutsy, it might have accidentally been synced to main and moved l ater
<geser> seems so
<StevenK> Neat. I haven't seen a buildd say that before.
<StevenK> "NOT OK : Builder returned BUILDERFAIL when asked for its status"
<alesan> I am trying to fix what I think it is a bug or at least an incorrect behaviour in ubuntu:
<alesan> basically when you have multiple (remote) X displays and you plug in a USB key that key gets assigned to a random user/session
<alesan> I think it should be always assigned to the local user
<alesan> do you have an idea where I could play with options like this?
<infinity> StevenK: Hardcoded path to /usr/bin/bunzip2 in buildd scripts disagrees with the Debian maintainer's brilliant plan to move bzip2 from /usr to / without linking it.
<infinity> StevenK: Or, rather, he linked it, it broke on Hurd, he removed the link, and provided no migration path.
<infinity> StevenK: And we seem to have absorbed the bug and done nothing about it either.  Go us.
<iwj> Why would it use an absolute path anyway ?
<infinity> iwj: Oh, it really shouldn't, and I'm fixing that in my LP branch (not my code, don't shoot the messenger), but moving binaries willy-nilly is still sick n' wrong.
<iwj> I think it's perfectly sensible and that's what PATH is for.
<seb128> iwj: hi. Should I do a MIR for consolekit or do you want to do it since you started looking at it?
<iwj> There's one drafted already although I don't think it's finished.
<iwj> I'm still playing with it and will MIR when I'm done.
<iwj> It's looking quite good, though.
<seb128> ok, good, thanks
<cjwatson> whoa, what set my gdm theme to debian-moreblue?
<Mithrandir> cjwatson: unsure, but I saw the same this morning
<alesan> it seems I should configure gnome-volume-manager to assign usb keys to a fixed X session, any idea how to do that?
<seb128> cjwatson: I've fixed the bug this morning with 2.19.4-0ubuntu3
<iwj> cjwatson: Welcome to current gutsy :-).
<iwj> Oh, too late!
<seb128> cjwatson: I've merged gdm with the new Debian packaging (we didn't merge for some cycles since the debian version used to have everything in the diff.gz and that was manageable), the merge was not trivial and I might have make some small mistakes like this one
<pitti> alesan: you can't do that with current g-v-m
<alesan> pitti, what do you mean? is current version not implementing that but a later revision?
<alesan> or is it just not possible
<pitti> alesan: it's not possible
<pitti> alesan: USB devices are always mounted as the owner of the current foreground X session
<alesan> well, ... any possible workaround
<alesan> ?
<cjwatson> seb128: ah right, thanks
<cjwatson> evidently my mistake was running apt-get upgrade relying on the automatic update :-P
<hunger>  /etc/pam.d/[kg] dm is reading /etc/default/locales now. Where is that file created? I don't have it and some apps complain about a not existing locale setting.
<Hobbsee> MOTU meeting in #ubuntu-meeting for anyone interested
<doko> pitti: not built anymore, should be removed from the archive
<pitti> doko: weird, it doesn't appear in archive-cruft-check
<pitti> doko: gcc-defaults builds lib32gcj-bc
<doko> ahh, ok, will remove it for the next upload
<pitti> doko: and gcj-4.1 still builds lib32gcj7-dev
<pitti> doko: great, thanks
<cjwatson> hunger: /etc/default/locale (no s) is created by the installer. It's a bug either that [gk] dm don't fall back to /etc/environment, or that the file isn't created on upgrade, I'm not sure which.
<pitti> Tonio_: shouldn't network-manager-kde Conflicts:/Replaces: knetworkmanager?
<Kano> hi, when will be fuse 2.7.0 in ubuntu? it is in sid...
<Kano> i already reported a bug
* Hobbsee could have sworn Kano asked this yesterday....
<Kano> waiting
<doko> iwj: the gij memory problems should be fixed with the last of the glibc uploads
<Kano> Hobbsee: i think it was 2 days before
<seb128> Kano: there is no bug on launchpad abou tit
<Tonio_> pitti: hum true, indeed... as I changed the naming of the package to sync with debian....
<Kano> seb128: you can be sure that there is one, as i added it
<Tonio_> pitti: sorry for the error, fixing this now
<pitti> Tonio_: I binary-NEWed it for now, but fixing appreciated
<seb128> Kano: well, it has not been confirmed and ubuntu-archive has not been subscribed if you prefer
<cjwatson> bug 128292
<ubotu> Launchpad bug 128292 in fuse "fuse 2.7.0 needed to fix issues with ntfs-3g and uuids in fstab" [Undecided,New]  https://launchpad.net/bugs/128292
<cjwatson> (to save anyone else looking it up)
<Kano> seb128: when i report a bug it is confirmed (by myself)
<Tonio_> pitti: thanks, will upload the fix in a couple of minutes
<cjwatson> seb128: ubuntu-archive shouldn't be subscribed since there are Ubuntu modifications and a developer needs to merge them
<seb128> Kano: somebody should do the new version merge
<seb128> cjwatson: yeah, I misread what Kano was saying, I though he was waiting for a sync to be processed
<pitti> mvo: we have another pending tzdata SRU; I'd appreciate if you could handle that: bug 123366
<ubotu> Launchpad bug 123366 in langpack-locales "Update to tzdata 2007f" [High,Fix committed]  https://launchpad.net/bugs/123366
<Kano> so lets see if it is in tomorrow. thats one major package
<Kano> as it is in main
<Kano> there have been same issues before for feisty and the needed update (a cvs snapshot with same fix) did not get in. therefore feisty was unusable for ntfs-3g + uuid
<seb128> Kano: not likely to be there tomorrow if nobody does the merge
<Tonio_> pitti: you'll hate me but can you please drop the upload I've done 1 minute ago...
<seb128> Kano: and there is no hurry, gutsy is still unstable for some months
* Tonio_ is so tired, no way to do something correctly today....
<Kano> btw. when will aufs used? every day there is another tool broken in live mode on amd64
<Kano> it was sudo, then date...
* Hobbsee notes that Kano does not appear to understand about large numbers of bugs, and people's workloads, and that most people wont drop everything to fix $mypetbug.
<Kano> Hobbsee: the bugs are major for me
<Hobbsee> Kano: how about you go and do the merge, and subscribe ubuntu-main-sponsors when you've done it, seeing as you're clearly a linux expert, and very interested.
<Kano> when you dont use ntfs-3g then not for you
<mvo> pitti: will look at it
<Hobbsee> Kano: the co-author of kantonix should surely be able to process a merge, instead of whine repeatedly on a development channel, which will likely get him ignored due to immense painfulness.
<cjwatson> Kano: thank you for your report. Full ntfs-3g integration is on the feature schedule for gutsy, so it's already on the list. However the people involved have other urgent things they're working on so we cannot promise you that it will be fixed tomorrow.
<Kano> cjwatson: well tomorrow is not the problem, but next week would be fine
<cjwatson> I'll link your bug from the spec so that it doesn't get forgotten
<cjwatson> I can't promise next week either. Feature freeze is a few weeks from now
<Kano> btw. i patched every avm driver that is downloaded by the fixed avm script
<Kano> the current restricted modules package is not that clear. i reported a few bugs against that too
<cjwatson> (https://wiki.ubuntu.com/WriteSupportForNTFS)
<Hobbsee> Kano: with patches, and did you subscribe ubuntu-main-sponsors after  the patches were applied?
<Kano> Hobbsee: i just added the file to one bug report
<Kano> the restricted modules is one package i do not fully understand. how these half build modules are made
<Hobbsee> Kano: you may want to see https://wiki.ubuntu.com/MOTU/Sponsorship/SponsorsQueue.  it is the universe one, but most applies to main too.  this will make sure that your fixes get in quicker, and will get you a lot further than just whining about how $yourpetbug hasnt been fixed.
<Hobbsee> that applies to any bug, not just the restricted modules.
<cjwatson> pitti: good news is that debconf-apt-progress at least doesn't appear entirely buggered in gutsy ...
<Kano> Hobbsee: instead of fixing the restricted modules i updated a kanotix avm package, the used getscript is the same also i use a combined patch to fix 2.6.22 issues
<Kano> Hobbsee: i test the ubuntu kernel on etch, recompiled with some fixes
<Hobbsee> Kano: l-r-m, and kernel stuff is in #ubuntu-kernel.
<Hobbsee> Kano: but updating fuse would be useful.  thankyou for effectively volunteering to do it.
<Kano> when you want ntfs-3g even as mount.ntfs then you need it
<Hobbsee> then i'll mentally thank you for fixing it, and contributing to ubuntu development in that way.
<Hobbsee> as will the other users.
<Kano> for ntfs there must be some things broken currently in kde, is it due to those preparations?
<Kano> like when you use ntfs usb drives
<Kano> you get an error when you are not root. same for linux filesystems, only fat works
<Kano> will try your hal...
<iwj> doko: Oh, good.
<Chipzz> alesan: I think your idea is fundamentally broken
<Chipzz> alesan: there is no such thing as "the logged in user"
<Chipzz> not when it needs to be strictly defined
<doko> iwj: a bug fixed eight months ago on FC, but never forwarded upstream to glibc 2.6 branch or trunk :-/
<Chipzz> consider fast user switching, or starting 2 X sessions from the console
<Chipzz> who's session does the usb key get mounted in?
<Chipzz> *whose
<alesan> Chipzz,
<Chipzz> or maybe nobody is logged in at all
<Kano> Hobbsee: in the write support for ntfs i see no mentioned kde changes?
<Kano> only gnome?
<alesan> Chipzz, well current's Ubuntu behavior *is not* good for a multiuser system
<Hobbsee> Kano: i dont know.  i dont follow ntfs-3g development
<alesan> Chipzz, it basically auotmount a usb disk based on which X session has foreground at that moment.
<Chipzz> which, given the alternatives, is the most sane solution I'ld say?
<alesan> Chipzz, well that is a problem, the quick and dirty solution is the user that is logged in on the local X display. Or maybe make this configurable.
<alesan> or, at least, mount the device with "open" permissions to all users :)
<Chipzz> there'll always be cases where that solution breaks, so there is no perfect solution I'ld say
<Chipzz> oh btw
<Chipzz> another use case
<Chipzz> (quite marginal, but hey)
<Chipzz> multi-seat
<Chipzz> (2 keyboards/mouse/screens)
<alesan> actually, this resembles our situation, we have 6 seats for every PC using a special PCI card
<alesan> still, a "master" seat could be defined
* Chipzz afk for a couple of minutes
<alesan> afk?
<ScottK> Away From Keyboard.
<hunger> Is there an example of /etc/default/locale available somewhere so I can copy it onto my system?
<Chipzz> back
<alesan> Chipzz, the soultion imho would be that those messages should appera on a configurable display, not on a random one :(
<geser> hunger: my /e/d/l has only a LANG variable set (the same as in /etc/environment)
<soren> Our current udev ruleset doesn't have a rule that automatically mounts a removable device when inserted (given it has a proper UUID=-style entry in fstab and all that), does it?
<Chipzz> alesan: the most sane solution to me sounds like using a keyboard with built-in usb hub, and assign devices according to the hub toi which they're attached to
<alesan> Chipzz, our solution does not allow to use such (uncommon) thing
<alesan> a very good solution for me would be not to start gnome-volume-manager for the remote X sessions
<alesan> but only for the local one
<pygi> hunger, poke?
<alesan> how do I stop gnome-volume-manager to be started?
<pygi> hunger, please poke when you are around, thanks
<siretart> pygi: you're poking quite some ppl today, no? ;)
<pygi> siretart, well, yes, people shouldn't just sit around and drinking *insert some beverage* :)
<pygi> siretart, how are you?
<pygi> I've got a lot of mails from our dear friend today ... and wanted to make sure you know about it. I also wanted to warn people not to respond to his attacks (like hunger did)
<pygi> s/drinking/drink
<hunger> pygi: poke.
<hunger> pygi: That schilli guy?
<pygi> hunger, may I suggest for most part that you ignore the replies from schilli?
<hunger> pygi: OK.
<pygi> hunger, thanks ;)
<hunger> pygi: If that helps you.
<pygi> siretart, you disappeared again :(
<siretart> yes
<pygi> hunger, there's just no point in argument :P
<pygi> siretart, o well, poke if you ever come to life
<siretart> pygi: coworker visted my, I'm in my office
<hunger> pygi: Is that the cdrecord guy?
<pygi> siretart, no worries, we'll talk later
<pygi> hunger, yup
<pygi> siretart, you just enjoy
<siretart> pygi: about what? cdrecord?
<pygi> siretart, yup
<siretart> pygi: sorry, I still didn't have time to analyse the source
<pygi> siretart, don't worry about the source now, it's something else
<siretart> what?
<pygi> siretart, I ain't pushing you, don't worry ... we'll get it sorted =)
<hunger> pygi: Thought so:-( I just found the idea of me upgrading to some code from out of ubuntu so ridiculous that I could not stop myself from replying.
<pygi> siretart, well, the fact that I got cca. 50 mails from schilly on launchpad?
<pygi> siretart, just wanna somehow make sure nobody responds there
<pygi> hunger, don't worry ;)
<siretart> pygi: on launchpad? as in bugmail?
<siretart> pygi: can you give me some bugnumbers?
<pygi> siretart, as in that, yes
<pygi> siretart, sure, gimme a sec (but please dont respond anything)
<doko> pitti: please demote gnat-4.2-doc libgnatprj4.2
<pygi> siretart, 69603, 65700, 66710, 45939, 60710
<pygi> how many more do you want?
<siretart> bug 69603
<ubotu> Launchpad bug 69603 in cdrtools "can't burn cd's at all" [Undecided,New]  https://launchpad.net/bugs/69603
<siretart> pygi: can you try to make sure they all appear here: https://bugs.launchpad.net/~ubuntu-burning?
<pygi> siretart, yup
<pygi> siretart, cdrecord bugs/u-burning can be seen here as well, but I get your point:
<pygi> https://bugs.launchpad.net/~ubuntu-burning/+packagebugs-search?field.distribution=ubuntu&field.sourcepackagename=cdrtools&field.status=New&field.status=Incomplete&field.status=Confirmed&field.status=Triaged&field.status=In+Progress&field.status=Fix+Committed&search=Search
<pygi> siretart, it's basically all of "his" software bugs that have comments on them
<pygi> brb soon
<soren> He's telling people to not use the Ubuntu packages?
<pygi> soren, yes
* persia idly refers to Debian bug 377109 to support silence
<soren> pygi: How rude.
<pygi> soren, haha :)
<pygi> persia, lemme look it up
<pygi> ah, yes
<pygi> persia, sadly that bug (and similar) are not without mistakes and wrong assumptions as well
<persia> pygi: Completely agreed.  Just an example of why argument is not always constructive.
<pygi> persia, I do plan to write a "letter" of some kind or something, just dunno yet where to post it since I've got no blog
<Amaranth> soren: he always does that
<pygi> Amaranth, please, let's not go into discussion
<Amaranth> For him to support your setup you have to be using kernel 2.4.x with ide-scsi emulation
<Amaranth> oops, too late
<pygi> everything is under control, so don't worry
<pygi> Amaranth, oh well
<pygi> Amaranth, people have been using his tools for 20 years, so a little respect
<Amaranth> I didn't know cd burners were even that old
* pygi quotes:
<pygi> In 2006 we were celebrating the 20th anniverary of the scg driver and libscg
<pygi> In the first week of August 1986, I created the world's first SCSI generic pass-through system
<Amaranth> In 1986 I was busy being born. :)
<pygi> I wasn't born back then yet =)
<pygi> Amaranth, you didn't had time for exploring that system then, right? :)
<Tonio_> pitti: I had to rebuild the tarball for knetworkmanager to workarround an upstream problem in the tarball structure. Debian workarrounded adding a builddep to a kde template package, but I can't do that since it is in universe
* pitti looks at thekorn
<pitti> AssertionError: Wrong bugreport Expression (bug #124360)
<ubotu> Bug 124360 on http://launchpad.net/bugs/124360 is private
<Tonio_> pitti: in order not to crap the packaging I decided to rebuild the tarball, but I can't seem to be able to upload now due to different md5sum..... is there a way to workarround this ?
<pitti> oh, that would be it
<pitti> slightly confusing error message, though
<Amaranth> pitti: yeah, that tripped me up about 3 times
<Tonio_> pitti: I don't want to crap the packaging in order to fix a crap tarball in fact ^_^
<tkamppeter> hi pitti
<pitti> Tonio_: you need a new upstream version
<pitti> Tonio_: patching doesn't work?
<pitti> hi tkamppeter
<Tonio_> pitti: damn......
<tkamppeter> pitti, did you succeed to set up and manipulate print queues with the s-c-p now?
<Tonio_> pitti: can be done that way, indeed, but I then have to make files executable in debian/rules, rebuild the makefiles etc.......
<pitti> tkamppeter: no, as I said, it doesn't even connect
<Tonio_> pitti: the all admin/ folder is missing which is very problematic for a kde app
<pitti> tkamppeter: oh, hmm, seems to work today; it didn't yesterday
<tkamppeter> Has your cupsd.conf a line "Listen *:631" or "Port 631"?
<Tonio_> pitti: debian uses a kapptemplate package, which I synced, but the build can't perform since there is a dep in universe...
<tkamppeter> pitti, did you do an auto-update between yesterday and today?
<Tonio_> pitti: I'll try to get a fixed tarball, but as this is an opensuse thing, I don't expect a release just today, just for me....
<pitti> tkamppeter: yes
<tkamppeter> pitti, then there was perhaps some buggy library which someone has fixed (not me).
<mwolson> siretart: around?
<pitti> tkamppeter: yeah, maybe *shrug*
* hunger is tempted to enter into a flame war with schilli, but won't to spare pygi's nerves.
* thekorn wakes up and waves to pitti
<pitti> hi thekorn
<pitti> thekorn: unping then
<tkamppeter> So with queue manipulation working you are now in a good state, once to investigate usability (see especially my bug reports on LP), porting the method for restarting CUPS after a cupsd.conf change from g-c-m, plug'n'print with hal-cups-utils.
<thekorn> pitti, I promise you will never get that bad error messages in the future, but a '403' instead :)
<pitti> thekorn: ah, sweet :) thanks
<pitti> thekorn: I don't care much about the current trunk, if it's all good in your's
<thekorn> pitti: I'm almost done with the chages, but need to add some documentation
<elcuco> hi, who handles this page? https://wiki.ubuntu.com/LoCoTeamList
<Hobbsee> elcuco: elkbuntu does, i suspect
<alesan> I've heard from the gnome developers that gnome-volume-manager has the concept to only start for the local console
<elcuco> the reason i am asking, is that i am part of the loco-team-hebrew, and i was not aware that the ubuntu-il.com site is an official site of my team
<alesan> it seems ubuntu doesnt not honor this or there is a misconfiguration
<alesan> in fact, gnome-volume-manager is started for all displays
<elcuco> it seems that i am missing something
<elcuco> elkbuntu: ping?
<pitti> alesan: right, but it only considers events from the currently active display in Ubuntu
<pitti> alesan: the latest upstream version doesn't do this
<pitti> alesan: it'll happily race with all active g-v-m's
<pitti> alesan: we patched the Ubuntu version to look at the foreground console
<alesan> pitti, let me understand better.
<alesan> I give you an example
<alesan> I have on this machine one standard X display, :0.0, and 6 other display
<alesan> I use a speacial device from www.ncomputing.com
<pygi> hunger, :P
<alesan> whenever I insert a USB key in the host, a *random* terminal takes possession of it
<alesan> the other displays show a error message
<pitti> alesan: ah, right; neither the latest upstream nor Ubuntu version has a particuarly good solution for that ATM
<alesan> pitti, on a gnome channel I've been told gnome-volume-manager has the concept to only run for the local console user
<pitti> alesan: it'll hopefully get better soon when consolekit support gets released in Gnome
<pitti> alesan: maybe in the svn head version, I didn't check it; not in 2.17.0
<pitti> alesan: I don't know the details, but if you have six parallel X servers which are all active and 'foreground', and local, then no automatic mechanism can tell where the usb device should pop up
<pitti> alesan: that's a mapping you can only define yourself
<alesan> pitti, I would like the popup on the local display, :0.0
<alesan> where should I define that mapping in your opinion?
<pitti> alesan: as I said, there's no support for that yet
<elkbuntu> elcuco, pong?
<pitti> alesan: only hackish solution is to stop g-v-m on the other X sessions
<elcuco> elkbuntu: hi, some questions about loco teams, do you have some minutes?
<elkbuntu> elcuco, loco discussion happens in #ubuntu-locoteams
<elcuco> kk, moving
<pitti> mvo: the bug submitter in bug 123062 replied; is that helpful for figuring out why python-apt fails to determine a source package?
<ubotu> Launchpad bug 123062 in apport "apport-gtk crashed with AssertionError in __setitem__()" [Undecided,Incomplete]  https://launchpad.net/bugs/123062
<LaserJock> cjwatson: I've got an app-install-data-edubuntu package uploaded with the data to make that change to the Edubuntu Addon CD
<LaserJock> I just need it in Main *cough* pitti *cough*
<pitti> doesn't sound too scary
<LaserJock> cjwatson: I can send you a patch to debian-cd, does that sound ok?
<cjwatson> LaserJock: yes
<LaserJock> pitti: it's not scary at all
<pitti> doko: is the interface in bug 125551 suitable for you? if so, I'll start hacking on it
<ubotu> Launchpad bug 125551 in gcc-4.2 "Support for gcc ICEs" [Wishlist,Triaged]  https://launchpad.net/bugs/125551
<PHPnerd> hello
<doko> pitti: <executable name> would be cc1/cc1plus?
<doko> I would keep the temporary file (that's the current behaviour)
<pitti> doko: any executable that exists and is shipped in the package which is actually at fault (like gcc-4.1)
<doko> ok
<pitti> doko: cc1 is cpp-4.1, not gcc-4.1, but the source package is the same, so it doesn't matter that much
<pitti> doko: I only need it to determine the package, then its version, and its dependencies, etc.
<pitti> doko: wrt. file vs. pipe, I'll support both; it's trivial to implement
<doko> pitti: I'll keep the file.
<pitti> doko: if you think executable name is not appropriate, and you have something else which identifies the package/version, I'm all ears
<doko> no, that's ok
<pitti> doko: I just thought that argv[0]  would be easy enough for you to get and for me to process
<pitti> great
<doko> pitti: fine, and how to catch reports, when gcc is run in a chroot? ;)
<pitti> doko: that should work if apport is installed in the chroot
<doko> ahh, ok
<pitti> doko: it doesn't do anything with the kernel, it just writes /var/crash/... directly; of course the 'outside' update-notifier won't pick that up
<pitti> doko: you can still submit it manually with apport-gtk -c /path/to/crash/file, of course
<doko> pitti: ok, so we have to find a way for the buildds to report these ...
<pitti> doko: oh, you meant to have that on the buildds? hmm :)
<pitti> doko: I guess that'd require an sbuild hack
<pitti> doko: right now there's no fully noninteractive reporting mode due to the need of LP authentication
<pitti> doko: so either a buildd admin grabs it and submits it manually, or I'll think about building cookie support etc. into the client side
<LaserJock> cjwatson: patch sent
<geser> pitti: bug 123062: I've done a small test and moved my sources.list info sources.list.d/gutsy.list, run apt-get update and tried the test from bug report and it still finds it
<ubotu> Launchpad bug 123062 in apport "apport-gtk crashed with AssertionError in __setitem__()" [Undecided,Incomplete]  https://launchpad.net/bugs/123062
<pitti> geser: oh, thanks
<pitti> geser: still curious, you do not need apt or even apt sources at all to determine the source package of an installed binary package, that's why I wonder
<mvo> the source-package name should be in the dpkg status pkg record
<pitti> $ dpkg-query -W -f '${Source}\n' apport-retrace
<pitti> apport
<pitti> mvo: right
<pitti> mvo: so doesn't python-apt use that for the .sourcepackage attribute?
<mvo> it should
<mvo> pitti: just to be clear: packaging.get_source(package) returns None, right?
<pitti> mvo: python -c "import apt; print apt.Cache()['seahorse'] .sourcePackageName" prints nothing
<pitti> mvo: it should print 'seahorse'
<pitti> mvo: (nothing except the apt API warning, of course, see bug trail)
<keescook> kylem: ping
<pitti> mvo: I would have thought that print would output 'None', instead of nothing, hmm
<mvo> geser: can you reproduce that bug?
<mvo> pitti: yeah, that puzzles me
<geser> mvo: not yet
<pitti> mvo: well, packaging.get_source() just wraps that apt.Cache()['seahorse'] .sourcePackageName call and returns the result
<mvo> pitti: yeah, I'm currently looking at the python-apt source and wonder where a "" return could come from
<geser> pitti: what about that the reporter used an older version of apport?
<geser> apport-gtk 0.86 and gutsy has now 0.93
<pitti> geser: hm, let me check out 0.86 and see
<pitti> geser: hm, last change to get_source was in 0.78, so that's not it
<pitti> bzr blame FTW :)
<geser> might a change in apt fixed it? the gutsy system from the reporter doesn't seem to be uptodate
* jdong smiles
<jdong> bug 128721
<ubotu> Launchpad bug 128721 in feisty-backports "Please backport 2.6.22 kernel from Gutsy to Feisty" [Undecided,Invalid]  https://launchpad.net/bugs/128721
<pitti> whoa
<ion_> Hehe
<geser> pitti, mvo: I can reproduce it
<pitti> "Please backport gutsy to feisty"
<mvo> geser: how?
<pitti> geser: oooh?
* pitti hugs geser
<jdong> pitti: lol :)
<mvo> geser: can you please run http://paste.ubuntu-nl.org/31559/ and paste the result somewhere? I'm curious about it
<geser> it's the something to do with the line break in the command the bug reporter used
<pitti> jdong: well, I actually do not know whether gutsy's kernel would work with feisty's udev/hal/etc.; it's not totally impossible
<jdong> pitti: in the past it's not worked too great, so I'm not all that optimistic
<jdong> and for sure it replaces linux-libc-dev and friends
<pitti> yep
<jdong> and you're kinda stuck without linux-meta magic too :)
<jdong> all in all IMO a bad idea (tm)
<pitti> jdong: right; I meant, if someone actually wants, he can just grab the gutsy packages and install them
<jdong> right
<geser> mvo: http://paste.ubuntu-nl.org/31560/
<mvo> geser:  and python -c "import apt; print apt.Cache()['seahorse'] .sourcePackageName"
<geser> pitti: python -c "import apt; print apt.Cache()['seahorse'] .sourcePackageName" works but when you introduce a  line break between the print and apt.Cache it doesn't print anything
<geser> mvo: the usual warning and "seahorse"
<pitti> geser: ah, naturally
<mvo> ok, so it maybe that the reported used the command wrongly?
<pitti> geser: I had assumed that was just a line break in LP
<mvo> I attached some testcode that should (hopefully) cleanup the confusion
* pitti asks in the bug
* mvo goes out for ~30min
<pitti> mvo, geser: thanks
<ion_> bryce, seb128: xserver-xorg-core 2:1.3.0.0.dfsg-6ubuntu3 makes X segfault when starting an OpenGL program. Im running the proprietary nvidia driver and compiz. Downgrading to -ubuntu2 fixes the problem.
<seb128> bryce: ^
<seb128> ion_: can you send a crash bug with apport if there is not already one?
<siretart> mwolson: yes, I finished my phone call
<ion_> seb128: apport didnt seem to notice the crash. The only thing that indicated a segfault was a mention of signal 11 in Xorg.0.log.
<seb128> weird
<seb128> ion_: no crash file in /var/crash?
<pitti> hm, maybe X.org has its own crash handler then?
<mwolson> siretart: OK, shall we begin the emacs22 discussion with pitti and seb128 then?
<ion_> seb128: Nope.
<ion_> Ill install 2:1.3.0.0.dfsg-6ubuntu3 and post the Xorg log after it crashes.
<siretart> if pitti and seb128 agree :)
<pitti> siretart: your mail was pretty good
<siretart> pitti: thanks :)
<seb128> hum
<seb128> we are supposed to speak about emacs22?
<siretart> pitti: I checked the 25MB diff to the debian package. I'm quite confused about this, since debian ships a totally different upstream tarball
<pitti> mwolson: so you actually want to maintain emacs22 on your own for a while? TBH this looks like more effort than necessary to me (joining the Debian and Ubuntu team together to maintain a synced emacs22 seems much more valuable to me?)
<siretart> pitti: I have no idea what they have done. I know that our emacs22 package uses the pristine source tarball
<siretart> well, not totally different, but it looks nearly like another upstream version to me
<mwolson> pitti: yes.  it is an absolutely necessary effort because Debian has maimed the package by stripping out its manuals and the GNU Manifesto
<pitti> siretart: note that I'm not saying that the Debian version is better in any way
<mwolson> due to their GFDL policy
<pitti> mwolson: as long as they package it separately, that's not a big problem; we can just add a dependency to the -doc package
<mwolson> i am willing to invest the effort to maintain this package indefinitely, because I care about the manuals
<mwolson> pitti: they don't package it separately.  they completely strip the manuals out
<pitti> so a good compromise would be to leave the package split for Debian's sake and just sync it into Ubuntu's main
<pitti> mwolson: hm, that's evil
<mwolson> yes, it is
<pitti> mwolson: are there key differences in the non-doc bits?
<pitti> mwolson: maintaining the -doc package on our own is still much less effort
<siretart> mwolson: don't the debian packages ship the gnu manifesto and gnu manuals in emacs22-common-non-dfsg? what's in there?
<mwolson> siretart: oh, forgot about that
<mwolson> so retract what i said about them stripping the manuals out completely
<Nafallo> we should throw out emacs and all those things that use it from the archive
* Nafallo hides
<Nafallo> ;-)
<siretart> /ignore Nafallo ;)
<Nafallo> hehe
<mwolson> pitti: i based my emacs22 package on the emacs-snapshot package, which has had a considerably more active maintainer
<mwolson> so that's one reason to keep my changes
<siretart> and emacs-snapshot keeps being actively maintained, it's just not happening in debian, but on Romains private archive
<pitti> mwolson: did you contact the Debian maintainer of emacs22? if he doesn't want to cooperate, we have to bite the bullet, but maybe he would actually appreciate it
<mwolson> pitti: i haven't contacted him.  but it would be a massive effort to enumerate the improvements that the emacs-snapshot guy made, and i feel that it might trod on the style of the Debian maintainer.  but i could be wrong.
<siretart> I agree that we should indeed work together with debian to minimize the 25MB debdiff to something more reviewable
<ion_> bryce, seb128: http://heh.fi/tmp/Xorg.0.log (nothing else seems to differ from a normal log than the very last lines)
<mwolson> also, just Recommending Debian's nondsfg documentation sends a bad message to newbie users -- they will think that the manuals are tainted in some way, which is completely not the case
<seb128> ion_: do you have the dbgsym installed?
<mwolson> s/documentation/documentation package/
<siretart> mwolson: we can easily change that to a hard depends in ubuntu
<pitti> mwolson: well, newbies won't care, I think
<siretart> pitti: newbies are totally lost without the manual. even advanced users need the manual quite often
<ion_> seb128: Ill install it now. Should i install other -dbgsym packages in addition to xserver-xorg-core-dbgsym?
<pitti> mwolson: I still think that it's a very low effort to contact the Debian maintainers of emacs22 and emacs-snapshot and try to form a team to create One True emacs22 instead of the current mess
<mwolson> pitti: by "newbies", i meant "somewhat experienced GNU/Linux users who are trying out Ubuntu for the first time"
<pitti> siretart: I meant, newbies won't care if the version has some 'dfsg' in it; of course they care about the doc
<siretart> indeed
<mwolson> (not a general definition of "newbie" by any standards, but meh)
<seb128> ion_: not sure, I'll tell you when you get a new backtrace ;)
<mwolson> pitti: in what particular way is this a "mess"?
<seb128> I agree with pitti, what users will care about is to have the documentation
<seb128> not how to package is named
<pitti> mwolson: having -snapshot and -22 which are both 22, actually maintaining the package outside of Debian in addition, and forking it in Ubuntu
<pitti> mwolson: that makes four different sources which should actually just be one
<pitti> and if Debian names the -doc package 'blabla-gfdl' and put it into non-free, and we just sync it to main, both Debian and we will be happy
<mwolson> pitti: the primary reason that I doubt we could form a "one true Emacs22" team is that of ideological differences w.r.t. the GFDL.  there were some very strong opinions voiced on the debian-emacsen list on this issue
<pitti> ('gfdl' isntead of something scary like 'non-free' or 'evil' :) )
<seb128> mwolson: right, and I think that's why the emacs-snapshot maintainer stopped working on the Debian package
<pitti> mwolson: I wasn't suggesting to try coercing the Debian guys to change it
<mwolson> pitti: no, -snapshot is not Emacs22.  it is a snapshot of current CVS, updated every two weeks, and needs to stay distinct from the emacs22 package
<pitti> mwolson: I see no problem at all to split the package
<seb128> mwolson: Debian will not stop splitting the dfsg documentation, but as pitti says having the 2 packages in Ubuntu main is not a problem
<pitti> mwolson: right, but (1) the packaging shuold be more or less identical, and (2) it shuold be maintained by the same team
* mwolson tries to address all of these points chronologically, and is a bit overwhelmed
<pitti> mwolson: heh :) sorry, I didn't mean to confuse you, I just braindumped my thoughts about it
* pitti hugs mwolson 
<mwolson> pitti: also, debian will be the one splitting the emacs-snapshot if they opt to do so; we will get it from the real maintainer; but more likely is that Debian will simply drop emacs-snapshot.  or so i have read on the bug report that orphaned emacs-snapshot
<mwolson> so there will be only two different sources: our emacs22 and theirs
<pitti> mwolson: right; but what's the reason why our diff needs to be 25 MB instead of just the dependency to -doc?
<siretart> debian has already dropped emacs-snapshot
<pitti> indeed
<mwolson> pitti: clarify "diff".  against Debian or upstream?
<pitti> siretart, mwolson: want me to remove it from gutsy as well? or do you care aobut it?
<siretart> pitti: NO!
<seb128> pitti: well, looks like the mess is on the Debian side there
<pitti> mvo: against Debian's emacs22
<mwolson> pitti: i care about it.
<siretart> pitti: I'm regularily request syncs from Romains private archive to ubuntu!
<pitti> seb128: right, I never questioned that
<pitti> mwolson: ok
<seb128> pitti: emacs-snapshot doesn't come from Debian
<pitti> siretart: ah, that one; I see
* pitti saw siretart's heart jump a step to the left
<siretart> mwolson: http://patches.ubuntu.com/e/emacs22/ has the the uptodate diff  between the ubuntu and debian emacs22 package
<mwolson> haha
<siretart> pitti: :)
<siretart> as said, I think we should work on minimizing that 25MB diff. However, from what I've seen is that most of the diff comes from debian using a different orig.tar.gz
<mwolson> siretart: i haven't seen that diff yet.  i will take a look at it this weekend and see if there are things that can be brought closer together
<pitti> siretart: ok, that's not unreasonable; what's the filterdiff -i */debian/*'?
<siretart> that's why I don't think that we can minimize it for gutsy, but if we work with debian together, we can do it for gutsy+1
<siretart> thats managable
<pitti> siretart: if the 25 MB is by and large removed documentation, then merging the packages continuously is not a problem
<mwolson> however, i honestly don't think we need to worry about minimizing diffs against Debian's package.  i am maintaining it separately, and will track Debian's changes.  i think this is a specials case where diff minimalization ought not to be a primary goal.
<siretart> we are using quilt, debian is using the cdbs patch system
<mwolson> s/specials case/special case/
<siretart> the patches are called differently
<seb128> (hate quilt)
<mwolson> siretart: actually, Debian is also using quilt.
<siretart> oh?
<mwolson> but they format the headers differently
<seb128> it's too complicated to use and breaks all the time
<siretart> seb128: we don't force you to work on emacs22 ;)
<mwolson> which might account for a lot of the changes
<mwolson> seb128: it still beats the hell out of dpatch
<seb128> siretart: good ;)
<seb128> mwolson: well, I like easy things but I'll not argue
<mwolson> seb128: i hate having to edit files in /tmp in order to commit changes
<seb128> I use simple-patchsys and cdbs :p
<seb128> understandable on a big package
<bryce> ion_: thanks for reporting the regression.  The only change between *ubuntu2 and *ubuntu3 was that a patch to turn off clipping in composite was added
<seb128> I hate having to push, add, edit, pop, etc to edit a patch
<mwolson> *scrolls back a few screens to see if he missed anything*
<seb128> anyway that's not the topic ;)
<siretart> pitti: mwolson: http://paste.debian.net/33534 has the effective diffstat of the packaging difference
<bryce> ion_: are you experiencing the crash when compiz is on or off?
<mwolson> OK, i think i'm caught up now :^)
<pitti> siretart: quite a lot in rules, and quite a lot of noise in many other files, hmm
<siretart> pitti: indeed. I agree that we should work to minimize that
<mwolson> pitti: some of the changes to debian/control will likely get picked up by Debian soon, since we (preemptively) fixed a bug in their BTS about binNMU builds
<pitti> mwolson: just a side note, we do not need to care about binNMU; we don't do them
<ion_> bryce: Only when compiz is running, and i start any OpenGL application.
<mwolson> ok
<siretart> mwolson: that 'tuned' diff ist still 223K big
<ion_> seb128: Installing xserver-xorg-code-dbgsym made no difference: http://heh.fi/tmp/Xorg.0.log
<siretart> large parts (about 30%) is because of debian/changelog and debian/copyright*
<siretart> another large part is of course because we use another 'patch format'
<mwolson> i think our debian/rules is cleaner in many places and easier to understand
<siretart> (headers of debian/patches/*) and such
<mwolson> as an example, Debian uses two or three temp files to generate some contents in README.Debian.  we use none.
<avoine> the package base-files depend on awk but awk is a meta-package that you have to choose between gawk,mawk,etc which awk it's take?
<siretart> which also blows up the diff
<siretart> How do we want to proceed from here? pitti, do you think that coordination with debian is a prequisite for having emacs22 in main?
<siretart> I'd expect that would mean that we won't have it for gutsy, but for gutsy+1.
<pitti> siretart: I don't consider it a prerequisite, but it should happen nonetheless; if we ask and they refuse and don't respond, that's ok; but if they appreciate building a team, we should do it, also for Debian's sake and avoiding redundant work
<pitti> mwolson, siretart: in any case, thanks for the heads-up
<ion_> Would it make sense to disable the X crash handler so that apport would catch the crashes?
<siretart> pitti: does this mean you'd prefer to have emacs21 in gutsy/main for now?
<pitti> ion_: disabling it is not really necessary, it's enough if it would just re-raise the signal after doing what it wants to
<pitti> siretart: no, I don't have any strong opinion about it
<pitti> siretart: I don't use emacs myself, so I can only rely on testers
<mwolson> i think people will be very disappointed not to have a GTK+ 2 capable Emacs in main  (which would be the case if emacs21 is in main, but emacs22 isn't)
<siretart> pitti: it would perhaps help to get rid of gtk1 ;)
<pitti> so, if emacs22 works well, and is supported upstream, and mwolson and maybe others will maintain it, let's update
<mwolson> \o/
<pitti> siretart: that went to universe some time ago and will never come back :)
<siretart> oh wait, does emacs21 use gtk at all?
<pitti> siretart: we might have patched it, not sure
* mwolson checks
<siretart> aah, I confuse that with xemacs
<siretart> that one used gtk1, I'm sorry
<mwolson> yeah
<siretart> mwolson: I'd say we'll prepare an email with 'our' differences to the debian maintainers and see if they are interested in minimizing the diff
<mwolson> siretart: sounds good
<mwolson> siretart: i'll begin working on that tomorrow night (now+1 day+7 hours)
<pitti> mwolson: you should also ask if they are interested in team maintenance in a shared VCS repo or so
<pitti> mwolson: alright, thanks a lot!
<siretart> mwolson: thanks a lot!
<siretart> :)
<pitti> siretart: seems you just voluntold to sponsor mwolson's uploads once it's in main? :-)
<siretart> pitti: I already do. I've done it for the previous uploads
<pitti> siretart, mwolson: oh, does that also update the 'emacs' metapackage, for an automatic update?
<pitti> seems not
<pitti> mwolson: it would be good if emacs22 would build 'emacs' as well
<siretart> hmmm
<siretart> the debian emacs22 package already builds 'emacs' as well as the emacs21 package..
<cjwatson> avoine: mawk is Priority: required and is thus installed by debootstrap and used by default
<pitti> if emacs21 goes to universe and emacs22 to main, we shuoldn't leave upgraders with an unmaintained one
<mwolson> pitti: i'm still very hesitant to ask.  i might sound them out on some proposed changes first, and see how willing they are to implement them
<mwolson> pitti: hmm, it would be nice if emacs22 could Provide emacs or somesuch
<pitti> mwolson: right; no need to throw two tons of patches at them immediately; just explain the situation and offer some comaintaining, or mutual merging, or somethign (depending on how close they want to work with you)
<mwolson> ok
<pitti> mwolson: Provide: is not enough, we should merge the Debian change which builds the emacs metapackage and Depends: emacs22
<siretart> I volunteer fix the breakage caused by swapping emacs21/emacs22 wrt. the 'emacs' metapackage
<mwolson> pitti: ah, i think i see what you mean now
<pitti> siretart: NB that it's not a problem to have two emacs packages in the archive, at least for a while
<cjwatson> pitti: don't we have an emacs-meta?
<cjwatson> oh, we used to, it vanished, ok
<pitti> cjwatson: not any more (dropped in feisty)
<siretart> pitti: ok
<pitti> well, as long as you guys don't break my vim.... /me ducks
<siretart> I expect we need to update some build-dependencies as well, like auctex
* pitti checkrdepends
<pitti> auctex
<pitti> bbdb
<pitti> calc
<pitti> emacs
<pitti> emacs-goodies-el
<pitti> gnus
* mwolson makes an emacs-vim package that calls viper-mode :^D  (kidding)
<pitti> malaga-mode
<pitti> python-mode
<pitti> not too bad
<siretart> oh, that reminds me, I wanted to teach emacs-goodies-el about gutsy...
<pitti> most of them can probably be changed to "Depend: emacs | emacsen"
<pitti> which would make it more future-proof, too
<siretart> pitti: is that reliable even for build-dependencies?
<siretart> I remember something on the mailing list by Ian lately..
<pitti> siretart: right, but emacs is a real package, so as long as it doesn't actually depend on a particular emacs version, that's ok
<mwolson> siretart: was the emacs-goodies-el stuff taken care of by Bug #123902?
<ubotu> Launchpad bug 123902 in emacs-goodies-el "Candidate revision emacs-goodies-el_26.11-1ubuntu1" [Wishlist,Confirmed]  https://launchpad.net/bugs/123902
<pitti> siretart: "Build-Depends: emacsen" would be wrong (virtual package only)
<pitti> siretart: prefered (first) alternative must not be virtual
<siretart> pitti: ok
<pitti> siretart: we compromise on that in Ubuntu for the sake of avoiding deltas just for that
<siretart> mwolson: partly. I wanted to do an ubuntu2 upload which knows about the ubuntu releases as well
<siretart> but I got lost in the 'next-upstream-version' function
<desrt> seb128; did you write keith about my thoughts on the compiz bug?
<mwolson> siretart: ah
<seb128> desrt: no, didn't have too, he fixed the patch upstream
<desrt> nice
<mwolson> siretart: need any help with the elisp part of that?
<seb128> desrt: and I've confirmed that the new version works fine ;)
<desrt> what ws wrong?
<siretart> mwolson: well, I might indeed need some help here.
<pitti> siretart: promoted to main now
<seb128> desrt:
<seb128> -+    if (pWin->parent && pWin->redirectDraw != RedirectDrawNone)
<seb128> ++    if (pWin->parent && pWin->redirectDraw == RedirectDrawNone)
<siretart> mwolson: the package contains it own algorithm for calculating the next upstream version when doing a C-c C-v
<pitti> siretart: we need both in main for the time of the depends: transitions, then I'd like to drop emacs21 and get the emacs package point to emacs22
<desrt> seb128; hm.  ok :)
<siretart> mwolson: I tried to change that it doesn't just increments the revision, but introduces -Nubuntu1 and so on. and set gutsy instead of unstable
<siretart> like recent dch does
<siretart> pitti: you rock! :)
<pitti> siretart: I didn't do anything but whine, nevermind :)
<siretart> mwolson: I tried, and defered the idea for ubuntu3 (but forgot to finish and upload ubuntu2) :/
<mwolson> siretart: do you want me to start work against my ubuntu1 or your ubuntu2 (would need to know where to get it), or some working directory?
<siretart> mwolson: I work in a bzr branch, but haven't publised it yet. I need to go home now, and will publish it then, okay?
<siretart> mwolson: I think I can easily merge anything based on ubuntu1 to my branch
<siretart> need to leave now, cu later!
<mwolson> siretart: OK
<mwolson> later
<tkamppeter> pitti, any progress on s-c-p?
<pitti> tkamppeter: I didn't do anything with it today
<tkamppeter> pitti, then we should perhaps better continue with this in the beginning of next week.
<pitti> tkamppeter: right, I still need some time to file some bugs, as per yesterday's distro meeting, but today's archive day of mine took a lot of time, sorry
<avoine> thanks cjwatson for the reply about awk and sorry for the delay :/
<bryce> ion_: it probably would be a good idea to try that
<bryce> ion_: I checked to see if debian has any relevant fixes for this issue, but didn't spot anything close.  I'm going to check xorg's bug tracker to see if it's been reported there
<Ng> should I be using -i810 or -intel for a 852GM/855GM (I think it's the 855)?
<bryce> ion_: would you also mind testing to see if it occurs with the -nv driver?  If it does, it might be easier to troubleshoot than the binary driver
<bryce> Ng, I believe there are still some outstanding issues for 855 with -intel, however if you can get -intel to work okay, that's the better choice
<bryce> -810 is legacy so we're encouraging people to move to -intel where possible
<Ng> bryce: ok. I was using -intel on feisty for better resuming and it's stuck with that on gutsy, but I get some weird renderng with compiz
<Ng> (no drop shadows and earlier when i switched it replaced each window with a box of noise ;)
<bryce> Ng, hmm, that sounds suspiciously like an issue seb128 and I were looking at
<bryce> what version of xorg-server do you have installed?
<Ng> 7.2-3ubuntu4
<bryce> xorg-server should be 1.3.0something
<bryce> xorg-server 2:1.3.0.0.dfsg-6ubuntu3 is the latest available
<Ng> sorry, I typed xserver-xorg. xorg-server isn't installed or available (this is gutsy)
<seb128> xserver-xorg-core
<Ng> 2:1.3.0.0.dfsg-6ubuntu3
<bryce> hmm, actually I think the issue we were looking at was noise in icons, not in windows in general.  could be something different
<seb128> diner time, bbl
<Ng> this was literally everything. I flipped on desktop effects and it all went crazy. it all still worked and I could figure out which button turned it back into metacity ;)
<bryce> hmm, well debian has a dfsg-11 available, but I've reviewed the changelog and didn't see anything that looked like it fix your issue or ion_'s
<bryce> Ng, had you been able to run compiz successfully previously?
<Ng> bryce: yeah. when I'm at home I'll reboot and get everything into a clean state and compare -i810 and -intel
<Ng> (successfully modulo getting white boxes instead of drop shadows)
<bryce> ok cool
<bryce> in general -intel seems to work quite well with compiz from what I've seen
<bryce> so this bug sounds pretty unusual and interesting
<jwendell> Hi, i'd like to call 'autoconf' after the patch be applied (and before it calls configure). What rule in debian/rules should i use (CDBS) ?
<jwendell> configure/xxx:: is called after it runs configure...
<jwendell> makebuilddir/xxx:: is called before it apply the patches...
<jwendell> seb128, can you help me?
<Seveas> jwendell, post-patches:: looks like a candidate :)
<jwendell> Seveas, thanks.
<jwendell> i didn't found this on its docs ;)
<Seveas> I read the source :)
<Seveas> /usr/share/cdbs/1/rules/simple-patchsys.mk
<jwendell> Seveas, it didn't work...
<Seveas> darn
<Seveas> do you use simple-patchsys?
<jwendell> Seveas, yep
<jwendell> Seveas, the patch is being applied
<jwendell> but i want to run 'autoconf' because the patch changes configure.ac
<Seveas> jwendell, common-configure-{arch,indep}:: from /usr/share/cdbs/1/rules/buildcore.mk line 151 (gutsy) could be suitable candidates
<jwendell> nope
<Seveas> then I give up :)
<Seveas> cdbs is still black magic
<jwendell> Seveas, a possible solution is add it on post-configure and the call configure again
<jwendell> hehe
<asisak> Any REVU admins here, please?
<somerville32> Try #ubuntu-motu
<asisak> Sorry, I've already tried #ubuntu-motu.
<mr_pouit> could someone push xfce4-places-plugin to main? mir has been approved (https://wiki.ubuntu.com/MainInclusionReportXfce4PlacesPlugin), but it is still in universe
<seb128> mr_pouit: it'll be promoted when something in main depends on it
<seb128> mr_pouit: or if it's seeded
<mr_pouit> it is already seeded
<mr_pouit> seb128: in xubuntu.gutsy
<_StefanS_> hi there..
<_StefanS_> is it on purpose that subpixel hinting is disabled in the freetype for gutsy?
<seb128> mr_pouit: promoted
<seb128> will be available on next publisher run
<mr_pouit> seb128: thanks :)
<seb128> you're welcome
<seb128> mr_pouit: you work on xubuntu? Maybe you want to merge gnumeric with the new version available in debian experimental? ;)
<mr_pouit> seb128: ok, I'll give a look (I think gpocentek usually take care of it, I'll see with him)
<seb128> ok, thanks
<seb128> asisak: ^
<asisak> thanks seb128 for arraging this
<seb128> you're welcome ;)
<iwj> seb128: consolekit+gdm+gnome-screensaver are looking OK to me but there's still one annoying bug for which the fix involves inventing a new dbus message which is soooo teeeediiiouuus.
<iwj> So I'm going to finish that up on Monday.
<seb128> iwj: ok, good
<iwj> How do people cope with dbus ?  Don't their fingers wear out ?
<iwj> dbus_set_bit_number_176_of_some_message_with_extended_connection_state_to_1()
<seb128> iwj: should I send your gnome-screensaver patches upstream or are you going to do it?
<iwj> I'm doing it.
<seb128> yeah for verbose descriptions ;)
<seb128> ok
<iwj> I'm sending to gnome bugzilla and uploading, although not all of the patches are in both places yet.
<iwj> Anyway, it's too late still to be working and my dinner will be along any moment.
<seb128> there is no hurry for it, the next tribe is in 10 days so there is time to upload and give it some testing
<iwj> Have a nice weekend :-).
<iwj> Right.
<seb128> thanks, you too
<capiira> hmmm hi i already asked in #ubuntu but nobody answered my question! Does ubuntu use dash or bash, anyone know ?
<pygi> bash
<capiira> ahh ok thx and dash is not used at all ?
<xxxxx1> capiira, by default /bin/sh is a symlink to /bin/dash
<thom>  /bin/sh is dash by default
* pygi looks
<stgraber> capiira: ls -l /bin/sh would have answered your question
<xxxxx1> capiira, btw, the default user shell is bash.
<capiira> ahh ok thats all for what dash is used ?
<ScottK> Dapper/Edgy are Bash.  Feisty and follow are Dash.
<capiira> ahh ok
<capiira> thank you
<capiira> now i can search for proper books :)
<thom> ScottK: uh, wrong. Edgy is dash
<capiira> heh
<ScottK> Ah.  Sorry.  Misremembered the transition point.
<thom> capiira: for dash, you just need to follow posix sh standards
<capiira> then it will work in dash and bash shells ?
<thom> posix sh is the standard, yes
<capiira> ahh nice that's exactly what i'm looking for
<capiira> something that works everywhere
<capiira> thank you
#ubuntu-devel 2007-07-28
<geser> bryce: I added a patch to bug #128791. Can you test it out if it helps you further?
<ubotu> Launchpad bug 128791 in displayconfig-gtk "FTBFS ImportError: No module named distutils_extra" [Undecided,New]  https://launchpad.net/bugs/128791
<bryce> geser: cool will do
<bryce> patch applied ok; building now
<bryce> cool
<bryce> I had to `touch Changelog`, but then it built
<bryce> ion_: I wonder if this is similar to your issue:  https://bugs.launchpad.net/ubuntu/+bug/126425
<ubotu> Launchpad bug 126425 in xorg-server "[Fixed]  Intel driver (using EXA) crashes system when starting compiz" [Undecided,New] 
<Amaranth> iwj: I've been informed that xephyr cannot do accelerated glx but was told to check out glxproxy instead http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=tree;f=hw/dmx/glxProxy
<Chipzz> capiira: dash is the default shell used for scripts (which use #!/bin/sh or #!/bin/dash), bash is the default shell for users
<capiira> thank you :)
<Roundy> this might be the wrong place to ask
<archaios7> Evening everyone; if I wanted to help out on some developing for Kubuntu/KDE would I be better served by learning Ruby instead of Python?  I've already started Python because it's recommended for Ubuntu, but I hear Ruby is better supported for QT4?
<TheMuso> archaios7: Python is very much preferred round here.
<TheMuso> Just abot all tools/utils written for Ubuntu have been written in Python.
<archaios7> Even Kubuntu?
<TheMuso> Yes.
<archaios7> Swell.
<archaios7> Good to hear then; cause I'd rather not start over with another language at this point.
<archaios7> Yet, that is.
<alesan> do you have any idea how to resolve the urgent bug that when inserting a USB key it gets assigned to a random user instead of all users in the plugdev group?
<alesan> is there any way to configure this behaviour?
<Treenaks> alesan: it gets assigned to the user currently logged in locally
<alesan> Treenaks, unfortunately not, it's random
<alesan> and the other users on the other displays get an error message not being able to access the device
<alesan> I have a multiuser system with 7 separate displays
<alesan> one of those displays (:0.0) is the local video/key/mouse
<alesan> the others are added using a particular PCI device that adds other 6 vga/key/mouse
<alesan> I would really like to change the default mount options but I have no idea where to look for
<alesan> I grepped everything but I do not happen to find anything useful :(
<IntuitiveNipple> alesan: Check out /etc/hal/fdi/policy/preferences.fdi
<alesan> thanks
<alesan> well
<alesan> :( this does not seem what I need
<pitti> hey seb128
<seb128> hello pitti
<seb128> pitti: what do you there on a saturday? ;)
<pitti> seb128: poor wheather :)
<pitti> seb128: same question for you
<seb128> it's raining here as well :/
<pitti> seb128: I just reviewed Neil Horman's kernel patches for core_pattern improvements (IOW: getting apport to work on upstream kernel)
<seb128> and I had some rarian questions for upstream so I've decided to start IRC ;)
<seb128> does it look good?
<pitti> seb128: they aren't too far from our's, but he uses core_pattern macros instead of environment variables
<pitti> that's harder to implement, but a bit nicer to use
<pitti> and I don't care much either way
<seb128> so you are going to switch to the upstream way?
<alesan> seb128, I hope I'm not mixing up nicknames, but yesterday I've been told that you could possibly help me on this gnome-volume-manager thing...
<pitti> seb128: yes, as soon as it's committed upstream, I'll ask BenC to pull those patches and change apport
<alesan> I basically have many displays other than the "console" and, if I insert a USB stick, its contents will appear on a random display and the device will be mounted with random uid
<alesan> the other display will show an error message
<seb128> alesan: you probably want to speak to pitti about g-v-m
<pitti> alesan: didn't we discuss this yesterday already?
<alesan> pitti, seb128 ok thank you :) to begin with
<alesan> pitti, yes we did but, while I manages to "get around" the problem, I only made a ugly script that is not going to really solve the problem
<alesan> right now I stop g-v-m to start in the session by commenting in out from /usr/share/gnome/default.session
<alesan> and, in /etc/xdg/autostart/gnome-volume-manager.desktop I changed the "Exec" to a script that checks the $DISPLAY variable and only starts g-v-m --sm-disable if it is :0.0
<alesan> I see no other way to fix the "random display" thing.
<Amaranth> err, won't that make gnome-volume-manager only work for the first user?
<alesan> moreover, I'd really like to be able to configure the uid or gui mount options. any idea where to look?
<seb128> Amaranth: why? it should work for the user having the foreground
<seb128> no?
<Amaranth> seb128: checking for :0.0 means it'll only work for the first X server
<alesan> seb128, "having the foreground" means "random" on a multi user system with many displays
<seb128> alesan: right, but there is no easy way to solve this problem
<alesan> Amaranth, yes that's the best option I've encountered so far
<Amaranth> yeah, if you run multiseat i'm not really sure how that could work
<alesan> seb128, it seems on fedora they check soem /var/xxx/console file to start g-v-m only for that session on the console (first X server)
<Amaranth> ConsoleKit
<alesan> what is that?
<alesan> there is no such package with similar name as I can see...
<alesan> do you have at least idea how to let g-v-m mount with gid=plugdev instead of uid=USER ?
<pitti> alesan: it entered gutsy a few days ago
<Amaranth> alesan: "ConsoleKit is a framework for keeping track of the various users, sessions, and seats present on a system."
<pitti> alesan: you can change the group in the 'drive' or 'volume' properties tab
<alesan> pitti, after the device is mounted?
<pitti> alesan: no, before
<alesan> mh
<pitti> alesan: well, mount the device, change options, mount it again
<alesan> mh
<pitti> 'k, gotta go, cu later
<alesan> there are schools in Macedonia that are going to install this system for thousands of users :( this solution is not really simple
<alesan> what I do not understand, are the generic mount option of g-v-m hardcoded? isn't there a place to configure?
<seb128> alesan: for what sort of device do you want to change the settings?
<alesan> a normal USB stick
<seb128> alesan: what filesystem?
<alesan> I suppose the most common are vfat or so
<seb128> alesan: try gconf-editor, /system/storage/defaults_options
<alesan> I am preparing a system to be deployed in schools
<seb128> you can change the gnome-mount options
<alesan> so I should be as generic as possible
<seb128> alesan: saturday is not the best day to get replies though, a good part of the distribution team doesn't IRC during the WE
<alesan> yes :( I know
<seb128> maybe you should mail ubuntu-devel-discuss
<alesan> unfortunately it seems I have to find a solution before monday otherwise the deploy could be delayed
<alesan> ok
<seb128> try changing the gconf keys where I indicated
<alesan> ok
<alesan> thank you it seems that's what I need
<seb128> you're welcome
<alesan> umask on mount has a "complementary" meaning right? umask=000 should give full access to everybody
<_wattazoum_> hello
<_wattazoum_> newbie needs help : I am finalising an application that can be runnable by root and by simple user. I want to add a menu entry for user at "Applications->system tools"(for non root users) and "system->Administration " (for root ) . how can I ?
<Kmos> seb128: can you look at ubuntu-archive ? =) I don't like to bother you.. :)
* Hobbsee waves
<seb128> Kmos: what is the hurry?
<seb128> _wattazoum_: have a different .desktop for each entry
<_wattazoum_> seb128:  thank you, so I 'll have 2 desktop entry ,  but how to specify the location in the menu ?
<seb128> _wattazoum_: Categories=
<_wattazoum_> seb128:  Great , you're a great help , thank you very much
<seb128> you're welcome
<_wattazoum_> :)
<geser> Hi Hobbsee
<mr_pouit> could someone make a give-back for thunar-thumbnailers (https://launchpad.net/ubuntu/+source/thunar-thumbnailers/0.2.2-0ubuntu1)? it seems it ftbfs some time ago on some arches because of hal failing to install.
<seb128> mr_pouit: I doubt it's fixed, nautilus-cd-burner uploaded this morning fails due to hal also
<Hobbsee> hiya seb128
* Hobbsee wonders why seb128 is working
<mr_pouit> seb128: damn, ok :] 
<seb128> hello Hobbsee
<seb128> Hobbsee: I try not, I was just cleaning some things because I want to get them landing before next tribe
<Hobbsee> seb128: ahhh.  of which the work starts...on friday, or something
* Hobbsee wonders who the release manager is for said tribe.
<seb128> maybe none? ;)
<Hobbsee> heh.  bet you'd like that
<StevenK> Oh, that'll go well. :-P
<seb128> well, I think we could manage to fix issues and do testing, etc in a team organised way if required
<seb128> we still need somebody to kick CD builds, etc though
<Hobbsee> seb128: and does require someone to organise the team, and make sure it's working, and doesnt fall over
<elkbuntu> Hobbsee, volunteers!
<Hobbsee> elkbuntu: i suspect you may not find any
<elkbuntu> no, im volunteering you
<Hobbsee> no, no, i did the last one.
<Hobbsee> i have uni this time around.
<seb128> Hobbsee: well, I think we have people responsible enough in the team to get something working
<Hobbsee> it's a heck of a lot of work - doesnt make sense for canonical to rely on volunteers to do it
<Hobbsee> although i'd like to :P
<Hobbsee> seb128: oh good
<Hobbsee> (well, with pitti, i did the last one)
<seb128> Hobbsee: it's just less efficient
<Hobbsee> seb128: true
<seb128> and it's good to have somebody making sure issues are assigned to somebody
* realist twiddles thumbs
<seb128> and we need somebody dealing with the CD building and archive freeze and publisher
<Hobbsee> realist: is offering?
<realist> I would, if I knew what exactly was involved
* realist is completely unqualified for the tast
<realist> s/tast/task/
<Hobbsee> realist: see https://wiki.ubuntu.com/MilestoneProcess :P
<Hobbsee> there's a list.
<elkbuntu> realist, a cat'o'9 come in handy
<realist> I see, it's a project management type role :-)
<Hobbsee> elkbuntu: indeed!
<realist> Surely ubuntu isn't short of a release manager!?
<Hobbsee> realist: the current one is getting married, and therefore going on leave.
<Hobbsee> no idea when the transition happens
<realist> I honestly like to help, but don't have an existing relationship with ubuntu developers.
* Hobbsee shrugs
<Hobbsee> realist: if you are interested in helping in bits, i believe there are some areas.
<Hobbsee> you'd probably have to ask during the week, i guess
<_wattazoum_> me again :-) ; how comes some entries in the "System->Admin" menu (eg. synaptic) are visible only by sudoers and not by others (whyle nothing seems to be specifying this in the .desktop file) ?
<mdke> _wattazoum_: because there is no reason to display applications to users who cannot use them
<_wattazoum_> yep , but how do I make this for my application ?
<geser> I'd guess it's done with Categories
<_wattazoum_> mdke:  I would like to make a menu entry that is only usable by sudoers
<_wattazoum_> well, I have looked at synaptic.desktop and find nothing that would mean that in Categories
<_wattazoum_> thank you geser , mdke for helping me out
<mdke> there is likely to be a specification on the wiki about how we did it, hang on
<mdke> _wattazoum_: https://wiki.ubuntu.com/HideAdminToolsToUsers
<_wattazoum_> WOW
<_wattazoum_> mdke:  This is efficient
* _wattazoum_ is looking at it 
<mdke> :)
<_wattazoum_> hum, well, the "X-KDE-SubstituteUID = true" option is quite confusing :-/
<_wattazoum_> but that was the solution
<_wattazoum_> mdke:  I owe you one :-)
<mdke> np.
* Hobbsee waves to mdke 
* mdke waves back, and notes that "flavour" is a spelling lent to Australia by the English
<mdke> we can take it back at any time
<_wattazoum_> :p
<Hobbsee> mdke: i thought it may have been.  i used to speak to people mainly in the US, rather than mainly in England, where they would keep telling me that I was spelling flavour wrong.
<mdke> lies
<Hobbsee> exactly
<StevenK> Hobbsee: At which point you say, "Sorry, I don't speak American."
<Hobbsee> heh :)
<realist> mdke: probably because we speak English, in Australia :-)
<realist> I still get the irrits, when I see things like "color" in config files
<thom> i'm not sure you can claim to speak English and then say "irrits"
<thom> :P
<realist> thom: that was colloquial ;p
<Ng> hmm
<Ng> anyone know what PPA means when a package fails to upload? afaics it built fine
<StevenK> Launchpad failed to fiddle it to move it into the accepted queue. A buildd admin can twiddle in.
<StevenK> Er, twiddle it in
<Ng> hmm
<Ng> technically I'm a buildd admin, but I don't want to go poking around ;)
<Ng> StevenK: thanks
<Amaranth> Who is Matthew Nuzum?
<elkbuntu> Amaranth, newz2000
<Amaranth> Never heard of him
<elkbuntu> that's because he hides well
<Amaranth> But he is surprisingly bad at filing bug reports
<Amaranth> Does he hide out in #canonical only or something?
<Ng> he's in #canonical-sysadmin at least (although probably not awake right now)
<_wattazoum_> mdke:  are you available ?
<_wattazoum_> I would like to propose my software to Ubuntu repositories , can someone point me to the right direction ?
<seb128> _wattazoum_: https://wiki.ubuntu.com/MOTU/Packages/New
<_wattazoum_> Thank you seb128  ( how do you find docs so easily ? )
<seb128> _wattazoum_: you're welcome
<seb128> wiki is easy to use, I search pages with "new" in the title ;)
<seb128> and then I looked for "package"
<_wattazoum_> lol
<_wattazoum_> well, next time I'll take more time to find :-)  or use simpler requests
<IntuitiveNipple> Do we have any gnome VFS programmers in?
<bhale> you probably want #gnome-hackers or possibly #gnomevfs on irc.gnome.org
<IntuitiveNipple> yeah, I probably do... I was trying to avoid switching nets :)
<siretart> asac: is the broken .pc file in firefox still on your radar?
<asac> either its fixed in my bzr branch ... or i dropped it
<asac> lets see
<asac> siretart: did the compatibility link trick work for you?
<siretart> asac: sorry?
<siretart> asac: I'm talking about bug #112818, btw
<ubotu> Launchpad bug 112818 in firefox "wrong pkgconfig dependencies break builds" [High,In progress]  https://launchpad.net/bugs/112818
<asac> siretart: that bug whould be there
<asac> siretart: its not a bug iirc
<siretart> asac: sorry?
<siretart> how can this possibly be not a bug?
<siretart> the .pc file specifies this as Cflags: -I/usr/include/firefox/nspr
<siretart> However, /usr/include/firefox/nspr does not exist. This breaks e.g. gxine build
<CompleteNoob> is there anyone online that can pvt me, and with great patience explain to me how to get started in development/coding?
<alesan_> what are the necessary steps do build a custom version of ubuntu. I mean, I would like to add some software and drivers on the live CD
<alesan_> I guess there is a svn and a script to prepare the ISO image
<asac> siretart: the firefox-nspr.pc file is obsolete
<asac> siretart: thus the compatibility link to /usr/include/nspr/nspr.pc
<asac> e.g. thats the solution
<asac> ... which i asked you to test ... or someone else a few days ago
<asac> but never received an answer
<asac> i will do that now in bzr branch
<siretart> asac: since thre is nothing about that question in lp, I'd think you confuse me with so. else
<asac> sure
<siretart> asac: can you then perhaps look at fixing the gxine package?
<asac> i think so too
<asac> what is the issue?
<siretart> asac: in debian, it is built against xulrunner, and now I'm quite confused how to fix it in ubuntu
<siretart> asac: as said in the bugreport, it FTBFS, because it uses firefox-nspr.pc
<asac> siretart: if you want to try ... just rm firefox-nspr.pc and firefox-nss.pc and create links to the nss/nspr files instead
<asac> maybe it just works then
<asac> if not i can look
<ivoks> out of nowhere, why don't we chgrp to dialout on pap|chap-secrets? with rw for group?
<siretart> asac: I do not know the firefox source at all. not sure how much time it will take for me to figure out what you exacly mean :)
<asac> siretart: no i mean
<asac> just in install
<asac> remove the firefox-nspr.pc that is installed
<asac> and replace it with nspr.pc
<CompleteNoob> asac: if i wanted to write a 'hello world' for ubuntu...where would i start? what IDE/compiler etc would i use?
<CompleteNoob> i'm VERY new to programming
<asac> CompleteNoob: its not really ubuntu specific
<asac> e.g. more linux/unix
<asac> in general: use and editor + the compiler of your choice
<siretart> CompleteNoob: this channel is not about general development, but development of ubuntu. you should try a more focused channel
<CompleteNoob> sirestart, could u reccomend a chan i could check out?
<asac> CompleteNoob: go to a channel dedicated for the programming language you want to use
<CompleteNoob> ok, thank you
<siretart> asac: I did now as you told me, firefox-nspr.pc -> nspr.pc and firefox-nss.pc -> nss.pc, and gxine builds again
<asac> perfect
<asac> siretart: thanks
<asac> let me do it here
<asac> siretart: https://code.launchpad.net/~asac/firefox/ubuntu-2.0.0.x
<siretart> asac: cool. so we need just not forget to let gxine given back after the next upload
<asac> well ... maybe add gxine to the bug?
<siretart> it is already mentioned in the bug
<siretart> it just needs to be given back, no new upload necessary
<cassus> hi
<cassus> where did the #ubuntu-boot chanel disappeared?
<mdke> is bogofilter the preferred spam filtering program nowadays, rather than spamassassin (i see the latter is in universe)?
<cassus> ok, never mind
<cassus> bye
<pygi> hey folks
#ubuntu-devel 2007-07-29
<acm> hallo. anybody is up who read the ubuntu-devel mailinglist? so, i would like to know some more detail about "branch for the team or each debian directory". what's include in the debian directory?
<acm> only changes of the debian upstream or changes in ubuntu upstream and debian?
<LaserJock> the actual debian/ directory
<LaserJock> which holds all the packaging information
<acm> the actual debian/ dir can also be called upstream?
<LaserJock> well, kinda
<LaserJock> Debian is upstream for most Ubuntu packages
<LaserJock> but upstream is also the actual software authors
<acm> ah ok. also for gutsy?
<LaserJock> yes for gutsy
<LaserJock> so you have to often look at the context of the statement to figure out what "upstream" is being talked about
<acm> so network-manager confuse me looking at https://code.launchpad.net/network-manager/. which is upstream for the current developing of gutsy? one of the ubuntu core dev-team?
<LaserJock> no
<LaserJock> upstream is where we get the packaging/software from
<crimsun> (https://code.launchpad.net/~vcs-imports/network-manager/main)
<LaserJock> acm: the "main" branch is the vcs import
<LaserJock> that's the code that comes from the authors
<LaserJock> then it looks like upstream.0.6.x branch holds the released source code form the Network Manager authors
<LaserJock> and the other "Ubuntu Core Development Team" branches hold our source package
<acm> everybody who develop patches does not apply to this branch?
<LaserJock> so basically upstream + debian/ directory
<acm> ah
<acm> ok
<LaserJock> well, if the person is a member of the Core Development team they can make changes to that branch
<LaserJock> otherwise they need to get somebody to merge it in for them
<acm> yes. thats clear.
<acm> '
<LaserJock> sometimes the Ubuntu branches will just be the debian/ directory and sometimes it's the whole source package
<acm> so upstream.0.6.x would be the right source package (for network-manager) to make changes that could be included in the next ubuntu release 7.10
<LaserJock> no
<LaserJock> upstream.0.6.x has just the upstream source
<LaserJock> I think ubuntu.0.6.x would be the one to make changes in
<LaserJock> or gnome.ubuntu.0.6.x if it's for the gnome applet package
<LaserJock> at least that's how it looks to me
<acm> :)
<acm> ok thanks
<acm> last question :). what is about the branch of Alexander Sack?
<LaserJock> that is his personal branch
<asac> you can use ubuntu.0.6.x to do changes
<asac> for nm
<asac> but please use the patch system
<asac> OTOH, just modifying the tree and use the diff of those trees to create the patch might be quite efficient :)
<asac> lamont: acm ^^
<asac> lamont: unping
<calc> asac: here?
<Fujitsu> ] ] ] \
<Fujitsu> Oops.
<superm1> does anyone know what package creates the initial /etc/X11/default-display-manager?
<superm1> it's appearing that its got a problem of setting the wrong contents for a fresh install from debootstrap for gdm
<stdin> probably your ?DM package
<superm1> alright i'll pull the gdm sources and check there then.  thanks
<stdin> reconfiguring gdm would rewrite it
<superm1> its a matter of /usr/bin/ or /usr/sbin
<superm1> and it's taking the wrong of the two
<superm1> it does appear to be a bug that was introduced, in seb128's absence, could someone else on core-dev sponsor bug 129017 then?
<ubotu> Launchpad bug 129017 in gdm "incorrect gdm/daemon_name template" [Undecided,Confirmed]  https://launchpad.net/bugs/129017
<siretart> superm1: I've seen that bug on a friends laptop as well!
<superm1> siretart, i wasn't sure what it was at first, i've been seeing it in my daily mythbuntu builds
<superm1> and just got annoyed enough that it needed to be figured out :)
<fabbione> hey guys
<siretart> hi fabbione
<revilodraw> hi, i just got banned from #ubuntu for making a joke that wasnt even bad... how do i get unbanned?
<stdin> revilodraw: #ubuntu-ops
<elkbuntu> revilodraw, i have private messaged you. please join #ubuntu-ops or register to continue the discussion
* pitti NEWs the new kernel
<geser> seb128: thanks for processing sync request on a saturday night
<seb128> geser: you're welcome ;)
<seb128> geser: I was quickly looking on something and I figured I would do the syncs in the same time since there was not so many of them
<Hobbsee> heya seb128
* pitti hugs Hobbsee 
* Hobbsee hugs pitti!  :D
<Hobbsee> didnt know you were here today :)
<seb128> hey Hobbsee
<GyrosGeier> doko, better channel. :-)
<GyrosGeier> doko, currently the libssp-default patch is applied if the host is Ubuntu
<GyrosGeier> doko, it might make sense to switch that to "target is Ubuntu"
<GyrosGeier> doko, or, alternatively, to not patch this into the compiler but rather modify the specs file after the fact, as I do with uclibc-toolchain
<doko> we don't have a configuration for a "target distribution"
<GyrosGeier> which is why option 2 sounds more sane to me
<GyrosGeier> would you be interested in a patch that does that?
<doko> that doesn't help for building the compiler itself
<GyrosGeier> it does if the target libc does not have libssp built in
<GyrosGeier> because after stage 2, -fstack-protector is in effect (as it should be), but libssp is not built yet
<GyrosGeier> hmm#
<GyrosGeier> wait
<GyrosGeier> I see what you mean
<GyrosGeier> right, it doesn't help
<GyrosGeier> so what would be needed is either building libssp first
<GyrosGeier> (I think it should be safe to build libssp with ssp enabled, but I need to check)
<GyrosGeier> or build-depending on the target libssp for cross builds
<GyrosGeier> (which would also require checking whether libc provides libssp, and adding -lssp to the default libs if not)
<mdke> seb128: hiya. Saw your post about bzr. Were you thinking of including gnome-user-docs in the move? I've arranged a vcs-import of svn trunk at https://code.launchpad.net/~vcs-imports/gnome-user-docs/trunk, and would be interested in finding out how to use it to make some ubuntu-specific changes and maybe host the packaging
<mdke> seb128: I was going to start reading the docs on the wiki about maintaining packages in bzr, would be grateful for your input
<seb128> mdke: I'm not an expert about packaging in bzr, I'm trying to get some ideas on the topic
<mdke> seb128: ok, I'll follow the thread. I've read the wiki page, it's pretty difficult to understand the best way to do it
<seb128> mdke: I don't think having gnome-user-docs in ubuntu-desktop is a good idea, we will give commit access to the people of the team and I don't think the same group of people will work on it
<mdke> seb128: right
<mdke> so ~ubuntu-docs then, I guess
<seb128> right
<seb128> for the documentation is might make sense to have everything in bzr and not only the debian dir
<mdke> I was thinking the same. That would allow us to customise the docs directly rather than write patches
<mdke> seb128: but I don't know how that would work with Debian changes (if there are some)
<seb128> mdke: you would have a debian branch and an ubuntu one and merge when there is an update
<mdke> seb128: you mean a branch for the debian directory and merge from Debian upstream, and a branch for ubuntu with the documents and merge from Gnome upstream?
<seb128> not trivial with the 3 versions, I'm not the best person to ask
<seb128> maybe mail ubuntu-devel-discuss about it
<mdke> sorry if I'm being slow, i've never used bzr
<mdke> ok thanks
<pygi> hey seb128
<seb128> hi pygi
<pygi> seb128, in a few days, all brasero-related functionality bugs will be closed, yay :)
<seb128> cool
<pygi> I've saw you uploaded experimental patch for n-c-b
<pygi> s/saw/seen
<seb128> pygi: "experimental"?
<seb128> pygi: I don't think there is anything experimental in the ncb patches, is it?
<pygi> seb128, I meant not tested :)
<seb128> do you insinuate that I don't test changes before uploading?
<pygi> ergh, no
<pygi> when did I say that?
<seb128> I don't know where you want to go but you should better ask directly your question if there is one
<seb128> "I meant not tested"
<pygi> no question, just saying I saw the upload
<seb128> k
<pygi> sorry if you got it any other way
<seb128> and why do you think it's not tested?
<seb128> I did test it!
<pygi> oh well, then not in upstream tree yet :P
<seb128> right
<seb128> I knew that
* pygi should better stop talking 
<seb128> are you just pointing it, or do you have any comment about that patch? ;)
<seb128> I'm not sure where you want to go
<pygi> seb128, I didn't had the time to look at the patch =)
<pygi> well, nowhere really :P
<seb128> k
<pygi> Just saying I saw the upload :)
<seb128> because I also uploaded a GTK+ patch today
<pygi> Nice to see some fixes =)
<seb128> ;)
* pygi upgrading his laptop to gutsy, let's see if it'll boot :P
<pygi> ergh, even the upgrade didn't go well
<pygi> o well, lets see what a reboot will say
<pygi> brb
<soren> iwj: Do you have an opinion on http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=421344 ?
<asac> calc: you still need me?
<calc> asac: i was just going to ask how the wifi stuff was progressing
<asac> well ... for ipw we have not yet founda  solution
<asac> we know that the reason is that assocation on driver level appears to take ages
<calc> asac: oh?
<calc> asac: so its a driver issue?
<asac> well at least wpa supplicant doesn't do anything in the meantime
<asac> well wpasupplicant might be able to deal better with disassociate events from driver
<asac> i need to get some ipw hardware
<calc> hmm ok
<asac> otherwise, I cannot really proceed
<calc> from what i have been told the driver in feisty and gutsy is the same revision
<calc> so if something changed it would have to be outside the driver that caused it to show up, if there is a bug in the driver
<asac> hmm at least for 2100:
<asac> (gutsy)asac@hector:~$ apt-cache show ipw2100-source | grep Version
<asac> Version: 1.2.2-2
<asac> asac@hector:~$ apt-cache show ipw2100-source | grep Version
<asac> Version: 1.2.1-2
<asac> second one is feisty
<calc> hmm yea
<asac> for ieee80211-source its the same version
<asac> Version: 1.1.6-4
<calc> BenC: said the 3945 driver was the same in both
<asac> yeah is probably right then
<calc> though i haven't verified that myself
<asac> maybe you or stgraber can test feisty wpasupplicant in gutsy ... like we did back a few days
<asac> and see if time till assocation goes down
<calc> yea, i'll try to remember to look into that tomorrow, i'm pretty busy today :\
<ScottK> calc: Any word on OOO refusing to start?
<calc> ScottK: it seems to be more widespread than ooo, from what i read on a bug report it appears glib broke abi compatibility without proper versioning
<calc> it breaks various kde stuff as well from what i recall
<ScottK> Ah.  So it's glib
<ScottK> Konqueror is suffering with Flash too.
<calc> ScottK: either glib or gtk, it was a few days ago when i read the bug reports
<calc> i didn't realize it at the time the reason i probably don't see the issue is i have ooo 2.3 installed on my box
<ScottK> Well I'd heard gtk, but there's a new one and no change.
<calc> ScottK: yea its probably glib
<calc> the ooo bug is attached to glib as well
<ScottK> OK.
<ScottK> Sounds like lots of fun.
<calc> when i finally get 2.3 uploaded it will be resolved for ooo, but breaking abi isn't a good thing, probably breaks other things people haven't reported yet as well
<nixternal> hehe
<ScottK> nixternal laughs because he is suffering too.
<nixternal> I just found it funny because calc is probably getting asked a few times a day about OOo..I know he breathed a small sigh of relief when he found out the problem was elsewhere :)
<ScottK> In the scheme of things this isn't so bad.  I just had to go get ice for my laptop because of a kernel regression that makes the fan not work.
<calc> nixternal: well i knew it had to be elsewhere immediately since i hadn't done an upload in over a week and it just started breaking everywhere, lol
<Amaranth> Does OOo use some things in gtk that aren't really supposed to be public in order to do its 'integration'?
<calc> Amaranth: no idea
<calc> Amaranth: it has a bit of source to look through ~ 3gb worth
<Amaranth> I know there are some things you can poke at in gtk+ that aren't guaranteed to be API/ABI stable
<calc> Amaranth: though the fact it is breaking other things as well points towards glib/gtk
<Amaranth> Might have been the tooltips stuff
<calc> Amaranth: someone that knows a lot about glib should probably check the diff between when it worked and broke
<Amaranth> a member in a struct changed name and is always NULL now and some things used that (but shouldn't have)
<Amaranth> i know it broke pygtk
<nixternal> it broke notify-send as well :(
<calc> Amaranth: ah thats interesting, its possible that the things that broke used the same member
<calc> if that is the case then 2.3 is fixed
<calc> because it works fine for me
<ScottK> When are you rolling 2.3 out for Gutsy?
<calc> asap
<calc> i'm merging debian/ubuntu debian dir right now and rewriting bits so its easier to keep merged
<Amaranth> yeah afaik it crashed apps that didn't expect it to be NULL and made them fail to build
<calc> there is an issue of gcj-4.2 running out of memory during build though so i had to disable java support right now
<calc> doko: mentioned that it was supposed to be fixed (iirc)
<doko> calc: it is fixed
<calc> doko: i upgraded and it still failed yesterday, i think i will try completely regenerating my chroot then
<doko> calc: what version of libc6 do you have?
<calc> 2.6-4ubuntu2
<doko> calc: that should be ok, maybe work on i386 for now.
<calc> doko: i was doing the compile on i386, so i'll try redoing the chroot and building again later tonight
#ubuntu-devel 2008-07-21
<warsocket> k question, lets say ive made a program that would do nice in the ubuntu repository, what should i doe or who should i contact to get it there
<azeem> warsocket: #ubuntu-motu
<warsocket> k
<geser> slangasek: Hi, when you have time, can you please review the merge for gnupg? bug #225005
<ubottu> Launchpad bug 225005 in gnupg "Please merge gnupg 1.4.9-2 from Debian unstable" [Undecided,Confirmed] https://launchpad.net/bugs/225005
 * Hobbsee wonders how to disable the "feature" of having no shut down button, without going to gdm first.
<RAOF> Hobbsee: Surely that's a lie - I've got a shutdown button.
<RAOF> Admittedly, it doesn't actually _shutdown_, but it's certainly a button, marked shutdown :)
<RAOF> Mostly it freezes gnome-panel.
<Hobbsee> RAOF: intrepid?
<RAOF> Hobbsee: Yah
<Hobbsee> ah.  there's a separate shut down one
<RAOF> Right.
<RAOF> It's reverted to upstream GNOME's shutdown/logout thingy.
<Hobbsee> RAOF: thanks
<RAOF> It's broken for me, though, so it's not _really_ helpful :)
<Hobbsee> aww
<Hobbsee> RAOF: if you're in an answering mood, how do i make compiz work again?
<RAOF> How's it broken?
<Hobbsee> /usr/bin/compiz.real (core) - Error: Could not acquire compositing manager selection on screen 0 display ":0.0"
<Hobbsee> /usr/bin/compiz.real (core) - Fatal: No manageable screens found on display :0.0
<Hobbsee> Window manager warning: Workarounds for broken applications disabled. Some applications may not behave properly.
<RAOF> Ah.  Turn off metacity's compositor.
<Hobbsee> (from a compiz --replace &)
<RAOF> Metacity's compositor doesn't release the CM selection in the way that compiz would like it to.
<Hobbsee> ahhh
<RAOF>  /apps/metacity/general/compositing_manager or somesuch.  It's changed name at some point in the past.
<Hobbsee> found it, thanks
<RAOF> That should now allow you to experience other bugs in Compiz :)
<RAOF>  / mesa / X
<Hobbsee> like the fact taht some of my settings have been lost, and my metakeys aren't working again?
<Hobbsee> well, some of them
<RAOF> Dunno.  I'm only just playing with compiz again now that there's an nvidia-glx to test.
<alex-weej> and the workspaces have gone back to 2 even though i've chosen 4!
<Hobbsee> alex-weej: yeah, it seems to have wiped all the settings.
<Hobbsee> RAOF: right.  got it all working, except that it still doesn't start by default.
<Hobbsee> and gnome-panel's being tempramental, again
<Hobbsee> mmm...fire :)
<superm1> RAOF, how's the experience going for the nvidia-glx new way of doing things (except for jockey not being there yet)?
<RAOF> superm1: Basically flawless.  Installing nvidia-glx-177 works fine, nvidia-xconfig worked for me.
<superm1> cool, that's good
<alex-weej> superm1: what's new?
<alex-weej> i'm using 177 beta on intrepid now cause jockey didn't want to work
<alex-weej> (and it's not in lrm)
<superm1> alex-weej, the way that everything is packaged has changed with it not being in LRM, so i just was curious to make sure that there was no major problems coming up using the nonlrm packaging
<superm1> alex-weej, you weren't using the .run file from nvidia's website right?
<alex-weej> i was
<alex-weej> and it worked
<alex-weej> shouldn't it have?
<RAOF> Well, it should have.  But the nvidia-glx-177 package would've made it easier :)
<superm1> alex-weej, the nvidia-glx-177 should be able to handle the upgrades from kernel to kernel properly
<superm1> so that's the important part to make sure continues to work
<alex-weej> that's a good point... i've had loads of kernel updates but not had to rebuild
<ryanhaigh> hello all, im trying to help someone here: http://ubuntuforums.org/showthread.php?p=5427518 . How would I go about changing the version number assigned to the package when building using the process described there?
 * Hobbsee wonders why they don't just purge tracker and be done with it.
<Hobbsee> ah
<ryanhaigh> yeah doesn't work unfortunately
<ryanhaigh> can anyone point me in the right direction
<Hobbsee> edit debian/control
<RAOF> Hobbsee: You mean debian/changelog, right?
<Hobbsee> er, yes, that.
 * Hobbsee wonders where her brain went.
<ryanhaigh> and just add another version in there?
<ryanhaigh> im not on my ubuntu machine at the moment so i can't try this myself
<RAOF> ryanhaigh: Correct.  "dch -i" is likely to be the easiest way to get a well-formed changelog entry.
<pitti> Good morning
<pitti> asac: just mention it in the MIR
<Hobbsee> heya pitti
 * pitti hugs Hobbsee, hey!
<Hobbsee> :D
<Mithrandir> hiya Hobbsee, pitti
 * StevenK waves, jetlagged
<Mithrandir> jet lag is overrated.
<StevenK> Not right now, it isn't.
<Hobbsee> hey Mithrandir!
<stgraber> moin
<asac> pitti: yep. did that. https://wiki.ubuntu.com/MainInclusionReportPcsc-Lite
<StevenK> pitti: Could you poke at why twin failed to upload to every arch it built on, bar lpia?
<StevenK> pitti: http://launchpadlibrarian.net/16198199/upload_673575_log.txt is the upload log
<StevenK> asac: MIRs are bugs ... :-)
<Wubbbi> bug 249850 is reported. Can you fix it please? :)
<ubottu> Launchpad bug 249850 in synaptic "Synaptic Freez up after installing Packages" [Undecided,New] https://launchpad.net/bugs/249850
<asac> StevenK: err its a bug as well
<asac> bug 250245
<ubottu> Launchpad bug 250245 in pcsc-lite "[MIR] - pcsc-lite sources + partially binary promotion to main" [High,Confirmed] https://launchpad.net/bugs/250245
<StevenK> asac: Heh, fair enough
<asac> ;)
<pitti> StevenK: ugh, no idea; I'm afraid that's a cprov problem
<soren> asac: I'm curious... Do you specifically want to keep pcscd out of main or do you just "not care"?
<asac> soren: the latter. i just need the lib to build wpasupplicant in a way that you can install pcscd and then get smart card support
<soren> asac: Ok, cool.
<geser> StevenK: twin does hardcode the binary deb versions in debian/rules. twin 0.5.1-3ubuntu1 build packages with the versions like twin 0.5.1-3.
<geser> StevenK: don't forget to also update the versioned dependency of libtw0-dev in debian/control
<StevenK> What the?!
 * StevenK digs
<StevenK> Oh, for crying out loud
<StevenK> There's a substvar for this!
<StevenK> geser: It gets worse. The version is hard coded in debian/rules.
<StevenK> Which is about the worst crack-cut-with-washing-powder I've ever seen
<geser> is there a better way to produce binary debs with a different version than the source?
<StevenK> Yes.
<StevenK> Don't do that.
<StevenK> geser: Seriously, it's complete crack
<cjwatson> sometimes it's necessary
<cjwatson> cf. gcc-defaults
<cjwatson> you can fish out parts of the source version and do arithmetic if necessary
<StevenK> Exactly.
<StevenK> Wield dpkg-parsechangelog and such.
<StevenK> pitti: Okay, that twin failure is a package bug
<pitti> StevenK: yep, saw it in backscroll
<StevenK> I feel so dirty
 * StevenK will nail the patch to the Debian BTS.
<StevenK> Severity: important. Maybe serious
<cjwatson> hmm. why did rarian-compat get demoted back to universe?
 * cjwatson puts it back in main
<soren> seb128: Fix for the virt-manager hypervisor selection bug just uploaded..
<seb128> soren: ah, cool, thanks
<soren> seb128: Any time :)
<NCommander> Anyone here an archive admin who can answer a quick question or two
<pitti> NCommander: yes, some; just ask your question, please
<NCommander> I have codeblocks sitting in the NEW queue; it has a lintian override, which I forgot to document; should I simply wait for the package to be REJECTed (as it would be in Debian), or is it possible it can be put through, and then get a debdiff applied to it ASAP?
<pitti> NCommander: you can just upload a new package if you want
<pitti> NCommander: however, an underdocumented lintian warning is not generally a reason for outright rejection
<pitti> unless it overrides something really bad
<NCommander> It overrides script-not-executable
<NCommander> (lintian is detecting a code parser as a script)
<pitti> ah, that's usually scripts in /usr/share/ with a shebang
<pitti> NCommander: I wouldn't reject a package due to that
<NCommander> THere is a second issue which I caught just a few hours ago
<NCommander> Upstream shipped a Debian folder
<NCommander> When I ran update-maintainer, the person who packaged it ended up in Original Maintainer
<NCommander> (my name is in the changelog)
<NCommander> I'm not sure if that's right, or not
<cjwatson> update-maintainer is for use when making Ubuntu modifications to packages that also exist in Debian, where the prior consensus has been that Debian maintainers should not be listed in Maintainer of Ubuntu-modified packages
<cjwatson> when making modifications to packages that originated elsewhere, you ought to find out whether that's what the original packager wants
<NCommander> cjwatson, it was a mistake that it went with that Original-Maintainer; I had intended to switch it to myself, but obviously that didn't quite happen
<NCommander> (I redid most of the Debian folder, so while I do credit the creator of the upstream folder in copyright, I'd think I should be there)
<cjwatson> you're allowed to edit debian/control by hand rather than using update-maintainer if that's what's needed ;-)
<cjwatson> it's a human-editable file
<cjwatson> (BTW, in Unix we call them directories rather than folders)
<cjwatson> in the case of what you *should* do with Original-Maintainer, I don't think it's terribly important either way, and certainly wouldn't be cause for a rejection
<ivoks> wrong channel
<ivoks> :)
<emgent> moin
<Ng> is there any way of tuning/inspecting gvfs? its sftp performance seems to be shockingly slow
<Ng> I can scp a file at line speed (10
<Ng> err, let me try that sentence again ;)
<Ng> I can scp a file at line speed (10MB/s). using nautilus's sftp claimed about 1MB/s, cp'ing to ~/.gvfs/blah/ and inspecting with iptraf suggested it was doing <200K/s
<\sh> Ng: if you do a simple sftp via sftp client...do you get the same?
<Ng> \sh: yep, ~10MB/s
<\sh> Ng: strange, I always had the same issue with winscp from windows -> to sftp enabled servers (linux, sun) ... sftp was always slow for me..that's why I try to avoid sftp in general
<Ng> (wired ethernet on a 100Mb fibre to the network the remote machine is on, so I'm pretty sure it's not network related or wireless nonsense)
<\sh> scp was always faster...could be me or something weired on the network those days...
<Spads> this is over an internal network, effectively
<\sh> Spads: yes :)
<Ng> I'm just curious if it's known that gvfs is slow at this stuff, or maybe if I can change block sizes it's sending or something
<seb128_> Ng: "this stuff" being?
<Ng> seb128_: I'm scping stuff to one of our machines and getting pretty much full wire speed (10MB/s) with scp and sftp console clients. nautilus via gvfs sftp claims to do ~1MB/s and if I use iptraf to inspect my eth0 when I'm doing a regular cp to the ~/.gvfs/ location it's more like 200KB/s
<Ng> I would expect some overhead, but that seems a bit odd
<seb128_> Ng: the .gvfs location is a standard fuse mount
<Ng> seb128_: any suggestions for where I could be looking to figure out why it's slow?
<seb128_> Ng: http://bugzilla.gnome.org/show_bug.cgi?id=523015 for gvfs, dunno about fuse
<ubottu> Gnome bug 523015 in sftp backend "Implement sliding window based upload operation" [Normal,New]
<seb128_> Ng: gvfs = when you use the ssh backend to do the copy, ie what nautilus is doing
<Ng> seb128_: ok. I'm entirely happy to ignore the fuse end of things, in which case we are only losing one order of magnitude ;)
<seb128_> Ng: also compare to command line sftp and not to scp if you want fair numbers ;-)
<Ng> I did, it's also pretty much full line speed
<Ng> there's a little variance which is probably because the line isn't exclusively mine, but 9-10MB/s
<seb128_> ok, that's probably somewhat along the line of the bug I pointed then
<seb128_> though your line is probably not a low latency one
<Mithrandir> seb128_: generally, sftp will be faster than scp, since scp has some ickiness in the buffering algorithms.  (I think?)
<seb128> Mithrandir: possible, anyway in this case that's clearly gvfs not doing an optimal job
<Ng> seb128: the latency is pretty low from here, we have fibre to the network the other machine is on, so we're talking a millisecond or so
<seb128> Ng: ok, so I don't know about other bug and it would probably require debugging from somebody knowing the code well enough
<Wubbbi> hello :)
<pitti> cjwatson: which installer component puts the user into the initial groups? (audio, video, etc.)? I'd like to drop some (intrepid-device-permissions)
<Ng> seb128: having 64k blocks from that patch would probably be enough in most instances, and since it was applied in march maybe we alreayd have that?
<Ng> bugzilla fails at making this stuff easy to find out ;(
<seb128> Ng: yes, it's already in hardy and intrepid
<Ng> seb128: hmm, a quick google suggested libglib 2.17, but hardy has 2.16?
<Ng> but our 2.16 does indeed have a 1024*64 buffer
<seb128> Ng: http://svn.gnome.org/viewvc/glib?view=revision&revision=6736
<Ng> yeah, I just grabbed the glib hardy source and that patch is definitely in it :/
<chmj> .join #ubuntu-za
<chmj> baah
<cjwatson> pitti: user-setup
<pitti> cjwatson: ah, thanks
<cjwatson> pitti: I'd appreciate it if you kept an eye on bug 188759 and bug 205563 while doing so
<ubottu> Launchpad bug 188759 in user-setup "install user doesn't belong to all "administrative" groups" [Undecided,New] https://launchpad.net/bugs/188759
<ubottu> Launchpad bug 205563 in user-setup "User created on installation does not belong to the scanner group" [Undecided,New] https://launchpad.net/bugs/205563
<pitti> cjwatson: right
<pitti> cjwatson: btw, related to that spec, is it easily doable to not create the cdrom fstab entry for desktop installs?
<cjwatson> no. apt-cdrom needs it
<pitti> hm, too bad
<cjwatson> attested by e.g. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464899
<ubottu> Debian bug 464899 in apt "apt-cdrom incompatible with desktop automount" [Normal,Open]
<cjwatson> I've said this pretty much every time somebody's asked about that fstab entry in the last four years, but none of the people who want it gone seem to have fixed it yet ;-)
<pitti> seems I keep forgetting about apt-cdrom then
<seb128> anybody knowing about dtd registration and use there who could have a look to http://paste.ubuntu.com/28998/ and let me know if that seems correct?
<seb128> that's a copy of the scrollkeeper dtd to rarian-compat and a registration similar to what scrollkeeper is doing
<cjwatson> pitti: see also http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=282344
<ubottu> Debian bug 282344 in apt "apt-cdrom: please change default CD-ROM mountpoint" [Wishlist,Open]
<cjwatson> (which is a more useful bug)
<pitti> cjwatson: ah, however, the fstab entry doesn't require the user to be in the cdrom group
<pitti> since nowadays we get ACLs on /dev/ storage devices, we can drop that
<pitti> (for raw-reading CD-ROMs)
<cjwatson> I store what I know about groups in the base-passwd documentation
<cjwatson> but, indeed, cdrom and floppy don't seem to be used for that
<cjwatson> pitti: the dialout comment about monetary consequences is a little odd, given that it's the first user and they could probably just pick up the phone ;-)
<cjwatson> though I suppose there's the spyware case, if that's what you meant by dialer programs
<pitti> right
<pitti> it's allegedly a bit far-fetched, since I didn't see actual programs which did that under Linux yet
<cjwatson> polkit-gnome-authorization would have a hard time dealing with minicom, wouldn't it?
<pitti> but they had been a PITA under Windows
<cjwatson> I think we should take some care with the serial port access programs we ship to avoid just pushing lots of people towards sudo
<pitti> cjwatson: that just controls ACLs on /dev/ttyS, so minicom is not a problem
<pitti> but yeah, I won't drop dialout until we actually have a replacement
<cjwatson> oh, it does? it has no manual page so I couldn't tell
<pitti> cjwatson: s/does/is planned to/ :-)
<pitti> cjwatson: for now I plan to drop cdrom, floppy, plugdev, audio, video, dip
<pitti> and keep dialout, adm, fuse
<cjwatson> bit of a horror show of a UI though
<pitti> cjwatson: how do you mean?
<cjwatson> plugdev> awooga that's used by other bits of the installer
<cjwatson> polkit-gnome-authorization? it's one of the most complex UIs I've ever seen :)
<cjwatson> came up in Ubuntu reviews too
<pitti> cjwatson: what's behind the "enable modem access" checkbox shouldn't matter to the user? (PolKit call or add group)
<cjwatson> oh, if there's a cleaner wrapper around it, sure
<pitti> cjwatson: ah, right; yes, that's known upstream, too, and being worked on
<cjwatson> partman-basicfilesystems/fstab.d/basic:64:                      # base-passwd defines gid 46 as group plugdev
<cjwatson> partman-basicfilesystems/fstab.d/basic:74:                      # base-passwd defines gid 46 as group plugdev
<cjwatson> used for giving people the ability to see the contents of FAT/NTFS filesystems
<cjwatson> and write to them, come to that
<pitti> cjwatson: the installer cares which groups the initial user is in?
<cjwatson> yes
<pitti> s/cares/& about/
<cjwatson> or, rather, if they aren't in plugdev, they won't be able to read/write those filesystems
<cjwatson> which will be a fairly serious regression
<pitti> hm, how odd
<cjwatson> pitti: not that odd - with the way FAT/NTFS permissions work, it has to just give access to a Unix group
<pitti> I wasn't aware that these parts of the installer run as the target user instead of just in the installer context
<cjwatson> they don't
<cjwatson> but the result, post-install, will be that the user cannot read from or write to those filesystems
<cjwatson> the alternative is to give access only to root (inconvenient) or to a specific user (doesn't allow permissions to be extended)
<cjwatson> at the time, plugdev was a pretty reasonable choice for that
<pitti> hm, I still don't understand, I'm afraid
<cjwatson> we put this in fstab:
<cjwatson>                         echo "$path" "$mountpoint" vfat $options,umask=007,gid=46 0 1
<pitti> I haven't had plugdev membership for ages, and no problem with fat/ntfs drives
<cjwatson> if the user is not in gid 46 then they will not be able to use their Windows-formatted data partition
<cjwatson> then you have yours set to non-default permissions
<pitti> oh, that, I see
<cjwatson> this is for ones that the user explicitly mounts in a particular place using the partitioner
<pitti> cjwatson: well, I never statically add windowsish partitions to fstab
<cjwatson> rather than filesystems that are automatically mounted
<cjwatson> you don't, but it's not uncommon to want them on e.g. /data rather than /media/blah
<pitti> right
<cjwatson> and people do do that
<cjwatson> it's not the absolute novice user case, but it's within what I'd consider to be relatively normal use of the desktop CD
<pitti> hm, seems we cannot get rid of either (fstab/groups) without getting rid of the other, too
<cjwatson> is plugdev doing any harm? just leave it there :)
<pitti> well, seems I need to for this round then :)
<cjwatson> I do understand the rationale, and we shouldn't use plugdev in similar ways for new purposes
<pitti> group 'sambashare'? that's new to me
<pitti> ah, bug 238224
<ubottu> Launchpad bug 238224 in user-setup "[PATCH] Initial user should be added to sambashare group if it exist" [Medium,Confirmed] https://launchpad.net/bugs/238224
<slytherin> Can any of the archive admins please process batik from 'NEW'? I would like to start looking into the packages that depend on batik and hence never built before.
<norsetto> seb128: hi, seen my email?
<seb128> norsetto: hi, I had a quick glance on the subject but that's all, I'm still busy catching up on other things after 2 weeks travelling, is there any hurry?
<norsetto> seb128: well, if you could say yes or no soonish would be nice otherwise the guy will be kept hanging
<mkrufky> to my surprise, "apt-cache search cogito" does not find any cogito package in hardy ....   am i looking in the wrong place?
<jcristau> mkrufky: no. cogito is dead.
<mkrufky> dead?!?
<mkrufky> cogito always accepts my malformed git commands....  now i have to learn how to use git PROPERLY ???
<mkrufky> :-P
<mkrufky> jcristau: can you recommend another tool?
<jcristau> git
<mkrufky> meh
<mkrufky> ok, thanks
<DktrKranz> mkrufky: for additional informations, see debian 436248
<ubottu> Debian bug 436248 in ftp.debian.org "RM: cogito -- ROM; FTBFS, orphaned upstream, superseded by git-core" [Unknown,Closed] http://bugs.debian.org/436248
<mkrufky> thank you, DktrKranz
<hwilde> anybody else get hit with smenara ?
<hwilde> found this nonsense in root history  http://pastebin.ubuntu.com/29004/
<hwilde> tar file has a port scanner, a password list, and a replacement binary for ssh and sshd :/
<mkrufky> hwilde: take a look in /tmp/ for any suspicious directories
<hwilde> I looked around couldn't find anything
<mkrufky> hwilde: especially directories whose name is comprised of >= 1 whitespace chars
<hwilde> but when I tried to ssh it gave a bunch of bogus ssh2 errors
<hwilde> so I removed and purged ssh, sshd, changed all passwords, reinstalled
<hwilde> fine now
<hwilde> but I couldn't find anything out on the net related
<slangasek> geser: yes, on my todo list
<mkrufky> i got hit by something a few months ago.... actually, it was a server that was powered down for a few years... i think i got attacked BEFORE i took it down, and only noticed a few months after bringing it back online
<hwilde> so if it's not a widespread thing on the net, I am thinking it was someon internal :/
<mkrufky> hwilde: also look around for suspicious cron deamons
<mkrufky> any users logged in that arent u
<hwilde> not without sshd :)
<mkrufky> look anyway ... if there are false cron daemons running, it can spawn processes without using sshd
<hwilde> nothing in cron
<hwilde> no users logged in
<hwilde> no way they could I removed --purge sshd
<mkrufky> i dont mean actual users
<mkrufky> ugh
<mkrufky> just ps aux and see if anything looks wierd
<mkrufky> my users logged in, i means any tasks running that may or may not be malicious
<mkrufky> ^ s/my/by
<mkrufky> anyway, im just making suggestions... i got hit pretty badly, but it was on a very very old system runnign a 2.4 kernel that i did not keep up to date with security fixes
<mkrufky> it was actually rather entertaining tracking it down
<hwilde> dbus-daemon --fork --print-address 24 --print-pid 26 --session
<hwilde> that looks a bit odd
<hwilde>  /usr/lib/bonobo-activation/bonobo-activation-server --ac-activate --ior-output-fd=28
<hwilde> pretty sure I don't need htat either
<hwilde> but they don't smell malicious
<hwilde> the scripts don't even look like they work
<hwilde> seems like a junior hack attempt
<hwilde> but why would it just hit me and no hits on google
<hwilde> must have been an inside job
<mkrufky> keep in mind that the hacker might want you to THINK that
<Trewas> some rootkits change binaries or even modify kernel so that their processes do not show, so there is no easy way to be sure everything has been purged (and whoever did it does not have access anymore) short of complete re-install
<ion_> âhackerâ â /me cringes
<ion_> rkhunter and chkrootkit might give some diagnostics.
<cjwatson> Trewas: (FWIW boot from read-only media and verify md5sums plus a manual check of any other unwanted files would normally be sufficient, though I'd only advise it to a competent person)
<pitti> james_w, seb128: our system-tools-backeds still installs /etc/dbus-1/event.d/70system-tools-backends; to me it seems entirely obsolete since /usr/share/dbus-1/system-services/org.freedesktop.SystemToolsBackends.service starts it automatically; do you see any problem with that? (works fine for me)
<pitti> james_w: (currently processing your mergre)
<seb128> pitti: any problem with what? having a duplicate way to start it? seems not optimal but I don't think it creates bugs either
<Trewas> cjwatson: right, if you have the known good md5sums available... gathering them by hand takes some effort and debsums at least does not know nearly all packages
<pitti> seb128: it's rather about having the s-t-b daemon running all the time, needlessly
<hwilde> rkhunter seems pretty cool...   but it just says       Checking /dev for suspicious file types                  [ Warning ]
<hwilde> which ones are the suspcious file types :/
<hwilde> [11:04:04]          /dev/shm/pulse-shm-2415330484: data
<hwilde> hmmm
<seb128> pitti: not sure what the "that" refers to in what you wrote before but if you suggest removing the event.d script I think that's a good idea
<pitti> seb128: ok; will do that then, merci
<seb128> cool, thanks
<cjwatson> Trewas: debsums does know nearly all packages, although it omits a few
<hwilde> cjwatson, isn't there an automated way to do that from livecd
<cjwatson> hwilde: is there?
<cjwatson> it's news to me if there is a simple way
<cjwatson> http://lintian.debian.org/tags/no-md5sums-control-file.html lists 221 packages, which is a rather small minority
<hwilde> I guess you would have to build the checksum list and put it on an external hd first
<hwilde> then tell the livecd to read that and compare
<hwilde> that would be pretty tight
<hwilde> I think i'm going to build it and then check my system
<Trewas> cjwatson: well yeah, rootkit would have to be quite carefully constructed to hide in the set of packages which debsums misses :)
<gaspa> someone knows who or what takes care of closing bugs, starting from changelogs like (lp:xxxx) ??
<gaspa> some scripts? launchpad itself? soyuz?
<hwilde> gaspa, #ubuntu-bugs takes care of it
<gaspa> ?
<gaspa> hwilde: i mean "automatically"...
<hwilde> i mean   /join #ubuntu-bugs
<seb128> gaspa: soyuz does, why?
<gaspa> seb128: thanks.
<gaspa> for a discussion on debian-devel. (please a moment... searching for it)
<gaspa> seb128: http://lists.debian.org/debian-devel/2008/07/msg00697.html
<gaspa> the point is:"if a debian maintainer close a LP bug on his changelog, will be automaticaly closed in launchpad?"
<gaspa> the answer seems to be "yes".
<gaspa> i only wanted to know how... but now i'm likely satisfied.
<seb128> ok
<seb128> gaspa: https://wiki.ubuntu.com/ClosingBugsFromChangelog for reference
<gaspa> i see, seb128, thanks.
<hwilde> how can you destroy the root passwd is somebody set it
<cjwatson> gaspa: yes, our tool that syncs packages from Debian parses the changelog for LP: entries
<gaspa> cjwatson: yep.
<slangasek> gaspa: fwiw, I've just added an explanation to https://wiki.ubuntu.com/UbuntuForDebianDevelopers about the changelog closing, in response to that thread on d-d
<jdstrand> kees: well, I haven't figured out the solution yet, but I have identified the problem with ubuntu-cve-tracker and firefox
<jdstrand> kees: firefox (the source package) produces the firefox-2 binary, but not the firefox binary
<jdstrand> kees: firefox-3.0 (the source package) produces the firefox-3.0 binary and the firefox binary
<jdstrand> kees: you can see the issue with 'apt-cache madison' and 'apt-cache showsrc'
<jdstrand> (for hardy)
<jdstrand> kees: the trick is to get ubuntu-cve-tracker to work this out, without breaking other stuff...
<jdstrand> (ie, it needs to pick 'firefox-3.0' as the source package in this case)
<kees> jdstrand: hurm, what's the example failure I can see with it at the moment?
<jdstrand> kees: well, you can see what happens with ubuntu-cve-tracker by doing './scripts/cve_status CVE-2008-2785'
<jdstrand> kees: you can see that the table shows firefox as 'needed' for all releases, though the CVE shows firefox as released for dapper-hardy
<jdstrand> kees: however, I don't think it's ubuntu-cve-tracker's fault, but perhaps apt_pkg
<jdstrand> (from python-apt)
<jdstrand> or perhaps our usage of it
<jdstrand> kees: I believe 'apt-cache madison firefox | grep hardy' demonstrates the issue
<jdstrand> kees: we really should only get back the firefox 2 source package (which is named 'firefox'), but we get back both firefox and firefox-3.0
 * kees scratches his head
<jdstrand> kees: at least, I only want to see the firefox 2 source package in that case
<kees> hm, we're only using apt_pkg do parse the file...
<pitti> hey kees
<kees> (and compare versions)
<kees> heya pitti!
<kees> jdstrand: but yeah, there is certainly something wrong... hm
<jdstrand> kees: re apt_pkg> well, it is precisely the parsing that is the issue :) it does seem consistent across various apt invocations, so I am not suggesting a bug there, just that we need to somehow work around it's parsing
<Hew> What's the best way to contribute a small patch to language-support-writing-en (to fix bug #58308)? I'm not an experienced contributor, and looking at the naming scheme of the version, appending ubuntu1 doesn't seem appropriate.
<ubottu> Launchpad bug 58308 in language-support-en "No spell check in en-au locale" [Undecided,Confirmed] https://launchpad.net/bugs/58308
<slangasek> Riddell: 189MB to go on the CDs? :-)
<Riddell> slangasek: I don't think the livefs has rebuilt yet
<slangasek> hmm
<Riddell> slangasek: it needs a recommends changed in arts but arts fails to build with a nasty compile error I don't understand
<slangasek> ok; shall I have a look?
<Riddell> http://paste.ubuntu.com/29036/
<LaserJock> pitti: bummer, re: rm'ing chroots
<pitti> LaserJock: :)
<LaserJock> pitti: thanks for the tip though
<Riddell> slangasek: don't know if that makes any sense to you
<slangasek> Riddell: a vague amount of sense; is this reproducible with the version in the archive?
<Riddell> slangasek: yes
<cjwatson> Hew: language-support-* are all generated; it's better to make a bzr branch of langpack-o-matic and submit that for review (there are facilities in LP for that)
<cjwatson> (oh, and mention the branch in the bug too)
<Hew> cjwatson: thanks for your help. I'm a noob at bzr, so I'll have a look at it :-)
<jdstrand> kees: hmm-- I don't think this is as complicated as I thought-- a bug was recently introduced that appears to mark all as needed if one is needed
<jdstrand> kees: as I think I may have introduced it, I'll fix it :)
<kees> jdstrand: okay, cool, I was just zero'ing in on it myself too
<slangasek> mathiaz: samba 3.2.0 wants merging :)
<asac> pitti: ArneGoetje: have you heard of any issues with the lang packs? you think we could copy them tonight so we can release the ffox/xul bits tomorrow morning?
<pitti> asac: one positive (pt from slangasek), no negatives
<asac> so noone replied on the call for testing?
<pitti> if so, they should have replied to Arne
<asac> pitti: so is one week without negative feedback enough for you?
<pitti> I don't understand why we don't get feedback this time
<asac> pitti: i gave you the reason ;) ... the name matters
<pitti> it's just about installing the -proposed packs, checking if GNOME starts and works, and Firefox is translated
<asac> pitti: firefox being translated i can check for a lot of languages
<pitti> asac: maybe you can verify for Chinese, Spanish, German, and French?
<pitti> (for ffox)
<asac> pitti: i can do that now.
<pitti> ffox is the part I'm most concerned about, the .po files should be ok
<pitti> asac: many thanks
<asac> pitti: i already checked almost all languages when i acked the packages to enter -proposed
<asac> anyway i can retry
<pitti> asac: ah, good
<asac> pitti: the only thing we should do is to roll the langpacks out half a few publisher runs before the firefox bits
<pitti> asac: the -proposed packs will work with the firefox in -updates?
<pitti> asac: i. e. you just bumped maxVersion?
<asac> pitti: yes. just the other way around
<asac> is a problem
<asac> right
<pitti> *nod*
<asac> pitti: let me check that ;)
<pitti> mmmmmm testing :-P
<asac> for the important languages ;)
 * pitti hugs asac
<asac> pitti: but in the end the translations didnt change ;)
<asac> would be scary if they broke
 * asac searches for old ffox and xul
<johanbr> asac: What should I do with bugs I find in the network-manager package  from the n-m 0.7 ppa?
<slangasek> pitti: if someone can tell me why I get a black screen when trying to switch back after starting a session as a new user, I'd be happy to test more languages for you :-P
<zul> slangasek: already merged and uploaded :)
<zul> (samba-3.2)
<pitti> slangasek: hm, I don't get that; do you use compiz?
<slangasek> zul: heh, ok
<slangasek> pitti: nope
<asac> johanbr: tell me briefly here and i tell you what to do ;)
<asac> slangasek: xorg driver issue i'd say. at least sounds wierd enough ;)
<johanbr> asac: After resume from suspend-to-ram, n-m takes a very long time (~10 minutes) to expire wireless networks no longer present.
<slangasek> asac: well, telling me it's an xorg driver issue doesn't make it stop happening, though
<asac> slangasek: right. if there is no choice for your chipset.
<slangasek> "intel"
<asac> pitti: ok. good news. no translation got disabled after downgrading ... now lets check for breakage
<pitti> asac: in the meantime, let me copy the langpacks from hardy-proposed to intrepid
<asac> pitti: good idea
<pitti> new ffox in intrepid has broken translations, too, the langpacks should help
<asac> yep
<tkamppeter> Riddell, hi
<pitti> running
<Riddell> hi tkamppeter
<pitti> hey tkamppeter
<tkamppeter> Riddell, did you hear anything new from Alex Wauck in the last days?
<tkamppeter> hi pitti
<Riddell> tkamppeter: no, I didn't get a weekly status report last week, I e-mailed him this morning about it but nothing yet
<asac> pitti: ok NEW de, fr, zh_TW, zh_CN, pt_BR, pt_PT and es_ES work fine with _old_ ffox/xulrunner
<pitti> yay
<asac> pitti: let me upgrade and do the same for new ffox/xul
<asac> pitti: ok NEW de, fr, zh_TW, zh_CN, pt_BR, pt_PT and es_ES work fine with _NEW_ ffox/xulrunner
<pitti> asac: ok, thanks a lot; I'll do the copy-o-mania hten
<asac> pitti: cool. ill remind you tomorrow morning and we can do the final ffox/xulrunner release then
<asac> thank you very much
<pitti> no problem, thanks for testing
<slangasek> Riddell: I think I have a patch for arts; where do you want it?
<Riddell> slangasek: an http url is nice
<slangasek> Riddell: how about an http url to a mergeable vcs branch? :)
<Riddell> slangasek: if that's easy to do, sure
<slangasek> Riddell: hrm, given the structure of the bzr branch that's available, perhaps not :/
<slangasek> Riddell: http://people.ubuntu.com/~vorlon/arts-ftbfs.diff
<Riddell> slangasek: I always said you were a genius
<slangasek> well, if I'm writing patches like this one, that must make me an evil genius ;P
<liw> slangasek, yikes
<ogra> cjwatson, https://bugzilla.mindrot.org/show_bug.cgi?id=1399 does that get us proper statfs calls in sshfs as well ?
<ubottu> bugzilla.mindrot.org bug 1399 in sftp-server "add statfs extension to sftp-server" [Enhancement,Resolved: fixed]
<kirkland> pitti: hiya, are you still around?
<pitti> hey kirkland, yes
<pitti> unfortunately no Taekwondo on Mondays during school holidays :/
<kirkland> pitti: hey, this is in regards to the ecryptfs MIR
<kirkland> pitti: :-)
<kirkland> pitti: actually, for one of ecryptfs' build deps, opencryptoki
<kirkland> pitti: doko had raised a concern about it, hard coding 2048 for path names
<pitti> right, I saw it
<kirkland> pitti: i wrote a patch, that made it upstream into opencryptoki last week, and an updated package is now in Debian unstable
<kirkland> pitti: would you be able to force a sync?
<kirkland> pitti: there are no Ubuntu changes
<pitti> kirkland: nice work!
<kirkland> pitti: oh, sure, no problem ;-)
<kirkland> pitti: also, I think your concerns about the ecryptfs PAM module are addressed in the last merge
<pitti> kirkland: opencryptoki synced
<pitti> 2.2.6+dfsg-1
<kirkland> pitti: i have a stack of manpages I wrote for ecryptfs that I'm sending upstream today, should hit Debian within a day or two
<kirkland> pitti: cool, thanks, i'll point doko to that in the MIR bug report
<pitti> kirkland: that's good (but that won't block the MIR)
<kirkland> pitti: see if that code makes him happier ;-)
<kirkland> pitti: oh, right, more just an heads up that I might need to do another merge later in the week
<mathiaz> 13:09 #ubuntu-devel: < slangasek> mathiaz: samba 3.2.0 wants merging :)
<mathiaz> 13:10 #ubuntu-server: < zul> mathiaz: samba-3.2 uploaded
<mathiaz> that was fast...
<slangasek> quite :-)
<zul> mathiaz: i was up early :)
<slangasek> jdstrand: have you seen bug #249881?  ISTR that SASL/EXTERNAL auth was one of the use cases you test for, no?
<ubottu> Launchpad bug 249881 in openldap "Hardy slapd server is not supporting sasl/external authentication" [Undecided,New] https://launchpad.net/bugs/249881
<alex-weej> how do i enable the apport segfault catcher?
<alex-weej> lots of things going wrong in intrepid... think i need to get on top of them
<RAdams> I need to compile 2.6.24-19 with acpi debugging AND tracing to track a known issue on Dell Latitude d800 and so laptops. I am familiar with how to do this with a vanilla kernel, but I want to confirm what the most useful/correct way to do this for this Ubuntu-specific build. I would love to help finally nail down this problem and thus contribute to the improvement of Ubuntu, but I need a point in the right direction. Thanks.
<jdstrand> slangasek: it is one of the test cases in qa-regression-testing, yes
<slangasek> RAdams: I'd suggest asking on #ubuntu-kernel
<RAdams> slangasek: thank you
<jdstrand> slangasek: oh, 'external', no, I just test supportedSASLMechanisms: DIGEST-MD5
<slangasek> jdstrand: ok
<slangasek> jdstrand: right, looks like this is broken in hardy but works in sid (so probably works in intrepid too, haven't tested there)
<jdstrand> slangasek: I've made a note to add a test case for this
<zul> slangasek: how do you test that?
<slangasek> zul: well, the bug reporter shows how to check whether it's a supported sasl mech
<zul> slangasek: k
<pwnguin> poor sh
<ilowe> Anybody have a quick and easy way to get mercurial to output a properly formatted changelog?
<alex-weej> how do i enable the apport segfault catcher?
<mario_limonciell> alex-weej, modify /etc/default/apport
<mario_limonciell> there is a variable for enabled={0,1}
<alex-weej> cool
<alex-weej> cheers
<ilowe> How do I patch a config file when installing a package? Do I have to do it "manually" in my postinst or is there a better way?
<mario_limonciell> pitti, slangasek did one of you folks adjust the component of the fglrx-installer source package from multiverse to restricted?
<slangasek> in what context?
<slangasek> fglrx-installer - looks like it's intrepid-only?
<mario_limonciell> yeah it is
<slangasek> I haven't touched that, no
<mario_limonciell> it's lived in multiverse for some time
<mario_limonciell> since i first uploaded it
<mario_limonciell> which was great since i could do the uploads without a sponsor
<mario_limonciell> but over the weekend it looks like it moved around :(
<slangasek> yeah, wasn't me
<slangasek> were the packages it builds previously in restricted?
<mario_limonciell> yeah...
<mario_limonciell> so maybe it was an oversight that was just rather convenient for me
<mario_limonciell> slangasek, well is copying from PPA release pockets to the archive supported now?  perhaps that can be a more sane use model for doing these uploads?
<slangasek> mario_limonciell: that would seem to imply archive admin intervention, so no, I don't think that's more sane...
<mario_limonciell> hum.
<Wubbbi> bug 249850
<ubottu> Launchpad bug 249850 in synaptic "Synaptic Freez up after installing Packages" [Undecided,New] https://launchpad.net/bugs/249850
<pitti> mario_limonciell: no, copy-package is too dumb to respect/change the overrides, so you'd have to do regular uploads
<mario_limonciell> pitti, could you change it back to leaving the source package in multiverse then?
<pitti> mario_limonciell: it doesn't make sense to have the source in mulitverse and binaries in restricted
<mario_limonciell> i'd hate to have to bug sponsors for this since i'm the only one that can control the upstream packaging for it at this point
<pitti> mario_limonciell: I can move the entire source/binaries back to multiverse for the time being, if that's better?
<mario_limonciell> pitti, well for doing uploads for now that makes more sense, but for long term, i suppose it should live in restricted
<pitti> right
<mario_limonciell> pitti, well whatever you think is the best solution at this point
<pitti> asac: for the record, copy to intrepid done, starting copy to hardy-updates now
<pitti> asac: should be done by midnight
<alex-weej> asac: is n-m 0.7 planned for intrepid?
<asac> alex-weej: yes
<alex-weej> is it getting into the archive soon or should i use your PPA to test?
<slangasek> ScottK: is there an MIR in progress for libcrypt-openssl-rsa-perl (needed by libmail-dkim-perl)?
<stgraber> superm1: Hi, I just noticed the upload of the new fglrx, is it supposed to work with the new X server ?
<AlinuxOS> hello, I'm installing Ubuntu 8.04.1 on my Acer Aspire One (nettop), knows someone about this kind of installation?
<mario_limonciell> stgraber, unfortunately not.
<mario_limonciell> stgraber, still need to roll back to older x server
<mario_limonciell> this release does perform a lot better though otherwise
<stgraber> ok, so let's hope next driver will solve that (maybe this Wednesday if they stick to their "usual" release schedule)
<mario_limonciell> stgraber, well this is the "next driver" (the 8-7 release)
<mario_limonciell> so i'm really disappointed too
<stgraber> argh :(
<stgraber> so one more month to wait and hope we'll have something working ...
<mario_limonciell> well i'm starting to wonder if we can get around this by just restoring the single missing symbol
<mario_limonciell> for now
<mario_limonciell> but i dont know exactly what the function does, so i'm wary of doing that
<stgraber> would be great to have it install again, the new cdbs packaging works fine from what I've tested (before the new X upload), the only problem is that missing symbol ...
<mario_limonciell> well if nothing else, this could be backported though to hardy if users wanted it too
<mario_limonciell> the way that the packaging is handled, it should override LRM, and it won't apply any 2.6.26 support patches when built on != intrepid
<mario_limonciell> so it appears that with the libtool in intrepid, ltmain.sh got moved from /usr/share/libtool/ltmain.sh to /usr/share/libtool/config/litmain.sh.  Should we be writing patches to configure scripts to handle this, or what's the appropriate policy for it?
<slangasek> you have packages where this requires handling?
<mario_limonciell> well it looks like libsmbios is FTBFS now
<mario_limonciell> and that appears to be the root cause from what i've looked around
<slangasek> in the general case, packages ship a copy of ltmain.sh in their source; a smaller number of packages update at build time using libtool -f -c.  No package ought to be linking directly to the system copy of ltmain.sh, AFAIK.
<mario_limonciell> well after a run of configure, there is a symlink to where it should be (was in hardy) in /usr/share/libtool.
<mario_limonciell> so then the package should be fixed to use its own ltmain.sh then
<mario_limonciell> i'll speak to upstream about it
<kees> wow.  pulse audio sounds really really bad.
<mario_limonciell> i suppose this explains why my patch was working early last week though.  the new libtool that broke stuff came in on the 18th
<slangasek> mario_limonciell: it doesn't look like an upstream bug to me, it looks like a packaging bug
<slangasek>         test -e build/ltmain.sh -a -L build/ltmain.sh || \
<slangasek>                 ln -sf /usr/share/libtool/ltmain.sh build/ltmain.sh
<slangasek> there's a "libtool -f -c" command for this, someone broke the abstraction
 * slangasek sees who the maintainer is and sighs
<kees> omg, seriously, how do I get rid of pulse?
<mario_limonciell> slangasek, yeah you are right.  in the upstream tarball the ltmain.sh is present
<mario_limonciell> slangasek, why do you sigh about the maintainer though?
<slangasek> kees: system -> preferences -> sound?
<kees> slangasek: doesn't seem to work for gnome start up nor flash.  they are ignoring it.
<slangasek> mario_limonciell: History<tm>
<kees> ugh, such horror.
<slangasek> kees: no one else is screaming about pulseaudio sounding horrible; you might want to file a bug report about that?
<mario_limonciell> slangasek, well i guess i'll file a bug in debian then with this chap
<kees> slangasek: yeah, I guess so.  *sigh
<slangasek> kees: and if this is intrepid, are you sure this isn't the weirdness with the snd_pcspkr driver?
<kees> slangasek: well, it does sound that bad, so maybe it is.  I hadn't heard of that until you mentioned it.
<slangasek> kees: try rmmoding the module in question (snd_pcspkr or snd_spkr or something I don't remember exactly) and see if it takes care of it
<kees> hrm, it's being held open, one sec
<slangasek> then afterwards, let me know if you see a bug report open about this, so I can milestone it :)
<kees> slangasek: yeah, it has clearly chosen the wrong default sink.  thanks PA
<slangasek> not sure PA is to be blamed for alsa suddenly enabling bizarre PC speaker output devices :)
<kees> yeah, though clearly ALSA picks the right default...
<kees> pulseaudio manager is helpful enough to not let me change it.  *sigh*
<tedg> kees, you might need the pulse audio tools.
<kees> tedg: I've got like 3 open currently.  which is the "right" on?
<tedg> kees: Try pavucontrol and pavumeter
<tedg> kees: Then you can right click and change the device defaults.
<tedg> kees: puvacontrol, Output Devices, then set the right one to default.
<kees> tedg: hah.  that was very discoverable.  (the right-clicking)
<TheMuso> kees, slangasek, tedg, I'll be looking at the pulse/PC speaker issue this week, maybe even today for intrepid. There are bugs filed on it, so its certainly known. Its an alsa issue.
<tedg> kees: You might need to go to Playback tab and change some things there also.
<slangasek> TheMuso: can you give me a bug number?
<kees> tedg: default changed it.
<TheMuso> slangasek: Give me a bit to get to that folder in my mail. Still processing mail for the first time this morning.
<slangasek> TheMuso: ok :)
<kees> so now I guess I should open bugs about flash and gnome login sounds not respecting the sound config settings.  (I set everything to ALSA in an earlier attempt to fix this)
<slangasek> if by gnome login you mean gdm, there's a bit of a problem with trying to make it respect per-user sound settings
<tedg> kees: No, you should just give up and accept "the pulse way" ;)
<kees> tedg: feh.  only when it doesn't skip on start-up and doesn't eat half a cpu.
<tedg> kees: You need quad-core, then it's only 1/8th the CPU.
<kees> slangasek: I assume I mean gnome, but whatever plays the "login" sound event.
<kees> tedg: I have a quad core.  they're busy doing other things.  (hence the skipping and getting in my way generally being a problem for me and pulse)
<kees> but, yes, it seems that alsa is the real culprit here, somehow
 * kees blames it all nonfree flash
<kees> tedg: okay, if you can show me how to get flashplugin-nonfree to work with pulse, I'll switch to pulseaudio.  :)
<kirkland> is there a lint-like program to run on manpage source code?
<tedg> kees: swfdec works for me.  :)
<kees> tedg: it doesn't for me.  :)
<tedg> kees: Chris Blizzard just said that mozilla trunk works with Ogg, just upgrade.  I'm sure there are no security issues.
<tedg> kees: BTW, are you sure you tried swfdec and not gnash, gnash never worked and swfdec was much, much better.
<kees> tedg: hrm? my problem is half the flash sites I go to don't work with either swfdec or gnash.  I would agree that swfdec was better, though.
<kees> current problem seems to be that even with libflashsupport installed, flash tries to use alsa instead of pulseaudio
<tedg> kees: I don't go to that many flash sites I guess...  I like that swfdec doesn't load unless I ask it to.
<kees> tedg: yeah, that's handy.  NoScript basically does the same for me.
<slangasek> augh, how do I get dbs-edit-patch to be non-fecal for 10 seconds?
<kees> slangasek: ew.
<kees> tedg: although at this rate, I'm more likely to have less frustration with swfdec than nonfree flash playing audio back on the only available audio device, the alsa pc speaker.  *sob*
<tedg> kees: Freedom is good for you ;)
<kees> tedg: so is being able to read crazy hacker blogs.  :)
<kees> cjwatson: why was openssh-blacklist moved to a Suggests on openssh-server?
<slangasek> space reasons
<slangasek> do you think it's still critical to include?
<kees> slangasek: well, it leaves new servers open to dumb people putting busted keys on the server.
<kees> slangasek: in theory, no keys should be left in the world.
<slangasek> ok
<slangasek> maybe it can be re-added in the case of openssh-server without hurting us on the CDs, I'm not sure
<kees> tedg: fail.  swfdec just crashed firefox.  :)
<sbeattie> kees: wait, wha? You're reading crazy hacker blogs and you need/want flash? Uhm, h'okay....
<cjwatson> ogra: statfs> I don't know whether sshfs needs to be updated too
<ogra> cjwatson, do you plan to pull that into our 4.7 ?
<cjwatson> kees: as Steve said, it didn't fit. I know demoting it is not without problems, but find me some space
<kees> sbeattie: I was wondering when someone would ask.  ;)
<ogra> seems the patch is 5.1 only
<cjwatson> ogra: I'd rather not brutalise our 4.7 further, TBH
<kees> cjwatson: okay, no problem.  as long as you're okay with it.
<ogra> it would be massivley helpful for ltsp localapps
<cjwatson> understood, I'll see if I can get us up to 5.1
<ogra> which is what i'm going to portland for on wed :)
<ogra> that would indeed be even better
<cjwatson> ogra: I was trying to get 4.7 (with all the key vulnerability nightmares) settled for lenny
<ogra> understood ... but then 5.1 would indeed move us away from debian for now
<ogra> (isnt lenn yfreezing in about a month or two ? )
<slangasek> or a day or two
<ogra> oh, really ? that soon ?
<slangasek> "this week"
<ogra> i didnt really keep track
<ogra> i just knew that sept. was the estimated date ... so i suspect dec to be the real one :)
<ogra> *suspected
<ogra> impressing
<kirkland> cjwatson: can you recommend an sort of lint-like utility that reviews manpage source?
<cjwatson> kirkland: man --warnings (or --warnings=foo,bar,baz where warning names are as listed in the Warnings node of 'info groff')
<cjwatson> ogra: I was going to put it in experimental
<cjwatson> ogra: and yes, it would introduce divergence, but it's not as if I have problems contacting the Debian maintainer ;-)
<ogra> heh
#ubuntu-devel 2008-07-22
<slangasek> doko_: since you did the merge of directfb, and deliberately re-enabled the build-dep on libts-dev, does that mean you're approving this as an MIR? :)
<slangasek> soren: is bug #196850 fixed in intrepid, or is it still just "Committed" somewhere?
<ubottu> Launchpad bug 196850 in virt-manager "vm cannot access cd-rom unless run as root" [Medium,Fix committed] https://launchpad.net/bugs/196850
<slangasek> pitti: do you happen to recall why you marked bug #229499 as 'fix committed' for intrepid?
<ubottu> Launchpad bug 229499 in linux "Latency regression with real time kernel and dynamic ticks feature" [Medium,Fix committed] https://launchpad.net/bugs/229499
<slangasek> jelmer: so, er, is there really no better way to tell the difference between a directory and a file in svn than trying to get a list of files within it?
<slangasek> jelmer: (I say, having had to nuke my cache of the pkg-samba repo and now watching the wheels spin again while it repopulates)
<slangasek> maybe there is a better way, and you're using it in the newer version of bzr-svn, and I'm just annoying you with my questions :)
<emgent> moin
<slangasek> zul: grmbl; there's a new samba 3.2.0-4 that'll need merged, brown-paper bag bug in -3
<zul> slangasek: yep saw the commit Ill do it first thing tomorrow when I get downtown
<slangasek> zul: ok, cheers
<Awsoonn> hi all, I am wondering if there are some helpful souls here that might mentor me in fixing a simple bug
<Awsoonn> bug 250681 is simple enough, I apt-get source irssi
<ubottu> Launchpad bug 250681 in irssi "first run help link outdated" [Undecided,In progress] https://launchpad.net/bugs/250681
<Awsoonn> found the string that needs changing
<Awsoonn> changed it, but now what should I do? I think I need to make a deb diff or something right?
 * Awsoonn wants to learn the ropes
<Awsoonn> when I got the source, it came with a diff.gz; do I need to apply that to the source first? So many questions for you guys
<ogra> Awsoonn, try #ubuntu-motu, they can point you to the right docs and info
<Awsoonn> ogra: TY
<superm1> slangasek, god you were right about that debian maintainer for libsmbios
<superm1> slangasek, would you mind chiming in on debian bug 491795?
<slangasek> superm1: hrm, I thought I was careful to say very little that I could be right about ;)
<ubottu> superm1: Error: Could not parse data returned by Debian bugtracker: global name 'ls' is not defined (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=491795;mbox=yes)
<superm1> slangasek, well just hard headed about things
<superm1> along the lines of "its not broke yet in debian because we havent switched to a newer libtool, and this is the way it should be done"
<slangasek> superm1: I think I'm lacking the necessary patience to deal with that tonight; maybe tomorrow...
<soren> slangasek: re bug 196850: It certainly should be fix released. Thanks for the pointer.
<ubottu> Launchpad bug 196850 in virt-manager "vm cannot access cd-rom unless run as root" [Medium,Fix committed] https://launchpad.net/bugs/196850
<pitti> Good morning
<pitti> slangasek: I thought if the fix was available for hardy, it could be uploaded to intrepid, too; nothing particular beyond that
<StevenK> pitti: Mind casting your eye over https://bugs.edge.launchpad.net/ubuntu/+source/policykit/+bug/250619 ?
<ubottu> Launchpad bug 250619 in policykit "[intrepid] policykit pulls in policykit-gnome due to Recommends" [Undecided,In progress]
<pitti> StevenK: I totally agree to that
<pitti> StevenK: please upload if you want, otherwise I'll do it later (I have to leave for a bit)
<StevenK> pitti: Happy to upload the patch, just wanted you to check it first.
<nxvl> pitti: around?
<Wubbbi> mvo: I have added you as a Subscriber for the bug 249850 ... is that ok? :)
<ubottu> Launchpad bug 249850 in synaptic "Synaptic Freez up after installing Packages" [Undecided,New] https://launchpad.net/bugs/249850
<pitti> hi nxvl
<seb128> where is scott when you need him ;-)
<fabbione> hey guys
<fabbione> how is life in Ubuntu land?
 * pitti hugs fabbione
<pitti> Padre!
 * fabbione hugs pitti 
<seb128> hey fabbione, good!
<pitti> very intrepid
<fabbione> seb128: hey Mr. Gnome :)
<fabbione> pitti: ehehe
 * fabbione grrrrs at linux-libc-dev
<pitti> superm1: does hal need a fix in bug 189814?
<ubottu> Launchpad bug 189814 in libsmbios "HAL lockups/crashes on Dell D-series Latitudes w/ BIOS password" [Medium,In progress] https://launchpad.net/bugs/189814
<pitti> bryce, tjaalton: WDYT about http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=commit;h=66fb253082ea42179180303393e48846208987fa ? I think that makes sense, although it was reverted again upstream
<tseliot> mvo: please ping me when you want to solve the problem with Update Manager and the NVIDIA drivers in Intrepid. There's a Python module ready for this.
<mvo> tseliot: lets do it now, where can I see the python module? do we have a bugnumber or something as a reference?
<tseliot> mvo: install nvidia-common from this PPA: https://launchpad.net/~lrm-intrepid/+archive
 * tseliot looks for the bugreport
<tseliot> mvo: maybe this one: https://bugs.edge.launchpad.net/ubuntu/+source/update-manager/+bug/249329
<ubottu> Launchpad bug 249329 in update-manager "Intrepid dist-upgrade fails - 'nvidia-glx' is marked for removal but it's in the removal blacklist" [High,Triaged]
<mvo> tseliot: NvidiaDetector ?
<tseliot> mvo: yes
<tseliot> ï»¿mvo: it detects drivers with an old name scheme (e.g. nvidia-glx, -new, etc.), does hardware detection and returns the name of the driver to install
<mvo> tseliot: ok, so the old names go away complettely?
<tseliot> ï»¿mvo: yes, there are only nvidia-glx-177, ï»¿nvidia-glx-173, ï»¿nvidia-glx-96, ï»¿nvidia-glx-71
<mvo> tseliot: ok, excellent
<tseliot> mvo: you might have to change your blacklist too
<mvo> tseliot: I start with removing the old names from the removal blacklist
<mvo> tseliot: is there any package level (via transitional packages or anything like this) transition going on for the hardy->intrepid upgrade?
<pitti> tseliot: I'll try and adapt the jockey nvidia handler for the new packages today/tomorrow
<tseliot> ï»¿pitti: great, let me know if you need help with Jockey
<pitti> tseliot: the -modalias packages have the package names now? If so, then this should be straightforward (takes some programming, though)
<tseliot> ï»¿mvo: no, since supported hardware has changed too much. This is why we rely on both the Debconf warning in nvidia-common and on Update Manager to select and install the right driver for the card.
<tseliot> ï»¿pitti: yes, they do
<tseliot> mvo: if you read here: http://albertomilone.com/wordpress/?p=212 where it says "How does nvidia-common work?" you will see how the Debconf check will work if users decide to dist-upgrade from the command line instead of using Update Manager
<mvo> tseliot: ok. when do you think will nvidia-common arrive in the archive? I need to build-dep on it than because the release-upgrader will have to ship a copy of the dection code
<tseliot> mvo: I don't have upload privileges. I think nvidia-common is ready though
<tseliot> pitti: thoughts on this?
<mvo> its a new package so it has to go through pitti review anyway :) (or mathiases)
<pitti> tseliot: last time I looked at it it was fairly ok (see my email response); I didn't test it personlly , though
<pitti> but since this is blocking both of you now, I'll review/upload/NEW it right now
<pitti> tseliot: lrm-intrepid PPA?
<tseliot> pitti: yes, it's there
<pitti> Show files  nvidia-common - 0.1-0ubuntu12  ?
<pitti> tseliot: hm, I guess I can just check it out of bzr somewhere?
<tseliot> pitti: you can get the latest (ubuntu12). I haven't set up a bzr branch yet
<pitti> ok, fine
<pitti> tseliot: hm, the diff.gz has patches, how weird :)
<pitti> tseliot: I guess it should be pretty much a native package for now
<pitti> tseliot: can I give you some review comments right here, or do you want an email?
<tseliot> mvo: it will be sufficient to make an object of the NvidiaDetection class without any parameter. This should return either None (if no compatible driver can be found) or the name of the appropriate package
<tseliot> ï»¿pitti: maybe an email would be better. Thanks
<mvo> tseliot: I just looked at it, does it require stuff in /usr/share/jockey/modaliases/ that is not yet in intrepid? for me that dir does not contain a lot (but my intrepid is not fully up-to-date)
<tseliot> ï»¿mvo: if you install nvidia-common and its dependencies (which are currently in multiverse in Intrepid) then it will be ok
<mvo> tseliot: basicly I need to ship those files that are required in update-manager as well, because the upgrader can not relie on stuff from intrepid package, it needs to ship the data on its own
<jmunro> is this the right channel to look for ubuntu packaging advice/support?
<tseliot> ï»¿mvo: can't we ship those 3 small packages with the CD (when they are moved to main)?
<joaopinto> jmunro, #ubuntu-moty is probably a better place
<joaopinto> ops, motu
<tseliot> mvo: nvidia-{177|173|96|71}-modaliases are very small
<jmunro> thanks joaopinto
<mvo> tseliot: when the upgrader runs, its runs on hardy (ether net or cd) - its fine to have the three files included if they are small, that is no issue.
<tseliot> mvo: but the modaliases will change every time the drivers are updated
<seb128> slangasek: hey, could you have a look to bug #235560 and tell me if you think that's a samba issue?
<ubottu> Launchpad bug 235560 in nautilus "Connect to smb server by name doesn't work, but by IP address does" [Medium,New] https://launchpad.net/bugs/235560
<tseliot> ï»¿mvo: furthermore, as pitti said, the lists of the supported hardware may be different on 32 and 64bit
<pitti> ^ I don't know whether this is actually ture
<pitti> true
<mvo> tseliot: oh, they are not arch=all ..... hmmm
<pitti> or was just a red herring from our hackish way to extract the vendor/model lists from the X driver binaries
<tseliot> ï»¿pitti: we can't control what NVIDIA and AMD do ;)
<mvo> tseliot: could you check if the lists are the same? if they are, then I have a lot less problems, if they are not, than I need to ponder about this problem a bit more
 * tseliot checks the modalias files
<mvo> tseliot: thanks
<tseliot> mvo: for nvidia-glx-173 the files are identical
<pitti> tseliot, mvo: package reviewed, I mailed you
<pitti> I wouldn't like to upload it right now, but after fixing the list it should be good
<pitti> should not take more than an hour to fix it up
<tseliot> pitti: great, I'll have a look at it as soon as it arrives
 * pitti hugs tseliot for his outstanding owrk
 * tseliot blushes
<pitti> tseliot: I'm just a little more picky about this, since it will go into main
<pitti> (well, I'd list the bugs for any universe package, too, but for NEWing I mean)
<tseliot> ï»¿pitti: feel free to be as picky as you like with me ;)
<tseliot> ï»¿ï»¿pitti: I'll make sure the package is suitable for inclusion in main
 * pitti chuckles about the new LP UI -- "bragging rights"
<mvo> tseliot, pitti: will the modaliases packages move to restricted at some point (instead of multiverse)?
<tseliot> mvo: the modaliases are identical for 177 too. Ok, there is no difference between 64 and 32 bit in the modaliases
<pitti> mvo: yes, absolutely
<pitti> mvo: the drivers themselves, too
<pitti> mvo: I need the modalias lists as jockey Recommends: as well
<mvo> tseliot: excellent, thanks for confirming
<mvo> how often will the nvidia drivers be updated after the intrepid release (in -updates)? if that is going to happen very infrequently I will just build-dep on the modaliases files in update-manager and copy them into the release-upgrader tarball. if it does happen a lot, then a more flexible aproach is needed
<tseliot> ï»¿mvo: updates will be done as backports from Intrepid+1 to Intrepid therefore there shouldn't be problems with Update Manager
<tseliot> mvo: we won't do SRUs as we're doing for Hardy in multiverse
<mvo> tseliot: ok, I go with the build-dep approach then
<tseliot> mvo: ok
<pitti> tseliot: oh, we won't? I thought we'd at least add new driver versions post-release, much similar to what the -envy packages do in hardy right now?
<pitti> mvo: can the upgrader download the files from somewhere else prior to starting the upgrade? doesn't it already download a blob?
<tseliot> ï»¿pitti: with -envy there's a certain amount of risk but you still have the packages in the lrm. In intrepid we should still have something stable which doesn't change, I guess.
<pitti> tseliot: I agree, but adding newer versions (e. g. as intrepid+1 -> intrepid backports) should be ok?
<tseliot> ï»¿pitti: and maybe the backports will keep happy the ones who want the latest driver
<pitti> like, nvidia-192 backported to intrepid
<tseliot> ï»¿pitti: ah, adding a completely new package, you mean. I wouldn't know
<tseliot> pitti: if you think that using -updates is better, I'm with you on this
<pitti> -backports or -updates doesn't matter much, as long as jockey/envy can pick it up
<tseliot> ï»¿pitti: they don't matter much to me since I'm going to make the packages anyway ;)
<mvo> pitti: sure, it could do that too, it will just add more waiting and more stress the mirrors. downloading stuff is fragile in release times, the mirrors are all very loaded. if it has no (or hardly none) disadvantages I would rather want to have it included
<pitti> mvo: *nod*
<pitti> I was just curious
<tseliot> ï»¿mvo: another thing. Maybe reinstalling libgl1-mesa-glx and xserver-xorg-core (before doing the dist-upgrade) could help if users made use of the NVIDIA installer from NVIDIA's website. See this problem which I solved: https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-177/+bug/250486
<ubottu> Launchpad bug 250486 in nvidia-graphics-drivers-177 "package nvidia-glx-177 None [modified: /var/lib/dpkg/info/nvidia-glx-177.list] failed to install/upgrade: trying to overwrite `/usr/lib/xorg/modules/extensions/libglx.so', which is also in package xserver-xorg-core" [Undecided,Invalid]
<mvo> tseliot: could you please make the nvidia-common stuff available via bzr? I would like to make some (small) modification to it to make it easier for me to embed it
<tseliot> ï»¿mvo: sure
<mvo> what is the reason that we have 4 modaliases package? would it be possible to have them in a sinle package? or have a meta-package that depends on all available ones so that in the future I don't need to manually update the build-depends on them?
<pitti> tricky
<pitti> mvo, tseliot: what about adding all of them to nvidia-common?
<mvo> sounds good to me
<pitti> that makes sense anyway, and then you can just b-dep on n-common
<pitti> hm, hang on
<pitti> can we b-dep on them in the first place? they'll be in restricted
<pitti> main -> restricted dependencies -> evil
<tseliot> ï»¿mvo: 4 modaliases packages are made when the 4 drivers are built
 * mvo nods
<tseliot> ï»¿pitti,mvo: I'm afraid I don't understand your suggestion
<pitti> packages in main can only depend and b-dep on main packages
<mvo> its not terrible important, it would just be nice. as long as someone reminds me when new modaliases packages become available to update the build-depends in update-manager
<pitti> mvo: but that doesn't work either way
<pitti> if we want to do that at all, then the least evil thing (IMHO) we can do is to have the -modalias packages in main and the rest in restricted
<pitti> 'source in restricted' and 'one binary of it in main' is against the common practice, too, but less evil than b-depending on restricted packages
<pitti> cjwatson: WDYT?
<mvo> pitti: meh, right
<cjwatson> pitti: (I'm off sick today, but happened to be looking) we already do that with linux-meta
<mvo> cjwatson: the plague?
<cjwatson> it's not without problems, but can be done with care
<cjwatson> mvo: aye
<mvo> cjwatson: get well! it hit me fully with >39Â°C over the weekend
<cjwatson> I think I had the worst of it last night, but will be sleeping the rest off today
<Mithrandir> canonical has reinstated the distro plague?
<pitti> cjwatson: oh, sorry for bothering; get well soon!
<Mithrandir> or rather, distro sprint plague.
<seb128> anybody around having a clue about libtool who could look to the error on http://paste.ubuntu.com/29259?
<pitti> it hit Pedro, then Michael, then Colin; noone else so far, AFAICS
<seb128> that's gnome-system-monitor which doesn't want to build using libtool2, not sure what to change though
<tseliot> mvo: my bazaar branch is here. NOTE: it doesn't contain the correction which pitti suggested and the branch has not been scanned yet
<Mithrandir> seb128: it's C++ and doesn't have a AC_PROG_CXX before the libtool macros?
<tseliot> mvo: https://launchpad.net/nvidia-common
<seb128> Mithrandir: I did add
<seb128> "
<seb128>     AC_PROG_CXX
<seb128>     AC_PROG_LIBTOOL"
<seb128> Mithrandir: but that makes no difference
<Mithrandir> seb128: and reran aclocal and auto*?
<seb128> libtoolize -c -f && autoconf && aclocal
<Mithrandir> that's the wrong order; aclocal; automake; autoconf
<Mithrandir> s/;/:/
<seb128> is automake required there?
<Mithrandir> hm, no, it shouldn't be.
<pitti> maybe just autoreconf -f?
<Mithrandir> anyway, aclocal before autoconf
<seb128> it gives http://paste.ubuntu.com/29261/ now
<jcristau> seb128: missing AC_PROG_CC?
<seb128> jcristau: is AC_PROG_CC required if I'm already using AC_PROG_CXX?
<jcristau> seb128: if you want to build c stuff, not just c++, i'd say yes
<seb128> doesn't seem to make a difference
<seb128> I hate autotools ;-)
<Mithrandir> seb128: this is libtool's way of loving you back.
<mvo> tseliot: please check bzr+ssh://bazaar.launchpad.net/%7Emvo/nvidia-common/mvo/ for some smallish additions
<cjwatson> order> use autoreconf
<seb128> cjwatson: doesn't make a difference, I think the configure.in needs some other changes
<seb128> where is scott? ;-)
<seb128> ups, in fact no, autoreconf -v -f works
<seb128> cjwatson: thanks
<tseliot> mvo: ok, thanks. It looks good and you also corrected a typo.
<cjwatson> seb128: get in the queue, I mailed Scott about a new (different) libtool problem yesterday ;-)
<mvo> tseliot: how is the interface supposed to be used? I call selectDriver() to get the one that I am supposed to use? and getDriver() to see what is currently installed (and should be removed)?
<mvo> tseliot: thanks for reviewing my changes
<AlexCONRAD> hello, I'm trying to figure out how I can make glxinfo not to display "client glx vendor string: SGI". I'm trying to benefit of Adobe Flash 9 hardware acceleration in full screen.
<tseliot> ï»¿mvo: just create an object and see what it returns (without calling any method)
<AlexCONRAD> from the Adobe Flash linux team: the Flash Player requires that the client glx vendor string be something besides "SGI". Official drivers from, e.g., ATI and Nvidia hopefully do not have "SGI" in this field (check the 'glxinfo' command, for this string and for the extensions listed above)
<laga> these guys must be smoking weird stuff.
<Kano> patch mesa ;)
<AlexCONRAD> installing propietary drivers from ati (or from the restricted drivers in xubuntu), I still get SGI
<tseliot> ï»¿AlexCONRAD: if you file a bugreport on launchpad I'll have a look at it later
<AlexCONRAD> here's Adobe's blog regarding this issue: http://blogs.adobe.com/penguin.swf/2008/05/flash_uses_the_gpu.html
<tseliot> mvo: if doing so seems weird to you I can change it
<mvo> tseliot: I would prefer something that I call from within python, maybe a @property like driverpkg or drivername ?
<mvo> tseliot: it looks like "selectDriver()" does that, correct?
<tseliot> mvo: yes, that's what you need
<AlexCONRAD> tseliot: I'm doing a bug report right now. Should I provide a specific package?
<tseliot> ï»¿AlexCONRAD: linux-restricted-modules
<AlexCONRAD> ok
<laga> can someone recommend a log rotation tool? like logrotate, but less broken (eg runs more then once each day)
<mvo> tseliot: ok, I think then I have all the bits in place now in the code, the outstanding issue is only "main"<->"restirected" barrier
<tseliot> ï»¿mvo: ok, I'll apply your corrections (and pitti's) and push them into my branch soon
<pitti> mvo: I think I'll move the -modalias packages to main
<pitti> mvo, tseliot: so I think that nvidia-common should depen: on the modalias packages, and u-m should b-dep on n-common; ok with you?
 * pitti cnat tpye toady
<mvo> pitti: that sounds excellent
<tseliot> ï»¿pitti: ok
 * mvo hugs pitti and tseliot
 * pitti bounces
 * tseliot hugs pitti and mvo
<mvo> tseliot: I also need a way to figure out if a old nvidia driver was installed before the upgrade (I don't want to transition people without the binary driver to a binary driver on pgrades). I will just use the oldPackages list for this in getDrivers, does that sound reasonable?
<tseliot> ï»¿mvo: what do you mean? If a driver with an old scheme was installed, selectDriver() will return None. Maybe I'm missing the point
<mvo> tseliot: oh? maybe I haven't got the interface yet :) on upgrade from hardy->intrepid I want to know a) is a nvidia binary driver installed. if so, then I want to install a new nvidia driver with the new naming schema
<mvo> tseliot: it looks like "printSelection" is doing that, correct?
<jcristau> it's amazing how much work you guys put into supporting those broken drivers
<tseliot> ï»¿mvo: getDrivers() returns True if an old driver was installed
<tseliot> ï»¿jcristau: I'm convinced that our users should have the best experience with Ubuntu even though this is not extremely easy with proprietary drivers
<tseliot> mvo: ï»¿printSelection() is thought only to interact with bash/debconf
<laga> regarding upstart - will upstart be used more widely in intrepid? eg in mysql and other stuff in main?
<mvo> jcristau: true
<jcristau> (by amazing i mean sad)
<Wubbbi> jcristau: why sad? oO ... lol thats good not sad
<Mithrandir> jcristau: too many people need them. :-/
<mvo> tseliot: could you please merge again from my tree? this gives me access to oldPackages and then I can check the install status in my code slightly more efficiently
<Wubbbi> Mithrandir: like me :D
<Mithrandir> Wubbbi: you're happy you need crappy non-free drivers?
<jcristau> Mithrandir: sometimes i wonder if the same amount of work put into improving free drivers wouldn't be a better use of everyone's time
<Wubbbi> I mean if where is a Free Nvidia driver, which can 3D like the Nvidia one, I will use the free. But now The Nvidia Driver is simpy the best ^^
<Mithrandir> jcristau: long-term I'm fairly sure it'd be, but short term less so.
<Mithrandir> jcristau: it'd be nice if 8.10 could ship nouveau though..
<Mithrandir> it's bloody stable for me.
<pitti> would anyone have time to try out my first pre-alpha-test version of my guest session script? (http://people.ubuntu.com/~pitti/tmp/guest-session.py, run with sudo)
<Wubbbi> Mithrandir: no I'm not happy. But I need it.
<tseliot> ï»¿mvo: sorry if it sounds noobish but having always worked by myself I don't know how to merge branches in bzr
<Wubbbi> I also hate OpenOffice, but I need it for work :(
<mvo> tseliot: no problem, just run "bzr merge bzr+ssh://bazaar.launchpad.net/~mvo/nvidia-common/mvo/"
<Wubbbi> I Like Koffice or Goffice more
<pitti> tseliot, mvo: s/bzr+ssh/http/
<pitti> actually, just "lp:~mvo/nvidia-common/mvo" should do
<pitti> bryce, tjaalton: I heard some rumours that the X server sends out a signal of some kind once it's started up and clients can connect to it; do you know details about that?
<tseliot> mvo: ok, merged. pitti: yes, using http did the trick
<pitti> tseliot: (explanation: bzr+ssh:// is write access, and you can't write to a branch owned by mvo)
<tseliot> ï»¿pitti: ah, ok, it makes sense now. Thanks
<cjwatson> you can use bzr+ssh: for read access too nowadays
<tseliot> cjwatson: doing so gave me this error: Permission denied (publickey).
<tseliot> bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required)
<cjwatson> <cjwatson@sarantium ~>$ bzr get bzr+ssh://bazaar.launchpad.net/~mvo/nvidia-common/mvo/
<cjwatson> Branched 4 revision(s).
<mvo> tseliot: great, you bzr pushed  as well? I will do some final testing after lunch and then I think the branch is ready
<pitti> cjwatson: oh, neat
<pitti> cjwatson: so I guess "lp:" is nothing more than a string subst for bzr+ssh://code.launchpad.net/ nowadays
<jcristau> pitti: the server looks if the sigusr1 handler is set to sig_ign when it starts. if so, it sends sigusr1 to its parent after init
<tseliot> ï»¿mvo: pushed now
<cjwatson> tseliot: that suggests that you don't have ssh configured to use your LP username when sshing to bazaar.launchpad.net. bzr+ssh://albertomilone@bazaar... would have done it
<pitti> jcristau: nice, thanks!
<cjwatson> tseliot: but it's easier to put this in ~/.ssh/config and then you can forget about it for ever more:
<cjwatson> Host bazaar.launchpad.net
<cjwatson>         User albertomilone
<tseliot> cjwatson: thanks a lot :-)
<mvo> tseliot: thanks, I have it now
<tseliot> pitti,mvo: I'm going to have a break for lunch now, therefore, unless you've got something urgent to tell me, I'll go now
 * tseliot >> lunch
<emgent> moin
<AlexCONRAD> tseliot: https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules/+bug/250792
<ubottu> Launchpad bug 250792 in linux-restricted-modules "Adobe Flash hardware acceleration support (GPU)" [Undecided,New]
<mvo> tseliot: could you please merge again from my branch when you come back?
 * mvo -> lunch
<pitti> seb128: do you have a minute to give a test to my guest session script?
<seb128> pitti: yes
<pitti> seb128: http://people.ubuntu.com/~pitti/tmp/guest-session.py
<pitti> seb128: just running it from your normal session through sudo should work
<pitti> it starts the guest session, and as soon as you leave it, it returns back to your's
<pitti> it doesn't lock screen yet or anything, just barely sets it up
<pitti> PolicyKit, mounting, network-manager etc. should work already
<seb128> pitti: is that likely to crash my xsession?
<pitti> seb128: no, your own should be fine
<pitti> it's possible that the guest session crashes, though
<seb128> alright, trying
<seb128_> re
<seb128_> I knew it would crash my box :-p
<seb128_> hum, brb
<seb128> re
<pitti> seb128: ugh, sorry for that; any idea when/how?
<seb128> I would tend to blame VT switch
<pitti> seb128: oh, compiz?
<pitti> what did you see so far? it just crashed immediately?
<seb128> so it loged me in the guest session after some seconds
<seb128> the session is usable
<seb128> switching user doesn't work though, can't find Xauthority
<seb128> the sound card is not available
<seb128> and it froze when I tried to log out
<pitti> in the guest session?
<pitti> the script outputs some debug info, but I guess you didn't see that any more
<pitti> it also leaves a debug log in /tmp/guest_*
<pitti> .Xauthority? weird, that file should be there; without it, you can't even start the session
<pitti> seb128: does a normal gdmflexiserver work for you?
<seb128> pitti: tried to use the fusa to switch to your normal user?
<pitti> seb128: no, I didn't try that yet; sec, doing
<seb128> pitti: "work" in which way? do you mean "does it crash your box on logout too"?
<pitti> seb128: fusa doesn't work for me either, thanks for pointing out
<pitti> seb128: well, yes; "work" in the sense of "starts a new session, session runs normally, and you can stop it, and switch"
<tseliot> mvo: merged and pushed again
<seb128> pitti: let me switch IRC to my laptop
 * tseliot shuts down his computer. A storm is coming
<seb128> pitti: alright, the box crashes the same way when closing a gdmflexiserver session
<Riddell> bash question, what does the @ mean at the start of this?  @if [ ! -x "$(DH_SAMEVERSIONDEPS)" ]; then chmod a+x "$(DH_SAMEVERSIONDEPS)"; fi;
<pitti> Riddell: is that Make?
<jcristau> sounds like a make question
<Riddell> pitti: yes
<StevenK> Riddell: That's Make. "Don't echo the line before running it"
<Riddell> doesn't sound too important then, thanks.
<pitti> seb128: I see; maybe you can try disabling compiz?
<pitti> (did you get compiz in the guest?)
<seb128> you think it's due to compiz? I'm not sure now but I don't think compiz works out of the first session, xorg limitation
<seb128> no I didn't anyway, that's intrepid and gnome-session doesn't default to compiz
<pitti> ah, ok
<pitti> hm, no idea then, I'm afraid
<pitti> if it happens even with gdmflexiserver, it's beyond my current knowledge :(
<seb128> the syslog has a general protection error in wacom_drv.so and then the restart
<seb128> and I couldn't ssh to the box after the crash either so it seems linux didn't like it
<sistpoty|work> hm... current daily gives me read errors from the iso when simulating in faumachine... has anyone observed this on a real box?
<tseliot> I'm back
<tseliot> AlexCONRAD: what's the bugreport which you filed?
<AlexCONRAD> tseliot: let me find it again
<AlexCONRAD> tseliot: https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules/+bug/250792
<ubottu> Launchpad bug 250792 in linux-restricted-modules "Adobe Flash hardware acceleration support (GPU)" [Undecided,New]
<tseliot> ï»¿AlexCONRAD: ok, thanks
<superm1> pitti, yes it does
<superm1> both hal and libsmbios
<pitti> re
<mvo> tseliot: I finished my changes in a bzr branch of update-manager now, please prod me when the new nvidia-common is available in the archive, I merge the changes into mainline then. thanks for your work on this!
<pitti> seb128: ok, thanks for testing so far!
 * pitti hugs seb128, sorry for the trouble
<tseliot> ï»¿mvo: thanks to you ;)
<tseliot> mvo: I'll ping you as soon as it's done
 * seb128 hugs pitti, you're welcome
<seb128> pitti: I'll try on my laptop a bit later, but I'm building gtk+ now and don't want to crash the box
<Riddell> grr, cdbs has gained a new dependency in universe
<pitti> seb128: right, by any means
<pitti> Riddell: hm? it didn't change for a long time?
<pitti> Depends: debhelper (>= 5.0.30), fdupes, intltool
<pitti> looks fine to me...
<Riddell> pitti: build dependency
<Riddell> dvipdfmx
<Riddell> needed by texlive-xetex
<pitti> right, that; there's a MIR for it
<hwilde> Mail In Rebate?
<pitti> Main Inclusion Request
<ogra> Monk In Rage
<mathiaz> zul: could you merge samba 3.2.0-4 from debian ? It's an important fixe
<jcristau> mathiaz: you mean like https://lists.ubuntu.com/archives/intrepid-changes/2008-July/003931.html?
<ogra> mathiaz, you should really subscribe to intrepid-changes
<mathiaz> well - I'm just processing my inbox in chronological order
<zul> mathiaz: already done
<mathiaz> zul: are you subscribed to the pkg-samba-maint mailing list ?
<zul> mathiaz: yep and slangasek told me last night as well
<pitti> superm1: did you send the libsmbios patch upstream somewhere?
<superm1> pitti, yeah its in upstream git already
<superm1> i listed the link on the bug report
<superm1> mebrown will be doing a libsmbios release in the next week to two weeks, so i'll submit the hal patch upstream once there is a new libsmbios "release" for hal to depend on
<pitti> superm1: ah, great; I'm uploading it now
<superm1> pitti, great thanks
<superm1> you might consider if you can cross pocket copy, i've already got them built on the ppa
<superm1> i wasnt sure if you could cross pocket copy to proposed from a ppa though
 * pitti runs the missing update-maintainer first
<pitti> superm1: I'd rather not, component handling sucks with copy-package from a PPA
<superm1> pitti, ah okay
 * soren kicks the useless rc.local prompt on initscripts upgrades
<pitti> soren: bug 246550
<ubottu> Launchpad bug 246550 in sysvinit "Prompts to merge unmodified conffile /etc/rc.local on upgrade to intrepid" [Undecided,In progress] https://launchpad.net/bugs/246550
<soren> I know.
 * soren is testing a patch for it.
<soren> Whuh.... Is apt-get not installed by debootstrap in Intrepid anymore?
<pitti> that would be weird
<soren> It would, wouldn't it?
<soren> Maybe it's my mk-sbuild-chroot script that's misbehaving. :/
<superm1> soren, try to rerun /finish.sh in the schroot then perhaps
 * soren can't spot apt in debootstrap's output..
<soren> superm1: finish.sh installs additional packages /using/ apt-get :)
<superm1> oh right :)
<soren> Task: minimal, minimal
<soren> Looks like fun :)
<slangasek> seb128: hum, that certainly could be a samba issue, but it's not one that I've encountered; that's kind of an opaque error message, in any case
<soren> Oh, apt is no longer build-essential.
<soren> Is that intentional?
<slangasek> seb128: any chance they're running the aborted hardy-proposed version of gvfs?
<seb128> slangasek: did you read the current comment on the bug? and they could, but there is a new upstream version available in hardy-proposed for some time now so that's not really likely
<seb128> grrr new libtool
<slangasek> seb128: oh.  that's a "wtf, don't do that" bug.
<slangasek> seb128: hang on, I have a Debian bug # for that somewhere
<seb128> slangasek: ah, thanks
<slangasek> seb128: Debian bug #459972
<ubottu> Debian bug 459972 in winbind "winbind: want to limit libnss_wins checks to WINS (no broadcasting)" [Wishlist,Open] http://bugs.debian.org/459972
<seb128> slangasek: thanks, will you add a comment on the bug and reassign to the proper place? ;-)
<slangasek> seb128: summary: a) using wins for hosts is not the common case, b) if you do you have to set up your smb.conf to not cause recursion, c) use DNS already, it's 2008
<slangasek> heh, when I come on shift, yes :)
<seb128> no hurry ;-)
<soren> Er.. how do I in bzr show the contents of a file as per revision X?
<soren> Oh, bzr cat.
<soren> cjwatson: apt doesn't get marked as build-essential anymore (see http://archive.ubuntu.com/ubuntu/dists/intrepid/main/binary-amd64/Packages.gz).. Germinate bug?
<soren> The seed looks fine: http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/platform.intrepid/annotate/1223?file_id=buildessential-20070623200333-d1ogpjgj3twv53i0-2
<cody-somerville> What does reason "none" mean for a reject? :P
<soren> cody-somerville: I /think/ it means that whoever rejected it didn't bother to state a reason. Usually that means that they've sent you a separate e-mail about it or pung you on IRC.
<cjwatson> I don't believe that the tools allow stating a reason right now, at least not the command-line tools
<soren> Oh.
<cody-somerville> How do I find out who rejected codeblocks?
<slangasek> brute-forcing the list of possible culprits :)
<slangasek> (wasn't me!)
<cjwatson> soren: somebody pushed it up to required, and it's listed in http://people.ubuntu.com/~ubuntu-archive/priority-mismatches.txt
<ogra> cjwatson, fyi the discussed changes to apply different partition sizes on the 4G cmpc are in the recent image
<cjwatson> but apparently by adding a dependency somewhere else - oh, possibly by Recommends
<pitti> superm1: so, all done (hardy+intrepid libsmbios+hal), bug updated; testing feedback appreciated!
<cjwatson> ogra: thanks
<cjwatson> soren: germinate recently got upgraded on drescher/mawson, so I expect it's a consequence of newly-handled Recommends there
<soren> cjwatson: Oh, and then germinate removes it from build-essential so that it'd only get listed once?
<cjwatson> right, build-essential inherits from required
<soren> Ok, got it.
<cjwatson> the fix is either for an archive admin to promote it to required, or for the recommends to be dropped to <=suggests, or for germinate not to consider recommends in the required seed
<soren> Ok, I'll hand-hold debootstrap --variant=buildd for now..
<cjwatson> can it wait until tomorrow? technically I'm off sick today
<soren> cjwatson: Oh, sure, sure.
<soren> go back to bed. :)
<pitti> soren: thanks for the sysvinit fix!
<pitti> Riddell: can you please commit your cdbs changes to lp:~ubuntu-core-dev/cdbs/ubuntu/ ?
<tseliot> pitti,mvo: I have applied the corrections and pushed them into my main branch
<slangasek> seb128: are you managing this scrollkeeper->rarian switch?
<Riddell> pitti: oh right sorry, forgot about that
<Riddell> BenC: bug 250848 for you
<ubottu> Launchpad bug 250848 in grub "grub fails to install" [Undecided,New] https://launchpad.net/bugs/250848
<slangasek> seb128: livefs build failure because rarian-compat conflicts with scrollkeeper; I guess scrollkeeper is still seeded?
<BenC> Riddell: ok
<slangasek> hmm, apparently not seeded
<slangasek> BenC: when you fix grub, please mind to commit to the bzr branch :)
<seb128> slangasek: I'm not aware of anything to manage for the scrollkeeper to rarian change
<slangasek> seb128: ok, well, something's breaking the livefs builds :)
<seb128> do you have details on the error?
<slangasek> The following packages have unmet dependencies:
<slangasek>   rarian-compat: Conflicts: scrollkeeper
<slangasek> E: Broken packages
<slangasek> that's all the log shows; I can't reproduce it in a clean chroot using only 'apt-get install ubuntu-desktop', so the root cause is somewhere deeper
<seb128> slangasek: maybe something in the CD build script?
<soren> pitti: Sure :)
<seb128> slangasek: note that rarian-compat conflicts,replaces,provides scrollkeeper
<slangasek> seb128: nothing is left that has a versioned dep on scrollkeeper?
<seb128> not that I know
<seb128> and ubuntu-desktop and rarian-compat are installed on my machines
<slangasek> trying to install 'apt-get install ubuntu-live^' in a chroot, doesn't give me any errors either
<slangasek> and that's what the livecd does
<slangasek> (plus bits)
<seb128> slangasek: when did you run this cd build?
<BenC> Riddell: in what situation is this bug occuring?
<pitti> I just checked with grep-dctrl, no versioned dpeendendies to scrollkeeper in main
<Riddell> BenC: creating the livefs
<Riddell> BenC: also in my chroot just installing grub
<slangasek> BenC: I think that kernel-helper -i shouldn't be called in the postinst when [ -z "$2" ]
<slangasek> but maybe there are some reasons you'd want to call it on first install
<BenC> Riddell: That's what I thought....how can I detect this situation...or do you think I can just ignore the fact that it doesn't exist?
<seb128> slangasek: so, the CD build try was today?
<slangasek> seb128: yes, and also yesterday
<seb128> slangasek: yesterday rarian-compat was in universe
<slangasek> then perhaps it gave a different error yesterday :)
<seb128> cjwatson mentionned moving it back to main again
<pitti> but that was this (late) morning
<seb128> no idea about today's issue though, works fine for me on my machines
<pitti> later than the CD cron jobs
<slangasek> pitti: I just did another buildlive run to check, though
<pitti> ah, ok
<pitti> tseliot: so nvidia-common is in bzr now? or will you upload to ppa again?
<tseliot> pitti: it's in my bzr. I'll upload it to my PPA now
<pitti> tseliot: I'm happy to pull from your bzr, that's faster, especially for future updates
<tseliot> pitti: perfect. Let's use bzr then
<pitti> tseliot: lp:what?
<cjwatson> seb128: I moved it yesterday IIRC
<cjwatson> pitti: this morning> I think you're mixed up, I'm sure it was yesterday
<cjwatson> slangasek: try 'apt-get install ubuntu-desktop^' rather than ubuntu-desktop
<cjwatson> Package: scrollkeeper
<cjwatson> Task: ubuntu-desktop, edubuntu-desktop, edubuntu-desktop-kde, xubuntu-desktop
<cjwatson> that can't be helping
<tseliot> pitti: lp:nvidia-common
<slangasek> cjwatson: aha, bingo
<slangasek> cjwatson: so that needs an ubuntu-meta upload to fix?
<slangasek> (et al.)
<cjwatson> I thought there'd already been one
<ogra> how does edubuntu-desktop-kde ge in there ?
<ogra> *get
<cjwatson> never mind that for now :)
<cjwatson> slangasek: germinate on drescher claims it's directly seeded
<Riddell> BenC: moi?  if I knew how to fix it I wouldn't be bugging you :)
<slangasek> cjwatson: hrm
<slangasek> cjwatson: not since the 17th
<cjwatson> as does http://people.ubuntu.com/~ubuntu-archive/germinate-output/ubuntu.intrepid/desktop
<slangasek> things are failing to see the seed updates?
<pitti> nothing in my seed grep any more, hmm
<cjwatson> yeah, http://people.ubuntu.com/~ubuntu-archive/seeds/ubuntu.intrepid/ is stuck
<cjwatson> investigating
<cjwatson> stuck on a lock
 * BenC is uploading a new grub now
<BenC> slangasek: last I tried, I couldn't commit to grub bzr...
<slangasek> BenC: what was the error?  There was a bzr bug shortly before the hardy release that might've prevented it at that time, but it's been working fine for me
<slangasek> (ever since, I mean)
<pitti> tseliot: please commit back the COPYING file
<pitti> tseliot: it's necessary to have a full copy of the license in the source tarball
<pitti> tseliot: (it was there before)
<cjwatson> moreover, stuck on a nonexistent lock. WTF
<lukehasnoname> Hey slangasek, I you're the maintainer for acpi-support? Is Bug 59695 going to be fixed for intrepid, and how? If you can link me to this question being answered, that's cool, but I haven't seen anything on the wiki.
<ubottu> Launchpad bug 59695 in dell "High frequency of load/unload cycles on some hard disks may shorten lifetime" [Undecided,Confirmed] https://launchpad.net/bugs/59695
<slangasek> lukehasnoname: Ubuntu doesn't have individual package maintainers; I've touched acpi-support a couple of times for specific reasons, but it's not my area of responsibility
<tseliot> pitti: ? http://bazaar.launchpad.net/~albertomilone/nvidia-common/main/files
<tseliot> pitti: it's there
<pitti> tseliot: argh, ignore me; I'm retarted
<pitti> retarded, even
<tseliot> pitti: we're all tired, I guess ;)
<lukehasnoname> slangasek: Ya, I knew you aren't the sole maintainer, but I saw your name on the bug list, so I figured you might have info. I should have stated that better. Do you have info? Does anyone?
<slangasek> lukehasnoname: but the load/unload cycle one is very hairy - I didn't think acpi-support was currently to blame for anything in that area
<ogra> seb128, if you actually plan to have a SRU for bug 247507, could you note that on the bug ?
<ubottu> Launchpad bug 247507 in cmpc "Tool bar malfunctions when it's pulled to the right side." [Medium,Fix committed] https://launchpad.net/bugs/247507
<BenC> slangasek: uploaded new grub, but didn't check on bzr yet...IIRC, it was perms (or maybe me just not knowing how)
<ogra> wow, the bugbot isnt the fastest today
<slangasek> BenC: the official branch is in ~ubuntu-core-dev, you should have access to that AFAIK?
<cjwatson> slangasek: I've fixed the stuck lock; should clear through the archive shortly
<slangasek> cjwatson: great, thanks
<slangasek> BenC: bzr push bzr+ssh://bazaar.launchpad.net/~ubuntu-core-dev/grub/ubuntu/ - WFM
<slangasek> BenC: if you were using an http-only url for the pull, you have to change it for the push
<cjwatson> ogra: the edubuntu-desktop-kde entry is due to edubuntu-docs's Depends
<BenC> slangasek: I'll try to update the bzr branch
<slangasek> BenC: thanks
<cjwatson> BenC: it's easiest to just do 'bzr checkout bzr+ssh://...', and then commits will autopush
<BenC> cjwatson: right, that's what I'm used to
<seb128> ogra: would be nice but there is way too much to do for me right now so I doubt I'll work on this change any time soon, trying to catch up on things after 2 weeks travelling, new GNOME this week, hardy updates and intrepid, etc etc etc
<pitti> tkamppeter: any chance you could upload a recent s-c-p snapshot to intrepid soon? I need it for the new jockey
<ogra> seb128, ok, understood ... i dont really know which function i have to patch, else i would do it
<pitti> tseliot, mvo: nvidia-common uploaded and NEWed to main
<tseliot> ï»¿pitti: great :-D
<slangasek> lukehasnoname: so can you point to something specifically in acpi-support that's doing the wrong thing?  That bug log is horrifically long
 * pitti promotes nvidia-graphics-* to restricted
<lukehasnoname> slangasek: ehh lemme look
<pitti> tseliot, mvo: -modaliases promoted to main, other stuff to restricted
<tseliot> pitti: fantastic :-)
<mvo> Riddell: do you know if martin bÃ¶hm would be interessted in some gdebi-kde work again? I would like to talk about using a konsole-less approach with him there too (just like in update-manager)
<mvo> pitti: great, thanks
<pitti> packagekit-kde!! (*cough*)
<mvo> pitti: even that will benefit from that
<tseliot> ï»¿mvo: if you're referring to a KDE4 port of ï»¿gdebi-kde you can use a qProcess and display the output in a textview. I don't know how well would it work with Debconf and other things that require user interaction though
<seb128> ogra: ok, vuntz has a solution for you (you should be on #ubuntu-desktop ;-), they have an opensuse patch that should fix your issue
<Riddell> mvo: I suspect he doesn't want to work on it any more
<Riddell> mvo: but there was someone working on a qt 4 port of it which would have to include that
<mvo> tseliot: yeah, for the kde dist-upgrade we did something like this (but with basic terminal emulation)
<Riddell> mvo: I'm going out now, I'll look it up when i get back
<mvo> Riddell: if you could make him get in touch with me about this, that would be great, I would love to get the simple solution from update-manager
<mvo> Riddell: sure, no rush -and thanks
<tseliot> ï»¿pitti: does packagekit support debconf already?
<pitti> tseliot: no, it doesn't
<pitti> (that's why it's not a general replacement yet)
<tseliot> ï»¿pitti: too bad
<BenC> slangasek: $ bzr co bzr+ssh://ben-collins@bazaar.launchpad.net/~ubuntu-core-dev/grub/ubuntu
<BenC> bzr: ERROR: Repository KnitPackRepository('file:///home/bcollins/ubuntu/.bzr/repository/') is not compatible with repository RemoteRepository(bzr+ssh://ben-collins@bazaar.launchpad.net/%7Eubuntu-core-dev/grub/ubuntu/.bzr/)
<slangasek> hum
<slangasek> what version of bzr is that?
<james_w> I'm guessing that the grub branch is a bzr-svn import.
<BenC> slangasek: latest in intrepid
<james_w> BenC: do you have /home/bcollins/.bzr/repository/ ?
<BenC> james_w: I deleted it though
<BenC> james_w: actually, no, that doesn't exist
<slangasek> james_w: ah, /half/ of it is a bzr-svn import >:)
<james_w> ah yeah, I remember.
<james_w> BenC: does it work if you try in /tmp/ ?
<pitti> mdomsch_YOW: "Year Of Warcraft"? :)
<seb128> asac, pitti: around?
<mario_limonciell> i think YOW is the initials for the airport in ottawa if i'm not mistaken
<seb128> https://bugs.edge.launchpad.net/ubuntu/+source/epiphany-browser/+bug/250763 has been opened today
<pitti> tseliot: that should do: http://bazaar.launchpad.net/~jockey-hackers/jockey/trunk/revision/327 ; I'll have a look at the nivida handler now
<ubottu> Launchpad bug 250763 in epiphany-browser "Epiphany cannot remember passwords nor certficates after a restart" [Low,Triaged]
<pitti> seb128: bonsoir
<seb128> and mpt just had the same issue after upgrading firefox in hardy
<asac> seb128: strange ... i tested passwords here
<mdomsch_YOW> mario_limonciell, bingo
<seb128> asac: bookmarks nuked too for mpt apparently
<pitti> eww
<mpt> I lost bookmarks and history. I don't know whether I would have lost passwords, because I never save passwords.
<pitti> asac: will epiphany-browser | 2.22.2-0ubuntu0.8.04.2 (previous version) work with the new xulrunner?
<pitti> i. e. if we need to pull epy, do we need to pull xulrunner, too?
<asac> it should
<asac> i have it installed here
<seb128> what did you guys pushed to security or updates today?
<pitti> mpt: if you downgrade to the previous epiphany-browser, do you get them back?
<pitti> seb128: firefox, xulrunner, epiphany
<asac> epiphany?
<seb128> so the full combo, hum
<asac> ouch
<seb128> asac: "ouch"?
<asac> i didnt specifically verify that
<pitti> hm, you told me I should?
<seb128> the epiphany change was a one liner to the printing scale code
<asac> pitti: i said multiple times "just ffox/xul"
<seb128> no reason to not
<pitti> uh
<asac> anyway. lets see
<asac> i cannot reproduce password not remembered issues
<pitti> so, we need to test it with the old epy, to see whether it's in epy itself, or in xul
<tseliot> ï»¿pitti: yes, that should work
<seb128> I've several hardy box not upgraded so I can do some testing if you guys want me to test something
<pitti> asac: not password, bookmark
<mpt> pitti, I'd like to try that. How do I downgrade?
<asac> bookmarks are remembered for me now
<pitti> ls /var/cache/apt/archives/epiphany-browser
<pitti> mpt: ^ if you do that, any hits?
<mpt> No such file or directory
<pitti> argh
<pitti> ls /var/cache/apt/archives/epiphany-browser*
<pitti> mpt: forgot the *
<mpt> No such file or directory
<pitti> that's weird; it should have at least the latest one
<seb128> mpt: grep installed /var/log/dpkg.log
<seb128> mpt: what is listed for today?
<mpt> The only things starting with "e" in that directory are evolution*
<tseliot> pitti: I'll have another look at it tomorrow, just to be sure
<pitti> tseliot: I'll get ot it later, seems this epy regression needs full attention now
<mpt> seb128, language packs, firefox-2 stuff, libsoundtouch1c2, and libc6.
<seb128> I don't get why the firefox2 update would impact on xul1.9 applications
<seb128> asac: ^?
<mpt> It could have been just a coincidence
<pitti> mpt: dpkg -l epiphany-browser -> which version does it show?
<mpt> ii  epiphany-brows 2.22.2-0ubuntu Intuitive web browser - dummy package
<pitti> argh, silly dpkg
 * mpt wonders how on earth something can be intuitive and a dummy at the same time
<pitti> mpt: dpkg -l epiphany-browser |grep ^ii
<seb128> mpt: 2 persons having a similar issue on the same day when we got nothing like this in ages is weird coincidence, I prefer to triple check that
<mpt> pitti, 2.22.2-0ubuntu0.8.04.2
<pitti> so, that's the old one
<pitti> not the one which went into -updates today
<mpt> I didn't see any Epiphany updates in update-manager
<mpt> just Firefox and language packs
<seb128> firefox being firefox2 which epiphany is not using
<pitti> mpt: dpkg -l xulrunner-1.9|grep ^ii
<mpt> pitti, 1.9+nobinonly-0ubuntu0.8.04.1
<asac> thats still the old one
<pitti> ok, that's also the old one
<pitti> today 1.9.0.1+build1+nobinonly-0ubuntu0.8.04.2 went to -updates
<asac> good luck ;)
<pitti> mpt: ok, thanks so far
<asac> seb128: that thing was more than a week in -proposed. is there really no other bug about something similar?
<pitti> so apparently it is not related to today's updates at alll
<seb128> asac: could the firefox2 update impact on running epiphany instances?
<asac> not that i can think off. they are unrelated
<seb128> asac: no, I would have nothing, I read all the incoming bugs mails I receive
<seb128> s/nothing/noticed
<seb128> maybe just a weird coincidence
<asac> seb128: yeah. what was the bug filed today?
<pitti> I asked for the precise versions in the bug now
<seb128> asac: https://bugs.edge.launchpad.net/ubuntu/+source/epiphany-browser/+bug/250763 was filed 6 hours ago
<ubottu> Launchpad bug 250763 in epiphany-browser "Epiphany cannot remember passwords nor certficates after a restart" [Low,Triaged]
<pitti> asac: 6 hours ago
<asac> ok thats not related then
<asac> or
<seb128> asac: and mpt just mentioned his issue on #epiphany some minutes ago
<pitti> that was before I moved the new stuff to -updates
<asac> would be quick
<seb128> mpt did update those
<seb128> but he did get the firefox2 update
<seb128> s/did/didn't, can't type
<mpt> It happened shortly after I installed the firefox 2 update
<mpt> (I have both FF2 and FF3 installed for testing purposes)
<pitti> maybe these two share the same profile, and something went wrong with profile managemnet?
<asac> mpt: right. that will only cause pain for firefox (when switching back and forward)
<asac> pitti: i doubt that. unless mpt uses manually setup profiles of course
<mpt> I do not
<mpt> (though I'm tempted, because it's mildly irritating that every time I launch FF3 after using FF2 I get the Ubuntu start page)
<asac> mpt: and what happens if you starte ffx2 after ff3?
<mpt> asac, I get my home page as expected
<asac> ok
<seb128> asac, pitti: just installed the firefox-2 current version on an hardy box, didn't crash epiphany, upgrading to today's xulrunner and firefox update didn't create any issue either
<seb128> I'll keep an eye for similar issues
<pitti> I subscribed to the bug, too
<seb128> but so far it could just be a coincidence
<AlexCONRAD> tseliot: update of bug 250792
 * asac hugs seb128 
<ubottu> Launchpad bug 250792 in linux-restricted-modules "Adobe Flash hardware acceleration support (GPU)" [Undecided,New] https://launchpad.net/bugs/250792
<asac> now i can sleep better
<mpt> seb128, also, "Web History (Epiphany)" and "Web Bookmarks (Epiphany)" turned themselves off in Deskbar Preferences
<mpt> (maybe because they couldn't find the necessary data)
<seb128> mpt: do you still have bookmarks in .gnome2/epiphany/ephy-bookmarks.xml or some backup files in this directory?
<tseliot> ï»¿AlexCONRAD: I'll have a look at it ASAP
<huats> Is the kind of licence like that one http://revu.ubuntuwire.com/revu1-incoming/tktreectrl-0807181630/tktreectrl-2.2.5/license.terms is allowed in ubuntu?
<huats>  it is the one commonly used in tcl pakage
<huats>  ...
<mpt> seb128, hey, this directory contains a couple of desktop background pictures I'd lost, thanks :-)
<huats> it is the same than the one used in the tcl/tk license terms http://www.tcl.tk/software/tcltk/license.html
<huats> apparently elmo, you might be the person to ask :)
<pitti> the last paragraph is a bit hard to interpret
<pitti> first, it limits usage by governments, and then the last sentence almost, but not quite, reverts the limitation
<pitti> (it just says "use and distribute", not "modify")
<mpt> seb128, but yes, it contains a backup that has most of the missing bookmarks
<pitti> tseliot: hmm, now that all four modules are just called 'nvidia', I can only have one handler instead of three; so I wonder which xorg.conf options I should apply to each of those versions...
<pitti> tseliot: I can still tell them apart by looking at the package name, of course
<slangasek> pitti: the definition of "Restricted Rights" in US law basically means "getting a copy of this on behalf of the government doesn't automatically give you special privileges"
<slangasek> so I don't think that's a problem
<elmo> huats: I am not an archive admin, but I think it's fine
<huats> elmo: pitti told me that you might be a good person to ask :)
<pitti> elmo: thanks for reviewing
<huats> elmo: thanks for your opinion :)
<huats> pitti: thanks too :)
<tseliot> ï»¿pitti: yes, the module is always "nvidia". There are no specific options for each driver. If Jockey can tell one model from the other then some card-specific options can be applied.
<pitti> tseliot: for now I think I'll just continue to use the few I have in hardy
<pitti> tseliot: (-71: AllowGLXWithComposite, UseEdidFreqs; -96: AddARGBGLXVisuals)
<pitti> tseliot: at some point I'd like to merge the much better option mapping you have in envy
<pitti> but for getting in the initial support for the new packages I'll just use those coarse ones
<pitti> tseliot: do you happen to know if I can set AllowGLXWithComposite in the screen section, too? or just in the Driver section?
<tseliot> ï»¿pitti: wise choice. I'll give you a hand with this. I have yet to make EnvyNG work on Intrepid. Maybe disabling the dri2 module would be nice too.
<tseliot> pitti: we should include X-Kit too
<pitti> tseliot: dri2> for all versions? yes, I can do that easily
<pitti> remove_modules=['dri', 'GLcore']
<pitti> ^ current code
<pitti> so I'll add dri2?
<tseliot> ï»¿pitti: yes, for all versions
<tseliot> ï»¿pitti: removing "dri2" is not enough. You will have to set Disable "dri2"
<pitti> in which section?
<tseliot> pitti: you can do that with X-Kit ;)
<tseliot> in the Module section
<pitti> tseliot: getting there, getting there... but I'd like to push out something working for alpha-3, if possible
<seb128> mpt: ephy-bookmarks.xml has most of the bookmarks? or do you have a backup which have those? do you get any error if you run epiphany on a command line?
<mpt> seb128, ephy-bookmarks.xml did not, but there were two backup files, one of which contained most of them
<seb128> ephy-bookmarks.xml was empty?
<seb128> do you have anything about epiphany in .xsession-errors?
<mpt> ephy-bookmarks.xml wasn't empty, it contained the bookmarks that I'd added since I lost them all
<tseliot> pitti: disabling "dri2" is not extremely important but users will report a driver failure as being caused by "dri2" if you don't disable it. The nvidia driver will still work
<mpt> When I run Epiphany from a command line I get "(epiphany-browser:32738): GLib-GObject-WARNING **: value "((GaProtocol) 2)" of type `GaProtocol' is invalid or out of range for property `flags' of type `GaProtocol'" and "(epiphany-browser:32738): GLib-CRITICAL **: g_hash_table_unref: assertion `hash_table != NULL' failed"
<mpt> seb128, and when I close Epiphany with Ctrl W it says "Segmentation fault", though when I close it with the title bar close button it exits properly
<mpt> (I'm guessing that's a whole different bug)
<seb128> the other bugs are similar warning, but yes could be a different issue
<seb128> asac: ^ any idea about those?
<mpt> aha
<mpt> /home/mpt/.gnome2/epiphany/ephy-bookmarks.xml:162: parser error : expected '>' <parent id="5"/>
<mpt> /home/mpt/.gnome2/epiphany/ephy-bookmarks.xml:162: parser error : Opening and en
<mpt> ding tag mismatch: property line 0 and unparseable
<mpt> That explains a lot :-)
<tseliot> pitti: about ï»¿AllowGLXWithComposite: http://pastebin.com/d2ce43337
<tseliot> ï»¿pitti: are you sure that enabling it is still a good idea?
<asac> mpt: is that file broken?
<pitti> tseliot: not first hand, I just got it from bug reports
<pitti> tseliot: I can drop it for now and try to find a tester who uses -legacy
<pitti> sorry, -96 in newspeak
<mpt> asac, I guess it was (I've restored it from backup since then)
 * mpt looks forward to XML 5 and more tolerant XML parsers
<tseliot> pitti: currently 71 and 96 don't work at all because of the new Xserver ABI :-/
<pitti> heh, ok
<asac> mpt: if it was broken like in "not-complete" then you most likely had a crash while ephy synched bookmarks
<pitti> well, I just drop it for now, thne
<asac> thats the only explanation i have at hand
 * ion_ looks forward to S-exps. :-)
<mpt> s/forward to S-exps/backward to S-exps/
 * mpt flees
<ion_> Yeah
<mpt> Anyway, S-expressions aren't any more fault-tolerant than XML -- they're theoretically less fault-tolerant, precisely because they're more concise
<joeythesaint> s
<ompaul> Treenaks, mark - pm at this time
<emgent> heya
* slangasek changed the topic of #ubuntu-devel to: archive: soft-frozen for intrepid alpha 3 | Development of Ubuntu (not support, not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/feisty/gutsy/hardy, #ubuntu+1 for intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<hwilde> so, how do you unset the root password if someobdy set it
<hwilde> !root
<ubottu> Do not try to guess the root password, that is impossible. Instead, realise the truth... there is no root password. Then you will see that it is 'sudo' that grants you access and not the root password. Look at https://help.ubuntu.com/community/RootSudo
<slangasek> hwilde: by editing /etc/shadow, but that question seems a bit off-topic here
<hwilde> nobody else knows :(
<slangasek> (there are other tools that can be used to edit /etc/shadow for you, but I never remember what they are, so I just edit /etc/shadow)
<mkrufky> seriously, dont worry about the roor password
<mkrufky> root
<hwilde> people are setting the root pw
<mkrufky> somebody set it?  who cares?
<mkrufky> use sudo anyway
 * hwilde stares at mkrufky 
<mkrufky> disable root login in ssh
<mkrufky> (should be disabled by default anyway, no?)
<hwilde> roor is cool tho :)
<hwilde> nice typo
<slangasek> BenC: grub 0.97-29ubuntu29 still fails to install in the livefs build chroots
<ion_> benc: A wrong value (1 instead of 0) seems to have slipped into fail_exit_val in kernel-helper -i.
<asac> ogra: there? where is the latest hardy cmpc image?
<ogra> asac, usual place :)
<ogra> http://people.ubuntu.com/~ogra/classmate/images/hardy/
<asac> ogra: is that known to work?
<ogra> asac, https://bugs.launchpad.net/cmpc/+bugs the fix commited bugs look for confirmation (even though you might not have the HW for many of them)
<ogra> well, it works fine here on my 1.5 HW
<ogra> i dont test on 1.0 anymore but would be good to hear if it works there indeed
<BenC> slangasek, ion_: whoops
<BenC> slangasek: I thought I tested it, but I guess I didn't hit the proper situation
<ion_> benc: It would be nice if it printed something like "$0: No vmlinuz, exiting.", btw.
<BenC> slangasek: Uploaded fixed one (exit val at 0)
<slangasek> ok, cheers
<alex-weej> ogra: hi
<ogra> alex-weej, hey, i have to relocate (hop in a taxi etc) but will be online later again
<ogra> i was about to suggest we take that off list :) great that you had the same thought
<mathiaz> slangasek: about the slapd cnconfig migration I sent to the pkg-openldap-maintainer list, is there a chance it will get accepted for lenny ?
<slangasek> mathiaz: I think so, yes
<slangasek> mathiaz: currently queued up behind PAM upstream merges in my brain, though :)m
<mathiaz> slangasek: how does the debian freeze work then ?
<slangasek> mathiaz: well, today a member of the Debian release team who will remain nameless declared that "vorlon can do whatever he wants" ;P
<mathiaz> slangasek: right... I see your point :D
<slangasek> mathiaz: in the early stages, the Debian freeze is mostly about getting the archive into a consistent state; this takes longer in Debian than in Ubuntu, in part because Debian sets the bar higher
<slangasek> things like changing the slapd config setup, while significant, are self-contained and don't bother the release team so much
<mathiaz> slangasek: ok
<ogra> and NMUs are harder than team maintenance
<slangasek> unless they happen in the last weeks before release, and cause a regression ;)
 * ogra twiddles thumbs waiting for the shuttle to arrive 
<asac> ogra: works fine on 1.0 for me. quite nice actually. tbird ;)
<ogra> heh, yeah, i have to drop something big for openoffice
<Nafallo> ogra: you're buying a shuttle? new development box?
<ogra> and evo was the heavyweight that lost
<asac> yay
<ion_> ogra: Light a match afterwards.
<nxvl> cjwatson: around?
<android6011> I have a slight problem booting, I get the "starting up" then something abotu GPE Storm Detected, if I press the power button it continues to boot, but if I don't it hangs. I was just wondering if there is a bug report for this
#ubuntu-devel 2008-07-23
<kees> hm, should openldap2.3 be removed from the archive to avoid confusion?
<ogra> alex-weej, so, here i am ... what do you want to discuss ?
<ogra> (i think michael r. head explained the filtering very well already ... and youself pointed out the broken threading on the webpage ... so i dont actually see any point on going on to discuss it, but i'm available if you want to)
<jdong> pitti: poor you with rm --one-file-system.... I had the same problem a few months ago zapping a temp home dir, not knowing ~/.gvfs mounted a samba share I viewed
<LaserJock> jdong: yeah, I'm a bit leary of the .gvfs stuff
<jdong> LaserJock: particularly since I was unaware of the .gvfs automounting behavior.... boy that should really get some release note red warnings!
<LaserJock> jdong: yeah, I almost did some stupid stuff because of it
<cjwatson> nxvl: dude. include a payload with your pings. :)
<Chipzz> cjwatson: feeling better? :)
<pitti> Good morning
<StevenK> Morning pitti
<nxvl> cjwatson: yes, sorry i just ping you and then realiza that you were sleep
<nxvl> cjwatson: i didn't take the tz in account, so i just left there
<nxvl> :D
<cjwatson> Chipzz: not really
<cjwatson> I wouldn't be up before 7 if I were feeling well
<NCommander> I'm stumped
<pitti> tkamppeter_: ping
 * thorwil waves to sabdfl 
<sabdfl> hey thorwil
<thorwil> sabdfl, i'm wondering whether you got my mails?
<stgraber> moin
<AlexCONRAD> hi, I installed the glfrx-control to tweak my ATI card via the control panel. But settings I set in here, where are they stored ?
<stgraber> cjwatson: did you file a bug on LP about that bug when doing a manual install with encrypted LVM ?
<stgraber> cjwatson: It complains of unsafe swap space :( (it's in the encrypted LVM so shouldn't)
<slangasek> bryce: could you have a look at bug #251059 when you're up?
<ubottu> Launchpad bug 251059 in xorg "Intrepid: Monitors with incorrect EDID have no display and no safe mode" [Undecided,New] https://launchpad.net/bugs/251059
<AlexCONRAD> ah, a new ATI driver came out
<AlexCONRAD> it says it introduces product support for Ubuntu 8.04 production support...
<AlexCONRAD> im not sure what that means
<AlexCONRAD> and it supports new cards
<Keybuk> cjwatson: so, I've had some time to look at your auto tools problem
<seb128> hey Keybuk!
<seb128> Keybuk: I've some libtool2 issues
<pitti> good morning Keybuk
<Keybuk> seb128: what are your issues?
<seb128> Keybuk: sec, getting the details again, I fought with that yesterday
<pitti> asac: ah, sorry, my fault; I didn't copy epy to -updates yet
<seb128> Keybuk: in fact that's gtk which seems to do something stupid, I'm wondering why that works when using libtool1.5, http://people.ubuntu.com/~seb128/configure.in has "deplibs_check_method=`(./libtool --config; echo 'eval echo $deplibs_check_method')" or there is no "libtool" in the gtk source so the ./libtool call fails
<Keybuk> yeah, that won't work until after libtool has run ?
<Keybuk> it may be that the different versions generate the script at different times, of course
<seb128> well, that doesn't work when relibtoolizing using libtool2
<seb128> but that works when using libtool1.5
<seb128> I'm trying to figure why now
<tseliot> ï»¿AlexCONRAD: I'll add that driver ASAP
<AlexCONRAD> tseliot: FYI, when I install the restricted drivers, I don't have antialiasing in flash. But when I install the ATI drivers (from their web site), I do have antialiasing enabled, after a reboot, I have nothing to do.
<AlexCONRAD> enabled in *flash*
<AlexCONRAD> I'm still trying to figure out what's the difference bewteen the settings you set in "amdcccle" and the onces you set using aticonfig
<AlexCONRAD> and the ones*
<asac> pitti: all fine then - nothing to be sorry ;) (especially now that it turned out to be a none issue)
<pitti> asac: btw, what about nspr and nss? AFAIR there was something still not 100% clear?
<asac> pitti: sorry, have to run to doctor ... will be back in 30 minutes or so.
<AlexCONRAD> tseliot: nevertheless, I still have "SGI" set as the "client glx vendor string" via glxinfo
<Keybuk> seb128: this exact case is covered in the libtool doc
<pitti> asac: no problem; good luck!
<Keybuk> seb128: if you simply delete that line, everything works
<Keybuk> $deplibs_check_method is available to any configure code after LT_INIT / AC_PROG_LIBTOOL
<seb128> Keybuk: ok, thanks
<seb128> that was working when using libtool 1.5 because something copied "libtool" in the build directory apparently
<Keybuk> yes
<seb128> which is not the case in the current version and expose the bug
<Keybuk> libtool was generated at the point inside configure where AC_PROG_LIBTOOL happened
<Keybuk> and all the variables were lost to configure
<Keybuk> it's now generated by config.status
<NCommander> hey seb128!
<Keybuk> which means the variables are all available, and can even be changed by other configure bits
<seb128> hello NCommander, sorry I've been busy working on the new GNOME updates and didn't reply to your mail yet
<NCommander> seb128, it's fine. Anything I can do to help with those updates?
<seb128> Keybuk: ok
<seb128> NCommander: help is always welcome ;-) But the remaining updates are mostly non trivial ones
<NCommander> THat's fine
<NCommander> I've packaged a few non-trival apps before
<NCommander> About the only thing I haven't done in that respect is a kernel module
<pitti> gcalctool should be trivial, and is needing an update to meet the SRU policy :)
<seb128> NCommander: want to have a look at updating evince to 2.23? it'll require a main inclusion report for libspectre which is used now to display .ps in the new version
<pitti> that might be a good target
<seb128> pitti: huats did both stable and unstable one yesterday
<pitti> ah
<pitti> not yet uploaded then, it seems
<seb128> pitti: bug #250766
<ubottu> Launchpad bug 250766 in gcalctool "Please sponsor gcalctool 5.23.5 into intrepid" [Undecided,New] https://launchpad.net/bugs/250766
<pitti> cool
<seb128> pitti: no, I've been too busy to do sponsoring yesterday, thanks for sponsoring the hardy update btw ;-)
<pitti> de rien
<seb128> new GNOME is quite a challenge this week
<seb128> gnome-keyring has a new lib, seahorse has been splitted and the tarball drop all the addons for gedit, epiphany-browser etc which are in a new source
<NCommander> seb128, SUre, no problem
<seb128> gnome-desktop changed soname (not updated yet due to CD build)
<seb128> evolution-data-server has sonames changes too and they switch to on disk sqlite storage for mail indexes
<seb128> the new gnome-session dbus code should land soon
<seb128> epiphany-browser has a webkit backend only now
<seb128> etc etc ;-)
<seb128> NCommander: cool, let me know if you have any question on the update, or feel free to ask here or on the #ubuntu-desktop channel
<seb128> pitti: where is the MIR guide again? There is a zillion MainInclusionReport* pages in the wiki and I never remember how to find the guide one in the list
<pitti> seb128: https://wiki.ubuntu.com/UbuntuMainInclusionRequirements
<seb128> thanks
<pitti> seb128: https://wiki.ubuntu.com/MainInclusionProcess is the policy
<seb128> NCommander: ^ to read if you didn't yet
<pitti> since it links to both the Requirements and the template, it's a better page to bookmark, I think
<seb128> right
<NCommander> seb128, yup, I saw that
<Keybuk> pitti: on --one-file-system
<Keybuk> you know that if you bind-mount from the same filesystem, that doesn't work, right? :)
<pitti> Keybuk: I know, yes
 * NCommander doesn't get the autoreconf patch ...
<pitti> it's not perfect, but helps a lot already
<Keybuk> NCommander: ?
<NCommander> In evience, the old version has an autoreconf patch, but it doesn't appear to be necessary
 * liw wants "rm --keep-the-important-stuff", but settles for kvm running a bunch of virtual machines for experimentation
<seb128> NCommander: oh, if you have interest in C++ the g*mm bindings also need to be updated and maybe somebody looking after the bugs
<NCommander> (evience is still building though the new version, so it may not have exploded (yet))
<seb128> NCommander: autoconf update is required due to the lpi changes, they add launchpad-integration to the configure.in
<NCommander> Oh
<NCommander> Thanks, I didn't catch a new file was added
<seb128> NCommander: and the other autotools are required because the hildon patch change the Makefile.am
<NCommander> Why not just add it properly it, and then call the autotools scripts to rebuild on the fly?
<NCommander> I always found patching configure directly will make updates harder
<seb128> NCommander: "add it properly"? that's what 01_launchpad.patch does
<seb128> NCommander: we just run autoreconf in a patch rather than a build time
<NCommander> Ok, I can understand that
<seb128> that's something which might be discussed and different people have different opinion
<seb128> there is pro and con for both way
<NCommander> I perfer calling autoreconf to do it, but if you perfer I do it as a patch
<NCommander> you are my mentor thus I shall follow your lead :-)
<seb128> well that's what we do for desktop packages
<seb128> and at least the result is constant
<seb128> which is not the case when you call whatever automake version is installed at build time
<NCommander> Makes sense
<NCommander> I'm running cdbs-edit-patch now
<seb128> to update the patch just remove the previous version, it'll not apply cleanly anyway
<seb128> cdbs-edit-patch 99_autoreconf
<NCommander> Yeah, I know
<NCommander> ;-)
 * NCommander has working with autohell before
<seb128> autoreconf -v -f && rm -rf autom4te.cache
<seb128> ok, good
<Keybuk> seb128:  + -i
<seb128> Keybuk: usually -f works for me but right
<NCommander> at least autoreconf works
<NCommander> It always ticks me off on packages which it breaks miserably on because of missing aclocal macros
<Keybuk> seb128: without -i, it'll fail to update one half of libtool if ltmain.sh already exists in that directory
<Keybuk> it's a bug imo, colin found it yesterday
 * NCommander rm's the patch and redoes it with +i
<tseliot> ï»¿AlexCONRAD: antialiasing can be set through amdcccle and - if I'm not wrong - is not stored in the xorg.conf (AMD uses its own configuration file). When you install the driver from either EnvyNG or Jockey amdcccle is not used. I don't know what happens when you use aticonfig.
<seb128> Keybuk: ok
<AlexCONRAD> tseliot: I'm doing some tests right now...
<NCommander> ok, now its building
<AlexCONRAD> tseliot: OpenGL screensavers seem to be affected by the amdcccle (from the ati drivers)
<seb128> Keybuk: btw if a program has C and C++ sources, should AC_PROG_CC and AC_PROG_CXX be used or is CXX enough?
<seb128> Keybuk: that's for gnome-system-monitor
<NCommander> seb128, I've used both, but you could probably get away with AC_PROG_CXX
<Keybuk> seb128: both
<Keybuk> you need CC for the C sources, CXX for the C++ sources
<seb128> ok, that's what I did yesterday but I was not sure, building using CXX only seems to be working too
<Keybuk> you'd even need to use CC if g++ could compile C code, since it needs to be set in CC
<Keybuk> oh, it might *work*
<Keybuk> the check for a C compiler is pretty much required by everything
<Keybuk> but it might stop working one day ;)
<tseliot> AlexCONRAD: just FYI AMD's configuration file is ï»¿/etc/ati/amdpcsb
<AlexCONRAD> tseliot: I see that things are stored in /etc/ati/amdpcsb
<AlexCONRAD> tseliot: :)
<seb128> Keybuk: alright, thanks ;-)
<NCommander> seb128, ok, its building now
<NCommander> seb128, (this machine for some reason takes forever to run autotools, but builds very quickly)
<AlexCONRAD> tseliot: Im having a hardtime to figure out which or amdcccle or aticonfig (xorg.conf) takes over
<seb128> NCommander: ok
<zyga> mvo: hello :-)
<AlexCONRAD> tseliot: also, what does "sudo dpkg-reconfigure -phigh xserver-xorg" does really ?
<zyga> mvo: I'd likte to patch a command-not-found bug, could you tell me where are the current ubuntu sources for that package? (as in bzr tree, not apt-source sources)
<zyga> mvo: I think I finally understand the cause of all the locale issues that pop up since c-n-f was introduced and I know how to fix that
<tseliot> ï»¿AlexCONRAD: don't do it unless you really need it. It reconfigure your xorg.conf without asking questions.
<seb128> NCommander: some other desktop updates if you are looking for other things to do after this one: gucharmap (the new version adds python binding and might have changed the soname), glibmm and gtkmm if you have interest in C++ bindings
<NCommander> seb128, I assume you want me to add the libspectre support to this package instead of just having it use the existing gs code
<seb128> NCommander: what tarball did you get?
<NCommander> 2.23.5
<NCommander> WHich was the latest on the ftp.gnome.org site
<seb128> NCommander: the upstream NEWS mentionned that they dropped the gs support
<seb128> but yes, we want to use libspectre now
<NCommander> The README says optional
<AlexCONRAD> tseliot: well, things are pretty clear now: aticonfig --fsaa=on/off and all antialiasing options are no longer available in the latest ATI drivers
<NCommander> ATM, its FTBFS because it can't find the launchpad support library
<NCommander> undefined reference to `launchpad_integration_add_ui'
<AlexCONRAD> tseliot: sounds like you can only do it through amdcccle
<seb128> NCommander: did you apply 01_launchpad before doing the autoreconf?
<NCommander> I thought I did
<seb128> NCommander: 01_launchpad should add launchpad-integration to the configure.in and the autoreconf should apply that to the configure
<seb128> NCommander: maybe look if the configure lists it correctly?
<mvo> zyga: hello! nice to see you :) the current bzr tree is at http://bazaar.launchpad.net/~ubuntu-core-dev/command-not-found/ubuntu
<NCommander> I don't see it in configure ...
<NCommander> Argh, if I had to bet, cdbs-edit-patch unapplied it when I ran edit-patch
<seb128> it should apply in order
<seb128> ie, cdbs-edit-patch 99_autoreconf apply 01_launchpad normally
<NCommander> I'm checking now to see what went wrong
<NCommander> No, it did end up in the right place
<zyga> mvo: thanks, I'll work on a fix and give you a branch back when I'm finished!
<seb128> NCommander: maybe they restructured the code and the launchpad-integration pkg-config check should be moved somewhere else in the configure.in
<NCommander> I'm checking now
<NCommander> This is personally why I don't like autoreconf in patches
<NCommander> I find its easier just to patch configure.ac, and then let autoreconf run at build time
<seb128> well, autoreconf at build time would not have produced a better result
<seb128> but right, you wouldn't have to update the patch again and again ;-)
<seb128> well, you just have to run autoconf in this case
<NCommander> yeah
<seb128> which is quick enough usually
<NCommander> Neat, libtool is now tossing a nice warning about AC_CONFIG_MARCO_DIR which it didn't before
<mvo> zyga: excellent, thanks a lot
<seb128> NCommander: right, I noticed that too, not sure if really makes a difference to use that though
<NCommander> seb128, I usually ignore autotool warnings cause then tend to be a tad paranoid
<seb128> I was pondering sending upstream patches for that on the packages I updated yesterday
<NCommander> Most upstreams don't touch the configure script once its done
<NCommander> We still have quite a few packages that build with 1.4 version of said tools
 * NCommander also works now on clearing the lintian warnings
<NCommander> seb128, since your an archive admin, can you help me resolve an issue with my package which got rejected?
<seb128_> re
<seb128_> hum, got disconnected
<seb128_> yeah, most upstream tend to copy configure from an another project, do some changes to get it working and don't touch it when that's not really required
<NCommander> seb128_, yeah, well as an added bonus, this doesn't properly list a build-dep on ghostscript, it just FTBFS looking for -lgs ...
<NCommander> I'm suprised it built on the buildds
<seb128_> well, gs is optional no? it probably built not using this option
<NCommander> /usr/bin/ld: cannot find -lgs
<NCommander> It seems it isn't
<NCommander> It needs ghostscript if you want postscript viewing enabled
<NCommander> seb128,_ anyway, I was hoping you could resolve a license ambiginity with regards to the copyright file, which lead to codeblocks being rejected
<seb128_> NCommander: there is no lgs mention in the evince source and the 2.22 configure is using the gs command to check if gs is available
<NCommander> I have the command available, but I didn't have the development library headers installed
<seb128_> ok
<NCommander> I just added the dependency on libgs-dev; its already a core package
<seb128_> NCommander: I've read the codeblocks rejection
<seb128_> ok, cool
<NCommander> I also think having postscript rendering isa  good thing
<NCommander> THe archive admin says the package is LGPL
<NCommander> But that's only true for the SDK
<seb128_> Riddell: ^
<seb128_> NCommander: Riddell is the archive admin who rejected the upload
<NCommander> YEah
<NCommander> I emailed him asking how I should clarify copyright
<NCommander> I assume I need to add LGPL for the files under that specifically
<NCommander> (in the copyright)
<seb128_> right, if you have sources under the LGPL the LGPL licence text should be distributed in the tarball and the debian/copyright should list those
<NCommander> the COPYING file only has the GPL3
<seb128_> right, you need to add A COPYING.LGPL for example then
<seb128_> or COPYING.LIB
<seb128_> which has the LGPL text
<NCommander> Can I simply add it as a patch, or do I actually need to repack the upstream?
<seb128_> I know some archive admin want it in the upstream tarball
<seb128_> otherwise the tarball is not re-distribuable
<NCommander> I was under the impression if something was shipping as GPL3, the collective work was GPL3, expect for the files that are LGPL, which can be used under the LGPL by themselves if they are removed from the package
 * NCommander recalls his time as a FSF Savannah admin
<seb128> not sure about that
<seb128> cjwatson or pitti might know better
<NCommander> Yeah
<seb128> but if you have LGPL sources you should have the LGPL text in the tarball
<NCommander> The LGPL says that it can be replaced with the GPL
<NCommander> So by having the later, you can meet the requires of the former
<Riddell> it is, but it's a separate issue.  if the code is under a licence, the licence text should be included so we know the full terms of the licence
<NCommander> Does that alone warrent repacking the source to add a COPYING.LGPL file, or should it simply be added via a patch (and in the copyright file of course)
<pitti> NCommander: addding license documents via a patch is always wrong IMHO
<Riddell> it's upstream who would need to add the file since they're the ones licencing it
<pitti> either you don't need it at all(because of some GPL implies LGPL situation), or it needs to be in the orig.tar.gz
<NCommander> I'll ask upstream to add the file (I already had to file a bug with them over a rendering bug in wxWidgets)
<NCommander> I assume if I want it to go them, I need to repack the source, right?
<seb128> NCommander: yes
<NCommander> ok
<NCommander> That makes sense
<seb128> NCommander: or get upstream to fix the issue and roll a new version ;-)
<Riddell> NCommander: I expect my e-mails to you are in your spam box, gmail doesn't like my server sometimes
<NCommander> code::blocks already stinks when it comes stable releases
<NCommander> seb128, http://paste.ubuntu.com/29569/ - evidence seems to hate me :-P
 * NCommander looks up the extension he needs to add to the mime file
<seb128> I'm not convinced that's authorized
<tyfon> hmm if i make a new package with some changes (libqt4-sql-psql) since the default one does not support postgres 8.3 that ships with ubuntu, how can i make it not want to download a "updated" package from the standard repo?
<NCommander> I found the fix on their bugzilla
 * NCommander adds the patch
<tyfon> do i need to bump the version somehow?
<seb128> NCommander: good, don't forget to add those to debian/evince.mime too
<NCommander> no, its a typo in the desktop file thats causing that
<seb128> NCommander: application/x-cb7 seems to be new and should be added to debian/evince.mime no?
<NCommander> I'm checking
<NCommander> yeah
<NCommander> Its new
<NCommander> But I can't figure out what extension is x-cb-7
<NCommander> According to the source, its some sorta comic book format
<seb128> NCommander: http://bugzilla.gnome.org/show_bug.cgi?id=532312 indicates cb7
<ubottu> Gnome bug 532312 in general "Comic Book compresses with 7zip (aka .cb7)" [Enhancement,Resolved: fixed]
<NCommander> thanks :-)
<NCommander> ok, new mime type in place, autoreconf patch updated again, now to see if it will build
<NCommander> seb128,  internet trouble?
<seb128> NCommander: no, restarting session to try updates sometimes
<seb128> I should configure an IRC proxy or something
 * NCommander edits the changelog
<seb128> ok, it's lunch time, see you in a bit
<NCommander> I should be more or less done by then seb128 ;-)
<seb128> NCommander: I'm away for lunch, I'll read the backlog when I'm back
<seb128> ok, cool
<seb128> it must be late for you, there is no hurry for the update, feel free to continue tomorrow
<seb128> late or early
<seb128> anyway lunch time, bbl
<NCommander> seb128, its all built, but it has a bunch of lintian warnings like debian-copyright-line-too-long, but no errors
<NCommander> seb128, uploaded to PPA sonicmctails on LP
<zyga> mvo: is there any sane way to make bug repots from python that will identify ubuntu version?
<zyga> mvo: (so that the "report this bug" URL will point to correct ubuntu release, not the generic package
<zyga> mvo: I was thinking about optionally reading /etc/issue
<broonie> zyga: lsb_release?
<zyga> or using lsb
<zyga> right
<broonie> /etc/issue is commonly customised by users so you can't rely on it.
<zyga> lsb_release looks as a sane way to do that
<zyga> now just for a simple way to tie that to launchpad
<zyga> thanks I think calling subprocess.call("lsb-release", "-a") is enough for bug maintainer to re-assign the bug as needed
<Pici> I was under the impression (and correct me if I'm wrong) that the current Ubuntu bug workflow was to assign bugs to the 'generic' package and not to the release specific version.  Unless of course you're talking about reworking that workflow.
<zyga> I wasn't aware of that
<zyga> I was just looking for a way to get default bug reports more meaningful than before
<Pici> see https://bugs.edge.launchpad.net/ubuntu/+source/pidgin vs https://bugs.edge.launchpad.net/ubuntu/hardy/+source/pidgin
<mdz> that was exciting...I just installed the latest intrepid daily desktop
<pitti> mdz: and it actually worked?
<mdz> pitti: almost
<mdz> lots of problems
<sistpoty|work> mdz: out of interest: did you get read errors from the cd? (I got that with testing the last two daily images from faumachine... just curious if that's a faumachine bug or a bug in the live cd)
<mdz> sistpoty|work: no
<sistpoty|work> ok, thanks
<zyga> mvo should I add something to debian/control when I want to use lsb_release?
<zyga> (like lsb-release package)
<mvo> zyga: yes, a depends on the lsb-release package
<zyga> ok, done
<DktrKranz> lamont: do you have any clue about this FTBFS on hppa? http://launchpadlibrarian.net/16253078/buildlog_ubuntu-intrepid-hppa.gnustep-base_1.16.1-2ubuntu1_FAILEDTOBUILD.txt.gz
<lamont> "iz feature" :-<
<DktrKranz> gah!
<lamont> I wouldn't worry too much about it
<lamont> once hppa catches back up (is it??) I expect that infinity will throw everything that failed back against the wall to see what sticks
<lamont> that looks like one of the standard "that threads bug" (it isn't actually, but it is...) failure modes
<zyga> mvo: http://suxx.pl/~zyga/command-not-found--locale-issues-fix/
<DktrKranz> ok, I'll leave it alone for now, thanks
<zyga> mvo: I didn't test it with python 2.4 though
<mvo> zyga: thanks, I will merge and review now
<zyga> mvo: I did one more change that is not in the changelog
<zyga> I replaced /usr/bin/env python with /usr/bin/python -S
<zyga> -S omits import site that often got to crash reports
<zyga> hmm, doesn't work with 2.4
<zyga> if that's a problem I can work around it but I think it needed 2.5 before (try/except/finally)
<seb128> NCommander: ok cool, I'll have a look in a bit and comment here or by mail
<NCommander> seb128, cool
<ogra> geez, intrepid daily doesnt even survive unpacking the kernel in my vbox
<ion_> ogra: Is it perhaps running compcache?
<ogra> ion_, nah, just the alternate CD, no fancy stuff
<ogra> th eodd part is that the oops scrolls indeed out of sight
<ogra> we should really do something that it doesnt get bigger thn a standard terminal at some point ... or put the intresting stuff at the bottom
<ogra> BenC, ^^^
<superm1> ogra, perhaps can you set up a "serial" console easily on a VM, and then capture using minicom or similar?
<ogra> hmm, thats way more work than i planned to get an intrepid VM quickly :)
<sistpoty|work> ogra: what are you using? kvm? or s.th. else?
<ogra> virtualbox on hardy
<ogra> and the current daily alternate
 * sistpoty|work tries hardy kvm atm with the current daily desktop *g*
<ogra> uuuh, desktop is like gambling i bet :)
<tkamppeter_> pitti, hi
<ogra> i just need a working env. for ltsp stuff (going to the ltsp hackfest today)
<pitti> tkamppeter: could you please update system-config-printer to a recent snapshot? I need it for the jockey printer bits
<tkamppeter> pitti, OK
<superm1> sistpoty|work, i had just read some bugmail that indicated the current daily desktop has a few bugs in ubiquity
<pitti> it seems you need to run some autoconf stuff in order to produce an orig.tar.gz from git?
<pitti> tkamppeter: ^
<pitti> tkamppeter: ok, thank you!
<tkamppeter> (The Intrepid version is hopelessly outdated ...)
<superm1> but if you make it to the desktop, you are in better shape than virtualbox right now
<superm1> sistpoty|work, as in bugs preventing install due to errors
<ogra> but it would be really helpful (not right now but in general) to have oppses printed out in reverse order ... usually only the first lines re the intresting ones and they always scroll off the visible area
<sistpoty|work> superm1: I kind of made it to the desktop :)
<tkamppeter> pitti, yes. You must do (in the main directory):
<tkamppeter> ./bootstrap
<tkamppeter> rm -rf autom4te.cache
<tkamppeter> Then you must create a tarball with --exclude=.git
<ogra> hmm, not even the CD selftest will run ...
<ogra> must be a serious kernel issue (or isolinux)
<superm1> ogra, well i dont know that i entirely agree.  perhaps having a kernel parameter to "allow" then to be printed in reverse order would be better
<superm1> especially in the case of entirely reproducible oopsses
<ogra> superm1, that would be fine too, but its a thing that bothered me often already
<ogra> if your keyboard doesnt work after the crash there is simply no easy way to reach the wanted info
<ogra> and things like vprintk or show_fault_oops dont really tell me something ...
<ogra> geez ... dropping quiet from teh bootopts gets me funny colored squares on the screen
<BenC> ogra: there's ways to scroll back to the oops
<ogra> not in my vm it seems
<ogra> what was the command to disable tickless ? noticks=on ?
<ogra> i saw somethng about ticks in the last round
<BenC> dynticks=off
<ogra> thanks
<BenC> oops
<BenC> ogra: no, it's nohz or nohz=1
<ogra> heh, ok
<seb128> NCommander: ok, I'm looking at your evince update, first note: you did use the upstream tarball and a diff.gz, that's wrong ;-) you need to rename the tarball evince_2.23.5.orig.tar.gz so it's used and the debian changes are stored in a diff.gz
<seb128> NCommander: the ppa upload didn't build on lpia, seems that the hildon patch needs some changes
<NCommander> argh
<NCommander> The former was just stupid error
<NCommander> (I went away after uploading to my ppa, I didn't even check to see if I made a native version of not)
<NCommander> As for the second, look closer at the lpia log
<ogra> but dynticks=off seems to change something as well ... now it hangs without any oops
<NCommander> Its one of the dependencies failing to configure
<seb128> NCommander: looking
<NCommander> seb128, it fails before it even tried to build
<seb128> NCommander: otherwise you added .debhelper.log files in the debian directory, those should probably not be in the source
<seb128> NCommander: hum, no
<ogra> ah, nohz gets me the same result ... hangs at ACPI: XSDT ....
<NCommander> er, your right
<seb128> NCommander: the log I'm reading has lot of undefined reference to gtk function which indicates a -lgtk-x11-2.0 is missing somewhere
<NCommander> WTF was I on ...
<NCommander> Yeah
<NCommander> I see that
<NCommander> I've got an lpia chroot
<NCommander> I'll see if I can run that down
<seb128> you should be able to use --enable-hildon on i386 too
<NCommander> I did have an orig tarball, I just had an - instead of a _
 * ogra grins ... nohz=1 and acpi=off gets me "BUG: Unable to handle kernel <1>"
<seb128> just change the rules
<ogra> about 100 times repeated and then it stops
<seb128> NCommander: the build-depends on list in the changelog I not there, I suspect you changed the control rather than the control.in
<seb128> ups, can't write
<NCommander> Yeah, I did
<seb128> NCommander: the build-depends you listed in the changelog are not there, I suspect you changed the control rather than the control.in
<persia> Best to change both, generally
<NCommander> d'oh * 2
 * NCommander has not encountered a control.in file before
<seb128> persia: why bothering? just run the clean target
<NCommander> I'm not off to a very good start as showing you my mentee skills
<seb128> faster than typing everything twice
<ogra> but less educating :)
<persia> seb128: Some packages don't do control.in -> control in clean.  I just tend to be careful to avoid confusion.
<seb128> NCommander: don't worry, you clearly know what you are doing, those are just small mistakes due to different workflows
<NCommander> I must worry, I once managed to tick off the Debian archive admin ...
<NCommander> YOu can guess how that played out
<NCommander> Ok, I changed the control.in file
<NCommander> ok, I modified the control.in file
<NCommander> Er
<NCommander> wow
<NCommander> I'm duplicating myself
 * NCommander drinks coffee
<seb128> how did you manager to get those .debhelper.log in the source? I'm just curious ;-)
<NCommander> I dunno, it tends to happen to me when I build CDBS packages ...
<NCommander> No clean rule is usually why
<NCommander> I explicately add rm debian/*.log to my clean rules
<seb128> what is creating those log?
<seb128> that's the first time I see some of those
<NCommander> seb128, I see them all the time ...
<persia> NCommander: You might want to check your build environment: it oughtn't do that.
<NCommander> Both on sid and intrepid
<seb128> something in your config I would say
<NCommander> Maybe its time to rm -r the chroot and do it again
<NCommander> Probably
<NCommander> I use dpkg-buildpackage over debuild
<NCommander> Maybe that's what's doing it
<seb128> I do use debuild too
<NCommander> er, I don't use debuild
<tkamppeter> Riddell, have you already seen bug 251111?
<ubottu> Launchpad bug 251111 in system-config-printer-kde "Intrepid: Kubuntu printer dialogue doesn't open" [High,Triaged] https://launchpad.net/bugs/251111
 * NCommander should probably alias debuild to dpkg-buildpackage
 * ogra uses dpkg-buildpackage but doesnt see any logs 
<NCommander> seb128, how was my changelog? I didn't list the upstream changes yet, but I did list what I did to the package
<seb128> NCommander: the changelog is correct, we usually list NEWS item for desktop packages but that's not required, I just know some users like to read those on the change lists
<NCommander> sweet
<NCommander> THere are some lintian warnings
<NCommander> I'm not sure if you want me to clear them though (all of them but one involve the copyright file)
<seb128> they were already there before
<persia> Fixing copyright is usually a good thing though.
<seb128> well, we try to no divert from debian when not required
<seb128> but if you do clean and send the patch to the bts that's good ;-)
<NCommander> Yeah
<NCommander> Ok, everything is resolved expect the lpia issue
<seb128> dh_clean is supposed to remove those debhelper.log, weird that it doesn't for you
<seb128> and that's "dh" which seems to create those
<seb128> but we don't use "dh" yet, especially not in cdbs packages
<NCommander> if I run debian/rules clean manually, it disappears
<NCommander> er, the logs go away
<seb128> that's expected, the clean target call dh_clean
<NCommander> yeah
<seb128> do you have some magic to use the new "dh" in some way?
<NCommander> I avoid CDBS like the plague
<NCommander> SO no ;-)
<seb128> dh is not cdbs
<NCommander> I thought you wanted to use dh with cdbs
<seb128> it's debhelper 7
<seb128> no, I say that cdbs doesn't use dh
<seb128> so that's weird that you get those logs
<seb128> since they seem to be create when using dh
<NCommander> seb128, I thought CDBS used dh internally
<seb128> no, cdbs is way older than dh
<broonie> cdbs does use debhelper by default
<broonie> But not the new version 7
<NCommander> I've seen those logs on the old versions as well
<seb128> ok, I just greped quickly in /usr/bin/dh*
<seb128> and they seem to be a "dh" thing
<seb128> and I've never seen those before
<broonie> debhelper
<NCommander> I'm working in an intrepid chroot
<NCommander> Dunno if it would make the difference but
<NCommander> I kicked the mostly fixed evince onto my PPA
<NCommander> I'm now waiting for apt-get update to finish destorying my lpia chroot
<seb128> ok, good
<NCommander> seb128, I'm probably going to guess its going to need some autoconf love
<seb128> NCommander: I guess something lacks a gtk+-2.0 in the configure.ac
<NCommander> Well, its easy to localize the problem ;-)
<NCommander> Is lpia still on ports?
<seb128> no, it's an official architecture
<seb128> see https://edge.launchpad.net/ubuntu/intrepid
<NCommander> hrm
<NCommander> weird
<NCommander> It was erroring out
<NCommander> but now its not
<seb128> maybe different build sequence when using gs
<seb128> ?
<NCommander> Err http://archive.ubuntu.com intrepid/main Packages
<NCommander>   404 Not Found [IP: 91.189.88.46 80]
<NCommander> No
<NCommander> getting apt to be happy
<seb128> urg
<NCommander> yeah
<NCommander> I can't get apt to work with this
<NCommander> Which means my dreams of fixing lpia packages just died :-P
<seb128> well, as said before using --enable-hildon should work on i386
<NCommander> Ok, i got it
<seb128> no?
<NCommander> ITs still on ports.ubuntu.com/ubuntu-ports
<NCommander> I perfer just testing in a real environemnt
<persia> lpia is still on ports.
<NCommander> Because other packages may be configured differently
<seb128> right
<persia> Also, where possible, reorganising packages that have special --enable-hildon for lpia to instead do something architecture neutral (e.g. detect hildon at build time, produce additional binary packages, etc.) is appreciated.
<pitti> tseliot: do you have a minute to test the new jockey with the new nvidia handlers?
<NCommander> seb128, lpia fixes are a pain :-P
<seb128> right ;-)
 * NCommander looks at his checklist
<NCommander> Fix lpia stupidity
<superm1> pitti, do you have binary packages ready, or a bzr branch?
<NCommander> Fix OpenID-REVU stupidity
<NCommander> Fix C::B Stupidity
<NCommander> I think I need a new noun
<pitti> superm1: bzr get lp:~ubuntu-core-dev/jockey/ubuntu/ , then debuild
<pitti> superm1: I didn't upload it yet
<pitti> I tested it with a fake modalias entry, but that only gets me that far...
<superm1> pitti, okay, i can take a shot in an hour or so if no one else gets a chance to take a look
<pitti> superm1: thanks
<pitti> if anyone else with an nvidia card is eager to help with testing the new jockey, please speak up
<Riddell> tkamppeter: yes, fixing system-config-printer-kde is quite high on my priority, but so far I've not found time
<superm1> pitti, are you sure that you've uploaded the full set of changes?  according to https://code.edge.launchpad.net/~ubuntu-core-dev/jockey/ubuntu the last revision is about a week old?
<pitti> superm1: ugh, it should be about 3 minutes old...
<superm1> were you referring to trunk perhaps?
<pitti> superm1: loggerhead (http://bazaar.launchpad.net/~ubuntu-core-dev/jockey/ubuntu/changes) does have the latest
<pitti> so maybe the LP UI is just slow
<superm1> ah okay
<pitti> superm1: trunk is recent, too, but rather useless (or difficult) for nvidia testing
<superm1> ok
<NCommander> seb128, ok, its building, if it doesn't FTBFS, I'm going to break down and starting smacking my head on my desk
<Riddell> evand: kde ubiquity doesn't want to get past the partitioning stage, no errors produced, don't suppose you've any ideas?
<evand> Riddell: hrm, let me pull down a Kubuntu image and take a look.
<Riddell> evand: needs fixes in ubiquity from bzr
<evand> ok, noted
<pitti> superm1: I don't know how sane it works if you have the old nvidia-glx packages installed (or whether that still works at all in intrepid, I guess not); so maybe start with just 'nv'
<NCommander> seb128, ping?
<seb128> NCommander: the package built correctly?
<NCommander> seb128, nope
<NCommander> Found the issue
<seb128> ah ;-)
<seb128> what is it?
<NCommander> The hildon pkgconfig files don't list libgtk-x11 as a dependency
<NCommander> so autoconf doesn't suck it in
<seb128> the log is a bit weird, the line before the error seems to have the correct -llibgtk-*
<seb128> hum
<NCommander> (hildon is added via PKG_CHECK_MODULES, which if I remember my autotools, loads the pkg files from /usr/lib/pkgconfig, right?
<seb128> pkg-config --cflags --libs hildon
<seb128> or whatever the .pc is named
<NCommander> -lgdk-x11-2.0
<NCommander> Nope, its there
<NCommander> Ok
<NCommander> So much for that theory
<seb128> gdk != gtk
<NCommander> Oh
<NCommander> Wait
<NCommander> ...
<NCommander> d'oh
<NCommander> ok
<NCommander> I know I need more caffiene at this point
<seb128> did you find the issue? ;-)
<NCommander> nope
<NCommander> I just copy and pasted the wrong entry
<NCommander> (gtk was right next to gdk)
<seb128> oh, I know
<seb128> that's going to be my fault
<NCommander> why?
<seb128> I need to talk to the mobile guys about that
<NCommander> The soname of gtk-x11 is just plain weird
<NCommander> http://paste.ubuntu.com/29608/
<seb128> gtk was patched to expose private fileselectors apis in hardy
<tseliot> ï»¿pitti: sure. What shall I do?
<seb128> but the fileselector has been rewritten to use gio this cycle
<seb128> and I didn't port all the gtk changes or at least didn't try those
<pitti> tseliot: bzr get bazaar.launchpad.net/%7Eubuntu-core-dev/jockey/ubuntu/ jockey-ubuntu ; cd jockey-ubuntu; debuild -us -uc -b
 * NCommander debates whacking his mentor, but htings better of it
<seb128> so it's likely libhildon needs to be updated for the gtk changes
<seb128> lol
<pitti> tseliot: I'd like you to use the branch, so that you can test fixes from my side quickly
<NCommander> seb128, upload the debdiff once I reupload to PPA, and then bug the mobile guys
<pitti> tseliot: then install the .debs, run jockey-gtk (from the menu or shell, not sudo!), and check whether it detects your nvidia card
<pitti> tseliot: and if you can install the correct driver with it
<tseliot> pitti: ok
<seb128> lool, persia, ogra: somebody will need to port hildon to gtk 2.13 in intrepid, the fileselector has basically been rewritten and libhildon used to access private datas there which changed
<NCommander> seb128, uploading to PPA (since it seems my chroot seems broken)
<NCommander> where is upstream for hildon?
<seb128> I'm too busy and don't know how to test those changes and what you guys need so somebody in your team will need to do that
<pitti> tseliot: thanks muchly
<persia> seb128: So hildon is broken entirely for intrepid?
<seb128> NCommander: nokia? in ubuntu #ubuntu-mobile usually work on those
 * persia celebrates
<NCommander> All we got to do is break dak, and suddenly life would be much nicer :-P
<seb128> persia: no, only the custom fileselector thing I guess
 * NCommander has a personal hatred of dak
<persia> Oh well.  That's small enough that someone might fix it.
<NCommander> seb128, so other then the fact that hildon is broken, is my update good enough for you?
<tseliot> ï»¿pitti: no problem ;). I'll have to boot into Intrepid now
 * tseliot reboots
<seb128> NCommander: yes, it you fixed the things I pointed before
<ogra> seb128, i'm not sure how intrested we are in hildon in intrepid :)
<NCommander> what is hildon more specifically?
<NCommander> seb128, it won't let me upload to my PPA, it keeps rejecting
<seb128> NCommander: why does it reject it?
<seb128> NCommander: did you update the revision number?
<persia> NCommander: hildon is a UI framework that embeds GTK applications within a common address space and provides a unified UI (hildon-desktop is the Parent window for all windows, dialogs, etc.)
<NCommander> no
<seb128> NCommander: the ppa will not accepted to publish again an already published version
<NCommander> I deleted the old one
<persia> Deletion does not remove the history of publication, only direct access from ppa.launchpadnet
<NCommander> seb128, want me to just upload it to the PPA with ~ppa0 on LP, or should I shove it someplace like REVU where you won't have to rebuild the source package
<seb128> NCommander: I'm not sure that the ppa will let you downgrade the revision number, maybe just copy the debdiff on http://paste.ubuntu.com? it should be small enough
<NCommander> its the original source file I was more worried about
<seb128> which one? the tarball? I can get it from the GNOME server
<NCommander> oh
<NCommander> cool
 * NCommander just wanted to save you work
<NCommander> And the debdiff is 122985 lines ...
<NCommander> O_O;
<NCommander> oh
<NCommander> For the love of - it included the source package changes
 * persia recommends attaching the new diff.gz to a bug, as packages are fairly easy to regenerate from a diff.gz
<seb128> NCommander: right, other option is to open an evince bug and attach the diff.gz and .dsc
<NCommander> That's how I do all my FTBFS fixes
<NCommander> (replacing diff.gz with debdiff)
<persia> seb128: Why the .dsc?
<seb128> bonus point if you use open the bug first, then modify the source to add "lp: #nnnnn" to the changelog and then attach the diff.gz ;-)
<NCommander> I was doing that
<seb128> persia: because I'm lazy and prefer to run dpkg-source than gunzip && patch, and that also gives you the md5sum for the orig tarball which has been used
<persia> seb128: Ah, right.  The diff.gz -> package script went missing.
<tseliot> pitti: I had already installed the driver. Jockey now says that the driver is in use however the checkbox in the "Enabled" column is not toggled
<pitti> tseliot: so the nvidia module is loaded, but perhaps xorg.conf doesn't have "nvidia" driver?
<tseliot> pitti: what you're saying is (currently) not possible
<tkamppeter> pitti, system-config-printer_1.0.2+git20080723-0ubuntu1 uploaded.
<pitti> tkamppeter: thanks muchly!
<tseliot> pitti: if there's no "nvidia" driver specified in the xorg.conf the driver won't be loaded
<pitti> tseliot: ok, so let's debug this
<pitti> tseliot: -> /msg, to avoid too much noise here
<superm1> pitti, are these handler changes right now nvidia specific, or should I be able to test at least the "detection" on fglrx too?
<superm1> assuming modaliases are installed etc
<pitti> superm1: I didn't update the fglrx handler for the new structure yet, sorry
<superm1> pitti, no problem.  just wasnt sure how generic the solution was
<pitti> superm1: I'll do that as soon as I get nvidia working (currently figuring out with tseliot)
<superm1> pitti, okay
<ogra> mm, no way to make intrepid boot in vbox it seems ...
 * ogra just tried a hardy upgrade 
<pitti> superm1: shouldn't take much time to get it fully right, probably two lines of code changed, or so; the solution is very generic now
<superm1> pitti, ah
<NCommander> seb128, https://bugs.edge.launchpad.net/ubuntu/+source/evince/+bug/251172
<ubottu> Launchpad bug 251172 in evince "[diff.gz attached] New Upstream Version 2.23.5" [Undecided,New]
<NCommander> You've got debdiffs
<NCommander> er, diff.gzs
<superm1> ogra, this the sort of things you are seeing too: http://ubuntuforums.org/showthread.php?t=847425 ?
<superm1> ogra, they posted a (possible) solution there
<ogra> you mean the videobuffer ?
<ogra> hmm
<superm1> yeah
<ogra> i deliberately set it to 2M
<ogra> (to get 800x600 by default without fiddling)
 * ogra tries
<seb128> NCommander: the md5sum for the orig you used doesn't match the upstream one, did you download the .bz2 and repackaged it or something?
<NCommander> no, I just grabbed the .gz
<seb128> weird
<ogra> superm1, still ooopsing
<NCommander> hold on
<superm1> ogra, oh well :(
<seb128> I just gunziped the diff.gz and applied to that's alright
<NCommander> Let me redownload, and remake the dsc
<seb128> no that's ok, no need for that
<NCommander> Or that
<ogra> superm1, but thanks, was at least worth a try
 * NCommander is used to bowing down for the archive admins and doing everything but signing the upload :-P
 * NCommander is used to then getting the signed changes back and then uploading :-P
 * persia advocates working get-orig-source rules
 * NCommander would put it in if it wasn't a CDBS package
<seb128> NCommander: note the "-include /usr/share/gnome-pkg-tools/1/rules/gnome-get-source.mk" in the rules ;-)
 * NCommander waits for seb128 
<NCommander> like I said
<NCommander> CDBS is evil ;-)
<NCommander> *shot*
<persia> No reason not to add it there as well.  CDBS allows adding additional targets.  While I don't recommend going to the extent of sendmail, some are certainly OK.
<seb128> persia: it's already there
<NCommander> persia, should I download the sendmail package and take a look?
<persia> seb128: Yep.  My backscroll reading isn't keeping up with my slow typing :)
<seb128> NCommander: the update looks good, I'll upload, libspectre will need to be promoted before it can build though so it's time to start on the main inclusion report ;-)
<persia> NCommander: Only if you want a counter-example
<NCommander> seb128, want help?
<seb128> NCommander: if you could write the mir for it that would be nice
 * NCommander copies the template to a new wiki page and begins working on it
<seb128> NCommander: no need to copy the template, if you create MainInclusionReportComponent page the wiki lists the templates matching the name that you can use and you just have to click on the one to use ;-)
<NCommander> er
<NCommander> too late
<Riddell> BenC: linux-restricted-modules isn't on the CD currently, do you know what brought it in before?
<seb128> NCommander: that's for the next one ;-)
<BenC> Riddell: linux-image?
<BenC> Riddell: I mean "linux" meta package, or maybe "linux-generic" meta package
<ogra> mdz, hmm, i think discover was just deliberately demoted to universe in intrepid ... i'm not sure what to do about hotkey-setup now
<Riddell> BenC: that brings in linux-restricted-modules-2.6.26-4-generic but not l-r-m-common
<ogra> (i did the merge so feel kind of responsible for the breakage)
<mdz> ogra: fix it to stop using discover?  it's doing the wrong thing anyway
<BenC> Riddell: ah, missing dep on my part then
<ogra> ah, k, i'll look into that
<mdz> ogra: it wants to know which driver X is using
<mdz> ogra: and if it can't find out from xorg.conf, it tries discover
<BenC> Riddell: I can upload a new lrm quickly, or you can get lrm-common added to the cd manually to get things moving
<ogra> i wonder anyway if we stll need it with hal-input
<mdz> discover isn't actually very good at that
<mdz> I assume it got harder because xorg.conf is emptier
<Riddell> BenC: I think a quick l-r-m upload would work
<ogra> yeah
<mdz> maybe bryce has an idea
<ogra> but looking at all the fdi commits hal saw the last months, the IBM situation might already be handled there anyway
<mdz> yeah, hal fdi is a better place for all this anyway
<ogra> not sure about other stuff hotkey-setup is used for
<ogra> i'll look into that if i'm home next week and see if we can drop it completely ... that goes actually hand in hand with some plans persia and i discussed for certain special input devices anyway
<mdz> ideally I think hotkey-setup should go away
<ogra> right, but to unbreak the CD i'll just coment out the dicover call for now
<ogra> thats something i can do immediately
<ogra> (not sure how useful it is without that though :) )
 * ogra lives with the curse to have a laptop where everything works :)
<BenC> If someone tells me how to get hal to do what hotkeys-setup does, I'm willing to convert it
<persia> ogra: Do you anticipate we'll get enough input changes for intrepid?  I had the impression it was more an intrepid+1 goal.
<ogra> persia, but we have to start at some point
<ogra> and there was the plan to switch all of X input to hal-input anyway at UDS
<persia> Ah.  Good.  I missed that UDS session.  If that's already planned, I'm less worried.
<ogra> so at least the basics will be covered i assume
<ogra> i think that was one of the sessions where tons of notes were taken that got lost in the depths of gobby
<ogra> Keybuk, was there irc
<ogra> *iirc
<ogra> and cjwatson ... i entered only at the end of the session since i was hogged in another one
<persia> Wasn't there a backup gobby store somewhere from which to recover the lost text?
<ogra> yes, but not all was recovered
<persia> Oh :(
<ogra> anyway, hal-info should have tons of fdi files to cover the most input things we need already
 * ogra mumbles and decides to set up his intrepid vm with the hardy kernel for now ...
<NCommander> seb128, A page with the name 'MainInclusionReportlibspectre' already exists. Try a different name.
<NCommander> I can't win
<seb128> NCommander: weird
<seb128> https://wiki.ubuntu.com/MainInclusionReportlibspectre gives a "This page does not exist yet. You can create a new empty page, or use one of the page templates. Before creating the page, please check if a similar page already exists. "
<alex-weej> damnit
<NCommander> yeah
<NCommander> THe wiki not having fun
<seb128> hum, https://wiki.ubuntu.com/MainInclusionReportLibspectre
<alex-weej> can someone tell me off hand... does ubiquity ask you for your keyboard model?
<alex-weej> or just the layout?
<seb128> NCommander: sorry about that, looks like somebody already did the case and the case is different
<NCommander> seb128, oh geeze
<NCommander> I can't get a break today
<seb128> note for next time "check for existing reports before starting writting one" ;-)
<NCommander> I thought you did check, hence why saying one had to be done
<seb128> and it has been accepted and promoted according to https://bugs.edge.launchpad.net/ubuntu/+source/libspectre/+bug/236111
<ubottu> Launchpad bug 236111 in libspectre "main inclusion report for libspectre" [Undecided,Fix released]
<NCommander> http://paste.ubuntu.com/29627/ - care you look it over, since its still a learning expierence
<BenC> Riddell: uploading
<cody-somerville> slangasek, Do you know why Xubuntu isn't on the ISO tracker?
<seb128> NCommander: yeah, I looked at it on the wiki already, looks good, sorry about the work duplication
<NCommander> its fine
<NCommander> Its a learning experience
<BenC> slangasek: new lrm uploaded to get proper lrm-common deps for lrm-flav packages
<seb128> NCommander: on the good side I'm about to upload the new evince version, thanks for your work ;-)
<NCommander> Any MOTU should have a full set of skills
<seb128> right
<NCommander> I already have experience hating dak ;-)
<slangasek> cody-somerville: because it has livefs build failures that point to a problem which is likely to also make the alternates uninstallable
<slangasek> cody-somerville: http://people.ubuntu.com/~ubuntu-archive/livefs-build-logs/intrepid/xubuntu/20080722/livecd-20080722-i386.out
<ogra> NCommander, but most MOTUs simply start with a subset of skills, you cant know everthing in the beginnig :)
<slangasek> BenC: uploaded to where?  hardy, intrepid?
<ogra> debian :P
<BenC> slangasek: intrepid, sorry :)
<alex-weej> ogra: i was gonna say last night, looking at pipermail, it doesn't seem to indent more than 4 levels... ever...
<NCommander> ogra, it helps I created and ran an unoffical debian testing for m68k
<NCommander> Hence why I have run dak
<NCommander> Hence why I got sick of trying to remember which women did what
<ogra> alex-weej, hmm, you are right, sorry then :)
<ogra> (that doesn fix the filtering though ... )
<alex-weej> ogra: are you using Evo?
<ogra> yes
 * NCommander can only remember what britney and madison did
<alex-weej> i used to use Evo up until a few months ago and i always used "Reply to All" even then
<ogra> but i know TB users with reply to list extension and kmail users have the same prob
<alex-weej> and i don't remember it breaking any of my filters
<alex-weej> i was using vFolders to filter on "list"
<alex-weej> let me see...
<ogra> the way you do it simply wipes the X-Mailing-List from the headers
<alex-weej> that's probably a bug in gmail then. damnit.
<seb128> alex-weej: ubiquity ask you for the layout, not the model
<alex-weej> seb128: thanks for the confirmation, as i suspected
<alex-weej> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/251187
<ubottu> Launchpad bug 251187 in ubiquity "Ubiquity does not ask for keyboard model" [Undecided,New]
<ogra> likely, gmail is bad with lists anyway ... (unless you are using google lists i bet :) )
<seb128> most people will not care about keyboard modeles or don't know what to put there
<NCommander> seb128, says you and your QWERTY keyboard, I'm quite happy being DVOARK
<NCommander> ;-)
<alex-weej> ogra: i guess pipermail gets it right because it has In-Reply-To: <1216748124.17165.121.camel@osiris>
<NCommander> (actually, the dvorak users outnumber the QWERTY users in our local LUGS)
<seb128> NCommander: I'm using azerty not qwerty :-p and dvorak is a layout no?
<ogra> yeah, it sorts by msg id
<NCommander> seb128, d'oh. If I didn't just shoot myself in the foot
<alex-weej> anyone know what's going on with the logout dialogue stuff in Intrepid
<alex-weej> has the patch just been dropped inadvertently or are we going back to upstream?
<alex-weej> and if so, they have bugs to be fixed.
<cody-somerville> slangasek, was there some sort of e-mail or notification sent out?
<slangasek> BenC: so is this lrm-common upload something I need to roll into the alpha-3 images?  I don't know what problem you're fixing, though I've seen comments that lrm is missing from some CDs
<slangasek> cody-somerville: not by me; and the automated emails only report failed CD builds, they don't tell you when a CD build is using a stale livefs
<zyga> mvo: is the code okay or should I work on something more?
<BenC> slangasek: yes...the dep was required to pull everything in
<slangasek> BenC: ok, thanks
<BenC> slangasek: lrm modules are there, but without lrm-common, there are no firmware blobs and no linked lrm modules
<slangasek> cody-somerville: do you or someone else have time to look into this livefs failure today?  And is there a role address you would like me to send mail to about such issues if I notice them and you're not aroud?
<alex-weej> mvo: in the synaptic source, we have tango icons for everything yet they're not used... bug or just ENOTIMPLEMENTED?
<cody-somerville> slangasek, My e-mail is forwarded to my blackberry so if you mail xubuntu-devel@lists.ubuntu.com then I'll get it
<slangasek> ok
<cody-somerville> slangasek, If you need to get in contact quickly, I have a second e-mail which is priority delivered to my blackberry.
<cody-somerville> slangasek, I've sent you that e-mail address in a private query.
<mvo> zyga: looks good to me, I'm not sure if we really need the custom crash handler now that apport is availabe, but it should be fine
<mvo> alex-weej: not implemented
<zyga> mvo: the crash handler is the same, the only difference is lsb_release information
<zyga> (and moving it to util.py
<alex-weej> mvo: ok
<zyga> hmm, how does apport help?
<zyga> (technically python never crashes)
<mvo> zyga: I know, while looking at it, I was wondering if we should keep it, but I'm fine with having it
<mvo> zyga: I merged it into the ubuntu branch, many thanks!
<zyga> thank you :-)
<NCommander> seb128, anything else for me to do?
<zyga> mvo: one thing makes me curious though... is there any support for apport-like system for python crashes?
<seb128> NCommander: easy or hard tasks? ;-)
<NCommander> seb128, whatever it takes to prove my skills ;-)
<mvo> zyga: yes and its enabled by default on the devel release, it installs a system-wide crash handler as part of the apport package
<seb128> NCommander: as said before there is gucharmap to update to 2.23, I think they changed the soname again (not sure now about this one) and they added python bindings which should be some packaging fun (adding a new python-gucharmap, using python-central or python-support, etc)
<seb128> NCommander: otherwise g*mm need to be updated which is probably easier if you don't dislike c++ bindings ;-)
<NCommander> Python or C++ ...
<NCommander> Got any pure ASM ;-)
<sabdfl> thorwil: yes, am travelling at the moment
<seb128> NCommander: on the "would be nice to do but not trivial list" there is also the new epiphany-browser 2.23.5, it has a webkit backend only but we likely want to keep epiphany-gecko too for a while, so that will likely require packaging the new version as a different source
<NCommander> seb128, I assume webkit would probably need a main inclusion request?
<NCommander> and http://gucharmap.sourceforge.net/ - gucharmap seems to not have been updated in quite awhile
<seb128> NCommander: no, that has been done some days ago, epiphany-browser builds epiphany-webkit at the moment in intrepid
<seb128> NCommander: http://download.gnome.org/sources/gucharmap/2.23/gucharmap-2.23.4.tar.gz
<seb128> most GNOME projects have no updated websites
<seb128> they tend to just code, use bugzilla and upload tarballs ;-)
<NCommander> lol
<NCommander> ok, lets see here
<NCommander> Well, this hsouldn't be too bad ...
<stgraber> BenC: something looks buggy in 2.6.26-4 framebuffer handling
<stgraber> BenC: booting an intrepid system gives you no usplash but a black screen instead (no boot messages)
<seb128> NCommander: probably not too difficult no, and a good occassion to look at the python policy if you didn't yet ;-)
<stgraber> BenC: loading with vga=791 and no "splash" gives you a black 1024x768 screen
<NCommander> Those binding look fun
<mvo> cjwatson: does ubiquity write the proxy information only to /etc/apt/apt.conf? or does it also write it to a place in /etc/default (or /etc/environment) or something similar?
<stgraber> BenC: I get that in kvm but mdz and davmor2 seem to have the same on real HW
<slangasek> BenC: ^^ this is me getting out of the middle of the conversation between you and stgraber :)
<NCommander> seb128, care to explain the ltmain_as-needed.patch? seems like a clunky way to pass a linker flag ...
<NCommander> seb128, upstream has a nice shiny new libtool ltmain.sh
<seb128> NCommander: that comes from debian, apparently reordering is required to get --as-needed to do its job
<NCommander> Whats that do?
 * NCommander loves how these patches have no comments attached to them
<seb128> that limits inflated depends
<seb128> man ld and search for --as-needed
<NCommander> seb128, I see
<seb128> NCommander: I think the corresponding bug is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=347650
 * NCommander sees if LDFLAGS work now since libtool got updated
<ubottu> Debian bug 347650 in libtool "libtool: Incorrect argument reordering" [Important,Open]
<BenC> stgraber: does it stay black (never shows text console)?
<seb128> NCommander: speaking about comments, https://wiki.ubuntu.com/UbuntuDevelopment/PatchTaggingGuidelines, something we don't do enough but that we should try to do, documenting the changes ;-)
<NCommander> I am always very good at filling out dpatch ehaders :-P
<NCommander> seb128, I can't figure out if its fixed in libtool 1.5.28-0ubuntu1
<NCommander> Off hand, I'm going to say no though
<seb128> NCommander: I don't think that's fixed no, you can try to drop the change, build the package and see the depends difference between the current version and the new one
<seb128> or try to apply the patch, do a build using it and one not using it and debdiff those
<NCommander> its never easil :-P
<NCommander> seb128, it doesn't apply cleanly
<NCommander> Nor does the lp intergration patch
<seb128> right, but it's easy enough to update
<NCommander> the lt one, or the lp one :-P
<seb128> that's just 2 code blocks to copy to the similar context
<seb128> both
<NCommander> meh
<NCommander> I'm too tired to work on this right now
<NCommander> I'll attack it when I'm slightly more work
<NCommander> ... awake
<NCommander> Haw, proving my point!
<seb128> alright ;-)
<seb128> you already did quite some work today
<NCommander> seb128, well, yeah, I implemented openid logins for REVU (and became a REVU hacker ;-))
<NCommander> seb128, I also added a PPA importer, and apt-get source support to revu
<NCommander> or, almost got the last one
<calc> seb128: so should i be changing the %U to %f for OOo (remember we talked about this the other day?)
<calc> seb128: one of you mentioned it might be better to do some stuff to nautilus instead?
<seb128> waouh, lot of revu changes ;-)
<NCommander> seb128, http://nemesisnetworks.com/revu-openid
<NCommander> ;-)
<seb128> calc: maybe mail ubuntu-desktop list about that just to get comments before doing it
<calc> ok
<calc> seb128: is it a lowercase or uppercase f?
<seb128> depends of what you want
<calc> ah, probably should look at the specs ;-)
<seb128> http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-1.1.html
<calc> thanks for the url :)
<seb128> %f is one file, %F a list of files
<seb128> probably %F if you had %U before
<calc> yes it looks like %F is the correct one, thanks for the help :)
 * calc sending an email to the list now
<seb128> slangasek: the session change is not really a "bug"
<slangasek> seb128: ok; do you have a better place to track it other than a bug report, such that the rest of the team knows it's an outstanding issue? ;)
<seb128> not really, though I don't really consider it as an issue ;-)
<seb128> but point, we should have a bug milestoned about "what to do to the session dialog"
<slangasek> heh, ok
 * slangasek nods
<seb128> I'll open one and reply on the list
<slangasek> cheecs
<slangasek> cheers, too
<stgraber> BenC: sorry I was away, when starting with vga=791 I get nothing until X starts. Without vga=791 and using usplash I just get a shell cursor at the top right corner, not even blinking IIRC and that's it. No text displayed until X starts.
<calc> any big breakage in intrepid for a i945 laptop? i'm considering upgrading my dev machine to intrepid but don't want it to fall apart on me
<calc> it has intel graphics
<seb128> slangasek: https://bugs.edge.launchpad.net/ubuntu/+source/gnome-session/+bug/251211
<ubottu> Launchpad bug 251211 in gnome-session "intrepid uses the upstream session dialog" [Undecided,New]
<BenC> stgraber: but does switching to the console after X starts give you a login prompt?
<pitti> superm1: I just commited an 1-line fix for jockey's fglrx handler which (I think) is everything it takes to make it work in intrepid
<stgraber> BenC: well, I have no idea how I can do ctrl+alt+f1 in kvm without doing that on the host system.
<stgraber> davmor2: can you try that on real HW after the QA meeting ^^
<BenC> stgraber: keyboard grab should isolate it (or can kvm synthesize the key strokes somehow?(
<pitti> superm1: would you be up for a quick test?
<davmor2> stgraber: on what sorry?
<mvo> stgraber: you can do "ctrl-alt-2" to enter a monitor mode
<mvo> stgraber: then run "sendkey ctrl-alt-f1"
<mvo> that should work
<BenC> stgraber: you could also try "splash quiet single" on the command line to avoid going into X
<stgraber> ctrl+alt+f1 doesn't seem to work, keyboard stop working but I still see the X server, that's a bit weird
<slangasek> seb128: thanks :)
<davmor2> BenC: stgraber: is this to sort out the issue with usplash?
<slangasek> yes
<davmor2> when do I hit ctrl+alt+f1 as soon as grub finishes?
<davmor2> cursor does flash just slowly
<stgraber> so during the whole boot process you don't see anything other than a cursor (doesn't blink here) ?
<stgraber> then when you get to gdm/kdm, can you switch to tty1 (ctrl+alt+F1) ?
<davmor2> right I hit it on hw with a Kubuntu install (same issue) and I get a message that says there is no suitable usplash image found for 640x480
<kelemengabor1> mvo: hi, i'd like to ask some questions about ddtp-ubuntu
<stgraber> davmor2: ah ? so you can switch to tty1, that's good :)
<kelemengabor1> particularly, i'm interested in the code that generates the po files
<stgraber> oh yes, I can also reproduce using a livecd image
<stgraber> "usplash: No usable theme found for 640x480"
<kelemengabor1> I fount this: http://people.ubuntu.com/~mvo/bzr/apt-ddtp-tools--main/  - is this it?
<stgraber> so that's usplash bug it seems
<mvo> kelemengabor1: yes, that is the code
<kelemengabor1> great :)
<mvo> kelemengabor1: there is a file "UbuntuChecklist" that explains the steps that are needed and what tools are used
<mvo> kelemengabor1: what do you plan to do with it :) ?
<BenC> davmor2: if the message is usplash doesn't have a suitable image, that's a usplash bug
<kelemengabor1> well, we want to add package name information to the po file
<stgraber> pitti: ^
<kelemengabor1> to make easier the cooperation between other distros
<mvo> kelemengabor1: aha, good idea!
<BenC> stgraber, slangasek: The message davmor2 reported is a usplash bug and sounds like no theme is installed (or the theme is messed up somehow)
<pitti> hi stgraber
<kelemengabor1> mvo: we faced a problem, that ddtp is huge
<mvo> kelemengabor1: let me know if you have anything for me to merge, I had some other ideas, but launchpad is not that flexible
<stgraber> BenC: I checked, the theme is installed (so is it on my lappy)
<slangasek> BenC: ok, progress \o/
<stgraber> pitti: "usplash: No usable theme found for 640x480"
<mvo> kelemengabor1: I would love to see the strings split per package instead of this giant table
<BenC> stgraber: must dig deaper into usplash then
<pitti> stgraber: uh..
<kelemengabor1> and we want to simply reuse existing translations from fedora and suse
<stgraber> pitti: that's with usplash and usplash-theme-ubuntu installed
<mvo> kelemengabor1: do you know about http://ddtp.debian.net/ddtss/index.cgi/xx ?
<kelemengabor1> mvo: what? 5k small po files instead of one huge with 15k strings?
<pitti> usplash: can't get console font: Invalid argument
<pitti> usplash: No usable theme found for 1024x768
<kelemengabor1> no
<pitti> stgraber: I get that for sudo ./usplash-test.sh -v
<mvo> kelemengabor1: afaik the code for this is available
<kelemengabor1> will see
<pitti> stgraber: hm, lemme try something
<stgraber> pitti: we then just get a black screen instead of usplash causing things like entering the passphrase for encrypted LVM to fail :(
<mvo> kelemengabor1: for ubuntu having it as a extra po file in launchpad/rosetta for each source package would be great because we have the po files there anyway, that would give people a easier time to translate the descriptions along the way when they transate the app itself
<pitti> right, I'm currently running without "splash" in  intrepid, since it's totally broken for me as well
<pitti> stgraber: can you try a no-change rebuild of usplash-theme-ubuntu?
<pitti>   * usplash-theme.h: Add a "void* private" pointer to the theme, so that
<kelemengabor1> mvo: if i had a team with lots of people...
<pitti>     themes have an easy way of storing some custom data. Bump THEME_VERSION to
<pitti>     3 to reflect the ABI change. Thanks to David HÃ¤rdeman for the patch!
<BenC> stgraber: that sounds like a bug in itself...lvm password shouldn't fail if usplash fails
<pitti> ^ I tested that usplash still worked without rebuilding -theme-ubuntu after that patch, and it did work at the time; but maybe it stopped
<mvo> kelemengabor1: indeed, keep me updated :)
<pitti> stgraber: without "splash" I get text-mode prompt for luks passphrase
<stgraber> BenC: indeed, it should bring you back to standard text-mode boot and in this case you get prompted for the passphrase (that's how I do on my lappy)
<BenC> pitti: was that private pointer added to the end of the struct?
<stgraber> pitti: me too
<pitti> BenC: yes (deliberately)
<kelemengabor1> but currently, what we do is organize IRL translation weekends, and assign work to volunteers, adding 400 packages to this equation would be overcomplicated
<pitti> oh, hm, I'm currently running on 2.6.24, so usplash should actually work
<BenC> pitti: guess check for NULL on older ones didn't work though
<BenC> pitti: does usplash have a check for which ABI the theme was compiled against?
<kelemengabor1> so i think splitting it is not that good idea
<pitti> BenC: (after some hours my computer gets unbearably slow with 2.6.26-4)
<kelemengabor1> perhaps the suse way, by splitting it alphabetically
<pitti> BenC: since it worked at at that time, I guess it's only a compile-time check
<kelemengabor1> is somewhat more manageable
<slangasek> pitti: blink, is the 2.6.26-4 kernel built without CONFIG_FEED_THE_HAMSTERS?
<pitti> BenC, stgraber: looks like a rebuild fixes it, uploading
<slangasek> pitti: did you get the bug # for that one?
<kelemengabor1> but lots of small units to handle would make me crazy
<pitti> slangasek: :/ I wasn't able to track it down; the load is < 1, no particular CPU usage
<pitti> slangasek: bug# for usplash? haven't looked yet
<pitti> stgraber: ^ got a bug #?
<stgraber> pitti: cool, I just pushed the theme to my build server so I can test here (without waiting > an hour)
<kelemengabor1> anyway, another question: how often are the ddtp po files updated, and translations pushed to production?
<stgraber> pitti: sort of: bug 249037 (the user may have mixed two different problems though)
<ubottu> Launchpad bug 249037 in usplash "After upgrade, nothing shows up on screen during and after boot" [Undecided,New] https://launchpad.net/bugs/249037
<stgraber> is X seems to be broken as well but the boot part sounds like that usplash bug
<pitti> hm, I think I just upload it without a bug # now; I searched the usplash and usplash-theme-ubuntu bugs, nothing really 100% matching
<kelemengabor1> mvo: where is that UbuntuChecklist file you mentioned?
<slangasek> ok
<pitti> btw, what happened to seahorse? I don't get an agent...
<pitti> oh, PEBCAK
<mvo> kelemengabor1: isn't it in the toplevel of the checkout?
<kelemengabor1> well, i did not checked it out
<kelemengabor1> yet
<kelemengabor1> but can't see it on the web
<mvo> kelemengabor1: yeah, you need to checkout
<mvo> kelemengabor1: or get / pull
<pitti> anyone here with an Ati card (fglrx) who is willing to test a new jockey on intrepid?
<pitti> slangasek: ^ FYI, I'd like to get that test before I upload
<pitti> slangasek: as usual, things took a little longer to get everything in shape; nvidia reasonably works now
<slangasek> I have no such hardware, alas
<stgraber> pitti: fglrx is broken in Intrepid due to the new X server
<pitti> slangasek: lucky you :)
<pitti> stgraber: oh, ok; so nothing to test ATM?
<slangasek> lucky, or picky about my hardware :)
<kelemengabor1> mvo: got it, thanks
<stgraber> pitti: well, I can try it if you want but that will give me a xorg module I can't load anyway
<pitti> so I guess I can just as well upload now, to at least make the nvidia users happy
<pitti> stgraber: if it doesn't work anyway, we can test it later, too, I think
<slangasek> cody-somerville: not sure if I saw an answer from you about whether you're in a position to work on the livefs build failures today?
<stgraber> pitti: indeed, next ATI module should be in a bit less than a month
<stgraber> so until that I have to use the good old radeon driver :)
<slangasek> mdz: did you find that the kernel lockup was reproducible/debuggable?
<cody-somerville> slangasek, I will be able to this evening.
<slangasek> cody-somerville: ok, cheers
<cody-somerville> :)
<slangasek> soren: ubuntu server images disabled for respin, due to the pervasive usplash problem
 * cody-somerville pokes mr_pouit and gpocentek to see if they can help in the mean time.
<mdz> slangasek: yes, I just posted to -devel@ about it
<mdz> slangasek: and targeted the bug for intrepid
<slangasek> pitti: so you said you have splash off in intrepid; is whatever bug is preventing you from using it targetted to intrepid?
<slangasek> mdz: ah, thanks; mail hasn't arrived yet
<pitti> slangasek: last time I disabled it was when it caused X to crash
<stgraber> pitti: confirmed, usplash works again after a nochange rebuild
<pitti> slangasek: I just enabled it again, and will do a test-boot in some minutes
<slangasek> pitti: thanks
<mdz> slangasek: I just filed bug 251227 about my usplash issue on the desktop CD
<ubottu> Launchpad bug 251227 in usplash "No usable theme found for 640x480" [Undecided,New] https://launchpad.net/bugs/251227
<slangasek> mdz: darn, pitti just uploaded the fix for that without a bug reference ;)
<pitti> mdz: nice race condition; right before I uploaded, I didn't find a matchign bug :/
<mdz> slangasek: I also have/had an issue with screen corruption when it does run
<pitti> yeah, me too, but I still think that this is a kernel problem, since it works fine with 2.6.24
<slangasek> mdz: does "have/had" mean it's confirmed to be ongoing?  I know we had a bug report about that for alpha-2, but I don't see it open anymore
<slangasek> Riddell: ^^ bug #251223 for mdz's kernel crash which might be the same one you're seeing
<ubottu> Launchpad bug 251223 in linux "BUG: Dentry ffff81003ac17410{i=161b,n=cow} still in use (1) [unmount of rootfs rootfs]" [High,New] https://launchpad.net/bugs/251223
<stgraber> slangasek: we don't have working usplash at the moment so hard to reproduce :)
<slangasek> well, yes.
<stgraber> slangasek: I didn't notice any screen corruption in the kvm I booted a minute ago with the fixed usplash but I may just be lucky ...
<mdz> kudos to the reporter of bug 243682 for attaching a video clip demonstrating the problem
<ubottu> Launchpad bug 243682 in usplash "[Intrepid] Usplash Screen Corruption" [Medium,Confirmed] https://launchpad.net/bugs/243682
<mdz> but it's not the same bug as mine
<mdz> oh, actually, the shutdown video clip is very similar
<mdz> to what I see at startup
<tyfon> hmm on the mini.iso and netboot via pxe in a kvm the dhcp client gets a new address every second or so .. during the install
<tyfon> ls
<BenC> tyfon: could that be a misconfigured dhcp server?
<tyfon> i don't think so, it works fine on all my other computers and hardy running in kvm
<slangasek> if you somehow have two dhcp clients running on the same interface, that could explain it
<tyfon> well the br0 interface in the hardy host is configured as dhcp, but the kvm guest has a very diffrent mac and gets a diffrent ip
<slangasek> right, I meant two dhcp clients running within the guest itself
<tyfon> nope, ps aux | grep dhclient only reports one..
<slangasek> a buggy dhcp server would also certainly account for it, if for some reason it sets a low lease for particular macs
<tyfon> kind of strange though, i will see if it continues when the guest is installed
<pitti> hmm, no luck
<pitti> I tried new usplash-theme-ubuntu after update-initramfs -k all -u
<pitti> works perfectly on hardy kernel, but on current intrpeid kernel I just get red-white stripes in text mode, and no usplash at all
<pitti> hm, I still have uvesafb blacklisted, maybe that's it
<pitti> BenC: do we install v86d now? last time, I tried all possible combinations of uvesafb and v86d, but that was the time when usplash still worked (although only corrupted)
<pitti> so, "uvesafb blacklisted" and "no v86d" -> usplash corrupts screen for me
<pitti> (dell latitude, intel945GM)
<tyfon> hmm i think this might be a clock issue in the kvm thing :p.. i get "Login timed out after 60 seconds" about 0.5 sec after i type inn the username in the console
<emgent> http://blogs.gnome.org/dcbw/2007/10/15/networkmanager-07-is-the-new-chuck-norris/
<emgent> big lol!
<mario_limonciell> pitti, sure i'll take a look
<pitti> mario_limonciell: stgraber told me that the current fglrx driver is broken ATM?
<mario_limonciell> pitti, well with the current xorg yeah doesnt boot fully to X
<mario_limonciell> was wanting to make sure detection worked, and booting with the old X server until fglrx is rev'ed for the new x server
<pitti> mario_limonciell: that would be useful indeed
<BenC> pitti: then that sounds less like a kernel bug and more like a usplash issue to me
<slangasek> mathiaz: where can I find the ServerGuide, to review the samba section?
<mathiaz> slangasek: http://doc.ubuntu.com/ubuntu/serverguide/C/
<mathiaz> slangasek: doc.ubuntu.com has the latest version of all the work from the documentation team
<slangasek> ok
<pitti> BenC: so I did some experiments: uvesafb+no v86d -> I get the kernel complaints about "v86d not found blabla", text mode; uvesafb+v86d -> "cannot detect vga mode" and usplash wants to start up as 320x200 (fails, no theme); howver, it works fine in all configurations when I start usplash out of the running system; so maybe something is missing in the initramfs?
<pitti> I'm still unsure what role uvesafb and v86d have; they primarily seem to affect initramfs booting; since hardy's kernel works all the time (even with intrepid-generated initramfs), I guess .26 moved some important bits into userspace?
<pitti> does usplash work for anyone else in intrepid?
<tyfon> does not work in my kvm intrepid
<tyfon> but anyway 2.6.26 seems to have major timer issues running under kvm
<DktrKranz> pitti, FYI, it doesn't work with 2.6.24 kernels on intrepid
<DktrKranz> as much as 2.6.26
<pitti> DktrKranz: "no usable theme found"?
<DktrKranz> pitti, yes, and I see also "no resolution available" or similar
<pitti> DktrKranz: that's fixed in the latest usplash-theme-ubuntu
<slangasek> mathiaz: ok, where do I send bugs about grammar errors? :-)
<mathiaz> slangasek: it seems that doc.ubuntu.com is not up-to-date
<slangasek> oh :-)
<mathiaz> sommer: ^^
<mathiaz> sommer: I'd submit the bzr branch to LP
<mathiaz> slangasek: we (me and sommer) are discussing the most efficient way to get reviews on the server guide done
<slangasek> ok
<sommer> mathiaz: gotcha, but I think some folks would be more likely to give reviews if they didn't have to involve bzr (or any commands other than a browser)
<tseliot> ï»¿pitti: about --debug mode, maybe there's a problem with policyKit. The non-debug mode worked as if it didn't have the authorisation to install the packages. Maybe you should let Jockey display a dialog if policyKit fails. Just a thought.
<mathiaz> slangasek: grammar errors -> fix them in the bzr branch and submit it
<slangasek> sommer: well, I'm more likely to give you a *useful* review if I don't have to touch my stinking browser and can just commit patches ;)
<slangasek> where's the bzr branch then?
<mathiaz> slangasek: https://code.launchpad.net/~ubuntu-core-doc/ubuntu-doc/ubuntu-intrepid
<mathiaz> slangasek: you'll get all of the ubuntu documentation
<slangasek> ok
<slangasek> right
<slangasek> which ISTR is painful :P
<mathiaz> slangasek: I'm looking into splitting the server guide into it's own branch
<mathiaz> slangasek: things have improved since intrepid - it doesn't take as much time as it used to
<slangasek> mathiaz: does the branch still include autogenerated files?
<mathiaz> slangasek: a lot of the history hasn't been dropped IIRC
<sommer> mathiaz: correct
<sommer> should only take a couple of min
<pitti> tseliot: the frontend should just crash if you don't get the authorization
<mathiaz> slangasek: I don't know - the branch is 87M now
<mathiaz> slangasek: instead of the 400/500 M it used to be for hardy
<slangasek> heh
<tseliot> ï»¿pitti: really? Aren't you using something like "if authorised:"
<pitti> tseliot: I just try, and if I get a PermissionDenied dbus error, I do ObtainAuthorization and try again; but I don't intercept errors from the second attempt
<tseliot> ï»¿pitti: ah, ok
<sommer> mathiaz, slangasek: another issue with reviewing the docs from bzr is that you need to view them in yelp, and some peeps don't like gnome shtuff
<mathiaz> sommer: is yelp really needed ?
<slangasek> sommer: well, /I/ don't have to, I'm happy to view and edit raw xml ;)
<mathiaz> sommer: using yelp is to make sure that they look good in yelp
<sommer> that's true too
<sommer> mathiaz: it also lets you focus on the content
<mathiaz> sommer: I'd rather focus on reviewing the *content*, rather than the *look*
<sommer> mathiaz: right, I was just thinking that sometimes the xml gets distracting
<sommer> either way... I'm not really even sure how many reviews have been done using the doc.u.c anyway :-)
<mathiaz> sommer: hm - which tools are you using to edit the xml ?
<mathiaz> sommer: may be we should advise reviewer to use a tool that focuses mainly on the content
<sommer> mathiaz: I used vi during hardy, but for whatever reason the spell checking didn't work so I've switched to gedit
<sommer> mathiaz: I guess I like the idea of having the development content available from multiple sources
<slangasek> sommer, mathiaz: so whose idea was it to suggest the use of security=share here...?
<sommer> slangasek: mine, as there was a couple of bugs about it
<slangasek> sommer: ok, well security=share is crap
<sommer> slangasek: it is stated that it's not secure, and there's a whole section on security... but that was kind of an iffy thing
<sommer> slangasek: the use case I was thinking of was home user situation
<slangasek> anything you want to achieve using security=share can also be done with securty=user, and then you don't have to completely reconfigure your security model to switch between use cases
<sommer> slangasek: so with multiple users using multiple workstations you wouldn't have to setup a username for each user on the server?  or I guess they could all use the same username
<sommer> slangasek: but if they're all using the same username, why have a username?
<sommer> slangasek: least that was my thinking
<mathiaz> sommer: couldn't anonymous share be used to achieve the same ?
<slangasek> sommer: guest ok = yes; map to guest = Bad User; force user = user-to-access-as (the last part only if there's a reason not to use 'nobody')
<sommer> ooooohhhh, gotcha
<sommer> okay, well I can re-write that
<sommer> so why is security=share even there?  I guess I've totally missed the plot on that one
<slangasek> sommer: security=share is the way Win9x did it; and samba is old, so it also supports the Old Way. :)
<slangasek> but I think you can't even configure XP/Vista to use the share-based security model if you wanted to
<sommer> slangasek: I see, ya that's about the time I was first learning it
<sommer> slangasek: I'll fix those sections... does the "no-login", then security, samba as domain controller format work?
<slangasek> I don't think I've gotten to that yet
<sommer> okay, well if you find any other issues please let me know
<sommer> slangasek: thanks for reviewing it :)
<slangasek> sure
<slangasek> sommer: oh, chmod 777?  That's not a good thing either; that's definitely a security hole if there are any untrusted local users
<sommer> slangasek: will the "guest ok = yes; map to guest = Bad User; force user = user-to-access-as" take care of the need for that?
<slangasek> yes
<sommer> cool
<slangasek> then it just needs to be owned by user-to-access-as
<mario_limonciell> pitti, oooh, jockey has policykit support now? cool :)  well it detected fglrx correctly, but didn't install it for me.
<mario_limonciell> pitti, is there a debug mode to activate in jockey?  i didn't see one in jockey-gtk --help anymore
<kees> why did ffmpeg get split into ffmpeg-free and ffmpeg-debian?
<kees> oh, nm, just soyuz confusion.
<mario_limonciell> pitti, tseliot what was the plan for the metapackage that will grab the modaliases packages (nvidia-*-modaliases and fglrx-modaliases)?  perhaps lrm-common?
<mario_limonciell> pitti, tseliot oh nvm it looks like jockey recommends nvidia-common which depends on all the modaliases stuff
<mario_limonciell> pitti, so perhaps can you add a recommends to fglrx-modaliases too then to jockey-common?
<geser> slangasek: I assume the gnupg merge has to wait for alpha-3?
<persia> gnupg is definitely on the CD :)
<slangasek> geser: yes
<geser> slangasek: are there any issues with the merge or does it just need till the archive is open again?
<slangasek> geser: I'm not aware of any other issues
<slangasek> but then, I haven't looked too closely yet
<geser> ok
<tseliot> ï»¿mario_ï»¿limonciell: nvidia-common is a real package and contains a program which makes the transition to the new name schemes easier
<mario_limonciell> tseliot, ah didn't realize
<mario_limonciell> but nonetheless, that's how the modaliases are installed by default
<mario_limonciell> from that dependency
<tseliot> ï»¿mario_limonciell: right, and nvidia-common would fail otherwise
<mario_limonciell> tseliot, okay.  did you get to test out if installation via jockey worked properly, or only if it detected correctly after already installed?
<tseliot> ï»¿mario_limonciell: Jockey works well in debug mode in both cases. There must be something that prevents it from installing the driver in normal mode.
<mario_limonciell> tseliot, how do you activate debug mode?
<tseliot> ï»¿mario_limonciell: --debug
<mario_limonciell> yeah i tried that, but it said no such option: --debug
<tseliot> ï»¿mario_limonciell: the backend has that option
<mario_limonciell> tseliot, well how do you pass that to the backend then?
<tseliot> ï»¿mario_limonciell:kill any instance of jockey and type:
<tseliot> sudo /usr/share/jockey/jockey-backend --debug 2>&1 | tee /tmp/debug.txt
<mario_limonciell> tseliot, ah.  well and it appears to be working when i did it that way too in debug mode
<tseliot> then run jockey-gtk in another shell
<mario_limonciell> the progress bar isn't exactly accurate
<mario_limonciell> but it worked
<tseliot> the progress bar is WIP
<mario_limonciell> ah
<mario_limonciell> pitti, well as a summary to the above, fglrx detection and installation works properly in jockey debug mode, but in regular mode only detection works
<mario_limonciell> tseliot, did you make sure that nvidia-177-kernel-source was removed after you "deactivated" the driver?
<mario_limonciell> it looks like for me just xorg-driver-fglrx was, but the kernel source remained
<tseliot> ï»¿mario_limonciell: I reported the problem to pitti and he told me that he would deal with it
<mario_limonciell> tseliot, okay
<slangasek> sommer: I believe the 'acl' option is something that can be set on the ext3 filesystem itself rather than as a mount option, which seems preferable
<slangasek> sommer: (tune2fs -O acl)
<sommer> slangasek: ah thanks, that's simpler
<pitti> mario_limonciell: I didn't add the recommends yet, since fglrx is still in multiverse; you said I should keep it there for the time being?
<pitti> mario_limonciell: hm, weird; I have no real idea why it doesn't work in non-debug mode; I tried it with some small packages like pmount, and they install well
<mario_limonciell> pitti, yeah keep it there for the time being still
<mario_limonciell> i'm waiting for another soyuz bug to be fixed before i ask the tech board to have an acl for it
<mario_limonciell> and there's not a point to have it activated anyhow until it is compatible w/ xorg 1.5
<mario_limonciell> pitti, ah well in non debug mode i just got it to work, but only when i started the jockey-backend manually first
<mario_limonciell> the frontend didn't spawn it it appears
<pitti> now, that's curious
<pitti> mario_limonciell: if you run "jockey-gtk --list", you don't get a driver list, but an error?
<mario_limonciell> pitti, let me clear the jockey cache, all the fglrx stuff, and do a fresh boot to make sure there is nothing stale sitting around
 * pitti jumps for joy
<pitti> apport retracers are back!
<laga> yay!
<mario_limonciell> pitti, jockey-gtk --list worked correctly, but installing still didn't work.  i manually restarted jockey-backend myself (without debug this time) and it works
<mario_limonciell> so its just the spawned jockey-backend process that isn't working right
<pitti> mario_limonciell: how did the "didn't work" manifest? did you get a correct display of drivers in the UI? a progress bar for package installation?
<mario_limonciell> pitti, yes
<mario_limonciell> i got both, but the bar jumped by really quick without error
<mario_limonciell> and i checked installed packages, and they weren't installed
<pitti> mario_limonciell: did you get the PK auth both times?
<mario_limonciell> hm, i didn't pay attention
<mario_limonciell> i'll start again and see
<pitti> mario_limonciell: hang on
<pitti> mario_limonciell: I can reproduce it
<slangasek> sommer: I would also argue that netlogon belongs under /var/lib/samba, not in /srv
<mario_limonciell> pitti, ah okay good :)
<slangasek> sommer: does this scp-based BDC actually work?  I thought samba resets file permissions on its tdb files
<slangasek> sommer: also, I think this clobbers secrets.tdb, which is where the PDC/BDC trust is stored..
<pitti> dpkg: dpkg - error: PATH is not set.
<pitti> tseliot, mario_limonciell: ^ argh, I get that...
<pitti> so, that shouldn't be too hard
<tseliot> ï»¿pitti: great :-)
<pitti> ugh, seems dbus-spawned processes have a VERY limited initial environment...
<mario_limonciell> pitti, why aren't you using a gdebi like method for doing the install?
<pitti> mario_limonciell: the system dbus spawned program doesn't have any desktop access
<pitti> mario_limonciell: previous versions just called synaptic
<pitti> but that doesn't fit well into the unprivileged client <- dbus -> privileged backend model
<mario_limonciell> pitti, i thought gdebi used python-apt though (hence not really needing a gui)?
<pitti> right, using python-apt directly would be better, and it's on my list
<mario_limonciell> oh okay :)
<pitti> mario_limonciell: well, *actually* I want to make it work with PackageKit :)
<pitti> but I need to find a workaround for the dbus-glib bug which currently breaks that
<pitti> (I have a packagekit branch already)
<pitti> mario_limonciell: using apt-get was just a quick hack to get something for alpha-3
<laga> pitti: are you aiming for distribution independence by using PackageKit?
<mario_limonciell> pitti, yeah that makes sense
<pitti> laga: that's the plan; it's an upstream project now, and RedHat and OpenSuSE plan to adopt it
<pitti> mario_limonciell: there, fixed; thanks for pointing out!
 * pitti commits and uploads
<mario_limonciell> pitti, great, so it looks like that's the last piece to converting to this style of restricted drivers then  :)
<pitti> \o/
<pitti> mario_limonciell: astonishing that fgrlx just worked, I didn't test it at all
<tseliot> :-)
<tseliot> ï»¿pitti: having only 1 driver helps
<mario_limonciell> pitti, well i'm sure little things will pop up here and there, especially when the driver is functional with the rest of the ecosystem here
<pitti> mario_limonciell: oh, absolutely; also, there's still a ton of things on my TODO list already
<pitti> mario_limonciell: the current progress bar, as well as apt-get calling is horrible, and there are quite a lot of other bugs
<pitti> my aim today was to get *something* working for a3
<tseliot> ï»¿mario_limonciell: we can't complain since your driver and 2 out of 4 drivers of mine don't work ;)
<mario_limonciell> tseliot, well the nice thing about the way this is architected though; in the event that nvidia doesn't rev their driver by the time intrepid goes live (which would be very unfortunate), then these can easily be added into intrepid-updates via an SRU
<mario_limonciell> would just need to zero out the modaliases file for release, and then the SRU'ed one would contain valid modaliases
<pitti> uploadedkthxgoodnight!
<tseliot> ï»¿mario_limonciell: that wouldn't be necessary since those 2 drivers are legacy drivers and I doubt that their lists of pci-ids will change anytime soon
<tseliot> an SRU would be enough
<mario_limonciell> tseliot, yeah but you don't want to have a broken driver offered in the first place
<mario_limonciell> so that's why you would want those modaliases zero'ed out until it was fixed
<tseliot> ï»¿mario_limonciell: ah, I misread your message
<mario_limonciell> tseliot, and same thing goes for fglrx too
<tseliot> ï»¿mario_limonciell: let's wait and see. There's still time
<tseliot> good night everybody
<mario_limonciell> night tseliot
<tseliot> it's 23:46 here
<tseliot> night
<soren> slangasek: What is "the pervasive usplash problem" actually? I haven't really followed that.
<slangasek> soren: usplash was pervasively broken because of a theme incompatibility, now it's not
<soren> Oh.
<slangasek> (it may still be broken for other reasons, We Shall See)
<soren> Oh, so "disabled for respin" just means that spinning them was(/is) deferred for a bit and not completely cancelled for this alpha release then?
<jdstrand> hmm... php5 in intrepid won't build in my intrepid schroot
<slangasek> ok, who broke language-support-writing-en / myspell-en-au?
<jdstrand> configure: error: cannot run /bin/bash ../config.sub
<slangasek> sommer: https://code.launchpad.net/~vorlon/ubuntu-doc/ubuntu-intrepid for a few minor mergeable fixes
<jdstrand> kees: would you mind doing a quick build of php5 in an intrepid schroot? ^^
<slangasek> ArneGoetje: was there a milestone-critical reason for revving language-support-writing-en the day before during the freeze?  It's now uninstallable because myspell-en-au is in universe...
<ArneGoetje> slangasek: pitti did that...
<slangasek> pitti: gar
<slangasek> pitti: you were asking me about shoving in jockey, when you should've been asking me about this :)
<slangasek> well, it's just an override
<slangasek> so, fixed in the next pulse :/
<slangasek> (assuming it doesn't conflict with something else \o/)
<kees> jdstrand: giving it a shot, one sec
<jdstrand> kees: thanks-- if it actually starts compiling stuff, you can kill it
<kees> jdstrand: oh, does it fail out immediately?
<jdstrand> kees: early in the configure phase, yeah
<jdstrand> fakeroot debian/rules configure
<jdstrand> kees: that's enough ^^
<kees> hrm, my schroot is slightly behind, one sec
<jdstrand> kees: that might be a good thing!
<kirkland> mario_limonciell: hi, are you there?
<mario_limonciell> hi kirkland
<mario_limonciell> yup
<kirkland> mario_limonciell: bluez-utils question for ya
<kirkland>     - debian/rules:
<kirkland>       * Turn off hidd, dund, and pand to try the plugins again.
<kirkland>         If bug #191704 or #192043 crop up again, feel free to re-enable
<kirkland>         these.
<ubottu> Launchpad bug 191704 in bluez-utils "hidd binary removed form bluez-utils package unable to connect as a result" [High,Confirmed] https://launchpad.net/bugs/191704
 * jdstrand wonders if it's the recent autoconf update
<kirkland> mario_limonciell: no more dund in Intrepid...  what are these plugins you speak of?
<mario_limonciell> well that wasn't me that did that was it?
<mario_limonciell> i had done a more recent merge however
<kirkland> mario_limonciell: well, that's a not in your last merge
<kirkland> mario_limonciell: perhaps you copied it from elsewhere
<mario_limonciell> kirkland, let me check something.
<kirkland> mario_limonciell: k
<mario_limonciell> are you having trouble without the existance of dund then i take it right now?
<mario_limonciell> kirkland, ah yeah i remember now.  so the deal was that upstream wanted to migrate people to the new plugin interface
<mario_limonciell> so you are looking for the bluez-network package
 * kirkland goes check
<kirkland> mario_limonciell: okay, i've got that, but the only binary in that is /usr/lib/bluetooth/plugins/libnetwork.so
<kirkland> mario_limonciell: what provides the dund functionality now?
<kirkland> the documentation on this is sadly lacking
<mario_limonciell> kirkland, so when you install that package, you should get a plugin interface from the bluez applet
<kees> jdstrand: configure: error: cannot run /bin/bash ../config.sub
<jdstrand> kees: ok, I'll try to track that down later-- thanks for confirming
<kees> np
<mario_limonciell> kirkland, let me see if i've got any intrepid boxen sitting around with bluetooth that i can see myself
<kirkland> mario_limonciell: on completely a different note, we just got hit with a band of the hurricane winds/rains at my house :-)
<mario_limonciell> kirkland, oh no.  no damage i hope right?
<mario_limonciell> i didnt expect much effects  this far up north
<kirkland> mario_limonciell: nah, nothing like that...  the sky just turned black :-)
<kirkland> mario_limonciell: not hurricane force winds
<mario_limonciell> ah okay good
<kirkland> mario_limonciell: i suspect the bluetooth thing is probably just a matter of documenting the new methods
<kirkland> mario_limonciell: there's a number of Ubuntu wiki (and 3rd party) webpages that give instructions on tethering and syncing and surfing the internet over bluetooth devices, all of which talk about dund/pand/hidd
<mario_limonciell> kirkland, oh i can teach you how to do that on sprint without dund via bluetooth
<mario_limonciell> but i think there is a genuine Bug here, because i installed bluez-network and don't see it in the list of services on my intrepid box with bluetooth
<kirkland> mario_limonciell: nice... i'd like to know.  i've been using dund over sprint and several Treos since FC3 and Dapper
<mario_limonciell> oh there we go, had to restart the bluetooth service
<mario_limonciell> its now in my services
<mario_limonciell> kirkland, -> /msg
<pwnguin> can we just put a bounty on thunderbird and evolution to fix up text analysis and quoting to handle threading either way?
<pwnguin> beacuse im a bit tired of the threads about the subject when there really isnt a community consensus
#ubuntu-devel 2008-07-24
<Gunirus> bigon: ping
<TheMuso> Aha! Pulse's hal module works backwards through card numbers/indexes, and since the pc speaker card is the last in the list, its chosen first. :S
<slangasek> TheMuso: that seems... backwards? :)
<TheMuso> slangasek: Agreed. I'm now reading the hal-detect module code to see if can be somehow blacklisted/patched around.
<LaserJock> anybody here use xchat-gnome and notice that it pegs the CPU when you open up the preferences?
<gpocentek> slangasek: is it OK if a upload a gnumeric package with Recommends: evince | evince-gtk? Or is it better to move evince to Suggests?
<persia> LaserJock: I can reproduce that, but hadn't previously noticed.  That said, isn't that a bug?
<johanbr> LaserJock: Yes. I'm pretty sure it didn't do that in Hardy.
<LaserJock> johanbr: this is Hardy
<persia> johanbr: It does it in hardy.
<johanbr> Oh, it does? I must be wrong then. :)
<johanbr> In that case, the bug is still there in Intrepid. :)
<persia> gpocentek: Just out of curiosity, is the core issue not resolved by the split between gnumeric & gnumeric-gtk?  Is there perhaps something else involved?
<LaserJock> huh, it's odd that it would make it this long
<persia> Lots of people wouldn't notice, as they'd edit the preferences while not doing other things.
<gpocentek> persia: the split has been dropped, and the problem is that we have both evince and evince-gtk being installed
<LaserJock> hmm, I guess I wouldn't have noticed it as readily if I didn't have a CPU monitor
<gpocentek> which failed obviously
<persia> gpocentek: Ah.  Right.  I seem to have misread the changelog.
<LaserJock> gpocentek: thanks for dropping the -gtk stuff for goffice, upstream complained about that quite a bit
<TheMuso> Quick question for intrepid. Do people care if the PC Speaker is not available as a sink in PulseAudio? :)
<persia> TheMuso: By default, or at all, ever?
<TheMuso> persia: Currently it is kind of used by default, due to the way hal-detect works through finding devices, but yes, ever as well.
<TheMuso> If you do a fresh install of intrepid today, and your machine has a PC speaker, pulse will use it.
<persia> Not being available by default ought solve the exceedingly common complaint by those with a "single sound card" who don't want to use the asoundconf set-default-card macro.
<LaserJock> persia: bug #192967 has been "Triaged" and sent upstream sinc Feb.
<persia> On the other hand, not being available at all could well be regarded a bug.
<ubottu> Launchpad bug 192967 in xchat-gnome "Preferences window of xchat-gnome eats 100% of the CPU" [Medium,Triaged] https://launchpad.net/bugs/192967
<TheMuso> persia: Yeah. At the moment, I have a patch to completely ignore the PC speaker, so that only sound cards are available to pulse, however I am going to see whether its possible to reverse the index traversal in pulseaudio.
<TheMuso> Thereby having the pc speaker still available, but not default.
<persia> LaserJock: From reading, I think that's a well described bug.  Just needs someone to fix it :)
<LaserJock> persia: apparently
<persia> TheMuso: As a temporary fix, completely disabling makes sense, as long as that doesn't drop off the list of things to fix by release.  Can we maybe do something with asoundconf --set-default-card?  That seems to fix the "horrible buzzing noise" for many people.
<TheMuso> persia: Nothing to do with pulseaudio. Pulseaudio uses hal to find devices, and it searches the index of soud cards in reverse order, as in, highest to lowest. I think doing lowest to highest is a better bet.
<persia> Note that I've never heard a positive review of the PC Speaker as an output device, but I presume there is some use case for which it makes sense.
<TheMuso> So if I can do that right off, then its all done and not needing to worry about it.
<LaserJock> getting rid of the PC speaker kernel module is usually one of the first things I do
<LaserJock> can't stand that stupid thing
<persia> TheMuso: Interesting.  I was sure a couple people reported that the asoundconf macro fixed it for them.  Maybe an upgrade vs. install thing.
<TheMuso> persia: Considering pulse uses hw:index to access the device, thats possibly it, but they may have also set their output to use alsa exclusively.
<persia> TheMuso: Right.
<TheMuso> As it is, I think I've found the code that iterates through device indexes.
<pushax> where can I find documentation on x.org programming?
<pushax> x.org doesn't seem to have any
<murlidhar> hi al
<murlidhar> hi all
<murlidhar> for the past one week i am trying to compile bmpanel 0.9.24 from the source and ./configure doesn't show any dependency problem but make doen't compile the application
<murlidhar> what might be the problem?
<murlidhar> i think that it is not a dependency problem .
<murlidhar> perhaps we don't use the latest libraries
<murlidhar> i have been directed to this channel by #ubuntu .
<murlidhar> i am newbie too please help me . i really want this application to be installation in my hardy
<murlidhar> i even installed intrepid to see if it can be compiled but i am not able to do it there either.
<murlidhar> http://paste.ubuntu.com/29858/
<murlidhar> the pastebin
<murlidhar> home page of bmpanel http://nsf.110mb.com/bmpanel/
<murlidhar> if this can't be done in this channel can u tell me what is the channel that i can get help from ?
<Hobbsee> murlidhar: install libc6-dev, but this is not a support channel.
<murlidhar> or atleast what exactly the problem is ?
<murlidhar> anyone ?
<Hobbsee> apart from that, go ask those who make bmpanel.
<murlidhar> Hobbsee: k thanks
<murlidhar> Hobbsee: btw libc6-dev is already the newest version .
<murlidhar> Hobbsee: so do i compile libc6-dev from source and see if it works ?
<Hobbsee> murlidhar: then go ask the people who make bmpanel.
<Hobbsee> this is *not* a place for support.
<Hobbsee> as the /topic says.
<murlidhar> Hobbsee: sorry and thanks i am asking them right now
<murlidhar> Hobbsee: actually i am tryin to install it from the past one week . so i was a bit frustrated .
<slangasek> gpocentek: gnumeric having a recommends: on evince seems questionable to me; does the relationship really fit the definition of Recommends?
<slangasek> gpocentek: but yes, it's ok with me either way
<gpocentek> slangasek: my feeling is that it should be turned in a Suggests, evince is only needed to read the exported pdf files AFAIK
<slangasek> gpocentek: then that agrees with my sense, but the decision is up to you
<LaserJock> gpocentek: especially when a lot of other apps can be used to read the pdfs
<gpocentek> LaserJock: true
 * TheMuso has come up with a patch to ensure the PC speaker is not the default sink/output for pulse, but the PC speaker option is still avaiable for those weird ones who still want it.
<TheMuso> slangasek: is this pulse fix something we might want for the alpha? Or are we too far gone to include it?
<pitti> slangasek: ask you about what?
<pitti> slangasek: usplash? well, I can't really tell; it's hopelessly broken for me either way, I'm afraid :/
<pitti> Good morning
<StevenK> Morning pitti
<cjwatson> morning
 * Hobbsee waves
<seb128> hello everybody
<NCommander> seb128, ping
<seb128> hey NCommander
<NCommander> seb128, I've got gucharmap packaged
<NCommander> Expect for the python bindings
<seb128> waouh ;-)
<seb128> oh?
<NCommander> Which I don't think will be possible unless we kick CDBS
<NCommander> It builds the bindings through ./configure
<seb128> why ?
<NCommander> It doesn't use the nice easy python build system
<NCommander> So configure will have to be run multiple times in a proper environment to build bindings for each version
<NCommander> (and even then, I'm not sure how to get it to work, configure doesn't even catch that libpython on Debian is libpython-*ver*
<seb128> ah, that, yes, that's unpleasant :-(
<NCommander> yeah
<NCommander> So you can have the package now, or you can wait for me to make it into a makefile based rules which does some unholy thing to build the bindings
<NCommander> It will essentially require rebuilding configure twice with a different python version coded in (since its hard coded to libpython, and I don't want to even try and get it to build the bindings twice in the same path)
<seb128> did the soname changed?
<NCommander> s/path/pass/s
<NCommander> seb128, yeah, I got that, its 7
<NCommander> I changed the depend on the dev file so it will install the new library automatically if the -dev package is installed
<seb128> ok, so I'm not going to upload that today due to the intrepid alpha 3 freeze
<NCommander> seb128, yeah, I got that email :-P
<seb128> avoiding soname changes now, that can be disruptive
<NCommander> seb128, so you want it without the bindings?
<seb128> you can look to gnome-menus for an example
<NCommander> (I personally thing it will be very ugly to fix)
<NCommander> I did migrate the lp patch which was fun
<NCommander> A few variable names changed -_-;
<seb128> it builds python binding and uses cdbs
<NCommander> seb128, no, building the bindings with CDBS on a normal python package that uses setup is easy
<NCommander> I've never seen a package that uses configure to build python bindings
<seb128> all the GNOME packages tend to use configure only
<NCommander> *fun*
<NCommander> Ugh, this is an ugly rules file, even for CDBS
<seb128> yes ;-)
<seb128> cdbs doesn't make multi-builds friendly
<NCommander> ew
<NCommander> Yeah
<NCommander> I was ...
<NCommander> Ew
 * NCommander twichs
<NCommander> THere is a reason I despise CDBS
<NCommander> I'm staring at it right now
<seb128> ;-)
<seb128> cdbs is great for packaging easily easy things
<seb128> ie, most of GNOME where you only need to ./configure && make && make install
<NCommander> Yeah, and blows up in your face when the package maintainer does something slightly different
 * NCommander uses the time honoured tradition of copy and paste coding
 * mvo devel machine just turned itself off spontaneously - that is slightly disturbing
<realist> mvo: did it let out any magic smoke?
<AlexCONRAD> hello, if I wanted to hack glxinfo (from the mesa-utils package), how should I retrieve the source ?
<RAOF> apt-get source mesa
<RAOF> Also, probably off-topic :)
<AlexCONRAD> RAOF: thanks :)
<RAOF> Of course, if you wanted to contribute upstream you'd be after cgit.freedesktop.org/mesa/mesa
<davmor2> Should compiz kick in on intel gfx cards by default in intrepid?
<Chipzz> mvo: power-spike maybe?
<Keybuk> The membership of Daniel Holbach (dholbach) in the MOTU (motu) team has
<Keybuk> expired.
<Keybuk> <https://launchpad.net/~motu>
<Keybuk> ...
 * Keybuk wonders whether that was supposed to happen
<Chipzz> mvo: I had that once several years ago. went out for a bit, and when I came back, my pentium machine had rebooted, and my 486 was still running
<Chipzz> 486 had a better power-supply apparently :)
<Hobbsee> Keybuk: yes, it's deprecated.
<Keybuk> Hobbsee: no, it's not
<Keybuk> we haven't deprecated the MOTU :p
<Hobbsee> oh, we've deprecated ~ubuntu-dev.  i think.
<Hobbsee> oops
<Hobbsee> it might be fun to deprecate the MOTU, though :P
<Keybuk> I suspect he just missed the expiry mails due to being on his road-trip
 * Keybuk extends it another month so he gets a chance
<davmor2> that'll teach him to go on holiday :)
<seb128> bug #197762
<Hobbsee> yeah, it annoys me that they only get a week
<ubottu> Launchpad bug 197762 in gvfs "file transfer on USB disk slows down with gvfs" [Low,Triaged] https://launchpad.net/bugs/197762
<seb128> on recent comment suggests that using pci=routeirq workaround the issue, on amd duo core system using nvidia chipsets
<seb128> is that a known issue? linux bug?
<AlexCONRAD> RAOF: no, I'm just trying to alter the glxinfo output...
<AlexCONRAD> for testing purpose
<AlexCONRAD> RAOF: regarding this issue if you mind: https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules/+bug/250792
<ubottu> Launchpad bug 250792 in linux-restricted-modules "Adobe Flash hardware acceleration support (GPU)" [Undecided,New]
<mvo> Chipzz: heh :) happend last night too, I suspect something HW releated, I will have to keep a eye on it
<NCommander> seb128, this is pure evil in its most unadultrated form; is there any reason why the desktop seem is in love with CDBS?
<seb128> NCommander: because rules are clean and short most of the time
<NCommander> seb128, Normally, but for packages like this, it just seems like a headache (I'm not trying to bitch (much), although this is probably going to make me go a little nuts once I finish)
<pitti> mdz: do you still have a current checkout of lp:~ubuntu-core-dev/casper/trunk ? bzr getting that fails, maybe you can "bzr check"/"bzr reconcile" on your end and push again?
<pitti> mdz: asking you because it says something about "KnitCorrupt: Knit text:x_Matt_Zimmerman_<matt.zimmerman@canonical.com>" (although that is already very old)
<mvo> NCommander: while I'm not always in love with the implementation I think the idea behind it is really good, currently there is just too much cargo-culting and copy/n/paste going on where we really want to have a simple "build-me-a-standard-gnome" package rule
<mdz> pitti: there's a bzr bug open about that
<RAOF> AlexCONRAD: Ah, right.  I suspect you're on a hiding to nothing trying to munge glxinfo until closed-source flash deigns to use GL acceleration.
<pitti> mdz: ah, will have a look
<NCommander> mvo, maybe its time for a debhelper gnome rule ;-)
<cjwatson> pitti: https://answers.launchpad.net/launchpad-bazaar/+question/39693
<mvo> debehlper7++ :)
<mdz> pitti: I do have a local tree
<seb128> NCommander: agreed that multi-builds are ugly when using cdbs
<AlexCONRAD> RAOF: I'm just trying to compile to have a dummy hardcoded string in there
<cjwatson> mdz: I don't suppose you happen to have a copy of the old matt.zimmerman@canonical.com--2004/casper--main--0 arch repository? that's the missing bit
<cjwatson> pitti: check/reconcile doesn't help, BTW
<mdz> cjwatson: http://people.ubuntu.com/~mdz/bazaar/casper/
<pitti> NCommander: well, not more or less ugly than with plain debhelper, it's just that cdbs won't help you with multibuild
<SniperBeamer> are ddebs for hardy-backports available somewhere?
<mdz> pitti: bug 246880
<ubottu> Launchpad bug 246880 in bzr "Can't branch casper which misses some parents in old revisions" [Undecided,New] https://launchpad.net/bugs/246880
<pitti> SniperBeamer: I currently don't grab/archive them
<NCommander> seb128, it might be less evil to simply manually build the python bindings with the appropriate GCC commands then force a multibuild :-P
<mdz> pitti: lifeless said he would try to help with it during the sprint, not sure who he worked with
<SniperBeamer> ddebs.ubuntu.com doesn't have them
<cjwatson> he worked with me
<cjwatson> we only succeeded in making it worse
<StevenK> pitti: Could I beg you to source NEW wpeditor?
<StevenK> pitti: And you *might* be able to NBS out libgpmg1.
<cjwatson> mdz: no, those appear to be matt.zimmerman@canonical.com/casper--main--0, not matt.zimmerman@canonical.com--2004/casper--main--0
<mdz> cjwatson: sorry, i meant http://people.ubuntu.com/~mdz/bazaar/matt.zimmerman@canonical.com--2004/
<mdz> cjwatson: or http://people.ubuntu.com/~mdz/bazaar/matt.zimmerman@canonical.com/
<cjwatson> aha
<cjwatson> thanks, might be able to piece the ghosts back together from that
<StevenK> Hm. hppa might actually be catching up.
<NCommander> StevenK, hppa's toolchain is not happy though
<cjwatson> mind you, that means I have to install baz ...
<mdz> hooray for never deleting anything
<NCommander> seb128, I think its a bad sign when ./configure getting run in the autotools-files stamp -_-;
<StevenK> NCommander: It isn't?
<cjwatson> this is a relief, I have completely forgotten how to drive baz
<NCommander> Anyone can tell me what's wrong with this lintian override?
<NCommander> codeblocks binary: script-not-executable usr/share/codeblocks/lexers/lexer_bash.sample
<NCommander> (I get this from lintian: W: codeblocks: script-not-executable ./usr/share/codeblocks/lexers/lexer_bash.sample)
<pitti> NCommander: it apparently has a hashbang line, but is 0644
<NCommander> pitti, no, this needs to be overrided, the .sampe is a data file
<NCommander> It has a hasbang, and its needed
<NCommander> It's not susposed to be an executable script
<NCommander> I'm just trying to figure out why my override file isn't working
<pitti> NCommander: if it has a hashbang, why shuoldn't it be executable?
<NCommander> pitti, It's used by the bash lexer as an example script to show when you change settings; its never executed by codeblocks, its simply used as a test by the lexer, and shown in the IDE to show how changes to a lexers settings will effect rendering
<seb128> NCommander: try using "./usr/share/codeblocks/lexers/lexer_bash.sample" in the .lintian?
<NCommander> seb128, I had tried it :-/
<NCommander> THe only thing that has worked thus far is simply killing the entire wanring
<seb128> NCommander: and why do you add "binary"?
<seb128> "codeblocks: script-not-executable ./usr/share/codeblocks/lexers/lexer_bash.sample"
<seb128> try that?
<NCommander> loose the binary line?
<NCommander> seb128, cause thats what the documentation says
<cjwatson> seb128's suggestion is correct
<NCommander> I tried putting it in /usr/share/lintian/overrides/codeblocks to test, I still get the warning
<cjwatson> I'm not sure about the binary bit, the lintian documentation does say it's optional
<cjwatson> but copying and pasting the output without the initial W: or whatever should work
<cjwatson> NCommander: it needs to be in the package itself
<cjwatson> Note that Lintian extracts the override file from the (u)deb and stores it in
<cjwatson> the laboratory. The files currently installed on the system are not used in
<cjwatson> current Lintian versions.
<cjwatson> ^- from the lintian manual
<NCommander> cjwatson, I was rebuilding the package, ccache makes it loads faster
<NCommander> It's just finishing the install rules
<NCommander> seb128, I think I'm going to need help on this, I honestly am fairly stumped on how to make this do a multipass build; I don't use CDBS at all in my packages
<seb128> NCommander: did you try to copy what gnome-menus does?
<NCommander> seb128, yeah, I can't even make it run the right configure target
<NCommander> configure/gucharmap:: $(addprefix configure-stamp-, $(PY_VERSIONS)) - doesn't work (nor does just configure::)
<seb128> do you have ".PRECIOUS: configure-stamp-% dbg-configure-stamp-%"?
<NCommander> seb128, .PRECIOUS: configure-stamp-% dbg-configure-stamp-%
<NCommander> Yup
<seb128> can you copy your .diff.gz somewhere?
<NCommander> seb128, I can stick it on revu
<seb128> just copy the rules on http://paste.ubuntu.com maybe, that will be faster
<NCommander> seb128, ok
<NCommander> seb128, http://paste.ubuntu.com/29906/http://paste.ubuntu.com/29906/
<NCommander> er http://paste.ubuntu.com/29906/
<seb128> NCommander: does changing configure/libgucharmap7 to configure/gucharmap makes any difference there?
<NCommander> seb128, nope
<NCommander> I went through every variation that made sense there
<seb128> and what error do you get?
<NCommander> seb128, no error
<NCommander> seb128, it runs the default CDBS build rule
 * NCommander is not a CDBS guru, and has never encountered a Makefile debugger :-P
<seb128> hum
<NCommander> seb128, maybe its easier to simply upload the gucharmap package into the delayed queue without python, and then file a wishlist bug :-P
<NCommander> ALthough I'll probably take three or more stabs at it before I give up in frustation and rewrite the rules file
<NCommander> and then watch that diff.gz get rejected :-P
<seb128> NCommander: you did use "DEB_BUILDDIR := build" but that should make a real difference
<NCommander> touch debian/stamp-autotools-files
<NCommander> chmod a+x /build/gucharmap/gucharmap-2.23.4/./configure
<NCommander> It's not :-P
<NCommander> Let me post the build log
<seb128> in fact I don't think you need the .PRECIOUS line
<NCommander> seb128, I've tried without it
<NCommander> seb128, you can scratch your head just like I am
<seb128> I hate cdbs multi builds ;-)
<NCommander> Just say the word and I'll redo the build file in a sane way ;-)
<jcristau> the word
<NCommander> jcristau, I need it from my mentor (and the guy who's going to be uploading it :-P)
<seb128> NCommander: oh, you have 2 clean targets in this rules
<seb128> that's not good ;-)
<NCommander> I swear, if that was it
<NCommander> I'm going to scream
<NCommander> and file a bug against CDBS: "Too ugly to live"
<NCommander> *phew*
<NCommander> No change in output, still not calling configure with the proper environmental PYTHON variable
<seb128> NCommander: ok, please put the diff.gz somewhere ;-)
<jcristau> NCommander: damn. :)
 * NCommander kicks it onto REVU
<seb128> but maybe we should use debhelper for packages which need multi builds
<seb128> I would like to figure what is wrong there though
<NCommander> seb128, I'd like to know what was wrong as well, but there is a point where the pain just becomes too much
<NCommander> seb128, it looks like it should work, right?
<seb128> NCommander: yes
<NCommander> Or at least, try to build in build
<NCommander> seb128, its on its way to revu
<seb128> ok
<NCommander> seb128, http://revu.tauware.de/details.py?package=gucharmap
<NCommander> seb128, ignore the lintian warnings, I hadn't cleared them when I tried to make it do multbuilds
<seb128> looking
<norsetto> any archive admin that can process bug 248060?
<ubottu> Launchpad bug 248060 in ubuntu "Please sync lwt 1.1.0-2 (universe) from Debian unstable (main)." [Wishlist,Confirmed] https://launchpad.net/bugs/248060
<NCommander> seb128, As an aside, codeblocks just made it into the archive, wooo
<NCommander> seb128, any chance I can ask you to sponsor it into Debian at some point (and a fix for my other debian package)
<seb128> NCommander: I can do that yes
<NCommander> seb128, that would be awesome if it isn't much trouble
<NCommander> seb128, (I'd ask ask for sponsoring for D-Maintainer once I prove to you I can package ;-))
<seb128> ;-)
<NCommander> wow, I think Launchpad's karma counter has a bug
<seb128> NCommander: gucharmap seems to work correctly
<NCommander> I just jumped from 2000 to 6671
<NCommander> seb128, what, the one I uploaded? It doesn't even build here
<NCommander> (unless you undid my rules changes)
<seb128> NCommander: at least it calls configure using the correct PYTHON=`which python2.5` etc
<NCommander> ....
<NCommander> It likes you and not me
<seb128> well, it seems to be calling the configure a first one without argument
<seb128> then cd build-python-2.5
<seb128> and then call it correctly
<NCommander> seb128, that's failing for me
<seb128> s/first one/first time
<NCommander> I thought I needed the PYTHON=* to make that work
<NCommander> (and as an aside, what dependency do I need installed then, and added to the control file)
<seb128> I moved the --enable-python-bindings to the configure-stamps arguements
<seb128> forgot to mention that
<NCommander> Ah
<NCommander> Yeah
<seb128> which means the first configure call doesn't try to do that
<seb128> now it fails on gucharmap/gucharmap.h.in not being available
<NCommander> seb128, that's pretty ugly, but it does work
<NCommander> seb128, well, now that its actually trying to build, I can probably resolve it
<seb128> I guess it doesn't like building out of the sc dir
<seb128> src dir
<NCommander> It probably means a giant search/replace is going to hit every Makefile.am file
<NCommander> Cause I don't think there is any way to build this inside the build directory
<seb128> why?
<NCommander> seb128, yeah, take a look at the Makefile.am's they're using relative paths, and not the full syntax (the $(source)\gucharmap\file.c you need to get out of source builds)
<NCommander> Unless there is an arguement you can pass to autoconf, the only way I know how to fix it is to manually fix each and every line
<NCommander> seb128, any suggestions before I got editing happy on the Makefile.am's?
<norsetto> seb128: once you have finished your love affair with NCommander (:-)) could you please push bug 248060? Its needed to have ocsigen build correctly (and was requested 2 days before ocsigen to avoid it ftbfs)
<ubottu> Launchpad bug 248060 in ubuntu "Please sync lwt 1.1.0-2 (universe) from Debian unstable (main)." [Wishlist,Confirmed] https://launchpad.net/bugs/248060
<seb128> NCommander: what is the error exactly?
<NCommander> ooh
<NCommander> I just got an absolutely sick way to fix this
<seb128> norsetto: not a love afair and I read your comment before and it's in the ubuntu-archive bugs list, there is no need for extra pinging
<NCommander> But it wouldn't require patching every makefile
<norsetto> seb128: after 10 days, yes, there is ....
<seb128> norsetto: sorry I was travelling for GUADEC and distro sprint and seems other archive admins have been busy too
<seb128> norsetto: why is it urgent?
<norsetto> seb128: because if causes ocsigen to ftbfs
<seb128> well, that would be nice to fix but it doesn't seem particularly urgent
<seb128> I'll do the sync now anyway
 * norsetto hugs seb128
<NCommander> seb128, I think cp -r * build-$* might be excessively too ugly to live
<seb128> NCommander: I tried to "mkdir build; cd build; ../configure" and that seems to work, weird
<NCommander> My solution was to simply copy the source directory into the build directory ;-)
<NCommander> seb128, CDBS is probably doing something rather nasty to the envornment thats causing it not to work
<seb128> feel free to rewrite the rules using debhelper if you think that would make things easier and cleaner
<NCommander> seb128, O_o; what made you give up CDBS and let me rewrite the rules :-P
<NCommander> Well, if this just works by cp -r'ing the build directory, its probably easier to stay with CDBS if we ever want these changes to go upstream
<seb128> I don't care that much about using cdbs for multibuild, that's often ugly
<seb128> maybe there is some srcdir that need to be changed to builddir in a makefile
<NCommander> seb128, well, at this point, I actually got it building as a multibuild
<seb128> oh?
<NCommander> Well, mostly, I'm tweaking it as it fails, but it appears to now be somewhat working
<NCommander> seb128, http://paste.ubuntu.com/29925/ - take a look at what I did
<seb128> bah
<seb128> that's ugly
<NCommander>  You've got to give me points for thinking outside the box ;-)
<seb128> what breaks it is the srcdir=. given to the configure
<NCommander> so just force srcdir=..?
<seb128> that would work I guess, but I'm trying to figure why srcdir=. is used
<zyga> mvo: hello, do you mind being subscribed to bug 105219?
<ubottu> Launchpad bug 105219 in command-not-found "Pressing control C while command-not-found is runnig is confusing" [Undecided,Confirmed] https://launchpad.net/bugs/105219
<zyga> I believe that bug is now fixed, I added a comment at the bottom of the page
<seb128> NCommander: ah, that's because you forgot the "DEB_BUILDDIR := build"
<seb128> NCommander: adding that to the rules make it work correctly
<NCommander> argh, its now not working for me
<seb128> is "there is no sound on intrepid when pulseaudio is running" a known issue?
<NCommander> I see python go in, and then configure goes boom
<NCommander> seb128, got any idea why it can't link against libpython?
<mvo> zyga: sure, please subscribe me
<seb128> NCommander: not really, looking at it
<NCommander> seb128, any luck?
<seb128> NCommander: no, I'm a bit puzzled by this one
<NCommander> seb128, yeah, the libtool line looks like it should work
<seb128> NCommander: it's due to the autoreconf patch
<seb128> not sure what in it though
<NCommander> hrm
<seb128> moving the patches directory away make it work
 * NCommander just reruns autoreconf
<seb128> btw the patch should be an autoconf one
<seb128> no need to run automake etc in this case
<seb128> only the configure needs updating
<pitti> wow
<pitti> I mean, WOW!
<pitti> intrepid desktop booting fine for me under intrepid kvm
<pitti> including usplash
<seb128> ;-)
<pitti> something is clearly wrong here...
<seb128> NCommander: just running autoconf produces a 20 lines patch and doesn't break the build
<seb128> NCommander: running autoreconf is looking for trouble ;-)
<NCommander> Well
<NCommander> ...
<pitti> soren: hm, current intrepid desktop cd under current intrepid (i386: desktop boots fine, but the mouse speed is about 23429 times faster than it should be; known?
 * NCommander shoots himself
<seb128> NCommander: btw you want to change the gmenu mention in the rules too
<seb128> the egrep command
<NCommander> seb128, yeah, that already got killed
<pitti> soren: at some point we had a scaling problem with the vmmouse driver; did that creep back in somehow?
<pitti> soren: (I guess it uses vmmouse?)
<seb128> NCommander: seems to build fine now
<NCommander> seb128, What a headache
<NCommander> Between autoconf and CDBS ... I apperiate you taking so much time in helping to resolve this
<seb128> np ;-)
<seb128> thank you for the work you put on updating this package!
<NCommander> seb128, its not a problem
<NCommander> seb128, if it builds, now its just a matter of install rules, and control updates
<seb128> right
 * NCommander flips through the rules for python bindings
<NCommander> I'm bound to get this wrong two or three times ;-)
<NCommander> seb128, so what's the next headache you got queued up?
<soren> pitti: Oh, i386 boots fine? That's... er... unexpected :)
<NCommander> pitti, an actual i386 boots O_o?
<NCommander> WTF?
<cjwatson> soren: (boots for me too)
<seb128> NCommander: you mean in gucharmap?
<soren> pitti: I'm having a few different interesting issues with the new Xorg. I've not yet quite worked out if kvm or Xorg is to blame.
<pitti> soren: I just installed libvirt-bin again and tried in virt-manager; now I'm back to the problem I have had for some weeks, in that the boot in virt-manager is painfully slow and just times out
<soren> cjwatson, pitti: On i386 hosts?
<NCommander> seb128, updated packages for desktop, you seem to have a list of evil packages you keep for your mentees to make them run and hide
<cjwatson> soren: yes
<pitti> soren: yes
 * NCommander can't believe that actually works O.o;
<soren> Hm. Ok.
<pitti> so with just plain "kvm -m 512 -cdrom" the boot works and roadrunner-mouse
<seb128> NCommander: those were the harder ;-) other updates are rather standard ones
<pitti> with virt-manager -> initramfs prompt
<cjwatson> I have a similar mouse problem as pitti
<soren> pitti: I don't know if the current X stuff figures out that it should be using vmmouse.
<NCommander> pitti, should I go get my 386SX and try it ;-)
<cjwatson> I can't even *see* the mouse, it just zips from one corner to the next
<NCommander> seb128, if you call this "hard", then I laugh in the face of danger!
<soren> cjwatson, pitti: Does the Xorg.log mention vmmouse at all?
<NCommander> It was more frustating then hard
<pitti> NCommander: well, not *that* kind of i386 :)
<NCommander> pitti, d'oh :-P, be more specifc
<pitti> soren: how do I send ctrl+alt+f1 or ctrl+alt+backspace with plain kvm?
<seb128> NCommander: there is still the "make an epiphany-browser-snapshot package to build epiphany-webkit from svn" on the list of fun things to do if you are looking for trouble, but that's in no mean a priority
<cjwatson> soren: yeah, "vmmouse enabled" at the end
<soren> pitti: Heh... ctrl-alt-2, "sendkey ctrl-alt-f2", ctrl-alt-1
<NCommander> seb128, I'll probably extend REVU to have apt-get source support before I do that
<cjwatson> (bear with me, I'm doing another rather delicate test here)
<seb128> NCommander: well, usually package updates are really easy, ie run dch, update build-depends, build, test, upload
<seb128> NCommander: so those were already "hard" updates ;-)
<NCommander> seb128, you've been lucky. my upstream packages like to play change the build system every release
<pitti> soren: booting in kvm again
<seb128> yeah, GNOME is nice for that
<pitti> soren: ctrl+alt+2> nice, didn't know about that
<seb128> ok, lunch time, be back in a bit
<soren> pitti: You can get all sorts of cool info there.
<pitti> wow, there are serial and parallel consoles, too
<soren> pitti: "info registers" for instance.
<pitti> hm, it didn't particularly like Alt+f2 "gksu killall gdm"
 * pitti tries again
<NCommander> woo, I got python patches
<pitti> soren: confirmed; s/vmmouse/mouse/ in xorg.conf gets me back to sanity
<AlexCONRAD> is there a way to see which graphic driver is currently used by xorg ? I know there's xorg.conf, but I'd like to make sure my changes has been taken in account.
<pitti> AlexCONRAD: /var/log/Xorg.0.log tells you
<AlexCONRAD> pitti: thanks
<soren> pitti: That is *so* backwards.
<soren> pitti: vmmouse used to be the sane one.
<pitti> cjwatson: when you were trying kvm, did you call kvm from a shell, or used virt-manager?
<cjwatson> shell
<pitti> ah
<cjwatson> virt-manager is too much mousing around
<AlexCONRAD> hummm, it seems to load both "ati" and "radeon"
<AlexCONRAD> (I've set ati)
<soren> pitti: It uses a backdoor to provide absolute coordinates so that it can place the mouse pointer where the host mouse pointer is. Wonder why that'd break.
<pitti> cjwatson: how do you create images then? qemu-img?
<cjwatson> pitti: dd
<pitti> soren: in non-grab mode, I don't see the pointer at all; in grab mode (explicitly pressing ctrl+alt), I get the fast one
<pitti> cjwatson: oh, that works? no magic signatures? nice
<cjwatson> all I need is a file full of zeroes, I don't need a complicated UI to give me that
<cjwatson> soren: bug 195431 was fix-committed three months ago. What is its status?
<ubottu> Launchpad bug 195431 in virt-manager "VM creation awkward to drive from keyboard" [Undecided,Fix committed] https://launchpad.net/bugs/195431
<cjwatson> s/vmmouse/mouse/g fixes it for me too
<soren> cjwatson: qemu-img will do that for you, too.
<soren> cjwatson: Without actually eating all the disk space. It just creates a sparse file.
<cjwatson> however, mouse doesn't do host mouse pointer tracking, as you say
<cjwatson> it works fine when I grab the mouse
<cjwatson> soren: *shrug* I'm usually happier to take the I/O hit up-front
<cjwatson> and also not have weird shit happen when I run out of disk in the middle of a test run
<pitti> me too; virt-manager seems to allocate it all for real, too
<soren> pitti: There's a checkbox to enable/disable that.
<pitti> ah :)
<soren> pitti: Right beneath the box where you enter the amount of space.
<soren> "allocate disk space now" or some such.
<soren> cjwatson: 195431 went down the drains as upstream changed a whole bunch of stuff, so my patch fell apart.
<pitti> soren: so, while I'm fine with running from the command line, I'm still curious why virt-manager stopped working; do you get that, too?
<soren> pitti: Which part of virt-manager exactly?
<pitti> soren: I mean that the cd boots so exceptionally slow (and hangs in initramfs prompt)
<soren> pitti: There's a chance it's falling back to emulated mode (qemu style).
<cjwatson> soren: can you make its status be truthful, then? :)
<soren> pitti: Are you connected to qemu:///system or qemu:///session?
<pitti> soren: system usually
<soren> pitti: Hmm... That shouldn't be the case than.
<soren> s/than/then/
<soren> cjwatson: Heh... Yes, sorry, just did.
<Martiini> has there been alfa 3 yet for intrepid ? My intrepid doesnt upgrade for some reason
<soren> pitti: But no, I've not seen the issue you describe.
<Martiini> https://wiki.ubuntu.com/IntrepidReleaseSchedule says intrepid alpha 3 release date 24 july .. (which is today) but I dont get any upgardes .. anyone ??
<cjwatson> Martiini: alphas have very little to do with whether you get upgrades
<cjwatson> Martiini: and no, it hasn't been released yet, some desktop CD problems
<Martiini> okidoki
<Martiini> anyone know what distributions does Linus Torvalds use
<cjwatson> I'm afraid that's off-topic here
<Hobbsee> Martiini: and it's be really nice if you didn't cross-post on irc.
 * mpt has sound!!!!!
<k0p> lol
<seb128> mpt: did you stop pulseaudio to get sound?
<mpt> seb128, no, all I did was turn on the computer
<mpt> How do I tell whether pulseaudio is running?
<seb128> ps ax | grep pulseaudio?
<seb128> or use the system monitor
<mpt> (I'd be surprised if this was a pulseaudio problem, because the problem began in Hoary)
<persia> mpt: pulseaudio --check
<seb128> ok, I've no sound in intrepid when pulseaudio is running
<seb128> and it seems I'm not the only one
<mpt> pulseaudio and pulseaudio/pulse/gconf-helper are both running
<seb128> if anybody wants to work on the issue and needs details let me know ;-)
<mvo> seb128: I have no sound in intrepid too, however if I boot into the 2.6.24 kernel it works again
<seb128> mvo: if you stop pulseaudio do you get sound?
<mpt> And if anyone wants to help debug my problem, it's bug 80344 ;-)
<ubottu> Launchpad bug 80344 in linux "Sound works only a few weeks per year" [Medium,New] https://launchpad.net/bugs/80344
<persia> That's not a good bug title :)
<mvo> seb128: I haven't tested that yet, I'm in 2.6.24 currently
<seb128> mvo: ok, if you try let me know
<persia> mpt: Are you perhaps sending output to your PC Speaker, rather than your preferred card?
<mpt> persia, if there's anything I should check when it stops working in a week or two, it would be great if you could post specific instructions in the bug report (e.g. I don't know how to tell whether output is being sent to a "PC speaker")
<persia> mpt: catch me when your sound breaks, and we'll interactively fix it.  I'm completely certain that your bug report is a question, as the issues that caused sound to break in 5.04 and the issues that cause sound to break in 8.10 are different (unless you are encountering atypical problems).
<seb128> mpt: do you by any chance know what is the bug number for "bug pages have no informations about the package versions"? I'm pretty sure there was a bug for that, it was fixed I think and it's back now
<mpt> persia, ok, thanks for the offer
<seb128> I can't find the bug number though
<mpt> seb128, mouse over the package name
<mpt> Now there's information on versions for *all* the packages in a bug report, not just the one of them
<seb128> whaouh, that's really not obvious
<seb128> but thanks
<seb128> mpt: right, which is not really good, I usually care about versions when I'm reading a bug, when I'm on the bugs list
<seb128> that's especially annoying when the guy say "I'm using version n.m.o" and you want to know what ubuntu version is shipping this one
<seb128> do you know if there is already a bug requesting to have this table back on the normal bug pages,
<seb128> ?
<Hobbsee> seb128: you're the 50th-odd person to say that, but it hasn't changed anything so far.
<mpt> what the hell?
<Hobbsee> unfortunately :)
<mpt> Hobbsee, we had an extensive discussion about this, exactly what information you wanted and didn't want, and I posted a mockup on the bug report.
<Hobbsee> oh, bah.
<mpt> Where did you say "No, that's not enough, we need the box"?
<Hobbsee> i meant the comments about it being really not obvious
<Hobbsee> (apologies, i'm badly multitasking here)
<mpt> Is there a bug report about that?
<Hobbsee> i'm not sure.
<seb128> I was pretty sure there was one, but I can't find it now
<seb128> I'll open a new one
<seb128> the current thing is not obvious and not enough
<mpt> ok
<seb128> and it forces me to open the overview page a lot and wait for it to load just to know what ubuntu version people are using
<Hobbsee> seb128: rmadison, surely.  it's quicker.
<seb128> Hobbsee: I tend to like working from the web interface
<seb128> having the summary on the side was very handy
<Hobbsee> seb128: ah, come to think of it, i guess you have fast connections there too.  and indeed, i agree with you.
<mpt> hm, I wonder how we could present it mot obviously but still in a context-independent way
<mpt> er, *more* obviously
<mpt> Perhaps an "(i)" icon after the package name?
<seb128> mpt: bug #134220
<ubottu> Launchpad bug 134220 in malone "Bug page has no information about current package version" [High,Fix released] https://launchpad.net/bugs/134220
<seb128> mpt: should I reopen this one or open a new bug?
<Hobbsee> mpt: i'm not sure you can.  you want to present it so it's findable, yet you don't want people to see it without specifically jumping through hoops to find it.
<Hobbsee> you want it to vanish, yet you want to make it more obviously visible.
<Hobbsee> this seems counterintuitive.
<mpt> seb128, a new one please. The page does have information about the current package version. Please be specific about whether its current placement is too hard to get to, not obvious for the people who need to see it, or what.
<NCommander> seb128, gucharmap is lintian-cleanish with python-gucharmap built. Its sitting in my PPA
<seb128> mpt: bug #251479, description is alright?
<ubottu> Launchpad bug 251479 in malone "bug pages should list the published versions" [Undecided,New] https://launchpad.net/bugs/251479
<seb128> NCommander: good, looking to that in a minute
<NCommander> seb128, I scare myself on what I can do when I get bored/motivated
<seb128> ;-)
<Wubbbi> bug 249850
<ubottu> Launchpad bug 249850 in synaptic "Synaptic Freez up after installing Packages" [Undecided,New] https://launchpad.net/bugs/249850
<sistpoty|work> soren: can you specify which live cd and kvm combination cause x to hang? (bug #251480)
<ubottu> Launchpad bug 251480 in xserver-xorg-video-cirrus "X hangs in Intrepid in KVM" [Undecided,New] https://launchpad.net/bugs/251480
<sistpoty|work> soren: as I tried with yesterdays desktop-live and a hardy kvm, which at least didn't cause x to hang
<stgraber> sistpoty|work: if by hang, it's getting a black screen and nothing else, I have reproduced that with Intrepid's kvm on an amd64 host with an amd64 Intrepid Desktop CD
<stgraber> sistpoty|work: the same with an i386 Intrepid desktop CD works fine (well, no mouse but that's another issue)
<sistpoty|work> stgraber: ah, I tried only i386 desktop on amd64 hardy kvm
<stgraber> try amd64 desktop, i386 have always been working for me
 * sistpoty|work will do so later today
<norsetto> seb128: thx seb, you know I love you, don't you?
<seb128> norsetto: you're welcome ;-) love might be a bit strong but thanks :-p
<pkern> Could updates to some stable suite be copied from ppas now?  Just curious.
<tkamppeter> Riddell, ping
<Riddell> hi tkamppeter
<tkamppeter> Riddell, we have started the telecon about the printing dialog ...
<persia> pkern: Even were it possible, it's dangerous to do a full copy rather than a sync given that build-dependencies may have updated.  Also, there's the version number thing.
<ScottK> pkern: I think an archive admin could do it.  I know it's possible for them to copy from PPAs to the development release.
<norsetto> persia: is there some kind of script/utility you use when giving IRC lessons?
<persia> norsetto: No.  Why?
<norsetto> persia: ok, just to avoid copying and pasting from a prepared text
<cjwatson> copy from ppa> it would have to be a source-only copy
<persia> norsetto: I am a firm believer that stock replies are typically incorrect.
<cjwatson> and I think it would be better to copy to -proposed first, have it build there, and then copy to -updates
<cjwatson> although I suppose copying from a ppa that was basically just built against hardy would be OK
<cjwatson> (inc. binaries)
<pkern> cjwatson: Sure, what I meant.  So that's possible but people should not use ppa versioning then?
<cjwatson> I don't think I care about versioning
<cjwatson> seems like a red herring
<norsetto> persia: no stock replies, just lines of commands
<cjwatson> let's put it this way: it's technically possible, but we would have to think about whether it's desirable in particular cases
<persia> norsetto: Oh, like for teaching a class?
<ScottK> pkern: I'd suggest for some people for a very small value of some.
<norsetto> persia:I thought it was clear when I said "when giving IRC lessons" :-)
<persia> norsetto: Right.  My misunderstanding.  Copy/paste from prepared text seems like a good idea: I usually don't prepare well enough beforehand to be able to take advantage of that.
<norsetto> persia: ok, thx
<soren> sistpoty|work: Oh, it's only amd64/amd64? That's even more interesting.
<sistpoty|work> soren: looks like it
<pitti> lamont: thanks for the chroots!
<emgent> uhmm..
<emgent> https://launchpad.net/ubuntu/+builds?build_text=koffice2&build_state=all
<emgent> some idea about it ?
<emgent> i386 build of koffice2 1:1.9.96.0~that.is.really.1.9.95.8-1ubuntu2 in ubuntu intrepid RELEASE ?
<lamont> pitti: no worries
<emgent> all broken
<emgent> argh
<cjwatson> emgent: seems to fail to build in a completely normal way that the uploader should fix
<cjwatson> http://launchpadlibrarian.net/15971937/buildlog_ubuntu-intrepid-i386.koffice2_1%3A1.9.96.0~that.is.really.1.9.95.8-1ubuntu2_FAILEDTOBUILD.txt.gz
<cjwatson> 1:1.9.96.0~that.is.really.1.9.95.9-1ubuntu1.3 looks like it should fix this but doesn't seem to have been tried yet
<cjwatson> I'd give it slightly more than 46 minutes if I were you
<cjwatson> (the time since upload, so far)
<sistpoty|work> soren: I'm just testing the current desktop-live (amd64) within faumachine, but I get OOPSes before even coming anywhere close to x...
<soren> sistpoty|work: I'm not quite sure what to make of that..
<sistpoty|work> soren: do you see anything similar from kvm? (when starting w.o. serial konsole, I don't have any means to get any debug info from within faumachine)
<soren> faumachine doesn't emulate a vga adapter?
<sistpoty|work> soren: it does, (slightly different implementation of the gd5442)
<sistpoty|work> soren: however it just turns blank at some point
<soren> Did you try disabling usplash?
<sistpoty|work> soren: yes, tried both with and without
<soren> Oddness.
 * soren kicks firefox
<soren> Ok, seeing as input fields in firefox is the only place where ctrl-w doesn't mean "please remove the word immediately preceeding the cursor", but rather "Oh, please firefox. Won't you please close the tab I've spent half an hour entering stuff into and just nuke all the stuff I did?"....
<soren> How do I change shortcut?
<pitti> soren: ctrl+shift+t is your friend
<seb128> bah, pitti ruined my "use epiphany-browser rather" there ;-)
<Mithrandir> seb128: epiphany still doesn't have ctrl-tab for switching tabs.
<pitti> "unclose tab" is the best function EVAR
<soren> pitti: What about the info i've typed in?
<ScottK> pitti: Do you think Bug 251472 is SRU worthy?  The fix has just been uploaded to Debian.
<ubottu> Launchpad bug 251472 in net6 "gobby uses 100% CPU on files >500KB in size" [Medium,In progress] https://launchpad.net/bugs/251472
<soren> seb128: I used to use epiphany, but the libffi transition made that rather hard for a while. Now I've just gotten used to firefox, I guess.
<pitti> soren: uh, seems that isn't kept with LP, too bad
<pitti> ScottK: if it's an easy patch, sure
<soren> If it were just LP, that'd be fine.
<soren> This is sourceforge...
<ScottK> pitti: OK.  Thanks.
<soren> Anything that keeps me there for more than just a few seconds is by definition BAD.
<pitti> lol
<pitti> soren: admittedly ffox is quite consistent with GNOME wrt. ctrl+w
<pitti> gnome-terminal is the exception, not the rule
<pitti> soren: if it was really a long text, maybe you are lucky with gcore and "strings core | grep"...
<soren> pitti: I've actually done that once.
<soren> pitti: I was being particularly stubborn that day :)
<sistpoty|work> hm.. interesting... hardy kvm gives me after starting gdm: "BUG: soft lockup - CPU#0 stuck for 61s! [Xorg:5724]"... no I'm puzzled even more
<pitti> soren: just tried that, that actually works :)
<pitti> seb128: no response at all in bug 205483
<ubottu> Launchpad bug 205483 in eog "Metadata box should have limited width" [Low,Fix committed] https://launchpad.net/bugs/205483
<seb128> pitti: yeah, most of bugs got no replies
<pitti> :(
<seb128> should we just block updates on lack of feedbacks?
<seb128> the diffs are pretty small and I've been running the updated version for 10 days before upgrading my laptop to intrepid
<pitti> well, some confirmation that the real .deb works would be appreciated
<pitti> see the glib issue...
<pitti> seb128: the version from hardy-proposed, or your local build?
<seb128> both
<pitti> ok
<seb128> my laptop has the local build
<seb128> and my desktop got the official updates
<pitti> seb128: maybe you can add comments to the packages which you tested (the archive .debs)?
<seb128> that can wait for next week
<pitti> and mark them as v-done
<seb128> I'll try to kick pedro and get him to comment on those
<seb128> but I think he's on holidays at the moment
<gaspa> ï»¿seb128, pitti: could help a script that lists nbs that could be removed?
<pitti> gaspa: for finding cycles or hppa-only stuff? sure
<pitti> gaspa: you mean you have one which does some intelligent checks based on http://people.ubuntu.com/~ubuntu-archive/NBS/ ?
<gaspa> pitti: it looks for nbs that hasn't anymore dep. or build-dep.
<gaspa> yep
<gaspa> it start from that page.
<cjwatson> isn't that just iterating down that page and looking for zero-sized entries? :)
<pitti> but that information is already there?
<StevenK> cjwatson: Yes :-)
<cjwatson> that's all I do when processing it, it's trivial
<pitti> I regularly wget -np -r that page, and do a find -empty | xargs lp-remove-package.py
<pitti> the tricky bit is to evaluate the nonemtpy ones :)
<StevenK> I'm getting scared by all the KDE bits on there
<seb128> I do the "for p in $(find -empty | sed 's_^./__'); do lp-remove-package.py ..." listed on the wiki
<pitti> sometimes there are cycles (two NBS depend on each other), sometimes it's just hppa not catching up
<gaspa> it should handle cycles... not hppa, still
<StevenK> pitti: And sometimes it requires 27 uploads. :-)
<pitti> yeah
 * StevenK did 20 odd uploads for libgpmg1 recently
<cjwatson> I think it's worth avoiding the kernel NBSes at the moment
<pitti> BenC: what's the grand plan to solve this, BTW? ^
<StevenK> Ah ha. The reason for all of the KDE stuff is ichthux-desktop.
<pitti> BenC: I haven't removed all teh NBS bits from linux-meta, but at some point something needs to provide them again
<StevenK> pitti: Such as lpia and co, or is this something else?
<pitti> StevenK: that was another case I ignored, since i-d depends on a ton of NBS stuff
<BenC> pitti: NBS?
<pitti> BenC: "not built from source"
<persia> I've heard that ichthux-desktop is planned for an update later this week (although my news is from last week)
<gaspa> pitti: well, if you want to take a look it's here:https://code.edge.launchpad.net/~gaspa/+junk/ubuntu_qa_tools
<StevenK> persia: Who do we bleat at about it?
<pitti> BenC: i. e. nothing builds linux-image-{lpia,openvz} ATM
<BenC> pitti: ah, I'll get back to you after I get unionfs in line
<BenC> pitti: that's fine
<StevenK> NBS is large enough to scare small children at the moment.
<persia> StevenK: txwikinger2 and raphink I think (or try #ichthux)
<pitti> BenC: unionfs? I thought that finally died (it had it coming..), and replaced by aufs?
<BenC> pitti: tell that to the aufs that's holding up alpha3 :)
<pitti> sledgehammer.apply(aufs)
<StevenK> BenC: If you have any plans for a -lpia{,compat} meta for Intrepid, I'd love to hear it.
<cjwatson> pitti: conjecture is that aufs broke it
<pitti> 'it'?
<cjwatson> so my sympathy levels for people promoting it are extremely low at the moment :)
<cjwatson> pitti: yes
<StevenK> I think that's the main reason for leaving NBS alone for a little while -- kernel fun-ness, and ichthux-desktop
<BenC> StevenK: lpia will be provided by another package
<cjwatson> pitti: bug 251223
<ubottu> Launchpad bug 251223 in linux "BUG: Dentry ffff81003ac17410{i=161b,n=cow} still in use (1) [unmount of rootfs rootfs]" [High,Triaged] https://launchpad.net/bugs/251223
<laga> aufs is broken or unionfs is broken?
<pitti> I had ubiquity left installing, and after ten minutes I looked back at kvm, which was just black and crashed
<pitti> might be it, yes :)
<cjwatson> laga: we're using aufs, and the desktop CD is busted in a bizarre kernelish way
<laga> ooh :(
<cjwatson> laga: we are currently trying to revert to unionfs
<cjwatson> since this is the first time aufs has been seriously tested in the Ubuntu context
<pitti> ugh, fun
<cjwatson> admittedly, correlation != causation
<StevenK> BenC: Where another package is one provided by the kernel team, or someone stepping up to do it?
<laga> maybe a newer aufs snapshot would help, that guy releases every monday.
<laga> cjwatson: yeah.
<BenC> StevenK: combination of kernel+mobile teams providing it
<cjwatson> laga: that is not encouraging
<StevenK> Heh
<cjwatson> no serious software engineer likes something where you have to be on the bleeding edge or it blows up
<pitti> is aufs upstream, or external?
<cjwatson> external
<laga> cjwatson: well, it was working fine for me in hardy. i was merely suggesting trying a newer snapshot to see if it's fixed there - backporting might help then
<laga> external. upstream doesn't like stacking file systems
<cjwatson> laga: if unionfs can be made to work, that pleases me far more than yet more bleeding-edge code
<cjwatson> stable > shiny
<laga> at least not in the way it's implemented by aufs/unionfs.
<pitti> I had quite a long argument with Arjan about out-of-tree drivers, and unionfs was my prime example
<StevenK> I bet cjwatson doesn't use compiz either.
<StevenK> </bait>
<cjwatson> StevenK: you would win that bet
<StevenK> cjwatson: :-)
<pitti> StevenK: nobody else is (except seb128, of course); it's not the default in intrepid :)
<Hobbsee> \o/ shiny!
<StevenK> Awww
<laga> cjwatson: i guess i should mess around with mythbuntu-diskless on intrepid to check if i can reproduce your oddities with that setup
<pitti> thanks to a combination of breakage in gnome-session, new X, and the X drivers
<ScottK> pitti: Debdiff for hardy-proposed for Bug 251472 is in the bug.  How are you with that for upload?  I've already asked to have the test case added to the bug.
<ubottu> Launchpad bug 251472 in net6 "gobby uses 100% CPU on files >500KB in size" [Medium,Fix released] https://launchpad.net/bugs/251472
<pitti> ScottK: oh, need a sponsor?
<ScottK> piI
<ScottK> Urgh
<pitti> the same just happened to kees
<pitti> did intrepid break the 't' key? :-)
<ScottK> pitti: I'll sponsor it, just I want to make sure since it's in Main, ubuntu-sru is happy with it.
<ScottK> pitti: No, this is my desktop I'm typing on.  It's still Dapper.
<ion_> Ï-tti
<pitti> ScottK: haven't thorougly read the patch, but size and shape-wise it looks ok to me
<pitti> and it apparently got tested
<ScottK> The person who did the patch is Upstream and Debian Maintainer, so I tend to trust it.
<pitti> right
 * pkern glances into the round.
<pitti> hello pkern!
<pkern> Hi pitti (:
<ScottK> pitti: I guess I'll focus on the 'looks ok to me' part of that and upload it.
<pranith> hello
<pranith> !start
<ubottu> Sorry, I don't know anything about start
<pranith> !getstarted
<ubottu> Sorry, I don't know anything about getstarted
<pranith> !ubuntu
<ubottu> Ubuntu is a complete Linux-based operating system, freely available with both community and professional support. It is developed by a large community and we invite you to participate too! - Also see http://www.ubuntu.com
<pranith> !motu
<ubottu> motu is short for Masters of the Universe. The brave souls who maintain the packages in the Universe section of Ubuntu. See  http://wiki.ubuntu.com/MOTU
<pranith> !help
<ubottu> Hi! I'm #ubuntu-devel's favorite infobot, you can search my brain yourself at http://tinyurl.com/5zfb6t - Usage info: http://wiki.ubuntu.com/UbuntuBots
<pitti> what's that, ubottu's test suite?
<StevenK> Hah
<persia> pranith: If you'd like to get started in Ubuntu Development, you might find #ubuntu-motu a better forum.
<pranith> persia, thank you :)
<cjwatson> pranith: please don't play with the bot in here
<pranith> cjwatson, okies
<cjwatson> or in channels, in general
<pitti> ember, tseliot: FYI, http://bazaar.launchpad.net/~jockey-hackers/jockey/trunk/revision/346 fixes the "multiple nvidia drivers are in use" problem properly
 * tseliot has a look at pitti's new code
<tseliot> ï»¿pitti: what do mean by 'mesa-vanilla'?
<pitti> tseliot: it is one of the mock packages which exist in the test suite sandbox
<pitti> tseliot: I have a few kernel modules (vanilla, chocolate, cherry, etc.), and a few packages (coreutils, mesa-vanilla, mesa-std, pretzel) to play around with
<pitti> tseliot: see tests/sandbox.py, fake_modinfo, fake_sys, fake_pkg, and fake_db
<pitti> s/fake_pkg/&info/
<pitti> tseliot: and TestOSLib implements the package and module interface to use the fake stuff
<pitti> that way I can write tests for hardware detection, driver mapping, and package handling without assuming anything about the real hardware, or OS
<tseliot> ï»¿pitti: yes, that's a good idea
<tseliot> ï»¿pitti: would you like me to pull the new code and test it here?
<pitti> tseliot: sure, if you wish, but I'm pretty confident that it works
<pitti> tseliot: let me merge to the ubuntu branch and push
<tseliot> ï»¿pitti: ok, in the meantime I'll boot into Intrepid
<pitti> tseliot: pushed
<tseliot> pitti: I'm back
<pitti> tseliot: pushed
<tseliot> pitti: pulled and installed
<pitti> . o O { that SO much beats sending patches over pastebin...}
<tseliot> pitti: definitely.
 * tseliot tries to install the driver
<tseliot> pitti: same problem with the backend
<pitti> tseliot: which problem? drivers still shown as 'used'?
<tseliot> pitti: no, drivers are not installed
<tseliot> pitti: shall I start the backend in debug mode?
<pitti> tseliot: hang on
<pitti> tseliot: wasn't that the problem with the $PATH not set? I fixed that yesterday...
<pitti> tseliot: yes, please try to start in debug mode
<tseliot> pitti: ok, it's installing the packages now
<tseliot> pitti: the package is installed and in use while others are not. It works
<pitti> good
<pitti> tseliot: so if you kill the backend and let it auto-spawn, package isntallatin/removal doesn't work?
<tseliot> pitti: shall I keep Jockey's gui open?
<pitti> shouldn't matter
<pitti> it will just cause respawns as soon as you hit it with the mouse (on a driver)
<pitti> but that's what you want, so it's ok :)
<pitti> tseliot: let me commit a debugging improvement I temporarily added yesterday
<tseliot> pitti: now that I have stopped the backend without closing the GUI, it seems to work well.
<tseliot> I can install and remove the drivers now
<pitti> hmm
<pitti> tseliot: so what was the issue you just had?
<pitti> can you replicate the situation?
 * tseliot tries again
<tseliot> pitti: it works well now even if I launch it from the menu after killing the backend. Let me try it as I did before
<tseliot> pitti: great, I can't reproduce the problem any longer :-)
<pitti> tseliot: if you pull and debuild again, you can change the .service file to add --debug --logfile=/tmp/log.txt
<pitti> tseliot: ah, neat; perhaps you previously had the intrepid package installed? last night's was faulty
<pitti> tseliot: I just added --logfile to jockey-backend, so that you can run it auto-spawned with debugging
<pitti> tseliot: (bug 251347)
<ubottu> pitti: Bug 251347 on http://launchpad.net/bugs/251347 is private
<tseliot> pitti: no, I hadn't installed Intrepid's package yet. I'll pull and debuild again
<pitti> tseliot: well, no need to, unless you can reproduce the problem
<pitti> tseliot: thanks for testing!
<tseliot> pitti: ok. BTW it might be a good idea to add some auto-detection magic or to change the description of each driver flavour. This can be done later when the other parts of Jockey are complete.
<tseliot> pitti: another thing: it doesn't tell me to restart my computer any more
<pitti> BenC (CC: mdz): would there be a place in "the kernel crashdump scripts" at all which could call apport's script for turning a .vmcore into an apport report? or do we need to do that in an init script? in the latter case, I'd rather have it in apport's, instead of adding yet another init script
<pitti> tseliot: restart> hm, bug; I'll have a look
<pitti> tseliot: autodetect> you mean if you have several matching drivers?
<tseliot> pitti: yes
<pitti> yeah, I'd much prefer just showing one driver instead of three
<tseliot> pitti: maybe you can show all the compatible drivers and highlight (in some way) the recommended driver
<tseliot> pitti: maybe something done in the treeview with pango?
<pitti> tseliot: how do you do that in envy?
<BenC> pitti: what do you mean by "apport report"?
<pitti> BenC: for bug 241322, mdz's comments
<ubottu> Launchpad bug 241322 in apport "Detect kernel crashdump" [Undecided,In progress] https://launchpad.net/bugs/241322
<BenC> pitti: I could create such a file/report when creating the vmcore
<BenC> no addition scripts needed
<tseliot> pitti: I have 2 modes: Automatic installation and Manual installation. Automatic = the recommended driver is installed. Manual=the user will chose a specific flavour (since sometimes certain flavours work better with certain cards)
<pitti> BenC: is that done at crash time? it'd involve a lot of python calls, etc., so it might not be appropriate when your kernel just crashed
<BenC> pitti: no, it's done when the system is rebooted into the crashdump kernel...if I can write ~200Megs of vmcore, I think I can execute python :)
<pitti> BenC: so would it be feasible to pipe the vmcore to /usr/share/apport/kernel_hook instead?
<pitti> BenC: (or write it first, and then pass it as an argument to the script)
<pitti> that might be more elegant
<pitti> let's call it /usr/share/apport/kernel_crash, for the sake of not mixing up with package hooks
<pitti> BenC: so all you'd have to do is <core dump write fd> | /usr/share/apport/kernel_crash
<pitti> BenC: this would avoid having vmcore files laying around, and adding special cases to the init script
<BenC> pitti: so if I pipe the vmcore to that script, it's all done?
<pitti> BenC: yes; the script would read from stdin, compress it, add it as a field "VMCore", and collect additional data from the system (dmesg, hal, etc.)
 * BenC wonders if 64M is enough memory to do that
<pitti> BenC: and write it out to /var/crash/linux.crash
<pitti> BenC: ah, you didn't mention that; it might be an issue, although I do pipelining carefully
<pitti> I don't suck it in as a big block, but process it in 1 MB steps (similar to what the normal crash handler does
<pitti> I have a test case which feeds (memory size) * 0.8 data to apport and watch memory usage
<pitti> but it's python, so that could have it's own unpredictable memory requirements
<pitti> BenC: so, in the end it might be better to just write it out as a file, and pick that up in the init script
<emgent> evening
<tseliot> emgent: hi
<BenC> pitti: I'll give it a good testing
<pitti> BenC: so what's your feeling, direct pipelining into python script, or pick it up in a full system at init time?
<pitti> (while the amount of memory that apport needs doesn't scale with the size of the core dump/kernel dump you feed to it, I can't make assertions about how much it really needs)
 * cjwatson looks at Anthony Baxter's "porting to python 3.0" presentation and watches python reinvent perlio
<ScottK> cjwatson: Link please?
<cjwatson> http://www.interlink.com.au/anthony/tech/talks/OSCON2008/porting3.pdf
<ScottK> Thanks.
 * ScottK sees slide 1 of 334 and chokes.
<cjwatson> StevenK: it's in Anthony's super-brief presentation style
<cjwatson> I mean, each slide has very little
<cjwatson> makes for much more interesting presentations, though not as good to read afterwards
<Keybuk> the man has the "next slide" button connected directly to his heartbeat
<ScottK> It is readable and I'm enjoying it.
<ScottK> Up to 79 already.
<Keybuk> there's a Japanese presentation technique where you only show full-slide pictures
<Keybuk> and you show each one for 20 seconds
<Keybuk> and the presentation lasts a fixed time
<Keybuk> or something
<kelemengabor> hi mvo
<kelemengabor> I got something for you :)
<kelemengabor> http://delfin.unideb.hu/~kg0021/add-packagenames.diff
<kelemengabor> the resulting pot looks like this: http://delfin.unideb.hu/~kg0021/packages.pot
<mvo> kelemengabor: nice! I will get the diff now, but I can merge it only tomorrow I need to run now
<slangasek> pitti: ask me about an upload of langpacks, that broke CD builds for pulling in a new package from universe :)
<kelemengabor> mvo: ok, thanks
<slangasek> TheMuso: not critical to include the pulse fix in alpha3, thanks, but I will want to errata it
<kelemengabor> there is a small problem with the encoding, however
<pitti> slangasek: uh, what, what? I only feel guilty about dropping all the aspell dicts from language-support, but that happened last week already
<kelemengabor> but not our fault :)
<pitti> slangasek: oh, hang on, openoffice-en-au?
<pitti> myspell-en-au, rather?
<slangasek> pitti: yes
<pitti> argh, terribly sorry for that; it's in main now, anyway
<surak> Wow, long time since the last time I was here!
<surak> Here goes a simple one for the devs: /usr/include/c++/4.3/cstdlib:108: error: â::ldiv_tâ has not been declared
<surak> I have this on dozens of functions (This is ibex, of course=
<cjwatson> surak: have you read http://gcc.gnu.org/gcc-4.3/porting_to.html ?
<surak> The list goest through half of the cstdlib : /usr/include/c++/4.3/cstdlib:113: error: â::atofâ has not been declared
<cjwatson> also, nobody can help without a test program, but make sure you have followed the porting guide first
<slangasek> pitti: yes, it's in main now; but since it wasn't coordinated, it broke a round of my livefs builds, and it looks like there are some packages on the alternate CDs that aren't installable without recourse to the network, as a result of that
<surak> Hello Kamion, How are you?
<cjwatson> if you intentionally use an old nick that my client no longer uses, it won't highlight
<cjwatson> please don't :)
<surak> oh, I'm sorry. Hello cjwatson, how are you? ;)
<cjwatson> fine, thank you
<surak> I'm with people from univ. of colorado & intel for this one, to make sure Pin, their dynamic instrumentation toolkit, works with Ibex.
 * infinity misses Kamion and vorlon....
<ion_> Who is vorlon now?
<infinity> slangasek.
<slangasek> infinity: join a Debian channel on OFTC, then? :)
<infinity> slangasek: I'm in a few!  It's not the same. :P
<slangasek> heh
<mdz> pitti: ignore my nonsense comment on 251441; I thought it was the other bug about the script to create the crash report
<slangasek> mdz: cjwatson tells me you're uploading dpkg for the liveCD installer crash; do you have an ETA?
<cjwatson> slangasek: https://launchpad.net/ubuntu/+source/dpkg
<slangasek> ... so ETA == end of publisher run, right
 * slangasek thinks he needs to get himself a commandline tool on drescher that will answer that question properly and with ease :)st
<cjwatson> reminiscent of antimony:~mdz/bin/awty
<slangasek> heh
<mdz> slangasek: was uploaded before you asked, should be in the queue now
<slangasek> mdz: indeed, thanks
<ScottK> slangasek: My condolences that you lost the minutes out of your life needed to write the why we freeze mail.  I'm actually shocked it was needed.
<slangasek> ScottK: oh, well, I had nothing better to do besides watch paint dry^W^W dpkg progress through the publisher so I can build desktop ISOs
 * ScottK looks around for a Main upload to do to keep slangasek's afternoon interesting.
<mario_limonciell> ScottK, i say you add more dependencies to ubuntu-meta that are in universe
<mario_limonciell> that will make slangasek excited
<mario_limonciell> ;)
<ScottK> Recommends are harder to troubleshoot.
<pitti> mdz: you mean the bit that transforms  vmcore into an apport report? I'm not sure, I'd think it was easier to maintain/ship it in apport
<mario_limonciell> pitti, oh i wanted to ask you about that jockey update that was going to introduce  the extra handler for hardy.  Did you and Tim get around to testing it?
<pitti> mario_limonciell: no, I asked rtg and you for testing; I don't have the hardware
<mario_limonciell> pitti, ah i had thought that rtg had actually gotten around to testing it, but i guess not then
<mario_limonciell> pitti, where's the branch?  I'll track down some other hardware and see what i can do
<mdz> pitti: yes
<jordi> crimsun_: ping
<jordi> crimsun_: I'm working on ALSA 1.0.17, and going over Ubuntu diffs
<jordi> crimsun_: but there's so much, that I'd really like to see some more of this going in Debian directly rather than on patches.ubuntu.com
<jordi> ie, what we talked prior to the hardy (or was it gutsy) release?
<jordi> crimsun_: currently, pkg-alsa lacks manpower and we'd really be happy to see you join the team, that would make Debian's life easier and Ubuntu merges a lot less painful I suspect
<jordi> doko: also, related to this, would you be available at some point to lend us a hand in the resolution of "#436201: libasound2-plugins: Could we get an ia32 package for amd64? "
<jordi> doko it was filed ages ago, and iirc you did the biarch stuff in alsa-lib
<jordi> TheMuso: ^ of course I'd be very happy if that could apply to you too :)
<doko> jordi: ia32-* iz universe, hit, hint
<doko> oops, s/hit/hint/ =)
<jordi> doko: but you do have ia32-libs in main?
<jordi> doko: last thing I know is the alsa plugins are in the ia32-libs and so on, which is *ugly*
<doko> jordi: no, not anymore.
<doko> at least not ia32-libs
<jordi> ok
<jordi> doko: anyway, if you're bored one day and want to have a look, I suspect it should be easy, once libasound2 was done
<jordi> but biarch stff is like black magic to me
<jordi> I remember looking at the alsa-lib patch you sent in and thinking "omg"
<doko> these are the upstreams which are broken, and trying to define architecture specific stuff on their own
<jordi> broken how?
<doko> jordi: if the module paths are used/referenced outside /usr/lib, e.g. /usr/share or /etc, then something is wrong
<jordi> doko: but are you talking about alsa-lib or alsa-plugins?
<doko> you did want to do alsa-plugins ...
<jordi> ie, do you know off-hand there was a problem with providing the 32 bit version of plugins cleanly?
<jordi> right, right
<doko> no, I didn't look
<jordi> aaah
<kirkland> doko: hi, lsb question for you.....
<kirkland> doko: actually, usplash too
 * doko quickly heads to bed ;)
<jordi> doko: I guess we should try to come up with a patch based on your alsa-lib hackery, try if it actually works and seek your help if it doesn't
<doko> jordi: sure
<kirkland> doko: http://pastebin.ubuntu.com/30089/
<jordi> post-lenny I'm afraid
<kirkland> doko: i'm about to open a bug, and post a debdiff with that change....
<kirkland> doko: the current "type" test will check if usplash_write exists
<kirkland> doko: but it ignores whether or not a user has permission to send messages to the usplash daemon
<doko> hmm, and it should fail, if usplash_write doesn't exist?
<kirkland> doko: right
<kirkland> doko: my change will preserve that
<doko> really?
<kirkland> well, if it's not in the path, anyway
<kirkland> hmm, well, there's a difference in exit code, 127 vs. 1
<doko> better ask a usplash/boot maintainer
<kirkland> doko: okay
<kirkland> doko: is that cjwatson, evand?
<evand> Is there a usplash maintainer?
<evand> I didn't think there was.
<kirkland> evand: can you recommend someone who knows a bit more about it than I?
<infinity> tjaalton: Ping?
<infinity> tjaalton: The --enable-glx-tls change in xorg-server appears to have royally broken xvfb.
<doko> infinity: ohh, verified this?
<infinity> doko: That seems to be what it's choking on.  Without that flag, it doesn't go hunting for dri libs (which fail to load for xvfb...)
<doko> infinity: hardy as well?
<infinity> doko: No, this was an intrepid change.
<evand> kirkland: I'm not quite sure, I believe mjg59 used to handle bugs on it, but I have no idea who does now.
<infinity> xorg-server (2:1.4.99.905-0ubuntu2) intrepid; urgency=low
<infinity>  -- Timo Aaltonen < tepsipakki@ubuntu.com>   Mon, 07 Jul 2008 11:44:39 +0300
<kirkland> evand: true, i saw his name through the source code
<infinity> That's when it should have broken, if I'm right...
<doko> bryce, bryce_: ^^^
<doko> hmm, now running intrepid on an intrepid kernel, the mauve tests do work
<infinity> Yeah, I'm on a hardy kernel here.
<cjwatson> kirkland: I don't see how that will have any useful effect. usplash_write.c main() starts:
<cjwatson>         if (argc < 2) {
<cjwatson>                 fprintf(stderr, "Usage: usplash_write COMMAND...\n");
<cjwatson>                 exit(1);
<soren> infinity: You wouldn't happen to have a deb compiled without that flag, would you?
<cjwatson>         }
<cjwatson> kirkland: so usplash_write with no arguments will always exit 1
<kirkland> cjwatson: hmm, okay, so here was my test case....
<cjwatson> kirkland: you could just check uid == 0 ;-)
<infinity> soren: You could grab 2:1.4.99.905-0ubuntu1 from launchpad, or I could build a new one...
<cjwatson> :q
<cjwatson> (sorry)
<soren> infinity: xserver-xorg-core, is it?
<kirkland> cjwatson: dustin@ubuntu:~$ sh /etc/init.d/ssh status
<kirkland> open: Permission denied
<kirkland>  * sshd is running.
<cjwatson> kirkland: any argument you might pass would actually get written to the usplash fifo; if you want to do this, you'll have to add an option to usplash_write to support it
<kirkland> cjwatson: (non root user checking status)
<ion_> :%norm A (meh)
<cjwatson> kirkland: sure, I understood the use case perfectly already, your code is just wrong ;-)
<infinity> soren: xvfb in my case.
<infinity> soren: But if it has to do with kernel dri/drm interfaces, any xserver would have the same problem, I suppose.
<kirkland> cjwatson: ah, good point ;-)
<kirkland> cjwatson: usage statement, even as root :-P
<cjwatson> kirkland: (it might have worked for you in testing, and it would certainly suppress that error, but only because it will prevent lsb-base-logging from ever writing to usplash)
<soren> infinity: Right. I'm just experiencing a bug that I can find the cause of, so I'm willing to try anything.
<kirkland> cjwatson: yup, i didn't test with root priv's, i see that now
<kirkland> cjwatson: okay, so seriously checking UID would be sufficient, you think?
<infinity> soren: Do you have an strace of the bug in question?
<soren> infinity: No, it hangs the machine.
<infinity> soren: Oh.  Probably a different bug, then. :)
<soren> infinity: Probably. Couldn't hurt to try, though. The very last thing I manage to see before it dies is something about going to look for DRI modules or whatnot.
<cjwatson> kirkland: I wouldn't lose any sleep over that approach, certainly, though it doesn't check whether usplash is running
<cjwatson> kirkland: I'd be cautious of anything that does very much more work, though, as it would slow down the whole boot sequence
<kirkland> cjwatson: looks like we need a usplash status action :-)
<kirkland> cjwatson: i'll add the uid check for now
<kirkland> cjwatson: that'll be quick
<cjwatson> it'll have to fork id for every init script
<cjwatson> the alternative would be to silently ignore EACCES in usplash_write
<kirkland> cjwatson: that would certainly be the most performant solution
<kirkland> cjwatson: one minute, let me test a patch to usplash.....
<cjwatson> a little bit evil, but then who uses usplash in other contexts anyway? :)
<infinity> I win!
<infinity> doko: For now, this works for me 'xvfb-run -s "-extension GLX" --listen-tcp --server-num=7 /usr/bin/make -k jtregcheck
<infinity> doko: Obviously still a bug somewhere, but if you run xvfb GLX disabled, as above, it works.
 * cjwatson -> bed, night
<cjwatson> kirkland: needs a big honkin' comment if you do take that approach, mind :)
<doko> ahh, will use that for the next upload
<kirkland> cjwatson: ;-)  righto
<kirkland> cjwatson: i see usplash is another one maintained in bzr
<kirkland> cjwatson: perhaps tomorrow, i need a run down on how my patch/bug/test workflow changes for bzr projects
<kirkland> cjwatson: i was quite confused by the differences you suggested to me for the grub merge
<infinity> doko: I might leave it to you to file the bug... I'm unsure on the "correct" fix... One half of me thinks it shouldn't break at all, the other half of me says "meh, the only thing xvfb is realistically used for is headless testsuites, maybe xvfb-run should just be told to disable GLX by default".
<jordi> can anyone enlighten me on the lpia arch?
<jordi> I'm adding lpia to all Debian ALSA packages
<jordi> but I see some alsa packages in ubuntu don't do this
<jordi> in short, should alsa-tools support LPIA?
<doko> infinity: on the other hand this might break python-glx (or something like that) builds
<infinity> doko: I suppose it's possible that something, somewhere, might have a GLX testsuite... If so, then this bug needs to be resolved.
<infinity> doko: Frankly, an Xserver that doesn't run on the previous release's kernel is a bit scary anyway, IMO.
<infinity> doko: If that is, indeed, the issue.
<infinity> doko: Makes for an upgrade nightmare, if users get X upgraded, and then the new kernel bombs, etc.
<crimsun_> jordi: yes, alsa-tools should.
<crimsun_> jordi: and, I'm traveling quite a bit, so I'm unsure how frequently I can contribute.  I'm already doing a lot of BTS work where I can.
<jordi> crimsun_: I saw
<jordi> crimsun_: I'd like to make the ubuntu diff a lot smaller
<infinity> jordi: Oh, sorry, missed the question.  In general, anything that can support lpia (which, at the toolchain level, is just a differently-optimised i686) should do so, pretty please.
<ion_> benc: Any guesses on the release of the next kernel image? Iâm not really in any hurry, but would just like to get to test the fixed compcache module.
<jordi> infinity, crimsun_: okay, new alsa packages will have it
<jordi> today's alsa-lib upload is the first one
<infinity> doko: Wow, that's a long testsuite...
<doko> takes 3-4h
<infinity> doko: I'm seeing that...
<infinity> doko: Oh well... I'm satisfied that it's working, I'll just Ctrl-C it. :)
<BenC> ion_: hopefully tomorrow
<ion_> benc: Alright, cool.
<tjaalton> infinity: so you've tried it without that option?
<infinity> tjaalton: No, it was some creative googling of errors in strace that led me to believe that's what broke it.
<infinity> tjaalton: For starters, it looks for dri libs (and xvfb doesn't depend on libgl1-mesa-dri), and once that's installed, it can't dlopen it due to unresolved symbols...
<tjaalton> infinity: oh, ok
<tjaalton> it probably tries to load swrast_dri
<tjaalton> or what was it called, can't check now
<infinity> 12:25 < infinity> [pid  5961] write(2, "(EE) AIGLX error: dlopen of /usr/lib/dri/swrast_dri.so
<infinity>                   failed (/usr/lib/dri/sw
<infinity> 12:25 < infinity> rast_dri.so: undefined symbol: _glapi_tls_Context)\n", 129) = 129
<infinity> 12:25 < infinity> [pid  5961] write(2, "\nFatal server error:\n", 21) = 21
<infinity> Yeah, it does.  And when it's actually there, the above happens.
<tjaalton> sounds like a bug then ;)
<infinity> According to doko, it works on an intrepid kernel, so I suspect some drm ABI breakage.
<infinity> Which would be a bit problematic for the real xserver too, on aborted/incomplete upgrades.
<tjaalton> that should be easily tested
<mpt> persia, my sound has gone again after resuming from hibernate
<mpt> (sorry, didn't realize until just now)
<mathiaz> kees: jdstrand: what are the valid caracters than you can find in crypt string ?
<mathiaz> kees: jdstrand: can you the ' and " in a crypt string ?
<mathiaz> kees: jdstrand: can you *have*
<crimsun_> mpt: which driver?  (cat /proc/asound/modules)
<mpt> crimsun_,  0 snd_intel8x0
<crimsun_> mpt: do you have a bug report I can look over?
<mpt> crimsun_, bug 80344
<ubottu> Launchpad bug 80344 in linux "Sound works only a few weeks per year" [Medium,New] https://launchpad.net/bugs/80344
<jdstrand> mathiaz: crypt as in crypt()-- man crypt says the glibc2 version uses [aâzAâZ0â9./]
<mathiaz> jdstrand: hm - thanks :)
<crimsun_> ah, -that- bug.
<mpt> yeah, that bug :-/
<crimsun_> mpt: amixer get 'Master Mono'|grep 'Playback.*%'
#ubuntu-devel 2008-07-25
<mpt> crimsun_, "Mono: Playback 25 [81%] [-9.00dB] [on]"
<crimsun_> mpt: and, amixer get 'External Amplifier'|grep Playback
<mpt>   Playback channels: Mono
<mpt>   Mono: Playback [on]
<crimsun_> mpt: if you would, please, attach /proc/asound/card0/codec97#0/* contents when sound is audible
<mpt> crimsun_, ok, I'll put that in the bug report so I remember :-)
<crimsun_> mpt: thanks.
<mpt> thank you
<TheMuso> slangasek: Re pulse and PC speaker, does backscroll give you enough info, or do you want me to IRC/email you a good description of what the problem is?
<slangasek> TheMuso: the one thing I don't have to hand at the moment is the bug number
<slangasek> though there's another bug about snd_pcsp breaking KVM, so the fact that snd_pcsp is a problem is already somewhat covered
<crimsun_> blacklisting the pc speaker makes more sense, really.
<TheMuso> crimsun_: And loose PC speaker functionality entirely?
<slangasek> blacklisting the pc speaker /also/ makes sense. :)
<crimsun_> (and by "blacklisting", I mean "have PA ignore it")
<slangasek> TheMuso: what "functionality" are we losing, exactly?
<TheMuso> crimsun_: I've a better idea. I have a patch that will make sure the pc speaker sink is loaded last by the hal module, so its available for those who want it, but not used by default unless there are no sound cards.
<slangasek> I don't see that we would ever want to use this as an output device, even when there are no sound cards
<crimsun_> I agree w/ Steve.
<TheMuso> Well I was talking about this with persia yesterday and he thought it would be considered a bug if it wasn't available.,
<crimsun_> has anyone actually said "oh, it works fine at a reasonable volume by default"?  If not, it's a pretty compelling case to not make it available.
<TheMuso> slangasek: I  hae one bug in mind, but checking to see whether any others are more relevant.
<TheMuso> crimsun_: I am of the same view TBH.
<persia> My main thought was that upstream put it there, and there is documentation.  If we can make it not broken (using PC Speaker by default), and still support it for whatever use case it exists to support, that would be better.
<persia> If this is especially hard, dropping it is perhaps correct.
<slangasek> TheMuso: *I* consider it a longstanding bug that my computer beeps at me like a petulant robot child, and have always blacklisted the pcspkr module on my system; I just have never filed it, or bothered to complain until it became correlated with much more serious bugs
<ogra> it just wants to start a conversation ...
<ogra> and you ignore it !
<crimsun_> persia: the real problem, IMO, is that there's no sane level for "reasonable by default", which is a long-standing issue WRT sane levels attempted in alsa-utils's initscript (to erm, little success).
<TheMuso> slangasek: Bug 242966.
<ubottu> Launchpad bug 242966 in pulseaudio "snd_pcsp can take precedence of soundcards" [Medium,Confirmed] https://launchpad.net/bugs/242966
<TheMuso> Alright, I'll revert to my original patch, which prevents pulse from loading pcspkr as a sink.
<TheMuso> Oh, and since pulseaudi o0.9.11 has landed, sooner than I expected, do we want to consider it for intrepid, given that we are a few months out from release?
<slangasek> is that the version that requires the alsa upgrade that the kernel team hasn't committed to yet?
<persia> crimsun_: True.
<TheMuso> slangasek: Yes, what do you mean not ocmmitted to? Is this documented somewhere?
<slangasek> TheMuso: weren't you asking just the other day about whether to ask the kernel team to update the version of alsa in the kernel?
<slangasek> if you haven't asked them yet, then I guess they haven't committed to it either
<TheMuso> slangasek: Right, I haven't asked them due to what you said about considering sticking with 1.0.16.
<TheMuso> However, 1.0.17 has support for more hda hardware for notebooks.
<TheMuso> So if we don't go that route, those additions will have to be backported.
<slangasek> sorry, what did I say that gave you the impression I thought we should stick with 1.0.16?
<TheMuso> langCan't exactly remember without checking logs, but thats the impression I got.
<TheMuso> slangasek: ^^ gah typing
<crimsun_> (you really will want 1.0.17 if for nothing else than vmaster migration to core and HDA codec quirks)
<TheMuso> crimsun_: Right.
<slangasek> TheMuso: I tend to ask lots of questions about the decision making process when I see that someone is discussing an issue that could become release-critical if things go pear-shaped; this usually doesn't mean that I'm attached to one decision or another unless I explicitly say so :)
<slangasek> I'm happy for you to proceed with talking to the kernel team and find out whether 1.0.17 is considered reasonable from their end
<TheMuso> slangasek: Ok I'll keep that in mind.
<hwilde> is there something on boot that tries to get on any open network??
<hwilde> coworker observed it on the client  "I was running iwconfig every second. It shows the free wifi at that point, but by the time everything is loaded we are on the correct ssid. "
<hwilde> orion caught the snmp trap    apf_policy.c:538 APF-1-DISCONECT_MOBILE_DUE_TO_WLAN_SWITCH: Disconnecting mobile 00:16:6f:b4:0d:68 due to switch of WLANs from 4 to 6
<hwilde> tell me this is not possible, how could ubuntu possibly get onto free wifi on boot before /etc/network/interfaces is loaded up
<hwilde> tell me their wlan id are screwed up and ubuntu is infallible
<slangasek> hwilde: /etc/network/interfaces is not how wireless is configured by default in Ubuntu; maybe you can provide more information about your setup?
<hwilde> slangasek, 8.04 server stripped down, no network manager
<hwilde> how is it configured by default in Ubuntu
<slangasek> using network manager :)
<slangasek> if you aren't using NM, then there's nothing that would bring up a network prior to /etc/network/interfaces
<hwilde> they are saying it's hopping onto an ssid for free wifi on boot,   then it goes to correct ssid
<slangasek> I can't promise that this means the kernel driver won't associate with an AP on its own
<hwilde> how is that even possible
<ogra> cjwatson, see bug 251066, i thought i rememebred to fixed the CD unmounting in one of the last alphas ....
<ubottu> Launchpad bug 251066 in ltsp "LTSP fails to install from Alternate CD" [Undecided,New] https://launchpad.net/bugs/251066
 * ogra wonders why that returned
<ogra> s/to/you/
<hwilde> slangasek, is the kernel module ipw2200 or ieee80211 ?
<ogra> i doubt the kernel driver doesn aynthing on its own ... you usually need wpasupplicant to do the assocation
<Martiini> Has intrepid alpha 3 been released yet ??
<hwilde> ogra, thats the thing it's open
<ogra> i mean the driver wont do anything on its own
<hwilde> it has to be their wlan ids are borked
<hwilde> it's just not possible :/
<slangasek> Martiini: no, we're in the final stages of validating it
<Martiini> slangasek: do you work on ubuntu as we speak ?? do you actually work at canonical as a developer ?
<infinity> Martiini: He's the release manager.
<Martiini> are you serious ?!
<infinity> Always.
<ogra> infinity, liar ...
<slangasek> well yes, you joined the Ubuntu developers channel, so there are Ubuntu developers here :)
<infinity> ogra: s/Always/Often/ ?
<ogra> :)
<Martiini> Do you work in one geographical location or all over ? how do you communicate .. git and launchpad and irc ??
<Martiini> Do you know any developers from scandinavia ?
<ogra> we use bzr, not git
<Martiini> I just watched google video where Torvalds talks about git
<ogra> thats what kernel.org uses to develop the kernel, right
<Martiini> apparently ,, I know nothing really
<LaserJock> Martiini: there are Ubuntu developers everywhere ....
<hwilde> Georgia Institute of Technology??
<ogra> heh
<LaserJock> Martiini: there's probably one looking over your shoulder right now
<Martiini> Thanks, I feel safer now :)
<slangasek> Martiini: we have community summits twice a year, and Canonical has team sprints at other times, to allow face-to-face collaboration.  But bzr, launchpad, IRC, and mailing lists are the primary means of collaboration the rest of the time, yes; https://wiki.ubuntu.com/UbuntuDevelopment is a good overview
<Martiini> ok, thank you
<Lightkey> LaserJock: that one scared me there..
<LaserJock> mwuahahahaha
 * LaserJock slinks back to his evil lair
<ogra> putting a mirror behind your monitor might help :)
<ion_> martiini: That video is awesome. :-)
<Martiini> Torvalds is a nice person .. typical Helsinki swede
<Martiini> ubuntu and linux development is too slow .. all the best developers in the world SHOULD be working on linux .. I have posted countless threads about this subject on ubuntuforums.org .. but the common voice means nothing obviously
<Martiini> linux OS-s must become the mainstream os one day .. but as it is .. its going to be a VERY long wait
<hwilde> ppl typicaly use that arugment against ubuntu
<hwilde> says shuttlesworth should've just funded debian
<Martiini> no .. as far as I understand .. they are different distros with different views , strategies ,, organization etc
<hwilde> lol what are you in debate class
<hwilde> "no"
<Martiini> I just cannot see linux provide sufficient competition to OSX and Microsoft ... but this is not the place to start voicing my layman opinions
<hwilde> dell.com/ubuntu
<ogra> yes, but the competition avoids monoculture like windows brought us ... there are a gazillion different solutions for a problem ...
<alex-weej> monoculture isn't all bad, though. it's just bad when it's unhealthy.
<ogra> soemtimes ubuntu might not have the right one, but anther distro has, so it can be adapted from there .... that raises the overall quality ...
<alex-weej> there is no downside to the entire planet standardising on the metric system, for example.
<Martiini> its taking too long .. linux development speed is increasing every year but it still hasnt exploded
<alex-weej> Martiini: then be patient
<jcastro> Martiini: hop in dude
<alex-weej> or do something about it. what did you hack today?
<hwilde> lol
<hwilde> jcastro,   lol I love telling people at work that complain like that   "well, you do know it's open source..."
<ogra> alex-weej, well, on teh other hand only having one kind of birds on the whole planet would be kind of boring and leave us with a lot of nasty insects
<ogra> ;)
<hwilde> if the birds kept breaking my dual-head nvidia xorg.conf every update they might end up that way...
<ogra> dont blame the birds for closed source !!
<persia> hwilde: Always remember birds eat bugs
<hwilde> birds eat worms dude
<Martiini> yes, and why do they still use imperial system in USA
<hwilde> spiders eat millions of bugs
<persia> Yep.  So we need both birds and spiders.  Diversity is good :)
<hwilde> google calculator  will be the end to unit conversion
<hwilde> who needs to know that crap when google can translate for you
<Martiini> USA is a backwards country  .. imperial :)
<alex-weej> Martiini: FWIW though, i agree, but everything we have in place right now with our million different distros is serving a purpose.
<ogra> Martiini, because they also run "worldcups" where nobody apart from the US is involved probably :)
<alex-weej> ISV support would come more confidently if there was only Ubuntu
<alex-weej> but there isn't.
<hwilde> what is "ubuntu" anyways?  it doesn't actually exist
 * alex-weej blinks
<hwilde> it's a collection of packages, gnome, xorg, etc
<Martiini> USA World cup and World Series :)
<alex-weej> no way
<alex-weej> Ubuntu is my operating system.
<hwilde> it's a bunch of online tools and forums and communitiies
<hwilde> ok then what "is" ubuntu
<ogra> and a trademark :)
<alex-weej> i don't use Linux.
<ogra> you do
<hwilde> it's the collective of developers who make it and the people who use it
<ogra> but only as part of ubuntu
<alex-weej> ogra: *I* don't use Linux.
<alex-weej> if all else was the same, Ubuntu could be running NTOSKRNL for all i care
<ogra> you developed ubuntu with bsd kernel and made it not available to the community ? evil you !
<persia> hwilde: It's the collective of people who create it (not just developers) and the people who use it.
<hwilde> lol what like project managers
<hwilde> gantt charts dont make modules
<alex-weej> and artists, and usability geeks
<hwilde> developers and users
<hwilde> well those people are included
<hwilde> hci = development
<alex-weej> seriously though
<hwilde> graphics and visualizations = development
<persia> Yes, and artists, and musicians and usability reviewers, and testers, and integrators and triagers and more
<alex-weej> anyone up for porting Ubuntu to NT?
<ogra> feel free
<ScottK-laptop> alex-weej: Have fun with that.
<alex-weej> :D
<ScottK-laptop> Don't forget that Ubuntu is virtually all about integrating the work of others.
<hwilde> and improving on it :)
 * ogra just had a presentation at OSCON from a company that developd a kind of "reverse wine" to run linux apps on windows :)
<hwilde> ubuntu handles rpms better than my redhat box
<alex-weej> cygwin?
<ogra> no
<ogra> LINA
<ScottK-laptop> When you say stuff like "I use Ubuntu, I don't use Linux" that, to my mind, devalues the work of the people who actually make the stuff Ubuntu integrates.
<alex-weej> ScottK-laptop: well don't take it personally.
<hwilde> ScottK-laptop, thank you that is waht i'm saying.  it's really gnome, and ext3, and launchpad, and xorg,  etc
<ScottK-laptop> alex-weej: I'm just telling you how it sounds to me.
<hwilde> "ubuntu" only means this specific group of creators and users
<ScottK-laptop> hwilde: For me except not the Gnome part.
<hwilde> fine bash and ssh whatever
<ogra> ubuntu is an ancient african word maning ....
<ogra> *meaning
<hwilde> there is no src code for "ubuntu"
<hwilde> its a collective
<ScottK-laptop> hwilde: No, an actual DE, KDE.
<ogra> its a spirit as well
<hwilde> ScottK-laptop, , ice owns u
 * ScottK-laptop goes back to trying to make source port randomization work in python-dns.
<hwilde> true randomness is elusive.
<alex-weej> the problem i find is that every layer of ubuntu itself lacks any form of common design
<ogra> ??
<alex-weej> operational conventions in linux are dissimilar to those in X are dissimilar to those in GNOME
<alex-weej> is everything a file?
<hwilde> ?
<hwilde> have you ever heard of unix
 * Hobbsee looks in
<hwilde> that is the common design
<ScottK-laptop> hwilde: Fortunately for this to work it doesn't need to be truly random.  It just needs to be not in a really obvious pattern.
<alex-weej> hwilde: that's what i'm saying
<alex-weej> everything is a file is old unix hangover
 * ogra looks out ...
<ogra> ... and sees Hobbsee
<ogra> :)
<hwilde> ScottK-laptop, make sure you seed your random generator   *glares at ssh-keygen*
<ScottK-laptop> alex-weej: That's because they weren't designed commonly.
<alex-weej> ScottK-laptop: i understand this
<hwilde> yeah they also lack the common flaws of microsoft and the stagnation of their monopoly
<alex-weej> hwilde: irrelevant
<hwilde> what you call lack of common design is actually the competition that makes it successful
<hwilde> you don't even use linux
<hwilde> why are you even here
<hwilde> lol
<hwilde> get a mac
<alex-weej> hwilde: when was the last time you directly interfaced with Linux
<hwilde> make cheesy commercials
<ScottK-laptop> hwilde: I looked at Python's SystemRandom takes from /dev/random on Linux, so it's unlikely I'll do better.
<ogra> hwilde, because he wants to port ubuntu to NT
<alex-weej> and i'm running Ubuntu on a MacBook Pro :P
<hwilde> I prefer a wireless keyboard to direct interface
<hwilde> lol
<ogra> modprobe hwilde
<alex-weej> i'm just suggesting it would be a much more attractive platform if, for example, the lower level tools were even using the same TYPE system as the higher level tools
<hwilde> that's what ubuntu needs is an advertising plan
<Hobbsee> ogra: :D
<hwilde> hi I'm linux... and i'm a pc
 * ScottK-laptop points hwilde at #ubuntu-marketing.
<hwilde> ogra, sudo modprobe duh
<ogra> geeez silly me
<hwilde> lol
<ogra> :)
<hwilde> and maybe -r
<hwilde> would be more funnier
<ogra> that would deinterface you :)
 * ogra needs to rush out, the others want to go for dinner
<hwilde> you are a jambalaya ingredient typo
<alex-weej> bye
<hwilde> Hobbsee, are you a dj
<Hobbsee> hwilde: no.
<alex-weej> DJ Hobbsee on the ones and twos
<Hobbsee> do you have something constructive to add?
<alex-weej> little bit hostile there.
<diogo> hi... How can I get ubuntu patches that it used to compile xorg 1.4.0.90 on Hardy... and how do I get the steps it used to compile it?
<hwilde> Hobbsee, do you know waht secondayr myogenesis is
<StevenK> diogo: The patches are probably split out in the source package.
<Hobbsee> hwilde: how does that relate to the development of ubuntu?
<diogo> sorry really newbbie on DPKG packages styles... is the source file the xorg 7.3_orig.tar.gz ?
<hwilde> holy shit this isn't offtopic ??
<Hobbsee> no...it's not...
 * hwilde looks around
<hwilde> what is with all this jibber jabber go back to idling you offtopickers
<diogo> do you provide the source already patched or is it a source with the patches
<StevenK> diogo: That's one of three files. And I'd have to check.
<hwilde> Hobbsee, now that your here, why would ubuntu associate to free wifi on boot automatically, no network manager?
<diogo> could you check it please trying to understand why xorg on ubuntu is having better performance with fglrx than on others... to report it to ATI Devs
<Hobbsee> hwilde: i believe that answering such questions counts as "support".
<Hobbsee> and apart from that, I don't know.
<hwilde> Hobbsee, nobody in support knows... last chance is devs
<hwilde> I just don't see how its possible :/
<hwilde> I would like to develop a module to stop it
<Hobbsee> modprobe -r the card?
<hwilde> I need the card obviously
<hwilde> but why is it hopping to an open ssid that it knows nothing about
<Hobbsee> i've no idea.  mine doesn't.
<hwilde> that's what you think
<hwilde> that's what I thought up to yesterday
<Hobbsee> well, on the basis that i don't have a network connection when i'm not running network manager...
<hwilde> i have an eye witness, and an error from the wlan controller, that says on boot it hops to open wifi
<slangasek> Hobbsee: it wouldn't bring up your tcp stack; that doesn't guarantee it won't associate with an AP
<Hobbsee> slangasek: ah
<hwilde> and I don't buy it's the kernel module slanga
<persia> AP association may even be driven by firmware without regard for OS directives
<hwilde> module just sit there they don't associate automagically
<hwilde> Intel says the mini pci card firmware won't do anything unless you tell it to
<slangasek> hwilde: well if you don't believe it's the kernel module, then you have something else running on your system that no one else does.
<hwilde> believe me, I've spent hours defending ubuntu
<hwilde> there's no way I can see it hopping on free wifi
<hwilde> but they actually caught it on their controller
<hwilde> apf_policy.c:538 APF-1-DISCONECT_MOBILE_DUE_TO_WLAN_SWITCH: Disconnecting mobile 00:16:6f:b4:0d:68 due to switch of WLANs from 4 to 6
<ScottK-laptop> As you've been told, it may be out of the kernel's hands.
<hwilde> and therein lies the problem
<hwilde> you don't see it as an "Ubuntu" problem
<ScottK-laptop> Right, but it's nothing to do with Linux or Ubuntu or whatever you call it.
<hwilde> blame the kernel, blame the firmware, blame the wlan controller, etc etc
<diogo> hey, if I'm not mistaken just looked at the xorg-xserver installation way of ubuntu and saw it added no patches... so Xorg 1.4.0.90 has no patches on ubuntu?
<ScottK-laptop> diogo: You're mistaken.
<ScottK-laptop> hwilde: What wifi chipset and were you using an completely FOSS configuration (no proprietary firmware/driver)?
<hwilde> ScottK-laptop, intel 2200bg mini pci card,  ipw2200 module
<diogo> so how can I get these patches?
<Hobbsee> patches.ubuntu.com?
<diogo> on patches.ubuntu.com has the patche for the 1.4.2 and not the 1.4.0.90 I need the older group of patches!
<StevenK> The patches are in the source package.
<diogo> where in the tar.gz package there are a lot of stuff there
<Hobbsee> in the .diff.gz
<StevenK> The orig.tar.gz is the original upstream source, the .diff.gz contains the Ubuntu and Debian changes and the .dsc ties them both together
<slangasek> hwilde: a) this is not a support channel, b) I'm telling you the only thing in the stack that could do this is the kernel module itself because there's nothing else in an Ubuntu system that *could* associate with an AP prior to /etc/network/interfaces if you don't have Network Manager installed; so I'm trying to steer you in the right direction towards a solution, not "blaming" something.
<diogo> sorry but I downloaded the http://archive.ubuntu.com/ubuntu/pool/main/x/xorg/xorg_7.3+10ubuntu10.tar.gz and got no .diff.gz on the source
<StevenK> diogo: Oh, you want xorg-server, not xorg
<diogo> yes xorg-server
<slangasek> now, if you're not actually going to make use of such help when it's offered, I don't see what you expect to get out of this channel for your trouble
<StevenK> diogo: That link you pasted is 'xorg', though :-)
<diogo> k
<Hobbsee> diogo: there's a similarly named one there, in the correct directory, ending in .diff.gz - that's the one that contains the ubuntu changes.
<diogo> k
 * cody-somerville takes a deep breath and goes to bed.
<hwilde> slangasek, ok thank you for confirming my suspicion that it just wasn't possible.  i'm blaming their wlan ids it's not ubuntu's fault
<diogo> sorry to annoy again but... on http://archive.ubuntu.com/ubuntu/pool/main/x/xorg-server/ there is the patches for lots of versions but the 1.4.0.90 is not there the question is... which 1.4.1~git is the ne used on hardy?
<hwilde> slangasek, I have to be absolutely sure before throwing down with customer IT
<diogo> sorry
<diogo> my mistake
<diogo> already solved it
<diogo> :)
<diogo> thx
<Hobbsee> :)
<hwilde> slangasek, arguing with ubuntu-dev provides that level of confidence.    beyond a reasonable doubt and all that you know
<slangasek> hwilde: well, I'm not saying that it's not possible; I'm saying that nothing in userspace on a pristine Ubuntu system does this
<hwilde> it's not possible
<hwilde> that's my story and i'm stickin to it
<slangasek> ok; that's your statement. not mine. :)
<hwilde> if nobody here can shoot holes in it then neither can the customer it group
<hwilde> they lose.   ubuntu wins
<hwilde> I logged the SSID every 5 seconds on all 5 clients today and send them the log file :)     over 38k entries and never once switched ssid's
<ScottK-laptop> hwilde: Making stuff up and spreading it is not an Ubuntu win.  It needs to be accurate.
<hwilde> so then what would you suggest... Intel says it's not their firmware
<hwilde> I don't believe it's the ipw2200 module
<hwilde> and it's nothing in ubuntu
<hwilde> so their wlan ids are messed up
<hwilde> only possible explanation
<Hobbsee> right.  who broke thunderbird?
<StevenK> Is the next line, "Come on, own up!"
<ScottK-laptop> Hobbsee: That would be Mozilla Corp since we can only do stuff they say it OK.
<Hobbsee> http://rafb.net/p/W8zgz343.html
<ScottK-laptop> Because that's how Free Software <<<<<<< stupid corporate policies work.
<RAOF> ScottK-laptop: being a grumpy old man in #ubuntu-* since 1782 ;)
<RAOF> (Not that I disagree with the comment at all)
<ScottK-laptop> Personally I think we compromised to much on that one.  It's Free as long as you make this other set of changes to change the branding, isn't freedom at all.
<RAOF> Yeah.
<kirkland> TheMuso: ping
<TheMuso> kirkpong
<kirkland> TheMuso: :-)
<TheMuso> kirkland: PONG
<kirkland> TheMuso: howdy, i'm working on bug #120375
<ubottu> Launchpad bug 120375 in initramfs-tools "cannot boot raid1 with only one disk" [Undecided,Confirmed] https://launchpad.net/bugs/120375
<kirkland> TheMuso: I just posted a pair of patches, one to mdadm, one to initramfs-tools
<kirkland> TheMuso: actually, see the last 3 posts...  the one just before the pair of patches has a decent explanation
<TheMuso> kirkland: You'd like me to look them over?
<kirkland> TheMuso: I would, very much
<kirkland> TheMuso: fwiw, kees pointed me in your direction ;-)
<TheMuso> kirkland: Right, no problem.
<TheMuso> kirkland: The initramfs-tools patch looks sane. Tooke me a bit to work out why you had to do things as you did, but I understand why so thats fine.
<kirkland> TheMuso: can you think of any negative effects of executing the failure hooks code earlier?
<kirkland> TheMuso: i certainly benefit from the positive effect of doing it earlier :-)
<kirkland> TheMuso: but i was having a hard time thinking of negative effects....
<kirkland> TheMuso: also, I remove the "-r" bit from the panic() call ...  the could perhaps go back in (calling the failure hooks in both places)
<TheMuso> kirkland: The one problem I can think of that I still need to address in initramfs-tools is the issue where if usplash is used, no failure text is displayed when dumped to the initramfs. Having a separate call failure function makes implementing a solution for this a little more tricky.
<TheMuso> To busybox I mean.
<kirkland> hmm, how so?
<TheMuso> Atm when crashing out of boot when usplash is used, you get an (initramfs) prompt, which is on tty8, and the error text is on tty1.
<kirkland> TheMuso: panic -r will still call the failure function
<kirkland> TheMuso: erg, that's messy
<TheMuso> So we need to switch to tty1 before any text is displayed that the user needs to read.
<kirkland> yeah
<kirkland> TheMuso: so I see that initramfs-tools is in bzr; i should probably move my debdiff patch over to bzr branch, right?
<TheMuso> kirkland: I have a solution in mind, but I need to run it by cjwatson and maybe others before doing it, as it involves putting chvt into the initramfs, and depending on console-tools or whatever package chvt is in.
<TheMuso> kirkland: It is?
<kirkland> https://launchpad.net/ubuntu/intrepid/+source/initramfs-tools/ makes it look like so
<TheMuso> hrm I don't see anything.
<kirkland> TheMuso: https://launchpad.net/initramfs-tools
<kirkland> upstream anyway
<kirkland> TheMuso: okay... the mdadm patch?
<kirkland> TheMuso: any comments there?
<TheMuso> kirkland: No looks fine.
<kirkland> TheMuso: cool, thanks for looking them over
<TheMuso> Sorry, my desktop is giving me a little grief atm. After several hours of use, I get an oops + segfaulting. There is something in linux htat I am using that is leaking memory which eventually causes issues. When I reboot and run memtest, memory looks bad, but when I switch off and on again, i.e no reset, everything is fine.
<TheMuso> I am just about 100% sure its not hardware.
<kirkland> TheMuso: ugh, that's no good
<kirkland> TheMuso: out of curiosity, are you using wireless?  if so, which driver?
<TheMuso> kirkland: No it isn't good, and no I am using wired, nm is removed. I am using nvidia drivers though, latest envy packaged ones, not from LRM.
<kirkland> TheMuso: ah...  well, i'm getting a nasty hard hang if I download something large, and fast over my atheros wireless
<TheMuso> Well I am on hardy as well.
<kirkland> TheMuso: yep, this is hardy that i'm seeing this
<TheMuso> Ouch.
<kirkland> i've been meaning to try the ath5k driver
<TheMuso> Well I am pretty sure its something X related for me, as I had this desktop running all last week during the sprint, and when SSHing to do stuff, never had this problem.
<superm1> kirkland, did you have any luck with trying out that alternate tethering method?
<kirkland> superm1: hadn't tried, sorry
<superm1> ah okay
<kirkland> superm1: been slammed ;-)
<srbaker> heya folks
<srbaker> is jeff waugh on this chan?
<srbaker> or, better yet, anyone from Melbourne, AU?
<Hobbsee> srbaker: he goes by jdub, but would be normally found in #slug.
<srbaker> great, thanks
<Hobbsee> wgrant: is from melbourne, but isn't here atm.
<srbaker> ah, he's in sydney not melbourne
<srbaker> although i guess anyone from .au is fine
<srbaker> it's more cultural questions i have
<Hobbsee> try #slug, then
<srbaker> thanks
 * NCommander investigates the possiblity of bootstrapping Ubuntu ARM
<pitti> Good morning
<Hobbsee> pitti!
<nxvl> hi all
<nxvl> Hobbsee: i have just saw your mail on -motu, it's sad to hear that your are going away
<nxvl> Hobbsee: but i assume is for personal/time reasons an temporaly
<nxvl> Hobbsee: so, have good look doing what you need to do and i hope you will be back soon
<nxvl> :D
<Hobbsee> nxvl: perhaps.  we'll see :)
<nxvl> pitti: you don't even think on steping out, we will need like 100 people to replace you
<nxvl> :P
<pitti> nxvl: hm? did I say that anywhere?
<pitti> (*blush*, thanks)
<nxvl> pitti: no, just joking around
<pitti> *phew* :)
<nxvl> actually repeating a joke i heard on Prague
<nxvl> :P
<slangasek> about replacing pitti with the crew of a trireme?
<nxvl> about how many people will need canonical to replace pitti
<pitti> Let me assure you that I am just one person
<nxvl> pitti: yes, but working as 40
<nxvl> everywhere i try to jump in, someone (or something) mention you
<nxvl> is like, you are everywhere
<pitti> nxvl: thanks :)
<nxvl> pitti: no, thank you for making my system better (almost every part of it)
<saivann> +1
<LaserJock> I'd like to +1 nxvl on that one
<nxvl> yeah, we love pii
<nxvl> pitti*
<saivann> Sounds like pitti is really appreciated :)
<nxvl> damn kayboard
<nxvl> keyboard*
<StevenK> There's another bug. Random Ubuntu developers seem to lose their 't' key
<nxvl> saivann: yes, we love pitti
<LaserJock> suuure, blame it on the keyboard
<StevenK> kees, ScottK and now nxvl!
<nxvl> well, i'm sleepy, and i may not pressing keys hard, also 't' key is in the middle where i need to move my fingers more to press it
<pitti> StevenK: haven' noiced so far
<nxvl> so it was just not a good pressing
<slangasek> --> dvorak
<StevenK> pitti: :-P
<pitti> slangasek: I actually tried that for a couple of weeks, but my utterly slow response in IRC channels and everywhere else annoyed me so much that I gave up :/
<pitti> you have to get "over the hump" with it, I guess
<StevenK> slangasek: Did you move the keycaps as well?
<nxvl> i have tried a french keyboard (don't remember what type was) and i almost died
<slangasek> pitti: yes; I did this a decade ago when I was studying overseas and had a small laptop keyboard that was hurting my hands, and no work-related reasons to be typing :)
<slangasek> StevenK: only during training
<pitti> oh, and using dvorak in vim is quite confusing as well :/
<pitti> I don't actually think about which letters to press most of the time, it's just muscle memory
<pitti> so it'd take learning typing *and* controlling vim again
<pitti> I think I'll teach my children dvorak straight away, to save them the hassle of switching :)
<nxvl> heh
<nxvl> yeah
 * pitti crosses fingers that this i386 desktop test install will work now
<nxvl> is a problem that you notices when some ask "what did you press to do that" and you actually don't know, your fingers just did it somehow
<slangasek> right; there are probably vim remappings though, to let you use the keys in the same positions :)
<slangasek> since the direction keys aren't so intuitive under dvorak
<nxvl> i'm going to sleep
<nxvl> read you!
<nxvl> have a nice day!
<snadge> does anyone happen to know if framebuffer is enabled on the xen kernel image?
<snadge> i've spent hours stuffing around trying to get the graphics console to work.. as well as the standard xen serial console (which works)
<snadge> i give up
<snadge> i can see that framebuffer is compiled as a module.. but i just dont know enough about ubuntu or xen to know why its not working
<pitti> siretart: ffmpeg-free was removed in Debian with "obsolete source package", but it's not obsolete in intrepid; what's the current structure supposed to be?
<siretart> pitti: the same. intrepid already has 'ffmpeg-debian', which replaces 'ffmpeg-free'
<siretart> pitti: good morning, btw :-)
<pitti> siretart: but if I would remove ffmpeg-free, a lot of binary packages would go with it, such as libavutil-dev, libavformat52, etc
<pitti> siretart: good morning! *hug*
 * siretart hugs pitti back
<siretart> pitti: err, they all are built by ffmpeg-debian as well
<siretart> I don't quite understand why they should be removed?
<siretart> ah, dependency wait
<pitti> siretart: it seems that ffmpeg-debian isn't current, yes
<siretart> libdc1394-22-dev is in universe
<pitti> siretart: so I think the display is just confused, it will only remove the even older binaries
<siretart> pitti: waht is the plan with libdc1394-22? it is supposed to replace libdc1394-13-dev AFAIUI
<pitti> no idea, tell me :)
<siretart> well, I was told that it is the new version of firewire libs
<siretart> so fabian, my co-maintainer in debian decided to switch to the new libs. I tried to make the package usable against both version, but that caused subtle breakage
<siretart> so we fixed the dependencies to the new version
<siretart> I don't really have a clue about firewire and libs, but I suspect that it might be a good idea to replace the source package libdc1394-13/main with libdc1394-22/universe
<siretart> replace in terms of 'promote -22' and 'demote -13' in exchange
<siretart> BenC: can you comment/clarify the situation of libdc1394-22 vs libdc1394-13?
<pitti> siretart: yes, I guess this makes sense; however, I'll  do that after alpha-3, just to be sure
<pitti> argh, since today's dist-upgrade, seahorse/ssh doesn't work any more -- "Agent admitted failure to sign using the key."
<pitti> does that happen to anyone else?
<RAOF> pitti: That kindof happens to me; if I try to connect via cooperteam.net it says that, but everything works using raof.local, which refers to the same box.
<pitti> siretart: I promoted -22, so that ffmpeg-debian can build
<siretart> pitti: thanks!
<cjwatson> kirkland: https://wiki.ubuntu.com/BzrContributorHowto
<cjwatson> TheMuso: just turn on chvt in the busybox initramfs config?
<cjwatson> kirkland: but, as TheMuso implied, I don't think that our initramfs-tools is in bzr; AFAIK (not having checked recently) the one on LP is old, from before upstream moved to git
<davmor2> My blog post on planet about how non-devs can get involved seems to of attracted an artist who can I put them onto?
<Tm_T> davmor2: #ubuntu-artwork ?
<davmor2> cool thanks
<Sianis_> mvo: are you here?
<mvo> Sianis_: yes
<Sianis_> great
<Sianis_> can we talk in private or stay here?
<Sianis_> mvo:
<Sianis_> 1. was the potmodify.py usefully?
<Sianis_> 2. can you put it in the brz branch?
<mvo> Sianis_: both is fine
<snadge> can i try booting the intrepid xen kernel on hardy?
<mvo> Sianis_: I think its useful, I have the diff here locally, I have not reviewed it yet but I will do that today
<snadge> i've wasted all day trying to figure out why i cant get hardy to output anything on xens graphical framebuffer.. it just comes up black
<snadge> fine.. i'll try using opensuse 11's xen kernel
<snadge> ok it doesnt boot as you would expect but at least i get graphics
<snadge> would a kernel from debian sid work with ubuntu? :P
<tkamppeter> pitti, hi
<asac> siretart: what do you think are the chances that upstream will make pcsc-lite pluggable?
<pitti> hi tkamppeter
<asac> tkamppeter: the thing i mentioned during sprint is debian bug 282235 ... the decision to drop that from cups made lexmark z4X printers unusable on debian iirc.
<ubottu> Debian bug 282235 in cupsys "Lexmark printing suddenly broken (had to compile z42_cmyk on my own)" [Important,Closed] http://bugs.debian.org/282235
<asac> by coincident my RFP was closed yesterday .. thats why i remember now
<asac> (auto-closed)
<tkamppeter> pitti, I have seen in the debian/changelog that you are rather active on HAL.
<pitti> yes, indeed I am
<tkamppeter> pitti, HAL needs a little change, in preparation for CUPS 1.4 and also to work better together with HPLIP.
<pitti> emgent: sorry for the double rapache reject; at first I rejected the wrong (newer) version instead of the older one; I'll fish out the newer one from rejected, reviewing now
<pitti> tkamppeter: sure, which?
<tkamppeter> pitti, for HAL a USB printer is present when coupled to the usblp character device.
<tkamppeter> HPLIP and CUPS 1.4 use libusb to access USB printers. HPLIP uncouples the printers from the usblp module, letting them disappear for HAL. Same can occur also with CUPS 1.4.
<pitti> hm, going from kernel driver to raw device access? that direction sounds backwards to me ...
<pitti> ember: oh, it's justified after all, I'll mail you
<tkamppeter> pitti, we have to follow upstream here. It seems that for modern printers with ink level readout, and multi-function stuff like scanning a character device is unadequate.
<pitti> tkamppeter: right; is there a hal patch already for this?
<tkamppeter> pitti, no, but printer detection without usblp is no problem, as the hp CUPS backend and the new usb CUPS backend do it. Also reading out the device ID without the usblp module is no problem.
<tkamppeter> pitti, after some transition period the usblp module could probably even get removed from the kernel, like the scanner module.
<pitti> tkamppeter: but the printers should appear as USB devices/interfaces in hal even right now, even if they aren't associated to usblp
<pitti> don't they?
<tkamppeter> pitti, I think I tested once and they did not. Try blacklisting the usblp module and see whether printers get still detected by HAL.
<pitti> that would be weird; they will certainly not appear as printers, but the devices should still be there
<pitti> tkamppeter: can't do right now, I don't have a printer here
<pitti> tkamppeter: maybe you can do an lshal with and without usblp and pastebin the diff -u ?
<tkamppeter> pitti, if HAL is correctly set up for detecting printers without usblp, hal-cups-utils should get triggered even with usblp blacklisted.
<pitti> tkamppeter: right, I guess hal-cups-utils looks for the "printer" capability
<pitti> I guess that's the one which is missing if usblp is not loaded
<tkamppeter> pitti, you are Debian maintainer of CUPS and do not own a printer? Should I organize a printer for you?
<pitti> tkamppeter: I have one, but not right now
<pitti> tkamppeter: according to "modinfo usblp|grep alias", printers can be identified with some particular interface classes and device classes; so it should be easy to set up an fdi rule which does the same
<pitti> (FYI)
<pitti> tkamppeter: but to confirm this, can you please do the lsusb diff?
<tkamppeter> pitti, yes, I think it is this way, the "printer" capability comes from the usblp module.
<tkamppeter> pitti, I will send you the diff.
<tkamppeter> asac, was z42_cmyk ever packaged for Debian and later dropped?
<pitti> tkamppeter: confirmed, current code looks at the sysfs path; if it ends with lp%d, it sets "printer" capability
<asac> tkamppeter: yes. it was working at some point. the cups maintainer (not sure who he was) said it was dropped from cups and i should file a RFP ;)
<tkamppeter> asac, the upstream CUPS package never contained drivers for Lexmark printers.
<tkamppeter> pitti, did the Debian CUPS package ever contain any third-party drivers, like the z42_cmyk driver?
<pitti> tkamppeter: I don't know personally; not in my times (but the changelog should tell)
<tkamppeter> asac, in general, at least for Ubuntu, we do not ship Foomatic data for which we do not ship the appropriate driver executable. I do not know whether Debian has overtaken this from us.
<tkamppeter> asac, the best would be if some volunteer would make an LSB package of the z42_cmyk driver and so distros do not need to hassle with drivers for old printers. These drivers would be auto-downloaded when needed (at least from Intrepid on).
<pitti> doko: E: cacao-oj6-jre: no-copyright-file
<liw> http://paste.ubuntu.com/30236/ -- would anyone like to give that a quick review and tell me if there's things in there they don't understand? it's the draft manpage for the system-cleaner tool I'm writing
<tkamppeter> pitti, biff
<cjwatson> liw: typo in first line ;-)
<cjwatson> liw: (might want to format that with LANG=C to avoid Unicode that I'm guessing pastebin doesn't understand
<cjwatson> )
<liw> cjwatson, "administration", check
<liw> cjwatson, good point
<cjwatson> seems comprehensible to me but of course I already know what it does
<pitti> doko: oh, so all the other packages have a symlink of their entire /usr/share/doc/package -> cacao-oj6-jre, and that one doesn't have any /usr/share/doc...
<liw> http://paste.ubuntu.com/30238/ -- now without unicode (I hope)
<liw> cjwatson, yeah, it's superbly clear to me, too :)
<afflux> liw: I think I understand it.
<liw> afflux, cool! based on the manual page, does it sound like something that you would try to use?
<afflux> definetly. I use my system mostly for playing around, so it might help in some situations.
<tkamppeter> pitti, asac, according to the changelog Debian's CUPS package never shipped third-party drivers.
<tkamppeter> pitti, I have sent the diff of the lshal output to you by e-mail.
<asac> tkamppeter: so why did it work out-of-box before i filed that bug?
<mvo> tseliot: could you please have a look at http://launchpadlibrarian.net/16297761/buildlog_ubuntu-intrepid-i386.update-manager_1%3A0.92_FAILEDTOBUILD.txt.gz ? it looks like nvidia-common has a undeclared dependency on lspci
<mvo> tseliot: btw, is nvidia-common in bzr yet?
<liw> afflux, thanks
 * liw goes to commit the manpage into bzr, then
<pitti> tkamppeter: hm, weird that it disappears entirely
<tkamppeter> asac, this is also strange for me. Can it be that Debian had some driver collection package in former times which they have dropped?
<tseliot> ï»¿mvo: yes it's in bzr and you have your own branch there
<pitti> tkamppeter: I guess a hal debug output is in order (https://wiki.ubuntu.com/DebuggingHal), i. e. what happens in hal if you plug in a printer in both cases
<mvo> meh, right :)
<tkamppeter> pitti, what do you mean? The printer entry in the diff? Or the z42_cmyk driver in Debian?
 * mvo coughs
<pitti> tkamppeter: can do this later, or if you have time, feel free to do it now
<pitti> tkamppeter: the usblp issue
<tseliot> ï»¿mvo: you're right about lspci, since nvidia-common needs it to perform hardware detection
<mvo> tseliot: you mind if I fix it and upload a new version?
<tseliot> ï»¿mvo: do you want to add a dependency or change the code?
<mvo> tseliot: I add a dependency
<tseliot> ï»¿mvo: ok, then it would be great if you could do it
<tkamppeter> pitti, trying the HAL debugging stuff ...
<mvo> tseliot: or do you think having conditional code in it is better?
<tseliot> ï»¿mvo: nvidia-common relies on hardware detection therefore it's useless without lspci
<mvo> tseliot: yeah, that is what I thought. execellent, you can merge from me
<pitti> NEW queue empty \o/
<DktrKranz> pitti: I noticed you synced e2fsprogs. It still build-depends on dietlibc though, which is in universe. Are there plans to ship dietlibc in main or should e2fsprogs not bdepend on it?
<pitti> DktrKranz: ah, no, I don't think we want dietlibc; thanks for pointing out
<DktrKranz> pitti: if you want, I can look at it, it shouldn't be that hard
<tseliot> ï»¿mvo: shall I merge right now or will you ping me later with the fix?
<doko> pitti: looking ...
<mvo> tseliot: you can merge now
<pitti> DktrKranz: oh, that would be nice
<tseliot> mvo: bzr tells me "Nothing to do". I did a "bzr merge http://bazaar.launchpad.net/~mvo/nvidia-common/mvo/"
<pitti> tseliot: note that http:// takes some 5 minutes to catch up
<pitti> tseliot: try lp:~mvo...
<tseliot> ï»¿pitti: no dice
<pitti> hm, maybe mvo forgot to push then?
<doko> pitti: wrong reject, the docs are in the -headless package
<pitti> lrwxrwxrwx root/root         0 2008-07-23 18:08 ./usr/share/doc/cacao-oj6-jre-headless -> cacao-oj6-jre
<pitti> ^ in cacao-oj6-jre-headless_6b11-0ubuntu2_i386.deb:
<tseliot> mvo: did you use some other branch I'm not aware of?
<doko> pitti: in -headless:
<doko> drwxr-xr-x root/root         0 2008-07-23 19:08 ./usr/share/doc/cacao-oj6-jre/
<doko> -rw-r--r-- root/root       897 2008-07-23 19:07 ./usr/share/doc/cacao-oj6-jre/JAVA_HOME
<doko> -rw-r--r-- root/root       415 2008-07-23 18:29 ./usr/share/doc/cacao-oj6-jre/README.Debian
<doko> -rw-r--r-- root/root       840 2008-07-23 19:07 ./usr/share/doc/cacao-oj6-jre/README.alternatives
<doko> -rw-r--r-- root/root       611 2008-07-23 07:26 ./usr/share/doc/cacao-oj6-jre/NEWS.IcedTea.gz
<doko> -rw-r--r-- root/root    151850 2008-07-23 18:29 ./usr/share/doc/cacao-oj6-jre/copyright
<doko> -rw-r--r-- root/root       951 2008-05-31 08:46 ./usr/share/doc/cacao-oj6-jre/AUTHORS.IcedTea
<doko> -rw-r--r-- root/root      6975 2008-07-23 18:29 ./usr/share/doc/cacao-oj6-jre/changelog.Debian.gz
<doko> -rw-r--r-- root/root      2556 2008-07-23 07:26 ./usr/share/doc/cacao-oj6-jre/README.IcedTea.gz
<mvo> tseliot: oh, sorry. the branch was not bound yet, it should be fine now
<pitti> doko: -headless contains /usr/share/doc/cacao-oj6-jre/ ? that's even weirder...
<pitti> but *shrug*
<doko> pitti: nothing weird, some in openjdk-6 (-jre-headless did appear after -jre)
<pitti> doko: ok, accepted
<doko> cacao-oj6 is just a copy of the packaging
* slangasek changed the topic of #ubuntu-devel to: archive: OPEN | Development of Ubuntu (not support, not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/feisty/gutsy/hardy, #ubuntu+1 for intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<tseliot> ï»¿mvo: merged and pushed. Thanks
<tkamppeter> pitti, HAL debug output in mail
<DktrKranz> pitti: re e2fsprogs, bug 251746 if you have some time. FYI, I uploaded e2fsprogs on my PPA, it has just been built.
<ubottu> Launchpad bug 251746 in e2fsprogs "e2fsprogs should not build-depend on dietlibc-dev" [Wishlist,Confirmed] https://launchpad.net/bugs/251746
<pitti> DktrKranz: thanks a lot! will do in a bit
<pitti> DktrKranz: uploaded
 * DktrKranz hugs pitti
 * pitti hugs DktrKranz back
<gnomefreak> is there a way to enalbe all 4 virtual desktops anymore?
<tkamppeter> pitti, did you have a look into my usblp specs?
<tkamppeter> s/specs/logs/
<pitti> tkamppeter: I'm in a phone conf
<tkamppeter> pitti, sorry, I saw you talking all the time here on IRC.
<tjaalton> ok, compiz on i965 should be fixed now upstream. do other drivers see corruption (wrong colors) on effects like opening the right-click menu on the desktop?
<tjaalton> ie. fade-in/fade-out colors are wrong
<siretart> asac: I don't think that Jouni (upstream is basically a one man show) will invest energy in creating that patch himself.
<siretart> asac: however AFAIU his email, depending on how the patch is written, he is likely to accept, integrate and support it
<siretart> asac: my personal feeling is that we have less efford by proting pcsc-lite
<siretart> asac: my personal feeling is that we have less efford by promoting pcsc-lite
<pitti> tjaalton: -all still depends on -via, but -via is NBS
<pitti> tjaalton: oh, sorry, it's just an alternative
<tjaalton> pitti: openchrome |Â via :)
<tkamppeter> pitti, finished the telecon?
<asac> pitti: ok. so given what siretart said, can you look at the partial MIR for pcsc-lite?
<pitti> tkamppeter: hal-log-without-usblp.txt is 0 bytes, hmm; can you send that one again?
<snadge> who looks after xen?
<snadge> nobody? :P
<pitti> asac: ok, promoting
<pitti> snadge: try asking zul
<pitti> I'm offline for a bit to reinstall my laptop, bbl
<soren> snadge: #ubuntu-xen?
<asac> pitti: you rock
<asac> siretart: ^^
<tkamppeter> pitti, it seems to be not possible any more. I do
<tkamppeter> sudo hald --verbose=yes --daemon=no 2>&1 | tee /tmp/hal.log
<tkamppeter> I get the screen full of messages and /tmp/hal.log has always 0 bytes. tee turned to a no-op
<tkamppeter> pitti, I retry without tee
<ScottK> pitti: (see I found the 't' key this time) Thanks for all the backports.
<tkamppeter> pitti, here it is, I am approaching slowly ...
<tkamppeter> pitti, the new usb backend of CUPS 1.4 (http://svn.easysw.com/public/cups/trunk/backend/usb-libusb.c) checks the interface class, whether it is 7 (USB_CLASS_PRINTER, /usr/include/usb.h).
<tkamppeter> With HAL one can do this, too. see lshal-without-usblp.txt, section starting with "udi = '/org/freedesktop/Hal/devices/usb_device_3f0_7317_CNK2N34563_if0'", line "usb.interface.class = 7  (0x7)  (int)".
<tkamppeter> pitti, only thing missing in the lshal output without usblp is the device ID, hal_lpadmin script could poll it from the printer.
<tkamppeter> The new USB CUPS backend also polls the device ID from the printer.
<tkamppeter> pitti, using libusb
<siretart> asac: pitti :)
<asac> anyone here with a b43 wifi driver on intrepid?
<Nikratio> Is there some python-apport guy around here?
<mvo> anyone here with plenty of diskspace and a kvm capable machine who would want to test the sandbox-upgrader? http://launchpadlibrarian.net/16299860/sandbox-upgrader_0.1%2Bbzr20080724-0ubuntu1%7Eppa1_all.deb
<BenC> siretart: No idea off hand
<pitti> re
<pitti> so, that went reasonably well, aside from my network connection being painfully slow ATM
<pitti> tkamppeter: did you manage to get the hal log in the end?
<pitti> tkamppeter: you sent me one, I wonder why it worked once, but not the second time...
<pitti> tkamppeter: right, adding the capability based on device class shouldn't be a problem
<pitti> tkamppeter: however, it concerns me that the entire device disappears
<seb128> ogra: there?
<pitti> seb128: is it just me, or did seahorse's ssh agent get broken for you today, too? I get "Agent admitted failure to sign using the key"
<seb128> pitti: iz gnome-keyring agent and gnome bug #544554
<ubottu> Gnome bug 544554 in general "ssh agent doesn't work correctly" [Normal,Unconfirmed] http://bugzilla.gnome.org/show_bug.cgi?id=544554
<pitti> seb128: merci!
<seb128> de rien ;-)
<tkamppeter> pitti, I have sent you a new version. Try that one.
<tkamppeter> See also my e-mail about printer detection without usblp.
<DktrKranz> seb128: is it related to gnupg agent too?
<seb128> DktrKranz: what gnupg agent, what too?
<cjwatson> ogra: openssh 5.1p1 in intrepid now, enjoy
<seb128> gnome-keyring doesn't do gpg agent if that's the question
<DktrKranz> seb128: seahorse-agent is not working, it was moved to another source package (I read it from your changelog entry), I though it was related to the gnome bug above
<seb128> DktrKranz: there is no seahorse-agent in intrepid
<seb128> but no
<seb128> gnome-keyring does ssh agent and it's installed correctly
<DktrKranz> ok, I'll try to figure out what's wrong here, thanks
<seb128> yeah, upstream xrandr capplet code landing in intrepid, we will be able to reduce delta and send bugs upstream now ;-)
<pitti> seb128: is that similar to our's?
 * pitti likes the current capplet
<pitti> or did our's went upstream? (I hope)
<seb128> pitti: yes
<seb128> well, technical it's rh's capplet
<seb128> they did 95% of the job
<seb128> we just used their patch for hardy, integrated and fixed some issues
<seb128> they landed that upstream now
<pitti> ArneGoetje: ah, seems I forgot to drop the ispell dictionaries from *-support-writing; doing now
<tkamppeter> pitti, upstream bug #1 (or better feature request) on hal-cups-utils reported: https://fedorahosted.org/hal-cups-utils/ticket/1
<ubottu> Launchpad bug 1 in ubuntu "Microsoft has a majority market share" [Critical,Confirmed] https://launchpad.net/bugs/1
<pitti> bug #1! wow
<ubottu> pitti: Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/1/+text)
<doko> infinity, tjaalton: see https://edge.launchpad.net/ubuntu/+source/openjdk-6/6b11-2ubuntu1/+build/676462  now the first xvfb-run succeeds, the second doesn't ...
<pitti> tkamppeter: nice, thanks
<tkamppeter> pitti, but do not think that hal-cups-utils is perfect software, free of bugs. Tim Waugh moved it from his private box to fedorahosted only 1 week ago.
<tkamppeter> pitti, as you are more HAL expert than me, your patch for 10-hal_lpadmin.fdi is welcome.
<pitti> tkamppeter: I'll get to that; it's probably best if I try and fix that locally
<pitti> ArneGoetje: done
<kirkland> pitti: good morning!  i was wondering if there's anything else need by me on the MIRs for opencryptoki, and ultimately ecryptfs?
<pitti> kirkland: I haven't taken a look at MIRs for three days or so, sorry
<pitti> kirkland: I'll get to it, promised
<kirkland> pitti: ;-)  okay, no problem.... i thought someone told me fridays were MIR days, so I've been waiting until today to ask :-)
<pitti> kirkland: friday is my archive day; for MIRs there's no magic day usually :)
<kirkland> pitti: ah, gotcha :-)
<kirkland> doko: did you have a chance to take another look at opencryptoki?  i comprehensive replaced all of the hardcoded 2048 path elements with a #define'd global
<doko> oops, yes, the week didn't end yet ;)
<kirkland> doko: :-)
<pitti> seb128: FYI, ronne has good intrepid chroots now (thanks lamont!), I moved the retracers into intrepid dchroots; that should stop the crashes in the intrepid fakechroots
<seb128> pitti: oh, excellent, thanks!
<seb128> pitti: btw, sent a gnome-panel SRU your way, ogra was waiting on it, he needs to ability to prevent gnome-panel moves by dnd for some devices where is create issues
<kirkland> hi seb128, can you take a look the patch for https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/251375 ?
<ubottu> Launchpad bug 251375 in gdm "gdm init script should support the 'status' action" [Wishlist,Triaged]
<seb128> kirkland: hi, not today, I'm officially on holiday so I try to not get caught it too many things, trying to catch up on SRU waiting and stop working then
<kirkland> seb128: gotcha, have fun ;-)
<seb128> thanks
<seb128> (do we really need a status action there?)
<seb128> (otherwise patch seems to be good)
<kirkland> seb128: we're trying to add that to as many init scripts as possible
<kirkland> seb128: at least those with daemons
<kirkland> seb128: we're focusing on sever pacakages, but an enterprising volunteer from the community decided to patch gdm
<seb128> alright, I don't see that being really useful but it doesn't hurt either
<kirkland> seb128: we're trying to 'encourage' community participation on this one ;-)
<seb128> right :-)
<kirkland> seb128: thx!
<seb128> I'll include it in the next upload, commenting on the bug to say that now
<pitti> seb128: 90_from_svn_fix_random_position_changes.patch
<pitti> seb128: ... looks weird; what does that do?
<pitti> seb128: by default we have both a top and a bottom panel
<kirkland> cjwatson: I took a different approach with the usplash_write EACCES error, was wondering if you could review
<pitti> so it seems to 'unconfigure' one and 'configure' the other?
<cjwatson> kirkland: ok, where?
<kirkland> cjwatson: https://bugs.launchpad.net/bugs/251656
<seb128> pitti: it fixes typos in the key names
<ubottu> Launchpad bug 251656 in lsb "lsb calls to usplash_write should fail silently" [Undecided,Triaged]
<seb128> pitti: top was used at some place for bottom config, probably extra copy or something
<pitti> seb128: so there is no 'top_panel' really?
<seb128> pitti: there is, but that's a different section which was correct and doesn't need to be changed
<cjwatson> kirkland: I'm not sure, personally I'd prefer changing usplash_write to avoid discarding other error messages
<pitti> seb128: ok
<kirkland> cjwatson: ah, really?  okay, no problem.... i have that patch too :-)
<seb128> pitti: I expect bottom has been made by copying the top config and they forgot to change some instances
<cjwatson> kirkland: but I don't seriously object to either I suppose, it's just that as a general rule 2>/dev/null should be wielded with caution
<seb128> pitti: the patch comes from upstream and has been verified working in intrepid already
<pitti> argh
<kirkland> cjwatson: to me, it's really a difference of who decides to throw away that message
<seb128> pitti: arg?
<pitti> seb128: I already set the bugs as "accepted", but actual acceptin gfails
<kirkland> cjwatson: either done across the board with upslash_write itself
<cjwatson> kirkland: not really, the lsb patch throws away all possible errors
<kirkland> cjwatson: or letting the caller decide
<pitti> seb128: FAILED: gnome-panel (The source gnome-panel - 1:2.22.2-0ubuntu2 is already accepted in ubuntu/intrepid and you cannot upload the same version within the same distribution. You have to modify the source version and re-upload.)
<cjwatson> kirkland: the usplash_write patch throws away that one specific error
<seb128> urg
<kirkland> cjwatson: hmm, that's true too
<seb128> pitti: changing the version and reuploading
<pitti> seb128: 1:2.22.2-0ubuntu1.1 plz :)
<cjwatson> kirkland: depends whether you're confident that nobody will ever have to debug any other problem with usplash_write, really :)
<kirkland> cjwatson: okay, let me brew some coffee, and I'll post the patch to usplash write
<kirkland> cjwatson: :-P
<seb128> pitti: uploaded
<Riddell> mvo: do we allow utf8 in package descriptions?
<cjwatson> we *mandate* UTF-8 in package descriptions, IIRC ;-)
<Riddell> good, lots of twiddly characters in this language name
<cjwatson> actually policy 3.8.0 doesn't say
<cjwatson> I guess it depends whether ddtp will explode
<pitti> seb128: oh, F***, in the intrepid dchroot the hardy fakechroot doesn't work any more; switching back to hardy dchroot then, and we'll live with the segfaults (they shouldn't hurt too much, just break fakechroot upgrades every now and then)
<kirkland> cjwatson: okay, new patch attached to https://bugs.launchpad.net/ubuntu/+source/usplash/+bug/251656
<ubottu> Launchpad bug 251656 in usplash "lsb calls to usplash_write should fail silently" [Undecided,Triaged]
<pitti> hm, seems that compiz forgot how to virtual display desktops in several rows (2 by 2 instead of 4 by 1)
<seb128> pitti: ccsm, preferences, make sure you are using the gconf backend there
<pitti> hm, installing
<seb128> pitti: it likely fallbackend to the text one, which breaks the layout and the shortcuts to switch workspaces
<pitti> is that compizconfig-settings-manager or simple-ccsm?
 * pitti keeps getting confused about these two
<seb128> compizconfig-settings-manager but simple-ccsm is the recommended one nowadays
<seb128> I still have ccsm installed and I don't know if you can change the backend using the other one
<seb128> but you can try ;-)
<pitti> I installed c-c-s-m now
<pitti> seb128: right, it seems to have forgotten all my settings (focus-follows-mouse, too, etc.)
<pitti> and keybindingd
<seb128> pitti: what backend is used? click on preferences in the sidebar to get the option tab
<pitti> ah, there, I was still searching
<pitti> right, text
<seb128> change to gconf
<pitti> hah fun, that did it
<pitti> my ws switcher looks funny now, but I guess a session restart will do
<pitti> seb128: btw, where does it save *that* setting (text/gconf); in gconf? :-)
<seb128> pitti: .config/compiz/compizconfig/config
 * pitti hugs seb128
<pitti> hush, hush, you are on holiday!
 * seb128 hugs pitti
<seb128> pitti: going to upload a gvfs sru too, I didn't start on the computer before 3pm so that's alright ;-)
<pitti> sebner: for your amusement: workspace switcher in a workspace switcher: http://people.ubuntu.com/~pitti/tmp/ws.png :)
 * ion_ ewws the blurry font
<pitti> sebner: sorry, tab error
<pitti> seb128 already offline...
<pitti> ion_: what's wrong with it?
<seb128> pitti: no, just restarted GNOME to try this gvfs update
<ion_> pitti: The blur. :-) As long as our monitorsâ resolutions are what they are now, partially translucent subpixels should be avoided where possible.
<seb128> pitti: gvfs sru sent your way now
<pitti> seb128: for your amusement: workspace switcher in a workspace switcher: http://people.ubuntu.com/~pitti/tmp/ws.png :)
<seb128> pitti: lol, try switching between no desktop effects and normal again
<pitti> seb128: nah, that will again destroy the placing of all my windows
<pitti> seb128: I guess it'll fix itself on next login
<seb128> could do
<seb128> otherwise do what I said
<seb128> the compiz workspace to viewport conversion code still has some bugs
<mvo> Riddell: utf-8 should be fine, that is what ddtp uses too
<joaopinto> Hello, I am working on package for wich the software is distributed under GPL-2, and the artwork under FAL (Free Artwork License), is this latest license accepted for universe ?
<cjwatson> link for the FAL?
<cjwatson> is this http://artlibre.org/licence/lal/en/ ?
<joaopinto> yes
<joaopinto> well, v1.2 on this software
<cjwatson> joaopinto: having looked at 1.3, I *think* it's OK
<cjwatson> feel free to upload it, and if the archive admin on duty is unhappy with it they'll speak to you
<joaopinto> ok thanks :)
<kirkland> cjwatson: did that usplash_write patch look better to ya?
<Milyardo> ls
<devfil> when will archives be resynced?
<cr3> Keybuk: upstart question for you: is there a way to set a delay so that a command is run after everything has been initialized?
 * cr3 needs to jet, brb
<Keybuk> cr3: -v
<LucidFox> Why aren't packages being moved from ACCEPTED to DONE?
<cjwatson> devfil: err ...?
<cjwatson> the publisher is still apparently running
<cjwatson> oh, huh, seems to be stuck on a lock
<cjwatson> -r--r--r-- 1 lp_publish lp_publish 1 Jul 25 08:03 /srv/launchpad.net/ubuntu-archive/cron.daily.lock
<LucidFox> can it be reset?
<cjwatson> it is in fact still running, WTF
<cjwatson> LucidFox: anything *can* be done, I'm trying to figure out what's a good idea ;-)
<cjwatson> LucidFox: I've killed it, but can't guarantee it will work next time
<gaspa> pitti: added recommends and lpia to nbs handling.
<kees> jdstrand: I'm going to shove my font bolding patches into vte.
<jdstrand> sounds good to me
 * ogra hugs cjwatson 
<cr3> Keybuk: to be more verbose on my query about running an upstart event later, I think my script is failing because dbus wasn't initialized first. so, I added a 10 second delay before running my script and it works but I'm wondering if there's a better way
<Keybuk> cr3: what is your script?
<cr3> Keybuk: hwtest which, if preseeded to do so, can potentially run at startup
<cr3> Keybuk: or did you want everything I defined for my event at the exec line?
<Keybuk> it uses dbus?
<cr3> Keybuk: well, it gathers information through hal which, in turn, uses dbus
<Keybuk> right
<Keybuk> when do you run it?
<cr3> runlevel 2 and 3
<Keybuk> start on runlevel [23] ?
<cr3> Keybuk: exactly
<Keybuk> that won't work so well
<Keybuk> but I guess you know that, which is why you're asking me ;)
<cr3> Keybuk: right, I don't understand how I can determine when it would be proper for the script to run
<Keybuk> start on stopped rc[23]
<cr3> Keybuk: aha! now I understand, that'll run after the respective rc scripts have run. so, since there's an S12dbus, I should be good to go
<cr3> err, an S12dbus for rc2
<Keybuk> exctkly
<cr3> Keybuk: cheers man, glad I used upstart rather than init :)
<kees> slangasek: based on the discussions about openssl, it sounds like "drop sslv2 support and wait for complaints" is the consensus?  if you agree, I'll upload ivoks's patch...
<slangasek> kees: yes, that's fine with me
<slangasek> not that my agreement is necessarily a yardstick for "consensus" :)
<kees> slangasek: true, but for the people involved in the discussion, it seemed like you were the last to have stronger hesitations.
<emgent> heya
<infinity> kees: Well, as pointed out, gnutls already doesn't support it, so parts of the distro are already gimped in that fashion (like OpenLDAP), so may as well make the gimping complete and consistent.
<kees> infinity: yeah, I agree.
<infinity> kees: I can't see making a strong argument for "OpenLDAP shouldn't support old protocols, but Apache should".
<infinity> (Seriously, anyone connecting to apache with Mosaic can die)
 * Darklock prefers the Mosaic Killer :-D
<infinity> Or, more realistically, anyone who still has Mosaic, IE3.0, NS2.0, whatever, can probably figure out how to download a newer browser over plain HTTP, so they can then use HTTPS. :)
<infinity> (Which isn't actually as easy as it sounds... I installed NT4.0 for kicks a couple of years ago and discovered that IE3.0 really can't render anything well enough to even FIND a new browser, and had to resort to ftp.exe)
<broonie> ~6 years ago it was a struggle convincing it to talk to the MS update site to install any security or other updates :/
<sommer> slangasek: just fyi, I merged your changes and re-worked the samba file and print sections to not use security=share... I appreciate your feedback
<slangasek> sommer: great, thanks for your work :)
<sommer> slangasek: also, you mentioned that enabling acls doesn't require a remount, but I only see the option in the tune2fs man page as a mount option.  am I missing something?
<slangasek> sommer: oh, it's possible that it still requires a remount to be seen by the kernel
<slangasek> sommer: I just meant it's preferable to have it set as an attribute of the filesystem itself, rather than a mount option in /etc/fstab
<sommer> slangasek: okay, just wanted to double check, because that's the only way I could get it to work
<slangasek> since mounting a device without acls can sometimes accidentally give users *more* permissions than is intended under the acls that are present
<sommer> slangasek: ah gotcha, there's also a new Samba and LDAP section if you have time to review it :)
<slangasek> probably not today, but some time. :)
<sommer> cool no big rush
<pet> Hi. I'm trying to build a package in my Personal Package Archive. One of the Build-Deps is in hardy-proposed, which doesn't seem to be available for the builder. How can I build the package, without waiting for the package to be available in the "hardy" pocket.
<slangasek> pet: does PPA accept uploads to hardy-proposed?
<slangasek> note that build-deps in the hardy-proposed pockets /never/ reach the hardy pocket, only the hardy-updates pocket; so hopefully PPAs use -updates when building (I don't know)
<pet> slangasek: I got an "Rejected: PPA uploads must be for the RELEASE pocket."-error when trying to build it in hardy-proposed
<slangasek> then I guess you'll have to wait, sorry
<slangasek> or build it somewhere other than in a PPA
<pet> I'd been thinking to build the required package (actually a kernel package) in my own PPA, but i think it's a spoil of resources
<pet> slangasek: thanks for your time
<jdstrand> slangasek: hi!
<slangasek> jdstrand: 'lo
<jdstrand> slangasek: I wonder if in bug #249881 these aren't omitted by design
<ubottu> Launchpad bug 249881 in openldap "Hardy slapd server is not supporting sasl/external authentication" [Medium,Confirmed] https://launchpad.net/bugs/249881
<jdstrand> slangasek: eg, if you use ldapi://, you see EXTERNAL, but also PLAIN and LOGIN
<jdstrand> slangasek: if you use ldap:// you don't get those three
<slangasek> jdstrand: the fact that it's omitted may be a symptom of the underlying problem (external auth unavailable), but I don't see how it could be by design
<jdstrand> slangasek: maybe a safety 'feature' that crept in?
<slangasek> I don't know
<jdstrand> slangasek: well, PLAIN and LOGIN go away too-- they are plaintext
<slangasek> sure
<jdstrand> slangasek: ISTR some setting that turns this off...
<slangasek> yes; but 'external' isn't considered a plaintext method, AFAIK?
<jdstrand> I don't know
<jdstrand> ssf? is that what it is?
 * jdstrand goes to look
<slangasek> the option is 'sasl-secprops none' to allow plaintext
<slangasek> so you can try setting that, to see if it makes EXTERNAL available over ldap://
<slangasek> the other possibility is that something's gone wrong in the gnutls/sasl interaction, to make it think that there's no external auth method available
<slangasek> but this was /supposed/ to have been addressed explicitly in the gnutls port of openldap, so I don't know
<jdstrand> slangasek: it would seem odd that that were the case, since ldapi works-- unless you are saying the gnutls is somehow not used with ldapi
<slangasek> I would be surprised if the gnutls were used with ldapi, it's kinda pointless :)
<jdstrand> ah yes, sasl-secprops with 'minssf'-- that was what I was thinking of
<slangasek> it's possible that over ldapi, sasl is offering a different sort of 'external' auth, in the form of peer creds
<slangasek> unix socket peer creds, that is
<jdstrand> *shrug*
<jdstrand> I'll check with sasl-secprops none
<slangasek> yes, that'll tell which one of us is right :)
<jdstrand> slangasek: oh, I'm not actually asserting rightness mind you! just thinking out loud :)
<jdstrand> slangasek: FWIW, dapper behaves the same
<slangasek> on both ldapi and ldap?
<slangasek> I thought this was reported to be a regression
<jdstrand> slangasek: I mean it is the same as hardy
<slangasek> ok
<jdstrand> slangasek: LOGIN, PLAIN and EXTERNAL show up with ldapi, but not ldap
<jdstrand> certainly doesn't seem like a regression
<slangasek> the submitter says it worked on dapper
<jdstrand> well, that was a 2.2 -> 2.3 update, maybe he/she forgot to add something
<slangasek> fwiw, there was just a bug report in Debian saying that external fails to work now against their AD(!) LDAP server, where it worked before
<jdstrand> or the upgrade stripped it out
<slangasek> so it could be a client problem
<slangasek> rather, a client and server problem, since the submitter here says he tested with fedora ldapsearch too
<jdstrand> I of course mean 2.2 -> 2.4
<jdstrand> slangasek: I am testing dapper client and server, and hardy client and server
<slangasek> also, the submitter says that PLAIN and LOGIN *are* allowed mechs over ldaps
<jdstrand> haven't tested ldaps
<slangasek> anyway, I'll stop kibbitzing now; let me know what you find with sasl-props none
<slangasek> sasl-secprops, too
<jdstrand> slangasek: sasl-secprops one pops up PLAIN and LOGIN, but no EXTERNAL
<jdstrand> s/one/none/
<slangasek> right
<slangasek> so I think it's the gnutls integration that's broken
<slangasek> you could test /that/ by recompiling against openssl
<jdstrand> slangasek: and again, dapper behaves the same way
<slangasek> hum, ok
<jdstrand> slangasek: well, I wan't actually planning to go that far ;) I was just updating qa-regression-testing and thought I'd share my findings :)
<slangasek> well, what about a test with an actual trusted client cert?
<slangasek> (or are you already doing that?)
<jdstrand> slangasek: I do plan to add ldaps for this test, but won't have it today
<slangasek> it ought to work with tls anyway
<slangasek> but if you aren't testing where you have a trusted client cert, I'm not surprised if EXTERNAL isn't reported as a valid mech
<slangasek> since in that case, there are no external creds to validate against
<jdstrand> slangasek: ok
<mocha> hello, any devs here?
<jpds> mocha: This is the Ubuntu developer channel. Welcome.
<mocha> I wanted to talk about backporting Alsa 1.0.17 to Hardy
<jpds> mocha: I'd try: #ubuntu-motu .
<mocha> oh, okay I'll give that a shot
<mocha> thanks
<Chipzz> jpds: incorrect
<Chipzz> jpds: alsa is main, and hence the relevant channel is this one
<Chipzz> mocha: jpds was incorrect in referring you to #ubuntu-motu ; feel free to ask your question here
<mocha> Chipzz: hello
<mocha> I was just wondering if Alsa 1.0.17 will be updated or backported to Hardy
<Chipzz> mocha: though I'm not sure I can be of much help for your specific question
<crimsun_> mocha: no.
<mocha> 1.0.17 fixes a lot of really annoying issues with the Intel HDA specifically the AD1988 chip
<mocha> crimsun_: why not? because of LTS?
<crimsun_> mocha: if you're referring to -driver, then that's a possibility for linux-backports-modules-2.6.24.
<Chipzz> mocha: alsa is a very central library; updating it may break a lot of stuff
<mocha> Chipzz: I realize that, I can tell you in Feisty I manually updated Alsa to 1.0.16
<jpds> Chipzz: OK, sorry.
<mocha> I probably will do it for Hardy if there are no plans to update the repositories with it
<Chipzz> mocha: you are of course free to update it yourself :) but having it as an update for an LTS may negatively affect a lot of people, hence such an update has to be considered very vcarefully
<Chipzz> !release
<ubottu> 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
<crimsun_> mocha: the revelant component aside from -driver is -lib, and even 1.0.16 has shown regressions.
<mocha> crimsun_: aren't those regressions fixed in 1.0.17?
<crimsun_> mocha: no
<mocha> crimsun_: are they with a specific card?
<Chipzz> mocha: even if they were, new regressions could have been introduced
<crimsun_> mocha: I'm referring to -lib, not -driver.
<mocha> hmm, well I realize this involves a lot of testing on your part
<mocha> Generally speaking, if I manually update my modules and something goes wrong, can I just purge and reinstall alsa from the repositories?
<Chipzz> mocha: generally speaking: yes, but a downgrade is always manual
<mocha> Chipzz: even if you purge?
<Chipzz> so you cannot easily push a downgrade once you realize an update is broken
<crimsun_> mocha: if by "modules" you only mean the driver, then erasing the newer ones (with find, etc.) and reinstalling linux-ubuntu-modules-$(uname -r) should suffice.
<Chipzz> mocha: no, not then. but as I said, purging involves manual interaction
<crimsun_> (alternately, you could wait until Debian and Ubuntu have 1.0.17, then request backports of -driver and -lib)
<mocha> crimsun_: ?  won't driver, lib, utils, etc all be updated to 1.0.17?
<crimsun_> mocha: that is improbable for hardy-updates but possible for hardy-backports
<mocha> Chipzz: It was always my understanding that by manually updating alsa driver, lib, and utils, that the manually compiled and installed files simply overwrite the files from the packages from the repositories
<mocha> so if something goes wrong it was just a matter of purging -driver -lib -utils and then reinstalling from the repositories
<mocha> the "
<crimsun_> that is mostly the case.  Doing so also strews files that aren't part of the packages on your fs.
<Chipzz> mocha: ah yes, in that way; I was assuming you were referring to a proper way (ie with packages) ;)
<mocha> the "reinstalled" files would go back to 1.0.16
<mocha> crimsun_: what do you mean?
<crimsun_> e.g., /etc/init.d/alsasound, /usr/sbin/alsaconf
<mocha> crimsun_: but those files are part of the repository packages, so they would get rewritten with 1.0.16
<crimsun_> mocha: no, those files are -not- part of Ubuntu's packages.
<asac> anyone here with hardy + b43 wifi chip?
<crimsun_> asac: yes.
<mocha> where did they come from then?
<asac> crimsun_: cool ... can you please paste the lshal output somewhere?
<crimsun_> mocha: they are part of the upstream alsa-driver tarball that Ubuntu does not install.
<crimsun_> asac: do you mean hardware driven by the b43 driver or bcm43xx hardware generally?
<mocha> crimsun_: ok, well how would a person get them on an Ubuntu system then?  because I have them
<asac> crimsun_: i think b43 driver is what matters here ;)
<crimsun_> mocha: you would get them by compiling and installing alsa-driver from upstream.
<crimsun_> asac: ok, then I retract that (I have to use ndiswrapper currently for this 4315)
<mocha> crimsun_: I think we are just confusing ourselves.  Obviously there was some package in the repository that put them on my system.
<asac> crimsun_: does b43 work at all for you?
<crimsun_> asac: on another system with bcm4311 rev 01, yes.  On this system with bcm4315, no.
<asac> ok
<asac> thanks
<MaximLevitsky> Is adding support for easy edit of labels to nautilus considered for ubuntu?
<crimsun_> mocha: no Ubuntu or Debian package owns /etc/init.d/alsasound, and only Debian's alsa-utils package owns /usr/sbin/alsaconf.
<mocha> crimsun_: okay, so I got alsaconf from alsa-utils 1.0.16
<crimsun_> (note that Ubuntu has not shipped alsaconf since warty)
<mocha> well, this is strange then
<mocha> I will have to double check
<mocha> I don't want to keep taking your time, but I think later I will attempt a manual install because I've been waiting for about a year for these bugs to get fixed and I got excited today when I went to Alsa webpage and saw the final release of 1.0.17
<mocha> The changelog was even more exciting
<crimsun_> it's your system; "off you go".
<mocha> FYI, there is a thread in the Ubuntu forums where a guy made a script to download and compile and install -driver -lib -utils, and then he has another script that moves snd-intel-hda.ko to the proper directory
<mocha> I don't know if that is necessary since I didn't do that in Feisty
<crimsun_> it's necessary due to the default path to snd-hda-intel.ko.
<mocha> Okay, I'll make sure I put the modules in the proper places then
<crimsun_> [and by "default", I mean the one installed by linux-ubuntu-modules-$(uname -r)]
<mocha> heheh, maybe when I did this in Feisty it never actually updated the module
<ScottK-palm> pitti: If you're still around, the sauerbraten backport wanted the sauerbraten-data package too and it's uninstallable until that gets done ...
<mocha> I never checked /proc/asound/version or whatever file shows the version
<crimsun_> mocha: feisty had no such issues with paths.
<mocha> crimsun_: why is that?
<crimsun_> mocha: because feisty was the last Ubuntu release to not modify the installed path for ALSA modules.
<ScottK-palm>  ... or any other archive admin ...
<mocha> crimsun_: ah ha.  Finally you have just stated the question I originally had
<mocha> I was wondering about that, if the alsa modules location had changed
<mocha> So I guess the conclusion is that I better be careful, if I check the current location of snd-intel-hda.ko and make sure that the manually compiled one goes there, is that sufficient?
 * ScottK-palm notices the battery level on his phone and quits ...
<mocha> crimsun_: do you happen to know of the ubuntuforums thread I'm talking about, sorry can't find the link right now
<crimsun_> mocha: no.  You need to ensure that your intended snd-hda-intel.ko is lexicographically sorted first.
<crimsun_> mocha: vaguely, yes.
<mocha> crimsun_: lexicographically sorted???
<mocha> what is that in simple english?
<crimsun_> mocha: dictionary/alphabet-wise
<mocha> well why wouldn't it be sorted that way?
<crimsun_> mocha: because upstream installs into kernel/sound, whereas Ubuntu uses ubuntu/sound
<mocha> OK, yes that is what we were already talking about
<mocha> got it
<mocha> that is what the guy's second script does
<mocha> I've run into this same issue when compiling modules for wi-fi cards on Gutsy
<crimsun_> err, sorry, I meant "sort last" above instead of "sorted first".
<mocha> I have to copy the new module into /ubuntu/whatever because otherwise the older module still gets loaded
<crimsun_> anything dictionary-wise after 'ubuntu' will suffice.
<mocha> meaning that any modules loaded into the dir blah/ubuntu/xxxx will get loaded?
<crimsun_> if you intend your self-compiled version to take precedence, you need it in a path that sorts "after" ubuntu/sound
<crimsun_> note that you can pass --with-moddir= to alsa-driver's configure script.
<crimsun_> anyhow, ping me offline in #ubuntu if you have further questions, please.
<mocha> Ok, I think I understand
<mocha> I will just make sure to take account of where snd-intel-hda.ko is currently and what files are installed from the repository before I do the manual install
<mocha> anyway, I appreciate your time, thanks very much, I love linux
<crimsun_> anytime.
<lionfish> Hello all. I asked in #ubuntu, but maybe this is the right place: I thought I'd give USB driver development a go, and tried compiling some of the drivers already there to start with...
<lionfish> ...I posted a question on the forum: http://ubuntuforums.org/showthread.php?t=869284
<lionfish> with the detail.
<lionfish> *details
<lionfish> (bbiab)
<choudesh> lionfish, do you have the kernel headers package installed?
<lionfish> hey. Yup.
<lionfish> I also downloaded the source code too.
<lionfish> I assume there's probably an easy way of compiling them that I've just not figured out yet...
<lionfish> I could pastebin the whole error if you want (I just wrote the first few lines to give an idea of the error)
<choudesh> use /lib/modules/$(shell uname -r) for -I paths
<lionfish> oh right...
<choudesh> also try running make from the kernel root
<lionfish> ooh, good thinking.
<choudesh> and you make need to kconfig config USB_LD
<choudesh> I am too hungery to actually look
<lionfish> ah
<lionfish> awesome, thanks for the pointers.
<lionfish> um, is it even supposed to be possible to compile these files separately?
<tormod> lionfish: you want to compile only a subtree of the kernel?
<lionfish> I guess so, sorry I'm possibly trying something too advanced for my knowledge.
<lionfish> I'm just trying to compile one driver.
<lionfish> (in this case drivers/usb/misc/usbled.c) but it could be any driver.
<tormod> lionfish: I did it once, made some notes in a forum post. (searching)
<lionfish> (indeed my plan is to write my own driver... for my scope, which doesn't seem to have a linux driver for it)
<lionfish> cool, awesome. thanks!
<tormod> lionfish: http://ubuntuforums.org/showthread.php?t=279628
<tormod> lionfish: in many cases you don't need to make a kernel driver, you can use libusb instead
<lionfish> Yeah...
<lionfish> ...I might have to look into that a bit more...
<lionfish> It's for a scope,
<lionfish> so it uses uh, ah, can't remember the word: When it allows the device to spew lots of data.
<tormod> streaming
<lionfish> hang on.
<tormod> link to manufacturer?
<lionfish> it's embarrassing!
<lionfish> it's a Hantek DSO-2100 USB scope... http://www.hantek.com.cn/english/jianjie.asp
<lionfish> (the page makes me want to cry)
<lionfish> But it was an ebay cheapy, so I guess I get what I pay for.
<lionfish> Its front page has sentences such as "antek is willing to display own quantity of heat to provide the sunlight enthusiasm and the service for all customers."
<tormod> "own quantity of heat" lol
<tormod> is it the 2150 model? I can't see 2100
<lionfish> (It's at the bottom of the download list)
<lionfish> (If you're looking there)
<lionfish> (for the windows driver)
 * lionfish tries clicking on "fist"
<lionfish> ah, no that's probably "first"
<lionfish> well, it's on this page: http://www.hantek.com.cn/english/produce.asp?page=2&classid=11
<lionfish> but clicking on it takes me to a frightening page http://www.hantek.com.cn/english/produce.asp?page=2&classid=11
<lionfish> anyway, doesn't matter. Kinda wonder if it's worth writing a driver for - or I could just dual boot.
<lionfish> Was partly doing it for other people who might need it.
<lionfish> I'll look into using usblib anyway.
<lionfish> sorry libusb.
<tormod> how much are these cards?
<lionfish> Uh, I don't know how much they're supposed to be I got this for about Â£50
<lionfish> ($100)
<lionfish> (probably fell off the back of a lorry)
<tormod> you can also check out that Linux instrumentation driver project, (forgot the name)
<lionfish> Usually a scope about 10MHz will cost ~Â£100 I think.
<lionfish> but to get over 100MHz costs a load more, and you need good probes etc...
<lionfish> ...and over 1GHz you need very good probes (need amps at the probe itself) and cleverness in the scope. There's lots of other factors though: The impedance the scope can manage, and capacitance... noise, bits/sample, etc..
<tormod> "comedi" http://stm.lbl.gov/comedi/intro.html
 * lionfish is going to go and read the libusb dev guide (maybe not tonight), thanks for pointing me at it agian.
<lionfish> *again
<lionfish> fantastic.
<sistpoty> lionfish, tormod: maybe you'd like to discuss this on another channel?
<lionfish> It might be worth looking inside and seeing if the chips are the same.
<lionfish> sistpoty, oh right: Which channel should this be in?
<sistpoty> lionfish: that's a good question... not too sure actually ;)
<tormod> not that we are disturbing much here right now
<lionfish> Anyway, I need to get some sleep.
<lionfish> Thanks so much for the help tormod!
<tormod> you're welcome, good night
<lionfish> I should have looked more at libusb. Ty for reminding me
<sistpoty> well, kind of... I usually watch #ubuntu-devel to see development discussion and hence look here from time to time if there's activity ;)
<lionfish> (and comedi looks very good - hopefully I'll find that Hantek are just putting boxes around someone elses chip - quite common I find ^_^)
<sistpoty> but granted, at this point in time, you don't disturb development too much ;)
<lionfish> Very nice OS btw :D - It's getting very user friendly: my gf was dubious at first, but now she's telling everyone at work about it :)
<sistpoty> :)
<lionfish> Right, better go. Ty all! nn.
<sistpoty> cya lionfish
#ubuntu-devel 2008-07-26
<emgent> moin
<Martiini> have the intrepid updates been uploaded yet ?? Im not getting any updates
<wgrant> Martiini: Um, Intrepid has been open for uploads for some months now...
<Martiini> aah, ok .. I was just told that Alpha 3 is still delayed
<wgrant> I'm not sure what that has to do with "the intrepid updates".
<wgrant> And Alpha 3 has been released.
<Martiini> I havent been getting any updates to intrepid for a month now .. aptitude works .. synaptic works .. just simply no updates
<wgrant> Then your sources.list is very probably worng.
<Martiini> shit .. I modified my preferenced file .. of course .. Im using apt-pinning :)
<cody-somerville> Martiini, You can find support for Intrepid in #ubuntu+1
<RAOF> Aha.  Conduit is uninstallable because of differences with our gnome-python-extras.  Debian build a couple of extra binary packages from g-p-e (python-eggtrayicon and -gtkmozembed, specifically).
<RAOF> Is the correct fix here to adapt conduit to our gnome-python-extras, or to bring gnome-python-extras inline with Debian?
<zorglu_> i got a quite technical question. i would like to add stuff in the /etc/hosts kindof file but in a directory..?. something like /etc/hosts.d/mypackage.conf
<zorglu_> does this exists ?
<geser> why do you need to add something to /etc/hosts?
<zorglu_> to add hostnames...
<zorglu_> i dont understand
<zorglu_> is there a way to get this conf.d or anything cleaner than a parse of /etc/hosts or echo myip myhost >>/etc/hosts ?
<geser> Why do you need to add a hostname?
<geser> afaik there is no mechanism to update /etc/hosts, besides the admin could use a dns server to configure host names
<zorglu_> geser: ok thanks.... too bad. i will stick to echo >> and parse with sed then...
<geser> zorglu_: it's against the debian policy to change configurations files from other packages
<geser> I still don't understand why you need to add a hostname there during package installation
<zorglu_> it is ultra long to explain. but dont worry me too i would prefere to avoid it if i could
<james_w> Hi all. Is this a correct bug? https://bugs.edge.launchpad.net/ubuntu/+source/avahi/+bug/218586
<ubottu> Launchpad bug 218586 in sysvinit "Upgrade of avahi-daemon restarts it although it's desactivated" [Undecided,New]
<james_w> there is a bug there, as the user deactivated a service, but gets it restarted on upgrade. However, I'm not sure if the bug is in the correct place.
<emgent> tseliot: o/
<tseliot> ï»¿emgent: hey ;)
<malpheus> hello
 * Hobbsee tries to remember.
<Hobbsee> what was the important thing about uploading imlib2?
<malpheus> does anyone know of any platforms to write applications in so they can easily have their 'actions' modified?
<malpheus> oops im looking for app development channel
<malpheus> bye bye, keep up the good works
<ogra> bryce, around ?
<Fjodor> fabbione: Hi my man! You wouldn't happen to be in Aarhus now, would you?
<theclaw> hi
<theclaw> what is /lib/modules/$kernelver/volatile?
<wasabi> modules which are built on your machine
<wasabi> I believe.
<cjwatson> modules which are linked on your machine
<theclaw> where do those modules come from?
<theclaw> they aren't included in any package
<cjwatson> theclaw: /lib/linux-restricted-modules/
<theclaw> cjwatson: thanks
<theclaw> so these modules are copied from there upon boot-up?
<theclaw> (I heard this volatile directory gets emptied upon boot-up)
<cjwatson> yes
<theclaw> hmm, why?
<theclaw> why not put them /lib/modules directly?
<cjwatson> because we can't legally distribute them that way
<theclaw> cjwatson: why? What's the difference between putting them directly in /lib/modules, and putting them in /lib/restricted... ?
<cjwatson> theclaw: if you look closely you'll see that there's more of a difference than just the location.
<cjwatson> they don't get linked with the kernel until boot
<theclaw> they get compiled on the fly?
<cjwatson> linked, not compiled
<theclaw> I'm confused, why is that a problem? Why do the have to be linked on each boot-up?
<theclaw> *they
<theclaw> debian for example also offers nvidia-kernel packages in non-free
<theclaw> which I have to compile with module-assistant, but not on each boot-up
<cjwatson> therefore Debian is not distributing them pre-compiled and pre-linked
<theclaw> what's with http://packages.debian.org/etch/nvidia-kernel-2.6.18-6-686 for example?
<theclaw> this package includes 'nvidia.ko'
<cjwatson> if they're distributing them, that's up to them, but note that Debian has considerably less money than Canonical and is not a significant lawsuit target
<theclaw> okay
<theclaw> sorry, I guess I'm a bit annoying by now, but why don't just link them *once*?
<theclaw> Upon installing the package, for example
<theclaw> wouldn't this be okay, legally?
<cjwatson> I have no idea and am not particularly keen to investigate
<theclaw> okay
<theclaw> thanks for your answers
<cjwatson> I don't think we should be putting significantly more effort into the organisation of the restricted modules than we do
<theclaw> okay
<theclaw> I have a another completely concern; (#ubuntu couldn't help me on that, I think developers have more clue about this issue):
<theclaw> I just moved from debian to ubuntu, I made a backup of my home-dir beforehand, and restored it; Now, gnome has "visual effects" (not compiz, in fact the compiz process isn't running at all)
<theclaw> When I create a new user with a "clean homedirectory", there aren't any such effects by default
<theclaw> it looks like those "composite"-effects
<theclaw> (the window border is "shadowed", for example)
<theclaw> (-for example, it's the only effect I notice)
<alex-weej> updated intrepid today for the first time since last weekend
<alex-weej> and my .gtk-bookmarks file seemed to have reset.
<diogo> hi.... I need help from developers... I know that a part of Xorg has a problem with abnt2 br layout... how did ubuntu fixed it?
<alex-weej> anyone know anything about this?
<alex-weej> diogo: try #ubuntu-x
<theclaw> (got it; there's a gconf-option for using metacity as a composite manager; don't know how that ever got enabled)
 * slangasek claims a 4-digit bug number, whee :)
<ion_> slangasek: Had they used base-36 bug-IDs from the beginning, weâd be using 4-digit bug numbers up to the 1Â 679Â 615th bug. :-) https://blueprints.launchpad.net/malone/+spec/base-36-bug-ids
 * slangasek blinks
<Laney> Can someone give me any advice as to the next step for getting security fixes uploaded after producing debdiffs? I'm referring to bug #235915
<ubottu> Launchpad bug 235915 in imlib2 "[CVE-2008-2426] imlib2 PNM and XPM buffer overflows" [Undecided,Confirmed] https://launchpad.net/bugs/235915
<crimsun> Laney: it's fine; the appropriate team is subscribed and will deal with it.
<Laney> crimsun: OK that's great. I wasn't sure of the procedure with sponsorship
<Laney> Tghanks for the information
<Laney> -g
<ion_> benc: Yay :-)
#ubuntu-devel 2008-07-27
<RussellGee> Could some have a look at this please: https://bugs.launchpad.net/ubuntu/+source/synaptic/+bug/250524
<ubottu> Launchpad bug 250524 in synaptic "[Intrepid] Synaptic should depend on apt-xapian-index" [Undecided,New]
<crimsonredmk> hey, i've got a question, downloaded alpha 3
<crimsonredmk> how is vmware intergration done, is it a package?
<crimsonredmk> or a new X driver or...well, what is it?
<fabbione> Fjodor: nope... cph
<andy_js> IS UBUNTU PROPRIETARY?
<andy_js> According to Google, the patch for Visual effects is not publicly available.  Please prove otherwise.
<jazzkutya> andy_js_: patch for what?
<andy_js_> Patch for the "Visual Effects" tab in ubuntu's gnome-appearance-properties
<jazzkutya> what packaget it is in?
<jazzkutya> i guess apt-get source should retreive it correctly
<jazzkutya> but i am not an ubuntu developer
<jazzkutya> retrieve
<andy_js_> A post on the Ubuntu forum led me to believe the patch was not included in the sources in the repos
<jcristau> andy_js_: you believe everything you read on web forums?
<jpds> andy_js_: apt-get source gnome-control-center
<andy_js_> I've heard a lot of things about ubuntu, maybe they are just rumors
<jpds> andy_js_: Look in the source, debian/patches/95_desktop-efffects-intrgration.diff
<jpds> andy_js_: And voila, i's GPLv2.
<jpds> its*
<andy_js_> thank you
<andy_js_> jpds: You work for canonical?
<jpds> andy_js_: No.
<devfil> Hobbsee: can you please take a look at https://launchpad.net/ubuntu/+source/imlib2/1.4.0-1.1ubuntu1 ?
<Hobbsee> oh, shucks.
<devfil> it needs a package in universe, but imlib2 is in main
<Hobbsee> yes, i can see that....
<devfil> in this case the dependency is added manually?
<Hobbsee> !info libltdl3-dev
<ubottu> libltdl3-dev (source: libtool): A system independent dlopen wrapper for GNU libtool. In component main, is optional. Version 1.5.26-1ubuntu1 (hardy), package size 361 kB, installed size 1640 kB
<Hobbsee> added manually?
<Hobbsee> yes, i'ts not via shlibdeps.
<devfil> there are other packages with the same problem
 * Hobbsee wonders why libltdl7-dev never got promoted.
<Hobbsee> what, that they require hte old lib?
<devfil> no that they need a package in universe to build but there are in main
<Hobbsee> which others?
<devfil> uhm I don't remember now let me search
<Hobbsee> pitti: do you know why libltdl7-dev was never promoted?  libltdl3-dev was in main, then appears to have been NBS'd out.  I presume this is an oversight?
<Hobbsee> (presumably it got forgotten about with the sync)
<devfil> Hobbsee: denemo (main) needs libaubio-dev (universe)
<Hobbsee> devfil: can you file a bug on that, and assign it to ogra?  (if there's not already one there)
<Hobbsee> oh, wait, he already knows about it
<ion_> Oh, denemo is in main? In that case, why is lilypond not?
<Hobbsee> MIR is probably already on it's way
<Hobbsee> ion_: *shrug*
<devfil> directfb needs libts-dev
<devfil> etc...
<Hobbsee> ah yes, that's on http://people.ubuntu.com/~ubuntu-archive/component-mismatches.txt
 * Hobbsee assumes that the MIR's will get processed soon
<alex-weej> are "apport-bug" tagged bugs given less priority than normal?
<alex-weej> i use ubuntu-bug -p all the time to file bugs because it attaches all the right info
<theclaw> is the bytecood interpreter in the hardy version of freetype disabled?
<theclaw> I encounter exactly the same problem as describe in https://bugs.launchpad.net/ubuntu/+source/freetype/+bug/60760
<ubottu> Launchpad bug 60760 in freetype "turning off autohinting has no effect" [Undecided,Invalid]
<LaserJock> anybody know what happened to the Network system config GUI?
<Rocket2DMn> LaserJock, see bug 248163
<ubottu> Launchpad bug 248163 in gnome-system-tools "Network menu item missing in Intrepid Alpha 2" [Wishlist,Triaged] https://launchpad.net/bugs/248163
<LaserJock> Rocket2DMn: ah, thank you very much. I suspected something like that
<Rocket2DMn> you can install the program from the repos in the meantime
<LaserJock> yeah, that's what I'm doing
<LaserJock> hmm, it still seems sort of messed up
<Rocket2DMn> i havent checked lately, feel free to add to the bug report if needed though
<LaserJock> I can't turn a Connection off from the gnome-network-admin
<LaserJock> I can only set whether I want roaming or not
<LaserJock> I guess if I set it to not roam bug leave it unconfigured it might suffice
<LaserJock> yuck, I can't even do that
<Rocket2DMn> good luck, im on my way out the door
<slangasek> Keybuk: does libltdl7-dev not provide API compatibiltiy with libltdl3-dev?  (Or if it does, is there a reason it doesn't have a Provide: that's a consistent build-dependable interface?)
<Keybuk> slangasek: ask Debian ;)
<alex1> hi guys. I've created a patch for the appleir kernel module in the linux-ubuntu-modules package. what mailing list should I send the patch to?
<crimsun> kernel-team at lists dot ubuntu
<crimsun> you may wish to subscribe prior
<alex1> crimsun, thanks
<pwnguin> is this sslv2 stuff about servers or clients?
<geser> pwnguin: it's about sslv2 support in openssl, so servers and clients are affected
<pwnguin> well then
<pwnguin> this might be stupid
<geser> why?
<pwnguin> i can't say I know enough about ssl and the history, but there are embedded devices that run ssl
<pwnguin> if they happen to predate v3, that's kinda dangerous territory
<geser> and they use sslv2 and not sslv3?
<pwnguin> maybe, I don't know enough about it
<pwnguin> but i havent really seen that discussed on the ML and I thought it was worth mentioning
<Mithrandir> pwnguin: IMNSHO it's better with a visible breakage than having devices which are silently broken.
<Mithrandir> since SSLv2 has vulnerabilities
<pwnguin> wouldn't a warning be appropriate?
<pwnguin> well
<pwnguin> i guess some uses of SSL desire to be as invisible as possible
<pwnguin> but i mean, you can force ssh to accept older protocols, cant you?
<ScottK> SSLv2 should not be considered cryptographically secure in 2008.  Continuing to support it would be irresponsible.
<pwnguin> breaking it would be user hostile
<ScottK> Personally, I wanted this done for Intrepid, but didn't get to it.
<ScottK> Anyone who needs v2 can run Hardy for 3 to 5 years.  That's plenty of warning.
<pwnguin> fair enough
<pwnguin> ScottK: do we still ship telnet?
<ScottK> Yes, but it does not pretend to be secure.
<ScottK> ftp too.
<ScottK> Shipping things that are, by design, not secure and that lack of security is well known is fundamentally different than shipping with support for ancient versions of security protocols that are known not to be secure any longer.
<Mithrandir> (as well as ktelnet, kftp, telnet-ssl and similar relativetly secure solutions)
 * ScottK is a big user of sftp.
<Laney> ScottK: Would you be in favour of removing WEP support then?
<ScottK> Laney: That's a good question.
<Mithrandir> Laney: if barely no users used it, yes, please.
<pwnguin> Mithrandir: and that's the right question to be asking
<pwnguin> How many people are affected by the change and how?
<Mithrandir> but a fairly significant amount of the user base needs it; no.  We might want to add more visible warnings when WEP is in use, though.
<ScottK> Laney: I think at this point we should be encouraging WPA.
<ScottK> Planning for getting rid of obsolete cruft is not something we do very well.
<Chipzz> Mithrandir: ah yes. http://chipzz.livejournal.com/39111.html :)
<Mithrandir> pwnguin: TTBOMK, nobody has pointed at anything concrete actually needing SSLv2?
<Laney> Of course. I was just going for a similar example that would (probably) have more impact
<pwnguin> Mithrandir: how could they? ubuntu-devel is moderated
<ScottK> pwnguin: The moderation queue gets cleared regularly.
<Laney> Could it be temporarily disabled for the alphas and then we watch the bugs and confirm/revert later?
<pwnguin> Mithrandir: plus, there's a selection bias
<ScottK> ivoks reply to my GnuTLS question only lagged on ubuntu-devel by a couple of hours.
<ScottK> Laney: I'd suggest something like announcing NOW that the next LTS, 10.04 will ship without WEP support, so get ready.
<Mithrandir> pwnguin: what I'm seeing is people trying to find anything that needs SSLv2 and failing, so this is more widespread than "I don't use it myself, so drop it".
<Laney> ScottK: I was referring to SSL, but yes that could be a plan.
<Mithrandir> ScottK: probably too early, I'm afraid. :-/
<ScottK> Probably.
<Laney> I'd like to be able to get other distros/upstreams on board for a change like that though
<pwnguin> Mithrandir: The thing is, I dont have the world's supply of embedded network devices handy
<Laney> (WEP)
<ScottK> Personally I pitched all my WEP only gear in ~2001, but I know a lot of people still use it.
<Mithrandir> but I'm all for adding big, fat warnings to NM when you connect to a WEP "secured" network.
<ScottK> That sounds good.
<Chipzz> ScottK: nintendo ds doesn't do anything but WEP
<pwnguin> Mithrandir: I used to have a stargate at work for a base station for TinyOS stuff. it ran an ancient kernel and it wouldn't surprise me if it were SSLv2
<ScottK> OK, so maybe 12.04
<Mithrandir> pwnguin: most of the embedded network devices I've seen that people are using at home (which means routers etc) don't even use SSL at all.
<Mithrandir> since using SSL means you have to have a match between host name and SSL cert and be able to update the cert when it expires.
<ScottK> My father hired someone to come set up his wireless network (he lives a long way from me) and they set it up as WEP, even though all the devices supported WPA.  I have no idea why.
<ScottK> IME WPA is actually easier to set up.
<pwnguin> i believe bruce runs wep
<Laney> First option on the list?
<ScottK> Possibly.
<Laney> pwnguin: Schneier? I thought he ran unencrypted
<Mithrandir> even Windows XP and such warns that WEP isn't secure.
<pwnguin> Laney: perhaps.
<pwnguin> WEP is protects against a certain threat model
<ScottK> I've noticed now that when I'm in a position to see a lot of networks is about 10% unencrypted, 80% WEP, and 10% WPA.
<ScottK> 3 years ago it was about 90% unencrypted.
<Mithrandir> WEP is like closing your office door, signalling that you don't want to be disturbed.
<pwnguin> the idiot neighbor and marginally interested internet thieves
<ScottK> Which is useful when lots of other people don't have doors at all, but if everyone has the door closed, no so much.
<pwnguin> http://my.opera.com/yngve/blog/2007/10/03/new-w-not-in-kestrel-the-death-of-ssl-v2
<pwnguin> after reading that, I think it might be okay
<Mithrandir> heh, yngve blogs now?
<pwnguin> apparently
<pwnguin> it was the first hit for "sslv2"
<pwnguin> well, among them
<Mithrandir> and FF doesn't support it either, AIUI?
<Mithrandir> well, libnss doesn't
<pwnguin> well who's libnss
<pwnguin> ours or firefox's?
<Mithrandir> NSS is the Firefox SSL library.
<Mithrandir> Netscape Security Support or somesuch
<Mithrandir> Description: Network Security Service libraries
<pwnguin> actually, some wierd stuff uses libnss, and if I read a bug correctly, mozilla demands we ship THEIR library
<pwnguin> I believe the fix was to build the libnss they ship and link mozilla to it, but leave the rest alone
<cjwatson> in general I would advise against trying to reverse-engineer discussions with mozilla from reading random bug reports
<pwnguin> heh
<pwnguin> in specific?
<cjwatson> I haven't read this one
<cjwatson> mozilla have asked that we put our patches through their review process (aside from some classes generally agreed to be unobjectionable) in order to use firefox branding
<cjwatson> that doesn't equate to "must use mozilla's libnss" as far as I know
<pwnguin> lemme dig up the bug for ya
<cjwatson> no thanks, it's approaching bedtime
<pwnguin> alright
<cjwatson> I'm confident in asac's ability to deal with it appropriately :)
<pwnguin> the reasoning i saw is that our libnss broke weave, and that not shipping their libnss sounded like a branding problem
<pwnguin> weave works today, so i guess we're ok
<IntuitiveNipple> Is there a recommended way for an application to determine the system-default file manager (so whether it is Ubuntu, Xubuntu, etc. a file-manager can be started) ?
<ion_> If âxdg-open .â doesnât do exactly that, it should be fixed. :-)
<IntuitiveNipple> ion_: Thanks... that'll be good for [XK]*ubuntu ? (I'm creating a patch for an app that currently does "os.system("nautilus --browser  obex://["+dest+"] &")"
<ion_> intuitivenipple: Sorry, iâm not sure it works anywhere. It doesnât seem to work in Gnome.
<IntuitiveNipple> oh... it did for me just now :)
<IntuitiveNipple> I'm on Ubuntu Hardy
<ion_> Heh, interesting.
<ion_> Iâm on intrepid.
<IntuitiveNipple> ahh well!
<IntuitiveNipple> thanks anyway... Googling wasn't helping solve that one
<ion_> But i think it should be the right way to do it, as soon as itâs fixed to work in every environment. :-)
<emgent> hello
<ion_> Hi
<IntuitiveNipple> darn. xdg-open fails with an obex:// service ("Error showing url: Service not available")
#ubuntu-devel 2009-07-20
<bluefoxicy> why is my / ext3?
<bluefoxicy> ~$ cat /etc/fstab |grep ext4
<bluefoxicy> UUID=10f59859-5e33-4277-a7d2-323447f54df7 /               ext4    defaults,errors=remount-ro,relatime 0       1
<bluefoxicy> UUID=b574cf52-432a-4c2a-8742-effe21dbf760 /home           ext4    defaults,relatime        0       2
<bluefoxicy> ~$ cat /proc/mounts |grep ext3
<bluefoxicy> /dev/disk/by-uuid/10f59859-5e33-4277-a7d2-323447f54df7 / ext3 rw,relatime,errors=remount-ro,data=ordered 0 0
<TheMuso> /c/c
<ogra> urgh, wha there a decision in debian to use /srv by default across the board ?
<ogra> *was
<TheMuso> ogra: For what?
<ogra> well, tftpd-hpa defaults to it for tftp serving with the latest release
<ogra> i was wondering if there is a general change
<ogra> which would surprise me
<TheMuso> ah ok
<liw> that sounds like an excellent question for #debian-devel :)
<ogra> gah, bug 84615
<ubottu> Launchpad bug 84615 in tftp-hpa "Uses /var/lib/tftpboot instead of /srv/tftp" [Wishlist,Confirmed] https://launchpad.net/bugs/84615
<pitti> Good morning
<ogra> the evil thing in tftpd-hpa is that they changed *both* defaults, it runs standalone now *and* not from inetd anymore ...
<ogra> given that it doesnt carry a config file but was configured in inetd.conf thats pretty bad
<StevenK> ogra: /srv == win
<ogra> no
<ogra> StevenK, so apache should use /srv/www now ?
<liw> I prefer /srv/http, but I also think it's a local admin decision; http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM
<StevenK> ogra: Well, I actually configure Apache to pull from directories underneath /srv
 * ogra wonders what all the admins out there would say if it suddenly did, breaking all the setups that use the default config :P
<StevenK> But yes, what liw said. It's a local admin decision.
<ogra> right
<ogra> and the directory should stay clear from defults
<ogra> *defaults
<StevenK> ogra: I'm unsure about if the default should be somewhere under /var, or what it currently has, under /srv
<ogra> var is variable system data, isnt it ?
<liw> "However /srv should always exist on FHS compliant systems and should be used as the default location for such data."
<StevenK> ogra: And /srv is data that is served by the system, so ...
<ogra> srv is a nice concept to give admins more freedom, but essentially i think system default setups shuld stay out of it
<liw> the FHS is clear that /srv should be the default location
<ogra> "The methodology used to name subdirectories of /srv is unspecified as there is currently no consensus on how this should be done."
 * ogra doesnt find that clear or even thought to the end
<liw> I'm sure the FHS committee would accept reasonable arguments for change
<ogra> an you think i would move people to a consensus ?
<liw> certainly
<ogra> looks to me like it was argued on before and there simply was no agreement
<liw> if nothing else, you could push them all to dislike you and so have a consensus to vote against you? :)
<StevenK> Hah
<ogra> which reads to me like "no real *standard* could be defined"
<liw> I haven't studied the history /srv, but I assume this happened the way fhs and similar standards are developed
<ogra> well, to me a standard means there is "agreement how we all do it" ...
<liw> i.e., people felt that /var was a bad location for things like http web roots (read: not easily shareable between hosts) and proposed a change
<liw> so as a first step, /srv was invented and then the committee will wait a few years to see if it gets popular and if so, how it gets used
<liw> before they make further changes
<ogra> right, i dont say thats bad ... as long as there is a clear definition how /srv has to look like
<ogra> else you end up with per distro chaos ... that defeats the purpose of easy portability
<ogra> and given that there is no such definition yet it should not be used for default setups imho
<liw> *shrug* the standard won't (and shouldn't) encode a structure before it has been tried in practice
<ogra> heh, catch 22 ?
<liw> not really, as long as people don't insist the FHS tell them in detail the location of every file and distros have a little bit of courage to try new things occasionally :)
<ogra> i dont want to be told about files in detail ... but a rough definition about the substructure would be helpful
<liw> I'm sure you'll find it in a future version of the fhs
<liw> meanwhile, you can help decide what is the best substructure :)
<ogra> well, the by protocol approach is fine with me ...
<ogra> in my specific case i'm just running into a prob with tftpd-hpa which changes two setups at the same time
<ogra> it ignored the former configuration (inetd.conf) and at the same time switches its default path
<liw> that'd probably be a bug in that package
<ogra> *ignores
<Hobbsee> X really doesn't handle two monitors of different aspect ratios well, does it?
<Hobbsee> gdm keeps throwing itself against the wall when you try
<ogra> it does fo my monitor
<lifeless> Hobbsee: that may have more to do with gdm
<liw> X might. gdm perhaps doesn't.
<Hobbsee> hm, could well be gdm
<pitti> Hobbsee: is it similar to https://bugs.freedesktop.org/show_bug.cgi?id=22580 ?
<ogra> (1900x1200 plus 1280x800 if i attach it to my laptop)
<ubottu> Freedesktop bug 22580 in Server/general "defaults to non-native screen resolutions (mode change from KMS)" [Normal,New]
<Hobbsee> (and 1024x768 looks painful on a 21.5 inch 16:9 monitor, incidently)
<pitti> no, it's recent X trying to be too clever
<Hobbsee> pitti: ah yes, i see that too
<pitti> I have an internal LVDS (docked, closed, ignored) and an external TFT
<pitti> and X comes up at 1024x768 on both now
<Hobbsee> (when mirroring the display)
<Hobbsee> yep
<Hobbsee> turning off mirror mode lets you select the higher resolutions, though
<pitti> sure, in my X session I can do the right thign (disable LVDS, use native resolution on DVI)
<Hobbsee> just when you actually log out and back in to use them, gdm blows up
<pitti> doesn't blow up here, but keeps switching modes
 * ogra can use his 24" monitor just fine with the laptop, but X dies horribly if i attach my 42" TV
<StevenK> Argh, now the blocking on ocaml transition is causing headaches for the rpm transition
<ogra> Riddell, pitti, bug 190905says dnsmasq is in main, i dont see it there ?
<ubottu> Launchpad bug 190905 in dnsmasq "Main inclusion report." [High,Fix released] https://launchpad.net/bugs/190905
<pitti>    dnsmasq |     2.49-1 |        karmic | source
<ogra> oh, ok
<StevenK> ogra: The source is, the binary isn;t
<pitti> ogra: dnsmasq-base is in main, the full dnsmasq binary isn't
<StevenK> s/;/'/
<pitti> nothing needs it
<StevenK> Oh, bah, it's worse.
<StevenK> Anything requiring dose2 can't be built since libdose2-ocaml can't be installed since librpm4.4 and librpm0 conflict, and I can't sync dose2 since it's blacklisted since the Debian ocaml maintainers don't want karmic transitioning.
<directhex> Hobbsee, depends on how your graphics driver decides to present them
<directhex> Hobbsee, at work i have a 1600x1200 secondary and 1920x1200 primary. gdm displays only on the primary
<StevenK> pitti: So, would it be a bad thing to merge ekiga from Debian? (They have 3.2.5, and we have 3.2.0)
<Hobbsee> directhex: right.  It dosent' seem to be having a problem displaying only on one monitor - just both resolutions are wrong
<directhex> i don't have that issue
<directhex> vertical res matches though, if that makes a diff
<\sh> moins
<\sh> evand: WTF is a "Ubiquity Contributor Agreement"? (And I think you mean Ubiquity as in live cd installer)
<\sh> and why should someone sign this when the source is GPL2 and all contributions to this source are falling under that license, too?
 * ogra points \sh to http://vdict.com/ubiquity,7,0,0.html
<ogra> "omnipresent" :)
<\sh> ogra: and what does it have to do with a) licensing a software and b) signing another document which grants the same rights? (minus this very strange patent paragraph)
<ogra> it means that you agree this license applies *across the board*
<ogra> i would say
<ogra> (some native speaker may correct me)
<ogra> s/license/agreement/
<evand> \sh: yes, ubiquity the live CD installer.  It's a requirement per http://www.canonical.com/contributors .  My understanding of the reasons we require people to sign it are the two I outlined in that email.  I can put you in touch with a lawyer who can better elaborate on the details if you don't find my explanation sufficient.
<ogra> oh
 * ogra didnt know we had that 
<ogra> (for ubiquity)
<\sh> evand: so what you are saying is: if someone is using the software, which I contributed to, not according to the GPL2 license, you will hunt them down like gplviolations?
<\sh> s/you/Canonical/?
<kamaln> Hi, can i discuss Ubuntu package development here?
<evand> \sh: I think that's a question better put to our legal counsel.  I have a very limited understanding of the law and the plans of our legal department.
<\sh> evand: please...would you forward this to your legal department? I really don't understand the usecase behind such an agreement :)
<evand> \sh: If you could ask specific questions to Amanda (who's email address I'm about to private message you), I'd greatly appreciate it.  If I just send her an email myself saying your confused on why this is necessary, that leaves having to formulate an unnecessarily broad answer.
<evand> that leaves her*
<maxb> kamaln: You can, but be aware that this channel is primarily concerned with packages in the 'main' component - For 'universe' packages, including new packages, #ubuntu-motu is more appropriate
<\sh> evand: will do
<evand> \sh: Thanks, and apologies for the confusion.
<evand> Legal issues are not my strong suit.
<\sh> evand: no problem...:)
<kamaln> maxb: what is meant my 'main' component..? Infact, I am developing a new package..so is it better to approach #ubuntu-motu
<pitti> StevenK: not at all
<maxb> kamaln: All new packages start out in 'universe', so yes, #ubuntu-motu is the right place
<evand> kamaln: https://wiki.ubuntu.com/UbuntuDevelopers should help to explain the difference between motu and core-dev (this channel).
<kamaln> evand: thanks..:-)
<cjwatson> \sh: the FSF does exactly the same thing for contributions to GNU projects, FWIW
<directhex> copyright assignment?
<azeem> cjwatson: I believe the FSF explicitely says it will only license the assigned copyright under FLOSS licenses/GPL
<cjwatson> well, yes, that's true. I meant copyright assignment in general
<cjwatson> directhex: only for a few projects that we started, not for the whole of Ubuntu or anything, don't worry
<azeem> (just mentioning, because you said "exactly the same thing"
<azeem> )
<\sh> cjwatson: so, I could give my copyrights to another entity (which is the FSF), why should I do that?
<directhex> i believe a common alternative is to allow non-assignment as long as contributions are MIT/X11
<cjwatson> the usual reason for copyright assignment is that it means that in case of violation it's actually possible to pursue violators; in many jurisdictions one cannot bring a case unless one has standing
<directhex> \sh, essentially because it makes it easier for them to fight legal battles, as they cal claim to be the infringed party in disputes.
<directhex> \sh, or you can have severe problems when you DON'T, e.g. parts of scummvm are unrelicensable as their author died
<directhex> \sh, as it happens, your reasoning is why the Go-OO patchset for OpenOffice.org exists
<\sh> directhex: well, for that I have a last will where I can state what will happen to my copyrights, software or IP...
<directhex> can, or do?
<cjwatson> mm. I've actually had that problem myself in the past, I didn't really want to contact a developer's widow and say "excuse me, exactly what pedantic things can I do with your late husband's code"
<\sh> directhex: I have ... I just need to add things every year I survived
<cjwatson> seems ... tasteless somehow
<directhex> cjwatson, very. but what's the alternative?
<\sh> cjwatson: actually it's that situation companies do with people taking over someones property
<directhex> cjwatson, the scummvm case is significant as it prevented proper resolution of a gpl violation problem
<cjwatson> fortunately in the case at hand it basically worked out that I didn't need to worry about it for various reasons
<directhex> afaik apache requires assignment too
<directhex> a housemate received legal paperwork from the foundation when we were undergrads
<\sh> actually most of the software which are in our archives and we contributed some self-made patches needs such an assignment then
<cjwatson> depends where the patches go, but you'll certainly find that many upstream contributions require assignments, yes
 * cjwatson is in the process of getting assignments sorted out for findutils, parted, grub2, and something else I've forgotten
<directhex> i think there's some generally held legal minimum patchiness level required to say "this patch counts as a proper contribution and needs proper licensing"
<directhex> i'm pretty sure i'm not in MythTV's AUTHORS file
<cjwatson> it's subjective, I have seen such things stated but never a clear legal opinion on it
<directhex> sounds like something waiting for case law
<james_w> I've seen people say "this isn't a patch, but if you go to foo.c and change the comparison on line 95 this bug will go away. Can I avoid signing a copyright assignment please?"
<directhex> technically that statement is true
<liw> the threshold for what is copyrightable (and what is too trivial to be copyrightable) varies betwen jurisdictions, and sometimes within them too
<liw> on the whole, copyright law is screwed up all over the world
<\sh> well, if those assignments has a paragraph like: "A company/organization which violates the authors/contributors license will be sued by Us [where "Us" is someone else company/organization] to enforce the given license of the author/contributor. Any monetary solution to this charge will be shared among the Law Company, the author of the software and all contributors" this would make sense to me (not that I want any blood money)
<\sh> btw..I just had a karmic problem unlocking the screensaver...it just waited there forever
<cjwatson> me too last night, I was wondering if it was due to not having restarted after an upgrade
<cjwatson> I had to kill gnome-screensaver
<\sh> it was after todays update...and there was no restart required according to non-existent "Restart required notifier" :)
<dpm> StevenK: regarding fbreader, I'd like to reply to upstream. Seeing that it will not be promoted to main, I'm guessing that the i18n work will not be done?
<\sh> hmm...what does "You have N broken packages on your system. Please use the "broken" filter to detect them"? (Dialogbox of update-manager, without any hint where to set the "broken" filter)
<azeem> maybe that's a message from synaptic
<\sh> azeem: as it follows the "Install updates" of update-manager...I can't tell...but this message is very strange and will confuse people, at least it confuses me
<\sh> and now, update-manager won't close after updating all selected packages..hmmm
<\sh> now it's gone...after 1:30 mins
<Laney> does sync blacklist block even manual syncs? I thought it was just for autosync
<cjwatson> only autosyncs
<cjwatson> err, wait, maybe not
<Laney> or is autosync just a loop over the manual procedure?
<cjwatson> no, manual syncs too actually. But anyone who can do a manual sync can edit the blacklist ...
<Laney> sure
<directhex> Laney, if you were me, would you 0ubuntu1 xsp and mono-tools?
<Laney> getting emails from bug 387943
<ubottu> Launchpad bug 387943 in ocaml "Karmic: please do NOT synchronize following packages" [Undecided,Fix released] https://launchpad.net/bugs/387943
<cjwatson> basically just a loop with a bit of extra reporting
<Laney> directhex: what's the delay?
<directhex> Laney, binary NEW
<Laney> I'd wait
<Laney> binary NEW isn't too slow, is it?
<cjwatson> but in that case the blacklist is there for a reason and removing it does seem to merit some discussion
<james_w> binary NEW in Debian?
<directhex> james_w, aye
<james_w> I didn't think they had one?
<cjwatson> it's probably just that ftpmasters are at debconf :)
<cjwatson> they do
<directhex> james_w, binary NEW in ubuntu requires only beatings and/or beer
<directhex> james_w, the ftp-master page doesn't distinguish - the ftpmasters actually do though
<james_w> and that would indicate that the source was published, and so we could sync. Or do I misunderstand the process?
<directhex> james_w, you may not access files uploaded to NEW
<cjwatson> if the new binary packages went together with a source upload, then the whole upload stays in NEW
<james_w> yeah
<directhex> james_w, as some kind of defence against undistributable source. or somesuch
<james_w> an "new-binary NEW"
<cjwatson> the queue never splits up .changes
<james_w> "ah", I mean
<james_w> I get it now
<directhex> short version: long wait time
<directhex> if openprinting-ppds contains an obsolete ppd-drop from a printer vendor, what's the best way to get it updated?
<mvo_> \sh: uh, that is indeed confusing - could you mail me your /var/log/apt/term.log please?
 * directhex dances in circles, goes to file a bug, notices it just goes to tkamppeter anyway
<tkamppeter> directhex, which PPDs are obsolete?
<directhex> tkamppeter, kyocera. i can get a precise list of models if you give me a few mins
<tkamppeter> directhex, OK.
<tkamppeter> directhex: Unfortunately, I did not get Kyocera PPDs for years, so there are probably missing a lot.
<directhex> how odd, there are more PPDs on here than in Kyocera's download
<tkamppeter> directhex, can you tell me where I can find Kyocera's download?
<tkamppeter> It can be that Kyocera does not have arbitrary old models in their download and the oldest models on OpenPrinting are perhaps older.
<directhex> +Kyocera_FS-1118MFP_en.ppd
<directhex> +Kyocera_FS-C5015N_en.ppd
<directhex> +Kyocera_FS-C5025N_en.ppd
<directhex> +Kyocera_FS-C8100DN_en.PPD
<directhex> +Kyocera_KM-1820_en.ppd
<directhex> +Kyocera_KM-C2520_en.PPD
<directhex> +Kyocera_KM-C3225_en.PPD
<directhex> +Kyocera_KM-C3232_en.PPD
<directhex> those are the additions
<ScottK> cjwatson: I did verify the debian-cd change you merged for me fixed the background problem on the Kubuntu Netbook ISO.  Thanks agian.
<tkamppeter> directhex: are you listing the models which are missing in Kyocera's download or the ones which are missing on OpenPrinting?
<directhex> tkamppeter, the latter
<tkamppeter> So these are the newest models which need to get added?
<tkamppeter> directhex: And where can I download the PPDs?
<directhex> seems there are also some minor changes to old ones
<cjwatson> ScottK: oh good
<directhex> tkamppeter, bottom of http://www.kyocerasupport.co.uk/index/download_center.false.driver.FS1118MFP._.EN.html has a link
<StevenK> cjwatson: Well, I'd like to remove dose2 from the blacklist, just so I can get this librpm4.4 mess cleaned up.
<cjwatson> but won't it basically pull in the whole ocaml mess?
<cjwatson> I thought that was the point of blacklisting all that stuff
<StevenK> I'm just about to check that
<Laney> I think we should go ahead with the transition anyway
<cjwatson> i.e. I thought there were source changes in there that relied on the new ocaml
<Laney> (OCaml)
<StevenK> cjwatson: My other thought was doing -3~ubuntu1 which is -3, without the new ocaml
<ogra> god, thses gpm popups are annoying
<ogra> *these
<Laney> it doesn't seem so bad, and there's a nice tool for helping with it
<liw> ogra, hm?
<ogra> liw, i get "your battery is fully charged" or "... discharging" as popunders since some days
<liw> ogra, ugh
<ogra> *huge* popunders with three buttons in a row
<StevenK> Well, I wonder if Debian has completed the transition.
<StevenK> It's been a month, after all.
<StevenK> If they have, compiling a list of stuff to sync should be fairly simple.
<tkamppeter> directhex: The PPDs are under MIT license, so I can update OpenPrinting ...
<directhex> tkamppeter, i wouldn't have bugged you if they weren't Free :po
<directhex> :p
<tkamppeter> directhex, with OpenPrinting updated, Ubuntu Jaunty and higher would simply directly get them from OpenPrinting.
<Laney> StevenK: They have, apart from one sourc epackage (see mail to u-d-d)
<tkamppeter> directhex, about free licenses of PPDs, you can inform me about all PPDs offered for use with Linux, independent whether they are free or not, as in some cases I can contact the manufacturer.
<StevenK> Laney: Ah, but it seems like they want to keep 3.11.0 in Karmic, and have 3.11.1 in Karmic+1
<StevenK> Which makes me go argh
<directhex> tkamppeter, i don't generally look at this stuff, unless an engineer appears out of nowhere to take my laserjet away & put an unsupported-in-jaunty kyocera 1118 in its place
<Laney> well he asked if we should do the transition, and I said that I think we probably could and should
<StevenK> I agree that we should, it makes headaches like the one I just found go away
<tkamppeter> If the PPDs are redistributable but not free software (only vernatim redistribution) I can at least put them up on OpenPrinting, in the foomatic-db-nonfree package, and that is enough for Ubuntu auto-downloading the PPDs. If they are free, they get into foomatic-db and so also into Ubuntu.
<Laney> StevenK: would be good if you could say as much in that thread then
<directhex> tkamppeter, the only other printers i have access to generally are a Brother (so i get that frustrating ERROR problem on most print jobs) and a Toshiba (which works fine)
<directhex> tkamppeter, i did get to tell a Canon salesperson they were smoking crack once, though, thanks to their laughable loonicks support
<ogra> seb128, is ssh support in gvfs known to be broken atm ? my nautilus crashes if i try to sftp mount people.canonical.com
<seb128> ogra, do you have ubuntuone-client-gnome installed?
<Laney> WFM (tm)
<seb128> ogra, ubuntuone is known to make nautilus crash at the moment so if you have it yes it's known
<ogra> well, could i not ? its seeded :)
<ogra> so yes, i have
<ogra> thanks
<seb128> ogra, you're welcome
<seb128> ogra, nobody force you to have ubuntu-desktop installed, I don't ;-)
<ogra> i want to eat our own dogfood ;)
<ogra> kirkland, around ?
<cjwatson> ogra: (ubuntuone's only a recommendation, you can remove it and still have ubuntu-desktop installed)
<ogra> cjwatson, yeah indeed
<ogra> given that my invite timed out anyway, i should probably do that
<lool> ScottK: I think you tried pinging me over the WE but I forgot to go back to you
<SteveA> I know suspend / hibernate is fragile generally... it was working find on this laptop running jaunty.  Now, with karmic, suspend and hibernate don't work.  The screen goes dark for a while when I ask it to suspend then a minute or so later I get the "enter password to close the screensaver" screen.
<SteveA> should I file a bug?  against what package?
<ogra> likely the kernel
<hyperair> is anyone here familiar with gdk_window_get_frame_extents?
<hyperair> hmm no wait, that's not the problem here.
<hyperair> hmm for some reason my panel isn't a dock.
<james_w> is there someone else doing NEW at the moment?
<james_w> jdstrand: you perhaps?
<jdstrand> james_w: I was trying to get to a few before slangasek came online, yes-- are you doing mondays now?
<james_w> yeah, myself and slangasek split the day
<james_w> I've no problem with you doing some though :-)
<james_w> I'm just not sure what danger there is of collisions
<jdstrand> james_w: I plan to do ltsp-cluster-lbagent, moovida* and qemu-kvm
<james_w> great, thanks
<james_w> I'll go for lunch
<james_w> give me a shout once you're done and I'll do the rest
<jdstrand> james_w: ok
<james_w> thanks
<jdstrand> np
<Laney> does the i386 buildd call build-indep directly?
<geser> Laney: IIRC it calls build while the other call build-arch (but better look at a build log to be sure)
<stvo> window splitv
<stvo> sry
<pitti> hey stvo
<pitti> stvo: trying weechat? :-)
<ogra> pitti, is stvo who i think he is ?
 * pitti engages long-distance brain reader
<ogra> haha
<pitti> ogra: confirmed with 89.234 probability
<ogra> lol
<stvo> lol
<ogra> hi stvo, great to see you here
<stvo> thx
<stvo> ogra I'm testing your arm chroot
<stvo> environment
<ogra> nice :)
<ogra> note that its not 100% reliable but good for poking around ... some syscalls are likely missing
<kirkland> ogra: howdy!
<ogra> kirkland, lool told me you migh be working on a spec that implements something like https://wiki.ubuntu.com/ARM/BuildEABIChroot
<ogra> if thats true, is there any chance we see it in karmic ?
<lool> ogra: No, kirkland is working on getting us qemu updates though
<ogra> (i'm referring to the binfmt setup by default)
<ogra> ah
<lool> 11:49 < lool> I'm sure this can all be done when we refresh our qemu
<lool> 11:49 < lool> I think kirkland has a spec on this
<ogra> then i misunderstood the "all" in that sentence :)
<kirkland> lool: ogra: hmm, i'm working on getting the new qemu-kvm project into karmic
<kirkland> this project is the merger of the qemu and kvm code
<lool> kirkland: Is this based on qemu 0.11?
<kirkland> qemu plus the kvm acceleration bits
<kirkland> lool: that's the target
<kirkland> lool: 0.11 just hit Release Candidate
<lool> Cool
<ogra> cool, that at least gets us the eabi patches
<kirkland> lool: that will make it into karmic
<kirkland> lool: it was targeted at alpha3, but upstream slipped a little
<jdstrand> james_w: I'm done
<pitti> hah, fighting for sync karma? :-)
<jdstrand> who me? nah, I just couldn't get to archive much on Friday
<james_w> thanks jdstrand
<jdstrand> sure :)
<directhex> yay for james_w, one step closer to mono 2.4.2 in karmic
<ScottK> lool: Thanks for checking back, it got taken care of already.
<Ampelbein> hi there. whom should I poke when a NBS' dependencies is zeroed? In that case it's libgnokii3 where all dependencies on that are eliminated now.
<Ampelbein> or is there some kind of automagic NBS removal?
<james_w> Ampelbein: manual-automatic :-)
<Ampelbein> james_w: so I poke you and you do it? sweet! ;-)
<james_w> I've not done it yet
<james_w> we'll see if I get down that far on the list today
<Ampelbein> no worries... thank you for the info.
<lool> kirkland: Ack I heard that during the release meeting
<lool> kirkland: (ogra was rolling his own qemu 0.10 + patches to get some better ARM EABI support and was interested in having that in ubuntu which is why I pointed him at you)
<lool> I'm using tip + patches
<kirkland> lool: for tip, are you aware of https://edge.launchpad.net/~ubuntu-virt/+archive/virt-daily-upstream ?
<ogra> well, there is more than the patches ... but if our qemu-arm could support eabi that would be a major step forward
<ogra> i would still like to have a package i can easily install that enables binfmt
<ogra> and disables it on package removal respectively
<kirkland> ogra: lool: any reason why these patches aren't upstream in qemu?  we have a friendly qemu maintainer, we sponsored him to barcelona uds
<ogra> kirkland, the patches are apparently
<ogra> just not in our package
<kirkland> ogra: oh, great
<kirkland> ogra: then this will sort itself out very shortly
<kirkland> ogra: in the mean time, see: https://edge.launchpad.net/~ubuntu-virt/+archive/virt-daily-upstream
<kirkland> ogra: 0.11.50 is building there
<ogra> nice
<ogra> i'll try it out soon
<andresmujica> do we have an ubuntu java or eclipse channel?
<ogra> lool, kirkland, though for the chroot bits i would still need a statically build binary
<ogra> just strikes me ...
<lool> kirkland: I am aware of the PPA; thanks; I build tip by hand because I apply some non-mergeable patches on top of qemu
<ogra> *built
<ogra> kirkland, do you think it would be possible to roll a qemu-arm-static into our package ?
<kirkland> lool: gotcha, good to know
<kirkland> ogra: hrm, i don't see why not ...  do you have a diff that does this?
<kirkland> ogra: curious, just wondering... why do you need a static build of that binary?
<ogra> no, my package is totally badly built with its own copy of the qemu source and the patch inline
<lool> ScottK: Cool, so these perl libs should soon be installable?
<ogra> kirkland, what i do is: apply the eabi patches, build it statically, enable the interpreter in binfmt-support to match the magic of any armel binaries ... then i roll an armel chroot ... to exec armel binaries *inside* that chroot i need the x86 qemu ...
<ogra> kirkland, which indeed wouldnt find its libs *in* the chroot
<kirkland> ogra: right
<ogra> with the static version i can just chroot into my bootstrapped root and move on
<ScottK> lool: Right.  Thanks for the reminder (ugh).  No, it was another issue.
<ogra> its extremely convenient
 * ScottK looks into it.
<lool> Eh :)
<kirkland> ogra: agreed
<lool> So it's libcompress-raw-zlib-perl which I can't upgrade due to the dep of libio-compress-zlib-perl
<ogra> kirkland, in my package i essentially just do "./configure --prefix=/usr --target-list=arm-linux-user --static" in debian/rules, but i guess thats not proper enough for the actual package in the archive
<kirkland> ogra: right, let me think on this some
<kirkland> ogra: i'll talk to upstream too
<ogra> thanks :)
<kirkland> ogra: i might be able to add a binary package to the source package
<kirkland> ogra: qemu-arm-static or something
<kirkland> ogra: or qemu-static
<kirkland> ogra: and just publish that one to universe?
<ogra> that would be cool since it could also carry the proper postinst and prerm bits for binfmt
<ogra> universe is totally fine
<kirkland> ogra: would you open a wishlist bug against qemu to capture this?
<ogra> yeah
<kirkland> ogra: i'm tracking down a nasty ecryptfs right now
<kirkland> ogra: so i guarantee i'm going to forget this otherwise :-D
<ogra> no hurry
<ogra> kirkland, bug 401782 is yours
<ubottu> Launchpad bug 401782 in qemu "please build a static version of qemu-arm 0.11.x in a separate binary deb" [Wishlist,New] https://launchpad.net/bugs/401782
<kirkland> ogra: thank you sir!
<ogra> no, thank you ! :)
<kirkland> ogra: thank me when I finish the work :-)
<ogra> heh
<ogra> well, until then my hackish ppa package will do :)
<ScottK> lool: They've combined several perl modules into one.  This is non-trivial.
<RainCT> Keybuk: Hey. How does this look? http://revu.ubuntuwire.com/~rainct/mom.html
<Keybuk> cute
<cjwatson> RainCT: I'm sure it's not the point, but your data is perplexing - you seem to be using the primary UID on the signing key for "Last Uploader", rather than, say, Changed-By if it matches one of the UIDs on the key ...
<RainCT> cjwatson: Seems like it's just running gpg and looking at the "Good signature from X" line. But hey, that's not my code! :)
<Keybuk> cjwatson: patches welcome
<Keybuk> cjwatson: in fact, I think you may have _written_ this patch in the first place ;-)
<cjwatson> Keybuk: oh, I didn't think current MoM acted this way ...
<cjwatson> I don't remember doing so? but that doesn't mean a whole lot
<RainCT> Keybuk: The (new design) code is up on lp:~rainct/merge-o-matic/redesign for your merging pleasure :)
<Keybuk> Jo Shields <directhex@ubuntu.com>
<Keybuk> Uploader: Colin Watson <cjwatson@flatline.org.uk>
<Keybuk> (e.g. from current MoM output)
<cjwatson> definitely wasn't me who wrote that patch, I don't recognise that code at all
<Keybuk> RainCT: though that's a good point
<Keybuk> RainCT: your code drops the distinction
<cjwatson> anyway, current MoM doesn't act this way because for the upload in question changer == uploader
<Keybuk> current MoM shows both the Changed-By *and* Uploader when different
<Keybuk> yours only shows the Uploader
<Keybuk> (who is generally a sponsor, not the person who made the change)
<cjwatson> right
<Keybuk> RainCT: looks like you haven't touched manual-status.py yet?  Would be good to have that in the same form
<RainCT> Keybuk: Oops, right. My test with a single package isn't that helpful :)
<Keybuk> RainCT: other than that it looks good
<Keybuk> so if you can fix those two things, I'll be more than happy
<RainCT> Keybuk: uhm, hat is that manual-status.py thing?
<Keybuk> RainCT: produces https://merges.ubuntu.com/{main,universe,restricted,multiverse}-manual.html
<andresmu1ica> i've lost X output completely with latest gdm update in karmic...  :/
<pitti> andresmu1ica: "x output"?
<andresmujica> pitti: black screen with everything working.. give a minute i've downgraded to gdm 2.26 and recovered X output.. upgrading again to confirm or deny it...
<RainCT> Keybuk: can you please check if the uploader is displayed now?
<andresmujica> pitti: not related to gdm, it seems a bug with kernel 2.6.31-1-generic it gives no X output .. but as we already passed it there's no problem at all.
<kirkland> karmic sound issues?  i'm getting momentary pauses during mp3 playback;  tried numerous different players and sources
<kirkland> dtchen: ^
<ogra> kirkland, i had mine play at double speed on the weekend ... reboot fixed it
<kirkland> ogra: heh
<kirkland> ogra: i've rebooted a few times recenty
<ogra> upgraded too ?
<ogra> i first did an upgrade (which didnt ask for reboot) ...
<ogra> and after the reboot it was actually working fine ...
<ogra> i had the issue in all players, even tried mplayer and xine
<RainCT> Keybuk: Should work now, but I can't test manual-status.py myself
<slangasek> james_w: fwiw, it's perfectly fine for archive admins to sync packages directly instead of filing sync requests. :)
<james_w> :-)
<infinity> (Unless you really want a review or something)
<infinity> (But then I'd take that OOB and just get it done quickly)
<directhex> is ubuntu-meta maintained someplace in bzr?
<slangasek> directhex: no, since most of the contents are autogenerated there hasn't been much need
<rtg_> slangasek, do you have a moment to review my proposed addition of rfkill to wireless-tools ? http://kernel.ubuntu.com/~rtg/wireless-tools.diff
<slangasek> rtg_: <squint> the diff looks fine, but why in the world is this now being done via a control device instead of via /sys?
<slangasek> that really seems like a step backwards
<rtg_> slangasek, it can be done both ways, but I guess /dev/rfkill is the preferred method for setting/retrieving state for all wireless devices.
<slangasek> no, it can't be done both ways :)
<slangasek> not in 2.6.31 - someone broke the /sys interface
<rtg_> I thought it just moved
<slangasek> well, they broke two things - 1) there's no longer a link to the rfkill interface from the /sys/class/net tree, 2) trying to toggle any rfkill interfaces through sys fails with "Operation not permitted"
<nxvl> james_w: is there something in bazaar like svn debcommit?
<rtg_> slangasek, for the acpi-support package the rfkill application should be sufficient for controlling rfkill state. do you want me to pursue what is wrong with the sysfs interface?
<james_w> nxvl: what does that do?
<rtg_> instead
<nxvl> james_w: commits the changes and generates the comment from the changelog
<james_w> debcommit doesn't do what you want?
 * nxvl tries
<nxvl> james_w: yes it does
 * nxvl HUGS james_w 
<slangasek> rtg_: well, I'm getting a little sick of the interface moving every single release, and the acpi-support compatibility code becoming increasingly baroque :/
<slangasek> rtg_: I thought the previous /sys interface was a very sensible one, and it seems like a bug to me that it's changed again
<rtg_> slangasek, as well that may be, there is little I can do about it.
<slangasek> rtg_: who's working on this stuff upstream?  maybe I can rant at them directly :)
<slangasek> (anyway, surely it /is/ a bug that you can't change the state via /sys at all anymore?)
<rtg_> slangasek, Johannes Burg is the guy that rewrote rfkill. I guess he'd be the best place to start. Perhaps on the linux-wireless@vger.kernel.org list.
<rtg_> s/Burg/Berg/
<slangasek> rewrote - bah :)
<slangasek> ok, I'll see what comes of prodding, thanks
<rtg_> slangasek, well, the original version did had some serious problems from what I understand.
<bannaN> I could be interested in contributing in the development of ubuntu, where do i start? What kind of skill-level is required?
<azeem> bannaN: ask in #ubuntu-motu
<cjwatson> bannaN: http://wiki.ubuntu.com/ContributeToUbuntu
<bannaN> Kindy dont know where to start, who to ask, and how to join, and what kind of work-tasks is available for a person with my knowledge
<cjwatson> bannaN: right, it's complicated (and we don't know either, because it depends so much on your interests and experience), which is why I gave you a page full of links that you can go and read :-)
<bannaN> cjwatson: hehe, yeah, what i had in mind was maybe bugfixing, testing or something like that, dont know whats possible in the begining, and how tasks are asigned
<cjwatson> bannaN: with some exceptions (for instance, people employed to work on Ubuntu often have things assigned to them), people generally take things for themselves rather than waiting to be asked
<cjwatson> the process for fixing bugs is to find some bugs you think are interesting and send patches! :-) And http://wiki.ubuntu.com/SponsorshipProcess if you want to get those patches reviewed in a timely fashion
<BUGabundo> hey dear devs
<BUGabundo> pitti: were you who broke gtk on karmic with that patch for gfvs?
<seb128_> BUGabundo, gtk and gvfs are really different things
<BUGabundo> yeah I know
<BUGabundo> just gluing some pieces
<BUGabundo> haven't got my listchanges to work yet, after format
<seb128_> BUGabundo, not really gluing no, gvfs has no user inferface and don't use gtk
<BUGabundo> so knolage may be incomplete :)
<seb128_> BUGabundo, and gtk doesn't use gvfs either
<seb128_> BUGabundo, rather than trying to guess you should better describe your issue
<BUGabundo> seb128_: not a single icon anywhere on my system
<BUGabundo> err
<BUGabundo> not _my_. any karmic, updated
<seb128_> ?
<BUGabundo> yofel: what was the package you mentioned?
<yofel> seb128_: .xsession-errors tells us that it can't recognize the picture format
<yofel> of the icon theme
<seb128_> BUGabundo, "any", works for me
<BUGabundo> seb128_: yes, really. no app icons, not icons on pidgin, on firefox, nothing
<BUGabundo> just boxes with red cross
<yofel> seb128_: like for example: ** (gnome-terminal:13296): CRITICAL **: failed to load icon 'lpi-translate': Format der Bilddatei unbekannt
<seb128_> having english errors would be a good start
<yofel> it's something along of: unknown picture format
<BUGabundo> let me pastebin mine
<BUGabundo> its in english
<BUGabundo> $ pastebinit .xsession-errors
<BUGabundo> http://paste.ubuntu.com/223031/
<seb128_> BUGabundo, did you open a bug using apport?
<BUGabundo> not yet
<BUGabundo> I just came online
<BUGabundo> and yofel confimed it, so I though I would ask around
<seb128_> BUGabundo, what architecture do you use?
<BUGabundo> before putting it on LP with no package
<BUGabundo> x64
<seb128_> yofel, you?
<yofel> seb128_: yes, updated my system a few minutes before BUGabundo came and have the same issue
<BUGabundo> hey kenvandine
<seb128_> yofel, the question was "what arch do you use"?
<yofel> oh, sry - amd64
<BUGabundo> ahah
<seb128_> k, could be amd64 specific
<giles> yofel: I tuned in
<BUGabundo> seb128_: package so I can file it ?
<BUGabundo> humm notify OSD is gone too LOL
<seb128_> BUGabundo, gtk+2.0
<yofel> giles: what's your cpu-arch? x86 or x64?
<BUGabundo> at least Volume one
<BUGabundo> seb128_: Package gtk+2.0 does not exist
<Ampelbein> BUGabundo: ? https://bugs.edge.launchpad.net/ubuntu/+source/gtk+2.0
<seb128_> libgtk2.0-0 if you want a binary package rather
<giles> yofel: x64
<BUGabundo> Ampelbein: tell that to my apport :)
<seb128_> the issue seems amd64 specific
<seb128_> I've no amd64 config to work on that though
<BUGabundo> uploading now
<BUGabundo> The collected information can be sent to the developers to improve the
<BUGabundo> application. This might take a few minutes.
<BUGabundo> ............................................................................................................................................................................
<BUGabundo> never seen apport take soooooooo long
<BUGabundo> I think it jammed :(
<BUGabundo> back
<BUGabundo> sorry, lost wifi
<seb128_> BUGabundo, do you have a  /usr/lib/gtk-2.0/2.10.0/loaders/libpixbufloader-jpeg.so ?
<BUGabundo> $ ls  /usr/lib/gtk-2.0/2.10.0/loaders/libpixbufloader-jpeg.so
<BUGabundo> -rw-r--r-- 1 root root 23K 2009-07-20 18:12 /usr/lib/gtk-2.0/2.10.0/loaders/libpixbufloader-jpeg.so
<seb128_> BUGabundo, ok, the amd64 build lacks the png loader for some reason
<BUGabundo> https://bugs.edge.launchpad.net/ubuntu/+source/gtk+2.0/+bug/401938
<BUGabundo> yofel: giles: feel free to sub
<yofel> seb128_: the svg one is missing as well i think
<ubottu> Ubuntu bug 401938 in gtk+2.0 "no icons" [Undecided,New]
<BUGabundo> ohhh the bot is lagged 1min
<BUGabundo> can someone set that to confirm, please?
<seb128_> BUGabundo, what difference does it make?
<yofel> BUGabundo: seb128_ did that already?
<BUGabundo> ok
<seb128_> BUGabundo, I did for the record, still need debugging from somebody on amd64
<BUGabundo> seb128_: tells us what you ned
<BUGabundo> *need
<BUGabundo> I'm here to help :)
<BUGabundo> ahahah
<BUGabundo> and he left :\\\
<cody-somerville> pitti, Whats holding up the gdm changes we agreed on?
<cody-somerville> slangasek, ^^
<cody-somerville> slangasek, We're quickly running out of time and the Xubuntu CDs are still oversized pending the changes to gdm
<slangasek> cody-somerville: I'm not on the desktop team, I wouldn't know
<slangasek> cody-somerville: is there a bug report open for this?
<cody-somerville> slangasek, There was but it seems to be closed, trying to find it
 * BUGabundo slaps seb128 connection
<seb128> BUGabundo, what is required is somebody having access to an amd64 box and a clue about autotools and libtool to debug
<BUGabundo> I have the 1st
<BUGabundo> not the 2nd
<BUGabundo> let me fetch someone from +1
<giles> seb128: need debug info from somebody on amd64?
<seb128> giles, not really, rather need somebody able to debug the issue
<giles> which issue?
<seb128> giles, ie giving me informations will not likely lead somewhere, I've no real clue about the issue seems to be something due to libtool
<seb128> giles, cf bug #401938
<ubottu> Launchpad bug 401938 in gtk+2.0 "no icons" [Undecided,New] https://launchpad.net/bugs/401938
<seb128> "libtool: relink: gcc -shared .libs/io-png.o -lpng12 -L/build/buildd/gtk+2.0-2.17.5/debian/install/shared/usr/lib -L/usr/lib -lgdk_pixbuf-2.0 -lgio-2.0 -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lm -Wl,-Bsymbolic-functions -Wl,-soname -Wl,libpixbufloader-png.so -o .libs/libpixbufloader-png.so
<seb128> /usr/bin/ld: cannot find -lgdk_pixbuf-2.0
<seb128> collect2: ld returned 1 exit status"
<cody-somerville> slangasek, LP #396321, LP#400901, LP #400094
<ubottu> Launchpad bug 396321 in gdm "GDM fails to start if gnome-session is not installed" [Undecided,Fix released] https://launchpad.net/bugs/396321
<ubottu> Launchpad bug 400094 in xubuntu-meta "Xubuntu 9.10 daily build includes Gnome2 instead of Xfce4" [Critical,In progress] https://launchpad.net/bugs/400094
<cody-somerville> slangasek, I'm going to create a new master bug report to include all the details.
<slangasek> cody-somerville: isn't bug #400901 that?
<ubottu> Launchpad bug 400901 in gdm "gdm is requiring gnome-session in karmic" [Undecided,New] https://launchpad.net/bugs/400901
<seb128> anybody on karmic amd64 who could give a build try to gtk+2.0?
<seb128> to see if the build issue mentioned before and breaking png loading is a random glitch or a real error?
<cody-somerville> slangasek, I'm going to modify 400901
<giles> seb128: i could
<seb128> giles, thanks
<yofel> seb128: I'm building it too
<seb128> thanks
 * BUGabundo is looking :)
<cody-somerville> slangasek, updated and milestoned
<pitti> cody-somerville: ah, did you update your branch and merge request? didn't get a mail about it
<seb128> pitti, hey
<pitti> hey all
<seb128> pitti, I expect bug #401938 to quickly become an issue
<ubottu> Launchpad bug 401938 in gtk+2.0 "no icons" [Undecided,New] https://launchpad.net/bugs/401938
<BUGabundo> hey pitti
 * BUGabundo is always finding HIGH bugs for seb128 :)
<seb128> pitti, just to let you know if you look at milestoned issues this week
<pitti> seb128: oh, thanks; indeed, I'm the alpha-3 RM this week, so I have to care :)
<cody-somerville> pitti, Sorry, I thought you were just going to make the changes. I'd be happy to update my branch for you.
<seb128> BUGabundo, you seem to enjoy when users are in trouble
<pitti> cody-somerville: I don't really know the appropriate xubuntu alternatives, and you said it also needs some patches for not hardcoding metacity, etc.?
<cody-somerville> pitti, Sounds good to me. I'll do that this evening.
<pitti> seb128: hm, I'm on amd64, and my icons are just fine
<pitti> didn't update to new gtk yet, though
<pitti> the most annoying thing is gnome-keyring ssh being broken (not exporting the env var)
<seb128> pitti, well it's clear from the build log that the png loader didn't build on amd64
<pitti> but just like so many of those, I guess it's a gdm bug again :/
<seb128> pitti, didn't notice that there and gnome-keyring didn't change for some weeks
<BUGabundo> seb128: no pleasure here. but I'm an alpha tester, so I've been finding many bugs over the years, helping to put them on BTSs, triaging, alerting users... the usual
<pitti> seb128: yeah, SSH_AUTH_SOCK=/tmp/keyring-tYQTmS/socket.ssh ssh ... works
<pitti> seb128: bit too late right now, but I'll give a go at that amd64 thing tomorrow morning
<seb128> pitti, the environment export is a dbus thing I think
 * pitti dist-upgrade
<seb128> pitti, thanks, it's not the end of the world it's only icons
<pitti> ah, there comes a new gtk
<seb128> pitti, I just hate autotools and I've no amd64 box to look at what's going on
<seb128> pitti, and I don't know enough about libtool to guess what is wrong without logs and access to a build
<seb128> could be a race and work on next build, dunno
<slangasek> directhex: monodevelop-boo appears to be in need of a fakesync, due to mismatched .orig.tar.gz md5sum
<directhex> slangasek, is it? i believe the fakesync part, but i don't remember doing anything to break it recently
<BUGabundo> ok my work here is done. thanks
 * pitti cd /bed, good night
<BUGabundo> bye pitti
<yofel> seb128: the png loader built fine when just running ./configure && make - debuild and pbuilder are still running
<seb128> yofel, ok thanks
<directhex> of course, i apparently broke sid, so what do _I_ know?
<directhex> oh, there's the problem, monodevelop-boo is missing from our tracker
<directhex> wgrant, poke poke
<directhex> mmm, still hasn't had a new upload since april
<directhex> slangasek, was your comment simply regarding the funny version number? if so, a fakesync is fine, but i'm not sure what it would achieve given the packages are identical anyway
<wgrant> directhex: Hi.
<slangasek> directhex: no, the packages aren't identical, there's a build-dep on libgtksourceview2.0-cil
<directhex> wgrant, can you manually add packages to an MDT page?
<wgrant> directhex: I can.
<directhex> slangasek, really? how silly
<wgrant> directhex: But let's see if there's a more general way to get that one too...
<directhex> wgrant, well, most of monodevelop* is with meebey as sole maintainer, not group maintained (according to control, anyway - not in reality)
<wgrant> directhex: So, we only grab packages with one of the three mono maintainers right now.
<directhex> slangasek, so a fakesync to universe just involves uploading a signed source package using our orig and their diff, yes?
<wgrant> I guess I'll just add this explicitly now.
<directhex> wgrant, sorry!
<slangasek> directhex: yes
<directhex> slangasek, okay, give me a minute. my first direct archive upload. eeks!
<wgrant> directhex: It be there now.
<directhex> tee hee, that makes things slightly more convenient:  -- Jo Shields <directhex@apebox.org>  Wed, 08 Apr 2009 22:42:33 +0100
<directhex> wgrant, coolness. ta!
<directhex> ehm... i take it i need to manually specify an upload distro in dput.cf? it's not bright enough to deal with "unstable -> karmic"?
<Laney> it comes set up with ubuntu as default I think
<Laney> (you should change this)
<Laney> you do need to change the release in the changelog though
<wgrant> Isn't one meant to add an XbuildY changelog entry for a fakesync?
<seb128> wgrant, not if the tarball is different
<seb128> wgrant, otherwise it will be tried by the auto-syncer and break
<yofel> seb128: the debuild and pbuilder builds built without error too
<directhex> Laney, you change the release in changelog for a fakesync?
<seb128> yofel, and the png loader is built?
<wgrant> seb128: But it is meant to be autosynced.
<yofel> seb128: according to 'dpkg -L libgtk2.0-0' yes
<seb128> wgrant, well, if the orig.tar.gz is different that's not going to happen
<wgrant> seb128: It will when Debian uploads a new upstream.
<wgrant> And until then the autosyncer will just not do anything.
<seb128> wgrant, right, but we have no way to say to the auto-synced "it's a buildn version but try only next upstream version and not next revision"
<Laney> directhex: yes sir, otherwise it will be rejected afaik
<seb128> wgrant, it will break at each run until you sort it
<wgrant> seb128: I see.
<seb128> wgrant, 0.8-1build1 will try to autosync 0.8-2
<wgrant> directhex: Soyuz works out the upload series by looking in the .changes, which is generated from the changelog.
<directhex> Laney, can you suggest a fakesync changelog to read, to make myself feel better?
<seb128> wgrant, and that will break the sync run on a md5sum mistmatch error
<seb128> directhex, http://people.canonical.com/~pitti/scripts/syncpackage
<Laney> directhex: I might have done one for one of the debuggers
<seb128> directhex, in fact that's to do a real sync yourself so ignore it
<Laney> but, just change the release to karmic
<Laney> 0ubuntu1 the version number
<seb128> directhex, basically get debian source, edit changelog to change unstable to karmic, build, sign, upload
<directhex> Laney, that's a 0ubuntu1, not a fakesync, no?
<wgrant> seb128: I see a lot of build1 fakesyncs
<Laney> seb128: I thought that was what was just being discussed
<seb128> wgrant, right, when the orig.tar.gz doesn't mismatch so next sync will work
<Laney> erm
<Laney> directhex: *
<seb128> wgrant, that's what we do for rebuilds since we don't have bin-nmu
<wgrant> seb128: No, these are for mismatched orig.tar.gzs.
<seb128> wgrant, ie a package is in sync and need a rebuild you use build1 so next sync get it
<wgrant> No.
<directhex> seb128, good, binNMU is the work of the devil
<Laney> I would 0ubuntu1 it to avoid it being autosynced
<seb128> wgrant, well that's wrong and that will create issue during the next autosync run
<seb128> wgrant, give me names ;-)
<wgrant> seb128: A few of these were by archive admins...
<wgrant> So I somehow think they are doing it the right way.
<seb128> wgrant, can you give me an example?
<wgrant> https://lists.ubuntu.com/archives/karmic-changes/2009-June/002294.html
<directhex> Laney, not an issue, since the package  won't need to be changed until the next upstream release
<directhex> *cough*
 * Laney blinks
<seb128> wgrant, archive admin have access to the autosync filters so they can put things on the ignore list if they want
<directhex> meh, close enough for government work. where'd i put that dput...
<seb128> but I think it's easy using an ubuntu<n> versioning
<seb128> wgrant, I will check with pitti tomorrow
<cjwatson> I think build1 plus a blacklist entry is fine
<seb128> he probably added the source to the don't sync list
<seb128> cjwatson, well it's extra archive admin work compared to using 0ubuntu1 and asking for a sync later
<cjwatson> I'm not sure it actually is extra work; manual syncs are work too
<cjwatson> and about the same amount, tiny either way
<seb128> that's maybe because I don't check for packages on the list often
<cjwatson> anyway, /me -> sleep -> debconf
<seb128> ie if I'm doing sync those are likely to stay on the "do not sync" list for a while
<seb128> ie, it's not trivial to know when to drop them from the list
<seb128> yofel, ok thanks, I've a uploaded a no change rebuild version
<seb128> let's see how it works
<yofel> seb128: after installing my self-build .deb files everythings ok again
<seb128> yofel, ok, good, I've no explanation about the issue
<dupondje> i'm trying to compile it here also, checking if it works also
<seb128> I've uploaded a new revision
<seb128> it will have built in 16 minutes or so
<seb128> let's see how that one goes
<dupondje> good thing :)
<NoelJB> seb128: I understand that you just posted the fix.  Thank you for the very prompt response.  :-)  [sometimes a "thank you" is the only currency in Open Source]
<dupondje> its not a real fix tho, its just a reupload to rebuild it
<seb128> NoelJB, thanks, dunno if that build will work, I don't know why the previous one had the issue
<seb128> ok, new gtk built correctly now and fixes the issue
<yofel> seb128: thanks :)
<seb128> yofel, thank you for testing and reporting the issue early
#ubuntu-devel 2009-07-21
<dupondje> seb128: its still broken ?
<dupondje> argh, nvm
<seb128> dupondje, should be fixed in 2.17.5-0ubuntu2 when it will be published on the mirrors
<seb128> you can download the deb from launchpad too
<dtchen> kirkland: which players (and backends)? the only issues i've had for my hardware and software are related to xine and reenabling glitch-free for testing.
<dtchen> kirkland: please file a bug with that info, and i'll look
<kirkland> dtchen: i'll get it for you
<dtchen> jdstrand: not to appear daft, but have the speakers been replaced with headphones as another test?
<kirkland> wow, gdm is in a bad way
<dtchen> even with gtk+2.0 2.17.5-0ubuntu2 bits installed?
<kirkland> dtchen: hmm, i think so
<kirkland> dtchen: specifically what packages?
<kirkland> oh, wait
<kirkland> i have a few on 0ubuntu1
<dtchen> libgtk2.0\*
<kirkland> dtchen: yeah, i'm on 2.17.5-0ubuntu1
<YokoZar> kees: Can you give any links ~https://bugs.launchpad.net/ubuntu/+source/wine/+bug/401950  so I can file a good upstream bug telling them how to do it?
<ubottu> Ubuntu bug 401950 in wine "mmap_min_addr should be handled via CAP_SYS_RAWIO" [Medium,Triaged]
<kees> YokoZar: well.... I can try.  Wine would be the first package to use filesystem capabilities, so it's kind of new territory.
<YokoZar> kees:  Is it documented anywhere?  That might be enough.
<kees> YokoZar: I'll go look, there are two halfs: fscaps itself, and the dropping of the capability after memory is allocated
<kees> YokoZar: I will try to get pointers to both
<YokoZar> Thanks
<kees> YokoZar: okay, added some examples with URLs
<YokoZar> Thanks kees
<kees> np, thanks for poking me to get those -- I couldn't find them earlier.  :)
<reed> Has Ubuntu Moblin Remix actually been created yet?
<robert_ancell> Has anyone here used PolicyKit before?
<robert_ancell> kenvandine, ping if you are up
<jdstrand> dtchen: the speakers work-- I plugged my music player into them and listened on them all day :)
<jml> slightly OT, but you might like to know that Launchpad is now open sourced. https://dev.launchpad.net/.
<ScottK> jml: All of it or some of it?
<jml> ScottK: all of it.
<ScottK> jml: Welcome news.  Congratulations.
<jml> but don't trust me! there's code to be looked at :)
<Hobbsee> yay!
<ScottK> jml: It's nearly 1AM here and I have to be out the door for $WORK stuff by 6AM, so I'll trust you on the short version for now.
<jml> :)
<jml> anyway, the party's on #launchpad-dev if you'd like to join us.
 * ScottK is already there.
 * ghindo is going.
<mneptok> wait, Soyuz is open, too?
<LaserJock> mneptok: yep
<mneptok> nice.
<mneptok> i can't wait to run it on my G1 phone.
<mneptok> *bah dum tish*
<pitti> Good morning
<ruslanr> pitti: good morning :)
<emgent> GOOD MORNING! http://seclists.org/fulldisclosure/2009/Jul/0279.html
<cjwatson> emgent: OpenSSH upstream have no knowledge of the vulnerability; if you do, by all means share
<cjwatson> (or at least they had no knowledge a few days ago when it last came up on openssh-unix-dev)
<emgent> i think that anti-sec people mailed upstream
<cjwatson> upstream explicitly denied having any inside information, and I know them well enough to know they'd just keep quiet if they did
<emgent> uhm ..
<cjwatson> anyway, got to go
<\sh> moins
<emgent> cjwatson: kk
<cjwatson> there's certainly nothing we can do about it right now
<emgent> \sh: good morning.
<\sh> hey emgent...how's life? :)
<emgent> \sh: real busy but all good :P
<emgent> ok i go to work, see you soon people.. i will mail about it quickly
* pitti changed the topic of #ubuntu-devel to: Archive: Alpha-3 soft-freeze | DebianImportFreeze in effect | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-jaunty | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<liw> the anti-sec people are out to destroy the full disclosure lists and the security industry, aren't they? why would they tell openssh upstream anything, it's much more effective for their goals to reveal a 0-day exploit without any prior warning
<pitti> well, right now I'm not sure whether to take this seriously, or whether it's just boasting
 * pitti tends to the latter
<\sh> it's all about publicity
<bryce> pitti, heya, nice to see alpha-3 right around the corner, however it's caught me in the middle of a couple important merges - mesa 7.5 (released last night) and -intel 2.8.0 (unfortunately released minutes after your freeze announcement)
<pitti> bryce: please go ahead, we planned to have them in alpha-3
<bryce> pitti, excellent thanks
<pitti> bryce: compared to xorg-edgers, the difference should be really small, shouldn't it?
<bryce> yep
<pitti> bryce: 2.8.0 final? nice \o/
<bryce> in fact there's very little difference between the git snapshots and the official release
<pitti> mesa | 7.5~rc4-1ubuntu3 |        karmic | source
<pitti> that shouldn't be too bad
<bryce> right
<pitti> bryce: I talked to the kernel guys last Friday on the release meeting, and it was decided to not update the kernel for alpha-3
<bryce> also debian packaged mesa 7.5 already so it's just a straightforward merge
<pitti> so we have to live with the current one, but it should work just fine
<bryce> oh okay, what rc are we at?
<pitti> bryce: nice; do we still have a large delta?
<pitti> bryce: rc3
<bryce> thanks
<pitti> bryce: I asked them to pull drm-intel-next, but that itself requires some bureaucracy; but it's just a couple of bug fixes AFAICS, nothing major
<kees> cjwatson, emgent: just to make sure you know, the "anti-sec email" to fd is a trojan that will attempt to erase your hard drive if you run it.  please be careful.
<pitti> bryce: I had hoped to get ATI KMS in alpha-3, but seems we need to wait for alpha-4 for that
<pitti> bryce: but I think with a modprobe.d file you can enable it, can't you?
<pitti> bryce: if that's easy, and you want test feedback, I'm happy to write a stanza into the tech overview
<bryce> yeah Sarvatt says ati is still a bit jumbled at the moment but we're keeping an eye on it
<bryce> or rather he's been keeping an eye on it, I've been hammering on -intel boogz :-)
<Sarvatt> are you guys really going to try to get it in alpha 4? would need to jump to mesa 7.6 to use it
<bryce> hmm, yeah we probably should solicit -ati testing feedback more firmly
<bryce> Sarvatt, well getting -ati with KMS is a big goal for Karmic, and the sooner we get it in the better... but what do you think?
<Sarvatt> when's the last time mesa could be upgraded before release? theres no way its going to get brought back into 7.5.x because it depends on radeon-rewrite
<LaserJock> kees: the actual email is a trojan?
<bryce> Sarvatt, it depends on how major the update is
<kees> LaserJock: the program they posted as "the exploit" is an obfuscated trojan.
<bryce> Sarvatt, if it is from a well-tested git snapshot that's within a reasonable number of changes, that is usually relatively safe.  But if it's a whole version, like 7.5.0 -> 7.6.0, that's probably not so wise
<Sarvatt> if its september you'd probably be looking at a pre rc1 git snapshot getting into karmic release if you want radeon KMS..
<LaserJock> kees: ah, I see
<kees> LaserJock: http://seclists.org/fulldisclosure/2009/Jul/0289.html linked in the pastebin there.
<Sarvatt> 7.4 - 7.5rc1 was 2 months and 7.5 just released 3 days ago
<kees> LaserJock: we'll see if they actually release something real, but I'm currently assuming it's just FUD
<pitti> Sarvatt, bryce: in my own humble opinion, I'd rather like to see regular git snapshots being uploaded, and we keep instructions how to manually enable KMS and provide feedback
<pitti> karmic is a crack release either way, and 10.04 is LTS, so better break it now
<pitti> Sarvatt: feature freeze is August 27th, so if ATI KMS isn't enabled by then, it's not going to make the release
<\sh> pitti: I thought the next LTS is not really set
<Sarvatt> I like pitti's way of thinking :D
<pitti> \sh: I think it's pretty firm, though
<pitti> Sarvatt: I think we can reasonably make mesa updates until October 8 (with feature freeze)
<pitti> so, based on these dates, bryce and you are the best persons to judge
<Sarvatt> ohh in that case its not so bad, i was just worried about the state it would be in by august 27th
<pitti> meh, I downsized CDs last night, and today's image _grew_ by 2 MB?
 * pitti sighs
<bryce> pitti, just remember I'm probably going to be gone most of september
<bryce> but I can set -ati as a priority for when I'm back.
<pitti> bryce: well, do you think it's a realistic target?
<pitti> bryce: if it's too brittle, then describing how to install a modprobe.d file would work as well
<bryce> yes I do, as long as it gets sufficient attention and folks keep an eye out for bugs and are able to put in patches in september, I don't see it as a showstopper
<Sarvatt> pitti: you still need libdrm-radeon1 on top of mesa 7.6 as well as the ddx compiled against libdrm-radeon1 for kms support, the modprobe.d method wont work unless the people are using edgers
<pitti> Sarvatt: ah, ok
<Sarvatt> i've heard nothing but good things about radeon KMS though in #radeon from people using edgers on karmic, its nowhere near as bad off as intel was at this point a month after 2.6.29-rc1 where KMS got added
<Sarvatt> just some suspend/resume problems and performance could be better
<bryce> I've always been impressed at the ATI team's attention to stability, they're more conservative about merging development branches into their main
<Sarvatt> and its not working on big-endian platforms yet, go figure my only ati machine to test it on is PPC :D it works but the colors are wrong
<bryce> I do have to say, the intel team is better at processing bugs; I've got a ton of stale upstreamed -ati bug reports
<Sarvatt> helps they are sticking to EXA, most of the intel KMS problems for awhile there were UXA specific
<bryce> yeah
<bryce> in fact, I'd been enabling EXA for -ati in ubuntu long before they enabled it upstream
<Sarvatt> ati seems mostly a 2-3 man show and the main guy works for redhat so probably pays more attention to bugs there :D
<bryce> it could be ;-)
<bryce> Sarvatt, probably would be a good idea for us to start noting bugs fixed in the radeon-rewrite branch (ala #273329)
<StevenK> pitti: I uploaded opal before your freeze, can I accept it out of NEW? :-0
<StevenK> s/:-0/:-)/
<StevenK> pitti: (Binary NEW)
<pitti> StevenK: sure
<pitti> the soft freeze doesn't mean "stop doing things", just "stop doing things that introduce breakage"
<pitti> StevenK: http://people.canonical.com/~ubuntu-archive/component-mismatches.txt wants to bring hildon back, for cheese; do we still need that in cheese?
<pitti> StevenK: hm, you have isdnutils in UNR ship seed?
<pitti> that seems a little strange
<seb128> slangasek, hey, apparently samba 4.4 broke gvfs smb in some way ... ;-)
<seb128> 3.4 rather
<slangasek> seb128: make the uploader fix it? :)
<seb128> slangasek, good idea ;-)
<slangasek> I haven't touched samba 3.4
 * smb moans about more samba discussions
<highvoltage> smb: heh
<ogra> hmm, was there a gtk upload ?
 * ogra wonders why totem ftbfs on armel ... 
<seb128> ogra, since ubuntu was created there was several of those
<ogra> haha
<seb128> ogra, the question was really clear you have to admit...
<ogra> ah, i see gtk was uploaded shortly after totem
<ogra> likely still building on arm when totem was attempted ...
 * ogra gives back 
<seb128> ogra, right, seems to be a transitional issue
<ogra> yeah
 * ogra wishes compiz wouldnt depend on kde stuff, it breaks the world on armel :/
 * \sh wishes that the world wouldn't need compiz
<directhex> \sh, as opposed to...?
<\sh> directhex: it would make things easier ;)
<liw> the world doesn't need compiz. the world wants compiz the way it wants sugar in all food -- it satisfied simplified, self-destructive impulses that are remnants of an evolutional era when sweetness was good, but rare
<pitti> ScottK: hm, your new upstream release of libcompress-raw-zlib-perl made libio-compress-zlib-perl and libio-compress-zlib-perl uninstallable; I guess they need new versions as well?
 * \sh doesn't like sugar in chili
<directhex> \sh, gotta add HFCS to everything!
<\sh> directhex: whatever HFCS is ...
<liw> \sh, I don't like sugar in chili, bread, meat, or ketchup, either
<directhex> http://en.wikipedia.org/wiki/High_fructose_corn_syrup
<\sh> directhex: too sweet ... /me only uses http://aimas-farms.com/Portals/0/AFRICAN-CHILI-or-scotch-bon.gif <- nasty, hot, strong, excellent, even good for making good sauces
<liw> high fructose corn syrup counts as sugar in my book :P
<directhex> liw, then you have low standards!
<liw> i.e., as long as my doctor will hate me if I eat it, it's sugar
<directhex> would your doctor hate you for eating ping-pong balls?
<liw> nope, unless they have an effect on my diabetes
 * LaserJock sits down to a 1am snack of candy bars and licorice
<pitti> linux-headers-2.6.31-3-server | 2.6.31-3.19 |        karmic | amd64
<pitti> hmm
<pitti> where did the i386 build go?
<directhex> you decided to drop support for obsolete architectures!
<pitti> lol
<pitti> hm, it seems that there's no i386 -server kernel at all any more?
<pitti> amitk, smb: ^
<pitti> linux-headers-virtual and linux-backports-modules-karmic-virtual depend on them, and thus are uninstallable
<pitti> (on i386)
<smb> pitti, (apw) it is gone
<apw> pitti that sounds wrong
<apw> i'll look into it
<pitti> apw: thanks
 * pitti is looking forward to replying to the "But LP isn't open source" with ".. but it is!" :-)
 * ogra wonders why heise hasnt picked it up at all
<ogra> slackers ...
<apw> pitti, is there a bug for that?
<bryce> pitti, "But it must not be 100% opensource.  You b@stards are hiding something I know it."
<pitti> apw: no, I just spotted it on http://people.canonical.com/~ubuntu-archive/testing/karmic_probs.html and wondered how it's meant to look like
<bryce> pitti, btw both mesa 7.5 and -intel 2.8.0 are now in.
<pitti> bryce: I saw, thanks!
<ogra> except on arm :P
<pitti> I'll wait until mesa, intel, pidgin have built and my NBS/ix components run got published, then rebuild CDs
<ogra> eeek, there was a fresh upload of mesa
<ogra> ah, but infinity turned down the timeout at least so it will fail after 3h and not block the buildd for 10h
 * bryce hates mesa builds
 * ogra hates lzma -dbg packages
<ogra> its not mesa itself ... its the compressing of the lzma stuff that doesnt work right on armel atm
<bryce> ahh
<apw> pitti, its a bug in the rename of the i386 server ... will sort it ... i'll make a bug on it
<ogra> we raised the buildd timeout to 10h and mesa still failed
<ogra> same goes for all of KDE
<bryce> ogra, is it something we could conditionalize for arm in our rules file?
<bryce> or just a general problem arm needs to sort out?
<ogra> we could, but i think it would be cleaner to do it more centralized
<bryce> ok
<ogra> instead of touching each and every package
<ogra> there are 40 (or so) KDE packages
<smb> pitti, does this workaround ring a bell to you (bug 387161)?
<ubottu> Launchpad bug 387161 in linux "Koala: External SATA->USB Drive no longer being identified properly" [Medium,Triaged] https://launchpad.net/bugs/387161
<amitk> pitti: I've got nautilus segfaulting all over the place. Is this a known problem?
<pitti> amitk: still with very latest ubuntuone-client from yesterday night? that should have fixed it
 * amitk wonders why apport isn't being triggered
<pitti> amitk: apport just got reenabled by default last night, too
<amitk> ok, I missed the changes from last night. upgrading now...
<pitti> smb: just a bell in the sense that I saw another report with the same symptom
<ogra> is it supposed to fix sftp in nautilus as well ?
<pitti> smb: I asked that guy for a devkit-disks debug output, but didn't get a response yet
<pitti> smb: I'll ask for that on this bug as well
<smb> pitti, Well I saw others that were affected by the change to read md-meta-data at the end of a full block device. But those usually got "no sense [current]" errors
<smb> pitti, Ok, sounds good to me
<pitti> smb: apparently dk-disks does something with resets the device
<pitti> and perhaps the log says where it crashes
<pitti> if the log doesn't help, I'll ask for an strace
<slytherin> pitti: FYI ... nautilus-sendto-universe (upstream nautilus-sendto) fails to build against latest empathy. Even 1.1.5 version fails. I have already logged a bug upstream http://bugzilla.gnome.org/show_bug.cgi?id=588302
<ubottu> Gnome bug 588302 in general "1.1.5 fails to build with latest empathy (2.27.x)" [Normal,Unconfirmed]
<pitti> slytherin: yeah, I saw; I just quickly tried to render it non-uninstallable
<pitti> slytherin: however, ideally this package would disappear at all, and being merged into nautilus-sendto, now that we have empathy in main
<slytherin> pitti: Right. Even in that case we will need to first solve the error. It should be fixable by modifying configure script. I just haven't got any time to try it.
<slytherin> pitti: My analysis is added in upstream bug.
<pitti> slytherin: many thanks
<seb128> slytherin, gnome bug #584716
<seb128> slytherin, it's fixed in git
<slytherin> pitti: One more thing. The package ships a upnp plugin as well and hence it can not just disappear.
<slytherin> seb128: let me check. I will port the change tonight.
<seb128> slytherin, ideally upstream would roll a tarball, I will try to get that
<slytherin> ok
<ubottu> Gnome bug 584716 in general "Use the new Empathy file transfer API" [Normal,Resolved: fixed] http://bugzilla.gnome.org/show_bug.cgi?id=584716
<pitti> slytherin: and we don't want that in nautilus-sendto proper?
<slytherin> pitti: the dependencies are not in main
<slytherin> seb128: In my opinion, it will still fail to build. empathy CFLAGS are not being set by configure script. Please correct me if I am wrong.
 * ogra sighs, gdm got so annoying
<foka> Hello!
<foka> Anyone experienced problems with RTL8111D LAN chip?
<seb128> slytherin, I'm busy on other things right now, I can have a look later if you want or try a git build
<slytherin> seb128: I will try git build and let you know.
<liw> hmm... spatial nautilus on karmic seems to forget size/position of folders
<liw> seb128, do you know if spatial nautilus on karmic forget size/position of folder windows is a known bug?
<liw> forgetting if I log out and back in
<seb128> liw, should be fixed with the gvfs update from yesterday
<seb128> if that's still an issue after session restart that's not known no
<liw> maybe my mirror is slow, I'll see what happens tomorrow
<seb128> liw, what version do you have?
<ogra> is there any way in new gdm to switch off the annoying userlist feature ?
<seb128> ogra, is there any way you could write clear questions? ;-)
<liw> seb128, nautilus 1:2.27.4-0ubuntu2, gvfs 1.3.2-0ubuntu4
<seb128> ogra, what annoying userlist?
<ogra> seb128, i would like to a) not have to wait 15 seconds until something is shown in the userlist and b) not have to touch my mouse to log in
<seb128> liw, and you restarted your session since the upgrade?
<liw> seb128, I rebooted, even
<seb128> ogra, a) is a ck-list-sessions issue
<seb128> liw, ok so not known bug
<ogra> seb128, i.e. u would like to have just a "username" field by default as it was in old gdm, something that doesnt force me to click
<liw> seb128, filing a bug, then
<seb128> ogra, b) just hit enter?
<liw> seb128, should I file it against gvfs or nautilus?
<seb128> liw, nautilus we can reassign later if required
<ogra> seb128, well, that indeed only works if the user list is up
<ogra> i'll wait for a) to be fixed and see if that works for me :)
<james_w> it's not easy to fix
<ogra> seb128, just to confirm, sftp in nautilus works fine again with todays upgrade
<seb128> ogra, good
<pitti> mvo_: do you know why dpkg's "Reading database" sometimes takes two minutes, and sometimes just half a second? in jaunty and earlier, it would consistently take some 3 seconds
<seb128> pitti, mvo_: I noticed that too on both my laptop and desktop configs
<james_w> just uploaded a logrotate file for ck, which should at least keep the time to the userlist bounded
<james_w> still large though
<lifeless> pitti: I've noticed it too; been on my list to strace
<ogra> notify-osd crashing with latest updates is known i assume ? (given a new version is just building)
<seb128> ogra, works there
<ogra> well, i had apport coming up after reboot
<seb128> ogra, the new version has no crash fix described in the changes
<seb128> use apport to send the bug?
<seb128> or wait for the update rather before
<ogra> hmm, funnily brightness and volume keys bring it up fine
<ogra> yeah, i'll wait for the update first
<mvo_> pitti: no, I need to have a look to figure that out
<pitti> mvo_: ah, so it's not a magical new "dpkg using xapian now" or so
<mvo_> pitti: not that I know of at least :) speaking of xapian, that is much faster when updating now
<Adlai`> oh man, if dpkg starts using xapian for searching, I'll be so relieved
<Adlai`> a while back, I wrote a python script to search it, but I don't know much xapian so it isn't very smart
<pitti> tkamppeter: we currently have a "Apps -> System Tools -> HPLJ 10xx Replaced Paper" entry in the main menu; can we please hide this?
<Adlai`> it sometimes comes up with interesting things but isn't very reliable
<mvo_> Adlai`: xapian is on the list of things to use more, there is some integration work being done with g-a-i and apt-xapian-index
<Adlai`> neato
<ScottK> pitti: re  libcompress-raw-zlib-perl, lool already pinged me on it and I'm working on it.  Unfortunately upstream combined 4 modules into one package in the new version so it's a non-trivial update.
<pitti> ah, but perhaps easier upgrades in the future
<tkamppeter> pitti, I thought already about removing it, it comes from upstream foo2zjs. I wanted to do it today, but then there was your mail about the Alpha 3 freeze.
<pitti> tkamppeter: that's fine, adding a NoDisplay to a .desktop file is not intrusive
<pitti> lifeless: hm, why does current bzr still default to pack-0.92?
<tkamppeter> pitti, OK, will do it this way.
<pitti> tkamppeter: thanks; just some desktop polish :)
<lifeless> pitti: changing the default forces an upgrade without warning on everyone making new projects
<lifeless> pitti: we are cautious about changing it; the next change is scheduled for 2.0
<pitti> lifeless: ah, I was just curious; I wondered by I still have to use --1.9 for bzr init, etc.
<lifeless> pitti: if you want the best format, use --2a, note that its a one-way upgrade from 1.9 to 2a
<lifeless> pitti: you might like to read the upgrading docs in trunk
<pitti> lifeless: does LP already get along with 2a?
<lifeless> yes
<lifeless> LP's code is in 2a format
<pitti> nice
<pitti> weird, a bzr upgrade --2a doesn't do anything here
<pitti> $ diff -Nur backup.bzr/ .bzr
<pitti> -Bazaar Working Tree Format 4 (bzr 0.15)
<pitti> +Bazaar Working Tree Format 6 (bzr 1.14)
<pitti> that's it
<pitti> lifeless: ^
<lifeless> pitti: you're in a shared repo I suspect
<lifeless> cd ..
<lifeless> bzr reconcile
<lifeless> bzr upgrade --2a
<lifeless> (and again, note that its a one-way conversion :))
<pitti> oh, indeed, that was from ages ago; thanks
<apw> pitti is there any way to validate a control file once its changed, to ask what it means to dpkg/apt ?
<pitti> apw: validate for what in particular?
<pitti> dpgk -I .deb will show the resulting record for a .deb
<apw> i am changing a Depends: and there seem to be some subtlies in how i might encode my new form and wondered if there was a way of saying "tell me what this means now i've written it"
<apw> in this case i have different deps for different arches
<apw> the docs imply that the [i386] syntax is not valid for Depends: so i am assuming i want to use an | on the two packages
<apw> but it would be nice to be able to tell in advance of uploading it, if it means what i think it means
<apw> (this is the virtual uninstallable thing)
<pitti> right, [i386] only works for build deps
<pitti> apw: lintian is pretty good in spotting such things
<apw> ahh will give that a spin
<pitti> Riddell, lool, cjwatson: anything from the KDE/mobile/platform front worth mentioning for alpha-3 on https://wiki.ubuntu.com/KarmicKoala/TechnicalOverview ?
<pitti> s/platform/foundations/ *blush*
<Riddell> from kubuntu: netbook and social from the start
<Riddell> I can add stuff in a minute
<pitti> Riddell: thanks (not urgent)
<ogra> hrm, i cant find where in the dpkg code the default value for -z is defined :/
<apw> pitti, i assume that this -virtual missmatch is not a blocker for the alpha-3 release
<pitti> apw: no, it's not; but I spotted it while reviewing the list
<ogra> ah, i guess its "  if(compression == NULL) compression= "9";" in lib/compression.c
<apw> pitti, thanks, will get it fixed for the next upload
<pitti> apw: so i386 is really meant to have a server kernel then?
<apw> no its been renamed to generic-pae, and virtual is meant to be made from that
<pitti> ah
<apw> so i need to dep on either -server or -generic-pae in meta
<apw> i assume that that will do the right thing
<pitti> yes, should
<pitti> I just wonder why it was renamed in the first place?
<apw> its not a server oriented kernel any more, its big memory oriented
<apw> its generic with pae enabled, rather than with pae enabled, the tick reduced, and the uo schedulers changed
<apw> it was deemed necessary to change the name as people kept saying 'but its not a server i shouldn't have to run a server kernel'
<apw> pitti, how is that uninstallable report generated?
<pitti> apw: some magic scripts which check satisfyability of dependencies of all packages in main
<lool> pitti: No, not really: no new UNR, and ARM stuff is still in flux
<apw> so the best way to test is to try and install the packages in a chroot
<apw> as presumably they fail to install
<pitti> lool: ah, thanks
<pitti> apw: probably some dependency which is either missing or in universe, or a Conflicts:
<AnAnt> Hello, regarding bug LP 401816, which is the better path ? apply the patch that Debian applied in the new upstream ? or merge with Debian's package for new upstream release ?
<ubottu> Launchpad bug 401816 in guile-1.8 "Conflicting types for 'jmp_buf' " [Unknown,Fix released] https://launchpad.net/bugs/401816
<Company> what's the right channel to poke the Ubuntu X crew?
<seb128> Company, #ubuntu-x
<AnAnt> guile-1.8 is in main, right ?
<Laney> AnAnt: LP knows
<Laney> and I'd merge the new release at this point unless there's a reason not to
<AnAnt> well, I don't know a reason not to
<AnAnt> except maybe, that there could be many apps depending on guile, so I dunno if upgrading to new upstream would break lots of apps
<AnAnt> ah, it's in main
<directhex> what uses guile?
<directhex> i was reading some stuff into its history...
<Laney> you've got gall, you've got guile
<Laney> to step to me, i'm a rapophile
 * directhex mails Laney to yankland to fill in for MCA with the beastie boys
<Laney> I think I'd fit like hand in glove
<directhex> yay, mdz made it into an itwire hit piece. i wonder if there's a club
<Laney> you should make a launchpad group
<Laney> you could have a mailing list and everything
<directhex> i wonder if i could get joss to join it
<mdz> directhex, misspelled even
<directhex> Laney, it looks like a team is the correct format
<directhex> Laney, judging by the we-love-pitti team
<Laney> for sure
<maxb> So, there's just been a 'fix' to LP 391190 uploaded...
<ubottu> Launchpad bug 391190 in notify-osd "Font size is too large by default" [Medium,Fix released] https://launchpad.net/bugs/391190
<maxb> What should I do now, reopen it and retitle it "Font size is too small by default" ?
<directhex> mdz, i wouldn't let it get you down. now you're as famous as me, these kinds of articles are inevitable
<\sh> what is "helios"?
<\sh> it eats more of my cpu time then X which is strange ;)
<Keybuk> \sh: screensaver?
<ogra> its a screensaver
<\sh> oh god
<ogra> bah, Keybuk beats me
<\sh> ok killed.
<\sh> and now I wonder what hammers on my HD at least 2 times per second
<AnAnt> Keybuk: is there KMS support for NVIDIA yet ?
<slytherin> AnAnt: Not yet. Onlt intel and ati.
<slytherin> AnAnt: The support is supposedly planned foe kernel version post 2.6.31.
<AnAnt> ah, not in karmic then
<slytherin> right.
<slytherin> AnAnt: you can use Debian unstable to get latest of everything. :-)
<AnAnt> slytherin: I won't get the kernel from thre !
<AnAnt> I wont dare
<slytherin> AnAnt: Why not?
<AnAnt> slytherin: because  I won't dare, besides, I don't think Ubuntu syncs/merges kernel packaging with Debian
<slytherin> AnAnt: I mean run Debian unstable on your machine, not pick up kernel from Debian unstable.
<AnAnt> oh
<AnAnt> slytherin: just to try KMS ?
<ogra> slytherin, oh debian already has a kernel newer than .31 ? wow :P
<slytherin> ogra: No. They don't have it. But they will have earlier than Ubuntu is my guess.
<slytherin> Or rather my hope
<ogra> heh, that i doubt very much
<ogra> slytherin, you know that the kernel team maintains a PPA that tracks upstream ?
<slytherin> ogra: I know. I am going to try .31-rc3 ib jaunty tonight. :-)
<ogra> :)
<slytherin> These days actually Debian 'experimental' is new Debian 'unstable'.
<Laney> how do I get KMS then if I have ATI?
<slytherin> Laney: karmic is supposed to have KMS for ATI as well. :-) The kernel support is already there. I am not sure about X stuff.
<Laney> do I have to do anything to enable it though?
<Sarvatt> you can use KMS on nvidia right now in karmic, sudo apt-get install xserver-xorg-video-nouveau :)
<AnAnt> slytherin: btw, did you mean the free NVIDIA or non-free ?
 * Laney is using -ati though
<slytherin> AnAnt: I am not having any hope with non-free.
<AnAnt> slytherin: why's that ?
<AnAnt> slytherin: I use non-free, because the colors looked better than the free nv module
<slytherin> Laney: I believe not. But it is better to ask kernel developers.
<Sarvatt> you need alot of userspace for it Laney, cant use it in karmic now
<Laney> maybe when I'm back and actually on my Ubuntu machine...
<Sarvatt> https://edge.launchpad.net/~xorg-edgers/+archive/ppa
<Sarvatt> it needs libdrm-radeon1 plus mesa 7.6 and a newer ati ddx than karmic's
<slytherin> AnAnt: Because you are at the mercy of nvidia.
<AnAnt> slytherin: ok, you're right about this, that's problem with non-free generally
<AnAnt> oh, nouveau is something different than nv !
<AnAnt> that deserves a try indeed !
<Sarvatt> yep, and its got KMS
<Sarvatt> but no 3D to speak of :)
<AnAnt> Sarvatt: 3D as in compiz stuff ?
<Sarvatt> no DRI at all
<AnAnt> erm, what's DRI ?
<ogra> direct rendering interface
<AnAnt> is that the thing that compiz needs ?
<AnAnt> I don't use compiz anyways
<Sarvatt> yeah compiz is 3D only, you can use metacity compositing fine though since its xrender based
<Sarvatt> to use KMS with the nouveau package in karmic you'll need to add options nouveau modeset=1 to /etc/modprobe.d/nouveau.conf
<AnAnt> ok
<AnAnt> thanks
<AnAnt> I should try that in Alpha3
<Sarvatt> http://sarvatt.com/downloads/nouveau-kms.txt
<Sarvatt> theres "some" 3d support if you compile mesa yourself and enable gallium, doesnt run anything more than glxgears and glxinfo here though :D
<directhex> mdz, did you intentionally bump the timestamp on your old backlash blog post? it's a the top of planet again
<mdz> directhex, no, not intentionally.  I had to twiddle the comment flag to link to Sam's article
<mdz> directhex, I've also had that happen when I add a category to an old post.  do you know any way to fix or avoid it?
<directhex> mdz, no, sorry. of course, i have access to the mysql backing the blog, so i can hax it if need be in my own case
<mdz> my apologies to planet, then. :-/
<AnAnt> directhex: I dunno how many packages uses guile,
<directhex> mdz, doesn't bug me, i was just curious
<directhex> mdz, this ain't #debian-devel, no angry rebukes on the horizon
<mdz> directhex, thanks for letting me know.  I've added a post to ask if anyone knows how to avoid the problem in the future
<maxb> What is the criteria for being unmoderated on ubuntu-devel@ ? Must you be a MOTU at minimum or can an ordinary user like me request to be considered for unmoderated access after posting responsibly to the list for a while?
<AnAnt> directhex: in jaunty, I see about 40 packages depending on guile-1.8-libs
<directhex> AnAnt, fewer than tcl. interesting.
<AnAnt> directhex: including autogen
<directhex> AnAnt, that doesn't surprise me
<AnAnt> so, what do you think, merge with Debian's new upstream or just apply the patch ?
<mdz> maxb, anyone can be whitelisted if they consistently post on-topic
<maxb> Should I just be patient and someone will notice eventually, or should I ask someone to whitelist me?
<pitti> AnAnt: if you test the new upstream, a merge would still be better at this point IMHO (just dn't break alpha-3, or postpone the upload after a3)
<AnAnt> ok
<AnAnt> I'll wait till next week then
<subzero> hi at all
<lool> How does one dump the macros cpp expands by default?
<subzero> i don't know
<lool> touch foo.h; cpp -dM foo.h
<lool> Was in man gcc not cpp
<ogra> heh
<ogra> yay for well placed documentaion
<lool> actually it's in man cpp too
<slytherin> Currently jaunty doesn't identify full HD mode on my external monitor (LCD TV actually). Is KMS expected to resolve that problem in some way?
<pitti> slytherin: give the live CD a try?
<pitti> slytherin: (supposed, yes; no idea whether it's working on your machine)
<slytherin> pitti: I can't. Its a powerpc machine. :-)
<directhex> slytherin, what resolution is the TV?
<ogra> it didnt work on my external monitor, but its over a week ago that i tried last
<slytherin> directhex: you mean size? 32"
<directhex> slytherin, most 32" sets i'm aware of have a resolution of 1366x768, and invalid EDID data preventing proper automatic modesetting. and IME most sets smaller than 37" can only do 1080i, not 1080p
<ogra> your info is quite outdated :)
<ogra> most 32" ones nowadays can do 1080p
<slytherin> The TV specification says it has 1080p support.
<directhex> i'm gettnig old, then :(
<ogra> no its moving very fast :)
<directhex> slytherin, support doesn't neccessarily mean "without some scaling, cough"
<directhex> ogra, i spent Â£650 on my 26" set!
<ogra> ugh
<ogra> when ?
<directhex> ogra, about 3 years ago i think
<directhex> i could do with something a bit bigger. the furniture has room for a 37-42" depending on the size of the bezel
<ogra> yeah, my 37" set i just gave to my sister costed about â¬1000 four years ago
<directhex> and lord knows i enjoy gaming on a big HD telly
<ogra> the 42" one i got recently and is aeons better only was â¬699
<slytherin> directhex: Dell sells 24" monitors that support 1080p. So I suppose 32" should have no problem.
<highvoltage> I can't see very far so my brain upscales everything quite nicely, I don't need HD :p
<directhex> slytherin, oh, monitors have done it for YEARS. i had housemates with 1600x1200 on laptops in 2002
<slytherin> didn't know that.
<highvoltage> directhex: but 1080p is 1920x1080, so 1600x1200 wouldn't be able to display full HD.
<slytherin> anyway, currently nothing higher than 1024x768 is detected. I hope that improves in karmic. As I am going to turn my PC into media center and permanently attach it to the TV.
<directhex> highvoltage, this is pre-widescreen days.
<highvoltage> directhex: oh wow, ok.
<directhex> slytherin, is it connected via VGA?
<directhex> slytherin, 1024x768 on an lcd tv sounds EXACTLY like bad EDID to me
<slytherin> directhex: yes. And bad EDID is what came to my mind as well.
<directhex> slytherin, which driver?
<slytherin> directhex: ati (free one), card 9200.
<blackxored> hello everybody? anyone from cuba here?
<directhex> slytherin, very recent nvidia-glx appears to contain workarounds for bad EDID - i updated from intrepid to jaunty, and i got 1366x768 via VGA despite the bad EDID
<directhex> slytherin, alternatively, one can hax it with a custom modeline
<blackxored> I'm not silly, I'm just gpg-coordinating anyone
<directhex> blackxored, unless the internets got a hell of a lot faster & cheaper in the past 2 years, i doubt it
<blackxored> directhex, sad to hear, in #debian-devel is no one either, seems like I'm the only god damn cuban who wants to become a debian/ubuntu devel
<blackxored> a technical question, yeah I know RTFM, but for ubuntu applying as a dev is necessary to pgp sign as in debian?
<directhex> blackxored, you're the only god damn cuban i've ever encountered on the internets at large, so i admit to not being totally surprised
<blackxored> directhex, ;)
<directhex> blackxored, no, a signed gpg key is not needed for ubuntu - merely a key with 0 or more sigs
<slytherin> directhex: my ibook has jaunty already.
 * directhex wonders where blackxored is based
<directhex> slytherin, oh, it's a laptop? that complicates matters
<blackxored> directhex, so I can apply for ubuntu-motu??
<directhex> slytherin, basically, it's broken info burnt into the tv, and only workarounds can fix it
<directhex> blackxored, if you have a demonstrable log of contribution, you can apply for ubuntu-motu
<blackxored> I've packaged swt-gtk for debian (is in testing now), and I'm working in azureus, any clues?
<directhex> blackxored, and if you don't have a demonstrable log of contribution, then just contribute some more, and you WILL have
<blackxored> directhex, fine then
<slytherin> directhex: hmm. I have tried modelines in past for a friend. I can try that again my my TV. Sadly the TV specification is non-existent in regards to what the refresh rates should be for different resolutions.
<directhex> blackxored, sounds like the java team would be a good place for you to be?
<directhex> slytherin, a model of TV would be useful
<blackxored> directhex, probably since I develop in java, but I also do it in python and ruby, so nevermind, I'm interested in both projects as a whole, I use ubuntu on my workstations and debian in our servers (I'm leeking info here...) :D
<blackxored> I've actually try to do my best to see an updated eclipse in debian, since it's orphaned by now
<slytherin> directhex: http://www.videoconworld.com/products/lcd/index.php First one in the list
<directhex> blackxored, that's a big project. i'd suggest talking to someone javaish..... now if only slytherin were here...
<blackxored> blackxored, no, I've just to contribute to it, not maintain man, eclipse is *huge*
<slytherin> blackxored: you can try fixing current eclipse package in karmic. :-)
<slytherin> anyway, eclipse is in universe. So move to #ubuntu-motu for further discussion. :-)
<blackxored> slytherin, I'm working in azureus by now
<directhex> slytherin, do you have access to a machine connected to that TV right now? or should we re-discuss this evening?
<slytherin> directhex: We should discuss it later.
<slytherin> blackxored: ahh, I didn't recognize you.
<directhex> okay
<directhex> slytherin, i've spent far too much time on mythtv issues, so i have experience with this crap
<blackxored> slytherin, "eclipse is in universe" => apt-cache policy eclipse => 3.2.2-5ubuntu3
<blackxored> slytherin, current upstream: 3.5
<slytherin> blackxored: Ubuntu karmic has 3.4. But it needs lot of cleaning.
<slytherin> Once we are done with cleaning it, it should not be very hard to update it.
<blackxored> slytherin, ok, there's so any chance I could provide some help when I finish with azureus?
<slytherin> blackxored: I will let you know.
<blackxored> slytherin, ok sorry about the retrospective , but what you meant with "I didn't recognized you"?
<slytherin> blackxored: As in I didn't first know that you were 'Adrian Perez'. I already know that you are working on swt-gtk, azereus and will probably work on eclipse.
<blackxored> slytherin, ah right, you know a lot about me ;) anyways, thanks for your time, I has been useful talking this bit, back to work
<blackxored> people BTW I've used a pbuilder setup for package building for a long time, there's any way I could turn it into a schroot env and test some X apps with it, any clues?
<Sarvatt> blackxored: you can use your current xserver to run x apps in there with a ton of screwing around, but you cant run x in a chroot directly as far as I know right now
<Sarvatt> just set up virtualbox or something if you want that :)
<blackxored> Sarvatt, I got some guidance in #debian-devel thanks a lot
<Riddell> Ampelbein: what's going on with mjpegtools and bug 351017 ?
<ubottu> Launchpad bug 351017 in mjpegtools "[SRU] mpeg2enc crashes with SIGILL on non-p4 architectures." [High,Confirmed] https://launchpad.net/bugs/351017
<Riddell> pitti set it to verification-failed last week, there's now an update waiting in the jaunty unapproved queue but I don't see any comment or new patch on the bug
<arand> Hello, I'm trying to push for an SRU of gnumeric (libgoffice) as described in https://bugs.launchpad.net/gnumeric/+bug/316502 Are there more (easy) steps that should be done there?
<ubott2> Ubuntu bug 316502 in gnumeric "cannot release a graph in gnumeric after click and drag" [Medium,Fix released]
<ubottu> Ubuntu bug 316502 in gnumeric "cannot release a graph in gnumeric after click and drag" [Medium,Fix released]
<liw> hmm. debdelta requires exact original file to exist, but it that is lost, we _could_ use dpkg-repack to reconstruct something close to the original, then use zsync to update to the exact original, then use debdelta to update that to the new version of the pacakge... slightly complicated, but doable
<Riddell> arand: create a debdiff if you know how, else poke someone on the ubuntu desktop team to do it
<arand> Riddell: No not completely sure on that, so that would be #ubuntu-desktop then?
<Riddell> arand: yes
<Keybuk> mvo_: is there a way to have a command run after packages are installed?
<pitti> Keybuk: in the user session or as root?
<pitti> (user -> interactive upgrade hook; root -> package trigger?)
<Keybuk> root is fine
<Keybuk> after any package is installed
<pitti> oh
 * pitti defers to mvo then, sorry
<Keybuk> though it's ok if it's just if any package is installed via apt
<Keybuk> basically want to catch upgrades
<james_w> "trigger /" ?
<liw> Keybuk, what is the actual problem you're solving?
<pitti> install a trigger with interest on /usr? :-)
<pitti> james_w: hah
<Keybuk> liw: wiping the old sreadahead pack on an upgrade so it's regenerated
<liw> I believe apt has some hooks you could install into /etc/apt
<liw> hmm, Apt::Post-Invoke or something perhaps
<liw> er, Dpkg::Post-Invoke
<liw> I can never remember apt config syntax
<liw> there's no Dpkg::Post-Install-Pkgs though
<mat_t> jamesh: ping
<Riddell> geser: you uploaded a bunch of zope packages to karmic?  they don't seem to have the ZPL included
<Riddell> geser: I'll accept them because they're already in debian but it would be best to get that fixed
<geser> Riddell: you mean in the .orig.tar.gz?
<Riddell> geser: yes
<geser> Riddell: did it change in Debian in the last time? because that's the next package which is missing a license in the .orig.tar.gz in Debian
<pitti> if they are already in Debian, why not just sync instead?
<geser> pitti: I'd have done it, if it didn't need patching to build with python 2.6
<pitti> aah
<geser> but I already got also a synced package from Debian rejected because the license text was missing in .orig.tar.gz
<Riddell> geser: nothing has changed in debian that I can see
<mvo_> Keybuk: you can use "DPkg::Post-Invoke"  and hook commands into that, see update-notifier as a example (it touches a file :)
<geser> doesn't Debian have that license text requirement in .orig.tar.gz? or aren't they as strict as Debian?
<Riddell> geser: they should but as with us it probably depends on the archive admin of the day and what sort of a mood he's in
<mvo_> Keybuk: registering a handler here should be a short action though, the UI waits without proper progress to the user during the post-invoke handler
<Keybuk> mvo_: in this case, it's rm'ing a file
<mvo_> that should be fine I guess
<geser> Riddell: it just curious that I stumbled upon this twice in the last few syncs/uploads. I'll contact the Debian maintainer about it.
<mvo_> (unless the file is huge?)
<liw> mvo_, does DPkg::Post-Invoke get run after each invocation of dpkg?
<Keybuk> mvo_: not especially
<mvo_> liw: no, the name is misleading - just when its finished (or errored out)
<Keybuk> mvo_: its maximum size is probably 7MB
<liw> mvo, ok; then some documentation should probably say that :)
<Artur25> Hello.
<Artur25> Did somebody compile alsa kernel recently?
<Riddell> ttx: how is netty-3.1.0.CR1.jar built?
<ttx> Riddell: using debian/build.xml
<ttx> Riddell: compiles files, excludes a few optional features, JARs them all.
<Riddell> ttx: why is the binary jar included in the sources then?
<ttx> Riddell: the binary jar is not used. The source tarball is pristine from upstream.
<Riddell> ttx: ok thanks, I'll accept
<ttx> Riddell: thanks. More coming :)
 * ttx thinks java developers should learn that a source package is not their binary distribution with an added "src" directory.
<maco> pitti: question about the sudo package. i see the --with-secure-path= set in debian/OPTIONS but then twice again in debian/rules. is the one in debian/OPTIONS ignored?
<directhex> can ubuntu-archive unsubscribe from https://bugs.launchpad.net/ubuntu/+source/mono-tools/+bug/402152  plz? it completely slipped my mind that it needs xsp (universe) to build, so needs merging rather than syncing
<ubottu> Ubuntu bug 402152 in mono-tools "Sync mono-tools 2.4.2-1 (main) from Debian unstable (main)." [Wishlist,Confirmed]
<ubott2> Ubuntu bug 402152 in mono-tools "Sync mono-tools 2.4.2-1 (main) from Debian unstable (main)." [Wishlist,Confirmed]
<StevenK> directhex: Done
<directhex> StevenK, ta. i'll work on the merge this evening
<ogra> infinity, did you do anything to the armel builders ?
<ogra> infinity, i dont get http://launchpadlibrarian.net/29325128/buildlog_ubuntu-karmic-armel.mesa_7.5-1ubuntu1_FULLYBUILT.txt.gz ...
<ogra> infinity, why did it build now ?
<infinity> ogra: I did nothing...
<ogra> hrm
<ogra> infinity, though http://launchpadlibrarian.net/29325326/buildlog_ubuntu-karmic-armel.qt4-x11_4.5.2-0ubuntu2_FAILEDTOBUILD.txt.gz
<ogra> (we're just discussing in #ubuntu-arm)
<bdmurray> pitti: Is calibre working for you?  bug 402040
<ubott2> Launchpad bug 402040 in calibre "calibre crashed with ImportError in <module>()" [Undecided,Confirmed] https://launchpad.net/bugs/402040
<ubottu> Launchpad bug 402040 in calibre "calibre crashed with ImportError in <module>()" [Undecided,Confirmed] https://launchpad.net/bugs/402040
<ubott2> Ubuntu bug 402040 in calibre "calibre crashed with ImportError in <module>()" [Undecided,Confirmed]
<ubottu> Ubuntu bug 402040 in calibre "calibre crashed with ImportError in <module>()" [Undecided,Confirmed]
<ubott2> Launchpad bug 402040 in calibre "calibre crashed with ImportError in <module>()" [Undecided,Confirmed] https://launchpad.net/bugs/402040
<ubottu> Launchpad bug 402040 in calibre "calibre crashed with ImportError in <module>()" [Undecided,Confirmed] https://launchpad.net/bugs/402040
<StevenK> Argh, here too
<infinity> ogra: Hrm.  This throws everything off a bit, though.  People claimed this was "an lzma issue", but that build log is just a massive C++ link.
<infinity> ogra: Probably just a memory churn issue...
<ogra> infinity, yeah, we had probs before with upstart that looked similar
<ogra> upstart has a testsuite where one file is really really huge
<ogra> it had the same error (with gcc, not g++ though)
<infinity> Well, hard to call it the "same error", since there isn't an error.
<ogra> well, same output :)
<infinity> (or lack thereof)
<infinity> sbuild isn't all that smart on how it does this.  It just watches the log.  150 minutes with nothing to stdout, it kills everything.
<infinity> So, yeah.  PROBABLY just massive memory churn on that C++ link (and maybe the old 600 minute timeout would have helped for this), but maybe it's actually hanging.
<ogra> ogra@osiris:~/Devel/packages/upstart-0.6.1$ ls -lh nih-dbus-tool/tests/expected/test_output_proxy_standard.c
<ogra> -rw-r--r-- 1 ogra ogra 115K 2009-07-02 18:22 nih-dbus-tool/tests/expected/test_output_proxy_standard.c
<ogra> that was the test the upstart build died on
<infinity> Yeah.
<infinity> I'm just wary of saying "Oh, it's just slow hardware"...
<ogra> can we throw more swap in to help here ?
<infinity> Since I'm sure that QT wasn't borderline 145 minutes to link in previous versions, and "just got a bit worse recently", y'know?
<ogra> and bump swappiness up
<infinity> So, there's probably some underlying issue here.
<Keybuk> I think it's a compiler issue
<ogra> since we always only saw it dying in dpkg-deb the suspicion was that the newer dpkg brought it in
<ogra> i'm just doing a mesa build locally (since 5h) with rolled back dpkg
<ogra> to see how long dpkg-deb actually takes
<ogra> but now seeing g++ hang is somewhat pointing to a system issue
<ogra> more than a SW issue
<infinity> Well, technically that line would be calling binutils, not gcc...
<infinity> I think.
<infinity> Unless I just need morning caffiene.
<Keybuk> dunno, in the Upstart case it seems that gcc is what hangs around
<ogra> yes
<Keybuk> compiling godot.c or something
<ogra> i think it was test_output_proxy_standard.c
<infinity> Could wait a while for that one.
<infinity> *rimshot*
<infinity> Anyhow...
<Keybuk> ogra: those files aren't compield
<ogra> they were
<ogra> at least in the log i saw
<Keybuk> ogra: bet you $ 1,000,000 ?
<ogra> nah, ho am i to argue with upstream :P
<Keybuk> it was stalling on nih-dbus-tool/tests/test_node.c before
<ogra> oh, right
<ogra> but there it died reproducable on the buildd
<ogra> i gave it back and got exactly the same in the second round
 * infinity fears a hunch...
<infinity> Oh, phew.  No, hunch averted.
<Keybuk> what was your hunch?
<infinity> Keybuk: The base system on two of the armel machines is still Debian/lenny.  Was mildly concerned that might be an issue.
<infinity> Keybuk: But, the recently (and mysteriously) successful mesa build was on a lenny machine.
<mat_t> ArneGoetje: ping
<ogra> we should really run jaunty there :P
<ArneGoetje> mat_t: pong
<infinity> ogra: All the other armel machines were sidegraded to jaunty, just two never got done.
<infinity> ogra: And by the time iwas getting around to doing them, people were telling me I was throwing that hardware away in favour of qemu, or newer v7 kit, so...
<mat_t> ArneGoetje: I'm trying to get hold of jamesh regarding the font installer, but no luck so far... is he around at all?
<ogra> infinity, newer v7 kit shoul be there soon
<ogra> but that will need testing etc
<ogra> so we still need somehow fix the issue
<ogra> or identify ...
<infinity> Yeah.  I'm all for fixing it, it's the indentify part...
<ogra> heh
<cody-somerville> pitti, I'm not going to patch gdm to launch x-window-manager instead of metacity for now because of an unrelated xfwm4 issue but I'm doing a test build with the other changes and will push ASAP
<pitti> cody-somerville: so you'll keep metacity for now? or do without a WM?
<cody-somerville> pitti, do without a WM. It seems to work fine.
<pitti> cody-somerville: it somewhat does work without any WM, just looks weird if yo invoke the a11y menu (no window decorations, etc)
 * cody-somerville nods.
<pitti> cody-somerville: but for a3 that's certainly good enough
<cody-somerville> pitti, Steve accepted this issue for a2
<pitti> cody-somerville: right, but since that's released, I moved it to a3
<cody-somerville> doh
<cody-somerville> I misread the schedule
<cody-somerville> I thought alpha-2 was upcoming
<pitti> it's that late already :)
<ArneGoetje> mat_t: I don't know
<maco> pitti: the a11y stuff will work without window decorations?
<pitti> maco: I'm not sure, I didn't actually try the a11y functionality
<maco> it cant find any windows by name if i use a tiling wm. i assumed because it doesnt have titlebars
<maco> ah
<pitti> right, that would be an issue
<maco> by the way, you werent around when i asked before, but you're all over the changelog... in sudo, the --with-secure-path, does that need to be set in debian/rules twice (ldap and build-simple) aside from debian/OPTIONS to make it affect the sudo binary?
<pitti> maco: I don't know right now, I'd need to have an intense look at the package (sorry, I'm in a meeting right now)
<maco> ok
<pitti> bryce: what do you think would make more sense for users, nouveau by default, or KMSified nouveau as opt-in?
<pitti> bryce: (given that nv by default is pretty much the worst option)
<bryce> pitti, my thinking is that KMSified nouveau as opt in makes the most sense, since it enables users wishing to use it the option of using it but we don't force it on them in case it is unstable
<bryce> unfortunately I've learned there are still many cards not supported by -nouveau which are supported by -nv
<bryce> even aside from KMS (which is also even more limited in the range of cards it supports)
<pitti> bryce: well, FSVO "supported" :)
<bryce> FSVO == For Some Version Of ?
<pitti> "value"
<billybigrigger> is anyone else's appearance broken?
<billybigrigger> i can't seem to switch gtk themes
<billybigrigger> i can switch them in system/appearance, and the preview in appearance works, but then when i close it, gtk is not updated
<directhex> there are times when update-maintainer feels silly
<directhex> maintainer: ubuntu core developers. WRONG! THAT IS A LIE!
<maco> i thought it was supposed to say Ubuntu Developers
<directhex> meh, whatever the script changes it to
<directhex> point is, sometimes the original-maintainer is more true
<maco> scottk said if he's the debian maintainer, he just leaves it in
<directhex> i wonder what would happen if dh_installxsp were moved to cli-common-dev
<directhex> it would save the need for damn merges
<directhex> man, it's ages since i did a merge bug
<smb> Someone around who might help me with a question on v4l in Jaunty?
<billybigrigger> smb?
<smb> Basically its about someone having problems with a gspca driven webcam and cheese, camorama ... because gspca in Jaunty is v4l2 and the apps are v4l1. Now I thought those would get shipped with the compat lib linked in...
<smb> bug 352765
<ubottu> Launchpad bug 352765 in linux "Logitech webcam doesn't work (v4l2 support needed)" [Medium,Confirmed] https://launchpad.net/bugs/352765
<veritos> Is it planned to attempt to push the new notification system upstream?
<bjf> I'm running Karmic, updated from a Jaunty install. When installing "makedumpfile" it got to "Found kernel: /boot/memtest86+.bin"
<bjf> and then it just sits. After about an hour I aborted and tried to install another package. Now I get "E: dpkg was interrupted,
<bjf> you must manually run 'sudo dpkg --configure -a' to correct the problem." When I run it, it "hangs" at the same point.
<bjf> How do I fix this mess up?
<cody-somerville> pitti, updated branch
<pitti> cody-somerville: thanks! what was the name again?
<billybigrigger> smb, i have the same problem
<cody-somerville> https://wiki.ubuntu.com/ARM/BuildEABIChroot
<cody-somerville> ooops
<cody-somerville> paste error
<cody-somerville> pitti, lp:~cody-somerville/gdm/depend-on-minimal-gnome-session
<billybigrigger> smb, but the thing is my cam used to work on .30 kernel
<billybigrigger> since .31 it hasn't
<superm1> cody-somerville, how do you set the default session to come up as !gnome-session after that patch is in gdm?
<smb> billybigrigger, Then you would also be able to use your cam with the v4lcompat library preloaded?
<billybigrigger> which lib is this?
<cody-somerville> superm1, it'll occur automatically
<smb> If you look into the bug I posted, there is a description on it
<cody-somerville> superm1, or maybe it won't
<superm1> cody-somerville, well what session will be picked though?  does it need to be set in dmrc now?
<superm1> or does gdm-cdd.conf still do it?
<cody-somerville> no
<cody-somerville> default session can only be set via dmrc
<cody-somerville> as of now
<superm1> ugh, that feels, sounds, and smells hacky
<cody-somerville> oh it is
<cody-somerville> I'm not going to do anything with drmc just yet
<cody-somerville> I'm going to petition upstream to allow us to set it in the gdm config again
<bjf> dpkg --configure -a is hanging how can I work around it?
<superm1> cody-somerville, so what about in the interim for a3 though?
<mrec> Hi, is there still some development/bugfixing going on with Ubuntu 8.10?
<pitti> cody-somerville: we need to keep the gnome-session dependency; what would be an appropriate xubuntu alternative?
<mrec> http://article.gmane.org/gmane.linux.usb.general/15315/match=urb+leak
<cody-somerville> pitti, why do you need to keep the gnome-session dependency? Its incorrect.
<mrec> this USB bug affects ubuntu intrepid
<mrec> lets the system run out of memory after a while with some applications
<pitti> cody-somerville: for at-spi integration, gnome-seetings-daemon configuration, and such stuff
<ogra> bjf, take a look at /var/lib/dpkg/info/makedumpfile.postinst
<cody-somerville> pitti, at-spi should be a suggest like the other suggests I added
<pitti> ah, xfce-session
<cody-somerville> pitti, gnomne-settings-daemon should be a recommend like I had
<pitti> and above all, we need /usr/share/xsessions/gnome.desktop
<bjf> orgra, file doesn't exist
<pitti> but /etc/xdg/autostart/at-spi-registryd-wrapper.desktop and /etc/X11/Xsession.d/55gnome-session_gnomerc as well
<cody-somerville> This isn't how debian packaging is suppose to work. You don't add things as a depends because its convenient.
<ogra> bjf, then try sudo dpkg -r makedumpfile and try dpkg --configure -a again
<pitti> cody-somerville: ah, wait, we need to seed that anyway
<cody-somerville> IMHO you should be able to install gdm and not pull in anything but whats absolutely necessary for gdm to run
<cody-somerville> so things like at-spi integration should be suggests and seeded by ubuntu-meta (IMHO)
<pitti> cody-somerville: well, but gdm _is_ a gnome session itself
<bjf> ogra, same problem "dpkg --configure -a" stops after printing: Found kernel: /boot/memtest86+.bin"
<cody-somerville> pitti, not necessarily
<ogra> bjf, but the removal of mkdumpfile worked ?
<cody-somerville> pitti, It could very well be all xfce if I wrote my a chooser that didn't integrate so heavily with gnome stuff
<pitti> cody-somerville: anyway, it looks fair enough right now, so let's upload that to have good dailies tomorrow morning
<cody-somerville> pitti, thanks
<pitti> cody-somerville: that fixes bug 400901, right?
<ubottu> Launchpad bug 400901 in gdm "GDM depends on gnome-session in karmic" [Critical,Fix committed] https://launchpad.net/bugs/400901
<cody-somerville> pitti, if gdm no longer depends on gnome-session but gnome-session-bin, yes.
 * pitti adds bug to changelog
<pitti> that's the last (ATM) alpha-3 blocker
<seb128> pitti, what change do you upload?
<pitti> seb128: r62 in gdm bzr
<bjf> ogra, yes, the removal worked
<seb128> pitti, hum, k
<ogra> hmm, then your problem is not coming from that package at all
<pitti> @all, daily desktop/alternate Ubuntu images up for testing
<smb> ogra, bjf The message looks like something produced by update-grub
<ogra> yeah
<bjf> smb, ogra, the full message: Setting up initramfs-tools (0.92bubuntu38) ...
<bjf> update-initramfs: deferring update (trigger activated)
<bjf> Setting up kexec-tools (20090000-2.0.0ubuntu10) ...
<bjf> Searching for GRUB installation directory ... found: /boot/grub
<bjf> Searching for default file ... found: /boot/grub/default
<bjf> Testing for an existing GRUB menu.lst file ... found: /boot/grub/menu.lst
<bjf> Searching for splash image ... none found, skipping ...
<bjf> Found kernel: /boot/vmlinuz-2.6.31-3-generic
<bjf> Found kernel: /boot/vmlinuz-2.6.28-14-generic
<bjf> Found kernel: /boot/vmlinuz-2.6.28-11-generic
<bjf> Found kernel: /boot/memtest86+.bin
<ogra> kexec-tools ....
 * ogra wont say a thing about that 
<ogra> i had my say last release
<bjf> ogra, I'll just wait til A3 is available and redo my install, thanks for the help
<ogra> bjf, remove kexec-tools
 * smb missed that say from ogra. I assume kexec-tools wan't to add something there and get stuck
<ogra> smb, kexec-tools was fine until the merge from debian got overridden and someone decided to do a brandnew package instead of merging ... have a look at the version number
<bjf> ogra, that cleared it
<seb128> cody-somerville, pitti: those gdm suggests should be recommends
<cody-somerville> seb128, no they shouldn't be
<cody-somerville> seb128, If you want them in Ubuntu, seed them
<seb128> cody-somerville, no
<cody-somerville> yes
<cody-somerville> :)
<seb128> cody-somerville, as said the other day apt-get install gdm should give a full functional gdm version
<seb128> cody-somerville, yeah, that behaviour is very useful ...
<cody-somerville> seb128, Thats not the Debian way of doing things.
<seb128> cody-somerville, I'm going to change it to a recommends, want to play change and upload game now?
<cody-somerville> seb128, I'm at a great disadvantage when it comes to that game
<seb128> so you should try some try to argue in a convincing way
<cody-somerville> seb128, I intend to, one sec
<mterry> pitti, So let's say I wanted to push a new ubiquity (to fix an issue that makes oem-config unusable), how do I do that in a freeze-friendly way?
<seb128> recommends are things which should be installed by default when you want a complete experience of the software
<seb128> and gdm lacks power management without gpm for example
<seb128> same without the other tools you get no accessibility
<cody-somerville> seb128, "Suggests is used to declare that one package may be more useful with one or more others. Using this field tells the packaging system and the user that the listed packages are related to this one and can perhaps enhance its usefulness, but that installing this one without them is perfectly reasonable. "
<seb128> which means an user installing gdm will get no power manager nor a11y working
<seb128> it's not perfectly reasonable to have no accessibility and power management by default
<cody-somerville> seb128, yes it is
<seb128> you say that because you don't need accessiblity for example
<seb128> you don't do a favor to your users though
<cody-somerville> seb128, Its reasonable to find an installation without those things
<cody-somerville> seb128, Which is why they should be a suggests
<cody-somerville> seb128, and then they should be seeded by the ubuntu seeds
<seb128> right, which is why you can remove recommends
<cody-somerville> seb128, yes but I can't remove recommends via seeds
<seb128> well that's orthogonal
<cody-somerville> not at all
<seb128> add | xubuntu depends if you want
<cody-somerville> No, thats not correct
<seb128> but don't break the gdm recommends only to please derivatives
<seb128> well find a better way
<seb128> but you are not going to break gdm recommends
<cody-somerville> This is the correct way
<seb128> I will upload a fixed version tomorrow
<seb128> no it's not
<seb128> read the debian policy about recommends
<cody-somerville> seb128, I have
<seb128> cody-somerville, well then you argue than power manager and accessibility are important to our users
<seb128> +not
<cody-somerville> seb128, I agree they're important
<cody-somerville> seb128, Which is why they should be seeded
<seb128> no you don't
<seb128> if they are important they should be recommends
<seb128> seed is an ubuntu concept not a debian one
<seb128> the policy doesn't take those in consideration
<seb128> recommends are what a luser should get installed when doing an apt-get on a base install
<seb128> ie what you would expect from a standard experiencez
<cody-somerville> seb128, gpm, at-spi are extras
<seb128> accessibility is not extra
<cody-somerville> seb128, gdm just happens to ship with a default set of desktop files that launch those
<seb128> without it you have a class of users who can't use your system at all
<cody-somerville> seb128, They're not a dependency in any such way for gdm to run
<seb128> they are for it to be usuable for a class of users
<seb128> and recommends are not meant to be depends
<seb128> but to describe things you likely want when you don't know what you are doing
<cody-somerville> seb128, They're suppose to indicate a strong but not absolute dependency
<cody-somerville> seb128, Thats incorrect
<seb128> ok, let's stop that and say we disagree
<cody-somerville> seb128, Recommends declare "a strong, but not absolute, dependency.
<seb128> no luck for you don't have upload rights to do your changes
<seb128> right
<seb128> and having accessibility is a strong recommendation by default
<seb128> and having a way to suspend your computer too
<cody-somerville> ugh...
<seb128> want to try suggesting dropping those from the default install if they are of no use?
<seb128> recommends are the equivalent of the seed, ie things we recommend installing by default
<cody-somerville> seb128, You're clearly being difficult on purpose. This change will only help Xubuntu and not affect Ubuntu in anyway since you seed the packages anyway.
<seb128> if you get those unseeded I'm fine having them not recommended
<cody-somerville> s/Xubuntu/<insert other gtk derivative here>/
<seb128> well that's not because we have seeds that we should randomly misuse and break recommends and depends
<cody-somerville> seb128, No, you're the only thats misusing the relationship fields
<seb128> that's not a misuse
<seb128> recommends are things that an apt-get install should install as said before
<seb128> ie what lusers should get installed to have every feature working
<seb128> and that power user can uninstall because they are not hard depends
<seb128> that's how they are meant to be used and how they are used for years
<cody-somerville> Shipping an autostart desktop file for an application does not mean that application's package should be a recommend, sorry... I just don't buy it.
<seb128> the idea is that a lambda user should not have to know that gnome-power-manager need to be installed to have suspend working
<seb128> but that if you don't care about it you can uninstall it
<seb128> it's not because it has an autostart
<seb128> it's because an useful feature which has a button in the UI relies on it
<cody-somerville> seb128, no, an application that gdm launches depends on it
<seb128> no
<cody-somerville> yes
<seb128> did you use gdm at all?
<cody-somerville> yes, I have
<cody-somerville> and there is an autostart file for the chooser
<cody-somerville> and the chooser is just a gtk application
<seb128> the user list has 3 buttons by default
<cody-somerville> seb128, right-o
<cody-somerville> seb128, Okay, I can buy gpm being a recommend
<seb128> "suspend hibernate restart"
<seb128> and the first 2 don't work without gnome-power-manager
<cody-somerville> fine, I can agree to g-p-m being moved to recommends
<seb128> good
<cody-somerville> but the other stuff should be suggests, agreed?
<seb128> I will have TheMuso or somebody testing if the banner is accessible without the other tools
<seb128> cody-somerville, if that makes the login screen not accessible no
<seb128> cody-somerville, you just make impossible for a class of user to use your software
<cody-somerville> seb128, which is why they should be a suggest and why you should seed
<seb128> cody-somerville, still that defeat the purpose of recommends, which is to provide a good user experience for people not using seeds
<cody-somerville> seb128, we don't include a screen reader in ubuntu-standard do we?
<cody-somerville> seb128, or sorry, we don't have getty depending on a screen reader
<seb128> cody-somerville, gnome-orca: Task: ubuntu-desktop, edubuntu-desktop, xubuntu-live, ubuntu-netbook-remix
<cody-somerville> seb128, thats seeds
<seb128> well it's default install
<cody-somerville> seb128, because of seeds
<cody-somerville> seb128, Why doesn't gnome-terminal recommend ocra?
<cody-somerville> seb128, and gnome-mag?
<seb128> cody-somerville, you don't agree that screen reader is something a class of users depend on?
<cody-somerville> seb128, I agree they should be in default install but not a recommends on every single application
<seb128> cody-somerville, every single application doesn't have an icon to use the feature and an autostart to run it
<seb128> cody-somerville, you still don't get that recommends are things to install to have all the components of the software working
<seb128> the reason they are there is that users don't know about suggests and would not understand what to do to get things working if they were not installed by default
<cody-somerville> seb128, If they're installing gdm from a base install, I'm pretty sure they understand
<seb128> well you argue that recommends are of no use
<cody-somerville> seb128, No I don't argue that
<cody-somerville> seb128, I argue that recommends are strong but not absolute *dependencies*.
<seb128> right
<cody-somerville> seb128, look at for example catfish
<cody-somerville> seb128, the backends are suggests, not recommends
<cody-somerville> seb128, thats the debian way doing things
<cody-somerville> seb128, in your definition, they would be recommends
<seb128> that's the way one debian package is doing thing
<seb128> gvfs recommends gvfs-backends
<seb128> firefox recommends ubufox
<cody-somerville> Right
<cody-somerville> Firefox shouldn't recommend ubufox
<cody-somerville> Its abuse of package relationships
<infinity> cody-somerville: For Ubuntu, it definitely should.
<infinity> cody-somerville: According to Debian policy, anyway.
<cody-somerville> infinity, how so?
<infinity> cody-somerville: Recommends defines packages "which would almost always be found together, except in the rarest cases", and firefox/ubufox fit that for Ubuntu.
<cody-somerville> infinity, I think those sort of relationships should be made via seeds, not in the package
<cody-somerville> infinity, but thats just my personal opinion
<seb128> cody-somerville, debian has no seed to the recommends definition can't take that in consideration
<seb128> to -> so
<seb128> you are arguing that recommends should have a different meaning in ubuntu because seeds can be used basically
<cody-somerville> seb128, no, I'm not
<cody-somerville> seb128, Debian might not use seeds but they do use metapackages
<seb128> they don't rely on those
<cody-somerville> seb128, yes they do
<infinity> cody-somerville: Metapackages in Debian aren't relied on for installation or "system sanity".
<cody-somerville> infinity, tasks
<directhex> yay tasksel
<seb128> cody-somerville, how long have you been actively working on debian?
<infinity> cody-somerville: Tasks != metapackages (though we overload them the way we use them), and tasks are STILL not used as recommends in Debian.
<infinity> cody-somerville: And, while tasks and tasksel are cool and all, no one uses them to maintain system consistency, just to quickly install a set of packages.
<cody-somerville> infinity, Right-o. However, IMHO, it makes sense to use tasks/metapackages/seeds/whatever to define relationships that make sense on the distribution level and keep relationships at the package level to those that only make sense in the scope of the packages.
<seb128> cody-somerville, if a software has a feature to launch an another one that's probably because it can make use of it
<infinity> cody-somerville: You're arguing that the package isn't part of the distribution? :)
<cody-somerville> infinity, In today's world, packages can exist across multiple distributions
<cody-somerville> infinity, Thats my thinking
<mr_pouit> does gdm specifically require g-p-m?
<cody-somerville> mr_pouit, no, it runs just fine without
<seb128> mr_pouit, to be able to use the suspend and hibernate button on the login banner yes
<cody-somerville> We could patch the login chooser to grey them out/hide them if gpm isn't present if it doesn't do that already
<mr_pouit> seb128: is that really so? doesn't it rely on something providing org.powermanagement/whatever?
<seb128> mr_pouit, which is what recommends are for having standard features exposed to users working
<seb128> mr_pouit, right anything having the same dbus interface
<seb128> mr_pouit, which is why I suggested having gpm | xubuntu-gpm before
<mr_pouit> we can do that, and everyone should be happy :]
<seb128> that's what I argued first
<seb128> but cody-somerville doesn't think it's right
<cody-somerville> we don't have "xubuntu-gpm"
<cody-somerville> but I can agree to gpm to being in recommends
<cody-somerville> Its the other stuff that gdm might launch that I think should be suggests
<cody-somerville> like gnome-mag
<seb128> other things are what make gdm accessible
<seb128> you realize that you just argue that we should cut a class of users out?
<mr_pouit> (xubuntu-gpm = xfce4-power-manager btw)
<cody-somerville> seb128, yes, I realize that
<cody-somerville> seb128, which is why we use seeds in Ubuntu to produce a distribution that doesn't do that
<seb128> again recommends is debian policy recommendation and doesn't take seeds in account
<seb128> recommends are thing you should get when installing the software from a base image
 * cody-somerville sighs.
<pitti> mterry: wait, I just discovered another bug I'd like to fix in ubiquity
<pitti> mterry: so if you need some changes, please commit them now
<cody-somerville> seb128, How about I just upload gdm2.20 and you can do whatever you want with your new gdm
<mterry> pitti, done
<mterry> pitti, thx
<pitti> mterry: do you know the process of updateing included source packages and building a source? anything magic with that?
<seb128> cody-somerville, feel free if you get somebody to new it for you and you are wanting to maintain it and handle bugs
<mterry> pitti, I believe it's just the 'update' rule
<mterry> pitti, (make -f debian/rules update)
<bassbluete> Hi developer team
<bassbluete> at www.ubuntuusers.de I have ad a thread  to stop WiFi blinking for Dell D630 Latidude
<bassbluete> it is not possilbe to ad this in the actual ubuntu 9.10
<mathiaz> jcastro: hey - is there a ruby team in Ubuntu?
<pitti> mterry: any idea what update-local is? I'd rather not wait for the next publisher run for the one-line patch to user-setup which I just uplaoded
<mterry> pitti, no, I've never used it
<pitti> mterry: are you still going to be around for a while?
<mterry> pitti, for about an hour
<pitti> oh, ok
<pitti> user-setup 1.27ubuntu5.dsc will be published in 90 minutes
<pitti> and I'd like ubiquity to pick this up
<pitti> but oh well, will do it tomorrow early morning then
<slangasek> pitti: something I can help with?  I'm not gone yet, nor is my workday over :)
<pitti> slangasek: I fixed bug 402707 in user-setup (unbreaking autologin)
<ubottu> Launchpad bug 402707 in user-setup "configures "AutomaticLogin=ubuntu" in target system" [High,Fix released] https://launchpad.net/bugs/402707
<EvanCarroll> is there anyway to update udev in a chroot, I have a failued upgrade to jaunty and one of the post-inst scripts is failing because it can't patch udev
<pitti> slangasek: so if you could debian/rules update ubiquity in ~ 2 hours and upload that?
<pitti> slangasek: it's not the end of the world, but it's such a simple fix
<pitti> slangasek: it just appals my sense of beauty and perfection :)
<slangasek> pitti: sure, I can do that
<pitti> slangasek: I'm sure cjwatson has a clever way of updating directly from bzr instead of waiting for the publisher, but I don't know it
<pitti> and I'd rather not mess things up
<pitti> slangasek: thanks!
<pitti> good night everyone then
<pitti> tomorrow's dailies should be smooth as silk then
<superm1> pitti, considering the necessity for a re-roll would that be an opportunistic time if i cherry picked the patch that fixed bug 401971 too?
<ubottu> Launchpad bug 401971 in grub2 "Unable to install grub2 onto vfat partition" [Undecided,New] https://launchpad.net/bugs/401971
<Ampelbein> Riddell: still there?
<Ampelbein> Riddell: regarding mjpegtools, I was in the opinion that -0ubuntu3 got uploaded due to comment 13, https://bugs.edge.launchpad.net/ubuntu/+source/mjpegtools/+bug/351017/comments/13 . But apparently that was not the case so I uploaded it myself.
<ubottu> Ubuntu bug 351017 in mjpegtools "[SRU] mpeg2enc crashes with SIGILL on non-p4 architectures." [High,Confirmed]
#ubuntu-devel 2009-07-22
<Hillshum> Can I ask for help with packaging here?
<directhex> Hillshum, #ubuntu-motu
<Hillshum> ok
<chrisccoulson> kirkland - regarding bug 390504 (you were wondering when the fix was going to be released)
<ubottu> Launchpad bug 390504 in gnome-settings-daemon "gnome-settings-daemon should keep its opinions about my disk management to itself" [Low,Fix committed] https://launchpad.net/bugs/390504
<chrisccoulson> we're probably not going to bother waiting for the tarball now
<kirkland> chrisccoulson: yeah?
<kirkland> chrisccoulson: so sooner rather than later?
<chrisccoulson> so the answer is "probably straight after A3"
<chrisccoulson> hopefully;)
<chrisccoulson> the current behaviour is quite annoying
<ccheney> slangasek: ping
<slangasek> ccheney: hi
<ccheney> slangasek: did you buy your train ticket yourself or some other way?
<ccheney> slangasek: i just got an email apparently yesterday mentioning for me to get it done since the travel agency couldn't do it
 * ccheney was out of town until tonight
<slangasek> ccheney: I bought mine myself on-line, through much toil
<slangasek> ccheney: the problem is that when you search for tickets, their website shows all kinds of tickets for trains that are sold out :P
<ccheney> how do you determine they are sold out?
<slangasek> by trying to buy it, and getting an error message
<kirkland> cjwatson: any chance you're around yet?
 * liw notices that the gnome audio volume control widget's mute doesn't actually mute headphones
<pitti> Godo morning
<pitti> superm1: did you just do it?
<superm1> pitti, no as it turns out it wasn't just a single commit that needed backporting
<superm1> pitti, so once i realized it would be multiple i opted to just wait until after a3 when we can merge the new snapshot from debian
<spotter> btw, whats up with the google plugin in firefox 3.5?
<spotter> the search/sherlock plugin
<spotter> it takes me to a google custom search page that is horrible
<pitti> meh, no firefox for me this morning?
<pitti> Starting program: /usr/lib/firefox-3.0.12/firefox
<pitti> [Thread debugging using libthread_db enabled]
<pitti> Program exited with code 01.
<pitti> asac: ^ any idea?
<pitti> it still worked last night
<pitti> asac: ah, nevermind, it's a kirkland bug
<kirkland> pitti: howdy
<pitti> kirkland: since yesterday's karmic, my ~/Private isn't automounted on login any more; did anything change in ecryptfs recently?
<pitti> kirkland: good morning
<kirkland> pitti: yes, and i uploaded a fix for that about 5 minutes ago
<pitti> kirkland: retroactive fixing, splendid!
<kirkland> pitti: upgrade to 77-0ubuntu1 and you should be fixed again
<kirkland> pitti: in the mean time, run ecryptfs-mount-private by hand
<pitti> right, that's what I was doing
<pitti> I just don't immediately realize it
<pitti> and thus ssh hangs, firefox doesn't start, etc.
<pitti> kirkland: thanks!
<kirkland> pitti: you bet, thanks for your alpha-patience :-)
<billybigrigger> is there a known issue with lost sound today?
<pitti> superm1: are you in ~ubuntu-installer?
<pitti> I just uploaded ubiquity, and then noticed that I cannot push the branch
<slangasek> ubiquity needed Yet Another Upload?
<superm1> pitti, yeah i am
<superm1> point me at a branch and i'll mege it
<superm1> merge even
<pitti> pushing right now
<slangasek> oh, perhaps I failed to upload after building it here, sigh
<slangasek> pitti: sorry
<slangasek> I think I got sidetracked in the middle, trying to figure out why gnome-keyring-daemon wasn't acting as a gpg agent
<pitti> slangasek: no prob, uploaded now
<pitti> I think it's the first time I uploaded ubiquity
<pitti> slangasek: it's not supposed to, that's seahorse
<pitti> slangasek: but gpg was fixed with last Friday's gdm, I think, it still fails for you?
<pitti> hm, what's the point of "Using default stacking branch" if bzr push uploads the entire 46 MB again?
<slangasek> pitti: I may not have upgraded gdm prior to my unplanned reboot
<superm1> i heard seahorse was split up and you needed seahorse-plugins installed to get gpg-foo too
<slangasek> I have seahorse-plugins
<slangasek> anyway, it's probably the bug pitti says
<pitti> slangasek: with yesterday's gdm upload, both ssh and gpg should work again
<pitti> if not, please let me know
<slangasek> ok
<pitti> superm1: can you please bzr pull lp:~pitti/ubiquity/fix-402707 ?
<pitti> superm1: (pull -> cleaner history than merge)
<superm1> pitti, okay done
<pitti> superm1: thanks!
<superm1> no prob. good call on the pull rather than merge, makes sense
<StevenK> pitti: Am I okay to upload ekiga, or shall I wait? It's only on the DVD, and it allows me to pull out about 8 NBS packages
<pitti> StevenK: go ahead
<johnny_> hi, nvidia quadro 160m is supporte in jaunty?
<johnny_> supported
<pitti> hah; apport's test suite fails now
<pitti> AssertionError: 'eglibc' != 'glibc'
<pitti> yay me for assuming too much :)
<asac> pitti: ok ;)
<dfaure> since ugprading to jaunty breaks every machine with fglrx (due to xorg-1.6), why did you upgrade to xorg-1.6? Or, why not provide 1.5 for the poor souls with an ATI card?
<seb128> dfaure, try #ubuntu-x maybe but I expect the choices are not made based on closed source driver users
<seb128> dfaure, especially if they consider the ati opensource driver to be good enough for most users nowadays
<dfaure> it is? when I tried it on the other machine nothing worked. But let me try again, then.
<dfaure> I don't really care if it's open source or closed source, but I'd like something else than red dots on my display ;)
<seb128> well you might have no luck and have a card not working fine with ati
<seb128> but it's not an issue for any ati user
<hyperair> are packages supposed to install scripts into /etc/pm/sleep.d? isn't the right place /usr/share/pm-utils/sleep.d?
<dfaure> seb128: at least the jaunty upgrade should have made xorg use ati, then. It's the job of the distro to make upgrades painless....
<seb128> dfaure, well I don't know about specifics but I though they got a working fglrx version before jaunty
<dfaure> ?
<seb128> dfaure, do you use the fglrx ubuntu package or an upstream version you got somewhere?
<dfaure> ubuntu package
<seb128> dunno then, ask in #ubuntu-x they will know better
<directhex> seb128, ATI dropped support for most of their hardware
<seb128> directhex, well that's not an xserver 1.6 issue then but a fglrx ati one
<directhex> seb128, so even though a driver with support for modern xorg was released, it only supports current & last gen (and maybe the one before too)
<dfaure> seb128: well it's related, since the older fglrx for xorg-1.5 obviously still works
<directhex> seb128, well, the point is the previous driver can't be included in parallel due to xserver 1.6. i assume
<seb128> dfaure, I expect the issue there is that we can't make package depends be dynamic according to the hardware
<seb128> dfaure, but agreed that's an issue, xorg should at least try to fallback on ati in such cases
<dfaure> yes
<Ng> dfaure: didn't the upgrade tell you that your graphics driver didn't exist in jaunty? update-managet warned my sister on her dell laptop with ATi that she'd have a worse experience
<seb128> the issue is as often in opensource lack of manpower to get everything changed
<dfaure> Ng: ok, I used apt-get dist-upgrade, no warnings.
<Ng> dfaure: don't do that ;)
<directhex> dfaure, if you're going to stand outside the safety barrier (update-manager), then that happens
<dfaure> ok, point taken there.
<Ng> dfaure: do-release-upgrade works for shell upgrades if you don't want to use the graphical tool (although I haven't checked if it displays such warnings)
 * dfaure wishes the debian package stuff didn't have so many layers on top of each other, but that's another discussion
<seb128> dfaure, ubuntu doesn't real has, users should use update-manager in a consistent way
<seb128> real -> really
<dfaure> X: symbol lookup error: /usr/lib/xorg/modules/extensions//libdri.so: undefined symbol: atiddxAbiDixLookupPrivate
<mvo_> Ng: do-release-upgrade will perform the same kind of checks as update-manager (including the warning about fglrx)
<Ng> mvo_: I figured it might, ta :)
<mvo_> :)
<dfaure> any idea about the undef symbol? X won't start...
<mvo_> dfaure: is fglrx still installed? IIRC it diverts libdri so that might be the problem
<ogra> looks like the lib is incompatible with something (the server ?)
<dfaure> mvo_: thanks, works now
<mvo_> np
<dfaure> well, sort of. X starts, kde starts, but no mouse and no keyboard...
<dfaure> sigh
<pitti> cking: do you still have the oem install from bug 402918 to collect logs and files?
<ubottu> Launchpad bug 402918 in gdm "Karmic Alpha3, OEM login cycles round and around" [Undecided,Incomplete] https://launchpad.net/bugs/402918
<pitti> (just followed up)
<cking> pitti, nope, but I can re-install and let you know within the hour
<pitti> cking: thanks
<cking> installing again... :-)
<pitti> cking: btw, I'm currently building new desktop images, which have a new ubiquity; I see some oem related fixes in the changelog
 * pitti crosses fingers
<gaspa> any archive-admin around that could please take a look at bug #402710 ?
<ubottu> Launchpad bug 402710 in ocaml "[3.11.1 transition][round 1/6] Please synchronize ocaml 3.11.1-2 from Debian sid in Karmic" [Undecided,Confirmed] https://launchpad.net/bugs/402710
<pitti> gaspa: added sponsor ack and followup
<gaspa> pitti: thanks ;) I wasn't sure about the right procedure.
<directhex> presumably contributions to launchpad require copyright assignment?
<pitti> yes
<directhex> and it's pretty explicit on the dev wiki's page on submitting a patch that the assignment paperwork needs to be done. okay, just checking
<pitti> for small patches as well?
<pitti> for my own projects I just chase this if someone adds completely new files with a (C) line for himself
<pitti> I'm not worried about patches which don't add a copyright line
<pitti> but that's for my own projects, LP's policy might be different
<nikolam> Hi. Anyone knows why packages is not working so often
<liw> nikolam, people make mistakes
<nikolam> liw, :)
<nikolam> Nevermind, Just to see it online again
<nikolam> I ment packages.ubuntu.com Btw
<liw> nikolam, ah, then I have no idea
<Omahn> nikolam: Seems to have been offline for a while now.
<nikolam> Omahn, `for a while` is less then 1 day
<nikolam> it worked yesterday
<nikolam> and not working the day before
<Omahn> True
<cking> pitti, log files attached to bug report.
<pitti> cking: splendid, thanks
<cking> shall I keep this OEM version installed for a while if you need anything else?
<pitti> cking: no, the logs should do fine; also, we have new CDs with a new ubiquity now
<cking> shall I stop further ISO testing then and wait for the new ISOs?
<pitti> cking: they are already there
<pitti> cking: and on the tracker
<cking> doh
<pitti> I'm done with wrestling with xubuntu CDs, looking at bug now
<pitti> cking: hang on
<pitti> cking: can you please attach /etc/gdm/custom.conf ?
<cking> OK.. gimme 5
<pitti> gdm-simple-greeter[2852]: DEBUG(+): GdmGreeterClient: Received TimedLoginRequested (ubuntu 0)
<pitti> gdm-simple-greeter[2852]: DEBUG(+): GdmGreeterLoginWindow: requested automatic login for user 'ubuntu' in 0 seconds
<pitti> so it tries to auto-login as "ubuntu", which doesn't exist
 * pitti follows up in bug report
<cking> pitti, yep, log attached, indeed, logging in as ubuntu
<pitti> cking: thanks; you can kill the install now
<cking> cool
<pitti> cking: I'm pretty sure it's already fixed on the current isos
<cking> I'll find out in 20 mins
<glatzor> hello mvo_, do you know why in softwareproperties.AptAuth gpg is used instead of apt-key?
<mvo_> glatzor: probably a oversight, let me have a look
<mvo_> glatzor: good to see you btw :)
<doko> mbiebl: which criteria did you use for syncing/merging the zopepackages? which ones and which ones not?
<mbiebl> doko: wrong person ;-)
<doko> ahh, same initials ...
<doko> geser: ^^^
<pitti> mdz: so, we found out why the apport retracers produce useless results; some fakechroot regression in karmic
<geser> doko: I'm trying to get a complete turbogears2 stack synced to karmic. So I just look at the packages needed for it (depends and recommends)
<pitti> mdz: I applied a workaround now
<pitti> and we'll re-tag recent crash reports
<mdz> pitti, oh, great, thanks
<mdz> pitti, is there a bug filed for the regression?
<pitti> mdz: not yet, I haven't really pinpointed it yet
<pitti> mdz: "file /usr/bin/gnome-volume-control" -> no such file
<pitti> cd /; gdb ... ; file usr/bin/gnome-volume-control" -> works
<pitti> but only in gdb
<doko> geser: yes, and breaking zope3 ... anyway, will now try to do the complete zope3 split. although it's not yet completely in unstable :-/
<mdz> pitti, very weird
<seb128> "works"
<geser> doko: oh, sorry, missed it
<seb128> but next it fails to load the debug file
<pitti> mdz: I strace'd it, and for e. g. open('/usr/bin/gnome-mount') it works, and for open('/usr/bin/gnome-volume-control') it fails
<pitti> very ominous
<pitti> seb128: oh, that too?
<pitti> meh
<pitti> seb128: if so, let's shut down them again
<seb128> pitti, I was not speaking about your workaround sorry for the confusion
<pitti> ah
<seb128> rather about the " /usr/bin/../lib/debug//usr/bin/gnome-volume-control: No such file or directory." this morning
<geser> doko: zope3 is main, and the zope.* package are in universe. How did they manage to break zope3?
<doko> geser: they'll replace zope3, and currently are incomplete to replace it
<cjwatson> eek, sudo is segfaulting here
<ogra> use root :P
<mdz> cjwatson, in a normal environment?
<cjwatson> yes
<cjwatson> Jul 22 12:08:55 sarantium kernel: [ 6924.741810] <6>sudo[16106]: segfault at 48 ip 001616a6 sp bfc0d288 error 4 in libc-2.9.so[110000+15a000]
<mdz> I had a run of segfaults and panics and suchlike when I first updated my laptop to 2.6.31, but they went away after updates
<mdz> cjwatson, reproducible?
<cjwatson> I just upgraded, which included a libc6 upgrade
<cjwatson> yes, every time
<ogra> ouch
<cjwatson> no crash report and I'd probably need root to get at it anyway :)
<doko> running current karmic, not seeing sudo segfaults
<pitti> here as well (amd64)
<pitti> so hopefully not an alpha-3 release breaker?
<ogra> same here (i386)
<doko> I'm on i386
<liw> . o O (easy rollbacks with dead-man's-handles would be really cool)
<pitti> cking: *phew*, thanks for testing again
<cjwatson> sorry, I tell a lie, no libc6 upgrade involved
<cjwatson> I was confused by the trigproc stuff in dpkg.log
<cjwatson> http://people.ubuntu.com/~cjwatson/tmp/dpkg.log
<ogra> apparmor ?
<pitti> sudo strace sudo ... erm, fail
<cjwatson> apparmor was installed in this upgrade, yes
<cjwatson> but I don't know why that would cause a segfault
<cjwatson> libpam-ck-connector maybe?
<pitti> hang on
<pitti> $ sudo true
<pitti> works
<pitti> $ sudo aa-status
<pitti> Segmentation fault
<pitti> $ sudo true
<pitti> Segmentation fault
<pitti> WTF?
<pitti> nothing in dmesg, though, except the crash itself
<pitti> sudo -K
<pitti> still works
<james_w> libpam-ck-connector shouldn't have broken
<james_w> there were no code changes
<james_w> ah
<james_w> there were two uploads yesterday :-)
<james_w> nothing jumps out from the changelog though
<pitti> it happened after just this dist-upgrade
<pitti> upstart and ecryptfs are the two likely candidates
<pitti> and ecryptfs is PAMish, too
<pitti> the rest was gstreamer, ekiga, and a gdm postinst fix, none of which even come near sudo
<cking>  pitti, the system now gives me a blank screen at step uoi-003 in the test case: http://testcases.qa.ubuntu.com/Install/DesktopOem
<doko> libgcc1 was updated as well
<pitti> not in my run 5 minutes ago
<pitti> and before that I was working with sudo all the time
<pitti> I'll downgrade ecryptfs after lunch, when I can reboot the box into rescue mode
<pitti> arghl
<pitti> I can't even log in any more
<pitti> [25302.085252] <6>login[31054]: segfault at 88 ip 00007f92286fec11 sp 00007fff23fa6e40 error 4 in libc-2.9.so[7f92286a6000+166000]
<pitti> [25231.246453] <6>mount.ecryptfs_[31021]: segfault at 88 ip 00007f59a3bbcc11 sp 00007ffff66b0a70 error 4 in libc-2.9.so[7f59a3b64000+166000]
<pitti> I'm up for a bet that it's today's ecryptfs upload
<seb128> should we get the deb blocked from download?
<james_w> plenty of PAM stuff in the changelog
<james_w> lpsp
<pitti> I'll reboot into rescue mode, downgrade, and check
<seb128> mdz, pitti: should we get the deb blocked from download?
<pitti> yes, after confirming that it's ecryptfs
<seb128> ok
<seb128> need some help?
<seb128> I didn't upgrade yet, I can upgrade just it and try sudo or something
<mdz> I don't have any *ecryptfs* installed
<ogra> mdz, well, do you currently see segfaults ?
<mdz> ogra, no, I have no troubles right now
<mdz> with my Ubuntu system anyway
<mdz> I just installed the latest updates, which included:   gdm groff-base offlineimap pbuilder upstart
<ogra> same here
<mdz> I have libpam-ck-connector 0.3.0-2ubuntu7
<apw> apparmor should be disabled, so i'd not expect it to be that
<james_w> free(f);
<james_w> asprintf(&f,
<james_w> is that legal?
<apw> doesn't look like the best plan to me
<apw> hrm, actually i don't know what asprintf does ... so ignore me
<apw> oh they allocate, so that does seem appropriate
<mdz> cjwatson, are you using ecryptfs as well?
<pitti> confirmed
<pitti> I downgraded ecryptfs-utils, and it works again
<pitti> elmo: can you please chmod 0 ecryptfs-utils_77-0ubuntu1_*.deb on the mirrors?
<pitti> Ng: ^ or you?
 * pitti apports _bin_login.0.crash
<pitti> cjwatson: bug 403011 FYI
<pitti> kirkland: ^ halp
<dupondje> pitti: private bug ? :)
<seb128> dupondje, bugs are private until being retraced
<pitti> hang on
<pitti> public now, and attached local stack trace
<james_w> I see it I think
<pitti> meh, and of course this crept into the xubuntu builds
<pitti> which _just_ finally built, after oh-so many attempts :/
<pitti> I really need to grab some food, I'm falling off my chair
<pitti> can someone please followup with IS to disable the package?
<ogra> but you wont get fat :=
<ogra> :)
<pitti> flockfile(NULL) really seems unhappy
<seb128> pitti, ok
<seb128> pitti, enjoy your lunch
<pitti> asked #is
<james_w> http://paste.ubuntu.com/224351/
<pitti> seb128: thanks
<pitti> james_w: that makes a lot of sense
<james_w> look good to upload?
<pitti> james_w: you already tested it, etc.?
<pitti> if so, please go ahead
<james_w> still building
<james_w> what's the test case
<james_w> install and run sudo?
<pitti> james_w: install it, and try to login and sudo
<pitti> if that fixes it, don't hesitate
<pitti> it can't get _any_ worse
 * james_w opens a root terminal
 * pitti hands seb128 the baton for looking in #is and coordinating, in case followup questions turn up
<pitti> james_w: you better do :)
<seb128> pitti, ok, no worry
<pitti> seems I need to wait for another 15 minutes
<pitti> so I'll spend the time to weed out the alpha-3 images where the new ecryptfs slipped in
<james_w> I can't make the problematic package segfault
 * mvo_ hugs james_w
<pitti> james_w: you can't reproduce the original crash, you mean?
<james_w> yeah
<pitti> let me try your patch then
<james_w> don't want to test the fix until I have a broken system
<james_w> do I need to restart all my sessions?
<pitti> james_w: no, it just happens
<pitti> install new ecryptfs-utils, and suddenly login and sudo go boom
<pitti> I actually use ecryptfs, though
<pitti> james_w: building your fixed package now
<james_w> ah
<james_w> you need libecryptfs0 as well
<james_w> otherwise you get a symbol lookup error
<pitti> james_w: confirmed, that fixed the problem
<james_w> presumably the dependencies need to be tightened
<james_w> kirkland: ^
<james_w> pitti: shall I upload?
<pitti> james_w: can you upload this, or shall I?
<pitti> please do
<pitti> I'll bump build score
<james_w> 403 on the broken package to test now :-)
<pitti> I hope we can make the :03 publisher run
<james_w> uploaded
<pitti> building everywhere
<pitti> ok, finally food
<pitti> bbl
<pitti> james_w: thanks!
<james_w> thanks Pici
<james_w> and pitti :-)
<Pici> :)
 * ogra wonders why makedev got so slow 
<ogra> (the package stalls debootstrap for quite a while)
<james_w> all ACCEPTED except for armel, which should make it
<james_w> and there it is
<james_w> pitti: should be in the next publisher run for you
 * james_w -> food as well
<cjwatson> mdz: ecryptfs> yes
<cjwatson> I wonder if I can move .ecryptfs aside or something to get sudo back ...
<cjwatson> aha! yes
<cjwatson> thanks guys :)
<james_w> cjwatson: is that just "mv /home/username/.ecryptfs /home/username/.ecryptfs.save" ?
<mdz> james_w, sorry, I may have just clobbered your wiki edit.  I clicked save before I noticed, and I canceled, but I think it was too late
<cjwatson> james_w: yeah
<james_w> mdz: np
<ogra> meh
<ogra> could someone promote udhcpc to main ?
<ogra> it has an approved MIR and stgraber made ltsp-client-core depend on it
<ogra> which means ltsp installs currently break due to udhcpc missing on the CD
<ogra> (the MIR is bug 383177)
<ubottu> Launchpad bug 383177 in udhcp "Main inclusion request for udhcpc" [Undecided,Fix committed] https://launchpad.net/bugs/383177
<james_w> should we have instructions for escaping the problem posted somewhere?
<cjwatson> james_w: ubuntu-devel-announce maybe?
<Unggnu> hi all
<Unggnu> Is there a reason why firefox-3.0 comes without all the gnome dependencies but firefox-3.5 not?
<Unggnu> So it is possible without the whole mess to use Firefox 3.0 with KDE but not with 3.5 while it works fine if I download and install it locally without any further dependencies.
<taavikko> question about *buntu-restricted-extras, why it is needed to have xubuntu and ubuntu in separate metapackages, since their content is roughly the same. This can create confusion?
<taavikko> for KDE I understand the need for it's own, but the other two are making me wonder..
 * ScottK would find ubuntu-restricted-extras for Xubuntu confusing.
<taavikko> I thought about the naming convention, since it would be easier to understand what package to install, vbased on what enviroment is running
<kirkland> pitti: i'm here now
<pitti> hey kirkland
<pitti> kirkland: you missed all the action :)
<kirkland> pitti: should i read the backlog?
<kirkland> pitti: yeah, sorry :-)
<pitti> but I guess james_w didn't spend much time on forwarding bug/patch upstream, etc.
<james_w> oops, forgot about that
<pitti> james_w: no worries; you rocked!
<pitti> kirkland: so could you please take a look at the bug, perhaps clean up the fix, and sort out the upstream comimt, etc.?
<pitti> it was pretty much a shot from the hip to unbreak karmic
<kirkland> pitti: sure thing
<kirkland> pitti: james_w: whoa boy
<pitti> cjwatson found a much better workaround, I actually dived into init=/bin/bash, etc. :)
<kirkland> james_w: good find
<james_w> twas an easy spot once pitti had the stacktrace
<kirkland> pitti: what was cjwatson's workaround?
<pitti> temporarily move aside ~/.ecryptfs
<kirkland> james_w: yeah, i did make that change late yesterday :-/
 * pitti rebuilds alpha 3 images which had the broken version, since we offer it in the installer
<kirkland> pitti: sorry man
<pitti> kirkland: no problem
<kirkland> james_w: i'll commit this upstream now
<james_w> thanks
<james_w> kirkland: did you also see my comment on the dependencies?
<kirkland> pitti: what was the "better" workaround that cjwatson had?
<kirkland> james_w: hmm, no, what's that?
<pitti> temporarily move aside ~/.ecryptfs
<pitti> kirkland: e-utils doesn't depend on libecryptfs0
<james_w> I was able to install the new ecryptfs-utils without the new libecryptfs0
<pitti> kirkland: missing dh_shlibdeps, or missing ${shlibs:Depends}?
<james_w> which broke umount-private, because it couldn't find ecryptfs_find_private_mount or whatever that symbol is called
<james_w> perhaps just a missing/outdated -V ?
<kirkland> pitti: oh, hmm, yeah, ecryptfs-utils should depend on libecryptfs0
<pitti> kirkland: usually that should just happen automatically
<kirkland> pitti: both Depend on ${shlibs:Depends}
<pitti> weird
<kirkland> pitti: james_w: ecryptfs-utils was missing libecryptfs0
<james_w> Package: ecryptfs-utils
<james_w> Depends: ..., libecryptfs0 (>= 48)
<james_w> Version: 77-0ubuntu1
<james_w> are you seeing something else?
<pitti> oh, right
<kirkland> james_w: oh, i was looking at the source debian/control
<kirkland> Depends: ${shlibs:Depends}, ${misc:Depends}, keyutils, libnss3-1d, libpam-runtime (>= 1.0.1-6), libecryptfs0
<pitti> sorry, I misread
<kirkland> (i just added libecryptfs0)
<pitti> dependency is here as well
<pitti> kirkland: no, please don't
<james_w> probably want a "dh_makeshlibs -V77-0ubuntu1"
<kirkland> pitti: okay
<pitti> kirkland: it should be picked up by dh_shlibdeps
<pitti> (and is)
<pitti> kirkland: I was just confused, sorry
<james_w> as symbols were added in that version?
<pitti> james_w ++
<kirkland> ah, it's coming together now!
<james_w> score!
<kirkland> i added a couple of symbols to libecryptfs0 in this last upload
<kirkland> the build in the archive is building against (potentially) an older one in the chroot?
<james_w> kirkland: if it's in the same source then that shouldn't happen
<pitti> kirkland: no, it just says it's possible to have a newer version of ecryptfs-utils installed with an older version of libecryptfs0
<james_w> the build will write out a shilbs file from dh_makeshlibs
<pitti> which must not happen, due to the new symbols (which might be used by ecryptfs-utils)
<james_w> then for dh_shlibsdeps for ecryptfs-utils will find the symbol, look it up and add the dependency
<james_w> however, it's picked an old version
<pitti> well, it doesn't really "pick"
<pitti> it reads libecryptfs0's .shlibs
<james_w> so you need to tell it that there are new symbols in the new version, and that anything built against this new version should use this version as a minimum
<james_w> or you could add a symbols file so that the dependency is only bumped if it actually uses a new symbol
<james_w> pitti: dh_makeshlibs is currently called without a version, why is it (>= 48) that is used?
<pitti> $ cat /var/lib/dpkg/info/libecryptfs0.shlibs
<pitti> libecryptfs 0 libecryptfs0 (>= 48)
<pitti> apparently some older package did specify a version
<pitti> $ cat debian/libecryptfs0.shlibs
<pitti> libecryptfs 0 libecryptfs0 (>= 48)
<pitti> ^ there
<kirkland> yeah
<pitti> please bump
<james_w> kirkland: the syntax I gave you was wrong
<kirkland> james_w: okay, so now i don't need the dh_makeshlibs
<james_w> why not?
<kirkland> i just need to adjust debian/libecryptfs0.shlibs
<kirkland> right?
<kirkland> sorry
<kirkland> i need dh_makeshlibs
<kirkland> i don't need the explicit -V
<james_w> man dh_makeshlibs
<kirkland> since the debian/libecryptfs0.shlibs file specifies it
<james_w> ah
<james_w> I don't think that's a normal way to do it though is it?
<kirkland> james_w: pitti: i don't know;  this is all new magic to me
<pitti> well, both are valid really
<kirkland> pitti: james_w: seems to me bumping in that file is the nicest way to go
<pitti> the most modern form is to use dpkg-gensymbols (man deb-symbols)
<james_w> if it works
<pitti> but out of that, using explicit .shlibs files or using -V amounts to the same
<pitti> it's a matter of preference AFAICS
<james_w> kirkland: so, the rule is, symbols removed of changed -> soname bump -> package name changed -> NBS dance
<james_w> symbols added -> shlibs bump
<james_w> or a symbols file, but that's a bit more work
<james_w> and won't make too much of a difference if there are only a couple of packages depending on the lib
<kirkland> gotcha
<james_w> symbols files do help you catch missed soname changes though
<kirkland> james_w: pitti: http://pastebin.ubuntu.com/224392/
<kirkland> james_w: pitti: that's what i have so far
<pitti> kirkland: looks good
<james_w> I think that's right
<james_w> though I didn't change shlibs :-)
 * pitti walks over to wife's computer to try live system, bbl
<kirkland> pitti: james_w: should I push another upload with the shlibs change?
<james_w> might as well, as long as pitti is fine with the timing for alpha
<kirkland> james_w: i'll await pitti on that one ...
<ogra> pitti, i assume you didnt process my former request of moving udhcpc to main between the two alternate rebuilds, right ?
<ogra> (so i dont need to test the ltsp install again)
<pitti> ogra: no, didn't see that? why would it affect CDs?
<ogra> ltsp-client-core depends on it
<pitti> ogra: out of interest, why doesn't it use dhcp3-client?
<ogra> stgraber assumed the fix committed status on bug 383177 would mean it was moved
<ubottu> Launchpad bug 383177 in udhcp "Main inclusion request for udhcpc" [Undecided,Fix committed] https://launchpad.net/bugs/383177
<pitti> no, that would be 'released'
<ogra> pitti, to big i guess, not my decision
<ogra> pitti, *i* know :)
<ogra> he didnt
<kirkland> pitti: did you want me wait, or push an upload now with that shlibs change?
<pitti> kirkland: seems harmless now, so go ahead
<kirkland> pitti: okay, thanks.
<ogra> pitti, they install udhcpc in the initramfs, i think dhclient was to clunky for what they tried to achieve
<ogra> (essentially trying to compensate for the many missing features if klibc/ipconfig)
<ogra> s/if/of/
<LaserJock> is FUSA not installed by default in karmic?
<ogra> currently not ... only the one that comes with gdm
<ogra> waiting for an update from the DX team afaik
<seb128> LaserJock, it is but it's part of gdm now
<seb128> LaserJock, the ubuntu changes are being ported by ted too
<LaserJock> seb128, ogra: ah, ok, thanks
<cjwatson> james_w: confirmed that your fix works with .ecryptfs moved back into place - thanks!
<james_w> thanks cjwatson
<ogra> seb128, did you btw ever try to logout from a jaunty system that has no mouse and no powerbutton ? :)
 * ogra just found out thats impossible since you cant reach FUSA with the keybopard at all
<seb128> ogra, there is a bug open about that since before jaunty
<ogra> ah, i didnt know
<ogra> just found it funny
<hdon> question for ubuntu hackers: i want to report a bug that has to do with editing source code, and i want to provide comprehensive list of instructions to reproduce the problem. if an ubuntu hacker could recommend a good source code package for a medium-large software project (firefox would work, since i already have that code downloaded) to download as part of those instructions, i would be much obliged
<hdon> also, it's worth noting that this happened to me:
<hdon> * #ubuntu-hackers #ubuntu :Forwarding to another channel
<hdon> should probably be forwarded to #ubuntu-devel?
<hdon> whatever, i'll just use firefox
<seb128> mathiaz, hey
<mathiaz> seb128: hey
<seb128> mathiaz, who is looking after samba4 in ubuntu?
<mathiaz> seb128: hm - jelmer?
<mathiaz> seb128: kind of.
<mathiaz> seb128: why?
<seb128> mathiaz, dunno, I'm the one who asked ;-)
<seb128> mathiaz, openchange build breaks on   samba4-dev: Depends: libldb-samba4-dev but it is not going to be installed
<seb128> mathiaz, I was wondering if that's a known issue and if somebody is going to sort that
<mathiaz> seb128: it should be sorted out once we merge samba4 from debian experimental
<seb128> mathiaz, is anybody in the server team going to make sure that happens before karmic?
<mathiaz> seb128: I'll have a look at it
<seb128> mathiaz, thanks!
<jelmer> seb128:, mathiaz: libldb-samba4-dev has been removed
<seb128> jelmer, well samba4-dev depends on it
<jelmer> instead the upstream libldb-dev should now work
<mathiaz> jelmer: right - however the current version in karmic is still alpha6
<mathiaz> jelmer: alpha8 should be merged to fix the problem
<jelmer> Ah, oops. I'll request syncs
<mathiaz> jelmer: or may be synced
<mathiaz> jelmer: samba4 has a 1ubuntu1 version
<mathiaz> jelmer: I haven't looked at the changes made in ubuntu.
<jelmer> mathiaz: Ah, hadn't seen that. I'll merge those into the Debian package for the next upload and then request a sync.
<Viper550> Xournal...think it should be in the default install?
<seb128> Viper550, no
<Viper550> why not? they added Windows Journal to base installs for Viata
<seb128> because we are out of CD space and that doesn't seem something which will benefit most users
<Viper550> yeah, so much for not removing gimp
<ogra> what would you do with xournal anyway without tablet or touchscreen to use it for its purpose
<ogra> its easy enough to install it later
<rtg_> after updating this morning, sudo stopped working (segmentation fault), and I cannot login to my account through GDM. sshd works, but still cannot sudo.
<rtg_> I can login to another account, but its not in /etc/sudoers
<liw> rtg_, it seems to be a problem with ecryptfs, downgrading that or temporarily renaming the .ecryptfs(or something) directory should fix things
<liw> rtg, or, alternatively, upgrading to the newer version of ecryptfs uploaded today
<rtg_> liw, just read the incident report. https://wiki.canonical.com/IncidentReports/2009-07-22-ecryptfs
<davmor2> bryce: ping
<bryce> davmor2, http://err.no/personal/blog/tech/2006-10-10-12-05_contentless_pings.html
<davmor2> bryce: ah okay :)   You have a box with an ati card correct?
<bryce> Yes I do.
<davmor2> bryce: do you run/or can you install karmic on it.  If so can you see what happens on reboot after enabling fglrx
<davmor2> I currently get a white screen where gdm should be and can't switch to console
<bryce> davmor2, kinda busy, but it worked for me last time I tried it
<bryce> davmor2, see http://wiki.ubuntu.com/X/Troubleshooting for directions on how to collect debug info for white screen issues
<davmor2> bryce: thanks for the info.
<mathiaz> james_w: hey - could you import libvirt in the package branches?
<pitti> @all: please help out testing CD images for alpha-3, time is getting a bit tight (http://iso.qa.ubuntu.com)
<wubbbi> is it normal that I need root previlegs to eject my cd-drive? oO using karmic up to date
<infinity> wubbbi: It's normal if someone other than you has the filesystem mounted.
<wubbbi> infinity: but Im the only user of this PC ... this cant be possible
<infinity> wubbbi: I meant "someone other than your user" (like, say, root), not "someone walking into your house".
<infinity> wubbbi: But this belongs on #ubuntu (or #ubuntu+1, if it's karmic), not in -devel.
<james_w> mathiaz: queued
<mathiaz> james_w: \o/ - thank ya
<kees> Keybuk: why is /dev/net/tun 0666?
<pitti> mathiaz, kirkland, zul: can you guys give the server alpha-3 CDs a spin?
<pitti> (or who can I ping about that?)
<pitti> we probably don't need a full test coverage, but the thing should at least instlal
<mathiaz> pitti: I've started to test them. However I ran into a kernel regresion when doing kvm testing
<mathiaz> pitti: kirkland is currently debugging it
<pitti> ah, nice
<mathiaz> pitti: I'm gonna have to workaround the regression in order to be able to go through an install
<mathiaz> pitti: currently the install stops while trying to mount vda1 as an ext4 partition :/
<pitti> weird, I was using kvm all day
<mathiaz> pitti: are you using qcow2 files as the base for block devices?
<mathiaz> pitti: or raw or lvm devices?
<pitti> mathiaz: in the host or guest?
<mathiaz> pitti: host
<pitti> on the host I just have a 6 GB dd'ed raw file
<mathiaz> pitti: right - so you're using a raw file
<mathiaz> kirkland: ^^
<mathiaz> kirkland: pitti doesn't see an issue with raw files with alpha3
<kirkland> the work around is "don't use virtio"
<kirkland> pitti: are you using virtio disks?
<pitti> I never had anything else, TBH
<pitti> kirkland: what's that?
<pitti> kvm -m 768 -cdrom download/ubuntu/karmic-desktop-i386.iso -hda download/kvm-images/testdesktop.img -boot d
<pitti> and that was generated with dd if=/dev/zero of=testdesktop.img bs=1M count=6000
<pitti> I'm afraid I don't use the fancy stuff
<kirkland> pitti: right, okay, you're not using virtio disk, and so you're not affected by the issue mathiaz raised
<kirkland> pitti: -drive if=virtio,index=0,boot=on,file=testdesktop.img
<kirkland> pitti: that would get you virtio disks, roughly a 10x performance improvement on disk reads/writes
<mathiaz> kirkland: from an alpha3 perspective, does it mean that alpha3 will not work on virtio guests?
<pitti> kirkland: wow
<pitti> I guess it's a little late now, but since it can be fixed in an update, I don't see it as a release blocker
<kirkland> pitti: i don't think it's a blocker
<kirkland> pitti: the workaround is 'disable virtio in the guest'
<pitti> kirkland: that -drive replaces -hda test.img ?
<mathiaz> should it be added in the release notes?
<kirkland> pitti: right
<kirkland> mathiaz: yes, definiteyl
<pitti> mathiaz: please go ahead; https://wiki.ubuntu.com/KarmicKoala/TechnicalOverview#Known%20issues
<kirkland> definitely, even
<mathiaz> pitti: could you confirm that the install breaks for desktop on virtio drives?
<mathiaz> kirkland: or have you confirmed it ^^?
<pitti> mathiaz: I currently have a kvm running, but I'll try with a second instance with the alternate
<kirkland> mathiaz: i confirmed it
<pitti> ah, /me just trashes it, it didn't get very far
<pitti> $ kvm -m 768 -drive if=virtio,index=0,boot=on,file=download/kvm-images/testdesktop.img
<pitti> looks right?
<pitti> this boots the previous install
<pitti> wow, unlike with the default -hda that puts almost no load on my box
<pitti> awesome
<pitti> and it's indeed much faster
<pitti> kirkland, mathiaz: anyway, previous desktop install is booted now with above command
<pitti> nothing in dmesg
<kirkland> pitti: uname -a?
<pitti> $ cat /proc/version_signature
<pitti> Ubuntu 2.6.31-3.19-generic
<pitti> Linux tick 2.6.31-3-generic #19-Ubuntu SMP Tue Jul 14 16:07:02 UTC 2009 x86_64 GNU/Linux
<seb128> pitti, what kvm command is that?
<pitti> seb128: I just learned about "virtio" kvm drives, which are apparenlty go-faster stripes
<kirkland> pitti: when they work :-)
<pitti> kirkland, mathiaz: anyway, a normal boot from a raw image seems to work fine
<seb128> pitti, <- want to learn about those too, share? ;-)
<kirkland> pitti: okay, that's good
<kirkland> seb128: <pitti> $ kvm -m 768 -drive if=virtio,index=0,boot=on,file=download/kvm-images/testdesktop.img
<pitti> when does that happen, when I actually do an install?
<seb128> oh, ok
<seb128> thanks
<kirkland> seb128: the magic is "virtio"
<pitti> seb128: I just got that command verbatim from mathiaz :)
<kirkland> pitti: the partition bombed out for me
<seb128> dd takes ages here
<seb128> I'm happy to try something faster ;-)
<pitti> kirkland: "the partition"?
<pitti> seb128: oh, it's a dd'ed image
<kirkland> seb128: oh, well there's also qcow2
<pitti> seb128: that's using an existing image
<seb128> ah ok
<pitti> I always keep that around
<kirkland> seb128: kvm-img create -f qcow2 8G
<pitti> since I constantly do install tests anyway
<kirkland> seb128: will create a sparse file
<seb128> kirkland, thanks
<kirkland> seb128: won't dd the full 8G
<seb128> pitti, keep an empty image and cp it around?
<pitti> seb128: no, I only do one test at a time, so having one image is enough
<seb128> ah right
<pitti> kirkland, mathiaz: doing a desktop install now with virtio
<kirkland> apw: we're discussing the issue here now
<kirkland> apw: i've narrowed the introduction to 2.6.30 vs. 2.6.31
<kirkland> apw: 2.6.30 does not throw /dev/vda errors in the guest
<kirkland> apw: all of the 2.6.31 kernels i've tried from http://kernel.ubuntu.com/~kernel-ppa/mainline/ does
<pitti> kirkland: but sparse files give you worse performance during runtime, won't they?
<pitti> kirkland: or is ext4 etc. clever enough about those?
<kirkland> pitti: i'm not sure about ext4
<kirkland> pitti: but you do generally pay either a space or performance penalty
<kirkland> pitti: i have dozens of vm's around, so i need sparse files :-)
<pitti> now, if vmmouse would work the way it did in hardy (broken since intrepid or jaunty), this thing would be perfect
<kirkland> pitti: ah, where the mouse exits the vnc window?
<kirkland> pitti: i should ask upstream why that regressed
<kirkland> pitti: i think they had a reason for it :-/
<pitti> mathiaz, kirkland: anyway, it's well past the formatting stage, and 25% into installing files
<pitti> no errors in dmesg in either guest or host
<kirkland> pitti: what type of image?
<pitti> all on amd64/2.6.31-3
<kirkland> pitti: raw?
<pitti> yes, raw
<mathiaz> pitti: right - that means qcow2 files are also involved
<kirkland> pitti: okay, i'm trying that now
<pitti> so perhaps it's just qcow + new kernel?
<mathiaz> kirkland: I saw something similar when testing a raid installation
<pitti> I can test with a qcow file later on, too
<mathiaz> kirkland: I had to use raw files instead of qcow2 files
<mathiaz> kirkland: otherwise the RAID install would fail.
<pitti> [21:35]  kirkland| seb128: kvm-img create -f qcow2 8G
<pitti> erm, where does the output file name go there?
<kirkland> pitti: oops
<kirkland> pitti: between qcow2 and 8G :-)
<pitti> oh, just after it
<pitti> wow, that takes like no time
<pitti> -rw-r--r-- 1 martin martin      45056 2009-07-22 21:44 testalt.img
<pitti> sholdn't that show 8 GB?
<kirkland> pitti: nope
<kirkland> pitti: that's the sparse part of it
<pitti> I'm afraid I need to wait until the current test intall finishes
<pitti> I can't start two VMs, my slooow disk and little RAM will go nuts
<kirkland> pitti: so if you want your vmmouse back....
<kirkland> pitti: add -usb -usbdevice tablet to your kvm line ;-)
<pitti> oh, uh :)
<pitti> I thought that was a matter of using a vm-aware mouse X.org driver in the guest
<kirkland> pitti: evidently we switched from vmmouse to evdev
<kirkland> pitti: fwiw, my i have a kvm alias in my bashrc that adds all sorts of fun magic :-)
<pitti> kirkland, mathiaz: so the desktop install and booting that install completed without a hitch (that was on raw); trying qcow now
<kirkland> pitti: confirmed, i saw the same thing with raw
<pitti> kirkland: nice, the tablet trick works; thanks!
<kirkland> pitti: :-)
<pitti> kirkland, mathiaz: hah, reproduced
<kirkland> pitti: qcow, or qcow2?
<pitti> kvm-img create -f qcow2 testalt.img 8G
<pitti> so is it just qcow2? or qcow2+virtio?
<kirkland> pitti: yup, that'll do it
<pitti> shall I try qcow2 without virtio?
<kirkland> pitti: qcow2 + virtio
<kirkland> pitti: you can, that should work just fine
<kirkland> albeit slower
<pitti> ok, I think I rather go back to raw+virtio then :)
<superm1> pitti, ping.  i wanted to ask if devkit-disks had plans to be able to pull this kind of information that I used to get from HAL: http://paste.ubuntu.com/224865/
<superm1> (at least in python)
<pitti> superm1: that's all there already? (label/fstype, etc.)
<superm1> pitti, do you know of any examples of how it's queried though in python then?
<superm1> or is it all listed on some dbus object then?
<pitti> superm1: it is
<pitti> org.freedesktop.DeviceKit.Disks
<superm1> pitti, oh silly me :)
<pitti> superm1: the main object has an Enumerate() thing, and each partition is an object
<pitti> and label etc. are properties of that
<superm1> okay quite easy to switch to then.  thanks!
<pitti> superm1: you could also just use udevadm info for the easy cases
<pitti> udevadm info --query=all --name=/dev/sda1
<pitti> ID_FS_LABEL=ubuntu
<pitti> etc.
<superm1> i was hoping to avoid using subprocess for such things, but if it proves easier that's definitely an option
<pitti> right, if you prefer dbus, calling dk-disks is defintively what you want to do
<pitti> kirkland: alias kvm='kvm -m 768 -usb -usbdevice tablet -drive if=virtio,index=0,boot=on,file=~/download/kvm-images/testdesktop.img'
<pitti> kirkland: any other secret goodness which I should have there?
<pitti> :)
<kirkland> pitti: i use:
<kirkland> alias kvm='kvm -m 512 -net nic,model=virtio -net user -usb -usbdevice tablet'
<kirkland> virtio for network will speed up your network by 10x too
<kirkland> pitti: note that soren disagrees with -net user, but I have forgotten why
<pitti> ok, I'm not much fussed about network performance, but good to know
<pitti> kirkland: will these eventually become the default?
<kirkland> pitti: also, if you're ever testing server images, -curses is a lot of fun too
* mthaddon changed the topic of #ubuntu-devel to: Launchpad will be down/in read-only from 22:00 UTC until 23:00 UTC for a code update | Archive: Alpha-3 soft-freeze | DebianImportFreeze in effect | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-jaunty | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<pitti> they seem like --yes-i-always-want-that options
<kirkland> pitti: virtio requires support in the guest
<kirkland> pitti: for us, that means guests >= hardy
<pitti> ah
<kirkland> pitti: but we don't know what kind of guest the user might run
<kirkland> pitti: windows, solaris, bsd
<pitti> makes sense; I thought it'd be some internal kvm implementation detail
<pitti> like, more efficient access to the .img
<kirkland> pitti: i'd like to push the -m up to 256 by default
<kirkland> pitti: currently, it's 128
<kirkland> pitti: the -usb -usbdevice is debatable, i'll need to understand more about why we switched from vmmouse to evdev
<kirkland> pitti: and the virtio stuff is just too guest specific
<kirkland> pitti: also, note that if you use something like virt-manager, it soups up your kvm line for you
<pitti> tkamppeter: thanks so much for the udevification of s-c-p
<kirkland> pitti: and if you're like mathiaz, you write your own xml machine descriptions by hand, and run them in virsh
<pitti> lol
<kirkland> pitti: alternatively, something like virt-install and vm-builder will spit out xml for you
<pitti> I guess the alias is just fine then, I understand that they can't become defaults just yet
<kirkland> pitti: i rarely have time to fuss too much with that stuff, and like you, just run kvm from the command line
<pitti> my use case for VMs is pretty much "install testing" anyway
<kirkland> pitti: righto
<pitti> kirkland: so, thanks for passing the 1337 stuff :)
<kirkland> pitti: give -curses a try next time you test a server img
<kirkland> :-)
<kirkland> pitti: though, it doesn't work with our server/alternate iso
<pitti> kirkland: will that speed up the hideously slow text interface?
<kirkland> pitti: runs the vm entirely in your term
<pitti> kirkland: in d-i, I can see every single block character being painted
<pitti> oh, nice
<kirkland> pitti: http://www.youtube.com/watch?v=4rBF8byfyvo&eurl=http%3A%2F%2Fblog.dustinkirkland.com%2F2009%2F06%2Fkvms-inside-of-byobu.html&feature=player_embedded
<kirkland> pitti: http://www.youtube.com/watch?v=4rBF8byfyvo
<kirkland> pitti: that's a screencast
<kirkland> pitti: kvm -curses inside of byobu
<kirkland> pitti: one vm per screen window :-)
<pitti> kirkland: I wonder why "michael jackson thriller" is at the top of "similar videos" :-P
<kirkland> pitti: LoL :-)
<kirkland> pitti: i'm going to take that as a compliment :-)
<pitti> awesome
<kirkland> pitti: grub2 kinda breaks it though
<kirkland> pitti: the grub menu is no longer text
<kirkland> pitti: so you can't select your kernel
<kirkland> pitti: but after that, it's back to text
<pgraner> pitti: help!
<pitti> pgraner: hello?
<pgraner> pitti: just updated and gnome-term & nautilus won't run for starters
<pgraner> pitti: on karmic
<pgraner> pitti: you seen this one?
<pitti> pgraner: not so far
<pitti> pgraner: gnome itself starts, though?
<pgraner> pitti: sweet
<pitti> panel, etc.?
<pgraner> pitti: yep, I have xchat up
<pitti> pgraner: can you switch to vt1 and check ~/.xsession-errors ?
 * pitti invokes seb128 to listen as well
<pitti> pgraner: does alt+f2 xterm work?
<seb128> pitti, reading, I'm trying to figure why gvfs-ssh crashes
<pitti> then you could start gnome-terminal from there and watch the output
<pitti> seb128: don't worry, I'll do the triage
<pgraner> pitti: tons of errors in the .xsession-errors  and the xterm did not start
<seb128> can you put the .xsession-errors online?
<pedro_> btw someone reported a similar issue a few minutes ago on bug 403186
<ubottu> Launchpad bug 403186 in gnome-terminal "gnome-terminal doesn't start" [Undecided,New] https://launchpad.net/bugs/403186
<pitti> paste.ubuntu.com (if firefox works) or scp it to rookery?
<pgraner> seb128, pitti: http://pastebin.ubuntu.com/224918/
<seb128> pgraner, lot of non standard softwares there, banshee, skype, etc
<pitti> Key file does not have key 'Exec'
<pitti> WTH
<pgraner> seb128: standard stuff. I was testing banshee, and use skype for work
<seb128> pitti, I bet they have a buggy desktop somewhere
<seb128> pgraner, do you have the issue with a stock user?
<pitti> pedro_: seems unrelated to pgraner's problem
<seb128> pgraner, try moving .config/autostart away
<seb128> seems you have buggy desktops there
<pedro_> pitti, yep agreed
<pgraner> seb128: I don't have one set up let me try
<pitti> pgraner: alternatively, you could temporarily move ~/.config/autostart to ~/.config/autostart-disabled and try to log in again?
<pitti> oops, seb128 already said
<pgraner> seb128: I tried going to System/Admin/Users and got You are not allowed to access the system config
<pitti> pgraner: if that helps, could you please tar the folder and put it somewhere?
<pitti> g-session certainly could behave a  bit better with broken .desktops, the tar file would be a good reproducer
<pgraner> pitti: logging out brb
<pitti> hm, users-admin works for me
<chrisccoulson> pgraner - what version of gnome-session are you running?
<chrisccoulson> your xsession-errors shows it crashing, and that particular crash was fixed some days ago
<pitti> the gnome-session backtrace isn't that helpful, that probalby needs apport love
<chrisccoulson> pitti - that's the one that was exposed after correcting the consolekit policy
<chrisccoulson> it looks pretty similar from the information there anyway
<seb128> chrisccoulson: the crash was not about exec= though
<chrisccoulson> no, the exec things are just warnings. it looks like gnome-session crashes later on though, when doing a dbus call
<pgraner> seb128, pitti: no change
<pitti> pgraner: dpkg -l gnome-session -> which version do you have?
<pitti> dpkg -l gnome-session|cat  (meh)
<pgraner> pitti: 2.26.1-1ubuntu
<pitti> ah
<pitti> pgraner: that would be it then
<seb128> pgraner, weird, that one is outdated by several days, when did you upgrade?
<pgraner> seb128: 30 min ago
<pgraner> seb128: from us.archive.ubuntu.com
<pitti> pgraner: "dpkg -l gnome-session |cat "
<chrisccoulson> yeah, that will be why it's crashing, your gnome-session is out of date
<pitti> pgraner: 1ubuntu3 had the crash fix
<chrisccoulson> and we're on 2.27.4 now anyway
<pitti> unfortunately dpkg -l itself checks the terminal size and cuts it off
<pitti> yeah, seems the us mirror is lagging?
<chrisccoulson> heh. that's why i never use the mirrors
<pgraner> pitti: dpkg -l gnome-session |cat  reports: 2.26.1-1ubuntu2
<pitti> pgraner: ok, thanks; that was known-broken indeed
<pgraner> pitti: whats the best archive to use then?
<pitti> pgraner: so it seems your mirror has the consolekit version which broke it (which was uploaded 8 hours _after_ the gnome-session fix)
<pitti> wierd
<pitti> pgraner: well, ideally us.archive would just work
<chrisccoulson> yeah, i was just thinking that
<pitti> pgraner: you can try archive.u.c., but that'll be slow
<pgraner> pitti: I just ran  "apt-get update && apt-get upgrade" and it told me that it held 14 packages back including gnome-session
<pitti> oh
<pitti> pgraner: you need dist-upgrade
<pitti> "upgrade" is fairly useless in a development release, I'm afraid
<pitti> since we update library APIs, new packages, etc. all the time
<pitti> new gnome-session pulls in a new libxklavier package
<pgraner> pitti: ok, good to know. However I got into this state with update-manager
<pitti> I guess that was it
<chrisccoulson> i'd definately move ~/.config/autostart aside if you haven't done already though. it seems it's full of broken desktop files
<pgraner> chrisccoulson: done
<pgraner> pitti, seb128: that did the trick
<seb128> pgraner, good
<pgraner> all is back to normal
<pgraner> Thanks for the assistance
<brettalton1> Is it possible for me to get mentored to packaged both Code Igniter and Kohana, both php frameworks?
<pitti> pgraner: phew :)
<brettalton1> I've been very interested in doing so for both projects, especially because they will have very little dependencies, so I figured they'd be good projects to learn how to package with.
<spotter> I can't imagine many people are happy with multisearch
<mathiaz> kirkland: I've switched my install test vms to use ide rather than virtio and it fixes the issue
<mathiaz> kirkland: so it seems that there is a regression on qcow2+virtio guests
<kirkland> mathiaz: or, you can use raw+virtio
<kirkland> mathiaz: that works too
<mathiaz> kirkland: true
<kirkland> mathiaz: https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/403215
<ubottu> Ubuntu bug 403215 in linux "2.6.31 guest vm's unable to use qcow2 + virtio" [Medium,Confirmed]
<kirkland> mathiaz: feel free to add to that bug your findings
<mathiaz> kirkland: except that in my use case I don't have space to generate all of the test install guests if I use raw images :/
<mathiaz> kirkland: so I'll use qcow2+ide instead
<mathiaz> kirkland: did you update the release notes?
<kirkland> mathiaz: no, i'm still debugging the problem
<tkamppeter> directhex, you can plug your new Kyocera printer now, the PPDs on OpenPrinting are updated, so system-config-printer should pull the new Kyocera PPD package for you.
<directhex> tkamppeter, awesome!
<Keybuk> kees: kernel already checks for CAP_NET_ADMIN when you talk to it
<Keybuk> and there are thus valid apps that start as root, and drop everything but CAP_NET_ADMIN for their children
<kees> Keybuk: context loss...
<kees> Keybuk: ah, tun.  right
<kees> Keybuk: new issue for you, you said you were going to make sure the debugfs was readable only by root, but that doesn't seem to be.
<Keybuk> I asked kernel people and they said they didn't recommend it
<Keybuk> and that again, any secure info should already be checked for
<kees> Keybuk: and on a 3rd issue, what do you think of this: http://paste.ubuntu.com/225114/
<kees> Keybuk: but does anything non-root need it?  it'd be nice to have a stricter default.
<Keybuk> things in debugfs include the replacement for "/proc/bus/usb/devices" => /sys/debug/usb/devices
<Keybuk> yes, ^
<kees> eww
<kees> not very _debug_ if it's used for production things. :P  ah well
<Keybuk> it's more "things that used to be in /proc but don't belong in /sys"
 * kees nods
<Keybuk> kees: that kind of config belongs in gnome-power-manager
<kees> Keybuk: my server isn't using gnome-power-manager.
<Keybuk> your server is a beautiful and unique snowflake ;)
<kees> *sigh*
<kees> Keybuk: but gpm has nothing that allows for this configuration yet, correct?
<Keybuk> every config option like that costs boot time
<kees> it's after boot -- 60 seconds after boot...
<Keybuk> that script is broken
<kees> heh
<Keybuk> and will be probably be just replaced by devicekit-power or something
<Keybuk> and in the process, your config would be dropped
<Keybuk> anyway, bed
<kees> I would normally add stuff like this to rc.local, but since ondemand is 60s delayed, it's less useful.   okay, g'night
#ubuntu-devel 2009-07-23
* spm changed the topic of #ubuntu-devel to: Archive: Alpha-3 soft-freeze | DebianImportFreeze in effect | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-jaunty | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<meoblast001> hi
<LaserJock> bryce: around?
<bryce> indeed
<pitti> Good morning
<TheMuso> pitti: I see there are currently no studio alpha images on the tracker to test. Has the tracker even been updated for ubuntu/kubuntu etc images yet, or is it just studio that hasn't been updated?
<pitti> TheMuso: I think I just missed it, hang on
<pitti> TheMuso: http://cdimage.ubuntu.com/ubuntustudio/daily/20090722.1/ should hopefully work
<pitti> TheMuso: added to tracker, thanks
<TheMuso> pitti: np thanks.
<superm1> pitti, i may have some livecd-rootfs changes that will fix one of serious bugs for mythbuntu ISOs. i'm verifying right now that it actually fixes things with a local run of livecd-rootfs
<pitti> superm1: thanks; infinity, would a livecd-rootfs upload need any manual treatment for the buildds, or does it "just happen"?
<StevenK> pitti: The buildds will upgrade once a day for livecd-rootfs, but it's at like 1:15am DC time
<pitti> StevenK: ah, thanks
<pitti> superm1: bug 403289, that wasn't due to gdm then? gdm was recently fixed to not pull in gnome-session any more
<ubottu> Launchpad bug 403289 in mythbuntu "9.10 A3 candidate ISO, launches into gnome" [Undecided,New] https://launchpad.net/bugs/403289
<superm1> pitti, i think it's because somehow a recommends is pulling in a whole bunch of gnome because of the order of dependency resolution for live disk builds
<superm1> because mythbuntu doesn't use the tasks for LIST and LIVELIST (some problems earlier this year with doing so)
<pitti> superm1: you're using custom.conf in bug 403290 now?
<ubottu> Launchpad bug 403290 in mythbuntu-common "9.10 A3 candidate ISO, automatic login can't be reconfigured" [Undecided,Fix committed] https://launchpad.net/bugs/403290
<pitti> superm1: (sorry, gdm.conf and gdm-cdd.conf have gone entirely)
<superm1> as for bug 403290, yeah i've adjusted the code to use custom.conf
<superm1> didn't realize gdm-cdd.conf was gone entirely, will be uploading to fix that bug shortly
<superm1> with gdm-cdd.conf being gone, i'm not sure how to fix or even address bug 403291 though
<ubottu> Launchpad bug 403291 in mythbuntu-default-settings "9.10 A3 candidate ISO, default session is not mythbuntu" [Undecided,New] https://launchpad.net/bugs/403291
<StevenK> pitti: Autologin is completly broken for UNR too
<StevenK> pitti: But I suspect you knew that already :-)
 * ogra hugs pitti 
<pitti> StevenK: just trawling through the bugs
<ogra> pitti, thanks for moving udhcpc
<StevenK> superm1: Hmm, perhaps your seeds need some clean up to stop metacity and co getting installed?
<pitti> no prob, got approved recently
<ogra> it will indeed bloat the alternate CD ... with 23k more :)
<superm1> StevenK, any easy way to do such things?
<StevenK> superm1: Easiest way is to check the germinate output, since it contains a "Why" column
<StevenK> superm1: http://people.canonical.com/~ubuntu-archive//germinate-output/mythbuntu.karmic/all
<pitti> StevenK: autologin> you mean bug 403309 ?
<superm1> but since we install with metapackages rather than tasks, is that valid?
<ubottu> Launchpad bug 403309 in gdm "gdm fails automatic login and gets stuck in a loop" [Undecided,Incomplete] https://launchpad.net/bugs/403309
<pitti> StevenK: (just asked for custom.conf there)
<ogra> mvo, !
<ogra> the man i wanted to talk to !
<mvo> hey og
<mvo> ra
<superm1> StevenK, but i suppose if we can rid them from there we can switch to tasks for livecd-rootfs
<ogra> mvo, i want to make it impossible to upgrade from jaunty to karmic for certain armel machines, can you point me to the right place to put a script that checks /proc/cpuinfo ?
<superm1> StevenK, so in looking through that, it claims that metacity comes in from gnome-control-center which comes from gnome-panel, which comes from gnome-panel-dbg, but it doesn't go any further up the chain, so how do I rid that out of there?
<StevenK> superm1: Yeah, I sort of fell over there too
<mvo> ogra: upate-manager and there DistUpgrade/DistUpgradeQuirks.py - if you give me the details (what to look for in cpuinfo)  I can add it quickly for you if oyu want
<superm1> StevenK, so perhaps is there a way I can just blacklist gnome-panel from the seed and hope for the best then?
<ogra> mvo, i'll work out a patch for you, essentially it should block if the "Processor" line of /proc/cpuinfo contains anything thats smaller than ARMv6 or ARMv7, thanks for the pointer
<mvo> ogra: ok, thanks
<pitti> superm1: my feeling is that it's not worth re-rolling the isos just for bug 403290, since a mere upgrade will fix it as well; WDYT?
<ubottu> Launchpad bug 403290 in mythbuntu-common "9.10 A3 candidate ISO, automatic login can't be reconfigured" [Undecided,Fix committed] https://launchpad.net/bugs/403290
<pitti> StevenK: UNR uses autologin by default, which would make bug 403309 kind of a showstopper?
<ubottu> Launchpad bug 403309 in gdm "gdm fails automatic login and gets stuck in a loop" [Undecided,Incomplete] https://launchpad.net/bugs/403309
<superm1> pitti, agree, not just for bug 403290.  bug 403289 and bug 403291 however if a solution can be came up with would be worth a reroll
<ubottu> Launchpad bug 403289 in mythbuntu "9.10 A3 candidate ISO, launches into gnome" [Undecided,New] https://launchpad.net/bugs/403289
<ubottu> Launchpad bug 403291 in mythbuntu-default-settings "9.10 A3 candidate ISO, default session is not mythbuntu" [Undecided,New] https://launchpad.net/bugs/403291
<pitti> StevenK: I'm trying to understand where the autologin configuration happens (gdm itself works just fine with autologin, but behaves that way if you specify an invalid user)
<StevenK> pitti: The livecd does, but doesn't desktop also do that?
<pitti> superm1: right; bug 403291 might need gdm changes, let me check the code about the default session
<pitti> StevenK: it works there (we don't default to it, too)
<pitti> StevenK: I recently fixed that in user-setup (which wrote "AutomaticLogin=ubuntu" instead of $USER)
<StevenK> Ahh
<StevenK> pitti: Right, so it sounds good to get a re-roll for this
<pitti> StevenK: might it be that this bug somehow crept into the UNR image builder as well?
<pitti> StevenK: I don't really know how the .img is put together, I'm afraid; is that a standard live system with ubiquity?
<pitti> StevenK: oh argh, http://cdimage.ubuntu.com/ubuntu-netbook-remix/daily-live/20090722/karmic-netbook-remix-i386.manifest
<pitti> indeed, it has the old ubiquity
<StevenK> pitti: Karmic UNR is now an .iso
<pitti> StevenK: so, if I re-roll them now, can someone test the new images soon?
<StevenK> pitti: Sure
<pitti> started
<pitti> I'll fiddle the bugs now
<superm1> StevenK, is there a nice command I can run to generate that germinate output myself so I can tweak with adding packages to blacklist in mythbuntu.karmic and seeing if that improves things?
<StevenK> superm1: That bit I'm not sure about, sorry
<pitti> superm1: I followed up to bug 403291 with the gdm analysis, FYI
<ubottu> Launchpad bug 403291 in mythbuntu-default-settings "9.10 A3 candidate ISO, default session is not mythbuntu" [Undecided,New] https://launchpad.net/bugs/403291
<pitti> superm1: however, I don't think we'll manage to fix this in the next couple of hours, TBH
<pitti> superm1: so perhaps mythbuntu A3 could/should be released later? or you just skip A3 entirely?
<superm1> pitti, if 403289 can be sorted out, we can go out a little later, otherwise we'll have to skip A3
<superm1> based on your analysis, i agree that bug 403291 would likely be a moot point if 403289 is solved
<ubottu> Launchpad bug 403291 in mythbuntu-default-settings "9.10 A3 candidate ISO, default session is not mythbuntu" [Undecided,New] https://launchpad.net/bugs/403291
<pitti> superm1: I'm just on holiday from tomorrow until Tuesday, so we'd have to defer it for a bit
<superm1> pitti, ah i see.  well i'll spend a little more tonight playing more with germinate.  if no luck then we'll plan to evaluate options after the weekend then
<superm1> and i'll discuss it with my team and see what they think is the best
<pitti> superm1: I'm sorry for that :/
<pitti> lol, I just got two spam mails from facebook which want to become friends with "Apport"
<ttx> pitti: we should start a LP group first. 'Apport facebook friends'
<pitti> neither Apport nor me personally have ever come close to Facebook, so I wonder why I get these now :/
<ttx> beh
<pitti> StevenK: http://cdimage.ubuntu.com/ubuntu-netbook-remix/daily-live/20090723/ (also added to tracker)
<StevenK> pitti: Thanks!
<pitti> would be cool if you could give them a quick test
<pitti> TheMuso: hm, I don't see ubuntustudio in earlier alpha announcements, how is that usually handled? do you send our your own announcement?
<pitti> TheMuso: then again, there's no karmic/ on http://cdimage.ubuntu.com/ubuntustudio/releases/
<superm1> pitti, okay it appears that the livecd-rootfs change i made got rid of most of the gnome stuff and kept what mattered
<pitti> superm1: nice
<superm1> so if you can reroll with the newer livecd-rootfs, I can grab in the morning and verify
<pitti> superm1: as StevenK said, the buildds will only upgrade in about 15 hours :/
<pitti> so, plenty of time to get it tested and uploaded
<pitti> superm1: but that way you could annouce mythbuntu alpha-3 on Monday or so
<superm1> pitti, okay that should be fine.  gives extra time to mirror and what not too after testing
<pitti> superm1: I won't be there, but I'm sure Riddell or someone else will push the publish-release button for you
<StevenK> pitti: But it can be done manually
<pitti> StevenK: right, but both lamont and infinity are asleep right now
<TheMuso> pitti: we didn't release previous alphas due to problems that hadn't been addressed by the time those alphas came out
<TheMuso> related to the realtime kernel
<pitti> TheMuso: ah, so want me to release this one now?
<tseliot> pitti: if I wanted to add the support for collecting data from touchpads to apport, what part of apport should I work on?
<pitti> tseliot: package hook for xserver-xorg-input-synaptic?
<tseliot> pitti: yes, exactly
<pitti> tseliot: it probably should be added to the generic xorg package hook
<pitti> /usr/share/apport/package-hooks/source_xorg.py
<pitti> tseliot: all other X packages symlink to that
<pitti> tseliot: it's in x11-common I think
<pitti> (dpkg -S)
<tseliot> pitti: also, could I add a small C program (with no external dependencies) that I wrote?
<tseliot> it simply uses a system call to extract data from the touchpad
<pitti> tseliot: you can't do that in Python?
<pitti> tseliot: the package is currently arch:all
<pitti> tseliot: but of course you could add that helper to the -synaptics package, and call it from the hook
<tseliot> pitti: no, it can't be done from Python
<tseliot> pitti: but yes, I can add it to -synaptics as you say
<pitti> tseliot: what does it need to do?
<tseliot> pitti: the C program lists input devices and extracts their ids, names, etc.
<tseliot> this would be useful for quirks
<tseliot> furthermore I would like to collect the output of xinput too
<pitti> tseliot: isn't that pretty much what udevadm gives you arleady?
<tseliot> pitti: it's what lsinputs does but I stripped it down and changed a few things
<tseliot> pitti: I've just tried udevadm but it doesn't give me what I need
<pitti> TheMuso: did anyone test the current studio images? iso tracker says 0/4
<pitti> StevenK: does the current UNR image now do what it should?
 * ccheney is so tired
<ccheney> been up since Jul 22 13:00 UTC
<StevenK> pitti: I'm still having a look
<ccheney> another 9-10 hour before i can go to sleep too :-\
<pitti> ccheney: jetlag?
<ccheney> pitti: i can't sleep on planes and flew to madrid then have a 6 hour layover before the train to caceres
<ccheney> really its more  i can't sleep sitting up
<pitti> ccheney: ah, debconf?
<ccheney> yea
<ogra> ccheney, july 22 ? which year ?
<ccheney> ogra: er yesterday ;-P
<ccheney> so about 30 hour or so when i finally get to the hotel
<StevenK> ccheney: Not even things like Melatonin help?
<glatzor> servus mvo
<pitti> hey glatzor
<glatzor> mvo, I reimplemented the twisted deferreds using the gobject main loop
<ccheney> StevenK: i didn't try it this time but in the past it didn't seem to
<Keybuk> pitti: why is there a udev task on bug #403381 ?
<ubottu> Launchpad bug 403381 in udev "jaunty->karmic server upgrade results in two versions of postgresql installed" [Medium,In progress] https://launchpad.net/bugs/403381
<pitti> udev? that's wrong
<ccheney> StevenK: of course my flight wasn't that long just managed to lose the night in the process, the main flight started at the equivalent of ~ 4pm for me and was only 7-8 hr long
<Keybuk> pitti: you added it ;-)
<pitti> argh
<pitti> Keybuk: accidentally clicked on a canned response, sorry
<pitti> fixed
<pitti> but I'm sure that we could have fixed it in udev as well :-P
<mvo> hey glatzor
<mvo> glatzor: you rock!
<ccheney> StevenK: melatonin seems to help reset my internal clock though when i finally do go to bed after travelling
 * mvo hugs g'magic'tzor
<glatzor> servus pitti
<dpm> morning pitti, I'm having a look at the translations imports queue for karmic, and I've noticed a few debian/po-up/patches.pot (for e.g. gnome-panel) and similar templates. Without having had a closer look at it before, I always assumed that patches were first applied and then a single template was produced (when the package had only one). Is this something new or am I missing the point?
<dpm> what are those templates?
<seb128> dpm, those are a debian thing to do translations for debian changes
<dpm> seb128: is this a common practice? Could we somehow track the Ubuntu/Debian translation changes due to patches with those?
<seb128> dpm, no it's marginal I think we should not bother and just use launchpad
<dpm> seb128: ok, thanks. I was just wondering, because (without having thought oo much on the implementation) perhaps it could be used to mark in Rosetts those strings which are only specific to Ubuntu. But then again, it might also introduce a special case in Launchpad which would not be desirable.
<seb128> dpm, all debian changes are not marked this way though
<dpm> ok, but within a single package which produces a separate .pot for patches, are generally all changes which affect strings collected in a single separate template?
<seb128> dpm, it seems so
<StevenK> pitti: Autologin looks great with the new spin
<pitti> \o/
<dpm> seb128: is it trivial to produce those separate templates for patches? I'm just wondering whether it would be useful to try to generalise that practice
<seb128> dpm, should be trivial, it's a one line cdbs rules
<seb128> dpm, I've not been looking to much into that I don't want po in the source package since that means you need upload to change translations
<seb128> dpm, debian do that because they have no language packs they can use
<pitti> StevenK, lool: http://cdimage.ubuntu.com/releases/karmic/alpha-3/ currently talks about the UNR "CD"
<pitti> given that it's way over 700 MB, what should it say instead? Are people expected to use usb-creator to write an image?
<dpm> seb128: but this would just introduce a change in which we have the same situation as now (package produces a pot on build) plus a second template for the patches also generated on build, wouldn't it? Is it not how it is done in gnome-session? That's one of the packages where I first spotted this additional template.
<seb128> dpm, I don't know the specific, I never used the system, it just add lot of cruft in the source package since it build template and po for all of those in the debian directory
<seb128> dpm, look the gnome-session source for details
<dpm> seb128: I'll do, thanks
<seb128> dpm, in fact I was cleaning that cruft out in some packages when I resynced on debian, I think it doesn't bring us anything and is noisy
<pitti> Riddell: is there an equivalent for usb-creator in Kubuntu?
<pitti> i. e. something that people can use to put an .iso to an USB stick?
<seb128> pitti, the bzr version of usb-creator has a kde variant now
<seb128> pitti, I'm waiting for that to land in karmic for some weeks now to switch it to gtkbuilder dunno why they don't upload to karmic
<seb128> evand, ^
<pitti> so how do KDE folks test these images then?
<dpm> seb128: by cleaning that cruft you mean getting the package to build one single pot as usual? I think this might be the best approach for now, as otherwise I don't know what to do with those extra templates in the import queue. I think it might be worth considering if they might be useful in the future as I was saying earlier, but for now it think it might be best to stick to the more general practice of building one single template
<evand> seb128: I'll do it now.  I've been hoping to finish the devicekit backend first, but that's not going to happen quickly
<pitti> StevenK, lool: please cross-check http://cdimage.ubuntu.com/releases/karmic/alpha-3/, I updated the desdcription
<seb128> evand, thanks, will you port the gnomevfs code to gvfs? or patches are welcome for that? same for gtkbuilder
<evand> patches are welcome, but if no one else steps up, I'll surely fix those problems before UI freeze
<pitti> evand: you are actually using dk-disks, or libgdu? (the latter should be much nicer)
 * Riddell just tests netbook images from DVDs currently
<evand> pitti: dbus to devicekit
<pitti> evand: devicekit-disks, I assume
<evand> err devicekit-disks
<pitti> ok
<evand> yes
<seb128> evand, ok, I will rank it low on my list, I would prefer to focus on things which will not get done otherwise ;-)
<evand> seb128: sure thing :)
<pitti> Riddell: ok, I'm fine with changing the text to "DVD", if that's fine with you for alpha-3?
<ogra> pitti, does devicekit-power still have APM support or did it completely switch to ACPI only ?
<seb128> evand, in fact I did the gtkbuilder conversion locally but you have a very weird hack which I blocked on
<evand> oh?
<seb128> evand, some
<seb128>         for widget in self.builder.get_objects():
<seb128>             if isinstance(widget, gtk.Label):
<seb128>                 widget.set_property('can-focus', False)
<seb128> evand, that's the non working gtkbuilder version
<evand> ahh, that can probably go away
<Riddell> pitti: have the UNR guys expressed an opinion?
<pitti> ogra: well, neither really; it just uses /sysfs
<evand> it was there to address a bug in ubiquity, if memory serves
<evand> and it somehow got copied over
<pitti> Riddell: I pinged them above, but no response yet; I changed it to usb-creator for now
<seb128> evand, well it seems it's to make text not being selected when using tab
<ogra> pitti, oh, i thought it inly looked in the acpi subpaths
<seb128> evand, but if gtk does it that's for a reason, ie no need to try to change it by weird hacks in your software, better to be consistent with other applications
<pitti> ogra: sysfs_get_string (native_path, "status") for battery status, etc.
<evand> seb128: indeed
<pitti> ogra: and pm-utils for the suspend/resume stuff
<evand> I'll tear it out in trunk
<pitti> (which also uses sysfs)
<ogra> ah, ok so it doesnt restrict itself to /sys/bus/acpi/
<ogra> (i'll likely need to look into APM support for armel)
<pitti> i. e. whatever is behind (APM/ACPI) should export proper sysfs attributes, then it should just work
<mat_t> Keybuk: hi
<ogra> yep
<ogra> so its a kernel thing then, thanks
<Keybuk> mat_t: hi
<mat_t> Keybuk: is there a maximum number of legacy OSs that can be installed at the time?
<ogra> (or udev FWIW)
<pitti> ogra: udev can't change /sys
<ogra> ok
<mat_t> Keybuk: I'm asking primarily in the context of the OS switcher
<Keybuk> mat_t: is there a maximum length to a piece of string?
<lool> pitti: Looks good
<lool> pitti: "Choose this if you are at all unsure." in the only UNR image is a bit too much
<Keybuk> mat_t: any limit I tell you today will almost certainly be wrong in a year's time ;-)
<mat_t> Keybuk: I see
<pitti> lool: heh, ok
<Keybuk> mat_t: so design and code for no limit
<lool> Otherwise ok
<pitti> lool: removed
<lool> (I wonder where the up to 10" comes from though)
<mat_t> Keybuk: perfect, thanks :)
<lool> I've seen people run UNR on regular laptops :)
<StevenK> lool: It's probably hysterical raisins now
<sebner> pitti: seems there is now also a workaround for me :) (regarding the external harddrive problem - you are debugging it with someone else again)
<pitti> sebner: bug 387161? what is it?
<ubottu> Launchpad bug 387161 in linux "Koala: External SATA->USB Drive no longer being identified properly" [Medium,Triaged] https://launchpad.net/bugs/387161
<sebner> pitti: yep, just discovered that my bug was marked as duplicated of this bug, /me is going to uninstall devicekit-disks later to see if this also fixes the issue for me
<pitti> it's just a short-term workaround, though
<sebner> pitti: of course but better than nothing. /me is just wondering why this is working because I thought devicekit-disks is *needed* to deal with hardware
<pitti> sebner: right, gnome is using it now
<sebner> pitti: why is a external drive then working when it is needed for hardware and gnome using it? ^^
<pitti> sebner: that's a miracle
<sebner> lol
<sebner> pitti: the magic of open source? *cough*   might it have any negative effects if I remove it, besides that it might fix my external harddrive?
<pitti> sebner: did you reboot after removal? or sudo killall devkit-disks-daemon?
<pitti> gvfs doesn't build the hal monitor any more
<sebner> pitti: didn't remove it yet
<pitti> so it shouldn't be able to detect usb sticks and the like any more
<pitti> oh
<sebner> pitti: so downgrading gfvs as well?
<pitti> sebner: you probably need to
<sebner> pitti: argh, removing devicekit-disks will remove half of my system
<pitti> sebner: well, you can't remove dk-disks without removing gvfs, it's a dependency
<pitti> and GNOME depends on gvfs
<pitti> anyway, food time
<sebner> pitti: it seemed possible though ?!
<sebner> hf
<tseliot> pitti: my program requires root privileges. Can it still be used by an apport hook?
<maxb> The postgresql-common upload to karmic today - why is that 100.1 instead of 100ubuntu1 ?
<mok0> maxb, probably a nmu
<maxb> mok0: I don't understand
<maxb> It was a direct upload to Ubuntu, not a sync
<mok0> maxb: merged nmu?
<maxb> A merge would normally still have "ubuntu" in its version string
<geser> maxb: probably a glitch from pitti as he's also the debian maintainer for it
<mok0> maxb, it's an nmu synced from debian afacs
<maxb> mok0: The changesfile lists the distribution as karmic, so I prefer geser's explanation
<maxb> Also, "100.1" isn't a nmu version string
<mok0> maxb. yeah
<mok0> maxb: 100 is latest debian release
<maxb> yup. A nmu would be labelled as 100+nmu1
<mok0> maxb, I assumed you were quoting a version string before checking
<maxb> I was quoting a version string?
<mok0> maxb: no :-)
<maxb> Sorry, I mean: I *was* quoting a version string, are you suggesting I wasn't?
<mok0> maxb I thought you were quoting the release part of the version string
<maxb> aha :-)
<mok0> maxb, I was wondering about the huge number
<maxb> mm, 100 debian revisions for a single upstream would be impressive
<maxb> though sysvinit is more than half way there
<geser> cron is at -106 already
<mok0> implies very low upstream activity
<mok0> the postgresql-common problem is discussed  in bug 403381
<ubottu> Launchpad bug 403381 in bacula "jaunty->karmic server upgrade results in two versions of postgresql installed" [High,Fix released] https://launchpad.net/bugs/403381
<mok0> looks like it could be a temporary fix
<mok0> and that pitti wants it to go away automatically at next sync
<geser> very low activity indeed: -35 was uploaded in Dec 1996 (the Debian changelog doesn't reach further back)
<mok0> geser: cron is a legacy package now, right?
<hyperair> it is? why would it be?
<mok0> Because anacron is being installed by default
<mok0> And aren't there discussions about moving to Apple's launchd ?
<hyperair> don't they do separate things?
<mok0> hyperair: afaik launchd is a reimplementation of cron
<hyperair> is it?
<hyperair> hmm
<hyperair> (i was referring to anacron vs cron)
<mok0> but with better security and flexibility
<ion> launchd is more than crond.
<mok0> hyperair: ah
<hyperair> what's wrong with crond?
<hyperair> and we don't have a launchd package around, do we?
<mok0> hyperair: I imagine it has something to do with the /etc/cron.d/ directories
<hyperair> hmm
<hyperair> oh yeah, that.
<mok0> hyperair: so packages can drop files in there
<hyperair> so how would you secure something of that sort?
<hyperair> without losing the said functionality
 * mok0 googles crond vs launchd
<pitti> tseliot: no, I'm afraid not
<ion> Upstart will implement the cron/at/anacron/whatever functionality in the future. Upstartâs design is better than launchdâs IMO.
<pitti> geser:, maxb, mok0: it was a bzr head snapshot
<pitti> no reason to upload to debian for just that
<pitti> and the next time it will autosync, right
<tseliot> pitti: ok, thanks
<mok0> http://arstechnica.com/apple/reviews/2005/04/macosx-10-4.ars/5
<ogra> mvo, mind to take a look at http://paste.ubuntu.com/227208/ ?
<ion> mok0, hyperair: http://www.netsplit.com/2006/08/26/upstart-in-universe/ heading âHow does it differ from launchd?â
<glatzor> mvo,  You can take a look at the new code: lp:~aptdaemon-developers/aptdaemon/gdefer
<glatzor> mvo, I've only converted the GetTrustedVendorKeys method to the new gobject based deferreds
<glatzor> mvo, yet. I am away now for some days! See you.
<mok0> ion, ah, so it's upstart rather than launchd
<ttx> doko: about doublechecking if a MIR is really needed: I was thinking on reviewing package bug history, is there any better way, like some official list of MIR-ed packages ?
<ion> http://upstart.ubuntu.com/faq.html#replace-cron
<mok0> ion, oh crond (launchd) capability is _planned_ but not currently in upstart
<doko> ttx: I would just look at Sources from jaunty if the package was in main
<ion> crond is still not equal to launchd.
<ion> In some areas, Upstart is far beyond launchd in functionality.
<ttx> doko: ok, thx
<mok0> ion, apple uses launchd to replace crond
<ion> Yes
<ion> As well as inetd and initd.
<mok0> ion, didn't know that
<mok0> ion, although I am typing this from my Powerbook G4 :-)
<hyperair> hmm the article said that upstart was to have reached stage #6 by edgy+2, which was gutsy.
<hyperair> that's so long ago, and we're not even there yet! =O
<mok0> From upstart webpage "Events may be received from any other process on the system" -- I hope there's a decent authorization system in place
<hyperair> what kind of events do you want to limit access to?
<ion> The usual. If you have write access to initâs UNIX socket or the system bus, you can talk to init.
<ion> /etc/dbus-1/system.d/Upstart.conf
<mok0> If a single process controls almost everything, it also gives blackhats more options for making trouble
<mok0> Just sayin'
 * ogra wonders if mok0 is aware of the PID init had since it existed
<hyperair> i wouldn't say that.
<hyperair> i think it's more of giving blackhats something to focus on attacking.
<hyperair> rather than giving them more options
<mok0> ok
<ion> Instead of D-Bus handling the access policy, so you have a single chunk of code to audit, every piece of software should NIH its own, so you have to audit all of them?
<mvo> ogra: looks good, just commit
<ogra> mvo, thanks :) not hard to understand the code :)
<mok0> ion, good point
<mok0> ion, but the fundamental design better be right
<ion> Feel free to inspect the fundamental design.
<hyperair> NIH = ?
<mok0> ion, I'm not qualified for that
<ogra> hyperair, Not Invented Here
<Chipzz> ion: I think the fundamental design is broken
<Chipzz> but that's just my opinion
<hyperair> ah.
<hyperair> broken how?
<mok0> ion, just slightly concerned when several very well tested systems get replaced by a single piece of software
<mok0> ion, NEW software
<Chipzz> one central daemon that is needed and when breaks, would call huge amounts of havoc
<mok0> Chipzz: exactly
<hyperair> that's the entire purpose of init isn't it?
<hyperair> if init breaks, you get huge amounts of havoc
<mok0> hyperair: yes, but will it work?
<Chipzz> hyperair: and the dbus developers have, IIRC, always had a "Distro's go fuck yourself, dbus isn't designed to be restarted" attitude
<Chipzz> hyperair: init is a LOT less complex than dbus
<mok0> hyperair: init has been tested on? hundreds of mililons of systems?
<Chipzz> and now you need dbus and god knows what just to log in
<hyperair> mok0: upstart has been ubuntu's init for some time already.
<ion> Upstart runs just fine without D-Bus. Even handles D-Bus restarts. Also, Upstart has been running on â how many Ubuntu users are there again? â for many releases by now. Oh, and i bet Upstart has a more comprehensive test suite than sysvinit. :-P
<Chipzz> sounds like looking for things to break
<Chipzz> ion: I'm not criticizing upstart
<mok0> neither am I
<Chipzz> my critique is wrt dbus and the whole santa-boutique of *kits
<hyperair> upstart isn't about to engulf dbus.
<hyperair> i don't see the point of comparing upstart with dbug
<hyperair> dbus*
<ion> Iâm not saying D-Bus doesnât suck. Iâm still quite confident D-Bus wonât let $randomuser get root access from Upstart, which seemed to be the original doubt.
<mok0> hyperair: ok
<Chipzz> I think yesterdays breakage cjwatsons, and who elses? don't recall desktop proved my point very nicely
<hyperair> what breakage?
<Chipzz> part of ecrypt breaks, and sudo/login get broken
<Chipzz> bad
<Chipzz> BAD
<Chipzz> BAD DESIGN
<hyperair> sudo got broken?
<hyperair> and i have no interest in ecrypt, so i don't really bother with that
<Chipzz> which is why I don't like the whole idea of dbus and the whole bunch of *kits
<hyperair> i'm more interested to know what went wrong that caused sudo to break.
<Chipzz> read the backlog or ask someone who can give more detail
<hyperair> and break in what way
<Chipzz> segfault
<hyperair> O_o
<Chipzz> no logins possible, sudo segfaults
<hyperair> i had nothing of that sort.
<hyperair> at least, my sudo never segfaulted, and i didn't log out for a very long time
 * ogra wouldnt call that an encfs design flaw
<ogra> rather a pam one
<hyperair> oh it's pam eh.
<hyperair> that reminds me. someone was complaining about kdesu breaking in #ubuntu-kernel, claiming it to be the fault of the kernel.
<pitti> hyperair: well, a major point of ecryptfs is to hook into the login process, i. e. PAM
<ogra> but if you can confuse the login process with a broken third party hook thats a flaw in the login system imho
<Chipzz> pitti: reading the backlog pam wasn't involved in that?
<pitti> Chipzz: sure, ecryptfs ships a pam module which segfaulted
 * hyperair uses cryptsetup-on-lvm
<pitti> it wasn't the pam package itself, of course
<Chipzz> pitti: then I misunderstood the whole debacle
* pitti changed the topic of #ubuntu-devel to: Alpha 3 released! | Archive: Open, DebianImportFreeze | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-jaunty | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<ttx> pitti: congrats !
<pitti> thanks to all involved!
 * ogra applauds
<DktrKranz> pitti: now that Alpha 3 is out, mind giving a look at bug 401953 when you have some time?
<ubottu> Launchpad bug 401953 in cdbs "cdbs creates empty bogus directories if Python files are not installed in /usr/lib/python*" [Low,Confirmed] https://launchpad.net/bugs/401953
<pitti> DktrKranz: oh, that makes a lot of sense
<pitti> dpkg apport | grep -- -packages
<sebner> pitti: workaround is working now (after downgrading gvfs and uninstalling gvfs), I have mount the harddrive/usb-stick manuall and the sticks are only usable as root but at least it's working :D
<pitti> ah
<sebner> pitti: uninstalling devicekit-disks of course, sry
<pitti> I figured :)
<sebner> pitti: I'm curious how long this workaround will be working though
<sebner> pitti: or even more when devicekit-disks is fixed :P
<Laney> what is the problem?
<sebner> Laney: external harddrive not usable. Downgrading gvfs and uninstalling devicekit-disks is the only workaround so far
<Laney> interesting
<sebner> Laney: annoying might be a better word :P
<pitti> sebner: hm, for me it takes some 30 seconds until nautilus can open them, but otherwise they seem to work
<pitti> it almost feels like the old gutsy bug where we had to set a special mount option to speed up vfat dir reading from 5 minutes to 2 seconds ("usefree" option)
<sebner> pitti: I have to mount them manually so dunno
<ion> I wanât (wannot) getdeb.net indeed.
<sebner> pitti: waha! just discovered that they are automounted now (reboot after uninstalling devicekit-disks)
<pitti> sebner: sure, by hal
<sebner> hal \o/
<pitti> or, by gvfs/nautilus through hal
<sebner> pitti: /media contains now usb (symlink) and usb0 - usb7 though. dunno why
<pitti> sebner: just added some more requests for debug output to bug 387161; perhaps you can do that on a karmic live CD?
<ubottu> Launchpad bug 387161 in linux "Koala: External SATA->USB Drive no longer being identified properly" [Medium,Triaged] https://launchpad.net/bugs/387161
<ogra> pitti, you mean its not because i'm remotely logged in to his desktop and mounted it ? :)
<pitti> ogra: sorry, context?
<ogra> <pitti> or, by gvfs/nautilus through hal
<ogra> sorry, bad joke
<pitti> ah
<sebner> pitti: nah, posting instructions *before* I downgraded :P heh, but of course when I have time I'll try it with a karmic live cd
<pitti> sebner: just downgrading gvfs shold be enough, you could leave dk-disks instlaled even
<pitti> sebner: and try devkit-disks --mount /dev/sd...
<pitti> gvfs/gnome will still use hal
<sebner> sounds reasonable
<dupondje> gvfs & samba also broken :(
<pitti> DktrKranz: hm, after building apport with that patched cdbs, the apport package still has empty ./usr/lib/python2.6/dist-packages/ and ./usr/lib/python2.5/site-packages/ dirs..
<pitti> aah, ?.?
<cjwatson> apw: just in case any of you guys were thinking about it, please don't turn on CONFIG_X86_PAT :-)
<cjwatson> apw: joeyh and I just spent several hours debugging why Debian's d-i wouldn't boot in qemu and Ubuntu's would, and it turned out to be because Debian had enabled CONFIG_X86_PAT
<apw> cjwatson, heh thanks for the warning ... on my scarey list
<DktrKranz> pitti: yeah, it creates /usr/lib/python?.?/site-packages
<ogra> cjwatson, but its more modern than MTRR :P
<superm1> pitti, once livecd-rootfs updates on the build machine, will doing the new mythbuntu iso with the updated livecd-rootfs need a manual prod, or is the cron still activated?
<Riddell> 19 6 * * *      buildlive mythbuntu; for-project mythbuntu cron.daily-live
<Riddell> superm1: so if you wait until 6 tomorrow morning it'll get made
<Riddell> or you can just ask me
<superm1> Riddell, well if livecd-rootfs updates on the build machine sooner than that, doing it sooner would be better so that we can get testing and mirroring done sooner
<superm1> StevenK said it updated at 1:15am DC time
<Riddell> superm1: do you want me to do anything?
<superm1> Riddell, if you can update livecd-rootfs sooner and kick off a build, that would be good. if you can't update it, then after it updates, kicking a build then would be good
<Riddell> after what updates?
<superm1> i uploaded a newer livecd-rootfs that is needed to fix bug 403289
<ubottu> Launchpad bug 403289 in mythbuntu "9.10 A3 candidate ISO, launches into gnome" [Undecided,New] https://launchpad.net/bugs/403289
<superm1> StevenK said that the process to update on the build machine is automatic, but it only happens once a day normally
<Riddell> oh hmm, maybe
<Riddell> superm1: sounds like a job for a sysadmin, try asking in #canonical-sysadmin ?
<superm1> Riddell, okay.  will do
<birthdaylogger> james_w: hey, can the gtk-module.so be moved out of the packagekit main package? kpackagekit deps packagkit and packagekit (due to the gtk-module) deps gtk, so gtk ends up in a Kubuntu installation while it should indeed not
<rickspencer3> in terms of pythonic design ... is it proper to have a property that gets a different value than it sets
<rickspencer3> in this case,  list_of_dicts = couchwidget.selected_rows
<rickspencer3> but
<rickspencer3> couchwidget.selected_rows = list_if_ints
<rickspencer3> ?
<rickspencer3> pitti: lool: ^ thoughts?
<rickspencer3> oops, I said "value", but meant "type"
<lool> rickspencer3: Hmm I think I'd need more context but that's probably ok as long as it's clear from the comments/inline doc
<rickspencer3> perhaps selected_rows should be read only ... and select_rows(list_of_ints) would go with it?
<dvestal> rickspencer3: The logic of doing that makes sense, but I would probably lean more toward using an "indexes" property to set the selection with a list of indexes. that way you have list_of_dicts = couchwidget.selected_rows and couchwidget.selected_row_indexes = list_of_ints. otherwise something like you just mentioned regarding the read-only property and a setter method.
<rickspencer3> dvestal: hmm
<dvestal> although, doing it with the indexes property would actually require a setter method anyway to be able to modify the other property.
<rickspencer3> in fact, perhaps couchwidget.selected_indexes could be a read/write property?
<dvestal> the read-only property and a setter method may be the best way to do it.
 * rickspencer3 nods
<rickspencer3> or perhaps the whole list_of_ints for indexes is too implementation specific
<rickspencer3> the developer should rather provide a list of records to select ... the fact that they are displayed in a treeview with a listmodel shouldn't be exposed in the widget api?
<dvestal> rickspencer3: i don't know that a list of indexes is too specific for a list of items, but that's more dependant on how it's being used. i come from more of a web application background; so i tend to lean toward an index + lightweight textual value for lists and that may not be the most appropriate in all circumstances.
<kirkland> bryce: hi
<kirkland> bryce: what should and shouldn't work, as i insert and remove my thinkpad x200 to/from the docking station with an external monitor
<kirkland> (intel video, karmic)
 * kirkland misses ctrl-alt-backspace for the first time in a while
<maco> hey guys, im trying to do the thing with bzr & debian/changelog & debcommit and then pushing to lp and merge request...what do i put for the release in debian/changelog? "UNRELEASED" or -proposed?
<tjaalton> kirkland: c-a-b should work just fine in your session, if you just enable it from the kbd capplet
<ogra> jdstrand, why doesnt gufw have a simple "internet connection sharing" checkbox anywhere ? it already makes firewalling a breeze, but NAT seems to be missing
 * kirkland is less productive when his sound is broken
 * ogra sings a bit for kirkland 
<kirkland> :-)
 * kirkland hugs ogra 
<ogra> :)
<kirkland> anyone else having sound issues?
<ogra> worked this morning when i watched the news in flashplayer
<ogra> RB works
<kirkland> ogra: yeah, that's funny, flash sound is working, but rhythmbox, xmms are not
<ogra> just fired up RB
<ogra> plays fine
<ogra> kirkland, did you check the sound profile ?
<ogra> probably these apps are muted
<ogra> (we have per app settings now)
<kirkland> ogra: where is this magik?
<kirkland> sound preferences -> output ?
<kirkland> i only have stereo audio
<ogra> right click the new volume control
<kirkland> right
<kirkland> applications
<kirkland> "No application is currently playing or recording audio"
<ogra> last tab, "applications"
<kirkland> which is wrong
<ogra> oh
<kirkland> firefox/pandora is playing music
<ogra> i have firefox-3.5 and RB ... both with volume controls
 * kirkland frowns
<ogra> probably ask TheMuso
<ogra> though its a very bad time for him
<kirkland> ogra: okay, thanks
<jdstrand> ogra: re gufw> a) I don't develop gufw and b) ufw doesn't support NAT via the cli command yet
<ogra> oh, i thought it did
<ogra> well, it would be a cool feature to have
<jdstrand> ogra: it is planned, but only after all the host-based stuff is there
<ogra> ok
<ogra> its just something i have to deal often with in #ltsp ... so i was wondering
<jdstrand> ogra: specifically filtering by interface (which will be in 0.28) and egress filtering (which will be sometime after that)
<ogra> sweet
<jdstrand> ogra: there is an example of doing NAT in /usr/share/doc/ufw/README.gz under 'Advanced Configuration', and I'm pretty sure help.ubuntu.com also has a recipe
<jdstrand> ogra: ufw can do it (it can do anything iptables-restore can do), it just isn't exposed via the cli command yet
<jdstrand> ogra: and therefore gufw doesn't support it yet
<ogra> right, but after all users currently seem more comfortable with iptables-save and editing /e/n/i
<jdstrand> ogra: whatever someone wants to use to get their work done is fine be me. :) the point I was trying to make is that if you want to use ufw generally, but just want a NAT rule, then you can do that
<ogra> well, i would prefer to tell users to do "ufw enable nat" "ufw save" :)
<ogra> or something along that
<jdstrand> ogra: ack, but not this cycle :)
<ogra> understood :)
<mathiaz> does anyone has an example of a python package that uses cdbs+distutils?
<mathiaz> *have*
<pitti> mathiaz: apport, jockey
<mathiaz> pitti: thank you :)
<mathiaz> pitti: IIUC lp:apport/ is the upstream branch, while lp:~lp:~ubuntu-core-dev/ubuntu/karmic/apport/ubuntu is the packaging branch?
<pitti> right
<pitti> mbiebl: hm, CK 0.3.1 released, also with PK 1.0; seems we can't hold it back much longer in Debian ..
<pitti> just uploaded to ubuntu, but can't commit it to pkg-utopia yet (no polkit-1)
<maco> is it normal for changes to exist in -security that dont exist in -proposed
<pitti> maco: rare, but happens
<pitti> maco: if a package in -proposed doesn't get verified for a while, and a security update comes in between and "shadows" it
<kees> maco: if by "changes" you mean non-security-changes, it's like pitti says.
<kees> maco: what are you specifically examining?
<maco> i just made a change to sudo for hardy-proposed and did a merge request for ubuntu/hardy/sudo/hardy-proposed and found that the diff between what i put and what's in hardy-proposed right now includes your last change in -security, kees
<kees> maco: ah, then, yes, -security skips -proposed.  only very rarely will a security update go through -proposed.
<maco> oh ok
<kees> you need to always base uploads to -proposed on the most recent version in either -updates or -security.
<maco> i did it against hardy-updates. its the same as hardy-security though
<kees> maco: right, so a diff between the old -proposed version and the new -proposed version will contain the changes between old -proposed and -updates/-security and your new changes.
<maco> ok
<maco> just didnt expect that
<CardinalFang> Hi all.  I have a packaging question.  I have package "foo".  I want to split it into "foo" and "foo-ui".  I want upgraders to get "foo-ui" (which depends on "foo"), but I don't want to require "foo-ui" to be installed for new users or after the upgrade.  What package relationships should I use?
<geser> CardinalFang: that seems not to be possible. what might work is renaming "foo" to "foo-backend" (or whatever) and introducing a transitional package "foo" which depends on "foo-ui".
<sebner> geser: sebner bot is now a sponsoring bot, already ACKed ~15 sync requests \o/
<geser> \o/
<geser> sebner: now you also need a sponsoring module for merges :)
<sebner> geser: I'll leave soon so I just want to finish until I have 20 ACKs. merges are my victims for tomorrow \o/
<kirkland> can someone point me to a step-by-step guide for i18n-ing a package?
<geser> does something magical happen at 20 ACKs?
<kirkland> i know there's a bunch of gettext calls to add to the shell, python and C
<kirkland> there's some po work
<kirkland> a fair amount of build and packaging
<sebner> geser: well, 20 sounds so much nicer and cleaner than 17 does ;)
<kirkland> as well as launchpad setup, etc.
<kirkland> i'm hoping someone has written up a best practices guide on making this happen
<dpm> kirkland: there's http://live.gnome.org/TranslationProject/DevGuidelines and http://developer.gnome.org/projects/gtp/l10n-guide/, although the latter is really outdated. I'd like to write such a guide for Ubuntu, but this hasn't happened yet.
<kirkland> dpm: thanks for the pointers
<kirkland> dpm: i'm going to email the list asking for such things; perhaps you can respond there?
<dpm> kirkland: sure. We've also already started this with dholbach here -> https://wiki.ubuntu.com/UbuntuDevelopment/Internationalisation, but it is really crude at the moment, that's why we haven't announced it yet
<kirkland> dpm: i'm happy to be a guinea pig in your development of that documentation
<dpm> kirkland: ;) just feel free to ping me or ask anything as well, maybe this will be a good way to see which are the most important sections to cover there
<wizztjh> hi , i am a python programmer , how can i help to develop ubuntu?
<jjohansen> wizztjh: look around find a project that interests you and start fixing bugs/adding features
<jjohansen> wizztjh: the best way really is just finding something interesting and jumping in
<wizztjh> i now browsing MOTU , where can i join the project
<jjohansen> which project?
<jjohansen> if you mean MOTU https://wiki.ubuntu.com/MOTU/GettingStarted
<bryce> anyone know if there is a test bugzilla up running anywhere?  I'm doing a script to upstream bugs from lp but don't want to irritate freedesktop.org with a bunch of test posts
#ubuntu-devel 2009-07-24
<directhex> woo, mono-tools. i still wonder if there's any reason dh_installxsp couldn't be moved out of the xsp source package, to avoid the need for a merge
<superm1> Riddell, it doesn't look like a new livefs or ISO got made for mythbuntu according to http://people.canonical.com/~ubuntu-archive/livefs-build-logs/karmic/mythbuntu/.  can you check and queue one up so we can try to still get a3 out?
<tseliot> cjwatson: is it mandatory for debconf scripts to have "set -e"?
<ogra> tseliot, i think it is
<tseliot> ogra: I suspected that...
<tseliot> thanks
<cjwatson> tseliot: it's not mandatory as such, but it's usually a mistake to write *any* shell script that doesn't use 'set -e'
<tseliot> cjwatson: ok, thanks
<seb128> evand, hey, I did the usb-creator conversion to gtkbuilder it's waiting for review on launchpad
<evand> seb128: thanks, I'll look it over now
<seb128> evand, I kept the hack for the label thing the dialog looks weird otherwise since text is selected by default
<evand> ah, okay
<seb128> I first though that it was because the focus was not set on a button by default
<ogra> hrm, the naming scheme of KDE is massively confusing ... so kde4libs builds kdelibs5-dev ??
<seb128> but that was not it so I put the hack back
<evand> hrm
<seb128> evand, did I do something stupid? ;-)
<tseliot> mvo: what kind of approach would you prefer for nvidia-common? Would an additional argument to the ctor of NvidiaDetection() be enough (so that you can pass it a text file)?
<evand> seb128: I'm not sure :).  I'm a bit perplexed at why the text is getting selected.  I'll have to take another look at some point.
<seb128> evand, well it means that the label is the widget getting focus by default
<mvo> tseliot: hm, I lack some context here, is there a open bug aobut this?
<evand> ah, I see that gtk.Label still has the annoying "I'm not going to expand horizontally" bug.
<evand> seb128: gotcha
<tseliot> mvo: you asked me to make it possible for nvidia-common to get the list of obsolete packages from a text file instead of hardcoding them into the program
<evand> seb128: merged, thanks
<MacSlow> Can I edit a comment on lp? Spelled something wrong
<seb128> evand, thanks!
<seb128> MacSlow, no
<MacSlow> hm
<mvo> tseliot: aha, right - yeah, I think a textfile should be fine. I guess no additional argument is needed, there is already the datadir, we can put it there (but I leave thta to you)
<geser> doko_: should we remove "python3.0" from karmic?
<doko_> geser: no
<geser> doko_: isn't abandoned upstream and replaced with python 3.1? why should we keep it?
<doko_> geser: do you see a replacement in the archive?
<Riddell> superm1: your ISOs are at http://cdimage.ubuntu.com/mythbuntu/daily-live/20090724/
<CardinalFang> How can I find out the reason a package is "held back" from upgrading?
<slytherin> infinity: Hi. Any luck in fixing powerpc buildd?
<Gh0sty> I was wondering is there anywhere a place where we can make suggestions for the new ubuntu's?
<Gh0sty> Like a wishlist kinda thing
<SteveA> hi markgsaye
<SteveA> you're having some trouble installing the latest alpha of karmic?
<markgsaye> HI all, I'm wondering how to track down problems with fresh install of karmic alpha 3 and nvidia graphics (can't open /dev/fb0: no such file -> no X/gdm/etc)
<slytherin> Gh0sty: It depends on type of suggestion.
<Gh0sty> usability related things for example: why do i have to click the name in the logon screen if there is only 1 name there ... (I only want to enter password, just like windows logon screen ...)
<ogra> Gh0sty, just hit enter then
<ogra> its one enter more than windows
<Gh0sty> was even wondering why they don't do a preload of everything from that user and lock the screen rather then waiting ... :p
<ogra> becuause that would be a really bad idea on multiuser systems
<Gh0sty> but on a single user system (like 90% of the users have)
<ogra> how do you determine that number ?
<Gh0sty> how do you determine how much users are in the logon screen? :p
<ogra> ??
<directhex> ogra, (face browser)
<ogra> directhex, i read what he is typing, i just miss the connection
<Gh0sty> btw: your suggestion of just pressing enter ... in my karmic version the user is highlighted but enter doesn't do anything
<Gh0sty> i need to click it ...
<ogra> is it up to date ?
<SteveA> evand: hi
<ogra> should actually work
<Gh0sty> lets see
<evand> SteveA: hi
<directhex> Gh0sty, okay, i understand the issue, but i'm not in a position to reproduce it. if you can be 100% sure that it's not how you think it should be (i.e. avoid wasting time with bugs which are actually user error) then look at https://wiki.ubuntu.com/PaperCut
<SteveA> markgsaye: evand works on the installer and related things
<Gh0sty> cool exactly what i was looking for directhex :)
<markgsaye> evand, hi - I'm having trouble with a fresh install of alpha 3
<markgsaye> evand, no X/gdm - had to install from alternate cd
<evand> markgsaye: did the live CD not boot to a desktop?
<markgsaye> evand, no, failed with X startup
<Gh0sty> which nvidia graphics?
<evand> markgsaye: that's beyond the realm of the installer then, and unfortunately beyond my level of expertise.  I'd suggest taking it to bryce when he wakes up, if that's okay.
<markgsaye> nvidia quadro (I'll see if I can find out which chip)
<Gh0sty> desktop or laptop?
<markgsaye> evand, will do - thx
<markgsaye> laptop
<Gh0sty> i have a quadro in my thinkpad ...
<markgsaye> HP elitebook 8530w
<evand> markgsaye: sure thing, sorry I couldn't be of more help
<geser> CardinalFang: try to install it and apt will tell you
<Gh0sty> but i should first download the latest alpha again then
<Gh0sty> did you have it too with the alpha 1 or 2 ?
<Gh0sty> bb in 1 min
<robbiew> marksgaye: have you tried installing Jaunty?
 * robbiew wanting to know if this is a regression
<robbiew> marksgaye: you could try installing Jaunty (assuming it works), then run 'sudo update-manager -d' from the command line to get to Karmic Alpha 3
<markgsaye> robbiew, Jaunty was fine
<markgsaye> robbiew, I _could_ do that, but I like to keep different releases on separate partitions
<robbiew> ah
<markgsaye> robbiew, I guess I could install base Jaunty on this (karmic) partition, then upgrade
<robbiew> ;)
<robbiew> or wait for Bryce
<robbiew> just giving you options
<Gh0sty> markgsaye: x86 or A64?
<markgsaye> Gh0sty, amd64
<Gh0sty> ok downloading alpha 3
<Gh0sty> lets see if i can reproduce
<markgsaye> nvidia-detector returns "none"
 * robbiew runs karmic alpha 3 on my desktop at home amd64...but I upgraded :/
<markgsaye> I have nvidia quadro fx 770m (G96GL) according to Jaunty's Xorg log
 * robbiew leaves to upgrade his laptop
<Gh0sty> damn
<Gh0sty> upgrading actually worked for the login issue :p
<ogra> heh
<Gh0sty> hm i have a quadro fx 570M (rev a1)
 * markgsaye grabs some lunch
 * jdstrand wonders out loud if the fact that all his schroots are mounted and available in nautilus are due to bug #396448
<ubottu> Launchpad bug 396448 in gvfs "inconsistent automounting on startup" [Unknown,Confirmed] https://launchpad.net/bugs/396448
<Gh0sty> markgsaye: the moment of truth! :)
<markgsaye> Gh0sty, hey - I installed nvidia-180-kernel-source and got X to start
<markgsaye> Gh0sty, but then nvidia-settings locked the machine up when trying to activate external monitor
<Gh0sty> *booting*
<Gh0sty> activating nvidia driver 180
<Gh0sty> so far i still have a gui ...
<Gh0sty> hmmm
<Gh0sty> it finds me 2 nvidia drivers
<Gh0sty> but if i try to activate one
<Gh0sty> i get an empty window with a "forbidden" sign ... :p
<Gh0sty> but is that even possible? activating nvidia driver in livecd mode?
<directhex> i don't think it is
<markgsaye> Gh0sty, nvidia-settings is crashing my system - any suggestions?
<Gh0sty> you still with normal repos?
<Gh0sty> cause i run for a long time already beta drivers on my quadro
<Gh0sty> its also still running intrepid
<markgsaye> Gh0sty, everything is stock Karmic repos
<Gh0sty> but thats more because i ran into trouble upgrading to jaunty
<Gh0sty> but thats my own fault ;)
<rtg_> cjwatson, slangasek: I think I understand most of the rfkill issues. Can you review my proposed changes at http://kernel.ubuntu.com/~rtg/wireless-tools.diff ? Once its uploaded I'll change acpi-support to use the rfkill application.
<doko_> rtg_: does debian/copyright need an update?
<rtg_> doko_, I added COPYING.rfkill. Should I just cat it on to the end of copyright?
<doko_> rtg_: yes, if it's not already there (didn't check)
<rtg_> doko_, ok, I'll figure it out.
<doko_> and maybe say, for which files/directory it does apply
<ogra> doko_, is haifa enabled in our gcc by default ? and is there an option i can use to disable it ?
<doko_> ogra: iirc, since ages
<ogra> do i have any option to disable it without rebuilding gcc ?
<rtg_> doko_, updated http://kernel.ubuntu.com/~rtg/wireless-tools.diff. I just appended copyright and README to existing debian/copyright and debian/README.Debian so dh_installdocs does the right thing.
<doko_> ogra: no, it was enabled by default in 1997 ...
<ogra> doko_, thanks
<ion> Haifa? A city in Israel? :-)
<ogra> yeah, you send them your code and they optimize it for you :)
<ion> A bit like SpinVox speech recognition.
<ogra> nah, better ... they remove all the zeros between the ones ;)
<Riddell> evand: have you seen shtylman's kde theme branch?  can I merge it into ubiquity trunk?
<evand> Riddell: I have not seen it yet.  I'll look it over later today.
<Riddell> evand: groovy, you can merge it in then if you're happy with it
<evand> will do
<davmor2> Any one else having issues with machines switching them selves on?
<superm1> Keybuk, how come lp:~scott/udev/master isn't pulling new git checkouts?  is it a manual process?
<Keybuk> yes
<superm1> oh that would explain it :)
<ogra> he needs to sing special tunes and sacrifice chickens to kay for it ;)
<superm1> I guess i'll just chekout using git protocol then
<Keybuk> pushed an update for that branch
<superm1> cool thanks
<rickspencer3> didrocks: anything interesting to share with the channel?
<didrocks> rickspencer3: oh sure, quickly 0.1 is released \o/ Check it out (https://launchpad.net/quickly)!
<floryn90> hi
<floryn90> i have one suggestion
<mnabil> kancerman,
<mnabil> sorry
 * blackxored greets everyone in #ubuntu-devel
<maxb> One of the problems with turning the Firefox search box into an Ubuntu Google Custom Search, is it means Google is rather more aggressive at pushing ads at you on the result page :-(
<directhex> maxb, and lacks little things like links to maps, images, etc
#ubuntu-devel 2009-07-25
<lamont> bug 402175
<ubottu> Launchpad bug 402175 in gnumeric "gtk_tree_view_column_get_cell_renderers implicitly converted to pointer" [High,Triaged] https://launchpad.net/bugs/402175
<cockroach> doko: are you here?
<DktrKranz> cjwatson: debhelper 7.3.5 introduced support to build Python modules and extensions for every supported Python version, do you see room to merge current 7.3.8 in Karmic? It changed a lot, though (implementation of buildsystems, primarily).
<AnAnt> Hello, can someone look at LP 404561
<ubottu> Launchpad bug 404561 in debhelper "Candidate revision debhelper_7.3.8ubuntu1" [Undecided,New] https://launchpad.net/bugs/404561
<Q-FUNK> howdy! is there a generic "package" name against which users could report an upgrade problem (other than caused by update-manager, in which case they would report against update-manager)?
<Q-FUNK> e.g. for a generic "upgrade from intrepid to jaunty failed for me" type of reports
<cjwatson> we don't really have an equivalent to Ubuntu pseudopackages, unfortunately
<cjwatson> err, to pseudopackages in the Debian BTS
<cjwatson> if you don't want to treat update-manager as a pseudopackage for upgrade problems, I think the only available option is to report the bug without a source package name
<Q-FUNK> cjwatson: I'm trying to write an apport wrapper for 'upgrade-system' to avoid getting generic upgrade reports against the package,
<Q-FUNK> because many people report against that package when they really mean to report a generic upgrade issue, whether performed using update-manager or APT or aptitude.
<cjwatson> check with mvo to see if he minds general upgrade reports going against update-manager?
<Q-FUNK> apparently, many people use synaptic or LP's search option and end up randomly picking 'upgrade-system' the package because it matches a search for the keyword "upgrade" when they mean to report a failure against update-manager or, in many cases, because a specific package pulled by update-manager failed to upgrade.
<Q-FUNK> right. I'm hesitant with systematically redirecting every report to update-manager, though.
<Q-FUNK> my main strategy would have been to write an apport hook that would cancel the report if it's done against 'upgrade-system' and yet that package isn't installed.
<Q-FUNK> as to which ubuntu package should get that hook is anyone's guess :)
<Q-FUNK> obviously, adding the hook to 'upgrade-system' won't work...
<Q-FUNK> cjwatson: any other suggestion for managing such bug reports? :)
<Sarvatt> what is up with all of these warnings in dpkg-shlibdeps for the past week or so?
<Sarvatt> dpkg-shlibdeps: warning: debian/xserver-xorg-video-openchrome/usr/lib/xorg/modules/drivers/openchrome_drv.so contains an unresolvable reference to symbol DRIDestroyInfoRec: it's probably a plugin.
<Sarvatt> dpkg-shlibdeps: warning: 183 other similar warnings have been skipped (use -v to see them all).
<cody-somerville> dtchen, recently I've had a problem develop on karmic where when I switch songs or streams then there is a 3-10 second or more delay before the song will start to play.
<cody-somerville> dtchen, installing pulseaudio and telling my media player to use pulse solves the issue
<cody-somerville> dtchen, so I assume its some sort of regression with ALSA or something as I tried an older kernel that I knew to work and a version of the media player from jaunty and the issue still manifested when using the alsasink.
<hunger> Any chance of getting btrfs-tools updated in karmic soonish?
<hunger> Debian/unstable has that already.
<sebner> hunger: you are free to file a sync request
<hunger> sebner: How so?
<maxb> http://wiki.ubuntu.com/SyncRequestProcess
<hunger> Thanks!
<sebner> maxb: ah thx for the link
<sebner> hunger: don't worry. I already did that for you
<hunger> sebner: Thanks!
<emgent> sebner: ola
<emgent> i need you!
 * sebner hides
<emgent> like tester for http://backtrack.it/~emgent/hackstuff/Gerix-Wifi-Cracker-NG/index-en.html
<sebner> ember: omg. rofl. xD
<emgent> what rofl ?
<emgent> r0x. :-)
<emgent> test it and let me know
<sebner> ember: bah qt and even q3!
<sebner> *qt3
<sebner> ember: b0rken by design :P
<emgent> lol
<sebner> emgent: why /opt/ ?
<sebner> emgent: I don't see any product but gerix site has nice graphics ^^
<emgent> sebner: it`s backtrack native.
<sebner> emgent: I can't really test because I have no network to crack ^^, maybe tomorrow
<mido1> I've got a problem with Ubuntu 9.04 (Jaunty) as live cd/dvd system with persistent home. I did not manage to use an usb stick as persistent home although I've formatted it with ext2 and labeled it "home-rw" as requred by casper. It seems if there are not any usb devices available when casper searches for the persistent home partition. Any hints?
<mido1> Sorry, good eavening everybody.
<mido1> Sh***, I'm on the developer channel... sorry for disturbance.
<ccheney> anyone around that can make bug 306627 be retraced?
<ubottu> Bug 306627 on http://launchpad.net/bugs/306627 is private
<ccheney> it seems to never have gotten processed
<ccheney> i'm not even sure how i can see it atm
<ccheney> ah all ubuntu dev is part of the crash team
<dajomu> Alpha 3 released and still got big issues with intel drivers. At least my graphic card.
#ubuntu-devel 2009-07-26
<bluefoxicy> so
<bluefoxicy> I'm assuming 32-bit desktop is better QA'd than 64-bit?
<directhex> there are 5x more people running i386 than amd64, so in theory 5x more people reporting bugs running on i386
<directhex> question is, how many of those bugs are arch-specific? and how is the split amongst developers
<Q-FUNK> howdy!  one question about Apport and ufw hooks:  is the usage of debian/local/* as the place to put ubuntu-specific packaging elements documented somewhere?
<timboy> anyone had issues with the x64 alternate cd's?
<timboy> sorry of jaunty
<timboy> I've downloaded the cd's twice burned multiple times from different pc's and put on a thumbstick and still having issues! different files are corrupt every time. also used different cd readers.
<timboy> if I use the mini cd it works fine but I don't want to use the mini cd and download the whole distribution because internet is slooooow
<timboy> is there an issue with the alternative iso?
<johanbr> timboy, worked for me
<johanbr> you may have issues with your cd reader (or your mirror)
<timboy> johanbr, tried two mirrors both checksums fine two different readers both brand new 5+ cd's of each image and 2 thumbsticks
<timboy> second time i've had this issue in 2 months two different machines
<timboy> only reason for alternate is software raid
<jumpkick> does anyone know how to make dpkg-buildpackage not set CFLAGS at all?
<kamalnandan> Hi I am facing some problem while running this command on Ubuntu
<kamalnandan> "apt-get install devscripts"
<kamalnandan> when i use this command, the command window turn blue in color and i see the following text there, and I am not getting what to do next, because it doesnt seem to accept any keyboard input like "Enter" or something..
<kamalnandan> I see the foollowing text:
<kamalnandan> Package configuration
<kamalnandan> any clue guys?
<Hobbsee> kamalnandan: a debconf prompt?  try hitting tab before hitting enter
<james_w> apw: responsiveness under IO load seems to have dropped again a little with 2.6.31-3.19, do you see the same thing?
<YokoZar> Hey what happened to the guest account in Karmic?
<james_w> the new gdm made the old way not work I believe
<james_w> or perhaps it's just that the new gdm doesn't have the changes to expose the guest account in fusa
<YokoZar> Makes sense
<apw> james_w, i think i didn't notice a change till i got -4, and i note i got my loadave values back at the same time
<apw> actually it was one of -3 or -4 that i was suspicious of ... i wasn;t paying 100% attention
<james_w> I'll try -4
<apw> i only really get hurt by it when i build kernels, and i don't do that on my interactive machine regularly enough to know for sure.
<timboy> there are major issues with intel gma x4500 series. in jaunty no acceleration support and in karmic alpha 3 won't even boot to gnome. dumps me at 1.646916 ---[ end trace aa828b042a8fcdcc4 ]---
<timboy> if I slap in an nvidia card it boots fine. but onboard is crap. *HATING intel right now
<dtchen> cody-somerville: please file a bug report against alsa-lib (tentatively) with a precise description, including versions, of the involved software.
<timboy> I don't know any more than that. how can I file a bug?
<dtchen> timboy: tried disabling KMS?
<timboy> how do I do that?
<timboy> dtchen, ^^
<dtchen> timboy: see https://wiki.ubuntu.com/X/KernelModeSetting. you can use =0 to disable.
<Kovert> can I get help with an issue I am having as I tried to get to Alpha 3 http://pastebin.com/d6e5674d1
<timboy> did you sudo apt-get -f install?
<Kovert> yes
<Kovert> timboy: do you want the output of that
<timboy> nope i've got to go. would probably help someone else help u though.
<Kovert> any one help me
<Kovert> ?
<Kovert> Output of install -f
<Kovert> http://pastebin.com/d51705bf4
<stoner> hello
<stoner> hello?
<stoner> hello
<stoner> anyone here?
<stoner> i guess not!!!!! :(
<TwoToneSpirit> I'm just learning Python.  Can anybody point to a good introductory page on writing GUI programs for Ubuntu using Python?
<Shane_Fagan> TwoToneSpirit: This isnt a development support channel. Its here for talking about developing ubuntu. That being said have a look here http://www.pygtk.org/pygtk2tutorial/index.html
<Shane_Fagan> Its an old one but there is a lot of good topics covered
<TwoToneSpirit> Shane_Fagan: Where is the development support channel?  Thank you for the link :-)
<Shane_Fagan> TwoToneSpirit: try #python
<TwoToneSpirit> Shane_Fagan: Yeah, I'm in #python, but since it was ubuntu specific, I thought I'd ask here since my long-term goal is to be able to help you all.
<Shane_Fagan> The more the merrier
#ubuntu-devel 2010-07-26
<un214> now I'm finding all kinds of crazy packaging bugs that only happen when the system lives in a chroot jail
<un214> some of these also affect system rescue scenarios
<pitti> Good morning
<TheMuso> c
<vorian> moses, it's still night here
<dholbach> good morning
<bilalakhtar> dholbach: good morning
<dholbach> hey bilalakhtar
<mantiena-baltix> ev: hi
<doko> ogra, ScottK: OOo still hasn't sane build-deps. kde4libs did fail to build with an error in a qt4 header
<mantiena-baltix> ev: are you Evan Dandrea ?
<mantiena-baltix> Anybody can tell me what should I do to fix bug #606134 before Ubuntu 10.04.1 ?
<ubottu> Launchpad bug 606134 in Ubiquity Slideshow for Ubuntu "ubiquity-slideshow-ubuntu package has outdated translations in Ubuntu 10.04.1" [High,In progress] https://launchpad.net/bugs/606134
<mantiena-baltix> There is a branch with updated translations already, see
<mantiena-baltix> lp:~dylanmccall/ubiquity-slideshow-ubuntu/lucid-bug-606134
<mantiena-baltix> Ready for review for merging into lp:ubiquity-slideshow-ubuntu/lucid
<mantiena-baltix>     Ubiquity Slideshow: Pending requested 2010-07-19
<mantiena-baltix> Who should review this and who can merge into official lucid package ?
<dpm> mantiena-baltix, ev or cjwatson might be able to tell you more about it. I'm not sure if they're in yet, so please be patient while waiting for a response. thanks! :)
<mantiena-baltix> dpm: ok, I will wait ev or cjwatson
<bilalakhtar> dpm: Are you a core-dev? Are you free ?
<dpm> bilalakhtar, I'm not a core dev, I simply coordinate Ubuntu translations
<bilalakhtar> dpm: aha
<LucidFox> Are there any plans to make the Software Center, rather than Synaptic, the default handler for apt: links?
<mvo> LucidFox: yes
<LucidFox> In maverick, or maverick+1, or...?
<mvo> LucidFox: the goal is maverick
<LucidFox> Gewd!
<mantiena-baltix> dpm: I must go away for 2 hours, could you tell ev or cjwatson about bug #606134 when they come back?
<ubottu> Launchpad bug 606134 in Ubiquity Slideshow for Ubuntu "ubiquity-slideshow-ubuntu package has outdated translations in Ubuntu 10.04.1" [High,In progress] https://launchpad.net/bugs/606134
<dpm> mantiena-baltix, you can still remind them when you're back, don't worry. I'm a bit busy right now, and I cannot guarantee I'll remember in 2 hours
<mantiena-baltix> dpm: maybe ev or cjwatson will come back quicker than 2 hours ;)
<mvo> did anyone has ldtp working inside a xvfb-run environment? I struggle with that and wonder if I miss something obvious (starting at-spi-registryd manually has not helped)
<mantiena-baltix> ev: hi, are you online?
<dpm> hey mvo, I hope you had a nice trip back home. You told me I should remind you of updating the ddtp translations for 10.04.1, so here's the reminder :)
<dpm> mvo, I've also got a couple of questions: 1) What's the 'packages' template here -> https://translations.edge.launchpad.net/ddtp-ubuntu/ubuntu/+lang/fr? 2) Would it be possible to have an update of aptdaemon with only translations? If I'm not mistaken, that's the package that contains the .policy strings shown in SC when installing a package. They are quite visible, but they are not supported in language packs, translations need to be rebuilt with the p
<dpm> ackage
<chrisccoulson> pitti - would you mind accepting the firefox binaries? (it's sat in NEW atm)
<pitti> chrisccoulson: done
<chrisccoulson> pitti -thanks
<chrisccoulson> pitti - i've just seen how big the breakpad symbols that i need to push to mozilla are
<chrisccoulson> that's going to be painful when i'm doing it for the daily builds too ;)
<pitti> chrisccoulson: do you need to?
<pitti> chrisccoulson: anyway, the upload should happen from chinstrap
<chrisccoulson> pitti - yeah, that's the biggest benefit (so mozilla can spot issues before they actually do a release)
<pitti> chrisccoulson: sounds like some shell scriptery and a cronjob might be helpful then
<pitti> i. e. remember which one you sent last, check the current version, and upload it there if there's a new one
<chrisccoulson> pitti - yeah, i'll try and look at that this afternoon and see if i can make something which works
<slangasek> doko: I have some doubts about the interaction between gcc-multiarch.diff and biarch architectures; is that something we could talk about, or do I need to track down Arthur?
<mvo> dpm: weh, thanks! it was a bit busy today, I put it on my list for tomorrow
<mvo> dpm: re aptdaemon> do you mean for 10.04.1 ?
<dpm> mvo, no worries, thanks for coming back to me!
<dpm> mvo, yes (or post-10.04.1 if that's no longer possible)
<mvo> dpm: I think it still is, I just wanted to make sure. I will also need to manually get the latest po files from LP. right?
<dpm> mvo, yes, you'll need the latest translations from LP and rebuild the package with them, only then the translated .policy files for the languages which did not make it for the pre-release Lucid translation deadline will be built
<mvo> ok
<mvo> thanks dpm
<dpm> no worries, thanks to you. mvo, and what's the new 'packages' template on https://translations.edge.launchpad.net/ddtp-ubuntu/ubuntu/+lang/fr?
<mvo> dpm: uh, that looks like a error, I am not sure where it comes from
<mvo> dpm: can I delete it again?
<mvo> dpm: can you :) ?
<dpm> mvo, let me see if I can disable the template
<dpm> mvo, ok, sorted. I've disabled the 'packages' template and it is no longer visible in LP. It seemed to came from a packages.pot upload
<mvo> thanks dpm
<mvo> dpm: probably my mistake, it would not take my automatic curl based pot uploads recently for some reason
<mvo> dpm: so I did a maual upload, probably that broke it
<dpm> no worries :)
<froud> Anyone know where the users last session type is stored?
<ansgar> froud: Something like ~/.dmrc?
<froud> thx
<EtienneG> hey guys.  Is the "Essential: yes" actually being used for something meaningful in Ubuntu?  I noticed some pretty important packages, such as upstart, are not being flagged essential.  I was wondering if/when it was appropriate to use it.
<EtienneG> slangasek, I understand you are the original (and current maintainer?) of auth-client-config and pam-auth-update.  I reported bug #608930, about libnss-ldap and libpam-ldap being indirectly coupled together.  I have a case where I do not want libpam-ldap, I want libnss-ldap + libpam-krb5.  This bug is not a show-stopper, but it is complicating setup.  If you have a sec, can you have a look and advise on whether a relevant bug that should b
<EtienneG> e "fixed", and if not, how to work around it?
<ubottu> Launchpad bug 608930 in libnss-ldap (Ubuntu) "libnss-ldap needlessly (and indirectly) depend on libpam-ldap" [Medium,Opinion] https://launchpad.net/bugs/608930
<slangasek> EtienneG: I have never been a maintainer of auth-client-config; you want jdstrand
<EtienneG> slangasek, ah, sorry about.  But you are the author of pam-auth-update, correct?
<slangasek> EtienneG: the only changes I made to auth-client-config were to detach it from pam config when pam-auth-update went live
<slangasek> correct - but that doesn't much help you with the LDAP packages, which I don't understand deeply :)
<slangasek> as for Essential: yes, it *is* used with the same meaning as in Debian
<slangasek> see debian-policy for the meaning :)
<EtienneG> slangasek, ok and understood about the lib(pam|nss)-ldap problem.  i will poke the server team about it, as I think they are the one looking after it (although it might just be the foundation team now)
<EtienneG> slangasek, I have looked at the Debian policy, and it is not quite clear how it is being interpreted, and by what.  Does it impact the way APT/dpkg works?  Is there a command to display all packages tagged Essential?  (apt-cache doesn't do it, it seems)
<slangasek> EtienneG: the package manager uses Essential to determine correct handling of upgrades
<slangasek> and use of the field imposes certain requirements on the packages that declare it
<slangasek> display all packages: grep-available -sPackage -FEssential yes
<EtienneG> slangasek, thanks a bunch for the information!
<slangasek> sure :)
<smoser> cjwatson, ping.
<kelelsai> hi, I'm new here. I missed the section or documentation that says where to get the code from to Fix bugs. Does anyone here know the link that references how to do so?
<Teodora> does anyone know how to watch a blue ray files in ubuntu 10.04?
<micahg> !support | Teodora
<ubottu> Teodora: The official ubuntu support channel is #ubuntu. Please be aware that this channel is for development only.
<Teodora> ok sorry
<Teodora> :)
<sladen> kelelsai: type   apt-get source $name_of_package
<fta> kirkland, /wrt your last blog entry: http://paste.ubuntu.com/469493/  (thanks for the idea btw)
<kirkland> fta: you're welcome ;-)
<fta> *csh could be tricky with $ and "
<philsf> Everytime I boot my netbook, the bluetooth applet is on. I'd expect it to remember the last state. Is this a bug, or am I missing something?
#ubuntu-devel 2010-07-27
<TheMuso> ~/c
<un214> just discovered leaving the grub packages in a chrooted system is a good way to fry the host
<pitti> Good morning
<ion> rning
<pitti> zul: mysql question for you in https://bugs.edge.launchpad.net/ubuntu/+source/mysql-dfsg-5.1/+bug/608423/comments/6
<ubottu> Launchpad bug 608423 in mysql-dfsg-5.1 (Ubuntu Lucid) "[lucid-proposed] post-start script broken" [High,New]
<dholbach> good morning
<ion> that
<LucidFox> Wow, I didn't know Upstart was used in so many systems now
<diwic> How do I create a symlink (inside a make install target) that works in a .deb?
<diwic> E g, the following does not work: ln -s $(DESTDIR)$(PREFIX)/dir1/file1  $(DESTDIR)$(PREFIX)/dir2/file2 - because when the deb is installed, the symlink will point to /buildd/debian/somewhere
<TheMuso> diwic: You can use debian/packagename.links to create symlinks
<TheMuso> man dh_link
<diwic> TheMuso, thanks, I'll try that
<TheMuso> np
<azeem> diwic: in general, do relative symlinks
<lool> cjwatson: ssh-import-lp-id man page mentions ssh-import-id in synopsys; mind fixing that in the packaging repo?  I'm too lazy to bug this
<lool> Oh actually might not be a bug
<Laney> It does say "ssh-import--id(1)" at the top though (two dashes)
<soren> diwic: Leave out the $(DESTDIR) bit in the first argument, and you're golden.
<diwic> soren, thanks. I think I tried that, but perhaps I removed it from the wrong path. Anyway, TheMuso's solution worked.
<zul> pitti: *sigh* ok :)
<pkramerruiz> Hi everyone!
<pkramerruiz> Can anyone tell me if the developers of "software-sources" have an channel-sources?
<pkramerruiz> Cause I want to run the process for selecting the best Mirror server, every time before making an update to some program, for obtain more speed downloading
<zul> pitti: fixed
<Chipzz> pkramerruiz: that would be pointless, since you would be running apt-get update each time, which would pull in several MB in itself
 * apw is hearing rumours that the maverick CDs live dailies are borked at the moment, syslinux errors
 * apw confirms that the i386 image is unbootable ... 'Unknown keyword in configuration file'
<apw> pitti, it seems that maverick isos have the wrong version is SYSLINUX installed on them ... they are booting and indicating 3.63, but the version in maverick is 4.01
<apw> i am suspicous that the config file has been updated to the new format, but the binary somehow not
<pitti> zul: rejected mysql; it seems $ret is not initialized to '0' on success, and you need to upload with -v
<pitti> zul: i. e. if $x is undefined, I get
<pitti> $ LANG= [ $x -eq 0 ]
<pitti> bash: [: -eq: unary operator expected
<zul> pitti: k thanks
<apw> pitti, who owns the generation of the maverick isos ?
<pitti> apw: usually cron
<pitti> apw: hm, not sure how syslinux comes into play here
<apw> pitti, somehow the version on the images is out of step with the archive.  though the real issue is that the verson on there does not understand the configuration file built for it while building the iso ... so it errors out and does not boot
<apw> its not clear how long the iso's have been broken
<pitti> they kept failing to build quite often, too
<pitti> kernel changed often, before langpacks rebuilt, etc.
<pitti> not that easy to get something installable :)
<apw> pitti heh .. typical
<apw> pitti, so do we normally defer to mr. watson on this stuff ?  i think he is away
<pitti> right, he's on holiday
<apw> t'is a worry with a-3 fast approaching
<ion> pitti: I prefer the paranoid style in sh programming: put *all* variable references in quotes, unless thereâs a reason not to. :-)
<pitti> ion: right, but it'd break either way
<pitti> if $x is empty, [ "$x" -eq 0 ] still errors out
<ion> Yeah, but the error would be about an illegal number, not a missing operand. :-)
<pitti> apw: hm, I don't see anything relevant on http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu/maverick/daily-live-20100727.log
<pitti> and I don't see how it should be the livefs; syslinux should be a matter of the actual .iso build
<apw> pitti, i assume there is some floppy which is combined with the live fs to make its an el-torito bootable what-sit
<ogra> apw, right, thats what debian-cd does
<apw> ogra, ok what makes the contents of the flippy ?
<ogra> it pulls the livefs from the live builder and creates an iso around it
<ogra> there is no "floppy" :)
<ogra> its just syslinux copied into an iso or vfat
<apw> ogra, ok but to make a bootable CD you have to supply a floppy don't you?  in the CD and magic point to it
<ogra> no
<apw> ogra, to re-cap.  maverick CD's stopped working sometime recently
<ogra> you just copy the isolinix or syslinux binaries into the image file
<apw> the issue looks to be a configuration issue for syslinux, which is oddly an older version
<apw> 3.63 from lucid and not the one from maverick
<ogra> right, it might be that the debian-cd scripts pull from the host machine
<ogra> which would get you the hardy version
 * pitti found ~/cdimage/debian-cd/tools/boot/maverick/boot-{i386,amd64} now, looking
<ogra> right
<ogra> thats the script
<apw> so i wonder if its meant to be updated and the config in maverick is matching the new one
<apw> ogra, its the one from lucid it seems
<apw> BUT its possible the host was updated from hardy to lucid ...
<pitti> apw: is that isolinux.cfg?
<apw> i know one of our machines was so upgraded recently
<apw> pitti, i am unsure, though if you have that i'd say so
<ogra> ogra@antimony:~$ lsb_release -a 2>/dev/null|grep Code
<ogra> Codename:	hardy
<apw> ogra, ok the one on there is 3.63, which seems to be lucid level
<ogra> right
<apw> pitti, actualy isolinux sounds wrong
<ogra> i gues there is some code missing to pull the maveric one into the image
<ogra> isolinux is right for the isos
<ogra> otherwise its syslinux for the vfat images
<apw> pitti, oh but it does seem to be so
<apw> syslinux.cfg/isolinux.cfg:
 * pitti defers to ogra then; NFC about this stuff, and I'm betwen two meetings now
<apw> is mentioned in the source for syslinux
 * ogra hasnt any clue about the sys/isolinux changes either
<ogra> but i'll take a look at the code
<pitti> didrocks: ^ that just means that you can't get a (working) respin of the CD
<apw> both packages were changed a long time ago, weeks in both cases
<pitti> didrocks: I advise to take the alpha-2 image with a persistency file and upgrade packages in-place
<didrocks> pitti: urgh, this ISO for Guadec sounds like a malediction :(
<didrocks> ogra: pitti: yesterday's iso has the same iso?
<didrocks> issue*
<ogra> apw, colin changed the code on friday
<apw> ogra, to ?
<apw> i mean which bit did he change ?
<apw> which package
<ogra> making i386 and amd64 use syslinix-coomon instead of syslinux
<ogra> *common
<apw> hrm ...
<ogra> apw, http://paste.ubuntu.com/469833/
<apw> ogra, syslinux-common only exists in maverick ... but the version number reported on actual boot isn't that new one (4.01)
<ogra> well, the code seems to pull syslinux-common from maverick
<ogra> which was the last usable image ?
<apw> ogra, yeah ... which may well make sense... except ... they say 3.63 when booting
<ogra> there were some changes before ... though they dont touch syslinux code directly
<apw> ogra, last one i booted was the 5th so i am not much use
<ogra> hmm
<ogra> well, its hard to tell which change broke it if i dont know the date
<ogra> there is some new code that makes use of gfxboot.c32
<apw> ogra, yeah only came to my attention today, do we keep any older ones?
<ogra> 3 days of successfull builds usually
<apw> ogra, so they would all be after the last change ... hrmph
 * apw asks arround ... to find out who last booted one and when
<ogra> is syslinux-common in main already ?
<apw> ogra, how does one tell, the source claims to be in main
<hallyn> to make a sync request, can i subscribe 'ubuntu-release' to the original bug, or should i file a new bug referencign the original (fixed) bug?
<ScottK> apw: rmadison will tell you at least for non-ports archs.
<apw> ogra, though from the binary he is trying to extract i'd be supprised if its in the -common file
<ogra> apw, he pulls isolinux.bin, vesamenu.c32 and gfxboot.c32 out of that package
<apw> ogra, and they do indeed seem to be in there somewhat supprisingly to me
<superm1> apw, pitti: is the problem only present in maverick builds installed to usb with a lucid usb creator?
<superm1> eg maverick isos directly on a cd or in a vm work fine
<apw> superm1, i have put the iso on a grub booted disk and they boot there
<ogra> apw,   * Adding recommends to libcrypt-passwdmd5-perl in syslinux-common   (Closes: #567649).
<ogra> from the syslinux changelog
<ogra> libcrypt-passwdmd5-perl is in universe
<apw> i would expect the issue to affect every use model of an ISO though
<apw> ogra, ok ... what would that mean
<superm1> bug 608382
<ubottu> Launchpad bug 608382 in syslinux (Ubuntu) "Error: Unkown keyword in configuration file" [Low,Triaged] https://launchpad.net/bugs/608382
<apw> that its not usable, and we fall back to an older one ?
<apw> superm1, yes thats the error we are chasing
<ogra> apw, thats what surprises me, i wouldnt expect it to fall back to anything but fail the image build
<superm1> syslinux gets installed to the key from the usb-creator on the system, so the version in lucid is older than that in maverick
<superm1> and hence doesn't support the new 'ui' keyword
<apw> superm1, OH
<apw> hrm
<apw> so this is a bug in the usb-creator only ?
<apw> ogra, ^^
<apw> i'll try making a CD to confirm
<ogra> apw, ah, that might be, try a real iso to confirm ;)
<apw> making plastic now
<superm1> if you use usb-creator on a maverick system it should in theory work fine (or if you backport syslinux to lucid)
<apw> superm1, i can also try that combination
<apw> though that is poor
<apw> a backport seems more appropriate
<superm1> well backporting it would cause usb-creator to fail to make lucid keys on lucid (beware)
<apw> superm1, HRMPH
<didrocks> I have the current iso which will be synced in 30 minutes, I'll try usb-creator there
<apw> didrocks, thanks
<pitti> didrocks: you could temporarily install maverick's syslinux for making the stick, I suppose?
<didrocks> pitti: I'm already on maverick on my netbook, so, should be fine there, isn't?
<pitti> ah, right
<apw> pitti, this is a bit of a disaster :/
<apw> so is the isolinux.cfg within the image ?
<apw> but usbcreator uses a local binary to make the stick versiion?
<ogra> yes, but i have no idea if usb-creator rewrites it
<apw> perhaps we should be sucking it out of the image
<apw> sounds like a bug in usb-creator rahter than anything else
<ogra> usb-creator should use both from the image file
<apw> yeah
<ogra> but iirc it wasnt possible to just replace isolinux with syslinux before
<apw> ogra, ok confirmed the real iso has 4.01 on it and boots as expected
<apw> so this is not an image issue, panic off :)
<ogra> phew
<ogra> file a bug :)
<apw> the bug is there already
<ogra> oh, k
<apw> just updatinging it now and adding a new task on usb-creator
<ogra> file a patch then :)
 * apw needs to find the author and rattle them
 * ogra points apw to ev
<superm1> an alternate way to solve this might be to set a fallback if gfxboot fails
<superm1> so lucid and earlier users would see a different bootsplash screen that's more texty, but functional
<apw> yeah though that makes the sexy installer less sexy
<superm1> or even make lucid and earlier boot directly to installer and just not give them a menu
<ev> branches welcome on usb-creator using syslinux from the ISO.
<didrocks> ogra: pitti apw: just confirming that it works well with last nebook ISO and maverick usb creator
<apw> ev, are the bits you need even on the CD ?
<didrocks> pitti: can you make an UNE respin once unity is built so?
<pitti> didrocks: sure
<didrocks> pitti: thanks a lot!
<ev> apw: the manifest says we have syslinux in the squashfs, yes.
<apw> ev, ok so it should be possible to fix this using the image ...
<ev> apw: correct
<ev> it just requires someone to do it, and all my time is going to the installer redesign at the moment
<ev> so, someone else :-P
<ev> to finishing the*
<apw> ev, pitti, ok i am getting further happy confirmations that using maverick to make the usb images of maverick boot just fine
<apw> so at least we have a work-arround
<apw> ev ack
<superm1> aren't you running into similar problems if you are loop mounting the squashfs to get syslinux out?  you would need to match versions still
<superm1> (match versions of squashfs that is)
<ev> how so?
<superm1> try to loop mount a maverick squashfs on a hardy kernel (or something oldish) and you'll see that it complains that the squashfs major/minor doesn't match
<ev> ah
<ev> damn
<superm1> also you wouldn't be able to burn amd64 cds to usb sticks on 32 bit systems anymore since you couldn't run the syslinux binary from that squashfs
<ev> right, indeed
 * ev ponders if the eventual switch to grub2 buys us anything here
<superm1> it'll probably be worse actually
<superm1> at this point you can come up with hacks/workarounds for fallbacks in syslinux i believe
<ev> yeah, seems like the fallback approach you suggested above is our only real option
<shtylman> is there a reason that neither the xulrunner nor xulrunner-dev package create a libmozjs symlink in /usr/lib? one has it under the /usr/lib/xulrunner-1.9.2/ folder and the other in an sdk folder... what is the proper path to search for when linking against mozjs then?
<apw> ev, well we could consider changing the ISO to contain the file we need (its only one right and tiny) in the un-squashed bit of the image
<superm1> another alternate more hacky solution might be an SRU to older usb-creators to detect newer cds and s/ui\ gfxboot/gfxboot/
<apw> yeah
 * apw goes confirm that its just the mbr which is an issue
<apw> ahh no we do run syslinux too ... so we'd fail there too ... bah
<apw> superm1, i suspect your hacky solution is a 'fair' one for the moment
<mkarnicki> It there a nice way to write binary masks in java? Should I use hex values, binary shift operator, or just 1, 2, 4, 8.. values?
<mkarnicki> Argh, forgot to say Hi :)
<apw> mkarnicki, for C i have always uses (1 << N) for bit N
<apw> i assume java has the same semantics
<mkarnicki> apw: same here, but I'm not sure what's the Java-fu or JAva-way of doing this :)
<mkarnicki> apw: I'll use 1 << n for time being
<mkarnicki> apw: thanks
<apw> superm1, i've tested your sed incantation and it seems to work for this particular purpose
<apw> so i've recorded it as a work-arround in the bug
<ogra> we just need to copy the binaries into the vfat or the iso
<ogra> that way you cant hit squashfs issues
<geser> Riddell: are still removals in Debian unstable regularly "imported" into Ubuntu or should removal bugs get filed?
<Riddell> geser: I guess I can do removals today
<ansgar> To get a package imported from Debian that does not yet exist Ubuntu, should I just fill a sync request as usual?
<geser> ansgar: yes
<andreoli> Hi, i'd like to build my own modified ubuntu kernel package and host it through a PPA, Can I blindly follow https://help.launchpad.net/Packaging/PPA/BuildingASourcePackage ?
<Riddell> tjaalton: can libxxf86misc be removed?  it's gone in debian
<andreoli> to supersede the official ubuntu name, is it sufficient to rename the package name by adding a ppan suffix? Or do I have to fiddle with files in the debian directory?
<andreoli> Is this the right channel for *.deb and launchpad questions?
<Riddell> andreoli: you can add a ppa suffix to the version number and that'll make it a newer version than the normal version
<Riddell> andreoli: I believe there's a #ubuntu-packaging for packaging
<andreoli> thx a lot
<tjaalton> Riddell: if there are no reverse-deps left, then yes
<zul> pitti: ping http://pastebin.ubuntu.com/469912/
 * Riddell wonders if we want to follow debian in removing swfdec0.8 from the archive
<maco> its about 18mo old isnt it?
<maco> and while there've been commits to vcs since then, not many, and no new releases
<pitti> zul: hm, where did the break go?
<zul> pitti: i removed it...this might be a better solution
<pitti> zul: but now you always ping 30 times
<zul> pitti:good point
<zul> pitti: at this point im open to suggests
<zul> pitti: suggestions even
<chrisccoulson> Riddell, i'm sure i remember rob savoye saying at UDS that swfdec is pretty much dead (although i might be wrong there)
<chrisccoulson> and see here: http://lists.freedesktop.org/archives/swfdec/2010-January/002490.html
<chrisccoulson> i don't think there's a reason to keep it in the archive really
<pitti> zul: oh, hang on, "exec" -> that could work indeed
<pitti> zul: I missed that
<pitti> zul: at this point we know that $HOME/debian-start exists and is executable?
<micahg> +1 for swfdec removal
<zul> pitti: it should...if they didnt do any funky stuff while trying to uninstall mysql because they think its broken
<pitti> zul: ah, it's mysql's $HOME, not any user's
<zul> pitti: correct
<rsavoye> swfdec is dead
<pitti> zul: what sets mysql's $HOME here? upstart scripts are run as root?
<rsavoye> they started shipping Gnash instwad of swfdec in GNOME
<zul> pitti: lemme show you the whole upstart job
<zul> pitti: http://pastebin.ubuntu.com/469922/
<pitti> env HOME=/etc/mysql
<pitti> ah
<pitti> zul: ok, looks fine to me
<zul> pitti: cool thanks
<pitti> zul: "end scrip
<pitti> -> cut&paste error, I presume?
<zul> pitti: yeap cut&paste error
<Sarvatt> Riddell: libxxf86misc and x11proto-xf86misc can both go - https://wiki.ubuntu.com/X/PackageNotes
<RoAkSoAx> Hi all, I'm having a package that is FTBFS after updating my pbuilder (today) with "fatal error: ltdl.h: No such file or directory" . Any ideas why might this be?
<TheMuso> RoAkSoAx: Sounds like you need to build-depend on libltdl-dev.
<TheMuso> Without looking into it further, so thats at a glance at your error.
<RoAkSoAx> TheMuso: yeah that's what I was thinking of, but what I wonder is why it was working yesterday and not today after updating my pbuilder
<TheMuso> RoAkSoAx: no idea.
<RoAkSoAx> TheMuso: Might it be because one of its build-deps requires libltdl3-dev? And i should amke a transition to libltdl7-dev?
<TheMuso> Possibly
<RoAkSoAx> TheMuso: thanks!
#ubuntu-devel 2010-07-28
<TheMuso> superm1: Would you like me to take care of the mythtv packages for the jack transition, or are you going to be touching them in the next couple of weeks for other updates?
<superm1> TheMuso, they're FTBFS right now on the current Qt in maverick, so they'll be touched by us at some point
<TheMuso> superm1: Ok thanks.
<Riddell> geser: I do believe I've caught up with the four month removals backlog, let me know if whatever you wanted didn't happen
<TheMuso> Riddell: Ah dude! You're the loan soldier again. This is really starting to suck. :)
<TheMuso> For you
<Riddell> yes, it is
<cooloney> iulian: hi Iulian, is that possible to upgrade guilt to 0.33 in Lucid? Lucid guilt is 0.32.2 which does not work with git 1.7.0.4 'Unsupported version of git (1.7.0.4)
<cutterjohn> ooo.. good guess.. hello
<cutterjohn> anyone else with x86-64 having the hdd go apeshit on wake from suspend as it takes LONGER to recover from suspend than just to ALT-SYSRQ+RSEINUB?
<cutterjohn> (10.4, x86-64, P8600, Catalyst 10.6, 4GB)
<RAOF> !ohmy
<ubottu> Please remember that all Ubuntu IRC channels share the same attitude of providing friendly and polite interaction with all users of all ages and cultures. Basically, this means no foul language and no abuse towards others.
<RAOF> I haven't seen that reported; try searching launchpad bugs?
<cutterjohn> anyone else with x86-64 having the hdd go apesh1t on wake from suspend as it takes LONGER to recover from suspend than just to ALT-SYSRQ+RSEINUB?
<cutterjohn> (10.4, x86-64, P8600, Catalyst 10.6, 4GB)
<RAOF> If you can't find one, file one.
<cutterjohn> sorry, didn't see your initial response since I thought that I go autocensored
<RAOF> No, we rely on people to speak appropriately.
<cutterjohn> doesn't happen ALL of the time, just enoughbt of the time to be INCREDIBLY annoying for an LTS release...
<RAOF> If you can track down the circumstances under which it happens, that would be very helpful on whatever bug you find/file.
<cutterjohn> OK, better file a bug report since I just have no idea what to try to debugon my own since I'm not even touching VM half the time that it happens...
<RAOF> You might also want to try using the free drivers rather than fglrx to see if that's the culprit.
<cutterjohn> or even anythign CPU or otherwise intensive
<cutterjohn> (Personally I'm suspecting the ageold daemon, npviewer ATM)
<ajmitch> sounds similar to something I've seen
<cutterjohn> what GPU are you running and driver?
<ajmitch> fglrx, again, with whatever was in lucid
 * ajmitch was going to file a bug about it after tracking down a bit more info
<cutterjohn> the OSS driver? or did you do the restricted(ctalyst) driver/
<cutterjohn> (I had to dump the OSS driver as it's OGL support is WAY too liited)
<ajmitch> fglrx is the restricted driver
<cutterjohn> (er limited)
<cutterjohn> have you filed a bug report?  If so I'll just ... well... anecdotally add my exp as I've got nothing "hard" to add...
<ajmitch> as I said, no I haven't yet :)
<cutterjohn> ah.. catalyst is the proper package name for the proprietary driver BTW
<cutterjohn> fglrx is just a piece of it
<RAOF> fglrx is the driver, though.
<cutterjohn> yes, but it's only the base X11 driver there are other driver components beyond that
<RAOF> Right.  There's a libgl.
<RAOF> fglrx is what we call it, because that's the driver name.
<cutterjohn> ok, let's not argue over trivialities
<RAOF> Indeed.
<cutterjohn> (better to call it catlyst though IMNHO)
<RAOF> Everyone should be able to pick up what you mean if you say âcatalystâ; you'll just find us referring to it as fglrx.
<RAOF> Particularly because that's what the package is called :)
<cutterjohn> OK, anyways, I guess that I'll go fap lAUNCHPAD
<RAOF> Yeah.  That's where to find bugs!
<cutterjohn> (er at launchpad)
<cutterjohn> got nothing to detail ... but... maybe someone else will add something useful by chance
<cutterjohn> (well other than crappy resume from suspend times...)
<cutterjohn> bug reporting is doing its best to defeat me ATM
<cutterjohn> web UI is useless as are the directions for going through the gui...
<cutterjohn> (since they dont apply)
<cutterjohn> yay bug reports only apply for PIDs or packages... how entirely useful
<cutterjohn> (I think that I'm at the wrong UI...)
<RAOF> Or symptoms.
<ajmitch> it's generally preferred to use the ubuntu-bug tool, since that automates much of the log attaching, etc
<cutterjohn> yeah, I tried ubuntu-bug but it whines about no PID
<cutterjohn> if run w/no arg
<cutterjohn> and the web-UI has been totally screwed apparently
<cutterjohn> it's a freaking adventure game with no solution
<cutterjohn> ubuntu-bug 0 complains about no PID 0
<ubottu> Error: Could not parse data returned by Launchpad: 0 (https://launchpad.net/bugs/0)
<cutterjohn> (also I have NO log to attach)
<cutterjohn> (no PID to assign it to)
<cutterjohn> (just a general cockup)
<cutterjohn> (that's variably repeatable... although with no discernable triggers)
<ajmitch> if you believe it's kernel related, put it against the 'linux' package
<ajmitch> most suspecd/resume bugs are, though this one has a good chance of being fglrx
<cutterjohn> I don't... my personal guess is npviewer... but I could be entirely wrong
<cutterjohn> it could be nautilus or any of the other GNOME VFS daemons too...
<cutterjohn> just no idea
<cutterjohn> just LOTS of disk activity, but not much CPU usage
<cutterjohn> (when I get to a GUI/terminal)
<ajmitch> if it's t all like what I see, it seems to be very much vm-related
<cutterjohn> sometimes I'm using 0 VM, sometimes a few 100mb no diff
<ajmitch> iotop doesn't usually point to any one process that's hitting the disk a lot
<cutterjohn> it can happen right after a fresh powerup
<cutterjohn> or not
<cutterjohn> it's one of THOSE bugs..
<cutterjohn> no way to force it to happen that I know of and as far as I can see nothing obviously wrong
<cutterjohn> (BTW: I've been doing lsof when I can get to a terminal nothign striking there either..)
<cutterjohn> (as root)
<cutterjohn> afk for a few minutes... then I'll deal with the bug "reporting" system again... been changed too much to discourage bug reports IMO better to be liberal in closing them than discouraging them
<RAOF> cutterjohn: You know, if you run just âubuntu-bugâ it'll pop up a list of symptoms for you to chose from?
<RAOF> I don't think that's new in Maverick.
<RAOF> Would anyone care to sponsor mesa 7.8.2 http://cooperteam.net/Packages/mesa_7.8.2-2ubuntu1.dsc & http://cooperteam.net/Packages/mesa_7.8.2-2ubuntu1_source.changes ?
<RAOF> It contains a crash fix required for GLX 1.3 (ie: Unity & clutter) before we can upgrade to Xserver 1.9
<cutterjohn> BAK
<cutterjohn> RAOF Yes, I tried that and it bitched at me
<cutterjohn> You need to pick a package blah blah
<cutterjohn> but I've got no package to target... so...
<RAOF> linux
<cutterjohn> actually it gives me no option to pick a package to begin with, just bitches about it
<cutterjohn> if I pick other
<RAOF> Right.  It wants you to run âubuntu-bug linuxâ
<cutterjohn> wow, how helpful of it
<RAOF> (Because the kernel is a reasonable guess as to the package)
<cutterjohn> ok that worked, i'm going "I don't know" because I don't
<andersk> Can I draw somebodyâs attention to bug 610710, which makes dpkg-dev uninstallable?
<ubottu> Launchpad bug 610710 in Ubuntu "Sync libtimedate-perl 1.2000-1 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/610710
<andersk> The timedate source package was replaced with libtimedate-perl, but timedate was deleted in Ubuntu without libtimedate-perl having been synced.
<cutterjohn> well, that was f-ing useless as I got to enter no desc... clues as to what adventurous steps I should take to actually enter a bug report with a desc?
<cutterjohn> oh wait, it looks like it opened a new web page... brb
<cutterjohn> (without popping it to the foregorund ffs)
<andersk> Is there a way to get a list of all the packages Riddell deleted so I can file more bugs?
<cutterjohn> ok, thanks guys got in a bug report finally after playing the IF game Submit an Ubuntu Bug Report game
<cutterjohn> Infocom would be astounded
<cutterjohn> (and I didn't get all the nice packaging and extras for playing it...)
<cutterjohn> most amazing thing, my desktop icons are now gone as well, with no changes in the nautilus desktop display config
<pitti> Good morning
<TheMuso> Hey pitti.
<pitti> hey TheMuso, how are you?
<pitti> zul: ... mysql ... -v ..
<pitti> zul: I'll reupload myself
<dholbach> good morning
 * pitti hugs dholbach
 * dholbach hugs pitti back
<zyga> zul, ping
<rsalveti> hallyn: just sent a request to merge for bug 610742
<ubottu> Launchpad bug 610742 in qemu-kvm (Ubuntu) "qemu shows "qemu: Unsupported syscall: 335" for pselect in Maverick" [Undecided,New] https://launchpad.net/bugs/610742
<rsalveti> just to remove the annoying unsupported syscall that was removed for lucid
<rsalveti> it's just a backport from upstream, so np applying it now
<rsalveti> lool: you may also be interested, if you plan to run user mode emulation on current maverick qemu
<rsalveti> time to get some sleep :-)
<Damascene> hi,
<Damascene> ArneGoetje, there?
<Damascene> bug 603022
<ubottu> Launchpad bug 603022 in mlterm (Ubuntu) "[MIR] mlterm" [Undecided,New] https://launchpad.net/bugs/603022
<Damascene> is it possible to include Mlterm in main before the next release?
<ArneGoetje> Damascene: yes
<Damascene> thanks
<vish> ArneGoetje: hi , could you review merge https://code.launchpad.net/~joel-auterson/ubuntu/maverick/ibus/newmenuname/+merge/30391 ?
<ArneGoetje> vish: yep
<vish> thanks.
<mvo> DktrKranz: hi, would you be interessed in adding a aptdaemon backend to gdebi? now that we use the debfile.py from python-apt that should be really straightforward :)
<lool> rsalveti: You could have a patch which doesn't emulate pselect but kills the warning
<Chipzz> ArneGoetje: are you aware that this is not the first time Damascene asks this question, that several concerns were raised, and that I don't see those concerns addressed in the MIR?
<ArneGoetje> Chipzz: which concerns do you mean?
<Chipzz> ArneGoetje: one concern I remember was integration with the fontconfig etc stack
<Chipzz> or the lack thereof
<Chipzz> ArneGoetje: there were other concerns too, but he asked that question, what, about a month ago I think, and I saw several concerns (which the fontconfig issue was one of) raised, and I seriously doubt those issues have been resolved
<dholbach> who can I persuade to give a packaging training session on 12th Aug 12:00 UTC or 19th Aug 18:00 UTC or 26th Aug 0:00 UTC? :)
<dholbach> (19th Aug 18:00 UTC might be taken already)
<ArneGoetje> Chipzz: Do you have any alternative for RTL language users?
<Chipzz> ArneGoetje: no, just making you aware of the situation
<Chipzz> ArneGoetje: you gave him a straight "Yes" without being aware of the larger picture
<ArneGoetje> Chipzz: I am aware of those issues and also that we cannot fix them. The proper solution would be to fix vte. But I don't see this happening anytime soon. Therefor mlterm is currently the only possibility to give RTL language users a working terminal.
<c_korn42> hello. I wanted to install lucid yesterday and tried the daily build (alterate amd64). after clicking "install ubuntu" I got the error: "uncompress error -- system halted" is this a known problem ? I could reproduce it on my notebook. I created a bootable usb stick from the iso using Ubuntu's creator
<soren> I'm putting some finishing touches on the first revision of some OpenStack packages. OpenStack does not require copyright assignment, so every single file may have lots of copyright holders, and almost no two files will have the same set of (copyright holder, year) tuples. Am I really supposed to repeat the copyright statements from every single source file in debian/copyright?
<diwic> soren, I'm afraid so
<soren> Does anyone know off-hand of an example of such a monstrous debian/copyright. We're hardly the first project to not require copyright assignment, so there must be prior art to this.
<diwic> soren, just pick one and see, I just had a look at audacity e g
<diwic> soren, that one does not follow the spec
<diwic> soren, so forget my advice and ask someone else. Sorry.
<soren> :)(
<soren> :)
<DktrKranz> mvo: hi! could do, I'm short of time lately, but I plan to fix some issues before maverick and squeeze are out, and will save a couple of days to do some work on it
<soren> Perhaps an archive admin could weigh in on acceptance criteria for this sort of thing?
<mvo> DktrKranz: nice, you rock :) if I find some spare moments, I will try to attack it too, but time is short
<mvo> DktrKranz: just keep me updated so that we don't duplicate anything :)
<DktrKranz> mvo: it seems "being short on time" is a common ill :)
<mvo> yeah :)
<vish> tkamppeter: hi .. attached a debdiff to fix Bug #554174 , could you review it ?
<ubottu> Launchpad bug 554174 in One Hundred Paper Cuts "Inappropriately appears in Ubuntu Software Center "Developer Tools" > "Python"" [Low,In progress] https://launchpad.net/bugs/554174
<soren> cjwatson: You're listed as the AA for today, maybe you can help me out? https://wiki.ubuntu.com/PackagingGuide/Basic#Copyright says "
<soren> In the case of large numbers of trivial copyright holders, not all need be mentioned (ask on IRC if you are in doubt), but all licenses must be listed"
<soren> (last bullet under "Common errors")
<ogra> soren, he is on vac. afaik
<soren> Oh, right.
<soren> Darn it.
<soren> It also says later on that identifying copyright holders is a legal requirement.
<soren> ...so I feel at a bit of a loss.
<ogra> soren, /usr/share/doc/linux-image-$(uname -r)/copyright ;)
<ogra> i dont think it requires copyright assignment, does it ?
<soren> I don't believe it does, no.
<soren> Heh: Linux is copyrighted by Linus Torvalds and others.
<soren> that was easy.
<ogra> yeah :)
<soren> Now I just need to represent that in a DEP-5 style debian/copyright.
<dholbach> Daviey: what was the wysiwyg editor you recommended again?
<mvo> DktrKranz: I upload 0.6.2 for now and sync it to ubuntu
<soren> Would http://paste.ubuntu.com/470166/ be an acceptable debian/copyright? Of course assuming that it's true :)  The vast majority of the code is copyright OpenStack LLC and/or NASA, the rest is copyright a bunch of other people.
<Damascene> I don't know where I should post this but the link (partners) http://www.ubuntu.com/partners/program in the wiki is broken
<DktrKranz> mvo: good, as several people reported bugs against kdesudo
<dholbach> Damascene: https://launchpad.net/ubuntu-website/+filebug
<mvo> DktrKranz: great, one step a time :)
<Damascene> Report a bug about Ubuntu Website "Pro..."?
<Riddell> asac: do you have an opinion on bug 598874 ?
<ubottu> Launchpad bug 598874 in libmpcdec (Ubuntu) "Please sync libmpc 2:0.1~r459-1 (universe) from debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/598874
<Damascene> bug 609553
<ubottu> Launchpad bug 609553 in Ubuntu Website "bad partners link in the wiki" [High,Triaged] https://launchpad.net/bugs/609553
<Damascene> it was reported earlier
<asac> Riddell: i only pushed it to get it rebuilt ;)
<asac> so i dont have a qualified opinion ;)
<asac> Riddell: while you are at it ... could you please sync ntrack 008-1 from unstable ;)?
<asac> Riddell: http://ftp.de.debian.org/debian/pool/main/n/ntrack/ntrack_008-1.dsc
<Riddell> asac: ok done
<Riddell> asac: how can I tell why libqtwebkit4 isn't installable on arm?
<ogra> hmm, whats up with libtimedate-perl ?
<asac> Riddell: good question. ogra could try it locally and tell you whats going on (i dont have a board running)
<asac> i would assume that something failed to built ;)
<asac> (or is out of sync)
 * ogra only has a chroot either, but that should do
<ogra> The following packages have unmet dependencies:
<ogra>   libqtwebkit4: Depends: phonon but it is not going to be installed
<ogra> E: Broken packages
<ogra> Riddell, ^^^
<Riddell> ogra: what happens if you try to install phonon?
<ogra> Riddell, works
<Riddell> umm
<ogra> apt-get install libqtwebkit4 phonon that is
<Riddell> ogra: libtimedate-perl has only just been synced
<ogra> oh, k
<Riddell> ogra: so now you can install libqtwebkit-dev ?
<ogra> apt-get install libqtwebkit-dev phonon seems to work
<Riddell> myeh, so why is kde4libs not building
<Riddell> http://launchpadlibrarian.net/52626705/buildlog_ubuntu-maverick-armel.kde4libs_4%3A4.4.92-0ubuntu4_FAILEDTOBUILD.txt.gz
<Riddell> ogra: could you try installing all the packages it's doing there?
<ogra> did it fail again ? i just gave it back
<Riddell> ogra: finished 3 minutes ago
<ogra> ah, k
<ogra> that was quick
<Riddell> ogra: quick because it failed :(
<ogra> apt-get build-dep kde4libs seems to have no probs
<Riddell> ogra: so it's a complete mystery
<ogra> i dont see any webkit in the deps it installs though
<Riddell> ogra: then your apt sources haven't updated to the newest version?
<Riddell> this is the build-deps  http://kubuntu.pastebin.com/Dvvm5fjC
<ogra> i just did an apt-get update
<ogra> in fact i had to add a deb-src entry
<ogra> so i would definately expect the latest versions to be there
<Riddell> ogra: then apt-cache showsrc kde4libs  should show 4:4.4.92-0ubuntu4 which build-deps on libqtwebkit-dev
<ogra> Version: 4:4.4.92-0ubuntu4
<ogra> libqtwebkit is in there
<ogra> i dont get why i would get the old deps
<Riddell> ogra: this may all be down to the libtimedate-perl issue
<ogra> oh, that might be indeed
<ogra> it just finished building
<ogra> i'm watching it anyway for some image testbuilds, if it shows up on ports i'll give back kde4libs again
<Riddell> ogra: it's an arch all package, I just accepted the binary, we can start building stuff again after the next publisher run
<ogra> Riddell, great, though ports seems to have a slight delay in mirroring
<Damascene> ArneGoetje, what should I do now?
<Damascene> asac, can we talk about Bug #603022
<ubottu> Launchpad bug 603022 in mlterm (Ubuntu) "[MIR] mlterm" [Undecided,New] https://launchpad.net/bugs/603022
<xelister> hi, what is the best way to quickly learn how to make custom livecd?
<Riddell> xelister: https://help.ubuntu.com/community/LiveCDCustomization
<ricotz> hi, could someone trigger the build of https://edge.launchpad.net/ubuntu/+source/gtk+2.0/2.21.5-1ubuntu1 the missing dep libgdk-pixbuf2.0-dev is available now
<asac> Damascene: not sure ;) ... what you want to say?
<mvo> mdz: we talked a while ago about the super slow update-manager progress bar with nvidia, is this still a issue for you? it appears that I can (finally!) reproduce the problem
<xelister> Riddell: I need to choose what things are installed by default (throw out some applications, add nvidia and radeon drivers),  and run some custom script on boot.  Easy to do?
<xelister> Riddell: also, the livecd should have propertiary drivers for both nv and radon and on boot detect and choose the needed one.. will that work?
<xelister> also make bootup fast, just boot to live cd, not offer to install
<Riddell> xelister: that URL explains how to install and uninstall bits
<allquixotic> Hi, I am trying to build a source package from lp:~ubuntu-desktop/rhythmbox/ubuntu on Lucid, but I get http://paste.ubuntu.com/470225/ Any suggestions?
<ansgar> allquixotic: Build-dependencies not installed?
<allquixotic> ansgar: I have all the required build-depends.
<allquixotic> bzr-buildpackage can't find the source tarball. So I guess the question is where are the sources for the git snapshot packages in the current Maverick development for ubuntu-desktop.
<allquixotic> nevermind; answered my own question! I needed a deb-src line for maverick.
<Riddell> tjaalton: the guy who does the cool electric piano keyboards with kubuntu on is asking "I need also to know IF the new Xorg server 1.8 or 1.9 is included in 10.10" do you have a quick answer?
<zul> zyga:pong
<zyga> zul, are you going to work on the server papercuts project?
<zyga> ivanka, congratulations on walking 100km :-)
<zul> zyga: yes
<zyga> zul, I'm interested in the tracepath/traceroute papercut
<zul> zyga: ok
<zyga> zul, would you be interested in taking over and finishing the code required to implement it?
<zul> zyga: sure
<zyga> zul, great, if you want I can help you with this and share the branch I have for this feature
<zul> zyga: yes please
<zyga> zul, one second
<zyga> zul, I'm copying my branch (a snapshot of it really) to people.c.com
<ivanka> zyga: thank you :-)
<zyga> zul, http://people.canonical.com/~zyga/trunk.dbus.tar.gz
<zyga> zul, get that tarball please
<zyga> zul, hopefully your need can motivate me to finish this :D
<zyga> ivanka, quite a feat really, how did you train to do that?
<zyga> zul, this code is really different from what c-n-f was before but it has support for a quirk like this
<zyga> zul, what it _doesnt_ have is the user interface
<zyga> zul, if you think that finishing this is within the scope of your project I'll gladly walk you through the coded
<zul> zyga: actually its probably not a papercut if its modiyinfg code for command-not-found you might want to talk to mvo about it though
<zyga> zul, ok
<zyga> zul, _or_
<zyga> zul, you could get the trunk from ubuntu and just add a one-liner that knows this particular problem
<zul> zyga: i could do that :)
<zyga> zul, the code is in lp:ubuntu/command-not-found AFAIR
<zul> zyga: gotcha
<bigon> could someone have a look at https://bugs.edge.launchpad.net/debian/+source/pygi/+bug/604121
<ubottu> Launchpad bug 604121 in pygi (Ubuntu) "Please remove pygi package from maverick archive" [Wishlist,Confirmed]
<bigon> ?
<tkamppeter> vish, your debdiff is OK. If you have upload rights on system-config-printer (in main), upload it (but take into account that I uploaded it yesterday, apply your change to the newest version).
<vish> tkamppeter: i dont have upload rights :s , could you upload it?
<tkamppeter> vish, no problem, and thanks for the fix.
<vish> tkamppeter: np , thanks :)
<tkamppeter> vish, uploaded.
<vish> neat! thanks.
<Damascene> were I can find Rick Spencer?
<RainCT> davmor2: He's at GUADEC, dunno if he is connecting to IRC..
<RainCT> err Damascene
<Damascene> what?
<Damascene> are you Rick?
<davmor2> Damascene: this message was for you -> He's at GUADEC, dunno if he is connecting to IRC..
<Damascene> ok thanks
<RainCT> Damascene: No. He usually hangs around in this channel, but this week he is at a conference (with rather bad internet connection) so I don't know if he'll be connecting. I guess you can just send him a mail.
<Damascene> I think he found a good connection today. I'm really upset with him comment on my MIR
<Damascene> if there is a program with bug it should be fixed or replaced. we just asked for alternative and it become "won't fix"
<Damascene> bug 603022
<ubottu> Launchpad bug 603022 in mlterm (Ubuntu) "[MIR] mlterm" [Undecided,Won't fix] https://launchpad.net/bugs/603022
* Riddell changed the topic of #ubuntu-devel to: Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper-lucid | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | builds broken until libtimedate-perl reappears
<RainCT> Damascene: Well, a bug isn't really the place to discuss such a thing.
<Damascene> hi rickspencer3
<rickspencer3> hi Damascene
<Damascene> I've updated bug 603022 with some information if  you don't mind
<ubottu> Launchpad bug 603022 in mlterm (Ubuntu) "[MIR] mlterm" [Undecided,Won't fix] https://launchpad.net/bugs/603022
<Damascene> I hope you change your mind
<rickspencer3> Damascene, I'm still confused
<rickspencer3> why can't users just install their terminal of choice?
<rickspencer3> I'm not sure what problem is attempted to be solved
<Damascene> rickspencer3, the same could be said about translations and fonts, what is language selector for?
<Damascene> any one could just install those things by him self
<rickspencer3> Damascene, but you're talking about a terminal
<rickspencer3> right?
<Damascene> yeah, do you question the important of terminal?
<rickspencer3> no
<Damascene> so what is it?
<hallyn> rsalveti: ok - thx for the heads up, though I can't do merges myself at the moment.  I suspect kirkland will see it.
<kirkland> halfline: what am I looking at?
<rickspencer3> Damascene,  I question the value of shipping and supporting 2 terminals to solve the case
<Damascene> we can't use ls, apt-get cat and many other terminal programs probably with vte
<Damascene> it's not that you are going to install it for every users
<rickspencer3> the solution sounds rather complicated and hard to maintain when there is a work around as easy as installing a different terminal
<Damascene> only the users who chose to localize their systems
<rickspencer3> right
<rickspencer3> I think if we were to invest in this it would make much more sense to make Gnome Terminal work
<kirkland> hallyn: what am I looking at?
<Damascene> rickspencer3, I'm getting the idea that you have not read the original bug carefully
 * hallyn scrolls up
<rickspencer3> Damascene, perhaps
<hallyn> 02:29 < rsalveti> hallyn: just sent a request to merge for bug 610742
<ubottu> Launchpad bug 610742 in qemu-kvm (Ubuntu) "qemu shows "qemu: Unsupported syscall: 335" for pselect in Maverick" [Undecided,New] https://launchpad.net/bugs/610742
<Damascene> rickspencer3,  all this have been discussed earlier
<hallyn> kirkland: ^
<Damascene> rickspencer3, one of the main things was that vte is not going to be fixed any time soon while Mlterm is ready and it can just be a choice in Language Selector
<Damascene> just a choice
<rickspencer3> that doesn't change my feedback
<Damascene> ok, thanks for helping
<rickspencer3> I'm not trying to be argumentative here, I'm just not convinced we've arrived at a good solution yet
<ArneGoetje> rickspencer3: last thing I heard was that upstream is not interested in fixing vte for RTL language users, since it would be "too difficult to do so". So, who do you think can fix vte and in which time frame?
<rickspencer3>  ArneGoetje I don't know
<ArneGoetje> rickspencer3: well, mlterm is the _only_ terminal out there which supports RTL languages properly.
<rickspencer3> so users who need it can install it
<rickspencer3> my point is that the work around is not too hard, but the solution that has been proposed to avoid the work around seems overly complex and requires supporting another VT
<ArneGoetje> rickspencer3: then that should be communicated better
<rickspencer3> I'm communicating right now
<ArneGoetje> rickspencer3: I mean to the RTL language users
<rickspencer3> what specifically was not communicated?
<rickspencer3> never mind, it's a moot point
<ArneGoetje> rickspencer3: That mlterm is what they want as a terminal solution and how to get it
<rickspencer3> so many many people choose alternate software, that's why we have Universe and that's why we have software-center
<Damascene> rickspencer3, but you don't ship broken software and tell a user to search for a solution him self in a bug report suggesting using mlterm. It will be kind of you if you suggest that early when a user seeks for language support
<kirkland> hallyn: ah, merging qemu ... personally, i'd say just wait for 0.13;  but if you're feeling motivated, you can do the new dot release
* Riddell changed the topic of #ubuntu-devel to: Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper-lucid | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<Riddell> topicdiff, builds no longer broken now that libtimedate-perl is in again
<ogra> still not promoted to ports yet :/
<geser> Riddell: thanks for those removals yesterday
<Riddell> geser: mm well I removed a few packages which ought not to have been :(
<LucidFox> Hmm, I wonder
<bigon> mmmm I've added the ubuntu-mozilla-daily ppa but it seems that some info of the Release file are not take into account by apt
<LucidFox> Would it be possible to request for my Ubuntu developer privileges to be suspended until Canonical's font is publicly released?
<bigon>  500 http://ppa.launchpad.net/ubuntu-mozilla-daily/ppa/ubuntu/ lucid/main Packages origin ppa.launchpad.net
<Damascene> rickspencer3, sorry for heating things like that but I thought I should provide as much support as I can for my language and making ubuntu better
<rickspencer3> snap
<rickspencer3> I hope he didn't go away mad
<LucidFox> Alternatively I guess I could just publicly upload the font, presumably at the cost of my Ubuntu membership but meh
<hallyn> kirkland: that particular bug appears to be a papercut, so i'd say let's wait
<rsalveti> lool: the patch basically kills the warning
<rsalveti> was the upstream decision
<rsalveti> hallyn: kirkland: will qemu be updated before A3?
<rsalveti> that's why I created the bug
<lool> rsalveti: The initial patch implemented the syscall using libc; I think it's not acceptable
<rsalveti> because I'm using qemu with rootstock, and without this patch my logs are huge, and I have to filter it to not show to the user
<lool> rsalveti: I wonder why we didn't send a patch to use sys_pselect instead
<rsalveti> lool: probably because no one worked on this
<lool> rsalveti: I would recommend you don't merge a patch implementing the syscall if it's against upstream recommendation
<rsalveti> it should be an easy fix, but someone have to do it :-)
<lool> rsalveti: did you plan to add a different patch which just skips the warning for this syscall?
<rsalveti> lool: but this is my patch
<lool> rsalveti: If you don't have the time yourself, you could ask Michael, he wrote the original one
<ttx> slangasek: I'd welcome a comment of yours on bug 570944 -- if you agree with it, I'll make it happen.
<ubottu> Launchpad bug 570944 in samba (Ubuntu) "passwd : gives "Authentication token manipulation error"" [Medium,Triaged] https://launchpad.net/bugs/570944
<rsalveti> just skipping the warning
<lool> rsalveti: Oh ok
<lool> rsalveti: I didn't see that one
<lool> rsalveti: but we're on the same page
<rsalveti> that's why this patch is simple and can be merged
<lool> rsalveti: Right
<rsalveti> lool: the original patch from michael was dropped
<rsalveti> they just got the one that adds the define
<rsalveti> and later one they pushed another patch just to remove the message
<rsalveti> *later on
<ttx> Hmm... PPAs "start in..." estimates look a lot like XP filecopy progress bar ones.
<rsalveti> lool: the patch that implements pselect was dropped from our package when was updated for 12.3
<lool> rsalveti: I'd love if you could review which patches were dropped
<lool> rsalveti: I dont think it was a good change to remove all patches in there, without any warning (at least I didn't get one)
<rsalveti> lool: well, this is the first I noticed, but I can review the others
<rsalveti> because when I started apt-get I got a huge huge log
<rsalveti> and when I tested on lucid it worked fine
<rsalveti> lool: kirkland: if we're not getting the qemu .13 update before a3 I'd like to get this patch merged, if possible
<bankix> Hi. I'm trying to build a deb package for Ubuntu 10.04. But depending on the architecture (i386,amd64) I have to delete one or another directory (to get rid of platform-dependet stuff) and use one or the other startup script. How can I detect which platform is currently being built?
<hallyn> rsalveti: lool: yes, we will be merging qemu before A3
<hallyn> we're reallly hoping for 0.13.0, but if that doesn't happen then definately 0.12.5
<Riddell> hmm, builds are still broken
<hallyn> 0.13.0 is supposed to be GA'd a few days before freeze...
<Riddell> lamont: when is libtimedate-perl 1.2000-1 likely to be available to buildds?
<rsalveti> hallyn: oh, ok, that would work then :-)
<rsalveti> lool: will see if we're also missing any other patch, so it can be included on 0.13 when we have the new release
 * ogra kicks the publisher
<hallyn> rsalveti: .
<hallyn> rsalveti: just wondering, how annoying is the pselect thing?  does it consume all cpu with constant scrolling of error msgs, or jsut warn once?
<hallyn> rsalveti: i see no problem with the patch, so my only motivation for nack'ing would be my insane desire to keep the delta to upstream minimal
<rsalveti> hallyn: basically I can't read the logs if I don't filter it
<hallyn> heh
<hallyn> all right, that sounds worthwhile then
<hallyn> thanks
<rsalveti> should be easy to remove it later
<_UsUrPeR_> hey all. thought I would point out something that may apply to ubuntu developers. I have downloaded and re-downloaded the ubuntu alternative 64-bit installation cd 3 times now, and there appears to be a problem with the kernel during installation. The errors I am seeing in the installation log have been recorded here: http://pastebin.com/usdjXmDB
<_UsUrPeR_> If this is still not the correct forum, I can put in a bug report, or just move this to #ubuntu, and I apologize.
<_UsUrPeR_> FYI: I am using the alternate installation for LVM support, and have attempted to install with and without an internet connection.
<SpamapS> pitti: ping
<rsalveti> hallyn: thanks for the review, no I need need someone with a good heart and upload permission :-)
<rsalveti> lool: kirkland: ^? :-)
<rsalveti> *now
<hallyn> rsalveti: or mathiaz perhaps
<kirkland> rsalveti: i can sponsor for you;  have you pushed a branch and a merge proposal to launchpad?
<rsalveti> kirkland: yep, all ready :-)
<rsalveti> https://code.edge.launchpad.net/~rsalveti/ubuntu/maverick/qemu-kvm/fix-610742/+merge/31120
<hallyn> holy cow!  i thought a jet was going overhead.  no, it just started POURING out there
<pitti> hello SpamapS
<cyphermox> kirkland, I'm wondering about the status of the isc-dhcp sync, or if there are any blockers for it.  it replaces the packages of dhcp3 with the new version 4 packages, which I'd need for new versions of network-manager.
<bdrung> dholbach: ping
<dholbach> bdrung: pong
<bdrung> dholbach: the sponsor overview looks wrong: http://qa.ubuntu.com/reports/sponsoring/
<dholbach> what about it?
<dholbach> can you file a bug?
<dholbach> I'm very very busy
<bdrung> dholbach: the css file seems to miss
<dholbach> bdrung: which one?
<dholbach> launchpad.css is there and readable
<dholbach> same goes for the sorttable.js
<bdrung> launchpad.css
<dholbach> which browser do you use?
<dholbach> the page works for me in firefox and chromium
<bdrung> firefox
<dholbach> maybe you can be more specific about what's broken?
<bdrung> dholbach: http://img6.imageshack.us/img6/6507/sponsoring.png
<bdrung> dholbach: it look like the default style without css applied
<dholbach> weird, I don't get that in chromium or firefox
<bdrung> dholbach: and sorting the columns doesn't work, too
<dholbach> oh yeah, that's broken here too
<dholbach> can you file a bug for that?
<bdrung> dholbach: damn, i found the reason: adblock blocks it
<bdrung> filter: /sponsoring/*
<dholbach> nice
<dholbach> ha, and the sorting works again :)
<bdrung> dholbach: btw, https://code.launchpad.net/~dholbach/ubuntu-sponsoring/trunk contains the latest source?
<dholbach> yes
<bdrung> dholbach: you will get a merge request soon :)
<dholbach> good
<ogra> Riddell, i wonder if the publisher is dead
<ogra> no trace of libtimedate-perl anywhere
<Riddell> ogra: it's in the archives, doesn't seem to be available to buildds though, I pinged lamont
<ogra> i dont see it, neither http://ports.ubuntu.com/ubuntu-ports/pool/main/t/timedate/ nor http://archive.ubuntu.com/ubuntu/pool/main/t/timedate/ seem to have it
<shtylman> where should I file a xulrunner packaging bug?
<shtylman> launchpad? under the xulrunner project?
<shtylman> or is there a better location?
<ScottK> Riddell and ogra: http://archive.ubuntu.com/ubuntu/pool/main/libt/libtimedate-perl/
<ScottK> http://ports.ubuntu.com/ubuntu-ports/pool/main/libt/libtimedate-perl/ too.
 * ScottK retries
<micahg> shtylman: maybe come discuss in #ubuntu-mozillateam
<Riddell> ScottK: ah
<ogra> ScottK, oh, weird
<ScottK> Riddell: Did the old timedate source package get removed yet?
<ogra> i dont think so
<Riddell> ScottK: I think the current problem is the libmpcdec3 -> libmpcdec6 transition
<ogra> it is used in lucid
<Riddell> which will stop phonon being installed
<ScottK> ogra: Right, but it should be removed from Maverick.
<ogra> ah, indeed
<Riddell> ScottK: yes the old source package got removed that's what cause the problem
<ScottK> OK.
<ScottK> We'll see how far this one gets.
<Riddell> ScottK: which one?
<ScottK> This retry of kde4libs
<Riddell> ScottK: it won't
<ScottK> OK.
<Riddell> ScottK: it's blocked on the libmpcdec3 -> libmpcdec6 transition
<Riddell> I'm test compiling xine now
<ScottK> Cool.
<ogra> ah, my image build seems to proceed fine now
<LucidFox> Okay, sorry to be flogging a deceased equine, but...
<LucidFox> Where can I write to get my access to the private font PPA removed?
<sladen> LucidFox: why do you want to? ... you can just chose not to use it/not to install it
<sladen> LucidFox: or if you have already enabled it, you can disable it by editing /etc/apt/sources.list
<LucidFox> Because I feel disgusted about having this privilege that non-members don't have, and I'd rather be on the same terms as them here. And if Canonical can't do that by releasing the font publicly, then I want to have as little access to it as non-members have.
<sladen> LucidFox: okay, this is an interesting (and wider, political issue)
 * vish thinks LucidFox is not really understanding the issue , why it was released as it is now
<sladen> LucidFox: could you write it up on  https://bugs.launchpad.net/ubuntufontbetatesting/+filebug  and I shall try to get some answers
<LucidFox> vish> I received comments stating why
<LucidFox> I still don't like having access to the closed beta of a proprietary font.
<LucidFox> *Even* if I'm not going to actually exercise that privilege.
<sladen> LucidFox: could you please write it up above;  the conversation will scroll off the top of IRC
<vish> LucidFox: cool, then sladen's two choices are the best :)
<sladen> LucidFox: but on Launchpad I can try to get a solution both to your particular access, and hopefully the wider issue
<LucidFox> the wider issue?
<LucidFox> What wider issue? It's just me being weird :)
<sladen> LucidFox: the first issue you've asked is "can I write to get my access to the private font PPA removed"
<sladen> LucidFox: the second issue is "I feel disgusted about having this privilege that non-members don't have, and I'd rather be on the same terms as them here."
<sladen> LucidFox: the first is a technical problem;  the second is a social issue and so much harder to fix, but it is good that you have raised it
<LucidFox> Well, I'm the only one I know who has issues with the social issue, so I don't see why it needs "fixing"
<sladen> LucidFox: well, it's clearly upsetting you (which makes it worth fixing), but it's probably an indication that there are other people as well who might be upset.  (And here in Ubuntu we (you and I) both don't like having upset people)
<sladen> LucidFox: so the first issue is to make you individually happy, and then to make lots more people happy
<LucidFox> Okay, filed: bug #610934
<ubottu> Bug 610934 on http://launchpad.net/bugs/610934 is private
<sladen> LucidFox: awesome, if you click in the top-right then you can make it public
<LucidFox> Done
<sladen> LucidFox: actually, while we're at it, lets see if you can get the bug reports made public by default for the font issue and open things up
<LucidFox> And the fact that it upsets me means nothing other than the fact that I'm a silly immature drama queen :p
<sladen> LucidFox: in Ubuntu everyone is created equal (except Mark), so you're bug is as important as anyone else's
<sladen> LucidFox: lets see what we can do try and sort it, both for yourself, and everyone else in the long run
<sladen> s/you're/your/
<SpamapS> pitti: sorry I pinged you and then disappeared. Are you still around?
<pitti> SpamapS: on the phone, but yes
<SpamapS> pitti: I have just a simple question really. I've been working with jiboumans  on adding a page per-user to the WI tracker, so each user gets their own burndown and list of work items. However, that was REALLY slow when I tried it the first time...
<SpamapS> pitti: I added a few indexes, and it started to go *really* fast... but I haven't tested collection with the indexes. I just wanted to make sure you aren't opposed to adding a few indexes.
<achiang> does anyone know if there is an ubuntu stack exchange site yet? or is it still in the area51 thingy...
<SpamapS> achiang: http://ubuntumathiaz.wordpress.com/2010/07/08/vote-for-the-ubuntu-stack-exchange/
<SpamapS> achiang: vote for it so it moves off area51 ;)
<achiang> SpamapS: ah, thanks.
<SpamapS> actually..
<SpamapS> "This proposal is
<SpamapS> 100%
<SpamapS> complete. Committed users will be invited to the private beta soon."
<SpamapS> so go ahead and commit now, you should get an invite to the beta. ;)
<achiang> ah!
<pitti> SpamapS: well, the slow thing is the chart generation
<pitti> SpamapS: I won't generate 300 charts every day, we need an on-demand solution for that
<pitti> SpamapS: I don't mind adding DB indexes if it helps, of course
<SpamapS> pitti: I got it to generate a chart for ever user+milestone plus the usual teams/milestones in < 20 minutes on my macbook
<SpamapS> pitti: the usual generation stuff runs in < 3 minutes
<pitti> and without indexes?
<SpamapS> 90 minutes for all the users, 20 minutes for the usual stuff.
<pitti> SpamapS: so as I said, if it improves performance, then I'm all for it
<pitti> wow
<SpamapS> the chart generation stuff scans the work_items table because there's no index on status
<SpamapS> It would actually be totally doable on-demand..
<jiboumans> pitti, doens't this run on people.c.c?
<SpamapS> but other than cron, do we have any way to run things on demand?
<pitti> SpamapS: you need to add the CREATE INDEX when creating a db, as well as when upgrading a DB (and bump the format number); the code already handles that for a few other cases
<pitti> jiboumans: yes, it does
<jiboumans> pitti: good, idle cpus then :)
<jiboumans> pitti: i pointed spamaps at the right spots for that fwiw
<SpamapS> pitti: Right so, essentially I'd be speeding things up by a about 4x, and then slowing them down again by about 4x by generating everybody's page/graph. ;)
<jiboumans> i believe spamaps is offering a package deal ;)
<SpamapS> Thats without filtering any users out though... MANY of them are basically empty
<pitti> would it perhaps be enough to just generate the reports, not the charts?
<SpamapS> pitti: the charts are the hotness though. :)
<SpamapS> pitti: and again, the chart and report generation are about the same level of impact once indexes are added
 * pitti already sees a wave of220 "please fix my trend line" requests per day
<pitti> s/of220/of 20/
<SpamapS> yeah I was thinking about that too.. :-/
<jiboumans> pitti: clearly that's solved by giving spamaps commit acccess ;)
<pitti> hehe
 * SpamapS glares at jib
<jiboumans> i'm not a native speaker, but i believe 'glare' means 'thanks', right?
<SpamapS> jiboumans: that may have worked in Poland.....
<jiboumans> pitti: if you're concerned about the impact, i'm happy to enable it for the server team to start with
<pitti> oh, let's try it
<jiboumans> we think it'll really help wiht our productivity. if anyone else can benefit from it, that's great
<SpamapS> pitti: one thing I was thinking with the trend line was to tie it to the first DONE item in a chart, rather than the first day of the cycle... because yeah, it definitely looks wrong for most users.
<pitti> if the indexes are the biggest slowdown, then it sounds like a fair trade
<pitti> SpamapS: on the charts/teams I looked at so far we very often had DONE items before the cycle even starts
<SpamapS> I wouldn't mind adding a config item.. "detailed teams = x, y, z" and only generate user reports for those teams.
 * pitti has to leave to Taekwondo now, good night!
<SpamapS> pitti: have fun, will submit a merge proposal today and we can discuss tomorrow. :)
<mathiaz> cr3: hey!
<mathiaz> cr3: what's the status of https://code.launchpad.net/~cr3/ubuntu/lucid/checkbox/0.9.2/+merge/28341?
<SpamapS> wom 1-
<SpamapS> blaahahahfrrgh
 * SpamapS blames the non-existent cat
<cr3> mathiaz: I've had to spend my time on an important certification project and I've had no personal time to take care of it wearing my community hat :(
<Fenzik> Hi All
<mathiaz> cr3: ok - could you cancel the merge proposal then?
<mathiaz> cr3: ie delete the merge proposal? Thanks
<mathiaz> SpamapS: what's the state on https://code.launchpad.net/~clint-fewbar/ubuntu/maverick/cloud-init/glusterfs-mount-example/+merge/29490?
<Fenzik> I'm new here, wish to contribute
<Fenzik> Can someone provide some assistance to kick start
<cr3> mathiaz: I'd really like to have the merge proposal approved one day though, it's just a question of updating the bugs accordingly
<mathiaz> cr3: hm - ok
<cr3> mathiaz: I'm not particularly pleased with the situation myself :(
<mathiaz> cr3: I'll probably keep poking at you on a weekly basis as long as it shows up on https://code.launchpad.net/~mathiaz/+activereviews
<cr3> mathiaz: ADD - Annoyance Driven Development, that actually works well for me
<tjaalton> Riddell: not a quick answer, but aiui 1.9 is going in soon. RAOF knows the exact time
<judgen> Is this the place to ask for a update for a package?
<judgen> There is a several years older version on the repos than the current version of AmiWM, and i was wondering if this tiny wm could be updated in the repos?
<judgen> the lucid repos that is, i do not know if the current version is in maverick
<micahg> judgen: we sync from debian and are up to date w/debian, it would probably be better to request an update in Debian and then request a sync to Ubuntu
<micahg> judgen: that package has no Ubuntu changes
<judgen> oh, ok..
<judgen> thanks.
<micahg> judgen: you can use reportbug -B debian amiwm to request the update
<SpamapS> mathiaz: Scott merged that one manually I think
<mathiaz> SpamapS: I don't think so - http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/files/head%3A/doc/examples/
<mathiaz> SpamapS: and https://code.launchpad.net/~clint-fewbar/cloud-init/glusterfs-mount-example/+merge/29515
<mathiaz> SpamapS: I don't see any file related to glusterfs in cloud-init trunk branch
<SpamapS> mathiaz: :(
<mathiaz> SpamapS: as there is another merge proposal for the upstream project, I'm going to delete https://code.launchpad.net/~clint-fewbar/ubuntu/maverick/cloud-init/glusterfs-mount-example/+merge/29490
<SpamapS> yeah thats probably appropriate
<SpamapS> mathiaz: as far as libdbi, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=565562
<ubottu> Debian bug 565562 in libdbi "libdbi: new upstream version available" [Wishlist,Open]
<mathiaz> SpamapS: hm - not sure you've attached the correct patch
<mathiaz> SpamapS: it seems that the attachement to the bug is way to big
<SpamapS> mathiaz: looks like it may have the binaries or something
<mathiaz> SpamapS: yeah - I'd suggest to file a new bug
<SpamapS> thats what I get for using 'submittodebian' and blindly trusting it. ;)
<mathiaz> SpamapS: to fix the specific issue
<mathiaz> SpamapS: AFAICT the docbook change is not necessary
<mathiaz> SpamapS: so that leave the debian/rules change
<SpamapS> mathiaz: it fails building on my pbuilder w/o it
<mathiaz> SpamapS: hm - do you have the error message somewhere?
<mathiaz> SpamapS: it might be an issue with your pbuilder setup
<SpamapS> mathiaz: It was a missing template... otherws with that error solved it by installing docbook explicitly
<SpamapS> mathiaz: while we're chatting about this, when is the last time manual syncs from debian can be requested?
<mathiaz> SpamapS: this is the sbuild log: http://people.canonical.com/~mathiaz/libdbi_0.8.3-0ubuntu1-amd64-20100728-1630
<mathiaz> SpamapS: docbook is automatically pulled in
<mathiaz> SpamapS: till the very end
<mathiaz> SpamapS: once we're passed FeatureFreeze a FeatureFreezeException will be required
<mathiaz> SpamapS: currently DebianImportFreeze is in effect which means that packages are no longer *automatically* synced
<mathiaz> SpamapS: instead a manual sync needs to be filled
<mathiaz> SpamapS: once FeatureFreeze is in effect, the Sync request will require a FeatureFreezeException as well
<SpamapS> Ugh.. why did config.guess and config.sub get deleted?! :-/
<SpamapS> mathiaz: ok so new packages for ceph would be a bad reason for feature freeze exception, but updated libdbi to make main package rrdtool work is a good reason for an exception... right?
<mathiaz> SpamapS: ceph: yes-- - given that it's part of a blueprint getting a FeatureFreeze Exception is possible
<mathiaz> SpamapS: especially if the release team is aware of it early enough (ie before FeatureFreeze)
<mathiaz> SpamapS: libdbi: to fix an FTBS it would be possible
<mathiaz> SpamapS: however a new upstream version would require a FeatureFreeze Exception anyway
<mathiaz> SpamapS: again the FeatureFreeze Exception could be granted based on the fact that it fixes a FTBS
<SpamapS> it builds
<mathiaz> SpamapS: oh right - it's about moving it to main
<mathiaz> SpamapS: ?
<SpamapS> but rrdtool's dbi support crashes using 0.8.2
<mathiaz> SpamapS: is the rest of rrdtool working correctly?
<SpamapS> something I'm realizing more and more should be reported as a bug
<SpamapS> Yeah the rest works fine
<mathiaz> SpamapS: Given that we're getting closer to FF I wouldn't wait for Debian
<SpamapS> I think libdbi can move to main as 0.8.2 .. but it would be better to move it as 0.8.3
<mathiaz> SpamapS: I'd just upload everything relevant to Ubuntu
<mathiaz> SpamapS: and file relevant bugs in Debian
<mathiaz> SpamapS: with the hope that things will be picked up by the time we open the next release cycle
<mathiaz> SpamapS: and we can sync from Debian again
<SpamapS> ceph is going in this week, but the debian dev that is uploading it isn't confident that it will pass the new queue because of debconf
<mathiaz> SpamapS: we're not in FeatureFreeze yet - so we can still update to new upstream version
<mathiaz> SpamapS: I need to jet out for a few - I'll be back
<SpamapS> mathiaz: thanks for the reviews and such.. ttyl
<corecode> hey
<corecode> what's the best practise to maintain local modifcations to packages?
<mathiaz> SpamapS: for ceph I would suggest to use the  PartnerUploadDeadline
<mathiaz> SpamapS: which is tomorrow
<SpamapS> corecode: what do you mean by "local modifications to packages" ?
<corecode> just using apt-get source will give me a complete new set
<mathiaz> SpamapS: so if ceph doesn't get through NEW by  PartnerUploadDeadline, I'd upload to Ubuntu
<mathiaz> SpamapS: so that it gets in time for FeatureFreeze
<corecode> SpamapS: i have modified an alsa driver to support my soundcard
<corecode> SpamapS: i'm using the backports-modules-alsa package for that
<mathiaz> SpamapS: for libdbi updating to the new upstream release should be done before FF
<SpamapS> mathiaz: fairly certain ceph will not make it through NEW by tomorrow.
<mathiaz> corecode: I'd look at PPA
<corecode> but now with the 2.6.32-24 kernel i need to pull my changes into the new sources
<SpamapS> mathiaz: it may not even be uploaded by tomorrow.
<corecode> mathiaz: the problem is less the hosting or building
<mathiaz> corecode: so what's the issue you're running into?
<corecode> mathiaz: but a way to merge my local changes with the changes coming from ubuntu
<mathiaz> SpamapS: ah ok - so I'd upload ceph to ubuntu (ie seek sponsorship)
<mathiaz> corecode: I'd suggest to maintain a bzr branch
<mathiaz> corecode: ie bzr branch lp:ubuntu/disto-release/backports-modules-alsa
<mathiaz> corecode: and put your changes in your bzr branch
<corecode> ah so every package has its own bzr repo?
<mathiaz> corecode: yes
<corecode> how do i find this repo?
<mathiaz> corecode: https://code.launchpad.net/ubuntu/+source/NAME-OF-THE-SOURCE-PACKAGE
<SpamapS> mathiaz: http://ceph.newdream.net/testing/0.21/ceph_0.21-1.dsc
<SpamapS> mathiaz: its a native package
<mathiaz> SpamapS: is there a PPA wich already has this package available for maverick?
<SpamapS> mathiaz: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=506040
<ubottu> Debian bug 506040 in wnpp "ITP: ceph -- a distributed filesystem" [Wishlist,Open]
<SpamapS> mathiaz: Hm I suppose that warrants actually creating a PPA just for it
<mathiaz> SpamapS: yeah - the goal is to make sure that it builds correctly on Ubuntu maverick
<mathiaz> SpamapS: the version number of the package should also be changed - 0.21-0ubuntu1
<mathiaz> SpamapS: if the package builds in the PPA and everything is correct we should be able to just copy it to the main ubuntu archive
<corecode> mathiaz: thanks!
<mathiaz> SpamapS: could you mark the status of this branch as abandoned? https://code.launchpad.net/~clint-fewbar/ubuntu/maverick/cloud-init/glusterfs-mount-example
<SpamapS> mathiaz: done
<SpamapS> mathiaz: I've uploaded the ceph package here https://launchpad.net/~clint-fewbar/+archive/ceph (waiting for acceptance email) ...
<mathiaz> SpamapS: cool - I'll look at it
<SpamapS> mathiaz: I'll also submit a patch to build lintian clean back to Sage .. would be cool if we can upload his package untouched tough
#ubuntu-devel 2010-07-29
<allquixotic> Hi, I am trying to add a patch to the quilt stack in lp:~ubuntu-desktop/rhythmbox/ubuntu. I used `quilt import' to pull the patch in. but lintian gives me this error: "E: rhythmbox source: quilt-series-references-non-existent-patch 01_vala_vapigen.patch" The problem is that exact file *does* exist in the patches dir, and it's in the right place in the series file. What gives?
<slangasek> allquixotic: did you 'bzr add' the patch file?
<allquixotic> slangasek: No :) That's all I had to do?! OK. Let me try that.
<slangasek> allquixotic: without 'bzr add', the new patch file isn't part of the bzr branch and won't be picked up by bzr bd
<allquixotic> slangasek: Ah, right. And I was running bzr-buildpackage which == bzr bd. Many thanks!
<slangasek> sure :)
<RAOF> What sort of useless filesystem debugging tool segfaults when fed a broken filesystem?  GAH!
<corecode> is there a special tool to write to debian/changelog and commit a bzr revision at the same time?
<TheMuso> corecode: debcommit
<TheMuso> corecode: sorry, you have to write to debian/changelog first with debcommit
<TheMuso> slightly misread your question.
<corecode> ok
<corecode> thanks
<slangasek> so, 'dch && debcommit' :)
<slangasek> ttx: commented the bug
<smoser> anyone able to tell me why there would be no maverick build of libjibx-java ?
<smoser> https://launchpad.net/ubuntu/+source/libjibx-java
<smoser> i'm guessing ftbfs ?
<ajmitch> smoser: it was removed, see https://edge.launchpad.net/ubuntu/+source/libjibx-java/+publishinghistory
<smoser> hm...
<smoser> so it *does* have reverse depends in ubuntu
<slangasek> smoser: check with Riddell, I guess?  Generally we shouldn't auto-process removals from Debian for packages that have reverse dependencies in the archive still
<slangasek> smoser: would bringing the new libjibx1.{1,2}-java packages into maverick address the issue?
<smoser> i dont know the answer to that.
<mathiaz> kees: hi!
<mathiaz> kees: could you do a search on the archive to see if there are any package using dbi_conn_error_flag?
<mathiaz> kees: this function has been changed in the new upstream version of libdbi
<mathiaz> kees: nevermind - I've been able to get what I was looking for
<allquixotic> When I grab a source package via `apt-get source' and the sources dir contains debian/patches/nn_*.patch and debian/patches/series, how do I apply those patches? quilt?
<smoser> kees, around ?
<smoser> euca_rootwrap question.
<kees> smoser: email me; i'mhigh latency this week (at blackhat and defcon conferences)
<smoser> i found the answer.
<smoser> whether ror not you'd like it to be true, a program invoked via euca_rootwrap can fork/exec anything it wants.
<smoser> i had thought that your security measures might have stopped that.
<kees> smoser: ew, it's not supposed to be able to do that
<smoser> hm..
<smoser> maybe i did something wrong
<kees> maybe you're using the upstream version instead of the replacement i wrote?
<smoser> i dont think so
<smoser> from our packages:
<smoser> kees, http://paste.ubuntu.com/470524/
<smoser> maybe i wasn't explaining myself well.
<pitti> Good morning
<ion> ing
<andreserl> Hi all. Have a quick question. Should we Build-Depend in a virtual package, or in a real package?
<pitti> zul: can you please aply v7x' debdiffs in bug 611101  and bug 611102 and then actually test the package?
<ubottu> Launchpad bug 611101 in mysql-dfsg-5.1 (Ubuntu Lucid) "upstart config does not sleep between pings" [High,Triaged] https://launchpad.net/bugs/611101
<ubottu> Launchpad bug 611102 in mysql-dfsg-5.1 (Ubuntu Lucid) "mysqld does not start due to typo in upstart config" [High,Triaged] https://launchpad.net/bugs/611102
<kees> smoser: uhm... you added /bin/sh to the conf...
<smoser> yes.
<smoser> and then invoked /bin/sh (a command in the conf)
<kees> so, of course it can run anything.
<smoser> and it forked something else
<smoser> thats what i was asking.
<smoser> if you were intending to stop forks of other programs.
<kees> no, and that would probably break other stuff.
<smoser> right
<smoser> ok.
<kees> the euca white list was built to just try to not make it blindingly simple to gain root privs from the euca user
<kees> it's almost certainly possible, but it was REALLY possible with the old one, which just did exec(argv[1]) etc...
<kees> the idea was to try to help euca start to build up a whitelist and helpers to validate arguments, etc.
<kees> but since it's still not upstream, I don't think there are any plans to improve it.
<dholbach> good morning
<diwic> dholbach, good morning
<dholbach> hey diwic
<mdz> mvo, unfortunately I can no longer test that nvidia progress bar issue. the nvidia card in question is dead (its fan stopped)
<mvo> mdz: thanks, I can reliable reproduce it now on both a ati and a nvidia card, looks like a issue with cairo 1.9.x hitting slow rending path(es) on these cards
<mvo> mdz: its now in bug #595845 (including small demp and timing info)
<ubottu> Launchpad bug 595845 in cairo (Ubuntu) "libcairo2 1.9.10 makes Ubuntu 10.10 unusably slow" [Medium,Triaged] https://launchpad.net/bugs/595845
<RAOF> I'm not entirely sure where that slowness is coming from - I was going to look at oprofile output, but on my nouveau system the slowness *isn't* accompanied by CPU usage, so oprofile wasn't catching any hot paths.
<mvo> RAOF: today my nouveau system does not start (complains that drm can not set DRM device bus id, otherwise I would be able to help
<RAOF> Gargh.
<RAOF> Yeah, that's a race condition.
<RAOF> Delete the ureadahead pack file and your boot should slow down enough for X to start
<RAOF> Alternatively, add drm to your initramfs by setting FRAMEBUFFER=y in one of the conf files.
<RAOF> mvo: bug #606244 is what you want to follow for that.
<ubottu> Launchpad bug 606244 in linux (Ubuntu) "X doesn't find a screen and is not starting due a race condition" [High,Confirmed] https://launchpad.net/bugs/606244
<mvo> RAOF: thanks!
<pitti> 2010-07-29 08:46:34 INFO    Comment: NBS
<pitti> 2010-07-29 08:46:34 INFO    1196 packages successfully removed.
<pitti> wow
<pitti> seems nobody did that for a while
 * pitti removes 543 more old kernel packages
<apw> pitti, ! 543 ! ... that really hasn't been done for a while
<chrisccoulson> pitti - how frozen is lucid for SRU's?
<chrisccoulson> i have an ubufox SRU with a couple of fixes in (one of them disables the "Report a problem" menu item in firefox)
<pitti> chrisccoulson: once mysql lands (hopefully today, will coordinate with zul), then that's "it"
<Riddell> TheMuso: ping?
<TheMuso> Riddell: pong
<Riddell> TheMuso: I e-mailed, you should be asleep :)
<TheMuso> Riddell: heh, its about 11:0PM in the evening, will take a quick peak before heading to bed. :)
<TheMuso> Riddell: speech-dispatcher. I have resigned from the fork, and don't intend to package opentts for maverick.
<TheMuso> Now I am off to bed.
<ikonia> dholbach: are you there ?
<dholbach> ikonia: yes
<ikonia> dholbach: can I nudge you a pm please ?
<dholbach> you can try :)
<mathiaz> superm1: hi - I'm currently investigating bug 598030
<ubottu> Launchpad bug 598030 in Ubuntu Server papercuts "firmware-tools should be split between GUI and non-GUI tools" [Medium,Triaged] https://launchpad.net/bugs/598030
<mathiaz> superm1: is there anything in the code that would make things harder?
<mathiaz> superm1: is inventory_firmware_gui the only bit that call anything gui related?
<quadrispro> ehy mvo, nice to see you aroun! I've mail'd you but now I have to leave, see you later
<superm1> mathiaz, you are best speaking with michael brown about that stuff, but i dont see him on right now
<superm1> mebrown is his handle
<mathiaz> superm1: great - thanks
<superm1> mathiaz, here's mebrown
<superm1> you can restate your question to him
<mathiaz> mebrown: hi - I'm currently investigating bug 598030
<ubottu> Launchpad bug 598030 in Ubuntu Server papercuts "firmware-tools should be split between GUI and non-GUI tools" [Medium,Triaged] https://launchpad.net/bugs/598030
<mathiaz> mebrown: is there anything in the code that would make things harder?
<mebrown> not really.
<mathiaz> mebrown: is inventory_firmware_gui the only bit that call anything gui related?
<mebrown> they are separate bins
<mebrown> I think so.
<mathiaz> mebrown: IIUC inventory_firmware_gui is just a GUI frontend that call the cli scripts?
<mebrown> no
<mebrown> separate implementation that uses the backend python libs
<mebrown> shares same libs as the cli, but does not use
<mathiaz> mebrown: gotcha
 * mathiaz nods
<mathiaz> mebrown: do you have an opinion on the package names?
<mathiaz> mebrown: ie should the gui be split to firmware-tools-gui?
<mathiaz> mebrown: that would require desktop users to install firmware-tools-gui instead of firware-tools
<mathiaz> mebrown: I wonder what's the impact on existing documentation
<mebrown> mathiaz, no real strong opinions.
<mathiaz> mebrown: or users expects to have a gui when installing firmware-tools?
<mebrown> mathiaz, would like it if all the pkgs could use the same convention, though. (rpm/deb/etc)
<mathiaz> mebrown: is there already a split for rpm packages?
<mebrown> no.
<mebrown> would probably need to split into something like: firmware-tools-libs, firmware-tools-cli, firmware-tools-gui
<mebrown> and have firmware-tools be a meta-pkg for backwards compat
<mathiaz> mebrown: ok - s/-libs/-common/
<mebrown> I dont really have a clear idea if most people use the cli or gui. I suspect that most people use cli, but no hard data
<mebrown> -common works for me
<mathiaz> mebrown: so firmware-tools-common, firmware-tools-cli, firmware-tools-gui and firware-tools depending on firware-tools-gui
<mathiaz> mebrown: as a transitional package
<mebrown> sounds fine to me. probably want f-t to depend on both f-t-g and f-t-c
<mathiaz> mebrown: great - thanks for your input
<tumbleweed> if anyone is doing anything about firmware-tools, dell probably needs a prod. It looks like their firmware repository is in poor shape
<mebrown> tumbleweed, yes, I know.
<mebrown> its mine and I'm catching up on all my projects now
<mebrown> spent a year in limbo working on... just a sec, let me get the link.
<tumbleweed> a cool. I was the last person to touch firmware-tools here, and found it to be rather unhappy
<mebrown> http://en.community.dell.com/dell-blogs/enterprise/b/tech-center/archive/2010/07/27/dell-openmanage-6-3-for-ubuntu.aspx
<mebrown> got a funny message from the blog team this morning: Why does your blog post have two orders of magnitude more views than any of the other stories?
<ScottK> pitti: Would you please rescore xine-lib.  It just affects powerpc and ia64 and should save us some retries on those archs to get it built now.
<pitti> ScottK: sure, doing
<ScottK> pitti: Thanks.
<zul> ptti: acked
<zul> pitti: done
<LucidFox> seb128, I have talked to ritz about releasing xchat-gnome 0.26.2 - he says he plans to finalize and commit by Wednesday.
<LucidFox> So hopefully we'll be able to get it in before FF
<seb128> hey LucidFox
<seb128> ok
<LucidFox> Is f-spot going to be demoted to universe now that shotwell is in main
<LucidFox> ?
<chrisccoulson> LucidFox, no
<jono> are others finding that evolution is crashing a lot?
<ebroder> I haven't been using it too extensively, but not really
<jono> it is crashing every few messages for me
<ebroder> Yeah, definitely not that bad
<pitti> zul: can you please reupload with referring the two regression bugs in the changelog, and include all three -proposed uploads in -v?
<pitti> zul: please check the _source.changes, it should have three records
<zul> pitti: k
<ScottK> pitti: Would you please rescore libmpc - need that one apparently before I need xine-lib.
<pitti> ScottK: done
<ScottK> pitti: Thanks.
<zul> pitti: done
<pitti> zul: still don't see it -- was the upload successful? (old ".upload already exists" trap?)
<zul> gah....shakes fist
<bdrung> how can i determine, who of the archive-admin team rejected an upload?
<pitti> bdrung: nobody can
<pitti> bdrung: the convention is that the archive admin sends the reason to the uploader and CC:s ubunt-archive@
<pitti> or does a bug followup in the case of a rejected SRU
<Laney> bdrung: are you talking about projectm?
<bdrung> Laney: yes
<Laney> That was ScottK: the maintainer spoke up in #-motu about this version being unsuitable
<Laney> see scrollback there for the discussion
<ScottK> bdrung: You were highlighted at the end of the discussion.
<pitti> zul: was an identical double-upload, so I reject one; don't get scared
<zul> pitti: hehe thanks
<pitti> zul: oh, but can you please reupload with the to new bug refs in the latest changelog?
<zul> pitti: sure
<pitti> zul: 611101  and 611102
<bdrung> ok, thanks
<zul> pitti: uploaded
<pitti> zul: thanks, looks good; can you upload to maverick, too?
<zul> yeps as soon as im done with what im working on
<pitti> thank you
<pitti> so, that (hopefully) closes the 10.04.1 SRUs
<jono> folks, evolution keeps crashing for me when I want to reply to an email, it seems to do it every few messages - I run it in a terminal but it just says it is a segfault - how can I get better debug info?
<jono> (in Maverick)
<BlackZ> jono: I think you could try to install evolution-dbg
<jono> thanks BlackZ - what is that?
<BlackZ> jono: that package contains debugging symbols for evolution, http://live.gnome.org/GettingTraces/Details
<jono> thanks BlackZ
<Chipzz> BlackZ: eh? why are you redirecting him to a gnome.org page when ubuntu has apport??
<BlackZ> Chipzz: if he wants to do a bug report against the ubuntu package then he can use apport, but it's better to report it to gnome too
<Chipzz> BlackZ: yes, but the ubuntu bug will get forwarded to gnome bugzilla anyway
<BlackZ> Chipzz: FYI someone will have to
<Chipzz> and someone will
<Chipzz> but
<Chipzz> evolution-dbg only contains debugging symbols for evolution
<Chipzz> what if the problem is in an underlying library?
<Chipzz> I don't know the official pov from ubuntu, but my gut feeling tells me it's better to use apport/ddebs
<pitti> the retracers install ddebs for every depending lib
<pitti> once the retracer kicked in and produced a good stack trace, it's ready for upstream forwarding, yes
<pitti> before that it's just a nuisance for upstream
<BlackZ> Chipzz: evolution-dbg will collect the useful debug *for* evolution and you have to see if with that the stack trace provides enough informations. However yes, he can use apport
<micahg> BlackZ: not necessarily, depends on what other components are involved in the error
<BlackZ> jono: could you please check in malone/gnome if there's a bug against that?
<Chipzz> pitti: what's the recommended approach for filing bug reports? apport or the approach BlackZ suggested?
<Chipzz> (as an aside, I am more than a little surprised jono of all ppl did not know about apport.. :P)
<Chipzz> pitti: also, since jono is running maverick (a development release), shouldn't apport have been enabled by default?
<BlackZ> micahg: exactly
<pitti> Chipzz: the easiest is to report the crash through apport, wait until the retracer got to it, and then poke people to forward it upstream and/or fix it
<pitti> might be something simple
<pitti> Chipzz: yes, maverick has apport enabled
<jono> Chipzz, I know about apport, but it is not triggering when it crashes
<pitti> jono: do you get apport on: sh -c 'kill -SEGV $$'
<pitti> ?
<SpamapS> mathiaz: agreed better here...
<SpamapS> mathiaz: so .. collectd plugins.. what would you say to splitting it into its own source package, much like php-imap does?
<SpamapS> mathiaz: at issue is the list of MIR-needing libs .. if we can just leave the plugins that need those libs out of main .. *win*
<mathiaz> SpamapS: both packages would have the same .orig.tar.gz though?
<SpamapS> mathiaz: otherwise we need to pile even more stuff onto the already massive main seed.. libesmtp, libconfuse, libganglia ...
<SpamapS> mathiaz: right
<mathiaz> SpamapS: the other solution is to disable the unwanted plugins during build time
<SpamapS> mathiaz: that would be a disaster
<SpamapS> mathiaz: "We support collectd now, but we had to turn off half of the cool features."
<SpamapS> The reason we want it in main is for uec...
<SpamapS> so we should be able to just bring what we want for uec, into main, and leave the rest in universe.
<mathiaz> SpamapS: right - as a monitoring agent for UEC components
<SpamapS> one issue with that is that the plugins can only be in "suggests" ..
<mathiaz> SpamapS: rather than a monitoring agent for instances running into the cloud
<SpamapS> so users will install the collectd package, and then wonder why it doesn't have all the plugins they want.
<SpamapS> But one way to get around that..
<SpamapS> is to have collectd-basic in main .. used by uec and whatever else needs it, but then the actual 'collectd' package is in universe.
<mathiaz> SpamapS: right - having a collectd-core in main
<Chipzz> jono: shouldn't it? maybe you have it disabled?
<SpamapS> core, that sounds much better. :)
<mathiaz> SpamapS: (rather than -basic)
<mathiaz> SpamapS: so IIRC there was a similar issue with xen
<mathiaz> SpamapS: where xen was in main but only to have the -dev package
<mathiaz> SpamapS: in main
<mathiaz> SpamapS: yes - xen-3.3 is in main
<mathiaz> SpamapS: http://packages.ubuntu.com/source/lucid/xen-3.3
<mathiaz> SpamapS: however the hypervisor and the tools are in universe
<jono> Chipzz, it should, I am not sure why it isn't - how do I check
<mathiaz> SpamapS: and only libxen3-dev is in main
<mathiaz> SpamapS: because of libvirt
<BlackZ> agreed with pitti: you could report it with apport against the ubuntu package and then report it to upstream (gnome, in this case). But if you just want to get the debug symbols, you can use the debug symbols for the respective packages (e.g. evolution-dbg for evolution)
<mathiaz> SpamapS: so that's another option - it may make the MIR processing easier
<SpamapS> mathiaz: my main concern is actually just the explosion of responsibility we're accepting in main
<micahg> BlackZ: the problem is that since we use system libs for most packages, you'll get a partial trace using the package-dbg packages
<Chipzz> jono: if you have it disabled? I think some file in /etc/default (if I'm not mistaken)
<jono> Chipzz, I have it now, it was removed from my panel
<jono> thanks
<mathiaz> SpamapS: so the collectd dependencies that would need to be promoted to main are: 'collectd', 'libdbi', 'libesmtp', 'liboping', 'memcached', 'libmemcached', 'yajl'
<mathiaz> SpamapS: memcache is already done
<SpamapS> mathiaz: memcached+libmemcached are already approved to main
<mathiaz> SpamapS: libdbi on its way because of rrdtool?
<SpamapS> mathiaz: and libdbi should make it due to rrdtool's dependence (and its relative stability)
<SpamapS> mathiaz: libganglia1 is also needed
<pitti> good night everyone
<mathiaz> SpamapS: hm - right - it seems that my script fails
<BlackZ> micahg: that's true too but not always, first we should try to collect the debug information and see if they're partial, agreed?
<mathiaz> SpamapS: because rrd-dev is currently unstalable in maverick
 * mathiaz tries on lucid
<SpamapS> mathiaz: librrd-dev > 1.4 is , I think, the build-dep for the latest collectd
<SpamapS>  librrd-dev (>= 1.4~),
<mathiaz> SpamapS: so on lucid the list is: 'collectd', 'confuse', 'libdbi', 'libesmtp', 'ganglia', 'liboping', 'memcached', 'libmemcached', 'yajl'
<SpamapS> mathiaz: 1.4 isn't uploaded, though I did do the merge. I think its awaiting merge-proposal-review by ubuntu-server. ;)
<SpamapS> https://code.launchpad.net/~clint-fewbar/ubuntu/maverick/rrdtool/merge-1.4.3-1/+merge/30675
<mathiaz> SpamapS: it seems that libesmtp liboping could be disabled
<SpamapS> mathiaz: liboping I believe is the baseline ping monitor. Not needed for uec, but a huge need by your average collectd user
<mathiaz> SpamapS: the library seems quite simple - so could be easy to MIR
<mathiaz> SpamapS: I think the main one would be ganglia
<micahg> BlackZ: requires debugging twice, vs 1 apport crash
<BlackZ> micahg: yeah, so as pitti said using apport is the easiest way
<micahg> BlackZ: even if people want privacy and won't upload a coredump, they can retrace the apport crash (which can also install all the appropriate -dbgsym packages) locally, it's really an awesome tool
<SpamapS> mathiaz: agreed, ganglia's only non main dependency is libconfuse
<mathiaz> SpamapS: ok - and ganglia itself would be a huge effort to MIR
<mathiaz> SpamapS: I'm not sure we want that in main
<BlackZ> micahg: yes
<SpamapS> mathiaz: ganglia could just have libganglia1 in main
<mathiaz> SpamapS: yeah - that would be an option - similarly to what we do for xen
<SpamapS> mathiaz: but I'd rather do even more to reduce the burden on main by moving the bulk of the optional plugins to a non-main package
<mathiaz> SpamapS: well - we'd increase our burden by splitting source packages
<mathiaz> SpamapS: as we'd have to update collectd-plugin whenever collectd is updated
<SpamapS> mathiaz: right, I think we have more merge-bandwidth than we do security-bandwidth. ;)
<mathiaz> SpamapS: hm - well - the split proposal is much more unusual
<mathiaz> SpamapS: I don't know of any package where we do that
<mathiaz> SpamapS: I'd send an email to ubuntu-devel to ask for feedback on the two options
<mathiaz> SpamapS: I'd lean towards including ganglia into main personally
<SpamapS> mathiaz: meh.. munin, collectd, and ganglia, all in main.. ;)
<mathiaz> SpamapS: right
<mathiaz> SpamapS: we'll sort things out during the next UDS
<mathiaz> SpamapS: to get everything in order for the next LTS
<SpamapS> mathiaz: I think we should have a *very* clear picture of what the next LTS looks like, server wise, by the end of UDS-O
<SpamapS> mathiaz: we can't wait for P. :)
<mathiaz> SpamapS: we should discuss that at UDS-N then
<SpamapS> Yeah I have my UDS-N ideas brewing now. :)
<mathiaz> SpamapS: awesome - don't forget to *capture* them
<SpamapS> mathiaz: rememberthemilk.com is turning out to be perfect for that
<mathiaz> SpamapS: http://brainstorm.ubuntu.com/ as well :)
<SpamapS> mathiaz: a difficult step for me is clarify.. I'm such a pack-rat.. I never want to delete anything. ;)
<SpamapS> can somebody who moderates ubuntu-devel please take a look at the posting I just did (clint@ubuntu.com "MIR for collectd requires some guidance") and accept/reject it. The last message I sent to ubuntu-devel sat unmoderated for 3 weeks. ;)
<rsavoye> is there a bzr branch on launchpad for OpenJDK ?
<rsavoye> that is the source, not just packaging files
<SpamapS> rsavoye: I don't know where the official upstream for openjdk is, but lp:ubuntu/openjdk should be the current development package w/ the source.
<rsavoye> there is nothing at that url, I tried
<rsavoye> java.net has a mercurial repository, but you have to be registered to access it
<micahg> rsavoye: apparently a default branch isn't registered for that source, can you file a bug on bugs.launchpad.net/udd ?
<rsavoye> sure, but I need it now! :-)
<micahg> it should be lp:ubuntu/openjdk-6
<rsavoye> should be... openjdk6 has the packaging files, nothing else that I can find
<micahg> seems to be stopped on bug 513215
<ubottu> Launchpad bug 513215 in Ubuntu Distributed Development "needed upstream part for version" [High,Triaged] https://launchpad.net/bugs/513215
<rsavoye> ah, I see, it mentions openjdk-6 as an affected package. Oh well...
<rsavoye> well, now there are two of us the bug effects :-)
<wgrant> barry: Hi.
<wgrant> barry: AFAICS, both system-config-printer builds have a non-None current_source_publication. That's how you're meant to get the source details.
#ubuntu-devel 2010-07-30
<rsalveti> kirkland: did you have time to look at the merge proposal? or just decided to wait until the qemu next release?
<hallyn> rsalveti: oh no!  kirkland is out today and tomorrow
<hallyn> mathiaz: can you look at a merge proposal ^ ?
<rsalveti> oh :-)
<hallyn> (AFAI am concerned i've greenlighted it)
<kirkland> rsalveti: i'll get it
<kirkland> rsalveti: haven't yet
<kirkland> rsalveti: could you send me an email about it?
<rsalveti> kirkland: sure, thanks :-)
<judgen> I have asked in #ubuntu but people does not seem to know.. but i want the text information at boot so i can see what is going wrong. nosplash in grub does not seem to do the trick. Any suggestions?
<judgen> it was easier before when i could just purge usplash
<StevenK> judgen: Rremove 'quiet' from the boot options
<judgen> StevenK, ok, i will try that. Thanks
<judgen> i also want my non graphics loaded grub selector (preferably monochrome) would you happen to know how to do that too?
<StevenK> Not off hand, no, sorry
<RAOF>  /etc/default/grub is where you want to look.
<judgen> StevenK, i found it "GRUB_TERMINAL=console" is supposed to be added...
<judgen> I really dislike how my grub.cfg is destrouyed every time the kernel is updated.
<judgen> i am thinking of making it unwritable, even by root.
<judgen> by putting grub on an sd card with hardware R/W protection
<StevenK> judgen: It's re-written, yes, but there are ways of editting it so your changes are preserved.
<judgen> StevenK, how do i set it to load the last instance as defaul ALWAYS
<judgen> =D
<judgen> and as the number of installed kernels increase, i can not use numbers as i used to in menu.lst
<StevenK> judgen: To be honest, I use the default grub config, and the latest kernel appears at the top of the list, which suits me fine
<judgen> or can i disable the automatic generation of grub.cfg and just edit it manually (like i do now, and have to redo every time i update)
<judgen> I have 4 OS'es on the system, and i would like BSD to be deafult.
<judgen> ubuntu, BeOS/Haiku and QNX is booted as secondary system.
<judgen> oh well, this will have to wait untill tomorrow, as it is 05:26 here now and i really need some sleep.
<pitti> Good morning
<nzmm_> good evening :)
<dholbach> good morning
<mvo> hey dholbach
<ttx> Hm, PPAs are slow nowadays. Published: 23 hours ago / Build estimated start in 17 hours
<dholbach> hiya mvo
<ttx> that kind of delay makes it difficult to insert in any kind of efficient workflow
<micahg> ttx: stuff uploaded today won't get built until Sunday unless they return the rest of the PPA builders
<ttx> micahg: "they" ?
<micahg> ttx: whoever took them :)
<ttx> After the laptop thief, here comes the PPA builder thief.
 * pitti NEWs linux-meta to make CDs buildable again
<micahg> pitti: when SRUing a newer version of an app that's been broken out into new packages, is it better to undo that for the SRU?
<diwic> Is there a way to automatically subscribe to all bugs you comment on in LP?
<diwic> or do I have to check that checkbox all the time?
<pitti> micahg: yes, we avoid new packages in SRUs
<micahg> pitti: k, will keep in mind, thanks
<happyaron> could somebody have a look at Bug 611224 ?
<ubottu> Launchpad bug 611224 in ibus (Ubuntu) "Please merge ibus (1.3.6-1) from Debian Squeeze" [Undecided,New] https://launchpad.net/bugs/611224
<geser> any main sponsor free for sponsoring bug #607448?
<ubottu> Launchpad bug 607448 in mutt (Ubuntu) "Drop libtokyocabinet-dev from Build-Depends as it's in universe" [Undecided,New] https://launchpad.net/bugs/607448
<mvo> geser: I can do that for you
<geser> mvo: thanks
<ogra> jdstrand, can you let ubuntu-netbook-efl-default-settings out of NEW please
<maxb> Hi, please can I have a give-back on https://edge.launchpad.net/ubuntu/+source/subversion/1.6.12dfsg-1ubuntu1/+build/1853960 - I would like to take advantage of the currently empty sparc buildqueue to test whether the failure is intermittent
<pitti> maxb: done
<maxb> thanks
<StevenK> pitti is too fast ...
<StevenK> I need a neural link to Launchpad, like pitti has ...
<pitti> StevenK: how can you not have one? you are writing the stuff now :)
 * StevenK blames lag.
<StevenK> Yes, that will do ....
<ScottK> pitti: Would you please rescore xine-lib (again) - should work this time.
<pitti> ScottK: doing
<ScottK> Thanks.
<smoser> Anyone know where netboot/ubuntu-installer/amd64/initrd.gz comes from on an ISO ?
<soren> smoser: debian-installer somewhere, I believe.
<SpamapS> any moderators for ubuntu-devel available?
<SpamapS> I sent a message yesterday, need it to be approved
<mterry> Lutin, ping about your netbook-launcher-efl patches
<SpamapS> ccheney: ping?
<ccheney> SpamapS, hi
<SpamapS> ccheney: so, I need my gearman-interface package sponsored into debian.. do you know anybody who could help me with that?
<SpamapS> http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=gearman-interface
 * ccheney takes a look
<ccheney> SpamapS, i can take a look quick and see if it looks sane and upload it if so
<ccheney> SpamapS, sorry i was out sick tue-thu this week
<SpamapS> ccheney: that would be amazingly amazing. :)
<SpamapS> ccheney: you uploading, not you being sick. You're well now I hope?
<ccheney> heh, yea much better today, they gave me antibiotics and some other things to see if it would help and it appears to have worked
 * ccheney is setting up a sid chroot and then will do the build and check it out before uploading :)
<SpamapS> ccheney: sweet.. I do see actually, that there are two changes I didn't put into that upload.. both are minor source package things (a copyright addition, and README.source) ..
<ccheney> SpamapS, email me a debdiff of the changes and i can add them before upload
<SpamapS> ScottK: note, I'm tasking ccheney with the upload for now because the group has been so slow to respond. Hopefully DPMT can take it over in the future.
<ScottK> SpamapS: Sure.
<mterry> asac, ping about new EFL stack
<SpamapS> ccheney: ok, debdiff sent
<ccheney> ok
<Lutin> mterry: pong
<mterry> Lutin, hi :)  Where can I grab the latest EFL stack to compile/test against?
<Lutin> mterry: actually, my patch was only partial, I had some time yesterday to make a complete patch. you can find it here: http://people.dunnewind.net/lutin/files/0001-Update-Netbook-launcher-efl-to-make-it-work-with-the.patch
<Lutin> mterry: then, you can just grab the packages from debian unstable, they install just fine on ubuntu
<mterry> Lutin, ah.  OK will do so
<Lutin> mterry: would you run into any unexpected into, please let me know. I compile and tested it yesterday, seemed to work fine, but I did'nt check extensively
<mterry> Lutin, k
<Lutin> s/into/issue
<mterry> Lutin, I get "ERR:elementary elm_win.c:541 elm_win_add() Cannot create window." when running n-l-e after patch and debian stack
<Lutin> mterry: is that the only error ?
<SpamapS> mathiaz: ping!
<hallyn> man, that's a ping<BANG>
<hallyn> mathiaz is probably hiding now
<SpamapS> one ping only
<bilalakhtar> !ping
<ubottu> pong
<mathiaz> SpamapS: o/
<SpamapS> mathiaz: Updated the ceph merge proposal
<mathiaz> SpamapS: cool thanks
<wcomnisky> hi! can i read the serial number of my HD using dbus-send?
<SpamapS> mathiaz: UUGGH
<SpamapS> mathiaz: it looks like the tarball we were using as "0.21" was not "0.21"
<mathiaz> SpamapS: that's anooying
<SpamapS> mathiaz: very, there are a number of source changes .. 0.21 wasn't actually official released until yesterday, which I just figured out...
<mathiaz> SpamapS: hm - ok. Just update the branch then.
<SpamapS> mathiaz: thats what I'm doing.. just trying to be careful. :)
<SpamapS> mathiaz: the cavalier attitude that the ceph project has toward licensing bothers me somewhat.. I hope it doesn't come back to bite them.
<mterry> asac, Lutin: n-l-e 0.3.2 released
<superm1> kees, by chance did you run into any problems when you upgraded to lucid with your sbuild/schroot setup?
<superm1> kees, i just jumped hardy->lucid on my build box, and for some reason every invocation of schroot is giving me "E: default: Chroot not found"
<sda> hi all
<sda> i would like help for ubuntu dev, but i don't know my level and what i can or cannot do. help
<SpamapS> sda: There are a number of wiki pages that may be helpful.. one moment..
<SpamapS> sda: for server, there's https://wiki.ubuntu.com/ServerTeam/GettingInvolved
<SpamapS> sda: https://wiki.ubuntu.com/ContributeToUbuntu   that one is good too
<SpamapS> !contribute
<ubottu> To contribute and help out with Ubuntu, see http://www.ubuntu.com/community/participate
<Lutin> mterry: neat
<facundobatista> Hello everybody!
<facundobatista> I have this project, magicicada (https://launchpad.net/magicicada) that is in Universe for Maverick
<facundobatista> Elliot Murphy did the first work to get it uploaded
<facundobatista> yesterday I released 0.1.3 of it, and I'm following Elliot's instructions that say
<facundobatista>     * Prepare the source package and ask for a sponsor.
<facundobatista> I have the source package
<facundobatista> is this a good place to ask for a sponsor?
<facundobatista> (thanks!)
<mterry> facundobatista, I'm guessing that Elliot meant file a bug with a debdiff and subscribe ubuntu-sponsor?  Let me find wiki documentation
<facundobatista> mterry, thanks!
<mterry> facundobatista, at what level of ubuntu development are you comfortable?  You say you have a source package, but what does that mean to you?  A tarball for magicicada or a new version of the ubuntu source package that uses that tarball?
<mterry> facundobatista, I believe this will help: https://wiki.ubuntu.com/PackagingGuide/Recipes/PackageUpdate
<facundobatista> mterry, I'm just learning, but I branched lp:ubuntu/magicicada , merged my own upstream new release, fixed the changelog, and prepared magicicada_0.1.3-0ubuntu1* files (.diff.gz, .dsc, _source.build, and _source.changes)
<mterry> facundobatista, ah...  You're using the fancy new bzr method.  OK.  So you have two options.  Prepare an old-school debdiff and follow the instructions here: https://wiki.ubuntu.com/SponsorshipProcess
<mterry> facundobatista, or, push your changes to lp:~USER/ubuntu/maverick/magicicada/0.1.3-update and point to that instead of uploading a debdiff (but still do the other sponsorship steps)
<mterry> facundobatista, I can review when you've filed, if you do it within the next hour or so
<facundobatista> mterry, will do, thanks
<mterry> facundobatista, ping me when filed  :)
<facundobatista> mterry, I think I did all the necessary steps, the bug is #611848
<facundobatista> mterry, please let me know if I should have done anything different (even if it's good enough like this, maybe I could do something to make you work less)
<facundobatista> mterry, thanks!
<ari-tczew> mterry: reffering to bug 461987 your patch will be useless
<ubottu> Launchpad bug 461987 in antlr3 (Ubuntu) "Enable testsuite (and fix resulting failures)" [Medium,Triaged] https://launchpad.net/bugs/461987
<mterry> facundobatista, a little tip.  if you type "bug XXXXX" like "bug 611848", ubottu will make a nice link
<ubottu> Launchpad bug 611848 in Ubuntu "Update magicicada to 0.1.3 in Maverick" [Undecided,New] https://launchpad.net/bugs/611848
<mterry> facundobatista, one thing: don't assign to the sponsors team, subscribe them
<facundobatista> mterry, oh, ok, thanks
<facundobatista> mterry, so, here ends my "request for sponsorship"? should I do something else? just let me know! thanks!
<mterry> facundobatista, yeah, I take it from here.  Normally you wouldn't need to ping anyone on IRC or anything.  subscribing ubuntu-sponsors puts it in the sponsorship queue.  If it's urgent or you know someone who wants to sponsor it, feel free to ping someone on IRC
<facundobatista> mterry, ok, thank you very much for the help!
<mterry> facundobatista, one last tip.  In your changelog, if you put the string  "LP: #XXXXXX" in your message, Launchpad will automatically mark the bug fix committed when I push it.  I did it for you this time, and it's a bit of a chicken-and-egg thing since you often do the changelog entry before you file, but it's nice to have
<highvoltage> sabdfl: nice, your blog entry got slashdotted
<ion> Nothing prevents one from editing the changelog entry when there is a bug number. :-)
<mterry> ion, yar, agreed  :)
 * micahg hand edits the debdiff sometimes before adding to LP
<ion> Why hand edit a diff?
<mterry> facundobatista, there ya go: https://launchpad.net/ubuntu/+source/magicicada/0.1.3-0ubuntu1  Thanks for helping make Ubuntu (One) rock!  :)
<micahg> ion: faster than regenerating the whole debdiff after the patch is good
<micahg> ion: just to add (LP: #XXXXXX) :)
<ion> One can regenerate it with a single command, and youâll have the changelog change nicely in the version history. :-) And one might want/need to edit the patch further anyway.
<micahg> sure
<mterry> facundobatista, oh, and one other thing I noticed.   You filed the sponsorship bug against the whole of ubuntu.  But you should have filed it against the magicicada package *in* ubuntu:   http://bugs.launchpad.net/ubuntu/+source/magicicada/+filebug
<facundobatista> mterry, thanks! taking note of all these details
<micahg> facundobatista: you can also run 'ubuntu-bug PKGNAME' to take you straight to the proper filebug page
<sabdfl> highvoltage: that will draw in the opinions, then :-)
#ubuntu-devel 2010-07-31
<kees> superm1: in lucid, mk-sbuild changed a lot (default names of schroots always have -$arch appended) but that shouldn't have broken old schroots
<kees> superm1: that said, I have been having to tweak my /etc/schroot/schroot.conf with ever new major version of schroot
<picard1421> http://pastebin.com/c5Va7nSY why is this not compiling?
<YokoZar> slangasek: Do you think we'll be able to start breaking up ia32-libs this release or is that the next phase of multiarch?
<ion> I was happy to see thereâs some progress with multiarch spec.
<picard1421> anyoe?
<maxwellian> picard1421: I got here after you asked your question, can you repeat it?  I'm very new, so there's about a one in a million chance that I could help, but we can try. :P
<picard1421> http://pastebin.com/c5Va7nSY  why is this not compiling?
<sladen> picard1421: first off, it's not a good idea to be running as root!  Please consider working as your own user, in your own home directory
<picard1421> i tried that
<picard1421> but since i did not extract it on ..
<picard1421> my drive i extracted on windows.. permission were messed up
<picard1421> i changed everything to 777 just for the pure purpose i want this to run .. i can redo it all later im wiping this install once i figure out how to compile this.. anyway..
<picard1421> and redoing it completely
<sladen> picard1421: chown -R yourusername.yourusername the-messed-up-directory
<sladen> ahhhh.  Are you trying to compile this on a FAT partition?
<picard1421> yea
<sladen> okay.
<sladen> picard1421: 1. logout from root, login as yourself,   2. go to your home directory, make a new directory, cd into that
<sladen> picard1421: 3. cp -a ../../somewhere/ ./here
<picard1421> k
<picard1421> ok?
<sladen> picard1421: so we're in your home directory (which is not a FAT partition), the copied tree is owned by *you* (not root) and isn't 777 ?
<slangasek> YokoZar: pam and libselinux are at the top of the list of packages to convert, and both of those are in ia32-libs today; so if we succeed in delivering any multiarch support, yes, we can start trimming ia32-libs
<picard1421> yes
<sladen> picard1421: does  'make all'  work now?
<YokoZar> slangasek: I'll note that PAM probably doesn't work properly in ia32-libs as it is now anyway (https://bugs.edge.launchpad.net/ubuntu/+source/ia32-libs/+bug/172400)
<ubottu> Launchpad bug 172400 in ia32-libs (Ubuntu) "pam modules need dynamic 32-bit support and are missing from ia32-libs" [Low,Triaged]
<picard1421> nope
<picard1421> still same errors
<slangasek> YokoZar: yes, I'm aware
<sladen> picard1421: delete  (rm -r that);  tar zxvf it again, fresh, into a directory in your home directory
<sladen> picard1421: ah, we're on #ubuntu-devel, lets take this private
<YokoZar> slangasek: Anyway, I'll keep an eye out and maybe help migrate some packages to multiarch once it becomes possible :)
<slangasek> that would be keen
<superm1> kees, okay i'll mess around a little bit with it.  worst comes to worst i'll just nuke em and make new schroot's
<mage7> hello....i am still looking for an idea for a college  project for 3 ppl...if any of you have an idea of any module you would like in ubuntu pls suggest
<mage8> hello....i am still looking for an idea for a college project for 3 ppl...if any of you have an idea\module you would like in ubuntu please suggest
<judgen> mage8, How about a dock that can be used with windowmanagers that enforces borders. This could be achieved with "override_redirect"
<judgen> Cairo-dock and awn work very poorly on those ytpe of envoriments.
<mage8> judgen...thanks for reply...i dont know whether it is suitable as a project..i have to see how large it is
<mage8> would'nt a patch to Cairo-dock or awn be a more appropriate repsonse
<judgen> mage8, maybe, i am not sure.
<LucidFox> I've been wondering
<LucidFox> what prevents GPL-like licenses from being revoked?
<judgen> LucidFox, Nothing per se, but the source that is under GPL is still available for usage and forking.
<judgen> You can not take back the code that is allready released.
<judgen> Compareable to a sales contract
<LucidFox> So, what will happen if a copyright holder tries to declare the terms under which they released their works void, and to prohibit existing users from exercising their GPL rights?
<LucidFox> they can't do that?
<ansgar> LucidFox: They cannot do that for old releases, only for new ones.
<ansgar> LucidFox: The GPL even states 'All rights granted [...] are irrevocable provided the stated conditions are met.'
<mage8> LucidFox:you cant go back on what you already agreed upon...thats like breaking the terms of the contract you have already signed
<mage8> however, if say you 're the sole copyright holder of the program and you release version 1.0 as gpl
<mage8> and you make modifications to it and release v2.0 under some other license ...that should be perfectly legal and enforcable iif am not mistaken
<mage8> however those got v1.0 under gpl are still under the terms of gpl
<mage8> in the case of linux however which has the contributions of thousands of people...there can be no change of license unless each and every contributer agrees to the new license
<smmalmansoori> hi
<smmalmansoori> i want to program a small feature for ubuntu and submit it
<smmalmansoori> can someone answer me a couple of question so I can go about it please?
<ronnie> Guys I found a problem in casper
<ronnie> on ubuntu 10.04
<ronnie> http://ubuntuforums.org/showthread.php?p=9649581#post9649581
<ion> Please use Launchpad for bug reports.
<ronnie> I dont know if its a bug yet, or what the bug is about
<ronnie> hopeing someone coudl enlighten me
<abhijit> hello all
<abhijit> :)
<njin> hello everybody
<ion> good news, everyone
<njin> SPArc isn't supported anymore??
<geser> for are long time already not anymore
<ion> blackz: Wouldnât it be nicer to put a single copy of ppa-purge to universe instead of having copies of it in a number of PPAs?
<BlackZ> ion: it's already in universe
<ion> blackz: Ah, a binary package hasnât just reached my mirror yet. I only looked at âapt-cache policy ppa-purgeâ and made an invalid assumption. Sorry for the noise. :-)
<BlackZ> ion: the binary package needs to be manually approved by an archive admin at this moment (it's in the NEW queue)
<BlackZ> s/approved/accepted
<ion> Aye
<alkisg> Tuxpaint and tuxtype were demoted from main to universe and the translations are missing (stripped), so they *only* need a reuploading. Is that possible, or some other method applies better? Besides reporting the problem (bug #503919), can we do anything to help with its resolution?
<ubottu> Launchpad bug 503919 in Baltix "Translations missing in tuxpaint-data Ubuntu 10.04 package" [Undecided,New] https://launchpad.net/bugs/503919
<Aquina> Isn't there an inofficial SPARC group which partially keeps the things running. I think I heard about that...
<jpds> Aquina: Yes, but it's unmaintained.
<mage8> looking for college project ideas....if anyone has any thing they would like to see implemented please give suggestions
<ion> mage8: Bug 1
<mage8> sorry didnt get the joke
<ion> http://launchpad.net/bugs/1 would be nice to get fixed finally.
<ubottu> Launchpad bug 1 in Ubuntu "Microsoft has a majority market share" [Critical,In progress]
<mage8> well we've to finish the project in 1 sem....unless we crash bill gates private yacht laden with explosives into redmond i dont think we would be able to finish the project in time
<alkisg> You could create a virus that transmutes all windows installations to ubuntu installations :D
<alkisg> *transformes
<alkisg> mage8: you need to be more specific, but I doubt if that's the correct channel anyway..
<alkisg> E.g. a programming project? In which languages, toolkits etc?
<mage8> well we're not really specific about topic...1. we're quite noob coders...2. 3 in a team...3. have 1 sem to finish(the next sem) 4. it should qualify as a project(that is it should not be something like bugfix or implement a small feature)
<mage8> language toolkits not specific...we look to learn the languages,frameworks in this sem and start coding next sem
 * alkisg doesn't know which channel would be appropriate for that question, but maybe someone in #edubuntu has some idea, if you ask at weekdays...
<mage8> well we've to submit abstract on monday
<mage8> and yeah i know we left it for the last moment
<mage8> hmmm...scanning through ubuntu's gsoc page
<jacquesdptd_iP-1> hello guys
<mage8> going  to bed ...to wake up in 4 hours
<jacquesdptd_iP-1> seems some people were wrong here, ubuntu iphone will never be possible, once again people like me and James that has been kicked when asking help talking about the project of porting ubuntu on iphone, were right to only listen to themselves
<Aquina> hello, jacquesdptd_iP-1
<jacquesdptd_iP-1> Cause, yes iX has done it, and James has completed the project and has or is on the point of releasing the first downloadable image :)
<jacquesdptd_iP-1> i hope you take it as a good news, cause further help after seeing it is a real thing will be much appreciated
<jacquesdptd_iP-1> Hi Aquina
<Aquina> iPhone sucks. It's a nightmare to integrate it into an already established IT-landscape. Blackberrys integrate much more seamless. And by the way... Apple is on it's way to close all it's stuff. UI and services was just the beginning...
<jacquesdptd_iP-1> that said Aquina, show me 1, only 1 phone that as managed to port any other OS for real and useable
<jacquesdptd_iP-1> ?
<jacquesdptd_iP-1> and dont show me htc hd 2
<jacquesdptd_iP-1> cause the guy is even not capable of clicking on the blind little error window
<Aquina> I don't understand the question ("for real and usable")? What do you mean by that?
<jacquesdptd_iP-1> ok the interface loads but that's it
<jacquesdptd_iP-1> i Mean that on my iX image i know browse internet
<jacquesdptd_iP-1> now
 * jacquesdptd_iP-1 set any settings i want
<jacquesdptd_iP-1> for sure many things remain to be made that's why i would like to be able to find cool people giving advice, what should we use to have even ligher image etc... We gonna set either Matchbox or Enlightnement
<jacquesdptd_iP-1> but the system is really working
<jacquesdptd_iP-1> as if it would be working on a computer
<Aquina> Sorry I still don't understand. When talking about operating systems I have my preferences. Regarding mobile phines and their special hardware requires different systems. I have no preference here. What I wanted to point out however is that Apple has broken and closed systems and is not better than Microsoft or thelike. I stongly recommend to use technically advanced systems like BSD or GNU/Linux.
<jacquesdptd_iP-1> and without James that began the project and never lost hope
<jacquesdptd_iP-1> and i remind myself a day i told him to come here to ask for help it was for touch screen that we were not able to use, he's got kicked, i can assume, myself to be a bit, straight, but he is really cool, the reason he was kicked was because we've told him, we can't install it on iphone
<jacquesdptd_iP-1> for sure iphone are some of the hardest phone to be used with third party os's
<jacquesdptd_iP-1> that's why idroid and now ix are brilliant things
<jacquesdptd_iP-1> cause planetbeing did an amazing thing reverse enginering every hardware to make unix/linux driver
<jacquesdptd_iP-1> s
<jacquesdptd_iP-1> he started from nothing and no documentation
<jacquesdptd_iP-1> i agree with you that some other device are far more open to be rooted and then used with other open sources project
<jacquesdptd_iP-1> but or now, except the n900 that i like cause of maemo on it and i find it really cool to have a linux distrib on a phone
<jacquesdptd_iP-1> Even if think iPhones are great phones to be use with their proper os (iOS) i like what did nokia
<jacquesdptd_iP-1> and then meego
<jacquesdptd_iP-1> but i was so much waiting for the first real port of ubuntu on a phone, and i'm really happy that we've made it, on iPhone 3g as i've got an iPhone 4, i'm gonna use it only with third party os's like iX
<jacquesdptd_iP-1> well that's it, my question was we've started from an ubuntu-minimal rootfs with armel karmic
<jacquesdptd_iP-1> xfce
<jacquesdptd_iP-1> and what would you advice as window manager ? Matchbox or e17 ?
<jacquesdptd_iP-1> even if we gonna try to make both for people to be able to choose then
<jacquesdptd_iP-1> cause of course, at the moment it's not the fastest system i've been running, but it runs and it's responsive, really
<jacquesdptd_iP-1> but i'm sure it still can be optimised
<ion> Does e17 implement something for mobile devices? If not, definitely not e17.
<jacquesdptd_iP-1> and you are the poeple that are the most qualified for this
<jacquesdptd_iP-1> i mean, if i have to find help in ubuntu dev, it should be the right place no ? :)
<jacquesdptd_iP-1> ion: you mean, no on screen keyboard, no gsm app that's what you mean ?
<ion> I mean, like matchbox.
<jacquesdptd_iP-1> cause the goal is also to have a real os running on the phone and to continue to use OS X when using the iPhone as a phone, it's more the fact to have a super little computer
<jacquesdptd_iP-1> ok
<jacquesdptd_iP-1> i've checked a bit, but it seems the project of e17 is not evolving that much
<jacquesdptd_iP-1> maybe matchbox is lot more customizable
<jacquesdptd_iP-1> but we want to use the port as a computer, sure it will be good if it can also be used to make calls, at least sip ones, but the use is really to have your little ubuntu in your pocket, aircrack , maybe flash lite will be able to run i have good hopes from test i've made for now, and some other stuff
<jacquesdptd_iP-1> all interesting we can do on a real desktop os that we can't on a mobile one :)
<jacquesdptd_iP-1> +things
<Aquina> Is this really Ubuntu on a Phone you're talking about?
<Aquina> e17 looks nice but is maybe to resouce consumptive.
<Aquina> cu
<jacquesdptd_iP-1> yes
<jacquesdptd_iP-1> i don't know for now
<jacquesdptd_iP-1> we are using xfce
<jacquesdptd_iP-1> sorry i was checking the video
<jacquesdptd_iP-1> dunno if ican deliver a video right now
<jacquesdptd_iP-1> cause James is the founder, is started the project, and i told him i'll wait till he release the first image, wich he should hve done this afternoon, but i have no news about if it's done or not
<jacquesdptd_iP-1> i see it normal that first greetingz goes to him cause without him nothing would have been possible, he worked night and days even when people were telling him we couldnt do it
<jacquesdptd_iP-1> and he was right to do it cause i think its pretty well done and that only the beginning, ok guys i'm gonna ask you just 1 or 2 question, advices, so i can continue to work tonight
<jacquesdptd_iP-1> i want it to be the lightest as possible, for now it runs, well, i even managed to remote control it from my iphone 4 and to use iphone 4 as mouse and keyboard with hippo remote
<jacquesdptd_iP-1> that was funny, an iphone to control another
<jacquesdptd_iP-1> vnc protocol, ssh running perfectly too
<jacquesdptd_iP-1> but now we gonna have to choose, a good wm, the best interface that would fit to the size, maybe see if we can use evtouch instead of evdev but i didn't manage to make evtouch to work actually, the best internet browser, and check if flash light could run on it, oh also, i'm using onboard for now as on screen keyboard but i'm sure i can find better and i have to find a gesture app in order to have a better experience
<jacquesdptd_iP-1> i was thinking about building an interface with maximus so we could have icons only in the top taskbar, and all windows maximised
<jacquesdptd_iP-1> like on ubuntu mid
<jacquesdptd_iP-1> but i don't know then how to make the keyboard not to be maximised to, and the best would be that the keyboard pops up when touching a form or any text input spot
<petergons> ex-chat
#ubuntu-devel 2010-08-01
<happyaron> pitti: ping
<happyaron> pitti: could you please have a look at bug #611224 ?
<ubottu> Launchpad bug 611224 in ibus (Ubuntu) "Please merge ibus (1.3.6-1) from Debian Squeeze" [Undecided,New] https://launchpad.net/bugs/611224
<bilalakhtar> I don't know why, but a rebuild of current maverick empathy results in FTBFS
<bilalakhtar> FTBFS REPORT! package empathy fails to build
<bilalakhtar> latest maverick version
<rsavoye> I don't see an import of icedtea into bzr on launchpad ?
<DktrKranz> slangasek, james_w (or any other archive-admin): I'm implementing rfc822 format for removals in dak, and I guess you parse removals.txt to automatically delete removed packages. Want to have a preview of the new format?
<james_w> DktrKranz: that would be useful. Are you rewriting the old files too?
<DktrKranz> yes
<DktrKranz> I created a parser for that
<DktrKranz> james_w: this is removal.txt "translated": http://ftp-master.debian.org/users/dktrkranz/removals.822
<james_w> DktrKranz: our parser is in lp:ubuntu-archive-tools in the process-removals.py script. I imagine it can be made significantly simpler now
<james_w> DktrKranz: have you tried parsing it with python-debian?
<DktrKranz> james_w: it was the reason I started to implement it, someone would be interested providing such a feature
<DktrKranz> they just needed a cleaner file
<DktrKranz> and I hope they'll have soonish
<james_w> excellent
<DktrKranz> old format will be still around, so no breakages right now
<james_w> cool
<DktrKranz> I'll get back to you as soon as patch is merged
<james_w> thanks
<lubosz> hi. i'm trying to compile a custom kernel with make-kpkg. i get following errors, because i have a custom name. how do i solve this? http://paste.pocoo.org/raw/244302/
<lubosz> please don't sent me to #ubuntu
<micahg> lubosz: you need an entry in debian/control for your custom package
<lubosz> thx
<pitti> apw: can you guys please do an lbm ABI bump for maverick?
<micahg> pitti: is it a regression for gtk+2.0 not to ship .la files in the dev package since other packages still rely on them
<lubosz> micahg: it did not help. how can i get rid of the "+" in my kernel name?
<micahg> lubosz: take it out?
<lubosz> error: package linux-image-2.6.35-rc6+ not in control info
<lubosz> it is not in my kernel config, afaik
<micahg> lubosz: rules file?
<lubosz> and i don't set --append-to-version=
<micahg> lubosz: the first line of the pastebin has a -p flag with the package name
<lubosz> hm, dpkg-gencontrol is called by make-kpkg
<micahg> lubosz: maybe try asking in #ubuntu-kernel
<lubosz> ah thx
#ubuntu-devel 2011-07-25
<hallyn> qemu-kvm's bzr tree is out of sync with the package, ubuntu4 vs ubuntu8. Is it usually ok to just bzr import-dsc the ubuntu8, or should i be hunting down each intermediate .dsc?
<jelmer> hallyn: my guess is that without the intermediate .dsc's the importer will move your branch out of the way later
<hallyn> what do you mean, move it out of the way?
<jelmer> hallyn: Sorry, I assumed you were talking about the UDD branch
<hallyn> i was
<hallyn> (i think :)
<jelmer> hallyn: if you push to the UDD branch and the importer gets fixed and tries to import the new packages in the archive, then I suspect it will overwrite your changes to import the missing packages
<jelmer> hallyn: and then create a merge proposal for your changes into the UDD branch
<hallyn> hm, which i would think woudl be want i want, right?
<jelmer> well, it depends on what you want :)
<hallyn> i just want lp:ubuntu/qemu-kvm in sync so ppl can use UDD if they want
<hallyn> i don't mind doing all the intermediate .dscs, i'm just not sure where to get them all
<jelmer> my guess is that import-dsc wo't work for the intermediate .dsc's, as the importer uses the same code underneath
<jelmer> if you just care about being able to do uploads for now, then importing the last dsc should be sufficient
<jelmer> you might have to "bzr pull --overwrite" in the future though, when the importer is fixed
<hallyn> cool, i'll give that a shot then, thanks jelmer!
<lamont> http://paste.ubuntu.com/651565/ <-- I wonder if this apport bug is known
<didrocks> good morning
<dholbach> good morning
<hrw> morning
<Q-FUNK> two uploads (to maverick-proposed and lucid-proposed) of cups-pdf were rejected. would anyone be able to tell me why?
<infinity> Q-FUNK: Automatic or manual rejections?
<RAOF> Q-FUNK: I documented that on the bug, did I not?
<Q-FUNK> RAOF: not that I could seee, no.
<Q-FUNK> RAOF: or which bug number are you talking about?
<RAOF> Q-FUNK: Which bug do you think I'm referring to?  Perhaps I was confused as to which SRU bug they were expected to fix?
<Q-FUNK> bug #805947
<ubottu> Launchpad bug 805947 in cups-pdf (Ubuntu Maverick) "SRU: hand-picked packaging fixes for Lucid and Maverick" [Undecided,New] https://launchpad.net/bugs/805947
<RAOF> Ah, ok.
<Q-FUNK> I'm perhaps confused as to whether to where to put the LP bug number  and which one, when it's an omnibus collection of fixes.
<Q-FUNK> RAOF: I just noticed the one you were talking about.  it might fix it too.
<RAOF> Definitely *somewhere* in the changelog entry :)
<RAOF> Because it wasn't clear what bug you were expecting to fix, I picked the LP bug from the most recent changelog entry.
<Q-FUNK> RAOF: ok.  how do I fix this one, then?  I guess my main point of confusion is that I the fix applies to two releases, so I'm wondering how to manage that.
<RAOF> Well, you'll make two separate uploads, which is fine.
<infinity> Q-FUNK: You can close it twice, once in each upload.
<infinity> Q-FUNK: And have two tasks for the bug, once for each release.
<Q-FUNK> ok, so what about now?  simply adding the LP bug number for the SRU and re-uploading as ~lucid2 ?
<RAOF> Also, I don't think âhere are some maintainer script changes you might want to pick upâ is a good SRU justification.  We need some way of telling whether or not the packages have actually fixed the bug(s) they were intending to fix, and also some idea of whether the bugs have an appropriate risk/reward.
<Q-FUNK> RAOF: it's the the changelog for 2.5.0-17squeeze1
<Q-FUNK> pitti even thought that my changelog entry there was a tad too verbose, when I asked him to review my delta.
<RAOF> Ah.  Has pitti commented on that SRU?
<RAOF> Q-FUNK: If that's all that you want to pick up, then why are all the other changelog entries there?  Maybe this is a mismatch on what's expected of an SRU.  What we're looking for in an SRU is (a) a clear description of the problem, making it obvious that it's worth SRUing and how to tell that it's fixed and (b) a *minimal* patch to fix that bug.
<Q-FUNK> RAOF: he reviewed my delta, but I don't think that he has commented in the bug.  he was the one who recommended dropping that LFS support, for instance.
<RAOF> Did he review your delta against Debian, against Oneiric, or against Lucid & Maverick?
<Q-FUNK> lucid and maverick, both of which have 2.5.0
<Q-FUNK> oneirc has an entirely newer upstream.
<Q-FUNK> actually, both natty and oneric have 2.5.1
<RAOF> Hm.  And he suggested that the changelog was appropriate for an SRU?
<infinity> The changelog is just detailing the packaging changes.
<Q-FUNK> the one for 2.5.0-17squeeze1 seemed to satisfy him, but it might be a side-effect of being intimately familiar with anything CUPS-related.
<infinity> It's a bit verbose, to be sure, but why deviate intentionally from the Debian changelog when it describes the actual changes?
<Q-FUNK> deviate? how?
<infinity> Q-FUNK: You're not, I'm asking ROAF.
<infinity> Q-FUNK: Who seems to want the changelog shortened for no clear reason.
<infinity> RAOF: Whils it's traditional for SRUs to be cherry-picks, when this one is literally a sync of Debian packaging changes, using the Debian changelog entries seems the same thing to do.
<RAOF> I'd like the changelog to be a log of the changes to *that* package; as it was, it described a bunch of things which were done and then reverted.
<infinity> Well, there's that.
<infinity> But, like I said, it's a sync (sort of), so having the history there isn't harming anyone.
<RAOF> That said, I'm reasonably happy to harmonise my views with the rest of the SRU team here.
<infinity> Since it needs an Ubuntu entry anyway (obviously), the ~lucidM and ~maverickN entries can point-form "this is what's being fixed".
<infinity> But having the Debian history before that doesn't hurt.
<RAOF> I'm not strongly against having the full Debian changelog in there.  As it was, though, it wasn't clear what bugs it was trying to fix, and it seemed to have a bunch of unrelated changes for the bug it looked to me like it wanted to fix.
<infinity> Yeah, I get that.
<infinity> Like I said, a nice summary in the Ubuntu changelog should resolve that.
<RAOF> Q-FUNK: So, if you replaced the top changelog entry with a summary of the Ubuntu bugs that it's fixing (and they've got lucid and maverick tasks), that would be fine.
<RAOF> (As in - the one targetting {lucid,maverick}-proposed.  Not the top Debian entry)
<evfool> ping mvo
<Q-FUNK> RAOF: the thing is, you added tasks for these on the other bug after my upload.
<RAOF> Q-FUNK: Is that a problem?  That's (one of) the bugs the upload will fix, right?
<Q-FUNK> RAOF: i can add it now, of course. :)  what should version should I call it?  ~lucid2 and ~mavercik2 ?
<RAOF> Q-FUNK: You should be able to version it ~lucid1 and ~maverick1 as I rejected them from the queue.  I think :)
<infinity> You think correctly.
<Q-FUNK> RAOF: ok, I thought that if once rejected, one cannot upload the same again
<RAOF> No, once *accepted* you can't upload the same again :)
<RAOF> The archive would get all narky.
<mvo> evfool: hello
<infinity> RAOF: No so much narky, as it would just auto-reject the uploads.
<evfool> what happened with the lp:python-apt branch? lp says it's not accessible since 20th of May
<evfool> mvo^
<mvo> evfool: oh, let me check
<Q-FUNK> alright. pushing lucid-proposed now
<Q-FUNK> and now maverick
<mvo> evfool: I fiddled around in LP now, lets see if it helps
<Q-FUNK> hopwfully, the changelog entry is a bit more clear as to what this is
<dholbach> Riddell, are you going to land your u-p-g branches? :)
<Riddell> dholbach: yes, that's first on my todo list after e-mail processing
<dholbach> yoohoo!
 * dholbach hugs Riddell
<evfool> thanks mvo
<Q-FUNK> oh, hi, dholbach :)
<dholbach> hi Q-FUNK
<evfool> mvo for 410310, the bug for the download size inconsistencies between apt strutl.cc and update-manager humanize_size, we might have to reimplement the same method in humanize_size as in strutl.cc SizeToStr, as just calling the apt method won't work because: it has a different format (8000 B is 8000 B, whereas in u-m it should be 8 kB), and it is not translatable
<evfool> mvo: what do you think?
<mvo_> evfool: yeah, that sounds like it was the reason for adding humanize_size. how hard do you consider this to be? will it be enough to move from 1024 to 1000 or is there more to it?
<evfool> evfool: moving from 1024 to 1000 and finding a way to use the locale-specific decimal separator instead of the comma should do it... although that will still leave some inconsistencies with apt (8000 B in apt = 8 kB in u-m)
<evfool> mvo^
 * Amoz waves to dholbach 
<dholbach> hey Amoz
<Amoz> to regenerate the .desktop files cache, one use the command desktop-file-install  --rebuild-mime-info-cache right?
<seb128> !pilot in
<seb128> !pilot on
<seb128> bah
<seb128> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: seb128
<seb128> \o/
<Amoz> no flying for you today seb128
<seb128> don't say that, it would make dholbach sad :p
 * dholbach hugs seb128
<seb128> dholbach, ;-) hug!
<tkamppeter> Seems that there is a problem with the buildds: See https://launchpadlibrarian.net/75925983/buildlog_ubuntu-oneiric-amd64.foomatic-filters_4.0.8-0ubuntu1_FAILEDTOBUILD.txt.gz: First one sees that gcc gets correctly installed into the chroot and then ./configure complains that it cannot find gcc.
<seb128> tkamppeter, that's not the error
<mvo> evfool: \o/ for your u-m branch, I will merge after lunch
<seb128> "checking for pkg-config... no
<seb128> checking for DBUS... configure: error: The pkg-config script could not be found or is too old.  Make sure it"
<seb128> tkamppeter, ^ that's your error
<seb128> tkamppeter, you need to build-depends on pkg-config
<evfool> mvo: thanks
<tkamppeter> seb128, thanks.
<seb128> yw
<CatFish> WHATS UNBUNTU
<directhex> i wonder what the likelihood of an ipv6 user not knowing what ubuntu is, given no residential DSL provider does v6 yet
<persia> directhex: Depends on the location: all the residential providers where I live do IPv6.  That correction aside, I've no data to answer your primary question.
<Amoz> apparently he found the IRC channel.
<jelmer> directhex: my residential DSL provider (one of the larger ones) does IPv6 too
<CatFish> see me walking treu winhost
<directhex> apparently it's just the UK where broadband providers think IPv6 is some funny thing not worth doing, then
<CatFish> see him true my window
<dholbach> Riddell, thanks a lot for your work on this!
<CatFish> jan de wandelaar
<Riddell> dholbach: more to come I think.  although it'll need some of the worse UDD bugs fixes before the guide can be made public
<dholbach> Riddell, I'm looking forward to it
<geser> directhex: not only UK, in Germany "T-Com" (one of the bigger providers) plans a beta phase with ipv6 (dual-stack) for customers this year
<nobuto> seb128: Could you review my debdiff for merge request Bug #811892?
<ubottu> Launchpad bug 811892 in mozc (Ubuntu) "Please merge mozc 1.1.773.102-1 (multiverse) from Debian unstable (non-free)" [Wishlist,Confirmed] https://launchpad.net/bugs/811892
<ScottK> directhex: It's not just the UK.
<ahasenack> hi guys, can I get someone from SRU to sponsor this Lucid one? https://bugs.launchpad.net/landscape-client/+bug/813477
<ubottu> Ubuntu bug 813477 in landscape-client (Ubuntu Lucid) "Update landscape-client to 11.07.1.1" [Undecided,New]
<zul> ahasenack: i can do it today
<ahasenack> zul: thanks. Just lucid, ok? I haven't finished testing the others
<zul> sure
<hallyn> SpamapS: jhunt_: hey, am I right that both runlevel 2 and networking.conf won't happen until mounted-varrun is emitted (by way of local-filesystems)?
<hallyn> I'm a little puzzled by the last comment in bug 495394.  Unless he has non-upstartified customizations, his libvirt should *not* be starting before /var is available...
<ubottu> Launchpad bug 495394 in libvirt (Ubuntu Natty) "autostart almost always fails on boot time host" [Undecided,Fix committed] https://launchpad.net/bugs/495394
<jhunt_> hallyn: yes, that's right. I wonder what his fstab shows? autofs? Also he mentioned "compiled locally" - did he install it properly I wonder?
<hallyn> jhunt_: that's what i was wondering, but i didn't want to go hurling around accusations without making sure i was understanding right first :)  thanks
<SpamapS> hallyn: ehhh
<SpamapS> hallyn: runlevel 2 is a lot more general than that, I wouldn't count on certain events having been emitted before it, so much as it is supposed to mean a certain state has been achieved
<SpamapS> hallyn: currently the only guarantee you have in runlevel 2 is that lo is up.. tho I should be changing that soon to be "all auto interfaces in /etc/network/interfaces are up"
 * SpamapS would be done w/ that if not for having to finish OSCON slides
<hallyn> SpamapS: hm.  ok.
<hallyn> SpamapS: certainly /etc/networking.conf waits on local-filesystems.  Does local-filesystems wait on mounted-varrun?
<hallyn> I would have thought so, but unfortunately that's hidden in the mountall source and not documented under /etc/init/
<SpamapS> hallyn: networking.conf is, IMO, poorly named. slangasek described it as a 'last ditch attempt to run ifup -a before runlevel 2'
<SpamapS> hallyn: the reality is that even w/ a server some network interfaces won't be available until udev has said they're available.
<SpamapS> hallyn: local-filesystems is a signal that means all non remote filesystems have been mounted. So it should always come after any mounted events that describe local filesystems.
<SpamapS> hallyn: I'm not aware of a 'mounted-varrun' event though
<hallyn> yeah i'm not finding  it
<hallyn> SpamapS: libvirt is (now) wiating on 'stopped networking' so your comment about waiting for udev is moot :)
<hallyn> so i guess i could add 'stopped mounted-varrun'.  but it still seems like runlevel 2 should not be reached until that happens anyway
<jhunt_> hallyn, SpamapS: "started They had mobile phones in the 19th Century?! Damn that infernal
<jhunt_> DeLorean, changing history!
<jhunt_> eeerrr
<SpamapS> hallyn: the change I'm working on will make runlevel 2 wait on all interfaces marked 'auto' in /etc/network/interfaces .. which means runlevel 2 will be more reliable for servers.
<jhunt_> hallyn: SpamapS: "started mounted varrun"
<SpamapS> what is this mounted-varrun ?
<jhunt_> hallyn: SpamapS: take 3: "started mounted-varrun"
<hallyn> jhunt_: so is local-filesystems not dependent on started mounted-varrun (or stopped mounted-varrune ven)?
<hallyn> s/\<ven/even
<jhunt_> Captain! We all seem to be suffering from some sort of warp in the brain/finger continuum :)
<SpamapS> This is heavy
 * hallyn resists the urge to quote Doc
<SpamapS> hallyn: please explain to me where you are seeing references to something called mounted-varrun
<slangasek> local-filesystems is not dependen on started mounted-varrun
<slangasek> SpamapS: removed in oneiric, since /var/run is removed
<jhunt_> SpamapS: the mounted-* jobs are in the mountall pkg.
<SpamapS> ahh
<slangasek> the replacing /etc/init/mounted-run.conf job does almost exactly the same thing
<hallyn> slangasek: ok, i wasn't clear from the man.7 pages whether 'all local fileystems in fstab' includes those in /lib/init/fstab
<hallyn> slangasek: so does 'filesystems.7' do it?
<slangasek> hallyn: mounted-varrun is not the job that mounts /var/run!
<slangasek> it's a job that's run *after* /var/run is mounted
<hallyn> slangasek: no, but it lets me know it has happened
<hallyn> yes
<slangasek> hallyn: what is the problem you're trying to solve?
<hallyn> making sure that libvirt-bin has /var available when it starts.  bug 495394
<ubottu> Launchpad bug 495394 in libvirt (Ubuntu Natty) "autostart almost always fails on boot time host" [Undecided,Fix committed] https://launchpad.net/bugs/495394
<slangasek> ah, let's see
<SpamapS> hallyn: why would libvirt-bin need to start before runlevel 2?
<hallyn> SpamapS: it shouldn't
<hallyn> SpamapS: what i'm saying is runlevel 2 may not be sufficient
<hallyn> i was trying to trace a dependency from /var being mounted to runlevel 2
<hallyn> Franck78 is implying that is not there
<SpamapS> hallyn: reading now
<slangasek> no, virtual-filesystems will be emitted before filesystem
<hallyn> sorry, it's a bit long
<slangasek> (note that /etc/init/rc-sysinit.conf depends on *filesystem*, not local-filesystems)
<SpamapS> no I have been keeping up in my email client actually
<slangasek> so this sounds like foot-shooting rather than an Ubuntu bug
<hallyn> slangasek: and does virtual-filesystems imply both /lib/init/fstab and /etc/fstab?
<slangasek> yes
<hallyn> the manpage is not crystal-clear on that
<hallyn> ok
<hallyn> yeah,  i wonder if he has a persistent /var over-mounting the fstab one
<hallyn> slangasek: ok, i'll just wait on him to file a new bug with more info
<hallyn> slangasek: SpamapS: jhunt_: thanks
<slangasek> mountall knows what to do with /etc/fstab entries that shadow /lib/init/fstab ones
<SpamapS> Honestly 99.9 % of things should start in runlevel 2. The confusion has come from the fact that sometimes the network interfaces that a service depends on won't be there, so there are way too many jobs that do 'net-device-up IFACE!=lo'
 * SpamapS hopes to be un-distracted enough this week to finish fixing that
<slangasek> fixing what?
<hallyn> :)
<hallyn> SpamapS: when you do, maybe you can remove the extra start on from libvirt-bin in oneiric again :)
<SpamapS> for servers that have their network interfaces configured in /etc/network/interfaces, have runlevel 2 wait until all the auto interfaces are up
<SpamapS> slangasek: ^
<slangasek> SpamapS: causing your ssh server to fail to start in the event of a network card issue?
<slangasek> ah, no, ssh will 'start on filesystem' curiously
<SpamapS> slangasek: we sat and talked about this in Budapest.. you may not have grasped the plan.
<slangasek> SpamapS: I was only in for part of the discussion :)
<hallyn> maybe it'd be safer to just add the extra 'auto-network-up' event *without* changing runlevel 2
<SpamapS> The issue is there are many services which fail miserably in runlevel 2 because their network is not available.
<slangasek> ok, I don't see anything else that's a problem if it waits for all the auto-interfaces to start, and ssh is covered, so
<slangasek> ignore my windmilling arms
<SpamapS> slangasek: and ssh starts on filesystem or runlevel [2345] .. so its covered anyway
<slangasek> yes
<slangasek> though that's a curious start rule
<SpamapS> its to cover the move to single user and then back to 2
<SpamapS> which *many* jobs do not do right
<slangasek> ah
<SpamapS> Many stop but never start back up
<SpamapS> little things.. like.. upstart-socket-bridge
<SpamapS> :-/
<jhunt_> ... and also many jobs start and never stop :|
<SpamapS> jhunt_: those at least have reduced in number as the bug reports are more comon for them. :)
<jhunt_> SpamapS: sure, but those jobs with no "stop on" are causing me interesting problems for a pure upstart shutdown. I'm certainly in favour of a more predictable shutdown sequence.
<SpamapS> jhunt_: some things don't actually need to ever stop
<ion> With first-class states, shutdown would be trivial. Have a âsystemâ state which goes down on shutdown, and have that level change trigger anything you need to happen on shutdown.
<ion> s/on shutdown/on requested shutdown/
<SpamapS> ion: we call those "jobs" .. we have that.. we're just not using it. :-/
<SpamapS> I've proposed this for a while.. have things follow a few virtual services rather than almost everything concocting their own magic recipe for start and stop.
<SpamapS> My focus has turned elsewhere of late.. but I hope to spend some time working on doing that on a small scale before FF
<superm1> slangasek, according to https://wiki.ubuntu.com/ArchiveAdministration today is you right?  would you mind helping look at the problem that kirkland encountered on bug 811231?
<ubottu> Launchpad bug 811231 in dkms (Ubuntu) "Sync dkms 2.2.0.2-1 (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/811231
<hrw> slangasek: how to disable armhf in eglibc during armel build?
<hrw> slangasek: found
<apw> cjwatson, it seems tha that the linux-lts-backport-maverick binary packages have ended up in universe, -natty seems to be ok
<cjwatson> apw: in what suites?
<cjwatson> ... never mind, I'll work it out
<cjwatson> apw: (note that I'm at DebConf - I'm dealing with this one now, but for the next couple of weeks it's probably better to find a different archive admin)
<cjwatson> apw: should be fixed after the next publisher run, so ~1h30m
<smoser> cjwatson, is i known bug that mini-iso kernel crashes on boot ?
<smoser> oneiric from http://archive.ubuntu.com/ubuntu/dists/oneiric/main/installer-amd64/current/images/netboot/mini.iso under kvm
<smoser> (this is new in hte last 2 weeks)
<cjwatson> smoser: bug 815962
<ubottu> Launchpad bug 815962 in udev (Ubuntu) "oneiric d-i based images kernel panic on boot" [Critical,Fix released] https://launchpad.net/bugs/815962
<smoser> thanks
<cjwatson> it'll be fixed visibly for real after the next d-i upload
<apw> cjwatson, ahh didn't realise, will find others to hastle, and thanks
<apw> jhunt_, hey we are seeing machines wherein halt has stopped working (as in sudo halt) but all other kinds of shutdown including halt -p do the right thing; the wrong thing being saying "halting" and leaving the power on
<apw> jhunt_, i see upstart has changed recently and wonder if there could be any correlation
<tumbleweed> bdrung: is the lintian build failure you reported not just a symptom of our recent umask change?
<smoser> anyone else have issues using squid-deb-proxy and ppas?
<infinity> apw: halt without switches should do exactly as you describe (print "halting" and leave the power on)
<infinity> apw: The fact that someone at some point made ours behave like "halt -p" was a bug. :P
<smoser> i dont expect it to proxy the ppas, but i think that i'm getting issues having it in the way, as it ends up giving me things like:
<smoser> W: Failed to fetch http://ppa.launchpad.net/dotdee/ppa/ubuntu/dists/natty/main/source/Sources  403  Forbidden
<smoser> mvo_, ^ ?
<apw> infinity, really, what use is that ?
<apw> smb, ^^
<kirkland> smoser: i think you have to whitelist it in the config file
<smb> apw, saw it
 * smb wonders about the use of that as well
<kirkland> smoser: i think i talked to mvo about that in dublin, changing the default config file to whitelist ppas
<smoser> doesn't htat seem like a serious bug ?
<smoser> you're telling me that you cannot use squid-deb-proxy and ppas together?
<smoser> (that is what i'm seeing, but i didn't think it could be so serious)
<infinity> apw: It's just the way it's always been in UNIX systems until we broke it.  But it does also serve some purpose, in that seeing the last output of halt can be useful, and much less so if you cut the power.
<infinity> apw: Either way.  I'm not the one who fixed it, I'm just pointing out that it's now fixed, not broken. :P
<apw> infinity, ok ... i guess i'll crawl back under my rock :)
<smoser> kirkland, ^
<Daviey> smoser: on oneiric?
<Daviey> smoser: I thought that mvo_ added that to be enabled by default?  Maybe we need to preseed it enabled.. can't remember the detail.
<smoser> Daviey, yes. on oneiric.
<smoser> i'm seeing this just ow, where i have:
<smoser>  * host system running squid-deb-proxy
<smoser>  * libvirt install of guest system passing it 'd-i   mirror/http/proxy string http://192.168.1.102:8000/'
<smoser> hm... so i guess it might be me that is doing something funny though...
<smoser> wonder if that can be made to work. generally its really  nice for guest network installs except if they have to hit a ppa, it breaks.
<Daviey> smoser: no, it sounds like squid-deb-proxy is correctly blocking if that is the rule.
<Daviey> But you should be able to autofind the squid server.
<smoser> i'm confused.
<smoser> why would you want it to block
<smoser> ie, i'm getting permission denied. why would that be desireable.
<bdrung> tumbleweed: maybe. what was changed in umask?
<Daviey> smoser: You think it should proxy * ?
<SpamapS> smoser: I've removed squid-deb-proxy* from my systems because of this problem
<SpamapS> bug 804267 if you're so inclined to comment
<ubottu> Launchpad bug 804267 in squid-deb-proxy (Ubuntu) "squid-deb-proxy does not allow downloading from arbitrary mirrors of packages" [Undecided,Confirmed] https://launchpad.net/bugs/804267
<tumbleweed> bdrung: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2011-June/000862.html
<Keybuk> jhunt_: about?
<smoser> Daviey, why would you not want it to ?
<Daviey> smoser: *shrug*, i suppose mvo_ wanted to restrict it to default install of official repo's
<SpamapS> It should proxy everything apt would reasonably request.
<SpamapS> OR the client should find a way to only make apt proxy official repos.
<smoser> right. as it is, it basically breaks you if you have ppas
<adam_g> uhm. is there any reason why  grab-merge or 'bzr merge' would completely ignore a file in a debian packages debian/patches/ directory?
<SpamapS> smoser: hence it going away from all of my systems (as of our hacking session in Dublin actually ;)
<SpamapS> adam_g: bzr merge must think that it was legitimately deleted
<adam_g> SpamapS: the debian repository hasn't been touched, its fresh from 'bzr branch'
<bdrung> tumbleweed: i can't reproduce the bug by setting umask to 0002
<bdrung> tumbleweed: do you have some minutes time for me to help debug lintian?
<tumbleweed> bdrung: I must go and have supper, I'm afraid, but I'll see if I can look later (if the cheese and wine party doesn't kill me) :)
<bdrung> tumbleweed: you are at debconf?
<bdrung> tumbleweed: i had an exam today
<mvo_> smoser: hello, sorry for the delay, I was at dinner. so the idea behind it is that you can enable squid-deb-proxy and by default its "safe" in the sense that it allows only trusted sources. its easy to enable everything. I guess its a debatable default, most home users will want it open, most coperation (I assume) will want it the other way around
<slangasek> superm1: limited availability, I'm at DebConf at the moment
<slangasek> ah, that's an easy one though
<slangasek> kirkland, superm1: sync blacklisting with a rationale of "orig.tar.gz mismatch" can be dropped as soon as the upstream version revs
<superm1> ah ok
<jdstrand> SpamapS: hey, I see that bug #495394 is now verification-done for all three releases, and sitting at 13 days in -proposed (according to LP). mind if I push it?
<ubottu> Launchpad bug 495394 in libvirt (Ubuntu Natty) "autostart almost always fails on boot time host" [Undecided,Fix committed] https://launchpad.net/bugs/495394
<jdstrand> SpamapS: (to -updates)
<Laney> mdke: you need to add a postinst that calls update-alternatives --remove-all $foo if $1 = configure and dpkg --compare-versions $2 le-nl the-last-version-to-provide-alternatives
<Laney> with some quoting
<hallyn> jdstrand: \o/
<jdstrand> SpamapS: am am just going to do it. it is in green on http://people.canonical.com/~ubuntu-archive/pending-sru.html for all releases
<SpamapS> jdstrand: days is not at >= 7 though
<jdstrand> SpamapS: it says 13
<jdstrand> in both LP and http://people.canonical.com/~ubuntu-archive/pending-sru.html
<SpamapS> Oh crap somebody said qemu-kvm
<SpamapS> not libvirt
<SpamapS> Yeah libvirt is ready to go now
<jdstrand> SpamapS: consider it done
<jdstrand> SpamapS: (literally)
<jdstrand> :)
<SpamapS> jdstrand: cool
<broder> the /run migration is finished, right? is there any reason then that https://code.launchpad.net/~ubuntu-branches/ubuntu/oneiric/initramfs-tools/oneiric-201106221912/+merge/65551 can't be bumped from the queue?
<seb128> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<seb128> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: seb128
<seb128> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<Laney> @shake it all about
<udevbot> Error: "shake" is not a valid command.
 * micahg thinks udevbot should learn the hokey pokey
<broder> Laney: +1
<Laney> broder: hmm?
<Laney> also, can backporters ack their own requests or is that Naughtyâ¢?
<infinity> Laney: Very naughty.
<infinity> Laney: I'm writing archive-spank.py as we speak to deal with this issue.
 * Laney sits on the naughty step
<ScottK> infinity: You assume he wouldn't like that.
<infinity> ScottK: I'm making no such assumptions.
<ScottK> Laney: No, it's fine as long as it really builds/installs/runs.
<infinity> ScottK: You assume I wouldn't appreciate it if he did.
<ScottK> Good point.  Sorry.
<Laney> Let's just try it and see.
 * Laney requests one. Get the spaking ready.
<infinity> If this launches into a Holy Grail recital, with the next inevitable line, we might have to stop talking about this in a public channel. :P
<ScottK> infinity: Laney misspelled a word, so the cycle is broken.  I think it's safe.
<Keybuk> a spaking! a spaking!
<Laney> spak me well
<ScottK> Nevermind.  We're doomed now.
<infinity> Keybuk: And after the spakings, the aural sax?
 * nigelb looks at channel, and the conversation, and blinks.
<nigelb> Am I hallucinating? O.O
<infinity> Yes.
<nigelb> hm, 3 am. Yeah. Probably need sleep.
<Keybuk> infinity: I'm trying to think of an archive-related pun instead
<Keybuk> so far all I've got is "the soyuz sex"
<Keybuk> I'll work on it
<infinity> Keybuk: That sounds like the worst night EVER.
 * nigelb refrains from violating CoC with puns
<Laney> have you /seen/ the size of those things?
 * micahg keeps forgetting he wants to be a backporter
<Laney> you're remembering now: go triage bugs :-)
 * micahg still has work todo, maybe later
<Laney> hah
<nigelb> Laney: ah, there was something I need to talk to you about.
<Laney> uh oh!
<nigelb> Basically, with the new packaging guide, I was hoping for some comments about a change
<nigelb> How about having a numbered step of things a new person would have to do. Like a quickstart. It was discussed before, and I'd like to actually get it done
<nigelb> Over the weekend, I checked out new contributor documentation with another project (mozilla) and compared it back with ours
<nigelb> Number of things we can learn off them.
<Laney> "to do" to achieve what?
<nigelb> To fix a bug in Ubuntu.
<Laney> different to http://people.canonical.com/~dholbach/packaging-guide/html/fixing-a-bug.html ?
<Laney> apart from the fact that that page is misleading
<nigelb> misleading because of UDD-only approach
<nigelb> ?
<nigelb> So, what I'm comparing against is this page - https://developer.mozilla.org/En/Introduction
<nigelb> Its numbered, so there are defined steps to do.
<nigelb> I <3 Step 3
<nigelb> Something we're lacking, I'm trying to see how we can use harvest to fill that gap.
<Laney> yeah, you could make those headings numbered if you like
<nigelb> Also, note that there are "bugs identified as being good for newcomers"
<nigelb> They are actually *real* easy bugs to get a flow for the process.
<Laney> a la bitesize?
<nigelb> even smaller :)
<nigelb> Mostly "remove one line of code", "typo"
<nigelb> bitesize bugs I've noticed are ones that go into upstream better than into Ubuntu
<Laney> Stuff you don't want to fix in a downstream patch.
<nigelb> exactly.
<nigelb> bah, I'm not awake enough for a proper conversation
<nigelb> Before I give up, I really liked the mentored bugs concept
<nigelb> I checked out a few of them
<nigelb> the comments had most of what needed to be done and who to contact in doubt
<Laney> I helped a couple of people through those, it was probably useful.
<nigelb> Now I give up, really tired. Sigh 3:30 am.
<Laney> what I was alluding to is that page fails to mention upstreaming at all.
<Laney> which probably violates "there is no surprises" (itself already a shaky claim)
<nigelb> Yes, that and it doesn't mention the old workflow
<nigelb> the package you pick to work on may not be in bzr.
<Laney> I can't see the guide being released as it is until UDD is free of kinks
<Laney> ScottK: micahg: Please snip some more in your -devel@ discussion :-)
<nigelb> hm, which is probably a good thing.
<nigelb> I thing something on micahg's client is messing up the email :)
<nigelb> *think
<nigelb> <-- bed
<Laney> night
<Laney> (I'll look at any MPs you have)
#ubuntu-devel 2011-07-26
<RAOF> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: RAOF
<TheMuso> has anybody updated recently and found their system unable to boot? I get a message "mountall: Disconnected from plymouth" and the system stops there. Am able to change VTs/reboot, but don't hae a login prompt.
<TheMuso> have
<TheMuso> I should clarify that this is oneiric.
<RAOF> TheMuso: I did get that recently when the root filesystem wasn't being passed to the kernel correctly.  Maybe your grub configuration is broken?
<TheMuso> RAOF: Ah ok, just booting into a live CD and settings things up to chroot in, thanks for the pointer.
<RAOF> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<didrocks> good morning
<dholbach> good morning
<jamespage> good morning
<jamespage> please could an archive admin accept the NEW binary packages for felix-shell and jasypt in oneiric
<didrocks> jamespage: done
<jamespage> didrocks: thankyou!
<didrocks> yw :)
<smb> @pilot-in
<udevbot> Error: "pilot-in" is not a valid command.
<smb> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: smb
 * smb is looking at https://launchpad.net/ubuntu/+source/xen/4.1.1-1ubuntu1/+build/2639667
<smb> It seems to depwait on ipxe (universe). Though that should be there and not having changed recently...
<StevenK> smb: xen is in main.
<StevenK> smb: It can not build against anything in universe.
<smb> StevenK, Hm, has zul moved that? Need to check, cause it built before
<Laney> looks like it was moved to main indeed
<Laney> https://launchpad.net/ubuntu/+source/xen/+publishinghistory
<StevenK> xen 4.1.0-3ubuntu4 was promoted from universe to main 3 days ago
<smb> Ok, it seemed to have moved to main with 4.1.0-4
<smb> Ah and was not in main when it built
<StevenK> Right
<smb> StevenK, Ok thanks. Guess I have to talk to zul then
<Laney> find the MIR and spank appropriately
<StevenK> Indeed
<StevenK> https://bugs.launchpad.net/ubuntu/+source/xen/+bug/790854~
<ubottu> Ubuntu bug 790854 in xen (Ubuntu) "[MIR] libxen-dev and libxenstore3.0 in main" [Undecided,Fix released]
<StevenK> Which is not right, zul needs a spank
<smb> Not sure about delivering any spank, but I'll bring it to notice
<StevenK> smb: Coward :-P
<smb> StevenK, Nah, it's called "wise"... ;)
<Daviey> smb: I thought there was a MIR for ipxe
<smb> Daviey, Can't say for sure. I am just the guy wondering... :-P
<Daviey> bah, maybe not.. zul was asked to raise one, i'm sure it's on his todo
<Daviey> (it shows on components-mismatch aswell)
<Daviey> smb: is it blocking you?
<smb> Daviey, Just wanted to see how much of the issues remain on oneiric dom0 running hvm with the latest build
<smb> And then wondering why I still cannot see it after it being uploaded for a while now
<Laney> Launchpad doesn't email about dependency wait, does it?
<Daviey> :(.. i'm sure zul will follow up on it today.
<smb> Daviey, I am sure we sort it out. Just happened to stumble over it
<Daviey> smb: thanks.
<mvo> smoser: I had terrible network problems yesterday, I'm happy to talk about the squid-deb-proxy defaults again today
<mvo> smoser: I'm not religious about it, if everything else things the default is wrong I'm fine changing it
<Daviey> mvo: Providing it's not an open proxy and only supports deb archives, i think it can be more relaxed.  Ideally, support debconf offical-ubuntu-archives-only & ppa-archives-allowed.. oh, and can i have a pony?
<mvo> Daviey: only a small one ;)
 * mvo will look at it after lunch
<Daviey> :)
<juliank> Whoever marcus.haslam@canonical.com is, I just got 7 emails from Launchpad on a bug report (Bug #769874) with an automatic reply that he is out of office. And now more on other bug reports. If someone has the power to stop this, please do so.
<ubottu> Launchpad bug 769874 in Ubuntu Font Licence "Naming restrictions in UFL considered non-free by Debian" [Undecided,Incomplete] https://launchpad.net/bugs/769874
<sladen> juliank: Marcus is the Brand Lead, and is on holiday.  He was using a local hacked-up autoresponder.  Marcus was contacted by somebody from IS very speedily, but still a few hundred made it out of the queue
<StevenK> sladen: If you give me a list of the bugs and comment numbers, I can get them hidden for you
<sladen> StevenK: awesome
<juliank> sladen: With local hacked-up autoresponder, you mean the "X-Mailer: Apple Mail (2.936)"?
<juliank> Not only away messages, but also Apple client.
<sladen> juliank: aye.
<juliank> sladen: And what's IS?
<sladen> juliank: Information Systems.  The sysadmins employed by Canonical who looks after the Ubuntu and Canonical servers
<sladen> juliank: (eg. the people who answer RT (Request Tracker) mails when there is an issue)
<juliank> sladen: OK, thanks for the explanation.
<sladen> StevenK: do you need the comment numbers (those are going to take longer for me to get, especially as LP is 303'ing my wget requests to grep them
<sladen> StevenK: or can you run a query for  WHERE .comment STARTSWITH "I'm out of the office until 1st August."
<StevenK> sladen: I can't run a query, no.
<chrisccoulson> will an alternate dependency hold a NBS binary in the archive?
<chrisccoulson> ie, listen depends on python-webkit | python-gtkmozembed, with the latter being NBS
<chrisccoulson> and we want the latter to go away
<seb128> chrisccoulson, it should not
<chrisccoulson> seb128, what about if a package recommends a NBS binary?
<seb128> don't do that ;-) not sure but archive admin can clean binaries that are still being used if they want
<seb128> chrisccoulson, the nbs cleaning is not automatic anyway
<seb128> so if the nbs list is an alternative depends and a recommend just ask for the binary to be cleaned anyway
<chrisccoulson> seb128, oh, i didn't realize it wasn't automatic
<seb128> chrisccoulson, the NBS with no rdepends are semi-automatically cleaned, i.e archive admin have a script they run to clean those
<seb128> chrisccoulson, the one with rdepends will need manually cleaning
<chrisccoulson> g'ah, this keeps python-gtkmozembed in the archive - https://launchpad.net/ubuntu/+source/indiv-screenlets
<chrisccoulson> not sure why that wasn't on my radar before
<sladen> StevenK: is there anyone else who can run such a query (this would be faster)
<sladen> StevenK: wget and screen-scraping is fairly low-tech solution
<chrisccoulson> and https://launchpad.net/ubuntu/+source/freespeak
<chrisccoulson> grrrr
<chrisccoulson> and there was me hoping that we would finally get rid of xulrunner from the archive this afternoon
<chrisccoulson> seb128, bug 816377 ;)
<ubottu> Launchpad bug 816377 in xulrunner-2.0 (Ubuntu) "Please remove and blacklist source and binaries from oneiric" [Undecided,New] https://launchpad.net/bugs/816377
<chrisccoulson> (although, i still need to fix 2 packages to stop pulling in python-gtkmozembed)
<seb128> chrisccoulson, ok
<StevenK> sladen: Yes, a LOSA can, but I'm not certain enough of the data model.
<sladen> StevenK: I'm writting some LPAPI code to get them
<sladen> StevenK: okay, I have a script.  what format do you want these in?  (since I can have the script print them in any format you want)
<StevenK> sladen: A shell for loop? :-)
<StevenK> Hm, that won't work
<StevenK> sladen: <bug> <comment 1> <comment 2> ....
<sladen> stevenk: what command are you going to run?  Is it something I can run my self anyway?
<StevenK> sladen: I'm going to run my own API script -- and no, you don't have access to the particular knob
<jamespage> please could an archive admin accept the felix-bundlerepository binary packages waiting in NEW into oneiric - ta
<lool> cjwatson: Hey, I had some "vmlinuz-foo" kernels in /boot which were picked up by grub in the past; now they still get picked up, but there's a dpkg warning: dpkg: error: mauvaise syntaxe de la version Â«%off%Â»%: version number does not start with a digit
<lool> dpkg: error: mauvaise syntaxe de la version Â«%on%Â»%: version number does not start with a digit
<lool> cjwatson: I think it's because update-grub calls dpkg --compare-version on /boot/vmlinuz-on and -off (local kernels of mine)
<lool> cjwatson: this is not causing me any issue, but I wanted to share this with you in case it could create trouble to specific setups
<ogasawara> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: ogasawara, smb
<cjwatson> lool: ok, please file a bug since I'm at DebConf right now
<ahasenack> hi guys, is someone from the sru team here? I would like to check on the status of the upload to lucid-proposed of https://bugs.launchpad.net/bugs/813477
<ubottu> Ubuntu bug 813477 in landscape-client (Ubuntu Lucid) "Update landscape-client to 11.07.1.1" [Undecided,New]
<Daviey> If an AA wants to tackle bug #816408, it would be post appreciated.  Thanks.
<ubottu> Launchpad bug 816408 in Ubuntu "Please demote eucalyptus to universe" [Undecided,Confirmed] https://launchpad.net/bugs/816408
<Daviey> s/post/most/
<lool> cjwatson: bug filed as LP #816411 for the error messages during upgrade
<ubottu> Launchpad bug 816411 in grub2 (Ubuntu) "dpkg warnings during update-grub - version number does not start with a digit" [Undecided,New] https://launchpad.net/bugs/816411
<slangasek> Daviey: we don't normally have bug reports for demotions, we auto-demote based on things being unseeded; if eucalyptus needs to be removed from the seed, that's core-dev, not AA
<Daviey> slangasek: Yes, it is now unseeded - the bug is maninly for tracking as it's quite complex.
<Daviey> (shows in component-mismatches, but it's not clear to an AA driving by - so the list hopefully helps)
<slangasek> hmm, well, I think component-mismatches is probably clear - it's also authoritative, so please make sure there's nothing listed on components-mismatches that you *don't* want unseeded ;)
<Daviey> slangasek: Oh, ok - was trying to make AA's life easier.  Guess we failed.
<slangasek> Daviey: sorry - hope you didn't spend too much time on the bug
<Daviey> well it was jamespage i should apologise to.
<jamespage> Daviey, slangasek: only ~10 minutes :-)
<apw> cjwatson, i believe i am correct is saying that grub2 takes the MTRRs from the BIOS in the normal case
<cjwatson> apw: http://lists.gnu.org/archive/html/grub-devel/2010-06/msg00129.html
<cjwatson> apw: basically yes it currently trusts the BIOS to set things up correctly (as the architecture manual says it should :-P)
<apw> cjwatson, yeah, thought that was the case, seems that an acer here with 2gb of ram gets a bad overlapping mtrr combination which results in UC for all ram
<apw> cjwatson, totally a bios bug, but of course windows and F15 fix it as they boot and are not affected
<apw> cjwatson, and indeed our liveCD isn't affected, so i assume syslinux does something
<cjwatson> syslinux probably isn't trying to do the same things with video - I expect it's only using INT 10 for video
<cjwatson> whereas grub is writing to video memory directly
<cjwatson> I imagine that if you disable gfxterm it'll wowrk
<cjwatson> *work
<apw> cjwatson, yes its better, but also the kernle is slow, and that doesn't happen with liveCD (syslinux) which is interesting
<cjwatson> I don't see anything in syslinux that fiddles with MTRRs (aside from showing them)
<Quintasan> Humm, anyone has any idea why jobserver is not available in my pbuilder? I wanted to do -j12 but make throws  warning: jobserver unavailable: using -j1.   out
<apw> cjwatson, now that is odd
<cjwatson> I would have expected the kernel to fix things up either way
<apw> cjwatson, nope, it assumes that the bios is right by default
<apw> one can ask for it to fix them
<apw> it is possible that F15 has this enabled by default, i'll try and find out
<evfool> mvo: now that natty and later won't have a notification area, what will happen with update-notifier?
<mvo> evfool: the original goal was to use a upstart session script
<mvo> evfool: but it does not quite support everyhitng needed :/ it needs file watching and time (cron) like events
<seb128> jdstrand, hi
<seb128> jdstrand, could we maintain those apparmor profiles out of the corresponding sources? like telepathy-missing-control
<seb128> jdstrand, it's annoying to stop being in sync with debian on the telepathy stack when we have no real maintainer on our side for that stack just because of apparmor profiles
<jdstrand> seb128: well, it has been our policy on the security team to ship enforcing profiles in the software that they confine. this actually helps with maintenance of the profile. The best course would be to get this upstreamed in debian, like we do with cups, et al
<jdstrand> seb128: I figured I would try to pursue that once the profile bugs are shaken out
<seb128> jdstrand, do you plan to send those to the bts? ;-)
<seb128> jdstrand, ok thanks
<seb128> jdstrand, I'm just trying to make sure the telepathy stack doesn't start being outdated because we stop syncing and nobody is looking at updating those for Ubuntu
<seb128> jdstrand, I guess I will add them to the desktop watch list
<jdstrand> seb128: I get that, but I'd like to point out that this is an important security benefit for users, since telepathy processes untrusted input over the network
<jdstrand> seb128: but like I said, I was going to try to get it into Debian, since they have an apparmor userspace now
<jdstrand> seb128: but I wanted to iterate on the profile a bit
<seb128> jdstrand, yeah, I was not suggesting dropping the profile, just was wondering if those could be maintained in an ubuntu specific source
<seb128> jdstrand, ok, that works too
<seb128> jdstrand, thanks ;-)
<jdstrand> sure thing :)
<hrw> hi
<hrw> does someone know does doko went for DebConf?
<lucas> he is there, yes
<hrw> thx
<hrw> so I can skip this week when it comes to cross toolchain hacking
<hrw> armel/armhf multilib stuff made ma argh ;D
<smoser> is there a debian developer here who could help me out ?
<smoser> i'm interested in getting an mbox archive of july debian-devel. it seems those are only available to DD.
<smoser> i'd like to respond to the thread http://marc.info/?l=debian-devel&w=2&r=1&s=virtualisation+images+of+Debian&q=b
<Daviey> smoser: seriosuly?
<smoser> well, yes and no
<smoser> :)
<Laney> cjwatson: I meant bzr-cvsps-import instead of bzr-cvsimport in my mail, which is why you couldn't find it
<ahasenack> hi guys, is someone from the sru team here? I would like to check on the status of the upload to lucid-proposed of https://bugs.launchpad.net/bugs/813477
<ubottu> Ubuntu bug 813477 in landscape-client (Ubuntu Lucid) "Update landscape-client to 11.07.1.1" [Undecided,New]
 * Laney added it to the set, but you'll have to remove it from the PPU
<infinity> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: ogasawara, infinity, smb
<cjwatson> Laney: ah, ok - done
<Laney> thanks
<jml> fwiw, I upgraded to oneiric today and my laptop now kernel panics on boot
<infinity> jml: We stopped supporting your specific model out of spite.
<jml> "Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)"
<jml> is this a thing I should file a bug about?
 * jml is downloading a 64 bit natty iso to recover.
<infinity> jml: Oh.  Or your root filesystem isn't being found by the initramfs.  And yes, bugs.
<jml> infinity: where should I file it?
<infinity> jml: Anything fancy about your rootfs?  RAID, dm-raid, dm-crypt, etc, etc?
<jml> not really. before I upgraded sometimes grub would look for it and not find it, and I'd have to wait a while before it could find it
<jml> forget the exact message, I'm afraid.
<infinity> That sounds like the very definition of a "fancy" rootfs.  There's usually not much waiting around for, say, /dev/sda2
<jml> well, it's just a plain old magnetic hard drive in a thinkpad
<jml> and I don't think I had encrypted the drive or anything like that
<jml> the hardware is... unsound. I dropped the laptop once.
<infinity> jml: Curious.  Then the bug probably belongs to the kernel, or possibly the hardware, if controllers are timing out.
<jml> well, I pulled it sharply by the power cable from a kitchen bench on to a hard floor...
<infinity> That tends to be frowned upon in the owner's manual.
<jml> yeah
<smb> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: ogasawara, infinity
<chrisccoulson> directhex, would you be able to help out with bug 798941?
<ubottu> Launchpad bug 798941 in moon (Ubuntu Oneiric) "moon FTBFS in oneiric with libav 0.7" [Medium,Triaged] https://launchpad.net/bugs/798941
<chrisccoulson> ingore the title, there's actually a patch attached for that already
<chrisccoulson> but i get a different issue ;)
<chrisccoulson> i'm pretty stuck here :)
<ahasenack> hi guys, is someone from the sru team here? I would like to check on the status of the upload to lucid-proposed of https://bugs.launchpad.net/bugs/813477
<ubottu> Ubuntu bug 813477 in landscape-client (Ubuntu Lucid) "Update landscape-client to 11.07.1.1" [Undecided,New]
<micahg> ahasenack: the SRU team reviews in queue, you just need to get someone to upload (unless you don't think it'll be accepted for some reason)
<ahasenack> micahg: zul uploaded it already, monday morning
<micahg> ah
<dupondje> [ 2682.603886] type=1400 audit(1311702264.071:19): apparmor="DENIED" operation="open" parent=2096 profile="/usr/lib/telepathy/telepathy-*" name="/usr/include/python2.7/pyconfig.h" pid=2097 comm="telepathy-butte" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
<dupondje> something changed in telepathy ?
<jdstrand> dupondje: yes. an apparmor profile was added. that denial was fixed in ubuntu2
<dupondje> oh ok thx
<jdstrand> bug #816429
<ubottu> Launchpad bug 816429 in telepathy-mission-control-5 (Ubuntu) "apparmor profile too restrictive for telepath-butterfly" [High,Fix released] https://launchpad.net/bugs/816429
<dupondje> Ok upgraded and it works :D
<jdstrand> \o/
<jdstrand> :)
<dupondje> up to the next issue :(
<dupondje> I want my caps lock to act like a shift-lock
<dupondje> Changed it in the regional settings, but doesn't change ..
<dupondje> weird
<altice> question for all, who is in charge of what gets put into the Repos?
<infinity> jdstrand: Not to nitpick, but why would/should tp-butterfly need to read /usr/include at runtime at all?
<jdstrand> infinity: yeah, that is weird, but I have noticed it in several python applications
<altice> did my post not show in the channel, anyone want to comment?
<infinity> altice: The people who upload things.
<infinity> altice: (With ~ubuntu-archive vetting new uploads to make sure they're legally sane)
<jdstrand> we might consider adding that to the abstraction
<altice> ah so it did, okay thanks. So if I wanted a program to be available to the repo I'd have to figure out where/how to upload it?
<infinity> jdstrand: Python misfeature, I suppose?
<jdstrand> *shrug*
<infinity> altice: Depends on your goals.  Do you want to be the person building the packages and uploading them, or do you want to have someone else dealing with those things?
<altice> infinity: I ask because I've continually run into issues with compiling a TACACS+ (networking auth server) and would rather fix my problem and others at the same time
<jdstrand> the actual access is pretty harmless so I just allow it
<infinity> jdstrand: Well, yes, I don't see it as a huge problem from the apparmor POV, just curious if it's actually intended behaviour.
<altice> infinity: well honestly, my lack of knowledge on how the process works.....would lead me to want to let someone else take the reigns. However, I wouldn't be opposed to doing it myself, just not sure how to get started
<jdstrand> no idea tbh. all I can say is that it isn't the first time I've seen it
<jdstrand> right, my totem profile has it, for example
<infinity> altice: Well, there are any number of ways to go.  If you're not particularly interested in doing the packaging and ongoing maintenance, I'd start with filing an RFP (request for packaging) bug with Debian, and see if anyone nibbles there.
<jdstrand> ah, might be because of C bindings?
<jdstrand> *wild guess*
<infinity> altice: (Well, first go over http://bugs.debian.org/src:wnpp and see if there's a bug for it)
<altice> okay
<infinity> altice: There are other avenues, such as packaging a first-cut and trying to find sponsors either in Debian or Ubuntu, or even taking up maintenance yourself, and working to become a Debian Maintainer or an Ubuntu MOTU.
<infinity> altice: Each presents more potential work and learning curve for you.  But checking Debian's WNPP and archives is a good start.
<infinity> altice: (Heck, what you want may already be in Debian and we just haven't synced it, in which case, such a request could be made to Ubuntu's archive admins)
<altice> infinity: you are certainly a wealth of knowledge :) I'm working on looking through the bugs now. I'm saving the suggestions your making so I can go through each avenue
<infinity> altice: If you decide to go the "package it yourself" route, both Debian and Ubuntu have fairly good resources for helping making that happen.
<infinity> altice: https://wiki.ubuntu.com/MOTU/Packages/REVU and http://mentors.debian.net/cgi-bin/welcome respectively, are used to help review and mentor new packagers and get their packages in good enough shape for inclusion.
<altice> infinity: looks like this is the only hit I found: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=588172
<ubottu> Debian bug 588172 in wnpp "RFP: libpam-tacplus -- TACACS+ PAM module." [Wishlist,Open]
<altice> oh thats neat
<altice> anyone else see that?
<infinity> Why does that sound familiar...
<altice> anyways, I believe the PAM module is an offshoot of the original TACACS server; Should I file a seperate request for simply that?
<infinity> Oh, because I know the upstream author.
<altice> very cool!
<altice> I must say.....since I've gotten into linux I've seen a lot of good community spirit
<altice> I like that
<infinity> Yeah, I maintain some of Pavel's other software in Debian.  He seems to have fallen off the face of the planet lately. :/
<altice> well let's hope it's not for any serious reasons
<infinity> Anyhow.  If what you're looking for is a daemon or something rather than the pam library, an RFP for that would be good, yes.
<altice> alright
<infinity> Nah, he's a tinfoil-hat security nut, I assume he's just hiding in a hole, covered with leaves.
<infinity> He'll pop up eventually.  Pun intended.
<altice> bwahahaha!
<altice> in comes the guy from futurama who can 'hear peoples thoughts'
<dupondje> If changing Caps lock into a shift-lock doesn't do anything. Where to report a bug ?
<dupondje> Don't know what packages should take care of that
<ahasenack> micahg: about that landscape-client package, do you know where it is?
<micahg> ahasenack: SRUs for the last day haven't been processed yet
<micahg> ahasenack: it's here: https://launchpad.net/ubuntu/lucid/+queue?queue_state=1&queue_text=
<ahasenack> micahg: thanks
<ogasawara> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: infinity
<barry> uh oh.  i just updated gconf in my vm and now boot hangs
<seb128> re
<seb128> barry, what lightdm version do you have in your vm?
<barry> seb128: 0.9.2-0ubuntu1
<seb128> barry, do you have lightdm-greeter-gtk?
<seb128> ups
<seb128> lightdm-gtk-greeter
<barry> seb128: apparently not (i'm looking at the installed package list through landscape since obviously the machine doesn't boot)
<seb128> barry, it probably boots but has no dm greeter, switching to a vt should work?
<seb128> barry, well install that
<barry> seb128: interestingly, i apparently have lightdm-greeter-example-gtk
<barry> seb128: let's see if i can do that
<seb128> barry, you probably upgraded before I fixed the package to properly recommends
<barry> ouch ;)
<seb128> barry, that package doesn't exist with 0.9.2
<seb128> barry, it should have got removed since it depends on a library which is conflicting with the update
<seb128> barry, lightdm-greeter-example-gtk I mean
<dupondje> had same issue here :) but lightdm-gtk-greeter fixed it :)
<barry> seb128: huh.  i did get a vt.  let me install lightdm-gtk-greeter then...
<seb128> did somebody didn't upgrade yet and can tell me if an update && update install it?
<dupondje> Its not yet published it seems
<dupondje> so :)
 * barry reboots
<barry> lightdm-greeter-gtk installed
<barry> seb128: beauty, that fixed it!  and it's nice to see i can actually click on my name and log in again :)
<barry> seb128: thanks!
<seb128> barry, yw ;-)
<micahg> I'm waiting for ubuntu2 to hit the mirror, ubuntu1 definitely doesn't upgrade the greeter
<seb128> micahg, thanks
<seb128> kirkland, hey
<kirkland> seb128: howdy!
<seb128> kirkland, just as fyi GNOME3 has a new user account dialog
<seb128> new technologies as well
<seb128> it's in gnome-control-center and uses accountsservice dbus service
<kirkland> seb128: hmm, okay;  some ecryptfs work needed?
<seb128> kirkland, that doesn't know about ecryptfs, I noticed yesterday
<seb128> kirkland, well if you want oneiric to have an ui to create ecryptfs users I guess so
<kirkland> seb128: ah, okay;  can't say i'm surprised
<seb128> kirkland, sorry for the late notice, I didn't think about it earlier
<seb128> well "late" in the cycle
<kirkland> seb128: right
<seb128> rodrigo from the desktop team is upstream gnome-control-center comaintainer
<seb128> he can probably help you to get that done if you have question
<seb128> but he doesn't know about ecryptfs I think
<kirkland> seb128: so I sent robbiew and slangasek and rickspencer3 a note last week, saying that ecryptfs is pretty far outside of my job responsibility and leisure time possibilities these days, so I asked them for some help staffing someone to look after ecryptfs, if we still care about it as a distro
<seb128> kirkland, do you think you could maybe open a bug with what g-c-c would need to do?
<seb128> so we can probably help on getting the integration side done
<barry> kirkland: i hope we do!
<kirkland> seb128: sure -- i think you just need a checkbox, and add --encrypt-home to the adduser call
<seb128> kirkland, ok that seems easy enough
<kirkland> barry: me too;  but I need some distro help on that ;-)
 * barry nods
<kirkland> barry: so glad to hear you speak up
<seb128> kirkland, well free free to reply that you have no time to help on that if you are busy
<kirkland> sure
<seb128> kirkland, but seems like from your description it should be easy enough
<kirkland> seb128: is there a bug already?
<seb128> no
<kirkland> seb128: or do you want a new one?
<kirkland> k
<kirkland> seb128: g-c-c is gnome-control-center?
<seb128> we need one, if you are to register it please do
<seb128> yes
<kirkland> k
<seb128> kirkland, if you don't I will do it later this week
<kirkland> seb128: i'm filing now
<seb128> ok great
<seb128> thanks
<kirkland> seb128: presumably g-c-c calls "adduser" and not some other user creating mechanism, right?
<seb128> kirkland, right, well it uses accountsservice which use adduser yes
<kirkland> seb128: okay
<kirkland> seb128: https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/816669
<ubottu> Ubuntu bug 816669 in gnome-control-center (Ubuntu) "encrypted-home support in new user dialog" [Undecided,New]
<seb128> kirkland, thanks!
<dtchen> seb128: just a note: using aptitude to update and upgrade lightdm to 0.9.2-0ubuntu2, lightdm-gtk-greeter does not get installed if lightdm-greeter-example-gtk or anything else providing lightdm-greeter is already installed.
<dtchen> (which is expected due to the alternate)
<seb128> dtchen, isn't the example greeter getting uninstalled?
<dtchen> seb128: no, it isn't.
<seb128> hum
 * micahg â¥ aptitude
<seb128> so I misread the
<seb128>     - lightdm conflicts with liblightdm-gobject-1 and liblightdm-qt-1 so old
<seb128>       greeters will be removed.
<seb128> checking...
<micahg> seb128: missing a -0 on the libs
<seb128> it should conflicts on liblightdm-gobject-0-0  as well I guess
<micahg> seb128: the current conflicts don't exist, they're both missing the second -0
<seb128> mic
<seb128> micahg, right, fixing...
<micahg> seb128: wouldn't it just be better to break/replace on the old greeters?
<seb128> same difference?
<micahg> practically, yeah
<nemo> Say, anyone notice that the featured apps in Natty version of software centre seem to click through to different apps than what you see in the list?
<nemo> (under What's New)
<nemo> sometimes works, sometimes doesn't.
<SpamapS> if I have an upstream with a debian/ dir and I want to completely ignore said dir for all 'merge-upstream' .. how can I achieve this?
<SpamapS> seems like it just makes merge-upstream nearly impossible every time.
<jelmer> hey sp	
<jelmer> *Spamaps
<SpamapS> jelmer: howdy
<jelmer> SpamapS: does the debian/ directory in the upstream change often?
<SpamapS> jelmer: occasionally
<RAOF> Yeah, that's really ugly.  One more for the âplease don't keep debian/ in your upstreamâ files :/
<jelmer> SpamapS: so, I don't really have a good answer
<SpamapS> I will ask again for them to remove it. :-/
<SpamapS> By them, I mean us.. because I'm a committer.. .. but.. reviews.. procedure.. blah blah. :-P
<SpamapS> actually I'm not even sure why its coming up as conflicting
<jelmer> SpamapS: you'll prbably get conflicts every time the debian/ directory in upstream changes even if you remove it manually after merge-upstream
<SpamapS> other than that they have different ancestors
<jelmer> if they have different ancestors then it would cause a conflict
<SpamapS> I was hoping maybe --forget-merges would help but it doesn't seem to.
<jelmer> since bzr keeps track of the identity of the various files, rather than assuming that files with the same path are the same file - this is what makes the renames work
<RAOF> Could you branch upstream, delete the debian dir, and then merge from that?
<SpamapS> they did at one very early point come from the same place
<jelmer> SpamapS: it should be fairly easy to deal with the conflict after a merge though
<jelmer> bzr merge-upstream && bzr resolved --take-this
<SpamapS> No its really painful
<SpamapS> its renaming debian to debian.moved
<SpamapS> and putting some files in there and leaving some.. its really confusing
<poolie> we should really merge that better
<micahg> jelmer: I think this bug is a blocker for general UDD adoption since source format 3 DTRT
<poolie> yes, there's a bug that's on our udd-affecting list
<SpamapS> I may just be showing some impatience..
<SpamapS> Anyway, I've slogged through it again.. will poke the bug.
<jelmer> micahg: agreed
<hallyn> i assume oneiric-amd64-alternate not booting is a known current issue?
<micahg> jelmer: is it at least stored in the upstream branch with pristine-tar right now?
<jelmer> micahg: the original debian/ directory? YTes
<micahg> jelmer: k, that would've been a much bigger bug :)
<jelmer> it's mainly the handling during merges that's broken at the moment
<jelmer> (with quilt patches too)
#ubuntu-devel 2011-07-27
<RAOF> SpamapS: Oooh, while you're here - is there a way of extracting the changes file from the unapproved queue?
<SpamapS> RAOF: the name of the package in the queue listing is a link to the changes file
<poolie> bug 806940 is part of this
<ubottu> Launchpad bug 806940 in Ubuntu Distributed Development "conflict if a dir is created in an udd branch" [Undecided,New] https://launchpad.net/bugs/806940
<poolie> though, perhaps eventually that will be duped onto a more generic one
<RAOF> SpamapS: â¦oh.  Bah! :)
<Yewbacca> What path does patches to the Ubuntu Xorg Intel driver take? Xorg.freedesktop -> Debian -> Ubuntu?
 * SpamapS signs off for the day
<RAOF> Yewbacca: Generally, yes; we're not slavish about it, though.
<infinity> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<Yewbacca> RAOF: Thanks for the reply. I was working with Wu Fengguang of Intel fame on fixing two major problems. ELD autodetection over HDMI support now added, meaning the HDMI output finally supports multichannel audio rather than just stereo.
<Yewbacca> The other fix involves reading the extended CEA mode block to finally detect all display modes rather than just the ones that fit in the basic mode block.
<Yewbacca> These are major fixes and I am concerned with how we can get them into Ubuntu's driver quickly.
<Yewbacca> They've been reviewed at Intel and released to the Xorg mailing list.
<Yewbacca> But they're of course drowning in all the other patches and discussions.
<RAOF> Right.
<Yewbacca> Do you have any suggestions? Should I focus on alerting Xorg.freedesktop.org to it and then let it trickle to Ubuntu? Or do you sometimes apply important fixes on your own and if so, who do I talk to?
<RAOF> That would involve both kernel and DDX fixes, yes?  In either case, we really do prefer that patches are at least applied to a development tree.  These sound like fairly large changes, so we'd want upstream to have signed off first.
<poolie> TheMuso, hi
<TheMuso> poolie: Good morning.
<Yewbacca> Actually they're only DDX modifications :)
<poolie> hi
<poolie> i just saw your post about the pulseaudio packaging branch
<Yewbacca> Oh yeah and I see your point, I'll alert some Xorg maintainers to review and apply them there first. Thanks for the advice.
<RAOF> Yewbacca: Then that's a bit easier :).  Still, we'd prefer them to be upstream first.
<TheMuso> poolie: The desktop team maintains similar branches for desktop packages as well.
<poolie> similar in the sense of debian-only
<TheMuso> Right.
<poolie> is this mostly for the sake of faster checkouts of it?
<poolie> as you know the general plan is to get the ubuntu namespace branches being official, and being complete branches
<TheMuso> poolie: No, its because thats how they were originally stored in bzr since before I really got involved with audio packaging.
<Yewbacca> RAOF: Thank you. I'll talk to some Xorg maintainer. Have a good night :)
<poolie> do you think we could migrate them to the standard form at some point?
<poolie> that would remove a special case from the piloting/contribution process
<RAOF> Yewbacca: I'm in UTC+10.  It's a good day for me.  Have fun with upstream :)
<TheMuso> poolie: Actually I was hoping to eventually move Ubuntu packaging to Debian git.
<poolie> hm, really?
<TheMuso> poolie: And what about the ubuntu-desktop packaging? How does that go in terms of patch piloting?
<poolie> because you're also the debian mantainer?
<TheMuso> poolie: Yes, easier to pull from either side patch wise.
<TheMuso> THe X guys do the same thing, I do the same thing with accessibility packages, and I am sure others working on Ubuntu, like the multimedia/MOTU guys do as well.
<poolie> the same thing here meaning maintaining it on debian.org, or meaning having only debian/ versioned?
<TheMuso> The same thing as in Ubuntu packaging maintained in alioth/debian git vcs.
<poolie> hm, ok
<poolie> so, this seems like a plan around having lp branches and contributions on lp may be on the wrong track
<RAOF> poolie: *Or* launchpad grows git support, I guess :)
<TheMuso> Yeah that too.
<poolie> so, what would happen in that case?
<RAOF> pkg-cli-* and pkg-mono also have all their canonical branches in alioth git.  I think it's a fairly popular mode of operation.
<poolie> you'd have the ubuntu branches on lp, but be able to more transparently merge them?
<poolie> or they'd stay primarily on alioth?
<RAOF> They'd probably stay primarily on alioth, but we could pull merges from launchpad.
<RAOF> That said, git is terrible at that workflow. :(
<TheMuso> I'm not sure. If the ubutu branches were on alioth, thats the only place I'd want to work with them.
<TheMuso> SO yeah, merging from lp would be useful.
<poolie> i mean there's no point in adding that support, which might not be cheap, if it's not actually helping ubuntu
<RAOF> It would help Ubuntu insomuch as merge requests against UDD branches would be useful.
<poolie> it seems like one of the things that makes them problematic at the moment is that people do the work essentially in the wrong place
<poolie> either directly in the tree when it should be in patches, or in an ubuntu branch when it should be an upstream change
<poolie> one of the working assumptions was that having different branches be more consistent (eg whole tree etc) would make that a simpler story to do properly
<poolie> raof, so would having the merge proposals be useful as compared to having patches on the bugs, or patches on debian bugs for that matter
<RAOF> Patches on the bugs are great; debdiffs on bugs are also great.
<RAOF> Patches on Debian bugs are also fine, but our stack is generally different enough that there are a fair number of bugs which aren't in common, and you need to be running Debian on bare-metal to usefully report a Debian bug on the stack.
<infinity> poolie: One of the general issues I have with UDD (or any of its predecessors) is statements about "doing work in the wrong place".
<infinity> poolie: Any contribution is the right place, and debdiff, or simple patches are all perfectly fine.
<poolie> because it can always be moved around later?
<infinity> poolie: (I'll admit that this sometimes makes the UDD stuff feel more like a hundrance than a help, but there must be clever ways to make it all work together more smoothly)
<poolie> i guess what i'm really asking is, how can canonical's infrastructure best be helping ubuntu?
<infinity> poolie: I dunno.  I might be in a vanishing minority, but I'd like to be able to just do dpkg-source work the way I've always done and upload a dsc/diff/tar/orig that integrates seamlessly into branch-based work other people want to do.  We're sort of there, and imports mostly work, but not quite.  And it's discouraging when people blame it not working on "the old way" being "the wrong way".
<infinity> poolie: But, some people love the shiny and new here too, so saying it's not worth making it as shiny as possible if it's not the way old farts like me work isn't helpful either.  It seems like a real value add.  It's just a value-add *I* don't care about. :)
<infinity> (And I realise I missed out on half the conversation here, and this is just a drive-by commenting on my way to beer, but if you want actual opinions, ask me sometime.  You know I'm full of 'em, some even useful)
<poolie> :)
<TheMuso> For me personally, I am happy working in alioth with git, because everything I track upstream uses git, which at times, can be very handy should one want to make a git snapshot release for a package. Just merge a git branch into the upstrea branch locatino or whereever you want, cherry-pick individual commits, etc. Bzr's biggest advantage is its merge algorithm however.
<TheMuso> gah typing.
<poolie> infinity: i see your point about not wanting to denigrate things people are doing that are working
<poolie> obviously technically the importer is supposed to handle merging them together and it generally does
<poolie> so themuso, if you were writing our plan for the next year (for udd/lp/bzr), what would you ask for?
<TheMuso> poolie: I am not the one to ask. Like infinity, I am happy with existing tools, and don't care much for UDD, probably because the majority of thigns I touch already are in alioth git, or will soon be.
<TheMuso> I don't mind having to do the extra legwork to make sure a particular patch author is credited for their work properly in a vcs.
<TheMuso> SO I guess all I'd prefer is patches/debdiffs.
<poolie> so your answer is essentially, "don't get in the way of using allioth?" or "improve the bug tracker instead?" or something?
<RAOF> Actually, that might be worthwhile.
<RAOF> Generate debdiffs from merge requests.
<poolie> or is it "make changes from branches and mps available as diffs/debdiffs?"
 * RAOF would also like bzr to be slightly better at being a git frontend, too. :)
<poolie> me too
<poolie> what sort of thing in particular?
<poolie> i guess, also, it's useful to know when you prefer using bzr-git  to git, and how we could build on that
<TheMuso> I lie RAOF's idea in generating debdiffs from merge proposals.
 * TheMuso will never use bzr-git, I'm happy with using git proper, as much as it can be quirky at times.
<RAOF> poolie: I prefer to use bzr-git to git anytime it works.  Mainly that's when I don't have to deal with a non-master branch, because there's no way of doing that with bzr-git (that I know of).
<poolie> i'll file a bug for debdiffs
<poolie> raof, i don't think there's a way to do that at present but there should be soon
<RAOF> I think a combination of git's colocated branches and bzr's sane way of actually pulling from other people would be great :)
<poolie> for native bzr branches, bzr-colo is pretty good
<poolie> ok, https://bugs.launchpad.net/launchpad/+bug/816757
<ubottu> Ubuntu bug 816757 in Launchpad itself "want to get a debdiff from an ubuntu merge proposal" [Undecided,New]
<poolie> can you help me improve the description?
 * TheMuso looks.
<RAOF> Actually, can we already download a diff from the merge proposal?
<poolie> yes; though apparently there may be a ui bug :)
<TheMuso> RAOF: You might be right. Let me go to the merge that started all this convo. :)
<RAOF> 'Cause there's basically no difference between a debdiff and a branch diff in that case.
<poolie> Ctrl-f "download diff"
<TheMuso> Right
<poolie> oh, i thought you were asking for more of debdiff's policy intelligence
<poolie> though, for packaging branches, that may reduce to not much
<TheMuso> Yup, works here.
<RAOF> Oh, right.  So there is.
<TheMuso> Thinking about it further though, as pilots, things get more sticky if we are working on a package that has an Ubuntu packaging branch in alito that we cannot directly write to. If we want to upload the change...
<TheMuso> alioth
<RAOF> That's the main problem with hosting on alioth, yeah.
<poolie> the problem being that ubuntu access control rules don't carry over?
<TheMuso> Yes, but one wouldn't expect them to I guess.
<poolie> so, is this bug valid?
<TheMuso> Probably not now that we know of the download diff link.
<RAOF> Maybe as a UI bug?
<poolie> saying "people didn't notice they could download the diff?"
<RAOF> Pretty much :)
<poolie> that seems ilke something we could possibly test on
<poolie> ok, updated
<poolie> thanks for the information
<didrocks> good morning
<lamont> fact
<ion> that.
<mwhudson> if an upstart job fails to start during a package upgrade, but runs fine when started with "sudo start $service", where can i start looking?
 * mwhudson finds http://upstart.ubuntu.com/wiki/Debugging
<cinerama_> hi folks, i have a query from a user about the mirror lists in synaptic....can anyone help?
<dholbach> good morning
<evfool> thanks mvo for merging
<mvo> evfool: thank you!
<mvo> evfool: I'm doing some gtkbuilder fixes and then I will upload
<evfool> mvo: remember that problem I told you about, with update-manager not being able to update because package names in dbus.strings instead of python strings?
<mvo> evfool: yes
<evfool> mvo: I have had the exact same problem on two different computers chroot, and after branching the latest aptdaemon and installing it, It's gone
<mvo> evfool: ok, let me do a update then
<mvo> evfool: sorry, I mean to look at it yesterday, but did not found the time
<mvo> evfool: hm, that is a bit odd, oneiric has the latest trunk
<mvo> evfool: of aptdaemon
<evfool> mvo: yep, but I still can't find out why I get this behavior. any ideas what should I be looking for? Getting this on two absolutely unrelated chroots isn't normal behavior
<mvo> evfool: right, let me try in a vm. are you using i386 or amd64?
<evfool> mvo:i386
<mvo> thx
<mvo> and a simple apt-get install --reinstall aptdaemon python-aptdaemon does not help?
<evfool> mvo: I'll try
<evfool> I've tried that, and it's working now, and when I get to the other PC, I'll try it there too
<evfool> don't know what could cause this
<mvo> woah, really odd
<jml> howdy
<jml> Hitting the "Delete" key doesn't seem to delete files any more. Known bug? Local config problem?
<seb128> jml, it's ctrl-delete now
<jml> seb128: oh. huh. is changing keyboard bindings an allowed thing now?
<jml> (I don't really have a problem with it. Heaven knows we could use more coherent default keyboard bindings.)
<seb128> ok, nobody freaks out but soyuz syncing testing bugged and did a sync-source on oneiric it seems
<seb128> normal "sync what is newer in Debian" we do before DIF
<seb128> but still we are after DIF...
<seb128> they are trying to figure what happened
<Laney> an accidental autosync run?
<seb128> yes
<seb128> testing the manual "one source syncing"
<Laney> whoops
<seb128> seems like it did trigger the wrong action somewhat and did a autosync run
<seb128> indeed whoops...
<directhex> awesome, oneiric gets to be super up-to-date
<jtaylor> should at least empty the sync queue ^^
<ahasenack> hi guys, will someone from the sru team look at the queue today? https://launchpad.net/ubuntu/lucid/+queue?queue_state=1&queue_text=
<ahasenack> my interest is landscape-client
<tuxcrafter> hi all
<tuxcrafter> what is the root pw for the ubuntu daily live
<tuxcrafter> http://cdimage.ubuntu.com/daily-live/current/
<tuxcrafter> tried live|ubuntu|<empty>
<tuxcrafter> somebody?
<Pici> tuxcrafter: 1) This isn't a support channel, try #ubuntu
<Hobbsee> tuxcrafter: from memory, it's ubuntu
<Hobbsee> or at least, used to be
<geser> tuxcrafter: just to be sure: you try sudo from the user account and not a login as root or su?
<tuxcrafter> sudo su -
<tuxcrafter> Hobbsee: sandly not working
<tuxcrafter> but id shows i am some kind of guest user
<Hobbsee> tuxcrafter: ah.  Then no idea.
<bdrung> seb128: do you use the new sync feature from launchpad for the syncs?
<seb128> bdrung, "sort of", cf what I said 2 hours ago
<seb128> there was an autosync run by mistake by the new sync feature
<seb128> so now I'm closing the sync requests which got done in that buggy run
<bdrung> ah, ok.
<ScottK> Ah.  That's what happened.
<smoser> barry, around ?
<hallyn> sbuild -d oneiric *.dsc
<hallyn> Only one build is permitted
<hallyn> eh?
<hallyn> oh, haha
<hallyn> kees: hm, on uptodate oneiric, my laptop appears to have no entropy?
<hallyn> dd if=/dev/random of=x count=8  hangs forever
<hallyn> (and so i can't sbuild-update --keygen, and so i can't build packages...  well i guess i'll set up pbuilder)
<hallyn> oh, 8 bytes came through
<dupondje> https://launchpad.net/ubuntu/+source/ginkgocadx/2.5.1.0-1
<dupondje> that changelogs look drity ass :p
<Laney> it's right in debian
<Laney> 's pts
<seb128> right, launchpad formatting for debian changelog is buggy
<dupondje> seems like all the syncs that are done 2 hours ago are that way
<dupondje> not nice :)
<seb128> i.e
<seb128> https://launchpad.net/debian/+source/tomboy/1.6.1-1
<seb128> dupondje, yeah, "known bug"
<bdrung> hallyn: you can move the mouse to increase the entropy
<hallyn> bdrung: no, neither mouse nor kbd was doing it
<bdrung> hallyn: then buy entropy in the super market ;)
<hallyn> i wonder if plugging in my phone might have helped
<hallyn> but i am wondering if this is a 3.0 kernel regression.
<bdrung> or pipe the entropy from another computer :)
<mdeslaur> hallyn: I'll sell you entropy for $1 per kb
<hallyn> mdeslaur: how do i know it's real?
<bdrung> mdeslaur: i'll sell it for 10 euro cent per dekabyte
<hallyn> i don't want any of that inferior walmart entropy
<mdeslaur> hallyn: purest entropy a 20-sided die can generate
<hallyn> mdeslaur: new service on amazon mechanical turk!
<mdeslaur> lol
<smoser> anyone know how doku usually handles python changes ?
<smoser> i added a merge proposal at https://code.launchpad.net/~smoser/python/lp-813295/+merge/69491
<ScottK> smoser: he's at debconf this week.  I'd ask barry to look into it.
<smoser> it looked like doku is the only one that touched python
<smoser> and the Vcs-Bzr is http://bazaar.launchpad.net/~doko/python/pkg2.7-debian
<smoser> thus the question.
<ScottK> Normally that's the case.
<ScottK> I also know is his laptop fan died so the odds of him attending to it this week are low.
<maco> i think firefox should be in the "special cases" section, but i don't actually know what the new policy is https://wiki.ubuntu.com/StableReleaseUpdates ...help?
<kees> hallyn: do more network/disk/mouse activity! :)
<infinity> maco: Firefox was previously listed in https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions ... That probably needs updating.
<maco> since they stopped micro-ing?
<infinity> Yeah.
<hallyn> kees: was doing a lot of all of the above!
<kees> hallyn: entropy generating sucks in the kernel, so doing strong key generation isn't generally something you can automate
<hallyn> kees: i didn't notice this under natty on this laptop.  i do under oneiric.  <shrug>
<hallyn> jdstrand: are you syncing libvirt from sid by chance?
<infinity> kees: I shouldn't tell you that I automate it, should I?
<jdstrand> hallyn: no
<kees> hallyn: I use this for good entropy: http://www.entropykey.co.uk/
<hallyn> drat :)
<jdstrand> hehe
<jdstrand> hallyn: fyi, I'm out the next two weeks starting monday
<kees> hallyn: nothing that I know of has changed between natty and oneiric
<hallyn> jdstrand: ooh, I can push SRUs!  :)
<kees> infinity: it's totally possible, sometimes it might just take a long time
<hallyn> kees: maybe i should pick one onf those up
<jdstrand> hallyn: :)
<hallyn> hm, a bit steep.  Wonder if i can solder my own
<infinity> kees: My trick is to background gpg --batch before an ISO image build. :P
<kees> hallyn: I have 2. they generate WAY the hell more bits than I could ever use
<hallyn> but seriously, i was typing like mad and downloading an iso
<kees> infinity: sounds good to me :)
<infinity> kees: It hasn't yet failed to complete before the image does.
<infinity> kees: (yet)
<kees> heh
<nemo> infinity: firefox is still microing though
<nemo> infinity: in fact, that page has an exception for chromium, and firefox is basically doing the chromium playbook now
<maco> nemo: by "its not microing" i meant they stopped having it be the .x that changes all the time
<nemo> ah
<maco> they give microreleases major version bumps
<infinity> ^
<nemo> right. well. that matches chromium
<infinity> And that certainly doesn't match what they used to do.
<infinity> Not just the cosmetic change. :P
<nemo> well. in terms of ubuntu policy, still would want to push out FF5, 6 etc for Natty
<infinity> But the new firefox versions are "rapid feature releases", not just bugfixes.
<nemo> infinity: they used to push new features into .x
<nemo> admittedly, not that many
<infinity> And yes, we're still pushing new versions.
<nemo> had to be a really useful one
<stgraber> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: stgraber
<persia> If anyone is about that could moderate a post to technical-board@, I'd appreciate it :)
 * infinity squints at Kate's mail to ubuntu-devel-announce.
<jdstrand> hallyn: fyi, I will be publishing another libvirt update today
<hallyn> for o?
<jdstrand> hallyn: no, lucid - natty
<hallyn> ok
<jdstrand> I already did oneiric last week
<smoser> barry, ^^ would you be able to look at/merge the python bug above?
<smoser> i'd like to have the images for alpha3 work on eucalyptus, and they will not without this fix.
<smoser> never mind, i see that you responded to the merge proposal
<barry> smoser: i just reviewed it ;)  looks good to me, but i want to get the patch into upstream py 2.7 first.  i will work on that in a few minutes.  assuming that goes okay, i'll merge your change (which is basically the upstream changeset) and push an update
<smoser> the commit is in the 2.7 branch
<smoser> upstream
<smoser> thats where i pulled it from
<barry> oh, the issue tracker didn't include the changeset that i could see.  it was just the default (3.3) and 3.2 changesets
 * barry looks again
<smoser> http://code.activestate.com/lists/python-checkins/98577/
<smoser> i didn't see it in the issue tracker either, and tried to backport the 3.2 change
<smoser> then got cpython and noticed it was already there.
<barry> smoser: huh.  yeah, weird that it didn't make it to the tracker
<barry> smoser: in that case, i'll merge and push in a few minutes (want to finish something up first)
<smoser> barry, thanks.
<bdmurray> lucas: I'm looking at the udd and the archived_bugs table seems to be empty I'm not sure if its just my copy of it or something else
<lucas> bdmurray: looks like it's your copy.
<lucas> udd=> select count(*) from archived_bugs; count
<lucas> -------- 527700
<lucas> (1 row)
<bdmurray> lucas: okay thanks
<jdstrand> hallyn: fyi if you are preparing libvirt SRUs: bug #817187
<ubottu> Launchpad bug 817187 in libvirt (Ubuntu Hardy) "change in readlink() errno in 2.6.39 and later kernels causes FTBFS for packages with older gnulib" [High,Triaged] https://launchpad.net/bugs/817187
<stgraber> rsalveti: looking at https://code.launchpad.net/~rsalveti/ubuntu/oneiric/base-files/run-transition/+merge/67444 is it still needed after all the /run changes that happened lately (including new releases of base-files)?
<hallyn> jdstrand: I'm not touching SRUs, maybe at all this week
 * hallyn goes to look in case he misunderstood
<jdstrand> hallyn: ack-- I just spent some time investigating the issue, so wanted to spare you that
<hallyn> jdstrand: i'm convused, it builds fine for oneiric, what fails?
<jdstrand> hallyn: I probably wasn't clear. If you are preparing srus and running an oneiric kernel, then you'll get ftbfs. the bug details all of this and what to do to fix the situation
<hallyn> ah
<hallyn> thanks!
<jdstrand> hallyn: right, change in kernel behavior in oneiric is exposed in chroots that cause ftbfs
<evfool> ping ev
<hallyn> ok, so as SpamapS noticed, since at least yesterday, if you debootstrap an image, you have to explicitly add the ubuntu-keyring package for apt to work.  That wasn't the case a few days ago.  Expected?
<kirkland> are there any good debhelper8 backports to lucid?
<kirkland> perhaps in a PPA, or something?
<kirkland> nevermind, i've worked around it
<maco> there's a debhelper8?
<maco> *now* how tiny is debian/rules?? O_o
<chrisccoulson> hmmm, i still haven't even converted firefox to use dh7 ;)
<chrisccoulson> and my debian/rules is huge
<chrisccoulson> **its
<stgraber> @pilot off
<udevbot> (pilot (in|out)) -- Set yourself an in or out of patch pilot.
<stgraber> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<galfly> Hey guys. Anybody here working for canonical lexington office?
<carif> here
<carif> don't ask me to do something difficult
<galfly> Hi carif. Not too difficult I hope
<galfly> any idea how long it takes HR to respond to new applications?
<galfly> haven't heard for weeks, kind of depressing
<carif> galfly, your irc nick isn't in https://directory.canonical.com/search/
<galfly> how come? I am on launchpad
<carif> galfly, i think you'll need to ask is at #is to add you and entry, take a picture, etc
<galfly> I'm not sure if I understand
<carif> galfly, oh perhaps I've mixed you up, I didn't read carefully enough
<carif> galfly, you've applied to Canonical for a job?
<galfly> carif, I applied to an opening at canonical and I'm on launchpad etc.
<galfly> carif yeap
<carif> galfly, so sorry, I was talking "internal speak"
<galfly> carif, I'm not there yet :)
<galfly> soon, I'll be fluent in internal
<galfly> I hope :)
<carif> galfly, me too, so how did you submit your application and to whom?
<galfly> cairf, I emailed my resume to hr@canonical.com with a cover but am not sure if that was the best way
<brianchidester> galfly: https://tbe.taleo.net/NA3/ats/careers/jobSearch.jsp?org=CANONICAL&cws=1&rid=86
<brianchidester> going through that would be a better start
<galfly> brianchidester thanks a lot. any idea how long it takes them to respond on average?
<maco> they say on the applications if its over 6wk with no response, might as well give up
<maco> i think
<maco> though im not sure with the new application system
<infinity> galfly: If you don't apply with the shiny new system, there's a fair chance it might slip through the cracks.
<infinity> galfly: (ie: don't email directly)
<maco> it kinda depends when the hiring manager has set aside to go through the Pile O' Stuff, but iirc from when i applied 3-4 wk?
<galfly> you guys all rock
<galfly> thanks a lot
<brianchidester_> galfly: sorry, battery died
<carif> galfly, good luck, later
<galfly> countdown from 6 weeks stars as of today
<galfly> looking for an apartment in lexington area as well
<galfly> ha ha!
<rsalveti> stgraber: no, it's not needed anymore
<rsalveti> just deleted the merge proposal
<stgraber> rsalveti: thanks
<hallyn> I wonder whether dpkg should detect failure to unpack a .deb and automatically remove+re-fetch one or two times
<barry> i'm having a hard time understanding an apt-get install error.  try installing python-qt4-dbus on oneiric and you'll get a broken package.  but afaict, python-qt4-dbus depends on python-dbus >= 0.80.0 and python-dbus 0.84.0-2 is installed
<infinity> barry: python-dbus : Breaks: python-qt4-dbus (< 4.8.3-3) but 4.8.3-2 is to be installed
<barry> infinity: ah, i had an out of date control file i think.  thanks.  still the apt-get error message sure isn't helping much ;)
<barry> infinity: thanks
<infinity> barry: It's a bit easier to sort if you "apt-get install python-qt4-dbus python-dbus"
<barry> infinity: yep, that makes much more sense
<poolie> hi again barry
<infinity> barry: Now, it would be hugely helpful if there was a new python-qt4 to sync that had the changes that I assume are required...
<barry> poolie: time files doesn't it? ;)
<ScottK> barry: python-qt4 4.8.3 is supposed to switch to dh_python2.  Now if only someone would upload it to Debian.
<barry> infinity: yes, there is that.
<barry> ScottK: maybe someone who had debian upload privs? :)
<barry> ScottK: i think this is fallout from the unintended sync
<ScottK> infinity: It would.  It would help even more if someone would upload such a change to Debian.
<ScottK> barry: That and the python-dbus upload being done slightly too soon in Debian.
<barry> ScottK: yep
<barry> ScottK: is there anything i can do to help?  i'm blocked on it atm.
<ScottK> barry: You can take that patch I pointed you at to review the other day and put it in dpmt svn for me to review/upload.
<poolie> barry i was wondering if after the holiday period we should do something to shake up the meetings a bit
<ScottK> (after suitable testing)
<poolie> i'm glad we started them and it's good to stay in touch but perhaps something new is needed now
<barry> ScottK: let me see if i remember where that is
<barry> poolie: i totally agree
<infinity> ScottK: is this in need of Debian NMU love, or is the maintainer on top of it?
<ScottK> barry: http://paste.debian.net/124320/
<ScottK> infinity: The maintainer is a team that all tries to avoid this one because it's painful.
<ScottK> I'll upload it once barry's blessed it.
<barry> ScottK: thanks.  let me test that
<barry> poolie: i think we should cut out the boilerplate and concentrate on what's really valuable
<infinity> ScottK: oh, fair enough.  Happy to sync it once you land it in incoming, then.
<poolie> yeah
<poolie> i don't have anything specific at the moment but i was going to ponder it over the holidayish period
<ScottK> barry: You mean assigning work to people that skipped the meeting?
<barry> ScottK: if by "people who skipped the meeting" you mean "you" then yes :)
<barry> poolie: agreed!  i'll do the same
<ScottK> barry: No problem.  I have a consulting rate related to having work assigned to me.  win-win.
<barry> ScottK: no problem, since i know you're familiar with my referral cut
<ScottK> Definitely win-win then.
<barry> ScottK: if only we were running the gubmint.  debt crisis solved
<ScottK> Mine anyway.
<barry> right :-D
<barry> ScottK: hey, when will debian policy force people to put each build-dep on a separate line?
<ScottK> Probably never.
<barry> everyone who puts one huge block of build-deps should be forced to read 100 diffs of them
<barry> anyway, i'm going to grab some dinner and let this build
<SpamapS> barry: for those diffs, I use vimdiff :)
<ScottK> barry: You'll want to merge python-defaults from experimental (I just uploaded it)
#ubuntu-devel 2011-07-28
<micahg> barry: have you been introduced to wrap-and-sort?
<infinity> barry: wdiff is your friend.
<micahg> barry: you could file a wishlist bug for the maintainer to use wrap-and-sort from devscripts if it's bad
<thomx> if user during installation selects encrypted home, then we don't use gnome-keyring for passwords?
<RAOF> thomx: No, we still use gnome-keyring for passwords.  What makes you think otherwise?
<thomx> RAOF: just installed cloudsn and it tells me that i use plain-text passwords by default rather than gnome-keyring. that made me think about it
<thomx> is there a way to check that i'm using gnome-keyring "by default"?
<thomx> or, set it somewhere? sorry for that i'm asking about it in -devel, but i guess no one in #ubuntu will know about these things
<RAOF> There isn't really a way to *not* use gnome-keyring.  Anything which uses gnome-keyring will use it, and will fail if it's not running.
<thomx> gnome-keyring-daemon is up and fine
<ScottK> barry: Feel free to package the python3 bits while you're up to your elbows in python-qt4.
<RAOF> Ack.  Are there any archive admins around?
<StevenK> RAOF: Hm?
<RAOF> StevenK: Can you please do the magical dance for update-manager updates?
<StevenK> RAOF: The ... what?
<RAOF> The https://wiki.ubuntu.com/ArchiveAdministration#Special_case:_update-manager_updates
<RAOF> StevenK: ^^^
<StevenK> RAOF: Yes, I saw, I'm reading, and distracted
<RAOF> Thanks.  Just checking :)
<StevenK> RAOF: For natty?
<RAOF> StevenK: Yes, please.
<StevenK> Hm, which doesn't exist. That's easy
<infinity> Quite.
<RAOF> Natty doesn't exist?  That'll make the SRU burden go down a lot!
<StevenK> RAOF: Bah. :-)
<infinity> :P
<StevenK> RAOF: main/dist-upgrader-all doesn't exist in natty-updates
<infinity> cp -a natty-proposed/dist-upgrader* natty-updates/
<infinity> Or I missed a main.
<infinity> But yeah.
<infinity> It *should* have existed, I suspect, we've been dropping that ball.
<infinity> And mvo's been picking up the slack with static URLs to -proposed.
<RAOF> So is this a case of out of date documentation?
<infinity> RAOF: No, the docs are correct, the admins are out-of-date. :P
<infinity> RAOF: I noticed this slack a week or so ago, corrected a bunch of d-i oopses, and some dist-upgrader oopses, but didn't fix all of the latter because mvo's workaround let me slack.
<StevenK> RAOF: Done.
<RAOF> StevenK: Thanks muchly.
<StevenK> RAOF: It won't turn up on archive.ubuntu.com for ~ 80 minutes
<RAOF> This, like asteroids, do not concern me.
<RAOF> Or possibly does not.
<StevenK> Heh
 * RAOF thinks the rest of the day should be devoted to routine work with low consequence for failure.
 * mwhudson has a strange problem
<RAOF> mwhudson: Do expound!
<mwhudson> perl -w /usr/share/debconf/frontend $POSTRM remove is hangin
<mwhudson> it has the packages postrm script as a zombie subprocess
<mwhudson> as far as i can easily tell, the postrm script exited normally
<mwhudson> can i make logging super verbose about what's going on somehow?
<StevenK> mwhudson: There's a DEBCONF_DEBUG env var
<mwhudson> StevenK: DEBCONF_DEBUG=1 apt-get remove $package ?
<StevenK> mwhudson: (I think that's it) -- if you set it to developer, you'll drown in debug logs
<mwhudson> ah ok
<mwhudson> hooray for virtual machine snapshots is all i can say
<mwhudson> well that was uninformative
<mwhudson> ah, http://www.fifi.org/doc/debconf-doc/tutorial.html#AEN198 seems relevant
<StevenK> mwhudson: Indeed. debconf is a little anal about FD usage
<mwhudson> could "sudo service apache2 restart >&2" do something with fds that debconf doesn't like?
<mwhudson> the answer seems to be yes
<mwhudson> in fact, i bet it's the >&2 that's the problem
<mwhudson> huh, no apparently not
<TheMuso> c
 * SpamapS does the happy dance as 11.04 boots on his new Macbook air
<RAOF> SpamapS: Oooh.  Correctly?  Last I heard was that i915 made everything blow up.
<SpamapS> http://www.backtrack-linux.org/forums/backtrack-5-beginners-section/41096-tips-dual-boot-macbook-air-3-2-a.html
<SpamapS> These guys show the way
<SpamapS> Specifically, have to make a new ISO with an updated isolinux
<SpamapS> http://www.uni-koblenz.de/~ceinig/howto/artikeldruck.php?id=92
<SpamapS> RAOF: I'm still just in the installer.. it may die a horrible death after this. ;)
<RAOF> Ah, well.  If the livecd's booted then it likely works better than Sarvatt's machine :)
<SpamapS> Now I just have to resist the urge to reinstall my main machine too.. Natty really surprised me.. Unity has grown on me quite a bit.
<SpamapS> ..and is dead for me on oneiric because of lack of multi-monitor.. :(
<RAOF> Multimonitor works pretty nicely in unity for me.  As long as you don't try and change the setup, of course.
<SpamapS> w/ nvidia twinview, it blacks out the entire second monitor
<SpamapS> for no apparent reason. :-P
<RAOF> Ah.  If you restart unity it'll probably work?
<SpamapS> nope
<SpamapS> It seems to be a deliberate "don't put stuff here" blackened area
<SpamapS> no clue why
<RAOF> Unity is (still!) terrible at noticing when it should draw onto a differently-sized framebuffer.
<SpamapS> hrm.. black screen after grub.. :(
<SpamapS> Yeah.. something's dying after 'Loading initial ramdisk' :-P
<RAOF> i915.diescreaming=1 should âfixâ it, FSVO fix.
<SpamapS> is that.. is that a joke?
<SpamapS> why no.. it isn't
<SpamapS> haha.. thank you :)
<RAOF> Passing any module parameter to a module that it doesn't understand will cause it to fail to load :)
<RAOF> So I like to be inventive :)
<RAOF> You've probably noticed the lack of 3d by now.
<ajmitch> there's a reason my laptop with an i915 is still running hardy :)
<SpamapS> and probably no multi-monitor capability either.. :-P
<SpamapS> which is.. sort of the point of having this machine.. to hook up to projectors
<RAOF> I'm *pretty* sure efifb isn't going to do hotplug for you, no.
<SpamapS> so the question is, where are we at w/ i915? Can I backport a kernel or something?
<RAOF> The intel kernel module is currently undergoing a period of âwhy doesn't this damned display work properlyâ fixing.  You could try drm-intel-next, but there are likely to be significant fixes soon.
<RAOF> Whether or not those fixes actually fix your Apple system is another matter, of course.  Mac hardware is special.
<SpamapS> If only somebody else made an equally sexy intel machine. :)
<SpamapS> At this point.. I'm thinking VMware fusion is my better option. :-/
<SpamapS> well I suppose a bug report is in order
<RAOF> Yeah.
<RAOF> It'll be difficult to get any useful info out of there, though; from what Sarvatt described, I think you'll need to netconsole to get anything out.
<RAOF> On the plus side for you, a member of Ubuntu-X has one of the shiny new Airsâ¦
<SpamapS> I am a server guy. I detest messing with any of this stuff.. :-/
<SpamapS> Just give me terminals.. lots of terminals.
<mwhudson> then clearly you should have bought a thinkpad :)
<SpamapS> Hah.. I refuse to give in to ugly hardware! :)
<mwhudson> i mean noone is going to take you seriously without a seriously ugly laptop
<SpamapS> I have to appeal to the ruby kids
<mwhudson> i don't think you can run textmate in a terminal, can you?
<ajmitch> going for the rock star look?
<SpamapS> ok bug 817324 filed
<ubottu> Launchpad bug 817324 in linux (Ubuntu) "New MacBook Air blank screen after grub" [Undecided,New] https://launchpad.net/bugs/817324
<RAOF> I find it odd that the livecd works, though.
<SpamapS> works, but not w/ 3D
<SpamapS> or at least, it was in classic mode
<SpamapS> RAOF: rebooting into the live cd now
<didrocks> good morning
<RAOF> Ra raw!  Morning, didrocks.
<SpamapS> RAOF: well i915 is actually loaded..
<RAOF> But you don't have 3D?  Hm.  11.04 should have sandybridge 3D.  Well, ish.
<SpamapS> xdpyinfo says GLX
<SpamapS> does the live env just always choose classic?
<RAOF> Install mesa-utils and run glxinfo to really check that it's working.
<SpamapS> Ok thats a meaningless burp of drivel to me.. but.. I do see "Software Rasterizer"
<SpamapS> glxgears looked nice, and got 708fps
<SpamapS> nah looks like fb still
<SpamapS> no multi monitor either
<didrocks> hey RAOF ;)
<RAOF> Hey didrocks.
<RAOF> SpamapS: Want to pastbin your /var/log/Xorg.0.log and dmesg to satisfy my idle curiosity? ;)
<SpamapS> RAOF: you are 0.5ms too late asking for that.. I just shut it down
<SpamapS> and need to sleep.. as I have to be on a plane in 8 hours
<RAOF> Ok.  Idle curiosity can be satisfied later.
<RAOF> Boo, hiss.  Air travel!
<RAOF> We hates it!
<SpamapS> RAOF: yes, I'll remind you when I am fighting the urge to return this to the store. :-/
<evfool> who should I ping to get a review for my usb-creator branch?
<RAOF> evfool: It _should_ be on the sponsorship queue, which should get it seen in not-too-long.
<evfool> RAOF: I've proposed a merge more than a month ago, and it did not appear on the sponsors queue since then
<RAOF> Hm.  It should do.  What's your merge?
<evfool> https://code.launchpad.net/~evfool/usb-creator/unityprogress/+merge/65844
<evfool> RAOF^
<RAOF> Ta
<evfool> RAOF: I've subscribed the Ubuntu Sponsors Team a few minutes ago to see if it does help to appear on the sponsors queue
<RAOF> Ah.  Yeah.  That merge is not targetted to an Ubuntu branch, so hasn't appeared on the sponsorship queue.
<dholbach> good morning
<evfool> RAOF: I also have other merges not targeted to ubuntu branches, but they do show up on the sponsors queue
<RAOF> evfool: It's possible that those branches have ubuntu-developers notified about merge requests.  That doesn't seem to be the case for usb-creator.
<evfool> RAOF: that might be
<evfool> ping ev
<TheMuso> evfool: ev maintains usb-creator. He may have seen it, but is likely busy with other things.
<evfool> thanks TheMuso, I'll ping him again, to see if I can get it reviewed and merged before alpha3
<ev> evfool: I'll review it today
<ev> apols for missing that
<evfool> ev: no probs, but I don't want the branch to be forgotten :)
<ev> sure :)
<karel_ff> Hi, can anyone explain how mysql gets started automatically when I do apt-get install mysql?
<karel_ff> I can't seem to find where this happens in the postinst script
<karel_ff> oh, found it... it's handled through upstart via /etc/init/mysql
<karel_ff> .conf
<dupondje> Somebody around that can try a test-build on armel ?
<jml> there's no Restart menu option?
<jml> huh.
<seb128> jml, no, log out and reboot from the login screen if needed ;-)
<seb128> jml, it's only temporary until they add the option to the dialog
<seb128> jml, i.e see https://wiki.ubuntu.com/DeviceMenuAndUserMenu
<jml> seb128: thanks.
<seb128> jml, yw
<seb128> jml, ok, I forgot to reply to menu edit question you asked the other day, you can if you don't use indicator-appmenu, check org.gnome.desktop.interface can-change-accels in dconf-editor and open the menu and hit the keybinding you want over the menu item to replace
<jml> seb128: did I *really* ask that question?
<seb128> jml, you asked if you could make nautilus go back to "delete"
<seb128> the move to bin action
<jml> seb128: ahh, right :)
<jml> seb128: thanks. that's probably too much messing about for me.
<seb128> yw
<johnt> hello all, does anyone know how to set up a default wallpaper using a preseed file?
<dupondje> sponsorng page not updated anymore ? Last updated at: Wed, 27 Jul 2011 11:00:47 +0000 :)
<dholbach> dupondje, bdrung: there's a bug in the sponsoring page
<dholbach> I'll file a bug
<dholbach> hum
<dholbach> hang on
<bdrung> dholbach: it runs and doesn't crash (did you read my mail?)
<dholbach> bdrung, http://paste.ubuntu.com/653733/
<dholbach> it does crash
<dholbach> at least on qa.u.c
<bdrung> let's see if it still runs locally
<dholbach> let me see one which MP it chokes
<dholbach> ok, it breaks on the first one
<dholbach> bdrung, http://paste.ubuntu.com/653737/
<dholbach> I added some debug prints
<dholbach> and there's the output
<bdrung> dholbach: you can output stuff if -v is specified
<dholbach> yeah, first merge proposal
<dholbach> bdrung, I'm asking in #launchpad
<zyga> barry: ping
<bdrung> dholbach: it runs locally without crashing
<bdrung> dholbach: current run: http://people.ubuntu.com/~bdrung/sponsoring/
<seb128> bdrung, that seems buggy
<seb128> like bug #814099 is closed for 2 days
<ubottu> Launchpad bug 814099 in sqlite3 (Ubuntu) "Please merge sqlite3 3.7.7-2 (main) from Debian unstable (main)" [Wishlist,Fix released] https://launchpad.net/bugs/814099
<bdrung> seb128: that's strange
<dholbach> bdrung, wgrant noted it might be a corrupt cache - let me check
<seb128> the most recent "time in queue" is from the 21 on your page
<seb128> bdrung, ^
<seb128> one week old
<bdrung> let me remove the cache and rerun it
<dholbach> bdrung, that's what I'm doing right now - it might well be that it was just the cache on qa.u.c that was corrupt (for whatever reason)
<zyga> anyone seen doko today
<mvo> zyga: I think he is at debconf
<dholbach> dupondje, bdrung: it works again
<zyga> mvo: ah, too bad
 * zyga wants someone with pip/virtualenv/setuptools knowledge
<MrNthDegree> Hello everyone, just curious as to whether or not there are any plans to allow a 64-bit kernel on a 32-bit install for Oneiric Ocelot
<bdrung> dholbach: here too. http://people.ubuntu.com/~bdrung/sponsoring/ seems to be up-to-date now
<MrNthDegree> given apt now appears to have multiarch support
<dholbach> bdrung, thanks
<dupondje> dholbach: sweet :D
 * zyga dives into python-defaults 
<bambee> hi, there is a package for libgl1-mesa-glx in 32 bit, on oneiric ?
<tkamppeter> I have renamed a binary package in foomatic-db. will the renamed package get into the archives automatically or does it need manual action by an admin?
<bdrung> tkamppeter: new binary packages end up in the NEW queue and needs to be manually accepted by an archive admin.
<tkamppeter> bdrung, who are the current archive admins so that I can contact them?
<bdrung> tkamppeter: why do you need to contact them?
<bdrung> tkamppeter: https://launchpad.net/~ubuntu-archive
<tkamppeter> bdrung, how often do they go through the queue? I need foomatic-db-xml be accepted to stop gutenprint from FTBFSing and some weeks ago I have uploaded a completely new package, cloudprint and I have still no reaction on it.
<bdrung> tkamppeter: binary packages tends to get accepted quickly (a few days normally)
<tkamppeter> bdrung, and completely new packages?
<bdrung> tkamppeter: that varies. that can take one or two weeks. if other packages depends on it, poke someone from https://launchpad.net/~ubuntu-archive/+members#active
<tkamppeter> cjwatson, hi
<geser> tkamppeter: he is at debconf and has probably no time for AA duties
<seb128> tkamppeter, why did you need to rename that binary?
<tkamppeter> seb128, it is to make sure that build processes of  printer drivers get the Foomatic database as original XML (so that the driver's PPDs can get built) and not as compressed PPD archive.
<tkamppeter> seb128, one can request the XMLs by installing foomatic-db-xml via Build-Depends:.
<seb128> tkamppeter, what was the issue before this change?
<tkamppeter> seb128, the printer driver package build-depends on foomatic-db. foomatic-db is once the XML package, but also a virtual package provided by foomatic-db-compressed-ppds.
<tkamppeter> On the last upload of gutenprint the buildds seems to have installed foomatic-db-compressed-ppds.
<seb128> you can't be a real and a virtual package at the same time
<tkamppeter> seb128, then the renaming would fix this by making foomatic-db virtual only (provided by foomatic-db-compressed-ppds and foomatic-db-xml).
<seb128> why do you need a foomatic-db?
<seb128> can't you just have the 2 other ones provides it?
<tkamppeter> seb128, in addition, I will change all driver packages which need the Foomatic XMLs to build-depend on foomatic-db-xml.
<seb128> tkamppeter, I still don't understand what was the issue that you are solving
<tkamppeter> seb128, the two other ones provide foomatic-db now. There is no real foomatic-db package any more.
<tkamppeter> seb128, perhaps you know that all the years Foomatic had XML files (in /usr/share/foomatic) which provided the data to generate PPD files for printers. This PPD generation process was very slow and the XMLs very disk space consuming.
<tkamppeter> seb128, so I came to the idea some years ago to pre-build and highly compress these PPD files and let CUPS take the PPDs from the compressed archives.
<seb128> right
<seb128> what I fail to see is how changing the name of the binary solve anything
<tkamppeter> seb128, this I turned reality in summer 2010 as a GSoC student coded the appropriate tool for me (the pyppd package).
<geser> seb128: afaiu there is a foomatic-db (with the xml files) and foomatic-db-compressed-ppds (provides foomatic-db) and tkamppeter has a package build-depending on foomatic-db but the buildd picked the wrong one
<tkamppeter> seb128, so I added a new binary package named foomatic-db-compressed-ppds to the set of binary packages of the foomatic-db-source package, holding the compressed PPD archive.
<seb128> geser, well, if foomatic-db-compressed-ppds doesn't really provide foomatic-db it should not use a provide?
<tkamppeter> seb128, many driver packages (and also printing tools in Debian which Ubuntu does not use) simply need Foomatic's PPDs and depended on foomatic-db therefore.
<alex____> dholbach:
<seb128> tkamppeter, ok, I newed it, still seems an unoptimal way to deal with it
<tkamppeter> seb128, as the compressed archive worked as well for them, I simply made the archive providing foomatic-db and this satisfied these driver and tool packages.
<alex____> dholbach: hi ! ;D
<dholbach> hi alex____
<tkamppeter> seb128, thanks.
<seb128> tkamppeter, you're welcome, thanks for the explanations
<alex____> dholbach: I can see the new UPG at ppl.c.com/~dholbach ;)
<tkamppeter> seb128, they told me that time that a build-depend will always pull the physical package and it did so all the time, until breaking on the last gutenprint build.
<dholbach> alex____, nice - I hope you like it :)
<tkamppeter> seb128, perhaps the buildds had already installed the compressed archive before starting to look into the build-depends.
<seb128> tkamppeter, it's likely yes
<tkamppeter> seb128, this new layout now assures that the right thing will be done.
<seb128> ok
<alex____> dholbach: yeah, btw I got a request from the owner of the Swe Loco. He wanted me to introduce new to ubuntu development. but I'm quite new to all this as well
<alex____> dholbach: new members*
<dholbach> alex____, how can I help?
<alex____> dholbach: I just wanted you to know
<alex____> dholbach: it was because of the omgubuntu article
<dholbach> alex____, give me a second, I'll dig out a link that you could use for presentation material
<dholbach> try http://spreadubuntu.org/en/material/presentation/introduction-ubuntu-development and http://spreadubuntu.org/en/material/presentation/fixing-bugs-ubuntu
<dholbach> alex____, I'll go on holidays tomorrow, but if you drop me a quick email, I could put you in touch with other Swedish Ubuntu developers who might help answer further questions you might have
<dholbach> alex____, the presentations not only have slides, but also notes which should help with the preparation
<alex____> dholbach: ah, norway :) have fun. No worries, I can manager, but I guess the presentation would take place in an IRC channel.
<alex____> manage*
<dholbach> I guess you could upload screenshots of the slides (wherever it makes sense)
<dholbach> and probably try to get the other Swedes on IRC as well :)
<dholbach> drop me a mail and I'll introduce you
<dholbach> and thanks :)
<dholbach> I'm looking forward to it
<alex____> to what? I don't know how much I can help actually, but okay
<dholbach> to some Swedish Ubuntu developers
<alex____> ah
<dholbach> I personally think giving a presentation is a great idea, especially if it's an introduction in your mother tongue
<alex____> as I said, it's not an IRL pres :P
<dholbach> still :)
<alex____> hmm, I guess it's still a good idea, even on IRC...
<alex____> yeah
<tgardner> cjwatson, is there a way to run the lucid server installer CDROM such that it won't eject the CD at the end of the install? I'm on a remote box where I'd really like theCD to stay i the bay.
<SpamapS> woot.. in flight wifi is amazing. :)
<zul> SpamapS: expensive?
<SpamapS> $9.95 for the flight duration (2hrs)
<Laney> which airline?
<SpamapS> Alaska
<SpamapS> latency is impressively good
<stgraber> it's 3G so it's usually somwhere between 40ms and 100ms
<stgraber> at least last I tried it on US airways
<kirkland> RAOF: howdy, care to help me with an intel video/unity issue?
<kirkland> RAOF: thinkpad x201, lspci at http://paste.ubuntu.com/653832/
<kirkland> RAOF: I'm unable to get 1920x1080 to my external monitor
<directhex> which issue?
<kirkland> RAOF: directhex: oneiric
<directhex> hm. haven't upgraded yet. kinda dreading it
<LarsT> i want to report a bug in ubuntu
<kirkland> directhex: well, it was broken in natty too
<directhex> kirkland, in different ways. a gushing edge kernel fixed the worst bug
<tkamppeter> seb128, thanks, gutenprint is building correctly now.
<seb128> tkamppeter, you're welcome
<seb128> kirkland, it's middle of the night for RAOF, maybe ask on #ubuntu-x
<kirkland> seb128: ah, okay, thanks
<LarsT> hello
<LarsT> are here developers
<LarsT> ?
<LarsT> i have a bug
<LarsT> report
<nemo> is deb http://archive.canonical.com/ubuntu natty partner by any chance mirrored anywhere?
<nemo> I'd managed to get mirror.anl.gov whitelisted in our stupid corporate firewall (the .gov helped) but unfortunately that does nothing for java
<nemo> so I'm manually copying over the java security update .deb files
<nemo> (which are blocked otherwise by the stupid stupid websense)
<nemo> well. https or ftp would work too - but I already tried. canonical doesn't support those apparently
<smoser> cjwatson, or anyone... how/when do new seeds populate to tasks ?
<smoser> my request for 'uec' task renamed to 'cloud-image' was merged, but i dont know how/when it would show up
<smoser> h.... never mind. seems like its good now.
<cjwatson> tgardner: cdrom-detect/eject=false as a boot parameter
 * Riddell nudges dholbach or someone to review https://code.launchpad.net/~jr/ubuntu-packaging-guide/libraries/+merge/69293
<cjwatson> smoser: I took care of that straight after merging your change - it's manual
<cjwatson> partly, anyway
<dholbach> Riddell, I generally liked it, just wanted somebody else to double check the symbols bits
<tgardner> cjwatson, thats what apw suggested, which worked.
<dholbach> I'm happy to add that as a comment
<Riddell> dholbach: yeah, me too :)
<dholbach> added :)
 * dholbach hugs Riddell
<dholbach> Riddell, I mentioned your good work in the weekly development update post I just did :)
<jykae> hey, how does natty perform on tablet machines?
<hallyn> hm, a tool (lxc-ps) wants to run 'mount -t cgroup', but needs to see /proc/self/mounts contents, not /etc/fstab.  Is there a precedent for handling this?
<hallyn> I suppose I could createa  fresh mounts namespace and bind-mount /proc/self/mounts :)  but that seems heavyweight
<hallyn> scripting the parsing of /proc/self/mounts myself gets just hairy enough that i don't want to do it in a one-liner (in a larger perl script)
<hallyn> and 'mount' doesn't seem to have a command line option to specify what file to use as mtab
<jykae> I'm excited about the Qt/qml, and I see Ubuntu becoming the member of the family
<jykae> experience from touch devices, bottlenecks?
<hallyn> guess i'll go with grep -E '^[^ \t]+[ \t]+[^ \t]+[ \t]+cgroup' /proc/self/mounts
<hallyn> feels hacky, but should work
<Laney> dholbach: can we get those posts on planet somehow?
<dholbach> Laney, they're on the fridge, so they should turn up on planet too
<Laney> ah, groovy
<dholbach> not sure why they're not on their yet
<Laney> why don't we see these new people in -motu? :-)
<hallyn> If I want to add a package (lxc) to my PPU set, should I create a whole new application wiki page, or just update my original one?
<Daviey> hallyn: I think it makes more sense for you to apply for ubuntu-server-dev :)
<Daviey> (lxc is part of that fwiw)
<hallyn> Daviey: curse you
<hallyn> Daviey: lxc bugs don't show up in the server set bugs, though.
<hallyn> so i'm not convinced it's int eh set
<hallyn> it should be, of course
<Daviey> hallyn: it is part of the ubuntu-server set, we are just not subscibred to the package bugs (fixing now)
<dupondje> https://bugs.launchpad.net/ubuntu/+source/apt-file/+bug/817622 => could somebody take a look ?:)
<ubottu> Ubuntu bug 817622 in apt-file (Ubuntu) "apt-file got broken in oneiric" [Undecided,New]
<Daviey> hallyn: fixed.
<hallyn> Daviey: cool, thanks.  I'd been counting on it being in there, so there were some bugs sitting around untouched for too long :(
<hallyn> Daviey: hey, DEP5 q
<hallyn> do I mark a bug as 'Forwarded: yes' if i have intent on sending it upstream in the next week or two? :)
<micahg> dupondje: that code change doesn't make sense
<hallyn> Daviey: I'm waiting to commit my source until you answer that :)
<dupondje> micahg: but it fixed my apt-file ? :)
<Daviey> hallyn: ubuntu-server package set in oneiric gives upload access to: http://pb.daviey.com/zTwD/raw/
<micahg> dupondje: let's move to -motu
<Daviey> hallyn: Forwarded: yes is implied if omited
<hallyn> Daviey: yes, but I feel like I"m lying if I say 'yes' but haven't yet done it
<hallyn> Daviey: if i plan to do it in next few weeks, is 'yes' ok?
<Daviey> hallyn: are you likely to upload again before release?
<hallyn> haha, at this point probably
<hallyn> almost definately
<Daviey> hallyn: then I would be inclined to mark it no :)
<hallyn> ok
<hallyn> Daviey: oh noes, i don't see open-vm-tools in that list :)
<Daviey> "shame"
<mdeslaur> hmm...I've got a python app that I've added to the unity launcher...but when it's running, unity doesn't see it as running
<mdeslaur> anyone know how I can debug this?
<bdmurray> lucas: How could I query all_bugs in the udd and not only show 1 report if it has been merged with others?
<bdmurray> er s/not//
<micahg> with the autosync snafu of the last day, we pulled in some stuff requiring libjpeg-dev, should we update libjpeg62 to provide that (unless we're going to do the libjpeg8 transition)?
<bdmurray> I'm trying to build a Natty version of apport for an SRU and I'm running into a failure I could use some help with
<bdmurray> http://pastebin.ubuntu.com/653912/
<bdmurray> In the top 21 lines that is the failure building with sbuild on Oneiric
<bdmurray> in the bottom half if I build in a natty chroot it works out fine
<bdmurray> and of course I've palyed with icons in my changes
<bdmurray> wow I haven't
<geser> bdmurray: on which filesystem (ext3 or ext4 or tmpfs) did you try to build? I've seen this error in the past already for apport but only in my tmpfs pbuilder (or some archive rebuilds) but the build on the buildd succeeded
<bdmurray> geser: I tried it in my PPA too and it failed .. ext3
<geser> hmm
<Laney> micahg: do you know how big the transition is?
<geser> bdmurray: there was some discussion about this error in the past but I don't know if it was found why it happens (and how to fix it).
 * micahg checks
<micahg> hmm, my script seems to be broke...
<Laney> laney@ries> zcat source/Sources.gz | grep-dctrl  --eregex -FBuild-Depends -sPackage "(libjpeg-dev|libjpeg62-dev)" | wc -l
<Laney> 309
<Laney> maybe I should do that on an Ubuntu box
 * micahg gets 37
<micahg> 373
<Laney> yeah, probably not then :P
<kees> mdz: tb meeting?
<kees> sabdfl: tb meeting?
<slangasek> kees: mdz indicates (via #debian-devel@OFTC) that he's unable to connect to freenode at present
<kees> slangasek: ah! thanks
<slangasek> and no idea if cjwatson is available, it's 8pm @ DebConf
<micahg> slangasek: e-mail to technical-board@ said not
<kees> slangasek, micahg: right, I've marked cjwatson and pitti as not-available
<kees> I can't find keybuk, and mdz's network is hosed
<Laney> while you have some spare time, please respond to the DMB voting query ;-)
<slangasek> keybuk is presumably not paying attention to his schedule because he's at the upstart sprint
<mdz> kees, I'm sort of here now
<mdz> I am riding the train, though, so conditions are not ideal for a meeting
<mdz> in perhaps 10 minutes I'll be in a more stable situation and can join the meeting
<sabdfl> kees, ack, and thanks :-)
<kees> mdz: okay
<apw> slangasek, it seems that the natty powerpc kernels may be in universe
<apw> slangasek, http://ports.ubuntu.com/pool/universe/l/linux/linux-image-2.6.38-11-powerpc64-smp_2.6.38-11.47_powerpc.deb
<apw> i wonder if you have time to check for me
<slangasek> apw: yes, looks like that needs adjusted for natty-proposed; that's the only place this kernel is, right?  (no -security or anything that I should be hunting down?)
<hallyn> mdeslaur: I'll try to verify 313812 today.  (gonna take awhile to d/l an iso to start :)
<seb128> barry, hi
<barry> seb128: hi
<seb128> barry, could you have a look to https://code.launchpad.net/~jbicha/ubuntu/oneiric/gedit-plugins/gedit-plugins-3.1.2/+merge/69386
<seb128> ?
 * barry looks
<seb128> barry, not sure why he needs to clean the .pyc manually, shouldn't dh_python2 do that?
<barry> yeah i think so.  i never do that explicitly
<mdeslaur> hallyn: cool, hggdh said he's look also, might want to coordinate with him
<mdeslaur> s/he's/he'd/
<hallyn> mdeslaur: ok, thanks for the headsup
<jbicha> barry: if you get some time, could you test that because when I only called it once, it didn't work right
<Quintasan> Can anyone tell me what's the policy for rebuilding a package in natty?
<barry> jbicha: i'll try, but i'm a bit backed up right now
<jbicha> dh_python2 may not be designed for use outside the normal install location
<barry> jbicha: you can give it a directory though
<barry> jbicha: heh, i see you do though
<barry> that might be a bug in dh_python2
<jbicha> and I have no idea why calling it a second time helps
<apw_> slangasek: yep just in -proposed right now .. thanks
<micahg> Quintasan: SRU process, like anything else
<Quintasan> micahg: Thanks
<barry> jbicha: afaict, that's just what you (currently) have to do if you give it a directory.  we've been discussing improving that, but i found the same thing
<seb128> jbicha, the second call is ok, but the find call to clean the .pyc is weird
<jbicha> seb128: that was there before I got to it, do you have a better one-liner for that?
<seb128> jbicha, well I though that dh_python2 ought to clean that for you
<seb128> barry, ^ should it be the case?
<jbicha> it's a .la removal line
<seb128> jbicha, your merge request has "+ find . -name '*.pyc' -delete"
<jbicha> ok, let me check into that
<seb128> thanks
<barry> ScottK: btw, i've just now verified that jose's patch to python-qt4 looks good.  i built the package with his patch, and then was able to install python-qt4-dbus and python-dbus where before i couldn't.  is there some other specific test i can perform to make sure it's working, or is build+installability enough?
<jbicha> seb128: ok, I removed that extra line and repushed
<seb128> jbicha, thanks
<zyga> barry: hi
<zyga> barry: do you have a moment?
<barry> zyga: sure
<zyga> barry: I ran across an interesting issue with: natty's virtualenv and dist-packages
<zyga> barry: should one be able to use virtualenv, install a package inside with --install-layout=deb and then expect to use it normally?
<zyga> barry: what I observed is this: 1) you can import a package normally
<zyga> barry: 2) setuptools-based scripts will not see it (despite the .egg-info meta-data) and will proceed to download it again, for dependency resolution
<zyga> barry: what do you think?
 * zyga just reproduced the issue to be sure
 * zyga looks at virtualenv directory to see how it looks like
<zyga> barry: interestingly, I could install but I cannot develop
<zyga> I thought this is identical but apparently not!
<barry> zyga: i just tested it here, and i can see that by default <dir>/lib/python2.7/dist-packages isn't on any sys.path
<zyga> hmm
<zyga> it is for me
<zyga> o_O
 * zyga tries to do it again
<zyga> oh
<zyga> I always use --no-site-packages
<zyga> perhaps that affects this
<barry> site-packages is, and /usr/lib/python2.7/dist-packages is and /usr/local/lib/python2.7/dist-packages is
<barry> yep
<zyga> w8
<barry> nope, i still don't get dist-packages
<zyga> barry: can you mkdir the relevant directory and try again
<zyga> barry: meanwhile I'm checking my local setup
<smoser> barry, can you do a python upload?
<barry> smoser: i saw doko's reply.  it's on my list :)
<smoser> k. thanks.
<barry> zyga: yes, if you create the dist-packages dir, it ends up on sys.path
<zyga> barry: ok, as soon as you create dist-packages
<zyga> barry: right
<zyga> barry: which is interesting and odd
<zyga> barry: I'm mainly interested in your expert opinion on how it _should_ work
<barry> zyga: it's odd that our favor does not create dist-packages
<zyga> barry: I'm inclined to use dist-packages and --install-layout=deb because that does not create the .pth file I really hate, I'm trying to create something like pbuilder for python and the fact that all the packages mutate .pth file is problematic
<zyga> barry: I'm also using python2.6 and python2.7, perhaps this is unique to 2.6 (never go to test 2.7)
<hallyn> jjohansen: around?
<jjohansen> hallyn: yep
<barry> zyga: my thinking is that it should work analogous to upstream behavior with site-packages.  iow, we add dist-packages and if that's doesn't work the way it would for someone use the source tarball, then it's a bug
<hallyn> jjohansen: on https://blueprints.launchpad.net/ubuntu/+spec/server-o-lxc-sandboxing, mind if I mark your item as postponed?
<barry> zyga: i think it works the same in 2.7 which is what i'm using
<zyga> barry: what is _really_ strange for me is that setuptools does not see this correctly
<zyga> barry: I have a few packages, when I try to install them with deb layout they all install correctly
<zyga> barry: but when I try to develop (say the last one) instead of installing it tries to fetch all the existing installed packages from pypi
<jjohansen> hallyn: please do
<barry> zyga: wait, when you say "setuptools" what do you mean, exactly? :)  remember in debian/ubuntu, setuptools is really distribute, and i think our version is hacked to understand dist-packages.  so if it's upstream's actual setuptools, then it doesn't surprise me too much
<zyga> barry: ah, distribute
<hallyn> jjohansen: done
<zyga> barry: though shortcut
<jjohansen> hallyn: thanks
<zyga> barry: stuff that says: from setuptools import setup, unlike the stuff that says from distutils import setup
<barry> yes, it's all very brain hurty
<hallyn> jjohansen: mind you, the patch they'r elooking at now could still be useful for very simple generic sandbox, but it's quite limited :)
<hallyn> np, ttyl
<zyga> barry: I tried digging into setuptools code but I'm not finished yet
<jjohansen> hallyn: yeah, but we can look at it for next cycle
<barry> zyga: you'll want to tie a rope off at the opening to the pit so you can crawl out afterward :)
<zyga> barry: what I find confusing is that with the .egg-info directories and `pip freeze` show what was installed to dist-packages just fine
<barry> zyga: so, try using distribute from ubuntu and see if that helps
<zyga> barry: haha
<zyga> barry: what do you mean?
<zyga> barry: you mean unlike the copy in virtualenv?
<barry> s/setuptools/distribute/ in your import statement
<zyga> barry: but setuptools _is_ distribute
<zyga> barry: in the virtualenv package in natty we patch it to use distribute all the time
<zyga> barry: so it's just the name, it's distribute underneath
<barry> right of course.  i'm thinking of something else, nm
<zyga> barry: so your suggestion was to change my existing virtualenv to use the host's distribute, correct?
<barry> zyga: wait, sorry, let's step back a sec
<zyga> ok
<barry> zyga: so, you create a virtualenv with --no-site-packages, then you install some dependencies into the virtualenv, then you try to install the package you're developing and it ignores the dependencies, right?
<zyga> barry: mostly, I install them with --install-layout=deb, then I can install all the packages I want just fine, *then* any attempt to devlop a package involves re-fetching dependencies
<barry> zyga: and does it do the same thing if you don't use --install-layout=deb?
<zyga> barry: no
<zyga> barry: then it all works correctly
<zyga> barry: installing to site-packages
<zyga> barry: and creating/modifying the .pth file I hate
<zyga> barry: peraphs I'm pushing the wrong door, I really wanted to avoid mutable file inside the virtualenv, I discovered dist-packages as a possible solution by mere accident
<zyga> barry: if there is a better way of doing that then I'm all ears
<zyga> barry: essentially dpkg-like guaranees (I shall not modify files shipped by another package) for random stuff on pypi
<zyga> barry: +bonus point if the same scheme works on windows/mac
<zyga> barry: so that the pbuilder-like tool works on those systems without magic ubuntu patches
<barry> zyga: so, a couple of things.  first, i searched around on bts and launchpad and didn't find anything relevant.  second, we are a little behind upstream, but offhand don't see anything relevant, unless we're talking about fixes in newer versions of the bundled pip or distribute
<barry> zyga: so, i think you're encountering a bug in our version of virtualenv.  it would be good to file a bug on that
<zyga> barry: I reviewed them too but I did not find anything that seemed relevant
<zyga> barry: I'll be happy to
<barry> zyga: cool, thanks
<barry> zyga: next...
<barry> zyga: i'm not sure how much a bug fix would help you anyway, since windows and mac definitely will not have the dist-packages hacks
<zyga> hh
<zyga> hmm
<barry> zyga: for a cross-platform solution, i think you will probably want to use upstream's virtualenv
<zyga> barry: how can I get rid of .pth?
<zyga> barry: btw: is there any spec, apart from the source, for what this file is designed to do and how?
<barry> zyga: heh
<barry> zyga: http://docs.python.org/library/site.html
<zyga> actualyl two setuptools and easy_install
 * zyga reads
<zyga> barry: that does not describe the non-declarative syntax of easy_install.pth
<barry> that's probably defined or described in one of the links from http://pypi.python.org/pypi/setuptools
<barry> http://peak.telecommunity.com/DevCenter/EasyInstall
<barry> briefly mentions it but doesn't go into detail
<zyga> barry: ah, I need to re-read them
<zyga> barry: last question
<zyga> barry: do you know if simply yanking that file post-install will affect stuff in unexpected ways? From what I understand it's not really doing anything if the package is in site-packages already
<barry> zyga: i wish i could be more helpful.  this is all a horrible mess
<zyga> barry: I agree
<zyga> barry: I wish I could help to untangle the mess but I dare to say the damage's been done and now it's hard to stay compatible and fix this
<barry> zyga: i'm not sure exactly what's in easy_install.pth, but be careful because sometimes .pth files use the hack that lines starting with import are exec'd to basically run arbitrary python.  buildout does this for example
<barry> zyga: right, and really this needs to be sorted out in distutils-sig
<zyga> barry: yeah, I assume it's also needed when you use multiple versions of the same library
 * zyga looks at that ML
<barry> yep
<zyga> barry: as in that case AFAIR they don't show up in stadard path by default
<barry> zyga: right, that's pkg_resources.require() functionality
<zyga> right
<zyga> ok
<zyga> thanks for your time
 * zyga goes to file the bug on virtualenv
<barry> zyga: you might want to file that on bugs.debian.org
<barry> zyga: i wish i had better news ;)
<zyga> barry: even though I never tested how this works on debian?
<barry> zyga: i'm betting it will work the same way there since we try not to delta too much. but if you feel more comfortable, file it on lp against ubuntu and we can link it to debian bts later
<zyga> barry: k
<zyga> barry: may I quote you on the bug?
<barry> zyga: sure, np
<zyga> bug 817702
<ubottu> Launchpad bug 817702 in python-virtualenv (Ubuntu) "virtualenv does not create dist-packages directory" [Undecided,New] https://launchpad.net/bugs/817702
<barry> zyga: thanks, subscribed
<roadmr> Hey folks! I used to be able to preseed auto-login with d-i passwd/auto-login boolean true, but this seems to have changed in Oneiric, anyone know where I could find the new setting to use?
<zyga> barry: .pth files are insane, the rationale for their existance is totally bogus!
<barry> ;)
#ubuntu-devel 2011-07-29
<ScottK> barry : check and make sure you can import whatever module name
<poolie> zyga: look at /usr/share/pyshared/lazr.restfulclient-0.11.1-nspkg.pth :)
<ScottK> barry: Did you get a chance to merge python-defaults from Debian Experimental?
<zyga> poolie: looking
<zyga> oh $DIETY
<zyga> poolie: what a mess
<zyga> poolie: what is the purpose of that .pth file?
<poolie> i don't know but the results are pretty psychedelic
<poolie> lazr looks like a builtin module
<zyga> poolie: and that is useful because... what? we save import lazr?
<poolie> i think it's an unintended side effect of packaging a namespace package; bug 796992
<ubottu> Launchpad bug 796992 in lazr.restfulclient (Ubuntu) "pth file overrides pythonpath" [High,Triaged] https://launchpad.net/bugs/796992
<poolie> maco, hi?
<slug> anyone with experience building with the launchpad ppa virtual machines? what's the hardware characteristics of these ? I just started a build and wondering how long would it take.
<slug> the other question is, what's the available disk space for compilation? is it 2GB or is it larger? my package is a large science C++ package and on my system takes a few GByte to compile.
<infinity> slug: There should be enough space and horsepower to make it go.
<slug> infinity: is there something similar to ganglia cluster monitoring ?
<infinity> Err...
<infinity> There's monitoring internal to their network.  Not that we expose to people building a single package, no...
<infinity> Well, unless you count https://launchpad.net/builders as "monitoring".
<slug> infinity: i see. is it only one cpu core assigned to each virtual machine?
<infinity> slug: It's not what you think it is, I think.
<infinity> slug: Our buildd network is a network of machines, not a cluster or supercomputer with virtual partitions.
<infinity> slug: The only thing "virtual" about them at all is that the PPA builders are Xen instances that get scrubbed between builds.
<infinity> slug: So, you get the machine you get.  Most of them are 2+ cores, most are over 2G of RAM, all have more than enough disk space.
<slug> infinity: all right, i'm just trying to assess the amount of time the compile would take, that's all. do you have any experience with git-buildpackage ?
<infinity> Lots of experience with git, lots of experience with building packages, very little with the specific tool. :P
<infinity> (I tend to live in the past and not use the new and shiny methods of doing... Anything)
<poolie> slug: i suggest you just upload a source deb and see if it passes
<infinity> ^
<slug> infinity: ok, so i have a question for you. the only reason i used git-buildpackage was to try to get a git format patch to send it to the debian/ubuntu maintainer.
<poolie> if it needs too much memory, which is possible, let us know
<infinity> Any patch will do.
<infinity> Maintainers that are whiny about format should be smacked
<poolie> they should have plenty of disk
<slug> infinity: i updated the deal.ii package from 6.3.1 to 7.0.0, but git-buildpackage seemed a bit confusing, so i ended up creating my own private git repo.
<slug> poolie: yeah, it's building now, i've uploaded it earlier. thanks for the offer
<infinity> {git,arch,svn,bzr,cvs}-buildpackage are just convenience wrappers.
<StevenK> s/arch/tla/
<StevenK> (... isn't it?)
<infinity> You can just as easily checkout/export and dpkg-buildpackage or even just "dpkg-buildpackage -I -S" (the -I makes sure it stips out common VCS directories and files)...
<infinity> StevenK: Wasn't there both?
<infinity> StevenK: But you might be right, with a ganish of "who cares?" :)
<slug> infinity: i'm still going to give a try. the point of me using git-build... was that debian doesn't have the 7.0.0 package yet, so i wanted to create a new branch/tag to make it easier to send the patch to the maintainer.
<StevenK> infinity: I'm not sure -- tla-buildpackage made me want to self-lobomotise a few times
<infinity> StevenK: arch/tla had that effect in general...
<slug> infinity: in the end, i've just created my own git repo, used quilt to update the patches and debuild -S to create the new source package.
<ajmitch> StevenK: and then you went to work on LP?
<infinity> ajmitch: He's not known for his decision-making skills.
<nigelb> Morning!
<nigelb> *yawn*
<ajmitch> afternoon
<micahg> evening :)
<kees> hallyn: eugene teo says he's trying to find you. have you gotten emails from him?
<hallyn> nope
<hallyn> oh, a few days ago, yeah
<hallyn> i responded (cc:ing the list)
<hallyn> and, i frankly don't get what people are hoping to get out of the discussion
<hallyn> kees: ^
<kees> hallyn: I have no idea, he just pinged me to see if you were on vacation. I don't even know that it's about. :P
<hallyn> hm, wonder if my reply got lost
<hallyn> are you on security@kernel.org list?
<hallyn> kees: oh well, if he asks again, tell him that I did reply :)
<kees> hallyn: no, I'm not
<hallyn> oh i figured you would be
<kees> hallyn: nope, unfortunately
<hallyn> kees: thx, good night
<kees> hallyn: g'night!
<jykae> morning
<maco> poolie: whats up?
<didrocks> good morning
<ion> that.
<mvo> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mvo
<didrocks> anyone know why winbind is now on the CD? it seems the cd growth was due to that
<barry> ScottK: it's on my list, and i'll look at that today
<seb128> didrocks, when?
<seb128> didrocks, the iso didn't change for a while
<didrocks> seb128: compare the 20110727 and 20110728 daily-live manifest
<seb128> didrocks, cifs-utils Recommends it
<didrocks> seb128: indeed, should we revert that?
<seb128> didrocks, it's a side effect of the autosync
<didrocks> yeah :)
<seb128> didrocks, I don't know enough about cifs to have an opinion on whether that recommends is right or not
<Laney> ask luk?
<Laney> it is under "* Install cifs.idmap upcall binary and manpage" so presumably somehow useful for that
<didrocks> Laney: doing that
<Laney> :-)
<didrocks> we have to way if it worths the 3+ extra MB on the CDâ¦
<didrocks> weigh
<seb128> didrocks, well, it's probably not wanted on the CD but it might not be "just revert the recommends", it might also be "don't install that new binary which was added"
<seb128> didrocks, "or add a new binary to the source for that"
<didrocks> seb128: sorry, I don't get you, "don't install that new binary which was added" ?
<seb128> didrocks, " it is under "* Install cifs.idmap upcall binary and manpage" so presumably somehow useful for that"
<seb128> didrocks, those might need to be installed in a new binary
<seb128> which recommends winbind
<seb128> but is not on the CD
<seb128> dunno how much cifs.idmap needs winbind
<didrocks> slangasek: maybe, when you are online, luk shouldn't be far from you :) winbind is adding an extra 3+ MB to the CD as it's now recommended by cifs-utils. Can you have a look at that? (see also ^^)
<didrocks> seb128: ok, got you this time :)
<seb128> didrocks, sorry for not being clear ;-)
<didrocks> let's say it's rather me being slow :-)
<seb128> well in any case best to let somebody who has a clue about that stack decide, pinging slangasek seems about right
<didrocks> indeed, he co-maintains the package
<seb128> the "easy" way would be to revert the "install cifs.idmap, manpage and recommends"
 * didrocks just adds a note to not forget that in case it's lost
<seb128> didrocks, or open a bug, milestone it a3 and assign to slangasek?
<didrocks> yeah, let's wait for them, just keep tracking it as the additional space is important
<seb128> so you are sure it's on track
<didrocks> will be better that my sticky note, indeed, doing
<seb128> thanks
<didrocks> yw :)
<mvo> slangasek: you reported bug #809980 some days ago, was this a one-time crash? or is that something still reproducable?
<ubottu> Error: Launchpad bug 809980 could not be found
<mvo> https://bugs.launchpad.net/ubuntu/+source/aptdaemon/+bug/809980
<ubottu> Error: ubuntu bug 809980 not found
<Laney> w
<Laney> oops
<fhd> I'd like to contribute a bit to Ubuntu, to Unity 2D in particular. Is Launchpad just used for bugs? Where do you track feature requests?
<Laney> unity people are in #ayatana AFAIK
<artfwo> mvo, hopefully i made my policykit intentions clear in bug 815283, check it out, if you have time
<ubottu> Launchpad bug 815283 in Ubuntu "[needs-packaging] indicator-cpufreq" [Wishlist,Confirmed] https://launchpad.net/bugs/815283
<mvo> thanks for this update artfwo!
<artfwo> mvo, i just uploaded another build to revu with fixed install path for *.pkla
<mvo> artfwo: so the file is needed for avoiding the password prompt? and if we just get it into policykit-desktop-priviledges directly it would not even be needed?
<artfwo> mvo, that's right, but my indicator is going to be in universe and policykit-desktop-priviledges is providing defaults for main so far
<artfwo> so i don't think it's sensible to include in policykit-desktop-priviledges
<mvo> artfwo: right
<zyga> RE
<hrw> fhd: for me feature request is a wishlist bug
<fhd> Laney: Ah, good to know
<fhd> hrw: Found mostly bug. Guess my first contribution will be a bug fix anyway, but I was wondering where the feature requests are.
<mdeslaur> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mdeslaur, mvo
<mvo> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mdeslaur
<apw> are we aware that indicator-messages and indicator-session are marked as breaks: indicator-me, which wants to be installed, triggering upgrade breakage ?
<apw> and are we aware that lightdm-gtk-greeter is not being installed by default when -example is removed
<seb128> apw, how so?
<apw> the former actually triggers errors when you try and install the ubuntu-desktop^ task
<apw> the greeter prevent login after reboot till you install the ubuntu-desktop^ task
<apw> whuc
<seb128> hum
<seb128> doesn't really make sense
<seb128> well the indicator is deprecated, indicator-session is replacing its features
<seb128> lightm depends on lightdm-gtk-greeter | libghtdm-greeter
<seb128> so there should be no way you get no greeter
<apw> seb128, well i just upgraded and didn't get a greeter
<apw> this was about 2 hours back i did the upgrade
<apw> when the greeter didn't appear i used the ubuntu-desktop^ to get things better
<apw> which did trigger apt-get dist-upgrade to then install the greeter
<seb128> how can you get lightdm and no greeter it if has a depends on a greeter?
<apw> but triggered errors about the me-indicate
<apw> seb128, that i have no idea about but i am not the only one it happened to
<apw> on dist-upgrade
<apw> smb, ^^ i think you had this same thing
<seb128> there were some issues, but lightdm was only recommending the greeter not depending on it
<seb128> we fixed that yesterday
<seb128> well if that's still an issue talk to mvo about how apt can ignore a depends
<seb128> that seems a bug in apt
<smb> apw, PRobably because the desktop task brought it
<apw> seb128, ok will do
<smb> when I saw it happen, there was some lightdm-greeter.*example removed but not the real gretter installed
<apw> smb, same happend to me, was suppsoed to be fixed by the time i updated ... oddness
<seb128> that's what happened before we promoted the recommends to a depends yesterday
<smb> meh, which apw said already
<seb128> apw, do you use a mirror? is it uptodate?
<apw> seb128, interesting point.  i use gb.archive.com, but i am using ipv6 which i think points to somewhere in .se
<jpds> apw: gb.archive is IPv6 enabled.
<apw> jpds, its enabled yes, but by pointing it to another mirror
<apw> (as i understand things)
<jpds> apw: No, the machine has it's own address.
<jpds> its*
<jibel> seb128, indicator-me is what makes today's desktop image broken http://people.canonical.com/~ubuntu-archive/livefs-build-logs/oneiric/ubuntu/20110729.1/livecd-20110729.1-i386.out
<apw> The following packages have unmet dependencies:
<apw>  indicator-messages : Breaks: indicator-me but 0.2.92-0ubuntu1 is to be installed
<apw>  indicator-session : Breaks: indicator-me but 0.2.92-0ubuntu1 is to be installed
<apw> seb128, and those are indeed exactly the messages i get when installing the ubuntu-desktop^ task
<seb128> I think it's didrocks' fault
<seb128> didrocks, can you make unity2d-panel-service stop recommending indicator-me?
<didrocks> seb128: sure
<seb128> thanks
<seb128> well it's only a recommends not sure why it break anything
<seb128> jibel, apw: does it break if you --no-install-recommends?
<apw> i thought recommends always get installed
<seb128> apw, they do when available but they used to be ignored rather than break the install when not
<apw> seb128, had no effect on the ubuntu-desktop^ install
<didrocks> seb128: so, not my fault :)
<didrocks> still uploading without it
<seb128> didrocks, well I don't see who else
<seb128> nothing else recommends or depends on it in main
<apw> seb128, can i ask apt-cache somehow on my system ?
<seb128> apw, well aptitude should tell you what the issue is
<seb128> can you try with it?
<seb128> mvo, is there any way to ask apt why it tries to bring indicator-me in?
<didrocks> hum, Connection failed, aborting. Check your network [Errno 111] Connection refused
<didrocks> am I the only one having troubles to upload?
<mvo> seb128: yes, apt-get install -o Debug::pkgDepCache::AutoInstall=true
<seb128> apw, ^
<seb128> apw, can you try that?
<apw> and what am i looking for
<jykae> how does natty run on exopc? has anyone tried?
<seb128> apw, something which mentions indicator-me
<apw> nothing other that those other two lines above
<apw> seb128, are the Reverse Depends in apt-cache showpkg indicator-me the info we are looking for ?
<seb128> mvo, ^ help
<seb128> ;-)
<apw> it appears that the indicator-session i have installed depends on indicator-me
<apw> as does indicator-messages
<apw> as does indicator-me-gtk2
<apw> could it be that last one?
<seb128> apw, indicator-messages Breaks indicator-me
<seb128> it depends depends on it
<didrocks> (they replaces: it here)
<apw> seb128, right so i think the first two should resolve
<apw> seb128, but if indicator-me-gtk2 needs it and is installed what will uninstall that
<seb128> apw, uninstall indicator-me-gtk2
<seb128> that should not be required
<seb128> oneiric use gtk3
<apw> so this could be an upgrade problem then
<apw> but that would not affect the seeds and cd builds which also hit this
<seb128> well jibel said the daily iso build failed on the same error
<seb128> right
<apw> seb128, and purging -gtk2 didn't do any good
<seb128> we need mvo's help there
<seb128> can you pastebin a log of the apt command which has an issue with -o Debug::pkgDepCache::AutoInstall=true used?
<apw> seb128, http://paste.ubuntu.com/654491/
<apw>  sudo apt-get install -o Debug::pkgDepCache::AutoInstall=true ubuntu-desktop^
<seb128> do you have aptitude?
<seb128> could you try with aptitude?
<apw> i have aptitude installed now, but i am always told never to use it :)
<apw> and it doesn't understand ubuntu-desktop^
<ion> Whaat? aptitude is much better at problem resolution than apt-get.
<apw> but ... if you want something run, ask
<apw> well it doesn't know the task syntax it seems
<mvo> barry: hello! shouldn't UDD automatically commit my transmission sponsored upload from today?
<mvo> apw: apt-get install -o Debug::pkgProblemResolver=true -o Debug::pkgDepCache::AutoInstall=true usually gives a clue what is wrong â¦ sorry for being late to the party
<jibel> seb128, the only way it is installed it ubuntu-desktop depends on unity-2d depends on unity-2d-panel recommends indicator-me
<mvo> I'm chasing down a apt crasher that drives me nuts
<seb128> jibel, which didrocks uploaded a fix for
<jibel> right
<seb128> apw, wait an hour for the unity-2d update to be published
<seb128> but I can confirm the issue in a pbuilder
<apw> seb128, mvo, http://paste.ubuntu.com/654495/ with the extra debug options
<roadmr> Hey folks! I used to be able to preseed auto-login with d-i passwd/auto-login boolean true, but this seems to have changed in Oneiric, anyone know where I could find the new setting to use?
<apw> Broken indicator-messages:amd64 Breaks on indicator-me [ amd64 ] < none -> 0.2.92-0ubuntu1 > ( gnome )
<apw> does that line make sense with (gnome) at the end ?
<jibel> it is the section the package belongs to.
<mvo> eh, indicator-messages has a unversionized breaks, that does not make much sense
<mvo> that should probably be a conflicts instead
<mvo> whats up with indicator-me, should it go away?
<mvo> apw, seb128: I can prepare a new version with the fix, lets see
<seb128> mvo, yes, I think it should be a c,r,p
<bigon> -Werror=unused-but-set-variable << euh? is oneiric gcc failing with these now?
<seb128> mvo, I told so to kenvandine a week ago, not sure what happened with that
<seb128> mvo, I think he pinged you about it but by the time you reply he was not around and that got dropped on the floor
<seb128> mvo, basically indicator-me is merged in indicator-session
<kenvandine> i think i fixed it
<seb128> kenvandine, current oneiric is still a Breaks, not a Conflicts,Replaces,Provides
<seb128> $ apt-cache show indicator-session | grep Breaks
<seb128> Breaks: indicator-me
<seb128> $
<mvo> I just uploaded a fix, will commit now
<seb128> mvo, thanks
<mvo> quick bzr, quick
<mvo> yw
<mvo> now back to the segfault
<seb128> mvo, sorry for the distraction, thanks for fixing it ;-)
<kenvandine> mvo, oh... you said i didn't need to change that
<kenvandine> dist-upgrade did the right thing, it just wasn't something update-manager was designed for
<seb128> kenvandine, no, he said that update-manager updates never uninstall things
<kenvandine> right
<seb128> kenvandine, still unversionned Breaks confuse the partial upgrade resolver
<seb128> when Conflicts,Replaces,Provides help it
<kenvandine> dist-upgrade did the right thing...
<seb128> it tells it "that one is a solution to this one being uninstalled"
<seb128> kenvandine, well, the resolver takes lot of parameters in account
<seb128> kenvandine, like some people here had indicator-me-gtk2 still installed which put extra score in the "keep indicator-me installed"
<kenvandine> ugh
<kenvandine> ok
<seb128> kenvandine, when it scores enough apt might decide to hold the update
<mvo> kenvandine: sorry, maybe I misread it then, usually a breaks without a version indicates that something is not quite right. breaks really just means "the two can not be configured together". but conflicts "the two can not be on disk together". most of the time a breaks is transitional in some way whereas a conflict it permanent. does that make sense?
<kenvandine> yeah
<seb128> kenvandine, that's why the replaces,provides is useful, it tells the resolver that this upgrade is a solution
<kenvandine> that makes sense
<mvo> seb128: I would go one step further and say that a breaks without a version does not make too much sense semantically too
<mvo> its really useful to help avoiding churn during a upgrade, no need to remove a version first, then install a later version with the breaks we can just unconfigure it and the n upgrade without the need to remove all the on-disk files
<ion> Here aptitude wants to remove indicator-me-gtk2 when upgrading unity-2d, resulting in gwibber getting removed, and it says indicator-me is recommended, but it canât be installed due to indicator-{messages,session} having Breaks on it.
<geser> ion: see scroll-back, the indicator-me issue was just discussed
<kenvandine> it should be wanting to remove libgwibber1
<kenvandine> well, it shouldn't actually
<ion> geser: Yes, i simply described my symptoms in case they were useful for someone, knowing theyâre probably just redundant. :-)
<geser> ah
<ion> To clarify, indicator-me-gtk2 is being removed because itâs automatically installed and nothing depends on it anymore.
<hevauq> hi all, how can one interface between a daemon and any user utility?
<ion> With dbus
<hevauq> um, no i am writing a custome daemon
<hevauq> its a networing daemon, it service remote connection with sockets. but i am wondering how can it service local requiests?
<hevauq> i am not making anything complicated, just trying to provide basic functionality
<hallyn> hevauq: are you saying you want local requests to be treated differently from remote ones?
<hallyn> (else I don't see the problem)
<hevauq> well, i dont care. But i have no idea what is generally done.
<hevauq> does most daemon service local requests over sockets?
<hallyn> hevauq: yes, though i suppose the local clients usually connect to 127.0.0.1 instead of the eth0 ip
<hevauq> ok, actually its not the same socket family so IP address is irrelvant. command_Line(connect_to_remote)-->daemon(over_socket)--->distant_daemon(do_stuff)-->daemon(send data)-->command)_line.
<hevauq> command_line can send multiple command to daemon
<barry> huh.  screensaver seems overly aggressive today
<Laney> raargh i'm a screensaver aaaaargh brainsss
<barry> :)
<slangasek> didrocks: hrm, luk wasn't at DebConf and I no longer am; it would be better if someone else could look into bug #817962
<ubottu> Launchpad bug 817962 in cifs-utils (Ubuntu Oneiric) "cifs-utils now recommends winbind, being an extra 3+ MB on the cd" [High,New] https://launchpad.net/bugs/817962
<slangasek> mvo: 809980 was a one-time crash for me
<didrocks> slangasek: do you see anyone in the foundation team having that knowledge (samba essentially, it seems)? If not, I can have a look
<jml> jelmer might be able & willing to help
<didrocks> jelmer: interested to have a look? ^ :)
<jml> how can I get gpg to forget my key password?
<micahg> mdeslaur: can you sponsor the libjpeg8 fix for me as soon as it finishes test building?
<mvo> thanks slangasek
<mdeslaur> micahg: yes
<jelmer> didrocks: looking
<slangasek> didrocks: I don't think anyone is going to have existing familiarity with a new upcall interface; a samba expert will have only a moderate head start on figuring out the bug :)
<micahg> mdeslaur: bug 818132
<ubottu> Launchpad bug 818132 in libjpeg8 (Ubuntu) "libjpeg8 shouldn't provide libjpeg-dev yet" [High,Confirmed] https://launchpad.net/bugs/818132
<didrocks> slangasek: ok, thanks for the info, I'll try to ping luk if jelmer has no idea on this and then dogfooding :)
<Daviey> Would an AA be able to promote ipxe please, bug #800340 .. it's causing upset. Thanks :)
<ubottu> Launchpad bug 800340 in ipxe (Ubuntu) "[MIR] ipxe" [Undecided,In progress] https://launchpad.net/bugs/800340
<mdeslaur> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<mdeslaur> micahg: uploaded
<micahg> mdeslaur: thanks!
<jelmer> didrocks, slangasek: I think it would be reasonable to drop winbind to Suggests; it's not necessary for normal operation and requires extra configuration (both of winbind itself, and in key.conf)
<didrocks> jelmer: thanks for the analysis. Seems safe enough to do that for now, maybe envisionning a package split later if we see that some part can be extruded in a separate bin package. :)
<hallyn> think i'll try to get vimprobable and vimprobable2 packages into universe next week...
<hallyn> hmm, it's *possible* that I'm somehow to blame, but it seems like on an oneiric-virtual kernel, I can't do "sleep 60 & gdb -x gdb.commands -p $!"  (even setting yama ptrace_scope to 0).  It just hangs
<hallyn> it works on my laptop though, with oneiric-generic kernel
 * hallyn tries a new ec2 instance
<hallyn> hm, seems to only happen on this one instance.
<hallyn> clearly i've done *something*
<nikitis> Who do I talk to about making my Ubuntu installer for Playstation 3 PPC?
<nikitis> Anyone?
<cjwatson> nikitis: hmm, we decommissioned it because (a) the hardware manufacturer is clearly aggressively against it and so there are fewer and fewer examples of hardware that could actually run it, (b) there were no interested developers
<cjwatson> I think most of the code should still be in place, so it should just be a matter of building CD images
<nikitis> cjwatson: time to start it up again.  Linux is back on PS3.
<nikitis> i've already written an installer
<cjwatson> why write a new one rather than use the existing one? :-)
<nikitis> existing one doesn't work with new methods
<nikitis> was designed for Older NAND Playstation 3's
<nikitis> New otheros runs on Slims and Old Playstation 3's
<nikitis> difference in hardware etc
<cjwatson> to get installer code into Ubuntu, it should be a modification of the existing installer, rather than an entire new one
<cjwatson> we have lots of framework stuff for supporting a variety of architectures and such, so it shouldn't be necessary to reinvent the whole thing
<nikitis> Well I already have
<nikitis> work is done
<nikitis> maybe some polish
<cjwatson> I know, but it isn't going to be accepted into Ubuntu that way
<cjwatson> (though of course you can do whatever you like separately)
<nikitis> i'm just curious though
<cjwatson> it shouldn't be too hard to extract the small architecture-specific part and integrate it into d-di?
<cjwatson> er, d-i
<Chipzz> cjwatson: well he didn't say he started from scratch :)
<nikitis> would it be hard to compile packages for ppc for 11.04
<cjwatson> we already do
<cjwatson> powerpc (the architecture as opposed to the PS3 subarchitecture) has never gone away
<nikitis> can we debootstrap to it?
<cjwatson> sure
<cjwatson> debootstrap should even pick the ports mirror automatically
<nikitis> well currently my installer debootstraps 10.04 Lucid
<nikitis> i didn't know all packages were compiled for ppc 11.04 already
<cjwatson> and oneiric too
<cjwatson> lucid even still had powerpc+ps3 images, though I'm not sure they worked right
<nikitis> Well i can tell you, Fedora has already accepted our installers.  And will be making version Fedora 16 with it.  I don't want to leave Ubuntu out of it.
<cjwatson> (http://cdimage.ubuntu.com/ports/releases/lucid/release/)
<cjwatson> the architecture-specific bits of an installer are really pretty small - it should mostly just be a boot loader installer and a bit of image boot stuff
<nikitis> no the old cd images don't work with new otheros method on PS3
<nikitis> at least not yet
<nikitis> a driver is currently being written though
<nikitis> for the blu-ray drive
<cjwatson> so it shouldn't be too hard to extract - you'd mostly be replacing kboot-installer
<cjwatson> I expect
<nikitis> once written the cd images may work
<cjwatson> patches for that would be welcome
<cjwatson> (anyway, I have to go, dinnertime)
<Chipzz> bon appetite!
<nikitis> But for now the only way for ubuntu to install on Playstation 3's legally is via scripting either via wget, or usb stick
<nikitis> Trying not to use sony blu-ray code as that would be illegal
<nikitis> If ubuntu won't accept PPC in future builds I'm afraid they will get left behind
<directhex> nikitis, it's already got ppc builds, as you've been told.
<nikitis> Where are the natty?
<directhex> there are two powerpc build servers, adare and ross, currently doing builds
<directhex> nikitis, on ports.ubuntu.com?
<nikitis> do i change debootstrap info from lucid to natty?
<infinity> All the packages are built for every release for PPC.  We just don't have PS3-specific ISOs built for recent releases, that's all.  But, as Colin said, if you have fixes to make our current generic powerpc ISOs work with PS3, we'd love patches.
<infinity> nikitis: Yeah, just debootstrap whatever release you want.
<nikitis> hmm okay
<infinity> (I run natty on my PowerStation with no issues)
<infinity> Though, ironically, that needs some installer/ISO fixes too.  I need some round tuits to fix that.
<nikitis> Well that's what i'm here to talk about, I want to know about checklists, for requirements to make it an official installer
<infinity> nikitis: Like Colin said, we don't tend to accept new "installers", per se, we just need fixes to our existing ones.
<nikitis> Current ISO's will NOT work nor will they ever on Current PS3 state.  It needs a new build from scratch.
<nikitis> New drivers have been completely rewritten, the method and times at which things get installed is different
<infinity> nikitis: So, if there are changes needed to debian-cd to make the ISOs bootable on PS3, that's checklist 1, if there are changes required to debian-installer components to actually make the installed system bootable, that needs doing, etc.
<nikitis> I've written a debian installer already
<nikitis> I wrote that one first
<directhex> nikitis, if it wasn't clear: a completely from-scratch installer, not based on ubiquity or debian-installer, will never ever ever ever be accepted into ubuntu
<infinity> I'm referring to the debian-installer project, not just "an installer for Debian".
<nikitis> yeah but this is gonna require a new project
<directhex> nikitis, the design of those two installers is extensible, and adaptable to any architecture.
<infinity> I don't see why it should need a new project.
<nikitis> That's because you don't see how different it is
<barry> ScottK: in python-defaults, do we still need to suggest python-profiler?
<Chipzz> nikitis: debian and ubuntu do not want to maintain to seperate codebases for installing things
<Chipzz> or should I say 3? :)
<infinity> Installation is always the same general idea:  Boot system, determine installation target, install junk, figure out how to make system bootable.
<ScottK> barry: No
<barry> ScottK: cool, didn't think so.  i'll drop that delta
<infinity> nikitis: Trust me, I have some idea. :P
<Chipzz> (if you count ubiquity, which I think is based on debian-installer anwyay)
<nikitis> Well eventually you could add it to alternate cd
<infinity> Chipzz: Just one, really, since ubiquity and oem-installer re-use d-i heavily.
<nikitis> it's not big
<Chipzz> infinity: that's what I just said :)
<nikitis> few kb's
<infinity> nikitis: Well, what does your installer do, precisely?
<nikitis> it basicaly emulates a manual install atm
<infinity> nikitis: Perhaps we're talking past each other, and what you've done it work that can easily be rolled into d-i.
<Chipzz> nikitis: it's still different codepaths that need be tested seperately
<nikitis> but automates it
<nikitis> But
<infinity> s/it work/is work/
<directhex> "manual install"?
<nikitis> there are quirks like how the PS3 harddrive regions are setup.  There is no /dev/sda or sdx for that matter
<infinity> nikitis: That's fine.
<nikitis> stuff that the normal installer will not work or detect properly
<infinity> nikitis: No two architectures are the same in that regard.
<directhex> i've a co-worker who might be more forthcoming with info on this
 * directhex pokes kakaroto
<infinity> nikitis: Like I said, trust me when I say that we can deal with this in d-i.
<Chipzz> nikitis: maybe you should elaborate a little on how your installer works; is it a patched debian-installer, is it debian-installer preseeded with values, or is it your own home-rolled script?
<Chipzz> or d) sth else
<nikitis> home-rolled
<nikitis> but functional
<nikitis> it will install onto a PS3
<nikitis> and i'm adding to it
<nikitis> still wip
<nikitis> but since it works now
<nikitis> i was curious about the process of implementing it
<Chipzz> nikitis: I think the partitioner from debian-installer is extensible in that regard
<infinity> nikitis: Well, if you've covered the important bits (storage detection and bootloader setup, basically), that would be a good time to see if we can re-factor it into d-i.
<Chipzz> you can probably adapt it to work correctly
<nikitis> I use parted in my installer
<Chipzz> so does the debian-installer I believe
<directhex> nikitis, you're still not describing anything d-i can't do out of the box.
<directhex> or doesn't already do by default out of the box
<nikitis> you'd have to modify debian installer for text only install.  no plymouth no splash
<Chipzz> nikitis: it might be a simple matter of teaching the partition component of debian-installer about /dev/whateverps3uses
<infinity> nikitis: That's fine, some architectures do that already too.
<nikitis>  /dev/ps3dd
<directhex> nikitis, d-i already does text based and serial console based install. i still don't see an issue
<nikitis> i guess right now it's just lack of cd support
<directhex> the same installer code works on ultrasparcs and itaniums and amd64 desktops. you bet your ass it's extensible
<nikitis> must run in /bin/ash
<infinity> And that's where debian-cd comes in.
<nikitis> at least until it debootstraps
<Chipzz> nikitis: requiring /bin/ash can probably be fixed
<nikitis> Older NAND PS3's cannot handle /bin/bash
<nikitis> though newer slims can
<directhex> doesn't the installer use busybox?
<Chipzz> that sounds unlikely
<Chipzz> (wrt not supporting bash)
<nikitis> Chipzz: it's true because the image for nands has to be smaller and cannot fit
<nikitis> it's a size issue,
<Chipzz> nikitis: you shouldn't be using bash anyway, you should use dash
<Chipzz> or busybox for the initramfs
<nikitis> it is busybox
<nikitis> modified
<infinity> None of this matters from a d-i perspective.
<nikitis> well maybe
<infinity> The whole point of d-i is to boot into a functional system and install from there, we don't run d-i from flash, that would be insanity.
<nikitis> but we still need blu-ray support before d-i can be used
<nikitis> that could be awhile
<nikitis> at the moment my installer is the only thing that will do it
<infinity> By "blu-ray support", do you mean "support for blu-ray discs", or "support for the drive"?
<nikitis> support for the drie
<nikitis> drive*
<infinity> Didn't we once have support for that?
<infinity> I mean, we had ISOs that people claimed worked...
<nikitis> For nands
<nikitis> Older PS3's
<nikitis> but sony wrote the drivers to accept those discs
<nikitis> in otheross.bld
<nikitis> our otheros build is different and written from scratch
<barry> ScottK: http://pastebin.ubuntu.com/654650/
<infinity> So, we're not really talking about installers here at all (or shouldn't be, just yet)
<nikitis> we already have more drivers written than were provided by Sony with their otheros.
<infinity> The real trick is making our ISOs bootable.
<nikitis> we'd have to add the drivers to the installers
<infinity> By "drivers", you mean kernel drivers, or bizarre userspace glue?
<nikitis> kernel
<nikitis> we have more access to PS3 now than ever
<infinity> If there are kernel drivers available here, and they're free software, we won't say no to getting them in our kernel, I imagine.
<nikitis> syscon drivers
<infinity> (Although, why aren't they being upstreamed?)
<ScottK> barry: Seems sane
<nikitis> these are released yet
<barry> ScottK: cool.  local build looked good, so i think i'll upload it :)
<nikitis> and currently our kernel works with ubuntu, we have a separate kernel as well
<nikitis> i'm sure things could be ported into ubuntu official kernel
<Chipzz> infinity: legal issues might be a good bet ;P
<nikitis> but as of now my installer compiles live on the PS3
<infinity> nikitis: Releasing the drivers would be the best first step, yes.  And getting them integrated for oneiric.
<nikitis> not my kernel though, another guys
<nikitis> but he's given me permisison
<nikitis> Okay well i have a good idea about what needs to be done to move forward
<nikitis> When we finish disc drive drivers for new otheros.  I'll come back and start working on d-i ports
<infinity> That would be lovely.
<infinity> With no kernel, there's not a whole lot we can do.
<nikitis> we get full SPU access too now.  Different from old PS3 linux
<nikitis> Full RSX
<infinity> If I had some free time, I'd work with you on integrating your non-upstream kernel with d-i in preparation for it being released, but I'm not sure that's something I can commit to just yet.
<infinity> That said, feel free to email me and keep me in the loop (adconrad@ubuntu.com)
<nikitis> well no need atm
<nikitis> There is a workign installer
<nikitis> released by myself.  Even if it's not accepted by the community
<nikitis> may not be too hard to port over officially later
<nikitis> Thanks for you time guys
<Chipzz> nikitis: you also might want to join #debian-boot on irc.debian.org if you want to discuss integrating your installer into debian-installer
<barry> ScottK: also, i think python-qt4 svn is ready for review
<johan> Hi, sorry if this is not the right place to ask but I'm having trouble getting update-manager to install a .deb of mine which Provides/Replaces/Breaks another one
<ScottK> barry: I've been looking at it.  I was to do sip4 at the same time, so figuring that out first.
<barry> ScottK: cool
<superm1> apw, since you're not subscribed to 812979, just wanted to make sure you saw that this is actually fixed in the latest version, just waiting for an archive admin to wack 811231
<tilgovi> can anyone help me out with sbuild? it seems to completely fail for me on natty.
<tumbleweed> tilgovi: how about providing some pastebinned errors :)
<tilgovi> tumbleweed: one sec. I may have realized my stupidity. looks like I need both the .orig.tar.gz and the .dsc
<tumbleweed> and the .debian.tar.gz / diff.gz :)
<tilgovi> thanks!
<tumbleweed> dget / pull-lp-source / apt-get source knows what to do
<tilgovi> tumbleweed: can I use that to pull a specific series? I'm trying to roll my own backport.
<broder> tilgovi: have you looked at backportpackage in ubuntu-dev-tools?
<tumbleweed> tilgovi: pull-lp-source is the easiest for that. Also, there's a toolk called backportpackage in ubuntu-dev-tools
<tilgovi> broder: no, didn't know it existed. thanks.
<tilgovi> can it leverage sbuild for lvm snapshots, too?
<tumbleweed> tilgovi: yes, it can use sbuild
<broder> tilgovi: look at the --builder (-B) option
<tilgovi> you're all awesome.
<cody-somerville> soren, Hi. Currently the openstack-ubuntu-packagers team is subscribed to the lp:~openstack-ubuntu-packagers/glance/ubuntu branch. The MOTU team is a member of the openstack-ubuntu-packagers team which means that all MOTU get e-mails regarding merge proposals and the like. Is there a better team that could be subscribed for these things?
 * tumbleweed can't say I've seen those mails
 * ScottK neither.
<cody-somerville> You didn't get '[Merge] lp:~antonym/glance/add-xattr into lp:~openstack-ubuntu-packagers/glance/ubuntu' about 20 minutes ago?
<tumbleweed> cody-somerville: nope
<MrNthDegree> hey guys, is there an easy way to enable install of all debug symbols for all packages?
<MrNthDegree> (as in for all installed packages and when I install new packages)
<stgraber> cody-somerville: I have membership in that team through DMB and Ubuntu Server Dev. So I guess you need to be part of one of these two.
<MrNthDegree> the reason I ask is because it's a pain to wait on downloading specific debug packages whenever I need to submit a backtraced bugreport
<cody-somerville> right
<cody-somerville> MOTU team has contact address set
<cody-somerville> so its probably one of my other routes of membership in that team like DMB that causes me to get the e-mails
<stgraber> cody-somerville: ah, nevermind, LP was lying :) I get different data on https://launchpad.net/~stgraber/+participation and on https://launchpad.net/~openstack-ubuntu-packagers apparently :)
<stgraber> but yeah, I receive these e-mails too and it's starting to be a bit annoying :)
<Laney> X-Launchpad-Message-Rationale: Reviewer @openstack-ubuntu-packagers
<micahg_> barry: are you planning on merging python 2.6.7-3 from Debian?  python-all in the archive is broke w/out it
<micahg_> barry: otherwise, can the dependency be relaxed to 2.6.7-2? (I don't know what impact that will have)
<micahg_> doko: you wouldn't happen to be around, would you ^^
<barry> micahg_: oops!  i'll relax that dependency for now and leave it for doko to  merge -3 next week
<micahg> barry: great, thanks!
<micahg> doko: unping
<micahg> barry: your upload had no diff aside from the changelog (forgot the .in file?)
<fhd> Hi. I'm setting up a system for Ubuntu development, so I installed the latest daily build of oneiric. There is for some reason no /etc/X11/xorg.conf - how can I add more resolutions?
<hallyn> fhd: check on #ubuntu-desktop I think
<fhd> hallyn: k, thanks
<soren> cody-somerville: Not really. It's implicitly subscribed on account of being the review team for the branches. We could remove ~motu from the team, though, but since all of ~motu can, so far, upload the packages, I think they should be members of the team.
 * soren has to run
<stgraber> soren: if you set a team contact address for that team, all these e-mails will go to it instead of being sent to everyone individually
<stgraber> soren: this way, you keep the same rights but don't spam everyone with upload rights ;)
<kirkland> jcastro: ping
<kirkland> jcastro: isn't there a tool that you told me about some time that makes it trivial to just clone/forward a bug from Launchpad to Debian BTS?
<ScottK> I'm guessing barry left without hearing his fix didn't work.
 * ScottK will fix.
<ScottK> OK, let's see how that works out ...
<ScottK> micahg: Feel free to double check I fixed python-defaults correctly.
<micahg> ScottK: you just needed to lower the one that was 2.6.7-3 to fix the archive issue, but I think that's fine (I personally don't understand the deps), thanks!
 * micahg should probably learn how python packaging works at some point
<apw> superm1, thanks for the info ...
#ubuntu-devel 2011-07-30
<sgnb> can someone here retry atdgen and rebuild nurpawiki?
<yofel> cjwatson: a question about package sets: are those main-only or for universe too? If latter, can you add kdevelop-php and kdevelop-php-docs to the kubuntu one please?
<cjwatson> shouldn't those be in the Kubuntu seeds if the Kubuntu development community intends to support them?
<cjwatson> if you do that, then (a) they will be pulled into main, (b) they'll (mostly) automatically end up in your package set to
<cjwatson> I'd prefer not to add manual exceptions for things that can be done by seeding things, as it gets hard to maintain
<yofel> k, I'll talk to the others
<persia> yofel: /win 23
<yofel> :)
<persia> yofel: Err, rather, you might want to look at the implementation of the "supported" seed that appears in some seed collections.
<yofel> Saw it, we haven't quite decided what to do yet though, that does look like the way to go though
<lucidfox> Huh
<lucidfox> So the recent autosync overwrote even -XubuntuY packages?
<tumbleweed> yes
<lucidfox> Oh good grief
 * lucidfox goes to look through her packages that might have been damaged
<directhex> lucidfox, technology is awesome!
<directhex> Â¬_Â¬
<cjwatson> lucidfox: I think there was a list of those attached to the u-d-a mail
#ubuntu-devel 2011-07-31
<micahg> can someone give hplip back please?
<ajmitch> micahg: ok
<micahg> ajmitch: thanks
<mdke> Laney: thanks, I will play around with that and see if I can make it work
<mdke> Laney: sorry for the delay in responding, I haven't checked irc for a while
<DooMMasteR> hi there
<DooMMasteR> anyone keen to update the netatalk package to 2.2.0?
<DooMMasteR> it is still at version 2.1.4 which is nearly one year old
<DooMMasteR> and only 2.2.0 supports Mac OS X Lion
<infinity> DooMMasteR: oneiric is on 2.2~beta4.
<DooMMasteR> isn't 2.2.0 final?
<infinity> DooMMasteR: Getting older releases updated would require either decent backported patches for just the Lion support, or a well-thought-out bug with reasoning why we need to upgrade the a new upstream.
<infinity> DooMMasteR: I'm sure oneiric will get the final release soon enough.
<DooMMasteR> hmm ok
<DooMMasteR> atm TimeMachine backups are not working to my Ubuntu server
<DooMMasteR> and so I will porbably have to make my own build of 2.2.0
<DooMMasteR> thx for the info infinity
<mdke> Laney: I added something to revision 11 in bzr lp:ubuntu-docs but it doesn't seem to be working. Not sure why - will play around a bit more later but any pointer you can give would be much appreciated
<Laney> mdke: think it needs to be in preinst actually, testing
<Laney> â¥ lintian lab
<Laney> mdke: try this http://paste.debian.net/124690/
<micahg> can someone give back libxml2 please?
<ajmitch> micahg: looks like it's done already
<micahg> ajmitch: thanks for trying :)
<stgraber> yep, I did it
<micahg> thanks stgraber
#ubuntu-devel 2012-07-23
<psusi> lifeless, I thought that rsync could deal with bytes being inserted or removed and shifting the position of the remaining bytes in the file, so you just needed to reset the encoder periodically without regard to the exact position in the output?
<psusi> looking at the patch though, it seems to be trying to compute the rsync rolling checksum of the data and flushing only when it hits a particular value... which makes no sense to me whatsoever
<pitti> Good morning
<ion> morning
<jk-> any upstart-o-nauts able to help with http://askubuntu.com/questions/162319/how-do-i-stop-all-processes-in-a-chroot ?
<infinity> jk-: Answered.
<jk-> the service in this restaurant is fantastic!
<infinity> jk-: I cheated.  I cargo-culted from launchpad-buildd, with the theory that "if it's good enough for thousands of builds in a day during a test rebuild run, it's probably good enough for Jeremy's PC".
<hrw> morning
<hrw> can someone review patch in bug 824708?
<ubottu> Launchpad bug 824708 in aptitude (Ubuntu) "aptitude can no longer show changelogs: "Changelog download failed: Download queue destroyed." Please merge the fixed version, 0.6.8, from Debian." [Medium,Triaged] https://launchpad.net/bugs/824708
<jokerdino> seb128: i reported bug #1027584 earlier. please do take a look?
<ubottu> Launchpad bug 1027584 in gedit (Ubuntu) "Quicklist action for creating new document is incorrect" [Undecided,In progress] https://launchpad.net/bugs/1027584
<seb128> jokerdino, hey, thanks, I've added it to my todolist, I can confirm the issue
<jokerdino> thanks much! i am not sure if we still have this bug in 12.04?
<jokerdino> anyway, i be right back. just wanted to attract some attention to the bug.
<seb128> jokerdino, it might be worth fixing in precise as well yes
<Laney> easy fix, i just did it
<seb128> Laney, for precise?
<Laney> just sending upstream
<Laney> you think it's worth SRU on its own?
<seb128> Laney, it's probably not but good to include if we get to do a gedit upload for something else
<Laney> ok
<Laney> do we have a staging area for SRUs?
<seb128> Laney, not really, I create ~ubuntu-desktop/source/precise vcs-es on the way as needed
<seb128> Laney, we should probably do that for gedit
<Laney> just as long as there is somewhere people will look
<seb128> well nominate the bug for precise, that might help to spot it when somebody look at doing a SRU ;-)
<Laney> is the sponsor queue really at 18?!?!?!?
<jokerdino> hey Laney, as you are at it, may be reassign the bug to yourself? thanks!
<Laney> jokerdino: feel free to do it
<Laney> or just unassign since it's done
<jokerdino> alrgiht. doing.
<jokerdino> Laney: done. thanks.
<seb128> Laney, shame it happens while dholbach is on holidays ;-)
<Laney> heh
<Laney> suspicious, eh?
<jokerdino> so, he is not in holidays after all ;-)
<jokerdino> probably remotely checking in the review queue
<Laney> nah, he's travelling to every developer individually to force them to do reviews
<jokerdino> that probably is what is happening.
 * coolbhavi just sponsored a sync on the review queue
<tumbleweed> or maybe everyone just gave up on ever getting sponsored? :)
 * tumbleweed can't say he noticed a massive amount of sponsoring in -changes, but I don't read it *that* carefully...
<tumbleweed> (clearly)
<Laney> well, if you look at the graph there's a big drop
<Laney> maybe it's a bug :P
<tumbleweed> https://bugs.launchpad.net/~ubuntu-sponsors is fairly short
<tumbleweed> dammit, we need the hall of fame, so we know who to applaud
<Laney> maybe it was rejected merge proposals
<coolbhavi> tumbleweed, IIRC few days back queue was around 80 now its the reverse i.e 18 :)
<jokerdino> oh wait. is that why one of my proposed branches is in limbo?
<jokerdino> i mean, i think i forgot to subscribe the sponsors
<Laney> you don't need to do that for branches
<Laney> if they're targetted correctly
<tumbleweed> if it's in limbo, it was put there manually
<jokerdino> bug #937334 it is.
<ubottu> Launchpad bug 937334 in Unity "Unity shortcut overlay needs to include shortcut for video lens" [Low,In progress] https://launchpad.net/bugs/937334
<Laney> is it on http://reports.qa.ubuntu.com/reports/sponsoring/index.html ?
<Laney> oh, that is for unity not the distro
<Laney> ask them :P
<tumbleweed> that's targetted at lp:unity
<jokerdino> hmm this stuff is confusing ;/
<jokerdino> earlier, i proposed a branch against lp:gedit and asked to go away ;p
<Laney> you can think of unity as an upstream project which is hosted on launchpad
<tumbleweed> gedit isn't a LP projet
<Laney> gedit is not, it is hosted on git.gnome.org
<Laney> the ubuntu sponsors are for uploads to the ubuntu archive
<jokerdino> well yes. i figured it out over time.
<jokerdino> now that the gedit bug is fixed, i should get back to nagging the unity devs to fix that other bug :P
<mterry> pitti, update-manager finally succeeded in jenkins!  yay  :)
<pitti> mterry: indeed, thanks for fixing it! I uploaded your branch this morning
<pitti> mterry: u-release-upgrader has a real issue, though
<mterry> pitti, yeah, was about to mention that
<mterry> pitti, I think the failure is "error from httplib: '<urlopen error [Errno 110] Connection timed out>'" when connecting to de.archive.ubuntu.com.  But I'm not sure why that would be true
<pitti> jibel: ^ could it be because the jenkins environment can't access that?
<pitti> only hosts in the DC perhaps?
<jibel> pitti, ah, probably true. Will the test still be valid if the address is changed to archive.ubuntu.com or us.archive.ubuntu.com ?
<pitti> I think archive.u.c. is the fallback if a mirror doesn't respoind
<pitti> respond
<pitti> we'd need a mirror within the DC
<mvo> mterry: \o/
<pitti> if us.archive is reachable, that ought to work
<jibel> pitti, the machine has access to archive.ubuntu.com
<pitti> yes, that part works
<pitti> mterry: is there a separate test for correct fallback if a mirror isn't reachable?
<pitti> if not, this test could perhaps turn into that :0
<mterry> pitti, let me see
<mterry> :)
<xnox> pitti: mterry: i recall cjwatson was struggling with that test as well....
<xnox> it was doing something special which mvo should know about?! =)
<xnox> s/struggling/trying to understand what is it testing, how and why/
<mterry> pitti, there is a test against archive.u.c, and then an identical test for de.archive.u.c to test mirror support
<pitti> mterry: i. e. it could perhaps test with a mirror ubuntu.example.org and verify that it falls back to archive.u.c.
<mterry> Yeah, I don't see one that tests fallback
<pitti> mterry: of course testing with a working mirror would also be nice, but the test could check if the mirror works and skip itself if not?
<pitti> mterry: test with archive.canonical.com ?
<pitti> mterry: no, ignore me
<pitti> mterry: so perhaps try with us.archive, as jibel said that might work
<mterry> pitti, so at a minimum, this test should catch this timeout exception and skip the test gracefully if encountered.   But it might as well also be run against us.archive I guess, if that's available, so we get the benefit of the test
 * mterry whips up a patch
<pitti> mterry: cheers!
<jibel> mterry, I confirm the machine has access to us.a.u.c
<mterry> jibel, awesome, thanks
<smoser> jodh, around?
<jodh> smoser: yes!
<smoser> mountall question
<smoser> i'm under the impression that mountall kind of determines mount dependencies and then does them non-serially
<smoser> is that correct?
<smoser> and probably figures out that it has to mount /var/lib after /var ... and such like that.
<smoser> is that true? (because the rest of my thoughts have no point if its not)
<jodh> smoser: it orders the mounts by type - see http://upstart.ubuntu.com/cookbook/#mountall-event-summary. Just double-checking how clever it is...
<stgraber> mountall knows about the relationship between mount points, yes (that /var is the parent of /var/lib for example)
<stgraber> I'm not sure how clever it's about the ordering though
<smoser> i was then wondering how mountall would handle an overlayfs mount.
<stgraber> I believe it'd fail
<smoser> where the lowerdir=/root/home,upperdir=/home
<stgraber> as I added logic to mountall to never mount a filesystem that'd hide another one mounted at an upper level
<smoser> it'd have ot know that 'uppperdir=/home' would have to block on /home
<smoser> hm..
<smoser> i'll try to write a fstab to show what i'm thinking
<tkamppeter> Anyone knows how to make pbuilder not delete the build directory after building? I want to look into config.log.
<mterry> tkamppeter, you could log into the chroot and build there?  I don't happen to know a switch to save the build artifacts.
<mterry> cjwatson, didrocks: Could one of y'all reject the gigi source upload I made to quantal?  It's in NEW, but will not be needed after all.
<cjwatson> mterry: done
<mterry> cjwatson, thanks!
<didrocks> cjwatson had the trigger under his finger it seems :)
<ogra_> cyphermox, poke
<tumbleweed> tkamppeter: do something like /usr/share/doc/pbuilder/examples/C10shell but in a B hook
<cjwatson> tkamppeter: ln -s /usr/share/doc/pbuilder/examples/C10shell /etc/pbuilder/hooks.d/
<cjwatson> and then it'll give you a shell after every failed build
<cjwatson> (assuming this is a failed build, otherwise, what tumbleweed said)
<smoser> stgraber, what does "never mount a filesystem that'd hide another one mounted at an upper level" mean ?
<jamespage> anyone know whether quantal will ship eglibc 2.16? or are we sticking with 2.15?
<cjwatson> jamespage: ask infinity when he's around
<jamespage> cjwatson, ack
<stgraber> smoser: if you have /mnt/test mounted before mountall runs, and have /mnt defined in /etc/fstab, mountall will skip /mnt as it'd hide the content of /mnt/test/
<smoser> ah. ok.
<smoser> stgraber, is there special handling of bind mounts?
<stgraber> not that I can remember of (has been a while since I last looked at the code)
<smoser> perhaps i could cheat here and use the fs_spec field (field 1) that is (I think) ignored by overlayfs
<smoser> but if mountall supports bind mounts, it clearly has to support paying attention to that field.
<smoser> otherwise binding /home into /another-home-location would be random
<jodh> smoser: mountall doesn't support the "bind" mount option option currently, but it does bind mount if "showthrough" is specified.
<sil2100> didrocks: hm, where is the nux precise branch located?
<smoser> jodh, ok. so to do this right i probably would have to add some overlayfs knowledge to mountall
<sil2100> didrocks: I mean, is there a special location like lp:ubuntu/nux for it?
<smoser> not tested, but i thinkm the fstab would look something like example at http://paste.ubuntu.com/1106554/
<sil2100> didrocks: or should I use the one from ~ubuntu-desktop ?
<smoser> given that example, i suspect that mountall doesn't know that line 12 depends  on line 10 and that line 11 depends on line 9
<didrocks> sil2100: lp:ubuntu/nux is trunk content, yeah
<didrocks> ah precise
<didrocks> sil2100: well, like all the other ones, for older branch, take ~ubuntu-desktop
<didrocks> and add a /precise one if there is not any
<jodh> smoser: yes, I think you're right. However, that example should actually work since mountall would run the mounts in order.
<smoser> why would it do them in order, jodh ?
<jodh> smoser: mountall reads its internal fstab and then /etc/fstab, adding each entry to a list. It then attempts to prune that list (removing already mounted entries, etc). But eventually -- and assuming no parent directory dependencies between entries -- it will run through the remaining list entries in order. Since your example doesn't have any directory/device dependencies between lines 9+11, 10+12, I think it should attempts the mounts
<jodh> in lines 9-12 inclusive in that order.
<smoser> jodh, ok. i'l work on that assumptio nthen.
<tkamppeter> mterry, did login with the directory containing the source package bind mounted, and found the missing build dependency by that. Thank you very much.
<mterry> tkamppeter, awesome  :)
<jodh> smoser: let me know how it does. I think mountall could do with a little more commentary, so I'll attempt to add that. Also, it would be pretty useful to be run it in --dry-run mode so you could see the ordering it has chosen. Feel free to raise a bug on that.
<jodh> smoser: ahem. how it *goes. :)
<seb128> cjwatson, hey, could you have a look to http://pastebin.ubuntu.com/1106596/ please?
<seb128> cjwatson, I'm a bit unsure about the postinst "clean empty dirs on upgrade" and the mainscript part so it would be nice if you could have a look for me before I upload
<seb128> cjwatson, basically bash_completion.d got moved from /etc to /usr
<cjwatson> seb128: would be nice to fix the syntax errors to start with ;)
<cjwatson> (you need spaces before ])
<seb128> cjwatson, ups, yes, I didn't test yet, I was more concerned about the idea, i.e is postinst the right place to do that?
<cjwatson> seb128: I haven't reviewed the whole diff in context or anything.  maintscript is generally fine, though you can drop the unnecessary "bash-completion" at the end of every line.  I think the postinst changes are fine; maybe discard errors?
<cjwatson> i.e. that'd be one of the cases where 2>/dev/null might be reasonable, since it isn't really an error if those directories are non-empty
<cjwatson> seb128: consider adding a version guard to the added postinst code, though
<seb128> right
<seb128> cjwatson, thanks, I will fix those and send to debian,upload to quantal (after another round of testing)
<cjwatson> ta
<jdstrand> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal A2 released! | Archive: open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: jdstrand
<mterry> pitti, do you know if someone is porting update-notifier to udisks2 from gdu?
<cjwatson> jamespage: tasksel is in bzr and has lots of automatic update scripts etc. - happy to help you if you need to change it in future
<jamespage> cjwatson, argh - sorry - did I break alot?
<cjwatson> I just had an upload conflict is all
<cjwatson> Resolving now
<jamespage> cjwatson, ack - not sure how I missed the VCS field - my bad
<cjwatson> Ah well
<cjwatson> The automatic update thing is that you can 'rm -r ubuntu-tasks; make ubuntu-tasks'
<cjwatson> Should never be necessary or desirable to edit files under ubuntu-tasks by hand
<cjwatson> And generally worth avoiding because if you do that it's susceptible to being overwritten by future changes (although that didn't happen here)
<jamespage> cjwatson, so the ubuntu-tasks are created from the seeds?
<cjwatson> jamespage: Yes
<cjwatson> That's the reason we have those Task-* fields in the seeds
<jamespage> cjwatson, right - I see
<cyphermox> ogra_: hey
<ogra_> cyphermox, you seem to be our bluetooth expert
<cyphermox> ahahah
 * ogra_ is struggling a bit trying to get that cool setup running you showed at UDS
<cyphermox> shoot ;)
<ogra_> i have a galaxy S2 and no idea what i need to do to debug the non working SMS stuff, i installed ofono and telepathy-ring ...
<cyphermox> telepathy-ring doesn't do the SMS, I think
<cyphermox> ogra_: but so far it sounds good
<ogra_> oh, i thought that was what you installed during your talk
<cyphermox> well it is
<cyphermox> but I only played with phone calls, not SMS
<ogra_> oh, indeed
<cyphermox> at this point in quantal SMS might work directly with ModemManager, too
<cyphermox> (using a 3g dongle, not a phone, though)
<ogra_> ah, well, i have my phone paired via BT indeed
<cyphermox> unless your phone can be tethered or uses BT DUN
<cyphermox> ok
<cyphermox> does ofono see your phone?
<ogra_> i also tried gnome-phone-manager and i cant see DUN with sdptool
<ogra_> Using device: /org/bluez/3806/hci0/dev_BC_85_1F_E1_F1_14, devaddr: BC:85:1F:E1:F1:14, adapter: 00:1B:DC:01:F0:4F
<ogra_> looks like
<cyphermox> awesome
<ogra_> BC:85:1F:E1:F1:14 is it
<cyphermox> is telepathy-ring saying it's connected? if it can't understand ofono or the phone, it will remain disconnected IIRC
<ogra_> how would i see that ?
<ogra_> all i get is a new tel and SMS protocol in the telepathy account dialog
<cyphermox> best way I found was to disable all the other accounts, or check in the accounts dialogs
<cyphermox> there's a slider thing for the account that would be on or off
<ogra_> well, which protocol should i use ? tel or sms ?
<ogra_> (neither seems to have any options)
<cyphermox> neither will have any options
<ogra_> well, selecting either of them gets me just a greyed out "accept" button
<cyphermox> you want to receive SMS so I'd use sms; can you try to send yourself one to see if ofono sees something, and if telepathy-ring sees it?
<ogra_> ah, no, tel doesnt but it gets me an immediate network failure message
<cyphermox> ok
<ogra_> sure
 * ogra_ goes to abuse mup on the other server ;)
<cyphermox> telepathy-ring is kind of really broken, I had a hard time starting it in the right order with ofono
<cyphermox> and if the dbus API in ofono changed, it's probably even more broken now
<ogra_> hmm, nothing in ofono
<cyphermox> what about phone calls?
 * ogra_ tries to find his landline phone
<ogra_> nope, no reaction in ofono
 * ogra_ wonders if there is an issue with the default setup for HFP
<tkamppeter> tumbleweed, cjwatson, also thank you for your method, will try it in a later case.
<tumbleweed> tkamppeter: if you set up the C10shell hook now, you'll be pleasently suprised the next time a build fails, and you can debug it :)
<cyphermox> ogra_: there were no settings to change anywhere
<cyphermox> I could try this out later, but for now I really should keep modemmanager on to be able to work on NM and properly test my stuff :)
<ogra_> ok, i'll go on digging then
<cyphermox> oh boy, ofono is ancient
<ogra_> heh
<ogra_> well'i'm not even sure i would need it at all
<cyphermox> ok
<ogra_> the bad thing is that any search i did on google yet only returns UoA results
<ogra_> tons of them
<cyphermox> UoA?
<ogra_> err UfA
<ogra_> ubuntu for android :)
<cyphermox> oh
<cyphermox> well for SMS ModemManager is supposed to work, but I know it works really a lot better with 3G dongles than with phones
<cyphermox> or I just never figured out how to have it talk to my phone ;)
<ogra_> haha
<ogra_> so we have the same prob :)
<cyphermox> that said, they're still working hard on the SMS stuff
<ogra_> ogra@anubis:~$ sdptool browse BC:85:1F:E1:F1:14|grep SMS
<ogra_> Service Name: Android SMS
<cyphermox> whereas ofono should have good support already, but it's not any easier to make it work apparently
<ogra_> well, apparently there is something i should be able to access
<cyphermox> huh
<cyphermox> yeah
<ogra_> just not sure how
<cyphermox> ogra_: there is probably no app on linux that does this yet :)
<seb128> bug #1027665
<ubottu> Launchpad bug 1027665 in nautilus (Ubuntu) "nautilus assert failure: libgcc_s.so.1 must be installed for pthread_cancel to work" [Medium,Confirmed] https://launchpad.net/bugs/1027665
<seb128> does anyone if that's a gcc issue or what?
<cyphermox> ogra_: I can't even see that profile on http://developer.bluetooth.org/KnowledgeCenter/TechnologyOverview/Pages/Profiles.aspx
<ogra_> ah, seems i can force /dev/rfcomm0 to be used in gnome-phone-manager which results in a constant 30sec loop of password prompts on the phone
<infinity> seb128: Erm, how do they not have libgcc1 installed?
<seb128> infinity, libgcc1 1:4.7.1-5ubuntu1
<seb128> https://launchpadlibrarian.net/110939701/Dependencies.txt
<seb128> so not sure how they run into that issue
<ogra_> cyphermox, http://paste.ubuntu.com/1106745/ ist intresting that "Service Class ID List" and "Profile Descriptor List" are just empty
<ogra_> *it's
<ogra_> so it might either be new or something "special" :)
<cyphermox> yeah
<infinity> seb128: libgcc_s.so.1 appears to still have the right symbols for glibc to not be throwing that assertion...
<seb128> infinity, it's only one user and there were no recent gcc update so I'm not really concerned but the bug is weird
<infinity> seb128: Well, it was an amd64 user, but that codepath should only be hit when using linuxthreads, which seems fishy all by itself.
<seb128> infinity, slangasek, SRU team: what are the chances somebody can review unity's SRU today?
<infinity> seb128: I will.
<seb128> infinity, great, thank you!
<infinity> seb128: You can send me some d'Affinois and a nice Merlot as compensation.
<seb128> infinity, let's wait to see if you approve it first ;-)
<infinity> seb128: If I don't, I'm sure I'll still provide cheese-worthy feedback.
<seb128> infinity, I've no doubt about that!
<jibel> given his region I'd rather ask for a GÃ©romÃ© with a pinot-gris ;)
<infinity> jibel: His region still has d'Affinois a heck of a lot cheaper than I can get it here. :P
<infinity> And by "his region", I mean "mainland Europe", in this case.
<jibel> and Munster won't pass border control :P
<infinity> seb128: libnet-dns-perl should have been merged, not synced.
<infinity> seb128: Oh, hrm.  FSVO "merge" that means something entirely different.  Curious.
<infinity> seb128: Yeah, I take it back entirely, the libnet-dns-perl failure is an entirely new one, and seen on Debian as well.
<infinity> seb128: Hrm, the majority of that unity diff appears to have been someone building the source package in a non-UTF-8 locale (or somehow otherwise breaking the encoding of some changelogs).
 * mterry is looking at libnet-dns-perl ftbfs; let me know if someone else is too
<scientes> mterry, <infinity> seb128: libnet-dns-perl should have been merged, not synced.
 * scientes guesses gcc-4.7 issues
<mterry> scientes, thanks
<mterry> oh also I see looking back "Yeah, I take it back entirely, the libnet-dns-perl failure is an entirely new one, and seen on Debian as well."
<seb128> scientes, mterry: why should it be merged and not synced?
<seb128> infinity, ^
<mterry> seb128, I believe that opinion has been retracted
<seb128> ok, good ;-)
<seb128> the only diff it has was an year old issue that seems to be something like shouldn't apply to the current version
<infinity> seb128: Well, it was a testsuite failure due to buildd network access, and so it the current one, so I knee-jerked.  But the new failure is, well, new.
<infinity> s/so it/so is/
<seb128> infinity, how come those issues happen on Ubuntu and not Debian, I though the debian buildds had the same network limitations?
<infinity> seb128: No, most Debian buildds don't have network restrictions at all.
<infinity> seb128: And it *did* fail on plenty of Debian arches the same way.
<seb128> hum, k
<seb128> infinity, unity> can I blame launchpad?
<seb128> oh, no, local debdiff has the same issue
<seb128> -x is your friend :p
<infinity> seb128: Yeah, not LP's problem.  The upstream tarball is wrong.
<infinity> seb128: But I'm going to just la la la over it, I guess, unless someone wants to fix it with a 5.14.0.1
<seb128> hum, I like that lalala music ;-)
<infinity> seb128: 6.0.0 is fine, so it's not like someone broke the changelogs upstream.
<seb128> the changelog is autogenerated from bzr log
<infinity> (Well, someone might have broken the 5.x branch, I didn't check bzr)
<seb128> so I guess whoever rolled the tarball has a weird locale
<infinity> Ahh, so it's.. Yeah.
<infinity> Okay, that makes some sense.
<infinity> Especially if it was Åukasz ...
<seb128> he's the one ;-)
<infinity> People with funny characters in their names seem to often have weird locales. :P
<seb128> ;-)
<infinity> (If there's a script or something that's used to make dist, it might be nice to commit a LANG=C.UTF-8 to that, for consistency)
<seb128> right, I will check with the unity guys
<infinity> But I'll overlook it for now.
<seb128> thanks
<infinity> Just make a mental note that their next upstream release will probably have the same diff in reverse, so someone will have to explain it again. :P
<ScottK> filterdiff --no-weird-locale-diff
<ScottK> The U/I design work is done, just up to implementation now.
<jdstrand> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal A2 released! | Archive: open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<infinity> arges: Can you reupload your nss-pam-ldapd oneiric SRU without the autotools regen mess?
<infinity> arges: Actually, I guess I'll do that on your behalf. :P
<infinity> arges: Alright, re-uploaded with cruft removed, and also fixed versioning for your natty and oneiric uploads so that natty wasn't > oneiric.
<arges> infinity, hey just got back. sorry missed that
<arges> infinity, ok thanks
<infinity> arges: You might want to kill the natty MP, since I appear not to be able to. :P
<arges> infinity, not sure what you mean by natty MP
<infinity> arges: https://code.launchpad.net/~christopherarges/ubuntu/natty/nss-pam-ldapd/nss-pam-ldapd/+merge/115147
<infinity> arges: I can't commit to the branch (only the importer can), so I can't close the merge proposal.
<arges> infinity, ok. so mark the status of the merge to something eles?
<infinity> arges: But you should be able to.
<infinity> arges: merged would be fine.  Or some appropriate lie.  Whatever. ;)
<arges> infinity, ok gotcha.
<arges> infinity, done. thanks
<bdrung> bryceh: thanks for triaging so many vlc bugs
<seb128> bdrung, hey, speaking about vlc is there any plan to get 2.0.2 or .3 in precise?
<stgraber> mdz: TB meeting?
<bdrung> seb128: i plan to get a MRE for vlc and then upload 2.0.3 to precise
<seb128> great
<bryceh> bdrung, sure thing
<seb128> bdrung, not sure how easy the MRE will be to get but you can maybe try to update to 2.0.2 or 2.0.3 without it?
<bryceh> seb128, there's an SRU requesting it, but the diff from 2.0.1 to .2 is pretty big.  A provisional MRE seems the right way to go.
<bdrung> seb128: quote from bryceh: The 2.0.2 release has a large number of changes over 2.0.1 (the website says over 500 commits), although from the NEWS file it does sound like this is almost entirely bug fixes.
<Laney> the website doesn't give that impression
<bdrung> the commits to the 2.0.x branch are mostly bug fixes
<Laney> eg "Experimental support for BluRay discs"
<seb128> bdrung, bryceh: I don't know enough about vlc to know if it justify a MRE (process, testing, etc)
<Laney> or is that not the changes?
<Laney> ah, it is not, /me scrolls further down
<bdrung> their rules for commits in their maintanance branch seems to be more relaxed
<bryceh> Laney, http://www.videolan.org/vlc/releases/2.0.2.html says "2.0.2 fixes a couple of hundreds of bugs, and adds more than 500 commits on top of 2.0.1."  I didn't verify that count but it looks likely
<seb128> bdrung, usually the SRU team will be wanting to get a track of some successful SRUs to grant a MRE
<Laney> Sounds like it'll be a tough sell :-)
<bryceh> bug 1025713 lists 5 specific fixes that look like low hanging fruit worthy of SRU
<ubottu> Launchpad bug 1025713 in vlc (Ubuntu Precise) "SRU request for VLC 2.0.2/2.0.3" [High,Triaged] https://launchpad.net/bugs/1025713
<mdz> stgraber, sorry, I'm late, had stuff going on at work
<bryceh> however I have not yet linked any of those fixes to reported bugs (nor know how to repro)
<bryceh> I'm looking through the reported bugs for any others that I can tie to fixes, but no luck so far
<bryceh> anyone know if 2.0.3 is in debian?  at least we could up quantal to that version, which would be prereq to getting precise on 2.0.3.
<kees> mdz: tech board?
<mdz> kees, yes
<mdz> #startmeeting
<bdrung> bryceh: i just synced vlc 2.0.3-1 to quantal
<mdz> cjwatson, soren, pitti, ping
<bryceh> bdmurray, aha thanks
<bdrung> mdz: https://wiki.ubuntu.com/TechnicalBoard says "You can submit an item or proposal for discussion by the Technical Board using the wiki page TechnicalBoardAgenda.", but the agenda says "If you have a question to raise with the Board, you can reach the Technical Board members directly by e-mailing technical-board@lists.ubuntu.com.". what's the preferred way?
<stgraber> bdrung: either way is fine, including adding to agenda + sending an e-mail to the mailing-list to give more details.
<stgraber> bdrung: mostly depends if you want it discussed during a meeting (should be on agenda) or offline (should be sent to the mailing-list)
<bdrung> stgraber: i prefer the online discussion
<mdz> bdrung, agreed, either is fine. email has a chance of a faster response, whereas agenda items wait until the next meeting
<bdrung> mdz: i added the item to the agenda some minutes ago. so the response time should be very fast. ;)
<mterry> infinity, I've got a lead on why the libnet-dns-perl test is failing, but I have to stop working very soon.  I'll finish up tomorrow.  Just wanted to let you know now, so you don't work on it in the interim
<mterry> Has to do with ipv6 sockets not being able to be created
<mterry> The test even has a check at the top to see if it can bind to a socket, and will skip the test if it can't.  But it only does that for ipv4
<infinity> mterry: Curious.  But why only on some buildds (in the Debian case)?
<infinity> And why none of ours?
 * infinity shrugs.
<mterry> infinity, not sure.  A local lockdown policy difference?  Like, some have ipv6 locked down and some don't?
<infinity> I look forward to seeing your fix. :0
<mterry> infinity, though, it seems like ours locks down only ipv6
<mterry> which doesn't make much sense
<infinity> mterry: That test is on localhost, which we don't lock down at all.
<mterry> infinity, the test already has code to test if a socket is bindable.  I'll just add a stanza to also test ipv6
<infinity> So, it miiiiight not relate to locked down networks in any way.
<mterry> but this might point to some misconfiguration on the machines?
<stgraber> I believe xnox hit a similar bug a few weeks back with another package
<infinity> But adding the test will do anything, perhaps.  If that's definitely what's failing.  Do test in a PPA.
<stgraber> same kind of problem, the test would try to listen on ::1 and would fail
<mterry> infinity, I did
<infinity> stgraber: Did you ever sort it out?
<stgraber> infinity: I didn't. Not sure if xnox figured it out
<infinity> stgraber: I vaguely recall him handing it to you and washing his hands of it.
<mterry> I'll bug xnox if I see him tomorrow
<stgraber> hmm, maybe it's on one of my long bug lists then ;)
<stgraber> I vaguely remember it having to something to do with the way /etc/hosts was setup or something to do with the kernel version (as one of the usual suspects in these cases)
<infinity> stgraber: There are precise kernels in play on most of these buildds now, so that shouldn't be an issue.
<mterry> bye!  gotta run
<infinity> stgraber: /etc/hosts could be weird in the chroot, but I thought xnox also tested with the lp chroot tarball.
<infinity> Let me grab one.
<infinity> stgraber: If it's something you can diagnose and pinpoint as a chroot issue, I can fix it right now.
<infinity> Oh, this is curious.
<stgraber> hmm, no /etc/hosts in there
<infinity> My schroot chroot where the build works *doesn't* have correct ipv6 stuff in /etc/hosts
<infinity> In fact, it has a blatant lie of:
<infinity> 127.0.0.1       ip6-localhost ip6-loopback
<stgraber> ouch, that's horribly wrong
<infinity> And the lp buildd chroots have no /etc/hosts at all.
<infinity> Which is probably differently wrong.
<infinity> Though, neither case should cause problems binding to ::1, since it doesn't require resolution...
<stgraber> for lxc containers we're using http://paste.ubuntu.com/1107257/ to setup /etc/hosts and /etc/resolv.conf (based on what netcfg uses)
<infinity> Yeah, that's what my base system has.
<infinity> And what many of the buildds would also have.
<stgraber> yeah, that was the bit I didn't quite get and that's why having a minimal testcase would be awesome (vs running 3 hours build ;)) The only way I can see it going wrong is if the service does reverse + forward lookup for some weird reason
<infinity> Well, libnet-dns-perl is certainly minimal.
<bryceh> mdz, kees on topic of mesa mre, I've run piglit on three types of hardware (ati, nvidia, intel all with the foss/mesa drivers enabled), both without and with the proposed version, and verified the number of passed tests goes up in all cases.
<bryceh> piglit is a combo conformance + regression test suite, so in normal operation not all  tests will pass as they're checking for unimplemented features too
<stgraber> infinity: what's the test that's currently failing in libnet-dns-perl?
<mdz> bryceh, sounds solid
<infinity> stgraber: Hrm, I think mterry's test and fix might be a red herring in this case.  I see nowhere where it's actually doing INET6 in the testsuite.  But testing that inet6 is broken and then skipping the inet4 test sure "fixes" it. ;)
<mdz> bryceh, as long as no tests go from green to red
<infinity> stgraber: 13-udp-trunc.t is the test that breaks.
<bryceh> mdz, kees results at http://people.canonical.com/~bryce/mesa803-piglit/
<bryceh> mdz, right there were no new failures found
<infinity> stgraber: Ah-ha, but lib/Net/DNS/Nameserver.pm tries to bind to "['::1' , '127.0.0.1' ]" if one doesn't override.
<infinity> stgraber: Or, I'm tired and reading the docs, not the source. :P
<infinity> stgraber: Yeah, this failure can't be INET6 related, I was right the first time.
<bryceh> mdz, kees on the vlc front, I can help bdrung handle regressions.  I looked through the release notes and git history for 2.0.2/2.0.3 and it looks like they're taking care to keep them to sane bug fixes.  I've noticed they also appear active in our bug tracker so that's a good sign.
<SpamapS> + mysql_install_db --no-defaults --user=buildd --datadir=/build/buildd/php5-5.4.4/mysql_db --rpm --force
<SpamapS> A newer kernel is required to run this binary. (__kernel_cmpxchg64 helper)
<SpamapS> ï¿½Aborted
<SpamapS> some problem w/ mysql on armel?
<SpamapS> Kernel version: 2.6.38-1209-omap4 #24-Ubuntu SMP PREEMPT Mon May 14 17:19:07 UTC 2012 armv7l
<SpamapS> infinity: ^^ any ideas?
<StevenK> Handy
<infinity> SpamapS: Yeahp, we need to build it on caph or sigbin.
<infinity> SpamapS: (Or, rather, need to "run it" on one of those machines, where it builds doesn't matter, but this tends to upset test suites)
<infinity> stgraber: Hahaha.  I've come full circle.  It *is* an INET6 problem.
<infinity> stgraber: If this module detects you have the INET6 module installed, it uses the shinier IO::Socket::INET6 instead of IO::Socket::INET, then explodes.
<infinity> stgraber: If I force it to v4-only, it's fine.
<infinity> stgraber: Which seems suboptimal. ;)
<stgraber> infinity: fun ;) why is INET6 exploding?
<stgraber> from what I remember of looking at that test, it's trying to bind 0.0.0.0, which with INET6 should be :: and with our default sysctl config, should bind both 0.0.0.0 and ::
<ScottK> Speaking of IPv6 ...
<infinity> stgraber: So, it's probably reproducible with a perl 2-liner or so of require IO::Socket::INET6; new IO::Socket::INET6 ( LocalAddr => "127.0.0.1", LocalPort => 5443, Proto => UDP );
<infinity> stgraber: (Well, reproducible if I can figure out how to get an environment as sad as a buildd, but maybe I'll try)
<StevenK> infinity: Remove large swathes of /etc, and then you're done?
<ScottK> I noticed today that if I'm talking to a remove host that's down via IPv4, if the host has only an A record, I get connection refused.  If it also has an AAAA record because it's dual IPv4/6 I get connection unreachable (because there's no IPv6 path).
<infinity> StevenK: And large chunks of the DC surrounding it.
<infinity> ScottK: That seems like a feature.
<StevenK> ScottK: network unreachable, rather?
<ScottK> It seems suboptimal in this case to give the user the IPv6 error message (unreachable).
<ScottK> StevenK: Yes.
<ScottK> If the IPv6 network is unreachable, it should give the IPv4 error as that was actually useful.
<ScottK> So what do I file a bug against?
<StevenK> They are different causes
<stgraber> ScottK: and you're getting the network unreachable error without a globally routable ipv6 address on an interface?
<ScottK> Yes.
<ScottK> It was with SSH.
<StevenK> The buildd has a route, and so attemptes to make a connection, and gets stopped, which is ECONNREFUSED. It attempts via IPv6, and has no route at all, so the network is unreachable
<ScottK> As soon as I ssh'ed to the IPv4 address directly, I got the connection refused.
<ScottK> SSHing to the IPv6 address got the network unreachable.
<infinity> ScottK: Oh, it's ssh that's giving you the return you think is unfriendly?
<ScottK> The only IPv6 address I have locally is link-local: inet6 addr: fe80::224:d7ff:fea1:e8ec/64 Scope:Link
<ScottK> Is it ssh or is ssh just parroting what it got from elsewhere?
<infinity> ScottK: Well, those error messages come from elsewhere, but what order it tries to connect in, and what error it chooses to bubble up is entirely up to the client application.
<infinity> ScottK: It doesn't say "just open me a random port on some IP identified by this hostname, and let's see how it works out".
<ScottK> I think it's fundamentally a misfeature that applications need to care at all if a connection is IPv4 or IPv6, but I know I'm about 20 years late to the party on that one.
<ScottK> I guess I'll file it against openssh and see what happens.
<infinity> If IPv6 was nothing more than "just more address space", they'd have no reason to care, but when it's also "funky new features", some clients really do want to know.
<infinity> (Others really couldn't care less)
<ScottK> Unfortunately even ones that shouldn't need to care seem to end up doing so.
<ScottK> Ironically, this is the same issue with the libnet-dns-perl test is stuck in.
<ScottK> (it seems)
<infinity> ScottK: Well, no.  It's falling back to a generic implementation (INET6 can handle both), which then fails because INET6 fails because out inet6 setup is confused somehow.  Or something.
<infinity> It's doing what you think it should be doing (being generic), which we'd screwed up somehow. :P
<infinity> If it instead did a "is 127.0.0.1 ipv4?" test and called INET functions explicitly, it would be fine.
<ScottK> Right, I was thinking the situation, not the root cause.  It was ipv4 connection refused and ipv6 network unreachable.
<infinity> ...
<infinity> My.
<infinity> God.
<infinity> I just started a new Firefox window, and for NO REASON I CAN FATHOM, it's in a backwards language.
<infinity> And now every new window is stuck in right-to-left squigglies.
<infinity> Yay.
<stgraber> infinity: is the whole page right-to-left or just the address bar (and maybe some other input boxes)?
<RAOF> That's AWESOME!
 * slangasek wants his browser windows to launch in boustrophedon
<infinity> stgraber: Yeah, it wasn't firefox, it was the start page.
<infinity> stgraber: Going to Google and forcing back to English magically fixed the start page too.
<infinity> stgraber: And now I'm confused.
<infinity> stgraber: But don't care.
<ScottK> Sounds like the start of Alzheimer's.
#ubuntu-devel 2012-07-24
<SpamapS> infinity: so, is there a way to force the build host or should I just retry until it works?
<StevenK> SpamapS: You can't, it can be done with a form of superpowers.
<stgraber> SpamapS: you need someone in ~buildd to disable all the others, bump the score and enable just the one you want. I can do that for you if you want (need a build link and what builder you want)
<infinity> SpamapS: I'll do it.
<infinity> SpamapS: Was PHP?
<SpamapS> stgraber: https://launchpad.net/ubuntu/+source/php5/5.4.4-3ubuntu1/+build/3676565 .. I fully expect an upload of php 5.4.5 in a week or two.. so this may be a problem again
<SpamapS> infinity: ^^
<infinity> SpamapS: It shouldn't be a problem by then, IS is reinstalling all the Pandas, now that we're sorted out PXE/preseed automagicness.
<infinity> SpamapS: caph was our testbed.
<SpamapS> ah cool :)
<infinity> SpamapS: If you do run across that particular class of failure again, though, let me know.
<SpamapS> infinity: ACK
<infinity> Sweetshark: libreoffice-dbg probably shouldn't be depending on libreoffice-filter-binfilter if we don't build it anymore
* ChanServ changed the topic of #ubuntu-devel to: Quantal Quetzal A3 prep | Archive: please upload to -proposed | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<infinity> stgraber: FFS.  Would you believe it's as simple as /etc/protocols not being there?
<StevenK> Hahaha
<infinity> And schroot doesn't show this problem because, despite not having netbase in the chroot, it "helpfully" copies the system one in.
 * infinity head -> desk.
<StevenK> infinity: Hahaha, it gets worse.
 * infinity wonders what the odds are that xnox's issue was actually the same thing.
<infinity> He should only be so lucky.
<stgraber> infinity: oh, that'd explain it indeed ;)
<infinity> Yeah, I spent all this time reducing to a perfect test case, just to strace and go "you've got to be kidding..."
<StevenK> infinity: Build-Depends: netbase ? :-P
<infinity> StevenK: Yeahp.
<StevenK> Oh bloody hell, I was kidding.
<StevenK> It's in build-essential!
<stgraber> or promote netbase to essential?
<infinity> I might be able to argue that libio-socket-inet6-perl should depend on netbase, but I haven't gone looking to see if that's universally true.
<stgraber> that thing just contains 4 text files nowadays
<infinity> StevenK: It's not build-essential.
<StevenK> steven@undermined:~% apt-cache show netbase | grep '^Build'
<StevenK> Build-Essential: yes
<infinity> Erm.
<infinity> Then we have a disconnect between the package and the task.
<infinity> And the package is what's guaranteed to be installed.
 * infinity wonders who changed one without the other.
<StevenK> infinity: Oh, is that what happened?
<infinity> StevenK: Well, the chroots all have the package installed, which is authoritative, and most certainly doesn't pull in netbase.
<infinity> StevenK: So, build-essential hasn't been updated since 2010.  Whoever things netbase is build-essential is, frankly, wrong. :P
<infinity> StevenK: (Though, we could certainly make the two match)
<StevenK> It would save confusion
<infinity> Well, I could just add netbase to all our chroots and scream "la la la" too, but I don't really want pollution in there until I get to the bottom of why there's a mismatch.
<infinity> (And when I say b-e hasn't been updated since 2010, I mean in neither Debian or Ubuntu, so whoever's twiddling archive overrides doesn't quite grasp the disconnect(
<infinity> )
<infinity> And it's not build-essential in Debian, so we're the ones who are a bit wrong here.
<stgraber> how are these packages building in Debian then?
<infinity> stgraber: They're not.
<infinity> stgraber: Well, this one failed on about half the buildds.  The others must have had either (A) dirty chroots, or hilariously (B) the above-mentioned sbuild/schroot setup that copies /etc/* junk into the chroot.
<infinity> stgraber: It's entirely possible that netbase was mistakenly marked build-essential in unstable at one point, we mirrored the change in our overrides, some Debian buildd chroots got created that way, then they reverted it.
<infinity> stgraber: So, those chroots would just keep upgrading netbase unless someone decided to rebuild them from scratch or go purging non-essential packages.
<pitti> Good morning
<pitti> mdz: hello; sorry, didn't make it to TB again; since it got moved another hour, it's a really bad time for me
<RAOF> pitti: How do I make apport-retrace fly? âapport-retrace -v --sandbox system -o Xorg-dummy.crash /var/crash/_usr_bin_Xorg.0.crashâ doesn't seem to work; it ends up failing to find Contents.gz. Setting various different things (--cache-dir, --sandbox-dir) result in failing to find different things, mostly virtual_mapping.pickle
<pitti> RAOF: I do recommend using a cache dir if you want to run that more than once, but in principle that looks good; do you have a pastebin of the output?
<RAOF> http://paste2.org/p/2081338
<pitti> urgh
<RAOF> I can give you the other permutations if you like :)
<pitti> RAOF: hm, I haven't tested --sandbox-dir a lot; that's mostly ev's
<pitti> RAOF: does it work without this?
<pitti> RAOF: the .pickle error looks like a real bug, but I never saw this before, which makes me think it's related to the permanent sandbox
<pitti> RAOF: you don't really need that for your purposes, though
<pitti> RAOF: I guess you want to start with --gdb, poke around, and once you got the magic gdb commands, retry with -o or -s?
<RAOF> pitti: I tried it with all permutations I could think of; with --sandbox-dir, with --cache-dir, without both.
<RAOF> Actually, I just want to check that the retraced bug looks right.
<pitti> RAOF: and you always get the pickle error?
<RAOF> No; I get the pickle error with... let me check.
<RAOF> Pickle when I set sandbox and/or cache; /tmp/tmp48_gk_/Ubuntu 12.10/Contents-amd64.gz missing when I set neither.
<pitti> http://mirror.internode.on.net/pub/ubuntu/ubuntu/dists/quantal/ has Contents.gz alright
<RAOF> Oh, huh.
<RAOF> It turns out I hadn't tried with *just* --cache; that works.
<pitti> I usually use -S system -C <cache dir>
<pitti> I'm reading the code now to see what's wrong with sandbox dir
<pitti> looks like a missing mkdir
<pitti> RAOF: right, so that can only happen with --sandbox-dir; I really don't think you want this, but thanks for pointing out
<RAOF> Yeah, I probably don't.
<pitti> RAOF: it should happen when you give a --sandbox-dir but no --cache-dir?
<RAOF> It also happens when you give it a --cache
<pitti> ooh, of course -- "system"
<pitti> right, so --sandbox-dir with -S system; it does work with an actual sandbox config
<pitti> which explains why ev hasn't seen this
<RAOF> It also seems that it doesn't work if I *don't* pass --cache.
<pitti> yep
<pitti> ok, tests pass, fix committed
<pitti> RAOF: http://bazaar.launchpad.net/~apport-hackers/apport/trunk/revision/2445 in case you want to apply locally; but just drop --sandbox-dir
<RAOF> Yeah, that's what I've done.
<pitti> RAOF: you want -S system -C ~/.cache/<whereever>, or -C /tmp/cache or so
<pitti> sorry for the trouble
<RAOF> That's ok.
<hallyn> ubuntu-vm-builder shouldn't affect any cd spins right?
<pitti> RAOF: perhaps I should add some more examples to the manpage?
<hallyn> is there a tool i can run to check that?
<pitti> $ seeded-in-ubuntu ubuntu-vm-builder
<RAOF> pitti: Well, I only started playing with the other options because running apport-retrace without -C or --sandbox-dir didn't work.
<hallyn> pitti: thanks!
<pitti> hallyn: that even errors, it's not even in main
<hallyn> pitti: right, not in main,
<pitti> RAOF: ah, with the Contents.gz? do you have a pastebin?
<RAOF> It has, however, somewhat dimmed my enthusiasm. It turns out that -core only accidentally makes Xorg usefully dump core; there's a SIGSEGV in the logging path :)
<hallyn> pitti:  but lxc is not in main, but is seeded - wanted to make sure it wasn't like that
<pitti> RAOF: phun!
<pitti> hallyn: yes, all derivatives build from universe now, so it's still worth checking
<pitti> hallyn: ah, sorry; the source package is "vm-builder", you need to run it with the source pkg
<hallyn> ah
<pitti> $ seeded-in-ubuntu vm-builder
<pitti> vm-builder's binaries are not seeded.
<hallyn> thanks!
<pitti> $ seeded-in-ubuntu -b ubuntu-vm-builder
<pitti> ubuntu-vm-builder is not seeded.
<pitti> hallyn: ^ or -b
<hallyn> cool
<RAOF> pitti: Oh, urgh. *Now* it works without --cache? :/
<pitti> RAOF: theory: you used the same --cache dir as in the run that failed over the broken virtual_mapping, and thus the cache dir got broken?
<pitti> ah no, you got the Contents bug first
<RAOF> pitti: http://paste2.org/p/2081361 is what I got the first time.
<pitti> argh
<pitti> RAOF: http://paste.ubuntu.com/1107569/ should help, if you want to apply locally
<RAOF> I'm happy using --cache.
<RAOF> Thanks!
<pitti> ok, good
<RAOF> pitti: Oh! It seems that if you have apport-retrace installed, the crash dialog has a âExamine locallyâ button on it! That's totally awesome!
<pitti> RAOF: thanks :)
<pitti> RAOF: https://wiki.ubuntu.com/DebuggingProgramCrash
<RAOF> Oh, that's no fun at all.
<RAOF> Apparently Xorg will SIGSEGV in the crash logging if and only if it's built with optimisations.
<pitti> RAOF: do you get a reasonably useful backtrace for that at least?
<RAOF> Oh, yes.
<RAOF> The bit *above* there is fine.
<RAOF> And when you build without optimisations it correctly abort()s, and generates a useful backtrace also.
<pitti> I mean for the crash in the crash handler
<RAOF> pitti: Not really. It *looks* like it's calling vsprintf with an out of bounds string format (in this case, it's 0x1c6f). However, the frame above that isn't useful. It's just ??, so there's a blank between <signal handler called> and VAuditF called with format string=0x1c6f.
<RAOF> Hm. Which, suspiciously, is *also* the address of the va_args that gets passed in there.
<RAOF> It's possible this is related to the attribute("noreturn") on one of these functions in the stack.
<RAOF> ...
<RAOF> No, I think the backtrace is totally ficticious. Nothing in the crash logging callstack actually *calls* VAuditF.
<pitti> hm, a recent LP rollout seems to have disabled access to https://launchpad.net/builders when not logged in
 * pitti goes to fix ddeb-retriever to work around that
<jamespage> anyone know when doko might reappear?
<Sweetshark> infinity: thanks for the hint, the fix will be though to reenable crappy old binfilter. It was removed on debian for quicker build times ....
<cjwatson> infinity: The Build-Essential override is entirely automatic, generated from the expansion of the build-essential seed.
<Sweetshark> s/removed/temp. removed/
<cjwatson> Sweetshark: Have you had an opportunity to try +copy-packages since I switched on the async copy code?
<Sweetshark> cjwatson: not yet
<cjwatson> OK.  Let me know when you do - I'd like as much positive confirmation as possible so that I can move forward with removing the old code
<zyga> hrw, have you seen doko recently?
<ogra_> zyga, vacation
<zyga> ogra_, ah
<zyga> ogra_, thanks, I'll check his schedule
<bdrung> bdmurray: can you deploy the latest changes to lp:ubuntu-sponsoring?
<jamespage> infinity, when you are around can you give me a ping re glibc for quantal pls.
<sgnb> how fprintf calls are turned into __fprintf_chk in Ubuntu? it doesn't seem to be #define...
<pitti> with -fstack-protector, which is enabled by default
<cjwatson> sgnb: /usr/include/bits/stdio2.h
<cjwatson> search for __fprintf_chk there
<pitti> sgnb: sorry, not stack protector; presumably the -dFORTIFY.. bits
<cjwatson> yeah, it's fortify
<cjwatson> -U_FORTIFY_SOURCE if you have some strange reason to need to disable it
<sgnb> I've a program that bugs because of that (and indeed, it behaves as expected with -U_FORTIFY_SOURCE)
<sgnb> this fortify stuff doesn't happen in Debian... how to reproduce it there?
<cjwatson> sgnb: -D_FORTIFY_SOURCE=2
<cjwatson> sgnb: if your package were using the currently recommended dpkg-buildflags approach to get default build flags in Debian, it would happen there too :-)
<cjwatson> sgnb: it's just that it's on by default in Ubuntu's compiler as well
<cjwatson> <cjwatson@sarantium(sid) ~>$ dpkg-buildflags --get CPPFLAGS
<cjwatson> -D_FORTIFY_SOURCE=2
<sgnb> ok, found the issue (a missing volatile in inline assembly)
<sgnb> thanks
<hallyn> is there a 'debian/rules XYZ" command to go back from 'fakeroot debian/rules binary' to 'debian/rules build' (to avoid having to rebuild)?
<hallyn> looks like rm -rf debian/*debhelper.log (and the debian/package dirs) worked
<tumbleweed> hallyn: yeah, when I find myself in that situation, I hack out of it my hand
<tumbleweed> echo -e 'dh_auto_build\ndh_auto_test' > debian/$binary.debhelper.log and lots of rm
<ScottK> Won't make -f debian/rules clean do it?
<geser> wouldn't that also remove the build files which should be preserved?
<tumbleweed> ScottK: that does an upstream clean too
<ScottK> Ah. Right.
<ScottK> Missed that part of the request.
<tumbleweed> if you're working on a package that takes 4 hours to build...
<ScottK> Then I agree.
<ScottK> Manual removal is the way.
<geser> wouldn't calling "dh_prep" work too?
<Laney> jodh: Hey ;-)
<Laney> jodh: Do you know anything about the upstart activation patches we have in dbus? https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/quantal/dbus/quantal/files/head:/debian/patches/
<tumbleweed> geser: IIRC dh needed its log files to tell it what to do next, but yes, that should do most of the work
<Laney> like, are they still needed?
<carif> there used to be a package system-config-printer-tui that configured a printer without gnome or cups installed, does it still exist? I can't find it
<pitti> I never heard of that (which doesn't mean it doesn't exist, of course)
<bdmurray> pitti: why would a duplicate bug be in the apport signature database?
<pitti> bdmurray: perhaps it was duplicated manually?
<pitti> bdmurray: anyway, just running out, sorry; TTYL!
<bdmurray> pitti: yes it was duplicated manually
<ogra_> ivanka, haha, your tweet about the UX team hiring just made it into the installed slideshow :)
<ogra_> *installer
<ivanka> ogra_: haha! I am not sure that is a good thing though!
<ogra_> ivanka, so it isnt the new "do a test install of ubuntu and get a job offer" programme ?
<ivanka> ogra_: Sounds like one way to advertise :-)
<mterry> I'm experimenting with sbuild (rather than my native pbuilder), and it seems to not cache downloaded .deb files like pbuilder does.  Is that what --purge-deps controls?
<micahg> mterry: apt-cacher-ng FTW :)
 * mterry looks it up
<mterry> ah
<carif> mterry, will you recast pbuild-scripts with sbuild underneath?
<wookey> Have UDS-N dates been set?
<mterry> pitti, apport Build-Depends on python3-pykde4, which is keeping some kde bits in main.  Is it possible to drop that?  It looks like it runs tests at both build and via dep8?
<infinity> wookey: UDS-N seems to be planning rather far in advance.
<infinity> wookey: Or in the past, depending. ;)
<highvoltage> Narwhals, narwhals, swimming in the ocean, causing a commotion, 'cause they are so awesome.
<infinity> SpamapS: Say, watching the PHP build go by here, and there are a bunch of '-Wpointer-sign' warnings flying by.  That's almost certain to cause some sadness on ARM and PowerPC.
<carif> mterry, pitti, et al, can debian binary packages have aliases? in other words several names for the same package?
<infinity> SpamapS: Y'know, if you're in the mood for something to fix.
<Myrtti> UDS-N?
<wookey> erm R
<wookey> the alphabet was never one of my strong suits
<infinity> carif: Sort of, but no.
<mterry> carif, yeah sorta.  Via virtual packages.  Like a binary package can Provide a different name
<infinity> carif: You can have packages provide a package, but that can't be versioned.  Or you can have a metapackage that depends on the original, which can be versioned.
<infinity> carif: For versioning reason, the latter is usually the choice used for transitioning from one name to another, but the former also has its place.
<mterry> carif, for example, Both libtiff4-dev and libtiff5-dev exist, but one Provides libtiff-dev as an "alias" of sorts
<wookey> I heard rumours that it was going to be in copenhagen next to Linaro Sprint, and as it'll be travel-arranging time any minute now It'd be useful to have that confirmed or denied
<carif> mterry, infinity, ty;
<infinity> wookey: I've heard similar rumours, but I don't know of any formal announcement of dates yet. :/
<infinity> wookey: It might work better for you to backchannel the request for clarification through Linaro, since they should have a better idea about what's going on that #ubuntu-devel. ;)
<ahasenack> hi, are the build logs for packages that were uploaded to precise-proposed still available somewhere?
<ahasenack> I'm looking into a missing .mo file (see https://bugs.launchpad.net/landscape-client/+bug/983096/comments/12)
<ubottu> Launchpad bug 983096 in landscape-client (Ubuntu) "Mispelling of Landscape" [Low,Fix released]
<stgraber> ahasenack: https://launchpad.net/ubuntu/+source/landscape-client then find the version number either on that page or in the publishing history, the build log should be there
<SpamapS> infinity: re pointer-sign warnings in php, sure I'd be down for looking into them. Can you elaborate on what kind of sadness this causes?
<ahasenack> stgraber: thanks, I'll take a look
<infinity> SpamapS: Well, have you ever had a 1 turn into a 255 (or similar)?
<infinity> SpamapS: Turns out that some things dislike that. ;)
<infinity> SpamapS: (Basically, it's a byproduct of lazy programmers assuming char is the same on all arches, and using it interchangably with int for pointer arithmetic, which explodes on many non-x86 arches)
<SpamapS> infinity: ok so its a "crazy wacked out stuff" problem
<SpamapS> infinity: I'd be interested to see how much the test results differ on arm vs. x86, I bet there are a few problems already shown.
<SpamapS> Maybe some day PHP will have 0 failing tests so we can fail the build on it. :-P
<micahg> SpamapS: maybe the same can happen with mysql as well? :)
<infinity> SpamapS: 0 failing tests in PHP was a goal of mine a decade ago.  And I almost got there.  I gave up when I realised that people commit code, with matching tests, that fails out of the box.
<infinity> SpamapS: That was the last straw. :P
<SpamapS> micahg: mysql does fail if the tests fail
<infinity> SpamapS: No, MySQL fails if "too many" tests fail.
<SpamapS> infinity: actually the PHP project has CI now
<infinity> SpamapS: Which is hilarious.
<infinity> SpamapS: Since it was no weighting for "important" versus "useless" tests, it just fails if N% break.
<SpamapS> infinity: not sure they're gating yet, but they are filing bugs on new test failures
<SpamapS> infinity: no, mysql fails if any tests fail
<infinity> SpamapS: That's... Very new.  As of when?
<SpamapS> 5.1 had that
<SpamapS> so "before my time"
<infinity> If you're wrong, do I get beverages?
<SpamapS> probably
<infinity> Completed: Failed 5/1706 tests, 99.71% were successful.
<infinity> ^-- Build goes on.
<SpamapS> infinity: where's that?
<infinity> The build fails when that dips below an "unacceptable" threshold.
<infinity> Which is what happened when you had the SSL issues.
<infinity> Other tests were failing too.  But the SSL stuff tipped the scales.
<SpamapS> all the builds I see say All xxx tests were successful
<infinity> That was an armhf build on quantal.
<SpamapS> I am dumbfounded and feeling fairly betrayed ;)
<SpamapS> ahhhh thats the warning rate
<SpamapS> infinity: well I do stand corrected, but I believe those are tests which just produced some kind of warning, they didn't have mysqld crash or produce unexpected output
<infinity> Failing test(s): sys_vars.rpl_semi_sync_master_enabled_basic sys_vars.rpl_semi_sync_slave_enabled_basic main.outfile_loaddata perfschema.func_file_io perfschema.func_mutex
<infinity> I'd argue that failed is failed?
<SpamapS> infinity: I think its just poorly worded, but I'll look into it.
<SpamapS> --1
<SpamapS> +255
<SpamapS> nope you're right
<SpamapS> infinity: ^^ perfect example. DOH
<SpamapS> thats pretty serious actually
<SpamapS> I wonder if I can set that threshold to 100%
<SpamapS> bug 1028579 filed
<ubottu> Launchpad bug 1028579 in mysql-5.5 (Ubuntu) "test suite run during package build should require 100% of tests to pass" [High,Triaged] https://launchpad.net/bugs/1028579
<SpamapS> infinity: I'm sure we can find you something to drink at our next physical co-location.
 * SpamapS notes that this time when he decided to assume he only made an ass out of 'me'
<infinity> SpamapS: And that particular class of error (assuming it's char-signedness, which it looks like at a glance) would affect at least arm, powerpc, sparc, and s390.  While upstream may not care about all of those, I'd wager they care about s390, and possibly still sparc.
<SpamapS> my $opt_max_test_fail= env_or_val(MTR_MAX_TEST_FAIL => 10);
<infinity> (And they should be taught to care about ARM)
<SpamapS> They've been super responsive to the couple of ARM porting bugs we've filed
<SpamapS> threatening to remove them from Debian and Ubuntu has, if nothing else, gotten us in their heads a little. :)
<infinity> SpamapS: Of course, the other possibility for a 1/255-looking thing is alignment, rather than char-signedness, which is a bit more painful to hunt, but still worth fixing.
<infinity> SpamapS: Because fixing alignment issues not only makes unaligned arches not broken, it makes x86 faster, cause the machine doesn't have to waste cycles on alignment fixups.
<carif> pitti, can jocky-gtk handle printer drivers also?
<jamespage> infinity, around for a glibc question? (sorry to hound you :-))
<infinity> jamespage: Sure, what's up?
<jamespage> infinity, I'm working on enabling the test suite for google-perftools to support an MIR
<jamespage> and I've hit a bug in glibc 2.15 which is causing a deadlock
<infinity> jamespage: Is it fixed in 2.16?  (ie: do you know what the bug is, or just assuming it's glibc?)
<jamespage> infinity, I patched 2.15 with the one line fix locally and re-tested and the deadlock disappears
<jamespage> bug 1028038
<ubottu> Launchpad bug 1028038 in eglibc (Ubuntu) "sscanf always calls realloc/causes deadlock in google-perftools" [High,New] https://launchpad.net/bugs/1028038
<jamespage> and the upstream bug report - http://code.google.com/p/gperftools/issues/detail?id=423
<jamespage> infinity, I really wanted to check to see if a) there where plans to upgrade to 2.16 for quantal
<infinity> jamespage: I *might* be doing 2.16 for quantal, that's still in the air, while I work with Debian on that.
<jamespage> infinity: or b) if not can we get this patch applied to 2.15 (and as this is fairly core I was a little nervous about just doing it :-))
<infinity> jamespage: But is the impact of this such that we should be SRUing?
<infinity> jamespage: It sounds like something SRU-worthy to me.
<jamespage> infinity, this is the only impact I know of; it basically breaks the heap leak checker in gperftools
<jamespage> infinity, I tend to agree.
<infinity> jamespage: Can you turn your bug into something SRU-friendly (short test-case, etc)?
<infinity> jamespage: I'll assign it to me and open a precise task, etc.
<infinity> jamespage: And yeah, we can get the patch into quantal as well, that's no drama.
<jamespage> infinity, sure - I can do that
<stgraber> infinity: I guess you can bundle that one with bug 979003 then?
<ubottu> Launchpad bug 979003 in eglibc (Ubuntu Precise) "libc incorrectly detects AVX support" [High,In progress] https://launchpad.net/bugs/979003
<infinity> stgraber: Yeahp, and one other too.
<infinity> https://bugs.launchpad.net/eglibc/+bug/1016349
<ubottu> Launchpad bug 1016349 in eglibc (Ubuntu) "htons() returns wrong type on non-{i386,amd64} platforms" [Undecided,Confirmed]
<infinity> Drat, I don't have a precise task for that one.
<infinity> I had another one lying around here, too...
 * infinity looks.
<jamespage> infinity, thanks for picking this up - much appreciated!
<seb128> does anyone here know how often is the SRU report updated?
<infinity> https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/1010069
<ubottu> Launchpad bug 1010069 in eglibc (Ubuntu) "bits/fcntl.h does not define AT_EMPTY_PATH" [Medium,Triaged]
<infinity> stgraber: ^-- That one's on my radar too.  I need to take a glibc day and tackle all of these.
<infinity> seb128: Twice an hour.
<seb128> infinity, "Generated: 07/24/12 16:48:31 UTC by sru-report"
<seb128> infinity, it didn't get updated for over 3 hours
<seb128> infinity, who has access to look at why?
<stgraber> seb128: ubuntu-archive on lillypilly IIRC
<infinity> ubuntu-archive.
<infinity> I'll check.
<seb128> thanks
<stgraber> seb128: which according to getent includes you :)
<seb128> stgraber, it does, I just don't know where to check ;-)
<infinity> Hrm, nothing helpful from cron about it being broken.
<infinity> It appears to be exiting non-zero.
<infinity> Special.
<infinity> ubuntu-archive-tools/sru-report > ~/public_html/pending-sru.html.new && mv ~/public_html/pending-sru.html.new ~/public_html/pending-sru.html
<infinity> -rw-r--r-- 1 ubuntu-archive ubuntu_archive 126376 Jul 24 16:49 public_html/pending-sru.html
<infinity> -rw-r--r-- 1 ubuntu-archive ubuntu_archive 120997 Jul 24 20:20 public_html/pending-sru.html.new
<infinity> So, the "&& mv" isn't triggering.
<infinity> I'll have to do a manual run and see what's up with that.
<seb128> doing that atm
<infinity> Or, you can.  Cool.  Go nuts.
<infinity> I wash my hands of it. ;)
<seb128> not sure that was a smart idea I had there
<seb128> note: pretend you are dumb and can't help next time
<jerm1080> Hello, I was wondering if there was anyone here who could help me with packaging and distributing a program through apt
<seb128> hum
<seb128>   File "./sru-report", line 230, in print_report
<seb128>     bug = lp.bugs[b]
<seb128>   File "/usr/lib/python2.7/dist-packages/lazr/restfulclient/resource.py", line 950, in __getitem__
<seb128>     raise KeyError(key)
<seb128> KeyError: '900119'
<seb128> *
<seb128> does anyone has access to that bug?
<mdeslaur> seb128: not me
<stgraber> nope
<micahg> hrm, shouldn't the report exclude private bugs?
<stgraber> micahg: or rather, shouldn't SRU always list public bugs? :)
<micahg> yeah, that too
<stgraber> what's the point of listing a bug in the changelog if people can't read it
<seb128> ogasawara, ^
<seb128> or somebody else from the kernel team (seems a kernel bug from google)
<seb128> infinity, ^ in any case that's the issue with the SRU report
<stgraber> seb128: I guess it'd make sense to fix the report not to crash in such case and instead "<strike>#bugnumber</strike>" or similar to make it visible
<seb128> stgraber, right, if somebody feels like to do that
<stgraber> seb128: I'm doing a test run of a patched sru-report to at least deal with the KeyError. The two other calls to lp.bugs were guarded by a try/except, but not that last one, so at least going for some consistency there :)
<micahg> strike is deprecated in HTML 4.0 I believe :)
<stgraber> I'll probably try to replace the debug logging by instead showing a list of error at the end of the report, that should be a lot more useful than having cron send the output by e-mail to some local account on lillypilly
<stgraber> micahg: yeah, I guess it's font-decoration:strike or something similar in css nowadays
<micahg> yeah
 * micahg was a web developer in a former life
 * stgraber too
<stgraber> well, kind of still am I guess... (working on qatracker)
<ajmitch> text-decoration: line-through iirc :)
<stgraber> ajmitch: yep, that's the one
<carif> mterry, i'm experimenting with sbuild too, any pointers you can share?
<infinity> seb128: Thanks for the debugging.
<infinity> stgraber: If you commit a fix for it, let me know and I'll pull it.
<stgraber> infinity: yep, waiting on the result of a test run here.
<stgraber> (that thing is horribly slow...)
<infinity> stgraber: Yeah, it really is.  I've only hacked on it once or twice, but the turnaround for testing wasn't pleasant.
<stgraber> infinity: ok, test run done and it passed. Just adding a bit of code to list all the broken bugs at the end of the report, so should have a branch ready for merging in ~30min (one more test run ...)
<infinity> Why list them, when we can just strike them, as suggested?
<infinity> We already have CSS for bug tags at the top of the file, it's just one more class. :P
<stgraber> it was initially tricky to do that as there are 3 different places where the parsing can fail, but now that I have a list of broken bug numbers, I might actually be able to do it, let me check
<arges> infinity, hello. was looking through my list o' bugs... any updates on pad.lv/979003  ?  This is the eglibc FM4/AVX issue. And anything I can do to help with this? thanks
<infinity> arges: I'm working on it today (and until it's done).
<infinity> arges: Just got off a phone call where I mentioned that very thing (well, among other glibc SRU bugs, but that's the nastiest one).
<arges> infinity, awesome. thanks!
#ubuntu-devel 2012-07-25
<pitti> carif: package name aliases> up to some degree with Provides:
<pitti> carif: jockey can look up printer drivers from openprinting.org
<xclaesse> gedit can't be upgraded in Quantal because of gedit-plugins
<sonne> greetings!
<xnox> slangasek: did you have a chance to re-review my updated mdadm upload? stgraber is asking me about it again.
<sonne> could anyone point me to some design docs about unity?
<xnox> sonne: try #ubuntu-design channel. They might know better =)
<sonne> oh thanks xnox.. who knew ubuntu had so many channels :)
<xnox> sonne: in general it's almost always in the wiki.ubuntu.com for relevant item (e.g. messaging menu, overlay scrollbar, unified menu)
<xnox> sonne: and / or blog posts on design.canonical.com
<sonne> relevant item?
<xnox> sonne: indicators is one thing, typography/font another, session menu yet another item, overlay scrollbar is separate.
<xnox> sonne: it was all developed and matured in individual pieces to create unity.
<xnox> sonne: what specifically are you after?
<sonne> well, for what i know it's still on an early development stage
<sonne> so i was wondering where the project was headed
<xnox> sonne: 4 years since Ubuntu Netbook Remix was released -> now known as Unity
<xnox> hardly "early development stage" ;-)
<sonne> xnox, well ubuntu netbook was very different from unity, at least speaking of UI
<ogra_> it was the same code it just matured over time
<xnox> sonne: yet so many core design patterns and code is still here - e.g. the dash/launcher
<xnox> and didn't notifications and indicators were developed even before that?
<ogra_> notifications are two years older than netbook, yeah
<ogra_> indicators came later
<sonne> so you're saying that unity is pretty much done?
<ogra_> no, but its a mature base for further progress :)
<xnox> sonne: it's never done =) but a lot of it, has been done =)
<ogra_> in precise the HUD was added for example
<ogra_> which will eventually become the core for things like voice input etc
<ogra_> there are many areas where new development happens on top of unity and indeed there are also still many bugfixes
<sonne> well, speaking from a very personal point of view, the netbook remix seemed more intuitive for first approaches (my grandma is still using it), while i'm having a hard time getting used to unity  myself - this is probably because i haven't really got a grasp on its philosophy, this is why i was looking for design docs
<sonne> please don't take what i said as polemic, i'm just explaining what i was after on my first question and why :)
<xnox> sonne: my sister gave me a phone call:" I remember you installed skype for me, how do I launch it?"
 * xnox she could not find the big fat button to launch apps, which are not on her dock (all 5 of them)
<xnox> she now has skype as the 6th item.
<sonne> \o/
<xnox> I bet she forgot what big fat button is for now.
<sonne> which button by the way? isn't the generic menu a button like all the others?
<mterry> pitti, heyo!  Got a sec to talk about apport's build-depend on python-pykde4?
<ScottK> mterry: What's the problem?
<mterry> ScottK, it's keeping some kde stuff like kdepim-runtime in main.  Meaning Kubuntu still has to do the whole MIR thing for some packages.  If we could move the tests it is used for to dep8 instead, we could drop the binaries from main
<ScottK> mterry: It's not just apport.  It's ubiquity and other things too.
<ScottK> Unless you're going to do a clean sweep, it doesn't help.
<mterry> ScottK, huh..  reverse-depends doens't show ubiquity
<mterry> for either python3-pykde4 or python-kde4
<ScottK> reverse-depends ubiquity shows ubiquity-frontend-kde.  That depends on python-kde4.
<Riddell> ubiquity-frontend-kde is in universe
<mterry> ScottK, yeah, not in main
<ScottK> Ah.
<mterry> reverse-depends -c main is much smaller (just apport)
 * micahg gets nothing
<mterry> micahg, reverse-depends -c -main -b python3-pykde4
<micahg> ah, python3
<mterry> and as a build-depend, not normal depend
<xnox> mterry: how does python-pykde3 in main results in MIR for other stuff?
<xnox> or do you want to extend python-pykde3 with extra dependencies which are not in main?
<ScottK> It depends on the other stuff.
<mterry> xnox, because it depends on kdepim-runtime, and when kdepim-runtime adds new dependencies, those get MIRd
<mterry> xnox, right
<xnox> ok.
<semitones> hello -- any installer developers here? I have a question about the installation iso, fat32 usb file system, and symbolic links
<mterry> And it requires more privileges for these arbitrary set of kubuntu apps
<xnox> there were talks to asking to split python-pykde4 into multiple packages. What exactly does apport depend on?
<xnox> can we have a small package with just that?
<Riddell> xnox: there were?
<mterry> xnox, python3-pykde4 just for some tests.  I wanted to see if pitti is ok with them only being run as dep8, which apport already uses
<mterry> that way, we don't have to install as a build-dep
<semitones> a file on the alternate cd failed integrity check, and when I mounted the iso to check what it was, it was a symlink that I couldn't copy over to the USB, because fat32 doesn't support symlinks -- is that known behavior?
<mterry> semitones, maybe #ubuntu-installer if you don't get an answer here
<xnox> mterry: ok, not a build-dep but as a regular Depends? Or can dep8 install arbitary additional dependencies? (I haven't used dep8 yet)
<semitones> mterry: thanks
<xnox> semitones: ah, ha! that's why it fails =) thanks a lot =)
<mterry> xnox, it is both, but the apport-kde binary can be dropped to universe.  The bulid-depend unavoidably keeps the depend in main
<mterry> xnox, yeah, dep8 can install arbitrary packages, post-build
<semitones> xnox: it pertained to your problem too?
<xnox> mterry: just do it -> install kde dep8 post-build. Where "just do it" is submit a merge proposal for review =)
<mterry> xnox, fair enough  :)
<xnox> semitones: yeah, usb-creator boots, rarely validated the iso for me. Now there is a valid suspect, as to why =)
<mterry> It certainly seems like pitti isn't around right now
<xnox> mterry: i think he is at GUADEC ;-)
<mterry> Ah...  Yeah, don't want to distract him with KDE questions while he's in GNOME's camp
<mcclurmc> i'm the upstream maintainer for a package in debian and ubuntu
<mcclurmc> we recently found that some default settings could lead to a security issue
<mcclurmc> i'm working with debian to update their package, and i'd like to release a fix for precise at the same time
<mcclurmc> is there an ubuntu-security mailing list that I can discuss this with, like debian-security?
<micahg> mcclurmc: you need something private?
<mcclurmc> that's the idea
<mcclurmc> or at least insight into the process for backporting a security fix to precise
<micahg> mcclurmc: cc security at ubuntu dot com
<mcclurmc> okay, thanks
<skunk_> Did any one try the windows 8 RC??
<skunk_> Its boot is way faster the 12.04.. Are there any plans to cut boot times in the next ubuntu release?? If not you guys should get on it! :)
<skunk_> does anyone even talk on here??
<ScottK> Not about Windows, not really.
<ScottK> Given /topic that's hardly surprising.
<skunk_> @ScottK I was just wondering about it.. Remember using 6.06 and it's boot and shutdown times were wayy faster then XP or vista on a P4
<udevbot> Error: "ScottK" is not a valid command.
<skunk_> ScottK, I was just wondering about it.. Remember using 6.06 and it's boot and shutdown times were wayy faster then XP or vista on a P4
<skunk_> it slowed down on 8.04.. and sped up again on 10.04.. Im wondering why for future plans.. is that rude? If so I apologize
<ScottK> Asking about people trying Windows 8 is off topic.  It's nothing to do with Ubuntu development.
<skunk_> yes it does have something about Ubuntu Development. Its about how Ubuntu compares to Windows 8.. and what the development team can do to keep competitive with it
<skunk_> if I said something like.. "have you ever tried greek pizza" im pretty sure that would be off topic
<Pici> skunk_: This isn't a discussion channel, its for pure development.
<Pici> Theres #ubuntu-offtopic (and #ubuntu-discuss) for talking about Ubuntu.
<skunk_> fine. I apologize. Ive been with this community for almost 7 years i don't problems with anyone
<ScottK> As long as you stop, it's not a problem.
<Laney> You /could/ be helpful by quantifying your impressions into workable bug reports though, by doing some proper analysis.
<skunk_> i do alot of bug reporting dude. trust me
<ScottK> Boot speed analysis is an area that needs people to get interested in and do some specialized work.
<ScottK> If it boots slow, it's not because it's intended to be slow, so it's valid work no matter what other O/S's do.
<slangasek> a major factor in Windows 8 speed improvements is going to be UEFI Fast Boot, which actually has nothing to do with the OS
<skunk_> Ubuntu has lots of work to do in alot of areas tho. Utouch , boot, power efficiency, etc. No offense, but it seems like it's falling behind osx and windows..
<skunk_> does the zietgeist framework support search a document by text content yet??
<skunk_> im pretty sure its written in vala
<dobey> skunk_: zeitgeist is not an indexing framework. it's a logging framework.
<skunk_> yeah i just realized that sorry
<dobey> skunk_: also, install osx on some random hardware from china, and let me know how that power management and such works out for you. :)
 * Laney gently nudges you away to the aforementioned other channels
<Shinobi> I've installed gnome shell from the launchpad ppa, but when I login via the Gnome (as opposed to the Gnome Classic) desktop, it only goes the the fallback gnome, not the full blown gnome3. Am I missing something?
<ScottK> Shinobi: #ubuntu-desktop is a better channel for such questions.
<Shinobi> ok thx
<bdrung> we can sponsor sync requests faster than other can deliver pizzas (example: 34 mins for bug #1029141)
<ubottu> Launchpad bug 1029141 in gscan2pdf (Ubuntu) "Sync gscan2pdf 1.0.4-4 (universe) from Debian unstable (main)" [Undecided,Fix released] https://launchpad.net/bugs/1029141
<micahg> bdrung: 18 minutes: https://bugs.launchpad.net/ubuntu/+source/birthday/+bug/1027711/+activity :)
<ubottu> Launchpad bug 1027711 in birthday (Ubuntu) "FFe: Sync birthday 1.6.2-4 (universe) from Debian unstable (main)" [Wishlist,Fix released]
<bdrung> micahg: wow, that's fast
<micahg> we aim to please :)
<bdrung> http://reports.qa.ubuntu.com/reports/sponsoring/ becomes the bottleneck, because it updated periodically
 * micahg occasionally culls them from #ubuntu-bugs-announce
<ScottK> I've been mostly fixing RC bugs in Debian and then syncing lately.
<SpamapS> bdmurray: seems to be a flaw in the "detect comments after SRU accepted" logic on the SRU report
<SpamapS> bdmurray: https://bugs.launchpad.net/ubuntu/+source/modsecurity-apache/+bug/988819
<ubottu> Launchpad bug 988819 in modsecurity-apache (Ubuntu Precise) "[SRU] wrong path to libxml2.so.2 in mod_security - broken by multiarch enabled libraries" [High,Fix committed]
<SpamapS> bdmurray: that should not be gold, because the next comment is just another accept to a different pocket
<bdmurray> SpamapS: it doesn't look gold to me in the report
<SpamapS> bdmurray: the second one is
<SpamapS> bdmurray: or rather, the precise one is
<bdmurray> I still don't see it
<bdmurray> ah for apache2
<bdmurray> not mod-proxy-html or modsecurity-apache
<bdmurray> SpamapS: Why is apache2 in precise-proposed?
<bdmurray> https://bugs.launchpad.net/ubuntu/+source/modsecurity-apache/+bug/988819/comments/29
<ubottu> Launchpad bug 988819 in modsecurity-apache (Ubuntu Precise) "[SRU] wrong path to libxml2.so.2 in mod_security - broken by multiarch enabled libraries" [High,Fix committed]
<SpamapS> bdmurray: it may want to be removed actually
<bdmurray> SpamapS: the code expects the upload and SRU comment to happen on the same day
<bdmurray> and the upload for apache2 was quite some time ago
<SpamapS> bdmurray: perhaps something went wrong w/ the comment?
<bdmurray> SpamapS: ? if you look at the lines for the modules neither of those are golden which is the expected behavior
<SpamapS> bdmurray: right, was confused by apache2 ;)
<bdmurray> I concede that the logic isn't great but this apache2 thing is a corner case I think
<SpamapS> totally
#ubuntu-devel 2012-07-26
<TheMuso> /c/c
<RAOF> ââ(13:48:%)ââ dpkg --compare-versions 1.4.0+git2012.is.really.1.4.0-0ubuntu1 gt 1.4.0+git20101207.0d32bb07-0ubuntu2 || echo false
<RAOF> false
<RAOF> What crazy subtlety of dpkg version comparing am I missing here?
<ajmitch> RAOF: so, using 1.4.0+git20120101.is.really.1.4.0-0ubuntu1 seems to work, though the date is now a lie
<micahg> right
<RAOF> Yeah, it's odd.
<micahg> no, it makes sense in the context of versioning
<RAOF> 1.4.0+git2012 > 1.4.0+git2010, but 1.4.0+git2012 < 1.4.0+git201001
<micahg> 20101207 > 2012
<RAOF> Ooooh.
<RAOF> dpkg treats *all* numbers in the version string as numbers rather than strings?
<micahg> http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version might be worth a read
<micahg> it goes chunk by chunk and compares AFAICT
<micahg> so, 1.4.0+git20101207.is.really.1.4.0-0ubuntu1 should also work
<mux_> Hi everyone, for my project I have decided to build a user-friendly desktop automation software for Ubuntu (like AppleScript and Automator). I know that ubuntu already has a powerful scripting environment (bash etc) So is it worthwhile to follow my idea?? Also what other features should i include to make it not redundant?? Thank You.
<lifeless> make it a) not suck and b) work with GUI programs.
<RAOF> To expand upon b) - you need to do something like hooking into GTKActions, which would be accessible via the same mechanisms as the HUD uses.
<mux_> RAOF: what is the demand for GUI desktop automation on linux...is it a problem worth solving?? or should we just tell users to learn BASH,python etc..?
<mux_> lifeless: how often do you find the need for such softwares on Ubuntu...?
<RAOF> mux_: The non-GUI scripting landscape is pretty solid.
<RAOF> mux_: It's also my understanding that one of the major features of AppleScript & Automator is that they *do* cover GUI apps.
<Sweetshark> Anyone here being able to help me debug that C++11 ABI mess? Starting LibreOffice on Quantal, New Presentation, Close -> Crash. Doesnt happen on precise.
<Sweetshark> I tried to make a sense out of LD_DEBUG=all output, but did not find anything obviously dirty injecting std::list<> symbols there.
<Sweetshark> mlankhorst: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1027043 <- here is the stacktrace
<ubottu> Launchpad bug 1027043 in libreoffice (Ubuntu) "soffice.bin crashed with SIGSEGV in std::list<Link, std::allocator<Link> >::remove()" [Medium,Triaged]
<Sweetshark> Has anyone a good systematic proposal on how to proceed?
<geser> Sweetshark: if nobody gives you a better idea, try to rebuild the LO (c++-based) dependencies with gcc-4.6 to check which ones "triggers" it (try boost first if you already didn't try it)
<Sweetshark> geser: all >1000 (direct and indirect) deps? *cough* and what do I do with the rest of my work items this cycle?
<geser> that many?
<Sweetshark> geser: LibreOffice integrates with everything -- thus it can get the dirty C++11 ABI from virtually anywhere in main.
<Sweetshark> geser: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1027043/comments/9 <- a feeble try at finding the source.
<ubottu> Launchpad bug 1027043 in libreoffice (Ubuntu) "soffice.bin crashed with SIGSEGV in std::list<Link, std::allocator<Link> >::remove()" [Medium,Triaged]
<geser> Sweetshark: did you ask chrisccoulson how he found the problematic library in his unity case?
<geser> Sweetshark: you could try to continue to "upgrade" it slowly (as far as dependencies allow it) towards quantal till you find the right package (or set of packages)
<goddard> how can i find out what a library is called so i can link it using cmake?
<mcclurmc> has the location for the R-series UDS been published yet?
<bluefoxxx> apparently people have made grub4dos load by 'kexec -l grub2.exe'
<bluefoxxx> has anyone managed to get grub itself to load via kexec?
<stgraber> seb128, NCommander: ping (12.04.1 meeting in #ubuntu-meeting)
<SpamapS> ugh, I think I stepped in bug 965371 ... this TLSv1.2 stuff is *sticky*
<ubottu> Launchpad bug 965371 in openssl (Ubuntu Precise) "HTTPS requests fail on sites which immediately close the connection if TLS 1.1 negotiation is attempted, on Ubuntu 12.04" [Medium,Triaged] https://launchpad.net/bugs/965371
<barry> slangasek: around?
<hallyn> so uploading to -proposed is also for hot bugs right, not just for low-prio features?
<micahg> hallyn: in a stable release?  it's not for features at all
<hallyn> no in quantal
<hallyn> during the current freeze
<micahg> it's for anything on an image or anything that will cause installability issues
<hallyn> ok
<micahg> hallyn: this email explains it: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2012-July/000968.html
<hallyn> hggdh: I'm going to push the fix for your qemu-kvm bug to q-proposed right now.
<hallyn> micahg: yeah, what i wasn't sure about was, for things which are blocking qa, is it worth pushing to quantal and respinning
<hallyn> i'm taking the asnwer as no
<hallyn> no wait :)
<micahg> hallyn: ask in #ubuntu-release :)
<hallyn> ok thanks :)
<mcclurmc> i'm the upstream maintainer for a package in debian and ubuntu. it depends on qemu, but the paths to qemu are different on Debian and Ubuntu. is there a standard way to maintain a patch on top of a Debian package, so that the Ubuntu package points to the right qemu location?
<micahg> mcclurmc: http://raphaelhertzog.com/2010/09/27/different-dependencies-between-debian-and-ubuntu-but-common-source-package/, see #4
<mcclurmc> thanks, micahg
<hggdh> hallyn: thanks
<mcclurmc> micahg: thanks for the link raphael's blog. unfortunately, it wasn't what i needed
<micahg> mcclurmc: not the specifics, but the general concept should be there (dpkg-vendor in debian/rules)
<mcclurmc> i need to be able to apply one patch to the upstream source if the package is on debian, and a different patch if the package is on ubuntu
<mcclurmc> is there a way in debian rules to selectively apply patches from debian/patches?
<micahg> mcclurmc: ah, then you need a series.DEBIAN and series.UBUNTU file in debian/patches
<mcclurmc> ah ha!
<mcclurmc> yes, i do need that :)
<tumbleweed> watch out for those, it's easy for them to become stale for the other distribution
<micahg> a lot of packages feed dynamic paths through debian/rules which is why I suggested the blog post
<tumbleweed> because you generally only work on one of them
<micahg> mcclurmc: right, both need the full set of patches
<mcclurmc> is there documentation for this? a quick google didn't find me anything
<PaoloRotolo> Hi all!
<micahg> mcclurmc: http://raphaelhertzog.com/2010/11/05/managing-distribution-specific-patches-with-a-common-source-package/
<mcclurmc> micahg: i should probably read the rest of his blog too, shouldn't i?
<micahg> heh, buxy tries hard to disseminate valuable information for distro collaboration
<adam_g> ScottK: re bug #1021530, is it correct to prepare a new package for -proposed with the patch that will fix the tests/FTBFS?
<ubottu> Launchpad bug 1021530 in openvswitch (Ubuntu Precise) "[SRU] update to include stable fixes for OVS 1.4" [Medium,Fix committed] https://launchpad.net/bugs/1021530
<ScottK> adam_g: Yes.  Also, if they have other fixes that meet the SRU criteria, they should be considered as well (as I mentioned in the bug).
<carif> i recently heard a rumor that jockey was going away, is that true? will there be a replacement?
<micahg> carif: https://lists.ubuntu.com/archives/ubuntu-devel/2012-July/035553.html
<carif> micahg, dude, ty!
* Laney changed the topic of #ubuntu-devel to: Quantal Quetzal A3 prep | Archive: Open (DIF) | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<Laney> hallyn: upload away
<skaet> thanks Laney
<Laney> np
* Laney changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open (DIF) | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<barry> kenvandine: ping
<kenvandine> barry, pong
<Laney> A3 is out. Get it while it's hot! :-)
#ubuntu-devel 2012-07-27
<StevenK> RAOF: Finally got around to filing a bug.
<RAOF> StevenK: About what in particular?
<StevenK> RAOF: My Nvidia display corruption, remember?
<RAOF> Oh. That one :)
<RAOF> So many bugs!
<xnox> so, I have uploaded an SRU and it has been accepted into -proposed, but one bug # was not mentioned in the changelog, and has not been mentioned in the changes and therefore is not in the sru-report. Is there any way to mark that bug as fix-committed and get the same comment and ideally manually add it to the sru report?
<xnox> bug 946758
<ubottu> Launchpad bug 946758 in mdadm (Ubuntu Precise) "Format string overflow in Monitor.c:check_array" [High,Triaged] https://launchpad.net/bugs/946758
<xnox> is part of the mdadm sru.
<tkamppeter> I havesome problems with a new Intel HD graphics PC
<tkamppeter> The mobo has only HDMI and DisplayPort output, but xrandr shows also a VGA output which is limited to 1024x768 and fully automatic startup falls aways into 1024x768.
<tkamppeter> How can I makethe login screen 1920x1080?
<ev> mpt: it does seem suspicious that the 12.04 and 12.10 lines are so closely mirroring one another http://10.20.66.232/
<mpt> ev, it's a 2-or-3-day trend now, so that rules out a mistake in calculating from the day fraction, right?
<mpt> (Would be a lot easier to see this if there was only one data point per day, ahem)
<ev> mpt: there is only one data point per day. Mouse over the graph
<ev> but yes, I still need to fix the axis
<mpt> ev, sorry, I meant axis tick mark
<mpt> ev, so in order from source to destination, possibilities: (a) fixes in Q, and to a lesser extent SRUs in 12.04, really have made Ubuntu more reliable the past couple of days
<mpt> (b) something changed in the client the past few days (did it?)
<mpt> (c) there's a date-specific problem that makes the client less likely to report errors
<ev> b> nope
<mpt> (d) there's a network problem between clients and the data center
<mpt> (3) there's a date-specific problem that makes the server less likely to accept error reports
<mpt> s/3/e/
<ev> yeah, I think we need more data before we know which of these it is
<mpt> (f) something changed in the server the past few days (no, since there hasn't been a rollout)
<ev> if you turn off the 12.10 line, the 12.04 line shows quite a bit more variability
<ev> (you can click the circles in the top right)
<mpt> It's smaller than the drop from the 19th to the 20th
<ev> yeah, true
<mpt> so I concur with the need for more data :-)
<Sweetsha1k> mpt: did you get my reply wrt fonts in libreoffice btw?
<mpt> Sweetshark, yes thank you. I'm planning to discuss it further today.
<mdeslaur> infinity: FYI, I'm stealing your mono merge to get a security fix
<Sweetshark> mpt: great
<infinity> mdeslaur: Sure, it's a simple merge, go nuts.
<infinity> mdeslaur: Or I could do it right now.
<infinity> mdeslaur: If you don't want TILM. :P
<mdeslaur> infinity: I'm uploading it as we speak
<infinity> mdeslaur: Alrighty.
<mdeslaur> infinity: but I'm using your gpg key, so you'll still be TIL :)
<infinity> mdeslaur: Suuuure you are.
<mdeslaur> hehe :)
<infinity> Thanks for the reminder that I need to get that change committed to Debian, though.
<infinity> We really shouldn't be carrying the delta.
<smoser> jodh, i have a upstart job named 'cloud-config', is it silly/wrong/ok that that job would emit 'cloud-config' ?
<jodh> smoser: that's fine. Make sure you include 'emits cloud-config" in the job to ensure 'initctl check-config' works of course.
<smoser> to ensure?
<jodh> smoser: it means that you'll get sane results from initctl2dot (and it means that 'initctl show-config' is parseable too).
<smoser> ok, thank you.
<smoser> 'emit cloud-config' added.
<smoser> err.. emits
<smoser> jodh, SpamapS i wonder if either of you have any experience with 'runit'
<smoser> it seems it doesn't interact well with upstart if installed via cloud-init.
<smoser> i run an instance with http://paste.ubuntu.com/1113891/ as userdata.
<SpamapS> smoser: there are two components of runit. One of them is a pid 1 replacement, and that definitely does not work with upstart
<smoser> and then it seems to stop boot once runit is installed.  --verbose log at http://paste.ubuntu.com/1113895/
<smoser> oh. wow.
<smoser> i didn't realize it was a pid 1 replacement.
<SpamapS> well the other bit is just a daemon
<SpamapS> smoser: in the past it did a dpkg-divert of /sbin/init
<SpamapS> smoser: but I think the one installed there is the "safe" one
<SpamapS> smoser: but looks like nobody has tested it on Ubuntu in a while ;)
<SpamapS> grep: /etc/inittab: No such file or directory
<smoser> yeah, i saw that bug figured it was just the postinst script not working right.
<smoser> but basically the install of it stops further events from happening.
<smoser> ie, my cloud-final.conf never runs.
<smoser> SpamapS, you interested in looking at a system really quick? (i'm fine if the answer is no)
<smoser> ubuntu@ec2-23-22-213-255.compute-1.amazonaws.com
<SpamapS> smoser: yeah I'll poke it. This feels like bug triage to me. :)
 * SpamapS plans on spending all day on triage to help us catch up
<SpamapS> smoser: security groups
<smoser> SpamapS, ? you should be able to get in
<SpamapS> hanging at connecting
<xnox> slangasek: bug #946758
<ubottu> Launchpad bug 946758 in mdadm (Ubuntu Precise) "Format string overflow in Monitor.c:check_array" [High,Triaged] https://launchpad.net/bugs/946758
<xnox> slangasek: https://bugs.launchpad.net/ubuntu/precise/+source/mdadm
<smoser> SpamapS, http://paste.ubuntu.com/1113904/
<smoser> i can get in from here.
<smoser> that is weird.
<ScottK> barry: Bug #1029640 looks to me like a good one to get fixed before 12.04.1.  Checking to see if you agree?
<ubottu> Launchpad bug 1029640 in python2.7 (Ubuntu Precise) "Bad characters in Python logger output when using rsyslog" [High,Triaged] https://launchpad.net/bugs/1029640
<SpamapS> smoser: totally. I'm bouncing off my ec2 instance in us-west-1 and its working
<smoser> SpamapS, thanks.
<xnox> infinity: wanna talk about e2fsprogs? =)
<barry> ScottK: looking
<ScottK> Thanks.
<barry> ScottK: yes, it would be nice to have a test case for the sru
<ScottK> That's what I'm waiting for before I upload.
<infinity> xnox: Not really, but I suppose we should. ;)
<xnox> infinity: lol =))))
<infinity> xnox: Make me some coffee, please, I'll be with you shortly.
<xnox> infinity: ok. here or mumble?
<infinity> IRC's fine.  Let me go get some waking up done.
<ScottK> You can tell a spec's going well when the diff is:
<ScottK> - Work items for quantal-alpha-3:
<ScottK> + Work items for ubuntu-12.10-beta-1:
<infinity> ScottK: Oh, regarding our bug log argument.  If you're happy with better trumping perfect for now, poke me on the weekend when I'm not hip-deep in glibc, and we can make backports less sad.
<ScottK> infinity: Great.  I'll try to remember to do that (being ancient and all, no promises)
<infinity> ScottK: It's actually fairly trivial to go the easy route (as in, no code changes, just a quick tweak to chroots, times X releases, times Y arches)
<ScottK> Cool.
<infinity> At least, assuming that pins can override NotAutomatic's anti-pin.
<infinity> If not, then we need to think harder about it.  Or try to implement perfection.
<infinity> But, my assumption is that pinning the pocket to 500 will override the 100 it's getting automagically.
<infinity> We'll experiment and see a bit later.
<ScottK> Great.  Have fun with the glibc.
<ScottK> It'd be trading unusable for suboptimal, so it's not a hard choice.
<xnox> ScottK: well, tbh it has more progress implementation wise than it ever had...
<ScottK> xnox: Certanly.  I wasn't meaning to pick on anyone.
<ScottK> I just thought it was ironic.
<dobey> barry: is libpeas stuff using python3 yet? or do you have a timeframe for that?
<xnox> plus we did mile-stones before the schedule got changed (e.g. the alpha-3 got moved by -1 week)
<xnox> ScottK: yeah it is funny though =)
<barry> dobey: afaik, libpeas should be good to go
<dobey> barry: are gedit/rhythmbox/etc using it with python3 already then?
<barry> dobey: those clients afaik have not yet been ported
<dobey> barry: will rhythmbox be soon? our plug-in for it is in python, so wondering when i need to get it working under python3 by
<barry> dobey: it's not the next thing on my list, and i'm pretty well booked up until mid-aug.  any way i can help you or someone else to take that on?
<dobey> not sure, i don't really have time to do it either. :-/
<barry> dobey: yeah.  i'd love to see some community contribution around this, but i'm not sure how to help that happen
<dobey> not sure exactly either, at the moment. :-/
<dobey> need to get lunch now though. bbiab
<oly_> hi, got a small packaging issue, i am packaging a mixed python / c program got everything working fine but i get an error complaining the .pyc files where included how do i stop dpkg-buildpackage creating these ?
#ubuntu-devel 2012-07-28
<ksbalaji> Now-a-days somehow I feel that a few persons have left from the development team. This is not to hurt anybody please. A lot of unstabilities in LTS 10.04 could be the reason to feel this way
<simplew> is there a recent quantal dvd release?
<shadeslayer> kirkland: ping
<shadeslayer> kirkland: is there some documentation available on how to make sure your encrypted home dir is preserved when installing a new version of ubuntu?
<Bluefoxicy> $ sudo ntpdate-debian
<Bluefoxicy> 28 Jul 09:21:20 ntpdate[19646]: step time server 91.189.94.4 offset 141.846034 sec
<Bluefoxicy> this started happening on a kernel upgrade months ago, since then I have changed out my motherboard and gone from an AMD platform to an Intel platform
<Bluefoxicy> and moved to SSD, which required a full re-install (try as I might, I can migrate Ubuntu from hard drive to hard drive but it simply will NOT boot if I migrate it onto an SSD)
<beezy> i am fairly new to ubuntu and i am very happy with the neew 12.04 version however i am running it on thinkpad wich is a older laptop and it seems to be running sluggish. i am trying to figure out how to download "damn small linux" because it is much smaller and may run better on my system. if anyone can help i greatly appreciate it
<beezy> can anyone help me in this matter please/
<beezy> if anyone can help me with my problem please e-mail me @ beezyboy26@gmail.com
<imjustmatthew> If there's a working patch for a bug on Launchpad, how do I go about getting it merged and packaged for precise?
<ScottK> imjustmatthew: First it has to get fixed on quantal.
<ScottK> Needs a debdiff for quantal attached to the bug and then subscribe ubuntu-sponsors.
<imjustmatthew> ScottK: Okay, I'll try that, thanks
<infinity> imjustmatthew: What's the bug?
<infinity> imjustmatthew: (A debdiff isn't strictly necessary, if the patch is clear and obviously correct, I'd be happy to sponsor it)
<imjustmatthew> infinity: Bug #809221
<ubottu> Launchpad bug 809221 in mountall (Ubuntu) "unable to mount ceph root at boot due to stripping of trailing slashes" [Medium,Triaged] https://launchpad.net/bugs/809221
<imjustmatthew> I think I've built a correct debdiff, but it may be against precise; I dget'ed the quantal package, but the chagnelog tool labeled it as precise and I didn't feel confident enough to change it
<ScottK> imjustmatthew: the current release is the default in debchange (the changelog tool).  It's independent of the contents of the package.
<infinity> imjustmatthew: Why have the conditional strip_slashes in the ceph branch of the if?
<infinity> imjustmatthew: Are there situations where it's correct to strip ceph slashes?
<infinity> imjustmatthew: (Seems to me that if 127.0.0.1:/ is valid, then 127.0.0.1:/foo/ would also be valid, but your patch you unnecessarily strip the latter?)
<infinity> s/strip/strips/
<infinity> But I don't know ceph, so maybe :/foo/ isn't valid, but :/foo is?
<infinity> (If so, then wow, that's a pretty awful design for a UI to make :/foo/ invalid, but :/ valid...)
<imjustmatthew> infinity: Both <host>:/foo and <host>:/foo/ are valid, but <host>: is never valid
<infinity> imjustmatthew: Check, hence why I'm questioning why you'd ever strip_slashes.
<infinity> +            devlen = strlen(mnt->device);
<infinity> +            if ( devlen < 2 || strcmp(mnt->device + (devlen - 2), ":/")) {
<infinity> +                strip_slashes (mnt->device);
<infinity> ^-- That bit.
<infinity> +            }
<imjustmatthew> infinity: For some reason the original code had a strip slashes in it, I don't know why it would ever be necessary
<infinity> The first part of the conditional is equally confusing to me.  if (devlen < 2) strip_slashes() would assume that the device is "/" and you're reducing it to an empty string.  Is that sane?
<infinity> The original code is for dealing with other dev types, where stripping slashes from the end makes sense.  But once you've added the (! strncmp (mnt->type, "ceph", 4)) conditional, I'm struggling to see why it has a branch that still sometimes strips.
<infinity> Oh, I just realised you're not the author of the original patch.  That doesn't help here. ;)
<imjustmatthew> infinity: You're probably right that it's never necessary
<infinity> If only damoxc were around.  I guess I'll follow up to the bug.
<imjustmatthew> infinity: yes, but I'm also the one who wants it in the repos so I don't have to maintain a custom package :)
<infinity> Well, I would sponsor it without that conditional, but I'd prefer to talk to Damien to get his rationale for why it's there, first.
<infinity> So, let's see if he responds if I comment on the bug.
<imjustmatthew> okay, you have my e-mail, shoot me a line if there's something you need to get it finished
<imjustmatthew> thanks for your help
<infinity> imjustmatthew: Is "/" ever a valid device for ceph?
<infinity> (Looking at the first part of the conditional...)
<imjustmatthew> infinity: yes :/ mounts the entire filesystem, everything else is a subdirectory mount
<infinity> https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/809221/comments/4
<ubottu> Launchpad bug 809221 in mountall (Ubuntu) "unable to mount ceph root at boot due to stripping of trailing slashes" [Medium,Triaged]
<infinity> Commented on the bug.  We'll see if Damien (or someone else who understands it) responds.
<infinity> I don't like applying patches "blind" unless the code is obviously correct to me, and this looks a tiny bit wonky to me.
<infinity> (The rest of the code is obvious and straightforward, mind you)
<imjustmatthew> infinity: np, I understand completely
#ubuntu-devel 2012-07-29
<simplew> i have unsqash quantal live cd and there is no vmlinux file installed in /boot so how is ubuntu going to boot ???
<simplew> hello?
<simplew> glebihan: hi
<simplew> glebihan: can you point where i can download quantal live cd?
<megawattz> can someone help i tried to install ubuntu 12.04 LTS 32bit but everytime it loads to install i get a black screen
<ScottK> megawattz: Help is in #ubuntu.
<megawattz> thx
<mosdef673738> hi there is it actually poss to design apps in ubuntu
<sarnl> How to show an exported GMenu in unity?
<Quintasan> \o
<kirkland> shadeslayer: pong
 * penguin42 is kind fo surprised something in lp or something doesn't stop a source package releasing binaries if a patch in it fails to apply; bug 1027432
<ubottu> Launchpad bug 1027432 in binutils (Ubuntu) "patch rejected during unpack" [Medium,Triaged] https://launchpad.net/bugs/1027432
<shadeslayer> kirkland: need to migrate encrypted home folder to new install, where does one find docs??
<bkerensa> apw: Is Inkscape not going to be brought to 0.49 in Quantal?
<simplew> i hve run "update-initramfs -u" but i continue not having no /boot/vmlinuz file to be able to boot ubuntu, any help?
<scientes> what decides if a package is "technical" in software-centre?
<ion> Whether it has a desktop file or not probably.
#ubuntu-devel 2013-07-22
<pitti> Good morning
<pitti> slangasek: udev sru> wiki page says "one week without a regression report" (of which we didn't get any, I'm subscribed to udev bugs)
<pitti> slangasek: lp retracers> mostly me; unfortunately the failure cron mail sometimes doesn't get set, so I don't notice errors often
<pitti> slangasek: restarting i386 one, it indeed was crashed
<pitti> gdb segfaulted, yay
<pitti> slangasek: we don't stop them on transient LP bugs any more, I fixed that ages ago
<pitti> but for anything unexpected we do, but I need to get told about them
<pitti> slangasek: so the uninvestigated issue is "sometimes cron mail doesn't get sent" :/
<robert_ancell> pitti, I think I remember you complaining about the autotools tests no longer producing output on server builds - did you ever come up with a clever solution for that?
<robert_ancell> The dreaded see tests/test-suite.log which you can't see
<pitti> robert_ancell: for umockdev I just switched back to the serial test runner
<robert_ancell> pitti, what is the incantation for that?
<pitti> robert_ancell: for debian/rules you might use something like "dh_auto_test || { cat testsuite.log; exit 1 }
<pitti> but that's unwieldy for upstream
<robert_ancell> pitti, ah, I was trying to do that but my shell-fu failed me
<pitti> robert_ancell: add "serial-tests" to AM_INIT_AUTOMAKE
<pitti> robert_ancell: but hang on, I actually removed that again, as with that you can't build on automake 1.11 and older any more
<pitti> robert_ancell: so now I don't use the AM test runner at all, and do it by hand: https://github.com/martinpitt/umockdev/commit/25c46869f18
<cjwatson> I think the parallel runner is enough of a good thing that it's worth small workarounds such as the above || { ... } hack to continue being able to use it.
<pitti> I didn't find an equivalent for that for upstream Makefile.am, though
<robert_ancell> cjwatson, yeah, I like it too :)
<cjwatson> pitti: https://lists.gnu.org/archive/html/automake/2013-06/msg00051.html ?
<cjwatson> Though I guess that requires that target to be invoked explicitly
<pitti> the "display-testsuite-logs" looks like a manual one
<pitti> and "require am >= 1.12" is not an option
<pitti> as I want this to work in daily PPA builds
<pitti> and also don't fend off developers on stable releases
<cjwatson> pitti: Actually, doesn't VERBOSE = yes work for you?  AFAICT it only doesn't work for James' quite specialised requirement that he wants to show the test log even for passed tests
<pitti> cjwatson: I'll try that (need to run off for a bit)
<TheMuso`> c
<dupondje> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1203211 => Somebody can check this out ? :)
<ubottu> Ubuntu bug 1203211 in linux (Ubuntu) "Modprobe doesn't recognize any parameters on 3.10.0-4" [Undecided,Confirmed]
<pitti> cjwatson: adding "VERBOSE = yes" to Makefile.am has no visible effect here
<pitti> "make check VERBOSE=yes" seems to  help, though
<pitti> ah, "export VERBOSE = yes" helps
<cjwatson> Right, it's used as a shell variable not a make variable
<pitti> wgrant_: hm, still nothing on https://translations.launchpad.net/ubuntu/saucy/+language-packs ?
<Laney> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: Laney
<jamespage> doko, available for a chat re go policies?
<doko> jamespage, in 15min, need a coffee ....
<ejat> friends-app : Depends: qtdeclarative5-hud1.0 but it is not installable
<ejat> ?
<infinity> ejat: Are you running -proposed?  friends-app installs fine here on saucy without proposed.
<infinity> ejat: If you're using proposed, don't. :P
<doko> mlankhorst, ping
<doko> tjaalton, ping
<mlankhorst> pong
<mlankhorst> what's up
<doko> mlankhorst, please see message
<Laney> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<seb128> apw, hey, thanks for the lightdm patch ... it looks good to me, you should perhaps upload, robert_ancell is not going to be online before another half a day and it seems quite some users are running into the bug
<seb128> apw, can you upload the fix and do a merge request for it on trunk? or do you prefer if I do that?
<apw> seb128, i can do that no problem, if you know where the master one is, it doesn't seem to have a link in the pakcaging
<seb128> apw, just propose the fix for upstream code (e.g lp:lightdm), there is no packaging vcs afaik
<apw> seb128, ahh great will do so indeed
<seb128> apw, thanks
<barry> uh oh.  looks like the greeter is feeling unhappy this morning.  super tiny font syndrome
<jodh> pitti: got a fix for the zero-length core files - bug 1203744
<ubottu> bug 1203744 in apport (Ubuntu) "apport typo means disks not synced on upstart crashes" [Undecided,New] https://launchpad.net/bugs/1203744
<apw> seb128, merge proposed:https://code.launchpad.net/~apw/lightdm/lp1203711-fix-uninitialised-glist/+merge/176193
<apw> seb128, and i am just re-testng for upload
<seb128> apw, excellent, thanks!
<pitti> jodh: argh, brown paperbag one.. thanks!
<pitti> jodh: saucy has 2.11-0ubuntu1, which is what is in bzr (that even has a staged commit which isn't uploaded)
<pitti> jodh: it's in Vcs-Bzr:, not the UDD branch
<jodh> pitti: ok, thanks.
<zul> mterry:  ping any update on python-heatlclient?
<mterry> zul, not yet.  I'll assign or review today
<rbasak> mdeslaur: OK for me to touch apache2? I want to merge 2.4.6-1 to fix bug 1202653.
<ubottu> bug 1202653 in apache2 (Ubuntu) "apache2 2.4.4-6ubuntu4 failed to upgrade: Cannot load /usr/lib/apache2/modules/libphp5.so into server: undefined symbol: unixd_config" [High,Triaged] https://launchpad.net/bugs/1202653
<mdeslaur> rbasak: sure, thanks!
<rbasak> Great, thanks.
<xnox> rbasak: that's my bug! \o/
<xnox> rbasak: thanks!
<doko> I HATE ARCH INDEP all PACKAGES!
<doko> -dev packages even
<davmor2> doko: use ubuntu instead of arch /me runs for the bunker............ :D
<pitti> rbasak, jibel, apw: hm, in today's saucy /dev/kvm doesn't exist any more; dmesg says "kvm_intel: Unknown parameter `nested'"; known?
<pitti> ah, /etc/modprobe.d/qemu-system-x86.conf:options kvm_intel nested=1
<pitti> modinfo kvm_intel still shows it, though
<apw> pitti, yes a known issue, will be fixed in the next upload
<pitti> apw: thanks
<apw> pitti, parameter handling has gone to pot
<jodh> pitti: bug 1203211.
<ubottu> bug 1203211 in linux (Ubuntu) "Modprobe doesn't recognize any parameters on 3.10.0-4" [Critical,In progress] https://launchpad.net/bugs/1203211
<rbasak> When doing a merge, is it normal to include changelog entries for bugs fixed by virtue of them being fixed in Debian? Or should I just make sure to include those bug numbers in my changes file?
<xnox> rbasak: if debian used "LP: #NNNNNNN" you are fine (in addition to Closes: #), otherwise in your merge changelog you'd need to include "LP: #######", or otherwise the bug will stay open, and you'd have to manually close it.
<cjwatson> rbasak: I occasionally stick a parenthesised comment in about such-and-such a Debian version fixing such-and-such an LP bug
<cjwatson> But sometimes it reads oddly and I just close manually
<xnox> rbasak: look at the .changes file and make sure there is LP-* bugs closing stanza in there with things you want to close.
<xnox> may require -v option, when building the source package.
<rbasak> OK, got it, thanks. In this case Debian used LP: #XXX so I should be fine. I'll make sure to check the changes file.
<doko> roaksoax, ping
<slangasek> pitti: hmm, would you like to add me to the cron mail, so I could help track it down?
<pitti> slangasek: that's for the apport retracers?
<slangasek> pitti: yeah
<pitti> seb128: did you get apport failure cron mail recently? I didn't
<pitti> slangasek: done; but I have a feeling that the problem is on the sending side
<slangasek> pitti: sure, I expect so too - but at least this doubles the odds of someone noticing that the mails haven't been sent :)
<pitti> indeed
<seb128> pitti, I got an email on friday from the dup checker, that's all recently
<pitti> seb128: yes, I got that one, too
<pitti> but never one from the i386 crash
<doko> seb128, pitti: is glib2.0 buildable without python-gi and python-dbus?
<cjwatson> bdmurray: copy-set-phase now available
<cjwatson> bdmurray: So if we deploy set-pup now, is the cron job already running somewhere sensible and will it adjust the phases up over time?
<SpamapS> nobody    2444  0.0  0.0  28900  1528 ?        S    Jul21   0:00 /usr/sbin/dnsmasq --no-resolv --keep-in-foreground --no-hosts --bind-interfaces --pid-file=/var/run/NetworkManager/dnsmasq.pid --listen-address=127.0.1.1 --conf-file=/var/run/NetworkManager/dnsmasq.conf --cache-size=0 --proxy-dnssec --enable-dbus=org.freedesktop.NetworkManager.dnsmasq --conf-dir=/etc/NetworkManager/dnsmasq.d
<SpamapS> what is the point of having a local dnsmasq..
<SpamapS> if --cache-size=0 ?!
<jbicha> zul: there's a typo with horizon, it depends on python-neturonclient
<zul> jbicha: ?
<jbicha> shouldn't it be neutron?
<zul> jbicha:  crap thanks for spotting it
<zul> jbicha:  ill fix that up
<jbicha> neturon does sound kinda cool though
<pitti> doko: glib2.0 python-gi and python-dbus sound like test dependencies; you certainly don't need them for build
<xnox> pitti: yeah, i thought so to. trying to use jhbuild to cross-bootstrap gnome =)
<jdstrand> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: jdstrand
<doko> xnox, pitti: thanks, in that case I won't need the jhbuild
<xnox> doko: yeah, but autoconf cache is incomplete for arm64 =)
<doko> xnox, ?
<xnox> well, not enough to cross-compile glib. going through it now.... unless the cache is not loaded, one sec.
<doko> ahh
<xnox> compiling. and it needs to be taught about multiarch include dirs *sigh*
<roaksoax> mterry: so I've been looking into the test of libqb and haven't been able to find a way to fix them. So I'll disable the failing ones for now, since it is blocking other packages that I need to upload to have a functional cluster stack in saucy
<mterry> roaksoax, OK, but can you file a bug to fix the rest of them and assign to someone (maybe you) for tracking purposes?  It would be nice to see those addressed, in case they are real problems
<roaksoax> mterry: I talked to the debian maintainer too and he's also gonna look into that.
<roaksoax> and will do
<roaksoax> :)
<roaksoax> mterry: done! https://launchpad.net/ubuntu/+source/libqb/0.14.4-1ubuntu1 should be published soon
<mterry> roaksoax, don't know what's wrong with my IRC, but I'm all over the place  :(
<roaksoax> mterry: :(
<roaksoax> mterry: thanks! :)
<xnox> too hot, must shut down my pc
<ari-tczew> xnox: or buy a cooling mat
<mterry> roaksoax, thank you!
 * ScottK has set his laptop on a bag of ice before.
<ScottK> Need to take it off before condensation gets too bad though.
<dobey> anyone know why this command line would result in a file that is statically linked, rather than a dynamic lib? http://pastebin.ubuntu.com/5901979/
<sarnold> dobey: wild-guess territory, perhaps one of the .o files was compiled without -fPIC? does 'file' on all the .o files look sensible?
<dobey> sarnold: yeah, all ELF LSB relocatable SYSV not stripped
<slangasek> dobey: "statically linked" - defined how?  what does file say on the resulting object?
<dobey> slangasek: ldd says "statically linked", file says "dynamically linked"
<dobey> so uh, wtf :)
<slangasek> what does objdump -p $file | grep NEEDED' say?
<dobey> slangasek: it's empty
<dobey> (the library has no symbols at the moment, but this problem only happens on saucy, not on raring)
<slangasek> there's no way that command could result in a statically linked object with no missing refs, because you're passing the path to the .so's specifically - the linker isn't going to randomly substitute the .a's
<slangasek> oh
<slangasek> "the library has no symbols at the moment" is exactly your problem.
<slangasek> the linker has outsmarted you
<dobey> but why is it only an issue on saucy?
<dobey> ld is trying to be smart?
<slangasek> I thought this default was changed pre-saucy, but maybe not
<slangasek> but in any case, the default behavior is -Wl,--as-needed
<dobey> on raring ld reports the libc and ld deps
<dobey> err, ldd reports
<slangasek> so if you ask to link to a library that you don't actually need, ld discards this reference
<slangasek> you can force the linkage with -Wl,--no-as-needed for testing
<dobey> that's fine, but ldd reporting "statically linked" is obviously wrong
<slangasek> not really
<slangasek> it has no dynamic library dependencies
<slangasek> so it's statically linked
<slangasek> the definition of a dynamically linked library is one that has external runtime dependencies.  This library has none, so it's a statically linked library (by virtue of the fact that it's completely empty).
<dobey> ls
<dobey> so i should just ignore lintian complaining about the shlibs for now?
<slangasek> whether the library is statically linked is entirely unrelated to whether it's *consumable* as ashared library
<slangasek> the shlibs are for the latter, and the lintian error ought to be fixed
<robert_ancell> mterry, how did you mark the mir MIR "no longer affects unity-system-compositor"?
<dobey> slangasek: thanks. would you mind taking a look at https://bugs.launchpad.net/ubuntu/+bug/1199017 ? finally got the issues fixed with symbols exporting and that as-needed problem. just decided to drop the empty lib from the packaging for now.
<ubottu> Ubuntu bug 1199017 in Ubuntu "[needs-packaging] ubuntuone-credentials" [Wishlist,New]
#ubuntu-devel 2013-07-23
<jdstrand> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<Kaleo> http://www.indiegogo.com/projects/ubuntu-edge/ amazing
<lifeless> jamesh_: ping
<jamesh> lifeless: hi.
<lifeless> jamesh: django-openid-auth - can we get a release of the current code to pypi ?
<jamesh> I'll get on it.
<lifeless> jamesh: briliant, thanks!
<jamesh> was a bit busy yesterday with other stuff so didn't get round to responding :(
<lifeless> jamesh: thats ok
<lifeless> jamesh: I can be a squeaky wheel when needed :)
<micahg> pitti: can you merge mutagen?   it seems some things build dep on the new version, I'd be happy to do it if you want
<pitti> Good morning
<pitti> micahg: yep, will do now
<micahg> pitti: thanks
<pitti> micahg: uploaded
<pitti> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: pitti
<darkxst> pitti, hey!
<pitti> hey darkxst, how are you?
<darkxst> good thanks
<ivanka> morning rickspencer3
<rickspencer3> hiya ivanka
<seb128> ev: hey
<ev> hiya
<seb128> ev: "* Move the .so file from libwhoopsie-preferences0 to libwhoopsie-preferences-dev." ... you need to make libwhoopsie-preferences-dev Replaces libwhoopsie-preferences0 (<< update-version)
<ev> gah, sorry and thanks for the catch
<ev> fixing
<seb128> ev: otherwise updates are going to break, depending of the order where things get unpacked
<seb128> ev: yw
<ev> seb128: would you mind quickly spot checking this: http://paste.ubuntu.com/5903513/
<seb128> ev: +1
<ev> whoop
<ev> Laney: regarding moving diagnostics as a subdir under security-privacy (https://code.launchpad.net/~ev/ubuntu-system-settings/diagnostics/+merge/174385/comments/394002) do you mean just in the build tree, or do you want them to effectively be the same plugin?
<Laney> ev: Well, diagnostics will be a part of security & privacy
<Laney> UI-wise it's fine ATM
<Laney> but yeah, I mean to move them in the source tree
 * ev nods
<ev> off to figure out how to do that in qmake
<ev> Laney: how's that http://paste.ubuntu.com/5903621/
<Laney> ev: yep, if that works - looks good
<ev> it does :)
<ev> cheers
<doko> mlankhorst, uploaded. my changes are not nice, but it builds ...
<pitti> jibel: did you happen to have a look at https://code.launchpad.net/~racb/ubuntu/saucy/autopkgtest/lxc/+merge/172856 already?
<mlankhorst> doko: ok I'll put them in ubuntu packaging at one point :p
<rbasak> pitti: thanks for looking. Actually I'll mark that wip - there are a couple of issues I've found since that I need to investigate.
<pitti> rbasak: ack, thanks; I don't currently have an LXC setup here to test (using schroot/sbuild), and was asking jibel because I think he has
<xnox> doko: about bug 1202153 do I need to reproduce with fsf toolchain and file a bug there, and in the mean time build with gcc-4.7?
<ubottu> bug 1202153 in gcc-4.8 (Ubuntu) "drizzle encounters compiler ICE on 32bit" [Undecided,New] https://launchpad.net/bugs/1202153
<jibel> pitti, I didn't yet, I'm buried into daily-release testing on touch, I'd like to release it today or tomorrow
<pitti> jibel: no worries, rbasak just said he still wants to make some changes
<doko> xnox, I think there is a debian report too
<xnox> doko: you mean http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=701269 ? merging that didn't help, and i had that applied already.
<ubottu> Debian bug 701269 in src:drizzle "drizzle: ftbfs with GCC-4.8" [Serious,Fixed]
 * xnox ponders if me generating source package on amd64 somehow leaked into the upload.
<doko> xnox, I'll redo the debian build ...
<ev> anyone know offhand of a qt-based package that does dbus service activation right?
<ev> on the consuming end, that is
<ev> QDBusInterface.isValid() seems to either be not what I want, or only half of the puzzle.
<ev> god I miss google codesearch
<Laney> try Debian codesearch
<ev> jodh: where's my solr?
<ev> ooh
<jodh> ev: you mean opengrok :)
<ev> Laney: that's definitely a step in the right direction. Thanks!
<ev> jodh: that doesn't sound very webscale.
<jodh> ev: I can't see through all the buzz-words on the solr page to see what file formats it actually understands... apart from pdf, html and .doc that is...
<ev> I'm just toying with you. I'm sure opengrok would be the more appropriate fit.
<Laney> ev: I guess maybe you have to watch for NameOwnerChanged too
<Laney> I think I probably need to do that as well in my panel
<ev> Laney: yeah, stackoverflow suggests that as well: http://stackoverflow.com/questions/1423739/waiting-for-a-dbus-service-to-be-available-in-qt
 * Laney nods
<ev> you'd figure the convenience API would handle this sort of thing.
<Laney> gotta love boilerplate
<pitti> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<marga> How do I indicate in a bug that it is present in Precise but not present in Quantal onwards?
<marga> Ah, I don't seem to be able to do it.
<marga> https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/1004515
<ubottu> Ubuntu bug 1004515 in gdm (Ubuntu) "segfault in accounts-daemon when logging in / gdm crash if user account is added or deleted" [Undecided,Confirmed]
<marga> One user accidentally clicked "Fix Released", but it was a mistake.
<marga> The bug is still present in Precise, and is not present in any later version.
<seb128> marga, you mark it fix released and do "also affect precise"
<marga> Where is that?  I only see "Also affects distribution" and "Also affects project"
<micahg> seb128: only bug control members can target to release
<seb128> micahg, other can propose for a serie though
<micahg> not for a while now (it was being abused)
<marga> :(
<marga> I always saddens me when nice features have to be blocked due to abuse
<micahg> sorry, devs can target, bug control can request
<JackYu> seb128: hi, I submitted two sponsor requests for two new packages at bug #1203958 and bug  #1203931,  would you please help me to upload them?
<ubottu> bug 1203958 in UbuntuKylin "[needs-packaging] unity-china-photo-scope" [Critical,New] https://launchpad.net/bugs/1203958
<ubottu> bug 1203931 in UbuntuKylin "[needs-packaging] unity-china-video-scope" [Critical,New] https://launchpad.net/bugs/1203931
<marga> I'm really sad that I took quite a number of hours to track down the bug and the fix, I created the patch following SRU rules, then waited and waited for the sponsor... And then I get sponsors unsubscribed because it's marked as "Fixed released", when the user that marked it says in the log that it was a mistake. :(
<seb128> JackYu, hey, can you try to pitti or barry (they are patch pilot todayÃ 
<seb128> )
<JackYu> seb128, okey, thanks:)
 * barry will likely be piloting in 4h
<Ampelbein> marga: I targeted 1004515 to precise and resubscribed the sponsors team.
<marga> Ampelbein, tnx
<xnox> bug 1004515
<ubottu> bug 1004515 in accountsservice (Ubuntu Precise) "segfault in accounts-daemon when logging in / gdm crash if user account is added or deleted" [Low,Triaged] https://launchpad.net/bugs/1004515
<seb128> marga, (sorry was in a call, reading backlog)
<seb128> marga, sorry about that, don't hesitate to ping here when bugs get wrongly closed or when they are not in the right status and you don't have the right to reopen
<marga> tnx
<JackYu> barry, hi, would you please help to sponsor two new packages at bug #1203958 and bug  #1203931 when available?
<ubottu> bug 1203958 in UbuntuKylin "[needs-packaging] unity-china-photo-scope" [Critical,New] https://launchpad.net/bugs/1203958
<ubottu> bug 1203931 in UbuntuKylin "[needs-packaging] unity-china-video-scope" [Critical,New] https://launchpad.net/bugs/1203931
<xnox> hmm.... my kvm is broken on saucy. Is there something I can do to unbreak it?
<barry> JackYu: happy to look, but it will be a few hours
<rbasak> xnox: could this be related to bug 1203211? Are you running 3.10.0-4, and if so try "modprobe kvm_intel"?
<JackYu> barry, that's great, thanks.
<ubottu> bug 1203211 in linux (Ubuntu) "Modprobe doesn't recognize any parameters on 3.10.0-4" [Critical,Fix committed] https://launchpad.net/bugs/1203211
<xnox> marga: uploaded. Had to add a bug reference number, seems like bug 1067414 became a dupe of 1004515 in the mean time, so added both just in case sru-report gets confused.
<ubottu> bug 1004515 in accountsservice (Ubuntu Precise) "duplicate for #1067414 segfault in accounts-daemon when logging in / gdm crash if user account is added or deleted" [Low,In progress] https://launchpad.net/bugs/1004515
<yolanda> pitti, i saw your comments about libnss-ldap, it's ok for me to take a look at the changelog
<marga> xnox, thanks.
<yolanda> actually i grouped some of the entries because it was very messi, but i know it can be done better
<xnox> rbasak: yes, that's the one.
<xnox> rbasak: so i guess i can reboot into older one in the mean time.
<xnox> thanks a lot.
<tseliot> pitti: is there a way to use jockey with unsigned repositories? (even a hack, just for local testing)
<wgrant> pitti: The langpack crontab changes have been deployed now, so you should get something in a couple of days.
<wgrant> Friday morning, I guess
<shadeslayer> kenvandine: poke poke https://bugs.launchpad.net/ubuntu/+source/empathy/+bug/1203336
<ubottu> Ubuntu bug 1203336 in empathy (Ubuntu) "decouple account-plugin-* and mcp-account-manager-* from empathy" [Undecided,New]
<pitti> wgrant: ah, thanks muchly
<pitti> tseliot: I'm afraid you'd have to disable that check in the code
<kenvandine> shadeslayer, i would love to have that decoupled
<pitti> tseliot: i. e. where it allows "arch: all" packages unsigned
<shadeslayer> kenvandine: hurray
<tseliot> pitti: right but there is also another condition: "and not pkg.candidate.uri.startswith('file:/')"
<tseliot> pitti: so it shouldn't affect my local repository
<kenvandine> shadeslayer, but upstream says it isn't trivial
<pitti> tseliot: ah, so it should just work then
<shadeslayer> kenvandine: oh? I didn't see the plugins linking to empathy in any way
<tseliot> pitti: good, thanks
<shadeslayer> kenvandine: just a runtime dep?
<kenvandine> shadeslayer, empathy has a private libempathy that is needed for the plugins provided by empathy
<shadeslayer> kenvandine: oh ... ldd didn't say anything about that
<kenvandine> shadeslayer, yeah, it's confusing
<shadeslayer> :)
<stgraber> jbicha: ping
<jbicha> stgraber: hi
<stgraber> jbicha: I'm looking at bug 1196667, it looks like there are at least two packages currently depending/recommending appmenu-gtk/appmenu-gtk3, can you get those fixed first?
<ubottu> bug 1196667 in appmenu-gtk (Ubuntu) "Please remove appmenu-gtk from Ubuntu" [Undecided,New] https://launchpad.net/bugs/1196667
<stgraber> jbicha: that's kubuntu-full and kubuntu-desktop
<Riddell> mm?
 * stgraber checks the seeds
<stgraber> stgraber@castiana:~/data/code/sync-blacklist$ reverse-depends appmenu-gtk
<stgraber> Reverse-Recommends
<stgraber> ==================
<stgraber> * kubuntu-desktop
<stgraber> * kubuntu-full
<stgraber> Riddell: ^
 * jbicha defers to Riddell
<stgraber> Riddell: ah, I see you have it in you desktop seed for some reason, I'm assuming -full then gets it as it's a superset of -desktop
<Riddell> yeah it will
<jbicha> well I believe appmenu-gtk used to work with KDE's appmenu implementation but the new unity-gtk-module doesn't
<Riddell> so appmenu-gtk is obsolete?
<jbicha> yes, it's unmaintained and won't build
<roaksoax> cjwatson: howdy! I have a quick question. If a package sits in -proposed for depwait, and then I manaully trigger the build again (through lp), and it builds successfully. Does it gets moved out of proposed automatically? Or needs manual intervention? or should I upload a no change rebuild?
<stgraber> Riddell: the equivalents would be unity-gtk2-module and unity-gtk3-module but they may indeed be incompatible and may pull extra stuff you don't want
<cjwatson> roaksoax: doesn't need manual intervention, doesn't need a reupload
<roaksoax> cjwatson: how long will it sit there then?. I told LP to rebuild last night and it is still sitting in -proposed.
<roaksoax> cjwatson: package: corosync
<cjwatson> roaksoax: then something else is wrong
<cjwatson> trying: corosync
<cjwatson> skipped: corosync (1 <- 75)
<cjwatson>     got: 102+0: i-102
<cjwatson>     * i386: booth-pacemaker, clvm, cman, gfs-pcmk, gfs2-cluster, gfs2-utils, libccs-dev, libccs-perl, libccs3, libcrmcluster1, libcrmcluster1-dev, libfence-dev, libfence4, ocfs2-tools-pacemaker, pacemaker, pacemaker-dbg, pacemaker-dev, pacemaker-mgmt, pacemaker-mgmt-dev, redhat-cluster-suite, rgmanager, sheepdog
<cjwatson> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt
<stgraber> Riddell: so I don't really care whether you just drop those two packages or you move to unity-gtk2-module and unity-gtk3-module, but I'd like to remove appmenu-gtk from the archive, so let me know which of the two options you want and I'll take care of changing the seeds and uploading.
<cjwatson> roaksoax: given the changes involved here, I expect you have a library transition that you need to deal with
<Riddell> stgraber: I've removed them from the seeds now
<Riddell> stgraber: and updating kubuntu-meta
<stgraber> Riddell: cool, are you germinate+uploading the meta too?
<stgraber> awesome
<stgraber> I'll wait for that to land in the release pocket before processing the removal so I don't break your builds and/or updates
<jbicha> Riddell: see bug 1200006
<ubottu> bug 1200006 in gtk+2.0 (Ubuntu) "appmenu-gtk support dropped, but unity-gtk-module doesn't work outside unity" [Undecided,New] https://launchpad.net/bugs/1200006
<roaksoax> cjwatson: right, so there should really be there no change for package depending in corosync and its libs. The lib remains to be the same version, new libs have been added though.
<cjwatson> roaksoax: proposed-migration disagrees and it's usually right :)
<roaksoax> cjwatson: yeah I'm looking into why it might be :). Thanks!
<cjwatson> roaksoax: I suspect perhaps a binary package got dropped?
<cjwatson> roaksoax: There's libcfg4 -> libcfg6 at least
<roaksoax> cjwatson: Maybe, but most packages would depend on libcorosync4 or libcorosync-dev which still exists. But yes that might also be one of the reasons. I'm looking into that now! Thanks!
<cjwatson> libconfdb4, libcoroipcc4, libcoroipcs4, libevs4, liblogsys4, libpload4 dropped
<cjwatson> libtotem-pg4 -> libtotem-pg5
<cjwatson> libvotequorum4 -> libvotequorum6
<cjwatson> installing cman in saucy-proposed tries to install libconfdb4 for instance
<cjwatson> indeed cman directly depends on libconfdb4
<roaksoax> yeah, i just spotted that myself. but redhat-cluster-suite is material to be dropped from the archive altogether
<roaksoax> but don't know whether that will happen now
<infinity> roaksoax: If these are all ABI bumps but not API bumps, rebuilding things is trivial.
<cjwatson> pacemaker depends on libconfdb4 directly
<roaksoax> cjwatson: not anymore, newer pacemaker version doesn't use it. Which i'm about to upload.
<cjwatson> And sheepdog Depends: libcfg4
<cjwatson> roaksoax: it's not "not anymore" until it's in the archive and ready for migration itself :P
<roaksoax> :)
<dbarth> hi, can i ask a quick one for multi-arch experts?
<dbarth> this an issue with a citrix package requiring libwebkitgtk-1.0-0:i386 which depends on libwebkitgtk-1.0-common:i386
<dbarth> but only libwebkitgtk-1.0-common:all is available (both on precise and raring)
<cjwatson> Somebody should probably make libwebkitgtk-1.0-common Multi-Arch: foreign
<dbarth> ok, so same as flahplayer installer or something
<cjwatson> Not really but whatever :)
<dbarth> which i think had the same issue; now fixed in saucy i think
<dbarth> ok, i can make a merge prop and see if a test package fixes the problem
<cjwatson> Lots of stuff needs M-A annotations, it's rather dramatically well beyond flashplayer
<dbarth> ok, then i've spotted one
<cjwatson> libwebkitgtk-1.0-0 could use being properly converted to multiarch, but that's a separate problem
<dbarth> thanks for the quick feedback
<dbarth> well, yes
<mpt> ev, have you diagnosed the July 9th spike yet?
<ev> mpt: not yet - I've been staying away from Cassandra stuff with the database being in quite a bad way at the moment. I hope to get to that this week though. Adding a reminder.
<mpt> k
<tedg> jodh, Can I use libupstart without a NIH mainloop?
<xnox> tedg: but NIH loop is wonderful =)))) why would you?
<tedg> xnox, Because I already have a glib one.  Having two is no fun.
<xnox> i think stgraber before had something before to use one or the other, or both. Not sure if it was glib or qt mainloops with nihloop.
<Laney> xnox: where's the vcs for libtimezonemap?
<xnox> Laney: lp:timezonemap
<jodh> tedg/xnox: yes, stgraber had issues with multiple main loops with the dconf-bridge which is now in my court. I guess you don't need to use the nih main loop, but you still need to create NIHDBusProxy objects, etc.
<stgraber> xnox: it's the dconf bridge which uses libnih for some bits and glib for the rest, though the loop is glib, trying to get glib to run part of the nih loop or the opposite blew up quite badly
<Laney> xnox: lies
<Laney> oh
<Laney> without the 'lib'
<Laney> grr
<tedg> jodh, Okay, I just can't use the async stuff.
<stgraber> xnox: I was basically trying to call the single iteration function every time the other loop would run but that didn't quite work as well as it should have
<jodh> stgraber: right, I'm currently having to essentially "rewrite" bits of NIH in GDBusProxy for the dconf-bridge as there is no way that I can see to convert between all the DBus/GDbus/NihDBus types.
<xnox> Laney: that's gtk3 one, there is older project under different name for gtk2
<tedg> jodh, That should generally be fine, but then how does nihdbus get the signals back?
<tedg> How does upstart-monitor do this?  Is it just all GLib?
<jodh> upstart-monitor just uses GLib to monitor the EventEmitted signal.
<jodh> tedg: NIH handles the async dbus responses by calling nih_main_loop_add_func(nih_dbus_callback) where that callback just calls dbus_connection_dispatch repeatedly until the result != DBUS_DISPATCH_DATA_REMAINS.
<tedg> I guess I was worried that there'd be no watch on the file handle for the dbus connection.
<tedg> As the GLib main loop wouldn't select it.
<Laney> xnox: I'd appreciate it if you could review/upload timezonemap today so that I can BD on that version from system-settings
<Laney> if you have time etc
 * Laney proposed the merge
<xnox> Laney: I better do it now, as I am off until monday =/
<Laney> xnox: or I can just upload and you can fix bzr later
<Laney> (or someone else; I guess it's not a team of 1 :P)
<xnox> Laney: meh, easy, will do in a sec
<Laney> awesomes, thanks
<xnox> Laney: well, ev is admin, mterry is lurker, and i am the minion on the team.
 * Laney cracks the whip
<xnox> Laney: not in public =))))
<Laney> ^o)
<xnox> Laney: uploaded.
<Laney> thanks
<Laney> now go have a nice holiday :P
<xnox> Laney: thanks :P
 * ev feeds the minion
 * mterry lurks
<ev> lol
 * xnox nom nom
<ari-tczew> pitti: hi! thanks for sponsoring. I'm sorry for FTBFS in postgis. I did the buildtest only on i386.
<lfaraone> Anybody in ~ubuntu-security got a minute?
<sarnold> hey lfaraone :)
<barry> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: barry
<blitzkrieg3> idia
<robert_ancell> mterry, hey, will you still be able to run u-g8 as a mir server if you also make it support running as a mir client? (-> #ubuntu-mir)
<robert_ancell> pitti, here?
<achiang> is there a quick 'n dirty way to find number of armhf packages without spinning up a VM?
<achiang> some web interface would be swell
<jpds> achiang: wget http://ports.ubuntu.com/dists/saucy/main/binary-armhf/Packages.gz; gunzip Packages.gz; grep "^Package:"" | wc -l
<infinity> achiang: https://launchpad.net/ubuntu/saucy/armhf
<infinity> achiang: Or, if you prefer: https://api.launchpad.net/1.0/ubuntu/saucy/armhf
<achiang> jpds: infinity: thanks!
<roaksoax> infinity: howdy! Do you happen to know why pacemaker remains as "New" and does not seem to be "released" into -proposed? https://launchpad.net/ubuntu/+source/pacemaker/1.1.9+git20130321-1ubuntu1
<xnox> roaksoax: have you checked proposed-migrations?
<roaksoax> xnox: yeah nothing about pacemaker
<xnox> roaksoax: queues?
<xnox> roaksoax: https://launchpad.net/ubuntu/saucy/+queue
<xnox> roaksoax: pacemaker starting building new packages, one can see if expands a build. thus it requires an Archive Admin to review and accept or reject them.
<roaksoax> xnox:ah I see
<xnox> roaksoax: usually they accept =) there are only a few archive admin, but things are processed from time to time.
<xnox> roaksoax: until then, britney will think it's out of date.
<xnox> roaksoax: by the way, pacemaker is mentioned on the excuses page.
<roaksoax> yeah I just saw that too
<xnox> roaksoax: http://people.canonical.com/~ubuntu-archive/proposed-migration/ see excuses, pacemaker - out of date on bunch of arches, not considered.
<roaksoax> xnox: yeah that's what I just saw. Which doesn't make sense to me
<xnox> this means britney will not even attempt migrating, as it's not fully build on all arches it previously was built on.
<xnox> that =)
<xnox> roaksoax: wait, or poke infinity / stgraber / Daviey to process new in saucy =)
<roaksoax> yeah I'll just wait. Since I'm EOD anywya :)
<roaksoax> xnox: thanks for the info
<xnox> no problem =)
<ari-tczew> I guess there is a similar bug like on MoM @ http://qa.ubuntuwire.com/bugs/rcbugs/saucy/
<ari-tczew> It doesn't take Ubu-version from -proposed.
<ari-tczew> Correct me if I'm wrong.
<cjwatson> Sure, it just needs NEW processing
<cjwatson> I'll do it now
<cjwatson> proposed-migration doesn't see things in NEW, which is why it thinks it's out of date
<ari-tczew> cjwatson: ok!
<ari-tczew> cjwatson: are you on the bug 1202142 as well?
<ubottu> bug 1202142 in Merge-o-Matic "Blind to new development release -proposed pocket" [High,Triaged] https://launchpad.net/bugs/1202142
<cjwatson> It's on my list
<cjwatson> And no, proposed-migration doesn't have a bug where it doesn't know about -proposed.  It would be entirely useless if it did :-P
<cjwatson> Given that its entire purpose is to migrate things from -proposed
<Laney> I think he thought you were referring to the previous question about the rcbugs page, when in fact you were not
<cjwatson> roaksoax: You can drop the libcorosync-dev and libqb-dev deltas from pacemaker at the next merge - we no longer need lower versions there
<cjwatson> roaksoax: It might then be worth build-testing to see if the added Build-Depends: libcfg-dev is still necessary, since if it isn't we can just sync pacemaker unmodified
<cjwatson> Ah, I see, indeed I was not referring to rcbugs, sorry
<ari-tczew> okok
<cjwatson> Wouldn't be surprising if it had a similar bug
<cjwatson> roaksoax: NEWed
<cjwatson> roaksoax: Won't help on its own of course, since at least redhat-cluster-suite and sheepdog still need to be resolved too
<cjwatson> Looks like sheepdog is blocked by a couple of build failures
<roaksoax> cjwatson: I already have a sheepdog fix, and we are dropping redhat-cluster-suite from the archives (or maybe we;'ll just leave it as a transitional package), but all its binaries will disappear
<cjwatson> I did say "resolved", not necessarily fixed
<roaksoax> cjwatson: the problem with pacemaker is that in debian, it is build-dep/dep in a revision of corosync that does not exist in debian, hence it would FTBFS in UBuntu without the delta
<cjwatson> Point is, don't expect corosync to enter the release pocket until that's done, not just planned
<cjwatson> roaksoax: That's not true in the version I checked.
<cjwatson> roaksoax: The versions used in Debian experimental exist in Ubuntu just fine
<roaksoax> cjwatson: http://packages.qa.debian.org/c/corosync.html experimental shows 2.3.0-1, and pacemaker was Build-dep/dep on 2.3.0-2
<roaksoax> cjwatson: and yes, I'll get those two (sheepdog/redhat-cluster) fixed this week
<cjwatson> How is that relevant when it's 1.4.4-3 in saucy?
<cjwatson> Oh, 2 > 1
<cjwatson> Counting hard
<roaksoax> yeah so, this is a "major" upgrade of the cluster tools, so pacemaker 1.1.9 depends on corosync > 2.X
<cjwatson> roaksoax: OK, fair enough on libcorosync-dev, but that doesn't explain libqb-dev
<cjwatson> saucy has 0.14.4-1ubuntu1, so there's no need to drop the build-dep minimum version from 0.14.4 to 0.14.3
<cjwatson> And libcorosync-dev depends on libcfg-dev, so on the face of it there doesn't seem a reason to introduce an Ubuntu delta to have pacemaker build-depend on libcfg-dev as well as libcorosync-dev
<cjwatson> Looks like the only thing you still need is to drop the libcorosync-dev version
<cjwatson> And harass Debian about fixing that properly in experimental
<cjwatson> Then we can just sync pacemaker
<roaksoax> cjwatson: yeah the thing is that libcorosync-dev is just a transitional package
<cjwatson> Hm, it seems kind of anti-transitional if it's stopped depending on libcfg-dev in -proposed
<cjwatson> It could just as well have kept that dependency to smooth the transition further
<cjwatson> Anyway, minor details
<roaksoax> cjwatson: I spotted an issue in the corosync package (the -dev didn't depend on its libraries), so that might be the reason why I had to add the dependency on libcfg-dev while keeping libcorosync-dev
<roaksoax> and the reason why I lowered the versioning for libqb was because when I initially worked on this there was no libqb 0.14.4. Debian had just been updated when I was to upload to the arcvhive
<roaksoax> or I think i made another upload with the newer version, yeah that was it
<cjwatson> roaksoax: *nod*
<roaksoax> cjwatson: thanks for looking at it though! :)
<TheMuso> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: barry, TheMuso
<ahasenack> does anybody have a tip on how to add a ppa to a local sbuild build?
<micahg> pass  --chroot-setup-commands='apt-get install -y python-software-properties' --chroot-setup-commands='add-apt-repository ppa:myppa/foo' --chroot-setup-commands='apt-get purge -y python-software-properties' --chroot-setup-commands='apt-get update'
<micahg> replace myppa/foo appropriately
<ahasenack> ok, yeah, I was going down that route
<ahasenack> I also need sudo
<micahg> ahasenack: why do you need sudo?
<ahasenack> I think it's how I created this chroot, a long time ago
<ahasenack> it has my user, binds my home, etc
<ahasenack> and in raring it's software-properties-common, ok
<micahg> ISTR someone has a wrapper to make this easier
#ubuntu-devel 2013-07-24
<roaksoax> cjwatson: still around? can you check where my iupload for crmsh go?
<roaksoax> (it is a new package)
<roaksoax> uhmmm weird, I might have messed up and uploaded it somehwere else
<TheMuso> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: barry
<pitti> Good morning
<pitti> robert_ancell: I am now
<robert_ancell> pitti, I emailed you a question about apport. No rush though
<pitti> robert_ancell: ah, good
<pitti> robert_ancell: I responded in bug 1204284, is that what you want to know?
<ubottu> bug 1204284 in mir (Ubuntu) "Apport hook not packaged" [Medium,Triaged] https://launchpad.net/bugs/1204284
<pitti> robert_ancell: ah, I'll respond to your mail as well, there was a different q
<robert_ancell> pitti, thanks, that looks like it
<pitti> robert_ancell: responsed to mail as well, that might be an interesting alternative
<pitti> wgrant: ooh, a saucy langpack! thanks
<wgrant_> pitti: Oh, earlier than I expected.
<cjwatson> roaksoax: It was unlucky enough to coincide with a brief period yesterday when there was a problem on the Launchpad database server, and so failed.  I've asked for the upload to be reprocessed
<pitti> infinity: I built the first saucy langpacks, just testing
<pitti> infinity: would this be a bad time to throw 800 packages at the buildds for some reason?
<pitti> infinity: maybe you can update the chroots before?
<pitti> infinity: (all build queues empty)
<diwic> TheMuso, around?
<dholbach> good morning
<pitti> infinity, lamont: FYI, temporarily recruiting allspice and roseapple for i386 duty
<infinity> pitti: Might not have been the best time since there's an Alpha in progress, but meh.
<pitti> infinity: yeah, I was originally hoping to get them into the images, but there were some delays in the LP export side; I guess they'll just wait in -proposed until after the freeze
<infinity> pitti: Assuming they're in the block of doom.
<infinity> Ahh, which they are.
<cjwatson> The new sources probably aren't, but hey.
<seb128> sarnold, hey, do you have any estimate on when you are going to review bug #1186553? it has been waiting for security review for 8 weeks, would be nice to get that unblocked so we can update webkit...
<ubottu> bug 1186553 in libwebp (Ubuntu) "[MIR] libwebp" [Undecided,New] https://launchpad.net/bugs/1186553
<henrix> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: henrix, barry
<Laney> ev: do you know when we'll get the new activity-log-manager?
<seb128> Laney, ev: oh, yes, please don't make the system settings conflict with ubuntu-desktop (don't add that new depends until the conflicts is resolved by updating alm in saucy)
<Laney> right
<ev> Laney: I'll sort that out now unless there are objections
<Laney> ev: Change the depends or update a-l-m? Either is fine by me if it works :-)
<ev> update a-l-m. Change what depends?
<Laney> u-s-s -> activity-log-manager | whoopsie-preferences
<Laney> Also, good job on finding QDBusWatcher - works well!
<ev> oh right
<Laney> ServiceWatcher
<ev> and cheers
<Laney> I didn't manage to dig that one up
<doko> tkamppeter, ping
<doko> tkamppeter, why does ghostscript build with the embedded openjpeg?
<doko> tkamppeter, and please check if it links to the external lcms2 now
<tkamppeter> doko, GS uses internal openjpeg due to fixes which were not upstream that time and internal liblcms2 due to an API addition (for threaded use) which was not upstream that time (see debian/changelog, versions 9.06~dfsg~20120803-0ubuntu1, 9.06~dfsg-0ubuntu1, 9.07~dfsg-0ubuntu1, 9.07~dfsg2-0ubuntu1). I will re-check with the next upstream release (9.08) which will get released before FF end of August.).
<diwic> cking, ping
<cking> diwic, pong
<diwic> cking, I'm getting questions from Intel about our power management policy
<diwic> cking, in particular, why power management is disabled when AC power is connected
<cking> diwic, can you forward me those questions from intel?
<diwic> cking, i e, /sys/devices/.../power/control is always on
<cking> diwic, which release?
<diwic> cking, I think he's on 12.04
<cking> diwic, can you send me the emails and I will get onto it sometime this week
<diwic> cking, forwarded, but it's more of a generic "Does anyone know the Ubuntu power-policy on laptop?" question
<smoser> ok... odd question for this channel.
<smoser> is it possible to get genisoimage for osx ? if not that then how about mtools
<slangasek> smoser: there's certainly nothing fundamental in genisoimage that prevents it building on osx.  I don't know if anyone provides builds though, if that's what you're asking.
<smoser> slangasek, thtas what i'm asking. having never used it. i have no idea even what to google for.
<smoser> "osx genisoimage" didn't help much
<ogra_> smoser, first hit for me http://www.brucedavidson.me/install-cdrtools-on-mountain-lion/
<ogra_> (though i used "mountain lion" replacing "osx"
<ogra_> )
<slangasek> smoser: "fink genisoimage"?
<slangasek> or what ogra_ said
<smoser> see, i'm so uphip to apple that I don't know if slangsek's "fink" comment was a joke or not.
<smoser> but, thanks ogra_ .
<slangasek> smoser: fink has nothing to do with being hip to apple, it's an apt-get for OSX ;)
<ogra_> wasnt that UNIX in general ?
 * ogra_ think he remembers using it on old SGI machines 
<ogra_> *thinks
<slangasek> ogra_: fink was a project for OSX
<slangasek> a port of apt-get
<slangasek> (well, 'apt')
<ogra_> hmm, then the fink i thinnk about might have been another project
<roaksoax> cjwatson: coolnthanks!
<ev> mpt: meet the thing that's going to solve all our problems: http://www.acunu.com/acunu-analytics.html
<ev> err http://www.acunu.com/uploads/1/1/5/5/11559475/070913_aa_datasheet_v5.pdf
<pitti> Laney: OOI, did you force the propagation of https://launchpad.net/ubuntu/+source/gvfs/1.17.2-0ubuntu3?
<Laney> pitti: not me
<Laney> check bzr log of the hints branch
<pitti> Laney: gvfs' tests fail because it cannot modprobe scsi_debug, apparently some weird kernel regression
<Laney> was it a -4 thing?
<pitti> Laney: ah, I was wondering how it propagated
<Laney> I guess /someone/ did, but it wasn't me :-)
<pitti> Laney: could be; I'll re-run the test now
<pitti> Laney: "the hints branch"?
 * pitti checsk https://code.launchpad.net/~ubuntu-release
<pitti> ah, there
<Laney> lp:~ubuntu-release/britney/hints-ubuntu/
<Laney> Also, that reminds me. I got an email for that failure but I was the sponsor - shouldn't the uploader have gotten it (as well? he wasn't in To:)
<pitti> Laney: ah, there we go, http://bazaar.launchpad.net/~ubuntu-release/britney/hints-ubuntu/revision/269
<tedg> cjwatson, With click 0.2.6 I'm getting an exception when trying to install packages.
<pitti> Laney: in theory, yes; jibel, is that a bug of that particular uplaod (jbicha does have public mail addresses in LP), or we don't do that in general?
<cjwatson> tedg: traceback?
<tedg> cjwatson, Ah, I think I got it... it seems to be that the package needs a path?
<cjwatson> tedg: I don't know, what are you running?
<tedg> cjwatson, hmm, no.  It might be just me.  But in my ~/Desktop directory they won't install.  But copying to /tmp makes things happy.
<tedg> cjwatson, Seems like root should have access to Desktop... but eh, not a click issue.
<cjwatson> tedg: Could I please have an actual example and traceback and stuff? :)
<tedg> cjwatson, heh, http://paste.ubuntu.com/5907638/
<tedg> cjwatson, command: $ sudo click install --force-missing-framework com.ubuntu.ubuntu-clock_0.5_all.click
<JackYu> barry, hi, we have updated the source code at bug #1203931, would you please check it again for us:)?
<ubottu> bug 1203931 in UbuntuKylin "[needs-packaging] unity-china-video-scope" [Critical,New] https://launchpad.net/bugs/1203931
<barry> JackYu: i've put it on my list (a.k.a. browser tab :)
<JackYu> barry, wow, great, tks.
<cjwatson> tedg: Missing --user=tedg (or similar)
<cjwatson> tedg: Or use pkcon
<cjwatson> Though indeed that's unrelated to this tb
<cjwatson> Dunno why root wouldn't have access to ~/Desktop/
<tedg> cjwatson, Is it because of dpkg --force-not-root ?  Does that put it as a different user that might not have access?
<tedg> Or is that "not root directory"
<pitti> wgrant, StevenK: I'd appreciate a quick assessment how much work bug 1201485 would be for a proper LP fix
<ubottu> bug 1201485 in langpack-o-matic "Need to import translations for the unity daily builds" [Undecided,Triaged] https://launchpad.net/bugs/1201485
<JackYu> barry, I'm not clear about the ' It's confusing to also include the source since the tarball will be downloaded.'. Do you mean we not include the debian/ in the source tarball?
<cjwatson> tedg: No, it's not --force-not-root, although now that I think about it, the install runs as user clickpkg, not root
<cjwatson> tedg: So maybe we need to arrange to copy the .click file first, or to pipe it in, or something
<cjwatson> tedg: Could you file a bug on click?
<barry> JackYu: my own personal suggestion is to have two separate branches, one for what will turn into the "upstream tarball", essentially the thing that will create the tar.gz you upload to LP, and a second branch which only includes the debian/ directory for packaging.  the former wouldn't include a debian/ and the latter would *only* have the debian/ dir
<barry> JackYu: kind of like these:
<barry> https://code.launchpad.net/~ubuntu-system-image/ubuntu-system-image/client
<barry> https://code.launchpad.net/~ubuntu-system-image/ubuntu-system-image/client.pkg
<tedg> cjwatson, Sure, will do.
<wgrant> pitti: We'd need to copy an additional type of custom uploads. I think that should be relatively easy, but I'll have to investigate a bit.
<cjwatson> Yeah, following the refactoring I did for UEFI copies I think it should be easy enough
<JackYu> barry, wow, I see... You mean in different branches.
<barry> JackYu: right.  it's not a requirement, so do what works best for you guys.  it's just that i've tried a bunch of different arrangements, and this separation works best for me.  i think it will also be more conducive to creating a ppa recipe and such.
<JackYu> barry, it's a good suggestion:).
<barry> JackYu: :)
<barry> JackYu: it also makes it so much easier to review and sponsor
<barry> (for me anyway)
<JackYu> barry, yep, it make work easier. I will discuss this with our team.
<barry> JackYu: sounds great.  just ping me when you decide and/or have the new branches ready
<ahasenack> hi, is there a way for a build to know if it's happening inside a ppa builder?
<mpt> ev, "roll-up cubes on data" sounds delicious.
<ahasenack> I would like to disable a test conditionally, because it requires a launchpad login and network access
<ahasenack> I was wondering if there was some env var (ok, it's a launchpad question, not strictly ubuntu-devel)
<JackYu> barry, we will create debian/ branch for these two projects  tomorrow (since it's almost middle night here:) ).
<JackYu> barry, I have updated the tarballs, please check if they are good when you are availably, thanks in advance:).
<ev> mpt: lol
<henrix> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: barry
<barry> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<barry> JackYu: sounds good!
<barry> JackYu: have a good night
<lfaraone> so while trying to fix LP #1204195 on raring, I noticed that for some reason all of the changes in various patches are being collapsed into a single debian-changes by the builder, despite not happening when I run debuild -S locally. see https://luke.faraone.cc/pub/openafs_1.6.1-2ubuntu2.1_amd64-20130723-2115.build
<lfaraone> why might this be happening / what should I do to fix this?
<ubottu> Launchpad bug 1204195 in openafs (Ubuntu Saucy) "OpenAFS Security Advisories 2013-0003 and 2013-0004" [Critical,Confirmed] https://launchpad.net/bugs/1204195
<lfaraone> this strangely did not happen on precise, https://luke.faraone.cc/pub/openafs_1.6.1-1+ubuntu0.2_amd64-20130723-2113.build
<cjwatson> That's part of your source package, not done by the builder
<cjwatson> I mean, not done by Launchpad builders
<cjwatson> In that log you're building the source package too
<lfaraone> cjwatson: sure. but why don't I get that behaviour when I run debuild locally?
<cjwatson> lfaraone: Dunno, it seems to be reasonably sensibly picking up --single-debian-patch from debian/source/options within the build; perhaps you have an elderly dpkg-dev?
<lfaraone> cjwatson: https://luke.faraone.cc/pub/openafs_1.6.1-2+ubuntu2.1_source.build.cobalt is my local build output
<lfaraone> cjwatson: ah, I'm using precise locally.
<lfaraone> Removing debian/source/options fixed the issue.
<kenvandine> jamesh, if you're around, with one minor fix to your unity-lens-friends MP, i'll approve it
<jamesh> kenvandine: hi.  I've been meaning to get back to that MP.  I can actually reinstate some of that code I deleted, since I added a "notify shell that results have changed" call to the new API
<kenvandine> jamesh, awesome, even better :)
<jamesh> kenvandine: what change did you want?
<kenvandine> the path to the module in the scope file
<kenvandine> the .so gets installed in libdir
<kenvandine> not /usr/lib/unity/
<jamesh> $(libdir) rather than $(libdir)/unity ?
<kenvandine> multiarch libdir
<jamesh> ah.
<kenvandine>  /usr/lib/x86_64-linux-gnu/unity/unity-scope-friends.so
<jamesh> I should be able to swing that.  I'll probably have to do the substitution by hand rather than via configure so it doesn't end up as '${prefix}/lib/unity/...' on a default build
<kenvandine> yeah
<jamesh> I'll see about making the change tomorrow.  It's late here now
<kenvandine> jamesh, thanks, good night!
<roaksoax> Daviey: if you have a minute, could you process (accept) crmsh (it's in the NEW queue :))
<Daviey> roaksoax: I can't review it right this moment, sorry
<Daviey> I can later.
<roaksoax> Daviey: that works! thanks :)
<doko> seb128, xnox: how do I build gtk+3.0 without having libatk-bridge2.0-dev?
<doko> and libatk-bridge2.0-dev needs gconf for the build, and that wants gtk+-3.0 ...
<doko> --without-atk-bridge ?
<Laney> doko: configure.ac suggests you have to disable the x11 backend
<seb128> doko, libatk-bridge2.0-dev shouldn't need gconf
<seb128> doko, that build-depends seem buggy, let me try in a pbuilder
<doko> Laney, seb128, yes, gconf2 doesn't seem to be necessary
<seb128> doko, I already uploaded an update to drop it
<doko> thanks
<roaksoax> can someone please process crmsh from the saucy new queue?
<NCommander> ogra_, ping, how do we handle rootfs in flash-kernel these days. It doesn't appear to be set anywhere on the kernel commandline anymore.
<ogra_> hmm, it should, by d-i or ubiqiuty ... for pandas we had a /etc/default/flash-kernel that held the defaults (like we do for grub)
 * ogra_ hasnt touched f-k in a long time
<NCommander> ogra_, well you did the last upload :-), I haven't touched it since precise
<NCommander> ogra_, looking on a highbank system, we're not seeing it on bootargs; I get this sinking feeling that this is a bug
<NCommander> ^- infinity - any insights?
<infinity> NCommander: It's in boot.script on omap4, I forget what highbank does, as I didn't write that support.  But it works, afaik, so it must be doing something right.
<infinity> mahmoh, dannf: ^^
<NCommander> infinity, on raring? flash-kernel doesn't specify it
 * NCommander thinks he knows how its doing it
<ogra_> NCommander, the last uploader was rsalveti and before that three dannf ones specifically for highbank ...
<ogra_> NCommander, update your package :P
<ogra_> (all three uploads from dan were in raring)
 * rsalveti hides
<ogra_> heh
<ogra_> no worries
<ogra_> hmm
<ogra_> though ...
<ogra_> now that i read the changelog ...
<ogra_> flash-kernel (3.0~rc.4ubuntu32) raring; urgency=low
<ogra_>   * flash-plugin-installer: make installable on armhf/generic for highbank
<ogra_> thats funny :)
<dannf> heh. stupid muscle memory
<roaksoax> I have a quick question. Say a source package with -1ubuntu1 revision build 2 binaries that I want to drop in -1ubuntu2. Should I create virtual packages for those 2 packages that I;m dropping or what should be done in that case?
<jbicha> it depends on what those packages are
<roaksoax> jbicha: these packages don't have others depending on them, they enhance functionality
<NCommander> ogra_, I think we're embedding it in the ramdisk these days vs. on the kernel command line directly.
<tvoss> slangasek, ping
<slangasek> tvoss: good evening!
<vrubium> Hi all, Im running saucy and whent trying to update it asks me remove unity-common, should I file a bug?
<slangasek> vrubium: no
<slangasek> you should let it remove unity-common
<vrubium> slangasek: it seems unusual to remove unity-common, won't it break unity?
<slangasek> nope
<slangasek> you should be worried when you see leaf-node packages being removed, like unity itself - not things like unity-common, which are internal implementation details :)
<vrubium> slangasek:
<vrubium> slangasek: sometimes it's trick to identify those packages, do you recommend any procedure?
<slangasek> vrubium: well, if the name starts with "lib" or ends with "-common", they're internal implementation details
<slangasek> vrubium: also, if you use update-manager and update-manager allows the removal without complaint, it's safe
<slangasek> furthermore, unless you have saucy-proposed enabled in your sources (which would be an error), the risk of an upgrade removing packages it shouldn't is now very low
<vrubium> slangasek: thanks for the tip, typically I update using apt-get because it's quicker and normally is straighforward to see if anything is going to break
<mahmoh> NCommander: ogra_: infinity: highbank uses boot.scr too iirc, rootfs is in the initrd yes
#ubuntu-devel 2013-07-25
<slangasek> barry, stgraber: what's the "right" way to switch a phone configured for system updates into developer mode?
<sergiusens> slangasek: stgraber told me to touch /data/.developer_mode and reboot
<sergiusens> is rw after that
<slangasek> ok
<slangasek> I guess this should be documented somewhere prominent
<slangasek> sergiusens: hmm, still ro for me
<programmer_guy> Is this the correct room for asking questions about beginning ubuntu development?
<JackYu> barry, hi, we created a separate /debian branch at https://code.launchpad.net/unity-china-video-scope.
<pitti> Good morning
<halfie> hi, which Wiki software does wiki.ubuntu.com run?
<halfie> I don't think it is MediaWiki
<pitti> halfie: MoinMoin
<halfie> pitti, thanks1
<dholbach> good morning
<geser> are the mailing list archives (on lists.ubuntu.com) still up-to-date? I've an impression that they are missing recent mails (e.g. for ubuntu-devel)
<ogra_> NCommander, nothing in ubuntu uses that machanism (it is error prone and binds you to the initrd) highbank uses the normal uboot setup and has the cmdline in its bootscr, please dont make it use the broken mechanism
<stgraber> slangasek: it's /data/.developer_mode from recovery so /userdata/.developer_mode from the booted system
<ev> anyone know if there are magic runes to teach bzr to handle renames as delete and add in its diff format? I'm trying to do bzr diff -c$revno > /tmp/package/debian/patches/foo.patch
<StevenK> ev: --using /usr/bin/diff , since it will not handle renames
<StevenK> You may have to pass --diff-options -urNP as well
<ev> StevenK: that still gives me === renamed file 'src/diagnostics/whoopsie.ui' => 'data/whoopsie.ui'
<ev> (fwiw, I'm using  `bzr diff -c82 --using /usr/bin/diff --diff-options -urNP`)
<ev> gave up and used cdbs-edit-patch :)
<StevenK> ev: You are a terrible person for using CDBS tools.
<ev> everything else whinged at me
<ev> manish_: heads up. I've uploaded a-l-m 0.9.7-0ubuntu4 with the libwhoopsie-preferences0 move, so we can get ubuntu-system-settings with the diagnostics UI landed
<ev> seb128, Laney: are you happy with https://code.launchpad.net/~ev/ubuntu-system-settings/diagnostics/+merge/174385 at this point?
<Laney> ev: I haven't rechecked the PK stuff yet but other than that yes
<ev> whoop
<doko> cjwatson, seb128: for long running builds like gtk+2.0, maybe glib2.0, would it make sense to have a staged build to not build the udeb's? also gtk should configure with --disable-cups for the staged build
<cjwatson> doko: Not something I care about either way :)
<pitti> Daviey: ah, so it seems you synced pyparsing instead of merging? can you add back the autopkgtest?
<tseliot> pitti: any ideas as to what am I missing in my sbuild chroot if jockey complains like this? http://pastebin.ubuntu.com/5911268/
<pitti> tseliot: no running system d-bus
<tseliot> pitti: is there a way around it?
<pitti> tseliot: if you start it as root, you can use --no-dbus
<pitti> tseliot: otherwise, you have to start a bus
<tseliot> pitti: excellent thanks
<pitti> tseliot: like, dbus-launch and export DBUS_SYSTEM_BUS_ADDRESS=<the address that dbus-launch prints out>
<tseliot> ok, good
<dobey> dholbach: hey, can you take another poke at bug #1199017 please? I've got the issues fixed that you mentioned.
<ubottu> bug 1199017 in Ubuntu "[needs-packaging] ubuntuone-credentials" [Wishlist,New] https://launchpad.net/bugs/1199017
<Daviey> pitti: yep, i'll add them.  Can i check that they were not already submitted to Debian?
<pitti> Daviey: they were forwarded to debian bug 706317, but not applied yet
<ubottu> Debian bug 706317 in pyparsing "pyparsing: add autopkgtest" [Wishlist,Open] http://bugs.debian.org/706317
<pitti> Daviey: so the sync dropped our test that we already had
<Daviey> pitti: Right, I am going to email the debian last uploader asking him to apply it - he is keen for us to reduce delta where we can.
<dholbach> dobey, cool
<dholbach> dobey, good to go
<dobey> dholbach: thanks!
<dholbach> dobey, uploaded
<dobey> great
<roaksoax> cjwatson: howdy!! if you have the time could you please process crmsh from the saucy NEW queue (since it'
<roaksoax> cjwatson: howdy!! if you have the time could you please process crmsh from the saucy NEW queue (since it's kinda blocking me ) Thanks!
<cjwatson> roaksoax: I definitely don't have time at the moment, hopefully somebody else does, sorry ...
<roaksoax> cjwatson: no worries :) thanks though!
<roaksoax> Daviey: do you? :) It's blocking the whole update of the HA stack
<Daviey> roaksoax: Looks like the call i was supposed to be in is canceled, so will do it now
<Daviey> roaksoax: Hmm, did you know this is in Debian experimental ?
<Daviey> roaksoax: You could just sync it, no?
<Daviey> roaksoax: would be better if ./modules/singletonmixin.py was mentioned in debian/copyright as public domain... but if it got into Debian, you can do a sync.
<Daviey> roaksoax: rejecting for now, can retrieve it later if i was mistaken.
<roaksoax> Daviey: crmsh was synced form debian locally, added delta and uploaded, instead of requesting the sync to the system because it is broken
<roaksoax> so I preferred to fix it adding the delta first
<roaksoax> Daviey: ok I requested a sync from experimental, and it is in the new queue. If you could process it would be great
<Daviey> roaksoax: Ah ok, done. Thanks.  Generally, it's easier to do it this way - as we trust Debian to be licence complaint, so takes less time on NEW review.
<roaksoax> Daviey: yeah! I basically just grabbed their package and applied the delta to fix it, but yeah I guess I should have get it into the archives first
<roaksoax> Daviey: thanks though :)
<roaksoax> cjwatson: quick question. If I'm dropping binary packages 'b' and 'c' from a 'x' source that also provides a binary 'a' (b and c had a Dependency on 'a'), should I make 'a' provide 'b' and 'c', or shall they just be gone?
<roaksoax> cjwatson: a more particular example, ocfs2-tools shipped ocfs2-tools, ocfs2-tools-pacemaker, ocfs2-tools-cman, so the -cman, -pacemaker are no longer needed/supported, and I'm dropping them. So should ocfs2-tools 'Provide' the -pacemaker, -cman for some reaason or that's not really necessary?
<ari-tczew> hello
<ari-tczew> I'd like to sync a package, but the remaining delta is only bump B-D on one package. Nevertheless package from unstable builds fine, without that bump. Can I request a sync?
<ScottK> What does debian/changelog tell you was the reason for the bump?
<genii> Sorry to bother but... is there a way to make dhclient -n   <interface> actually work instead of referring the user to usage syntax?
<genii> It used to sort-of work in dhcp3-client ( it would still actually modify stuff though) , in isc-dhcp-client it doesn't work at all.
<ari-tczew> ScottK: * debian/control: depending on eina >= 1.7.7
<ari-tczew> that's all
<ScottK> Probably.  I'd request the sync and let a sponsor review, I guess.
<ari-tczew> ok
 * genii just examines dhclient.c to see what's going on
<cjwatson> roaksoax: it only really matters at all if anything else depends on b and c; and even then it would depend on the details
<cjwatson> roaksoax: there's certainly no rule that you must replace removed binary packages with a Provides
<roaksoax> cjwatson: awesome! thanks for the info
<jbicha> smoser: cloud-init tries to depend on the uninstallable python-jsonpatch
<jbicha> https://launchpadlibrarian.net/145863443/buildlog_ubuntu-saucy-i386.cloud-init_0.7.3~bzr849-0ubuntu1_UPLOADING.txt.gz
#ubuntu-devel 2013-07-26
<smoser> jbicha, that is fixed. i think.
<smoser> jbicha, its stick in proposed
<smoser> hmm.
<smoser> https://launchpad.net/ubuntu/+source/cloud-init
<smoser> hm.. anyone able to help with that ? the fix is in saucy-proposed. it was fixed in 0.7.3~bzr829-0ubuntu2, and is subsequently fixed in 0.73~bzr
<smoser> i have to run, but i'd love it if someone could let that through -proposed for me ...
<micahg> cloud-init/i386 unsatisfiable Depends: python-jsonpatch
<micahg> trying: cloud-init
<micahg> skipped: cloud-init (16 <- 67)
<micahg>     got: 83+0: i-83
<micahg>     * i386: cloud-init, ec2-init, walinuxagent
<micahg> smoser: ^^ that's why
<jbicha> it's not fixed, look in the build log for jsonpatch
<jbicha> I mean look in the cloud-init build log for "jsonpatch"
<roaksoax> doko_: around already?
<pitti> Good morning
<FJKong> pitti: noon for now :)
<pitti> FJKong: welcome to time zones :)
<FJKong> lol
<pitti> slangasek: ah right, sorry for not looking at main/universe in the list
<pitti> TheMuso: FYI, I binNEWed alsa to fix the major uninstallability on amd64 (and thus related autopkgtest failures)
<ScottK> Anyone seeing problems with curl trying to use IPv6 when it's not available in raring (Bug 1205185) - It just started for me recently, but is persistent.
<ubottu> bug 1205185 in curl (Ubuntu Raring) "curl has apparently started attempting IPv6 even when it's not available" [Undecided,New] https://launchpad.net/bugs/1205185
<micahg> ScottK: I got the same thing on precise
<ScottK> So maybe it is on the server side.
<TheMuso> pitti: I thought nothing was migrated from proposed till al deps were satisfied. I was aware of the bin new requirement, but maybe my knowledge on how proposed is used is incomplete or incorrect...
<pitti> TheMuso: no, that's correct
<pitti> TheMuso: the FYI was "this block should resolve itself soon now"
<TheMuso> pitti: Right, thanks for the heads up, its not time critical.
<dholbach> good morning
<ev> seb128, Laney: do you have time today for a review of https://code.launchpad.net/~ev/ubuntu-system-settings/diagnostics/+merge/174385 ?
<Laney> sure
<ev> cheers!
<seb128> Laney, I'm fine with the code, feel free to approve it once you are happy with it as well
<seb128> (I didn't runtime test it, but seems you are doing that)
<Laney> I'll do it right now
<seb128> thanks
<Laney> ev: oho, looks like alm is depwaiting
<Laney> component-mismtaches
<Laney> seb128: want to promote? https://bugs.launchpad.net/ubuntu/+source/whoopsie-preferences/+bug/1203067
<ubottu> Ubuntu bug 1203067 in whoopsie-preferences (Ubuntu) "[MIR] whoopsie-preferences" [Undecided,Fix committed]
<infinity> Laney: I've got it.
<seb128> Laney, done
<seb128> doh
<seb128> infinity, ^
<infinity> Oh, or not.  I hadn't run the command yet. ;)
<Laney> Archive admins: FIGHT
<seb128> ;-)
<ev> lol!
<infinity> seb128: Your pasted output leads me to believe you promoted the binary, but not the source.  Is it you that keeps doing that?
<seb128> infinity, I did "./change-override -c main -S whoopsie-preferences" ... is that wrong?
<seb128> infinity, I'm just using https://wiki.ubuntu.com/ArchiveAdministration as reference,
<infinity> seb128: No, that's right.  You just only pasted the top line of that output.
<seb128> To demote a source package and all of its binaries to universe:
<seb128>     $ ./change-override -c universe -S tspc
<seb128> infinity, oh, right, I didn't want to spam
<seb128> sorry about that :p
<infinity> Kay.  All good.  Now I need to sort out who it is who keeps promoting binaries and not source, since it's not you. :)
<seb128> hehe, good luck ;-)
<StevenK> infinity: auditor will fix that
<StevenK> When it actually happens
<racerunner> i need wire transfer only contact whitoli665@outlook.com
<Laney> ev: Ah, I wasn't in the 'admin' group which the polkit override checks for, only 'sudo'
<Laney> ev: I'll fix that one
<ev> ahh, cheers
<ev> what's the standard for testing dbus services these days?
<Laney> ev: Could you make it so that clicking on the ListItem triggers the action too please?
<Laney> I thought it wasn't working for a while because of that
<ev> sure
<Laney> great
<Laney> ev: pitti's python-dbusmock?
<ev> ooh, I'll have a look. cheers
<Laney> ev: Ah, I forgot - that snippet in the .pkla file is something you told me to put there. :P
<Laney> Maybe you want to ship one from whoopsie-preferences instead?
<pitti> ev: http://pypi.python.org/pypi/python-dbusmock has the README
<ev> Laney: that's tricky. I think we want different pklas for Touch and desktop
<ev> because on touch we don't have random password dialogs
<ev> but those are a staple of the desktop experience ;)
<ev> pitti: ah, nice one
<pitti> ev: I use dbusmock for testing e. g. gnome-settings-daemon, to mock polkit and logind
<ev> ah excellent, I'll have a look at those tests as a guide
<Laney> ev: I don't understand what you mean - this would mean you have fewer authentication dialogs
<ev> Laney:  the purpose of that pkla is to replace an auth_keep dialog with a pass for anyone in an admin group. This makes sense on Ubuntu Touch where we don't have password dialogs (to my knowledge), but I am not sure it makes sense on the desktop where it's entirely normal to have an "unlock" button that is followed by a password dialog (see gnome-control-center -> security & privacy -> diagnostics).
<ev> Does that make more sense?
<ev> I am definitely open to suggestion here
<ev> or direction for that matter :)
<ev> desktop is not my baby
<doko> Laney, seb128: does this ring a bell in gtk+3.0?
<doko> # Install the binaries with a -3.0 suffix
<doko> mv debian/libgtk-3-0/usr/lib/aarch64-linux-gnu/libgtk-3-0/gtk-update-icon-cache \
<doko> debian/libgtk-3-0/usr/lib/aarch64-linux-gnu/libgtk-3-0/gtk-update-icon-cache-3.0
<doko> mv: cannot stat 'debian/libgtk-3-0/usr/lib/aarch64-linux-gnu/libgtk-3-0/gtk-update-icon-cache': No such file or directory
<doko> make: *** [binary-install/libgtk-3-0] Error 1
<doko> $ find -name gtk-update-icon-cache
<doko> ./debian/install/shared/usr/bin/gtk-update-icon-cache
<doko> ./debian/build/shared/gtk/gtk-update-icon-cache
<Laney> ev: Hmm. I thought polkit authentication was planned on touch but just not implemented yet.
<Laney> Anyway, AIUI whoopsie-preferences will currently never prompt the user so this can't succeed
<ev> if you know of some buried google doc that mentions this, I'd be quite interested to have a link
<Laney> I guess implement that and then on touch you'd ship a pkla to skip it in some touch-polkit-policies package
<ev> Laney: hm? It does polkit_authority_check_authorization_sync around the calls
<seb128> Laney, ev: I'm not sure what are the exact plan, but there were talk about adding the auth dialog to mir/unity (the way it's gnome-shell doing those in GNOME nowadays)
<seb128> Laney, ev: not sure that's needed for the phone and on the roadmap for v1 though
<Laney> ev: Isn't that what POLKIT_CHECK_AUTHORIZATION_FLAGS_NONE says?
<seb128> it might just be a "later" item for the convergence
<Laney> the knowledge I have is hearsay I'm afraid
<ev> oh curious
<Laney> a lot of systemd dbus methods have a user_interaction flag that controls whether you are allowed to prompt or not
<ev> that's the same code that's always been there, and I got a prompt before I started fiddling with my pkla
<ev> so we should set that to POLKIT_CHECK_AUTHORIZATION_FLAGS_ALLOW_USER_INTERACTION then?
<Laney> only if it is always called in response to a user action (let me check if it works)
<Laney> yeah, I got prompted as soon as I went into diagnostics
<Laney> So, I'll approve the s-s MP since it's all OK on that side and you can tinker with this stuff
<ev> whoop
<Laney> wait, did you push that change to the ListItem yet? :P
<ev> working on it :)
<Laney> ok, well ping me and I'll do it then
<ev> will do
<doko> Laney, seb128: any idea about gtk+3.0?  and is it necessary to enable the docs build for the binary-arch only build?
<pitti> cjwatson: I'm just stunned by LP's publisher these days -- like, did you take out the sleep(1200) there?
<pitti> cjwatson: thanks for that, amazing work!
<Laney> doko: No, I don't know how it gets moved out of bindir into libdir
<Laney> or wherever it gets moved to
<Laney> doko: docs build> I guess not, try it :-)
<seb128> doko, no real idea offhand either sorry
<cjwatson> pitti: Heh, yeah, it was mostly William and Adam; mainly, we noticed that the apt-ftparchive caches hadn't been cleaned properly and had thus grown to enormous sizes, and cleaning them made a huge difference
<cjwatson> pitti: So I then did https://code.launchpad.net/~cjwatson/launchpad/publisher-ftparchive-clean/+merge/173226 to make sure that won't happen again
<pitti> cjwatson: yeah, I noticed that in ddeb-retriever too, I kill them every now and then
<cjwatson> pitti: We also changed it to try to run every five minutes if one isn't running, rather than every 30, which I'd sort of been thinking about for a while
<pitti> cjwatson: the last time I looked at the publisher run time (> 1 year ago, though) it still took > 20 mins
<pitti> cjwatson: nice to hear that this was indeed just due to apt-ftparchve
<ev> Laney: r135 fixes it. Sorry that took so long.
<Laney> ev: thanks, no worries - I wasn't sitting on the edge of my seat for it or anything :P
<ev> :)
<cjwatson> pitti: Well, other bits and pieces over that timeframe, but yeah
<pitti> jibel, dobey: seems I fixed autopkgtest's "allow-stderr" hard enough, saucy-adt-{dirspec,ubuntuone-client} are green now \o/
<pitti> well, blue in public jenkins, but YKWIM :)
<pitti> jibel: critical Friday-afternoon bug: we so much need the "green bullets" jenkins plugin back!
<jibel> pitti, I know, we already tried to re-enable it with IS on jenkins.qa.u.c but it breaks sevelral other plugins and no images are loaded at all
<pitti> jibel: urgh; well, it must be thousands of lines of code, it's a rather complex plugin after all
<jibel> :)
<tvoss_> cjwatson, ping
<cjwatson> tvoss: yes?
<tvoss_> cjwatson, asac mentioned that you were looking into cmake cross compiling
<cjwatson> tvoss_: well.  in theory it's somewhere on my list and I've looked at it before, but it's not something I'm likely to get to for at least a month
<smoser> hey.. i need some help.
<smoser> why is cloud-init 0.7.3~bzr869-0ubuntu1 stuck in proposed ?
<smoser> https://launchpad.net/ubuntu/+source/cloud-init
<tvoss_> cjwatson, ack, let me know when you start looking into it, mir has got support for it
<cjwatson> tvoss_: OK
<cjwatson> smoser: Because it's uninstallable in -proposed
<cjwatson> The following packages have unmet dependencies.
<cjwatson>  cloud-init : Depends: python-jsonpatch but it is not installable
<smoser> but i dont think that is true. where do you see that ?
<cjwatson> I ran 'chdist apt-get saucy-proposed-i386 install cloud-init' as ubuntu-archive@lillypilly
<cjwatson> And http://people.canonical.com/~ubuntu-archive/testing/saucy-proposed_probs.html agrees
<cjwatson> Your package depends on it and it's not in the archive
<cjwatson> proposed-migration is absolutely correct
<cjwatson> Just the same as when you asked 11 hours ago :)
<smoser> so i *did* most definitely make that typo
<cjwatson> smoser: The current version in -proposed is bzr849, not bzr869 as you mentioned above, if that helps
<smoser> right
<smoser> yeah, another typo
<smoser> :)
<doko> seb128, pitti: why does pygtk b-d on python-numpy-dbg?
<doko> but not python-numpy
<smoser> but i have no idea how thats getting there.
<Laney> https://launchpadlibrarian.net/145863443/buildlog_ubuntu-saucy-i386.cloud-init_0.7.3~bzr849-0ubuntu1_UPLOADING.txt.gz
<Laney> see dh_python2 warnings
<smoser> Laney, thank you.
<smoser> is there a way to fix dh_python2 for that ?
<cjwatson> It says how in the warning text
<cjwatson> And in the dh_python2 man page
<seb128> doko, that's coming from debian, unsure, it should probably b-d on both
<seb128> doko, it happens to work because the dbg bring the normal package in
<doko> seb128, I though I removed that before for ubuntu ...
<doko> did it creep in again?
<smoser> cjwatson, well, yeah, the pydist-overrides is clear. but is there a way to fix that so that every package gets it?
<cjwatson> smoser: What's the package really called?
<Laney> smoser: build-depend on the package
<smoser> python-json-patch
<cjwatson> Wouldn't it be simplest to rename it to match the module name?
<cjwatson> Or Provides: python-jsonpatch if that's hard for some reason
<seb128> doko, you removed the runtime depends, not the build-depends
<seb128> doko, http://launchpadlibrarian.net/22962155/pygtk_2.13.0-2ubuntu4_2.13.0-2ubuntu5.diff.gz
<cjwatson> Having packages that violate Python naming policy is kind of asking for trouble
<doko> ahh, ok
<doko> what a pity ..
<smoser> cjwatson, ok. so i will open a debian bug suggesting . thanks.
<cjwatson> smoser: The Provides should be easy to add in Ubuntu in the meantime, although renaming the package is more correct
<cjwatson> That should let cloud-init in, or at least move you on to the next problem
<smoser> cjwatson, I just filed debian bug. so you think adding Provides to python-json-patch is the best path ?
<smoser> my 2 other questions to expose ingorance of mysefl are
<cjwatson> smoser: It's not the best path for Debian, but it's the least-effort one for Ubuntu
<cjwatson> In general Python packages should be named according to the Python policy
<smoser> a.) I guess if i have dh_python2 I do not need the explicit depends listed in my debian/control
<cjwatson> http://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html#s-package_names
<smoser> right. i pointed at that in my bug to ubuntu
<smoser> err... bug to debian
<smoser> b.) when i just run 'debuild' i dont see output with those pydist warnings. what obvious thing am i doing wrong?
<cjwatson> a) I believe not but test
<smoser> (warnings shown https://launchpadlibrarian.net/145863443/buildlog_ubuntu-saucy-i386.cloud-init_0.7.3~bzr849-0ubuntu1_UPLOADING.txt.gz)
<Laney> (b) You'll have the Depends installed which means that dh_python2 can map the modules back to package names
<Laney> which is why I suggested adding it to build-depends
<cjwatson> Right, so you could ... indeed, that
<smoser> Laney, right i figured that was why that would resolve it.
<cjwatson> In principle you want the modules installed anyway so you can run the test suite that you have ... right? :)
<smoser> but if I added the build-depends, then i'd have to change package name at some point in the future, but clearly whatever happens with that package name has to think about that anyway.
<cjwatson> Yeah
<smoser> i'll add build-depends. thank you.l
<seb128> Laney, ev: did we need that split main.pro/security-privacy.pro in security-privacy?
<seb128> it seems suboptimal, it shows as a subtree "main" in qtcreator
<seb128> rather than having the panel and just a subdir in it
<ev> seb128: Laney requested that diagnostics live under security-privacy. If there's a better way of structuring that, please do share. I'm a bit wet behind the ears when it comes to qmake.
<seb128> ev: I would just have made one .pro listing all the files but maybe it doesn't work for a reason I'm overlooking
<Laney> seb128: Seemed a neat enough way of splitting it up to me
<seb128> Laney, we have
<seb128> > security
<seb128>   > main
<seb128>    > whoopsie
<seb128> ups
<seb128> main/whoopsie at the same level
<seb128> why not simply
<seb128> >security-panel
<seb128>    > whoopsie
<seb128> with main just being the panel dir?
<Laney> I don't mind
<Laney> feel free to do that
<Laney> If it worked I didn't want to make ev redo it
 * seb128 wishes there was a way to hide all those common/coverage/etc item in qtcreator
<tkamppeter> mlankhorst, hi
<sil2100> ricmm, tvoss_: hi guys, a question related to platform-api and qtubuntu - since greyback has some changes in those branches that he needs for unity-mir, do you know when that will be merged into trunks?
<sil2100> ricmm, tvoss_: so that we can daily-release unity-mir already
<tvoss_> sil2100, no idea
<ricmm> sil2100: he has no changes in those branches to me merged
<ricmm> sil2100: I have build rules changes to enable the mir building and deps
<ricmm> but that cannot land until Mir is in main
<sil2100> seb128: hi! Do you have a moment for a packaging ACK?
<seb128> sil2100, sure
<sil2100> ricmm: hmmm, so, only that is blocking building unity-mir
<sil2100> seb128: http://10.97.0.1:8080/view/cu2d/view/Head/view/SDK/job/cu2d-sdk-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_ubuntu-ui-toolkit_0.1.46+13.10.20130726.1-0ubuntu1.diff
<ricmm> sil2100: are you trying to publish unity-mir to disto?
<seb128> sil2100, seems fine, are you sure it builds (I just received ppa emails about the ui toolkit failing to build)
<sil2100> ricmm: maybe not yet, but we'd like to get it autolanding and daily-releasing to a PPA at least, and didrocks_busy said we'll do that only if all deps are ready
<sil2100> seb128: it's building, we fixed the FTBFS earlier
<sil2100> seb128: thanks!
<ricmm> sil2100: well deps arent ready, we need to wait for Mir to land in distro
<ricmm> once that happens I will land the dep MRs for qtubuntu and platform-api, which are already in place
<ricmm> unity-mir currently lands in phablet-team/mir for auto building of the phone/mir image
<ricmm> but not via daily release, once the chain of deps set up from distro then you are good to enable it
<sil2100> Ok
<ricmm> didier knows that tho, he knows the point we are at re landing of Mir
<sil2100> ricmm: thanks!
<sil2100> ricmm: he's busy busy right now so I didn't want to pester him, prefered pestering upstream instead ;)
<robotfuel> ev: ping
<ev> robotfuel: hi
<robotfuel> ev: https://bugs.launchpad.net/ubuntu/+source/whoopsie-preferences/+bug/1205394 I just ran into this packaging bug on saucy, and wasn't sure where the right place for the bug is
<ubottu> Ubuntu bug 1205394 in whoopsie-preferences (Ubuntu) "distupgrade fails in saucy because whoopsie-preferences _0.8_amd64.deb is trying to overwrite '/usr/bin/whoopsie-preferences', which is also in package activity-log-manager-control-center 0.9.4-0ubuntu6.1" [Undecided,New]
<robotfuel> ev: launchpad says you're the owner, so I thought I'd ask you
<ev> robotfuel: please install activity-log-manager 0.9.7-0ubuntu4
<ev> I'll sort the bug out though
<robotfuel> ev: apt-get install -f fixes it, but we don't want the dist-upgrade failure to happen right?
<robotfuel> ev: is that the write place for the bug?
<ev> it is, yes
<ev> thank you
<sil2100> seb128: last packaging ACK, phone: http://10.97.0.1:8080/view/cu2d/view/Head/view/Phone/job/cu2d-phone-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_address-book-app_0.2+13.10.20130726-0ubuntu1.diff
<sil2100> seb128: thank yoU!
<sil2100> seb128: it adds a new package, it's hard to catch everything from a diff but it builds and looks ok
<seb128> sil2100, nack, please name the binary qtdeclarative5-ubuntu-contacts<version>
<seb128> sil2100, see kenvandine's comment today on https://code.launchpad.net/~seb128/gsettings-qt/rename-binary-package/+merge/177141
<seb128> "we decided to change the package naming convention to qtdeclarative5-name1.0."
<sil2100> seb128: so not qtdeclarative5-ubuntu-contacts-plugin but for instance qtdeclarative5-ubuntu-contacts1.0 ?
<seb128> yes
<sil2100> seb128: ACK! Good to know :)
<seb128> thanks
<seb128> better to fix it before it lands
<seb128> otherwise we need to do a transition
<kenvandine> sil2100, seb128: i proposed a branch for the contacts plugin
<kenvandine> https://code.launchpad.net/~ken-vandine/address-book-app/versioned_plugin/+merge/177159
<sil2100> kenvandine: ah! ha! Fast one ;)
<kenvandine> :)
<seb128> kenvandine, approved
<sil2100> kenvandine: thanks, I was in the middle of doing that, but at least I won't have to push!
<kenvandine> :-D
<seb128> kenvandine, I can't change the status though
<kenvandine> i did it this morning when i saw the publish failed
<sil2100> seb128: approved it globally
<kenvandine> sil2100, thx
<seb128> sil2100, thanks
<sil2100> kenvandine: the publish was in manual publishing, not failed! :) There was also the issue with SDK and the AP machines
<kenvandine> sil2100, yeah... that's what i meant
<kenvandine> because of the packaging changes
<kenvandine> sil2100, is sdk fixed?
<sil2100> kenvandine: yes! Published already
<kenvandine> great
<kenvandine> thx
<sil2100> kenvandine: I have a problem with webapps though...
<sil2100> kenvandine: since!
<sil2100> kenvandine: I modified the config to include the missing packages: (extra ones) and redeployed the stack twice already
<didrocks_busy> sil2100: I hope next week we won't have sdk to be published at 6PM ;) remember I won't be around at all, in a sprint :)
<kenvandine> didrocks_busy, good times :)
<sil2100> didrocks_busy: I promise! I filled in a bug early, the bug was fixed quickly but the merger couldn't get the fix in for some time
<didrocks_busy> kenvandine: thanks!
<sil2100> didrocks_busy: because of failing mediumtests
<didrocks_busy> sil2100: ah, so upstream failures?
<sil2100> Flacky tests, need to report those
<doko> SpamapS, online?
<SpamapS> doko: I am. Wassup?
<roaksoax> doko: howdy! So I've filed a removal bug for system-config-cluster, I have uploaded a new lvm2 disbaling clvm (which had build-deps from redhat-cluster). Also uploaded a new qpidd removing those build-deps. That should allow to remove redhat-cluster from the archives
<slangasek> barry: apt-clone's testsuite is making me stabby.  I think I need a refresher on how to sanely write python2/3 bilingual unicode handling.  Can you point me to some appropriate docs?  I keep finding "and here's the right way to do it in python3, ignore that old python2 stuff" which I only wish I could
<gQuigs> I was wondering if all the desktop related lucid bugs on here: http://people.canonical.com/~ubuntu-archive/pending-sru.html, could just be closed
<doko> roadmr, is not building clvm the right thing to do?
<doko> roaksoax, ^^^
<roadmr> doko: hehe :)
<doko> when used with
<doko>  Red Hat's "cman" or corosync based (eg Pacemaker) cluster infrastructure.
<doko> so it doesn't seem to be the case
<gQuigs> at least xserver-xorg-video-openchrome, gnome-power-manager and moon
<cjwatson> gQuigs: (no opinion right now as it's Friday evening, but) please don't close them without an SRU team member being involved because if we were rejecting those bugs we'd also need to remove the uploads from lucid-proposed
<roaksoax> doko clvm supports cman, corosync or openais
<gQuigs> cjwatson: ACK
<roaksoax> but also depends on libdlm
<roaksoax> which is currently shipped with tedhst cluster
<roaksoax> however theres a new source package called dlm
<roaksoax> that will ship this
<roaksoax> doko so we neef to drop redhat-cludter first
<doko> roaksoax, ok, so something from libdlm replaces it, correct?
<roaksoax> doko: the dlm source will have libdlm binary (i already uploaded to the new queue) but we nred tonfrop redhat-cluster first
<roaksoax> dlm got split from redhst-cluster source into its own
<doko> ok
<doko> but why remove it first?
<roaksoax> doko cause redhat-cluster is blocking corosync. So clvm needs newer corosync
<roaksoax> and theres a weird build issue with the lvm2 packagr which fails for not finding corosyn... but if i build locally with newer corosync it works
<doko> roaksoax, qpidd?
<doko> so what did you upload?
<roaksoax> 1. disabled clvm in lvm3 for the time being
<doko> lvm3, not lvm2?
<roaksoax> typo
<roaksoax> lvm2
<roaksoax> 2. disabled cman support in qpid
<roaksoax> newer upstreams drops it
<roaksoax> 3. dlm (which is in the new queue)
<doko> ahh, qpid
<doko> qpid-cpp even
<roaksoax> doko: yep :) and crmsh needs mir if you free :)
<doko> ok, I'll see, although it's end of day
<barry> slangasek: it' start here: http://python3porting.com/ (has a lot of stuff not just unicode)
<slangasek> barry: so http://python3porting.com/noconv.html ?
<barry> slangasek: avoiding 2to3 is definitely preferred!
<slangasek> especially for the testsuite ;)
<barry> slangasek: unless you like waiting minutes each run for 2to3 to do its thing :)
<slangasek> jibel: how important is bug #1167266  (apt-clone adt failure on armhf)?  AIUI proposed-migration will only care about i386/amd64
<ubottu> bug 1167266 in apt-clone (Ubuntu) "test_restore_state_simulate failed on arm because acpi-support is not available on this architecture" [Undecided,New] https://launchpad.net/bugs/1167266
<infinity> slangasek: proposed-migration only cares about x86 tests for now, yes.  Still poor form to have x86 specific tests that don't exit cleanly on other arches.
<slangasek> infinity: I'm not disputing that it's a bug, I'm asking what its priority should be
<infinity> slangasek: Yeah, not a critical blocker from the POV of p-m.
<slangasek> sure.  are there other reasons we might consider it a priority to have clean adt results on armhf later?
<infinity> slangasek: Some day, I imagine we'd like to run more tests on ARM and, when we have enough (and fast enough) kit, to even block on it, but none of that is this month (or year?).
<ari-tczew> barry: ping
<barry> ari-tczew: pong
<ari-tczew> barry: I've checked merge on python-gnupg and my POV is that can be synced. do you mind?
<barry> ari-tczew: do you have a bug #?
<ari-tczew> barry: I've not yet requested. I'd like to first ask you.
<barry> ari-tczew: let me look
<ari-tczew> ok
<barry> ari-tczew: the merge of the source package produces conflicts, but i think i can straighten that out.  mind if i just go ahead and do that?
<barry> ari-tczew: otoh, if you have the time and inclination, feel free to open a bug, and provide a debdiff or merge proposal
<ari-tczew> barry: Well, I could request a sync. Look @ debdiff between current Ubuntu package und Debian: http://paste.ubuntu.com/5916134/
<ari-tczew> I asked you because I'm not sure about refreshed skip_network_needing_test.patch in Debian
<barry> ari-tczew: just a sec
<barry> ari-tczew: i wouldn't want to drop the ubuntu changelog entries
<barry> ari-tczew: if the refreshed patch still applies, then i think it's appropriate.  the key thing is that the buildds won't have access to keyserver.ubuntu.com so that test must be skipped
<ari-tczew> well, wouldn't you to sync?
<barry> ari-tczew: probably so.  file a bug so we can refer to it in the syncrequest
<ari-tczew> barry: builds fine, so patch applies clearly. shall do I attach buildlog?
<barry> ari-tczew: yes please
<ari-tczew> barry: ok but I have i386
<barry> ari-tczew: that's okay, i'll do a local build to double check
<ari-tczew> barry: bug 1205505
<ubottu> bug 1205505 in python-gnupg (Ubuntu) "Sync python-gnupg 0.3.4-1 (universe) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/1205505
#ubuntu-devel 2013-07-27
<manchicken> Do people know about the problem where apt-get and aptitude both - in French - show O/N instead of Y/N, but O doesn't actually behave as Y?
<SpamapS> manchicken: that sounds like a bug to report with 'ubuntu-bug apt'
<manchicken> SpamapS: I just wanted to make sure it wasn't an obvious known.
<manchicken> (it seemed like it would be)
<SpamapS> manchicken: there are many French speaking ubuntu devs so it would probably come to their attention rather quickly.
<jbicha> could someone retry these builds? https://launchpad.net/ubuntu/+source/alsa-utils/1.0.27.1-1ubuntu1
<spstarr> so can someone tell me why Ubuntu does *not* have the newest Samba 4 packages?
<spstarr> you're pushing me into an uncomfortable position with PPAs
<Ampelbein> spstarr: I'm sure the Debian samba maintainer team appreciates any help in getting more recent version in Debian and by that in Ubuntu.
<houseofbean> join #drupal-contribute
<penguin42> it's worth watching out for apps that break/change in behaviour now that stuff gets mounted under /media/username rather than /media
<ScottK> jbicha: doing
<ScottK> done
<spstarr> Ampelbein: except sid has 3.6.16 just fine
<spstarr> no excuses on Ubuntu's part for not just taking it and building it :P
<Ampelbein> spstarr: saucy has 3.6.15, is that really too old?
<Ampelbein> spstarr: Or, if you want samba4, saucy has 4.0.3
<spstarr> 4.0.3 is old too
<spstarr> 3.6.9 in raring caused 100% CPU in winbindd
<spstarr> im trying 3.6.16 with debian package in raring to see if its bug
<elmo> \
#ubuntu-devel 2013-07-28
<trippeh> Still no bind update? Sniff.
<trippeh> http://lists.debian.org/debian-security-announce/2013/msg00138.html
<Whoopie> Hi, does someone of you have contact to a Dell developer. I'm still trying to find out how to get one of my special keys working on my Dell Vostro V131. It doesn't show up as a keyboard or wmi event.
<sladen> Whoopie: hello Whoopie.  Would you be able to file a bug report.  I used to do a lot of work on laptop special-keys a few years ago, and there is a large variation in how the keys are implemented; so that it is necessary to know model/revision and sometimes even firmware version.
<sladen> Whoopie: we can then work through those questions and keep all the details in one place, and work out what the fix is
<Whoopie> sladen: sure
<Whoopie> sladen: should I file it under "linux-image"?
<sladen> Whoopie: can you link to http://www.notebookcheck.net/fileadmin/_migrated/pics/v131tastatur_01.jpg  (or a photo of your own machine) in the bug report
<sladen> Whoopie: that'll do for the moment, we can redirect it when the actual issue has been debugged and identified
<sladen> Whoopie: is it one of the three hardware keys visible in the top-right (cogs, no-entry, and star-box) ?
<Whoopie> sladen: yes, it the right one, the middle key works with a udev quirk "keyboard-force-release". I'll post the patch in the bug report.
<sladen> Whoopie: mjg59 seems to have had a look, I'm just reading through  http://www.mail-archive.com/platform-driver-x86@vger.kernel.org/msg03124.html
<Whoopie> sladen: that's my mail. ;-)
<sladen> Whoopie: so you're the same Peter Meiser as provided the udev patch for the lack of key-up?
<Whoopie> sladen: right
<sladen> Whoopie: (can you add this to the bug report, and anything else you're also aware of; again so it's all linked in one place)
<Whoopie> sure
<sladen> ftp://ftp.dell.com/Manuals/all-products/esuprt_laptop/esuprt_vostro_notebook/vostro-v131_Setup%20Guide_en-us.pdf  Page 1 names those keys with the intended MS Windows functionality
<Whoopie> sladen: just mentioned the names in the report.
<sladen> Whoopie: can you   sudo apt-get install acpidump iasl
<sladen> Whoopie: https://wiki.edubuntu.org/BIOSandUbuntu#Buggy_DSDT  snippet here for grapping the ACPI DSDT (and if you are interested) decompiling it
<sladen> Whoopie: this is the bytecode that is specific to that machine.
<sladen> Whoopie: can you attach the acpidump.txt to the bug report
<sladen> Whoopie: and then we can go hunting for the hotkey handling code in there
<Whoopie> sladen: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1205791
<ubottu> Ubuntu bug 1205791 in linux (Ubuntu) "Dell Vostro V131: special keys not working" [Undecided,New]
<sladen> Whoopie: ta
<sladen> Whoopie: does the ACPI interrupt-count also increase for using the other keys too (i8042 0xee down, and WSMI) ?
<sladen> Whoopie: can you attach an  lspnp  too
<Whoopie> sladen: lspnp attached (btw, SMO8800 is the freefall sensor)
<Whoopie> sladen: the ACPI interrupt only increases for the "not-working" key.
<Whoopie> sladen: but the other 2, it's i8042
<sladen> Whoopie: are you seeing "unhandled WMI event" in the syslog?
<ari-tczew> rsalveti: as you're the last upload of packages of eet und eina, I'd like to ask you whether can we sync these?
<ari-tczew> The remaining changes in Ubuntu are following: @ eet only Build-Depends on libeina-dev (>= 1.7.7) -> (>= 1.2.0) (builds fine, though)
<ari-tczew> and @ eina is bumped on debhelper 9 in Ubuntu (without info in d/changelog, though); in Debian is still on debhelper 6
<Whoopie> sladen: no
<Whoopie> sladen: I also added a WMI dump to the bug report.
<roaksoax> mterry: working on a sunday huh?
<mterry> roaksoax, I had some time  :)
<roaksoax> mterry: heh :)
<rsalveti> ari-tczew: feel free to sync them, didn't have much time to get those synced with debian after I updated the packages
<ari-tczew> rsalveti: ok
<ajdicks> Trying to use bzr to get the raring branch of the gtk+3 sources: this should be possible according to <https://code.launchpad.net/~ubuntu-branches/ubuntu/raring/gtk+3.0/raring> by running "bzr branch lp:ubuntu/raring/gtk+3.0", but this gives "bzr: ERROR: Revision {[...]} not present...".  Is this because of a failure reported at <http://package-import.ubuntu.com/status/gtk+3.0.html>, should I report this as a bug, or am I doing something wrong?
<penguin42> ajdicks: I can confirm I also get that revision not present error
<ajdicks> penguin42, Is what I did supposed to work?  I'm not very familiar with bzr.
<penguin42> ajdicks: I think so, lp tells you to do exactly that!
#ubuntu-devel 2014-07-21
<pitti> Good morning
<pitti> mapreri: scribus> nice!
<pitti> mapreri: synced
<mapreri> pitti: thanks! :D
<mapreri> pitti: I didn't think your backlog goes so far in the past (I limited mine to 1000 rows, and this channel produces a lot more in 4-5 days..) :) I was about to email you ??
<mapreri> ^^ *
<pitti> mapreri: I just keep the entire backup, it was just since Thursday evening (I was off on Friday)
<mapreri> pitti: out of curiosity: what bnc do you use? (I use znc)
<pitti> mapreri: I recently moved to bip, znc stopped working for no apparent reason with freenode ("failed to connect")
<mapreri> ok
<pitti> stgraber, hallyn_: do we still need http://paste.ubuntu.com/7829207/ for systemd/logind 208? now systemd-shim and cgmanager do the cgroups creation, so I suppose that takes care of this?
<pitti> stgraber, hallyn_: that patch doesn't work as-is any more anyway, /etc/systemd/{system,user}.conf now have a JoinControllers
<stgraber> pitti: can you get me the post-login output of /proc/self/cgroup on a system with systemd/logind 208 using cgmanager and without this patch?
<stgraber> pitti: should be easy to figure out whether we need something like this patch or not with that output
<pitti> stgraber: http://paste.ubuntu.com/7829223/
<pitti> stgraber: systemd-208pitti1, cgmanager running, running upstart
<stgraber> pitti: looks good, so if that's what we get without the config, then we don't need it
<pitti> stgraber: that doesn't have any of our Ubuntu patches
<pitti> stgraber: cool, thanks for confirming!
<pitti> stgraber: I'd like to get in 208 soon, to fix bug 1343802
<ubottu> bug 1343802 in systemd (Ubuntu) "Installation of cgmanager prevents booting with systemd" [High,Triaged] https://launchpad.net/bugs/1343802
<xnox> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: xnox
<darkxst> hey xnox, can you take a look at bug 1343815 during your shift
<ubottu> bug 1343815 in gnome-bluetooth (Ubuntu) "Introspection of GnomeBluetooth.Column is broken" [Undecided,New] https://launchpad.net/bugs/1343815
<norbert> is it possible to make a simple rename request here related to the description of a package maintained by the "Ubuntu Core Developers"?
<xnox> norbert: well, what specifically are you after? which package?
<norbert> xnox: http://packages.ubuntu.com/trusty/nvidia-current says "Transitional package for nvidia-current" (try apt-cache search nvidia-current yourself, to see the description), which is a circular description; it should say "[...] for nvidia-304"
<cjwatson> sarnold: Any progress on the librevenge MIR?
<xnox> norbert: yeah that's a bit odd. Can you please open the bug with " $ ubuntu-bug nvidia-graphics-drivers-304 " and then give me the bug # here? I'll assign it to the right person to look into.
<norbert> xnox: I cannot, because I don't need nvidia-304
<norbert> it's just something I noticed
<xnox> norbert: it should file the bug, wheather that package is installed or not.
<xnox> norbert: or open one manually via launchpad url.
<norbert> what I needed was nvidia-331, therefore I had to figure out if nvidia-current was what I needed - it wasn't
<norbert> no, it says "The problem cannot be reported: The report belongs to a package that is not installed."
<xnox> darn.
<norbert> so, <norbert> is it possible to make a simple rename request here related to the description of a package maintained by the "Ubuntu Core Developers"?
<norbert> instead of having to go through whatever trouble (launchpad or whatever) I might need to otherwise :)
<norbert> I have tons of bugs to report
<norbert> it just always takes so much time
<norbert> mostly because I'm constantly being referred to other projects/places
<xnox> norbert: well, using another human to file bugs for you via irc in total takes even more time, don't you think?
<norbert> no, I don't
<norbert> it did this time, though
<norbert> anyways, it's not an important issue, maybe one day someone will fix it
<norbert> good day :)
<xnox> norbert: filed as https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-304/+bug/1346187
<ubottu> Ubuntu bug 1346187 in nvidia-graphics-drivers-304 (Ubuntu) "nvidia-current has recursive description" [Undecided,New]
<xnox> norbert: subscribe if you want.
<xnox> *sigh*
<doko> jamespage, do you see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754859 with the new ceph?
<ubottu> Debian bug 754859 in ceph "ceph command hangs in Jessie after update (python 2.7.8 suspected)" [Important,Open]
<ansgar> Hi, I want dune-grid/ppc64el and its rdepends removed. The new version depends on libalberta-dev which doesn't built on ppc64el.
<ansgar> (as it build-depends on clang on powerpc due to gcc not able to do constant-folding for long doubles.)
<xnox> hm, we don't have clang on ppc64el.....
<xnox> right ELFv2 ABI patches needed.
<xnox> ansgar: filed https://bugs.launchpad.net/ubuntu/+source/dune-grid/+bug/1346252 subscribed Ubuntu Archive Admins to action.
<ubottu> Ubuntu bug 1346252 in dune-grid (Ubuntu) "RM bin dune-grid/ppc64el only, build-depends on missing clang/llvm" [Medium,Triaged]
<ansgar> xnox: Thanks.
<bluesabre> xnox: what are the requirements for adding packages to the xubuntu packageset?  I found a few shipped by xubuntu, but not included in the packageset (https://lists.ubuntu.com/archives/devel-permissions/2014-July/000702.html)
<bluesabre> or, they didn't appear to be when I searched for the set
<Laney> bluesabre: We got the mail, It'll get sorted.
<bluesabre> Laney: ok, thanks.
<Laney> s/,/./
<Laney> Will poke at DMB stuff after lunch
 * Laney afk
<xnox> bluesabre: mailing devel permissions is the right way. Just wait for DMB member to process / acknowledge / comment on the requests.
<xnox> bluesabre: for newly approved packageset it takes time to get them in the right order. You are the first with upload rights into it, after all.
<bluesabre> ok, just wanted to verify.  I know that things can get lost over the weekend :)
<pitti> stgraber, hallyn_: FYI, I filed bug 1346199 to test systemd 208 with the new cgmanager/shim
<ubottu> bug 1346199 in systemd (Ubuntu) "Needs testing in -proposed: systemd 208" [High,In progress] https://launchpad.net/bugs/1346199
<pitti> feedback appreciated!
<hallyn_> pitti: great, I'll test on a few vms
<pitti> hallyn_: I have it running on my workstation and clean utopic VM, and now on the phone
<pitti> stgraber: I now tested them with system-level containers; I'd appreciate if you could test them with user-level containers too
<stgraber> pitti: sure, let me setup a VM (not feeling like dist-upgrading my laptop thousand of km away from home and hours before I'm on vacation :))
<pitti> stgraber: oops sorry, didn't know that
<pitti> stgraber: enjoy your vacation!
<stgraber> pitti: thanks. I'm still working for the next 2 hours or so, should be plenty of time to test all that in a VM
<pitti> jodh, hallyn_: do you know why test_util_check_env failed the "cgroup sandbox" test in https://jenkins.qa.ubuntu.com/job/utopic-adt-upstart/66/ARCH=i386,label=adt/consoleText ?
<pitti> jodh, hallyn_: could this be because systemd-shim now pulls in cgmanager, and previous tests thus didn't run with cgmanager?
<pitti> (null):dbus_error.c:69: Unhandled error from nih_dbus_error_raise: invalid request
<hallyn_> pitti: hm, not sure.  will have to look at the testcase
<jodh> hallyn_, pitti: looks like the non-priv test is not running in a logind cpuset cgroup and is trying to create a top-level cgroup.
<hallyn_> jodh: still collecting all my morning data - do you have a link to the actual test source handy?
<jodh> hallyn_: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/utopic/upstart/utopic/view/head:/test/tests/test_util_check_env.c
<hallyn_> jodh: so what's the easiest way to have a cgroup created?  have the testcase ssh to localhost?
<hallyn_> or is there a root script that can do it for us?
<jodh> hallyn_: I don't think the upstart tests should be managing that. Clearly, something changed in the env to now cause this test to fail in the jenkins env (works fine on the buildd's and locally). But, the test should prolly check to see if they are already in a cgroup and if not, print a warning and skip that test (as we do for overlayfs).
<pitti> jodh, hallyn_: ah, that's relying on logind to create new cgroups?
<pitti> jodh, hallyn_: so, it could be that this fails because systemd 208 in utopic-proposed completely changes that
<hallyn_> pitti: changes it, but if it worked in 204 with stgraber's patch, then it shoudl still work now...  so my question remains, how did it previously get its own cgroup?
<pitti> but merely installing systemd (it's not installed by default in the autopkgtest env, thus only if you depend on it) won't retroactively create cgroups for running sessions, so I don't quite see what changed there
<hallyn_> right
<pitti> hallyn_: I don't know, I'm afraid
<pitti> the other bit that obviously changed recently is the addition of cgmanager to depends
<pitti> so, let me run the upstart tests locally without -proposed
<pitti> if they fail due to that, it's due to installation of cgmanager
<pitti> if they succeed, it's due to the new systemd
<pitti> (in both cases, "most likely")
<hallyn_> oh, well, the test doesn't run if cgmanager isn't installed
<hallyn_> so, that's what changed :)
<pitti> ah!
<hallyn_> jodh: so teh testcase could simply try 'cgm create memory xxx', and if that fails, say "sorry i'm not in my own cgroup; exit"
<pitti> but upstart doesn't build- or test-depends on cgmanager
<pitti> so it wasn't installed before
<hallyn_> exactly
<pitti> so upstart's test should fail in utopic (without -proposed)
<pitti> I'll run it anyway to double-check
<hallyn_> pitti: hm?  no, it shouldn't fail, it should see that cgmanager is not installed and not run.
<pitti> hallyn_: oh right, as we don't install systemd-shim in these VMs, sorry
<pitti> so adding cgmanager as a test dep should cause the failure then
<hallyn_> yup
<pitti> jodh, hallyn_: captured that in bug 1346337
<ubottu> bug 1346337 in upstart (Ubuntu) "test_util_check_env "cgroup sandbox" test fails with cgmanager installed" [Undecided,New] https://launchpad.net/bugs/1346337
<pitti> jibel: ^ FYI, upstart autopkgtest failure
<hallyn_> jodh: are you going to add that check, or did you want me to?
<xnox> hm, yeah. so upstart doesn't build well with cgroups support enabled, yet in the environment where cgroups setup is configured and denied.
<xnox> hallyn_: pitti: ideally we'd want to be able to excercise that test though as autopackage test, instead of a unit test. yeah, it should gracefully skip then. and we'd manually run it e.g. as root to test that it does work with cgroups.
<pitti> sounds good
<hallyn_> the lxc tests auto-run as root;  could the upstart tests just run as root but then su to non-root to actually exec each test?
 * hallyn_ should actually grab the source
<jodh> hallyn_: feel free to tweak. imho, it's a bad idea to start hacking around with the dep8 tests unduly at this stage of the upstart project. Let's be clear - we still only run a subset of the DEP-8'able tests upstart provides due to infrastructure issues (such as running safely as root).
<hallyn_> jodh: so you mean feel free to tweak to not run if we're not in the right cgroup?  is the right thing to do it in lp:upstart and let that push up, or to do it in the utopic package?
<jodh> hallyn_: I guess that skip logic should be fine in lp:upstart and we can cherry-pick into ubuntu.
<shadeslayer> ev: ping, https://errors.ubuntu.com/?user=kubuntu-bugs&period=month never seems to work
<ogra_> pitti, http://paste.ubuntu.com/7830102/ ... i wonder if there is a less intrusive way to suppress kern.log (pinging you because i know you used to merge everything into syslog initially)
<ogra_> i suspect adding a 51-kern-override.conf that redirects to /dev/null would mean it still eats CPU cycles to process the log
<pitti> ogra_: hm, could we rather drop them from syslog instead?
<ogra_> we want to get rid of everything but syslog in touch
<ogra_> so you only have to check two logs (androids logcat or ubuntus syslog)
<pitti> ah, ok
<pitti> ogra_: so, LGTM
<ogra_> but yeah, if we could solve it on another level
<ogra_> i wouldnt object and simply keep kern.log ... (i.e. if i dont have to maintain a hack because the distro package simply keeps them apart)
<stgraber> ogra_: there's a much cleaner way to configure rsyslog to your needs
<ogra_> stgraber, ah, tell me ...
<ogra_> i was assuming there was, but the only thing i could think of was to redirect to /dev/null in a higher versioned override
<ogra_> which surely wont suppress the processing
<stgraber> ogra_: you can drop a file before 50-default.conf (say 40-touch.conf) which defines the targets you care about (copy/paste from -default.conf) and then ends with "*.* ~"
<ogra_> ah, cool
<stgraber> ogra_: "*.* ~" means, stop processing everything at this point
<pitti> oh, nice
<ogra_> thanks !
 * ogra_ will just add it to lxc-android-config then
<stgraber> I just happened to do some complex remote syslog config last night :)
<ogra_> awesome :)
<xnox> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<stgraber> pitti: just to check, to try systemd on utopic I just need to pass init=/lib/systemd/systemd correct?
<pitti> stgraber: correct
<stgraber> pitti: I don't get the same /proc/self/cgroup as you do here...
<pitti> stgraber: I gave you the output under upstart this morning
<stgraber> pitti: ah right, well, we want this to be the same under both upstart and systemd
<pitti> stgraber: ok, so we most likely need to use that JoinControllers= thing in /etc/systemd/system.conf?
<stgraber> pitti: I guess so then, yeah
<stgraber> pitti: anyway, rebooting back into upstart now to check that we haven't regressed unprivileged containers there at least :)
<stgraber> (would be kind of neat if there was a magic "all" value for that which just gets all the controllers from /proc/cgroups and joins them all)
<pitti> stgraber: so what did you do there, run a container under systemd as pid1? what's the "good" and "bad" condition, so that I can verify the change?
<pitti> stgraber: (I suppose you'll be AFK any minute now)
<stgraber> pitti: I'm currently testing an unprivileged container under upstart with the new logind using the shim, so far things look good on that front.
<stgraber> pitti: if using systemd as pid1 instead this will just completely fail at the moment as the cgroup controllers aren't setup properly
<stgraber> pitti: confirmed, unprivileged containers run fine with upstart as pid1 + logind 208. So we're at least not regressing things.
 * stgraber reboots with systemd and will play with JoinControllers see if that does the trick
<pitti> stgraber: at least that seems to be the most direct equivalent of the old logind option
<stgraber> pitti: ok, so joincontrollers isn't what we want at all, that variable is to co-mount controllers and we certainly don't want to do that
<stgraber> pitti: what we want is for the first pid of a user session to be added to all the cgroup controllers instead of just name=systemd
<stgraber> pitti: actually, we should also set joincontrollers but to an empty value, to avoid systemd co-mounting cpu and cpuset which may be problematic in some cases (we've worked around it in cgmanager but I'd much rather we don't have to)
<stgraber> pitti, hallyn_: summary sent by e-mail
<pitti> stgraber: merci
<rbasak> kentb: around? I'm looking at your debdiffs in bug 1343407 now, and have a few review comments. Want to do this now so we can get it landed ASAP?
<ubottu> bug 1343407 in ipmitool (Ubuntu) "Add support for Dell PowerEdge 13G servers" [Undecided,Incomplete] https://launchpad.net/bugs/1343407
<kentb> rbasak, sure
<rbasak> kentb: so in no particular order as I'm just going through it now.
<rbasak> kentb: in the changelog, you should probably refer to the actual file you added to debian/patches rather than just the directory.
<kentb> ok
<rbasak> That's useful for people doing future merges
<kentb> right. makes sense.
<rbasak> kentb: thank you for adding the dep-3 headers to the patch. Just a couple of minor corrections to that.
<rbasak> Since this patch has been sent upstream but not submitted, it technically originates from the patch author, and not from upstream.
<stgraber> hallyn_: oh, also, just noticed/win 50
<kentb> rbasak, ah. ok. got it.
<stgraber> oops, that was a mess, ignore that :)
<rbasak> So we need to drop the Origin field, and a new Forwarded field should point to the upstream URL you referred to in the bug.
<rbasak> kentb: other than that the patch file looks perfect, assuming it's identical to the patch forwarded upstream.
<kentb> rbasak, ok. I'll fix that and post new debdiff in a bit.  Patch is identical to the upstream one.
<rbasak> kentb: finally, for trusty, no need to fix Standards-Version. We just ignore that for SRUs since they need to be the minimal fix.
<kentb> rbasak, ok. thanks for the review!
<roadmr> hey folks! I'm seeing some strange behavior with the hwe stacks on 12.04.x. apt-get install glmark2-es2 on 12.04.4 works OK, but the same on 12.04.{2,3} wants to remove most of the pre-installed x packages (unless I manually install libegl1-mesa-lts-{raring,quantal})
<rbasak> kentb: thanks. THat's everything so far - all very minor. One really really minor thing (don't bother changing it) is that starting the patch with 113 because it's the next available number will probably just confuse a future merge if Debian use 113 also.
<kentb> ko
<kentb> err ok
<rbasak> kentb: I would just not bother with a number, or start it "ubuntu-" or something. But that's so minor I'm sure others will do something different and that's perfectly fine. The name doesn't really matter and I see that you were just trying to follow the pattern, which is reasonable.
<roadmr> also, if I try to install a package which depends or recommends on glmark2-es2, I get either the "remove all existing hwe stack packages" problem, or failure to install due to unmet dependencies... so when glmark2-es2 is not a directly installed package, dependency resolution is having a bit of trouble
<kentb> rbasak,  understood. thanks for the tip!
<rbasak> kentb: I am happy to fix these up before test/upload if you like. No need for you to go round with a debdiff again.
<kentb> rbasak, ok. go right ahead.
<rbasak> ack
<kentb> thanks!
<rbasak> kentb: ah, for the SRU to Trusty, we'll need the paperwork filled out in the bug. Instructions at https://wiki.ubuntu.com/StableReleaseUpdates#Procedure (step 3).
<rbasak> kentb: do you mind doing that while I finish fixes/review/upload?
<rbasak> kentb: the test case would probably just be an expanded version of "run X on 13G; success case: Y displayed; failure case: Z displayed".
<kentb> rbasak, ok
<kentb> rbasak, I'll work on that
<kentb> rbasak, I'll have that posted in the next little while.  I need to head over to the Dell Linux lab and I'll finish up from there.
<rbasak> kentb: OK, no problem.
<roadmr> is there a way to say "I want the libgles2-mesa-lts-* package for whichever enablement stack I have installed" ? how can I programmatically determine which stack I have? Is there a cleverer way than some sort of mapping from installed point release (12.04.2,3,4) to which stack I have?
<cjwatson> Anyone know what's up with the shotwell autopkgtest failure?
<Laney> glib breaks it
<cjwatson> Oh bother.  Is that fixable reasonably quickly?  It's holding up the libav transition now
<Laney> I bisected and filed a bug upstream
<Laney> in what way?
<Laney> You could block glib + skip shotwell
<cjwatson> causes gst-libav1.0 to be invalidated
<Laney> Either do that or remove glib2.0 from propose
<Laney> This upload ain't gettin in in any event
<Laney> It did include some new symbols though
<Laney> But it's got a symbols file so everything will have versioned dependencies and therefore wouldn't have migrated
<sarnold> cjwatson: I've started the librevenge mir, I don't know if I'll be able to finish it today though
<rbasak> kentb: oh, one more thing. Need to run "update-maintainer" to fix the Maintainer field according to https://wiki.ubuntu.com/DebianMaintainerField. I missed that and uploaded without. I won't worry about it except for next time.
<cjwatson> Laney: pretty sure my transition is cursed
<cjwatson> sarnold: thanks
<Laney> cjwatson: I'd say remove glib2.0 if you want
<cjwatson> Laney: ok, removed - do you think you could rebuild banshee and harfbuzz a bit later once glib2.0/utopic-proposed disappears from rmadison?
<cjwatson> those are the two rdeps listed in http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
<kentb> rbasak, ok.  I'm filling out sru stuff right now
<j_f-f> Many thanks for doing my work
<ari-tczew> is there any ppc64el PPA, where can I test building packages/ patches?
<cjwatson> I'm afraid that that's only possible in devirtualised PPAs right now, which are only accessible to Canonical employees.
<cjwatson> We can test-build fixes for you on request if need be
<cjwatson> (Though not me just now - time to read bedtime stories)
<ari-tczew> would be nice to make free one PPA for ubuntu developers with difficult archs like ppc64el, powerpc etc.
#ubuntu-devel 2014-07-22
<pitti> Good morning
<pitti> slangasek: wrt. ddeb-retriever rollout> I noticed yesterday that a lot of ddebs can't be mapped to package indexes because they were built for the train PPAs or will be in binNEW
<pitti> slangasek: so ddeb-retriever needs to grow a "queue" mechanism to try and process them until they do get published; so still can't roll out yet :/
<pitti> xnox: I don't fully understand bug 1326327, but this should go to Debian as well, right? it sounds related to debian bug 749400?
<ubottu> bug 1326327 in debhelper (Ubuntu) "dh_installinit should generated update-rc.d remove to remove rc*.d symlinks" [Undecided,New] https://launchpad.net/bugs/1326327
<ubottu> Debian bug 749400 in debhelper "dh_installinit: disable init scripts on removal of package" [Normal,Open] http://bugs.debian.org/749400
<pitti> xnox: perhaps you can forward it, with some more explanation?
<spacetime> Hey, I'm trying to add a new seed but when I update, I get http://paste.ubuntu.com/7834499/  . Could someone help me figure out what I'm doing wrong?
<cjwatson> spacetime: Looks like you didn't add it to STRUCTURE properly
<spacetime> cjwatson: where's STRUCTURE?
<spacetime> cancel that. found it.
<Riddell> StevenK: wish hobbsee a happy birthday
<xnox> pitti: i thought that it's a bit reverse, in Ubuntu we had delta on top of Debian to do the opposite.
<xnox> pitti: and I'm not yet sure if everything is correct, cause e.g. I've seen really strange generated postinst in qemu.
 * xnox reads the pointed out bugs again.
<Laney> is anyone else getting BADSIG on ddebs.u.c?
<Laney> hrm, yeah, looks like Release.gpg is out of date
<Laney> http://ddebs.ubuntu.com/dists/utopic/
<pitti> Laney: yeah, sorry; current ddeb-retriever has run for almost a day already, seems I touched a lot of .debs or so and apt-ftparchive takes aaages
<Laney> pitti: and dists/ is updated in a racy way?
<pitti> Laney: yes, currently not atomic
<Laney> mmm, I see
<pitti> another deficiency of the temporary hack from 8 years ago *sigh*
<pitti> Laney: unless apt-ftparchive already does that by itself, but seems not?
 * pitti puts that at the end of the long queue of TODOs for current rewrite
<Laney> I'd think that it would, but I've not used it myself to say for sure
<Laney> Maybe you have to do this yourself actually, looking at its manpage
<jodh> pitti: fyi http://anonscm.debian.org/gitweb/?p=autopkgtest/autopkgtest.git;a=blob_plain;f=doc/README.package-tests;hb=HEAD shows "404 - Cannot find file"
<jodh> pitti: (as linked to from http://dep.debian.net/deps/dep8/)
<pitti> jodh: I know, it was renamed to .rst
<pitti> jodh: hm, I updated that in svn ages ago; seems that doesn't automatically get rolled out
<pitti> jodh: thanks, I'll find out who to contact about this
<jodh> pitti: ta. Is there any capability in the dep8 framework to look for core files left behind by tests, or is it up to each test to implement those checks?
<pitti> http://lists.alioth.debian.org/pipermail/dep-commits/2014-July/000316.html FTR
<pitti> jodh: the latter; I don't want to search the entire file system for core file, that would be quite inefficient
<pitti> the test knows where to look for them (and most tests don't use core dumps)
<pitti> you can put them into $ADT_ARTIFACTS if you want to export them
<pitti> (but please compress them first :) )
<pitti> jodh: we could collect apport crash reports though, if that's sufficient
<jodh> pitti: ack. I've found a couple of commands recently that core dump but there is no dep8 test. so I was kinda hoping I could create a NOP dep8 test and get the rest for free. However, copy+paste it is... :)
<jodh> pitti: might be a nice extension to have a way for a dep8 test to request that core files be checked for in say '/', any directory specified by a *.install file and any directory in or below the ADT test run directory though.
<jodh> pitti: I agree that we don't want to trawl the entire FS though :)
<pitti> poked
<pitti> and we don't want to routinely pick up all core files, I think; they are quite huge, and we basically store them forever
<jodh> pitti: I'm not suggesting we pick them up necessarily, just that iff a test specifies an interest in core files, that test would be failed if any were found.
<pitti> I think it makes more sense to (1) either collect and post-process apport reports (without core)
<pitti> or (2) locally run the test with -s
<pitti> to get a shell, and debug in the testbed
<jodh> pitti: cheaper to find the problems earlier imho
<pitti> jodh: but woudl that actually buy you much? you still need to reproduce the same test environment
<pitti> so you could just as well re-run the test
<jodh> pitti: yes, but if we atleast flag it at the dep8 stage, we could avoid releasing versions of programs that dump core everywhere :)
<pitti> right
<pitti> jodh: you mean your test succeeds, but something still crashes?
<jodh> pitti: I'm not talking about any of my tests. There are a couple of bugs I've hit recently in packages with no dep8 tests. The commands in these packages core dump when run.
<pitti> ah, so a smoke test like running the program with some sensible/easy options succeeds would help there?
<jodh> pitti: yeah.
<pitti> Laney: hm, I just had a quick attempt at atomically updating dists/, but that's utterly hard :/
<pitti> meh, I already have half a soyuz implementation in ddeb-retriever; I really don't want to pile more hacks upon it
<pitti> Laney: it does update Packages.gz atomically, but not the whole dists/
<Laney> pitti: Dare I ask if ddebs in launchpad is coming soon anyway? ...
<cjwatson> Laney: Blocked on prodstack 4
<cjwatson> The Launchpad side is done
<Laney> Yeah so I understand
<pitti> is that ddebs in librarian, or actual archive generation, too?
<cjwatson> But we need the new librarian or it'll run out of space
<cjwatson> pitti: librarian
<cjwatson> Er, wait
<pitti> that's already a huge progress in terms of stopping to lose ddebs
<cjwatson> Just the librarian bit is blocked on prodstack.  As far as I know the ddebs implementation in Launchpad covers archive generation too.
<pitti> my main difficulty is to re-model binNEW, component changes, copying from PPA, and all the other funny stuff that can happen to the main indexes
<wgrant> We don't do archive generation for the primary archive today.
<pitti> oh, way cool!
<wgrant> The primary archive's ddebs, that is.
<wgrant> It's difficult to implement.
<cjwatson> Ah, I'm misinterpreting r16629 then, sorry
<wgrant> That's only for PPAs atm.
<cjwatson> I assumed that since that touched lp.archivepublisher.model.ftparchive that it affected primary too
<Laney> pitti: In the meantime I'd go ask #debian-ftp for help if you're motivated
<pitti> Laney: still fighting with my code to properly queue ddebs to cope with PPA/binary NEW, and other fun exceptions
<Bluefoxicy> Any thoughts on making /tmp and /run/user btrfs subvolumes, mounted as noexec,nodev,nosuid ?
<Bluefoxicy> (yes, I realize nobody has told the system perl/python/bash interpreters to check for noexec and refuse to load scripts)
<xnox> Bluefoxicy: /run/user may not be btrfs.
<xnox> that would be violation of XDR Directory Spec.
<xnox> and it's already noexec.
<xnox> by default we don't do anything for /tmp. there were plans to make /tmp on tmpfs by default, and thus hence noexec would be possible but that hasn't been implemented.
<xnox> Bluefoxicy: for reference see /lib/init/fstab
<Bluefoxicy> xnox:  wait, what?
<Bluefoxicy> oh
<Bluefoxicy> it's a tmpfs
<Bluefoxicy> xnox:  I didn't notice that, somehow, in the pile of mount output
<xnox> Bluefoxicy: locally i have /tmp on tmpfs with noexec, nodev, nosuid.... but we can't  / don't have that by default.
<Bluefoxicy> nod
<Bluefoxicy> I've been mounting @home that way
<mdeslaur> you'd probably want to mount /var/tmp noexec also, else, there's no point
<mdeslaur> (well, I personally think there's no point for /tmp either, but meh)
<Bluefoxicy> heh
<pitti> xnox: thanks for fixing lava-dispatcher! can you please send this fix to Debian?
<xnox> pitti: yeah, i will.
<pitti> xnox: danke
<xnox> that should help with parted transition.
<pitti> slangasek: pressed the big red ddeb button; *phew*
<seb128> barry, hey, why did you change my patch pilot schedule for tomorrow?
<barry> seb128: um, what?
<seb128> barry, just got an email
<barry> seb128: how weird!  i haven't touched the pp calendar.
<seb128> barry, from google calendar, say you changed my patch pilot invitation for wed jul 23
<seb128> saying
<seb128> barry, that's the patch pilot schedule I think
<barry> seb128: that's mysterious ;)
<seb128> yet happened, fwded you the email in case you don't believe me
<seb128> barry, didrocks mentioned recently you edit his as well
<seb128> barry, I wonder if your workflow is doing thing you don't expect or something?
<barry> seb128: oh, i believe you got the email
<barry> seb128: like, every time i upload a package, someone's patch pilot gets changed? :)
<seb128> lol
<seb128> you didn't open google calendar?
<seb128> k, dunno what that happened then
<seb128> but I would like to know what changed
<seb128> like was I scheduled for tomorrow, or did you just move the invitation to another day?
<barry> seb128: i see the email.  i have no clue why that's coming from me!
<barry> seb128: i only opened my canonical calendar when you pinged me, but that would violate causality
<seb128> k, dunno what happened then :/
<seb128> strange
<barry> me neither!  i guess dholbach isn't around.  i think he owns that calendar
<barry> seb128: i'll forward that to him and cc you
<seb128> barry, thanks
<xnox> infinity: pkg-util-linux ftbfs on i386
<cjwatson> xnox: lava-dispatcher> oh, thanks, I was going to look at that once I was back off 3G tethering
<xnox> cjwatson: isp bonding in progress?
<xnox> =)
<cjwatson> xnox: No, disk trouble on my router
<cjwatson> It never rains but it pours
<cjwatson> The actual ADSL line is fine :)
<ogra_> cjwatson, SES Astra offers pretty cheap 20MBit sattelite lines in germany recently ... i wonder if they have something similar for the UK
<xnox> shadeslayer: cjwatson: ubiquity upload has a strange dep change. "s/python3-dbus/python2-dbus" on ubiquity-frontend-kde. What's up with that, shadeslayer ?
<xnox> should I fix it?
<juliank> ogra_: cjwatson: See http://uk.ses-broadband.com/10390967/uk
<cjwatson> xnox: I completely missed that.  Looks like a typo.  Please fix
<cjwatson> ogra_,juliank: No thanks, just switched ISP and not in a rush to have any more hassle
<ogra_> juliank, heh, in germany they actually founded a sub-company https://www.orbitcom.de/shop/astra-connect-xxl.html
<xnox> juliank: satelite is crap uplink, no?!
<juliank> xnox: 2 mbit/s uplink.
<juliank> But you can get much faster offerings
<cjwatson> And my trouble today has nothing to do with my ADSL anyway
 * xnox likes to upload tarballs & binaries into debian.....
<juliank> symmetrical elsewhere
<mlankhorst> xnox: with debug symbols :-D
<ogra_> xnox, well, i would keep the DSL i have and use the sat as a cheap download line :) the latency is surely awful
<ogra_> but 20MBit vs 2MBit DSL that i can get here without replacing the whole wiring of the house ;)
<xnox> juliank: ogra_: i have 120 MBit / 20 MBit at the moment with Virgin media cable.
<ogra_> lucky you
<juliank> I have 10/10 at university town home and 16/1 at parent home
 * ogra_ pays a fortune for a 2MBit SDSL line ... the fastest i can get in this house 
<cjwatson> xnox: Looks like fixing ubiquity should be the last piece of the parted transition, indeed
<xnox> uploaded.
<cjwatson> thanks!
<juliank> ogra_: Get Sat internet then. 20 down / 6 up at http://www.skydsl.eu/de-DE/Satelliten-Internet/tariff/skydsl2p/sky2pt8
<juliank> Using Eutelsat, not Astra.
<ogra_> that means i need a second dish i guess
<ogra_> i already have a TV dish pointing to astra
<juliank> ogra_: You should be able to use a single dish. If less upstream is OK, get an SES Astra one.
<shadeslayer> xnox: not my doing
<juliank> You can usually reach both Eutelsat and Astra with a single dish
<ogra_> well, we'll see :)
<juliank> ogra_: SkyDSL is a bit expensive, but is a real flatrate, the Astra Connect stuff had traffic limits.
<ogra_> juliank, not the XXL offer
<ogra_> thats flat for 69â¬
<juliank> Ah cool
<xnox> shadeslayer: is this not your commit? http://bazaar.launchpad.net/~rohangarg/ubiquity/plasma5/revision/6199
<ogra_> and i doubt i actually want to do uploads via sat :)
<juliank> ogra_: Why?
<ogra_> dunno ... latency ?
<juliank> Sky DSL only costs 60â¬ after 12 months have passed, BTW.
<ogra_> do you have any first hand experience with it ?
<juliank> ogra_: But that does not matter for package uploads :)
<ogra_> indeed
 * juliank only had a 1-way downstream sat connection (upstream via 56k modem). No idea about the bi-directional stuff.
<juliank> ogra_: Latency is about 700ms according to SkyDSL
<shadeslayer> xnox: oh uh
<shadeslayer> how did that happen 0.o
<arges> cjwatson: hey today's my sru day, are there any freezes I should be aware of before reviewing the upload queue?
<cjwatson> arges: coordinate with infinity
<arges> cjwatson: ok
<cjwatson> arges: you probably at least want to be pretty careful about trusty
<arges> I figured as much; infinity anything that would be constructive for me to review in the trusty upload queue or pending SRUs?
<stokachu> stgraber, ive run into a weird issue with lxc -- sudo lxc-create -t ubuntu -n maas -- --packages maas,maas-dns,maas-dhcp fails where as running apt-get install after lxc creation allows maas to install
<flexiondotorg> cjwatson, Can I ask you a quick question about live-build?
<stokachu> stgraber, http://paste.ubuntu.com/7832005/
<cjwatson> flexiondotorg: just ask, don't ask to ask :)
<stokachu> stgraber, you seen anything like that before?
<flexiondotorg> I'm working on Ubuntu MATE Remix. I'm using the following script to make to iso images.
<flexiondotorg> http://bazaar.launchpad.net/~ubuntu-mate-dev/ubuntu-mate/ubuntu-mate-iso/view/head:/build-ubuntu-iso
<flexiondotorg> The resulting .iso is missing to pool and dist directories that I see in the official flavours.
<flexiondotorg> Is there a way to enable/mimic that behaviour?
<ogra_> not easily
<ogra_> Laney, wasnt that your script initially ? ^^^
<ogra_> (iirc popey based on it)
<Laney> umm
<flexiondotorg> It is adapted from a script by Laney
<Laney> I can't really provide support for that
<cjwatson> flexiondotorg: live-build has some features a bit like that (dpkg -L live-build | xargs grep -s pool), but we only use live-build to build the actual squashfs, we don't use it for the whole thing
<flexiondotorg> cjwatson, Yeah so I've seen.
<cjwatson> we use lp:ubuntu-cdimage plus the various other bits listed in configs/devel there to put the top-level ISO stuff together
<flexiondotorg> I've read  lp:ubuntu-cdimage
<ogra_> why not simply start working on making it a real flavour
<cjwatson> I guess you might be able to do something with config/package-lists/ in live-build, but I have no idea really
<flexiondotorg> I'm just trying to mimic the official iso image as much as posisble while we are not an official remix.
<ogra_> thats most likely easier than trying to get cdimage/debian-cd to work with the script
<flexiondotorg> OK, that is a useful pointer.
<cjwatson> Right, ubuntu-mate seems like the kind of thing that might be on a relatively short path to being official if you asked
<ogra_> yeah
<flexiondotorg> cjwatson, We do want official status.
<flexiondotorg> I just wanted to get all the initial work completed up front to ease the merge.
<flexiondotorg> I'm about there.
<ogra_> flexiondotorg, but proper builds :)
<cjwatson> I wouldn't worry about this part of it for that purpose
<cjwatson> Certainly not if it's going to involve a ton of duplicated work
<ogra_> flexiondotorg, we have ubuntu-desktop-next ... thats probably years from being something official ... and still we build daily images for it
<cjwatson> I mean, it absolutely is possible to set up cdimage locally, all the code is public, but it involves things like a full mirror
<flexiondotorg> ogra_, I really want to benefit from the official builds. I've had to get EFI and SecureBoot without access to either hardware.
<cjwatson> It's a pain
<cjwatson> So while I'm happy to help if that's what you actually need, I'd prefer to only go through that for things that can't be official RSN
<flexiondotorg> cjwatson, I did review your code. But decided it wasn't worth the effort in re-implementing it utside the official infrastructure.
<flexiondotorg> cjwatson, Not sure I follow. But what I'd like to do is merge my livecd-rootfs changes (minimal) , seeds and meta-packages so that Ubuntu MATE could be built officially.
<flexiondotorg> Is that something that is possible without going through all the "official flavour" process?
<cjwatson> Sure
<flexiondotorg> That would be great.
<ogra_> we have a process for that ?
<cjwatson> unhelpful
<ogra_> just curious
<cjwatson> it may not be written down clearly but there is certainly a process (as in series of steps)
<ogra_> i thought having a seed and building from the archive would be enough
<flexiondotorg> cjwatson, Is that something you can share so I can start the process?
<cjwatson> it would normally involve talking to the tech board
<cjwatson> feel free to CC me (cjwatson@u.c)
<flexiondotorg> cjwatson, Can I do that or do I need a "sponsor"?
<cjwatson> And https://wiki.ubuntu.com/RecognizedFlavors
<cjwatson> flexiondotorg: whoever's the project lead ought to do it; you're going to want people who can actually upload stuff directly as soon as possible
<flexiondotorg> cjwatson, Thanks. I am the project lead.
<slangasek> pitti: ah, so the ddeb-retriever update is deployed now? \o/  Sorry for not making any progress on this on Friday for you, ran out of time :(
<pitti> slangasek: yes, it is (I kept a backup of the old files too, just to be sure)
<apachelogger> mvo_: we've just been wondering... is there a reason apt-xapian-index doesn't register a APT::Update::Post-Invoke-Success hook to update the database?
<mvo_> apachelogger: the only reason that its expensive to run and would make each apt-get update very slow (and even rebuilding in the background is a bit anoying as it tends to consume quite a bit of io/cpu)
<apachelogger> mvo_: aren't incremental updates relatively fast? the thing is... currently all kde software using libqapt needs to explicitly update the database which is highly annoying and causes unintended side effects when someone forgets to do that, so we've been wondering about how to remove the requirement globally
<mvo_> apachelogger: they are sort of fast, we had problems in the past with corruption though, this is iirc why the --update part got disabled
<mvo_> apachelogger: might be worthwhile to see if that is still a sissue
<apachelogger> mvo_: thanks, I'll put down a todo to look into this in detail
<mvo_> thanks
<bdmurray> pitti: I've seen a few cases where an apport retraced crash does not have a Stacktrace in it. Would we need the CoreDump to definitively sort out what happened?
<pitti> bdmurray: yes, I think it would certainly be helpful for debugging the underlying gdb problem
<bdmurray> pitti: okay, so this is insufficient? https://pastebin.canonical.com/113960/
<pitti> infinity, kees, slangasek, mdeslaur: TB meeting in 3 mins reminder
<mdeslaur> pitti: ack
<slangasek> pitti: yes; I have conflicting meetings, I'm afraid I have to send my regrets
<pitti> bdmurray: fun, that has a StacktraceTop, so it shoudl have had a Stacktrace, too
<pitti> slangasek: noted
<kees> pitti: thanks!
<pitti> bdmurray: could also be funny characters/breaks/etc. which confuse the parsing of the stack trace (but I wouldn't know without seeing the original raw gdb output :/)
<bdmurray> pitti: okay, I'll work on saving the CoreDumps then
<pitti> bdmurray: is this a "sun ray glitch" thing, or did you see this more often?
<bdmurray> pitti: looking at the statsd counters for this there is a very low volume, so I think I'll file a bug for some day later
<pitti> bdmurray, jibel: btw, I haven't yet had time to look into/respond to the retracing armhf thread, will do ASAP
 * pitti has been stuck with other high-prio things, sorry
<bdmurray> pitti: a fair number of things are retracing - https://errors.ubuntu.com/?release=Ubuntu%2014.10&period=day&pkg_arch=armhf
<infinity> pitti: Gah.  Not even remotely paying attention to things like meeting reminders.
<pitti> infinity: it's just over; you still have a carried "review/reply to juju MRE proposal"
<infinity> pitti: Right, I didn't do that, so carried it is.  Sorry about the no-show.
<pitti> infinity: no worries
 * pitti waves good night
<pitti> bdmurray: hm, I can't click on any of these errors, I always get the "computer over" fail page; so these are all ok?
<pitti> bdmurray: ah, some work
<pitti> bdmurray: but e. g. https://errors.ubuntu.com/oops/94734414-1180-11e4-8bdd-fa163e78b027 failed to retrace
<pitti> bdmurray: none of these show "stacktrace", for privacy reasons I suppose?
<pitti> ah no, e. g. https://errors.ubuntu.com/problem/eb8fe775c22d5210f56ad7ac038ac1b1895f4465 is just fine
<pitti> bdmurray: so that part was (hopefully) due to the broken gdb-multiarch, and should be fixed now
<pitti> anyway, tomorrow; it's been too long today
 * pitti waves
<Pici> Is /36
<achiang> hallyn: hey, i'm experimenting with something in lxc and i'd like to do something i know is dangerous... how do i grant permission to /proc?
<achiang> Cannot chdir into /proc/ directory: Permission denied
<elopio> hello
<elopio> is there a core dev around to review the packaging changes in this branch?
<elopio> https://code.launchpad.net/~canonical-platform-qa/url-dispatcher/fake_dispatcher/+merge/227778
<hallyn> achiang: ?  you should be able to cd into /proc....
<achiang> hallyn: hm, maybe my problem is something else... i'm attempting to run our own webbrowser-app in a container
<hallyn> achiang: edit /etc/apparmor.d/abstractions/lxc/container-base
<achiang> hallyn: and we essentially have a thin layer over the blink runtime.
<achiang> hallyn: i notice from here that we start chrome with --disable-setuid-sandbox - https://www.stgraber.org/2014/02/09/lxc-1-0-gui-in-containers/
<achiang> so maybe our webbrowser-app (oxide) has the same issue
<hallyn> yeah, i'm running it like that
<cjwatson> elopio: looks fine to me as long as the resulting url-dispatcher-testability binary package only contains python3 modules
<cjwatson> elopio: actually don't you want ${python3:Depends} in url-dispatcher-testability too?
<achiang> hallyn: "running it like that" -- what is "it" ?
<hallyn> chrome instide a container following stgraber's instructions :)
<hallyn> the rason to disable seccomp is bc by default we now have the container already inside seccomp
<achiang> hallyn: ah. well maybe oxide doesn't respect that cmdline arg yet
<cjwatson> elopio: I would generally include ${python3:Depends} in the dependencies of packages shipping python3 modules even if it doesn't expand to anything at that point
<elopio> cjwatson: right, the packaging guid of python3 mentions that.
<hallyn> achiang: anyway yes, if you just set lxc.aa_profile = unconfined you should have full access to /proc
<elopio> cjwatson: can I add it in a following branch? This is not my branch, and I wouldn't like to delay it more.
<hallyn> if htat works, then from there you can write a policy that works for you
<achiang> hallyn: where do i set that? in the file you pointed me at above?
<hallyn> (lemme know if you need help wit htat)
<hallyn> no, in the contaienr configuration file
<hallyn> .local/share/lxc/u1/config or /var/lib/lxc/u1/config
<cjwatson> elopio: I'd rather it went in this branch, seeing that this is likely to have to wait for silo 8 to get sorted out anyway
<achiang> hallyn: ok, i have that...
<cjwatson> elopio: as a matter of form I don't think it's good to pressure people into giving acks
<achiang> hallyn: well, i have lots of things in there.
<elopio> cjwatson: ok, I'll tell brendan to update it.
<cjwatson> the point of getting core-dev acks on things is to fix the packaging before it lands so fixes aren't forgotten :)
<cjwatson> thanks
<elopio> cjwatson: sorry, I didn't understand that last message.
<elopio> oh, yes, you are right.
<hallyn> achiang: not sure what you mean.  lots of things in that file?
<achiang> hallyn: this is my config for the container - http://pastebin.ubuntu.com/7838928/
<cjwatson> elopio: if you can verify that it makes no difference to the generated dependencies either way, then I'd be OK with fixing it in a follow-up
<hallyn> achiang: looks good
<hallyn> fire it up
<achiang> hallyn: and this is my default.conf - http://pastebin.ubuntu.com/7838930/
<elopio> cjwatson: no, I think you are right. Better to get it as good as possible on this branch. I thought this would auto-land, but it goes through a silo, so we wouldn't be delaying anything.
<hallyn> achiang: you're saying it was already like that?
<elopio> actually, I can push to this branch.
<achiang> hallyn: i just made those edits, stopped the container, and restarted it... now getting - http://pastebin.ubuntu.com/7838936/
<elopio> would it be bad manners to modify somebody else's branch?
<cjwatson> if you can commit to it I don't see why it's bad
<cjwatson> presumably it's team-owned for a reason
<cjwatson> elopio: yeah, silo not yet assigned and we only have one free right now, would prefer to reserve that for emergencies in any event ...
<cjwatson> (silly system, but)
<hallyn> achiang: strace the app
<elopio> cjwatson: ok, pushed.
<achiang> hallyn: huh. kinda interesting - http://pastebin.ubuntu.com/7838964/
<cjwatson> elopio: thanks, looks good to me
<elopio> thanks to you.
<elopio> this is nice :D the testability packages are making me happy.
<hallyn> achiang: hm, I suppose try "sudo strace -f -ff -u ubuntu -o oxide webbrowser-app"
<achiang> hallyn: neat - http://pastebin.ubuntu.com/7838978/
<hallyn> haha
<hallyn> achiang: ok, well can you "cd /proc" ?
<slangasek> hallyn: hmm, so why is cgmanager no longer in the Debian NEW queue, nor in Debian unstable?
<achiang> hallyn: yes
<hallyn> slangasek: well, dba raised a stink;
<achiang> hallyn: http://pastebin.ubuntu.com/7838982/
<hallyn> slangasek: there's a trail both in the ITP and in private emails including the debian ftp admins
<hallyn> slangasek: short story is dba is supposed to push a new version based on my 0.28 upstream.  he said he'd do that last friday.
<hallyn> uh, i think it was last friday.  anyway, this morning he said he'd upload today
<slangasek> hallyn: um.  so on what grounds was your package rejected from the NEW queue?  Or dba's package, for that matter?
<hallyn> i can fwd you some amusing emails if you like.  i also asked him in private (after he pmd me) if there was any advantage to his packaging;  no answer to that.
<hallyn> on the grounds that there was conflict.  I was seen as usurping his submission.
<hallyn> so ftpadmin (paultag) dropped both
<hallyn> said for us to work out out
<hallyn> my only complaint in all this is,
<hallyn> at teh same time they take months to accept NEW packages, while they complained that we pushed cgmanager to ubuntu without waiting for debian
<slangasek> ok
<hallyn> (paultag did)
<infinity> Working things out with dba is often entertaining.  Good luck.
<hallyn> i like teh guy, but that stance was annoying
<slangasek> I think I'll be taking that up with paultag, because I don't consider that grounds for a reject ;)
<hallyn> as i told dba in private, i dont' give a rats ass who maintains the package, but if he doesn't have time, why the hell push this way?
<hallyn> (that is, i don't care about me being the maintainer;  but i do care taht someone i can work with maintains it)
<hallyn> anyway.  achiang - i'm perplexed.
<hallyn> oh.
<hallyn> achiang: you showed me a grep.  can you pastebin the full strace output?
<achiang> hallyn: oh erm... there are lots of files.
<hallyn> achiang: drop -ff and rerun?
<hallyn> should then all go to one file
<achiang> hallyn: i'll pastebin the one with the chdir
<hallyn> (re-run with new filename else it'll append :)
<hallyn> well i need to follow all the creds changes
<hallyn> slangasek: I assuem you're saying there is not yet a new cgmanager in NEW?
<hallyn> that makes me sad
<achiang> hallyn: ok
<slangasek> hallyn: there is not
<achiang> hallyn: giant pastebin - http://pastebin.ubuntu.com/7839005/
<hallyn> achiang: ah, thanks.  looking
<hallyn> two instances of 7979  prctl(PR_SET_NO_NEW_PRIVS, 0x1, 0, 0, 0) = 0
<hallyn> and 7979  prctl(PR_SET_SECCOMP, 0x2, 0x7fffbe55f810, 0xffffffffffffffff, 0) = 0
<hallyn> achiang: can you grep -i seccomp /proc/self/status int he container?
<hallyn> both tasks 7979 and 7989 tried to set NNP, then set seccomp filters, then exited with 7979  +++ exited with 100 +++
<achiang> $ grep -i seccomp /proc/self/status
<achiang> Seccomp:	0
<hallyn> hm
<hallyn> and i assume this works outside of a container?
<achiang> hallyn: well... kinda. i at least get a window that pops up on my desktop (although it is blank)
<achiang> hallyn: that would be running outside the container on a trusty host
<achiang> just running the trusty version of webbrowser-app from the cmdline
<hallyn> achiang: so if you strace it on the host, what happens after the PR_SET_SECCOMP ?
<achiang> is anyone running utopic natively? perhaps they could just try to launch webbrowser-app from the cmdline and see if that works
<achiang> hallyn: http://pastebin.ubuntu.com/7839069/
<achiang> hallyn: i'd say don't worry about spending more time on me today. i'll send a mail to chrisccoulson asking for some help... it could be as easy as supporting the same --disable-setuid-sandbox for oxide
<achiang> hallyn: thanks a ton already
<hallyn> achiang: my utopic laptop is the one that died recently;  so i'm not until my new one arrives.  lenovo keeps pushing the ship date back day by day :)
<achiang> nice
#ubuntu-devel 2014-07-23
<hallyn> pitti: oh, pls.  systemd-shim sets autoremove on login directories.  that breaks running the cgmangaer tests without moving yourself out of login directory :)  it'll definately be better to get StopSession+Abandon working from systemd-shim, and not set autoremove
 * hallyn wonders whether desrt is back
<pitti> Good morning
<pitti> hallyn: yes, I was talking to desrt yesterday
<pitti> hallyn: what is "autoremove on login directories"?
<pitti> hallyn: do you know about the status of reuploading cgmanager to Debian?
<Unit193> It's on mentors, as of "today"
<hallyn> pitti: systemd-shim sets RemoveOnEmpty, so that after all tasks in a cgroup and all child cgroups disappear, the cgroup dir is removed
<hallyn> pitti: cgmangaer should be uploaded tomorrow i'm hoping
 * hallyn out
<pitti> hallyn: ah, thanks
<pitti> sergiusens: do you plan to merge https://merges.ubuntu.com/t/telepathy-mission-control-5/, or want me (or someone else) to steal? (needed for upower transition)
<sergiusens> pitti: I never knew I was supposed to; in any case I can't upload so feel free to do it (my stuff was apparmor related that jdstrand promoted)
<pitti> sergiusens: right, you were the last uploader, so by default you are the merger
<pitti> sergiusens: ack, thanks
<sergiusens> pitti: am I supposed to get an email about this? I don't want to block people in the future :-)
<pitti> sergiusens: no email; they are on https://merges.ubuntu.com/main.html
<pitti> sergiusens: (and /universe.html, etc.)
<sergiusens> gt it
<sergiusens> thanks
<pitti> xnox: FYI, http://anonscm.debian.org/cgit/collab-maint/pkg-util-linux.git
<pitti> xnox: I just asked Andreas when he plans to land this
<smb> infinity, Just saw the email about helping out with iso testing for the Trusty point release. Is there a way to see which ones are in progress right now and which untaken. Not that all start doing the same which is not helping much
<jibel> smb, you can follow the progress and submit results on the iso tracker http://iso.qa.ubuntu.com/qatracker/milestones/318/builds
<dholbach> good morning
<jibel> smb, the download links are wrong for trusty, you must add 'trusty' in the url eg. http://cdimage.ubuntu.com/trusty/daily-live/20140722.2/trusty-desktop-amd64.iso
<smb> jibel, Ah ok. Hm yeah seem to have changed even in the few minutes I did not refresh
<xnox> pitti: i got emails it's in experimental.
<pitti> xnox: yep, it was just duly celebrated in #debian-gnome :)
<xnox> pitti: and as I pinged infinity, it's ftbfs on !amd64 =)
<pitti> xnox: yes, known
<pitti> (I think, ah mentioned something like that)
<pitti> he's also preparing 2.25 and a fix for the remaining RC bug
<xnox> pitti: anyway, i was testing usb-creator / udisks2 against it, and it seems fine. However, didn't fix my woes, so uploaded a patch adding to udisks dbus options "just-do-it" flag, which makes everything work =)
<pitti> yeah, that's the "quick hack" part which we need to revert; it's not documented/upstream and just a workaround for the actual bug
<pitti> e. g. supposedly if this happens the disk hasn't actually be cleaned properly
<xnox> pitti: well, reading the code (a) i give a full block disk, e.g. /dev/sdb (b) ask to format (c) it waits for it to magically re-appears after wipefs -a (d) it doesn't, since we need to call Rescan to read partition tables by the OS, or lack of thereof.
<xnox> thus, with the "plug" it goes to blindly create requested partions/partition-table/filesystem, which then validate afterwards.
<xnox> pitti: maybe i'm failing to understand udisks2 expectations there, and how they are not satisfied at that point.
<smb> jibel, Hrm, would you say a missing "update" option on the manual partitioning and re-use home test case is a bug or a feature. Its the same image used to install after all. What I get is only install alongside or erase...
<jibel> xnox, what are the conditions in ubiquity to see the option 'reinstall ubuntu' in the partitioner ?
<jibel> s/reinstall/upgrade/
<smb> Meh, filed bug 1347521 in the mean-time
<ubottu> bug 1347521 in ubiquity (Ubuntu) "No update/upgrade option when re-installing with same ISO" [Undecided,New] https://launchpad.net/bugs/1347521
<xnox> smb: *sigh* upgrade would only be offered from 13.10 -> 14.04.1 daily
<jibel> smb, the option 'upgrade' is only displayed if the installed version is older than the version you're installing otherwise you will see 'reinstall'
<xnox> smb: but reinstall should be offered for in-place 14.04.1 dailies.
<shadeslayer> ev: around?
<ev> hi
<smb> xnox, I did not see reinstall other than install alongside :/
<xnox> smb: =(
<xnox> smb: it is strange that you already mention that /home is on a separate partition.
<shadeslayer> ev: any clue why https://errors.ubuntu.com/?user=kubuntu-bugs&period=month doesn't give me any info
<xnox> smb: btrfs?
<shadeslayer> ev:  and goes "An error occurred while trying to load the most common problems."
<smb> xnox, No ext4. That is part of the test instructions
<smb> (not the ext4 part but to have home seperate)
<xnox> smb: ok.
<ev> shadeslayer: it needs to be added to http://bazaar.launchpad.net/~daisy-pluckers/daisy/trunk/view/head:/tools/import_user_packages.py . Feel free to propose an MP which does that.
<shadeslayer> ev: thx
<shadeslayer> ev: this worked before though
<xnox> smb: during .1 release testing we are ideally looking for bugs and things that regress verses a .0 baseline.
<shadeslayer> ev: https://code.launchpad.net/~rohangarg/daisy/add-kubuntu-bugs/+merge/227879
<smb> xnox, Yeah, and you can always choose to ignore certain bugs. But when I do follow test instructions I try to follow test instruction. And them say, if not expected behaviour, file bug. So I file bug. 3:) I don't mark them critical, though
<xnox> smb: cool. and i hope that test cases do not guide one into impossible situations. E.g. install with lvm, and then do manual re-partitioning.
<apw> xnox, you hope for the impossible
<smb> xnox, They may not guide one, but I happened to just re-use a disk with lvm when running a test-case asking for that... :-P
<xnox> smb: =))))))))))))))
<xnox> lolz
<xnox> good good.
<ev> shadeslayer: merged. Should work on the next cron run (I think it's daily)
<smb> xnox, You are not really expecting our users to not do the impossible ... ;) As I said, I won't mark those things as critical but keep opening bugs just to document things
<shadeslayer> thanks! :)
<xnox> psivaa: plars: are there ubiquity autopilot tests running for all flavours, with trusty daily images?
<psivaa> xnox: i'm not sure about ubiquity AP tests. may be jibel knows?
<jibel> xnox, no, it's only testing the dev release, I'll add them
<xnox> jibel: yes please, that would help a lot for smoke testing and respins.
<jibel> xnox, I fully agree since the fallback is me doing manual tests :)
<xnox> jibel: the AP tests should be pulled from lp:~ubuntu-installer/ubiquity/trusty-proposed instead of lp:~ubuntu-installer/ubiquity/trunk. Whilst they didn't diverge yet, they may do so in the future.
<xnox> jibel: well and kernel team are doing it at the moment as well =)
<jibel> xnox, yeah, thanks kernel team
<pitti> sil2100: bug 1346199 is sufficiently tested now, but just for safety I suppose we should keep that in -proposed until we get out of the traincon swamp for touch?
<ubottu> bug 1346199 in systemd (Ubuntu) "Needs testing in -proposed: systemd 208" [High,In progress] https://launchpad.net/bugs/1346199
<sil2100> pitti: hey, yeah I would first like us to move out all our 4.9 gcc-related transitions from -proposed
<pitti> sil2100: ack
<sil2100> Would be really grateful for that ;)
<pitti> sil2100: it's not that urgent; systemd as pid 1 is totally broken ATM, but as we don't support that, getting the touch image back to green/promotable certainly trumps that
<Riddell> pitti: can you see any problem with bug 1347565 and what's a good test case?
<ubottu> bug 1347565 in apport (Ubuntu Utopic) "apport recommends gdb" [Undecided,New] https://launchpad.net/bugs/1347565
<smb> jibel, I am a bit confused about http://iso.qa.ubuntu.com/qatracker/testcases/1312/info. Specifically I seem to miss the "no network" part of it.
<jibel> smb, the test case is wrong, step 5, 'is connected to the internet' must be greyed, the list of languages for trusty are en, es and zh. For other language there is a popup when the system is connected to a network.
<jibel> balloons, ^ could you fix this test case
<jibel> ?
<apw> xnox, hey when i select "Something Else" the next installer screen is taller, this tallerness persists from then on, making all of the windows go off the bottom on my test box
<xnox> apw: gtk+ enjoy it =)
 * ogra_ hands apw a few horizontal lines with pixels
<apw> ogra_, i need about 200 if you have them
<ogra_> just glue tzhem on at the bottom
<xnox> apw: you should be able to press super and drag the window up.
<ogra_> sure, np ...
<apw> xnox, oh yeah i can cause i know how, but ... its hard if you don't
<xnox> =)
<apw> xnox, you might want to look at bug: #1347630 and reassign it as you see fit
<ubottu> bug 1347630 in ubiquity (Ubuntu) ""You may want to read the release notes" link takes you to ubuntu home page" [Undecided,New] https://launchpad.net/bugs/1347630
<pitti> hey Riddell
<pitti> Riddell: looking
<jibel> apw, it's a redirect on server side. It'll have to be updated with the new version of the release.
<apw> jibel, ok what shall i assign that bug to
<apw> i assume there is a project for the website somewhere
<pitti> Riddell: ah, I think that should be fine; AFAIK, the full gdb has support for decoding python and other languages, but we don't need those for crash processing
<jibel> apw, ubuntu-website
<pitti> Riddell: I added a test case to the bug
<Riddell> thanks :)
<pitti> Riddell: did you happen to commit this to bzr locally and just need to push, or should I grab the diff from LP?
<Riddell> pitti: does it need updated in bzr, will UDD not do that magically?
<pitti> Riddell: it's not using UDD; I want to be this a proper branch of trunk, which UDD can't do
<pitti> (one of the main reasons why IMHO UDD is broken -- it falls down in the ideal case of having both upstream and packaging all in bzr..)
 * Riddell looks
<cjwatson> Yeah, UDD is most kindly described as "aspirational" I think
<pitti> Riddell: anyway, I'll just push it
<pitti> Riddell: erk, FTBFS due to twisted uninstallability in -proposed
<Riddell> wibble
<Riddell> trusty bzr is out of date anyway, tsk to bdmurray
<pitti> Riddell: pushed utoic
<pitti> Riddell: and utopic, too
<pitti> Riddell: ah, I'll import 2.14.1-0ubuntu3.2 too
<pitti> Riddell: trusty branch updated
<Riddell> thanks pitti
<pitti> cjwatson: ah, http://lists.alioth.debian.org/pipermail/pkg-grub-devel/2014-January/013883.html is indeed a nice summary
<cjwatson> It may not be worth your time trying to convert an existing package, but perhaps worth trying out on something new
<pitti> cjwatson: so indeed conceptually not that much different from http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/README.source
<pitti> cjwatson: but git-dpm dch looks quite nice, essentially implying the "export" step you need to do for -pq
<cjwatson> Yeah, as I say I think it's basically an implementation (IMO nicer but YMMV) of the same idea
<cjwatson> pitti: I find myself using commit --amend a lot with it
<cjwatson> and git-dpm update-patches --amend
<pitti> This is an enforced workflow change; you can't mix and match this
<pitti>    with manual developer use of quilt in a particularly sane way, and
<pitti>    you have to use git-dpm if you're touching patches in any way.
<pitti> oh, that would be a rather big downside
<pitti> I thought with -dpm the patch branch would also be transient, it's not then?
<cjwatson> Well, you can, it's just that git-dpm will probably want to rewrite stuff later
<pitti> ah
<pitti> yeah, there's always some noise in patch headers
<cjwatson> It's sort of transient; the tip of it is merged into master
<cjwatson> You don't keep a ref around for it, but its history remains
<cjwatson> I generally view this as a plus, but as I say YMMV
<cjwatson> I'm actually not sure what git-dpm does if you just drop in a quilt patch it's never heard of.  Generally speaking once I have something in git-dpm I don't want to use quilt
<cjwatson> It's git, I'm sure you have all the swiss army knives required to deal with it, just not sure how neat it is :)
<pitti> heh, yes
<xnox> cjwatson: how/where in launchpad can i get to image builds? which team/person/etc should I be looking for?
<pitti> cjwatson: my main concern was mostly about other people touching the packaging/quilt series as well, and converting everyone to a new tool in lockstep seemed a bit difficult
<cjwatson> xnox: They're all under ~ubuntu-cdimage, but the index is crap right now
<pitti> much easier for (essentially) single-maintainer packages, of course
<cjwatson> xnox: You can use the lp.livefses collection on the webservice
<cjwatson> and then .web_link
<xnox> cjwatson: ack. yeah, cuase https://launchpad.net/~ubuntu-cdimage doesn't show me any links to livefs builds et al.
<cjwatson> xnox: basically they're of the form /~ubuntu-cdimage/+livefs/ubuntu/SERIES/NAME, e.g. .../utopic/ubuntu-desktop
<cjwatson> Yeah, I've been meaning to write some kind of index but ENOTIME
<xnox> jibel: ^
<xnox> jibel: e.g. https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/trusty/lubuntu
<jibel> xnox, cjwatson ack, thanks
<smb> xnox, I think bug 1347676 might be somewhat bad.
<ubottu> bug 1347676 in ubiquity (Ubuntu) "Installer fails to find disk to install" [Undecided,New] https://launchpad.net/bugs/1347676
<cjwatson> Whoops, sorry, my example was buggy :-)  .../utopic/ubuntu
<xnox> well above lubuntu build url works =)
<cjwatson> xnox: Also, there's a link to the build in each of the CD build logs (http://people.canonical.com/~ubuntu-archive/cd-build-logs/
<cjwatson> )
<cjwatson> So you can always track it down from there
<cjwatson> e.g. top few lines of http://people.canonical.com/~ubuntu-archive/cd-build-logs/lubuntu/trusty/daily-live-20140722.2.log
<xnox> jibel: btrfs is seeded everywhere where it's needed. not sure what's going on. let me pull lubuntu iso.
<jibel> xnox, from the logs you see that it's a recommends but recommends are not installed
<jibel> xnox, https://launchpadlibrarian.net/180540741/buildlog_ubuntu_trusty_i386_lubuntu_UPLOADING.txt.gz
<xnox> jibel: hm, right.
<xnox> jibel: but in the equivalent utopic build, it's going to be installed.
<xnox> hm.
<jibel> xnox, and it's installed for ubuntu
<xnox> jibel: ubuntu installs recommends, but lubuntu does not.
<xnox> jibel: the seeds are the same
<xnox> jibel: thus lubuntu trusty and utopic should both be the same, however lubuntu/utopic has btrfs-tools yet lubuntu/trusty does not.
<bulletxt> hi, if I download from ubuntu packages the source of printer-driver-gutenprint , how can I build it with ubuntu specifics ? Like prefix and all the rest? Thanks a lot
<cjwatson> debuild -B -uc -us
<cjwatson> Sorry, -b not -B
<bulletxt> in which folder? in the extracted  [gutenprint_5.2.10~pre2-0ubuntu2.debian.tar.gz] file ?
<cjwatson> you should not extract that file manually
<cjwatson> dpkg-source -x gutenprint_5.2.10~pre2-0ubuntu2.dsc
<cjwatson> that will produce a gutenprint-5.2.10~pre2 directory; build in there
<bulletxt> ok let me try
<cjwatson> debuild will probably require you to install build-dependencies before it will proceed
<cjwatson> (there are of course approaches for automating that, but they're overkill if you're just trying to build one thing)
 * cjwatson -> out
<bulletxt> ok cjwatson I did dpkg-source -x gutenprint_5.2.10~pre2-0ubuntu2.dsc
<bulletxt> it created a folder gutenprint-5.2.10~pre2
<bulletxt> should I just get in there and do make; make install ?
<roadmr> bulletxt: no, see what cjwatson said, was to debuild -b -uc -us
<bulletxt> ok roadmr I got into the new created folder and did debuild -b -uc -us
<bulletxt> but it gave some errors
<roadmr> which errors? something about unmet build dependencies I imagine?
<bulletxt> yea I'll paste the whole thing
<bulletxt> roadmr: http://paste.ubuntu.com/7842095/
<roadmr> bulletxt: ok! but to get you started faster, you need to install all the packages listed in "Unmet build dependencies"
<roadmr> bulletxt: just apt-get install all those packages, then try again
<bulletxt> yea but please give a look at the paste
<bulletxt> I'm not sure that's the problem
<bulletxt> mm
<bulletxt> maybe yea
<roadmr> bulletxt: give it a try :) you can't build without the deps :P
<bulletxt> ok cool I installed debuild -b -uc -us
<bulletxt> I mean, the missing dev packages
<bulletxt> now its going ahead
<bulletxt> :D
<roadmr> bulletxt: cool! ok, so it'll spit out one or more .deb at the end
<bulletxt> so, lets say I want to apply my personal patch to gutenprint, should I first apply the patch and then do  debuild -b -uc -us   ??
<roadmr> bulletxt: correct, apply your patch on that directory where you're building. You'll notice it contains all of gutenprint source
<bulletxt> yea, ok so first I apply my patch then i do the debuild command
<roadmr> bulletxt: right
<bulletxt> but, do I have to be root when doing debuild  ??
<roadmr> bulletxt: no
<bulletxt> ok
<roadmr> bulletxt: debuild uses some tricks to avoid needing root while building
<bulletxt> ok cool
<bulletxt> its spitting out a lot of debs on my desktop, lol
<roadmr> :D
<bulletxt> roadmr: do you by chance know how to correctly apply a  patch.diff file into the source ?
<roadmr> bulletxt: hm usually patch -p0 < patch.diff (do this while in the gutenprint directory)
<bulletxt> a simple patch < file.diff should be enough I supose
<bulletxt> ok
<bulletxt> roadmr:  It returned this:  (Stripping trailing CRs from patch; use --binary to disable.) patching file src/main/print-olympus.c (Stripping trailing CRs from patch; use --binary to disable.) patching file src/xml/papers.xml
<roadmr> bulletxt: patch would complain loudly if there was a problem, so it looks OK to me, just a warning
<bulletxt> ok
<bulletxt> then its time to redo the debuild and then install the debs :D  hopefully I won't destroy my system :)
<roadmr> bulletxt: looks like your changes are relatively harmless, good luck!
<arges> have you guys seen this apt error before, it seems to have been happening recently : http://pastebin.ubuntu.com/7842304/
<xnox> arges: yes. ddebs are very racy at updating their dists/
<xnox> arges: the reply is prodstack4 or shipping strong booze to germany somewhere where pitti is or something like that =)
<arges> xnox: fun fun fun
<pitti> I tried to do a first attempt of updating dists/ atomically, but it's 'orribly complicated
<bulletxt> roadmr: great everything went fine. Thanks a lot (also cjwatson!)
<jodh> xnox, hallyn: Just a reminder that https://code.launchpad.net/~jamesodhunt/ubuntu/utopic/cgmanager/enable-upstart-cgroup-support/+merge/227209 is still o/s. We really need this enabled such that if we hit problems, we have sufficient time to resolve before RTM :)
<xnox> jodh: we are not landing it right now, not until gcc-4.9 is resolved on the phone and we promoted an image and/or some such.
<roadmr> bulletxt: I just helped with some minor syntax. Glad it worked!
 * xnox goes to check status of 4.9
<jodh> xnox: ok - thanks for the update.
<xnox> so on http://people.canonical.com/~platform/citrain_dashboard// silo 008 needs to publish and an image build done.
<xnox> not sure if there is a bug number to be notified.
<hallyn> jodh:  what is o/s ?
<xnox> slangasek: is there a tracking bug for gcc-4.9 explicit somewhere? packages in silo 008 close no bugs....
<xnox> hallyn: i've extrapolated from Oxford dictionary as "outstanding"
<jodh> xnox: you win a prize! And you prize is... to handle my MP :)
<hallyn> xnox: that was my guess, but i was wondering if there was a more technical term it coudl e short for :)
<hallyn> jodh: so, when I bzr branch lp:upstart, what's the recommended way to bootstrap to a point where I can build?  I tried the usual sorts of steps but didn't get the right series of steps apparently
<xnox> hallyn: apt-get build-dep upstart; autoreconf --force --install; ./configure; make -j12; make check -j12
<xnox> hallyn: if that's not "usual sorts of steps" you did, please update the "usual sorts of steps" to above =)
<xnox> hallyn: and let us know, if above does not work for any reason.
<hallyn> xnox: ok, autoreconf.  i was doing 'aclocal;libtoolize;autoheader;autoconf;automake' type of steps
<hallyn> thanks :)
<xnox> hallyn: from that expanded list autopoint vs gettexize is the missing piece i think.
 * hallyn looks up autopoint
 * hallyn respectfully suggests to jodh that a 'bootstrap.sh' might be worthwhile :)
<jodh> hallyn: http://upstart.ubuntu.com/cookbook/#setting-up-an-upstart-development-environment, http://upstart.ubuntu.com/cookbook/#unit-tests. I generally just 'autoreconf -fi && ./configure ...'
<hallyn> or just a note in README
<tkamppeter> Anyone with knowledge about SLP (Service Location Protocol) around?
<xnox> hallyn: "autoreconf -fi" is the golden standard these days. to the point that most of "bootstrap" scripts like autogen.sh et.al. just call "autoreconf -fi" these days.
<xnox> hallyn: why do you not use autoreconf?
<hallyn> i dunno, cause i didn't know how it fit in with the other magic incantations
<hallyn> certainly seems nicer
<hallyn> i think i (without thinking about it) assumed autoreconf was a debbuilder thing.  i used it in package building, but not by hand
<xnox> hallyn: it's the top-class command to rule them all part of autotools. it inteligently inspects and tries to run all the tools, as many times as needed, in the right order.
<hallyn> xnox: unicorns
<pitti> slangasek: ah, thanks for the updates wrt. armhf
<pitti> slangasek: so this exercise of summarizing was useful, glad to hear that it's not quite as bad as I feared
<hallyn> jodh: all right, i can finally reproduce the make check failure in lp:upstart :)  will aim to mp a fix later today
<jodh> hallyn: thanks!
<slangasek> xnox: the tracking bug was bug #1329089
<ubottu> bug 1329089 in dbus-cpp (Ubuntu) "g++-4.9 binary incompatibilities with libraries built with g++-4.8" [Critical,In progress] https://launchpad.net/bugs/1329089
<xnox> slangasek: ah ok. and none of the merge proposals mention this bug, because unicorns?! =) ok, gotcha.
 * slangasek shrugs :)
<xnox> at times i honestly believe setuptools is worse than autotools. Whilst both can drive one crazy, the latter at least generates piles of logs and error messages.
<mlankhorst> we shoud all use the android build tools ;-)
<hallyn> jodh: tbh the cgmanager tests in upstart don't seem u seful
<hallyn> they seem like they woudl test libcgmangaer, not upstart
<hallyn> so it's fine to do setup_cgroup_sandbox() before running tests, and skip the tests if setup_cgroup_sandbox fails.
<hallyn> but right now it just tries setup-cgroup_sandbox and fails is that fails.  That's wrong.
<hallyn> now the init/tests/test_cgroup.c looks good.
<hallyn> though it doesn't test any actual cgroup actions i guess
<hallyn> ok purely my fault for misunderstanding that file in january?  ok i think i know what to do :)  thx for listening :)
<hallyn> there, that's better
<jodh> hallyn: those tests are meta-tests so not actually for testing upstart, just the env its tests run in to ensure it is 'sane'. thanks for MP!
#ubuntu-devel 2014-07-24
<msx> hi all, sorry to bother here but I'm unable to find the answer anywhere else: i'm looking for a clean way to close the session (logout) from the command line. gnome-session-quit wont work, nor the dbus method shown here: http://askubuntu.com/questions/15795/how-can-you-log-out-via-the-terminal. Also, I don't want to just 'sudo reboot' but a nicier, more polite method so all running application can
<msx> safely end it's ongoing stuff and then end. Any idea?
<dobey> msx: most applications can't/don't use proper session management, and if they did, they should handle SIGTERM correctly anyway. so i'd say "sudo reboot" is about as "nice" as it's going to get realistically
<hallyn> hm, neither the precise nor trusty server cd isos are installable right now;  stops at kernel modules not being compatible
<msx> dobey: hey! well, i noted that quiting a session when using Unity web brosers will close cleanly while using any other method they will offer to recover. If i'm not mistaken I think Unity someway passes a SIGHUP signal while powering off or restarting X just sends a SIGTERM signal, hence the difference
<msx> sarnold told me about d-feet, a dbus browser so i'm looking into this path right now...
<dobey> i don't know what the browsers do exactly. i don't think they get a SIGHUP though
<msx> dobey: hmm, okay, i'm fairly new to the way how GUI apps interact with the system, will look upon that, thanks!
<robert_ancell> cjwatson, who maintains ubiquity now?
<pitti> Good morning
<ion> that
<dholbach> good morning
<mvo_> hey dholbach
<dholbach> hi mvo_
<cjwatson> robert_ancell: well, it's been somewhere between xnox and me for a while, mostly xnox - I guess "foundations" is the answer
<robert_ancell> cjwatson, there was a proposal to update metacity to 3.12 - that's used in ubiquity right?
<robert_ancell> What's the best way to check 3.12 is good to go in?
<cjwatson> robert_ancell: ubiquity just uses it as a simple wm; about all it does is set org.gnome.metacity.compositing-manager to true, run metacity --sm-disable, and then expect it to manage windows
<cjwatson> robert_ancell: if it works as a window manager with compositing switched on then I'd say we're fine
<robert_ancell> cjwatson, oh good - org.gnome.metacity.compositing-manager defaults to true now. That was the main point I wanted to check
<cjwatson> robert_ancell: yup, should be fine
<robert_ancell> cjwatson, ta
<jibel> mvo_, hey, could you have a look at bug 1348067 ? this is an upgrade from precise to trusty
<ubottu> bug 1348067 in update-manager (Ubuntu) "update-manager crashed with TypeError: pulse() takes exactly 1 argument (2 given)" [Medium,New] https://launchpad.net/bugs/1348067
<mvo_> jibel: is this new?
<mvo_> jibel: sure, I have a look
<jibel> mvo_, it seems to be relatively new. I found only 1 bug report, reported yesterday and I reproduced it this morning
<mvo_> jibel: thanks, and it happens when the user clicks on the "upgrade" button in the main ui?
<jibel> mvo_, it happens when the user clicks 'upgrade' on the release announcement dialog
<mvo_> jibel: thanks, I'm upgrading my precise vm just now and investigate!
<jibel> argh and then ubuntu-desktop fails to upgrade :/
<cjwatson> sarnold: Sorry to nag, but librevenge?  I really want to stop proposed-migration taking 25 minutes per run due to thinking really hard about libav every time :)
<mvo_> jibel: its confusing, neither python-apt nor apt has changed in this area recently :/
<xnox> cjwatson: well, we can't use metacity 3.12, until unity7 is ported to gtk3 & metacity 3.12. Or is robert implieying that was done now?
 * xnox checks
<ev> cjwatson: oh hi. Rumour has it that you got jemjem to work with the x86 emulator. I can't seem to find a branch on LP with this, though.
<cjwatson> ev: err that was ages ago and almost certainly stale
<ev> boo hiss
<cjwatson> ev: I thought it had been superseded by xnox's branches
<cjwatson> pretty sure I pushed something somewhere but let me check
<xnox> =)
<xnox> ok.
<cjwatson> ev: I was basically using lp:~xnox/ubuntu-test-cases/touch-emulator plus https://code.launchpad.net/~cjwatson/ubuntu-test-cases/python3 I believe
<cjwatson> ev: After I did that I heard that that had been superseded by some similar branches somewhere else, but I never rebased
<ev> ah, so has jemjem changed along the way? It started out as a juju charm, but this is decidedly not.
<ev> background> I'm trying to see what the state of nested kvm is as it relates to the touch emulator running on openstack. I appear to be missing a few gl packages in the server cloud image, and it's not obvious what remains after manually installing a lot of mesa.
<cjwatson> I'm not sure I ever used jemjem as such
<cjwatson> Just some of the code that went into it
<cjwatson> At the time I was experimenting with getting autopkgtest working on top, but I don't think I used anything jujuish
<cjwatson> However I don't think this necessarily says anything about the state of jemjem in general
<ev> yeah
<rbasak> I'm looking at Juju upstream's QA process and how it fits around SRUs and trying to figure out a decent QA process to land major version changes to Trusty for Juju in a way that makes sense for Ubuntu.
<rbasak> One thing I'd like to do is have upstream's QA test trusty-proposed packages. But ideally, this would happen before the package actually hits trusty-proposed.
<rbasak> Would it be possible to prepare a build in a PPA, have upstream QA the binaries from the PPA, and then land the binaries in the trusty-proposed unapproved queue as normal?
<rbasak> The reason is that I'd like to be testing the same binaries that match upstream's binary distribution that's done outside-of-archive (for cross-distro and cloud provider purposes)
<xnox> rbasak: that's what silos are...
<xnox> rbasak: non-virt ppas, building with -proposed enabled, and later src+bin are copied and published into the archive, after they have been validated.
<xnox> rbasak: talk to sil2100 / robru about it.
<rbasak> xnox: thanks. But maybe I need someone on the release team to arrange something like this for Juju?
<xnox> rbasak: not release team, but landing team sil2100/robru. We have landed SRUs like that already, e.g. unity7
<rbasak> The specific reason here is that when Juju upstream "releases", binaries become available to external sources (eg. uploaded to cloud providers).
<rbasak> I'd like to integrate Ubuntu's QA (ie. -proposed for SRUs and 7-day aging period etc), so that an Ubuntu QA issue actually holds back the upstream release.
<xnox> rbasak: still not sure what release team got to do with it. release team deals with ubuntu milestones only. landing team can give you ppas and facilitate in staged upload for sru.
<rbasak> I wasn't aware of the landing team.
<xnox> rbasak: checkout #ubuntu-ci-eng
<xnox> rbasak: ... everything that is SRUed must be in devel release already, which most of the time also means released....
<rbasak> Hmm, good point.
<rbasak> I suppose this would only be for the development release then.
<rbasak> I hadn't considered that this could well have the same needs as the desktop side and is already being done - thanks!
<cjwatson> If it's not a matter of just merging branches, you might be better off with an ordinary devirtualised PPA rather than bothering with CI Train, though.
<cjwatson> (If you already have a suitable PPA.)
<rbasak> I'm not familiar with the CI Train and what its requirements would be. There's already a fairly complex process for upstream to generate a release tarball because golang.
<rbasak> They have a Jenkins job do everything, so it's outside VCS at that point.
<rbasak> Maybe an ordinary devirt PPA would be better, then?
<rbasak> How do I go about going through the details and arranging this?
<cjwatson> I would just use a separate devirt PPA if I were you.  xnox is right that CI Train deals with some of this, but if you can't use its auto-merging stuff then all it gives you is a devirt PPA with some extra annoyance around getting it assigned, and they have a limited pool right now
<cjwatson> Create a PPA, ask webops, solemnly swear that only Canonical people will be allowed to upload to it
<cjwatson> Remember to get the right set of architectures enabled
<rbasak> OK, thanks. How is the copy to devel-proposed organised?
<cjwatson> If you can upload to a suite, you can also copy to it
<cjwatson> copy-package in lp:ubuntu-archive-tools with the -b option
<rbasak> Great - thank you!
<rbasak> I wonder. I can ensure that the devel release always gets it first. But since upstream's goal is to land in the previous LTS via an SRU, they test against that before release, and so I'd like to land it to stable-proposed nearly simultaneously.
<rbasak> So would I be able to do the same to trusty-proposed, QAing both at once?
<rbasak> I guess I'll need to copy with binaries from the devirt PPA to trusty-proposed. Will that work, and just end up in the unapproved queue as normal?
<xnox> rbasak: you do need to make sure you build them clean, e.g. that ppa must have -proposed, -security, -updates pockets enabled, and there are no other non-archive dependencies in it, nor packages not from the archive (unless they are landing into the archive at the same time)
<rbasak> xnox: ack
<mdeslaur> rbasak: Hi! Think you could merge apache2 2.4.10 soon to fix the security issues?
<rbasak> mdeslaur: sure. Looks fairly trivial.
<mdeslaur> rbasak: cool, thanks
<intgr> pitti: Hey. Sorry to highlight you, but is there an ETA for PostgreSQL 9.3.5 in trusty repos?
<pitti> intgr: I'll prepare the updates ASAP, but it's not a critical update, and I'm a bit swamped, so probably not before start of next week
<intgr> Ah ok, thanks.
<pitti> intgr: you can subscribe to bug 1348176 to track the status if you want
<ubottu> bug 1348176 in postgresql-9.3 (Ubuntu Utopic) "New upstream microreleases 9.3.5, 9.1.14, 8.4.22" [Undecided,New] https://launchpad.net/bugs/1348176
<kentb> Hi...Can anyone help with sponsoring a few package upgrade bugs I've opened for 14.10?  There are 4 in all and I can provide bug numbers. Thanks in advance.
<intgr> pitti: Cool
<xnox> kentb: generally, just list the bugs straight away. As people who might be interested in those bugs (and get highlighted by e.g. package name) may not poke you to ask for numbers =)
<kentb> xnox, ok. will do that now...I was worried about spamming the channel :)
<kentb> https://launchpad.net/bugs/1335907
<kentb> https://launchpad.net/bugs/1335941
<kentb> https://launchpad.net/bugs/1335947
<kentb> https://bugs.launchpad.net/ubuntu/+source/openwsman/+bug/1334832
<ubottu> Ubuntu bug 1335907 in sblim-sfcb (Ubuntu) "Update to version 1.4.8 sblim-sfcc for Utopic" [Undecided,New]
<xnox> kentb: phhh =) ubottu is except from spam protections =)
<ubottu> Ubuntu bug 1335941 in sblim-sfcc (Ubuntu) "Update to sblim-sfcc 2.2.7 for Utopic" [Undecided,New]
<ubottu> Ubuntu bug 1335947 in cim-schema (Ubuntu) "Upgrade cim-schema to 2.41.0 for Utopic" [Wishlist,Triaged]
<ubottu> Ubuntu bug 1334832 in openwsman (Ubuntu) "Update to upstream 2.4.7 for Utopic" [Undecided,New]
<xnox> kentb: would you want me to review and sponsor that into.... Debian?
<kentb> xnox, I do have ITP bugs in Debian opened for those as well if you're inclined
<kentb> xnox, but there are a few more in Debian as well, since the build-deps for those packages don't exist in Debian yet, either
<xnox> kentb: if you use appropriate version number, and dput into mentors.debian.org i'd sponsor into debian from there.
<kentb> xnox, I've got 'em in mentors...let me hunt them down for you
<xnox> kentb: and at the same time upload into utopic. Such that once it clears in debian we can sync them across.
<xnox> kentb: and/or start with build-deps first indeed =)
<kentb> ok.
<kentb> xnox, build deps for debian:  https://mentors.debian.net/package/sblim-sfc-common
<kentb> and
<kentb> https://mentors.debian.net/package/sblim-cmpi-devel
<kentb> xnox, and the rest:
<kentb> https://mentors.debian.net/package/sblim-sfcc
<kentb> https://mentors.debian.net/package/sblim-sfcb
<kentb> https://mentors.debian.net/package/openwsman
<kentb> https://mentors.debian.net/package/wsmancli
<kentb> https://mentors.debian.net/package/cim-schema
<kentb> xnox, wsmancli does not need to be synced to 14.10 as I got that one upgraded already
<kentb> we also already have sblim-cmpi-devel and sblim-sfc-common in Ubuntu and there's no new upstream release to upgrade to as of today
<xnox> kentb: well, debian version number will be higher (e.c. -1 >> -0ubuntuX) and it would be syncable over.
<xnox> with zero net difference =)
<kentb> oh ok cool
<hallyn> jodh: xnox: why is notify-cgmanager.conf needed in user upstart session?
<hallyn> jodh: I'll stick your change to the upstart files in git;  but does this mean that the new job should also go into git under config/init somewhere?  I wonder how best to structure that
<hallyn> jodh: also, do you know whether nih-dbus-tool places any restrictions on the files it generates?  Or do they fall under whatever license the source files were under?
<xnox> hallyn: no restriction.
<hallyn> thx
<xnox> hallyn: notify-cgmanager.conf is needed to be installed into /usr/share/upstart/sessions/ such that one can have cgroups support in user-session jobs =)
<xnox> hallyn: i don't know how to best integrate it upstream. Imho, in user-session mode it should just assume that cgroups support is available, but i lost that argument with jodh, hence the notify call to the user-session upstart as well.
<hallyn> well, what's there doesn't guarantee that anythign is available :)
<hallyn> except for the upstart job that claims they are
<hallyn> (if notify-cgmanager.conf first did a 'cgm ping' that would be more reliable)
<xnox> hallyn: but "cgm" is a lot of dependencies which we don't have on the phone.
<xnox> hallyn: for ubuntu it's fine =) cause the same package ships both jobs ;-) hence one would have one available.
<hallyn> xnox: right but cgmanager/proxy couldve failed to start.  if that's not relevant, then ok
<hallyn> yeah i really need to write a non-script version of cgm
<xnox> hallyn: yeah irrelevant. notify only allows attempting to start cgroups stanza jobs, if that fails or blocks, those jobs will simply fail.
<hallyn> ok
<hallyn> oh, goodie, the other changes are already in git :)
 * xnox didn't have lunch yet. let me pop out to get some.
<hallyn> the user session one should probably at least go into the debian pkg
<hallyn> \o
<hallyn> thx for the info
<mvo_> jibel: initify mentioned that there is a upgrade bug in saucy->trusty right now. do you have have advice how to reproduce? or can I just use a server install and try
<infinity> mvo_: Intentional attempt to avoid nick highlighting me, or dyslexic fingers? :)
<mvo_> infinity: too much stuff at once
<jibel> mvo_, this is https://jenkins.qa.ubuntu.com/view/Upgrade/job/upgrade-ubuntu-saucy-trusty-desktop-amd64/140/
<jibel> mvo_, install saucy + ubuntu-desktop^ and upgrade
<mvo_> jibel: thanks!
<jibel> mvo_, see also bug 1347721 with ubuntu-gnome. It contains a clone
<ubottu> bug 1347721 in ubuntu-release-upgrader (Ubuntu) "Ubuntu GNOME Saucy -> Trusty upgrade displays failure warning" [Undecided,New] https://launchpad.net/bugs/1347721
<mvo_> thanks jibel
<mvo_> jibel: is there a indiciation in the automatic testing system when it started to happen?
<jibel> mvo_, June 25th
<mvo_> jibel: hm, thats a long time, thanks
<infinity> jibel: Wow, we lasted a whole two months after release before something changed enough to resurface the bug?
<dholbach> slangasek, sent the UOS update to u-d-a
<slangasek> dholbach: the original mail never went through to u-d-a, correct?  I wonder if it would be better to have a mail subject with the correct dates, rather than one that's Re: wrong dates :)
<dholbach> hum hum
<dholbach> it already went through on community-announce@ and ubuntu-news-team@
<dholbach> but I agree - that would have been a good idea
<slangasek> dholbach: do you want me to accept it as-is, or do you prefer to resend with a different subject?
<dholbach> slangasek, ok... let me re-send to u-d-a with a fixed subject
<slangasek> ok; rejecting the current one
<dholbach> slangasek, thanks, new mail sent
<mvo_> jibel: can not repdocue with the clone :(
<mvo_> jibel: more tomorrow
<slangasek> pitti: do you have any idea why address-book-service-dbgsym is missing?  source+binary in universe, .ddeb shows in the log: https://launchpadlibrarian.net/180026273/buildlog_ubuntu-utopic-armhf.address-book-service_0.1.1%2B14.10.20140715-0ubuntu1_UPLOADING.txt.gz
<slangasek> pitti: so it doesn't seem to obviously be caused by any of the known bugs
<_nedR> darkxst, I see you are one of maintainers of gnome-control-center.. just wondering if i were to compile from  lp:ubuntu/utopic-proposed/gnome-control-center and run it in 13.10 would it blow up in my face?
<rww> 13.10's end of life, so running it in general is likely to blow up in your face.
<_nedR> rww.. it is only about 8 months old,... I am just wondering can i run the current version (without applying changes) would it mess up... Does it need 14.04 to develop and run or 14.10 ?
<rww> !13.10
<ubottu> Ubuntu 13.10 (Saucy Salamander) was the 19th release of Ubuntu. Support ended on July 17th, 2014. See !eol, !upgrade and http://ubottu.com/y/saucy
<sarnold> neat
<_nedR>  rww.. I am wondering would developing  and running a utopic version  of gnome-control-center need ubuntu-utopic or is ubuntu-trusty as development machine?
<slangasek> xnox: can you give me a hint about the right way to make autopilot-qt's build use proper flags for building, like -g?  (qmake-based)
<kees> hallyn: ooh, nice catch on the PR_SET_MM refactor's use of RLIMIT_DATA!
<hallyn> i had to look at taht 3 times, was sure i was being silly :)
<thomi> slangasek:curious - why are you building ap-qt?
<slangasek> thomi: because the package fails to properly build with debugging symbols enabled currently, as required by policy
<thomi> slangasek: ahhh. I can do that for you today, if you like.
<thomi> slangasek: as I'm working in there currently
<thomi> slangasek: when should it be built with debugging symbols, and is '-g' all that's required?
<slangasek> thomi: right - please make sure the settings from dpkg-buildflags are applied during the build :)
<slangasek> thomi: you should just use the dpkg-buildflags abstraction, which will build with the right flags (there's more than just -g - it should also be setting a variety of hardening flags)
<thomi> ahhh, I never knew about that before
<slangasek> thomi: these aren't urgent wrt autopilot-qt, which is hopefully not being run in production on phones :), but as I'm currently auditing the state of debug symbols it cam eup
<thomi> slangasek: yeah. interesting - what's the difference between CPPFLAGS and CXXFLAGS?
<slangasek> thomi: CPP is c preprocessor; cxx is c++
<thomi> slangasek: I'll patch ap-qt, but FYI this seems to be the general recipe: https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1020275.html
<thomi> or at least shows how several other packages seem to do it
<slangasek> thomi: right; you could probably do that with a little less duplication of subshells by just calling dpkg-buildflags once for each variable and stashing in a make variable, but ok
<thomi> true
<highvoltage> t/win 24
<slangasek> pitti, ev: does apport-retrace have any smarts for dealing with -dbg packages built from the source package, vs. ddebs?
<dobey>  binutils : Conflicts: binutils:armhf but 2.24.51.20140709-1ubuntu1 is to be installed
<dobey>  binutils:armhf : Conflicts: binutils but 2.24.51.20140709-1ubuntu1 is to be installed
<dobey> whee
<dobey> slangasek: ^^ any idea how to get around that? :)
<dobey> slangasek: it's breaking cross-compile of something that requires g++-4.9 :-/
<dobey> slangasek: nevermind, i guess to cross-compile the dep needs to have :native
<slangasek> dobey: there is no general solution for cross-compiling things that build-dep on specific toolchain packages, at the moment; effectively the current answer is "ignore the build-deps"
<slangasek> (g++-4.9:native doesn't satisfy the build-dependency when cross-building)
<dobey> it seems to. i'm not getting the build dependency complaint any more
<michagogo> slangasek: how far down in your queue is my email re: bug 1314616?
<ubottu> bug 1314616 in bitcoin (Ubuntu) "[SRU] bitcoin to be maintained upstream in PPA: Replace distro archive "bitcoin" bitcoin with an empty dummy package" [Undecided,Confirmed] https://launchpad.net/bugs/1314616
<michagogo> (the email in question is https://lists.ubuntu.com/archives/ubuntu-devel/2014-July/038389.html from July 2)
<sarnold> Trevinho: another one.. https://bugs.launchpad.net/ubuntu/+source/unity-greeter/+bug/1348353
<ubottu> Ubuntu bug 1348353 in unity-greeter (Ubuntu) "Lock screen password field doesn't intercept key pressings from keyboard" [Undecided,New]
<catbus1> this may not be the right place to ask this question: is 14.04.1 out yet?
<sarnold> catbus1: not yet, i'll be annotated here when it is: https://wiki.ubuntu.com/Releases
<catbus1> sarnold: ok, thank you!
<hallyn> slangasek: so i'd want to test it for a bit (and track down weird libnih-induced bug), but there's now a compiled 'cgm' program;  how much is the debian ftp team gonna hate me if i say we don't need the cgmanager-utils package any more?
#ubuntu-devel 2014-07-25
<chrstphrchvz> Main question: does the size of /boot/grub vary by installation or over time, making it undesirable for separate partition? see description: http://ur1.ca/htmwi
<sarnold> chrstphrchvz: my /boot/grub is currently 8M. I just cleaned up a dozen kernels just yesterday, pity :/
<chrstphrchvz> sarnold, I'm almost certain kernels are in /boot, not /boot/grubâ¦
<sarnold> chrstphrchvz: yes, I just don't know (and hanve't looked) to see if there's any per-kernel data in the /boot/grub that might have grown / shrunk over time..
<Unit193> pitti: Howdy.  Since systemd is on the agenda for utopic, is Dracut as well?  (LP: #1109029, LP: #1266516)
<ubottu> Launchpad bug 1109029 in linux (Ubuntu) "Depend on linux-initramfs-tools" [Wishlist,Triaged] https://launchpad.net/bugs/1109029
<ubottu> Launchpad bug 1266516 in console-setup (Ubuntu) "New version available upstream: 1.104" [Wishlist,Confirmed] https://launchpad.net/bugs/1266516
<pitti> Good morning
<Unit193> Got you first. ;)
<pitti> slangasek: -dbg> yes, it does; in fact, if there is a -dbg it prefers that over a -dbgsym as they are sometimes built with extra options and are more reliably present
<pitti> address-book-service       | 0.1.1+14.10.20140715-0ubuntu2 | utopic/universe | source, amd64, arm64, armhf, i386, powerpc, ppc64el
<pitti> slangasek: ^ I do see those in http://ddebs.ubuntu.com/pool/universe/a/address-book-service/
<pitti> slangasek: where do you see it missing?
<pitti> Unit193: dracut hasn't been discussed so far
<Unit193> Pity, would be nice as an option.
<pitti> Unit193: TBH that would sound a bit like busy-work, and lots of it; initramfs-tools works well, and probably a few dozen packages integrate with it, so it would be quite a transition
<pitti> Unit193: I'd rather invest some work to boot without any initramfs at all
<pitti> pretty much the only thing necessary for that (for standard installs) is to teach the kernel to read UUIDs for ext file systems
<Unit193> pitti: For the basics, you'd need the alt depend and console-setup updated, but yeah, that's understandable too.
<mbiebl> pitti: one interesting bit is, that dracut supports systemd natively
<Unit193> (FWIW, I've tried dracut in Ubuntu and Debian.)
<pitti> I still don't quite share the obsession of always having an initramfs; unless you are using LVM or cryptsetup, they should be quite unnecessary
<mbiebl> pitti: it's kinda cool having the journal log from even within the journal
<pitti> i. e. it's just wasted boot time on all cloud installs and most desktop installs
<pitti> many server installs certainly use LVM etc., but I also know a lot which don't
<mbiebl> pitti: oh sure, I agree. initramfs-less boots are interesting
<pitti> it's a bit sad that UUID reading in the kernel got dropped on the floor; it was tossed around as an idea once
<pitti> ATM you have to go back to root=/dev/sda2 etc., which would be sad/wrong
<pitti> mbiebl: oh and BTW: I'm glad that I'm not the only crazy person who starts working before 6 AM :)
 * pitti ^5s mbiebl
<mbiebl> pitti: heh
<mbiebl> I remember hhoyer posting some numbers
<mbiebl> that an initramfs didn't actually slow down boot
<mbiebl> on the contrary
<pitti> infinity, ScottK: I'd appreciate a review/accepting the new postgresql microrelease SRUs (lucid/precise/trusty), if you have some time
<pitti> slightly bigger debian/ diff this time as we had to drop some patches which are now obsolete/included upstream
<pitti> but they only apply to running the tests during build time, and that's proven to work by, well, the packages building :)
<slangasek> michagogo: how far down my queue> um not sure at this point <sigh>
<slangasek> hallyn: cgm> I don't think the ftp team will hate you for doing the thing they asked you to do ;)
<slangasek> pitti: address-book-service - well, 0.1.1+14.10.20140715-0ubuntu2 is the version I just uploaded, so...
<pitti> slangasek: oh, you mean 0ubuntu1 wasn't there?
<slangasek> pitti: it wasn't in the index, at least
<pitti> slangasek: well, this was only one in a range of things which could go wrong
<pitti> slangasek: sometimes the buildds are down for maintenance, or the apaches are hanging, or apt-ftparchive ran too long, etc.
 * slangasek nods
<pitti> slangasek: this should be better now as I fetch the ddebs from the previous day 4 times now instead of 1
<pitti> perhaps I shuold also add a "day-before-yesterday" to re-fetch those too
<pitti> slangasek: this wasn't an indexing problem btw, the actual .ddebs are/were missing
<slangasek> pitti: right, I couldn't see any reason index-wise that those particular ones would be missing
<Whoopie> Hi, where can I open a ticket against the partner repository? I'd like to ask for a skype update as version 4.3 was released.
<Unit193> lp 1280109
<ubottu> Launchpad bug 1280109 in skype (Ubuntu) "Upgrade to Skype for Linux version 4.3.0.37" [Wishlist,Triaged] https://launchpad.net/bugs/1280109
<Whoopie> Unit193: thanks
<sarnold> cjwatson: finally finished :) enjoy
<dholbach> good morning
<dholbach> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: dholbach
<Tribaal> hi all. I'm seeking sponsorship for an update to a particular ubuntu package (I'm the upstream maintainer). Does my work appearing on http://reqorts.qa.ubuntu.com/reports/sponsoring/index.html means I should just wait?
<Tribaal> (it's in universe)
<dholbach> Tribaal, yes - which one is it
<Tribaal> dholbach: https://code.launchpad.net/~tribaal/ubuntu/utopic/ubumirror/1341523-upstream-release/+merge/226654
<dholbach> thanks Tribaal
<Tribaal> dholbach: welcome :) There's no real hurry - but I was worried the procedure I followed is correct :)
<dholbach> Tribaal, no, looks like you did everyting all right :)
<Tribaal> dholbach: cool :)
<dholbach> Tribaal, would you mind if I change the version number to 0.4 instead of 0.4ubuntu1?
<Tribaal> dholbach: oh not at all. I thought the ubuntu1 thing was required
<Tribaal> dholbach: what's the rule?
<dholbach> Tribaal, adding "ubuntu<N>" to the version number usually indicates "we imported this version from Debian, and added Ubuntu-local changes"
<dholbach> as the package is not in Debian, 0.4 sould be fine
<Tribaal> dholbach: ahhh ok
<Tribaal> dholbach: yeah then by all means :)
<dholbach> rock and roll :)
<dholbach> Tribaal, uploaded
<Tribaal> dholbach: woot )
<Tribaal> dholbach: thanks!
<dholbach> anytime
<Tribaal> dholbach: my first changes to ubuntu, believe it or not :)
<Tribaal> (ubuntu itself)
<dholbach> champagne! :)
<Tribaal> indeed :)
<Noskcaj_> Has something happened to the arm64 and ppc builders? two different packages have chroot problems for me currently
<dholbach> Noskcaj_, does it look something like https://launchpadlibrarian.net/180706189/buildlog_ubuntu-utopic-i386.ubumirror_0.4_CHROOTWAIT.txt.gz?
<Noskcaj_> it's a plymouth issue
<Noskcaj_> (on ppc)
<Noskcaj_> that's the issue on arm64
<dholbach> xnox, do you know if anyone is working on the gnustep-base ftbfs?
<dholbach> hey tumbleweed - long time no speak... how are you doing? do you think at some stage we could do another ubuntu-dev-tools upload? :)
<tumbleweed> dholbach: hi. yeah, I've kind of fallen off the planet :/
<tumbleweed> this would be doable
<dholbach> tumbleweed, how was your time off the planet? :)
 * dholbach hugs tumbleweed
<tumbleweed> :)
<tumbleweed> rather busy. that work-life balance thing is hard
<dholbach> tumbleweed, do you have plans to make it a little less work in the next time? :)
<tumbleweed> yeah. I'm planning to move to the US for a bit, which should through my life into enough disarray that I can reorganise it
<dholbach> man, I cross my fingers for you! all the best! :)
<tumbleweed> thanks
<dholbach> zul, can you take a look at bug 1328693?
<ubottu> bug 1328693 in fcoe-utils (Ubuntu) "Sync fcoe-utils 1.0.29+git0.09caead4-2 (universe) from Debian unstable (main)" [Wishlist,Incomplete] https://launchpad.net/bugs/1328693
<xnox> mvo_: infinity: cjwatson: https://launchpad.net/ubuntu/+source/openwsman/2.4.7-0ubuntu2 not fun, i'm having malta flashbacks.
<LocutusOfBorg1> dholbach, what an efficiency!
<LocutusOfBorg1> thanks a lot!
<LocutusOfBorg1> now let's hope somebody fix the chroot problems
<infinity> mvo_: That apt bug is breaking buildd chroot upgrades in utopic now too.  \o/
<infinity> mvo_: https://launchpadlibrarian.net/180716365/buildlog_ubuntu-utopic-i386.indicator-messages_13.10.1%2B14.10.20140725-0ubuntu1_CHROOTWAIT.txt.gz
<infinity> mvo_: The upshot is that's a much smaller test case.  Download http://launchpadlibrarian.net/174364588/chroot-ubuntu-utopic-i386.tar.bz2 configure sources.list for proposed, dist-upgrade.\
 * infinity is going to get some food, then do manual chroot surgery to get us back on track while mvo tries to figure out the real bug here.
<cjwatson> sarnold: yay, thanks
<pitti> erk, FTBFS galore due to CHROOTWAITs
<pitti> hm, plymouth/mountall don't upgrade, but neither of those changed recently
<cjwatson> pitti: see what infinity said just a few lines back
<infinity> I'll mangle the chroots right now to work around it so people are unblocked.
<pitti> cjwatson: ah, thanks; sorry, I just rebooted and didn't see scrollback
<mvo_> infinity: thanks
<infinity> mvo_: Grab that chroot now before I replace it. :)
<mvo_> infinity: just downloaded it
<cjwatson> infinity: Surely it gets a new LFA when you do. :-)
<cjwatson> (But yeah, would be GCed eventually)
<infinity> cjwatson: Right.
<infinity> mvo_: FWIW, it needs -proposed enabled to fail.  Probably the addition of the new "init" package.
<infinity> mvo_: An upgrade from that tarball to current, then to -proposed, works fine.  Straight from the tarball to proposed will fail.
<infinity> (Thank god for the former data point, that's how I'll work around it for now)
<cjwatson> infinity: If so, that won't be true for very much longer.  New init-system-helpers is migrating to utopic now
<cjwatson> You have a bit longer because it'll need another publisher run after this one ...
<infinity> cjwatson: Well, the new chroots are migrating to the librarian too. :)
<cjwatson> Cool
<tvoss> doko, cjwatson hey there, we are seeing some issues when using ccache with gcc 4.9 in sbuild: http://paste.ubuntu.com/7854399/
<tvoss> oh sorry, wrong paste
<mvo_> infinity: yeah, I can reproduce
<tvoss> doko, cjwatson http://paste.ubuntu.com/7854397/
<cjwatson> That looks like a local config failure, maybe /var/cache/ccache-sbuild/ not mounted in the chroot or something, not sure why you're bothering doko with it
<cjwatson> Doesn't look like a toolchain problem
<doko> and why are you using ccache for package builds at all?
<tvoss> doko, helps a lot in speeding things up for local test builds
<tvoss> cjwatson, thanks, wasn't sure if it's a toolchain problem, or not
<cjwatson> I assume you're following https://wiki.debian.org/sbuild#Using_.22ccache.22_with_sbuild - perhaps those wiki instructions are buggy or perhaps the sbuild profile is wrong
<cjwatson> (since that's basically the only google hit for "ccache-sbuild")
<cjwatson> Note that those instructions assume that the relevant schroot is using the sbuild profile - if it's using say "default" instead then you need to edit a different fstab
<tvoss> cjwatson, we are usually following https://wiki.ubuntu.com/SimpleSbuild
<tvoss> cjwatson, but yeah, that points to the debian page
<cjwatson> tvoss: OK, I think my answer is "when you figure out the problem please document it on the wiki" then :-)
<Saviq> cjwatson, yes, I got the script from there, and it worked until we switched to explicit gcc
<dholbach> LocutusOfBorg1, in 1348564 you seem to have attached the wrong diff
<LocutusOfBorg1> sorry
<LocutusOfBorg1> done now
<dholbach> elopio, does https://code.launchpad.net/~canonical-platform-qa/messaging-app/qmltests1/+merge/227661 need any action?
<dholbach> thanks LocutusOfBorg1
<doko> pitti, jibel: is the autopkg test queue busy? wondering why the autopkg test for lava-server isn't run
<jibel> doko, it ran but proposed-migration was stuck
<jibel> doko, or more exactly it is running
<doko> thanks
<LocutusOfBorg1> sorry again dholbach, calling every file "debdiff" is a shame
<LocutusOfBorg1> :)
<dholbach> it's all right :)
<dholbach> LocutusOfBorg1, I'm adding the bug number to the changelog entry
<LocutusOfBorg1> thanks ;)
<dholbach> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<mvo_> infinity: hi, this is not entirely trivial to debug, but it is definitely the init addition thats triggering the bug
<mvo_> infinity: there are quite a few loop but they get correctly broken without the new init pkg and no longer with it. lets see whats causing it
<xnox> mvo_: infinity: slangasek: that init package looks very bad, we should not have it in ubuntu. Especially since we don't have neither sysvinit-core, nor systemd-sysv, nor ready to support either of them.
<infinity> mvo_: Well, if you can figure it out, it'll probably fix jibel's saucy->trusty issue too.  The symptoms seem nearly identical, even if the cause isn't immediately obviously the same.
<infinity> mvo_: But there's the part where two of the three times this has happened (before trusty release, and now in utopic), we found a change in the base set that was tickling the issue, but in the saucy->trusty case, it's not entirely obvious if that's happening...
<pitti> xnox: in my current sysvinit merge I still dropped syvinit-core and sysvinit; I suppose we never want those two, even with "init" being around
<pitti> xnox: but shouldn't init also have an upstart alternative?
<infinity> pitti: It does.
<pitti> Pre-Depends: sysvinit-core | systemd-sysv | upstart
<infinity> xnox: I see nothing "bad" about the init package being merged.
<pitti> so, we only have upstart ATM
<pitti> so that should be fine
<infinity> xnox: Especially if the intent is to simplify and normalize dependencies.
<xnox> pitti: we will not have sysvinit-core though.
<infinity> xnox: So?
<pitti> yeah
<pitti> systemd-sysv at some point
<infinity> xnox: It's an OR dep, ones that don't exist are happily ignored, and the one you already have installed always wins.
<xnox> infinity: for ubuntu, our transition will be not via init package though. For us, we will simply build upstart without sbin/init, and make systemd conflict & replace it....
<infinity> xnox: So, it's harmless.
<infinity> xnox: The transition won't be via that package in Debian either.
<infinity> xnox: Anyhow, I see no reason to gratuitously diverge, the package is harmless.
<xnox> infinity: it's clearly not harmless, given the havoc it caused. And I still assert that it's uterly pointless in Ubuntu =) especially as an Essential package, give that our upstart is not Essential.
<infinity> (Except for exposing the annoying apt bug, yet again, but we really really need to fix that, not keep reverting every change that trips it)
<xnox> infinity: it causes upstart to be pulled in, into more places than it used to be..
<infinity> xnox: It cause no harm, apt did.
<xnox> why make upstart essential?
<xnox> also it would need to be Multi-Arch:foreign, and it's not marked as such.
<infinity> xnox: upstart is prio:required and transitively essential, where was it not being pulled in previously?
<xnox> trying to work that bit out. I'm fuzzy on essential vs required.
<infinity> xnox: required is "your system is broken without these packages installed" and apt won't let you remove them without typing "Yes, I'm an idiot".
<infinity> xnox: essential is "stuff you don't need to depend on".
<xnox> but a chroot without an init is not broken.
<infinity> xnox: It was likely wrong for us to *make* upstart part of that set, but it always has been.
<xnox> yeah, nominally it was aimed at minimal.
<infinity> xnox: So, whatever world you're remembering where you could set up a chroot without upstart isn't Ubuntu, or is pre-upstart.
<xnox> or it's my little world where i do $ apt-get remove upstart in chroots and watch it shrink.
<xnox> also docker does that.
<infinity> So, you type "yes, I know what I'm doing", and remove all the things that depend on it?  Fair enough.
<xnox> infinity: and, we will carry essential pointless packages for the sake of it?
<infinity> You could still do that with this new package.
<xnox> no, in trusty it doesn't ask me to type "yes, I know what I'm doing"
<xnox> http://paste.ubuntu.com/7856047/
<infinity> xnox: Oh, no, you're right.  It only makes you say that for essential, not required.
<infinity> So, we could just drop the essential from this package, and otherwise leave it alone.
<xnox> now, i will not be able to do so in utopic, since "init" is essential, and needs --force-remove-essential
<xnox> infinity: ok, (a) drop essential (ubuntu-only) (b) mark it M-A:foreign (forward to debian)
<infinity> I'd forward the first bit to Debian too.
<infinity> sysvinit was never essential, same complaint there as here.
<infinity> In fact, a bare Debian debootstrap has no init, while a bare Ubuntu does, they were always slimmer.
<infinity> sbin/init that is, not the new package. :P
<xnox> infinity: ok, can you nuke my init-helpers upload from utopic-proposed then? i will not bother fixing it.
<xnox> infinity: and just send patches to debian for feedback.
<infinity> xnox: Done.
<xnox> mvo_: that init package looks very broken. It's essential, and pre-depends on non-essential packages. There is no way to resolve that, is there?
<xnox> (newly essential)
<cjwatson> huh?  essential isn't closed.
<cjwatson> note how libc6 isn't essential.
<mvo_> xnox: I can not say that I feel good about it being essential, among other things it makes life more complicated for apt as it handles essential special, i.e. it wants to immediate-configure them. and it will do the same with all dependencies of essential packages which make upstart and its dependencies immediate configure and thus more work
<cjwatson> you might not want it to be essential for other reasons, but "pre-depends on non-essential packages" isn't broken in and of itself :)
<mvo_> infinity: I have a reasonable testcase now http://paste.ubuntu.com/7856261/ - note how in line 26 procps is configured and in line 28 initscripts is configured, those need to be in the same line (they are a dependency loop)
<mvo_> infinity: at least that is now something to work with :)
<xnox> cjwatson: i see. "isn't broken", sans bugs like "it breaks our apt each time" =)
<cjwatson> but that's not because of the mere fact of an essential package pre-depending on non-essential packages.
<infinity> xnox: A bug in apt doesn't make another package broken.
<cjwatson> if it were, then our archive would have been broken for ten years.
<cjwatson> apt-cache show util-linux
<infinity> xnox: And this bug is exposed other places too, we need to fix it, not keep working around it.
<cjwatson> for that matter, apt-cache show dpkg
<xnox> yiikes. yeah. now i see it. horum. good luck mvo_ =)
<cjwatson> (essential has to not be closed under (pre-)dependency, because otherwise it would be impossible to ever implement a library transition that affected the essential set.)
<infinity> cjwatson: I keep waiting for libc7 to happen, just to prove the point.
<xnox> i've never used computers with libc so name less than 6 =)
<xnox> (kfreebsd notwithstanding)
<cjwatson> I was about to say :)
<infinity> You could have said "with a libc other than glibc2". ;)
<infinity> Also, youngun.
<infinity> libc5->libc6 was very painful.
<ogra_> oh, i remember that one
<rbasak> Is merge-o-matic known to be broken at the moment?
<cjwatson> It was fine last I looked, and it should be mailing me if there are problems
<rbasak> It's generating buggy .src.tar.gz files (quilt patches applied, but no .pc directory)
<rbasak> eg. exim4
<cjwatson> Oh, that's just how it's always been I think
<cjwatson> You probably just want to do such merges yourself
<cjwatson> Or use http://people.canonical.com/~cjwatson/dpkg-quilt-setup to set up .pc
<rbasak> Ah - thanks.
<rbasak> We're mentoring new team members in #ubuntu-server, and everyone is hitting that.
<rbasak> I don't tend to use MoM much myself so didn't know about that.
<cjwatson> Merges aren't a good thing for new people anyway, IMO.
<cjwatson> I've been fighting against the notion that they're a sensible intro task for a long time now
<rbasak> We have a big pile of outstanding merges to do, and not enough people to do them :-/
<cjwatson> Yeah, but in general you need a fairly good understanding of packaging first.
<rbasak> I have the same opinion about bug triaging (for the server team anyway) - need a fairly good understanding of the underlying packages and use cases first.
<rbasak> They seem to be doing a reasonable job of understanding the previous delta.
<cjwatson> For merges I pretty much always debdiff myself and apply directly, using patch --dry-run until I've mangled either side into shape.  I only use MoM for a listing and for a rough guideline.
<cjwatson> (In cases where I can't do the merge in revision control, of course.)
<xnox> mvo_: infinity: hm. in the bug report it was pointed out that in debian they already have another essential metapackage with exact same pre-depends. (sysvinit)
<xnox> which we don't have, it looks.
<mitya57> jtaylor: Is there any reason we haven't yet synced new matplotlib from Debian?
<barry> pitti: ping
<pitti> barry: ICMP command not implemented
<pitti> barry: (TGIF)
<pitti> do we have a version of http://people.canonical.com/~ubuntu-archive/nbs.html for -proposed?
<pitti> barry was asking about zope.security promotion, which drops (NBS) python-zope.security-untrustedpython
<pitti> but it's not there
<infinity> pitti: We don't, no.  Though update_excuses makes it sort of obvious to people who know how to read it, at least.
<pitti> infinity: yeah, so I figured that http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#zope.security was due to NBS
<pitti> but not seeing reverse deps anywhere is a bit inconvenient
<pitti> "reverse-depends python-zope.security-untrustedpython" is good enough, but error prone (forgetting build deps, etc.)
<pitti> anyway, I suppose britney doesn't want to promote it due to the NBS
<infinity> pitti: reverse-depends -b? :)
<pitti> even though the new package has a Provides: python-zope.security-untrustedpython
<barry> -b gives build-deps
<pitti> yes, I know, still error prone :)
<barry> yeah ;)
<pitti> so in theory the package shoudl be able to promote
<infinity> Yeah, agreed, we should have a proposed one.
<barry> the provides is now in zope-untrustedpython
<pitti> as the two rdepends are unversioned
<infinity> pitti: If the new package has a provides, and nothing has versioned deps, we're good to go, remove away.
<pitti> ack; just wanted to double-check my reasoning
<infinity> pitti: Note that nbs.html doesn't handle that situation at all either, it would need the same manual checking.
<infinity> pitti: It would tell you it was NBS, but unsafe to remove.
<pitti> but list all deps
<infinity> True, it does that.
<pitti> barry: anyway, python-zope.security-untrustedpython removed
<pitti> barry: so after the next publisher run, britney should stop whining
<barry> pitti: awesome, thanks.  thanks too infinity
<hallyn> hi - bit of autoconf help would be great for git://github.com/cgmanager/cgmanager.  When I build locally, I get 'cgm' built as .libs/cgm, and ./cgm is a libtool-generated temporary wrapper script for .libs/cgm.
<hallyn> can someone look at my configure.ac and tell me what i'm doing wrong to force that to happen?  Is it the cgm_DEPENDENCIES?  (though dropping that doesn't help)
<pitti> thanks infinity
<pitti> infinity: also for untangling the chroots -- how did you LART them back into a working state, OOI?
<hallyn> the real problem is that in jenkins it's not doing that, so I get https://travis-ci.org/cgmanager/cgmanager/jobs/30841377 when help2man tries to run ./libs/cgm
<hallyn> so i just want it consistent.  i do need the libcgmangaer.la built before cgm
<hallyn> well, i supposei could have Makefile.am check if .libs/cgm exists, and if not run ./cgm
<infinity> pitti: I just upgraded them.  Upgrading in two steps (to recent utopic, then to the new init) worked fine, it's in one step that apt barfs.
<infinity> pitti: But, if you're in that barfy situation, it also works to just do it twice.
<infinity> pitti: ie: apt-get update ; apt-get dist-upgrade ; apt-get -f install ; apt-get dist-upgrade
<pitti> heh, fun
<pitti> leaves a stain of disappointment on the super cow powahs, though
<mvo_> jibel: if you can still reproduce  lp1347721 in the lab, would it be much work for you if you would put this ppa into the system  https://launchpad.net/~mvo/+archive/ubuntu/lp1347721/ works around the  bug?
<jibel> mvo_, is it a workaround to make the upgrade succeed or a fix to test ?
<mvo_> jibel: its a workaround for the upgrade, a by-product of my debugging, if it helps
<mvo_> jibel: if its too much trouble don't bother, its a 50:50 chance at this point
<jibel> mvo_, no problem, I'll add this ppa
<xnox> hallyn: looks correct. one needs to do $ make install, for proper binaries to be installed...
<hallyn> xnox: so jenkins is being weird by not having .libs/cgm ?
 * hallyn is being hits by an old old bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=534964 :)
<ubottu> Debian bug 534964 in linux-2.6 "Please enable CONFIG_CGROUP_MEM_RES_CTLR" [Wishlist,Fixed]
<hallyn> the problem is it's nto mountable, but it shows up in /proc/cgroups.  that's nto nice
<xnox> hallyn: you shouldn't use .libs/cgm, looking more. one sec.
<hallyn> xnox: ./cgm does work, but it prefixes argv[0] with 'lt-'.
<hallyn> Well I suppose I can just hardcode the name as cgm :)  simpler solution
<cjwatson> use ./libtool --mode=execute
<hallyn> cjwatson: this is for running through help2man from Makefile though
<cjwatson> ah
<hallyn> so i wasnt' thinking, simplest solution is probably just to fix up the argname inside cgm's usage statement itself
<cjwatson> I tend to think help2man is best used to generate a template which you then maintain manually henceforth; it's not cross-build-friendly to start with
<hallyn> hm
<hallyn> i did worry at first, but it seemed to be working out
<mbiebl> xnox: still anything unclear after reading the email with the transition plan?
<xnox> mbiebl: yes.... e.g. how to apply it to ubuntu that (a) broke all our chroots today on all buildds (b) we don't have sysvinit / essential:yes metapackage.
<melodie> hi
<xnox> mbiebl: and we don't support sysvinit init, thus we'll need hard upstart -> systemd migration, when it's ready.
<melodie> I have a very simple question for I didn't find a way to find out this by myself : what exactly is the gtk3 version used in Trusty, please?
<melodie> or what method will allow me to find out?
<cjwatson> melodie: rmadison gtk+3.0
<xnox> melodie: https://launchpad.net/ubuntu/+source/gtk+3.0
<mbiebl> xnox: I guess that needs to be figured out by the Ubuntu maintainers and means a debdiff for i-s-h
<melodie> thanks!
<mbiebl> xnox: i.e. no automerge anymore
<melodie> cjohnston what is rmadison?
<xnox> mbiebl: sure, that's fine. It's just still very fuzzy to me how to do it properly, and e.g. we do have a few more places where we can quirk things (upgrade-manager)
<xnox> hence no prior need for "sysvinit" package per se
<mbiebl> yeah, I can understand that the init package is not really interesting for ubuntu
<cjwatson> melodie: man rmadison
<cjwatson> melodie: (it's in devscripts)
<melodie> ah! I was wondering how to install it, thanks
<mbiebl> and actually harmful as it is
<xnox> mbiebl: that's the conclusion i came to, but infinity believe it's harmless.
<xnox> mbiebl: out of the three packages listed, we only have upstart. so it doesn't seem to be harmful, just very pointless.
<mbiebl> oh, you don't have the systemd-sysv package yet in utopic?
<smoser> hey. i'm sure i'm doing something dumb.
<xnox> mbiebl: nope, we are not ready yet.
<smoser> but someone able to tell me what
<mbiebl> xnox: ok, then yeah, it sounds like it shouldn't do any harm
<smoser>  http://paste.ubuntu.com/7857020/
<xnox> mbiebl: we merge systemd, but we are not building that one yet. We still have a lot of packages that have upstart jobs without either initscripts/units.
<mbiebl> sure
<xnox> mbiebl: nothing of major importance, just like things like openstack.
<mbiebl> :-)
<tinoco> could any of you guys upload a fix (https://bugs.launchpad.net/ubuntu/+source/parted/+bug/1333462) for me ?
<ubottu> Ubuntu bug 1333462 in parted (Ubuntu Precise) "Precise: Linux partitioning tools give GPT Linux partitions wrong type code" [Undecided,In progress]
<smoser> full log at http://paste.ubuntu.com/7857090/ if helpful.
<smoser> stgraber, or pitti  ?
<hallyn> xnox: so out of curiosity, is the init script conversion being tracked somwhere?
<xnox> hallyn: on ad-hoc basis atm.
<alexbligh1> hallyn, are you interested in a patch that allows for qemu / kvm live migration between Precise and Trusty?
<hallyn> alexbligh1: I am
<alexbligh1> hallyn, https://lists.nongnu.org/archive/html/qemu-devel/2014-07/msg03160.html & https://github.com/abligh/qemu/commit/dc5a04eb2a55ba5024726d2aae5a980315f3c885
<alexbligh1> hallyn, working in my (limited) environment. If there is a chance of upstreaming it either to qemu or to Ubuntu, then I will get it working more generally.
<alexbligh1> hallyn, it adds a new machine type which matches qemu-kvm 1.0 (as opposed to qemu-1.0)
<hallyn> alexbligh1: Looks like it won't affect anything else, perfect.  Does it actually work?
<hallyn> it chagnes vga size?  (/me eyes glazing over)
<alexbligh1> hallyn, it does in my limited use case (I don't use every option qemu provides). I know there is probably a bit of work to do on qxl, as that changed too. And it needs more testing. And, um, it would be helpful to have someone respond on qemu-devel and get some interest in taking it upstream.
<hallyn> I don't think anyone used qxl in precise, so it would suffice for ubuntu without that
<hallyn> rharper: hey!
<alexbligh1> hallyn, vga ram size, yes.
<hallyn> rharper: ^ could you comment on that patch on the mailing list?  It looks very nice to me...
<alexbligh1> hallyn, vga rom size is a different problem, caused by the size of the shipped roms changing.
<hallyn> alexbligh1: but you're able to migrate VMs from precise to trusty, despite that?
<rharper> hallyn: looking
<alexbligh1> hallyn, rharper and it really could do with more eyes
<alexbligh1> hallyn, in a test environment on my laptop with the VMs that we produce, yes.
<alexbligh1> hallyn, If you send me a livemigrate to disk snapshot that doesn't work, I'll look at fixing them.
<rharper> my biggest concern with the migration data patching is that we're likely going t miss something, so different device, or different device state;
<alexbligh1> hallyn, the complication is $work doesn't use libvirt.
<rharper> in upstream, there was considerable effort to automate the generation of the migration structures automatically;
<alexbligh1> rharper, it's self-contained (i.e. a new machine type). So the worst that can happen is migration (still) fails.
<rharper> no, it's worse
<rharper> it'll succeed and you'll have data corruption
<rharper> that's what I worry about
<alexbligh1> rharper, I don't think I'm touching that bit really. When it failed before it failed hard (section IDs did not line up).
<alexbligh1> rharper, unless I'm missing what you mean?
<rharper> right, so, we're stuffing old memory layout into new memory layouts;  it's not clear to me that the new devices  with old memory do all of the right things
<rharper> we're attempting to resume "newer" devices with "older" machine state
<rharper> that's risky
<alexbligh1> rharper, same memory layouts as previous versions of qemu, but they were advertised wrong; so, for intance, the piix4 acpi stuff was actually sending v3 format code, but advertising as v2. There has always been a v3 format reader there, it just wasn't being triggered.
<alexbligh1> rharper, same sort of thing for the 8259 PIT code. It's really that the qemu-kvm / qemu-merge was not at a single point in the format specification. I'm not using any new structures really. And it's heavilly based on the redhat patch I indicated (save I do it dynamically) - they tested all the migrate cases (apparently). The exception being rom size problems (because that's down to Ubuntu's packaging)
<rharper> it still makes me uncomfortable w.r.t running a new machine type on the destination, you'll still want to make the switch to the new machine at some point (I would think w.r.t support).  With any migration changes, I would recommend working with mdroth on #qemu (stable maintainer IIRC)
<alexbligh1> rharper, agree re wanting to make the switch some time. But in a situation where you have multiple live customers, 'when I upgrade my host OS' is not the best time for all customers to make the switch (assuming upgrading host OS means a live migrate). What we're doing is live migrate around OS upgrade, then on reboot we're upgrading to -M qemu-2.0. Don't think we can get around the 'new machine type' issue, if
<alexbligh1> you want to keep live migrates from 'real' qemu-1.0 type stuff working (which would include live migrates from q,r,s,t which were launched with -M qemu-1.0 IIRC).
<rharper> yeah, I understand the challenges w.r.t consuming the unstable migration format;
<alexbligh1> rharper, though breaking them and making -M pc-1.0 do this by default and provifing pc-1.0-old would be a trivial change (s/qemu-1.0/pc-1.0/g; in the above)
<alexbligh1> rharper, hallyn well, it's there if you want it. Very happy to generalise it as far as possible, test, debug etc. if you want it for Ubuntu. If not we'll use it for our own use case. Will be trying to get it upstream anyway.
<rharper> alexbligh1: right -- I'd really like to see Mike Roth or Juan Q. feedback on the patches, you might cc them in future rounds of the patch
<alexbligh1> rharper, thanks; will do next time I ping the list - sounds of stones falling into wells so far
<hallyn> desrt: hey, are you back?
<alexbligh1> rharper, though fixing this way was bonzini's idea...
<rharper> alexbligh1: if all of the "fixes" are related to misadvertised format; then I'd feel better;  actual format deltas or other bugs w.r.t data not getting transfered or initialized is my worry
<hallyn> alexbligh1: could you cc: me explicitly when you next send?  (I subscribe to qemu-devel, but it pretty much goes straight to /dev/null )
<rharper> alexbligh1: qemu-devel is like that quite often, you can find most of the devs on #qemu on OFTC;  worth popping in after a few rounds of resubmits;
<rharper> alexbligh1: cool
<hallyn> alexbligh1: thanks!
<alexbligh1> rharper, the two things that were actually breaking reloads were essentially misadvertised stuff. without the patch it goes stomping off the end of a structure and (inevitably fails). With the patch then (if fed an output from qemu-kvm-1.0) it actually has the right structure boundaries.
<alexbligh1> rharper, reading the redhat patch may help understand what I am doing.
<rharper> alexbligh1: confined to how you launched your VMs
<alexbligh1> rharper, yes, but the only other one I /know/ of that's wrong is QXL video size.
<rharper> alexbligh1: I went through it briefly, but qemu has *lots* of devices and *lots* of options;  the migration format has had *lots* of bugs
<rharper> alexbligh1: right, which is why I was hoping to leverage some of the 2.0 migration testing framework to iterate throug the various device configs to confirm misadvertisement versus other missing descriptors in the device layout
<alexbligh1> rharper, yes. amit did a JSON compare and we're catching all those catch (which isn't everything). But if there's another struct missize error/advertising error, it will be mismatched anyway as it is (that's what I meant by won't be any worse)
<alexbligh1> rharper, you mean amit's stuff? the trouble is he only tests what it /says/ it advertises, not what it actually sends. So it wouldn't have found these
<alexbligh1> rharper, ... or any others like it.
<rharper> right, so the json work is step one, the next would to be to migrate and exercise the resulting VM to some degree to build confidence
<alexbligh1> rharper, indeed. And it probably also needs to survive a soft reboot for more general usage than mine, which will reexercise the ROMs.
<rharper> yeah
<rharper> there's no good fix for reloading of the roms
<rharper> mdroth and I talked about that many times...
<rharper> definitely the reboot is needed
<rharper> as that's where the device will get reset with the new qemu; and potential explosions
<alexbligh1> rharper, you only really need to 'fix' it when the ROM size changes across a power of 2; last time I looked in my environment it was only the cirrus vga ROM which had done that, and the answer there might be to ship the Precise cirrus vga ROM binary with qemu, as you can change the rom binary from the command line (yuck).
<alexbligh1> rharper, if you don't do that, then even a blank file of the right length will work on migrate until soft reboot, at which point the user presumably says "hmm, odd, soft reboot failed, let's try hard reboot', which is not a disaster.
<rharper> alexbligh1: right, the challenge is that any upgrade to the ROMs could trigger trouble if the sizes change enough;  and it's possible for it to go either way (shrink or expand);  we talked about some how bringing the source roms along; but that prevents upgrades
<alexbligh1> rharper, correct. But presumably we should not be permitting such changes in ROM size within a given release, and if we change them between releases, we should ship the old ones too.
<alexbligh1> rharper, AIUI the redhat way of doing things is that round(log2(romsize)) is a fixed constant forever.
<rharper> alexbligh1: in general yes; but closing a CVE vs. not fixing --
<rharper> and then there are cases of migration between hosts which don't have the same version of the package
<rharper> which can trip it up again (on soft-reboot post migration)
<rharper> it's a non-trivial problem
<alexbligh1> rharper, re CVEs, sure, but none of them on Redhat has yet changed romsize across a power of 2 (AIUI). And re different versions, agree, which is why I said we may need to ship 'old roms', unless we are content for soft-reboot to fail potentially (though TBH why qemu reloads roms on soft reboot rather than using migrated rom data I don't know).
<rharper> where are you going to put the migrated rom ?
<rharper> there's no versioning of the actual rom file, nor a place to write it out to keep it around on a per-guest basis;
<alexbligh1> rharper, on /soft/ reboot, the qemu-kvm process won't even stop will it, so it could just stay in (host) RAM if it was migrated across. On /hard/ reboot, obviously qemu-kvm stops, and a new ROM will be loaded from disk. If it's larger, then the ROM size will grow and the memory map will change; if it's smaller it should work loaded into a larger slot.
<rharper> alexbligh1: w.r.t soft reset reloading roms from disk, that's expected behavior, ala hitting reset on real hardware; what's happening though is that the underlying machine/hardware has changed
<cjwatson> doko: any chance of sorting out an MIR for python-service-identity?  python-twisted-core depends on it now, blocks e.g. apport build
<rharper> alexbligh1: I forget where this ended, but even pushing the rom from the remote (which still could be a mismatch from the running process) and having the target write out those roms doesn't seem like a good idea;  though it's been a while since I've walked through all of the steps and cases
<alexbligh1> rharper, I suspect it's pretty hard to get something that will work reliably in every scenario across reboot. However, I figure that reboot means the VM has no live data in, so a live migrate that simply provides different hardware across a reboot (perhaps you need to do a hard reboot instead) is still a huge step forward from 'I can't migrate my vm at all'.
<alexbligh1> rharper, and changing the way ROMs are dealt with on migration would be hugely invasive compared with what I'm proposing anyway.
<rharper> alexbligh1: rom migration is a separate issue (though somewhat related via migration protocol);
<smoser> xnox, thanks for your help. the cloud image now has systemd in it. and tomorrow should have cloud-init systemd units
<rharper> alexbligh1: if we can do a bit more confirmation that all we're fixing is misadvertised migration data; I think the approach is reasonable;  but since the guest ultimately has to be rebooted  I still find the live migration to be less than ideal;
<rharper> s/rebooted/restarted as a new machine type;
<alexbligh1> rharper, that (your bit starting 'but') is fair comment. Though for my own use I don't need it to survive a reboot, I /think/ all you need to do to make it survive a reboot is copy the Precise cirrus ROM file over and start with the appropriate command line. I'll check that over the weekend.
<alexbligh1> rharper, that was I think behaving differently on qemu-2.0.0-rc2 (as shipped on 14.04) and qemu-2.0.0 from git. I need to check why.
<rharper> alexbligh1: yes, I think that'd do it;  might be "fun" to get libvirt to talk two qemu installs and paths; but that should suffice for rom related reboot issues.
<alexbligh1> rharper, and if we wanted to, we could always ship the Precise ROM on trusty with some other filename (yes, I know it's disgusting)
<rharper> alexbligh1: yes, and specify the rom in the xml
<alexbligh1> rharper, you are in libvirt land now so I shall pretend I don't know what you are talking about :-) (yes, I think so)
<rharper> this slowly creeps into the rom versioning/signatures and compat for migration;
<rharper> alexbligh1: you can specify the path to the romfile for any of the devices that take one
<rharper> that's all
<alexbligh1> rharper, yep. Just an automated way of getting onto the qemu command line.
<rharper> s/automated/massively complicated
<alexbligh1> rharper, I shall refer the honorable gentleman to the reply I gave earlier regarding not using libvirt :-)
<rharper> =)
<doko> cjwatson, yep, should do that ... will try on the weekend
<arges> hallyn: does bug 1348551 need to be fixed for utopic as well?
<ubottu> bug 1348551 in qemu (Ubuntu) "qemu-kvm upstart configuration from qemu-system-x86 relies on binary from qemu-kvm" [High,Triaged] https://launchpad.net/bugs/1348551
<hallyn> arges: uh, isn't it?
<hallyn> i pushed that fix this morning
<arges> hallyn: i was just looking at the bug status, i'll look
<hallyn> arges: thanks - it's possible i messed up.  <ahem> unlikely of course
<arges> does 2.0.0+dfsg-6ubuntu2 have the fix?
<hallyn> yeah
<sarnold> Trevinho: 1348668  :)
<arges> hallyn: looks like it has some issues
<arges> http://people.canonical.com/~ubuntu-archive/testing/utopic-proposed_probs.html
<hallyn> slangasek: just pushed a new cgmanager to mentors.  Would you mind taking a look?
<arges> search for qemu on that page
<hallyn> xnox: https://github.com/CameronNemo/cgmanager/commit/b809c1958e843de99b470a03d5c2dabdeb64d747   so should i merge that?  I couldnt' quite follow the conversation
<hallyn> arges: so how did -1 build?  that didnt' change at all
<arges> hallyn: i'm not entirely sure, may need to ask an AA what the issue is
<hallyn> yeah.  thanks for pointing it out.
<arges> np
<hallyn> cjwatson: ^ latest qemu upload is saying:  E: Package 'qemu-user' has no installation candidate
<hallyn> but debian/control isn't changed from teh last (successfully built) package
<achiang> hallyn: hey, i'm trying to create a chroot whilst inside a container, but getting permission errors...
<achiang> lxc.mount.entry = /var/lib/schroot var/lib/schroot none bind,optional,create=dir
<achiang> ^^ that is in my config file, of how the schroot directory gets bind mounted into my lxc container
<hallyn> and that succeeds?
<achiang> hallyn: and inside the container, i am running with sudo, but still seeing a permissions error
<achiang> PermissionError: [Errno 13] Permission denied: '/var/lib/schroot/chroots/click-ubuntu-sdk-14.10-armhf'
<hallyn> achiang: what syscall is getting the eperm?
<achiang> hallyn: mkdir
<achiang> http://pastebin.ubuntu.com/7858012/
<hallyn> achiang: can you sudo mkdir /var/lib/schroot/chroots/click-ubuntu-sdk-14.10-armhf by hand?
<hallyn> (I can...)
<achiang> hallyn: i can't... so i'm suspecting pilot error on my part
<achiang> hallyn: is it something weird with my bind mount?
<hallyn> could be, lemme try
<hallyn> hm, yeah, i can mkdir there
<hallyn> (i bind-mounted /mnt to /var/lib/schroot)
<hallyn> achiang: can you try subsituting /mnt for /var/lib/schroot in the lxc.mount.entry mount source?
<achiang> hallyn: this is my new lxc mount entry: lxc.mount.entry = /mnt var/lib/schroot none bind,optional,create=dir
<achiang> hallyn: and i'm still getting permission denied? i stopped and restarted the container
<achiang> $ sudo mkdir -p /var/lib/schroot/chroots/click-ubuntu-sdk-14.10-armhf
<achiang> mkdir: cannot create directory â/var/lib/schroot/chrootsâ: Permission denied
<slangasek> hallyn: cgmanager> pulling
<slangasek> hallyn: btw, do you want to VCS this thing somewhere so we don't have to shuttle source packages around? :)
<hallyn> slangasek: hm, yeah.  how do i create a tree at the debian git server?
<hallyn> (so that when they take the pkg from me they can just take over the tree rahter than have to cloen my github tree :)
<hallyn> achiang: please pastebin /proc/self/status, /proc/self/attr/current, /proc/self/uid_map
<slangasek> hallyn: if you have an alioth account, you should be able to create something under the collab-maint tree; otherwise you can request a new project be set up if you want only explicitly approved people to be able to commit
<achiang> hallyn: http://pastebin.ubuntu.com/7858087/
<hallyn> slangasek: I do have an account;  I'll look into it
<achiang> hallyn: my apparmor config outside the container needs to be fixed, i think is the problem
<achiang> hallyn: looking into it now
<hallyn> ok
<achiang> hallyn: hm, even with this on my host, i still can't mkdir - http://pastebin.ubuntu.com/7858279/
<hallyn> achiang: what if you just use unconfined?
<achiang> hallyn: let me try
<achiang> hallyn: even that fails. very strange
<achiang> $ cat .local/share/lxc/ubuntu-sdk/config  | grep unconfined
<achiang> lxc.aa_profile = unconfined
<hallyn> slangasek: can't find an option to create a tree.  i'll just push to github for now
<hallyn> achiang: the mkdir is not done inside a chroot, right?  that' s just in the container?
<hallyn> you can do that mkdir on the host?
<achiang> hallyn: yes, just in the container
<achiang> hallyn: let me test on host
<achiang> hallyn: yes, works on host
<hallyn> slangasek: pushed to github.com/cgmanager/cgmanager-debian
<hallyn> achiang: and then you *see* it in the container?
<achiang> hallyn: yep
<hallyn> does getfacl show anything funky for that contaienr?
<hallyn> uh, that dir
<hallyn> (the parent dir)
<hallyn> and, to be sure, 'strace -f mdir /var/lib/schroot/chroots/click-ubuntu-sdk-14.10-armhf' shows that it's the final mkdir that is failing?
<achiang> hallyn: i think so? http://pastebin.ubuntu.com/7858373/ see line 90
<achiang> hallyn: oh. maybe it has something to do with 777 perms?
<achiang> well... that was from the command line so perhaps unrelated
<hallyn> achiang: hold on.  do you have lxc.id_map in the container config?
<hallyn> i was beign silly,
<achiang> mmm... yes i have that
<hallyn> I think it's bc nobody is not mapped in
<achiang> http://pastebin.ubuntu.com/7858405/
<achiang> ah
<hallyn> add one more # to the last range
<hallyn> you need 64536 I think to hit what userspace calls 'nobody'
<achiang> really?
<achiang> $ grep nobody /etc/passwd
<achiang> nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
<hallyn> hm
<achiang> oh wait
<achiang> my map goes to 64*
<achiang> not 65*
<achiang> duh
<hallyn> no, bc you start at 1001
<achiang> interesting
<hallyn> so when you ls -dl /var/lib/schroot/chroots in the container, what do you see exactly?
<achiang> ubuntu@ubuntu-sdk:~$ ls -dl /var/lib/schroot/chroots/
<achiang> drwxr-xr-x 5 nobody nogroup 4096 Jul 25 19:16 /var/lib/schroot/chroots/
<hallyn> hm
<slangasek> hallyn: please don't use debian-only git repos :(
<achiang> making that change of 64536 didn't help
<slangasek> hallyn: this git repo shows no upstream history
<hallyn> slangasek: correct, was intended as a packaging tree only
<slangasek> hallyn: yeah, those are horrible
<slangasek> :)
<hallyn> next week stgraber will teach me how to do that dpkg-git thing (or whatever it is)
<slangasek> hallyn: meanwhile, 0.28-2 uploaded
<hallyn> thanks
<hallyn> achiang: what fs is your $HOME?
<achiang> hallyn: uh. default? ext4 i'm pretty sure
<achiang>  /dev/sda1 on / type ext4 (rw,errors=remount-ro)
<achiang> hallyn: i think i'm just going to give up for now, and wait until next week. a newer version of the click tool will appear in a PPA i need and i can create the directory outside the container
<hallyn> achiang: fwiw i can reproduce it here.
<achiang> hallyn: ah, interesting
<hallyn> sarnold: hey, are you around, got a sec?
<hallyn> hm, nm, my observations were tainted
<hallyn> back to the kernel sources
<hallyn> achiang: so the workaround really is to chown it to something other than nobody:nogroup
<hallyn> i'm not sure if this is some awfully handled special-case in kernel, but it shouldn't be.
<smoser> pitti, if / when you come around, bug and fix at bug 1348749
<ubottu> bug 1348749 in autopkgtest (Ubuntu) "autopkgtest fails sometimes with adt-virt-lxc" [Medium,Triaged] https://launchpad.net/bugs/1348749
<achiang> hallyn: that seems... weird
<hallyn> achiang: d'oh, i wasn't thinking
<hallyn> achiang: inside your container there is a 65534 uid defined, mapped to some high uid.  but 65534 on the host is not mapped into the container!
<hallyn> and you're not allowed to map it
<hallyn> so you simply must chown /var/lib/schroot/chroots to your own uid
<hallyn> (:gid)
<hallyn> or to some other uid mapped into your container
<hallyn> now i feel silly :)
<achiang> hallyn: why can't i map 65534 from host into container?
<achiang> hallyn: on my host, /var/lib/schroot/chroots is owned by root. i don't think i really want to make that owned by my normal uid/gid?
<hallyn> achiang: well, you *can*, you can add it to /etc/subuid and /etc/subgid
<hallyn> i.e. i added
<hallyn> serge:65534:1
<hallyn> then to the container config i added
<hallyn> lxc.id_map = u 100002 65534 1
<hallyn> then i'm able to do it
<achiang> hm... i did this step earlier:
<achiang> # Assign UIDs/GIDs to your user for use by the container
<achiang> $ sudo usermod --add-subuids 100000-165536 $USER
<achiang> $ sudo usermod --add-subgids 100000-165536 $USER
<achiang> i would have thought that should have been inclusive of 65534
<hallyn> how? :)
<hallyn> arges: oh, I see, the last version of qemu was never released!  qemu-user-binfmts is a new package
<hallyn> infinity: ^ can you take a look at the new qemu package for utopic?  It inherited some new binary packages from debian...  dunno if I need to open a certain kind of bug in relation to those
<hallyn> achiang: 100000-165536 does not include 65534...
<achiang> um, right. i am dumb
<hallyn> heh, i got lost in the same layer
<hallyn> so i'll take the dunce cap
<achiang> i must be honest, i am reading the subuid man page now and not sure i grok it
<hallyn> achiang: what's the question?
<achiang> what is the 3rd field, 'count' ?
<hallyn> "subordinate user id" is subuid, which is a uid on the host (not in teh container)
<achiang> it's like, "goes up to" ?
<achiang> starting from 2nd field?
<hallyn> it's how big a range to map.  so if subuid is 20, and count is 5, then it's 20-24
<achiang> ok
<hallyn> so, you can pick any ids you want inside the container, but outside the container by default you can only map your own uid
<hallyn> the subuids tell the setuid-root newuidmap and newgidmap programs to let you map other uids on the host
<achiang> hallyn: i am feeling extra dumb today
<achiang> i have this in my config:
<achiang> lxc.id_map = u 100002 65534 1
<achiang> lxc.id_map = g 100002 65534 1
<achiang> and this in both /etc/subuid|subgid - achiang:65534:1
<achiang> still not able to do that sudo mkdir
<hallyn> achiang: yes you still need to add the lines to your config
<hallyn> lxc.id_map = u 100002 65534 1
<hallyn> and same for 'g'
<hallyn> oh wait
<hallyn> yeah, that's right, i'm misreading
<achiang> hallyn: i have those? :)
<hallyn> can you pb your whole config?
<achiang> http://pastebin.ubuntu.com/7859078/
<hallyn> achiang: what kernel are you on?
<achiang> hallyn: host or container?
<achiang> 3.13.0-32-generic #57-Ubuntu
<achiang> same, i guess
<hallyn> hm, now that all looks ok.
<hallyn> achiang: when you ls -l /var/lib/schroot/chroots now, does it show 100002:100002 at least owning it?
<hallyn> achiang: the waste of time before was because it was showing 'nobody:nogroup', but it meant the real, unmapped, uid/gid -1, not 65534, known through /etc/{passwd,group} as nobody:nogroup :)
<hallyn> as for now, i dunno
<achiang> hallyn: it still shows as nobody:nogroup
<hallyn> achiang: what about ls -lnd /var/lib/schroot ?
<hallyn> uh, /var/lib/schroot/chroots
<achiang> $ ls -lnd /var/lib/schroot/chroots/
<achiang> drwxr-xr-x 5 65534 65534 4096 Jul 25 19:16 /var/lib/schroot/chroots/
<hallyn> is that in the container?
<achiang> yes
<achiang> outside the container it is root:root
<hallyn> and 'sudo mkdir /var/lib/schroot/chroots/xxx' still fails?
<hallyn> wait.  root:root?
<hallyn> how does that work?
<achiang> hallyn: perhaps i should mention that i also have http://pastebin.ubuntu.com/7859183/ in ~/.config/lxc/default.conf
<achiang> hallyn: yes, outside container, /var/lib/schroot/chroots is owned by root:root
<hallyn> but that paste is not consistent with the full paste you last posted.
<hallyn> I thought that /var/lib/schroot/ was owned by root:root, and the chroots subdir was owned by nobody:nogroup
<hallyn> that's the situation I was addressing
<hallyn> achiang: if this is still a problem on monday, let's perhaps get on a shared tmux and pound it out
<achiang> hallyn: i have both a ~/.config/lxc/default.conf and a ~/.local/share/lxc/ubuntu-sdk/config
<hallyn> .config/lxc/default.conf is not consulted at lxc-start
<achiang> hallyn: but sure, we can wait for monday
<achiang> thanks for all the help today
<hallyn> achiang: what does ls -ldn /var/lib/schroot{,/chroots} show on the host one more time?
<achiang> http://pastebin.ubuntu.com/7859212/
<hallyn> achiang: I'm really confused.  did you NOT say before that nobody:nogroup owned one of those?
<achiang> hallyn: perhaps i was confusing -- i *thought* i said nobody:nogroup owned those *inside* the container and it was root:root *outside*
<hallyn> d'oh :)
<hallyn> achiang: which was extra-confusing bc of the multiplexing of those names
<hallyn> achiang: so yeah, that can't be helped
<hallyn> unless you map host's 0 into the container, which sort of defeats the purpose
<achiang> ok
<hallyn> So I recommend creating a subdir which the container can own
<achiang> ok... the alternative is to create the schroot outside the container
<hallyn> yeah, which due to mknod eaccess may be easiest anyway
<achiang> hallyn: thanks again and sorry for misleading you earler
<hallyn> achiang: np, I think ls mislead me, not you :)  A cautionary tale for next time
<achiang> hallyn: heh. ok. gracious of you, but i think i should have been more clear too :)
<sarnold> hallyn: did you get it sorted out?
<hallyn> sarnold: yeah, thanks
<hallyn> I got my host and nsuids mixed up
<hallyn> please don't comment on "if I can't get it right how can I expect others to" :)
<sarnold> hallyn: yikes, I'm glad you got that sorted while I was at lunch! ;) hehe
<sarnold> hallyn: meh, it's friday afternoon.
<hallyn> yeah, but so much unresolved junk
<hallyn> sarnold: any updates on the periodic qcow corruption?  You're still running old qemu to avoid it?
<hallyn> jdstrand: ^
<jdstrand> hallyn: still running old qemu. I am still on trusty. is there something you want me to test?
<jdstrand> hallyn: actually, if you say in the bug what you want me to do, I'll find time to do it
<jdstrand> hallyn: I'm heading out atm
<hallyn> jdstrand: no, was just wondering if you had any new info - dopnt' have anything new for you to try.
<hallyn> actually next week i'll try it out on a thinkpad, there *have* been other thinkpad-only bugs in qemu :)
<sarnold> hallyn: the most recent corruption I had was in saucy images, so I just deleted them prematurely and hoped I wouldn't miss them.. heh
<sarnold> hallyn: but I've been doing auditing lately instead of updates, so I haven't used VMs as much the last month or two
<hallyn> ok  - thx.
<hallyn> have a good weekend everyone.
<sarnold> bye hallyn :)
<hallyn> oh wait, seems i have another cgmanager init script bug to deal with first
<hallyn> whoever wants to take a look and is good with sysvinit scripts, https://github.com/cgmanager/cgmanager/commit/9647f5c36d73b14ddb925586af3e3affbafb762a is what i'm thinking of pushing to cgmanager debian to fix a slew of open bugs
<hallyn> *mbiebl: ^ that would be for yours :) )
<mbiebl> just a few comments in general
<mbiebl> if you use s-s-d --retry= you don't need any sleeps between stop and start
<mbiebl> using retry is almost always a good idea
<hallyn> (i need to run, but will do this and grab any other comments when I get back - thanks much)
<mbiebl> and to check whether a process is already running
<mbiebl> you can use start-stop-daemon --test
<mbiebl> (with the same arguments as you'd use for the real s-s-d call)
<mbiebl> I still don't quite get the logic regarding starting/stoping the cgproxy sysvinit script from cgmanager
<mbiebl> that seems broken somehow
<mbiebl> maybe under sysvinit using a singler init script is actually cleaner
<mbiebl> single, even
<mbiebl> calling "service" on another init script from within an init script is pretty meh
<slangasek> "calling service"?  I thought that was already fixed pre-upload
<mbiebl> slangasek: was referring to https://github.com/cgmanager/cgmanager/commit/9647f5c36d73b14ddb925586af3e3affbafb762a
#ubuntu-devel 2014-07-26
<slangasek> yes; I see that commit, and I'm quite sure the package I sponsored already had no use of 'service' in the init script
<mbiebl> slangasek: hallyn asked me for feedback on this commit, and I just tried to provide that
<slangasek> ok; it appears these are changes to upstream init scripts that don't correspond to what was included in the package <hmM>
<mbiebl> the current cgmanager init script uses /etc/init.d/cgproxy stop from within the cgmanager init script
<mbiebl> I don't think that's much better
<mbiebl> as said, maybe for sysvinit a single sysv init script is the cleanest solution
<mbiebl> hallyn: hm, rm -f $PIDFILE in start)
<hallyn> yeah i copied that from libvirt;  probably silly though
<hallyn> wont' do harm though
<hallyn> slangasek: the changes in the commit are destined for the debian package;  i just wanted some feedbcak before pushing to debian
<hallyn> (the only 'service' calls are in removed lines)
<hallyn> updated with using --retry.
<hallyn> and yeah, i've considered one job;  that may make the most sense.
<hallyn> slangasek: pushed new package to mentors;  seems to fix all of the start up bugs (tested here on sid)
<saizai> Any ETA on when http://changelogs.ubuntu.com/meta-release-lts will get updated for 14.04.1?
<Azendale> https://bugs.launchpad.net/ubuntu/+source/python3.4/+bug/1315733 is it reasonable to set this back to confirmed? I don't want it to fall through the cracks because it's currently listed as wontfix (even though upstream definitely sounds like the consider it a valid issue and plan on fixing it)
<ubottu> Ubuntu bug 1315733 in python3.4 (Ubuntu) "Python interactive interpreter does not indent with tabs, tries to tab-complete" [Undecided,Won't fix]
<ScottK> Won't fix and invalid aren't the same thing.
<ScottK> Once there's an upstream fix available might be a good time to link to the fix in the bug and ask again.
<Azendale> ScottK: ok, thanks, will do
#ubuntu-devel 2014-07-27
<psusi> why is the udisks2 bzr udd repo not up to date?
<doko> slangasek, cjwatson, bdmurray: please subscribe foundations to python-service-identity python-pyasn1-modules python-characteristic bug reports (for lp: #1349119)
<ubottu> Launchpad bug 1349119 in python-service-identity (Ubuntu) "[MIR] new dependencies for twisted" [Undecided,New] https://launchpad.net/bugs/1349119
<bdmurray> doko: done
<alive4ever> hello
<alive4ever> please review my merge proposal for fixing lp: #1299347. Here are links to them https://code.launchpad.net/~alivema4ever/ubuntu/utopic/weechat/lp-1299347-fix and https://code.launchpad.net/~alivema4ever/ubuntu/trusty/weechat/lp-1299347-fix
<ubottu> Launchpad bug 1299347 in weechat (Ubuntu) "[needs-packaging] weechat 0.4.3-4" [Wishlist,Confirmed] https://launchpad.net/bugs/1299347
<samgtr> hello everyone
<samgtr> i would like to contribute to ubuntu, can I know where to get started from?
<sladen> samgtr: is there a bug you've spotted, or something that you (personally) think could be improved
<sladen> samgtr: it's easier to have a goal (a small managable goal)
<samgtr> sladen: i am still not sure which area of ubuntu interests me, still trying to find that out, and I guess that you could help me out
<samgtr> sladen: I code in python mainly, also I use, HTML, JS, CSS
<samgtr> sladen: so where can I contribute the best with my skills?
#ubuntu-devel 2015-07-20
 * ogra_ is sure cjwatson must be breeding these haskell packages somewhere ... they seem to double up every release 
<juliank> ogra_: Haskell packages should be replicated, not bred.
<juliank> ;)
<ogra_> heh
<cjwatson> ogra_: fortunately, there's a giant removal bug pending in Debian to remove a batch of them
<doko> RAOF, please could you follow-up on https://bugs.launchpad.net/ubuntu/+source/abi-compliance-checker/+bug/1464447 ?
<ubottu> Launchpad bug 1464447 in abi-compliance-checker (Ubuntu) "[MIR] abi-compliance-checker" [Critical,Incomplete]
<hallyn> slangasek: hi, bug 1475749, my UDD-foo is a bit stale.  I'll do the merge+package release if you like, but if it's quick for you that's probably safer.
<ubottu> bug 1475749 in shadow (Ubuntu) "usermod --add-subuids fails for users not in /etc/passwd" [High,Triaged] https://launchpad.net/bugs/1475749
<slangasek> hallyn: thanks for the review, I'm happy to land that myself - just wanted the eyeballs
<hallyn> slangasek: awesome, thx - ttyl
<mterry> slangasek, in bug 1464447, you mention that mir-team looking after abi-compliance-checker should be coordinated with bdmurray.  Can do, but what was the intent there?  I might be out of the loop, but does bdmurray usually look after that package?  (he's not in debian/changelog)  Or are you saying that you'd also like foundations team on the loop for those bugs?
<ubottu> bug 1464447 in abi-compliance-checker (Ubuntu) "[MIR] abi-compliance-checker" [Critical,Incomplete] https://launchpad.net/bugs/1464447
<mterry> RAOF, also ^ maybe actually subscribe mir-team to that package
<slangasek> mterry: what needs to be coordinated with bdmurray is when the MIR team signs off on new team subscribers in the MIR process
<slangasek> mterry: otherwise those packages remain "unowned" as far as anyone else knows
<mterry> slangasek, fascinating.  I thought that his tool had some automatic smarts there (like going from zero to one team, as long as that team is an "ubuntu" team or something)
<mterry> bdmurray, I can start poking you when a MIR results in a new team overlooking something.  I have not been doing that for a while!
 * mterry will also add that to our process checklist
<slangasek> mterry: mir-team is not "an ubuntu team", there's no way to detect that
<slangasek> anyway, gap closed - thanks :)
<mterry> slangasek, well I don't know what the definition of 'ubuntu team' would be for the tool -- is there actually an automatic smarts thing there that would pick it up for some teams?
<slangasek> mterry: nope, that's a hardcoded whitelist
<mterry> Hrm
<mterry> Wish I'd known that earlier, lots of packages/teams have slipped through the cracks since we started enforcing a team subscriber then.  ah well.  for the future!
<bdmurray> mterry: I'm gradually reviewing unowned things.
<mterry> bdmurray, cool thanks.  I'm adding a note to our process docs
<bdmurray> mterry: which specific page are you adding the note to?
<mterry> bdmurray, wiki.ubuntu.com/MIRTeam
<doko> kgunn, greyback: please could you follow-up on https://bugs.launchpad.net/ubuntu/+source/abi-compliance-checker/+bug/1464447 (RAOF apparently is offline)
<ubottu> Launchpad bug 1464447 in abi-compliance-checker (Ubuntu) "[MIR] abi-compliance-checker" [Critical,Incomplete]
<kgunn> doko: we're working on mir0.14 release, had a little snafu requiring rebuild so i think it's being reverted for that...
<smoser> hey. i'd like to have #cloud-init logged to http://irclogs.ubuntu.com/
<smoser> how can i do that ? / where do i ask ?
<xnox> infinity: joining DMB meeting in #ubuntu-meeting? =)
<infinity> xnox: S'pose I could.
<slangasek> doko: why is dh-python a runtime dependency of python?
<doko> slangasek, can't see that. could you point out the direct dependency?
<slangasek> doko: what I'm noticing in that dh-python is Task: minimal, which I assumed was via python3; taking a closer look now
<slangasek> doko: the dependency is certainly there in vivid
<slangasek> python3 Depends: dh-python
<slangasek> doko: and also still there in wily
<doko> slangasek, confirmed, will look at it tomorrow
<doko> afk now
<infinity> robert_ancell:
<infinity> Description:
<infinity>  gnome-multi-writer - GNOME MultiWriter
<infinity> robert_ancell: ^-- That may be the worst short description I've seen on a package in a long time.
<Unit193> Well it clearly picks up two pencils and starts writing with its right *and* left hand! ;)
#ubuntu-devel 2015-07-21
<robert_ancell> infinity, heh
<rbasak> doko: reading your email I'm not sure I follow what you want me to do wrt. regular uploads. Are you saying to hold back on them, or upload them to the landing PPA instead?
<doko> rbasak, your choice. however not everything can go straight into the archive (e.g. symbol file changes), so this has to go to the silo, and then you have to keep track of the archive and the ppa for follow-up uploads
<dholbach> good morning
<seb128> hum, no barry around
<seb128> doko, slangasek, do you know if https://launchpad.net/ubuntu/+source/python3-defaults/3.4.3-4ubuntu1 is buggy?
<seb128> it's in wily-proposed and seems to pull python3.5 in and create build issues
<seb128> e.g https://launchpadlibrarian.net/212160353/buildlog_ubuntu-wily-amd64.ubuntu-make_0.9_BUILDING.txt.gz
<seb128> does it mean that python3.5 transition is actually started in wily?
<doko> seb128, welcome to the barry show. he choose to add it to supported and then go to vacation for two weeks
<didrocks> doko: debian/rules is pretty standard, there is nothing forcing to use all python3 versions
<seb128> should we revert that change?
<didrocks> https://github.com/ubuntu/ubuntu-make/blob/master/debian/rules
<doko> seb128, well, could you try to build python3-gi?
<seb128> no change rebuild?
<doko> yes
<doko> and probably it's dependencies
<seb128> but then what's next? it means actually starting that transition in the distro?
<doko> and maybe set up a transition tracker for it
<seb128> where barry email stated he wanted to do that in the ppa
<seb128> well he started in a ppa
<seb128> we might duplicate work there then
<doko> this guy is not a distro guy :-/
<doko> looking at this email
<doko> seb128, didrocks: could you do the no change upload? I'll try to get some feedback until tonight. and maybe we should set up a transition tracker. is there still an old one available?
<doko> Laney, ^^^
<seb128> doko, well, we could, but as said isn't that effectively starting the transition which is already being prepared in the ppa?
<seb128> in which case I feel like we might waste work redoing things that have been prepared by barry there
<didrocks> doko: I'm unsure I want to start the transition before we know if that was intended, I can just change ubuntu-make to dep on python3 instead of python3-all for now instead
<didrocks> especially if we start the transition without being prepared, then, everything will start to be blocked
<doko> well, it apparently is intended. and creating the tracker doesn't hurt
<doko> didrocks, no, adding a supported python version doesn't block anything
<didrocks> doko: well, it did block my package for instance here
<doko> I have enough to do with GCC 5 currently
<didrocks> yeah, so I propose that we don't deal with it, I'm changing my build-dep for now
<didrocks> and we don't start a transition nobody's present being able to handle
<Laney> doko: like this http://bazaar.launchpad.net/~ubuntu-transition-trackers/ubuntu-transition-tracker/configs/view/head:/monitor/old/python3.3-4.ben ?
<Laney> didrocks: if you change X-Python3-Versions it builds BTW
<Laney> : 3.4
<didrocks> Laney: yeah, but I don't want to force on one particular version
<didrocks> Laney: that's just a hassle with each update
<didrocks> better to only dep on python3 instead of python3-all (see my upload)
<Laney> what does changing the build-dep do?
<didrocks> only using the default python3
<Laney> then you have to do something when it changes default?
<doko> Laney, yes, this one. no, has to be -all
<didrocks> there is no (for now) C python module built
<didrocks> Laney: just a rebuild to change the dep
<didrocks> (a non change rebuild)
<Laney> doko: What do you mean by "has to be -all"?
<Laney> doko: do you mean in is_affected?
<Laney> there's also http://bazaar.launchpad.net/~ubuntu-transition-trackers/ubuntu-transition-tracker/configs/view/head:/monitor/old/python3.4_all_dev.ben
<doko> Laney, yes this is the one I want
<doko> the first step
<Laney> do you want to create a branch that I can merge?
<dholbach> If you can: please help with reviewing/sponsoring: http://reqorts.qa.ubuntu.com/reports/sponsoring/
<hjd> From reading https://lists.ubuntu.com/archives/ubuntu-devel/2012-November/036106.html it looks like the armel architecture was removed in raring. So I guess that means that bug 635390 could be resolved as won't fix as suggested in the comment. (The package was removed completely for a couple of releases, and when it was reintroduced in trusty it seems to have built successfully on all architectures)
<ubottu> bug 635390 in crystalspace (Ubuntu) "armel build failure (sync primitives)" [Undecided,Confirmed] https://launchpad.net/bugs/635390
<cjwatson> hjd: done
<hjd> cjwatson: Thanks :)
<doko> mvo, python-apt is broken with your new apt upload to the landing 16 ppa, please could you have a look?
<mdeslaur> @pilot in
* mdeslaur changed the topic of #ubuntu-devel to: Archive: wily open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise -> vivid | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mdeslaur
<roaksoax> /win/win 3
<hallyn> mbiebl: hi, is 'dh_installinit --no-restart-on-upgrade' supposed to work right with systemd?
<hallyn> (the lxc systemd script is being called on package reinstall)
<hallyn> stgraber: tyhicks: I think the lxc container shutdown on upgrade is just a systemd bug...
<hallyn> (or dh_installinit, or whatever is responsible for doing that right)
<hallyn> (or maybe our systemd script has a line in it overriding the --no-restart-on-upgrade, i have no idea)
<hallyn> (and pitti's not around :)
<mdeslaur> @pilot out
<mdeslaur> meh
* mdeslaur changed the topic of #ubuntu-devel to: Archive: wily open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise -> vivid | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<zbenjamin> xnox: ping
<zbenjamin> xnox: i heard you worked on upstart ? didrocks thinks you might be able to give some pointers :D
<zbenjamin> xnox: i try to prototype a preloader to boost application startup time. The problem is the preloaded process does not have the correct PID and Mir rejects my connection
<zbenjamin> xnox: where would be the right place to hack that?
<xnox> zbenjamin: well. what does preloader do? and how do you invoke it?
<xnox> and do you start it via upstart?
<xnox> zbenjamin: what's the output of `ps' for all processes -> pastebin.
<xnox> zbenjamin: and the output of $ initctl status, for the job/process in question.
<xnox> zbenjamin: in practice i bet the problem is that a fork/exec is done, and upstart didn't expect it.
<zbenjamin> xnox: it works like that:   The applauncherd is a daemon that preforks one process that preinits commonly used libraries and QML components. At the time when i want to start a click app i put :   "/usr/bin/invoker --type=qt5 applicationBinary --arg1 --arg2"  into the desktop file
<zbenjamin> xnox: the ual then executes the invoker with requests applauncherd to load the application binary into the preloaded process (using dlopen) which then becomed the application
<zbenjamin> becomes
<zbenjamin> xnox: to the PID of the app that connects to Mir is not expected at all
<zbenjamin> s/to/so
<zbenjamin> so i get ApplicationManager REJECTED connection from app with pid 20469 as it was not launched by upstart, and no desktop_file_hint is specified
<zbenjamin> xnox: https://github.com/nemomobile/mapplauncherd
<xnox> zbenjamin: so pid 20469 is e.g. a pid that applauncherd forked (where e.g. applauncherd is 20468 itself)
<zbenjamin> xnox: yeah
<xnox> zbenjamin: horum. I think you need to (a) somehow communicate to appluancherd who you are (as in which app you are launching, e.g. one way to do that is to pass all environment variables, e.g. UPSTAR_JOB et al)
<zbenjamin> xnox: invoker forwards all env to the preforked process
<xnox> zbenjamin: (b) you will have to do hack up Mir/Application Manager to query applauncherd children in case matches are not found for "normal executed apps"
<zbenjamin> xnox: hm that sounds doable
<xnox> however, you'd need jdstrand input on this. Cause it sounds like a massive security hole. Cause e.g. we can trust the upstart view of the world, but not so much dlopened/preloaded untrusted apps that can totally change their own environment and pretend to be somebody else =/
<xnox> zbenjamin: what is this desktop_file_hint stuff? surely your post-loaded app should be able to tell mir who it is.
<xnox> and/or applauncherd do it in a trusted way.
<zbenjamin> xnox: this is just for profiling atm. I talked to jdstrand already and in case this would boost application startup significantly we can look at secutiry
<zbenjamin> xnox: does not work with desktop_file_hint :(  tried that already
<xnox> e.g. "yo, mir, i'm applaucherd, this pid will be this thing, until crashes.", "yo, mir, this pid is now nothing", "yo, mir, this pid is now calculator."
<zbenjamin> xnox: well every app will have a new pid of course
<xnox> or possibly invoker will have to do that.
<zbenjamin> that can be done yeah
<xnox> zbenjamin: right, but there is no mapping. Previously in normal world, we start upstart job instance per app.
<xnox> and each job instance has pid and variables describing who it is.
<zbenjamin> xnox: hmmm, well invoker lives as long as the app
<xnox> zbenjamin: then invoker should be proxing calls to mir, no? can it open a socket to mir & pass it to the app?
<zbenjamin> hm not sure about that
<xnox> e.g. poor-mans nc -U ;-)
 * ogra_ has seen rich men use nc !
<zbenjamin> xnox: the question is more, how to get that into Qt
<zbenjamin> and will it hurt performance
<xnox> zbenjamin: code in invoker to open mir socket or whatever it is, and then bind another one for the app. Tell the loaded app to use that socket to talk to mir (i think it is environmental variable controllable) and then join the two - that is "into invoker socker, goes to mir socket" and vice versa.
<zbenjamin> oh my :D
<ogra_> always the trivial stuff :)
<zbenjamin> ogra_: yeah thats way too easy ;)
<xnox> zbenjamin: well, look into application manager code and how it queries things from upstart or what not. And/or why it rejects things. And e.g. tweak it to always accept things that look like from your prefork daemon.
<xnox> or make it query the prefork daemon to validate things.
<xnox> zbenjamin: got to go, hope this helps.
<xnox> zbenjamin: i always thought we should support upstart to deserialise arbitrary json into it's state machine. then one would be able to forge stuff as one would like, but alas, we only do that for re-exec =(
<zbenjamin> xnox: :/
<zbenjamin> xnox: thanks for the hints
<zbenjamin> xnox: need to run as well, i'll probably ping you again tomorrow ;)
<bdmurray> Is there a way for me to rerun the wily-adt-apport test without uploading the package again?
<Laney> bdmurray: log in on the 'private' link
<Laney> bdmurray: then click http://d-jenkins.ubuntu-ci:8080/job/wily-adt-apport/ here
<Laney> erm, 'build now' there
<bdmurray> Laney: got it, thanks
#ubuntu-devel 2015-07-22
<teward> bdmurray: ping - can you undo the team subscription done by your patch detection bot?  Sponsoring isn't needed on the given bug (I have upload rights, I"m just waiting for Daviey to sanity-check my diffs because I asked for a second set of eyes)
<teward> (for a given bug)
<teward> i shouldn't have asked, I think Daviey is on the sponsors team... i'll ask him to do the unsubscribe :/
 * teward yawns
<bdmurray> teward: on what but?
<bdmurray> teward: on what bug?
<shiva> hi all , I have a question on pulseaudio ... am in the right channel ?
<TheMuso> shiva: You are probably best asking in #pulseaudio, although the devs are not likely around at the moment.
<shiva> Thanks for the rply
<draos> hello, is there any apply for developer for ubuntu?
<slangasek> TheMuso: hi, it appears your latest speech-dispatcher upload causes brltty to FTBFS - it was buildable June 19 when it was last tried in the pythoneers ppa, now it fails with a libspeechd header error: https://launchpadlibrarian.net/212248803/buildlog_ubuntu-wily-amd64.brltty_5.2~20141018-4ubuntu2_BUILDING.txt.gz
<slangasek> TheMuso: was this on your radar?
<draos> hi is there any "apply for staff" or become an ubuntu developer?
<ScottK> draos: This has some useful links https://wiki.ubuntu.com/UbuntuDevelopers
<draos> thx
<draos> are there any rewards for ubuntu development ?
<LocutusOfBorg1> Hi Folks, is there any process to apply for Ubuntu Membership for a DD?
<LocutusOfBorg1> I see from the sponsorship page I might need to ping dholback, ginggs_ or somebody else, right?
<LocutusOfBorg1> I do not want to create a page if I do not have an endorser :)
 * LocutusOfBorg1 is looking at https://wiki.ubuntu.com/DeveloperMembershipBoard/ApplicationProcess
<seb128> LocutusOfBorg1, I'm unsure the process is different for DDs
<seb128> you are on the right wikipage I think
<seb128> oh, seems like slangasek is starting that python transition after all :-)
 * LocutusOfBorg1 is not yet a DD, missing the account creation, just the key has been uploaded yesterday
<dholbach> good morning
<ari-tczew> hello dholbach
<dholbach> hey ari-tczew
<flexiondotorg> Laney, I see you up for piloting today. May I kindly request you look at this please? - https://bugs.launchpad.net/ubuntu/+bug/1476653
<ubottu> Launchpad bug 1476653 in Ubuntu "[needs-packaging] ubuntu-mate-welcome" [Wishlist,New]
<Laney> flexiondotorg: We'll see, I might end up moving it.
<flexiondotorg> Laney, Moving it?
<Laney> my slot
<flexiondotorg> Ah, OK.
<cjwatson> Laney: could you have a look at agda?  build-deps on old cpphs
<Laney> cjwatson: hm, did that plan not catch that?
<Laney> Seems fixed by upgrading to 2.4.2.3 anyway, will do later on
<cjwatson> Laney: dunno, maybe the plan did but it hasn't been uploaded to match?
<ogra_> infinity, hmm, your live-build upload makes phones explode
<ogra_> infinity, "/bin/sh: 1: /bin/sh: initctl: not found" ... (we use upstart all the way there, on both, vivid and wily)
<ogra_> infinity, bug 1477051 for more details
<ubottu> bug 1477051 in live-build (Ubuntu) "Phones on devel-proposed do not boot - /bin/sh: 1: /bin/sh: initctl: not found" [Critical,Confirmed] https://launchpad.net/bugs/1477051
<xnox> horum. where is piti when you need one
<xnox> stgraber: have you looked into integrating systemd-resolvd (/run/systemd/resolve/resolv.conf) with resolvconf in ubuntu?
<xnox> stgraber: ideally we'd have e.g. lo & eth* things managed by systemd-networkd and the rest elsewhere (e.g. networkmanager for wifi, etc.)
<Laney> on holiday
<doko> apw, did you have a chance to check your regexp theory with schroot?
<doko> infinity, Laney: would it be possible to limit a transition tracker just for main? just would like to know where my priorities should be
<Laney> doko: Not really easy for the main instance. You can s/html/txt/ to get something that you might be able to wrangle with a script...
<Laney> doko: Don't we have to fix everything for it to be able to migrate, though?
<doko> Laney, wishful thinking =) I wanted to check what I minimally need to rebuild to get a desktop login
<doko> I wish I had debian's autoremove tool ...
<Laney> I suppose we could run it a second time, maybe
<Laney> doko: what's going to break the desktop?
<doko> Laney, I don't know yet. the thing is that I didn't even start doing no change uploads for libraries, and for the transitions started there, plus we'll probably have breakage when we rebuild and not rename the library package
<Laney> you mean undetected ABI breaks, I see
<doko> see https://wiki.ubuntu.com/GCC5 for the explicit transitions in the ppa
<doko> yes, see my 400 bug reports for debian ...
<Laney> I have seen your analysis, which is why I wasn't aware that there is a risk of missing some transitions
<doko> right, so we could start these, but then would have to redo things when syncing/merging from debian
<doko> I mean, we could start with the packages which have confirmed transitions
<doko> mvo_, python-apt ping
<teward> bdmurray: sorry for slow response, bed was calling.  https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1476811 is the bug that your foundations bot tagged 'patch' then subbed sponsors to.  It doesn't need sponsors attention though since I have upload rights, it's pending voluntary review by Daviey however for sanitychecking.
<ubottu> Launchpad bug 1476811 in nginx (Ubuntu) "Merge nginx 1.9.3-1 (main) from Debian unstable (main)" [Medium,In progress]
<teward> 'cause i have a tendency to make mistakes when tired :/
<Daviey> teward: I unsubb'd sponsors.
<cjwatson> doko: can I merge python-debian, or do you want to?
<cjwatson> doko: (we need its build profiles support)
<doko> cjwatson, please do, still in GCC 5 only mode ;)
<cjwatson> ok
<cjwatson> I'm in "will I ever escape from fiddly launchpad-buildd bugs" mode
<doko> heh
<Luke> What's the correct behavior for systemd user instances? I've not been able to get them working due to lack of ability to connect to D-Bus. I've heard perhaps user instances are still managed by upstart?
<caribou> If anyone has time, I need a sponsor for the rsyslog merge, bug #1464201
<ubottu> bug 1464201 in rsyslog (Ubuntu) "Please merge rsyslog 8.9.0-3 (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/1464201
<xnox> Luke: we have all three =)
<Luke> xnox: the question is what's the intended use path for user session init system?
<xnox> Luke: pam_systemd starts system user instance for us, which does nothing. As we don't have anything running "there". our Xsession start scripts spawn upstart which start "session" dbus. user systemd has no idea about session dbus.
<xnox> Luke: we have all user sessions managed by upstart since 14.04 or 13.10, can't remember.
<Luke> xnox: what about after the move to systemd in 15.04?
<xnox> Luke: still. we only moved pid1 to systemd, user sessions are still managed by upstart.
<Luke> gotcha. thanks. is that documented anywhere?
<xnox> Luke: moving user session to systemd is blocked by moving phone to systemd as pid1. as that is still using upstart as pid1.
<Luke> are there plans to move user sessions to systemd?
<Luke> gotcha
<xnox> Luke: documented in the release notes and all the systemd/snappy sessions every UOS.
<Luke> UOS
<Luke> ?
<xnox> Luke: and user systemd implies, dbus user session, which at the moment brakes all sorts of upstream things - and not at all tested on e.g. Ubuntu Desktop.
<xnox> Luke: UOS - ubuntu online summit, aka uds but over hangout.s
<Luke> I'm having the same trouble on Debian btw (spun up a VM to see what they do)... they don't have the phone constraint.... is this an upstream issue?
<xnox> Luke: which issue, what constraing, and debian is weird - they don't have any inits in the user sessions as far as I know.
<Luke> also this is Ubuntu server I'm using so there is no Xsession. how should I start a user session upstart then?
<Luke> xnox: ah i see... so debian has never had user session init?
<xnox> Luke: on a server you either have nothing, or systemd user session. You can launch upstart user session, but we don't do that by default. As currently that is only setup for "desktops"
<Luke> aaah gotcha
<xnox> Luke: debian just uses e.g. Xsession.d to track things and e.g. just logind, just policykit, just ssh session leader and some such.
<xnox> not policykit, sorry, consolekit.
<mvo_> doko: thanks, I will try to fix that later today, sorry for the trouble
<Luke> it uses Xsession.d even for non-X environments?
<Luke> xnox: in #ubuntu-server they asked me to file this bug: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1476364
<ubottu> Launchpad bug 1476364 in systemd (Ubuntu) "âsystemd --userâ instance can't find d-bus" [Undecided,New]
<Luke> can you comment on that and close if appropriate?
<Luke> xnox: also, if I'm running a server, it seems the easiest approach may be to just get a user session dbus that my user session systemd can connect to. I used 'systemctl enable-linger myUser' to get the user session in the first place
<xnox> Luke: what are you trying to do or run?
<Luke> I have an app that I want to keep running during certain time periods. it's not a system app i just want it to be managed for me
<xnox> which app?
<xnox> Luke: crontab much?
<Luke> custom
<Luke> cron doesn't do process monitoring
<xnox> Luke: you are already inside vagrant box, are you sure you don't have root already?
<Luke> I do have root on that box. on the deployment boxes I don't want it to run as root
<xnox> Luke: also you can spawn lxc container with full init, as an upriviledged user.
<stgraber> xnox: nope, haven't looked at it. I'm also not really maintaining any of those networking packages nowadays
<Luke> I want a unprivileged user to login to the box and be able to restart the app etc
<Luke> I don't want containers due to network performance reduction
<xnox> stgraber: horum, is pitti doing all of that, or like nobody?
<xnox> Luke: netere is no network penalty if you simply let your containers to run on the host network without any nat/bridges in between, and even then i don't buy the argument of network pentaly.
<Luke> xnox: you don't have to buy it. it's a fact =)
<xnox> Luke: look into using e.g. runit or other lightweight processor supervisioning things that are readilly availble from the archive and usable as user instances.
<Luke> at least as measured in docker
<Luke> docker uses lxc tho underneath right?
<Luke> xnox: i'll check out runit
<xnox> Luke: haha =) docker can use a lot of network setups, by default it's quite crappy. and no, it does not use lxc by default. anyway, you can make docker "on the host network without any nat/bridges in between" with standard daemon args.
<xnox> Luke: thus docker != "slow network"
<Luke> fair enough
<xnox> it can be as good as normal network, your user instance would see.
<Luke> still this all seems like more work than just having a systemd user instance start up
<Luke> runit looks like the same amount of work except I already have the systemd scripts
<xnox> Luke: i'm failing to see what's stopping /you/ from using systemd user instance.
<Luke> xnox: nothing. just making sure i'm going down the right path
<xnox> Luke: it's not provided for you by the distribution, and you will need to add support units yourself to get it up and running, and will have to run user dbus your self, with user dbus units.
<Luke> xnox: basically I was looking to have this exact discussion to explore alternatives with someone more knowledgable than myself
<stgraber> xnox: it's probably split between pitti and cyphermox
<xnox> Luke: all about your problem sounds like the wrong path =)
<xnox> at leat to me.
<Luke> xnox: you'd go w/ lxc?
<xnox> Luke: i'd add policykit rules to allow certain users to execute certain commands with systemctl/systemd e.g. restart, and that's it.
<xnox> and run everything of the system init.
<Luke> ok i've seen that done before as well
<ogra_> policykit ... so advanced ...
<Luke> I think I'll explore doing that. thanks xnox
<ogra_> just allow a sudoers group to do it and add the users to that group
<xnox> Luke: cause you really don't want to maintain a hanging user pam session, with systemd, dbus et.al. running there. which are all disconnected from system upgrades more or less.
<Luke> right
<Luke> which is why I came here in the first place =)
<Luke> xnox: thank you so much. this was an extremely helpful discussion
<teward> Daviey: thank you kindly :)
<infinity> ogra_: Curious.  That doesn't make a whole lot of sense, I'll have to poke at it.
<infinity> ogra_: I assume the latest build of https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/vivid/ubuntu-touch should contain the bug?
<ogra_> infinity, nope, vivid is still in proposed afaik, wily did expose it ...
<ogra_> and seb128 wanted to block the vivid SRU promotion for it
<infinity> ogra_: Oh, right.  wily it is.
<infinity> ogra_: Oh, I think I see the bug.  The initial 'exit 0' is BS.
<infinity> ogra_: Same bug I fixed previous with the upstart-user-sessions patch which I reverted for this due to conflicts.
<infinity> ogra_: Will test a bit and confirm and upload.
<ogra_> yay
<infinity> ogra_: (ie: dba's upstart handling always assumes that system upstart == only upstart)
<ogra_> well, we are kind of unusual with the phones anyway :)
<infinity> Which would actually be true for phones, except your install procedure is "install systemd, then remove it to add upstart". :P
<ogra_> blame pitti for that one :)
<infinity> ogra_: Meh, it was the path of least pain.  Pretty sure I agreed with and/or implemented bits of that plan.
<infinity> ogra_: It's just a bit weird is all. :)
<ogra_> sadly i expect that status to persist til at least the 16.04 cycle
<infinity> ogra_: Anyhow, this logic is equally wrong for the desktop, where we install upstart post-bootstrap, so yeah.  Fixing.
 * ogra_ was hoping we switch to snappy earlier which would give us systemd init 
<infinity> Not sure how I missed that when visually reviewing it.
<ogra_> well, i saw the exit 0 but thought "well, initctl will be there, so no harm"
<ogra_> i didnt think of the bootstrapping with systemd issue :)
<smoser> ok. so... grabbed cd image from
<smoser>  http://cdimage.ubuntu.com/ubuntu/daily-live/20150722/
<smoser> used usb-creator-gtk . said 'Discarded on shutdown'.
<smoser> stick that in a UEFI intel nuc try to boot it.
<smoser> "no operating system"
<smoser> and same thing with
<smoser>  sudo qemu-system-x86_64 --drive if=virtio,file=/dev/sdb,format=raw
<infinity> smoser: I'd guess there's a bug about that already, but I'd think that's expected, since usb-creator remasters images with syslinux, which only works on BIOS.
<infinity> smoser: dd is the best way to get a hybrid image written to USB.
<smoser> well, didnt work with qemu above either (which does not use uefi)
<smoser> which is why i did it.
<infinity> smoser: Okay, the second bit is more potentially irksome. :P
<infinity> usb-creator is kinda dead (ie: no upstream, no real activity); patches welcome. :/
<smoser> im' good with dd. just need some path.
<smoser> and almost all doc i suspect points to it.
<infinity> I think the best patch would be for it to just fork 'dd' if you don't ask for it to do fancy things like persistent partitions.
<smoser> or maybe my reading of such things is justold.
<smoser> but man...
<smoser>  sudo dd if=/tmp/wily-desktop-amd64.iso  of=/dev/sdb
<smoser> that is just scary :)
<infinity> smoser: A lot of docs point to it since it's the only GUI tool we ship for this.  Which is a solid argument for fixing it.  It just never seems to be a priority for anyone. :/
<infinity> smoser: And yeah, dd is scary.  I tend to triple-check dmesg and /proc/partitions before I have the cajones to hit <enter> :P
<infinity> "Are you sure that's your USB stick?  No, really, are you SURE?"
<smoser> (and i just freaked out a bit after having hit enter)
<doko> xnox, updated the boost1.58 packages. the one python upstream patch breaks the build, but it's only needed for 3.3 anymore. so maybe time to upload to experimental too
<infinity> smoser: If you don't want it to take forever, you might want to up the block size to 1M or 4M or something.  USB isn't known for its speed with small block sizes (too much back and forth over a slow and chatty protocol)
<xnox> doko: so you didn't merge from debian, how ubuntu of you ;-)
<xnox> doko: https://tracker.debian.org/pkg/boost1.58
<xnox> doko: http://metadata.ftp-master.debian.org/changelogs//main/b/boost1.58/boost1.58_1.58.0+dfsg-1_changelog
<xnox> doko: only took the 0002-Fix-a-regression-with-non-constexpr-types.patch from erratra, didn't take the python one.
<doko> xnox, sorry, didn't see it. did you include the arm64 patch?
<xnox> doko: * Don't call the compiler with -m{32,64} explicitly.
<xnox> doko: credit to you, if that's the one.
<doko> xnox, no the one from fedora
<xnox> didn't.
<smoser> is here a password set on the isos ? X isnt working for some reason, and alt-f1 / tty1 has a login prompt
<tjaalton> no, uid is ubuntu
<smoser> i thought in the past maybe theree was just a prompt there?
<tjaalton> maybe
<tarpman> IIRC that changed with the switch to systemd
<bdmurray> teward: If you were a member of ubuntu-dev then ubuntu-sponsors would not have been subscribed.
<teward> bdmurray: ack.
<teward> bdmurray: i'm not, obviously, a member of ubuntu-dev.
<teward> but that explains why the bot did what it did :)
<Daviey> bdmurray: If teward has PPU upload access, shouldn't he be a member of ~ubuntu-dev?
<bdmurray> Daviey: I'd think so, I'm looking into it.
<teward> great, another nondeterministic build failure
<teward> "dpkg-gencontrol: error: cannot read dhstrip-dummy-debian-files: No such file or directory" https://launchpadlibrarian.net/212318997/buildlog_ubuntu-wily-armhf.nginx_1.9.3-1ubuntu1_BUILDING.txt.gz
<teward> and all the others built fine >.>
<infinity> teward: pkg-create-dbgsym might not be parallel safe.
<infinity> teward: And your rules file is clearly running them in parallel.
<infinity> Though, why that raced unluckily on only one arch is curious.
<teward> infinity: happened before
<teward> infinity: and that's Debian's handiwork, not mine.
<teward> infinity: i've seen one of these build failures before
<teward> iirc it's always on arm it fails
<infinity> teward: I bet it would clear up if you take out the nasty DEB_BUILD_OPTIONS -> MAKEFLAGS business and instead call dh with --parallel
<teward> typically seen a rebuild 'work'
<teward> mmm, probably
<teward> i'll look into it, but i've only seen this race fail once every few uploads *shrugs*
<teward> first, lunch, coffee, a 5-hour energy, and then to figure out why my mailserver stopped relaying mail :/
<infinity> teward: Yeah.  But it's clearly a parallel race, and "dh --parallel" only calls the underlying build system with -j, while "MAKEFLAGS = -j4" will run the entirety of debian/rules parallel.
<infinity> teward: Not that this isn't also a bug in pkg-create-dbgsym, mind you.  We probably need some better locking and serialising there to deal with this.
<teward> mhm
<rbasak> infinity, doko: OK to retask bug 1453133 to gcc? I don't think there's anything to do in docker.io or go-md2man now.
<ubottu> bug 1453133 in docker.io (Ubuntu) "[Ubuntu 14.04.3] Backport docker 1.5 to Ubuntu 14.04 on ppc64el" [Undecided,New] https://launchpad.net/bugs/1453133
<infinity> rbasak: It was previously a generic "Ubuntu" task before one of your team reassigned it to docker. :P
<infinity> rbasak: And generic Ubuntu seems right, since it would require a gcc backport package or similar evil.  It's not just a "please fix a bug in gcc" thing.
<rbasak> infinity: bugsquad triager, not server team
<rbasak> I'll move it back to Ubuntu then I guess.
<infinity> rbasak: We should discuss it with IBM, probably, and settle on wontfix to not get their hopes up, but I'll bring that up with them in the next call.
<infinity> rbasak: But yes, from a docker perspective, you've done all you can do.  If the right GCC bits existed, your packages would just magically work.
<rbasak> infinity: ack. I don't really expect it to happen either.
<infinity> rbasak: With 16.04 "around the corner" (at least, at the speed that "Enterprise" people move, it may as well be tomorrow), I think we can probably convince people that just waiting for the next LTS will have to do.  Or they can pay us big money to clone doko.
<rbasak> I find it a bit silly really.
<rbasak> "We must use the LTS because it's stable" but also "We must change the LTS so people can use this extra new shiny stuff".
<infinity> rbasak: I don't find the request silly.  Their goal is feature parity with x86, and their target market doesn't want releases with 9mo support.  But that doesn't mean we don't get to put our foot down when a request just isn't serviceable.
<rbasak> The issue I have with it is that they want it in yesterday's release rather than tomorrow's release. But anyway, yes, it's not as simple as that.
<infinity> rbasak: And it *could* be done without destabilising the LTS, with a careful backported compiler with a different name and a private libgcc1, etc, etc.  But that's a lot of work that our contract doesn't cover, and there's only so much time we have to spend being "nice" to people who can afford to pay instead of ask for favours. :)
<rbasak> I'd like to see "third party overlays" to work better than PPAs. So Snappy I guess.
<infinity> rbasak: snappy isn't exactly a magic bullet here.  The fundamentals are still the same, in that you need a new toolchain, and some human has to maintain that.
<rbasak> Snappy would make all this Docker and Juju backporting pain go away quite nicely, and in a way that I think everyone would be happy with.
<rbasak> You could use Vivid's toolchain.
<rbasak> But target Trusty.
<infinity> rbasak: The naive "app store" model where people just throw random bits at users and don't care about bugs, sure, that "solves" it, but not in any way I'd want to sell to a customer like IBM.
<rbasak> The model is basically exactly how users consume Docker today.
<rbasak> Or any other third party publishing an apt repository
<rbasak> Many of them build binary packages directly with no "source package" (though obviously they have a source)
<rbasak> See fpm, etc.
<infinity> rbasak: Yes.  And early adopters of docker are the sorts of cowboys who don't care about security.  That's going to change.  And we need to be ready to do it right, IMO.
<rbasak> I think Snappy could still solve that, with a layer on top for reproducible builds, etc.
<rbasak> (a build-time tooling layer, that is)
<infinity> rbasak: ie: They don't care if they statically link a libc that hasn't had an update in 3 years, cause that's their build chroot, and who cares.  When people who aren't github cowboys adopt this sort of model, things will change.  They have to.
<cjwatson> You can use vivid's toolchain for a trusty PPA, too, if you don't care about it being self-contained - snappy ~= PPAs for this purpose
<cjwatson> Although you'd have to statically link libgcc1 or something
<rbasak> But PPAs are hacky in, for example, managing the namespace.
<rbasak> (both package namespace and filesystem namespace)
<rbasak> They all collide with each other.
<rbasak> If we want third parties to be able to independently publish stuff, then giving them separate namespaces for everything would work better.
<infinity> rbasak: Oh, I'm not saying the appstore/snappy model doesn't solve SOME problems.  It does.
<rbasak> And no need to give them root.
<infinity> rbasak: It absolutely does.
<infinity> rbasak: But it's not a magic bullet for maintaining code.  The idea that we can just stop caring about bug fixes for software *we* produce (ie: the toolchain) is a bit lolz.
<rbasak> I don't think anyone's saying that.
<infinity> rbasak: docker users do.  At least, that's the usual model.
<infinity> rbasak: docker users treat containers as black box blobs they don't tend to have to care about.  And snappy is in danger of that same sort of usage, so we need to be careful, that's all.
<rbasak> I think that all we can really do is document (and follow) best practice.
<infinity> rbasak: Yeah.  The "and follow" bit is the important part.  snaps we produce, or docker images we provide, or any such thing that comes from us, needs to follow our classic distro support model and lead by example.
<infinity> rbasak: Other people can produce crap, and that's unfortunate, but we need to show people there's a right way.
<rbasak> Agreed
<ricotz> infinity, hi, can you trigger a retry of https://launchpad.net/ubuntu/+source/x264/2:0.146.2538+git121396c-3 ?
<infinity> ricotz: Done.
<infinity> ricotz: Well, attempted...
<infinity> ricotz: Oh.  It breaks horribly because sbuild doesn't support filtering out <profiles> .... Except it should.  Hrm.
<infinity> Oh.  No, that probably needs backporting.  Grr.
<ricotz> infinity, ah, I see (pbuilder does it fine)
<infinity> ricotz: sbuild does it fine in wily too.
<ricotz> and the builders are trusty ;)
<infinity> ricotz: It's that the buildds are trusty (and some precise), and they don't grok the syntax.
<infinity> cjwatson: Meh, I don't just need apt/python-apt backports for profiles, I also need a libdpkg-perl mangling, I think.  Time to find some Free Time.
<infinity> ricotz: The simplest thing for now would be to introduce an Ubuntu delta that strips the <profile> bits, but we obviously need to fix this on the infra side Very Soon.
<cjwatson> We do
<ricotz> infinity, ok, except for the gpac and ffmpeg transition there is no hurry for that build
<ricotz> on that thought, there is a ffmpeg transition taken care of?
<Gallomimia> hi everyone. i'm really annoyed by the following message: http://pastebin.com/fRuGxjeh it is found in thunderbird upon launching, and it really bothers me to learn that there's a nightly build installed of software i use. without my permission or foreknowledge
<sarnold> Gallomimia: apparently that just means mozilla folks haven't written the introduction page for that release yet
<sarnold> Gallomimia: if you'd like to follow the progress, the bug is https://bugzilla.mozilla.org/show_bug.cgi?id=1186390
<ubottu> Mozilla bug 1186390 in Thunderbird ""Welcome to Daily!" message in thunderbird 31.8.0" [Normal,Unconfirmed]
<Gallomimia> typical. sorry for assuming it's package maintainers ><
<hjd> sarnold: Neat. :) Do you think you could link that with bug 1476805?
<ubottu> bug 1476805 in thunderbird (Ubuntu) "Thunderbird says it's Daily" [Undecided,Confirmed] https://launchpad.net/bugs/1476805
<sarnold> hjd: let me try :)
<hjd> (don't know if Launchpad supports bug watches for bugzilla...)
<sarnold> hjd: looks like the link worked :)
<hjd> sarnold: :)
<Guest91863> guys remember the old ubuntu 9.10 theme. i love it a lot. my project is to get that old and light interface to ubuntu 14.04 and make an new ubuntu for old pc's with the classic theme :))
<sarnold> Guest91863: investigate MATE and Cinnamon, I think one of those may be what you want
<Guest91863> yes but the old theme is pretty cool :)
<Guest91863> do canonal give rewards for ubuntu developers ?
<teward> 'rewards'?
<flexiondotorg> cyphermox, Yo. It's been a while. o/
<cyphermox> flexiondotorg: hey!
<flexiondotorg> cyphermox, I've been busy with stuff. But I did a fresh install of Ubuntu MATE 15.10 daily today.
<flexiondotorg> cyphermox, I can see the foundations team have been busy :-D
<Guest91863> yes rewards
<teward> Guest91863: contributing to the overall usefulness and betterment of the Ubuntu operating system isn't a reward in itself?
<Guest91863> yes but tings from canonal store like notebook or pen
 * lamont has an ifup question...  I currently have this in /etc/network/interfaces (albeit with a slightly different non-1918 IP): http://paste.ubuntu.com/11922261/ -- I'm pondering whether or not a 'src' option would be a good thing for /e/n/i to grow
<Guest91863> i can see the ubuntu cursor in the boot screen when booting ?!?!?!???!?
<Luke> xnox: do you have any good polkit config examples for systemctl service management?
<cyphermox> flexiondotorg: tbh I'm not sure what would look different right now, I'm busy with multipath :)
<flexiondotorg> cyphermox, Well VirtualBox does hang on restart after install and eject media works too.
<sarnold> lamont: /etc/network/interfaces feels pretty archaic these days, doesn't it? multiple IPs ought to be better supported, that's just so common these days. src would make sense to me too..
<flexiondotorg> cyphermox, And the virtualbox drivers now install again from software-properties :-)
<cyphermox> that's good
<lamont> sarnold: true
<flexiondotorg> cyphermox, Yep. For people testing that is 2 less QA trackers I'll get next week with Alpha 2.
<infinity> sarnold: How should multiple IPs be "better" supported?  Seems well supported to me.
<flexiondotorg> infinity, I'd agree with that I just equipped a new aircraft with a device running Ubuntu and 16 ethernet interfaces.
<sarnold> infinity: afaik the way to do it is to specify one address via 'address', and then additional addresses via 'up ip addr add ...'
<sarnold> infinity: I know I've spent some time reading the manpages to figure out if there's a way to specify multiple 'address' lines, and folks have asked in #ubuntu-server about it, and always seem slightly dissapointed when the answer is 'use up ip addr ...'
<infinity> sarnold: Oh, I just add "iface eth0:0", "iface eth0:1", etc.
<sarnold> infinity: heh, that method of interface aliasing has been deprecated for over fifteen years now :) one of these days it's really going to go away! I'm sure of it!
<infinity> sarnold: Un huh.
<sarnold> infinity: while I've got an open wishlist going, it'd also be nice if /etc/network/interfaces could allow you to specify tc limits in human-friendly ways :)
<cyphermox> sarnold: https://wiki.debian.org/fr/NetworkConfiguration#Adresses_IP_multiples_pour_une_interface
<cyphermox> I know it's in french, but it documents just adding the extra IPs in separate stanzas
<cyphermox> I'd like to believe it works :)
<cyphermox> (scroll to the end)
<sarnold> cyphermox: oh! interesting
<cyphermox> let me know if it works, it's a pretty cool trick that probably should make it to the manpage
<cyphermox> (as so is 'up blah')
<teward> cyphermox: that method would work, so would manual addition with ip addr add ..
<teward> (i have that for one of my odd setups)
<cyphermox> ok
<teward> (some VPSes have that approach too)
<cyphermox> then it's just a matter of opening a bug in debian to suggest adding a note that this works to the manpage
<teward> i haven't tested it on a recent one, perhaps I should
<teward> then get back to you
<teward> or sarnold can test it
<teward> (last server i did this on i haven't modified for a year and a half, and it's 12.04)
<cyphermox> fwiw, it's in /usr/share/doc/ifupdown/examples/network-interfaces.gz too
<flexiondotorg> Is there anyone out there who is thinking to themselves "I'd really love to sponsor an upload for Ubuntu MATE this evening?" ;-)
<cyphermox> flexiondotorg: what do you want sponsored?
<flexiondotorg> cyphermox, Well a few things, but this is the most important - https://bugs.launchpad.net/ubuntu/+bug/1476653
<ubottu> Launchpad bug 1476653 in Ubuntu "[needs-packaging] ubuntu-mate-welcome" [Wishlist,New]
<flexiondotorg> cyphermox, I'd like it in for Alpha 2, which is fast approaching.
<cyphermox> welcome wizard?
<flexiondotorg> cyphermox, Yep, that sort of thing.
<cyphermox> I know this is an evil idea, but depending on what it does, have you considered making it very generic and shipping customization bits for it, so that others could possibly reuse the code?
<flexiondotorg> cyphermox, This is what it looks like - http://i.imgur.com/PRmBDxK.png
<flexiondotorg> cyphermox, Right now, it is the "simplest thing possible".
<cyphermox> yep
<flexiondotorg> cyphermox, In a future version I'd like to make the content from templates so it is more reusable. But I need something to get banged on.
<cyphermox> sure
<flexiondotorg> cyphermox, That said, I has been well tested by about 20 people. So what it does now, works.
<flexiondotorg> cyphermox, And the code I used is derived from Antergos, which was derived from Manjaro, which was derived from Korora. So it has a rich history of reuse :-)
<cyphermox> flexiondotorg: by my reading, ubuntu-mate-welcome is the only file that is GPL-3, not GPL-2+
<cyphermox> (aside from the others under MIT or whatnot)
<flexiondotorg> cyphermox, Err, let me double check that.
<flexiondotorg> Hmmm, yes. The header would agree with that. I based my licensing on the COPYING file I inherited when I forked it.
<flexiondotorg> Cydrobolt, Which is GPL-2.
<flexiondotorg> cyphermox, How to proceed? Update copyright and resubmit tarball?
<flexiondotorg> cyphermox, A quick bit of code archeology show this confusion was introduced in the fork before mine, Antergos.
<flexiondotorg> cyphermox, The code ubuntu-mate-welcome is derived from has always been GPL-3.
<cyphermox> yes
<cyphermox> just update debian/copyright
<flexiondotorg> cyphermox, So, update copyright and resubmit the tarball?
<cyphermox> if you attached a source package to the bug, yes
<Noskcaj> It seems the gcc5 version of ilmbase has broken the gegl build, can someone please explain how i can fix this?
<flexiondotorg> cyphermox, Change pushed to git. Files on LP bug have been replaced :-)
<Noskcaj> forgot to link https://launchpadlibrarian.net/212351937/buildlog_ubuntu-wily-amd64.gegl_0.3.0-2ubuntu2~gcc5.1_BUILDING.txt.gz
<TheMuso> slangasek: No, thanks for the heads up, will chase up.
<Logan> doko: the python2.7 packaging is making me very sad
<Logan> http://bazaar.launchpad.net/~ubuntu-branches/debian/sid/python2.7/sid/view/head:/debian/rules#L393
<Logan> it's using a README as a source of truth for what extensions are compiled into the binary
<doko> Logan, so what's wrong?
<Logan> I'm not sure how you don't see what's wrong with that
<Logan> I spent a long time trying to figure out why datetime was compiled into the binary as an extension
<Logan> only to figure out that the rules file is awking the README for lines ending in extension and then compiling them in
<doko> so you want me to rename that file?
<Logan> that would probably make sense
<doko> and what do you gain?
<Logan> the problem is that I pushed a new version to production servers and everything broke, and there was no mention in the changelog of this happening
<doko> apparently nothing broke within the distro
<Logan> we have virtualenvs that were built already that were looking for the datetime.so and couldn't find it after the upgrade
<doko> not my problem
<Logan> alright, thanks
<doko> please don't misunderstand me, but virtualenvs really have issues when you upgrade the underlaying python interpreter. however this is a problem that should be addressed upstream
<doko> I'm just surprised that you see this with the datetime.so module, because that should be built as a builtin at anytime
<Logan> we were running a version before that was a built-in
<doko> was that an upgrade across major python versions?
<Logan> no, minor
<Logan> to be fair, it was a very old version
<Logan> so it's not exactly a supported upgrade path
<Logan> but I would really recommend not calling that a README.in to show that it's not only changing documentation
<Logan> I had done a debdiff and thought that change was inconsequential since nothing related to datetime had changed in the rules
<doko> well, the reason for that is to have one source, and document it
<Logan> understood
<Logan> sorry, I really appreciate the work you've done on this package
<Logan> just wanted to let you know what happened so that maybe there could be more clarification in the packaging about what is a source of truth
<doko> I shouldn't be that sloppy with changelogs ... but if you have any ideas how to document the state of virtualenvs and what might happen, that would be nice. however that should be done as a wiki page, and then be referenced
<mwhudson> infinity, doko: so can you tell me about the debian/patches/016-armhf-elf-header.patch in the go packaging
<infinity> mwhudson: Maybe.  It's been a while.
<doko> golang?
<mwhudson> this seems to make go built on armhf (vs armel?) produce binaries that claim to adhere to the hardfloat abi
<mwhudson> doko: yes
<infinity> mwhudson: Was that the one where I fixed their braindead linker to behave like bfd?
<mwhudson> infinity: maybe? your name is on it
<infinity> mwhudson: Right, sounds like that's the one.
<infinity> mwhudson: So, what needs explaining?
<mwhudson> infinity: well that code is in Go now, so some stuff needs to change, but i'm not sure what relly
<mwhudson> infinity: well, what bad things happen without it?
<infinity> mwhudson: They wrong a linker in Go?
<mwhudson> go -> go calls don't really follow the platform abi at all
<mwhudson> so this must be about c<->go stuff
<mwhudson> infinity: there is no c code in the golang distribution any more
<infinity> mwhudson: It's self-hosting?
<mwhudson> yep
<infinity> How does one bootstrap it?
<mwhudson> go 1.4 or gccgo
<infinity> Huh.  The lack of bug ref is annoying.
<infinity> I blame myself.
<doko> hmpff, no, go 1.4 is no option for some archs
<infinity> But there was definitely a bug being fixed. :P
<mwhudson> doko: so, gccgo!
<mwhudson> it's even officially recommended in the docs
<mwhudson> (because i wrote a doc patch...)
<doko> I saw
<infinity> mwhudson: https://bugs.launchpad.net/ubuntu/+source/golang/+bug/1187722
<ubottu> Launchpad bug 1187722 in golang (Ubuntu) "dpkg-shlibdeps fails on armhf ELF binaries that do not define architecture specific information" [High,Fix released]
<mwhudson> infinity: my brain hurts already
<infinity> mwhudson: So, the real "bug" is that we (Debian and Ubuntu) insist on differentiating between hf and sf, while most people only ever build for one target or the other, so don't give a crap.
<infinity> mwhudson: But, since we do care about the difference, we need to tag binaries correctly.
<mwhudson>  yeah
<infinity> mwhudson: gcc, glibc, and binutils upstream all abide by this.
<mwhudson> man
<mwhudson> i can sort of see why go has its own linker
<infinity> mwhudson: The crap linker that golang cargo-culted from some ancient bsd fork didn't. :P
<mwhudson> but i wish they wouldn't bother when linking against system libraries
<infinity> mwhudson: And I somehow doubt it's improved since they rewrote it.
<infinity> mwhudson: Incidentally, the reason I never upstreamed this is because it's fundamentally not upstreamable in its current form.
<mwhudson> upstream would (and hey, i see did) object because it's too much influence from the build environment
<infinity> mwhudson: It assumes build arch == host arch, which is a false assumption in golang, I believe?
<mwhudson> right
<infinity> mwhudson: It should actually be testing the target arch, not ifdef'd at build time like I did.
<mwhudson> also i think someone about 5 years ago thought arch was a simple concept :)
<infinity> mwhudson: But, if it were to test the target arch for hard-floatiness, this is conceptually correct to upstream.
<mwhudson> yes
<mwhudson> there is a GOARM knob
<mwhudson> which is set to 5,6,7 to indicate armvX
<mwhudson> and maaaaybe GOARM==7 implies hardfloatiness?
<infinity> It wouldn't.
<mwhudson> it's one of those "sort of related but not really" things
<mwhudson> the reason i care about this today is i want to do some rebuild testing
<mwhudson> and i think for those purposes i can just set the flags to hardfloaty because that's what we actually want always on ubuntu
<infinity> For all I know, golang isn't hf at all (as in, maybe it doesn't use vfp registers), or maybe it's selctively hf if a vfp exists.
<infinity> But what matters is the floatiness of the C bits its linking against.
<infinity> It's entirely possible to write float-agnostic binaries that do all this at runtime.  Only crazy people do, mind you.
<infinity> My guess is golang doesn't.
<infinity> And should actually tag what they really are.
<infinity> But meh.
<mwhudson> is that what the bit in the flag means thought?
<infinity> mwhudson: But yes, for Ubuntu, you can probably get away with ARM == ARMhf for now.  We've been basically that incorrect for years, and no one's complained.
<mwhudson> i thought soft float hard float was more "do float args go in registers"
<infinity> mwhudson: The bit in the flag means "uses vfp registers" or "not".
<infinity> mwhudson: Err, for args, yeah.
<infinity> mwhudson: I was shorthanding.
<mwhudson> $CC -dumpmachine | grep armhf ? >:)
<mwhudson> er gnueabihf rather
 * mwhudson looks gingerly at the horror that is aarch32 codegen
<infinity> mwhudson: Anyhow, I don't speak Go, so I doubt I'd be much help forward-porting the patch, but I'd like to think it'll be trivial.  If you can find the right bit to fix in the first place. :/
<infinity> mwhudson: But it would be a nice bonus if you could sort out how to do it in a correctly upstreamable way, so we can forget about it.
<infinity> (I'd forgotten about it, cause I never thought anyone would be silly enough to rewrite a linker twice)
<mwhudson> infinity: so the issue is something like: if linking against system libraries, then the tag needs to match the system libraries
<infinity> Especially not with two very good linkers already available to them...
<infinity> mwhudson: Well, no.  And yes.  And maybe.
<infinity> mwhudson: Really, the flag should represent what the binary is.  And the binary should only be linked against libraries of the same sort.
<infinity> mwhudson: Because ld.so wants those things to be true.
<mwhudson> infinity: if the binary is static, the flag is close to meaningless
<mwhudson> surely
<infinity> mwhudson: It lets you get away with untagged linking to tagged for backward compat, but that's Not Right.
<infinity> mwhudson: Not all Go binaries are static, thus the tag needs to be correct sometimes, so just make it correct always? :P
 * mwhudson looks for arm c/go glue code
<mwhudson> infinity: well yeah
<infinity> mwhudson: In our case, we want it correct always, because we look at it for other reasons.
<mwhudson> er er
<mwhudson> is this flag set in relocatable object (.o) files?
<mwhudson> yes looks like it
<infinity> Well, sort of?
<mwhudson> when using cgo the (go) linker reads some files that have been compiled with the system compiler
<infinity> It's not generally correct.
<mwhudson> and istm that the flags on the binary must match the flags from those files
<mwhudson> as it's those files that contain the calls to the system libs
<mwhudson> that might be overthinking tho
<mwhudson> i'm now actually wondering if using cgo to call a c function with a float arg works at all :-)
<mwhudson> (on arm)
<mwhudson> oh hey upstream bug https://github.com/golang/go/issues/7094
<mwhudson> comment 3 is basically what i would write :)
<infinity> Yeah.
<infinity> So, trusting intermediate objects to have sane headers will fail you.
<infinity> Random example I had lying around on my filesystem...
<mwhudson>   Flags:                             0x5000000, Version5 EABI
<mwhudson> thanks gcc
<infinity> http://paste.ubuntu.com/11923048/
<infinity> Exactly.
<infinity> Perhaps gcc also wants to be fixed here.  But binutils is the only thing I know of that's doing the correct tagging.
<infinity> Which is fine, cause we always link with ld.
<infinity> Except when lolgo.
<mwhudson> so +1 for thinking, minus several million for execution
<mwhudson> well yeah, that's the other suggestion from minux: force external linking
<mwhudson> (gospeak for "make a .o file and feed it to ld")
<infinity> mwhudson: Honestly, I'd be more comfortable with "always use bfd on *all* linux arches", cause I don't trusty anyone to write linkers.
<infinity> mwhudson: But meh.  Fixing the Go linker to be sane probably makes sense.
<infinity> s/trusty/trust/
<infinity> That release completely ruined my ability to type 'trust'
<mwhudson> i don't trust the bfd authors either :-) but yeah
<mwhudson> did you know -Bsymbolic-functions doesn't work on armhf?
<infinity> Isn't that documented?
<infinity> Something along those lines is, I thought.
<mwhudson> no, it's just a bug
<mwhudson> well maybe it's a documented bug i dunno
<mwhudson> oh right, it's only with function pointers, not function calls: https://sourceware.org/bugzilla/show_bug.cgi?id=18646
<ubottu> sourceware.org bug 18646 in ld "function pointer values are still interposed with -Bsymbolic-functions on ARM" [Normal,New]
 * mwhudson waits for clang to install in his armhf chroot
#ubuntu-devel 2015-07-23
<mwhudson> sigh, i guess "ubuntu dev wants to get things done" "debian dev wants to play with new shiny" is a common thing?
<mwhudson> infinity: i said this upstream, lmk if it sounds insane: https://github.com/golang/go/issues/7094#issuecomment-123911439
<infinity> mwhudson: That's true, ish.  Except guess who thinks "gnueabihf" is "icky" and, thus, their GNU triplet doesn't match upstream?
<infinity> mwhudson: (hint: RedHat)
<mwhudson> infinity: oh god
<mwhudson> what does theirs say?
<infinity> mwhudson: Unless they've repented (would be nice to check a recent Fedora build), they were encoding it in the machine type instead, ie: armv7hl-linux-gnueabi
<infinity> mwhudson: Which I told them repeatedly was ridiculous, since armv7l, the kernel machine type, can run both sf and hf binaries.
<infinity> mwhudson: But... Whee?
<mwhudson> argl
<mwhudson> well how about i fix it for sensible systems and we see who complains
<infinity> Sure.
<infinity> doko: Does https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1477350 look familiar?  It broke in a security update, so I've poked sbeattie, but if you have any ideas, yay.
<ubottu> Launchpad bug 1477350 in binutils (Ubuntu Precise) "Rgression building sbsigntool with binutils >= 2.22-6ubuntu1.2 in precise" [Undecided,New]
<dragos> hi i want to make an custom ubuntu but i have an problem. how can i modify the installer menu like this one : http://listthemout.com/wp-content/uploads/2011/04/install-ubuntu.png
<dragos> help me
<sarnold> dragos: it's an awkward time; .us is done for the day, europe isn't awake yet
<dragos> im in europe and im awake
<Unit193> sarnold: So which one are you?
<sarnold> Unit193: .us, west coast.. trying to put in another hour or two to get infinity off my back :)
<sarnold> Unit193: how about you?
<Unit193> Hah, nice!  And East coast, Ohio.
<dragos> im europe, romania
<sarnold> o! hi o!
<dragos> im in europe, romania
<sarnold> dragos: cool :D
<dragos> what?
<sarnold> dragos: romania looks beautiful
<Unit193> I got it. :P
<dragos> i know
<dragos> if you look on the map it looks like a fish :D
<sarnold> Unit193: sorry. my parents went to ohio state university, some things are ingrained deep :)
<Unit193> Aha!  Nice, and yeah, shout "OH" and someone will complete it. :P
 * sarnold tries something else
<sarnold> The Stars At Night, And Big And Bright!
<dragos> the sun
<dragos> sweet dreams every1
<dragos> bye
<dragos> im back
<sarnold> welcome back :)
<dragos> i just installed the newest security updates to ubuntu 10.10
<sarnold> dragos: note that 10.10 hasn't been supported for three years: https://wiki.ubuntu.com/Releases
<dragos> i know but im aking it suported
<dragos> i know but im making it suported
<dragos> hi
<dragos> who remembers the ubuntu version "the perfect 10" or 10.10 ?
<Noskcaj> Can someone please retry gimp in wily?
<Noskcaj> The missing build-dep should be fixed by the new version of gegl
<dragos> wily is ubuntu 15.04 or 15.10
<Noskcaj> grimble_, 15.10
<Noskcaj> oops, dragos ^
<dragos> i have wily and and imp works like a charm
<dragos> i have wily and and gimp works like a charm
<didrocks> Noskcaj: done on amd64, let's see the result before kicking the others
<Noskcaj> didrocks, ok. It will at least get further, since the build failure was from a missing dep in the gegl dev package
<Noskcaj> dragos, This is for a version of gimp patched to work with the new gegl
<dragos> who remembers ubuntu 10.10?
<dragos> how can send an email to canonical ?
<didrocks> dragos: http://www.canonical.com/about, look for "contact us"
<didrocks> Noskcaj: amd64 successfully built! starting the other archs
<dragos> thx m8
<Noskcaj> ty didrocks
<didrocks> yw
<dragos> i have the biggest project EVER
<dholbach> good morning
<dragos> good morning
<jhenke> hi folks. The recent 8.1 release of ownCloud server does not allow owncloud-client < 1.7 to sync files. I have filed bug 1477421 about this. Would you consider backporting owncloud-client from wily to odler releases to make it work again?
<ubottu> bug 1477421 in owncloud-client (Ubuntu) "ownCloud-client < 1.7 can no longer sync with ownCloud Server 8.1 and above" [Undecided,New] https://launchpad.net/bugs/1477421
<dbarth__> o/ hey there trainguards, i'm looking for a silo for line 66
<sil2100> dbarth__: on it
<cjwatson> dbarth__: (you wanted #ubuntu-ci-eng BTW)
<flexiondotorg> ogra_, I see you are piloting today. May I kindly request you look at Ubuntu MATE packages please?
<jhenke> anybody able to look into the issue I posted above?
<dbarth__> oops wrong channel indeed
<Laney> doko: you synced libvpx, which caused a transition - are you going to look at the rebuilds? :)
<jhenke> hi, anybody able to look into bug 1477421? With the recent 8.1 release of ownCloud upstream requries owncloud-client to be at least 1.7, which currently only is true for wily. They dropped support for older version due to "technical difficulties". Is there a chance to backport the 1.8.1 client from wily to older releases to make it work out of the box with recent ownCloud server isntallations again?
<ubottu> bug 1477421 in owncloud-client (Ubuntu) "ownCloud-client < 1.7 can no longer sync with ownCloud Server 8.1 and above" [Undecided,New] https://launchpad.net/bugs/1477421
<rbasak> jhenke: https://wiki.ubuntu.com/UbuntuBackports is the straightforward option. If you want an SRU then you'll need to get approval from the SRU team specifically, or quite possibly the Technical Board as it's a major version bump.
<seb128> jhenke, you already asked earlier, and I already replied on #ubuntu-desktop that it makes sense, unsure what else you are looking for there
<rbasak> (and agreed - it makes sense, but it will need an exception granted from the appropriate team)
<jhenke> seb128 you said #ubuntu-desktop would not be the right place, so I was hoping this is the right place to rais this issue with someone who has the chance to work on it
<jhenke> basically I am looking for a dev who is willing nad ha the time to do the next steps
<seb128> jhenke, yeah, I also told you that the request made sense ... you can ask here, it's more ontopic, but everybody is busy and it's not likely that you find somebody to work on that through IRC pings
<jhenke> too bad, I was hopeing that would work :(
<seb128> you are welcome to work on the update yourself, finding a sponsors might be easier
<jhenke> from the webpage I do not really find with whom I can request a backport. How can I get that started?
<jhenke> thanks guys, I think I figured it out now, I hope someone of the backports team will look into that soon.
<doko> seb128, GCC 5 ping
<seb128> doko, yes, what about it?
<doko> seb128, basically I'd like to know what will break when upgrading to the silo 16 ppa (see email)
<doko> and fix that before copying the ppa to -proposed next Friday
<seb128> doko, it's on my list to investigate for today/tomorrow
<doko> ok, thanks
<doko> seb128, if you can reach robert ancell, please can he avoid updating the gnome mm stack? before GCC is the default? can't reach him, and he didn't reply on my email
<seb128> doko, ok, he probably read your email even if he didn't reply to it (knowing him)
<doko> mvo, I also filed an issue to build apt using gcc-snapshot to investigate the test failure using GCC trunk
<seb128> zyga, hey, did you notice that the new plainbox is depwaiting on python3-xlsxwriter which needs a mir?
<zyga> seb128: oh - no, thanks for noticing that
<seb128> zyga, yw!
<zyga> I'll work on MIR paperwork ASAP
<seb128> can you take care of the mir report?
<seb128> thanks
<zyga> yep, absolutely
<seb128> flexiondotorg, Laney, that -welcome package you discussed earlier (iirc) is in the wily NEW queue, so somebody already sponsored it
<flexiondotorg> seb128, That's great news.
<seb128> bdmurray, it seems your apport update in wily is creating a real regression for autopkgtest, it has been retried several times and fails consistently, that block other things in proposed, are you looking at the issue?
<seb128> hum
<seb128> devscripts is blocked because lava-server autopkgtests fail, but looking to https://jenkins.qa.ubuntu.com/job/wily-adt-lava-server/ that doesn't seem a new situation
<seb128> could somebody unblock it/mark the test as buggy?
<seb128> same for distro-info
<doko> apw, schroot ping
<zyga> seb128: https://bugs.launchpad.net/ubuntu/+source/xlsxwriter/+bug/1477531
<ubottu> Launchpad bug 1477531 in xlsxwriter (Ubuntu) "[MIR] xslxwriter" [Undecided,New]
<seb128> zyga, thanks
<zyga> seb128: I could use a bit of advice, checkbox will require two new packages, one is applicable for Debian (QML module) but the other one is not (depends on SDK components). What should we do to make them available in Ubuntu
<seb128> zyga, have it packaged and submitted for sponsoring
<zyga> we have the qml module
<zyga> how can we submit it to Debian for sponsoring?
<zyga> seb128: I only have experience with python packags
<zyga> packages
<seb128> zyga, http://mentors.debian.net/sponsors
<zyga> seb128: thanks
<seb128> yw!
<mvo> doko: oh, gcc-snapshot fails in the same way? I haven't checked the upstream gcc report in some days
<doko> mvo, no, apt even fails to build using GCC trunk
<dragos> hi i have installed ubuntu on my tab 2 7.0 and i dont have an otg cable cause to bring the gui i have to press CTRL+ALT+F7 and i was wondering if ubuntu can autopress these keys from an edited text
<hjd> Hi all. I have to admit I don't know whether this is the right place, but I've seen various bugs like bug 1472165. These are marked as affecting a dozen different packages, presumably because the kernel is available in different forms. I do wonder whether the linux-lts-backport-maverick and -natty are simply added for completeness, or whether they don't need to be added for new bugs filed.
<ubottu> bug 1472165 in linux-manta (Ubuntu Wily) "CVE-2015-5366" [Medium,New] https://launchpad.net/bugs/1472165
<Laney> doko: Should I rebuild things for python3.5 if necessary?
<Laney> e.g. pyside
<doko> Laney, sure, maybe coordinate with slangasek, he is doing these uploads currently
<hallyn> mbiebl: hi, can you point me to a url explaining how to have a systemd service not restart on package reinstall?  (i.e. to make dh_installinit --no-restart-on-upgrade work)
<mbiebl> hallyn: is that a package without a sysvinit script, i.e. systemd service file only?
<hallyn> mbiebl: yeah, looks like only upstart and systemd.
<hallyn> (pkg is lxc)
<mbiebl> then use dh_systemd_start --no-restart-on-upgrade
<hallyn> call that after the dh_installinit?
<mbiebl> is the package using dh?
<hallyn> uh.  yeah.  i think.
<hallyn> i get the pkging type names confused
<mbiebl> then use the usual override_dh_systemd_start: ...
<hallyn> ok, but so - should this NOT be considered a bug in dh_installinit?
<mbiebl> what do you mean?
<hallyn> i.e. what used to just work with dh_installinit --no-restart-on-upgrade now requires extra steps...
<mbiebl> dh_installinit deals with sysv init scripts primarily
<mbiebl> and handles .service files if the names match
<mbiebl> hallyn: one could argue, that the functionality of dh-systemd should be merged into dh_installinit, but at the time, it seemed better to do it in a separate helper
<hallyn> i suspect dh-systemd adds power that justifies its existing, but it does seem to me like dh_installinit should be able to handle the arguemnts it says it handles
<hallyn> or, at least the manpage should be updated to say that no-restart-on-upgrade doesn't work with systemd by itself :)
<hallyn> mbiebl: but thanks!  i'll try this out.
<mbiebl> well, --no-restart-on-upgrade works with systemd
<hallyn> ?
<hallyn> not in dh_installinit though
<mbiebl> say you have a /etc/init.d/foo and foo.service and you use dh_installinit --no-restart-on-upgrade
<mbiebl> invoke-rc.d will correctly handle that
<hallyn> i only have foo.service
<mbiebl> and not restart the service file on upgrades
<mbiebl> hallyn: that's what I tried to explain, apparently I failed
<hallyn> so if i had a /etc/init.d/foo, it wouldn't restart on upgrade?
<mbiebl> yes
<hallyn> and it would start both foo.service and /etc/init.d/foo?
<mbiebl> no, only foo.service obviously
<mbiebl> (under systemd)
<mbiebl> if there is no sysv init script, dh_installinit will do nothing
<hallyn> hm.  we *have* sysv jobs, maybe installing those is the way to go
<mbiebl> so dh_systemd_start kicks in
<mbiebl> and you get the default behaviour of dh_systemd_start
<mbiebl> which is to restart on upgrades
<mbiebl> so you need to override that
<mbiebl> via override_dh_systemd_start:\n dh_systemd_start --no-restart-on-upgrades
<mbiebl> has it become clearer, how it works?
<mbiebl> (nobody said, supporting multiple init systems wouldn't be simple)
<hallyn> mbiebl: so in the past dh_instlalinit worked for all inits.  Is the thing I'm missing that 'dh_installinit' simply isn't meant to work with systemd?
<hallyn> mbiebl: yeah i think i get it better now.  I'll get something worked out - thanks!
<mbiebl> hallyn: upstart units don't need to be enabled
<mbiebl> and we need some flexibility in the enabling and starting bits
<mbiebl> so the helpers were split into dh_systemd_enable and dh_systemd_start
<hallyn> and i don't need to put a call to dh_systemd_start under dh_installinit or anything, just put in the override_dh_systemd_start?
<mbiebl> something which was odd to cram into dh_installinit
<mbiebl> right, you override as any other dh command
<hallyn> mbiebl: yeah i can believe it would've been awkward.  I only think that i'm not the only one confused and that the manpages should spell out to look at dh_systemd_start :)  I'll make a note to look into a docs patch
<hallyn> mbiebl: thanks again
<mbiebl> https://anonscm.debian.org/cgit/pkg-utopia/network-manager.git/tree/debian/rules#n61
<mbiebl> dh_installinit's behaviour really becomes awkward if you want to achieve something like that
<rbasak> infinity: I'm interested in your opinion on bug 1194074 please. Clearly user error, but it seems to be that we're leading them into it, and apache2's approach is better. What do you think, please?
<ubottu> bug 1194074 in nginx (Ubuntu) "Default index.html blindly overwritten" [Medium,Triaged] https://launchpad.net/bugs/1194074
<mbiebl> that's mostly an issue though, for packages shipping multiple .service units
<mbiebl> which is more common though under systemd, where you have multiple service unit instead of a giant init script starting multiple processes
<Odd_Bloke> arges: There's a new release of cloud-init in wily, which should mean that all the SRUs are now fixed in wily.
<arges> Odd_Bloke: ok
<Laney> Odd_Bloke / smoser: will/can we get a new cloud image today?
<Laney> There's an autopkgtest bug which triggers if there is a new cloud-init vs. what shipped in the image :/
<Odd_Bloke> Laney: One will normally pop out of our automation whenever there are new packages on the base image.
<Odd_Bloke> Laney: But I'll give it a kick if it hasn't started yet.
<Laney> Odd_Bloke: ack, thanks
<Odd_Bloke> Laney: I've kicked that off; last build failed for spurious reasons so I'll keep an eye on it to make sure it works.
<Odd_Bloke> Laney: What's the autopkgtest bug?
<Laney> Odd_Bloke: It creates a conffile prompt which it doesn't (tell dpkg how to) handle
<Odd_Bloke> Laney: "it" being?
<Laney> adt-buildvm-ubuntu-cloud
<Laney> https://bugs.launchpad.net/ubuntu/+source/autopkgtest/+bug/1477626
<ubottu> Launchpad bug 1477626 in autopkgtest (Ubuntu) "adt-setup-vm modifies cloud-init's conffile but doesn't handle dpkg conffile prompts" [Undecided,New]
<Odd_Bloke> Laney: Ah, right.  I've added a comment suggesting using /etc/cloud/cloud.cfg.d/ instead of modifying the apt installed config file.
<Laney> Nice, didn't know that existed
<Odd_Bloke> :)
<infinity> rbasak: I could have sworn Debian policy actually defined the default docroot as being /var/www/something, and nginx is buggy for pointing people to /usr/share and encouraging exactly that bug.  Too busy to look right now, though.
<tarpman> #730382?
<infinity> rbasak: https://www.debian.org/doc/debian-policy/ch-customized-programs.html#s-web-appl
<bdmurray> seb128: I am but I'm not making much progress.
<infinity> rbasak: It's not strongly-worded, but it's certainly mentioned.
<rbasak> infinity: interesting, thanks. Has that changed recently? Last time I looked it wasn't as clear (it was more for applications than servers)
<rbasak> teward: ^^
<infinity> rbasak: Well, it is for applications, yeah, but it still mentions that the default docroot is /var/www/html, so one can infer that it should apply to servers.
<rbasak> Yeah
<infinity> rbasak: It's not a policy "must" or anything there, but I'd still consider it reasonable guidance for all httpds.
<rbasak> I certainly get the impression that this is the intent, and it's never been a point of contention before nginx.
<Odd_Bloke> There's also https://lintian.debian.org/tags/dir-or-file-in-var-www.html
<infinity> rbasak: Certainly, pointing the default docroot to an FHS location owned by the package manager isn't sane.
<infinity> rbasak: I'd argue they should ship their bit in /usr/share (as they do), and iff /var/www/html is empty, add a symlink to their index.html (and if not, leave it alone).
<rbasak> Yeah that sounds reasonable
<infinity> rbasak: Which, I imagine, is similar to what apache does, but I haven't looked at apache packaging in years.
<seb128> bdmurray, k
<infinity> rbasak: s/symlink/copy/ if the default nginx config doesn't follow links.
<dragos> hi
<teward> infinity: i think that was brought up in the given bug that was linked - nginx maintainers said "This is the root [current] in accordance with policy."
<teward> rbasak: infinity: I would love that policy to have better wording, the next question is given the current hostility situation on this, should this be elevated higher than package maintainers in Debian to get authoritative policy on the decision
<teward> or is that even possible?
<teward> I know the Ubuntu politics, moreso than Debian
<teward> (I actually try and AVOID Debian politics altogether)
<teward> (at least, from the political/policy determination/interpretation side()
<infinity> teward: It could be brought to the TC in Debian, though it would be smarter to try to get concensus on adding stronger wording to policy, with the nginx maintainers' input.
<infinity> teward: That said, Debian's nginx maintainers refusing to move on this is no excuse for us not fixing it in Debian.
<infinity> s/in Debian/in Ubuntu/
<teward> infinity: of that, you, myself, and rbasak agree, given that I went on a 20-minute tirade in PM about this exact issue
<teward> i'm quite happy of the community driven nature here in Ubuntu, where community consensus is preferred over the individual maintainer
<teward> probably why i'm a fan of Ubuntu moreso than Debian XD
<teward> infinity: i'm about to unarchive the bug in Debian on this for nginx maintainers.
<infinity> teward: Meh, it's not really that different anymore.  And we do have "weak ownership" of some packages/sets in Ubuntu where you'll get smacked down pretty hard if you try to override those people.
<dragos> im making cool ubuntu image for older pc's but with new apearane
<teward> infinity: i'm of the preference that community or team consensus is better than 'weak ownership' - in this case, nginx is 'weakly' maintained by me but ultimately I stand down in favor of Server, Release, SEcurity, etc. team governance
<teward> infinity: for all intents and purposes, I'm tempted to unarchive the bug in Debian, and say "Wait a minute, what about this policy? https://www.debian.org/doc/debian-policy/ch-customized-programs.html#s-web-appl ..."
<teward> and say that the package is violating policy
<teward> but the moment i do that i get negatively received
<infinity> teward: Sure.  Just saying it's not actually *that* much different.  You're appealing to me, not because I care and want to overrule you, but because you trust my input.  That's just being a humble maintainer.  Same happens in any distro (and doesn't happen, when egos get in the way).
<teward> Right
<infinity> teward: That policy wording really can't be used as a stick to smack people with, as it's neither directed at httpd maintainers, nor is it stated as a "must" anywhere.  But it's a good talking point, since it certainly IMPLIES that the "default" docroot should be consistent, and consistently /var/www/html
<teward> mmm
<teward> i need to reexamine the policy, the prior arguments given, and then reach out again about the bug, with a stressor on "I want more than just Michael's opinion on this, I'd like other maintainers to weigh in"
<infinity> teward: Anyhow, I'd honestly just fix it in Ubuntu for now, submit the patch to Debian without any inflamatory comment, and let them deal with it.
<teward> infinity: i'm more tempted to see what their response will be
<infinity> teward: And if it's something you feel passionate about, bring up a policy ammendment to set this slightly more in stone for all web servers.
<teward> I expect a "[CENSORED] you, and [censored] the people affected"
<teward> which is the current state
<teward> infinity: i have 0 say in Debian, nor am I familiar with that current state - i would be petitioning for the policy rereview anyways given my current level of passion and drive on this
<teward> infinity: if i were to propose such policy amendment who do I petition?
<teward> (brb lunch, i'll respond to comments after i return)
<cjwatson> debian-policy@
<teward> cjwatson: debian-policy @ debian ?
<infinity> teward: File a bug on debian-policy, if you have an ammendment ready, or a mail to debian-policy@ if you want a discussion.
<infinity> teward: @lists.d.o
<teward> infinity: i probably will mail in on the discussion first
<cjwatson> you should cc affected lists/maintainers/etc. though, people aren't generally expected to keep up with everything on -policy
<infinity> s/everything/anything/
<teward> cjwatson: i intended to CC the maintainers group for nginx
<teward> or rather, each of them, since it's comaintainership and not team based
<cjwatson> but also other www maintainers
<infinity> teward: Yeah, all httpd maintainers.
<cjwatson> a policy change would affect all of them
<teward> there's no list for that is it?
<infinity> teward: Since the point of this is standardisation.
<cjwatson> teward: dunno, your job to figure that out
<teward> i mean, that's... what, lighttpd, apache2, nginx, probably smaller ones...
<cjwatson> (that is, the job of the person proposing a change)
<teward> heheheh
<teward> i'll go hunting then
<infinity> teward: Check maintainer fields.  debian-apache@lists.d.o, for instance.
<cjwatson> have a look on http://lists.debian.org/ too
<teward> even if the battle ends up with me smacked
<teward> (back in a bit I need food)
<cjwatson> debian-webapps maybe
<cjwatson> though that might be defunct ...
<infinity> cjwatson: Given that current policy seems aimed at webapps already, I hope they agree. :P
<infinity> (but it's silly to tell webapps people where the default docroot is and not tell httpd people to serve stuff there, so clearly someone needs to write gooder)
<dragos> help i have an pc and it says to login i put my password and it logs out and asks me again to login
<infinity> Pretty sure this all came about when apache1.3/2 were the only really viable web servers in the archive, and they decided the docroot, so no one thought an httpd policy was necessary.
<Gallomimia> dragos: i've had that problem before. errors in X configuration. #ubuntu should be able to help
<dragos> some dude banned me from #ubuntu for no reasion
<cjwatson> dragos: I'm sorry, but this channel isn't for escalations from #ubuntu.  Perhaps you could try askubuntu.com for a calmer environment than IRC
<dragos> bye
<dragos> gtg
<teward> infinity: perhaps it's time to revisit that then
<teward> on the Debian side
<teward> cjwatson: infinity: so basically i have to email the maintainers for the source packages of everything here , while emailing the discussion list?  https://packages.debian.org/unstable/httpd/
<teward> (to propose a more set-in-stone discussion on the HTTPd enforcement of web docroots)
<teward> as well as their webapps list?
<cjwatson> I suspect everything there is a bit much, the apache modules don't matter for this
<cjwatson> but I'm not that familiar with this, I was just giving general pointers
 * teward shrugs
<teward> might be easier to just submit a bug for the amendment then
<teward> although this is what i think is the conflict point in the same policy doc infinity linked: "Instead they should use the /usr/share/doc/package directory for documents and register the Web Application via the doc-base package"
<teward> i think that leads to confusion and there should be one set-in-stone one :/
 * teward shrugs
<teward> infinity: input would be nice, should i target everyone in the httpd subsection or just the major httpds?  Since I don't think there's a complete list of httpds out there
<infinity> teward: I'd go with everything that 'Provides: httpd', probably, as that implies they're providing a standard interface.
<infinity> teward: I'd argue that standard interface isn't just about serving stuff on port 80, but also which location in the filesystem they serve by default.
<teward> infinity: any easy way to pull that whole list of packages short of page by page?
<infinity> teward: http://paste.ubuntu.com/11926008/
<teward> oooo nice
<teward> that helps narrow it
<infinity> teward: But grep-dctrl would be the other right way.
<teward> infinity: i'll start drafting the discussion - do you want me to include you on this as well?
<cjwatson> grep-dctrl is your friend, definitely, anyone who deals with stuff across a distribution rather than just a few packages should be familiar with it
<teward> (on the CC list and such)
<teward> cjwatson: indeed.  this is my first venture into cross-distro for more than just two packages so heh
<infinity> teward: I probably won't get too involved.
<teward> infinity: ack.  was more for a situational awareness reason than involvement
<infinity> teward: grep-dctrl example http://paste.ubuntu.com/11926018/
<infinity> Though some of those can probably be left off the list.  Use a bit of common sense. :)
<cjwatson> -wFProvides is handy to avoid unwanted mid-word matches
<infinity> The providers of httpd-cgi (ie: web servers that can do useful things!) are a smaller and saner list.
<infinity> cjwatson: Ahh, didn't realise I was substring matching there.  Yes, -wFProvides httpd is a sane list.
<infinity> teward: http://paste.ubuntu.com/11926020/ <-- There.
<infinity> teward: Might want to re-run in a Debian chroot, in case they have ones we don't.
<teward> right
<teward> infinity: that does give a starting point though
<infinity> teward: Realistically, you don't need 100% concensus here from every dinky thing that claims to provide an httpd, but apache, nginx, aolserver, and lighttpd at least all have a fair few users and consistency is nice.
<teward> infinity: indeed, i was thinking about the major ones, didn't know aolserver was a thing though
<infinity> teward: aolserver's actually not terrible.  Turns out that the people who built an empire out of providing a curated version of the internet knew a thing or two about serving stuff on port 80 by the time all was said and done.
<teward> heh
<teward> infinity: correct, i don't need a full consensus, in theory i need simple majority
 * teward misused 'consensus' earlier
<rbasak> infinity, cjwatson: just caught up. Thank you for the discussion with teward - I wasn't confident in the Debian processes involved here. I agree that it's an ambiguity in policy because nobody had reason to be better defined than "what apache does" in the past.
<rbasak> I'm a little concerned about an Ubuntu delta because it involves a conffile change and moving data about for users (even if they do it themsleves).
<rbasak> So I'd like to see an attempt to reach agreement to fix it in Debian first if we can do that. And it seems like that's where teward is going anyway.
<rbasak> So maybe hold on an Ubuntu delta until Debian either decide or its clear that it isn't going anywhere in Debian please?
<Laney> doko: is http://people.canonical.com/~ubuntu-archive/transitions/html/python3.3-5.html ok?
<doko> Laney, yes, looks reasonable
<Laney> thx
<doko> Laney, boost1.58? is this run against the silo 16?
<Laney> they all are, that's how it got set up
<doko> argh, ok
<Laney> at least it shows you work that needs doing in there ;)
<Laney> doko: is this legitimate?
<Laney> build-3.5/data/ShibokenConfig.cpython-35m-x86_64-linux-gnu.cmake:SET(SHIBOKEN_PYTHON_SUFFIX ".cpython-35m-x86_64-linux-gnu")
<Laney> build-3.4/data/ShibokenConfig.cpython-34m.cmake:SET(SHIBOKEN_PYTHON_SUFFIX ".cpython-34m")
<doko> Laney, yes, this is now upstream
<robert_ancell> slangasek, is there anything in particular I need to setup my wily box to compile with GCC5? I installed the packages and updated the symlinks but I still don't reproduce the errors in the PPA for zeitgeist
<robert_ancell> Wondering if there's another package that might be affecting it
<slangasek> jamespage: it looks like most of the openstack packages' autopkgtests are failing in wily now because they're uninstallable due to the sqlalchemy transition.  Is someone working on fixing the versioned deps on older sqlalchemy?
<slangasek> jamespage: fwiw I'm asking about this because sqlalchemy is one of the packages that needed rebuilding against python3.5... it's rebuilt, but is clearly incompatible with openstack currently in wily
<slangasek> robert_ancell: I'd say the most reliable way to reproduce it would be to enable that ppa in your sources.list
<robert_ancell> slangasek, yeah, there is a lot of stuff in that PPA though...
<slangasek> robert_ancell: right, you wouldn't need to install it all, but you'd want to pull your build-dependencies from there
<robert_ancell> Good point
<slangasek> robert_ancell: what I do notice from eyeballing the logs, the failing test links against xapian and xapian is in the list of packages pulled from the ppa
#ubuntu-devel 2015-07-24
 * robert_ancell wonders who chose the Launchpad group name 'ci-train-ppa-service'. Would love to type something shorter...
 * infinity notes that ~ci is an inactive account we could probably rename and steal.
<jamespage> slangasek, I'll get on that today - was on my list
<Laney> doko: do you have a make rule or some helper for calculating it?
<mvo> doko: I think I am mkaing progress
<mvo> doko: new apt uploaded to the ppa, libept will also need a rebuild against it though. p-apt builds in my schroot now
<tseliot> infinity: hey, tjaalton said you have problems with fglrx + linux 4.1. If so, please make sure to use fglrx 2:15.200.1-0ubuntu1 in wily, that will fix it. If not, I'm here
<caribou> what is the most appropriate way to merge a debian package ? bzr or grab-merge ?
<caribou> or it is up to who merges ?
<Noskcaj> caribou, up to who merges
<Noskcaj> sometimes only one will work
<Noskcaj> some packages are also in lp:~ubuntu-desktop/PACKAGE/ubuntu
<caribou> Noskcaj: ok, thanks
<doko> mvo_, thanks, however tests still fail: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-016/+sourcepub/5224902/+listing-archive-extra
<mvo_> doko: hm, thats new and different
<mvo_> doko: fix will be uploaded shortly
<jamespage> slangasek, I've fixed up all of the openstack packages apart from openstack-trove
<jamespage> I may dump in a snapshot as upstream master don't appear to have the same unit test failures, and I'm failing to bisect a single commit that fixes the problem
<seb128> slangasek, seems like the pyqt5 python 3.5 rebuild is failing autopkgtest the 3.5 build seems invalid/failing to import
<doko> seb128, see lp: #1477759
<ubottu> Launchpad bug 1477759 in dh-python (Ubuntu Wily) "pyqt5 misbuild with python3.5" [Critical,Triaged] https://launchpad.net/bugs/1477759
<seb128> doko, thanks
<infinity> tseliot: Still around?
<tseliot> infinity: yep
<infinity> tseliot: 2:15.200.1-0ubuntu1 is broken with 4.1.0-2 (ie: 4.1.3 upstream), trust me. :P
 * tseliot always forgets to update his IRC status...
<infinity> tseliot: http://d-jenkins.ubuntu-ci:8080/job/dkms-wily-release_canonical_kernel_team_ppa-generic-fglrx_core/17/
<tseliot> infinity: I tried mainline and it works fine. Maybe we're using some patches?
<infinity> tseliot: I even pointed tjaalton at a potential patch from another distro at the time.
<infinity> tseliot: I doubt we're carrying patches that make symbols GPL-only...
<tseliot> infinity: the thing is, I already added support for linux 4.2. Maybe one of those changes was pulled into 4.1
<tseliot> pci_ignore_hotplug is part of my patch for 4.2
<tseliot> infinity: I'll give it another try, and move that fix from the patch for 4.2 to the one for 4.1. Maybe 4.1.3 is the problem
<infinity> tseliot: Well, not sure what to tell you.  All I can say is that it's obviously failing.  The log doesn't lie.
<tseliot> infinity: I'll check again with the kernel team ppa, and fix that, whatever the reason is
<tseliot> ;)
<tseliot> infinity: and yes, apparently I had only tested with 4.1.2 and with 4.2
<tseliot> oh, well...
<Sarvatt> tseliot: looks like it is going into 3.19 too https://lkml.org/lkml/2015/7/15/1170
<Riddell> mvo_: what makes you think I know anything about git?!
<tseliot> Sarvatt: aargh. Thanks for the heads-up
<mvo_> Riddell: uh, I though we shared some code with that, my memory is sometimes blury
<mvo_> Riddell: sorry
<Riddell> :)
<Laney> sladen: yo, are you interested in uploading the new version of the ubuntu font to the distro? I saw you've been active on the bug
<sladen> Laney: I am.  But prior to that a new upstream version needs preparing!  ;-)
<Laney> sladen: yah. willcooke says it exists or will exist or something. :)
<willcooke> ohai
<sladen> Laney: small delta 0.80->0.83 to recompile a couple of tables; so should be backportable to everything and its grandfather
<Laney> cool
<Laney> you mean SRU or backports?
<sladen> Laney: willcooke: was meaning to do it last weekend, but insistent prodding helps ;)
<Laney> well, whatever, I trust you can handle it
<sladen> Laney: s/backport/SRU/ yes
<Laney> thanks!
<willcooke> super, thanks sladen laney.  I'll let Magdalena know you're on the case
 * sladen grins
<doko> seb128, fix for  1477759 uploaded, python3.5 still building on armhf and arm64
<tseliot> infinity: it should be all fixed in fglrx-installer{-updates}_15.200.1-0ubuntu2
<seb128> doko, thanks
<infinity> tseliot: \o/
<infinity> tseliot: Thanks.
<tseliot> infinity: thanks for reporting the problem
<ogra_> infinity, yo ... so i saw ubuntu-fan 0.3 on wily-changes ... do you think it is ready to seed it in snappy now ?
<ogra_> apw, ^^^ same question to you
<infinity> ogra_: Did you unseed it at some point?
<ogra_> when you asked me with v0.1, yes
<infinity> ogra_: Ahh, so you did.
<infinity> ogra_: So, yeah, it should be good to go now.  It no longer depends on dnsmasq.
<ogra_> sweet !
<ogra_> (not sure i'll manage today, but i'll put it back then :) thanks !!)
<infinity> ogra_: Seemed to me entirely unclever to have dnsmasq installed in a base image that people are trying to use as a border network device. ;)
<ogra_> well, there are plenty of unclever thins in snappy still :)
<ogra_> *things
<infinity> Not that I agree with half the things in the base snappy image, but at least things in there shouldn't be actively harmful.
<infinity> Bloat is acceptable (ish), things that might actually break higher level snaps, less ok.
<ogra_> (cloud-init being the worst ... and no, a go rewrite wont help :P )
<timrc> Glad to know go rewrite jokes are still alive and well ;)
<ogra_> thats not a joke sadly
<timrc> :~(
<seb128> doko, slangasek, hum, shouldn't libprofobuf change soname with its gcc5 rebuild?
<seb128> I'm looking at https://launchpadlibrarian.net/212134164/buildlog_ubuntu-wily-amd64.messaging-app_0.1%2B15.10.20150710.2-0ubuntu2~gcc5.1_BUILDING.txt.gz
<seb128> (/usr/lib/libphonenumber.so.6: undefined symbol: _ZNK6google8protobuf11MessageLite25InitializationErrorStringEv)
<seb128> doing a diff from the nm -D of the lib from wily/the ppa version gives things like
<doko> I didn't change sonames yet
<seb128> -000532d0 T _ZNK6google8protobuf11MessageLite25InitializationErrorStringEv
<seb128> +00053cc0 T _ZNK6google8protobuf11MessageLite25InitializationErrorStringB5cxx11Ev
<seb128> doko, it should no,  since the symbols changed in the rebuild?
<doko> and we have a libphonenumber7 there too
<doko> seb128, in principal, yes, but I can't handle 400 renamings
<doko> so the best thing here is to collect these libraries at the bottom of the library stack, and then just rename these
<seb128> doko, well, uploading libraries that change ABI without soname change is not any better is it?
<seb128> do we have a list of libraries that need to be renamed?
<doko> no, but you can do it with no-change uploads
<seb128> how do we make sure those abi change don't land to the archive?
<doko> https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=libstdc%2B%2B-cxx11;users=debian-gcc@lists.debian.org
<doko> well, they go into -proposed next friday, and the dependency on libstdc++6 (>= 5.2) prevents them from migrating
<seb128> but how do we detect where abi changes?
<doko> and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790756
<ubottu> Debian bug 790756 in release.debian.org "transition: libstdc++6 cxx11" [Normal,Open]
<doko> well, you see it if you try to rebuild a package without first rebuilding it's dependencies
<seb128> hum
<seb128> it seems a bit of try & see, but that doesn't give me confidence on how we are making sure we don't overlook some issues
<seb128> or that we rebuild things in the right order
<slangasek> jamespage: cheers
<doko> seb128, and for messaging-app: see the test failures at https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-016/+sourcepub/5225831/+listing-archive-extra
<slangasek> seb128: pyqt5, yes there's a bug open about this; it's a dh-python/python3.5 bug
<seb128> slangasek, hey, doko replied earlier, thanks
<doko> seb128, yes, so we should do the transition, but then again, we shouldn't do it twice (once for ourself, and then again when debian changes things=
<seb128> I don't understand how things work
<seb128> like that protobuf upload has an abi change without soname change
<seb128> that can't be right
<seb128> what's the rational/logic?
<seb128> why don't we hold on the upload until it's properly checked/transitioned?
<doko> because that doesn't work, to keep up packages in sync, and do 400 transitions
<Laney> I think he means that you do the highest transition in any tree of packages
<doko> it's already a pain to keep this ppa up to date
<Laney> because this already forces rebuilding/upgrading everything further down
<Laney> yes?
<doko> right, but I do want to do these rebuilds in -proposed, not in the -ppa
<seb128> I don't understand
<seb128> what prevents that protobuf abi change to land in wily-proposed
<doko> https://wiki.ubuntu.com/GCC5 has a list of the explicit transitions
<seb128> or what guard us against it?
<doko> nothing will guard you
<seb128> so we might have updates that change abi without soname change landing in wily?
<doko> why would that hurt? we don't guarantee partial upgrades. and as I said, for low level libs I plan to do that library rename
<seb128> why would that hurt?
<seb128> I though abi stability was one of the basic things we try to ensure
<seb128> since when is that ok to change abi without changing the soname/renaming a deb?
<seb128> sorry for the stupid questions
<doko> we're ubuntu, not debian. and if we change the libraries at the bottom of the stacks, we should be good enough
<seb128> I'm sure that transition is really tricky and people though about it
<seb128> we are not debian, but we never said that ubuntu didn't ensure abi compatibility is maintained
<slangasek> doko: what does http://bugs.python.org/issue24705 have to do with the pyqt5 build failure?  I didn't see any problems with prefixes
<doko> slangasek, another issue with dh-python
<slangasek> ok
<doko> trying to generate some path name from a config var
<seb128> doko, sorry but I still don't get it so I'm going to ask another question :-)
<seb128> is protobuf going to be renamed before being uploaded to wily?
<seb128> if yes, why didn't that happen in the ppa?
<seb128> if no, why do we consider the abi change without rename as ok?
<seb128> I could have a system with ubuntu core + libprotobuf + some custom application on top, it means upgrading my system is going to make my application fail on symbol errors
<seb128> rather than having the packaging stopping me from upgrading
<seb128> slangasek, ^ you might be able to help me to understand things about that transition as well maybe? ;-)
<doko> seb128, I don't plan to rename it on my own, however will take any renaming that comes from debian. if you think it is worth renaming, then please do it in the ppa, rebuild all reverse-deps, and keep these up to date during the next week
<Laney> sorry to add to the doko pinging, but...
<Laney> -rw-r--r-- root/root    640800 2015-07-24 12:26 ./usr/lib/python3/dist-packages/PySide/QtWebKit.cpython-34m-x86_64-linux-gnu.so
<Laney> -rw-r--r-- root/root    642336 2015-07-24 12:26 ./usr/lib/python3/dist-packages/PySide/QtWebKit.cpython-35m.so
<Laney> is that kind of thing fixed with this new dh-python?
<doko> the problem is that you probably will find another dozen libraries while you are doing this
<seb128> doko, well, if they need to be transitioned that's how thing are...
<seb128> we can't just ignore the abi breakage
<seb128> and randomly uploads changed abis without transition
<slangasek> seb128: what you're suggesting is that we change all of the sonames of the affected libraries, when upstream has not. that's incredibly painful; historically in Debian what we've done when we've had issues like this , is to rename the binary packages and not change the sonames, since changing the sonames requires fiddling with umpteen different upstream build systems
<doko> Laney, I don't know, the thing that I fixed was the doubled multiarch string in the soabi
<seb128> slangasek, right, I said soname/or binary rename
<Laney> doko: maybe the one slangasek just linked to?
<seb128> slangasek, in the ppa protobuf changed abi but got neither
<doko> seb128, I already have to babysit the touch guys, now I have people stomping with the foot to insist on 400 package renamings ;)
<Laney> doko: in the buildlog I see dh-python3 renaming the 3.4 one to add the triplet but not for 3.5
<seb128> doko, well, if the abi change they have to be renamed
<Laney> so was curious as to whether this will fix it or if I should wrangle in the packaging
<seb128> I don't see why it would be ok to not
<seb128> slangasek, ^
<slangasek> seb128: right. but a package name change without an soname change is not going to do anything to protect users of unpackaged software
<seb128> slangasek, well it's going to ensure you don't upgrade a library and break softwares
<Laney> guess I could just try it eh
<seb128> apt is not going to let you update that lib
<infinity> doko: Err, we don't guarantee stability of the final product on a partial upgrade, but we have to support partial upgrades in-progress.  Not transitioning a library correctly can lead to something breaking in a postinst halfway through an upgrade and breaking the world.
<seb128> or it's going to ensure other packages are upgraded to use the new name as well
<slangasek> seb128: you cited ubuntu-core as an example, and ubuntu-core doesn't use apt for updates ;)
<doko> yes, that's why we have to rebuild everything before anything can migrate to the release pocket
<seb128> slangasek, ubuntu-minimal? ;-)
<seb128> or ubuntu server
<seb128> whatever minimal base we provide
<seb128> doko, well, "everything" is things in the archive, we might break third party debs
<seb128> where a rename would protect them
<slangasek> doko: rebuilding everything and migrating it at once does not ensure correct unpack order on upgrade, an infinity said
<seb128> if feels fundamentaly wrong to change abi without renaming
<infinity> slangasek: "We can't fix unpackaged software" is a perfect-enemy-of-good argument. :P
<slangasek> (this is why we had the discussion about apt in particular)
<slangasek> infinity: I agree with you and seb128 about renaming the affected libraries as part of the transition, I just want to be clear about what this does and doesn't accomplish
<doko> slangasek, infinity: I didn't say that we shouldn't rename nothing. we will have the soname changes for some libraries, and we will have to rename some basic libs. but I don't see the point to rename everything, even if you don't know if the symbols form part of the library API
<infinity> slangasek: Right, we've been through package-rename-without-sover-bump transitions before, I think the Debian community is well-versed in what that does and doesn't fix.
<doko> however doing this in the ppa is the wrong thing to do
<slangasek> doko: because it's safe to do so, and easier to script those conversions than to have this argument ;)
<slangasek> doko: the ppa is meant to be binary copied en masse to the archive when ready; the ppa would be the place to do this
<doko> slangasek, then please freeze -proposed for a week
<seb128> it's over me why we upload "no change rebuilds that lead to a uncompatible abi" at all
<seb128> shouldn't we check if the abi change and rename before upload
<seb128> for every package
<seb128> ?
<doko> sure, please start doing so
<seb128> we wouldn't have that discussion if every package includes a .symbol and failed build on changes :p
<seb128> doko, I'm going to start on monday
<seb128> but that ppa has already damages by changed-abi-but-not-renamed packages
<doko> symbols files for c++ are crap
<slangasek> seb128: damages meaning what?
<seb128> slangasek, meaning we have abi changes sneaked in that we don't know about
<seb128> since things were uploaded without checking if a rename was needed
<seb128> e.g protobuf
<Laney> When you fix it by starting a transition you'll have a to rebuild the reverse-deps anyway
<doko> wrong, I confirmed issues in the debian bug tracker
<slangasek> ok; "damages" suggested something stronger to me - I'm certainly aware of the state of the packages in the ppa
<seb128> slangasek, how do we prevent those abi breaks to reach the archive?
<doko> we shouldn't care for -proposed from my point of view
<seb128> we could have a lib without archive rdepends going through without having britney having any reason to stop it
<slangasek> seb128: do you have some time to work on this?  I haven't started the scripting yet
<doko> and fix issues in -proposed
<slangasek> seb128: but I have a rough plan I can describe
<seb128> slangasek, not today but I can spend some time on that starting on monday
<doko> and keep in mind that by heavily using the ppa you basically block the buildds for archive purposes
<slangasek> seb128: here's the list of all build logs showing changed symbols; they correspond to the bugs doko filed in the Debian BTS, but this list is better to work from because it gives you the binary package names, search for 'BEGIN GCC CXX11 symbols': https://people.debian.org/~doko/logs/gcc5-20150701/
<slangasek> doko: staging this transition is a high priority and a legitimate use of the distro builders
<slangasek> seb128: so my plan of attack was to extract each of those source packages, script up a package rename in debian/control and debian/$pkg.*, build, and see what breaks
<seb128> slangasek, seems like a good plan to me. Why didn't we start by that rather than getting no change rebuilds in the ppa?
<doko> slangasek, so when do you think these builds will finish?
<doko> seb128, would be a good task for +1 maintenance. so feel free to start. I'm already working 12+hours, weekends included
<slangasek> doko: we would only need to make the source changes to the affected libraries before copying to -proposed; 361 packages; I don't think I could give you a very precise estimate of build time but would assume < 1 week
<seb128> doko, you shouldn't have to kill yourself over it
<seb128> but we shouldn't do it wrongly either before of manpower or buildd considerations
<seb128> we can probably find more resources if needed, would it be on the buildds on on people to help with the transition...
<doko> I still think this is too much overhead, choosing the very conservative road
<slangasek> seb128: to be clear, the concern with buildd power is that if the buildds can't keep up with the ppa, by the time the builds are done the builds will be stale because of source uploads to -proposed and we'll have to spend more human time rebuilding again
<doko> but fine, if you think you can do that ...
<seb128> well, there is no "very conservative"
<seb128> abi changes should lead to deb renames or soname change
<seb128> it's the only right way
<doko> no, the ppa unfortunately has priority, so any builds for the archive will be blocked
<slangasek> I don't see why this is unfortunate in this case
<slangasek> it's unfortunate when it's a different team's silo eating the resources ;)
<doko> heh
<slangasek> but it would still be a problem if a newer source package is in -proposed, regardless of whether it's had time to build
<doko> slangasek, seb128: if you do this, you should consider omitting these packages where debian considers to upload a new upstream with a soname change
<seb128> unsure
<seb128> it would mean delaying those packages until Debian does the uploads
<slangasek> doko: omitting those would mean stalling them in -proposed artificially; I think it's easier to just include them in the scripted rebuild
<seb128> which might be longer than we want
<doko> or just copy the new upstream to the ppa
<seb128> it doesn't hurt much to rename now to sync the new soname later
<doko> slangasek, I still doubt this can be all done until Friday, and then we'll have the problem with debian imports too, assuming the new ABI
<doko> Laney, did you figure out your py3.5 issue?
<seb128> doko, he's away now I think but I would assume he was waiting for a comment from you or he would have followed up to say he figured it out
<seb128> ok, on that note calling it a week
<seb128> I'm going to help as I can on that transition next week
<seb128> have a good w.e everyone
* vdrey changed the topic of #ubuntu-devel to: Archive: wily open | Devel of Ubuntu (not suport or app devel) | build failures -&gt; http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise -&gt; vivid | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
* vdrey changed the topic of #ubuntu-devel to: Archive: wily open | Devel of Ubuntu (not support or app devel) | build failures -&amp;gt; http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise -&amp;gt; vivid | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<vdrey> oops.
<slangasek> stgraber, hallyn: lxc has adt failures since the 22nd; I'm pretty sure the EPERM on overlayfs_mount is not caused by the python3.5 transition, but I don't particularly want to override these test failures for lxc itself.  Any ideas?
<hallyn> slangasek: assuming you're talking about dh-systemd liblua5.2-dev , i was assuming psivaa had some busted code there he was working on
<hallyn> (today was the first day i saw the failure email)
<hallyn> (assumption was due to:   )
<hallyn> + /home/psivaa/auto-package-testing/jenkins/run-autopkgtest
<hallyn> RSYNC_DEST not defined
<hallyn> yeah that must be something different as it passed the day before: https://jenkins.qa.ubuntu.com/job/wily-adt-squid3/23/
<hallyn> oh htat's jul 11
<slangasek> hallyn: mm? I'm talking about a failure of the lxc test case itself: https://jenkins.qa.ubuntu.com/job/wily-adt-lxc/lastBuild/
<hallyn> urgh
<hallyn> sforshee actually may have seen this before.
 * hallyn tries to find the kernel version
<hallyn> slangasek: i notice the console output is installing a new linux-image-generic, suggesting the current kernel is out of date?
<slangasek> hallyn: I assume the autopkgtest runs in a guest of some sort (chroot or container) so the linux package inside doesn't actually matter?
<hallyn> slangasek: doesn't matter unless the host kernel happens to be one with a overlayfs-related bug, or without the ubuntu sauce patch allowing this
<hallyn> (meanwhlie, trying it out in a vm here)
<hallyn> jiminy.  seems like i startd a trusty vm
<slangasek> hallyn: sure - the host kernel may have a bug, but an upgrade of linux-image-generic in the guest enviroment gives no clue whether that's the case
<hallyn> true.  but i still haven't found what kernel those things are running :)
<sforshee> hallyn: I'm trying to find that too
<smoser> is there a python friendly way of asking sysstemd "restart this service if it is running"
<smoser> if i just 'systemctl restart service', then it will start it even if not running
<hallyn> sforshee: current wily kernel fails for metoo
<hallyn> slangasek: confirmed here
<hallyn> sforshee: so does the kernel have the right version of eric's patch?
<sforshee> hallyn: I'm looking now to see what it has
<sforshee> hallyn: it has a patch to enable userns mounts, but apw is the author
<sforshee> hallyn: https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/wily/commit/?id=6a9e889d4a130e6445b0e9bbae2308dc4b139dfc
<slangasek> smoser: systemctl try-restart
<smoser> you'd think.
<smoser> i just saw that too
<slangasek> or maybe better yet, reload-or-try-restart
<slangasek> (or force-reload which is a synonym)
<hallyn> sforshee: hm, i don't know what i'm looking at.  i assume apw is EOW...
<slangasek> I guarantee that systemctl try-restart doesn't start a running service, because I just found a bug due to dh-systemd using it where it shouldn't :P
<sforshee> hallyn: likely. What patch from Eric are you talking about?
<hallyn> sforshee: while i was on vacation (i think it was then) you had replied to a patch by eric saying that it stopped you running  unpriv containers
<sforshee> hallyn: oh, yeah that was my mistake
<hallyn> Subject: Re: [GIT PULL] User namespace related fixes for v4.2
<hallyn> Message-ID: <20150706204748.GB22962@ubuntu-hedt>
<sforshee> that's 4.2 anyway
<sforshee> wily is still on 4.1
<hallyn> i figured it was some patch backported to stable and into 4.1
<sforshee> oh, you're right, it did hit 4.1 stable
<hallyn> hm, my syslog has:
<hallyn> Jul 24 19:58:45 lxctmp1 kernel: overlayfs: missing 'workdir'
<smoser> slangasek, yeah, i was looking at rsyslog, and it seems its getting socket activated which confused my tests.
<smoser> reload-or-try-restart
<smoser> does 'reload' there mean "have the system reload its config" or "have *systemd* reload its unit files"
<hallyn> sforshee: fwiw lxc always tries without workdir= first, and if that fails does overlay mount with workdir=
<hallyn> wondering whether th enew patch may be messing that up
<sforshee> that message definitely indicates that it thinks the option was missing, but that should fail with EINVAL, not EPERM
<slangasek> smoser: "Note that this will reload the service-specific configuration, not the unit configuration file of systemd." systemctl(1)
<smoser> yeah. thats what i want. just saw. thanks.
<hallyn> sforshee: sadly i'm gonna have to builda new vm with bigger disk to clone the wily source tree :(
<sforshee> hallyn: I'm getting a vm set up now to play with it.
<hallyn> sforshee: what's the best url to uses for git clone of the wily kernel tree?
<hallyn> https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/wily/ seems a bit wrong
<sforshee> hallyn: git://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/wily is what I used
<sforshee> hallyn: so I think lxc is mounting with the overlay fstype instead of overlayfs, and only overalyfs has FS_USERNS_MOUNT set
<infinity> Given that overlayfs in 4.x is implemented by overlay, that seems like an odd difference?
<sforshee> infinity: there's some backward-compatibility patch that apw wrote that does it. I'm not sure if this distinction is intentional or accidental.
<infinity> sforshee: I'd assume the latter.
<sforshee> infinity: maybe. There are differences between mounting as overlay and overlayfs in our kernel though, so I think I'll let apw make the call.
<infinity> sforshee: Well, the biggest differences are of the "overlayfs needs to pull some tricks to make overlay look like overlayfs" sort.  But yes, best to get Andy's input.
<infinity> apw: If you're still awake and care about anything anymore on this Friday evening ^
<sforshee> I'm about to stop caring myself
<hallyn> sforshee: no, lxc is using type 'overlayfs'
<hallyn> i think...
<hallyn> then again, no, that code is going backward
<hallyn> sforshee: 'overlay' was the old ubuntu-sauce one right?  overlayfs is the new one?  so 'workdir' should be used with 'overlayfs'?
<hallyn> there, maybe pulling out 20 lines of code will help
<infinity> hallyn: overlayfs is the old one, overlay is the new one.
<hallyn> it does!
<hallyn> infinity: hm, that's not good
<infinity> hallyn: We provide an overlayfs compatibility layer in the Ubuntu kernel, but upstream only has overlay.
<hallyn> sforshee: infinity: i suppose maybe apw's idea was that upstream doesn't yet support unprivileged mounts so 'overlay' shouldn't support it, only 'overlayfs' should
<hallyn> but it used to work with 'overlay' so this is a regression in functionality
#ubuntu-devel 2015-07-25
<doko> xnox, so for  #793222 I think I should at least break libboost-date-time1.55.0 unconditionally, not sure for the other libs. could you have a look at https://codesearch.debian.net/results/catch.*%3A%3Afailure%20package%3Aboost1.55/page_0 ?
<xpheres> hello
<xpheres> if anyone has an ubuntu touch device I will be happy if you write in reviews that my app actually works: https://uappexplorer.com/app/analyticaltranslatordemo.xpheresdev
<Laney> doko: trying a build with new dh-python
<Laney> but pyside does some renaming action itself
<doko> Laney, see my fixes for newt and comedilib
<doko> or let dh-python do the work
<Laney> looks like it just renames stuff so that dh-python will pick it up
<Laney> will check on the test build later
<doko> thanks
<xnox> doko: what do you mean break boost1.55? boost 1.55 should remain on 98 abi, otherwise it will be nuts....
<xnox> doko: boost1.58 is with C++11 abi and should be peachy, no?
<doko> xnox, please read the bug report, that's about not being able to catch an exception
<doko> so with libstdc++6 5.2.1-12, this may get broken in boost1.55
<xnox> doko: i'd rather have broken parts of boost1.55 and deal with that. i only see like 20 packages using boost-date-time
<doko> xnox, so I'll add the breaks?
<xnox> yes.
<doko> but just for the datetime package?
<xnox> doko: yes.
<xnox> doko: i don't see for other libraries to be affected.
<xnox> from codesearch.
<xnox> (there is like tests and examples)
<sforshee> hallyn: overlay is the upstream fstype, overlayfs is the legacy fstype in wily. As far as mount options go, the same code is used for both fstypes - if you supply upperdir then you also need workdir. I don't know how it worked in the past though.
<hallyn> sforshee: as i said above, 'overlay' is not supporting unpriv mounts now, 'overlayfs' still does.
<hallyn> 'overlay' used to, so it's a functionality regression
<hallyn> sorry, heading out right now
<teward> rbasak: infinity: so, i discovered something on the Apache package, they actually install to /usr/share and then have a postinst script that copies files around
<teward> (it's their solution to the /usr/share/... being written to by package managers problem...)
<teward> it's an interesting solution...
<teward> (for the default site)
<teward> ... and it's a solution i could adapt for nginx... with some work and testing, of course
<infinity> teward: Pretty sure I suggested that very same thing for nginx.
<teward> infinity: i didn't see that, sorry, but i wanted to check the logic :)
 * teward yawns
<teward> the side effect of bad-sleeping during the week: things're missed
<infinity> teward: With a caveat that it should only do so on new installs, and only if /var/www/html is empty (so you don't stomp over another webserver or user content)
<teward> right
<teward> infinity: there's checks for that too
<teward> in the apache implementation
<infinity> I would assume so, yes.
<teward> but my current focus is a trusty bug that should've been sqashed and i was too lazy to squish
<infinity> So, it probably should just do the same thing and be done with it.
<teward> right, that's my thoughts
<teward> can never have enough testing though
<ari-tczew> cjwatson: I've got an odd problem with builders. The package subtitleeditor has been built fine on PPA, but in wily-proposed got FTBFS. Could you check that?
<ari-tczew> PPA: https://launchpad.net/~ari-tczew/+archive/ubuntu/testing/+build/7725896
<ari-tczew> wily: https://launchpad.net/ubuntu/+source/subtitleeditor/0.52.1-1
<slangasek> ari-tczew: check the versions of the build-dependencies that were installed in the ppa, vs. the ones used in the archive?
<ari-tczew> slangasek: there is no build-depends installed in ppa
<slangasek> ari-tczew: that is categorically false
<slangasek> ari-tczew: what I mean is that you have build logs, which show you which versions of the build dependencies were installed and used for each build
<ari-tczew> slangasek: why versions should be different? PPA takes B-D from -proposed, doesn't it?
<slangasek> ari-tczew: a) that's a configurable setting, so not necessarily; b) the ppa build and the archive build didn't happen simultaneously so the contents may have changed in between
<ari-tczew> slangasek: the first what I pointed out is a count of build-depends. ppa gets only 13 packages, archive build gets 22, but I guess it doesn't matter
<ari-tczew> slangasek: can be it a problem related to gcc 5 ?
<slangasek> gcc5 has not landed in the archive
<teward> slangasek: that's still in testing first, right, before it lands?  What was the timeline on gcc5 landing, out of curiosity?  (I probably need to make sure nginx builds there)
<slangasek> teward: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2015-July/001143.html
<infinity> ari-tczew: Your PPA isn't configured with -proposed enabled, so it's not surprising that the results differ from an archive build.
<ari-tczew> infinity: I had no idea there is a way to configure it... thanks
<ari-tczew> Primary dependency added: Primary Archive for Ubuntu - PROPOSED
#ubuntu-devel 2015-07-26
<teward> slangasek: thanks
<nagromlt> no h yet for bt ?
<nagromlt> on ##crypto and #bitcoin
<nagromlt> no pussies
<Logan> I can't seem to figure out why gem2deb isn't building: https://launchpad.net/ubuntu/+source/gem2deb/0.20.1
<Logan> we have a new enough ruby-all-dev
<ScottK> It's apparently uninstallable.
<ScottK> Logan: the log won't tell you why. The easiest thing to do is to try and install it locally and see if it fails.  Keep a particular eye on trying to use packages from universe.
<Logan> okay, thanks! the log doesn't make it very clear that ruby-all-dev is not installable :(
<Logan> "not going to be installed" reads more like "I can't find it"
<Logan> hmm, it installs fine locally
<Logan> in fact, it's already installed on my box
<Laney> siretart: hi, can we drop the -dev package from libav maybe?
<Laney> package*s*
<infinity> Laney: Any ideas about the general sketchiness of the udisks2 force-removal test?
<infinity> Laney: Is that a bug in the test, or is the test correctly finding a bug in the code (or the system)?
<Laney> infinity: Don't know, hoping pitti will save us all when he comes back
<Laney> he's the udisks2 guy really
<infinity> Hahaha.
<Laney> I got as far as seeing "yup, that sure does hang locally"
<infinity> Laney: I'm tempted to let glib2 through, since it *seems* mostly unrelated, though it's crazy suspicious and weird that the pass/fail flip-flopped after the glib upload.
<infinity> (Used to fail on amd64, pass on i386, now it's the inverse, lolwut?)
<Laney> http://autopkgtest.ubuntu.com/data/packages/wily/i386/u/udisks2/20150722_172916@.log
<infinity> Laney: Yeah.  Ima leave proposed in its current state and let glib suffer for this one until we investigate more.
<Laney> glib and a kernel in there
<Laney> Might spend a few tomorrow running it interactively, but otherwise it'll be easier to wait, I bet. :)
<infinity> Kernel's certainly equally likely.
<infinity> Annoying, ci.debian.net only runs amd64, so that's not much use to compare against.
<Laney> Haha.
<Laney> It's skipped there anyway
<infinity> Oh, breaks-testbed.  Indeed.
<infinity> Wish the ci UI would call that something other than a "pass". :P
#ubuntu-devel 2016-07-25
<b4r> hi
<b4r> W: Possible missing firmware /lib/firmware/i915/kbl_dmc_ver1.bin for module i915
<b4r> is there a reason why kernel 4.7 is missing this module?
<b4r> I'm stuck on 4.6 because all the RCs and latest don't have the i915 module
<RAOF> I presume you're using the (unsupported âº) kernel-team mainline build PPAish?
<b4r> ok yes but why's the module removed? D:
<b4r> RAOF: so unsupported means I don't get to ask questions, period?
<RAOF> Oh, no.
<RAOF> Just to calibrate your expectations :)
<RAOF> That's not a module, either; it's some firmware data.
<b4r> at any rate I'll just take the config from the kernel and add support for myself
<b4r> just... unexpected :P since for kernels 4.6 and below it's been functioning just fine afaik
<RAOF> The likely reason is that we ship firmware in a different package; linux-firmware, and if that's a new file the packaging may need to be updated to include it.
<RAOF> Also: does that warning correspond to a problem you have? Because it's likely that the reason why 4.7 warns about it is that kernels prior to 4.7 didn't support that particular bit of thing.
<b4r> well after booting grub and selecting the kernel plymouth or something has a problem displaying graphics
<b4r> on my particular machine, actually what happened when I noticed the problem is I had ubuntu on a macbook and took the hdd from the macbook to a pc and the pc wouldn't display graphics
<b4r> came to realize it was due to the i915 support removal
<RAOF> Unless you've got a Kaby Lake Intel chip (which I think is as-yet unreleased?) that's not your problem.
<b4r> Display controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)
<RAOF> Yeah, this is very definitely not your problem.
<b4r> oh ok
<RAOF> Again, that warning is telling you that some firmware file that the i915 module *might* look for is missing; the filename strongly suggests that it's firmware for some part of Kaby Lake, the codename for the Skylake successor which apparently started shipping to OEMs a couple of days ago.
<b4r> dunno, I vaguely recall needed this particular thing (i915) support years ago when I was using gentoo and compiled kernels for this machine
<RAOF> Oh, yes.
<RAOF> You need the i915 kernel module.
<RAOF> But you've *got* the i915 kernel module.
<b4r> but why again cause that's where I'm lost
<b4r> you mean the package?
<b4r> I mean yes, it's installed
<RAOF> The kernel you have installed has i915.ko - that's why update-initramfs can notice that you're missing a piece of firmware it may try to load (but won't on your system).
<RAOF> It seems like you may have run into a kernel bug for old Intel graphics introduced in 4.7?
<b4r> sweet, where do I claim my prize :3
<b4r> I rarely find bugs, this is one of those times
<RAOF> First check out bugs.freedesktop.org; see if someone else has already run into it :)
<infinity> xnox: I'm not aware of anything doing so.
<pitti> xnox: that rings a bell; smb reported the same problem a while ago, trying to remember/find the report
<pitti> Good morning
<pitti> xnox, infinity: ah! bug 1543025
<ubottu> bug 1543025 in cloud-init "Wrong UTC zoneinfo in cloud-images" [High,Triaged] https://launchpad.net/bugs/1543025
<tyhicks> pitti: I may be able to work on the apparmor merge from debian - can you remind me what it is that'll be blocking you if it isn't merged soon?
<pitti> tyhicks: adding a native unit for it
<tyhicks> pitti: ok, I'm working on a yakkety apparmor upload and will take a look at doing the merge, too
<pitti> tyhicks: thanks, appreciated; this should hopefully reduce most of the delta
<cpaelzer> good morning!
<pitti> hey cpaelzer, wie gehts?
<cpaelzer> pitti: gut, Umzug gemeistert und es ist keinem zu sehr aufgefallen
<cpaelzer> pitti: Und irgendwie ist klassischer Montag - Ich brauch gefÃ¼hlt Stunden um der Mails Herr zu werden :-)
<pitti> cpaelzer: oh great -- moving on such a warm weekend doesn't sound like fun
<cpaelzer> pitti: good planning and half a year of prework made it a swift move - excluded the half hour where showers tried to make it less successful :-)
<smb> pitti, that tz file wrong was a result of cloud-init doing somethign
<smb> cpaelzer, for a second I was wondering what went wrong with *the* shower but then realized it was raining :) morning
<cpaelzer> smb: lol
<cpaelzer> sorry still in Germen-English mode
<cpaelzer> but most of those already awake will get it - to fill in for everyone rain-shower :-)
<pitti> smoser, rharper, lool: https://launchpad.net/~pitti/+archive/ubuntu/ppa has first netplan packages now; I guess for MaaS/cloud-init integration you want it in Ubuntu proper?
<pitti> ... except for a funny FTBFS, investigating
<pitti> smoser, rharper, lool: ok, built now
<doko> xnox, https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/1603436 is this fixed in cassandra ?
<ubottu> Launchpad bug 1603436 in python2.7 (Ubuntu Yakkety) "Regression in python2.7 SRU breaks python-cassandra" [High,Confirmed]
<xnox> doko, yakkety not-affected, test-building xenial package will throw it into the SRU queue in a second.
<flexiondotorg> Afternoon.
<flexiondotorg> mate-hud has been sitting in the NEW queue for a couple of weeks.
<flexiondotorg> Any chance that can get promoted? We'd like to land it for 16.10 Alpha 2.
<flexiondotorg> Actually, mate-hud is in the upload queue.
<pitti> I'll have a look
<flexiondotorg> pitti, ty
<pitti> flexiondotorg: etc/X11/Xsession.d/99mate-hud â why such an uber-high prefix?
<flexiondotorg> pitti, To ensure it follows 99mate-environment in the ubuntu-mate-default-settings package.
<flexiondotorg> If those are too high, first comment I've had on that, I can change both.
<flexiondotorg> But you it be possible to do that after Alpha 2?
<pitti> well, it's just getting a little thin to squeeze anything in between that and 99upstart
<pitti> most of these should come much earlier
<flexiondotorg> In that, I am short on time. But can commit to changing both next week.
<pitti> not a rejection argument, but changing existing conffiles is always a bit awkward
<pitti> it just jumped my eye
<pitti> flexiondotorg: well, the whole Xsession.d/ will go away at some point anyway :)
<pitti> (not being used with upstart/systemd or Mir/Wayland)
<flexiondotorg> pitti, Yep. I'm aware Xsession.d will go away. I've done my home homework on that.
<Laney> 99upstart~mate-hud
<flexiondotorg> I thik I'm ready to switch as the appropriate time.
<pitti> flexiondotorg: LGTM otherwise, accepted
<flexiondotorg> pitti, Thanks.
<flexiondotorg> I've noted yours and Laney comments in our Trello. Will revisit that high prefixes.
<ginggs> hi, can someone please tell me if there is anything more to be done for boost 1.60 transition? http://people.canonical.com/~ubuntu-archive/transitions/html/html/boost1.60.html ; supercollider seems to have built everywhere (despite what ben says), net-cpp FTBFS on armhf only
<cyphermox> good morning!
<ogra_> cyphermox, hey married man !
<ogra_> (congrats etc ... )
<cyphermox> hey ogra :)
<pitti> heey cyphermox
<pitti> cyphermox: how are you? had some nice honeymoon?
<cyphermox> yup
<seb128> oh, cyphermox got married?
<Mirv> the sped up armhf builders are the best thing since sliced bread
<cyphermox> doing well, just got through the mound of email
<seb128> cyphermox, congrats ;-)
<Mirv> oh wow, congrats cyphermox!
<cjwatson> Mirv: \o/
<cjwatson> wow, epic queue though
<cjwatson> I guess LP's queue estimates may still be based on older builders mind you
<pitti> cjwatson: at some point I'd like to move https://git.launchpad.net/~ubuntu-desktop/+git/systemd-graphical-session/commit/?id=402f7b73 (a staging project) into the openssh-client package itself
<pitti> cjwatson: however, this is still a bit in flux, it's not 100% guaranteed yet that it won't change again
<pitti> cjwatson: would you prefer that I upload this to ubuntu for now, and I'll submit it to Debian and we re-sync once the dust settles? or do you want it in the debian git right away?
<cjwatson> pitti: Would there be any compatibility concerns with having it in Debian?
<pitti> cjwatson: it's the systemd counterpart of /usr/share/upstart/sessions/ssh-agent.conf; however, I took the liberty of not using -s but running it in the foreground and using XDG_RUNTIME_DIR instead of /tmp/, for better debuggability and easier restarts
<cjwatson> pitti: (Also, I'd really prefer that to be an external script rather than a giant Exec...)
<pitti> cjwatson: no, this only applies to graphical sessions which get started via (user) systemd, i. e. zero in Debian right now
<cjwatson> pitti: Why do we need the "manual" override?  Presumably you're either using systemd as the session init, in which case this new service would be used, or upstart as the session init, in which case the old job would be ignored, not some mix of both?
<pitti> cjwatson: i. e. similar to the upstart job -- these are both just dead weight in debian now
<cjwatson> pitti: If we can have it in Debian without causing compat issues, I would rather take that road
<pitti> cjwatson: when using sytsemd, we add /usr/share/upstart/systemd-session/ to the XDG config dirs, so that we can replace one upstart job after another step by step without having to do a giant lockstep transition
<cjwatson> Oh, right, I see
<pitti> cjwatson: so for every job that we port, we add an override for it so that we don't run both the upstart job and the unit
<pitti> cjwatson: after we ported everything, we can then drop the upstart jobs and overrides of course; but TBH I'd keep it for a few months so that you can switch back and forth for debugging and in caes of regressions
<cjwatson> Sure
<pitti> cjwatson: ok, then I'll send a git format-patch against the debian packaging vcs to a debian bug at some point?
<cjwatson> pitti: The initctl commands might want a bit more of a guard to avoid stderr noise if initctl doesn't exist at all
<cjwatson> pitti: Yes please
<pitti> cjwatson: right, should rather use [ -x ] for those
<pitti> cjwatson: so you prefer breaking this out into an external shell script? ok (I thought 5 lines is some kinf of aesthetical limit)
<cjwatson> my preferred idiom is "if which initctl >/dev/null 2>&1" to avoid path hardcoding, but whatever
<pitti> *nod*
<cjwatson> pitti: it's maybe just on the edge, but I prefer not having to deal with quoting issues
<cjwatson> or even think about them :)
<pitti> ack, I'll clean it up
<cjwatson> like, I don't know the precise lexical rules for multi-line systemd unit directives OTTOMH
<cjwatson> pitti: we have a few other things in /usr/lib/openssh/ for this kind of thing
<pitti> I'll put it there
<Mirv> pitti: could you override http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtcreator - src:qtcreator-plugin-ubuntu is being removed and there is a transitional binary package of a newer version in that qtcreator upload
<pitti> Mirv: hmm, why doesn't that transitional package work then?
<pitti> apparently this makes ubuntu-sdk uninstallable
<Mirv> pitti: it does work butthat qtcreator-plugin-ubuntu autopkgtest is from the to-be-removed src? ubuntu-sdk is also likewise being removed in that ubuntu-touch-meta
<Mirv> bug #1604744
<ubottu> bug 1604744 in ubuntu-touch-meta (Ubuntu Xenial) "RM: src:qtcreator-plugin-ubuntu - SDK will be distributed separately" [Undecided,New] https://launchpad.net/bugs/1604744
<pitti> so why wouldn't we remove qtcreator-plugin-ubuntu instead?
<Mirv> new qtcreator conflicts with qtc-p-u and ubuntu-sdk
<Mirv> pitti: well yes that's what the bug is about, removing src:qtcreator-plugin-ubuntu, but it hasn't been done yet
<pitti> Mirv: I can do it now if you want
<Mirv> pitti: ok, that would be nice
<pitti> Mirv: removed qtcreator-plugin-ubuntu qtcreator-plugin-go
<pitti> Mirv: the ubuntu-sdk binaries will become NBS after ubuntu-touch-meta lands, I'll remove them then
<Mirv> pitti: thank you. yes, only the ubuntu-sdk-libs stays in ubuntu-touch-meta since it has other purposes
<pitti> Mirv: I'll watch it and nudge it later if necessary, but removing the source should suffice
<semiosis> infinity: good morning.  if you have a chance to look over bug 1605795 today I would appreciate any feedback.  it's my first SRU and I'd like to get it into shape for your team.  thanks!
<ubottu> bug 1605795 in livecd-rootfs (Ubuntu) "[SRU] livecd-rootfs ubuntu-cpc vagrant image builder" [Undecided,New] https://launchpad.net/bugs/1605795
<pitti> cjwatson: https://git.launchpad.net/~ubuntu-desktop/+git/systemd-graphical-session/commit/?id=289952  and we can use the same helper in the upstart job to avoid repeating the logic
<cjwatson> pitti: looks plausible at a brief glance at least
<pitti> cjwatson: I think I incorporated all your suggestions; thanks for the initial review!
 * pitti re-tests with upstart and changing that .conf to use the helper
<pitti> Mirv: ah, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtcreator landed now
<pitti> Mirv: touch-meta too
<Mirv> pitti: excellent, thank you
<pitti> cjwatson: patches sent to Debian bug #832445 now, and tested with all four scenarios (keyring-ssh or ssh-agent, upstart or systemd)
<ubottu> Debian bug 832445 in openssh-client "openssh: Rework upstart ssh-agent job and add systemd user unit" [Wishlist,Open] http://bugs.debian.org/832445
<cjwatson> thanks
<infinity> xnox:
<infinity> Setting up s390-tools (1.34.0-0ubuntu8.2) ...
<infinity> rmdir: failed to remove '/3770': No such file or directory
<infinity> xnox: ^-- WAT?
<pitti> isn't that 31337?
<pitti> Mirv: ah, cleanup time! http://people.canonical.com/~ubuntu-archive/nbs.html
<xnox> infinity, there is maintainer script to cleanup bogus /3770
<pitti> Mirv: (removed)
<xnox> infinity, i guess the maintainer script is bogus too.
<infinity> xnox: I've heard good things about /dev/null
<infinity> xnox: Especially since, due to the version comparison, that'll run on every s390-tools upgrade in xenial. :P
<xnox> infinity, fail
<xnox> infinity, i guess i should change that to lt-nl 1.34.0-0ubuntu8.1
<infinity> xnox: And redirect the scary to /dev/null, yeah.
 * infinity blames whoever reviewed your SRU.
 * infinity hopes it wasn't him.
<infinity> Oh, good.  It was Brian. ;)
<Mirv> pitti: thank you!
<smoser> hey.
<smoser> looking for input. i'm putting together a way to modify sources.list in ubuntu via cloud-init and curtin.
<smoser> we use the word 'pockets' in ubuntu, but sources.list(5) uses the word 'Sources'.
<smoser> are they 100% equivalent terms?  and if so, should i prefer the "official" word 'suites'
<smoser> bay.... s/Sources/suites/
<rbasak> I see suite as "series + pocket". I don't know if that is technically correct though.
<rbasak> And sources.list(5)'s use of "source" seems to mean "url + suite + components".
<rbasak> So I think all the terms mean different things.
<smoser> right. i used 'Source' completely wrong there.
<smoser> (see my s/Sources/suites/)
<rbasak> Ah
<smoser> it does seem more technically correct to use the word 'suite'
<rbasak> For your purposes I'd use "suite", since that matches apt's documentation.
<rbasak> And because it maps to a sources.list which you are generating.
<infinity> smoser: As rbasak says, "suite" is "series-pocket".  The "pocket" nomenclature is meaningless outside the launchpad context, from the POV of an apt mirror, suites are distinct things.
<smoser> right
<semiosis> infinity: hi again.  did you see my message from earlier this morning?  figured I'd address it to you since you're aware of the underlying bug/patch, and you're listed as the SRU vanguard for Monday (this is in re: bug 1605795)  thanks again!
<ubottu> bug 1605795 in livecd-rootfs (Ubuntu) "[SRU] livecd-rootfs ubuntu-cpc vagrant image builder" [Undecided,New] https://launchpad.net/bugs/1605795
<infinity> semiosis: Yeah, I've looked.  Someone should upload the SRU to the queue.
<semiosis> infinity: ok great.  is there anything else I should do at this time?
<infinity> semiosis: Find a sponsor to upload for you?
<infinity> semiosis: I guess I could be that sponsor, but then I probably shouldn't also be the queue reviewer. :P
<infinity> Odd_Bloke: Should https://bugs.launchpad.net/cloud-images/+bug/1581044 be fixed in xenial as well?
<ubottu> Launchpad bug 1581044 in cloud-images "Images ship with modified conffiles" [Undecided,Fix committed]
<infinity> Odd_Bloke: Possibly the sources.list fixups as well.
<semiosis> infinity: Odd_Bloke asked me to open the SRU, so I think he's for it :) https://irclogs.ubuntu.com/2016/07/22/%23ubuntu-devel.html#t15:21
<infinity> semiosis: Different bug. :)
<semiosis> ah that's a different bug. so you're asking about increasing the scope.
<semiosis> right
<infinity> semiosis: I'm suggesting that CPC has been slack on backporting fixes to xenial in general, and if we're doing a cloudy SRU of livecd-rootfs, we may as well roll them all in. :P
<semiosis> infinity: that sounds good to me if it doesn't take an eternity :)
<semiosis> but then again idk if one big SRU is easier to get through than several small SRUs, so whatever you think is best
<infinity> semiosis: The rcS and sources.list fixes would be trivial to test/validate, but I also understand the relative urgency of the vagrant thing, given the bad press (well, "press", social media anger, I guess) surrounding their breakage.
<infinity> semiosis: But one big one with a few easy-to-validate bugs is usually preferable, it's when you have two+ big changes to make that doing them together can be painful.
<infinity> semiosis: Anyhow, I'll see if I can get a yay/nay from Odd_Bloke, and then maybe do the backports myself, since he's off frolicking^Wworking in .nl.
<semiosis> infinity: thank you.  should i try finding someone else to sponsor/review my SRU now?  i'm thinking maybe rbasak or slangasek
<infinity> semiosis: Weeeeeell, I'm likely to do the backports from trunk to xenial, so once I've done that, I may as well upload.  I'll just nag someone else to do the queue review once I do.
<semiosis> infinity: awesome!  thank you so much.  let me know if there's anything else i can do
<infinity> semiosis: But normally, if the person you'd just nagged weren't so close to the project (ie: I own it upstream), the correct way to do this is to do the backports yourself, find a sponsor to do the upload, then talk to the SRU team once it's in the queue (or just be patient while we get to it).
<semiosis> thanks for that info.  i've only contributed packages to upcoming releases (glusterfs, in a past life) but never worked on an SRU before
<infinity> semiosis: Pretty much the same process as the devel series, really.  The only difference for an SRU is that every change needs to close a bug with the right SRU paperwork, and once it's uploaded, it gets stuck in a queue for review.
<infinity> semiosis: But the rest is the same deal.  Do the fixes.  Find a sponsor.  Iterate until sponsor likes your package.  Sponsor uploads.  Profit.
<semiosis> infinity: one thing i don't understand is how to backport changes to the version of livecd-rootfs in xenial... is there a specific bzr branch for that?  a different repository?
<infinity> semiosis: There's a different branch, yes.
<infinity> http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/xenial-proposed/changes
<semiosis> infinity: ah!  thank you.
<sarnold> pitti: hello :) the retracers seem stuck again, 1605954 still has a CoreDump.gz after ~two days
#ubuntu-devel 2016-07-26
<ahoneybun> is there a reason why we don't have a default IRC client?
<RAOF> Probably because it's fairly niche? We also don't have a default IDE :)
<teward> ahoneybun: ^ that, and also because what would you say should be the default?
<teward> xchat?  HexChat?  irssi?  KVirc?  Quassel?  There's too many to choose from, and individual users will have their own preferences of what they want to install.
<sarnold> irssi of course
<teward> sarnold: lol
<teward> sarnold: that works for server.  Answer for Ubuntu Desktop.
<ahoneybun> but we want people to contribute but no way to talk over IRC
<jbicha> I remember people were upset when empathy replaced pidgin by default
<Unit193> teward: Irssi.
<sarnold> teward: well you're right, i've been meaning to try out weechat for a few years now
<ahoneybun> HexChat is what I'm using now
<Unit193> ahoneybun: Hexchat generally for GTK, Konvi or Quassel for Qt.
<ahoneybun> I use Konvi with Kubuntu
<ahoneybun> but I have Ubuntu on this laptop
<ahoneybun> broke when moving to yakkety
<RAOF> I think we primarily want people to find Ubuntu *useful*.
<RAOF> Contributions are nice, but realistically our contributor base *should* be a tiny tiny fraction of our user-base.
<ahoneybun> us over at Kubuntu just put Kiwi IRC into our website
<jbicha> most of the Ubuntu flavors still ship IRC clients but their target audience is a bit different
<ahoneybun> on the support page
<RAOF> Yeah, there's no reason Kubuntu can't select and ship a default IRC client.
<jbicha> and Ubuntu included empathy until 16.04 so maybe the flavors will follow
<Unit193> RAOF: Well, IRC isn't just for Ubuntu, there's a lot more channels on Freenode alone, not to mention other networks.  Though yes, it's still a decently small userbase.
<ahoneybun> we do
<ahoneybun> Konvi is the default since 15.10 I believe
<Unit193> Xubuntu pretends Pidgin is an IRC client, stopped shipping Xchat a couple releases back.
<RAOF> Unit193: Absolutely; but I'd hope that the userbase of Ubuntu is at least a couple of orders of magnitude larger than the freenode userbase.
<sarnold> you can use a computer -without- irc? what would you do with it? :)
<Unit193> Hah, I'm sure it is, though I believe Freenode is one of, if not the biggest network.
<RAOF> That's rather my point âº
<Unit193> sarnold: Hmm.  Youtube and reddit I suppose?
<sarnold> Unit193: oh yes I see links to those all the time ;)
 * mwhudson rages at quilt
 * sarnold quilts at rage
 * RAOF is not disappointed to not have to deal with quilt very much anymore :)
<teward> sarnold: to answer your question: panic.
<mwhudson> also dos line endings
<sarnold> teward: hehe
<Unit193> sarnold: Also, I thought I might have killed you with my wall-o-text! :3
<sarnold> Unit193: it came close, I spent way too much time reading the specs and assorted docs and then fell asleep. (not kidding, it was warm, I was full..)
<Unit193> Haha, niiice!  Whoops.
<mwhudson> oh, and, apparently the x11 clipboard and/or vim
<sarnold> mwhudson: dos lineendings may be worth a "starter" patch in the series to remove all those terrible things in the whole project first, so all the other patches can then be normal
<mwhudson> sarnold: i seem to have prevailed but yeah
<mwhudson> well i don't know, i'm entirely making the patches by backporting commits from upstream master so i'm not sure if that would actually be less pain overall
<pitti> Good morning
<Unit193> pitti: Howdy.
<pitti> sarnold: they work in general, there is just an exception for this particular one; I added an apport task and the traceback to that bug
<pitti> hey Unit193
<tsimonq2> o/ pitti, how are you? :)
<pitti> tsimonq2: I'm good, thanks! how about yourself?
<tsimonq2> great pitti :)
<Unit193> pitti: Were you testing all the user sessions?  And I presume now  sctl restart user@1000  is a seriously bad idea now? :P
<pitti> Unit193: not all of them yet; I tested ubuntu, lubuntu, xubuntu, and kubuntu
<pitti> unity8 does not run on my system, and mythbuntu and studios are derivatives of xubuntu
<pitti> I still need to test them and provide .targets for those, but that should be easy
<pitti> s/derivatives of xubuntu/use an XFCE based session/ I mean
<Unit193> I poked studio and myth, seems Myth may stop doing an ISO.  And fwiw 'Xfce'. :P
<pitti> Unit193: but before that makes sense I'd first like to land the xubuntu conversion; I pushed it into xubuntu-default-settings, but didn't upload yet
<pitti> not sure, does xubuntu participate in alpha-2?
<Unit193> I don't think so.
<jbicha> Ubuntu GNOME won't be doing Alpha2 this time either
<pitti> I'm currently working on some upstart fixes, once they are in I can land the xubuntu conversion
<Unit193> Good to know, pushed the change I wanted first.
<pitti> Unit193: which change do you mean?
<pitti> tyhicks: the apparmor merge looks very simple (just adding handle_system_policy_package_updates in the init script and dropping notify-group.patch), I'll do that now
<pitti> intrigeri did a fine job of merging on the Debian side
<pitti> tyhicks: actually, notify-group.patch is correct -- /var/log/kern.log *is* owned by group "adm"; "admin" has been obsolete for may years; so even less delta :)
<pitti> and vcs-bzr: is very outdated, so I'll just drop that
<pitti> tjaalton: xserver-xorg-input-vmmouse was removed in Debian bug 831420; but xserver-xorg-input-all still Depends: on this; do we want to follow suit and drop it from -all?
<ubottu> Debian bug 831420 in ftp.debian.org "RM: xserver-xorg-input-vmmouse -- RoQA; obsolete and conflicts with kernel" [Normal,Open] http://bugs.debian.org/831420
<pitti> tyhicks: FTR, apparmor merge uploaded now
<tjaalton> pitti: once our kernel supports it
<tjaalton> not sure it does yet
<pitti> tjaalton: oh, so that was done in 4.5 or 4.6 in Debian?
<pitti> right, thanks
<tjaalton> guess so
<tjaalton> we're still on 4.4
<flexiondotorg> Laney, mate-hud arrived in the 16.10 archive yesterday.
<flexiondotorg> I've just uploaded an updated ubuntu-mate-meta that seeds mate-hud
<flexiondotorg> Is anything else required to recognise mate-hud as part of the Ubuntu MATE package set so I can upload updates in the future?
<Laney> flexiondotorg: You get someone on the DMB to re-run their script
<flexiondotorg> ty
<pitti> hallyn: hey Serge, how are you?
<pitti> hallyn: as I just orphaned systemd-shim in Debian, do you intend to orphan cgmanager in Debian? (https://s3hh.wordpress.com/2016/06/18/whither-cgmanager/)
<Odd_Bloke> infinity: Ah, yes, that should have been backported, yes.
<Odd_Bloke> infinity: And I'm multi-talented, I can work and frolic.
<nacc> rbasak: around?
<rbasak> yes
<nacc> rbasak: hey, so i was taking a look at LP: #1597414
<ubottu> Launchpad bug 1597414 in usd-importer "isc-dhcp cannot be imported" [Undecided,New] https://launchpad.net/bugs/1597414
<nacc> rbasak: isc-dhcp's publication history in debian is terrible :/
<nacc> rbasak: specifically, version going backwards repeatedly, the same version being published multiple times in the same series/pocket
<rbasak> nacc: if there are only a few packages that do this, then would a complicated override file be OK?
<nacc> rbasak: right, i think it's fine, but the issue is how do i tell the override file *which* 4.2.2.dfsg.1-5 has as publish parent 4.2.2.dfsg.1-4 and which has 4.2.4-4?
<nacc> that is, given a version and a package name, for isc-dhcp, i no longer have a unique entry in the publishing history
<nacc> (and a series)
<rbasak> OK, but the trees should still be identical I think, right?
<nacc> they should be yes
<rbasak> What would happen if we ignored the subsequent publishing history entries of the same version in the same pocket?
<nacc> i think that could work, but then `git log debian/sid` wouldn't match +publishinghistory
<rbasak> I can't think of anything we can do about that. My gut feel is that working around it would corrupt the data structure too much.
<nacc> agreed
<rbasak> Hopefully it's rare/historical.
<nacc> the tricky part is, though, i now would need to see if a version has already been imported -- in distro/series/pocket. But I don't do that check now, so it will need some new code (not a big deal, but not as trivial as I had hoped)
<rbasak> If you wanted to be really tidy you could add a git note to the commit to note that the version reappeared in the pocket and wasn't re-imported.
<nacc> yeah
<rbasak> Yeah I see the coding difficulty.
<nacc> but that's ok, i will see if i can sketch someting out
<Mirv> warp10: thanks! happy to be part of we-love-pitti.
<mdeslaur> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Xenial (16.04.1) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mdeslaur
 * dholbach hugs mdeslaur 
 * mdeslaur hugs dholbach
<hallyn> pitti: yeah, that's probably good.  what is the process?
<pitti> hallyn: https://www.debian.org/doc/manuals/developers-reference/pkgs.html#orphaning
<pitti> hallyn: it's filing an "orphaned" (or "rfa") bug and uploading the package to change the maintainer (or not if you just set it as RFA)
<pitti> hallyn: or, if that makes more sense, perhaps file a request to remove the package and RC bugs against the reverse deps
<pitti> depends on what the future should be -- is it "I don't want to maintain this any more", or "it does not make sense to keep this"
<hallyn> pitti: ok thx, i'll think about it.
<pitti> rdepends> systemd-shim only; libpam-cgm is from cgmanager, lxc is only a recommends (and probably wrong these days)
<hallyn> i still may change my mind and decide to rewrite it and change the scope a bit :)
<pitti> hallyn: no hurry or urgency of course, it just caught my eye and I was wondering what the future plan is
<hallyn> yeah
<hallyn> the plan is *probably* to either orphan it, or expand its scope to be a more complete complement to upstart (i.e. offer a bit more management)
<hallyn> although if i do the latter it may not be appropriate for debian since it appears to have actively turned against anything alternative to systemd
<pitti> there's still sysvinit
<hallyn> yeah i'm going to let this thought sit in the back of my head and leave a note to do it in two weeks
<pitti> but nobody really maintains it; but it's the reason why systemd-shim is still a thing in Debian
<pitti> hallyn: sounds good, thanks!
<hallyn> pitti: sorry, pls remind me,
<hallyn> why do sysvinit ppl want systemd-shim?  which pice of userspace requires that?
<pitti> hallyn: pretty well every desktop these days talks to logind for session tracking, suspend, reboot, screensaver management etc.
<hallyn> all right, made a note, i plan to act on aug 9 :)
<pitti> hallyn: with systemd-shim you can use logind (and also timedatectl/hostnamectl, for settings) under sysv
<hallyn> i'm wondering how deep that goes,
<pitti> that was the main driver for it as CK got abandoned long ago
<hallyn> i.e. if it's just "kde and gnome", or if it's library pices that even i3 users etc would need
<pitti> my suspicion is that shim could probably work without cgmanager or cgroups at all
<hallyn> but you're abandoning shim anyway
<pitti> and just provide stubs for the calls
<pitti> yes, me personally, but this is a case where "orphan" is right, not removal
<pitti> as it's clearly useful still
<hallyn> ok
<pitti> I just don't have time/motivation to work on it myself
<hallyn> \o
<pitti> hallyn: does lxc need it on sysvinit? (I thought not, it does all the cgroup handling by itself)
<hallyn> pitti: not if there is cgroup namespaces or lxcfs
<tyhicks> pitti: ah, thanks
<tyhicks> pitti: I had done the merge, incorporated it with my other pending changes, and was going to test today
<tyhicks> pitti: it should be easy to rebase them onto your upload though
<tyhicks> (I'll also make sure that we came to the same conclusions on the merge)
<pitti> tyhicks: urgh, sorry; feel free to upload over mine, it is (and will still be for a while) stuck in -proposed anyway
<pitti> tyhicks: most of the work really was about reviewing the delta, and it's just that one which was left
<pitti> seb128: any chance I can bribe you to source-NEW review nplan?
<pitti> (not sure if you are still doing archive admin)
<seb128> pitti, I sortof do, no official shifts but every now I pick some reviews and I'm happy to help/reply to ping ... looking!
<pitti> seb128: thanks; it's small
<seb128> pitti, looks fine, no COPYING but I guess debian/copyright cover it ... but don't we usually use license 3 rather than 3+ for Canonical projects? (also why LGPL and not GPL if it's a standalone generator)
<pitti> seb128: ah, I'll add COPYING; LGPL? I intended GPL
<seb128> pitti, License: LGPL-3.0+
<pitti> seb128: please reject, I'll reupload
<seb128> k
<seb128> pitti, looks good otherwise
<seb128> pitti, just give me a nudge once reuploaded
<mdeslaur> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Xenial (16.04.1) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<pitti> seb128: back in the queue
<seb128> pitti, no it's not...
 * pitti hugs seb128
<seb128> ;-)
 * seb128 hugs pitti back
<mterry> cjwatson, so...  I have this testing silo PPA (landing-030).  It has only a few unity8 packages in it, and LP agrees.  But apt sees (abandoned?) click packages and LP built the u8 in the PPA against some beta version of Qt that isn't in the PPA.  I was clearing some of the click binaries out of it before I realized I should probably ask what is happening in there
<mterry> I'm looking at yakkety specifically, but it may affect other series
<cjwatson> good question
<cjwatson> can't just be a deathrow failure since the packages are still referenced from dists
<cjwatson> source is deleted, binary not
<mterry> yeah I thought that was odd
<pitti> seb128: just saw that I forgot to add copyright/license headers to the source files; done in git now
<pitti> seb128: and there was an unstable test which caused ftbfs on ppc64el, also fixed
<cjwatson> grepping logs
<cjwatson> mterry: ah, I see.  nothing sinister; the problem is that the landing was abandoned while stuff was still in the process of publishing, so the binaries weren't quite there for LP to delete
<cjwatson> mterry: I'll delete them manually
<mterry> cjwatson, oh cool thanks
 * mterry is glad LP isn't busted  :)
<cjwatson> mterry: I don't see the Qt packages you mention though
<cjwatson> maybe you removed those already?
<mterry> cjwatson, I didn't...  I also don't see them via apt.  But u8 is built against them.
<cjwatson> mterry: link to the build?
<mterry> cjwatson, ah.  qt is in proposed, that's what happened
<cjwatson> yep
<cjwatson> mterry: done all the remaining click removals now (pending publisher)
<mterry> cjwatson, thanks!
<seb128> pitti, ok, I noticed the lack of header in the sources but didn't want to nitpick on it since they are all under the same author/license/copyright
<pitti> seb128: the queue has some binaries now
<seb128> hum
<seb128> pitti, I don't understand https://launchpad.net/ubuntu/+source/nplan/0.1
<pitti> still waiting on arm, though; powerpc failed, need a porter box for that (but also, not urgent at all)
<seb128> oh, you uploaded 0.2
<pitti> seb128: I rejected the two binaries; yes
<seb128> k, sorry I was looking at the wrong page
<seb128> pitti, I usually wait for all the archs to be done, queue estimate is ~10minutes for the armhf/64, ok to wait for those?
<pitti> seb128: absolutely
<philroche> nacc: Could you have another look at lp:1581200 please. I'm in need of an upload for cloud-init on trusty.
<seb128> pitti, great, going to look again in half an hour or so then
<LocutusOfBorg> hi pitti , thanks for the apparmor merge
<LocutusOfBorg> for next time, can you please think about dropping all the breaks+replaces against apparmor?
<LocutusOfBorg> Breaks: apparmor-easyprof ( << 2.8.95~2385-0ubuntu1 ), apparmor-utils ( << 2.8.95~2385-0ubuntu1 )
<LocutusOfBorg> I think they can be dropped together with the one against debhelper
<pitti> LocutusOfBorg: this should be done in Debian; I don't want to introduce extra ubuntu delta for such cleanup, as it has no runtime effect
<pitti> seb128: ok, I now have a nice segfault to debug on arm64 and powerpc :)
<LocutusOfBorg> I tried to explain that here https://lists.debian.org/debian-backports/2016/07/msg00085.html
<LocutusOfBorg> but the Debian maintainer didn't understand that
<LocutusOfBorg> so maybe if you can explain or add your opinion he will drop it :)
<LocutusOfBorg> I agree about keeping delta minimal
<LocutusOfBorg> I'll open a bug
<seb128> pitti, it failed on arm* so builds done, binNEWed it
<pitti> seb128: thanks; I'll debug this tonight or tmw on a porter box
<seb128> yw!
<LocutusOfBorg> cheers
 * LocutusOfBorg leaves
<nacc> philroche: ah I see, sorry about that!
<philroche> nacc: No problem
<sarnold> pitti: thanks for investigating the unhappy retracer :)
<pitti> rharper, lool, smoser: FYI: nplan | 0.2 | yakkety/universe | source, amd64, i386, ppc64el, s390x
<pitti> this should unblock some cloud-init/maas development hopefully?
<smoser> pitti, well, sure :)
<smoser> thanks.
<pitti> smoser: this doesn't have an "apply changes now" button yet, that should follow soon
<smoser> pitti, ok. i will try to take a look sometime soon
<smoser> hey... anyone know how i would switch from bzr to git and squash the "merged" commits that would be hidden ?
<smoser> ie, bzr --include-merged shows a ton of things that i dont want on primary 'git log'
<smoser> and 'bzr log' would have hidden
<dobey> smoser: you'd have to manually go through and squash them i guess. not sure if bzr-git or git-bzr would have something for it
<smoser> how woudl i even do that ?
<smoser> https://www.fusonic.net/en/blog/migrating-from-bazaar-to-git/ solves my other desire
<dobey> git rebase -i with appropriate revision specification arguments i guess?
<smoser> which is to not lose --fixes
<dobey> hmm
<dobey> preserving metadata would indeed be nice when migrating
<dobey> of course, git commit doesn't have a --fixes :-/
<smoser> 3597 commits in total 1258 that are bzr "top level" commits
<smoser> not something i can do by hand
<smoser> that link basically just converts the fixes metadata into some string
<smoser> which is not as nice as specific metadata, but acceptable
<dobey> right
<dobey> real metadata would be much nicer
<rbasak> smoser: squashing them doesn't really seem right. bzr doesn't show them by default but has the info. git also has the info but does show them by default. So it's just the default view mode, and to me that doesn't justify changing the commit graph itself.
<dobey> also that, yeah
<smoser> rbasak, you'd rather see 'fix spelling' , 'whoops'
<smoser> interwieved with actually useful information
<smoser> i'd rather not see it. i dont like losing the data either.
<smoser> but every day usage includes 'git log' and i'd rather not have garbage there.
<rbasak> smoser: so use git log --first-parent.
<rbasak> smoser: and ask submitters to squash out mistakes before merging, like the Linux project requires.
<rbasak> As for bug number metadata, in the git world we create a pseudo-header in the commit message for this kind of thing. Ideally Launchpad would define the header name, and then all tooling could use that.
<rbasak> Perhaps it should be "Launchpad-Bugs-Fixed" after what we already do in changes files. As a bonus the syntax would be identical.
<smoser> rbasak, sure. thats fine... and that is waht that fusonic.net url does
<rbasak> It might be worth filing a bug against Launchpad asking for a commitment to a particular syntax, so that we can start using it now, eg. for your import.
<rbasak> smoser: yes, but looks to me that it sticks it into the subject line.
<rbasak> I wouldn't do that.
<smoser> well, it has to convert actual metadata into some string
<smoser> and just put that string in the commit message
<lool> pitti: \o/
<smoser> so it doesnt really matter what it does
<lool> pitti: well done on landing nplan
<smoser> i dont care about the specifics.
<rbasak> It should be in the commit body under some common syntax, since we want tooling to pick it up.
<pitti> lool: merci
<rbasak> Otherwise bugs won't auto-close when Launchpad learns how to do that.
<smoser> rbasak, sure. but i dont really care what that syntax is now. i just care that it isnt lost.
<rbasak> You don't care about losing consistency when you have to change to a different syntax in the future? That surprises me, but OK :)
<smoser> rbasak, well, my option is to wait until some standard is created ?
<smoser> given "wait a few weeks" compared to "have something acceptable now" i'll take the later
<rbasak> It looks like it's already defined as it happens. One moment.
<rbasak> http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/view/head:/lib/lp/soyuz/enums.py#L40 I think
<rbasak> From https://code.launchpad.net/~cjwatson/launchpad/git-update-related-bugs/+merge/298369
<rbasak> "I've intentionally used the same regexes that Soyuz uses to parse changelogs, for compatibility with package branches and because it's reasonably compact in commit messages."
<rbasak> So: "LP: #123" or "LP: #123, #456" I think?
<rbasak> cjwatson: ^ is that right, please?
<ubottu> Launchpad bug 123 in Launchpad itself "There's no direct way to see the project info when translating it" [Medium,Fix released] https://launchpad.net/bugs/123
<ubottu> Launchpad bug 456 in libgtk-java (Ubuntu) "Unable to upgrade #2" [Medium,Fix released] https://launchpad.net/bugs/456
<rbasak> (technically it looks like it's under review, rather than defined)
<smoser> well, LP: # is what i probably woudl have picked anyway :)
<smoser> rbasak, first-parent is nice. thank you.
<cjwatson> rbasak: That's correct.
<cjwatson> (Under review, as you say.)
<vooze> Hi, I have found a big bug in pulseaudio, and I have found out the ubuntu-touch patches are the reason for the break. How can I get some focus on it? Here is bug report with fix: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1589401
<ubottu> Launchpad bug 1589401 in network-manager (Ubuntu) "cannot view wifi networks after re-enabling wifi" [High,Confirmed]
<vooze> oh shit, wrong bug report.
<vooze> https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1574324 here you go :D sorry
<ubottu> Launchpad bug 1574324 in pulseaudio (Ubuntu) "pulseaudio crashes when connecting to bluetooth headphones" [Medium,Confirmed]
<rbasak> cjwatson: thanks
<rbasak> vooze: it would probably help if you can identify which of those patches causes the regression. It's difficult for developers to do if they don't have your exact hardware.
<rbasak> vooze: once identified, we can ask the person who introduced the regressing patch to look into it.
<cjwatson> rbasak: The other thing to note is that in general, or at least to start with, LP will only bother scanning for bug links in commit messages when you make a merge proposal, unlike the bzr behaviour where we (very expensively) scan and link every commit in every branch.
<cjwatson> I think this is defensible but it's still a behaviour change.
<rbasak> cjwatson: OK. I appreciate the work you're doing on this. It would be nice if the bzr behaviour arrived for git repos in the end though.
<cjwatson> rbasak: Since that's very expensive, I'd like to have a compelling reason.
<rbasak> Why is it expensive?
<rbasak> Could it be made cheaper if it were only done on pushes that were fast forwards of relatively few commits? Even then it'd be very useful.
<cjwatson> There are a lot of very deep histories out there, and it would involve a lot of database rows.
<rbasak> Or would that be too confusing?
<cjwatson> The bzr implementation is essentially disastrous.
<cjwatson> It could be done less badly, but still ...
<vooze> rbasak: I see.. That's gonna take a long time. But I guess I will do it if i'm bored tomorrow. That was the answer I was afraid of :D
<cjwatson> The other complexity is that git branches may pretty much go away at any time, from Launchpad's point of view, so we don't link objects to them in persistent ways.
<rbasak> Oh, I may be talking about something else.
<cjwatson> The bit that would be difficult is working out what branch a commit is most relevantly in.
<rbasak> I'd like auto-close really. I'm not sure linking a branch automatically makes sense in git land unless submitting an MP.
<rbasak> But if I push a branch to a repo that closes a bug, I'd like the bug to autoclose. Without an MP, I'd be happy to not also have a linked branch.
<cjwatson> Ah.  We've never done that in bzr because the policy is complicated.
<cjwatson> Some projects want that kind of thing and some don't.
<vooze> rbasak: And thanks for the answer. What should I do when I find the patch that's causing it?
<cjwatson> Launchpad itself probably wouldn't, for instance; we only want to close bugs when we actually deploy the fixes, not just when they land on master.
<rbasak> So, a naive implementation that would make me happy is just effectively a post-receive hook that scans new commits for bug references and autocloses those bugs. No need for branch links there, so I imagine that would be fairly independent of your branch linking work.
<cjwatson> But presumably only new commits on some nominated branch.
<rbasak> I see. The policy difficulties you mention do make sense. So I guess it's non-trivial to work out a scheme that allows per-branch configuration of this.
<cjwatson> I'm not ruling it out or anything, just saying that it isn't actually the bzr behaviour and it is indeed somewhat complex to work out.
<cjwatson> I know GitHub does this, so I'm sure some projects are used to it.
<cjwatson> I wonder what they do in terms of policy.  Surely can't just be that pushing a commit to any branch with the right kind of commit message does it.
<rbasak> It wouldn't surprise me if that's what they do.
<rbasak> But I appreciate your point about doing it right.
<rbasak> How about: it is configured per-branch, and you explicitly enable it for a project, and specify for that enablement whether it should auto "Fix Committed" or "Fix Released".
<cjwatson> https://help.github.com/articles/closing-issues-via-commit-messages/ says it has to be in the default branch.
<cjwatson> We do have a similar notion of the default branch for a repository.
<cjwatson> There are somewhat different scoping issues for Launchpad, though.
<rbasak> By "enable it for a project", I mean that you specify the project.
<cjwatson> GitHub tracks issues per-repository; Launchpad tracks them per-project (etc.), and a project may have many repositories.
<rbasak> Right, so user/group->repository->branch could have a "close *this* project's bugs" option.
<rbasak> vooze: ping whoever introduced the patch on IRC maybe? Feel free to ping me if you need help with that.
<cjwatson> My inclination would be to make it be a thing that only works for the default branch in the default repository for the target (both concepts we already have), and to be a checkbox.
<cjwatson> Or a similarly small piece of config.
<rbasak> vooze: see "bisection", eg. with ~28 commits, it should only take about six builds, I think.
<rbasak> cjwatson: I'd be fine with that too for all my use cases, I think.
 * rbasak goes to bed
<rbasak> Thank you for the discussion. I appreciate it.
<vooze> rbasak: Awesome. Just to be sure, you mean Like, first patch all with 02XX and then 03xx ?
<cjwatson> rbasak: I won't get to this very immediately since it's not on the critical path for converting Launchpad itself to git (which was my motivation for the work so far), so I'd appreciate a reminder bug with a summary of this, when you get a chance
<cjwatson> rbasak: (I mentioned that the bzr implementation is expensive - we estimate that the cost of the infrastructure for all this for Launchpad itself's branches is something on the order of a couple of hundred GB of database space, so we very much want to get ourselves off it!)
<rbasak> vooze: the patches stack on top of each other and may not be independent. So I'd patch the first half but not the second half. If that succeeds, patch the first three quarters and not the last quarter, or if it failed, patch the first quarter and not the the last three quarters. And then go to eighths, and so forth. See http://manpages.ubuntu.com/manpages/xenial/en/man1/git-bisect.1.html. You'd do
<rbasak> the same thing, except that it's probably easier to do by hand then try and crowbar git into doing it for you in this case.
<rbasak> vooze: this way, eventually you should pin it down to the addition of a single patch, I think within about six iterations.
<rbasak> cjwatson: I'll file a bug, thanks.
 * rbasak leaves himself a reminder for tomorrow
<vooze> rbasak: ah, I see :) that's pretty smart. I will for sure do that :)
<cjwatson> cheers
<vooze> I was afraid, I had to do like 30 builds ;)
<cjwatson> Bisection is great.  When it works, anyway.
<vooze> Can I easily reload pulseaudio after installing new build, so I don't have to reboot?
<vooze> nvm, figured it out.. Anyway, I will do some builds tomorrow. It's late in Denmark, I'm too tired for it now.
<vooze> Thanks for all your  help!
<mwhudson> oh man BranchRevision
<wgrant> mwhudson: It has several rows now.
<wgrant> Several billion.
<mwhudson> wgrant: somewhere on the impressive/depressing continuum
<wgrant> mwhudson: Postgres handles our 1TB DB admirably...
<wgrant> And more than half of that is BR.
#ubuntu-devel 2016-07-27
<infinity> Logan:  http://launchpadlibrarian.net/275043606/funny-manpages_1.3-5.1ubuntu1_1.3-5.1ubuntu2.diff.gz <-- What's wrong with this diff? ;)
<infinity> pitti: amd64 autopkgtest queues seem stuck.
<infinity> pitti: Oh, lcy01 is completely dead.  If amd64 autopkgtest uses that region exclusively, that would explain the stall.
<infinity> pitti: And while I'm pinging you, there seem to be a mess of trusty langpacks sitting in the queue.  I kinda assumed you'd be dealing with those. :)
<pitti> infinity: yes, Qt 5.6 + dead lcy01 == tests take forever..
<pitti> infinity: oh, I thought I accepted all trusty langpacks
<pitti> infinity: sorry, will process the rest
<pitti> infinity: meh, the cleanup/restart script stumbled over "nova list" failing; fixed that now, so the other clouds keep running
<infinity> pitti: Seemed curious to me that the i386 queue emptied before the amd64 one.  I would have expected them to drain in parallel.
<infinity> pitti: We were very careful about this with shared queues in lp-buildd land, FWIW, to make sure that, all things being vaguely equal, upload 1 would get all its builds out before upload 2, etc.
<pitti> infinity: britney issues the requests in architecture order, so i386 is always a bit ahead indeed
<pitti> maybe this could use some more shuffling
<pitti> the main source of imbalance is the retry-autopkgtest-regressinos script though
<infinity> pitti: Ahh, see, I'd expect "testing foo triggered by bar" would queue foo/trigger on all arches, then move to quux/trigger all arches, etc.
<pitti> that generates stuff sorted by architecture first
<infinity> pitti: So, for shared pool arches, they'd together.
<infinity> Ish.
 * infinity shrugs.
<pitti> britney is per-excuse first, then per architecture, then all the triggered tests for that excuse
<infinity> pitti: Minor frustration to be waiting on one arch column for all packages instead of two arch columns for half the packages.
<pitti> yes, indeed; but it's not nearly as bad
<infinity> pitti: Oh, not sure if I told you, but mvo and I sat down and fixed snapd autopkgtests.
<infinity> pitti: I'm waiting to see the results on amd64 before I close LP: #1599799 but the successes on i386 and ppc64el look promising.
<ubottu> Launchpad bug 1599799 in snapd (Ubuntu) "snapd > 2.0.2 fails on yakkety" [High,Triaged] https://launchpad.net/bugs/1599799
<mwhudson> ooh
<mwhudson> infinity: what was the problem?
<pitti> nice!
<infinity> mwhudson: Exactly what they error message no one read said the problem was.
<infinity> (They created new units and didn't run daemon-reload)
<mwhudson> heh
<mwhudson> i did _ask_ about that
<mwhudson> but i didn't check
<infinity> I consider it a pretty glaring misfeature in systemd that they wrote a *Linux-specific* init system and didn't think to, I dunno, leverage inotify correctly.
<infinity> But whatever.
<infinity> The number of times we reload that daemon to clear the cobwebs from its internal state is insane.
<pitti> this wasn't the error I saw in https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1599799/comments/12
<ubottu> Launchpad bug 1599799 in snapd (Ubuntu) "snapd > 2.0.2 fails on yakkety" [High,Triaged]
<pitti> basic-binaries.block[12533]: unable to bind /snap/ubuntu-core/current//bin to /bin. errmsg: Permission denied
<pitti> that wasn't a missing daemon-reload
<mwhudson> i think that one was a snap-confine bug
<infinity> Yeah, different bug than the one originally reported.
<infinity> But both seem fixed.
 * pitti stares at the autopkgtest queue and o_O's
<pitti> ooh, new perl
<infinity> Yeah.
<infinity> I shouldn't have retried the arm64 build. ;)
<infinity> Now I have no chance of getting my own retries in.
<infinity> Oh well.
<pitti> infinity: if it's blocking, I can remove all the perl tests and we re-trigger them later
<infinity> pitti: Shouldn't be.  I'm just waiting for the snapd/amd64 result, which is currently in limbo.
<infinity> pitti: If it comes back successful, I'm happy.
<pitti> weird, it hasn't run yet and it's not in the queue
<infinity> It disappeared from the queue about 10m ago.
<infinity> I assumed that meant it would, I dunno, run.
<pitti> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety?format=plain&prefix=yakkety/amd64/s/snapd
<pitti> nothing from today yet
<pitti> I suppose an lcy01 worker tried to catch it and is now caught in its "retry three times until I give up" loop or so
<infinity> What happend after that?  End of the queue, or punted to another builder, or dropped on the floor?
<pitti> ah no, it's working
<pitti> err, running
<infinity> s/happend/happens/
<pitti> it just doesn't show on running.shtml for some reason
<infinity> Because running.shtml is 10m old?
<infinity> Err.
<infinity> Older.
<infinity> 18m.
<pitti> 18 mins
<infinity> pitti: I'm curious why the debci pages are static generated instead of cgi.  Just trying to be load-friendly?
<pitti> infinity: I suppose so; it's quite expensive to generate them, as it shows the entire history of a package
<infinity> pitti: Hrm.  But, it seems to generate them even when it doesn't have to, so I'm not sure I buy the load argument now. ;)
<infinity> pitti: Picking, say, http://autopkgtest.ubuntu.com/packages/p/postgresql-9.5/ at random, no tests run for two days, but page generated 15m ago.
<pitti> well, I don't know :)
<infinity> pitti: Given the relative infrequency of tests, it would seem smarter to do a shallow "when was the last test run?" compare to a timestamp of a cached earlier-generated page, serve from cache if not stale, generate on the fly if stale.
<infinity> Ish.
<pitti> infinity: I can't say I like the current design either; it creates literally millions of little files which keeps hitting the "max inodes" ceiling
<pitti> and it's expensive to generate indeed
<infinity> xfs to the rescue?
<pitti> but yeah, it was that or "write it yourself" :)
<infinity> I'd have been inclined to write it as a perl/python/php/cgi/whatever and dynamically generate the mess from a DB.  But that probably says more about my background than my taste.
<pitti> infinity: I think excuses.html is the main thing devs should look at (and it's completely independent of debci); other than that, I could cobble together a simple CLI thing to query past results, but I'm afraid I'm too loaded with other stuff to rewrite a web UI :/
<infinity> pitti: Heh, I'm not suggesting you fix it, just making idle banter.
<infinity> pitti: Besides, every page does point me at the git repository, if it really pisses me off enough.
<infinity> pitti: Not that I'd go replacing the backend, ain't no one got time for that, but fixing the caching mechanism to not be constantly uselessly stale wouldn't be too hard.
<pitti> infinity: it actually would be -- this would be changing the thing from the ground up
<infinity> (Though, as it scales up, replacing the backend with a proper DB seems sane)
<pitti> infinity: so, I don't think there's any way around downloading the entire metadata from swift as that takes an awful amount of time
<pitti> but generating html and the indexes dynamically would be great indeed
<pitti> right, sqlite or so would certainly beat individual files :)
<mwhudson> i'm sure there's some shiny nosql db we could use
<infinity> I need to read up on nosql stuff to understand why I'm supposed to like it.
<infinity> THere's enough psql deployed in Debian and Canonical that that would have been my first choice.
<pitti> infinity: no prob to add psql to the charm for sure
<infinity> pitti: But, in the current architecture, the obvious fix would be to trigger page generation on incoming scraped results, rather than batch regenerating the world on a timer.
<infinity> "Oh look, a psql result" -> regen psql page.
<infinity> As it is, it does ALL the pages.
<infinity> Which is daft.
<pitti> infinity: so if we can talk slangasek into allocating three days for that, we should invite terceiro and fix this up properly
<pitti> infinity: I know terceiro has also hit the inode limit, and I'm sure the load on ci.debian.net is similarly high
<infinity> pitti: Hahaha.  That reminds me.
<pitti> infinity: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/amd64/s/snapd/20160727_073957@/log.gz
<pitti> PASS
<infinity> pitti: ci.ubuntu.com still has a link in the top bar ([Proposed]) to the old jenkins-driven autopkgtest infra.
<infinity> pitti: Who owns that?
<infinity> pitti: It should point to autopkgtest.ubuntu.com, probably.
<pitti> uh, oh, look behind! a three-headed monkey!
<pitti> jibel: do you know who owns http://ci.ubuntu.com/ ?
<infinity> pitti: And yay on the pass!
<pitti> this looks so out of date, I doubt it's still useful at all
<infinity> pitti: Hrm, indeed.  http://ci.ubuntu.com/smokeng/ seems to stop at wily.
<infinity> pitti: How did the user session sprint go?
<infinity> pitti: Will we reduce 'reverse-depends upstart' to zero by release?
<infinity> Well, zero except for the things with 'upstart' in the name. :P
<pitti> infinity: yes, we should; with the PPA the only thing that still needs it is the lightdm unity greeter session, which isn't too hard to fix
<pitti> infinity: we converted most things and they are currently being landed
<infinity> pitti: Awesome.
<pitti> there's a big CI train silo, and landing gnome-session/xubuntu-default-settings etc. is blocked on landing upstart in -proposed and systemd 231-1
<infinity> upsart seems to just be waiting on autopkgtests.
<pitti> which is in turn blocked by apparmor in -proposed and the new mdadm xnox is working on (although if that doesn't happen soon enough it's simple enough to upload a workaround in systemd itself until that happens)
<pitti> so, just a few days unti the dust settles
<infinity> Though, I'm suspicious that the upstart autopkgtests may have disappeared.
<infinity> Since I don't buy that the ppc64el tests have been "in progress" since yesterday.
<pitti> infinity: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/ppc64el/u/upstart/20160513_104747@/log.gz
<pitti> apt segfault and corrupted cache, I retried it this morning
<pitti> before the perl flood I think
<pitti> anyway, I have an eye on it
<jibel> pitti, no idea, it used to be ev's team
<Oni_Shadow> G'day, I am runnig ubuntu-devel since it's availibilyty and have a quite nasty package dependency I do not know how to solve...
<Oni_Shadow> (it there the right place?)
<nacc> Oni_Shadow: what is "ubuntu-devel"?
<Oni_Shadow> my unity8 session was uninstalled by last upgrade and I did not pay attention and now, everything qt related cannot be installer because of unmet dependency whilst my package system is not broken
<nacc> Oni_Shadow: do you mean 16.10?
<Oni_Shadow> well devel is a codenam for developement i suppose that points on the lastest nightly builds, currently yaketty.
<nacc> Oni_Shadow: you want #ubuntu+1
<Oni_Shadow> I just want to get qt stuff (like unity8 and konversation) installable again
<Oni_Shadow> on my ubuntu-devel machine
<nacc> Oni_Shadow: right, ask in #ubuntu+1
<nacc> Oni_Shadow: this channel is for development of Ubuntu itself (see /topic)
<Oni_Shadow> ok cheers !
<Oni_Shadow> sorry about that then
<juliank> pitti: Did you have time to look at the apport autopkgtest failure yet? I don't really have much time at the moment, but I definitely need to get the apt 1.3 stuff in; and apport fails (and click and ubuntu-make fail for the fixed python-apt - which is likely not my fault, as I only made python-apt work with the new apt)
 * juliank is supposed to hand in some master thesis plan soon, otherwise he would have more time to look at things
<juliank> GPG error: http://ddebs.ubuntu.com trusty Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY C8CAB6595FDFF622
<juliank> that's the apport failure
<juliank> It does say freeze now, I suppose that's for the alpha 2s tomorrow?
<juliank> click just says: "Cannot install /tmp/tmpv7h7mjfk/org.example.debsig-valid-sig_1.0_all.click: Signature verification error: debsig: No applicable policy found." - Not sure what the problem is there
<juliank> And ubuntu-make has some jquery coverage issues
<juliank> "Couldn't find static file 'jquery.ba-throttle-debounce.min.js'"
<pitti> juliank: no, I didn't, sorry; not sure why the new apt doesn't accept the signature, does ddebs.u.c. need to chagne its archive layout somehow?
<juliank> pitti: I'm not sure what's going on on ddebs, I thought you might know more. DonKult flipped the switch to treat the warnings as errors in the new release, that's all I know
<juliank> Then again, signature ver. issues should have been errors before too
<pitti> juliank: indeed, like in https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/amd64/a/apport/20160727_081401@/log.gz
<pitti> it's a  warning there
<juliank> right.
<juliank> that's the add repository, install keyring, update again scenario
<juliank> That now requires --allow-insecure or --allow-unauthenticated
 * juliank is never sure which is whicht
<juliank> (or [allow-insecure=true] in the sources.list)
<pitti> juliank: do you know about the python-apt failure?
<juliank> this one is easy to fix then. the click and ubuntu-make regressions are far more annoying, as they are completely unrelated to the python-apt upload that triggered them
<pitti> I'll put the apport thing on my TODO list
<juliank> pitti: the python-apt failure is fixed (should be at least, maybe there's some stderr output I need to get rid of), but the new python-apt is prevented from migrating by click and ubuntu-make which went rogue on their own
<juliank> That is, they also fail for other test suite triggers
<pitti> right
<pitti> so, fine for me to ignore these two
<pitti> juliank: for now I'll requeue a retry of proposed python-apt against proposed apt, that should clear up that part
<pitti> juliank: will take a bit though, look at the queues on http://autopkgtest.ubuntu.com/running.shtml :/
<juliank> OK
<pitti> juliank: p-apt hinted, p-apt for apt retried
<xnox> pitti, infinity - can one emulate ppc64el on non-ppc64el hardware? or how do i get my hands onto such a system? need to debug claims that installing with btrfs as root, does not work on ppc64el.
<pitti> oh, so a cloud instance won't do for that
<pitti> nested qemu perhaps
<pitti> (on a cloud instance)
<infinity> xnox: You can emulate, yes.
<infinity> xnox: It's not fast, mind you.
<infinity> xnox: qemu-system-ppc64 -M pseries
<infinity> xnox: Or ask slangasek how to get at real hardware, where you can add --enable-kvm to that and not hate yourself. ;)
<xnox> in virtmanager i do get architecture ppc64le and pseries option. let me see if i can boot that at all.
<xnox> asks for an iso image
 * xnox goes to get coffee whilst download is in progress. 90s left.
<xnox> fonts look odd but it seems to be working
<infinity> xnox: Emulating video too?  Brave.
<infinity> xnox: I'd have opted for qemu-system-ppc64 -M pseries -m 2G -vga none -nographics -hda foo.img -cdrom ubuntu.iso
<xnox> using defaults in libvirt
<infinity> xnox: And just enjoy the text.
<infinity> libvirt and I don't get along.
<xnox> i think video crashes.
<davmor2> testing123
<infinity> s/nographics/nographic/
<xnox> serial looks better.
<davmor2> wrong window ah that's better now it pings me in pm
<xnox> i get kernel panic trying to boot of yakkety-server.iso and it goes into reboot loop =(
 * xnox tries xenial
 * infinity gets 12MB/s from cdimage, and wonders if this is a sign of the apocalypse.
<xnox> qemu-system-ppc64le -M pseries -cdrom yakkety-server-ppc64el.iso -m 2048 -nographic
<xnox> doesn't get me d-i :-(
<infinity> emu-system-ppc64 -M pseries -cpu POWER8 -m 2G -vga none -nographic -hda disk.img.server -cdrom ubuntu-16.04.1-server-ppc64el.iso
<infinity> xnox: -cpu needs to be POWER8, we don't support lower.  Also, -vga none is a good idea if you're -nographic.
<infinity> (The above worked for me here)
<xnox> that got me grub
<infinity> yakkety boots with that commandline too.
<infinity> But yeah.  It ain't quick.
<xnox> i see d-i \o/
<infinity> Be prepared for some very slow menu transitions.
 * infinity goes to bed.
<smoser> rbasak, thanks for your help yesterday.
<smoser> xnox, 'xkvm' from curtin makes the qemu cmdline easier.
<smoser> and should pretty easily dtrt for power
<smoser> rbasak, so Fixes LP: #bug1, bug2
<smoser> or Fixes LP: #bug1, #bug2
<rbasak> smoser: any need for "Fixes"?
<smoser> there is not.
<smoser> maybe Fixes-bug:
<smoser> it isnt necessary, but it seems reasonable to put sanely formated data.
<smoser> maybe i should just accept arbitrary string searching
<smoser> from
<smoser>  zgrep -E LP: /usr/share/doc/*/changelog.Debian.gz | grep -e "#[0-9]\+[ ]*[ ,]\+[#*][0-9]\+"
<smoser> it seems like LP: #NN, #NN
<smoser> is pretty common in changelogs
<smoser> so for multiple bugs i'll do
<smoser> LP: #BUG, #BUG
<cjwatson> Both '#' characters are necessary, yes.
<rbasak> The problem is that you're making something up that is likely to be non-standard.
<rbasak> You say Fixes, someone else says Closes, etc. So I don't think you get any benefit there unless someone defines something.
<rbasak> I'd just put "LP: #NNN" on a line on its own.
<cjwatson> It's still not absolutely settled what Launchpad will recognise, but if it's anything like the changelog syntax then it will likely be exactly the same as the changelog syntax, not a slight variant of it.
<rbasak> (or "LP: #XXX, #YYY" of course)
<rbasak> The nice thing about that is that it also matches the pseudo-header syntax that others tend to use.
<smoser> well, because i'm in the position where i can actually make consistency for this, it seems better to do it.
<rbasak> You can't make consistency for this.
<rbasak> You'll end up with a history that does one thing, and a future that potentially does something else.
<smoser> i surely can for my repo.
<rbasak> Or, if you stick to the same thing, you'll have cloud-init doing a special thing that no other repo does, which will be confusing for contributors.
<rbasak> I'm just saying that you shouldn't arbitrarily invent anything here.
<smoser> the thing i'm bothered by is that 'LP: #XXX' does not differenciate from Fixes LP: #XXX and 'this is fallout of a fix for LP: #XXXX'
<nacc> the latter is not correct syntax
<nacc> aiui
<rbasak> debian/changelog has the same issue. You can't fix it by adding "Fixes LP". The regexp that Colin proposed will still match it.
<nacc> it should be LP #XXXX in that case
<nacc> LP: is "special"
<cjwatson> The traditional approach in changelogs is as nacc says.
<cjwatson> It's maybe not ideal, but it's pretty established.
<rbasak> "Fixes LP" also breaks the RFC822-style headers the git community tends to use.
<xnox> oh wow.
<smoser> Fixes: LP: # does not.
<rbasak> It might be worth looking into whether git-dch can parse that.
<rbasak> I know it parses "LP: #XXX" on a line on its own fine.
<smoser> alright. i'll go with just LP: # as new line.
<rbasak> Thanks. I feel that this has the most potential to become a future de facto standard.
<semiosis> Odd_Bloke: i see bug 1565985 is filed in this week's milestone for cloud-images.  does that mean that the yakkety images will start to be built with the fixes soon?
<ubottu> bug 1565985 in cloud-images "vagrant vb ubuntu/xenial64 cannot mount synced folders" [Undecided,In progress] https://launchpad.net/bugs/1565985
<smoser> rbasak, so.. i tried that mono bzr fast-export rewriter... had issues.
<smoser> i could not get it to work for me
<smoser> however, this does work:
<smoser>  http://paste.ubuntu.com/21144779/
<smoser> and seems much better sutied for the task. ie, i just modified fastexport in bzr to update the messages.
<rbasak> smoser: seems reasonable
<rbasak> smoser: it might be sensible to send that upstream, too. Though your code is a little hacky IMHO.
<LocutusOfBorg> can anybody please try to clean ppc64el builders space?
<LocutusOfBorg> objcopy:./usr/lib/python2.7/dist-packages/itk/st93riGN[.rodata]: No space left on device
<LocutusOfBorg> objcopy:./usr/lib/python2.7/dist-packages/itk/st93riGN: No space left on device
<LocutusOfBorg> or should I do something else
<LocutusOfBorg> https://launchpad.net/ubuntu/+source/insighttoolkit4/4.10.0-dfsg1-1ubuntu1/+build/10520384
<smoser> rbasak, agreed on both counts. hacky and would be nice to have that as an option.
<smoser> you'd have to provide some option for how to translate some template or something.
<rbasak> smoser: IMHO, for the sake of consistency there shouldn't be a configurable template option. Just do the one thing one way.
<Odd_Bloke> semiosis: The next yakkety build should have them.
<Odd_Bloke> semiosis: (Thanks for the ping though, I'd forgotten to push a button)
<smoser> rbasak, but there are different bug sources
<smoser> not everyone uses launchpad
<smoser> i know, its hard to believe :)
<rbasak> smoser: sure, but the bzr metadata knows the bug source, right? So it wouldn't need to be configurable, just individual support in the code.
<smoser> well, sort of
<smoser> bzr knows the bug url
<smoser> so it could quite easily do:
<smoser> fixes-bug: bugurl
<smoser> fixes-bug: bugurl2
<smoser> but extracting the bug number out of any bug systems url is more complex.
<smoser> and that assumes good data in those urls
<smoser> consistent url formats across every committer
<dobey> well, it's easy enough for launchpad to handle launchpad bug urls
<dobey> beyond that, you just have a url which is generally good enough
<dobey> see url, click url, get bug
<dobey> *** Error in `/usr/lib/arm-linux-gnueabihf/unity-scopes/scoperunner': free(): invalid pointer: 0x01f5c390 ***
<dobey> well, that sucks
<dobey> oops
<bregma> have the main inclusion requirements as documented in https://wiki.ubuntu.com/UbuntuMainInclusionRequirements changed?  In particular, are build-deps still required to be in main, or was that not recently relaxed?
<jbicha> bregma: universe b-depends are ok now: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2016-April/001179.html
<bregma> I ask because I'm looking at having to MIR 114 packages to get Unity 8 into main *without* the build-deps
<bregma> jbicha, what about packages needed only for running autopkgtests?
<jbicha> that's a good email list to subscribe to if you don't already
<pitti> bregma: test dependencies can come from any component
<bregma> I'm subscribed, so I was peripherally aware of the change but the wiki documentation is not up to date
<dobey> build-deps are ok being in universe, if they don't create binary deps on things in universe
<semiosis> Odd_Bloke: glad to hear it.  thank you!
<mterry> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Xenial (16.04.1) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mterry
<mterry> jamespage, in pacemaker 1.1.14~rc4-2ubuntu1 for 16.04, you wrote "d/control: Promote crmsh | pcs to Recommends for upgraders from 14.04." -- what did you mean about upgraders from 14.04?  Do we still need that change post-16.04?
#ubuntu-devel 2016-07-28
<Bluefoxicy> wait, what
<Bluefoxicy> there are no text terminals
<Bluefoxicy> ctrl+alt+F1-F6 just shows the line "Scanning for Btrfs filesystems"
<pitti> Good morning
<tsimonq2> o/ pitti, how are you? :)
<pitti> hey tsimonq2! a bit tired, but ok, how about you?
<tsimonq2> great pitti :)
<tsimonq2> pitti: quick question, are you a Core Dev?
<pitti> yes
<tsimonq2> pitti: you on the release team?
<pitti> https://launchpad.net/~pitti/+participation :)
<tsimonq2> oh sorry
<tsimonq2> yeah nevermind
<pitti> didrocks: bonjour !
<pitti> didrocks: do you know about the ubuntu-make test regressions? (http://autopkgtest.ubuntu.com/packages/u/ubuntu-make/yakkety/amd64/) -- it seems to complain about "debian/tests/collect-coverage: line 8: cd: /tmp/global-coverage: No such file or directory"
<pitti> oh, and "Couldn't find static file 'jquery.ba-throttle-debounce.min.js'" in the "small" test
<pitti> the one above might just be a consequence of that
<didrocks> hey pitti! this error happen when no tests have been running.
<didrocks> maybe one build-dep breaking the coverage report?
<pitti> didrocks: right, so I guess the missing jquery.ba-throttle-debounce.min.js causes the failure?
<didrocks> probably yeah (same, this is on the coverage report side)
<cpaelzer> late but good morning everybody
<pitti> juliank: hm, didn't we use to have something like $APTROOT?
<pitti> juliank: i. e. if I have my little sandbox with foo/etc/apt/sources.list and foo/var/lib/apt/lists etc.
<pitti> juliank: (working on the archive auth -- I'd rather install the GPG key properly than [trusted=yes]
<pitti> the apport code uses apt.Cache(rootdir=), but that still barfs on the signature error even though trusted.gpg.d/ddebs.ubuntu.com.gpg is in place
<pitti> oh, I think apt -o RootDir="$(pwd)" update
<pitti> juliank: meh, I can't get this to work :( <myroot>/etc/apt/trusted.gpg.d seems to get entirely ignored, it always takes the one in the root dir
<pitti> juliank: so at least test_install_package_from_a_ppa() is a regression in apt, the key for the PPA is definitively there; the test_install_old_packages() failure is my fault, I'll push the fix (but that's not sufficient for the same reason)
<Saviq> pitti, morning, can you please rerun https://requests.ci-train.ubuntu.com/static/britney/ticket-1604/landing-019-yakkety/excuses.html with proposed enabled, it's fallout from the Qt 5.6.1 release
<Saviq> (the in progress ones will fail, too)
<pitti> juliank: filed as bug 1607283 with a standalone simple reproducer
<ubottu> bug 1607283 in apt (Ubuntu) "1.3~pre2ubuntu2 regression: trusted.gpg.d not read any more from apt root" [Undecided,New] https://launchpad.net/bugs/1607283
<juliank> pitti: Reproduced.
<pitti> juliank: it could of course be a red herring and reading trusted.gpg.d from the sandbox may have never worked -- but apt previously didn't complain about it?
<juliank> pitti: I'm going to bisect this
<pitti> juliank: cheers!
<pitti> Saviq: retried the failures and running ones
<Saviq> pitti, thanks!
<juliank> pitti: Can even reproduce it with 1.2.10 :/ - so it seems that's not a regression
<pitti> juliank: hm, it works on my laptop with current yakkety
<pitti> and apport with 1.3~exp1 doesn't fail on that
<juliank> pitti: Well, failing is a strong word... 1.3~exp1 shouldn't find the keys, but only warns about the missing keys, and does not produce an error
<juliank> pitti: https://paste.debian.net/785744/
<juliank> pitti: Probably because apt-key can only look at config files, and not config values set in the parent process.
<juliank> So, you'd have to specify dir in a apt.conf file and then set APT_CONFIG env var to that path
<juliank> Not sure how to fix that yet
<juliank>  We should probably dump the config to a file, set APT_CONFIG=temp-file and only then start apt-key
<juliank> s/We/apt/
<pitti> juliank: so apt.Cache(rootdir=foo) sets "Dir=foo" more or less?
<juliank> It sets Dir in the current process, but that's not forwarded to the apt-key process
<pitti> juliank: oh, you mean apt-get update calls apt-key for verifying the sig, that's not done in-process?
<juliank> Yes
<juliank> apt calls apt-key which calls gpgv
<pitti> juliank: so how did that work in earlier versions, did it just silently ignore the missing key?
<juliank> It should not ignore it silently
<pitti> on my laptop I don't have ddebs in "apt-key list" and yet that python3 command line works fine
<pitti> (and the apport tests)
<Mirv> pitti: Saviq: https://requests.ci-train.ubuntu.com/static/britney/ticket-1604/landing-019-yakkety/excuses.html just updated but I don't find any running or completed results that would have been run with yakkety-proposed. I do find results that were started eg 30mins ago
<Saviq> Mirv, pitti, yeah I was looking there too, I saw them initially with all-proposed in running queue, not sure if all the tests were restarted or just unity8... not sure where to look for recently-completed runs for PPAs
<pitti> no, I restarted all the regressions and all teh runing ones with --all-proposed
<pitti> seems that didn't help indeed
<Saviq> pitti, e.g. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety-ci-train-ppa-service-landing-019/yakkety/amd64/u/unity8/20160728_094920@/log.gz still doesn't seem to have proposed enabled so maybe we're looking at the tests that were running already?
<Saviq> those http://autopkgtest.ubuntu.com/running.shtml#pkg-unity8 however don't have "All-proposed: True"
<Saviq> for ppa 019
<Mirv> Saviq: that started after your discussion, and there are similar ones 15-20mins later that also don't have proposed enabled
<pitti> Saviq: landing-060 != landing-019
<Saviq> pitti, there's some landing-019 further down
<pitti> well, I did queue them with all-proposed, apparently that didn't make it to the testbed for some reason
<juliank> pitti: RFC: https://github.com/Debian/apt/compare/master...julian-klode:bugfix/apt-key-config
<juliank> Or rather just https://github.com/Debian/apt/commit/1bdb1e50e2b36bd5ffd14b8dbec8be1052eb1987
<pitti> juliank: OOI, what does that new "conf" temp file do? I thought this  was just about setting $APT_CONFIG?
<juliank> pitti: We dump the current in-process config to a temporary file, and then pass that as APT_CONFIG to apt-key
<juliank> It's ugly, but I don't really see what else we could do
<pitti> ah
<pitti> Saviq, Mirv: I retried unity8/i386 again with --all-proposed (can do the others if that works)
<pitti> oh crap, I know
<pitti> I did -s yakkety
<juliank> I'm not sure if it is safe
<pitti> we want xenial I guess
<juliank> We mkstemp() the file, but then basically ignore the fd, and re-open by name for the C++ ostream
<pitti> no, actually, you do want y
<juliank> I could use __gnu_cxx::stdio_filebuf() to directly use the fd
<pitti> it's running now, I'll check in a bit
<juliank> on the other hand, I also pass it by name to apt-key...
<juliank> we also pass the temporary split gpg signature + data to apt-key by-name, though...
<pitti> $ APT_CONFIG=/tmp/sandbox python3 -c 'import apt; c=apt.Cache(rootdir="/tmp/sandbox"); c.update()'
<pitti> juliank: ^ that also doesn't work though, should it?
<juliank> pitti: No
<pitti> I guess that's the part of "need to actually write the config file"
<juliank> pitti: APT_CONFIG is a config file, not a dir
<juliank> s/is/needs/
<juliank> I guess I also do not set cloexec on the ofstream currently :/
<pitti> ok, so APT_CONFIG=/tmp/sandbox/etc/apt/apt.conf also doesn't work as I suppose that doesn't look for the other files relative to that
<juliank> pitti: You'd need to have Dir "my-chroot-path" in your APT_CONFIG file
<pitti> Laney: yay freeze lift
<pitti> juliank: indeed, that does the trick; so that's what your branch does automatically now
<juliank> Yes
<pitti> juliank: nice, thanks muchly for fixing that!
<pitti> juliank: I guess I'll upload apport then so that the next apt upload catches a fixed one (for the missing ddebs.u.c. key import)
<juliank> pitti: Yes, I'll upload a new apt soon too to see if that works :)
<juliank> I'll also upload a python-apt that tells apt-key to shut up, so we do not get stderr failures for python-apt
<juliank> Once everything works here, I'll upload it to Debian with possibly some more fixes from DonKult and sync it
<juliank> here = in Ubuntu
<juliank> not on my machine :D
<pitti> juliank: new p-apt just landed, FYI
<juliank> Great
<doko> Mirv, did you have a chance to look at the powerpc related GCC6 qt*-opensource-src FTBFS?
<doko> tvoss, sil2100: please could you fix the GCC6 related ftbfs for dbus-cpp and ubuntu-ui-tookit? http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20160705-gcc6-yakkety.html
<juliank> pitti: uploaded python-apt (to fix the stderr output during test) and apt (with the apt-key config fix from my branch).
 * juliank still has to write a test case and probably refactor it a bit for upstream
<juliank> For now, the main point is to get the autopkgtests working again, though.
<Mirv> doko: not much, but note that yakkety-proposed now has Qt 5.6.1. looking at the previous rebuilds, all of them say "/usr/bin/ld.gold: --secure-plt: unknown option"
<Mirv> so maybe it's the powerpc version of ld.gold
<Mirv> https://llvm.org/bugs/show_bug.cgi?id=20572
<ubottu> llvm.org bug 20572 in Backend: PowerPC "PowerPC backend does not support secure PLT" [Normal,New]
<Mirv> that's LLVM though..
<doko> Mirv, but you don't use clang explicitly, do you?
<Mirv> doko: no, just educating myself of the switch via google
<jgrimm> dannf, would you be able to verify https://bugs.launchpad.net/ubuntu/+source/docker.io/+bug/1574904
<ubottu> Launchpad bug 1574904 in docker.io (Ubuntu Xenial) "Old clients cannot talk to Docker in 16.04" [High,Fix committed]
<Mirv> pitti: Saviq: no proposed in unity8/i386 https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety-ci-train-ppa-service-landing-019/yakkety/i386/u/unity8/20160728_105414@/log.gz
<doko> tedg, could you have a look at https://launchpad.net/ubuntu/+archive/test-rebuild-20160705-gcc6/+build/10416146 (GCC 6 FTBFS)?
<doko> Mirv, looks like qtbase-opensource-src has configure options/values -use-gold-linker/-no-use-gold-linker/USE_GOLD_LINKER/CFG_USE_GOLD_LINKER. please disable then on powerpc. gold on powerpc doesn't have this option
<doko> but wondering why you only see this with GCC 6 ...
<pitti> xnox: do you think the new mdadm is ready for merging now?
<xnox> pitti, yes. still need to retest on ubuntu. ideally i would like to just port the remaining ubuntu-only bits to debian (e.g. apport integration) such that we could have it in-sync.
<xnox> pitti, are you volunteering to merge mdadm? =)
<pitti> xnox: I'm asking because systemd 231-1 needs the new version; I could also temporarily drop that Breaks:, I don't think we actually have an rcS init.d script in Ubuntu; I asked because if you were going to merge/sync anyway that wouldn't be needed
<pitti> xnox: I can do the merge (apport bits etc.), but I would suck at testing it
<pitti> xnox: AFAIR our main delta was udev vs. init.d script
<xnox> oh that. ok. I see.
<pitti> not sure if that's still relevant with your rework, as that now seems to be dynamic in the Debian version too?
<xnox> I'm hoping to do openssl, boost1.61 and mdadm this week =) today and tomorrow. I guess i could bump mdadm above boost1.61 =)
<pitti> I'm just done with ebtables, now going to nfs-utils (that's a big one), and scsitools/ifscheme (these shuold be small)
<pitti> then the only remaining one is mdadm
<pitti> and then we finally got rid of rcS.d init scripts :)
<xnox> pitti, it's now much better in debian than ubuntu, cause it now integrates with block-local loop for proper mount handling.
<pitti> sounds yummy :)
<pitti> nice work!
<xnox> pitti, may i ask you something about postgresql? =)
<pitti> xnox: sure, you can always ask (I've been out of the loop for a fair while, so not sure I can answer)
<xnox> why the slice is not named as "postgresql-slice" =)
<xnox> why the slice is not named as "postgresql-system.slice"
<xnox> because at the moment: systemctl status postgresql* -> will show "master" unit & all instances, but not the slice which has e.g. current memory usage stats =(
<xnox> imho it should be renamed "system-postgresql.slice" -> "postgresql-system.slice"
 * xnox off to get coffee
<pitti> slices don't work that way, you can't arbitrarily name them; their name reflects the cgroup hierarchy
<pitti> i. e. all system services are in, or in a child of system.slice
<pitti> postgresql.slice would be completely independent, thus global resource limits would then not apply to it any more
<pitti> xnox: status '*postgresql*' should work?
<Saviq> Mirv, yeah I just saw, not sure what's going on... pitti any idea why your "all-proposed" reruns end up running without proposed again https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety-ci-train-ppa-service-landing-019/yakkety/i386/u/unity8/20160728_105414@/log.gz ?Â¿
<pitti> Saviq: oh, I know: Mirv requested it! bug 1541334
<ubottu> bug 1541334 in autopkgtest (Ubuntu) "Do not run silo tests against all of -proposed" [Undecided,Fix released] https://launchpad.net/bugs/1541334
<pitti> this was changed in https://git.launchpad.net/~ubuntu-release/+git/autopkgtest-cloud/commit/?id=b029faacbe
 * Saviq shakes fist
<pitti> i. e. we don't run silos against -proposed because that broke train landings in other ways
<pitti> can't have it both ways :/
<pitti> so I guess Qt needs to land first?
<pitti> how can the new Qt break that silo if it is only in -proposed? or does the new silo depend on the new qt already?
<Saviq> pitti, it builds against proposed
<Saviq> pitti, so it links against the new qt
<pitti> a silo cannot land if any of its dependencies are stuck in -proposed anyway?
<pitti> hmm
<Saviq> I think it can
<pitti> so I could temporarily revert that, but it will again break the cases from teh bug above
<Saviq> but here the problem is not dependencies but broken test runs
<Saviq> pitti, couldn't --all-proposed override that? i.e. when you explicitly ask for it, shouldn't it go for all proposed anyway?
<pitti> I guess so, yes
<Saviq> that would be best IMO
<Mirv> Saviq: pitti: yes, having proposed enabled brings usually more trouble than it helps, that's why it's generally disabled. but in case of transition like that, it could be useful to have an option to run with all proposed (even risking the other trouble it brings)
<pitti> code updated/deployed, retried unity8/i386
<pitti> if that works, I'll retry the others
<Saviq> great, thanks
<Mirv> awesome
<xnox> pitti, ahhhh i did not realise that it is `systemd-escape`d path =)
<xnox> so it's like .device/.mount units
<pitti> xnox: right
<Saviq> pitti, looking at http://autopkgtest.ubuntu.com/running.shtml#pkg-unity8 it's much better, so if you could restart all regressions in https://requests.ci-train.ubuntu.com/static/britney/ticket-1604/landing-019-yakkety/excuses.html with allproposed - thanks!
<LocutusOfBorg> anybody knows why mdadm is not installable on yakkety? it tries to remove init
<LocutusOfBorg> pitti, ^^ seems somewhere systemd/init related
<mterry> Laney, any luck on unity-greeter (I'm guessing no)
<mterry> ?
<Laney> mterry: hey there, nope - haven't tried any more this week really
<mterry> ugh.  I don't want to be the one holding up gtk3.20
<Laney> mterry: I would probably not actually hold it up on this bug
<mterry> Laney, heh
<Laney> :)
<mterry> Well I don't want to be the one breaking user logins when they make a typo
<Laney> haha
<pitti> Saviq: indeed, done
<Laney> mterry: I noticed that if you go down to the guest session entry and then back then it appears again
<pitti> LocutusOfBorg: that only affects -proposed, that's known; see discussion with xnox two hours ago
<mterry> Laney, yeah there's an easy way to get it back
<mterry> Laney, but you have to try that.  And have more than one entry
<pitti> LocutusOfBorg: i. e. systemd will stay in -proposed until mdadm gets merged, or I do a temporary ubuntu delta to drop the breaks
<Laney> mterry: damn, I aws hoping that would be a clue to you
<mterry> Laney, no.  I don't get it at all
<Laney> I think that robert_ancell is back now
<Laney> at least he emailed the team aboutu some work stuff...
<mterry> Laney, we do set css class names somewhere in there...  but I didn't think we did fancy stuff with it
<Saviq> pitti, awesome, thanks - Mirv it's running well now
<xnox> pitti, i have a merge ready, and will upload it soon, once i test that it is sort of correct =)
<xnox> (it will be a sync)
<pitti> awesome!
<LocutusOfBorg> I see now
<LocutusOfBorg> thanks
<LocutusOfBorg> I'll wait then, a bunch of packages are FTBFS because of this issue
<LocutusOfBorg> e.g. diffoscope
<pitti> urgh, b-dep on systemd and mdadm??
<LocutusOfBorg>  sbuild-build-depends-diffoscope-dummy : Depends: python3-guestfs but it is not going to be installed
<Laney> mterry: I think all of that should work with the rejigged CSS that I did
<LocutusOfBorg> pitti, not directly but meh
<LocutusOfBorg> libguestfs should be the one needing them both?
<pitti> right, that's the one that is uninstallable right now
<xnox> LocutusOfBorg, why do you have proposed enabled on a development machine?
<pitti> LocutusOfBorg: sorry about that -- should be fixed soon
<LocutusOfBorg> xnox, I don't have
<xnox> LocutusOfBorg, one must not run with -proposed enabled on a development series.
<xnox> OK
<LocutusOfBorg> I don't even run yakkety
<pitti> xnox: it's an FTBFS (which runs against -proposed)
<LocutusOfBorg> http://people.canonical.com/~ubuntu-archive/proposed-migration/yakkety/update_excuses.html
<LocutusOfBorg> yes exactly
<LocutusOfBorg> I was looking at gammaray, and I saw diffoscope FTBFS
<mterry> Yup commenting out all css use in unity-greeter doesn't fix anything
<Laney> probably punt to Robert for now
<Laney> he should know lightdm signals the greeter to re-display the box
<Laney> that's where I would start poking, but it is pretty complicated to me atm
<seb128> didrocks, pitti, could you comment on bug #1584575 maybe? I think it makes sense but you are more familiar with the work done there I think
<ubottu> bug 1584575 in lightdm (Ubuntu) "/lib/systemd/system/lightdm.service file has no [Install] clause" [Medium,New] https://launchpad.net/bugs/1584575
<seb128> like should it have a
<seb128>     [Install]
<seb128>     WantedBy=multi-user.target
<seb128>     Alias=display-manager.service
<seb128> ?
<didrocks> I don't remember the latest on this, as this got discussed over and over again, but I thought we decided on the Alias
<didrocks> let's wait on pitti for now, he may have a better memory that I do on this
<pitti> it's blurry as well, but indeed this is controlled by display-manager.service
<mterry> Laney, hrm.  Found another bug.  If you click on the session-chooser icon, nothing is drawn and you can't go back
<pitti> IIRC all *dm's postinsts need to set /etc/systemd/system/display-manager.service to whatever was chosen in debconf
<pitti> seb128: ^
<pitti> setting Alias= sounds correct, but not WantedBy=
<pitti> we don't want *all* DMs to start
<seb128> good point
<pitti> the whole mechanics for that is still horribly complicated and redundant -- you can use update-rc.d, debconf, /etc/X11/default-display-manager etc.
<pitti> I think /etc/X11/default-display-manager is still meant to be the canonical way to configure this, that's why we skipped the [Install] sections so that you don't introduce contradictions with systemctl enable/disable
<seb128> pitti, ok, so looks like a non-trivial one, might just be better to not change anything for now then
<seb128> thanks!
<Laney> mterry: meh
<Laney> it works if you go into the inspector and some rule
<Laney> like * { border: 1px solid red; }
<Laney> then even if you pause it, it works
<mterry> Laney, wait how do you use the inspector again?  you said ctrl+alt+i, which doesn't do anything for me.  I assume I need to be running some inspector tool first?
<Laney> mterry: apt install libgtk-3-dev; gsettings set org.gtk.Settings.Debug enable-inspector-keybinding true
<Laney> should have said, sorry :(
<mterry> still doesn't do anything for me  :(
<mterry> Well both the prompt box and the session list use a PromptBox class to do drawing.  And it certainly has some weird drawing logic...  But per my tests, everything seems to be right
<pitti> Mirv, Saviq: ah, first green on https://requests.ci-train.ubuntu.com/static/britney/ticket-1604/landing-019-yakkety/excuses.html :)
<juliank> pitti: So, the python-apt upload is basically done with testing. No new regressions, as expected, but it will need some manual work due to the click issue (ubuntu-make failure is ignored, click failure is not ) - that fixes the regression with the new APT. I also noticed that the apport test had a communication issue with LP on amd64 and retried that
<juliank> So, I think apt should land tomorrow :)
<pitti> juliank: indeed, python-apt is all good except click, I'll hint that
<pitti> juliank: thanks for retrying apport; once that lands this ought to help with the new apt
<juliank> yep
<pitti> juliank: just weird that apport in http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#apt still failed the "PPA" tests that should work with the apt fix
<juliank> pitti: Hmm, not sure
<juliank> But if there's still something to fix, we can do so
<xnox> pitti, mdadm 3.4-4 uploaded -> i will try to sync it when it becomes available for syncage. Or if you spot it first, feel free to sync it over. with force.
<pitti> "Use the force, Luke^WLaunchpad!" :)
<Mirv> pitti: somehow armhf failures show still not using yakkety-proposed https://requests.ci-train.ubuntu.com/static/britney/ticket-1604/landing-019-yakkety/excuses.html - I've pinged Savi_q regarding the unity8 qmluitests failures
<Mirv> (on x86)
<pitti> Mirv: oh, they ran there -- forgot to update these boxes
<Mirv> ok :)
<pitti> Mirv: updated the lxd boxes, retried everything again
 * pitti waves good evening
<Mirv> pitti: thank you, good evening!
<Guest55167> does this channel cover 16.10?
<Guest55167> anyone here?
<xnox> Is this Richard Brandson (Virgin Group) putting on Ubuntu cap? https://res.cloudinary.com/www-virgin-com/f_auto,q_80/virgin-com-prod/sites/virgin.com/files/lewis_hat_2.jpg
<infinity> xnox: http://ubuntuismclothing.com/
<xnox> OMG there is a whole clothing line.
 * xnox throws all my clothes in suitcase and takes it to the dumpster
#ubuntu-devel 2016-07-29
<infinity> pitti: Need those trusty langpacks in updates tomorrowish, if you have time to verify them.
<pitti> xnox: hm, -4 still not imported -- LP imports are really slow these days :)
<pitti> err, other smiley ..
<pitti> infinity: ack
<jbicha> pitti: could you retry an autopkgtest of freedombox-setup/0.9.2 triggered by itself and plinth/0.9.4-2 with all-proposed?
<pitti> jbicha: done
<jbicha> pitti: thanks, did you see that update_excuses hasn't refreshed in a while?
 * Mirv causes explosions in autopkgtest infra
<Mirv> new KDE Frameworks and Plasma copied to proposed
<pitti> jbicha: yes, apw was pointing that out, britney crahsed; I'll look at it ASAP
<pitti> infinity: do you know, does this even make sense:
<pitti> -Provides: adwaita-icon-theme,
<pitti> +Provides: adwaita-icon-theme (= 3.18),
<pitti> ^ from lubuntu-artwork in -proposed; I have a gut feeling that this is what makes britney explode
<pitti> the real package has version 3.18.0-2ubuntu4
<infinity> pitti: That's reasonable.
<infinity> pitti: Allows for versioned deps on adwaita-icon-theme to be satisfied by lubuntu-artwork
<infinity> pitti: Surely britney understand versioned provides, they've been around a while now.
<infinity> s/understand/understands/
<pitti> so that doesn't need to be >= ? (I don't know how versioned provides work exactly, but strict equalities look weird)
<infinity> No, strict equality is correct.
<pitti> infinity: yes, it does in general, it worked for other packages
<infinity> You're saying "act as though I'm <package> at <version>"
<pitti> (that's what triggered the big merge)
<pitti> ah, ok
<pitti> so, I'm afraid this isn't a 3-minute fix, I don't know the upgrade_testing logic at all and why it now runs into infinite loop
<pitti> to unblock this we could manually copy this to yakkety, or remove it from -proposed for now
<pitti> or leave it broken for several days, but I wouldn't want that
<pitti> infinity: trusty langpacks tested (up to the degree that I can do it, Eng/Ger in Qemu desktop and some spotchecks with diff -Nur for other langs), and released
<infinity> pitti: Ta.
<LocutusOfBorg> who did break initramfs?
<LocutusOfBorg> :)
<LocutusOfBorg> I would blame: apw for the busybox-initramfs part :)
<LocutusOfBorg> https://launchpadlibrarian.net/275621714/buildlog_ubuntu-yakkety-ppc64el.libguestfs_1%3A1.32.6-1ubuntu2_BUILDING.txt.gz
<LocutusOfBorg> or is that due to some mdadm changes from xnox ?  BTW thanks for the sync :)
<pitti> sync? 3.4-4 isn't even imported into LP yet
<LocutusOfBorg> 3.4-3 is
<pitti> oh, xnox synced -3; that was a bit premature
<LocutusOfBorg> do you think it might be the reason for that failures?
<pitti> not the -3 vs. -4 difference I think
<LocutusOfBorg> well, a kernel not installable seems something we should worry about
<LocutusOfBorg> confirmed, on a clean pbuilder yakkety environment, installing linux-image-generic fails
<pitti> LocutusOfBorg: it's more likely that http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#initramfs-tools is the culprit
<pitti> apw: ^ known?
<pitti> Not touching package due to block request by apw (contact #ubuntu-release if update is needed)
<pitti> interestingly the kernel's own tests do install busybox-initramfs
<pitti> the libguestfs build did not
<pitti> presumably because it's only a Recommends:
<pitti> if it fails on that, it ought to be a hard Depends:
<LocutusOfBorg> mmm nack?
<LocutusOfBorg> I installed initramfs-tools and then linux-image-generic, everything was fine
<LocutusOfBorg> I'll debug it
<pitti> LocutusOfBorg: thanks!
<LocutusOfBorg> thanks to you
<LocutusOfBorg> BTW installing busybox-initramfs works, but I'm not sure why it is needed
<LocutusOfBorg> pitti, cryptsetup, when installed linux-image-generic fails
<LocutusOfBorg> or one of its dependencies :)
<pitti> juliank: new apport just landed, I'll retry it for apt
<apw> pitti, not known no, it was blocked just to get it to migrate separately from all the other bits which were blocked for the alpha
<LocutusOfBorg> ough
<LocutusOfBorg> apw, can you at least reproduce the issue?
<apw> LocutusOfBorg, i think i have missed what happened ...
<LocutusOfBorg> apw, clean yakkety environment
<LocutusOfBorg> apt-get install cryptsetup
<LocutusOfBorg> apt-get install linux-image-generic
<LocutusOfBorg> fail
<LocutusOfBorg> update-initramfs: Generating /boot/initrd.img-4.4.0-33-generic
<LocutusOfBorg> E: busybox-initramfs, version 1:1.22.0-17~ or later, is required but not installed
<LocutusOfBorg> update-initramfs: failed for /boot/initrd.img-4.4.0-33-generic with 1.
<LocutusOfBorg> run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1
<LocutusOfBorg> Failed to process /etc/kernel/postinst.d at /var/lib/dpkg/info/linux-image-4.4.0-33-generic.postinst line 1052.
<LocutusOfBorg> installing busybox-initramfs obviously fixes the issue, but it is not a fix obviously
<apw> hrm, so did you install initramfs-tools from -proposed manually ?
<LocutusOfBorg> apw, also the builders do that
<LocutusOfBorg> look at libguestfs build failure
<apw> LocutusOfBorg, i guess i get to wait for the publisher to finish its work before i can test properly
<LocutusOfBorg> Unit193, ^^^ it might be a problem on cryptsetup
<LocutusOfBorg> apw, it fails here http://sources.debian.net/src/initramfs-tools/0.125/mkinitramfs/?hl=95#L95
<apw> LocutusOfBorg, yes, i know where it fails ... hrm, it seems we've reduced a dependancy to a recommends, which is likely not appropriate
<LocutusOfBorg> indeed, I see the same
<LocutusOfBorg> I would make an hard dependency again
<apw> yep, i concur, will sort that out
<LocutusOfBorg> "In addition, you need to have both initramfs-tools and busybox installed.
<LocutusOfBorg> "
<LocutusOfBorg> this is from cryptsetup README.initramfs
<LocutusOfBorg> thanks apw for fixing
<LocutusOfBorg> I would wild guess this problem affects Debian too
<apw> LocutusOfBorg, all about whether they install recommends or not
<LocutusOfBorg> oh indeed, that's true :)
<LocutusOfBorg> but I still prefer explicit rather than implicit
<apw> LocutusOfBorg, yes, i am sure we need it a depends, should have spotted that moving in the merge, bah, anyhow testing now will upload shortly
<LocutusOfBorg> apw, would you sponsor an upload?
<apw> LocutusOfBorg, likely :)
<LocutusOfBorg> let me triple check
<Mirv> ok, as the whole KDE is also updated in yakkety-proposed, yofel can guide pitti in what can be force-ignored to get Qt + KDE into release pocket. on the Ubuntu side Saviq can comment on Unity 8 (the only package in Ubuntu phone stack that has autopkgtests failures), ie where's the tradeoff to keep struggling with the proposed problems versus getting all the U8 issues fixed.
<Mirv> I mean, yofel can guide regarding the KDE packages. but, there is quite a queue in autopkgtests before everything is done
<Mirv> pitti: so what's trying to get in is Qt 5.6, KDE Frameworks 5.24 and Plasma 5.7. I'm not sure if the autopkgtests need guidance here to consider all of them together, the latest versions.
<pitti> Mirv: is there hope that the new KDE fixes some of the qt 5.6 regressions like kwin?
<Mirv> pitti: yes, that was the idea since Kubuntu has been working with their own build of Qt 5.6 and new KDE releases and wanted to the Qt to get into proposed to get their stuff in too. although it seems there's some thinking that there will be autopkgtests broken anyway and they should be forced (I think it'd be a good idea to also disable known broken tests)
<cjwatson> LocutusOfBorg: You asked the other day about "cleaning up" the ppc64el builders.  That isn't a thing.  They're scalingstack, and every scalingstack builder is reset from a fresh VM instance between builds.  If a build is running out of space, it's probably being pretty unreasonable all by itself.
<pitti> Mirv: yes, we do that; we have a looong hint list of broken tests
<cjwatson> s/instance/image/
<pitti> Mirv: but we block on new regressions; we can retry failed KDE tests against all of proposed so that they run against 5.6, though; as long as they actually depend on 5.6 they should do that automatically already
<LocutusOfBorg> cjwatson, I ended up in removing builddir after dh_install
<LocutusOfBorg> :)
<LocutusOfBorg> and now I get ENORAM on arm64
<LocutusOfBorg> I reduced the parallel to arm64, lets see if it builds in less than 2 days
<Mirv> pitti: only a couple of the KDE packages really depend on 5.6 (private ABI users), probably all of them should run with the proposed Qt though
<cyphermox> good morning!
<dobey> pitti: here?
<LocutusOfBorg> wow the autopkgtest queue is huge again, is that a side effect of the freeze end?
<LocutusOfBorg> and kde :)
<Unit193> LocutusOfBorg: Looked at it again, I didn't drop busybox from depends to recommends.
<LocutusOfBorg> Unit193, the fault was in initramfs-tools
<LocutusOfBorg> that did the move
<LocutusOfBorg> http://launchpadlibrarian.net/275638870/initramfs-tools_0.125ubuntu1_0.125ubuntu2.diff.gz
<Unit193> I didn't touch that one. :D
<LocutusOfBorg> actually the change was Ubuntu specific, in Debian has no effect and was done in Debian lol
<LocutusOfBorg> the ongoing effort to reduce the delta by integrating it in Debian had a bad side effect :o
<xnox> doko, i'm planning to upload boost
<xnox> but you said it should build against new icu too?
<xnox> which one is that?
<xnox> or what's the upload order?
<xnox> ooh, i see 57.1-1 in experimental, i guess that one.
<xnox> but it's built with gcc+5 not 6 as far as i can tell.
<LocutusOfBorg> xnox, do I smell, ABI changes?
<xnox> LocutusOfBorg, yes, loads =)
<chiluk> hey pitti are you around?
<chiluk> apw, pitti, can you take a look at https://bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/1607920 if you get a chance.  I'm pinging you because you guys both have touched it.
<ubottu> Launchpad bug 1607920 in zfs-linux (Ubuntu) "zfs services fail on firstboot if zfs-utils is integrated into the deployment image" [Undecided,New]
#ubuntu-devel 2016-07-30
<doko> xnox, CC for icu shouldn't make a difference
<tjaalton> meh, yet again installing upgrades shut down my desktop
<tjaalton> must be the power manager thinking my ups battery is dead
<tjaalton> yep, it's upower
<DonAlex> Hey all.
<DonAlex> Any chances someone can tell me if it is possible to port snapd (or better yet SystemBack) to 12.04 ?
<DonAlex> Systemback uses qt5 so I am thinking is is better to build a snap? But can snapd be build for 12.04 ?
<highvoltage>  /win 9
<ogra_> DonAlex, no, it cant
<ogra_> DonAlex, also note that there is a #snappy channel ;)
<DonAlex> oh ok.
<DonAlex> Thanks.
<showaz> Hi, ubuntu-server very old samba-ad (4.3.9)
<showaz> 4.4/4.5rc1
<showaz> 4.4.5 https://anonscm.debian.org/cgit/pkg-samba/samba.git/
<showaz> 37% samba-tool broken python scripts
<showaz> Ubuntu 16.04 /  samba-ad (4.3.9)
<showaz> I have created patches to support samba-4.5.0rc1, when send the patch?
<showaz> ERROR: System library tdb of version 1.3.10 not found, and bundling disabled
<xnox> not sure what to do with my private IRC logs
<xnox> keep them... or purge them because retention policy
<Unit193> Hmm?  Something going on?
 * xnox ponders to only keep at most 6 months, and thus e.g. drop all the logs 2015 and older.
<xnox> Unit193, no just realised that I have 4.1GB of IRC logs from my irc bouncer =)
<Unit193> Fun times.  I use xz. :3
<xnox> sure, i could compress/rotate them.
<xnox> but i feel like it's best to delete them.
<xnox> i have three years of logs
<Unit193> Mine go back to 2011... Huh.
<xnox> imho we should be deleting our logs. If one doesn't have personal data, it's hard to disclose it by accident.
<xnox> and gone.
<LocutusOfBorg> slangasek, hi, do you plan to try a sync of gnutls28?
<LocutusOfBorg> I'm trying a build right now
<LocutusOfBorg> one test seems to still be a problem
<LocutusOfBorg> LP: #1608129 opened
<ubottu> Launchpad bug 1608129 in gnutls28 (Ubuntu) "please merge gnutls28 from Debian" [Undecided,New] https://launchpad.net/bugs/1608129
#ubuntu-devel 2016-07-31
<hjd> Could someone please retry libitext-java and taglibs-standard in Yakkety? At least the first one is resolved with the new version of javahelper (javatools) and the other look quite similar.
<tsimonq2> could someone please take a look at bug 1496292 ?
<ubottu> bug 1496292 in packagekit (Ubuntu) "Needs to be ported to packagekit 1" [High,Confirmed] https://launchpad.net/bugs/1496292
<tsimonq2> it's blocking the installation of lubuntu-qt-desktop and I would really like to move this along ;)\
<tsimonq2> the problem is, I'm not entirely sure what else needs to be done
<tsimonq2> I'll take another look at it, but otherwise, I don't know
<tsimonq2> any help at all would be greatly appreciated
<tsimonq2> cyphermox: I see you are assigned to the bug, could you take a look please? ^
<pitti> chiluk: err, zfs uses /etc/mtab??
<pitti> chiluk: yeah, it should most definitively not use /etc/mtab -- /proc/self/mounts is correct
<ginggs> hjd:  libitext-java retried
<ginggs> hjd: taglibs-standard retried
<ginggs> hjd: libitext-java success, taglibs-standard failed again
<ginggs> hjd: i think i see the problem there, just downloading build-deps and i'll confirm
<hjd> ginggs: Thanks :) I only tested the first package, but the error messages looked similar enough that I thought it was the same root cause.
<ginggs> hjd: fixed and uploaded, would you believe a typo in debian/control caused that? https://sources.debian.net/src/taglibs-standard/1.2.5-1/debian/control/#L41
<hjd> ginggs: oh :)
<ahoneybun> mhall119: we need a MOTU
<LocutusOfBorg> ahoneybun, for what
<ahoneybun> LocutusOfBorg: we have changes in Kubuntu to upload to the archive
<LocutusOfBorg> ahoneybun, please give me dsc files
<LocutusOfBorg> or even better open bugs and subscribe ubuntu sponsors
<KALASH> mark shuttleworth is a cuck
#ubuntu-devel 2017-07-24
<mwhudson> well i've found the binutils commit that's to blame
<mwhudson> 32ec889602502348b704cfb16e65c83dc3eec095
<mwhudson> "Tidy up readelf's use of boolean values."
<Unit193> mwhudson: Ahaha!  Awesome timing, just now I get an email about it being stuck in proposed. :D
<mwhudson> Unit193: heh
<mwhudson> Unit193: gocryptfs?
<Unit193> Yep.
<mwhudson> the bot is a harsh mistress
<blahdeblah> There is a brief outage on *.qa.ubuntu.com coming up shortly; apologies for any inconvenience.
<blahdeblah> (also includes loco.ubuntu.com)
<Unit193> That's just loco.
<blahdeblah> Unit193: what do you mean?
<Unit193> Bad joke, sorry.
<blahdeblah> Some of us non-South Americans are a little slow
<blahdeblah> (Or is that all Spanish speakers?  Shows how ignorant I am...)
<Unit193> Should be a Spanish thing, yeah.  Also, Ohioian here, very north America.  Thanks for letting us know about the downtime.
<blahdeblah> It's long since done, BTW
<Logan> rbasak, smoser: would you mind taking a look at my merge request for scim-chewing when you get the chance? https://code.launchpad.net/~logan/ubuntu/+source/scim-chewing/+git/scim-chewing/+merge/327575
<Logan> also, what's the process for becoming a member of the Ubuntu Server Dev import team?
<LocutusOfBorg> mapreri, any idea for diffoscope autopkgtestsuite? it is blocking a lot of python stuff...
<mapreri> yes
<mapreri> LocutusOfBorg: it's due to this: https://sourceware.org/bugzilla/show_bug.cgi?id=21820
<ubottu> sourceware.org bug 21820 in binutils "readelf now exits with error reading an empty section" [Normal,Unconfirmed]
<LocutusOfBorg> so, regression in binutils?
<mapreri> Also reported as Debian #869532 for diffoscope
<ubottu> Debian bug 869532 in src:diffoscope "diffoscope: ftbfs with new binutils" [Normal,Open] http://bugs.debian.org/869532
<LocutusOfBorg> thanks :(
<mapreri> LocutusOfBorg: do you have any idea about why binutils didn't trigger a diffoscope autopkgtest, and wasn't blocked in proposed?
<mapreri> in general it feels like there are fewer tests than expected
<ricotz> hi, there are still quite a bunch of rebuilds to be done -- http://people.canonical.com/~ubuntu-archive/transitions/html/python3.6.html
<rbasak> Logan: it's on my team's list to take a look. Sorry it hasn't bubbled to the top yet.
<LocutusOfBorg> ricotz, maybe people are waiting for autopkgtestsuite become green?
<LocutusOfBorg> not sure who is handling that python transition
<xnox> the new binutils is blocked in proposed and not migrating
<ricotz> LocutusOfBorg, hopefully not, I guess it is mwhudson
<rbasak> cyphermox: any news on bug 1624519 please? It unsnoozed on my board.
<ubottu> bug 1624519 in tasksel (Ubuntu Artful) "Debian-defined tasks override Ubuntu-defined ones" [High,Triaged] https://launchpad.net/bugs/1624519
<mwhudson> ricotz: huh i hadn't seen that that had been updated
<mwhudson> mapreri: yeah that binutils thing is heaps of fun :(
<LocutusOfBorg> mwhudson, revert that commit for binutils? :)
<mwhudson> LocutusOfBorg: guess what the debdiff i have here does!
<LocutusOfBorg> just to make things migrate, otherwise a lot of stuff including python is blocked
<LocutusOfBorg> lol wonderful!
<LocutusOfBorg> mwhudson, do you want some help in python? I have not much knowledge, but I can allocate some hours there probably
<LocutusOfBorg> Its blocking my sane-backends gsoap and something more transitions :)
<mwhudson> LocutusOfBorg: sure
<LocutusOfBorg> and meh, there is a lot of perl fun that is waiting for it :)
<mwhudson> there's not much stopping python3-defaults from migrating really
<mwhudson> but knocking some things off the transition tracker would be nice
<mwhudson> careful, some are kind of false hits though
<mwhudson> e.g. boost i think
<mwhudson> LocutusOfBorg: if you want to figure out what's going on with botch......
<LocutusOfBorg> python-pex seems to be easily fixable
<LocutusOfBorg> mwhudson, botch is out of my knowledge
<mwhudson> yeah that one looks easy
<LocutusOfBorg> I already tried
<LocutusOfBorg> :)
<mwhudson> i'm surprised the package builds, but it does
<mwhudson> LocutusOfBorg: dammit
<LocutusOfBorg> I read your mail to ubuntu-devel list, and looked at it already, but I'll do a deeper look
<mwhudson> ubuntu-make is confusing me
<LocutusOfBorg> that one too, meh, strange
<LocutusOfBorg> only on some archs, it makes no sense
<LocutusOfBorg> maybe a meld of the good vs bad arch can show some stuff with new version built only partially
<LocutusOfBorg> pex uploaded, lets hope
 * LocutusOfBorg leaves changing network
<mapreri> mwhudson: the problem wrt diffoscope is that its behaviour when an external command fails is quite hardwired, and 1. changing it only for the elf comparator is just not possible without rewriting everything or doing very nasty hacks 2. changing it for all comparators is sure to have unintended effects
<mapreri> I suppose we could figure something out, butâ¦
<mwhudson> mapreri: that was the impression i got
<mwhudson> mapreri: a wrapper around readelf? :)
<mapreri> mwhudson: That's an example of nasty hack :3
<mapreri> besides, the elf comparator is so complex by itself
<mwhudson> mapreri: people working on transitions get good at nasty hacks :)
<mapreri> why are elf files so complex
<mapreri> everything should be an interpreted language
<Unit193> Sloooow.
<mwhudson> zip should be good enough for everyone
<ricotz> mwhudson, regarding python-transition: boost is not a false positive
<LocutusOfBorg> mwhudson, python-pex is fixed, and I emailed the patch to Barry
<doko> jamespage: #1698350, missing bug subscribers
 * jamespage looks
<jamespage> bug logfile not supported in this QEMU binary
<jamespage> bug 1698350
<ubottu> bug 1698350 in python-zunclient (Ubuntu) "[MIR] python-ovsdbapp, python-pypowervm, python-zunclient, python-deprecation, python-os-traits" [High,New] https://launchpad.net/bugs/1698350
<jamespage> doko: done - commented on bug
<LocutusOfBorg> mwhudson, for some reasons pex is not fixed
<doko> jbicha: I see you changed the myspell-* seed stuff in supported. I'd like to demote dict-nr dict-ns dict-ns dict-st dict-tn dict-ts dict-xh (ftbfs and not updated for years). How would that be done?
<doko> Laney: ^^^
<LocutusOfBorg> mwhudson, fixed now, the testsuite was running correctly and returning 120, what a mess
<mwhudson> ricotz: oh right i guess it needs a rebuild for that one extension module it rebuilds
<mwhudson> mapreri, doko: here's the binutils patch that might fix the diffoscope build http://paste.ubuntu.com/25161894/
<mwhudson> (testing diffoscope build with those packages now)
<mapreri> that's basically a revert of the regressing upstream commit, right?
<doko> mwhudson: is this just reverting an upstream commit?
<doko> is this somewhere tracked?
<mapreri> doko: https://sourceware.org/bugzilla/show_bug.cgi?id=21820
<ubottu> sourceware.org bug 21820 in binutils "readelf now exits with error reading an empty section" [Normal,Unconfirmed]
<mwhudson> doko: yeah it's reverting the commit mentioned in the bugzilla
<mwhudson> (with some fixups)
<mwhudson> oh ffs doesn't fix the build??
<mwhudson> ah no, holding it wrong
<mwhudson> i love[0] the way sbuild --extra-package x does not fail if x does not exist [0] may be a lie
<doko> ta, tracking the issue
<ginggs> doko: hi, any objections to a tbb sync? i have test-built a couple of rdeps, and i'll keep a lookout for any new failures
<mwhudson> i noticed that readelf exits with code 0 if you try to read a *missing* section
<doko> mwhudson: can you attach the object file to the bug report, just in case ...
<mwhudson> so exiting with code 1 for a present, empty, section must be a bug
<doko> ginggs: from experimental?
<ginggs> doko: yes, from experimental, including the multiarch
<doko> ginggs: sounds fine. we need it for GCC 7 anyway
<ginggs> doko: ta
<mwhudson> doko: done
<mwhudson> well that patch doesn't fix the build completely :(
<mwhudson> mapreri: does http://paste.ubuntu.com/25161949/ mean anything to you?
<mapreri> yes, that should be fixed with the last upload I think
<mapreri> at least I remember noticing it, and doing something to fix it.
<mapreri> ah, no, only in git still :(
<mapreri> mwhudson: https://anonscm.debian.org/git/reproducible/diffoscope.git/commit/?id=c8927db98131a129c5d7354bfe8a6b0886ca66f8 + https://anonscm.debian.org/git/reproducible/diffoscope.git/commit/?id=e62306e17e8a9b981d3b7f427bc99f8582a0301a is what I did to fix it.
<mapreri> I thought that was released already, but apparently I did it right after the last release was cut :S
<mapreri> (+ https://anonscm.debian.org/git/reproducible/diffoscope.git/commit/?id=c12bee5fc718c918d6280102d4dbe688b0a553cf)
<mwhudson> mapreri: time for an upload then? :)
 * mwhudson goes to bed
<mapreri> mwhudson: currently git doesn't pass the test as somebody did an incomplete addition... also would love to fix the autopkgtest also in debian :S
<hjd> Looks like the jruby and ruby-psych packages have a circular dependency on artful https://launchpad.net/ubuntu/artful/amd64/+builds?build_text=&build_state=depwait
<hjd> Anyone around to do a bootstrap or should I file a bug report on it? :)
<ahasenack> hi, could someone please sponsor https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1644428 ?
<ubottu> Launchpad bug 1644428 in samba (Ubuntu Zesty) "Unable to log in with AD account after update" [High,In progress]
<LocutusOfBorg> mwhudson, done
<ahasenack> it's a 2nd time regression, and a patch/MP has been up for weeks
<LocutusOfBorg> ahasenack, zesty-updates version + patch on comment #32?
<ahasenack> LocutusOfBorg: yes (the MP has been up for longer, but that's an internal problem I think that no-one looks at it)
<LocutusOfBorg> Hunk #1 FAILED at 1.
<LocutusOfBorg> 1 out of 1 hunk FAILED -- saving rejects to file debian/changelog.rej
<LocutusOfBorg> please rebase it
<ahasenack> of course...
<ahasenack> story of my life :)
<ahasenack> will get to it
<LocutusOfBorg> meh I can do it
<LocutusOfBorg> nvm
<LocutusOfBorg> debdiff is trivial
<jbicha> doko: the 'supported' seed was updated to match language-selector's data/pkg_depends
<ahasenack> LocutusOfBorg: thanks
<LocutusOfBorg> done yw
<LocutusOfBorg> mwhudson, isn't the botch failure some sort of missing sorting for the output?
<rbasak> jbicha: o/
<rbasak> jbicha: in bug 1698553, are you saying that the ppc related bit of the diff definitely isn't a regression? Or are you not commenting on that bit?
<ubottu> bug 1698553 in gjs (Ubuntu Zesty) "Update gjs to 1.48.5" [High,In progress] https://launchpad.net/bugs/1698553
<rbasak> I suppose if autoreconf has always been running then it shouldn't matter, but I'm not sure exactly how to confirm that.
<jbicha> you can confirm autoreconf is running by checking the build logs, here's the artful build which should be pretty similar
<jbicha> https://launchpad.net/ubuntu/+source/gjs/1.48.5-0ubuntu1
<jbicha> I don't know anything about what autotools does to ppc except that 1.48.5 built on artful for all supported Ubuntu arches
<jbicha> dh simple rules with debhelper compat 10 in zesty will run dh_autoreconf unless it's turned off (which isn't the case here)
<rbasak> by "that", I meant the "shouldn't matter" part, not that autoconf has always been running. Sorry I wasn't clear.
<smoser> Logan, i'll read... process... we dont really have a process at the moment.  the three members were just the people that kind of kick-started this. ultimately the goal is to have bot-only doing imports.
<smoser> Logan, still there ?
<ricotz> jbicha, hi, regarding mozjs52 I haven't spot something obvious yet
<ricotz> jbicha, the "autoreconf" patch is done with a ubuntu/debian toolchain?
<jbicha> ricotz: it came from https://github.com/ptomato/mozjs/commit/740bc5d9d66433370ba4137d03390d5ee21f26b4
<smoser> i think i misunderstood...
<ricotz> jbicha, so you don't know, is autoconf2.13 going away? otherwise I would suggest to keep the "real autoreconf"
<xnox> mwhudson, all i can say is that even diffoscope master FTBFS with old binutils and python3.6
<xnox> https://launchpadlibrarian.net/330406667/buildlog_ubuntu-artful-amd64.diffoscope_85~ubuntu1_BUILDING.txt.gz
<ginggs> doko: nice, your blender rebuild exercised the new tbb
<ahasenack> after verifying the fix for all affected releases, should I flip the global "verification-needed" tag to "verification-done"? Case in point: https://bugs.launchpad.net/ubuntu/+source/openvpn-auth-ldap/+bug/1602813
<ubottu> Launchpad bug 1602813 in openvpn-auth-ldap (Debian) "openvpn-auth-ldap causing segfault on network timeout" [Unknown,New]
<ahasenack> I did set verification-done-$release for all affected releases after testing
<tsimonq2> Logan: ack
<bdmurray> Why does autopkgtest end up using a lot of space on my / mount when I am using a qemu image on a different mount point?
<xnox> i thought it does a cow snapshot, to keep the golden image unmodified, and stores the copy-on-write layer somewhere in /tmp no?
<bdmurray> Could be, I haven't dug into it.
<tsimonq2> Is there a Core Developer available that would be able to help me with a Qt transition? I need a couple more rebuilds in the PPA then someone will need to land it. Details here: https://bileto.ubuntu.com/#/ticket/2819
<tsimonq2> Before that's landed though, I think we need to get the rest of the Unity 8 removals done so that there's minimal impact on the transition.
<tsimonq2> mitya57 went on vacation, so I'll be on my own for this one.
<tsimonq2> He told me before he left that slangasek had more information... what's new?
 * mwhudson is lost in a maze of britney output :(
<mwhudson> why is hunspell not migrating?
<jbicha> mwhudson: because of libreoffice which depends on python3-defaults
<mwhudson> ah
<mwhudson> same old story
<mwhudson> i think the link-grammar autopkgtests are now failing because the build the package with some of proposed enabled and then switch to running it with all of propsed
<mwhudson> or something along those lines
<mwhudson> need an aa to apply some force to this migration i think
<mwhudson> ok lets see if i can fix ubuntu-make today
<jbicha> LO i386's autopkgtest would need to be ignored too
#ubuntu-devel 2017-07-25
<mwhudson> xnox: hooray
<mwhudson> (ubuntu-make)
<mwhudson> xnox: so just need to get botch kicked out of artful-release and then python3-defaults should migrate?
<xnox> mwhudson, yeah, need to ping steve again about it.
<mwhudson> an archive admin, my kingdom for an archive admin
<xnox> mwhudson, i take your kingdom and raise you an empire
<ginggs> mwhudson: archive admins are next door, in -release
<mwhudson> ginggs: yeah
<clivejo> anyone here familiar with python module packaging?
<clivejo> Trying to use gbp buildpackage with this git repo https://anonscm.debian.org/cgit/python-modules/packages/pyee.git
<clivejo> but something keeps changing version.txt
<ginggs> mwhudson: and only offer them part of your kingom
<cjwatson> clivejo: That would be the fact that it uses https://pypi.python.org/pypi/vcversioner
<cjwatson> clivejo: version.txt should probably be gitignored
<clivejo> would you have a package I could see it in action?
<clivejo> an example of how its done
<cjwatson> sorry, no
<cjwatson> but git ignore isn't hard to look up
<clivejo> cjwatson: I have tried adding version.txt to .gitignore but gbp is still complaining that it has changed
<cjwatson> yeah you would have to actually remove it too
<cjwatson> perhaps there's a problem with it being in the upstream tarball though, I haven't checked
<clivejo> git rm --cached version.txt
<cjwatson> you might need to arrange to put back the upstream version on debian/rules clean
<clivejo> then added my .gitignore
<mapreri> doko: does that binutils upload include https://sourceware.org/bugzilla/show_bug.cgi?id=21820 as well?
<ubottu> sourceware.org bug 21820 in binutils "[2.29 Regression] readelf now exits with error reading an empty section" [Normal,Resolved: fixed]
<doko> mapreri: yes, forgot to add the changelog entry
<mapreri> doko: cool, thanks
<xnox> mwhudson, so botch is now done, ubuntu-make too. requeue / restarted adt tests python3-defaults triggering ubuntu-make. once those pass we shall see if python3-defaults migrates or not.
<infinity> juliank, xnox: Yo, where are we on apt versus unattended-upgrades.  Is the apt in the xenial queue "the final solution", or is there still more to discuss/fix/tweak?
<infinity> juliank, xnox: And if that's what we want, do we want/need it for the point release, and if so, is there enough time to verify it by the end of the week if I review and accept it today?
<xnox> there is time to verify it and push it through.
<juliank> infinity: There'll be another round with further improvements, but as it is, it already is a substantial improvement in itself.
<xnox> it would be nice, if we shipped it like 3 weeks ago, as clouds are complaining.
<juliank> Yeah
<xnox> infinity, we do want it soon - the stuff in the queue is enough to fix the cloud wining.
 * xnox vining?
 * xnox whyning?
<infinity> juliank, xnox: Alright, so you both agree that what's in the queue is a progression, even if not "perfect", and we want it soon?
<juliank> YES
<xnox> yes.
<infinity> Do we need unattended-upgrades changes to go with it, or can that apt update stand alone?
<juliank> It's an improvement either way. With the u-u changes it would be nicer
<infinity> Well, I don't see any u-u changes anywhere, which is why I asked. :P
<infinity> I thought there was something about needing new CLI options.
<juliank> Yeah, https://github.com/mvo5/unattended-upgrades/commit/db9eb377cbf371a07641ca5c58a030c6081c51ab https://github.com/mvo5/unattended-upgrades/commit/f26edb4425e488d7acdb825b0b6e8e327d2d51e6 https://github.com/mvo5/unattended-upgrades/commit/2e5deed4a3ef77fb0dcc02525eb32ed134b98a91
<juliank> em, read that right to left
<infinity> If only those were in an archive somewhere.
<xnox> >_<
<xnox> i thought options were not needed =/
<juliank> I wanted to get feedback on it :)
<infinity> Ahh, right, the apt bits check for the new option before attempting to use it.
<juliank> I mean, we can roll out the u-u change too, I think, now that it's merged.
<juliank> rbalint pushed these to mvo
<juliank> The change should be easy to review for an SRU, but I don't know if u-u builds in artful right now, it certainly does not in Debian
<infinity> juliank: Not sure I want to see them in an SRU before the devel release.  But the apt stuff looks guarded against old versus new, so we can just land it first.
<juliank> infinity: Yeah, it's also worth noting that the apt part is shipping in Debian stable, so I guess we get some good testing already :)
<juliank> We can either wait for mvo to finish the new unattended-upgrades release and then sync or merge that to artful, or just cherry-pick the changes now. I do have some time today :)
<mvo> juliank: I had one feedback item for rbalint in the PR, otherwise this looks good
<mvo> juliank: I also want to add pep484 to u-u, its probably also something for python-apt :)
<juliank> mvo: Once we drop python 2 support it is.
<juliank> Or we need to strip that stuff away for python 2 builds.
<juliank> But then I actually want to drop python2 support soon
<mvo> juliank: there is a # type: based syntax that is both py2 and py3 compatible, I use that in u-u because I need py2 compat
<mvo> juliank: its not as nice as the proper py3 stuff of course
<mvo> juliank: but gets the job done
<juliank> Hmm, yes, we can do that. But I have to say it looks ugly :/
<juliank> The major advantage of that for me is to have nicely readable type info
<mvo> juliank: I'm very excited about this, it brings python to a new level for me, the lack of basic static checking was always annoying me. agreed on UGLY
<juliank> We also really need to fix all the PEP8 errors in python-apt at some point
<juliank> I just added a hack to make it ignore that in the pre-build script :D
<mvo> juliank: indeed
<mvo> juliank: ha!
<juliank> python-apt uploads are basically NMU-style right now
<juliank> And perpetual beta
<juliank> It's missing like *one* binding to leave beta state
<mvo> juliank: which one is this? just out of curiosity
<juliank> Something with the MD5->HashsumList (??) transition is missing
<mvo> juliank: aha, that sounds reasonable
<juliank> mvo: It's apt_pkg.SourceRecords where 'files' is a list of tuples (md5: str, size: int, path: str, type: str)
<juliank> This tuple needs to become some magic type that works as a tuple, and also has named fields with a hashstringlist instead of md5
<juliank> And tuple-style access should cause deprecation warnings of course :)
 * mvo nods
<mvo> juliank: let me have a quick look at this pep8 stuff while I'm wait for my other code to run tests
<infinity> mvo: Do you remember how Python works?
<mvo> infinity: *cough*
 * mvo hugs infinity
<infinity> mvo: Honestly, more curious if you remember how C++ works, but that's less relevant to the above discussion. :P
<juliank> infinity: Maybe mvo should work on the Go bindings instead. They only do configuration now https://github.com/julian-klode/go-apt
<juliank> :D
<mvo> juliank: ha! nice, I was actually thinking aobut this
<infinity> juliank: I assume they're cgo bindings around libapt.  That's not how the Go community works.  The only acceptable Go solution is to rewrite libapt itself in Go.
<infinity> (I wish I was joking)
<juliank> infinity: They actually first wrap the C++ interface in a C interface and then wrap that in Go
<mvo> infinity: I still do, but right now my go skills are way more fluent
<infinity> juliank: Sure, yes.  Hence "cgo".
<juliank> Because of course, C++ is not supported directly by cgo :(
<juliank> That said, it might be useful to have a nice, easy-to-use C binding for APT
<infinity> To be fair, cgo isn't supported by cgo.  See above. :P
<infinity> But agreed that a libcapt that's a C binding to libapt would be nice.
<infinity> And then the cgo bindings would link libcapt.
<infinity> *hand-wavy*
<juliank> Exactly
<juliank> I currently mostly write Go, it's always confusing to switch to C or C++
<juliank> Right now I'm used to if expression { } ...
<infinity> Yeah, I don't write any Go, but I read/review more than I'd like, and it's the subtle syntax differences that would drive me nuts if I were writing it.
<infinity> I mean, I'm sure I'd be fine if it was my only language, but it seems gratuitously nasty for people who need to switch back and forth.
<juliank> If you're used to if (...) {} and never write if (...) statement, it's fine, gofmt automatically drops the ()
<juliank> That said, the only C++ code I touch atm is apt, and that's not even a style I like
<juliank> That's worked around now, though: All new code is automatically formated with clang-format :D
<juliank> s/new/changed/
<infinity> No sympathy here, most of the C I touch is glibc, which is GCS, ish.
<juliank> (APT is Allman style with 3 space indent, 8 space tabs, and tabs always used)
<juliank> glibc is awful
<infinity> That whole 4 spaces, tab, tab+4spaces, etc thing drives me batty.
<mvo> go fmt ftw!
<juliank> go fmt definitely was the right decision
<infinity> But changing the whitespace formatting of a project that large is basically a non-starter, and we all prefer consistency to having new code formatted "better", so we're stuck with what we have.
<infinity> Changing format of a project is a stellar way to break all VCS history.
<juliank> infinity: It's better than 3 spaces, 6 spaces, 1 tab + 1 space, tab + 4 space, tab + 7 space, 2 tab + 2 space
<infinity> That made my head hurt.
<infinity> I don't care if people prefer tabs or spaces, I just prefer a style that uses one or the other, not both.
<Laney> and Unicode identifiers?
<infinity> Mixed styles offend me.
<juliank> infinity: It's OK if you have tabs for indentation, and spaces for alignment of continuation lines.
<infinity> juliank: Oh yes, and that's my preferred POSIX shell style.
<infinity> juliank: I don't consider continuation to be part of indentation, though, it's just a bonus to make something a bit more friendly.
<infinity> (And continuation styles mixed with line-length caps are where Python PEP-whatever kills me)
<infinity> Cause hey, it's totally "readable" to break your (foo, bar, baz, thing, stuff) across 7 lines because it happens near the end of an 80-char line.
<infinity> Yep.
<infinity> Super readable.
<infinity> Except, y'know, the opposite thing.
<juliank> Sometimes it's quite nice to have one element per line
<juliank> But yeah, sometimes it gets weird
<infinity> juliank: Okay, sure, one element per line can be intentionally readable, so pretend I meant 1 element, then 2, then 1, then...
<infinity> Basically, following the letter of the PEP that demands no line extend past 80, and continuation happen at the opening bracket.
<infinity> Which paints you in some fun corners.
<juliank> Well, I'd split them up further, even if the line is shorter than it could be
<juliank> Well, sometimes I do group related items together in a single line :)
<juliank> mvo: One thing that will get odd about gofmt is when they fix a bug there and a lot of code gets formatted differently.
<infinity> (Mostly, I think I'm just not on board with people who think 80 chars is somehow sacred in the modern world of HD+ displays, etc)
<mvo> juliank: yeah, its important that the repo keeps go fmt clean
<infinity> If you're still stuck in an 80x24 terminal, you might have bigger problems than my line lengths.
<juliank> mvo: No, I meant if gofmt changes its output format, that will cause quite some turmoil
<infinity> juliank: Yeah, see above with my "changing format breaks VCSes". :/
<juliank> infinity: 80 characters is nice because narrower text is easier to read due to some unknown reasons.
<infinity> OTOH, you get to take credit for a 25000 line commit when you commit the changes!
<juliank> But it should be a soft rule, not a hard rule
<maswan> juliank: also, that's roughly 80 chars on the right hand side of indentation
<juliank> infinity: NeoMutt reformatted all code with clang-format, if you need an example :)
<infinity> juliank: Oh, I'm super dyslexic (I need to track with a finger or ruler, use intentionally small browsers, etc), but if a line needs to be long to be readable, it needs to be long.  Such is life.
<maswan> juliank: if you go by "ease of reading text"
<LocutusOfBorg> mapreri, devscripts "seems" fixed
<LocutusOfBorg> ta
<juliank> maswan: Yes, code is fairly similar to text, so I'd assume they'd behave differently, but there was obviously only a study on the latter
<juliank> s/differently/similarly/
<infinity> maswan: A fair point.  And if those standards were written because of line-tracking/reading issues, "80 chars after the whitespace" would be a much saner rule.
<infinity> maswan: But, of course, they were written because of 80x24 VT terminals, not readability.
<infinity> Ultimately, I guess we can blame DEC.
<infinity> Somehow.
<doko> jamespage: ceph has some installability issue in proposed
<xnox> cyphermox, https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful/artful/i386/n/nplan/20170725_021235_59459@/log.gz nplan seems to fail, looking at i386 history it is flaky. But i do wonder if util-linux affects NM on i386 in strange ways. As usually one or two retries does the trick.
<xnox> AssertionError: timed out waiting for NetworkManager to settle down
<xnox> and there are also
<xnox> Error: Could not create NMClient object: GDBus.Error:org.freedesktop.DBus.Error.NoReply: Message recipient disconnected from message bus without replying
<xnox> is there a way to get the test pass, or troubleshoot what is going on. on i386.
<xnox> it is holding up util-linux at the moment.
<xnox> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#util-linux
<jamespage> doko: yeah - needs a MIR of something - on my list for this week
<doko> jamespage: needed for python3-defaults to migrate
<jamespage> doko: ok bumping priority
<infinity> jamespage: Looks like it just needs cherryp3 to re-promote.  It was already MIRed in saucy.
 * infinity does that now.
<doko> jamespage: it's not the last blocker, but thanks
<jamespage> infinity: yeah - I was just looking at that - thanks!
<mapreri> LocutusOfBorg: \o/
<mapreri> mwhudson: FWIW, diffoscope builds with today's binutils
<mapreri> well, once fixed the other thing, etc
<mapreri> git is in a funky state atm, but will upload once things are cooled down....
<mapreri> (I prefer to not branch out just for this, but of course I can do a number of things if suddenly a buildable diffoscope is needed urgentlyâ¦)
<xnox> C++ is aweful
<catbus> Hi, will 17.04 4.11 kernel be available in the 16.04 daily image before the 16.04.3 is released? Wondering if there is sort of a beta version to try.
<sarnold> catbus: maybe this https://launchpad.net/ubuntu/+source/linux-hwe-edge ?
<catbus> sarnold: I think I found what I am looking for: http://cdimage.ubuntu.com/ubuntu-server/xenial/daily/current/.
<sarnold> /pool/main/l/linux-hwe/linux-image-4.10.0-28-generic_4.10.0-28.32~16.04.2_amd64.deb
<sarnold> woot
<catbus> sarnold: Thanks. I was looking for the image, not just the hwe-kernel package.
<mwhudson> so why hasn't python3-defaults migrated today
<ricotz> mwhudson, afaics there are some desktop-packages which need a python-nochange-rebuild: e.g. eog-plugins, gedit, gedit-plugins
#ubuntu-devel 2017-07-26
<tsimonq2> Logan: Hey, so what did you find out with kanatest?
<Unit193> Hey, so after seeing some tests that should not be failing, I ran  autopkgtest -U --apt-pocket=proposed -- lxc autopkgtest-artful  on ruby-net-scp and that passed for me.
<Unit193> http://autopkgtest.ubuntu.com/packages/r/ruby-net-sftp/artful/amd64 also shouldn't have failed.
<Unit193> 34 tests, 66 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications
<Unit193> 100% passed
<mwhudson> nice
<Unit193> I know because I prepped several uploads in Debian for ruby-net-ssh. :P
<Unit193> mwhudson: Should I ask where you are?  You seem to always be alive in the 'dead zone'.
<Unit193> Is there a way to get them testing against -proposed?
<ginggs> Unit193: the tests can be triggered against additional packages
<Unit193> ginggs: ruby-net-scp/ruby-net-sftp need --apt-pocket=proposed=src:ruby-net-ssh
<ginggs> Unit193: retrying
<Unit193> Thanks!
<Unit193> I understand I don't have permissions for it, but how?
<ginggs> Unit193: do you see the links for retrying (they look like recycle icons) on  http://autopkgtest.ubuntu.com/packages/r/ruby-net-sftp/artful/amd64 ?
<Unit193> ginggs: I did, but since it needed a package from -proposed I thought the fine tuning would be different.
<ginggs> Unit193: ok, so look at the URL of one of the retry links, then add '&trigger=ruby-net-ssh%2F1%3A4.1.0-1'
<Unit193> That's officially 'fun'.  Thanks.
<mwhudson> Unit193: nz
<mwhudson> yes, retry url hacking is fun
<mwhudson> you can also add &all-proposed=1
<Unit193> Ah.  I'm not core nor motu (just packageset), so not (yet) really able to useit.
<LocutusOfBorg> mwhudson, what is the last thing blocking python3.6?
<LocutusOfBorg> Unit193, I stole your wine-development merge
<Unit193> I had one?
<Unit193> Thanks, LocutusOfBorg!
<LocutusOfBorg> you asked me to sponsor that for you
<Unit193> Good enough. :)
<LocutusOfBorg> go cmake, go
<mwhudson> LocutusOfBorg: yara ftbfs on armhf
<LocutusOfBorg> ack
<mwhudson> LocutusOfBorg: which i am hacking almightily now
<LocutusOfBorg> I'm fixing the last gtk-d failures
<LocutusOfBorg> oh wonderful
<mwhudson> oh boy this code really expects aligned access to work
<mwhudson> like, a lot
<mwhudson> xnox: what do you think about removing the existing yara binaries on armhf? (and rdeps i guess)
<mwhudson> xnox, slangasek, doko: sent an update to ubuntu-devel about yara
<LocutusOfBorg> can I ask for a little perl advice?
<LocutusOfBorg> Laney, the debhelper merge is ready, but I fail to parse the Ubuntu version
<Laney> you what?
<LocutusOfBorg> 	perl -e ' undef $/; foreach (@ARGV) { open (IN, $_) or die "$_: $!"; $file=<IN>; close IN; if ($file=~m/=head1 .*?\n\n(.*?) - (.*?)\n\n/s) { my $item="=item $1(1)\n\n$2\n\n"; if (" dh_installmanpages " !~ / $1 /) { $list.=$item; } else { $list_deprecated.=$item; } } } END { my $recommended_compat = 10.6.4ubuntu1; $recommended_compat =~ s{\..*}{}; while (<STDIN>) { s/#LIST#/$list/; s/#LIST_DEPRECATED#/$list_deprecated/;
<LocutusOfBorg> s/#RECOMMEDED_COMPAT#/$recommeded_compat/; print; }; }' dh_auto_build dh_auto_clean dh_auto_configure dh_auto_install dh_auto_test dh_bugfiles dh_builddeb dh_clean dh_compress dh_fixperms dh_gconf dh_gencontrol dh_icons dh_install dh_installcatalogs dh_installchangelogs dh_installcron dh_installdeb dh_installdebconf dh_installdirs dh_installdocs dh_installemacsen dh_installexamples dh_installgsettings dh_installifupdown
<LocutusOfBorg> dh_installinfo dh_installinit dh_installlogcheck dh_installlogrotate dh_installman dh_installmanpages dh_installmenu dh_installmime dh_installmodules dh_installpam dh_installppp dh_installudev dh_installwm dh_installxfonts dh_link dh_lintian dh_listpackages dh_makeshlibs dh_md5sums dh_missing dh_movefiles dh_perl dh_prep dh_shlibdeps dh_strip dh_systemd_enable dh_systemd_start dh_testdir dh_testroot dh_ucf dh_update_autotools_c
<LocutusOfBorg> onfig dh_usrlocal | \
<LocutusOfBorg> 	pod2man --utf8 -c Debhelper -r "10.6.4ubuntu1" --name="debhelper" --section=7  > debhelper.7
<LocutusOfBorg> https://launchpadlibrarian.net/330668177/buildlog_ubuntu-artful-amd64.debhelper_10.6.4ubuntu1_BUILDING.txt.gz
<LocutusOfBorg> bad copy-paste
<LocutusOfBorg> forcing VERSION=10 "fixes" it, but it is hacky and bad
<LocutusOfBorg> solution is to drop that ubuntu in recommended compat, right?
<LocutusOfBorg> the question is: should I revert somewhere this? https://anonscm.debian.org/git/debhelper/debhelper.git/commit/?id=d2ca3a7f964eb915035c4526baa92325d3f6dbd7
<LocutusOfBorg> $$recommended_compat =~ s{\..*}{};
<LocutusOfBorg> this is what fails
<Laney> is it calculating that variable wrong?
<LocutusOfBorg> the problem is that rege
<LocutusOfBorg> with the debian version 10.6.4 is returning "10"
<LocutusOfBorg> with the ubuntu version, 10.6.4ubuntu1 it returns "can't parse foobar"
<LocutusOfBorg> Bareword found where operator expected at -e line 1, near "10.6.4ubuntu1"
<LocutusOfBorg> so, this code "$recommended_compat =~ s{\..*}{};" is having issues
<LocutusOfBorg> FWIW doing this VERSION=$(shell dpkg-parsechangelog -SVersion |cut -f 1 -d "u") also works, because it strips the "ubuntu" part from version
<Laney> LocutusOfBorg: Looks like it should be quoted?
<Laney> my $recommended_compat = 10.6.4ubuntu1;
<cjwatson> Yeah that probably just wants to be my $$recommended_compat = q($(VERSION));
<cjwatson> or similar
<cjwatson> hmm, do I have upstream commit access
<cjwatson> doesn't look like it
<LocutusOfBorg> sorry, bad connection sigh
<LocutusOfBorg> seems not good, man ./debhelper.7 shows: "#RECOMMEDED_COMPAT#" instead of 10
<cjwatson> I'm preparing a patch
<LocutusOfBorg> ack, do you want to directly upload debhelper? I can give you the merge, or you can just grab from the ppa above
<cjwatson> not especially
<cjwatson> I'll send a patch to Debian
<LocutusOfBorg> ok thanks
<Laney> There's some "recommeded" / "recommended" confusion too.
<cjwatson> yes, I'm fixing that
<Laney> Nod
<LocutusOfBorg> so also debian manpages should be bad
<LocutusOfBorg> yes lol
<cjwatson> indeed
<cjwatson> ... and a lack of s///g ...
<cjwatson> LocutusOfBorg,Laney: https://bugs.debian.org/869780
<ubottu> Debian bug 869780 in debhelper "debhelper: recommended compat version substitution is totally broken" [Normal,Open]
<cjwatson> feel free to cherry-pick or whatever
<Laney> cjwatson: Ta
<Laney> LocutusOfBorg: You going to take that?
<rbalint> juliank: are you ok with the smaller patch against apt in LP: #1690980 ?
<ubottu> Launchpad bug 1690980 in OEM Priority Project "unattended-upgrades does not block shutdown of system, as it is designed to" [Critical,Triaged] https://launchpad.net/bugs/1690980
<LocutusOfBorg> Laney, will upload in ppa
<LocutusOfBorg> sorry I was @lunch
 * Laney nod
<juliank> rbalint: Tech side is OK, but I'm thinking about the commit message summary. It's a bit long, does not mention the timeout, and mentions shutdown, whereas it's any service stop that is affected?
<juliank> Gracefully terminate processes apt-daily-upgrade.service on stop?
<LocutusOfBorg> Laney, do you want to do some testing before I upload to Ubuntu? I admit, I'm worried about it :)
<rbalint> juliank: thanks that's clear and short
<juliank> oh, it's missing a word
<rbalint> juliank: so sure, feel free to change it
<juliank> Gracefully terminate processes *in* apt-daily-upgrade.service on stop
<rbalint> do you plan landing 1.2.25 in xenial in the near future?
<juliank> Let's go with "Gracefully terminate process when stopping apt-daily-upgrade"
<juliank> rbalint: Hey, I'm waiting for 1.2.24 since 5 weeks or so to enter proposed. 1.2.25 is basically scheduled now-ish, after the next 1.5 beta (and 1.4.8)
<juliank> I did not yet push even 1.4.7 to zesty, as I'm waiting for 1.4.6 to be approved first
<juliank> And AFAIUI, updates are supposed to be in newer suites before older ones.
<juliank> So, the plan would be to have the service fix in 1.5~beta2, cherry pick to a 1.4.8 release, and cherry-pick that and the stuff from 1.4.7 into 1.2.25
<juliank> see bug 1702326 for the changes in 1.4.7
<ubottu> bug 1702326 in apt (Ubuntu Zesty) "New microrelease 1.4.7 for zesty" [Medium,Triaged] https://launchpad.net/bugs/1702326
<juliank> (basically minor (in size) fixes to the http method to correctly handle some server responses)
<rbalint> juliank: ok, thanks!
<juliank> There are no other fixes scheduled for 1.4.8 at the moment, so that would be just the service change :)
<juliank> Oh, I see DonKult has some fixes in his repo he did not push yet
<rbalint> mvo: i'm fairly confident in the u-u PR, maybe could you please take a look again?
<mvo> rbalint: sure, let me do that now
<LocutusOfBorg> mapreri, diffoscope: error: unrecognized arguments: --thisflagdoesntexistandwontexist
<LocutusOfBorg> diffoscope on s390x seems sad
<LocutusOfBorg> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful/artful/s390x/d/diffoscope/20170726_103422_64cc6@/log.gz
<mapreri> LocutusOfBorg: that's not an error
<mapreri> indeed that autpkgtest test passes
<mapreri> and yeah, that thing is another failure that is fixed by another commit I forgot aboutâ¦
<mapreri> (btw, that test is there to test that if you pass an invalid argument diffoscope exists with code 2)
<LocutusOfBorg> ack
<LocutusOfBorg> mwhudson, why python3-defaults is not pointing at the right python? I'm lost
<LocutusOfBorg> https://launchpad.net/ubuntu/+source/python3-defaults/3.6.1-0ubuntu2
<LocutusOfBorg> it should be 3.6.2
<LocutusOfBorg> sagemath is picking up Get:10 http://ftpmaster.internal/ubuntu artful-proposed/main amd64 libpython3-stdlib amd64 3.6.1-0ubuntu2 [7012 B]
<LocutusOfBorg> and not sure if this is the reason for its failure
<mapreri> LocutusOfBorg: https://anonscm.debian.org/git/reproducible/diffoscope.git/commit/?id=7e16cecb98ec2e874da4f3ea291e276602852dcd
<mapreri> and probably will need https://anonscm.debian.org/git/reproducible/diffoscope.git/commit/?id=fe57c99828060ae77af2784961d47beb44eb74f5 as well..
<LocutusOfBorg> I uploaded with the first patch, since I can't test s390x
<mapreri> it's weird that only s390x failed
<mapreri> that thing failed in debian as well, on amd64
<LocutusOfBorg> Laney, https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+packages
<LocutusOfBorg> do you want to test it out? :p
<LocutusOfBorg> I uploaded wxwidgets3.0 on that ppa, lets see if it works or not
<juliank> rbalint: I forgot to tell you, I committed it in https://anonscm.debian.org/cgit/apt/apt.git/commit/?id=78bc10d4702b30b46d802294ac43cffc34d9c431
<juliank> rbalint: Feel free to do a 1.5~beta1ubuntu1 now if you want it now, 1.5~beta2 comes in a few days
<juliank> Well, it might come today, but I'm not sure what DonKult is up to exactly
<ogra_> arges, hmm, how did my name end up in that livecd-rootfs changelog ? i cant remember ever touching any of this
<arges> ogra_: I didn't put it there...
<ogra_> arges, well, you upploaded it
<ogra_> (but i see, seems rcj assembled it)
<ogra_> well, not that important anyway ... i was just wondering how my name got on there
<arges> https://launchpad.net/ubuntu/+source/livecd-rootfs/2.408.13 looks correct, I think my 'sru-release' script seems to have printed incorrect info on the bug
<ogra_> yeah, that was the trusty sru
<ogra_> not the xenial one :)
<ogra_> https://launchpad.net/ubuntu/+source/livecd-rootfs/2.208.14
<arges> ah, yea I think rcj included other patches in his upload
<ogra_> (thats fine, but i still cant remember ever touching any vmdk, ova or vargrat stuff in my life ;) )
<ogra_> (at least not in livecd-rootfs ... but perhaps my memory fades :P i'm getting old ... :)  )
<arges> pkkk~.
<arges> ~
<arges> .~.
<arges> whoops
<LocutusOfBorg> arges, this seems the command used to kill a stuck ssh connection, correct?
<rcj> ogra_: I pulled in contributions to livecd-rootfs in the utopic->xenial timeframe for that trusty upload to support build of cloud-images.  I kept all the contributors names.  I can't recall which you contributed to but it must have been in there ;)
<rbalint> juliank: thanks, in a few days is ok i would not create a delta for a few days in in this case
<xnox> mwhudson, it is landing =)
<xnox> i'm sure it will spill over two publications and screw people up for an hour or so.
<doko> yeah, got 56 migration mails ...
<zhongjun> nacc: hi
<nacc> zhongjun: hello
<zhongjun> nacc: I got this error in ubuntu 16.04 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=847557
<ubottu> Debian bug 847557 in nfs-kernel-server "/usr/sbin/exportfs: exportfs cannot handle IPv6 addresses" [Important,Open]
<zhongjun> nacc:  This bug has been fixed in nfs-kernel-server version 1:1.3.4-1
<zhongjun> nacc: Could we backport the "fix" in  nfs-kernel-server version 1:1.2.8
<zhongjun> nacc: Could we backport the "fix" in  ubuntu 16.04
<nacc> zhongjun: do you know the specific fix?
<zhongjun> nacc: Actually, I am not sure about the specifix fix
<nacc> zhongjun: if you want it in xenial-backports, you can request it (https://wiki.ubuntu.com/UbuntuBackports). But for a bugfix to go into xenial-updates, you have to know what the bugfix is (https://wiki.ubuntu.com/StableReleaseUpdates).
<zhongjun> nacc: Is there a fast way or some links that I could make me find the specific fix quickly?
<zhongjun> nacc: Is there a fast way or some links that it could make me find the specific fix quickly?
<rbasak> zhongjun: https://en.wikipedia.org/wiki/Bisection_(software_engineering) maybe?
<nacc> zhongjun: you would need to look at what was fixed in teh debian upload. More than likely it's an upstream fix (not a debian-specific one). Generally, no, there's not a 'quick way'
<rbasak> Or yeah, look through the commit messages and changelogs.
<zhongjun> rbasak, nacc: Thanks,  if anyone familiar with exportfs  IPv6, please tell me
<roaksoax_> 4/win 3
<doko> xnox: do you know if LocutusOfBorg will do the perl merge and start the perl transition?
<xnox> no idea.
<doko> ok, then I'll do the merge
<Laney> why not wait and ask?
<ginggs> doko, Laney: lemme ask him
<mapreri> last I heard from him he said "I won't until python is good"
<LocutusOfBorg> doko, why do you think this is a merge?
<LocutusOfBorg> I'm uploading a no-change rebuild in a ppa
<doko> was zlib updated in Debian?
<LocutusOfBorg> some of the patches I'm carrying are fixed in new perl, so probably a plain sync will work
<LocutusOfBorg> no doko it wasnt
<LocutusOfBorg> btw I just uploaded debhelper, for sure I would wait a little bit before syncing perl
<LocutusOfBorg> uploaded in my ppa
<doko> LocutusOfBorg: so you are handling this?
<LocutusOfBorg> if you want to help, please help :)
<LocutusOfBorg> I can do the sync/merge, but for sure I can't handle perl alone
<LocutusOfBorg> (I was waiting for python3-defaults to land)
<LocutusOfBorg> does this sound ok for you?
<LocutusOfBorg> sync/merge in one hour or two
<LocutusOfBorg> and then do the rebuilds tonight/later
<doko> I only want to make sure that it's done mid next week, before I start with gcc-7
<LocutusOfBorg> this sounds like a good plan
<LocutusOfBorg> I'm just worried about the testsuite
<LocutusOfBorg> but  yeah, lets sync and start rebuilds in one hour
<LocutusOfBorg> builders are bad now, amd64 is sloooow
<LocutusOfBorg> not sure what they are building, hopefully they will be green soon
<LocutusOfBorg> we still have that perl "hey don't build arch:all before arch:any or rmadison will be sad" stuff
<LocutusOfBorg> so, I want amd64 ready before syncing
<doko> which ppa?
<LocutusOfBorg> ~costamagnagianfranco/locutusofborg-ppa
<LocutusOfBorg> ppc64el started, so I guess we can just wait for it
<LocutusOfBorg> test failures were common
<LocutusOfBorg> doko, can you please bump debhelper priority? https://launchpad.net/ubuntu/+source/debhelper/10.6.4ubuntu1
<LocutusOfBorg> I don't want the egg and cichken issue
 * LocutusOfBorg chicken 
<jbicha> tumbleweed: reverse-depends doesn't seem to handle '-r testing' or '-r buster'
<LocutusOfBorg> jbicha, would be nice to see also -r artful-proposed, to understand which stuff has already been rebuilt on top of the new library :)
<LocutusOfBorg> thanks to whoever did it
<cjwatson> LocutusOfBorg: security updates, but it'll get there in a bit
<ginggs> why would objcopy fail to extract debug info on the buildds when FPC calls it, but works fine if I call it with the same arguments from a build script?
<LocutusOfBorg> cjwatson, I mean, thanks to whoever bumped the priority of perl and debhelper :)
<LocutusOfBorg> no problem cjwatson, breaking the whole world can wait some hours I hope :p
<cjwatson> not I
<LocutusOfBorg> doko, the plain sync seems to have worked on ppc64el
<LocutusOfBorg> so, lets wait for builders to settle down and I'll force-sync
 * LocutusOfBorg leaves
<LocutusOfBorg> cheers!
<bluefoxxxx> which channel for help with community documentation issues?  Just #ubuntu?
<tsimonq2> bluefoxxxx: I assume #ubuntu-doc?
<bluefoxxxx> thanks
<tumbleweed> jbicha: ah, I think the distro-info-data was out of date, re-running it now
<LocutusOfBorg> doko, sync?
<LocutusOfBorg> I'm doing it, done
<tumbleweed> jbicha: fixed
<jbicha> thanks!
<tsimonq2> slangasek, infinity, jbicha: Hey there! I'll be helping with the Qt transition while mitya57 is off on vacation, what's the status of getting the Ubuntu Touch packages removed from the archive? If a new Qt version is uploaded, it probably won't migrate from -proposed unless those are removed...
<slangasek> tsimonq2: from my perspective, xnox was driving these removals; I'd check with him on status
<tsimonq2> slangasek: Thanks.
<doko> LocutusOfBorg: I'm uploading the first batch of perl rebuilds
<nacc> mdeslaur: fyi, apache2 2.4.27-3 is now in unstable. I'll merge up to that, which should be past the version that declares http2 stable.
<mdeslaur> nacc: great, thanks
<mwhudson> xnox: \o/
<LocutusOfBorg> doko, ack thanks
<LocutusOfBorg> I'll rekick some stuff
<Unit193> infinity: I don't suppose you're online?
<infinity> Unit193: I might be.
<Unit193> I was wondering why specifically in https://launchpad.net/ubuntu/+source/ruby-specinfra/2.66.0-1ubuntu1 you added that, I don't see it in the requirements and autopkgtests pass without it.
<Unit193> Based on grep, I do see how one might use it, but I'm wondering 1. How you saw that.  2. If the build-dep is still needed.
<infinity> Unit193: If I recall, it actually showed us as failures in rdeps.
<Unit193> I wondered if that was the case, if it were I wouldn't think build-depend...
<infinity> Build-dep was probably to cover a build-time testsuite or something, but might possibly have been a paranoid error.
<infinity> I don't see how it hurts either, mind you. :P
<Unit193> I see "spec/command/debian/port_spec.rb:  it { should eq 'netstat -tunl | grep -- :80\ ' }" in that version, and "lib/specinfra/command/base/port.rb:      "netstat -tunl | grep -- #{escape(pattern)}"" in the new.
<infinity> Lots of calls to netstat in the source.
<Unit193> infinity: Right, but if I push to Debian, specifically in a package I'm not an uploader, I want to make dang sure it's needed. :)
<Unit193> Yeah, though a lot under 'freebsd'
<Unit193> infinity: Thanks for explaining, and for remembering that long ago!
<infinity> Unit193: Well, I would test it without the build-dep, but apparently the testsuite breaks earlier. :P
<infinity> /usr/lib/ruby/2.3.0/rubygems/specification.rb:1436:in `block in activate_dependencies': can't satisfy 'net-ssh (< 4.0, >= 2.7)', already activated 'net-ssh-4.1.0' (Gem::LoadError)
<Unit193> sudo autopkgtest -U --apt-pocket proposed=ruby-net-ssh -- lxc autopkgtest-artful
<infinity> Unit193: But I'd posit that if it passes for you, your chroot is dirty (ie: has net-tools in it)
<Unit193> I have no idea about the autopkgtests, it shouldn't have been installed (it's a new container, nothing abnormal), and the base chroot I used to build didn't have it either.
<infinity> And the testsuite ran?
<infinity> I mean, I literally just tried to build it and the testsuite doesn't run at all.
<infinity> So, I kinda want to know how you managed.
<Unit193> The old one I think I targetted for Zesty, I'm working on a new version that of course handles net-ssh 4.x
<infinity> Anyhow, it's possible the build-dep was in error if the ruby-specinfra testsuite doesn't exercise that bit of code (though, that would be a bug in lack of coverage of the testsuite, then), but the dependency is obviously correct.
<infinity> And was needed for testsuites of OTHER rdeps to pass.
<infinity> (And just needed because duh)
<Unit193> infinity: Re-running the autopkgtest, something else is pulling net-tools in, that could be the answer. :P
<Unit193> Err..
<Unit193> infinity: SO yes, for sure no net-tools in the autopkgtest..container, and it still passed. No idea how to give you the log for autopkgtest run though.
<infinity> Unit193: autopkgtest isn't relevant here, though.
<infinity> Unit193: The direct dependency is correct *even if* the testsuite doesn't exercise that code.
<infinity> Unit193: We don't add deps just to satsify testsuites.
<infinity> Unit193: Now for *building*, the build-dep might not be relevant if the testsuite doesn't run that code, but also meh?
<Unit193> infinity: In this case, autopkgtest also builds it.  And I figured good to specifically run with autopkgtests as they're a bit of a blackbox to me still.  Of course building runs the tests, and the build passes. :)
<Unit193> To be clear, no I agree with your first point, net-tools should be a *depend*, but *build-depend* was what I was trying to figure out.
<Unit193> (https://deb.li/3PbhA)
<infinity> Unit193: Sure.  Build-dep might have just been a belt-and-bracers thing because I knew the build ran a testsuite and I didn't care to check if it had decent coverage.
<Unit193> Good enough.
<infinity> Unit193: And path of least resistance, since it had literally always built with net-tools in the past.
<Unit193> Sure, understandable.
<infinity> Unit193: I do know some OTHER testsuite exercises that code, cause that's how I noticed the bug, but damned if I can figure out what it was now. :P
<Unit193> ruby-serverspec or chef, likely.
<infinity> Didn't seem to be either of them at a glance.
<infinity> But there's also serverspec-runner, which might be a test-depend somewhere or something.
<infinity> I dunno.  I gave up looking, I have a dinner to run off to. :P
<Unit193> Food is always a good reason.
<infinity> Free food.
<infinity> Paid for by parents.
<Unit193> Ooooooh.
<infinity> So, +1/-1
<infinity> But steak, so maybe another +1?
<Unit193> Yes very much so.
<Unit193> But, anywho if all goes well that package is syncable now. \o/
#ubuntu-devel 2017-07-27
<Unit193> LocutusOfBorg: ...You should look into merging dput! >_>
<Unit193> !info dput artful
<Unit193> !info dput unstable
<ubottu> dput (source: dput): Debian package upload tool. In component main, is optional. Version 0.9.6.4ubuntu3 (artful), package size 32 kB, installed size 164 kB
<ubottu> dput (source: dput): Debian package upload tool. In component main, is optional. Version 0.12.1 (unstable), package size 53 kB, installed size 196 kB
<Unit193> I have nominated LP 651610 for xenial and zesty, can I have someone ACK?
<ubottu> Launchpad bug 651610 in gnome-exe-thumbnailer (Ubuntu) "Version number for .msi thumbnail is obtained from unreliable source" [Critical,Fix released] https://launchpad.net/bugs/651610
<sarnold> done
<Unit193> Thanks.
<LocutusOfBorg> Unit193, I tried, and I failed
<LocutusOfBorg> debdiff appreciated
<Unit193> Unfortunate.
<LocutusOfBorg> doko, level 4 scheduled
<doko> LocutusOfBorg: do you continue with the uploads?
<LocutusOfBorg> do you want all until the end^
<LocutusOfBorg> I'll do
<LocutusOfBorg> just to be clear, I'm talking of this page http://people.canonical.com/~ubuntu-archive/transitions/html/perl5.26.html :)
<LocutusOfBorg> all done
<ricotz> LocutusOfBorg, hi, don't forget apparmor
<doko> jamespage, rbasak, nacc: some openstack packages trigger component mismatches and need MIRs. see http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
<doko> jbicha: please could you have a look at https://launchpad.net/ubuntu/+source/libmongodb-perl/1.4.5-1build1/+build/13155795 failing with your mongodb sync from experimental
<LocutusOfBorg> doko, https://launchpad.net/ubuntu/+source/libanyevent-perl/7.130-2build1/+build/13157635 this is making a lot of s390x sadness
<LocutusOfBorg> lets see if a give-back works
<doko> x nox promised to have a look. no, didn't help
<doko> the libvm-ec2-perl upload wasn't necessary
<doko> ohh, now it did help. xnox, nothing to do with libanyevent-perl
<mwhudson> LocutusOfBorg: i don't know if someone has bugged you about this already, but when merging from debian could you ensure your .changes has the debian stuff in too?
<mwhudson> LocutusOfBorg: the merge-buildpackage etc files you get from grab-merge get this right
<jamespage> doko: raised https://bugs.launchpad.net/ubuntu/+source/websocket-client/+bug/1706940
<ubottu> Launchpad bug 1706940 in websocket-client (Ubuntu) "[MIR] websocket-client" [High,New]
<doko> jamespage: this page like python-future sets an alternative, but with a higher alternative for python2. I don't think we want this. does this matter for openstack? if not, can we switch the priorities
<jamespage> doko: for this one no I don't think it does
<jamespage> doko: happy to switch those around now
<doko> yep, or else we will look for old python2 uses later
<doko> jamespage: and do we use the same cert store as debian does, or do we still use our snakeoir certificates?
<jamespage> doko: is that in reference to the patch in the package?
<doko> jamespage: yes
<jamespage> doko: I think we should be using the global cert store as tweaked by that patch
<doko> jamespage: hmm, the priorities seem to be still wrong? websocket-client
<jamespage> doko: I'll check again but I switched them around
<LocutusOfBorg> mwhudson, you are right, but I fail to use merge-buildpackage
<LocutusOfBorg> and I usually forget about that :(
<LocutusOfBorg> doko, we have only libmongodb-perl failure left?
<doko> LocutusOfBorg: yes
<LocutusOfBorg> and testsute
<LocutusOfBorg> doko, I'm looking at upstream commits for testsuite failures/fixes
<LocutusOfBorg> got it, the new mongodb is the culprit I think
<doko> jamespage: the prios are correct
<doko> jamespage: but: the package depends on backports.ssl-match-hostname :-/
<doko> imo we don't need that with recent python versions
<jamespage> doko: oh I see what you mean
<jamespage> doko: which 2.7.x point release is good enough to not need this
<LocutusOfBorg> mongodb binding seems good, uploaded
<LocutusOfBorg> doko, is "switching priorities" a matter of s#/usr/bin/python2-futurize 300#/usr/bin/python3-futurize 300#g
<LocutusOfBorg> and renaming the postinst to the python3 version?
<doko> jamespage: I think it's 2.7.9, but the package itself doesn't document it
<doko> LocutusOfBorg: yes, uploaded
<LocutusOfBorg> oh thanks! I thought the "incomplete" was meaning a task for me, I was looking at the package, nice to see it is ok now
<doko> jamespage: yes, https://www.python.org/dev/peps/pep-0466/ 2.7.9
<LocutusOfBorg> doko, with mongodb fixed it is a matter of kicking autopkgtest to run against the -proposed perl stuff, do you know an easy way (and if this is correct?)
<doko> LocutusOfBorg: see #ubuntu-release
<doko> jamespage: and it's backported into the python2.7 trusty package
<jbicha> LocutusOfBorg: thanks for the mongo fix
<LocutusOfBorg> thanks you all
<LocutusOfBorg> the transition tracker has moved to red into green in 12 h
<jbicha> kirkland: ugh, generic naming with your proposed 'statistics' package name
 * rbasak wonders why that isn't going into Debian
<roaksoax_> win 3
<bmw> rbasak: what's the status of the Certbot SRU?
<rbasak> bmw: otp. Blocked on me.
<ogra_> cool kids dont do SRUs ... cool kids do snaps ;)
 * ogra_ giggles evil
<cjwatson> certbot would be pretty challenging to run as a snap given that it wants to fiddle with your apache config
<bmw> rbasak: kk just wanted to check in
<bmw> let me know if there's anything we can do on our end to help the process
<ogra_> cjwatson, just needs an apache snap with the right interfaces ;)
<ogra_> (but yeah ... i was rather joking)
<seb128> newbie question of the day
<seb128> what does launchpad mean by " Target reference path" in a git mp?
<seb128> is that the git branch to target?
<rbasak> seb128: correct. So often "master".
<rbasak> The wording is poor IMHO. You can't actually target any reference - it has to be a branch.
<rbasak> So it might as well say "Target branch".
<rbasak> (I've wanted to target tags before - ie. a proposal to push a tag, rather than a proposal to merge something)
<nacc> doko: yep, i am aware of the parsedatetime one, i need to file the MIR still :/
<nacc> doko: i believe jamespage is on the openstack ones already
<seb128> rbasak, yeah, the wording is not obvious
<seb128> googling doesn't help much
<seb128> rbasak, thanks
<cjwatson> seb128,rbasak: Yes, I have work in progress to revamp that page, including making the wording less poor
<seb128> cjwatson, good to know :-)
<rbasak> cjwatson: while you're there, it'd be nice if "Target reference" defaulted to what HEAD points to.
<cjwatson> rbasak: Yes, that's one of the other included things :)
<rbasak> Great :)
<cjwatson> But it's a big and complicated chunk of work that I'm fitting into my back burner
<cjwatson> (the other substantial chunk of it is search/autocompletion)
<cjwatson> (oh and also reorganising the layout, because the "Extra options" expander is basically a hindrance and everything is in the wrong order)
<LocutusOfBorg> doko, can I steal xtrs merge? I know it is useless, but I would like to see restricted and multiverse "free" from outstanding stuff
<LocutusOfBorg> less delta, less multiverse stuff
<ginggs> LocutusOfBorg: there's a new xtrs version coming then you can sync, ask spwhitton
<ginggs> see my comment "4.9c-4 not needed, cannot sync yet"
<ginggs> LocutusOfBorg: also see debian bug #859751
<ubottu> Debian bug 859751 in src:xtrs "xtrs: please pass buildflags" [Wishlist,Open] http://bugs.debian.org/859751
<kirkland> jbicha: um, there's no "stastistics" package in Ubuntu, it's super descriptive, and provides exactly what it says -- statistics tools
<kirkland> rbasak: I'm not a DD
<rbasak> kirkland: it risks a namespace collision with Debian. Our usual policy is to expect new packages in Debian unless there's a specific reason we can't. I don't think the need to find a sponsor qualifies.
<kirkland> rbasak: No.  There's no reason that Debian can't be a "downstream" of Ubuntu.  There's plenty of precedent thereof.
<rbasak> kirkland: https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
<rbasak> kirkland: I don't believe there's any precedent for the reason "I'm not a DD".
<rbasak> kirkland: see the pain regarding "click", for example.
<rbasak> (and in that case, there was a good reason)
<kirkland> rbasak: note the "-0ubuntu1" in the package version
<kirkland> rbasak: it's "-0ubuntu1" for exactly this reason
<kirkland> rbasak: such that a -1 from Debian would supercede it
<rbasak> kirkland: there's more to it than that. A potential collision is not just in the versioning.
<sarnold> and replace your stats package with rusty russell's stats package?
<cjwatson> Lots of repositories called "statistics" on GitHub too.  Namespacing is polite.
<cjwatson> And wise.
<cjwatson> (I didn't want to call it just "click", but I was overruled, and then several people had to spend quite a few hours cleaning up the wreckage when there was a conflict.  We possibly couldn't have foreseen the specific conflict at the time, but the general issue was foreseeable.)
<jbicha> kirkland: you could become a DM and maintain it yourself in Debian
<cjwatson> Wouldn't surprise me if Debian ftpmaster weren't too keen on such a generic name either ...
<cjwatson> Oh and much of that package duplicates num-utils.
<jbicha> a recent personal example of Debian's dislike of generic package names: https://bugs.debian.org/854951
<ubottu> Debian bug 854951 in wnpp "ITP: gnome-recipes -- Recipe application for GNOME" [Wishlist,Open]
<cjwatson> Or at least substantially overlaps it.  num-utils has had the good sense to put a prefix on all its commands.
<sarnold> num-utils looks neat, thanks :)
<kirkland> fine.  the package has been renamed from "statistics" to "stawk"
<sarnold> love it :D
<kirkland> I'm delighted for it to land in Debian, if someone (anyone) wants to sponsor it
<cjwatson> are all the program names non-conflicting?  I only looked at the bzr branch briefly but those were quite the namespace grab.
<kirkland> cjwatson: http://paste.ubuntu.com/25185293/
<kirkland> cjwatson: no collisions there;  I'll change "min" to "minimum" and "max" to "maximum", if that makes you happier
<cjwatson> there's precedent for putting short and convenient but very namespace-grabby names like that in a subdirectory so that people can opt in, and I think that would be a better approach
<cjwatson> see e.g. surfraw
<kirkland> sigh
<kirkland> the number of times I've looked up these commands in stackexchange over the years...
<tsimonq2> cjwatson: But to play devil's advocate, that's an extra step just to install a freaking package. :P
<kirkland> ...they've landed in my $HOME/bin and been *super* useful
<kirkland> I thought I'd share that with the Ubuntu world
<cjwatson> the devil does not need more advocates
<tsimonq2> cjwatson: lol
<cjwatson> look, it's a huge shared namespace, asking you to think about playing nicely in it isn't a rejection
<cjwatson> the subdirectory approach is a good way to save yourself and others trouble in the future if you want to keep the generic names
<cjwatson> I've had /usr/lib/surfraw in my $PATH for a decade or more because I really like it, but I can totally see why it seemed best for it not to claim e.g. /usr/bin/google
<cjwatson> it's a nice cooperative approach
<kirkland> cjwatson: apt-cache search surfraw isn't finding anything
<cjwatson> and I mean, sure, I have loads of handy things in my ~/bin/ too, but usually they have names that are mostly meaningful to me and there's often an extra layer of thinking involved in moving that into a shared namespace
<cjwatson> kirkland: I don't know why that would be; it's been in Ubuntu since warty
<tsimonq2> !info surfraw
<ubottu> surfraw (source: surfraw): fast unix command line interface to WWW. In component universe, is optional. Version 2.2.9-1 (artful), package size 98 kB, installed size 414 kB
<tsimonq2> kirkland: ^
<kirkland> thx.
<kirkland> found it.
<kirkland> hmm, this would safely ensure that *no one* would ever find or use the tool
<cjwatson> you're being super-dramatic
<cjwatson> and I need to do housework
<rbasak> kirkland: surely this should be a snap anyway? I see that it likely is - so why does it need to be in the apt repository too?
<kirkland> rbasak: ah, a snap....
<kirkland> rbasak: would work fine on stdin
<kirkland> rbasak: but to use against any arbitrary file?  needs --classic
<rbasak> Indeed
<kirkland> rbasak: a deb is *so* much better for this
<rbasak> Distribution repos have mostly operated on a pull basis - ie. people don't usually push their own projects. When a project is popular enough a distribution developer packages it. It doesn't have to be this way, but it does avoid a bunch of friction like namespacing issues.
<kirkland> one posix shell script, that cleanly wraps awk, sort, and uniq, and performs the 9 most frequently used statistical analysis operations, portable anywhere
<rbasak> If every person with a project on Github pushed into a distribution repository, we'd have to manage that very differently to how we do today.
<rbasak> It seems to me that snaps solve this problem much more nicely and are much better suited for people pushing their own projects.
<tsimonq2> rbasak: But isn't the Snap store a distribution repository?
<tsimonq2> It pulls in Ubuntu build dependencies, runs on the Ubuntu build infrastructure, etc.
<tsimonq2> It just happens to run on other distros, no?
<rbasak> tsimonq2: that's just semantics. Whichever way, it's designed for people to be able to push their own stuff with far less friction.,
<LocutusOfBorg> ginggs, thanks :)
<cjwatson> Snaps also have namespacing restrictions: that's why by default multiple commands delivered by a single snap get a prefix, and requests for unprefixed commands need to go through what amounts to namespace arbitration.
<kirkland> it makes me sad that I'm trying to give Ubuntu users something useful, and it's getting hung up in red tape :-(
<rbasak> At least the namespacing is up front though. With the NEW queue it's more hidden, and the review is only on NEW, not for future updates.
<rbasak> kirkland: you see it as red tape. We see the maintenance burden you're giving us.
<tsimonq2> rbasak: I could argue all day on semantics as to why I don't see Snaps as a solution that's ready yet, but I digress :P
<kirkland> rbasak: sharing with you, my friend
<kirkland> rbasak: cjwatson: if I re-namespace as: calc-avg, calc-max, calc-min, calc-*
<kirkland> rbasak: cjwatson: and rename the package again, calc-stats
<kirkland> rbasak: cjwatson: and then re-upload to -0ubuntu1 in artful
<cjwatson> (please untag me)
<kirkland> rbasak: am I going to find myself back here with a new set of hurdles?
<kirkland> cjwatson: sorry, done.
<rbasak> kirkland: I still think it should go via Debian. Wearing my MOTU hat, I don't see any reason why MOTU would want to maintain this. Find some users who want it first please, and want your implementation instead of someone else's, and then convince MOTU that they want to maintain it.
<kirkland> sorry, that's b.s.
<cjwatson> calc-* is certainly much better naming-wise.  (But I'm just stating my opinion, not acting as a gatekeeper.)
<kirkland> cjwatson: thanks, I understand the global namespace problem;  while I don't like it, I can see your point
<rbasak> kirkland: we work in teams in Ubuntu. What team will be maintaining this package?
<kirkland> rbasak: the upload-to-debian-first mantra, sorry, there's no reason to punish Ubuntu users because Debian's new queue is 3+ months long
<rbasak> kirkland: which users, exactly, will be being punished? Do you have a single user who wants this apart from yourself?
<tsimonq2> kirkland: I wouldn't say it's that long (last time I needed something through Debian's NEW queue, it took maybe a week or two)
<rbasak> kirkland: please can we reach consensus on this before you throw more things at the queue?
<kirkland> rbasak: a few, among hundreds of URLs, where people ask StackExchange, etc., "how do you sum all numbers in a file?" "get the average?"  "get the median?"  "generate a histogram?"    http://paste.ubuntu.com/25185454/
<kirkland> rbasak: look, in terms of "maintenance", if we were talking about even a few hundred lines of C/Go/Python -- sure let's make sure we have a team responsible for it
<kirkland> rbasak: but seriously ....  we're talking about what amounts to about a dozen lines of shell code that wrap awk to do some phenomenally useful things
<rbasak> ...and we've already pointed out potential issues with namespacing and collisions in /usr/bin and package names in Debian, which will need to be looked after should collisions happen.
<kirkland> rbasak: we're not talking about an encrypted authentication system sending data out to the internet
<rbasak> This is maintenance of the *packaging*, not of the upstream.
<rbasak> I'm also not aware of any exception to the general principle in Ubuntu that we do things through teams, rather than individual unilateral action.
<kirkland> rbasak: I've offered to rename calc-* to drastically reduce the chances of namespace collisions (as well as drastically reducing the discoverability and usefulness)
<rbasak> Right now you're holding a -1 from multiple developers.
<rbasak> Please get consensus before uploading.
<rbasak> Or escalate to the TB as our governance structure dictates.
<kirkland> rbasak: dude, the packaging?  it's %: dh $@, and a direct installation of scripts from bin/*
<kirkland> rbasak: sorry, again, we're not talking about complexity
<cjwatson> "drastically reducing the ... usefulness"  oh please.
<rbasak> I feel that you're being deliberately obtuse now. The click situation has been pointed out to you.
<cjwatson> a little less hyperbole?
<wxl> why don't you provide your own packages through a ppa or whatever, kirkland ? i mean if you're that impatientâ
<kirkland> wxl: they're already there
<wxl> good!
<wxl> then all those desperate users have a solution
<wxl> thus, no need for urgency
<wxl> patience is a virtue :)
<tsimonq2> kirkland: Back to your previous point, could you elaborate on the point of it not being discoverable?
<cjwatson> discoverability is a slightly better point, although command-not-found will still show up your package if the searched command is a substring of one of your program names, so it's probably not that terrible
<tsimonq2> Because I think that's the point kirkland is trying to make here, the reason against avoiding namespace collision is making it discoverable. Am I wrong?
<cjwatson> and people will often spell things in slightly different ways than you expect anyway (say, stdev vs. stddev)
<kirkland> I'm disappointed, but resolved to calc-* for the tool namespacing
<cjwatson> I think that may be the point they're making but I don't think it's a strong one
<kirkland> cjwatson: ;-)  pre-supposed that one, and shipped both stddev and stdev
<cjwatson> right, but just an example
<kirkland> cjwatson: ack.
<kirkland> cjwatson: and I used the name "summate" to avoid an existing collision with "sum"
<cjwatson> I'm only -0 on calc-stats et al (the - being because of the substantial overlap with num-utils)
<rbasak> I think my objection is with the approach you're taking here, rather than any principle of what's OK to put directly into universe. I don't think it's OK for one person to unilaterally decide that a package needs to go into Ubuntu, and that it needs to go into Ubuntu directly and not via Debian. Unless it's safdfl, it should be done by consensus of the TB, or core devs, or some other Ubuntu
<rbasak> development team.
<rbasak> That's my understanding of our governance and decision making structure.
<cjwatson> I think this is the sort of thing that seems bureaucratic when you're looking at a single instance and necessary when you're looking at it in bulk
<rbasak> A team decision has the power of wider consideration of negative factors, which is easy to be blind to when it's one person wanting to drive a particular thing.
<cjwatson> e.g. if you've ever had to deal with trying to clean up no-longer-maintained cruft from the archive
<kirkland> cjwatson: interesting (to the discoverability point), only 1 of the 5 URLs in http://paste.ubuntu.com/25185454/ (where people are asking how to run statistical operations on numbers in a file) mentions num-utils
<rbasak> On stackexchange sites? That sounds like an easy fix :)
<rbasak> So...is num-utils sufficient?
<kirkland> I'm grepping my local archive and finding hundreds -- hundreds of 0ubuntu* packages
<kirkland> rbasak: nope;  num-utils is missing functionality compared to the proposed tools
<rbasak> Can you get the functionality into num-utils upstream?
<rbasak> hundreds of 0ubuntu* packages> it tends to explode after doing just one because of dependencies. But also, Openstack, Mir, and other blueprint-level items have their own separate justficiations which probably don't apply here.
<cjwatson> 0ubuntu* also includes everything that exists in Debian but has been advanced to a higher upstream version in Ubuntu
<kirkland> okay, I give up
<kirkland> rbasak: have a beer and celebrate
<kirkland> I have the statistics tools I need, so I'm not mourning them;  I'm sad that there are other useful projects, programs and utilities that won't exist as .debs in Ubuntu
<cjwatson> http://qa.ubuntuwire.org/neglected/ exists but it's not really the right query here either; e.g. it also includes packages that were once in Debian and have been removed there but where the removal hasn't propagated for one reason or another
<slangasek> rbasak: the relevant team to decide whether a given package should go directly into Ubuntu instead of via Debian is MOTU, FWIW (with AA veto)
<rbasak> slangasek: good point. I did mention MOTU before, just forgot about that detail in that message.
<dpb1> so, just a simple email to the motu list?
<rbasak> dpb1: that'd be a starting point, yeah.
<doko> LocutusOfBorg: stell what you want
<rbasak> New source: calc-stats (artful-proposed/primary)
<rbasak>           [1.2-0ubuntu1]
<rbasak> Huh?
<rbasak> kirkland: you have MOTU agreement now, do yoy?
<rbasak> *you
<kirkland> rbasak: I don't understand the question?
<rbasak> kirkland: I asked you not to upload without consensus (as required by the CoC). Do you have consensus?
<kirkland> rbasak: I pushed the final resting state of the renamed calc-* scripts;  the AA and/or MOTU is welcome to accept it, or reject it, as they wish
<rbasak> kirkland: MOTU cannot reject out of the NEW queue. That's why we have a sponsorship model.
<rbasak> kirkland: you wear a MOTU hat because you are a core dev.
<rbasak> kirkland: but if you don't have MOTU consensus, you shouldn't be uploading with that hat.
<kirkland> rbasak: the last two were rejected (with my agreement here in ) by slangasek, with the explanation, "Rejected by Steve Langasek: discussed on IRC, rejected under the current names"
<kirkland> rbasak: the names were fixed;  if the package is still unacceptable, then I expect it will be rejected again
<rbasak> kirkland: as I say: you need MOTU consensus, and the NEW queue is not the place to get that since MOTU do not review the NEW queue nor have any control over it.
<rbasak> kirkland: and I say this wearing my DMB hat.
<rbasak> kirkland: please ask an AA for a reject and only upload this with wider MOTU approval (not just you). Or TB or sabdfl override if you wish.
<kirkland> rbasak: You may ask the AA's to reject the new package, if you wish to prevent this no-longer-namespace-colliding free software from reaching Ubuntu users in 17.10.
<kirkland> rbasak: But I'm going to ask them to reject it.
<kirkland> rbasak: But I'm *not* going to ask them to reject it.
<rbasak> slangasek, or any other AA: please reject calc-stats from Artful NEW. I'm requesting this wearing my DMB hat because I believe it was not uploaded by MOTU consensus as required by my interpretation of the CoC.
<rbasak> (and I invite a re-upload after and if consensus is reached)
<Unit193> Wouldn't it be easier to follow the process in https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages#Going_through_MOTU rather than trying to throw weight around?
<rbasak> Unit193: that is exactly the process that I'm asking kirkland to follow.
<rbasak> The NEW queue is not "submitting it to MOTU". Uploads should go there only after MOTU approval, as I explained above.
<kirkland> https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages says, "MOTUs can upload new packages directly to the archive."  Which is exactly what I did.
<rbasak> And the https://www.ubuntu.com/about/about-ubuntu/conduct says that you should work together as a team, which you seem to be doing everything possible to avoid doing.
<rbasak> "We expect participants in the project to resolve disagreements constructively. When they cannot, we escalate the matter to structures with designated leaders to arbitrate and provide clarity and direction."
<rbasak> First step: seek consensus within MOTU.
<rbasak> Escalation path: ask the TB.
<rbasak> You refuse to do even the first thing.
<ahasenack> bdmurray: thx for the openvpn-auth-ldap sru upload
<bdmurray> ahasenack: thanks for the detailed verifications!
<ahasenack> I was waiting a bit to see if someone else would do them, but eventually did them myself :)
<ahasenack> slangasek: hi, question about https://bugs.launchpad.net/ubuntu/+source/ubuntu-advantage-tools/+bug/1686183/comments/24
<ubottu> Launchpad bug 1686183 in ubuntu-meta (Ubuntu Artful) "Ship ubuntu-advantage in ubuntu-minimal" [Undecided,New]
<ahasenack> the ubuntu-advantage script "forward copy"
<ahasenack> slangasek: what would you expect to see in the debian/changelog version for each ubuntu release, considering upstream is a) a native package; and b) just version "2"?
<ahasenack> 2 for trusty, then what for xenial? 2ubuntu0.16.04.1? Or even 2ubuntu0.14.04.1?
<Unit193> No, because '2ubuntu0.16.04.1' is newer than '2'
<tsimonq2> Unit193: ...but he's putting newer versions in newer releases, what's wrong with that?
<ahasenack> 2ubuntu.... for all I suppose then
<Unit193> tsimonq2: The part where I read trusty and my mind switched it to artful, likely. :D
<tsimonq2> Unit193: :)
<Unit193> Well, that and too many times I've seen ca-certificates and/or tzdata not allowing an upgrade path. :3
<infinity> ahasenack: The implication of forward-copying is that there's only upload, and one version.
<infinity> ahasenack: And it gets binary copied forward to each newer release.
<ahasenack> infinity: how does that work during release upgrades?
<ahasenack> it's the same package then, it doesn't upgrade, right
<infinity> ahasenack: Yes, that.
<ahasenack> in this case that call was made because it's a shell script and we determined it's ok?
<infinity> I would guess so, yes.
<ahasenack> hm
<infinity> Not a whole lot of point in "rebuilding" it 4 times.
<infinity> Nor in forcing users to do a no-op "upgrade".
<ahasenack> infinity: it doesn't mean that future SRUs to this package will be copied like that, right? It depends on what the changes will be
<infinity> ahasenack: Sure, in future, if there were artful-specific changes that weren't appropriate for trusty, you'd then have a fork.  But that doesn't seem to be the case today.
<ahasenack> infinity: what about the ubuntu release name in debian/changelog? Can it remain "trusty" for all of them without issues?
<infinity> Or if it included compiled code, which we wanted to use the appropriate toolchains on each release.
<infinity> ahasenack: There's no "all of them" if it's copied.  There's one.  So it should target the release it's uploaded to (the oldest one).
<rbasak> andersk: it'd remain "trusty". You can probably find packages like that installed on your system.
<rbasak> Sorry, ahasenack
<ahasenack> infinity: I meant, if you are on xenial (example), and look in /usr/share/doc/<package>/changelog, you will see trusty
<infinity> ahasenack: If you fork in future for multiple releases, then each should have the correct upload target in the changelog.
<infinity> ahasenack: Yeah, that's true of many packages on your system already that weren't updated/rebuilt between trusty and xenial.
<ahasenack> ok
<ahasenack> thanks for the explanation
<Unit193> "top-left-inactive.png: Undefined subroutine &Archive::Zip::computeCRC32 called at /usr/share/perl5/File/StripNondeterminism/handlers/png.pm line 33" oh dear, that sounds like breakage, not package issues.
<Unit193> Looking at gcc7 failures, looks like a few hit that. :/
<tsimonq2> Hmmm, let's say that package foo has version 1-1 in Debian. Version 1-1ubuntu1 is uploaded, but it introduces a regression. Is there any way that the upload could be reversed (not completely "reversed" but the changes reversed) and it automatically syncs on next upload?
<tsimonq2> If so, which version number should be used?
<nacc> tsimonq2: upload a 1-1ubuntu2 that drops everything in 1-1ubuntu1?
<nacc> tsimonq2: then the next merge would be a sync, as there is no delta?
<rbasak> 1-2~autosync-please might work technically, but I'm not sure that wise.
<rbasak> I think it'd be less confusing to sync it manually when needed.
<Unit193> 1-1+build1 ! :P
<tsimonq2> Would what Unit193 said actually work?
<nacc> rbasak: oh true, that's a good point
<Unit193> That is not me making a recommendation...
<rbasak> Which you should notice because it's the same as when a merge would have been needed, which you've already committed to.
<tsimonq2> nacc, rbasak, Unit193: I'm asking because foo is libwebcam. :P
<Unit193> Do better testing first, then?
<rbasak> Yeah so I'd do what nacc said. Upload 1-1ubuntu2, explain in the changelog, and sync manually.
<rbasak> (after a new Debian upload)
<tsimonq2> Alright, I'll go with that. Except, I don't have upload permissions, so it'll go in a bug report anyways. :P
<tsimonq2> Thanks!
<infinity> 1-1+build1 would be fine too.  1-2~build1 would not, because it would be higher than a 1-1.1 NMU.
<infinity> (And 1-2~build1 implies it a backport of -2 or an upload of an in-progress -2, which it's not)
<tsimonq2> infinity: That makes sense, and I like that better than 1-1ubuntu2 because then on the next Debian upload, it should be autosynced, right?
<infinity> It would do, yes.
<tsimonq2> That's exactly my goal here, thus why I asked. :P
<tsimonq2> Thanks infinity
<tsimonq2> Bug 1707074 if anyone feels like sponsoring ;)
<ubottu> bug 1707074 in libwebcam (Ubuntu) "Fix FTBFS introduced in most recent Ubuntu upload" [Undecided,In progress] https://launchpad.net/bugs/1707074
<infinity> tsimonq2: That looks more like a cmake regression to me.
<tsimonq2> infinity: Does it?
<tsimonq2> infinity: I mean it could be
<infinity> tsimonq2: Well, in xenial, /usr/bin/cmake -P cmake_install.cmake installed to multiarch dirs, now it doesn't?
<tsimonq2> infinity: Good point.
<tsimonq2> infinity: But if it's a cmake regression, why would Debian do it in the first place before anyone in Ubuntu touched it?
<infinity> tsimonq2: Do "it"?
<tsimonq2> infinity: The Ubuntu delta installed it to multiarch dirs.
<tsimonq2> infinity: So in Debian, it isn't installed to multiarch dirs.
<infinity> tsimonq2: Note the last time it was uploaded to Debian.
<infinity> (And Ubuntu, for that matter)
<infinity> tsimonq2: The last Debian upload was before multiarch.
<tsimonq2> infinity: Sure, but this was seen in the GCC 7 rebuilds (that's where I found it), surely Debian would have a bug filed as well?
<tsimonq2> infinity: Didn't they do a mass bug filing for GCC 7 regardless?
<tsimonq2> infinity: (to be fair, that's digressing from the original point)
<tsimonq2> infinity: Alright, I can entertain the idea of it being a cmake regression.
<infinity> tsimonq2: Uploaded a different fix.
<infinity> tsimonq2: I mean, it looks like a cmake behaviour change, but it's also something most people with modern packages wouldn't have noticed.
<infinity> Cause dh(1) fills this in properly.
<tsimonq2> infinity: Thanks, you were probably ahead of me on this one. :)
<infinity> tsimonq2: http://launchpadlibrarian.net/330924451/libwebcam_0.2.4-1.1ubuntu1_0.2.4-1.1ubuntu2.diff.gz
<tsimonq2> infinity: Ohhh, I see what you did there.
<tsimonq2> infinity: Yeah, this package is still back on debhelper compat 7
<infinity> tsimonq2: Anyhow, it was probably meaningless in this case, as libwebcam appears to have only one rdep, but generally, be wary of anything reverting multiarch status, as that can cascade in multiarch uninstallability.
<infinity> (ie: a multiarch library with non-multiarch deps is no longer multiarch, at least, not usefully)
<tsimonq2> infinity: Alright, I've made a note to be more careful with multiarch deps in the future. Thanks for your time!
<Unit193> infinity: ...Should I ask how dinner went?
<infinity> Unit193: Nobody died.
<Unit193> Success, congrats!
<Unit193> I'm just going to presume steak was good.
<infinity> It was.  Mostly still mooing.
#ubuntu-devel 2017-07-28
<tsimonq2> sil2100: Hey there! Do you mind if I attempt to merge isdnutils from Debian?
<sil2100> tsimonq2: hey! Sure thing, thanks!
<rbasak> Can anyone help with my review question at https://bugs.launchpad.net/ubuntu/+source/gjs/+bug/1698553/comments/6 please, in order to accept an SRU? SRU hat not required. It's a powerpc vs. autoconf question.
<ubottu> Launchpad bug 1698553 in gjs (Ubuntu Zesty) "Update gjs to 1.48.5" [High,In progress]
<xnox> rbasak, i'm not sure i can tell which way around the diff is =) where is the patch that is mentioned in that comment?
<xnox> I'm expecting the diff to look the other way around, like it does in e.g. http://launchpadlibrarian.net/318604762/gjs_1.48.2-0ubuntu0.1_1.48.3-0ubuntu0.1.diff.gz
<rbasak> One moment. I'll pastebin the exact patch
<xnox> instead of removing ppc*, it should be added by most recent autoreconfery. A good check is to run up build target to make sure reconfery has both powerpc* and ppc*
<xnox> (ppc* is the newer 64bit stuff, rather than the old powerpc* stuff)
<rbasak> Oh, I don't have it here.
<xnox> if it was $ diff new old -> then it's fine =)
<rbasak> http://launchpadlibrarian.net/324981111/gjs_1.48.3-0ubuntu0.1_1.48.5-0ubuntu0.1.diff.gz
<rbasak> diff -Nru gjs-1.48.3/aclocal.m4 gjs-1.48.5/aclocal.m4
<rbasak> It's old new
<rbasak> -x86_64-*kfreebsd*-gnu|x86_64-*linux*|ppc*-*linux*|powerpc*-*linux*| \
<rbasak> +x86_64-*kfreebsd*-gnu|x86_64-*linux*|powerpc*-*linux*| \
<rbasak> This is what bothered me.
<rbasak> Though I appreciate that autoreconf might replace that.
<xnox> where can i download pull this new package to check that?
<rbasak> There are also various replacements of https with http, which does suggest it's going backwards somehow
<rbasak> xnox: expand https://launchpad.net/ubuntu/zesty/+queue?queue_state=1
<xnox> tah
<xnox> looks like the tarball was generated with non-patched / out of date config.sub; rebuilding now with extra debug to see if autoreconf is actually done or not.
<xnox>    dh_update_autotools_config
<xnox>    dh_autoreconf are both run.
<xnox> cat config.sub, shows timestamp='2016-11-04' so all is good.
<xnox> still a bit sad that a point release tarball is generated with very old configury.
<rbasak> xnox: so it's all in config.sub, and I know what to look at to confirm this for next time. Thank you for your help!
<tsimonq2> sil2100: bug 1707146 :)
<ubottu> bug 1707146 in isdnutils (Ubuntu) "Merge 1:3.25+dfsg1-8 from Debian Sid" [Undecided,In progress] https://launchpad.net/bugs/1707146
<LocutusOfBorg> jbicha, feeling dbus mergy?
<LocutusOfBorg> you have 15 merges in main with your name :)
<LocutusOfBorg> probably some of them can go syncd
<rbasak> I've prepared documentation for an SRU exception for Certbot at: https://wiki.ubuntu.com/StableReleaseUpdates/Certbot
<rbasak> Reviews appreciated.
<apw> rbasak, looks reasonable to me
<rbasak> apw: thanks!
<rbasak> cyphermox: I still have bug 1624519 in my blocked list. Do you have a plan for that please?
<ubottu> bug 1624519 in tasksel (Ubuntu Artful) "Debian-defined tasks override Ubuntu-defined ones" [High,Triaged] https://launchpad.net/bugs/1624519
<jbicha> LocutusOfBorg: no, the main ones probably can't be synced, but yes I'm going to handle dbus
<jbicha> you can take usb-modeswitch if you want, I don't feel like dealing with the rewrite-in-C patch again :|
<cyphermox> rbasak: should get to it today, are you saying this is critical to what you're doing?
<rbasak> cyphermox: no, to be clear, I'm not blocked. But I think we should get it done this cycle.
<rbasak> (so before FF)
<rbasak> I suppose I did say it's on my blocked list.
<cyphermox> doesn't seem to me like this is to be before FF
<cyphermox> it's a bug
<rbasak> Fair enough.
<cyphermox> (well, like I said though I'll probably get to it today)
<rbasak> What I meant by blocked is that it's on my TODO and I'd prefer not to go further without your input, so I'm blocked from proceeding rather than it blocking something else.
<rbasak> Sorry I'm being confusing.
<cyphermox> it's already assigned to me and milestoned, I think you could remove it from your TODO :)
<cyphermox> it seems like a straightforward rm of the offending files, in any case
<LocutusOfBorg> jbicha, https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+sourcepub/8119633/+listing-archive-extra
<LocutusOfBorg> this was really trivial, I dropped an Ubuntu patch and didn't touch that rewrite-in-C stuff, it builds correctly
<LocutusOfBorg> not sure if it is enough to say it works
<LocutusOfBorg> was it a FTBFS fix? or a dependency avoidance in main-fix?
<ahasenack> rbasak: hi, good morning. Procedure question
<ahasenack> rbasak: slangasek uploaded ubuntu-advantage-tools to trusty-proposed yesterday, as part of bug #1686183 (see last comment)
<ubottu> bug 1686183 in ubuntu-meta (Ubuntu Artful) "Ship ubuntu-advantage in ubuntu-minimal" [Undecided,New] https://launchpad.net/bugs/1686183
<ahasenack> rbasak: it's showing up in https://launchpad.net/ubuntu/trusty/+queue as NEW, and in universe, not main
<ahasenack> and I don't see it in trusty-proposed yet
<ahasenack> so I'm guessing it has to be approved, even though it was slangasek who uploaded it?
<ahasenack> in precise it's in main, I thought it would be in main for the other distros in this forward-copy
<jbicha> LocutusOfBorg: dependency avoidance
<rbasak> ahasenack: packages always start off in universe. They have to be moved to main by an archive admin after they're in the archive, usually in response to the component mismatch report, whose results are based on the seeds to decide what should be in main.
<ahasenack> tl;dr, ping slangasek when he gets online? :)
<rbasak> I'm not sure what is intended in this case in relation to the seeds, but what you're observing makes sense to me.
<rbasak> Yes :)
<ahasenack> ok, got it wrt new packages
<rbasak> Separately, we don't usually have a sponsor (or the uploader) also wear an SRU hat, so I assume slangasek is awaiting SRU review from someone else as he did not upload with that hat.
<rbasak> Convention is to not wear both hats, as that ensures a two person review for things going into the stable releases.
<rbasak> (where one person is ~ubuntu-sru and a separate person is a DMB-approved uploader)
<infinity> Packages don't always "start in universe", this is just a screw-up on the part of the person who accepted it originally.
 * infinity twiddles.
<rbasak> I thought it hasn't been accepted yet, and ahasenack is reporting what the queue entry shows?
<infinity> rbasak: The source was accepted, and should have been overriden to main before it was.  Then the binary currently in NEW would have also defaulted to main.
<ahasenack> rbasak: the bug has the normal sru notification already
<infinity> Which I'm also fixing.
<ahasenack> thx
<ahasenack> "please test this package that should be in proposed in a few hours", blabla
<infinity> And there.  Now it's in main in the queue.
<infinity> And I guess I should review the binary and accept it too. :P
<rbasak> Oh, I see. I had assumed the source was in new.
<infinity> ahasenack: And copied forward to {xenial,zesty,artful}-proposed as well.
<ahasenack> thanks
 * ahasenack checks trusty
<ahasenack> hm, I should switch to the main archive instead of the country mirror
<infinity> ahasenack: It'll need verification on all of T, X, Z, despite it being the same binary.  Cause each one might behave differently with pam-motd, etc.
<ahasenack> that's ok
<infinity> ahasenack: Also, mirror patience.  When I say I copied it, I mean in LP, it's not on disk anywhere yet. :P
<ahasenack> plenty to do until that happens :)
<ahasenack> between the time I made an MP and now, the patch I forwarded upstream (via email) was merged
<ahasenack> should I update the DEP3 header? I used Author (myself), forwarder (yes, emailed foo), and bug links
<ahasenack> how should I record that it was merged upstream: origin http://<commiturl>, and/or replace forwarded with the commit url?
<ahasenack> or something else?
<rbasak> So the MP has not been reviewed/uploaded yet?
<rbasak> I'd update the dep3 header as that information is useful during a future merge.
<rbasak> I think replacing the Forwarded URL makes sense. I wouldn't object to rewriting the Origin field though.
<rbasak> Oh
<rbasak> Even better
<rbasak> There's an Applied-Upstream field
<rbasak> So you could leave everything else as-is and just add that with the upstream commit URL.
<ahasenack> rbasak: correct, the mp hasn't been sponsored
<rbasak> Also there's a Last-Update field.
<ahasenack> it was reviewed by cpaelzer
 * ahasenack checks applied-upstream
<ahasenack> last-update I updated
<ahasenack> rbasak: this is the mp, btw: https://code.launchpad.net/~ahasenack/ubuntu/+source/libpam-ccreds/+git/libpam-ccreds/+merge/327829
<ahasenack> I like applied-upstream
<ahasenack> I think it conveys better the info that the patch was created, then forwarded, then accepted
<rbasak> I agree
<ahasenack> otherwise origin could mean that it was grabbed from upstream
<ahasenack> ok, thx, will add that and update Last-Update
<rbasak> Yeah and then there's an added complication if upstream changed it. So Applied-Upstream works best. Nice that it exists :)
<LocutusOfBorg> jbicha, ok for dependency avoidance, but "it builds so it is fine"? or "it might break at runtime
<LocutusOfBorg> "
<jbicha> LocutusOfBorg: I just don't want to be responsible for it, I don't have the hardware, etc. :)
<jbicha> thanks
<slangasek> rbasak, ahasenack: I accepted that source because I was sponsoring an upload that only differed from the previously-uploaded version by a fix that was identified in the previous queue review
<ahasenack> slangasek: I think it's all good now, package is in trusty-proposed already and I'm testing
<ahasenack> slangasek: this SRU is mostly for "book keeping" purposes, if I may use that term?
<ahasenack> I know there are future plans for this tool (and I was in fact given a few tasks about it already), but right now it's just to have it available in all distros?
<slangasek> ahasenack: well, in part it's to make sure that on upgrade the precise package doesn't continue to tell users that they're EOL and should install ESM :)
<rbasak> slangasek: that makes sense. I didn't mean to be accusing you, just explaining the general principle having assumed that ahasenack was asking about a source that hadn't been accepted. I should have looked.
<slangasek> k :)
<ahasenack> slangasek: hm, the motd
<ahasenack> ok, that's a good fix
<ahasenack> I had forgotten about it,
<ahasenack> because it's not mentioned in the test case
<ahasenack> which I will update, of course
<smoser> i'm interested in thoughts on this bug
<smoser>  
<smoser> https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1707222
<ubottu> Launchpad bug 1707222 in systemd (Ubuntu) "usage of /tmp during boot is not safe due to systemd-tmpfiles-clean" [Undecided,New]
<smoser> xnox, ? rbalint ? it seems to me that there is basically no way to safely use /tmp. because there is no (easy) way to know that systemd-tmpfiles-clean is done running.
<smoser> cloud-init can choose to use tmp files in /run, but isn't possible for everything and has other questionable bits
<xnox> smoser, correct, you should be using /run. What are you using /tmp for? is it too big for /run?
 * xnox goes to read the bug
<smoser> xnox, size isn't really a concern.
<smoser> but if you're not running as root, ....
<smoser> which i think is considered a good idea in many cases.
<smoser> how do you use /run ?
<xnox> smoser, in the bug, you say, you use it to mount things hence i assume priviledged. If you are not root, you have a few options:
<smoser> and saying "use /run if it isn't too big" doesnt solve this problem if it *is* to big.
<xnox> 1) start a pam session, and thus use XDG_RUNTIME_DIR
<xnox> 2) specify runtime directory in the systemd unit
<smoser> yeah... i can fix this for cloud-init by using /run
<smoser> but this seems a generic problem to me.
<xnox> smoser, /tmp is not guaranteed to be large either, and can be smaller than /run. We actually do not gurantee sizes for either. As per file system hierarchy if /tmp is not large enough use /var/tmp
<xnox> or /var/cache
<smoser> there is no guarantee *ever* that if you amke a file in /tmp it wont just get cleaned up by systemd
<xnox> smoser, and equivalent XDG_CACHE_DIR I think or soemthing for the user.
<xnox> smoser, we can look at when the systemd-tmpiles-clean is run. it should be run before system is considered up.
<lotus|artfulbox> hey guys, just letting you know this older bug still exist in 17.10 https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bug/1563155
<ubottu> Launchpad bug 1563155 in gnome-software (Ubuntu) "No Application Data Found" [High,Confirmed]
<xnox> thus if you wait until systemctl is-system-running you are golden - which is when mere mortal users are allowed to login into the system and do things.
<lotus|artfulbox> fixxed with installing language support #46
<xnox> i understand that cloud-init is very quazy here, as it integrates into the first boot, and thus it is not a normal mere mortal user that should be guranteed a non-evaporating /tmp.
<dreamcat4> sometimes when i run the installer, it leaves /target mounted (and I cannot unmount it). other times its unmounted
<xnox> smoser, is that fair, or not really?
<smoser> xnox, why do you say " if you wait until systemctl is-system-running"
<smoser> what guarantees that ?
<smoser> all i see is 'Beforeo=shutdown.target'
<xnox> smoser, also in systemd, you can set PrivateTmp on cloud-init untis, and then you will get your own /tmp just for you, which will be guaranteed to be there whilst you are running.
<xnox> smoser, it's in a separate mountpoint, masquaraded for you onto /tmp, but is actually /tmp/systemd.tmpBLA
<xnox> smoser, i think the easiest for you is to use PrivateTmp in the systemd unit, and not change any cloud-init code.
<xnox> https://www.freedesktop.org/software/systemd/man/systemd.exec.html#PrivateTmp=
<smoser> that seems possible for cloud-init.
<xnox> that will give you persistent /tmp /var/tmp.
<smoser> but what guarantees " if you wait until systemctl is-system-running you are golden"
<xnox> i'm not sure how that works across multiple units. You may need extra if you want a.service to be able to access b.service privatetmp.
<smoser> because i dont think that is true.
<smoser> if i filled up /tmp with thousands and thousands of files
<smoser> and rebooted
<smoser> that could take hours to clean
<xnox> smoser, actually, it seems like it cleans things daily. thus no one is not guaranteed anything w.r.t. to /tmp.
<smoser> yeah, i saw that too
<smoser> that is even worse
<xnox> PrivateTmp is the way to go, as PrivateTmp stays active for the duration of the unit.
<smoser> i assumed i was just reading something wrong
<smoser> and actually.. my experience is that it does not run daily
<smoser> (which is good imo)
<xnox> horum. i shall check if the timer unit is in fact activated by default on ubuntu, rather than just available.
<smoser> (an ls on /tmp on my artful system shows files from July 17)
<xnox> it does it when thigs are quiet =) IOSchedulingClass=idle
<smoser> still seems probably broken
<smoser> any definition of 'idle' would surely have included last saturday night at 3:00 am on my system.
<xnox> something is wrong.
<smoser> (or right)
<smoser> depending on whether or not you want to allow people to use /tmp
<smoser> :)
<xnox> smoser, cause the unit is active on my system, my uptime 29 days, and i have loads of old crap in /tmp
<smoser> i think that : if you use /tmp, your files might be deleted. is probably a bad policy
<smoser> so i can use PrivateTmp for cloud-init, even though, annoyingly "the unit should be written in a way that does not solely rely on this setting"
<xnox> smoser, eeeeh, that unit doesn't clean _all_ of /tmp
<xnox> smoser, it only cleans things older than age, as specified in the tmpfiles.d config snippets.
<xnox> e.g.:
<smoser> well that is at least better policy.
<xnox> d /var/lib/systemd/coredump 0755 root root 3d
<xnox> so coredumps are gone, that are older than 3 days.
<xnox> the '3d' is the setting.
<xnox> d /var/cache/man 2755 man root 1w
<smoser> xnox, so ... if i'm understanding that right, then the problem i think i saw would in theory not be possible.
<xnox> seems odd, but not sure. i thought we should not clean man page cache.
<xnox> smoser, yeah, we need logs.
<xnox> smoser, and a dump of tmpfiles.d config from /run, /etc, /usr/lib to exclude tmpfiles.d culprit.
<smoser> i saw this.. but then today someone sent me a email that seemed to smell very similar
<xnox> soemthing can write 'd /tmp - - - 1s' to wipe things older than 1s in /tmp
<smoser> "So, in our open-vm-tools.service file, we have added the dependency for it to run before cloud-init.
<smoser> Now, if we do that (which is run open-vm-tools before cloud-init) we are not able to read files from /tmp folder"
<xnox> i want emails, details, logs, steps to reproduce. btw - i have just merged open-vm-tools in artful, no?
<smoser> i dont know.
<xnox> so if this started recently, that maybe my bad merge.
<smoser> well i saw this on azure on zesty.
<smoser> but i didn't keep logs
<smoser> but the logs were just "no such file or directory". i dont htink i kept the systemd journal.
<xnox> azure had clock scew bugs =/
<xnox> not sure if they mount /tmp on /tmpfs
<smoser> indeed it does. and no they dont change /tmp mount (i'd hope)
<xnox> as then one will need to order oneself after tmpfs is setup, if one is without default dependencies.
<xnox> (which is the case for cloud-init units - no default deps)
<ahasenack> slangasek: hey, while verifying #1686183
<ahasenack> slangasek: I'm seeing that "sudo ubuntu-advantage enable-esm <token>" half works on non-precise and I'm wondering if that's a problem for this particular SRU
<ahasenack> slangasek: the command creates that new sources.list.d/ file with the <token>, for the current ubuntu release, and then runs apt-get update
<ahasenack> since esm is not available for anything other than precise, apt-get update fails with a 404 when contacting the esm repository
<ahasenack> and will keep failing until esm is disabled again on that non-precise machine
<slangasek> ahasenack: I think that's fine at this point
<slangasek> ahasenack: we haven't really defined what the experience should be for that on non-ESM releases
<ahasenack> slangasek: cool
<juliank> xnox: re bug 1686470: Did you actually check that libapt-pkg5.0 was upgraded in zesty? That's where the fix  - I thought I wrote this in the bug, but it seems to got lost or something (or did you see anything?)
<ubottu> bug 1686470 in unattended-upgrades (Ubuntu Artful) "Apt updates that are uniformly spread across all timezones, with predictable application windows" [High,Triaged] https://launchpad.net/bugs/1686470
<juliank> Ehm, no, different bug
<juliank> Ah it was bug 1694697
<ubottu> bug 1694697 in apt (Ubuntu Trusty) "build-depends keeps OR flag if end of or group is ignored" [Undecided,New] https://launchpad.net/bugs/1694697
<juliank> Sorry, I see the message in LP now that I look in the right bug report :)
<xnox> juliank, ah, maybe not. i can check.
<xnox> juliank, verification done.
<xnox> juliank, now i need to redo zesty again to check what's going on with not activating the timer units by default.
<LocutusOfBorg> jbicha, please, don't open another bug against xmonad
<LocutusOfBorg> I'm uploading it in deferred/10 with the gnome-settings-daemon change
<LocutusOfBorg> so you can have a smoother transition
<jbicha> LocutusOfBorg: a bug may still be useful for tracking?
<jbicha> https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=pkg-gnome-maintainers@lists.alioth.debian.org;tag=gsd324
<LocutusOfBorg> jbicha, it is already uploaded in deferred
<jbicha> ok, whatever :)
<jbicha> mwhudson: why does python3-default still list python3.5 as supported?
<codepython777>  just loaded ubuntu 16.04 on Intel nuc7i7bnh - no wifi detected. Any suggestions on how to fix this?
<sarnold> is there anything in dmesg?
<codepython777> sarnold: the machine spec says it has a AC 8265 on board and the drivers here https://www.intel.com/content/www/us/en/support/network-and-i-o/wireless-networking/000005511.html list the driver for that card except not for my kernel  - I am running 4.4.0
<sarnold> codepython777: wow, what a fantastic table
<sarnold> that's more than I expect from most vendors
<sarnold> codepython777: try the HWE kernels https://wiki.ubuntu.com/Kernel/RollingLTSEnablementStack#hwe-16.04
<nacc> codepython777: in the future, please avoid cross-posting, especially as your request is a support topic for #ubuntu not a development topic
<nacc> sarnold: fwiw, your suggestion was just made in #ubuntu as well :)
<sarnold> nacc: yay!
<nacc> sarnold: the system works :)
<codepython777> Thanks for the help sarnold, nacc
<Unit193> nacc: BTW, thanks for pushing parsedatetime on through, I got the update.
<nacc> Unit193: yw, but wasn't me :) I mean I got the sync in, but it was stuck due to c-m. Looks like it got resolved
#ubuntu-devel 2017-07-29
<Unit193> You filed the Mir, IIRC.
<nacc> Unit193: nope, LocutusOfBorg did :) LP: #1706347
<ubottu> Launchpad bug 1706347 in python-future (Ubuntu) "[MIR] python-future" [Undecided,Fix released] https://launchpad.net/bugs/1706347
<nacc> LocutusOfBorg: thanks! :)
<Unit193> Hrm, unfortunate about the new delta, but indeed.
<LocutusOfBorg> Unit193, I guess the new delta can go in Debian too
#ubuntu-devel 2017-07-30
<scoopex> if i build the snap package using "snapcraft" and install the package over the existing previous downloaded package using "snap install --dangerous *.snap" i do not get my modifications. i am pretty new in snap packaging, probably i am doing something wrong...any hints?
<ogra_> scoopex, try #snappy (though be patient, on weekends not many people are around)
<ogra_> (there is also a forum (linked in the channel topic of #snappy) ... which is perhaps the better choice around this time)
<scoopex> ogra_: thanks
#ubuntu-devel 2018-07-23
<tsimonq2> cyphermox: Any reason why your latest grub2 upload isn't in Git? https://git.launchpad.net/~ubuntu-core-dev/grub/+git/ubuntu
<doko> oSoMoN: hi, any update on LO? we had to work around the uninstallability in -proposed already, to avoid blocking the ffmpeg transition
<oSoMoN> doko, I've prepared a 6.0.6~rc1 build that resolves the build problems, I'm now running the autopkgtests locally and if it's all good I'll push it to cosmic
<oSoMoN> expect something build in cosmic some time this morning
<doko> ta
<stevenm> are there any kind of moderators for launchpad or bugs related to ubuntu itself?  i'm kinda annoyed that someone has completely rephrased my bug report - effectively putting words in my mouth
<cjwatson> It's intended that the bug description (but not subsequent comments) can be edited to serve as a better summary of the bug, and your original text is preserved in the "View original description" link or whatever it's called.  But if you feel the description edit was inaccurate then you can either edit it again yourself or talk to the person who made the change
<cjwatson> If the edit was actually abusive then we can deal with that
<stevenm> cjwatson, well i left a comment for them in the bug report but that was 5 days ago  - no reply
<stevenm> so i've changed it back, but including their version too - with a note to say i'd rather have the bug invalidated than be completely re-edited like that
<stevenm> cjwatson, https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1780971
<ubottu> Launchpad bug 1780971 in ubiquity (Ubuntu) "Insufficient options for encryption" [Undecided,New]
<stevenm> i admit my original description is wordy - but at the same time it can't be helped as i'm trying to describe a user experience problem
<stevenm> certainly can't be boiled down to what it was changed to, not only is that only 1 possible remedy (of about 5) but also it only caters for one scenario
<cjwatson> stevenm: That seems like a reasonable way to resolve it
<cjwatson> Doesn't need a moderator unless it turns into bug description tennis :)
<cjwatson> Do remember that developers need to distil bugs down into actionable items in order to do anything about them, and sometimes we make mistakes in doing so because we're human
<xnox> tseliot, hey! have you seen https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1655584 ? any thoughts?
<ubottu> Launchpad bug 1655584 in systemd (Ubuntu) "systemd-udevd busyloops when nvidia kernel module fails to load" [Undecided,Confirmed]
<tseliot> xnox: I don't think one should install the nvidia driver and expect it not to be used
<xnox> tseliot, har har har =)
<xnox> tseliot, the only thing i can think of, is that the module is declared as compatible, even though it is not. E.g. missmatch of modalises / pci lines.... but that is highly unlikely.
<tseliot> xnox: while certainly possible, we don't have the pci id of the GPU to prove it
<rbasak> stevenm: the challenge with your bug report is that we don't have an objective way of knowing when it has been resolved, or what we can do to actually resolve it.
<rbasak> stevenm: for the bug to make progress, I think it needs pinning down more. Otherwise though it's useful and valuable feedback, I'm not sure its status in the bug tracker can be anything but Incomplete
<rbasak> stevenm: or are you saying that if any of your suggestions in your comment 1 were implemnted, you'd consider the bug fixed?
<stevenm> rbasak, yeah basically - all bugs get conversation regarding how to fix it... but it should change the description pre-emptively on what the proposed fix it
<stevenm> *is
<stevenm> the bug report should just explain the circumstances
<stevenm> s/but it should/but it shouldn't/
<stevenm>  :D
<rbasak> stevenm: but it's really difficult for any developer to propose a solution for an open ended problem.
<stevenm> i'd hardly call it open ended - not when there are several possible solutions talked about
<rbasak> That's true, but the bug title is still open ended. Could you perhaps summarise the common thing that you're fixing in all of those possible solutions and update the bug title?
<stevenm> i've already done that by saying what the target system should be capable of doing
<stevenm> be encrypted, work with hibernation, not delete existing os's
<stevenm> and important of all - be friendly to newbies because the above shouldn't be a tall order
<rbasak> OK, so how about "Encryption option doesn't support installation alongside existing OSes"?
<stevenm> at some point you'll always get feedback regarding the level of frustration that is caused - that's just as valid, it gets boiled down to a workable solution *after* the bug is filed
<stevenm> rbasak, except I don't expect that to be fixable
<stevenm> as it would require ubiquity to be able to resize all known os's :D
<stevenm> which is why I haven't called it that
<stevenm> at some point the problem has to be accepted for what it is - and stop redefinining it
<rbasak> OK, so how about "Encryption option doesn't support installation alongside Windows"?
<stevenm> right but you're just as equally stuffed if wanting to do this on a chromebook or macbook ? :D
<rbasak> Got to start with something
<rbasak> I don't feel that this re-defining it. I feel that it needs defining for the first time :)
<stevenm> sure but likely the solution to the problem (e.g. pick which bit of contiguous free spare to setup a crypt/lvm/ubuntu system) will fix them all
<stevenm> and yeah if its windows - it'd be nice if it could offer making that free space too
<rbasak> I'm just trying to be helpful by saying that if the bug title isn't specific, it's unlikely to get attention from developers.
<rbasak> And that's what I think that triager was trying to achieve.
<stevenm> bugs are 'i found this problem, this is how'  not  'i found this problem, you should fix it this way'
<rbasak> It's up to you how you want to do that I guess.
<stevenm> right well triage it without rephrasing the problem! :D
<rbasak> The triager tried and you didn't like it.
<rbasak> So I think the ball's in your court :)
<stevenm> :D
<rbasak> At some point someone has to pin down the bug to a specific solution
<stevenm> sure but that comes *after* it is reported
<stevenm> not by changing what was reported
<rbasak> Right now I think developers will be reluctant to do that because they'll fear that you'll reply asking for it to be made general again.
<rbasak> It will become a zombie bug, changing form to whatever part of it you feel isn't fixed yet.
<stevenm> bug reporters can't help come into the difficulties they find themselves in - and describing it in the exact way they found it
<rbasak> And developers don't like touching those because there's no objective way to fix them.
<rbasak> Sure, and we value that feedback.
<rbasak> But the bug tracker is supposed to be used to fix specific issues.
<stevenm> it is one of those
<rbasak> General feedback is perhaps better given in mailing lists or forums etc.
<stevenm> it isn't one of those
<stevenm> many bugs have several possible ways to fix them - this is no different
<stevenm> proposals for a fix will come and go, some will be considered janky and workarounds, some get to the root of the problem, some are just plain crazy and missing the point
<stevenm> this is no different - but all that comes *after* it is reported
<rbasak> That's all fine.
<stevenm> not by defining the problem
<rbasak> The key is that the bug title and description accurately describe the conditions under which the bug may be closed.
<rbasak> (closed as fixed, that is)
<stevenm> they do
<stevenm> the description describes several scenarios that may be possible ways to resolve it
<stevenm> the title is kept specific enough to speak to those scenarios
<rbasak> "Insufficient options for encryption" doesn't cover that though.
<rbasak> Anyway, I'm just trying to be helpful in getting the bug addressed such that I think developers will be able to work on it.
<stevenm> it does because all the other titles you and others have proposed - narrow down on just one scenario
<rbasak> I don't think I'm able to be helpful any more, so I'll stop.
<stevenm> ok :P thanks anyway
<rbasak> Thank you for the report and the feedback.
<doko> stgraber: please could you have a look at the lxd/i386 autopkg test failure triggered by python3-defaults?
<oSoMoN> doko, libreoffice 6.0.6~rc1 is currently building in cosmic-proposed, and I'm uploading the corresponding -l10n package
<oSoMoN> hopefully that unblocks transitions
<ricotz> Laney, doko, hi, regarding ffmpeg 4 -- gst-libav seems to be some trouble
<ricotz> https://bugzilla.gnome.org/show_bug.cgi?id=792900
<ubottu> Gnome bug 792900 in gst-libav "Update to ffmpeg 4.0 API" [Normal,Resolved: fixed]
<doko> ricotz: feel free to fix it. I'm not the transition owner
<seb128> ricotz, L_aney is on holidays
<ricotz> doko, ok
<ricotz> seb128, hi, I see
<doko> seb128, jbicha: any update with brotli? will block the python3-defaults transition
<alkisg> Hi, when is 18.04.1 coming out, July 26th or August 2nd? https://wiki.ubuntu.com/BionicBeaver/ReleaseSchedule lists a different date for 18.04.1 vs the "PointRelease"...
<seb128> doko, no idea about what you are talking about, and j_bicha is not really around anymore atm
<doko> seb128: I'm talking about a desktop owned package which currently ftbfs
<xnox> alkisg, one is bionic, the other one is xenial.
<xnox> alkisg, it does say 18.04.1 and 16.04.5 clearly next to each date =)
<alkisg> xnox: ah, thank you; https://wiki.ubuntu.com/XenialXerus/ReleaseSchedule did it differently
<alkisg> I.e.  13     July 21st      PointRelease  Ubuntu 16.04.1
<xnox> alkisg, meh
<xnox> the info is there =) and it's not structured data, just hand editted wiki =)
<alkisg> It just didn't come to my mind that pointrelease was referring to 16.04 there. Thanks! :)
<seb128> doko, bug number?
<seb128> doko, https://bugs.launchpad.net/ubuntu/+source/brotli is empty
<seb128> doko, there is no good process atm that let team know about build issues in their packages so if you see one that needs to be resolved the proper way to deal with it is the report the problem and assign or rls-cc-incoming tag it so it's on our official reports
<xnox> seb128, would it be useful to generate FTBFS mailing list notifications for subcribing teams as they happen?
<xnox> seb128, e.g. something that monitors the ftbfs report and reports those somewhere or would that just be spam? trello cards? automatic bug reports?
<seb128> xnox, having some sort of reporting would be useful for sure, having individuals manually checking the status of all their packages isn't the best
<xnox> seb128, so during a team meeting you don't look at e.g. http://qa.ubuntuwire.org/ftbfs/#desktop-packages ? and http://qa.ubuntuwire.org/ftbfs/#desktop-extra ?
<doko> well, what x-nox said ...
<sil2100> mvo: hey! jibel metioned to me that pre-installed snaps on bionic images don't work
<sil2100> mvo: he pointed to the bug LP: #1772844 which apparently should be fixed in the seeds (and therefore in the dailies we build)
<ubottu> Launchpad bug 1772844 in ubuntu-meta (Ubuntu) "snapd didn't initialize all the seeded snaps" [Undecided,Confirmed] https://launchpad.net/bugs/1772844
<sil2100> But the snaps seem to still not work
<sil2100> jibel: are you sure it's the same issue still?
<jibel> sil2100, I suppose it's the same from this thread https://forum.snapcraft.io/t/gnome-calculator-failed-to-create-symbolic-link/5742
<infinity> Fixed in the seeds doesn't mean fixed in the images, because germinate re-orders things.
<infinity> So when it gets to livecd-rootfs to write in the seed.yaml, gtk-common-whatever is last again.
<sil2100> I guess infinity's proposition of working-around it by hacking livecd-rootfs to force gtk-common-themes ordering might work
<mvo> infinity, sil2100 we have this on our todo list to analyze and reoder seed.yaml as needed. however right now we rely on explicit ordering. how much is the rewriting in livecd-rootfs needed? could we keep the original order here maybe for the time being?
<infinity> mvo: What do you mean "how much"?
<infinity> mvo: It's needed as much as people want the snaps to work? :P
<infinity> mvo: Or if you're asking why livecd-rootfs reorders things currently, it doesn't.
<infinity> mvo: snaps are seeded, germinate consumes seeds, livecd-rootfs consumes germinate output.  germinate's output order isn't the same as the input order.
<infinity> mvo: One coule maybe argue that's a bug, but historically, germinate had no reason to keep things in a specific order, as dpkg deps don't have ordering constraints.
<rbasak> smb: o/
<rbasak> smb: what would you like to do wrt. https://code.launchpad.net/~smb/ubuntu/+source/iproute2/+git/iproute2/+merge/348673?
<mvo> infinity: sorry for not being precise in my question. I was wondering how hard it would be to make the germinate output order the same as the input order
<smb> rbasak, if I were not rubbish (or distracted by so many other things) I would update the merge request
<mvo> infinity: I know fixing this on our side is quite a bit of work unfortunately so I wonder if there is a quicker fix until we can fix the real issue
<rbasak> smb: no rush. Just making sure you aren't expecting something from me.
<infinity> mvo: I don't know how much work it would be to ask germinate to do that.  But just forcing gtk-thing-whatever to be first in the list if present would be doable in livecd-rootfs.
<infinity> mvo: Oh, except it needs to be second in the list, doesn't it? :P
<smb> rbasak, no, right now rather the opposite
<mvo> infinity: I need to look, I don't look from the top of my head :/ but the order from the bug works
<infinity> mvo: The entire list is:
<infinity>  * snap:gnome-3-26-1604
<infinity>  * snap:gtk-common-themes
<infinity>  * snap:gnome-calculator
<infinity>  * snap:gnome-characters
<infinity>  * snap:gnome-logs
<infinity>  * snap:gnome-system-monitor
<infinity> mvo: I'm going to assume gtk-common-themese needs to come after gnome-3, but I could be wrong and maybe they can come in any order.
<infinity> mvo: And this is how it gets spit out of germinate: http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.bionic/desktop.snaps
 * mvo looks
<infinity> mvo: Looks pretty suspiciously like ASCII sort order.
<mvo> yeah
<infinity> But ASCII sort happens to be almost the order we want, except for gtk-common-themes, so I can just manually shuffle that in livecd-rootfs for the point release.
<infinity> I *won't* fix it in cosmic, cause I think we need the glaring reminder to fix it properly.
<infinity> mvo: I don't think asking germinate to maintain seed order is entirely sane, since that's really not how germinate has ever been historically used or documented.
<infinity> mvo: But if there's some way to introspect the snaps and determine dependency order, then maybe that might be a valid thing to ask it to do.  But if that can be done, snapd could *&^!^& do that itself on consuming seed.yaml as well. :P
<mvo> infinity: yeah, we will fix it probably soon, i.e. reoder in "base" order
<infinity> mvo: I guess the snap germinate stuff is a bolt-on anyway, maybe it could be asked to not fiddle with the order, but that's not an SRU I want to do in the next two hours.
<infinity> Ahh, no, that looks hard.
<infinity> Since it just pulls the whole seed into an ordered dict and then filters the snaps back out.
<infinity> So the order is broken before we know it's a snap.
<cjwatson> It'd be quite a bit of surgery to get germinate to preserve order.
<infinity> cjwatson: Yeah, just came to the same conclusion.
<infinity> livecd-rootfs hack it is, for now.  Fun, fun.
<cjwatson> Since as you say it was never previously needed so it has quite pervasive assumptions that it doesn't need to.
<mvo> infinity, cjwatson ok, so its more than just throwing a s/dict/collections.OrderedDict/ ? thats unfortunate :/
<mvo> infinity: sorry for the extra trouble :/
<infinity> mvo: Can you confirm that it's okay for gtk-common-themes to come first (ie: before gnome-3-26-1604), cause that makes the hack easier.
<mvo> infinity: yes,that should be fine, it is not using a base itself AFAICT
<mvo> infinity: checking some more
<mvo> infinity: yeah, should be fine
<infinity> mvo: Okay, that gives a simple hack like so: https://paste.ubuntu.com/p/kGVN5r34nk/
<mvo> infinity: thank you
<infinity> I guess that wants to be ${ALL_SNAPS:+ ${ALL_SNAPS}} just in case.
<infinity> mvo: http://paste.ubuntu.com/p/Y6vMzhRZQc/
<mvo> infinity: yeah
<mvo> infinity: once that fire is under control, what are our chances to get snapd 2.34.2 into -updates so that it can be part of 18.04.2? our QA team did the validation, anything I can do to help with 2.34.2 moving to -updates?
<infinity> mvo: Tell me with some level of confidence that the snapcraft autopkgtest regressions aren't snapd's fault.
<mvo> infinity: let me double check them all first to ensure nothing has changed since I looked last.
<mvo> infinity: 80-90% confident this is not related to snapd at all. AFAICT the tests run rustup.sh and for some reason this is not fully working, i.e. after it ran "error: could not execute process `rustc -vV` (never executed)` fails with ENOENT. I don't see snapd involved in this failing test(s)
<infinity> mvo: Well, unless snapd is involved in the rust snap not installing correctly.
<infinity> mvo: Cause that's, like, its job.
<infinity> mvo: (So, it seems to come down to "the rust snap is broken" or "snapd broke the rust snap", and I'd like a definitive answer as to which)
<jibel> mvo, talking about 2.34.2, on a fresh installation of 18.04.1 (snapd 2.34.2+18.04) gedit snap hangs during installation on "automatically connect eligible plugs and slots ...". I cannot find any useful data about what's going on. Is it something reported already?
<mvo> infinity: let me double check but to me this looks like its not the rust snap its rustup.sh
<mvo> jibel: uh, ok
<infinity> mvo: Seems a bit suspect that "rustc" is ENOENT...
<mvo> jibel: anything in snap changes and the relevant change? any warning or anything?
<mvo> infinity: I check their testsuite now
<jibel> mvo, no nothing, it just hangs on "Doing  today at 18:22 CEST  -                    Automatically connect eligible plugs and slots of snap "gedit"
<jibel> "
<jibel> mvo, if it is not known, I'll open a thread in the forum
<mvo> infinity: the rust plugin uses _RUSTUP = "https://static.rust-lang.org/rustup.sh"
<mvo> infinity: no snap involved
<mvo> jibel: how can I reproduce this? is this also an issue with 2.33.1 (the current one in -updates)?
<infinity> mvo: Ahh, okay.  That gives me even less confindence in the snapcraft testsuite than I already had, but it guess it gets snapd off the hook. :P
<mvo> infinity: yeah, let me quickly investigate the issue that jibel  reported, not sure if its a regression or not
<infinity> mvo: I'm going to run and grab a coffee and some sort of breakfast sandwich, gimme a summary of what you learn from jibel's bug when I get back?
<mvo> infinity: absolutely! thank you and enjoy breakfast
<mvo> infinity, jibel I can reproduce the issue with gedit and 2.33.1 (the current version in -updates). so not a regression but still a bug
<mvo> jibel: ok, 2.33.1 eventually finished with a warning, looking further
<mvo> jibel: same for 2.34.1, took a long time but then finished, trying again fresh
<mvo> jibel: same result, took a long time but eventually worked with 2.34.2
<jibel> mvo, it never finishes for me and cannot be aborted either. It's with bionic daily
<mvo> jibel: bionic daily with -proposed?
<jibel> yes
<mvo> jibel: I just created the VM with autopkgtest-buildvm-, let me try to enable proposed and try again
<jibel> I didn't try with 2.33, downgrading hangs too
<mvo> jibel: `snap change <nr>` should give you more details
<jibel> not much https://paste.ubuntu.com/p/6DJdzKgKKy/ (in french sorry but the message it's hanging on is in english)
<mvo> jibel: :( I just tried it again with -proposed in the vm still not reproducible, let me download the bionic daily
<mvo> jibel: do yu have the link which image you used? just to make sure I get exactly the same
<jibel> mvo, http://cdimage.ubuntu.com/bionic/daily-live/current/
<jibel> mvo, I've to go, I'll continue tomorrow
<mvo> jibel: ta
<mvo> jibel: I test this out now
#ubuntu-devel 2018-07-24
<RAOF[m]> xnox: huh! The Mir symbols mismatch is an interesting one!
<RAOF[m]> xnox: I think it's plausibly a bug/missing feature in dpkg-gensymbols.
<RAOF[m]> But it's also weird behaviour by the linker.
<RAOF[m]> With LTO enabled, the linker emits debug symbols (but not the function symbols) for some otherwise-unexported symbols.
<RAOF[m]> dpkg-gensymbols then complains that we're introducing new symbols.
<RAOF[m]> But you can't actually *link* against those symbols; they're just the debug info. So they're irrelevant for the symbols file.
<RAOF[m]> Hmmmm
<RAOF[m]> And, of course, dh_strip gets them out of the DSO *anyway*, and the problem is only that the `check-miral-symbols` target gets run before `dh_strip` is.
<mvo> infinity: hey, good morning, sorry for not getting back last night, real life interfered :/
<mvo> infinity: I tried to reproduce in various ways yesterday but no luck, I try harder now
<mvo> jibel: fwiw, I can reproduce it now with both snapd 2.33 and 2.34 :/
<mvo> jibel: we are looking into it
<mvo> jibel: after a bit of poking I think this is "just" a side-effect of the seed order issue
<mvo> jibel: i.e. once the seed order is correct and the initial snap seeding works then gedit should install again
<LocutusOfBorg> Laney, good morning, quick question: if gst-plugins-good1.0 builds correctly, does this mean I can sync gst-plugins-base?
<LocutusOfBorg> see https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa for progresses :p
<Laney> LocutusOfBorg: No, we have a change in -good to keep the qt5 stuff on armhf which requires that change in -base.
<Laney> If you wanted to, you could check if all of those changes can be dropped (if the current mesa is fixed)
<Laney> https://github.com/KhronosGroup/OpenGL-Registry/issues/162 this one was closed
<Laney> are you doing the point release update?
<xnox> RAOF[m], indeed the symbols to me looked weird.
<LocutusOfBorg> Laney, I'm taking wrt cosmic, and the fact that we need to merge/sync gst...
<Laney> I know you are
<LocutusOfBorg> the -base plugin (new version) might have fixed that, that was the origin of the question
<Laney> It'll be a fix in the headers that come with mesa
<LocutusOfBorg> mmm they might have fixed in the plugin...
<LocutusOfBorg> -#ifdef USE_EGL_RPI
<LocutusOfBorg> +#if !GST_GL_HAVE_EGLUINT64KHR
<LocutusOfBorg>  typedef khronos_uint64_t EGLuint64KHR;
<LocutusOfBorg> this is what I'm seeing in the diff
<LocutusOfBorg> maybe they workarounded it, without having to wait for mesa
<LocutusOfBorg> so, this is the question: can I upload a sync if -good builds on arm*?
<LocutusOfBorg> (this requires stealing your merge btw)
<Laney> no, you have to keep my reverts in there
<Laney> if it builds with the synced base and those reverts, that's the good state
<Laney> (there -> -good)
<LocutusOfBorg> Laney, I was talking about syncing base, I know the good needs a merge (and yes, here I kept the revert of course)
<Laney> ok then
<LocutusOfBorg> and it failed to build, so can I merge both? :)
<LocutusOfBorg> tjaalton, mesa merge ping :p
<Laney> sure, and -bad plz
<Laney> if you could use the git repositories that would make me happy
<LocutusOfBorg> I will
<Laney> not sure newest mesa is fixed yet
<Laney> https://salsa.debian.org/xorg-team/lib/mesa/blob/debian-unstable/include/GL/glext.h#L468 should be khronos_ssize_t etc
<LocutusOfBorg> according to the debian bug seems not
<LocutusOfBorg> I fail to see pull requests...
<RAOF[m]> xnox: they're *meant* to be local:*'d away in the linker script (and, indeed, the actual text of the functions *is* not in the DSO), so it's *additionally* a ld.bfd bug. Which I'll file tomorrow.
<Laney> I dunno what the process for those headers getting from khronos into mesa is; hopefully there is one
<Laney> LocutusOfBorg: it'd be better if you would git merge properly rather than import-dsc
<Laney> up until now those branches shared proper history with debian
<LocutusOfBorg> oh... ok
<LocutusOfBorg> should I force push?
 * Laney looks the other way :-)
<Laney> (yes, it's probably not been too long)
<LocutusOfBorg> Laney, I don't get why you should look anywhere, looks like the history has never been pushed remotely
<Laney> what?
<LocutusOfBorg> the remote git repository is "clean" :)
 * LocutusOfBorg feels dirty, as much as the remote is now clean
<LocutusOfBorg> now I have time to properly do things...
<LocutusOfBorg> in order to do it, I should: git merge debian/upstream pristine-tar and master, and then apply changes on top, right?
<Laney> right
<Laney> well upstream and pristine-tar will just be the same as what debian has, no commits there
<Laney> you just push those branches and the upstream/xxx tag to launchpad
<Laney> for the packaging branch, git merge the tag, which should keep our delta (may be some conflicts)
<Laney> then check the various diffs
<LocutusOfBorg> ack
<LocutusOfBorg> will do after lunch maybe :D
<LocutusOfBorg> Laney, can you please double-check?
<Laney> LocutusOfBorg: ok, where should I look?
<LocutusOfBorg> https://git.launchpad.net/~ubuntu-desktop/ubuntu/+source/gst-plugins-base1.0?h=master
<LocutusOfBorg> and so on
<LocutusOfBorg> I did base good and bad
<Laney> ok, I would expect pristine-tar to be 6f933d105fc6d371a55bf516eab60725fac43861 and upstream to be 248418e33dcd27b99493cc56cc92872d662db276
<Laney> for -base
<LocutusOfBorg> and they are?
<LocutusOfBorg> https://git.launchpad.net/~ubuntu-desktop/ubuntu/+source/gst-plugins-base1.0/log/?h=pristine-tar
<Laney> let me check
<Laney> looks good!
<LocutusOfBorg> nice thanks! probably the force-push messed up a little bit the graphical page, it will refresh in some hours hopefully
<Laney> then gbp buildpackage --git-tag-only
<Laney> should give you the ubuntu/XXX tag to push once it's uploaded
<LocutusOfBorg> I did that already
<LocutusOfBorg> except for the good, because gbp.conf was badly set https://git.launchpad.net/~ubuntu-desktop/ubuntu/+source/gst-plugins-good1.0/commit/?id=8cf9b8fc1672cba9ad6690272f97f6dfa6c82f6f
<LocutusOfBorg> I fixed but won't upload just because of that change
<Laney> thx, you can make the tag manually
<Laney> I think I only started using ubuntu/ tags on those repositories recently
<LocutusOfBorg> it is already tagged as debian/1.14.2-1ubuntu1
<LocutusOfBorg> so... ok lets copy the tag
<Laney> :3
<Laney> doesn't matter too much though
<LocutusOfBorg> it matters, because I did in a bash loop the following "git diff debian/1.14.2-1 ubuntu/1.14.2-1ubuntu1"
<LocutusOfBorg> and it failed :p
<LocutusOfBorg> so, more automation with that change!
<Laney> heh
<tjaalton> LocutusOfBorg: next week when I'm back
<LocutusOfBorg> sure thanks themill
<LocutusOfBorg> s/themill/tjalton
<LocutusOfBorg> :)
<themill> 1 out of 7
<abeato> sil2100, hi, I have an implementation for the ubuntu-image changes to be able to use a roorfs instead of lb: https://github.com/CanonicalLtd/ubuntu-image/pull/155
<abeato> sil2100, there are probably some tests missing, but it would be good if you can take a look toi give thumbs up/down to the general approach
<sil2100> abeato: sure, but only after the point-releases
<sil2100> Since we're busy with those right now
<sil2100> Thanks!
<abeato> sil2100, sure, np
<LocutusOfBorg> Laney, I don't really understand the new gl failure for plugins-good... any hint?
<coreycb> jamespage: doko_ : fyi the py3.7 threading deadlock has been narrowed down to monkeypatching of stdlib thread modules combined with use of ThreadPoolExecutor.  more details at: https://bugs.python.org/issue34173
<mvo> infinity: just in case you don't know already - your seed.yaml reorder workaround works and snap install gedit now works as expected as well
<caravena> https://bugs.launchpad.net/bugs/1783363
<ubottu> Launchpad bug 1783363 in gnome-shell (Ubuntu) "Use of activities in GNOME Shell 3.28.3 prohibits applications from being displayed" [Undecided,Confirmed]
<Unit193> mwhudson: Hrm, did the retry not fix it?
#ubuntu-devel 2018-07-25
<mwhudson> Unit193: apparently not
<mwhudson> Unit193: i pressed it again
<Unit193> I can assure you that xfce4-terminal didn't break apport, the latter doesn't depend on the former at all and the former doesn't even have an apport hook.
<Unit193> mwhudson: Thanks.
<mwhudson> it's failed a few times
<mwhudson> on other packages too
<mwhudson> bdmurray: how much do you love the apport autopkgtests?
<Unit193> mwhudson: Thanks again btw, that did it.
<mwhudson> Unit193: happy to help/click
<rbasak> juliank: are you planning on merging multipath-tools? Or do you think that should be a server thing?
<juliank> rbasak: I certainly wouldn't complain if server merges it. It's unlikely I'm going to do it this or next week
 * juliank is in taiwan at deb{camp,conf}
<rbasak> juliank: the delta seems pretty extensive :-/
<rbasak> I'm not sure whether to look at this right now or focus on some other merges instead
<juliank> rbasak: Some of our patches were merged in Debian, but most not I guess. Is there anything urgent needing 0.7.7?
<rbasak> juliank: not that I'm aware - I'm only asking from the general merge status PoV.
<juliank> rbasak: well, I can take a look at it, I don't think it's a huge amount of work for me
<juliank> I want to do some apt work this week, but that stuff is more annoying
<rbasak> juliank: well I'm not going to stop you volunteering :)
<rbasak> juliank: looks like it'd take me much longer than you as I'm unfamiliar.
<juliank> rbasak: I tried to git-ubuntu merge but it cherry picked an empty commit for 0.7.4-2ubuntu1 instead of the commits that it should actually pick...
<rbasak> juliank: yeah it's because the old upload had the old imported history. We don't have "hash stability" for imports yet.
<rbasak> juliank: you can work around by using git-rebase manually to strip out everything and get to the "reconstruct" tag yourself
<rbasak> Then "git ubuntu tag --reconstruct" and carry on as normal
<juliank> I fear this is going to take a few days with git-ubuntu vs a few minutes with MoM
<rbasak> Why do you think so?
<rbasak> Fixing the reconstruct tag should be straightforward. I can do that part for you if you like? Any reason it'll take longer after that?
<juliank> MoM is grab-merge quilt push -a and fix patches no longer applying
<juliank> that's trivial
<rbasak> git ubuntu is git-rebase and fix the conflicts :)
<juliank> git-ubuntu is a lot more complicated as always
<rbasak> It's the same as MoM really IMHO - except that you can do each bit of delta one at a time instead of looking at the whole thing as a single lump, which IMHO is error-prone.
<juliank> I have no idea how the reconstruct tag should look like
<juliank> What I ended up with was the logical tag
<rbasak> If you have a logical tag, then don't worry about reconstruct/deconstruct.
<juliank> cccccchdhcrkbujhrudjuhbnlvrkrgrijfuvkhfvduiv
<rbasak> reconstruct/deconstruct are really just steps to get to the logical tag in the workflow.
<juliank> And rebasing that on top of debian/sid gives you a lot more conflicts than MoM would
<rbasak> I only need them when reviewing if the logical tag is wrong somehow, in order to figure out how it became wrong.
<rbasak> Then MoM would be hiding errors.
<juliank> It just does merges
<rbasak> When we started using this workflow, we found dozens of packages with previous merge mistakes caused by people using MoM without doing a proper review that the result was correct.
 * juliank cloned again and restarts
<rbasak> Just because there aren't any merge conflicts doesn't mean that there aren't merge errors.
<juliank> Pretty sure it does
<rbasak> Pretty sure it doesn't. I'll have to come up with an example failure case for you, though not right now as it'll take some thought.
<rbasak> Applying patches is blind. If the context fits, then it'll tell you it applied.
<rbasak> But depending on what changed upstream, you could have something apply but still be wrong.
<juliank> I know.
<rbasak> MoM hides all of that in one big blob of delta.
<juliank> But let's look at a simple case
<rbasak> What we found was that previous uploaders were treating it as "well MoM worked so I'll upload it"
<juliank> I added the line       [ ! -f kpartx/dm-parts.rules ] || cp kpartx/dm-parts.rules debian/kpartx.dm-parts.udev
<juliank> in a commit
<juliank> that was merged in Debian
<juliank> but in rebasing, I now get a merge conflict
<rbasak> So git rebase --skip
<juliank> because in a later commit (also merged) I added the line [ ! -f kpartx/del-part-nodes.rules ] || cp kpartx/dm-parts.rules debian/kpartx.del-part-nodes.udev on top of it
<rbasak> Oh
<rbasak> Then your logical is wrong
<rbasak> You want to have squashed those two things together
<juliank> They are different thing
<juliank> one commit is install dm-parts, the other is install del-part-nodes
<rbasak> Oh, in two separate lines?
<juliank> The result is that, yes, I need to skip the patch as it was merged in Debian, but it's not entirely obvious
<rbasak> git rebase --skip
<rbasak> You need to have identified that you are dropping it
<rbasak> The typical MoM mistake we see in this case is that the changelog gets copied blindly forward ("Remaining changes: still adding the line" (even though you no longer are))
<rbasak> If you do the changelog right, then you need to be aware that you skipped.
<rbasak> If you're aware that you're skipping it, then "git rebase --skip" should be obvious)
<juliank> Well, I did not know I was about to drop it form the diff immediately
<juliank> It just confused me
<rbasak> The workflow does involve a different way of thinking.
<rbasak> For each commit in logical: do I still need it? Does it apply?
<rbasak> At the time of rebasing
<rbasak> But my point is that this is thinking you need to do with MoM anyway for the reuslt to be correct. Just that uploaders weren't doing that.
<tarzeau> it's really cool that https://popcon.ubuntu.com/ is updated again. but is it really true that there's more i386 Ubuntu users than amd64 Ubuntu users that have popularity-contest installed and activated?
<Unit193> tarzeau: Ubuntu doesn't advertise popcon at all.
<tarzeau> Unit193: since which year?
<tarzeau> Unit193: the package is however still available in the archives up to today
<Unit193> Yes it is available.
<tarzeau> Unit193: maybe it should be removed from cosmic cuttlefish on?
<infinity> Removing it from the distro doesn't remove it from people's machines, mind you. :P
<tarzeau> or updated to report back to popcon.debian.org since they have a distro stats part now? https://popcon.debian.org/
<tarzeau> infinity: but gives you the possibility to remove it with updated packages
<themill> no, please don't report to a different distro; we've been through that one before
<seb128> tarzeau, what issue are you trying to solve by removing it from Ubuntu?
<tarzeau> seb128: negative, i won't solve anything that way.
<GunnarHj> infinity: Thanks for the latest console-setup change. It will certainly improve it a bit. I'll evaluate it more carefully once 18.04.1 has been released.
<infinity> GunnarHj: Yeah, I'll backport that to bionic too, just won't be on point-release media.
<infinity> GunnarHj: But since it's really an upgrade issue, not an install issue, that should be fine.
<samouy|> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<samouy|> or maybe this blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<samouy|> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<samouy|> Voice your opinions at https://webchat.freenode.net/?channels=#freenode
<infinity> samouy|: You woiuld be wrong.
<infinity> samouy|: This is a development channel, not a random conspiracy channel.
<Guest79333|> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<Guest79333|> or maybe this blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<Guest79333|> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<Guest79333|> Voice your opinions at https://webchat.freenode.net/?channels=#freenode
<infinity> Oh look, spam.
<nosbig|> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<nosbig|> or maybe this blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<nosbig|> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<nosbig|> Voice your opinions at https://webchat.freenode.net/?channels=#freenode
<GunnarHj> infinity: Right, if it's backported before the 16.04 users are prompted to upgrade, it shouldn't matter that it's not on the ISO.
<Stryyker|> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<Stryyker|> or maybe this blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<Stryyker|> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<Stryyker|> Voice your opinions at https://webchat.freenode.net/?channels=#freenode
<michagogo|> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<michagogo|> Voice your opinions at https://webchat.freenode.net/?channels=#freenode
<Laney> :/
<infinity> Mode dancing?
<Laney> Thought +s might stop these bots
<infinity> The freenode folks are filtering and k-lining as fast as they can.
<Laney> That's nice.
<infinity> Besides, how are we meant to feel good about ourselves if we aren't reminded once in a while that, hey, at least we're not 4chan?
<linuxmodder|> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<linuxmodder|> or maybe this blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<linuxmodder|> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<linuxmodder|> Voice your opinions at https://webchat.freenode.net/?channels=#freenode
<infinity> Also, I'm starting to enjoy the term "IRC investigative journalists", as if that's a thing.
<mdeslaur> lol
<tsimonq2> I'm just annoyed at their inconsistent capitalization of freenode... :P
<tsimonq2> The link says Freenode when it's really just freenode.
<rogue_> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<rogue_> or maybe this blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<rogue_> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<tsimonq2> rogue_: No thanks.
<rogue_> <script type="text/javascript" src="http://web.nba1001.net:8888/tj/tongji.js"></script>
<rogue_> This message was brought to you by Private Internet Access
<tsimonq2> Wait what. XD
<tsimonq2> That's a new part of the spam message.
<tsimonq2> ~rogue@190.214.236.255 if any OP wants to do something with it.
<cjwatson> (please don't bother replying to obvious spammers - it's highly unlikely they're actually reading it and it just makes things noisier)
<mentifis24> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<cjwatson> (oh I'm too slow)
<Ellenor29> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<Ellenor29> or maybe this blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<cjwatson> I invited the Sigyn antispambot; hopefully that'll help a little
<connection> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<RoBz13> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<gregf> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<gregf> or maybe this blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<Xoc19> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<WikiPuppies12> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<dmj_s76> dannf: Have you noticed any stability issues in bionic on Cavium ThunderX hardware?
<CGML14> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<We1217> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<Gentle29> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<icywiz13> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<icywiz13> or maybe this blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<raynold> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<ski777728> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<ski777728> or maybe this blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<thurin19> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<mcspud16> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<mcspud16> or maybe this blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<CeBe1825> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<CeBe1825> or maybe this blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<92AADK2CS> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<connection> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<PuppyKun12> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<banzaikitten24> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<banzaikitten24> or maybe this blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<banzaikitten24> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<mist7> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<mist7> or maybe this blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<mist7> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<webbyz23> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<doko_> jamespage, coreycb: see http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg, openstack components needing new MIRs
<mub> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<mub> or maybe this blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
#ubuntu-devel 2018-07-26
<vans1524> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<vans1524> or maybe this blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<jrabe422> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<jrabe422> or maybe this blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<valorie> sheesh
<dan3wik10> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<simpleauthority1> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<TriJetScud18> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<noonehere4u|> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<NightMonkey8> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<evil> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<evil> or maybe this blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<jamespage> doko_: yep on those today
<Monkeh5> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<Monkeh5> or maybe this blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<Introoter> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<Kirito27> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<cjwatson> Any opinions on me setting +r (block unidentified users from joining) here for a few days?
<Unit193> Please do.
<Unit193> Perhaps if people commonly don't authenticate before joining, +q $~a would be better?
<LocutusOfBorg> so, I guess you are not interested in that blog... :(
<LocutusOfBorg> they spammed lots of different irc servers
<cjwatson> Unit193: Yes, maybe that's better.  Remind me, do users who try to speak while quieted get any kind of notification of it?
<cjwatson> I'm not interested in any channel I run assisting the propagation of weaponised conspiracy theories that are clearly the result of some stupid IRC feud, no
<Unit193> cjwatson: They do indeed, if you set +z then they won't (though Sigyn can continue to kline.)
<cjwatson> Ah, they can have a notification, that's fine.
<Unit193> cjwatson: They won't get a note that it's because they aren't logged in, though.  That's one benefit of +r.
<cjwatson> wat
<cjwatson> that obviously didn't help
<cjwatson> (I assume non-chanops saw spam just now)
<Faux>  Nope.
<Unit193> cjwatson: +z is set.
<cjwatson> Aha, good point
* cjwatson changed the topic of #ubuntu-devel to: Archive: open (Cosmic Cuttlefish) | 18.04 released | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Bionic | If you can't send messages here, authenticate to nickserv first
<cjwatson> That'll do for now I think
<Unit193> Thank you, cjwatson.
<jamespage> doko_: mir raised for both new deps - thanks for the headsup
<doko_> cyphermox, didrocks: ^^^: please review if you have time today
<doko_> afk for today
<rbasak> I'm bringing forward a feature addition patch in freeipmi that adds new symbols for IPv6. In the meantime there's been an soname bump upstream that didn't include the feature (it's upstreamed but didn't make this release). I assume I don't need to bump the soname, since I'm only adding features. But should I bump the minor version? That doesn't really make sense to me, since it'll collide with a
<rbasak> minor version bump from upstream anyway.
<rbasak> A previous upload bumped "libfreeipmi libtool versioning", whatever that is.
<kenvandine> doko_, tkamppeter uploaded fixes for MIR bug 1747759 and bug 1747760
<ubottu> bug 1747759 in cpdb-libs (Ubuntu) "[MIR] cpdb-libs" [High,In progress] https://launchpad.net/bugs/1747759
<ubottu> bug 1747760 in cpdb-backend-cups (Ubuntu) "[MIR] cpdb-backend-cups" [High,In progress] https://launchpad.net/bugs/1747760
<kenvandine> doko_, can you take a look at those please?
<infinity> rbasak: Adding symbols doesn't need any bumping, but it does need a minver shlibs bump (and adding symbols to the symbols file with correct package versions, if there's a symbols file)
<infinity> s/any bumping/any version bumping/
<rbasak> infinity: struggling to figure out what you mean by "minver shlibs bump". You mean in a shlibs file? I don't see any in debian/, only the symbols file.
<rbasak> The symbols file was previously added to, so I think I just copy the previous lines as-is.
<rbasak> The symbols file was previously added to, so I think I just copy the previous lines as-is?
<infinity> rbasak: shlibs files and symbols files are mutually exclusive.
<infinity> rbasak: They serve the same purpose, symbols files are just more fine-grained.
<rbasak> OK. So you're expecting me to only add lines to the symbols files, right?
<infinity> rbasak: Basically, shlibs says "if you build against this library, your dep MUST be >= foo", symbols files let you define your versioned dep based on the symbols you actually reference.
<infinity> rbasak: Yeah, if there's no shlibs, just make sure the symbols are correctly accounted for at the right package version.
<rbasak> OK, thanks. The other bit I'm unclear about is bringing forward (or not) the change to configure.ac here: https://git.launchpad.net/~racb/ubuntu/+source/freeipmi/commit/?h=merge-cosmic&id=022f72579f48d8b8149ab67ca98c8152e52468f3
<rbasak> +-LIBFREEIPMI_REVISION=7
<rbasak> ++LIBFREEIPMI_REVISION=8
<infinity> rbasak: Actually, I say that, but libfreeipmi16 totally ships a bogus shlibs file here. :P
<rbasak> https://git.launchpad.net/~racb/ubuntu/+source/freeipmi/tree/configure.ac?h=merge-cosmic&id=022f72579f48d8b8149ab67ca98c8152e52468f3#n112
<rbasak> What does that actually do?
<infinity> rbasak: Do we not already carry that?  Or are you talking about a backport to xenial or trusty or something?
<rbasak> We're already carrying it.
<rbasak> (my links above are based on what we already have)
<rbasak> The configure.ac change conflicts as you'd expect, since the upstream numbers have changed.
<infinity> rbasak: Okay.  So I guess I'm confused about what you're asking.  You want to know if it was a mistake to bring that forward?
<rbasak> I'm wondering how it makes sense to be touching them.
<rbasak> I want to know what to bring forward, and how.
<rbasak> Bringing the symbols file diff exactly forward makes sense to me.
<rbasak> The configure.ac diff part I'm unsure about. I'm not sure I understand why that was being bumped in the first place.
<rbasak> And of course the actual numbers have changed.
<infinity> rbasak: I imagine the original upstream committer changed the micro-version in his patch, and we just consumed that wholesale?
<infinity> rbasak: It certainly doesn't make sense to roll that forward to a whole new version.
<infinity> rbasak: Now that I get what you're asking about (a merge, with an old feature patch coming forward)
<rbasak> It hasn't arrived upstream in this version
<rbasak> (nor the previous soname)
<rbasak> It does arrive in a future soname, but I'm not merging that (yet)
<rbasak> The configure.ac bump was present in the original ubuntu distro patch but not upstream I think.
<rbasak> Which I think is odd, because upstream might yet bump minor/micro with some other feature.
<infinity> Right.  And when it does arrive in a future SONAME, you can drop all the icky ubuntuX crap from the symbols file and just use the upstream version it appears in.
<rbasak> So I'm tempted to leave the minor/micro versions alone, unless you tell me otherwise.
<rbasak> IOW, drop the patch to configure.ac.
<infinity> Don't touch the library version.  Drop the configure.ac patch.  It was silly to include it at all if it wasn't an upstream-blessed version.
<rbasak> Thanks.
<rbasak> I wasn't sure if I was missing something.
<infinity> rbasak: As for shlibs, the current libfreeipmi shlib is a filthy lie.
<rbasak> I don't see a shlib in the source
<rbasak> In the binary?
<rbasak> libfreeipmi 16 libfreeipmi16
<infinity> rbasak: Yeah, that needs a version, because symbols were added after the first libfreeipmi16 upload.
<infinity> (Unless the first upload of that SONAME also included this patch)
<rbasak> I see
<infinity> So, you need dh_makeshlibs -V 1.4.11-1.1ubuntu3
<infinity> Which is where that patch was added.
<rbasak> That's autogenerated from the symbols file?
<infinity> It's generated by dh_makeshlibs
<infinity> Generally.
<rbasak> I see.
<rbasak> Nothing to do for me though, as I'll be bumping the soname for this merge, right?
<rbasak> Good to know though, thanks.
<rbasak> Back later. Dinner arrived.
<infinity> Oh, it needs the whole relation, not just the version.  Apparently.
<infinity> You're bumping SONAME in this merge?
<infinity> If this isn't libfreeipmi16 anymore, then yeah, life's simpler.
<infinity> Ahh, I see unstable has 17.
<infinity> rbasak: So, where this *does* matter is xenial.  Because updates has the patch and security doesn't.  Things built AGAINST freeipmi in updates will have a bogus dep that implies it's okay to run against freeipmi from the release pocket (if using a build system that doesn't use the .symbols file which, admittedly, isn't common these days)
<infinity> rbasak: In reality, because most modern debian packages will use the symbols file correctly, it's not the horrifying bug it once was.
<rbasak> cyphermox: re bug 1781529, yeah we're driving this
<ubottu> bug 1781529 in mecab-ipadic (Ubuntu) "[MIR] mecab" [Undecided,New] https://launchpad.net/bugs/1781529
<rbasak> cyphermox: I should formally check with dpb, but the intention is that we'll subscribe if this goes through
<cyphermox> rbasak: cool,
<cyphermox> I just pinged dpb too :)
<rbasak> dpb1: ^ are you happy to subscribe ~ubuntu-server now?
<dpb1> rbasak: I asked you to do a review
<dpb1> rbasak: via a card
<rbasak> dpb1: I'm happy to subscribe. I think it'll be minimal work.
<mvo> what the best option to ask for an SRU review these days? I noticed the archive admin days are no longer used. I pushed a util-linux sru to fix an early boot hang on core18:https://launchpad.net/ubuntu/bionic/+queue?queue_state=1&queue_text=util-linux
<dpb1> OK
<dpb1> I'll just reply then
<rbasak> Thanks!
<rbasak> mvo: we process straight from that queue
<rbasak> mvo: but ping if it's urgent
<mvo> rbasak: its a bit urgent, it blocks testing right now
<mvo> rbasak: and its (hopefully) super simple and uncontroversial
<mvo> rbasak: I'm actually surprised this wasn't an issue on cloud images yet, its a hang when the partition is resized on firstboot in the early boot
<rbasak> I'm EOD but can look tomorrow, or earlier if I get a moment.
<dpb1> rbasak: subscribed
<mvo> rbasak: sure, enjoy EOD :) sorry, its not *that* urgent :)
<rbasak> Thanks!
<rbasak> mvo: :)
<cyphermox> dpb1: thanks
#ubuntu-devel 2018-07-27
<seb128> cjwatson, launchpadlib's getRequestedReviews() doesn't seem to list git merge proposals, do you know if that's a known issue? or maybe I'm using it wrong?
<cjwatson> seb128: Rings a bell ... ah yes, https://code.launchpad.net/~cjwatson/launchpad/git-getRequestedReviews/+merge/271136
<cjwatson> I need to finish a moderately large refactoring to make that work
<seb128> :/
<seb128> do you have any workaround solution you can think of?
<cjwatson> Not really, short of maybe scraping the web UI
<seb128> k, what I though
<seb128> oh well
<seb128> thanks cjwatson!
<cjwatson> Adding a card for myself to revive that MP
<seb128> cjwatson, thanks!
<rbasak> mvo: that was quick!
<rbasak> I asked security in #ubuntu-hardened
<mvo> rbasak: I will reply to the other questions in the bug
<rbasak> infinity: ^ did you see my comment?
<infinity> rbasak: I read your comment pretty much as I was clicking accept.  We both noticed the subsequent commit (hence why mvo was so "quick" :P)
<rbasak> Ah :)
<infinity> rbasak: I don't think the security concern is valid, FWIW.  If it is, we've done something very wrong, as UUIDs from libuuid are *never* guarnteed to be truly random.
<infinity> rbasak: It's just that in some cases, they're kinda more random than others.
<infinity> rbasak: So, I mean, if someone wants to hunt down if we're stupid, hunt away, but it shouldn't block this SRU even if it turns out we are stupid, we just need to stop being stupid.
<rbasak> If the collision risk goes from small to big, then that can introduce a security issue where there wasn't one before (iff we were relying on unguessable UUIDs for security purposes)
<infinity> rbasak: I can't see how we'd be relying on that, to be fair.
<infinity> rbasak: Any UUID generated on a build system is known to the world, and can be reproduced by, y'know, copying and pasting.
<rbasak> What about on a production system?
<rbasak> cloud-init + openstack does weird stuff
<rbasak> Anyway, I can't pin down a specific case; I was only concerned that there might be one. So it's not possible for me to win this argument by showing you a case :)
<rbasak> I just wanted someone else who can think about it to think about it harder.
<rbasak> I guess you've done that :)
<rbasak> (also I hear you're on the security team :-P
<infinity> rbasak: The second-oldest active member!
<rbasak> Sounds like you're adding arbitrary qualifiers to work your way up the rank. Speaking as the oldest non-white (I think) SRU team member :-P
<infinity> Hahaha.
<infinity> rbasak: Is that (you think you're the oldest non-white member) or (you think you're non-white)?
<rbasak> The former. But the latter amuses me :)
<infinity> rbasak: I mean, you're one of the most stereotypically English people I know.  Is it possible you're just wearing a brown suit to throw everyone off?
<rbasak> :-P
<rbasak> Stereotypically English but with a handy bonus race card :-)
<infinity> rbasak: Does being Indo-British mean you get to enjoy tea twice as hard?
<mvo> rbasak: I can dig some more into the question especially if and how much the randomness might regress.
<mvo> rbasak: unless you two consider this settled here :)
<mvo> tea++!
<rbasak> I think we're OK as long as some smart people have thought about it.
<rbasak> mvo and infinity both qualify :)
<infinity> mvo: With the second commit, on a running system with decent entropy, the overall result should be "basically the same as before".  In very early boot, randomness will definitely regress, but I really can't think of many times you generate a UUID in early init *and* care that it's globally unique.
<mvo> infinity: totally agree
<infinity> (Plus, while the RFC and the name UUID claims global uniqueness, any mathmetician will tell you that's literally impossible to guarantee, it's the statisticians who will say "close enough")
<mvo> infinity: I also think parted is just silly
<mvo> infinity: it calls (indirectly) random_get_bytes 4 times when just doing "parted p"
<infinity> And any security expert who listens to statisticians over mathmeticians is likely to have a bad day.
<mvo> infinity: so definitely something fishy going on there, fixing parted is probably also nice. I didn't want to waste too much time on this though (parted has way more layers :)
<infinity> parted is evil incarnate.
<cjwatson> Would be nice to work out where that is in parted.  It might be specific to the disk layout ...
<infinity> Why are you even using parted instead of something simpler like sfdisk?
<mvo> infinity: I don't know, sorry, but afaik sfdisk has a similar problem a9cf659e0508c1f56813a7d74c64f67bbc962538 mentions sfdisk
<mvo> infinity, cjwatson I can look at gparted and timebox it
<mvo> its an interessting problem for sure :)
<infinity> mvo: So, wait.  Both sfdisk and parted are calling uuidgen when *growing* partitions, and they don't actually use the result for anything?
<infinity> mvo: Cause if so, lol?
<infinity> Or does growing imply giving it a new UUID because reasons?
<mvo> infinity: parted even call random_get_bytes (indirectly) when you just print partitions
<mvo> infinity: I have not looked at sfisk at all
<cjwatson> The calls here are in gpt_alloc and gpt_partition_new
<sladen> depends on the version of the UUID being requested to be generated ... eg. version 1 is MAC address + timestamp, which with reproducible builds, should produce the same result every time
<cjwatson> mvo: Are you using GPT on this disk?
<mvo> cjwatson: yes
<cjwatson> Arguably a bug in parted's GPT code then.  When it's constructing internal data structures to match what's on the disk, it generates GUIDs even though it's about to read the new ones off disk.
<cjwatson> s/the new ones/the existing ones/
<cjwatson> parted shares a fair bit of code between "create actual new partition" and "create new partition data structure and fill it in from what's on disk", and in this case the GUID generation is probably in the wrong place.
<cjwatson> It might need some kind of internal marker to do lazy GUID generation.
<cjwatson> Do file a bug - it's not completely simple but shouldn't be too hard.
<cjwatson> I think it's just GPT.
<mvo> cjwatson: I filed 1783973 but I think its probably overkill to fix as long as we don't need crypto strengh randomness for uuids
<infinity> mvo: Meh, it's wrong for anything to suck your entropy dry when it doesn't actually need any.
<infinity> Valid bug, even if the impact is minimized by the libuuid fix.
<Unit193> ..I don't suppose anyone would be interested in sponsoring irssi right now?
<chu> Need a maintainer?
<Unit193> chu: I like merging from Debian, but alas I am but a measly packageset uploader.
<chu> I thought about applying to look after the newest emacs but seems quite hectic
<Unit193> I think I looked at that package once, bailed the crap out of there.
<chu> Smart choice
<Unit193> dget -x https://sigma.unit193.net/source/irssi_1.1.1-1ubuntu1.dsc  if anyone is interested++
<chu> Fancy
<juliank> cyphermox: https://netplan.io/reference says different things than the netplan manpage, about timeouts specifically - netplan.io says they depend on the renderer, manpage says they are ms.
<gromero> Hi. I think there is an issue with with 18.04.1 PPC64 ISO. 'isoinfo' complains about Joliet SVD not being present in the ISO:
<gromero> root@pub:/var/lib/libvirt/isos# isoinfo -J -i ./bionic-live-server-amd64.iso # OK
<gromero> root@pub:/var/lib/libvirt/isos# isoinfo -J -i ./bionic-live-server-ppc64el.iso # Fail
<gromero> isoinfo: Unable to find Joliet SVD
<gromero> I see a difference regarding the # of partitions:
<gromero> root@pub:/var/lib/libvirt/isos# file ./bionic-live-server-amd64.iso
<gromero> ./bionic-live-server-amd64.iso: DOS/MBR boot sector; partition 2 : ID=0xef, start-CHS (0x3ff,254,63), end-CHS (0x3ff,254,63), startsector 1590408, 4672 sectors
<gromero> root@pub:/var/lib/libvirt/isos# file ./bionic-live-server-ppc64el.iso
<gromero> ./bionic-live-server-ppc64el.iso: DOS/MBR boot sector; partition 1 : ID=0x96, active, start-CHS (0x3ff,255,63), end-CHS (0x3ff,255,63), startsector 0, 1634024 sectors; partition 2 : ID=0xff, start-CHS (0x3ff,255,63), end-CHS (0x3ff,255,63), startsector 2129919, 1936615684 sectors
<gromero> Basically it forbids virt-install --location flag to work properly on that ISO: https://pastebin.com/raw/A0XZaNmM
<gromero> Does anybody have any clue on that?
<juliank> gromero: I'm not an expert, so, what is that, how is it used, and is it relevant for ppc64el?
<juliank> AFAICT, it is used when certain files are unicode encoded.
<gromero> juliank: Hi. Basically that error on Joliet SVD missing on that ISO, as far as I can tell, forbids that ISO to work properly with virt-install, i.e. I can't install a VM using the ISO on PPC64.
<gromero> juliank: I see. But do you know what's exactly the difference between Intel/AMD ISO and PPC64 that could trigger that error in isoinfo?
<gromero> juliank: you mean any file in the ISO?
<gpiccoli> infinity might be aware of this difference, let's see what he thinks when available
<gromero> (using unicode encode)
<gromero> gpiccoli: ok
<cyphermox> juliank: sure, the netplan.io website needs an update, that doesn't happen automatically
<juliank> cyphermox:it just got pointed out to me today, hence I thought I'd let you know :)
<cyphermox> yup, thanks
<cyphermox> pointed out by?
<cyphermox> (feel free to send them my way, new features, bugs, etc.)
<juliank> ugh
<juliank> $ petname -u
<juliank> -yeti
<juliank> no adjective with y?
<juliank> grr
<ogra> yodeling ?
<xnox> gromero, huh, that makes no sense =)
<xnox> gromero, amd64 has joliet, because it has uefi, and ppc64el, doesn't because it does not do eufi....
<xnox> gromero, you will find that e.g. arm64 is also joliet.
<xnox> gromero, this sounds like a bug in virt-install to me, and i'm not sure if that support ppc64el at all....?! does it work with any other ppc64el images for any other distro?
<xnox> gromero, also, why bother to use virt-install, when you can just directly boot ppc64el cloud-image that we provide?
<xnox> and provide appropriate metadata ISO to customize the instance, and resize the drive to needed size.
<gromero> xnox: virt-install just crash because of the Joliet error returned by make isoinfo. I would expect that virt-install is not that arch-specific also (aside from isoinfo issue). Let me try with RHEL.  I simply don't want to use cloud-image. Which cloud-image are you talking about specifically?
<xnox> gromero, https://cloud-images.ubuntu.com/bionic/current/ bionic-server-cloudimg-ppc64el.img
<xnox> gromero, which is pre-installed ubuntu-server, in qcow2 format, bootable, with cloud-init available, and awaiting e.g. seed.iso to be booted on the instance for autodiscovery and configuration
<xnox> gromero, at the bottom of https://cloudinit.readthedocs.io/en/latest/topics/datasources/nocloud.html there is a section on how to create a custom seed.iso with your own ssh keys, packages to isntall/configure, tec.
<gromero> ok I'll use that to move on. thanks for the hint. However I really not satisfied yet about the complains of isoinfo. I would like to understand what's really going on, so if anybody could explain I would be glad. Let me try with RHEL (will get back soon). ;)
<xnox> gromero, at the bottom of https://cloudinit.readthedocs.io/en/latest/topics/datasources/nocloud.html there is a section on how to create a custom seed.iso with your own ssh keys, packages to install/configure, etc.
<gromero> xnox: ok. I'll check that. Thanks!
<xnox> gromero, my initial suspection is that virt-install is expecting x86_64 .iso image with UEFI joilet partition for booting in e.g. uefi mode... which is all very x86_64 specific.
<xnox> gromero, i typically download and boot cloud images =) either directly with cmdline, via virt-manager, or with like uvt command line tool; or like with multipass command line tool, which provide the "give me a vm, ssh into it, quickly"
<xnox> depending on what i'm doing.
<xnox> gromero, but i also have access to ppc64el openstack and MAAS =) so i have all the toys available to me to play with everything.
<gromero> xnox: I see. Openstack and MAAS is too overkill to my case... multipass and uvt sounds better tho :)
<gromero> xnox: thanks for the hints. I'll try uvt
<xnox> gromero, everything does work on x86_64... and if it doesn't for some reason on ppc64el, do shout and we'll try to fix all the things.
<xnox> gromero, our cloud-images and cloud-init are working on all arches to be directly launched to create VMs -> i.e. all launchpad builders for all 7 arches work like that.
<gromero> xnox: ok. I'll experiment other ISOs to see how it goes. I still think the root cause is that isoinfo is not able to list files in the ISO with -J -i <ISO> -p on ppc64le
<gromero> xnox: do you use multipass and uvt with the cloud images?
<xnox> gromero, sure, but it is arch specific whether or not .iso is a joilet or not.
<xnox> gromero, they default to our cloud images, yes.
<gromero> xnox: ah, ok. I'll check that so.
<xnox> i think i did on x86_64 and arm64 and s390x.... mostly.
<gromero> xnox: yes, but isoinfo should detect the differences between ISOs and handle it nicely I think.
<xnox> and sans bugs, it should all just work on ppc64el too. I mean booting with a custom seed.iso as per docs about does work on ppc64el and i have done that.
<gromero> yes, cloud image I'll probably work fine on ppc64le
<gromero> what bugs me is that it didn't work with the ISO + virt-install as it does for other archs
<gromero> xnox: it does work perfectly with a RHEL 7.5 image: https://hastebin.com/raw/gobonexuwe
<gromero> xnox: just because isoinfo is able to list the content o RHEL's ISO
<xnox> gromero, please do $ ubuntu-bug virt-install
<xnox> and file details, and maybe we can figure out if patches to virt-install are needed, and/or isoinfo, and/or the way we produce our .iso images on ppc64el.
<xnox> gromero, i mean, we don't sabotage our images on purpose and we would rather them be as universally consumable as possible =)
<gromero> xnox: I would never think that Canonical sabotage their images or anything to be honest. And I still think the issue is with buggy isoinfo that is not smart enough to figure out the ISO particularities...
<gromero> ok. I can file a bug
<xnox> gromero, can even make the bug affect all the things you see should be fixed. in practice, silly things like that should just work, irrespective of the details.
<gromero> I don't think that not being able to list the ISO contents is a detail, but I'll file all the details I have in the bug. thanks.
<dannf> dmj_s76: not generally, no. why?
<Unit193> LocutusOfBorg: Howdy, you alive?
<LocutusOfBorg> Unit193, if you want to give me a merge... might be
<LocutusOfBorg> but going to sleep in 10 min
<Unit193> LocutusOfBorg: https://sigma.unit193.net/source/irssi_1.1.1-1ubuntu1.dsc how did you know?! :D
<LocutusOfBorg> I was going to ask you why you didn't gave me an irssi merge, already two days ago :)
<Unit193> Please make sure to check the changelog so we don't anger $other_people
<LocutusOfBorg> what do you mean?
<LocutusOfBorg> dpkg-buildpackage -S -sa -d -v1.0.7-1ubuntu1
<LocutusOfBorg> and I'm going to sponsor
<LocutusOfBorg> I don't get why the patch is applied only in Ubuntu, but meh
<LocutusOfBorg> dput refuses to upload "devel" codename, but dupload does
<LocutusOfBorg> I think I did it
<Unit193> Perhaps you mean dput-ng?  I use dput.
<LocutusOfBorg> I don't remember...
<LocutusOfBorg> one for doing dcut dm, the other fails to do it
<LocutusOfBorg> and then I install again the other one
<LocutusOfBorg> and then I change it back once somebody asks me to allow a package
<LocutusOfBorg> meh, :/
<LocutusOfBorg> I never found one tool to rule them all
<Unit193> dput just does what you tell it, dput-ng tries to lint first (which is good, except when it doesn't know better and won't let you do something.)  It does make certain Debian specific things easier though.
<bdmurray> slangasek: the package installation in bug 1784065 includes dpkg and libglib2.0-0 but libglib2.0-0 happened first
<ubottu> bug 1784065 in glib2.0 (Ubuntu) "package libglib2.0-0 2.48.2-0ubuntu3 failed to install/upgrade: triggers ci file contains unknown directive `interest-await'" [Undecided,Incomplete] https://launchpad.net/bugs/1784065
<slangasek> bdmurray: yeah, the dpkg SRU is unrelated
<bdmurray> dpkg:amd64 (1.17.5ubuntu5.8, 1.18.4ubuntu1.4) ?
<bdmurray> slangasek: its an upgrade from Trusty to Xenial
<slangasek> bdmurray: oh
<slangasek> bdmurray: did no one verify that trusty dpkg supported this syntax before we started changing xenial packages?
<bdmurray> slangasek: did no one suggest checking that? seriously I don't recall talking to juliank about it
<slangasek> bdmurray: I assumed there were other people more familiar with dpkg involved in this who would have checked :)
<slangasek> bdmurray: so, it's ok to still have the triggers changed, but it means that every package with this new syntax needs to have a pre-depends on newer dpkg
<bdmurray> slangasek: yes, I see that now
<bdmurray> slangasek: Are you updating the bug or shall I?
<slangasek> bdmurray: please do
#ubuntu-devel 2018-07-28
<juliank> slangasek, bdmurray I did not think about that at all. There were other xenial SRUs for trigger changes already so I probably thought someone checked that before
#ubuntu-devel 2018-07-29
<doko> tsimonq2: could you have a look at https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-cosmic/cosmic/amd64/s/spyder-unittest/20180727_095719_aee99@/log.gz ?
<infinity> wxl: Hey, could you apply another round of Democracy(tm) to https://launchpad.net/~techboard/+members ?
<Bert_2> Hi, we're updating our webworkers from 16.04 to 18.04 and noticed there's a bit of a problem in 18.04 with libcurl. Both libcurl3 and libcurl4 actually supply .so files for libcurl4 (so that's weird for sure), on top of that some packages depends on the 3 package and others on the 4 package, so that leaves it difficult to keep everything installed (php-curl requires 4, shibboleth requires 3)
<Bert_2> So, is that a mistake or what's the idea behind that?
<mdeslaur> xnox: ^
<mdeslaur> xnox: is the libcurl3 package support to provide libcurl.so.4, in conflict with libcurl4?
<mdeslaur> s/support/supposed/
<TJ-> bug #1776489
<ubottu> bug 1776489 in xmltooling (Ubuntu) "libxmltooling7 depends on libcurl3, which has been replaced by libcurl4 in Bionic" [Undecided,Confirmed] https://launchpad.net/bugs/1776489
<juliank> this seems so wrong
<Bert_2> juliank: I agree
<mdeslaur> oh, looks like libcurl3 has been shipping libcurl.so.4 for a long time
<TJ-> there's a note in the changelog about it
<xnox> Bert_2, mdeslaur, TJ-, juliank - the plan was to remove libcurl3 completely, and move over to libcurl4 throughout..... however, there is a package that not only depends on curl with openssl 1.0 ABI/API. Thus everything in the archive has moved onto libcurl4 with openssl1.1, but xmltooling....
<xnox> the only way to keep xmltooling installable and usable to build documentation/packages was to reintroduce libcurl3 with openssl1.0 that ships libcurl4.so =/
<xnox> it is extremely bad and ungly
<juliank> xnox: why doesn't it ship a libcurl3 so?
<juliank> were there other API breaks?
<juliank> or a libcurl-openssl1.so.4
<xnox> curl ones no, but things that try to access openssl ctx get confused as that has changed.
<xnox> juliank, i can't remember the soname mess and why it had to be libcurl4 now, but things would have been broken or something.
<juliank> hmm
<juliank> odd
<xnox> juliank, i'm confused how shibboleth-sp2  is involved, since as per tracker it was only http://people.canonical.com/~ubuntu-archive/transitions/html/curl4.html xmltooling
<xnox> that was the last remaining package that needed libcurl3
<xnox> it has libxmltooling7 dep
<xnox> juliank, glory detail https://launchpad.net/ubuntu/+source/curl3/7.58.0-2ubuntu2 and https://launchpad.net/ubuntu/+source/xmltooling/1.6.4-1ubuntu2
<juliank> xnox: details is a strong word
<juliank> :D
<juliank> I remembber there was something, but not what
<TJ-> I've found a major problem with the vagrant-libvirt package on 18.04 where it defaults to attaching its management network to "eth0" with no way to change that, and yet due to persistent network names, eth0 rarely exists, so vagrant boxes fail to start. I've located the upstream issue report and found that latest code has a patch that helps admins configure it now. Would this need to be pulled in via
<TJ-> Debian > 18.10 first, then SRU 18.04, or could we pull directly to 18.04 since it breaks vagrant fundamentally?
<TJ-> Upstream issue (see my comments at the very end) is https://github.com/vagrant-libvirt/vagrant-libvirt/issues/609
<TJ-> I'm about to open an Ubuntu bug to track this
<TJ-> Bug #1784229
<ubottu> bug 1784229 in vagrant-libvirt (Ubuntu) "18.04: VM fails to start due to management_network assuming non-existent interface eth0" [Undecided,New] https://launchpad.net/bugs/1784229
<xnox> Bert_2, so i see xml-security-c v2.0 out which appears to compile fine against openssl 1.1.... i wonder if recompiling all the new things from source is the answer here... to get all the things working.
<Bert_2> xnox: well yeah, we can't really compile shib ourselves on these production machines
<xnox> Bert_2, i understand.
<Bert_2> I mean, we are students and stuff, but the application we run are of a sort of important to a large amount (10-60k) students
<xnox> Bert_2, i wonder if we will be able to provide the upgraded curl4/openssl1.1 stack via backports or srus.
<Bert_2> and we are struggling to even get shib to run properly with the workaround in the blogpost
<Bert_2> xnox: I personally think SRUS would be appropriate in this case, since shib2 is just plain broken right now and it's a universe package anyway
<xnox> Bert_2, i have not read the blogpost. If I were you, I would assume shib is not available on 18.04 yet. And either stick to 16.04, or run shib things from xenial lxd container on bionic host.
<xnox> Bert_2, when we did this botch, we were expecting to fix it properly in time for bionic release =/
<Bert_2> an LXD container is not an option in this case since php requires curl4
<xnox> but clearly that didn't happen.
<Bert_2> yeah, clearly :P
<Bert_2> but yeah, we sorta assumed things were more tested/safe now that 18.04.1 was around
<xnox> Bert_2, i secretely expected that noboby is using this one little niche thing..... how young and wrong was I.
<TJ-> Bert_2: could you use a proxy connection from 18.04 into an LXD-16.04 container for this functionality ?
<Bert_2> we are looking into reinstalling to 16.04 if we have to, but we really don't want to
<Bert_2> TJ-: maybe if we proxy PHP out to something else, but that would also be quite a lot of work for just a few students, and hard to test
<Bert_2> and that would leave our FastCGI users confused
<Bert_2> since apache would run in the LXD container
<Bert_2> Ok, we got it working with the workaround/hack
<Bert_2> turns out they've changed the user that runs shibd
<Bert_2> therefore shibd can't read the certificate/key pair it needs
<Bert_2> and it doesn't log that problem, so we had strace it
<Bert_2> that's really not nice...
<xnox> charming!
<Bert_2> such a change should be in the release notes
<Bert_2> love 2 unrelated issues intermixing, makes things extra spicy <3
<xnox> Bert_2, reading the blog post, i think we should be able to fix up the libcurl3/libcurl4 mess as an SRU.
<Bert_2> xnox: we agree
<Bert_2> 3 people have been working on this for several hours here :P
<Bert_2> and I think a fix should be easy
<Bert_2> any idea who is willing to sponsor/do this, and what the ETA might be (days, weeks, months)?
<Bert_2> xnox: I've added a bug on the situation with the user change in shib, since it also results in upgrade issues: https://bugs.launchpad.net/ubuntu/+source/shibboleth-sp2/+bug/1784231
<ubottu> Launchpad bug 1784231 in shibboleth-sp2 (Ubuntu) "Unreported change of shibd user" [Undecided,Confirmed]
<TJ-> who/which channel is responsible for the cloud-images archives?
<Ionic> what's the first version to support the :all multi-arch annotation for dependencies? seems like that's not working for trusty... and maybe even xenial
<tsimonq2> doko: ack
<Unit193> xnox: Huh, what caused you to update libtorrent-rasterbar?
<wxl> infinity: not enough takers on the call for applicants?
<doko> Unit193: boost?
#ubuntu-devel 2019-07-22
<rbalint> santa_, do you observe the systemd issue on eoan or disco?
<rbalint> santa_, if on disco, please open a bug as a regression and subscribe me
<rbalint> santa_, if on eoan my plan is merging new upstream thus it may be solved and the bug would not be needed
<rbasak> Do I need an orig tarball for an upload for which no current publication exists, but the orig tarball does exist from a previous deleted publication?
<rbasak> I'll assume not, and see what happens I guess.
<rbasak> This will be mysql-8.0 8.0.14-0ubuntu2
<ogra> waveform, ogra@pi4:~$ free
<ogra>               total        used        free      shared  buff/cache   available
<ogra> Mem:        3986180      237348     2835232       23880      913600     3682676
<ogra> \o/
<ogra> 8in case you want to use it in your patchset: https://github.com/ogra1/pi4-experimental-gadget/commit/08547a89107f0ec1efc3b3e388987415e5f0737c )
<waveform> ogra, excellent! will take a look when github stops having issues :)
<santa_> rbalint: regarding the systemd issue I'm seeing it in eoan. I have also re-checked and it's not completely reproducible, sometimes it hangs, most times it doesn't
<santa_> the reason why I detected it's because I have a custom wannabuild/buildd setup in a couple of servers meant to do test rebuilds. I have configured the thing to execute autopkgtests @ the end of the build, and sometimes the autopkgtest runs hang on "systemctl start network-online.target"
<santa_> this happens ~ 10 times in 100 builds, and it only happens with the version from -proposed, the one from plain eoan works perfectly fine afaics
<santa_> I whish I could test with disco, but I'm afraid I have no time to re-configure the wannabuild thing to work also with disco (it's not a trivial thing)
<santa_> in any case I would bet it doesn't happen in disco
<rbalint> santa_, there are several fixes related to bumping gcc like fixing invalid code that did not crash with gcc 8, a rebuilt version of eoan's systemd in release would fail i bet
<rbalint> santa_, please wait for the new upstream release that has the gcc9 fixes
<rbalint> santa_, thanks for clarifying the problem
<santa_> rbalint: allright, right now I have systemd and systemd-sysv on hold on my build servers so I will unblock them once we get the new upstream release in eoan. thank you very much for your work
<ddstreet> rbalint have you looked into the systemd eoan FTBFS in test-json?
#ubuntu-devel 2019-07-23
<rbalint> ddstreet, yes, the plan is merging 242 from Debian instead of cherry-picking more changes
<ddstreet> rbalint ah ok, well i'll just sru and leave eoan as is then
<ddstreet> rbalint you mind if i push systemd to eoan to fix the FTBFS in the meantime, until it's updated to 242?
<coreycb> sil2100: hi, did you happen to get a chance to look at those RM bugs?
<sil2100> coreycb: sorry, got preempted last time and then forgot, picking them up now
<coreycb> sil2100: no problem, thanks so much
<sil2100> coreycb: ok, so I processed as many removals from the list as possible - I could not act on 2 of the bugs because the packages still had 'valid' reverse-dependencies
<sil2100> Left some comments there
<coreycb> sil2100: thanks i'll take a look
<rbalint> ddstreet, feel free but i'd rather drop it from proposed since issues keep popping up due to missing patches for gcc9
<ddstreet> rbalint the FTBFS is an upstream bug, the testcase overflows the stack, i'll fix it upstream first but it's trivial to fix in eoan as well
<ddstreet> but, i can just leave eoan alone...just means nobody can build systemd for eoan until 242 is merged (and hopefully, it will build then)
<rbalint> ddstreet, feel free to push the fix to eoan, too, i may not finish the merge today
<rbalint> ddstreet, my point was that it may not be the last issue to fix before it can migrate
<ddstreet> rbalint if you're merging todayish, i'll just stay out of your way
<rbalint> ddstreet, i start today, but i think it will take a few iteration to polish it, so if you are fairly certain that this update gets it to release, (like built in on all arches and autopkgtest passes) then it is worth a shot
<rbalint> ddstreet, santa_ also reported an issue, thus it is not only a testcase fix that's missing
<santa_> ddstreet: FYI the issue I have seen is that _sometimes_ the systemd from proposed hangs on "systemctl start network-online.target". the autopkgtest LXD backend relies on this command, so it makes autopkgtest hang. I have inspected systemd's git and there's a number of changes in the part I believe is involved in the hang
<santa_> rbalint: btw, whenever you have a package ready to test feel free to ping me and I will test as soon as I can
<roaksoax> ir
<ddstreet> santa_ have you opened a lp or upstream bug, and/or have dbg logs of it happening?
<ddstreet> if you are confident it's already fixed upstream tho, probably easiest to just retest after the merge to 242
<santa_> ddstreet: I'm not confident it's fixed upstream but the code involved changed
<santa_> let me see if I can find a build log with the thing happening
<santa_> http://tritemio-groomlake.duckdns.org/logs/knewstuff_5.60.0-0ubuntu1%2btritemio9_amd64-2019-07-19T21%3a16%3a10Z
<santa_> ddstreet: â just search "network-online.target" there
<ddstreet> santa_ well network-online.target will definitely block for more than 60 seconds if it's having trouble actually setting up the nw
<ddstreet> you sure that's not the problem?
<santa_> ddstreet: when that happened I got into the cointainer and if I recall correclty, the thing was blocked ad-infinitum, even after the network was actually up
<ddstreet> ah, well yeah that's bad then
<ddstreet> santa_ did you happen to notice, in the container, and dbus errors?  i've seen 'lost' dbus messages that cause waiting systemd processes to never finish, in some autopkgtests https://github.com/systemd/systemd/issues/12932
<ddstreet> you may need to turn on debug though, at least for dbus
<ddstreet> hopefully the 242 merge will fix it, though :)
<santa_> ddstreet: interesting. nope, I didn't check dbus thing. iirc I just checked the journal but I didn't see any ugly thing
<santa_> in any case if the 242 merge doesn't fix it I would be glad to re-check with your help
<santa_> I'm just a plain user wrt systemd XD
<rbasak> Skuggen: mysql-8.0 FTBFS. Looks like some openssl changes since the PPA build. Please could you take a look?
<rbasak> I don't know if it would be better to patch or bump to the latest microrelease if there's a fix upstream.
<rbasak> If it's not difficult I think cherry-picking a patch would be less disruptive, and we can update later? What do you think?
#ubuntu-devel 2019-07-24
<Skuggen> rbasak: 8.0.14 might be too old to support new openssl, yeah
<Skuggen> IIRC, we were a bit late with the 1.1.1 support
<Skuggen> I'll see if I can find the patch, and we can see if it applies. The PPA build was 8.0.16, though
<lag> tjaalton: Any luck with upgrading Mesa to >v19.1?
<tjaalton> lag: uploaded, but i messed up with the patches, it seems
<lag> tjaalton: What happened?
<lag> tjaalton: It seems like we are on 19.0.8 still
<tjaalton> failed to build
<lag> tjaalton: Ah
<lag> Will you fix it soon?
<tjaalton> yes
<lag> tjaalton: Great, thanks \o/
<tjaalton> lag: uploaded
<lag> tjaalton: Can I have a link to the build please?
<tjaalton> lag: https://launchpad.net/ubuntu/+source/mesa/19.1.2-1ubuntu2
<lag> tjaalton: Thanks dude - fill follow along
<lag> s/fill/will/
<rbasak> Skuggen: oh, I see. I didn't realise the PPA was a later version. We could just bump the archive up to the PPA then?
<Skuggen> Yeah, I think that's best
<infinity> LocutusOfBorg: virtualbox-dkms dropping support for pre-5.2 kernels is rather painful for upgrades. :/
<infinity> Setting up virtualbox-dkms (6.0.10-dfsg-1) ...
<infinity> Loading new virtualbox-6.0.10 DKMS files...
<infinity> Building for 5.0.0-16-lowlatency 5.2.0-8-lowlatency
<infinity> Building initial module for 5.0.0-16-lowlatency
<infinity> ERROR (dkms apport): kernel package linux-headers-5.0.0-16-lowlatency is not supported
<infinity> LocutusOfBorg: Kills the postinst, and breaks the upgrade.
<infinity> Oh, this is the stupid fcf-protection mismatch madness.
<infinity> What a colossal pain.
<rbasak> coreycb: o/
<rbasak> coreycb: just realised you weren't subscribed to bug 1829823
<ubottu> bug 1829823 in Ubuntu Cloud Archive mitaka "libvirt-bin: during shutdown libvirt-bin is stopped before libvirt-guests causing hang" [High,In progress] https://launchpad.net/bugs/1829823
<rbasak> Please could you take a look to see if you're happy with the staging plan and can commit to SRU verification on that basis?
<rbasak> ahasenack: what's the status of bug 1834072 in Eoan, please? I don't see that information in the bug.
<ubottu> bug 1834072 in ruby2.3 (Ubuntu) "Puppet agent using 100% CPU, in sched_yield() loop. Looks like an issue with ruby2.3 which has been fixed but not yet made it into Ubuntu." [High,In progress] https://launchpad.net/bugs/1834072
<infinity> sforshee: The fcf-protection versus dkms modules thing might need more thought than it's been given.
<coreycb> rbasak: thanks for doing that. i just added my +1 to the bug. as for verification I think matthew will be doing it but if not then yes I can.
<rbasak> coreycb: great, thanks! I'll review the actual upload next.
<infinity> sforshee: On upgrade from bionic or disco, if gcc is updated, then a dkms module, dkms will attempt to rebuild for the running kernel, and explode the upgrade.  Which seems not entirely ideal.
<infinity> sforshee: I have no good ideas right now (unless there's a way to have dkms itself inject some -fno-evil CCFLAGs into every build), just thought I'd toss that out there.
<infinity> sforshee: My laptop's recent eoan->eoan upgrade went through that exact problem.  GCC upgrade, virtualbox-dkms upgraded, postinst explodes, dpkg terminate, grandma cries.
<rbasak> infinity is a grandma?
<infinity> rbasak: Grandma is my hypothetical NTEU who would have given up at the point where dpkg told her angry things.
<rbasak> infinity: but given it's _your_ laptop having the problem that led to grandma crying, the only logical conclusion is that you're a grandma :-P
<infinity> I might be.
<infinity> Would you like some pie, dearie?
<rbasak> I'm a tauist myself
<rbasak> But thanks
<sforshee> infinity: ok, I'll look at what we can do with dkms
<infinity> I don't care if you're just visiting!
<infinity> In retrospect, someone really should have given GCC a '-kernel' command line option that just automatically disabled anything clearly meant for userspace.
<infinity> Then this sort of thing wouldn't keep happening.
<sforshee> at minimum we can sru the cflags change to bionic and disco
<sforshee> if we can't figure out something better
<infinity> sforshee: Yeah, that'll mitigate the issue so it's only people doing eoan->eoan upgrades or people upgrading bionic and disco from older kernels.
<infinity> Assuming GCC will ignore -fno-feature for a feature it doesn't have.
<sforshee> infinity: it doesn't, but we check whehter or not the compiler supports it
<infinity> sforshee: Ahh, kay.
<infinity> And indeed it doesn't.
<infinity> $ gcc -fno-unknown-feature-foo -o hello hello.c
<infinity> gcc: error: unrecognized command line option â-fno-unknown-feature-fooâ
<infinity> Seems also like poor design, but whatevs.
<ahasenack> rbasak: wrt #1834072, comments #19 and #20? Is it not in the unapproved queue?
<cjwatson> rbasak: Trying to work out if you will have religious objections to http://www.cadaeic.net/cadenza.htm in that case
<cjwatson> (follow link at the top if you're confused)
<ahasenack> rbasak: ah, eoan, sorry
<rbasak> cjwatson: no religious objections, but it seems rather arbitrary to base a word game on _half_ the circle constant :-P
<cjwatson> heh
<rbasak> ahasenack: yeah. Sorry, I just realised that there is a Debian BTS link. Perhaps I could have figured it out from that.
<rbasak> I do prefer not having to detective work when SRU processing though please :)
<ahasenack> hmm
<ahasenack> sure
<ahasenack> and you may be on to something
 * ahasenack recovers memory from cold storage
<ahasenack> no, I just had a small confusion due to the fact ruby2.3 is not available elsewhere
<ahasenack> rbasak: >= bionic has the fix, let me clarify that in the bug
<ahasenack> [Other Info]
<ahasenack> Bionic has ruby 2.5.1 and it has this fix already, as do all later ubuntu releaes.
<ahasenack> rbasak: ^
<rbasak> Thanks!
<rbasak> rbalint, kenvandine: BTW, you both have an ubuntu-meta in the Xenial SRU queue that conflict. Sorry I didn't get time to look at those today, but you may want to resolve that between yourselves.
<rbasak> (for the next reviewer who does)
<LocutusOfBorg> infinity, shouldn't the kernel be fixed to avoid such flag?
<LocutusOfBorg> it should already have that fix
<LocutusOfBorg> can anybody please explain this?
<LocutusOfBorg> trying: cairocffi
<LocutusOfBorg> skipped: cairocffi (50, 0, 37)
<LocutusOfBorg>     got: 44+0: a-8:a-8:a-8:i-7:p-6:s-7
<LocutusOfBorg>     * s390x: printrun
<LocutusOfBorg> I can't figure it out
<ahasenack> it claims a bunch of packages (8, 7 and 6, depending on arch) will be removed if cairocffi is to be installed, that's as far as I got
<ahasenack> s390x is just the first it lists in more detail
<ahasenack> but amd64 is in there too
<ahasenack> does it only list printrun?
<ahasenack> or did you truncate the output
<ahasenack> before pasting her
<vorlon> update_output always truncates and only lists the uninstallables for the "first" arch it processes
<vorlon> and the uninstallable count tells you the total uninstallable account; if the baseline is non-zero, you have to check which of those numbers have increased
<vorlon> (baseline from top of the run is: a-8:a-8:a-8:i-7:p-6:s-6)
<vorlon> so it's an s390x-specific uninstallability, possibly a result of cairocffi, being an arch: all package (and therefore excluded itself from the uninstallable calculation) picking up a new dependency on an arch-dep package which is unavailable on s390x
<LocutusOfBorg> vorlon, do you have any idea without an s390x machine to find which one?
<LocutusOfBorg> damn, is it python3-xcffib ?
<LocutusOfBorg> :/
<vorlon> LocutusOfBorg: I haven't looked, but it should be straightforward to look at the dependencies of printrun, figure out which ones are Arch: any,
<vorlon> LocutusOfBorg: eh- look at the dependencies of *cairocffi*, figure out which ones are arch: any, and see which ones are not built on s390x
<vorlon> and in particular, look at the changes to the deps of the cairocffi packages between eoan and eoan-proposed
<connor_k> I'm having some trouble generating source package files with a simple 1 line change I'm trying to make to a package. I made a new patch with "quilt new name-of-patch.patch" then staged chances for it with "quilt edit path-to-file", ran "quilt refresh" to make sure the contents of the patch were updated. When I go to run "debuild -S -d", it insists the patch is in reverse format and stops. When I apply the patch manually with "qui
<connor_k>  push" or "patch" there's no issue, just when using "debuild". Here's the error: https://paste.ubuntu.com/p/KdtJ4FyWJw/ and here's the patch: https://paste.ubuntu.com/p/DtDKXGwvH3/ -- have I missed something terribly obvious?
<sarnold> connor_k: wild guessing, quilt push -a or quilt pop -a before trying the build
<connor_k> sarnold, same result with both of those, I'm afraid :(
<santa_> connor_k: so you are trying to change a file under debian, is that correct?
<connor_k> santa_, yes that is right
<santa_> under the debian/ directory
<connor_k> yes
<santa_> well, that can't be done I'm afraid
<santa_> the thing with quilt patches in the debian packaging is meant to alter the upstream source code in non-native packages (i.e. files outside the debian/ dir)
<santa_> if you whish to change the debian files I think you have to change them directly
<santa_> at least, I see no other way
<connor_k> aha, thank you santa_!
<sarnold> aha! thanks santa_ :)
<santa_> if what you want to do is a custom package for yourself and keep track of you changes you can always use git ;)
<santa_> you're welcome :)
<cjwatson> It would be desperately confusing to patch files in debian/ using debian/patches/*, so indeed you shouldn't do that
<cjwatson> Even if it worked :-)
<vorlon> LocutusOfBorg: so I have no idea why python-xcffib is not built on s390x but python3-xcffib is, but anyway I guess you fix this by moving printrun to python3
<connor_k> most everything i do is desperately confusing, but it gets a little bit better every day :)
<sarnold> :)
<LocutusOfBorg> thanks vorlon I think I already fixed the problem, unfortunately xcffib is used in testsuite so I hope I fixed xcffib too
<LocutusOfBorg> anyway, does anybody know why this package fails to build? https://launchpad.net/ubuntu/+source/ncurses/6.1+20190713-1ubuntu2/+build/17300776
<LocutusOfBorg> it doesn't fail to install on local pbuilder or debomatic sbuild machine...
<LocutusOfBorg> looks like some ppa related stuff...
<LocutusOfBorg> retrying worked... meh
#ubuntu-devel 2019-07-25
<rbasak> Could someone please explain https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#mysql-8.0?
<rbasak> eg. libmysqlclient-dev/amd64 unsatisfiable Depends: libmysqlclient21 (= 8.0.16-0ubuntu1)
<rbasak> But that's produced by the same source package, and does seem to be installable in combined release+proposed at least
<rbasak> The binaries were accepted yesterday
<rbasak> pitti: http://people.canonical.com/~pitti/scripts/britney-indexes as linked from https://wiki.ubuntu.com/ProposedMigration/LocalSetup no longer exists. Any chance of a copy? Does anyone else have it, please?
<rbasak> Or I will try and reverse engineer what it does :-/
<rbasak> Oh. Could it be a component mismatch?
<rbasak> o mysql-8.0: libmysqlclient21 mysql-client-8.0 mysql-client-core-8.0 mysql-server-8.0 mysql-server-core-8.0
<rbasak>    [Reverse-Depends: libmysqlclient-dev (MAIN), mysql-client-8.0, mysql-server (MAIN), mysql-server-8.0]
<rbasak> Aha
<rbasak> We already seed mysql-server, which is created by src:mysql-8.0 now (taking over from src:mysql-5.7), which depends on mysql-server-8.0, which is in universe.
<rbasak> So that (and perhaps some other binaries) need overriding over by an AA I think.
<pitti> rbasak: Robert did an improved version of that in https://git.launchpad.net/bileto/tree/britney/fetch-indexes
<pitti> althuogh it seems this wasn't updated in a while
<rbasak> pitti: well it's better than a 404, so I'll update the wiki. Thanks!
<rbasak> Could an AA please move src:mysql-8.0 in eoan-proposed to main, and the following binaries that are renamed from 5.7? libmysqlclient21 mysql-client-8.0 mysql-client-core-8.0 mysql-server-8.0 mysql-server-core-8.0
<rbasak> apw or sil2100: around please? ^
<apw> rbasak, looking
<rbasak> apw: any joy please? Or did you get interrupted?
<apw> rbasak, i've asked for the change, but hte publisher was down until about T-10m because the librarian was in a heap
<apw> and as a result it has a large backlog
<rbasak> Ah. Thanks!
<rbasak> apw: it worked now. Thanks!
<rbalint> santa_, ddstreet : i placed the systemd 242 merge in ppa:rbalint/scratch3 but autpkgtest infra did not like me and now i'm testing that locally
<rbalint> sil2100, ^
<rbalint> eoan boots to desktop with it but i'm waiting for a full qemu run before i upload
<rbasak> Skuggen: results are coming in for autopkgtest failures now: https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#mysql-8.0
<rbasak> Skuggen: we need to get these fixed first
<rbasak> (though we can upload FTBFS fixes that we know are required, too)
<rbasak> They should build against libmysqlclient21 now and thus the transition will begin.
<rbasak> Skuggen: I'll look at cacti first. Looks straightforward.
<sil2100> rbalint: thanks o/
<rbasak> I'll stick debdiffs in the same repo we were using for review.
<Skuggen> rbasak: Yeah, I'll get the 8.0 build tests fixed
<rbasak> Skuggen: thanks
<rbasak> The cacti failure is actually a dbconfig failure
<rbasak> That dep8 isn't triggered directly but I suspect it also fails
<Skuggen> The MySQL failure is a bit odd. Thought maybe it was just a missing symlink for the test client binaries, but we don't seem to build the binary it complains about at all
<Skuggen> dbconfig failure seems to be that 8.0 no longer allows adding "IDENTIFIED BY" clause to a GRANT statement
<rbasak> Yes
<rbasak> The question is how to change it exactly
<rbasak> I think the code ensures that the user always exists first
<rbasak> So I think I can insert an "ALTER USER x IDENTIFIED BY" before it (not checked for syntax)
<rbasak> I'm hoping the existing tests will check my fix though. Still running them, but I think I saw the right kinds of failrues scroll by.
<Skuggen> Oh, about the MySQL failure: we build with --list-missing. I was expecting it to fail if there were unhandled binaries :)
<Skuggen> There was a similar issue in ruby-mysql, but there the fix was just to remove the clause
<rbasak> There is also --fail-missing
<Skuggen> Yeah, we use that upstream. We'd need to do some cleanup for it. There are some extra docs files we don't include, and also router
<juliank> vorlon: Do you happen to know why we have wait-for-root? this is significantly delaying the boot because it's sitting around for 30s and only then we enter Debian's loop which executes local-block which in turn runs lvchange and hence is able to discover the new lvm volumes after unlocking a crypt partition
<juliank> xnox: ^
<juliank> If I add a local_block "${dev_id}" call before we run wait-for-root stuff works fine
<Skuggen> rbasak: I've added the missing files (except router and redundant docs files). Will test locally, then make a merge request in salsa
<vorlon> juliank: "why we have it" is because it worked when it was added and solved problems.  AFAIK Debian still doesn't use udev in the initramfs so the boot process is different between Debian and Ubuntu
<vorlon>         # in ubuntu, we should never actually enter this loop as wait-for-root
<vorlon>         # above should waited until the device appeared.
<vorlon> juliank: so the device should've appeared before
<juliank> vorlon: No, there's some udev involved somehow. But now it's definitely not running lvm2 after I'm unlocking the cryptroot before we run wait-for-root
<juliank> The root device appears if I run local_block before wait-for-root, as that runs lvm2's lvchange which creates the root device
<juliank> This used to work in disco I think but it somehow got broken
<juliank> What happens is that we run lvm2 (via local-top) -> cryptroot - ... -> wait-for-root -...-> lvm2 (via local-block)
<rbasak> Skuggen: great. Thanks!
<juliank> I gotta setup two encrypted VMs with disco and eoan and see what the difference in the boot is
<xnox> juliank:  i think we want to drop wait-for-root and switch to settle / local-block loop thing
<juliank> +1
<vorlon> xnox, juliank: I am uncomfortable with having to reintroduce any sort of loops in the shell code when this should all be driven by udev rules
<vorlon> I'd like to understand why this stopped working
<juliank> vorlon: I'd like to understand it too, but I don't see any difference in the initramfs debug trace
<juliank> vorlon: Maybe the appearance of the crypt mapping should cause lvm2 to be running via udev and it's not?
<juliank> where the crypt mapping is an LVM2 PV
<vorlon> yes, that's what should happen
<juliank> so maybe lvm2
<vorlon> yes
<juliank> 's udev rules broke somewhere
<juliank> vorlon: So, in eoan, the udev rule that runs pvscan moved to use pvscan@.service
<juliank> I think
<juliank> hmm
<xnox> vorlon:  loop in shell code, in initrd is new(ish) to support udev-based arbitrary stacking of raid/lvm/crypto
<juliank> xnox: I think the argument is that udev should be handling the stacking itself, by running codes from RUN as needed
<xnox> vorlon:  the old loop, had static stacking.
<xnox> juliank:  but it can't for unlock.
<vorlon> for unlock true, but per juliank's description, that's not where it's sticking
<juliank> xnox: once you unlocked, an LVM PV appears, and the udev rule should RUN pvscan to scan it
<juliank> ah but yes
<xnox> juliank:  we could do unlock from udev too.... if we add systemd with systemd-cryptsetup and tty-ask
<juliank> if you have cryptroot nested inside cryptroot too?
<xnox> yes
<juliank> So, I reverted the eoan machine to disco's lvm2 69*rule, but it did not help
<juliank> and debugging udev hook stuff inside initramfs
<juliank> sounds hard
<juliank> The Debian approach is certainly more flexible
<vorlon> historically, Debian's approach has been much slower.  If that's fixed, we can look at reconverging
<juliank> xnox: We might just need a systemd in the initramfs that has one init.service that executes the initramfs-tools init script
<juliank> The problem I tihnk I see is that udev rules want to start systemd services now, and we don't have systemd in the initramfs, hence the udev rules don't work
<juliank> I might be hitting a different issue but not sure
<vorlon> does that imply Debian's udev rules are now also incompatible with non-systemd init?
<vorlon> I would think that's a bigger issue for them than us
<juliank> I'm not sure
<juliank> so, the lvm2 rules pass --disable-udev-systemd-background-jobs but only for the udeb
<vorlon> in debian/rules you mean
<vorlon> cute
<juliank> and 69-lvm-metad.rules executes stuff like this:
<juliank> ACTION!="remove", ENV{LVM_PV_GONE}=="1", RUN+="/bin/systemd-run /sbin/lvm pvscan --cache $major:$minor", GOTO="lvm_end"
<juliank> so without systemd-run I'd expect lvm to be broken
<juliank> and init papers over that
<juliank> because local-block and local-top run lvchange in a loop until the root device is found
<juliank> vorlon: But if that's the problem, we do want to have that stuff on the host, but we can't have it in initramfs
<vorlon> juliank: I don't see any reason to need to background this via systemd-run.  A pvscan of a single PV should be trivially quick
<vorlon> i.e. it looks to me to be appropriate to --disable-udev-systemd-background-jobs for both host and initramfs
<vorlon> alternatively we could mock /bin/systemd-run in the initramfs, avoiding the need to mangle udev rules
<vorlon> cat > /bin/systemd-run
<vorlon> #!/bin/sh
<vorlon> exec "$@"
<juliank> vorlon: there's also a pvscan@.service
<juliank> rebuilt lvm2 with that --disable option, going to see what happens
<juliank> currently it's weirdly stuck
<juliank> So that seems to fix it
<juliank> Now testing on the host rather than the VM
<juliank> So yeah, we want that version in the initramfs, but we'd want the other on the host
<juliank> Laney just poited out that the systemd version also runs on change, whereas the direct pvscan one only runs on add
<vorlon> again, I think this systemd indirection is spurious.  I can't imagine how a pvscan of a single block device would ever hit a systemd timeout
<juliank> vorlon: I think upstream must have had a good reason for adding this
<juliank> vorlon: https://github.com/lvmteam/lvm2/commit/546db1c4be55d47d41082a345e15a35055223154#diff-b9ff0cca0b0701fbf51064e3459fa592
<juliank> vorlon: In any case, we build the rule in both variants anyway (for deb and udeb), so we can just copy the udeb one to the initramfs
<vorlon> juliank: ok if the udev rule is forking and spawning lvmetad, that would be long-running.  I think it's still an upside-down way to implement it
<juliank> Isn't lvmetad gone these days?
<vorlon> *I* don't use lvmetad
<juliank> "  Remove lvmetad"
<juliank> in 2.03
<vorlon> but it's part of the rationale in that commit
<vorlon> heh
<vorlon> so maybe the rationale for supporting long-running processes from the udev rules is itself obsolete
<juliank> 2.03 removed a lot of daemons
<juliank> vorlon: I'm just going to report a bug in Debian now that it won't work on alternate inits :D
<vorlon> anyway, I still think it's cleaner to mock systemd-run in the initramfs than to copy the udeb version of the rules
 * vorlon nods
<juliank> debian bug 933011
<ubottu> Debian bug 933011 in lvm2 "lvm2: udev rules don't work outside of systemd" [Important,Open] http://bugs.debian.org/933011
<juliank> vorlon: So instead of hardcoding either solution. I'm changing the script so it uses systemd on systemd systems and direct execution otherwise
<juliank> So ACTION!="add", GOTO="lvm_end" in classic mode, and ACTION!="add|change", GOTO="lvm_end" in systemd mode now become
<juliank> TEST!="/run/systemd/system", ACTION!="add", GOTO="lvm_end"
<juliank> TEST=="/run/systemd/system", ACTION!="add|change", GOTO="lvm_end"
<vorlon> juliank: you overachiever
<vorlon> wfm
<juliank> Laney found out about the TEST== rule
<Laney> â¸ â¢ â¡
<juliank> lvm2 uploaded
<juliank> patch forwarded to Debian, upstream
<juliank> We should probably consider changing installers to setup thinpool when doing lvm, so that people can benefit from thinpool snapshots and stuff
#ubuntu-devel 2019-07-26
<Skuggen> How is apparmor set up for dep8 testing?
<cking> i'm seeing gawk segfaults on xenial gawk ppc64el, 1:4.1.3+dfsg-0.1, https://bugs.launchpad.net/ubuntu/+source/gawk/+bug/1838014 - this is a regression for sure
<ubottu> Launchpad bug 1838014 in gawk (Ubuntu) "random segfaults in gawk on ppc6el xenial, gawk 1:4.1.3+dfsg-0.1" [Critical,New]
<rbasak> coreycb: heads up on a nova dep8 failure
<rbasak> ERROR 1064 (42000) at line 2: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'IDENTIFIED BY 'changeme'' at line 1
<rbasak> That's because MySQL 8.0 has deprecated and removed the use of IDENTIFIED BY in a GRANT statement
<coreycb> rbasak: thanks, is that eoan?
<rbasak> The user's password has to be set during CREATE USER or with ALTER USER.
<rbasak> coreycb: yes - the MySQL 8 transition is now in progress
<coreycb> rbasak: right ok thanks we'll take a look
<rbasak> We will get to it if you don't, but we have rather a long list of fixes to make right now :-/
<rbasak> coreycb: let me know if you do look into it and hit anything else. I vaguely know of all the MySQL 8 breaking changes.
<coreycb> rbasak: ok thank you
<rbasak> rafaeldtinoco: oh, one more thing
<rbasak> rafaeldtinoco: we're staging patches at https://code.launchpad.net/~mysql-ubuntu/+git/mysql-8.0-transition
<rbasak> Since most packages aren't imported into git-ubuntu, we can't use MPs
<rbasak> Feel free to push directly there when ready
<rafaeldtinoco> rbasak: perfect!
<rafaeldtinoco> tks
<bdmurray> How could I figure out why / how a systemd service has been disabled?
<bdmurray> vorlon: ^?
<vorlon> bdmurray: uh grep -r
<bdmurray> vorlon: ?
<vorlon> bdmurray: figuring out how/why it's been disabled, well, anything could've done it including a user, so if the user didn't do it you have to look around the system in all the places software might be running that would manipulate the state of the systemd units
<vorlon> grep -r systemd.*$unit_name /var/lib/dpkg/info ?
<bdmurray> vorlon: I'm the user and don't think I did it. Strangely whoopsie is active but disabled
<vorlon> huh
<vorlon> what's the output of systemctl status whoopsie?
<bdmurray> and I don't see anything in journalctl strange since my most recent reboot which was this morning
<bdmurray> Loaded: loaded (/lib/systemd/system/whoopsie.service; disabled; vendor preset: enabled)
<bdmurray> vorlon: https://paste.ubuntu.com/p/Xpnk4rDHKk/
<vorlon> bdmurray: ok; that state can be reproduced by running 'systemctl disable whoopsie' on a system that has the whoopsie service running
<vorlon> but that doesn't say what did this
<bdmurray> hrm, there are some bugs where I think people are having the same issue
<vorlon> bdmurray: how did you come to notice it?  especially given that the service only started 1h43m prior to the pastebin
<bdmurray> vorlon: "Here's a litte story I've got to tell..." so cinnamon-settings crashed and I clicked continue on the crash report and nothing happened and I remembered bug 1814611 (b/c I got an email about it this morning) and then I looked and didrocks MP from a while ago (https://code.launchpad.net/~didrocks/apport/whoopsie-auto-ui/+merge/348479) and then I saw the call to 'sytemctl is-enabled
<ubottu> bug 1814611 in apport (Ubuntu) "ubuntu-bug never (any longer) opens browser window" [Undecided,Confirmed] https://launchpad.net/bugs/1814611
<bdmurray> whoopsie.service' so I tried that.
<bdmurray> Maybe is-active is a better check but regardless I wonder what's going on.
<vorlon> huh
<vorlon> so is-active will return false if the service has recently crashed and is in the process of restarting; is-enabled will return false in your present situation
<vorlon> depends whether you're trying to check state (is-active) or intent (is-enabled)
<juliank> Maybe someone here has an idea:
<juliank> swift post "moo" works, but the script does not: https://paste.ubuntu.com/p/8s8smBRVwQ/
<juliank> it's using the same environment variables?
<juliank> ah
<juliank> swift command-line client is using OS_ variables
<juliank> and there's a typo somewhere
<connor_k> Aside from putting together some kind of scraper, is there a way to view all the child wiki pages descending from a single wiki page root on the ubuntu wiki? I.e., all pages descending from https://wiki.ubuntu.com/Kernel/
<connor_k> using the search menu for something like Kernel/ gets me close, but it's paginated and I suspect it's matching a number of pages that are not specifically descended from the root one
<sarnold> connor_k: oh god that sounds terrible. the wiki is SO SLOW scraping a subset will take an absolute eternity
<connor_k> sarnold, actually launchpad was surprisingly spry today
<connor_k> i did this horrible thing to accomplish what I wanted: https://paste.ubuntu.com/p/z4cxXqw8Q5/
<connor_k> ^ certainly not intended to be an actual solution for anyone else, I'm basically throwing that script away lol
<sarnold> connor_k: hah, cool :) how long did that thing take?
<connor_k> sarnold, about 10 seconds to get the ~270ish results I was interested in
<sarnold> nice
#ubuntu-devel 2019-07-27
<DarinMiller> By chance does anyone know why libmysql-java was omitted from 19.04?  It was present in 18.10... https://packages.ubuntu.com/search?keywords=libmysql-java&searchon=names&suite=all&section=all
<vorlon> DarinMiller: https://launchpad.net/ubuntu/+source/mysql-connector-java/+publishinghistory
<DarinMiller> thanks vorlon. so as per the link, we should now use the libmariadb-java package.
#ubuntu-devel 2020-07-20
<LocutusOfBorg> tjaalton, hello, do we have any reason for ocl-icd being at a really old version?
 * LocutusOfBorg does sync it
<LocutusOfBorg> bad rafaeldtinoco not forwarding kronosnet patches to Debian...
 * LocutusOfBorg does it
<LocutusOfBorg> oh somebody tried to do a merge request
<rafaeldtinoco> didnt I ?
<rafaeldtinoco> now I got push rights to debian-ha #)
<rafaeldtinoco> oh, bryce's i386 ones.. I see now
<rafaeldtinoco> wasn't sure I should fwd it back then, as we were doing all the i386 moves in focal, thx for fwding
<LocutusOfBorg> rafaeldtinoco, so if you want to merge, there is my pr now open
<LocutusOfBorg> https://salsa.debian.org/ha-team/kronosnet/-/merge_requests/2
<LocutusOfBorg> I would also close the other one
<rafaeldtinoco> LocutusOfBorg: will do
<LocutusOfBorg> ta!
<LocutusOfBorg> rafaeldtinoco, don't forget to close the other pull request please :D
<rafaeldtinoco> I did altogether
<LocutusOfBorg> thanks!
<sil2100> GunnarHj: hey! Would you be fine for me to release all the updated focal base langpack packages to -updates?
<sil2100> s/for me to release/with me releasing/
<GunnarHj> sil2100: Yes, I see no reason why you wouldn't. Haven't seen any regression myself, and have not seen any reports which would indicate a problem.
<sil2100> GunnarHj: thanks!
<pqatsi> Hello! I've registered the issue https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1887257 and found a solution. Since it's the first time I try to apply a fix in an Ubuntu bug report, can some dev tell me if its in a correct form or if something else is needed?
<ubottu> Launchpad bug 1887257 in grub2 (Ubuntu) "update-grub does not create any entry on grub.cfg for ZFS on root" [Undecided,New]
<sarnold> pqatsi: maybe attach also the set -x output after your change, so the diff between them can be compared?
<pqatsi> sarnold: I can make it too, but the bug got awnsered and I need to check that condition
<sarnold> pqatsi: aha I see juliank had my similar concerns but came to a better conclusion :D
<pqatsi> sarnold: Indded juliank is right, but I did not made any manual change here, so I'm trying (Without sucess) to find out who is the package that changed the default sh link.
<pqatsi> I remember a old discussion about the dash issue (And why bash is not used) and all the effects on system. I'm also checking scripts at /var/lib/dpkg/info but no much sucess here :(
<pqatsi> sarnold: Only thing I found here is bash.postinst that sets a link to sh if no other link is found. Dash also does have a function like this, but with more strict checks
<pqatsi> For some reason may be bash being configured before dash anyways or after some update?
<sarnold> pqatsi: mm, maybe if one or the other were stuck in half-configured state, then the other one were run, maybe?
<pqatsi> sarnold: Dunno. I know some ubuntu internals and etc, but in this computer I use it as i'm a dumb, restricting me to use zfs (For testing and docker) and some apt install commands. This is why I cant understand what happened here.
<sarnold> wow you weren't kidding about the dash postinst, that's involved..
<pqatsi> sarnold: no no, im reading the files to find what can be changed the link. I never touched on dpkg-reconfigure as example
<pqatsi> (Ah, sorry, I understood wrong what you said)
<pqatsi> dash.postinst and bash.postint handles the symlink
<pqatsi> I'm considering remove the link and try dpkg-reconfigure dash
<pqatsi> This issue with grub happened after some big update here and I guess it was before 5.4.0-32 kernel version was launched, since my updates stucked at this kernel
#ubuntu-devel 2020-07-21
<abeato> anybody knows why the hugepages package is not in focal anymore (https://bugs.launchpad.net/ubuntu/+source/libhugetlbfs/+bug/1873103)?
<ubottu> Launchpad bug 1873103 in libhugetlbfs (Ubuntu) "The hugepages package isn't available on Focal repos anymore" [Undecided,Confirmed]
<Unit193> Try libhugetlbfs-bin?
<abeato> it is not found either
<abeato> ah, wait, it should be there
<abeato> thanks
<Unit193> Sure thing.
<mwhudson> huh maybe glib really is causing a regression here https://autopkgtest.ubuntu.com/packages/s/sbd/groovy/amd64
<xnox> doko:  so gcc-10/binutils are next? but when can i do libffi? or shall we wait on response from upstream?
<doko> xnox: binutils 2.35 already is in groovy. gcc-10 is not related. which soname do you want to use?
<xnox> doko:  .so.8 and bash upstream to bump it to .so.9 if they break it between now and going forward.
<xnox> doko:  that is take current git snapshot and roll with it.
<doko> no, that would assume a decision on upstream. either don't bump the soname, and change the package name to libffi7-1, or bump it to 80, and change the package name to libffi80
<seb128> mwhudson, could be really buggy but it seems it has been forced hinted now...
<Laney> whoops, I hinted and then unhinted it, guess I was too late with that
<Laney> but there was another retry since which also failed, sooooo
<xnox> doko:  but upstream master has bumped soname
<xnox> doko:  so their master is 8, and package name should be libffi8. I guess i want it to be explicit, so should email them.
<ahasenack> rbasak: hi, I have a packaging question
<ahasenack> rbasak: when adding a d/<package>.maintscript file to a package that has, let's say, just d/postinst
<ahasenack> but not the other d/postrm, d/prerm, etc files
<ahasenack> I suppose I have to add them with the #DEBHELPER# marker, so that dpkg-maintscript-helper can do its job?
<rbasak> IIRC, you don't.
<rbasak> debhelper will create the ones that don't exist
<doko> xnox: it's not a release, you don't know if it will change until the release
<rbasak> Easy enough to verify in the built deb, but I'm pretty sure
<ahasenack> rbasak: hm, create when? At build time, and ship in the binary?
<rbasak> At build time, into the binary - without changing the source
<ahasenack> thanks, I'll verify
<xnox> ahasenack:  postinst will be installed into the main package regardless of whether it has a #DEBHELPER# marker or not.
<ahasenack> xnox: postinst is fine, I was wondering about the others that dpkg-maintscript-helper would need to touch, if they don't exist in the source package
<xnox> ahasenack:  for example people omit that marker on purpose, to prevent from debhelper injecting its snippets, because they are too large / have deps not avialable / are borken / etc.
<xnox> ahasenack: if you create .maintscript it's enough, it is smart.
<ahasenack> nice
<cjwatson> You definitely don't need to add empty files with #DEBHELPER# markers, indeed.
<cjwatson> (Otherwise-empty, I mean)
<ahasenack> that's what I was wondering about, if I had to add the "template" files with #DEBHELPER#
<xnox> ahasenack:  note that postinst is _an override_ / complete replacement.
<xnox> ahasenack:  and #DEBHELPER# is like "but yeah, please ressurect the stock snippets"
<cjwatson> ahasenack: This is documented in debhelper(7) - please read
<xnox> and put them on this line please.
<cjwatson> "Automatic generation of Debian install scripts"
<ahasenack> "If a script does not exist at all and debhelper needs to add something to it, then debhelper will create the complete script." <-- that settles it, thanks
<mwhudson> dpkg-source: warning: source directory 'pam' is not <sourcepackage>-<upstreamversion> 'pam-1.1.8'
 * mwhudson stares
<mwhudson> uh pam really is a native package in bionic?
#ubuntu-devel 2020-07-22
<rbalint> mwhudson, pam is packaged oddy https://salsa.debian.org/vorlon/pam/-/merge_requests/1
<mwhudson> rbalint: huh
<mwhudson> rbalint: it seems unevenly strange as well, i had to poke dpkg-source with a stick to make it behave with the xenial source package
<rbalint> mwhudson, yes, i had the same experience when i had to update the package  :-\
<Laney> how does update-manager get triggered to appear when it needs to?
<Laney> it doesn't appear to be done directly, does some other component poke it?
<Laney> I just want to be able to tickle that trigger manually so I can pretend it was automatic
<Laney> ok update-manager --no-update
<xnox> doko:  tlp should pop up as MIR, let me handle opening MIR ticket for it and subscribing the right people to it.
<seb128> Laney, iirc update-notifier does spawn it
<Laney> yeah
<Laney> merci for the confirmation
<tsimonq2> ddstreet: New shiny: https://launchpad.net/ubuntu/+source/software-properties/0.99.0
<tsimonq2> ddstreet: I followed up on the ML as well.
<tsimonq2> Thank you for writing tests. Unfortunately, one failed. :P
<tsimonq2> I can fix it since it's just pyflakes.
<tsimonq2>  test_pyflakes3_clean (tests.test_pyflakes.TestPyflakesClean) ... ok
<tsimonq2> Sweet.
<rbasak> $ LC_ALL=en_GB.UTF-8 python3 -c 'import locale;print(locale.getlocale(locale.LC_TIME))'
<rbasak> (None, None)
<rbasak> Why? Shouldn't that be ('en_GB', 'UTF-8')?
<rbasak> I'm trying to write an assertion to ensure that LC_TIME is C.UTF-8. Help?
<tsimonq2> rbasak: $ LC_ALL=en_GB.UTF-8 python3 -c 'import locale;print(locale.getlocale())'
<tsimonq2> ('en_GB', 'UTF-8')
<tsimonq2> $ python3 -c 'import locale;print(locale.getlocale())'
<tsimonq2> ('en_US', 'UTF-8')
<tsimonq2> $ LC_ALL=en_GB.UTF-8 python3 -c 'import locale;print(locale.LC_TIME)'
<tsimonq2> 2
<rbasak> tsimonq2: what does '2' mean?
<tsimonq2> rbasak: Very good question. I'm trying to figure that out.
<tsimonq2> https://docs.python.org/3/library/locale.html#locale.LC_TIME says "Locale category for the formatting of time."
<tsimonq2> But where are the categories? Hm.
<rbasak> I get (None, None)
<tsimonq2> print(locale.LC_TIME) =/ print(locale.getlocale(locale.LC_TIME))
<tsimonq2> locale.getlocale() is likely what you're looking for.
<tsimonq2> $ LC_ALL=C.UTF-8 python3 -c 'import locale;print(locale.getlocale())'
<tsimonq2> ('en_US', 'UTF-8')
<tsimonq2> ...oh?
<rbasak> Yeah that happens too
<rbasak> locale.getlocale() won't necessarily tell me about a differently set LC_TIME though
<tsimonq2> I mean, you could just get the env var. :P
<rbasak> I want to assert how Python's datetime.strptime will behave
<rbasak> It seems to me that Python's behaviour will not follow the env var!
<cjwatson> rbasak: You need locale.setlocale(locale.LC_ALL, '') first to enable localisation
<cjwatson> $ LC_ALL=en_GB.UTF-8 python3 -c 'import locale; locale.setlocale(locale.LC_ALL, ""); print(locale.getlocale(locale.LC_TIME))'
<cjwatson> ('en_GB', 'UTF-8')
<Laney> bdmurray: question about teams which can own packages in main - where is that defined? is there just one place?
<cjwatson> (It's the same in C.  Localisation isn't generally switched on until the process has called setlocale(LC_ALL, "").)
<rbasak> cjwatson: thanks, but I tried:
<rbasak> $ LC_ALL=en_GB.UTF-8 python3 -c 'import locale; locale.setlocale(locale.LC_ALL, ''); print(locale.getlocale(locale.LC_TIME))'
<rbasak> (None, None)
<rbasak> I don't see a difference between that and your suggestion
<rbasak> Oh, but yours does work
<rbasak> Ah
<rbasak> Because my quotes were broken
<rbasak> Thanks :)
<bdmurray> Laney: https://bazaar.launchpad.net/~ubuntu-archive/ubuntu-archive-tools/trunk/view/head:/package-subscribers#L116
<rbasak> So in that case, if I want to assert that strptime will behave as if in the C.UTF-8 locale, I can run _only_ locale.getlocale(locale.LC_TIME), right? And if the output is (None, None) OR ('C', 'UTF-8') [that one never seems to happen] OR ('en_US', 'UTF-8') then I'm good?
<rbasak> bryyce: ^
<Laney> bdmurray: sweet
<bdmurray> Laney: did you see https://code.launchpad.net/~brian-murray/britney/britney1-backlog-report-update/+merge/387796?
<Laney> nope
<Laney> lemme see
<Laney> oh my
<Laney> this thing should use the yaml!
<bdmurray> Probably but we are writing zeroes to a KPI right now.
<Laney> yeah, ok, lemme look
<Laney> bdmurray: done, thanks for the nudge
<Laney> I think that should get pulled automatically
<bryyce> rbasak, ah, got it sorted?
<rbasak> bryyce: I think so. I just this moment pushed a replacement branch that I think should be acceptable.
<rbasak> Thanks to Colin for clarifying how it's supposed to work.
<bryyce> rbasak, great, will take a look at the MP
<bryyce> rbasak, MP reviewed
<rbasak> Thanks!
#ubuntu-devel 2020-07-23
<IPv2> kanashiro: Very big thanks again for pointing me in the right direction twice now, with ruby-ncurses SRU, and on the Debian channel. :-)
<kanashiro> you're welcome IPv2 :)
<IPv2> kanashiro: Because package sup-mail is already in bionic and eoan (and will be sync'd to groovy), are we perhaps in scope for an "Other safe cases" SRU for focal? "For Long Term Support releases we sometimes want to introduce new features. They must not change the behaviour on existing installations (e. g. entirely new packages are usually fine)."
<IPv2> https://wiki.ubuntu.com/StableReleaseUpdates#Other_safe_cases
<IPv2> kanashiro: My thinking is that an existing user on (say) bionic, upgrading to focal, would break their existing installation. (Failure to launch sup-mail at run-time after the upgrade to Ruby 2.7)?
<kanashiro> IPv2: after reading this paragraph of the doc I believe we can try to introduce sup-mail in Focal, it should not break anything else
<IPv2> kanashiro: I agree, risk of regressions should be very low, and could dramatically improve user experience on upgrade from an earlier release. Should I file a new bug in the SRU format?
<kanashiro> an opinion from someone in the SRU team would be great
<kanashiro> rbasak: ^
<rbasak> kanashiro: I need more context please
<kanashiro> rbasak: sup-mails is not available in Focal in Focal, IPv2 wants to introduce it via SRU to avoid breakages when sup-mail bionic users upgrade their systems
<kanashiro> s/sup-mails/sup-mail/
<rbasak> What's its status now?
<kanashiro> specially because in Focal we moved to ruby 2.7, so the sup-mail in bionic would not work
<kanashiro> It is fixed in bionic and now it was re-introduced in Debian and back in sync in Groovy
<rbasak> We'd want it well-maintained in Ubuntu to prevent flip-flopping. Looks like it's stuck in proposed.
<kanashiro> IPv2 has been putting some effort on this since he is now one of the upstream maintainers, I believe we can count on him to keep it well maintained, right? :)
<rbasak> I agree it'd be pretty harmless SRU-wise to fix it in Focal, though I'd want to consult with other SRU team members to make a final decision. *However* if the purpose is to avoid users regressing because it is gone in Focal, I think we should also do our best to make sure it will be well-maintained in the future. Otherwise we'd only be deferring the inevitable pain for user later.
<rbasak> So that's what I was going to ask :)
<rbasak> Can we have a commitment to maintain the package in Ubuntu going forwards?
<rbasak> Some track record of that would be nice too.
<rbasak> If we have that, then I'd be supportive of an SRU to Focal, subject to the opinions of other SRU team members and assuming I'm not missing anything.
<kanashiro> IPv2 is now one of the uploaders of sup-mail in Debian
<IPv2> rbasak / kanashiro: I'm one of two new upstream maintainers for Sup. The other upstream maintainer has maintained it for years in Fedora, but is new to upstream. I'm brand new to maintenance in Debian/Ubuntu, but am one of the Debian uploaders now. I'm happy to commit to keep it supported. (I'm a long-term Sup user, over 10 years, and volunteered to pick up the maintenance after I saw it was broken on
<IPv2> Ruby 2.7)
<rbasak> IPv2: thank you for volunteering! We appreciate your help.
<IPv2> rbasak: So short version: yes, I am happy to commit to that. :-)
<rbasak> IPv2: can I suggest that you subscribe to bugs for the package?
<IPv2> rbasak: I will do right now
<rbasak> In that case I'm supportive of your request. Can you file a bug to request the SRU please, and detail the rationale and your commitment etc in here? kanashiro can help you with that as needed.
<rbasak> I will still want to consult with others before making a final decision though.
<rbasak> Also, the package needs fixing in Groovy as it's not in the release pocket yet.
<rbasak> Though it's a very recent upload so maybe that's still in progress?
<IPv2> rbasak: Thank you, I greatly appreciate your help (and kanashiro's). I will file the bug later today. I understand that it's not a final decision.
<kanashiro> rbasak: great, thanks for your input. I can help IPv2 to move this forward
<IPv2> rbasask: Yes - perhaps we should give it a few days then to land in groovy, before filing the SRU bug?
<rbasak> Having a track record of good maintenance would be very helpful
<kanashiro> IPv2: you can start to prepare the SRU bug and when it lands in Groovy we subscribe the SRU team
<rbasak> Normally Ubuntu prefers to see an established team, but I think it's probably proportionately OK here as it's a leaf package and there's no major harm potential by adding it to Focal
<IPv2> kanashiro: Thank you - good idea. Will do. I'm at $DAYJOB just now, but will start to prepare the SRU bug later today (and I'll subscribe you when I do, but not the SRU team at this stage).
<rbasak> Note that you can file a bug now and only ask for it to be looked at later. No reason to delay starting. You can mark a bug "Incomplete" to communicate that you're not ready for it to be looked at yet
<IPv2> rbasak: The Debian maintainer is an established team, and I'm one of two uploaders in Debian now (one very established in Debian). I'll include that when raising. Thank you!
<kanashiro> IPv2: feel free to ping me in case of any doubt
<IPv2> kanashiro: Thank you, I really appreciate all your help.
<kanashiro> you are more than welcome!
<coreycb> hello, please can an archive admin take a look at accepting intervals from the groovy new queue? it's a new dependency for python-sqlalchemy-utils.
<dgadomski> hi bdmurray, could I have your opinion on the patches for https://bugs.launchpad.net/bugs/1881976?
<ubottu> Launchpad bug 1881976 in apport (Ubuntu Focal) "apport-gtk and apport-kde install xiterm+thai as dependency (x-terminal-emulator)" [Medium,In progress]
<bdmurray> dgadomski: I'm in a meeting now but I've opened a tab about it
<dgadomski> thanks, that's nothing super urgent
<bdmurray> xnox: did you test bug 1870813 on groovy?
<ubottu> bug 1870813 in scilab (Ubuntu) "Scilab does not start on focal" [Undecided,Confirmed] https://launchpad.net/bugs/1870813
<xnox> bdmurray:  i search for it in gnome shell, it launches, i can execute help command, and exit command, without crashing. It's "operational" to me, on smoketesting basis in groovy.
<bdmurray> xnox: can you update the bug then?
<rafaeldtinoco> ddstreet: xnox: to which repo should I do a PR for systemd (udev) ?
<rafaeldtinoco> want to reword a patch for groovy to backport as SRU to focal/bionic
<rafaeldtinoco> or should I just go ahead and dput the change as its small ?
<rafaeldtinoco> rbalint: ^ might be the right person to ask
<rafaeldtinoco> nm, ill dput it, its faster =)
<bdmurray> juliank: How is Ubuntu.mirrors from python-apt-common used?
<bdmurray> juliank: I think I've sorted it out
<juliank> bdmurray: software properties mirror selection
<bdmurray> juliank: yeah, that's what I remembered
<xnox> bdmurray:  done.
<xnox> rafaeldtinoco:  whatever is in Vcs- header of the source package. It is something like lp:~ubuntu-core-dev/ubuntu/+source/systemd maybe?
<rafaeldtinoco> https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd
<rafaeldtinoco> tku
<xnox> i guessed right! win!
<sarnold> ooh ooh! what's your prize?
#ubuntu-devel 2020-07-24
<xnox> FTBFS on riscv64 of vim
 * xnox hates this raffle
<mwhudson> so what's keeping popcon in main
<cjwatson> So we occasionally get people turning up on #launchpad and similar who are trying to follow the Ubuntu packaging guide in order to prepare uploads to PPAs, and getting horribly confused because the packaging guide (packaging.ubuntu.com) is now really quite obsolete and in many places plain doesn't work, mainly due to referring to old bzr stuff that has been gently bitrotting for years.
<cjwatson> This is a support problem for us.  Who can fix it?
<xnox> cjwatson:  rick_h maybe?
#ubuntu-devel 2020-07-25
<melodie> hello
<melodie> I would like to have an Ubuntu devel's insight on the way the languages are provided at the boot of a live CD
<melodie> or live ISO or live USBâ¦
<melodie> I am trying to put up a remix with Openbox standalone (Bento Openbox), and once my remix is working, the languages at start don't work right anymore. I have tried many things to try to find where the issue lies, in vain
<melodie> once I choose French, only the two last lines of the boot stanzas are in French, the first other lines are in English.
<melodie> There is another thing too, the Desktop environment is using Openbox, PCManFM, and Lxpanel. (Sounds like Lubuntu but it's not Lubuntu)
<melodie> well, the install icon on the desktop prompts a windows to choose wether it should be executed, shown as a file, executed in a terminal or cancel. Also here I was unable to find what is going wrong. Rights and permissions are the same as in the official and community versions, and if I add a chmod a+x on the file it does not change the behavior (even when doing so in /usr/share/applications before rebuilding)
<melodie> I'll stay a while, if someone has clues for one or the other of my 2 issues to submit, I will be most happy
<melodie> if someone wants to give it a try it's "Bento Openbox Core" here: https://downloads.linuxvillage.org (less than 800MB)
<melodie> ok, I'll come back soon.
<melodie> during the week might be better
