[09:59] <lool> I merged kexec-tools with Debian
[10:00] <ogra> nice !
[10:00] <ogra> but it still doesnt work ?
[10:00] <ogra> (on arm)
[10:03] <lool> ogra: It still hangs when you try to kexec within qemu/versatile
[10:03] <lool> The Debian merge was mostly packaging stuff
[10:04] <persia> The packaging is sane again?
[10:05] <lool> Yes
[10:05] <lool> The Ubuntu diff is absolutely bearable
[10:06] <lool> We mostly disable kexec on boot by default and add kdump
[10:06] <lool> Too bad I didn't notice there is a kernel.ubuntu.com/git kexec-tools git tree, but it has its own issues anyway
[10:07] <persia> I suspect it's from that tree that last week's tests were executed.
[10:07] <lool> I mailed cooloney on the kexec issue; I hope he can help us there, it's too low level for me
[10:08] <persia> Probably best to coordinate with ericm_ and NCommander to make sure everyone is testing the same source.
[10:08] <persia> I thought ericm was doing most of that, but cooloney may also be able to help.
[10:08] <lool> persia: The tree has the same issues as lucid, it's out of date by one upload before my work and just misses the kdump init script
[10:08] <lool> I rather suspect NCommander took Debian's or upstream's kexec-tools
[10:08] <persia> Quite possibly.
[10:12] <lool> I wonder whether ericm can be bothered for versatile kexec
[10:12] <persia> lool: Did you ever get anywhere with the pbuilder-dist changes to do better detection of when to use the alternate debootstrap?  Should I track down some other python person?
[10:12] <lool> I didn't attack that
[10:12] <persia> I suspect that getting versatile kexec working would be a good step towards getting it working anywhere else.
[10:12] <lool> My real plan is to remove the need for pbuilder-dist altogether, but that's a longer term effort
[10:12] <persia> No worries then.  I'll try to find someone else.
[10:13] <lool> If you remind me of everything we agreed to do, I can certainly do it
[10:13] <persia> I have a solution to drop pbuilder-dist: migrate to schroot/sbuild :)
[10:13] <lool> Eh
[10:13] <lool> schroot/sbuild doesn't have cowdancer though; it does have LVM snapshot, but it's a bit different
[10:13] <persia> You didn't like me using the architecture to determine when to use the emulator: you seemed to prefer to do host/guest arch compat comparison.
[10:13] <persia> schroot *does* have COW now, in 1.4, although I haven't quite figured out how to get it working.
[10:14] <persia> It's on my list to try to get schroot to work with pbuilder-style tarballs, COW, etc. in the next few months (although I'm not sure I can release with lucid)
[10:14] <lool> I don't see that; are you sure you don't mean LVM COW?
[10:14] <persia> I am.
[10:14] <lool> persia: I don't see this in /usr/share/doc/schroot/NEWS.gz though; let me check sbuild
[10:15] <lool> I don't see it in sbuild's NEWS either
[10:15] <lool> persia: Do you have any name/reference for the feature?
[10:15] <persia> "Support for union filesystems has been added ... loopback chroots with a temporary writable overlay ...".  It's not quite COW, but should have similar performance.
[10:16] <persia> Quote is from sbuild's NEWS.gz
[10:16] <lool> Ah but that's not in lucid?
[10:17] <persia> Yes it is :)
[10:17] <lool> I was checking lucid files
[10:17] <persia> So was I.  Check item 8) in NEWS for 1.3.0-rc1
[10:17] <lool> Why don't I see union in NEWS.Debian and NEWS??
[10:17] <lool> sbuild doesn't have 1.3.0-rc1
[10:17] <persia> Err, sorry.  From *schroot* NEWS.gz
[10:17] <persia> sbuild is just a build script that runs against schroots.
[10:17] <lool> Ack I see it now
[10:18] <cooloney> lool: yeah, i'm looking at that.
[10:18] <lool> Using union fses is much cleaner than pbuilder's approach
[10:18] <cooloney> persia: ericm_ made it kexec works on dove, IIRC.
[10:18] <lool> cooloney: let me know if you need any help with the setup
[10:18] <persia> lool: And `sudo pbuilder` is just pointless escalation.  schroot's selective mechanism is much richer.
[10:18] <cooloney> persia: he will help me about this
[10:19] <lool> persia: Tell me about it
[10:19] <persia> cooloney: I thought it kinda worked, but then crashed on the call, but I may be mistaken.  Great to hear you guys will be working together on this.
[10:19] <cooloney> lool: yeah, do you know where can I download the rootfs for testing
[10:19] <lool> cooloney: Best to create your own; it's quite easy
[10:19] <persia> cooloney: Use rootstock to generate one :)
[10:20] <lool> I still call debootstrap by hand, but the recommended tool is probably rootstock or just build-arm-chroot
[10:20] <cooloney> persia: yeah, since imx51 also has some issue about kexec, i need to work on that as well as versatile
[10:20] <lool> rootstock will setup misc configs for you, hostname, passwords and the like
[10:20] <persia> Definitely rootstock.  It does a lot of the installer bits that build-arm-chroot skips, like user creation, etc.
[10:20] <persia> (which don't belong in build-arm-chroot, really)
[10:20] <cooloney> lool: oh, it is very slow for me to download the evironment. i tried rookstock before. heh
[10:21] <lool> cooloney: You don't have a mirror nearby?
[10:21] <ogra> cooloney, kexec didnt work on friday when NCommander tried it though that might be because kexec-tools was broken
[10:21] <lool> cooloney: I can back you my rootfs if you like, hold on
[10:21] <cooloney> lool: can i try common local ubuntu mirror for that?
[10:22] <cooloney> lool: yeah, i love that. hehe
[10:22] <lool> cooloney: You need a ports mirror sadly
[10:22] <cooloney> ogra: yeah, ericm_ mention that before.
[10:22] <lool> cooloney: What I recommend is that you use squid as a caching proxy
[10:22] <lool> If the .debs don't change too often, nost of the debootstrap bits will be cached in there
[10:22] <cooloney> lool: i guess there is no such ports mirror in China.
[10:23] <ogra> cooloney, use approx on your local machine
[10:23] <lool> cooloney: squid-deb-proxy is a package which will setup squid to that effect
[10:23] <cooloney> lool: great, is there any wiki for such setup?
[10:23] <ogra> then you at least only have to download once
[10:23] <lool> cooloney: Then you just need to set http_proxy in /etc/environment and you're done
[10:23] <lool> cooloney: squid-deb-proxy might have some doc
[10:23] <ogra> or as lool said
[10:23] <lool> cooloney: I'm scp-ing my rootfs, but will take a while
[10:23] <cooloney> lool: got you
[10:24] <ogra> approx needs no setup though ... you just point to your local IP
[10:24] <ogra> on port 9999
[10:24] <cooloney> lool: thanks a lot, if it is done, just email me
[10:24] <cooloney> ogra: right, i think i tried approx before. any wiki about that?
[10:25] <cooloney> lool: email me the url, heh
[10:25] <lool> cooloney: URL will be http://people.canonical.com/~lool/rootfs.img
[10:25] <lool> but not finished yet
[10:26] <ogra> cooloney, apt-get install approx ... then use -mirror http://<your local IP>:9999/ubuntu-ports in your scripts (or set http_proxy to <your local IP>:9999)
[10:26] <ogra> i use it with rootstock all the time to speed up my testbuilding
[10:27]  * lool simply has a local mirror
[10:27] <persia> A local mirror tends to be the easiest way to deal with limited bandwidth, but does require a bit more hardware.
[10:27]  * ogra thinks lool is a rich man who can waste useful diskspace
[10:28]  * lool thinks his time is more valuable than hardware
[10:28] <ogra> with a disk that costs €20/GB i really dont like to waste it
[10:29] <lool> 20 EUR/GB?  are these made of gold?
[10:29] <ogra> well, i rarely need most of the packages from the mirror ... so just caching the ones i use over and over makes a lot more sense
[10:29] <cooloney> OMG, you guys all have local mirror?
[10:29] <ogra> lool, no, of super speedy flash :)
[10:29] <lool> https://www.materiel.net/ctl/Disques_durs_internes_SATA/46461-Barracuda_7200_12_S_ATA_1000_Go_32_Mo.html
[10:29] <cooloney> so normally, how big disk is enough for setup a  mirror?
[10:30] <ogra> cooloney, nope, as i said above, i think a local mirror is a waste of diskspace
[10:30] <cooloney> ogra: apparently, you don't have, heh
[10:30] <cooloney> ogra: you got faest speed maybe. heh
[10:30] <lool> That's .075790 EUR/GB  :)
[10:31] <ogra> a local proxy will only cache what i need, a local mirror copies the whole archive
[10:31] <cooloney> ogra: right.
[10:31] <ogra> lool, does it boot in 8sec ? :P
[10:31] <lool> ogra: That only works if you always the same stuff
[10:31] <cooloney> but lool doesn't care about that
[10:31] <lool> ogra: Actually about that yes
[10:31] <ogra> indeed, its perfect for image builds
[10:31] <lool> Because it's in RAID10 and doesn't start the desktop
[10:31] <ogra> haha
[10:31] <ogra> cheater
[10:32] <ogra> lool, http://people.canonical.com/~ogra/osiris-lucid-20100202-6.png :P
[10:32] <ogra> and thats a slow boot ... i usually have around 230MB/s
[10:33] <persia> Stop wagging :p
[10:33] <cooloney> lool: how big is your rootfs? heh
[10:33] <lool> ogra: Err you know I have SSD on my laptop since a year and a half?
[10:33] <cooloney> lool: 1G?
[10:33] <lool> Plus mine is bigger than yours
[10:34] <ogra> lool, yeah, as i said, youre a rich man ... i'm a poor german, cant spend on wine for lunch :P
[10:34] <cooloney> ogra: lol
[10:34] <lool> Just don't try teasing me!
[10:50] <lool> cooloney: Done uploading
[10:50] <lool> cooloney: There isn't much free space, you can grow the rootfs by appending some zeroes to the file and growing with ext2resize
[11:11] <ogra> lool, was it you who added the if [ ! -f /usr/share/debootstrap/scripts/$DIST ];then check to rootstock ?
[11:12]  * ogra cant remember from where that got merged, but it seems silly to additionally keep the version check code
[11:12]  * persia suggests `bzr blame ...`
[11:12] <ogra> persia, bah, trying to kill my lazyness ?
[11:13] <persia> Every day, in every way :)
[11:13] <lool> 23     ogra@ub | if [ ! -f /usr/share/debootstrap/scripts/$DIST ];then
[11:13] <ogra> hrm
[11:13] <lool> committer: Oliver Grawert<EMAIL_ADDRESS>[11:13] <lool>   add a check if debootstrap supports $DIST, thanks to Erik Corry<EMAIL_ADDRESS>for the fix !
[11:13] <ogra> oh, k
[11:13] <ogra> i think i got that one by mail
[11:14] <ogra> adn i think i'll just kill all the silly version checking then
[11:16] <lool> ogra: This check doesn't seem too bad though, what's the issue with it?
[11:16] <ogra> lool, nothing apart from bloating the code if we check for /usr/share/debootstrap/scripts/$DIST anyway
[11:17] <ogra> its kind of a duplication imho
[11:17] <lool> ogra: Where do you do that?  in build-arm-chroot?
[11:17] <ogra> rootstock
[11:17] <lool> So where is it duplicated?
[11:17] <ogra> if $(dpkg --compare-versions $DBSV lt $DEBOOTSTRAP_MIN_VER);then
[11:17] <ogra> vs
[11:18] <ogra>  if [ ! -f /usr/share/debootstrap/scripts/$DIST ];then
[11:18] <lool> The version check is the one I'd drop
[11:18] <ogra> right, thats what i said :)
[11:18] <lool> The data-driven check seems more future proof than a version requirement which will be out of date every release
[11:18] <ogra> right
[11:25]  * ogra -> break
[12:02] <cooloney> lool: i am downloading now.
[12:03] <cooloney> lool: it is 300M, need I append some zeroes? I don't understand heh
[12:06] <ogra> its an img not a rootfs
[12:06] <ogra> so to have more space on it you need to make it bigger by adding zero byte blocks and resize the partition
[12:07] <cooloney> ogra: got you. so normally how to do that : adding zero?
[12:07] <ogra> use dd
[12:16] <cooloney> ogra: dd conv=notrunc oflag=append if=/dev/zero of=rootfs.img bs=1M count=1024
[12:17] <cooloney> ogra: is this kind of command, right? add 1G zeroes at end of rootfs.img
[12:19] <ogra> cooloney, hmm, never used append, but if it does the same as skip and seek that should work
[12:19] <ogra> best to try it on a copy of the image i guess :)
[12:20] <cooloney> ogra: heh, right. hehe
[13:11] <lool> cooloney: That seems about right
[13:11] <lool> cooloney: Or just dd if=/dev/zero bs=something count=something >> rootfs.img
[13:12]  * ogra guesses cooloney would already have shouted and cired if it hadnt worked :)
[13:12] <ogra> *cried
[13:12] <lool> ogra: But it's actually a rootfs
[13:12] <lool> It's just that most people say rootfs when they mean rootfs tarball
[13:15] <ogra> well, one is an imag the other is the content of a filesystem
[13:15] <ogra> neither is named right anyway :)
[13:15] <ogra> since neither is actually a filesystem per se
[13:26] <lool> the rootfs.img is a filesystem
[13:26] <lool> i.e. root file system
[13:41] <lool> asac: is bug #474322 on your radar?
[13:41] <ubot4> Launchpad bug 474322 in linux-fsl-imx51 (Ubuntu Jaunty) (and 1 other project) "linux-image-2.6.28-16-imx51 appears broken on armel (affects: 1)" [Critical,Triaged] https://launchpad.net/bugs/474322
[13:41] <lool> it's from November and is a regression in a security update of the kernel in jaunty
[13:44] <lool> rcn-ee: Re: your qemu-arm-static -> qemu-kvm-extras-static issues: this should be fixed in latest versions
[13:44] <lool> rcn-ee: let me know if it isn't
[13:46] <lool> rcn-ee: Do you have a place where you publish your daily rootstock build logs, or is http://rcn-ee.homeip.net:81/dl/rootstock/ just updated manually?
[13:46] <lool> I wonder whether we should publish daily built rootfs like the UEC images
[13:47] <lool> I wonder why devtmpfs breaks for you
[13:49] <persia> rcn-ee: Regarding the "fixed" statement above, note that setuid binaries still won't work, but this is an inevitable consequence of how the emulation is done.
[13:51] <apw> ogra, lool, i've built some kernel .deb's for lool's versatile configuration changes, want to get some testing on them before i upload them; see the 13.18 kernels here: http://people.canonical.com/~apw/misc/arm/
[13:52] <ogra> apw, will test soon, thanks a lot
[14:00] <lool> apw: Tested with serial console, works fine up to a console login prompt
[14:03] <asac> cooloney: can you check the bug lool mentioned?
[14:03] <asac> 474322
[14:03] <asac> that is
[14:04] <asac> cooloney: seems it stopped working on bbg1 after security update... thanks!
[14:05] <lool> apw: Checking with graphics now (vga/fb video output)
[14:06] <lool> apw: Boots fine; NB: I just extracted the vmlinuz file and usese that
[14:06] <apw> ok
[14:07] <lool> apw: I don't think it's a regression, but I can't actually poweroff/reboot the system
[14:07] <rcn-ee> lool, yeap it looks fixed... (worked friday night when i was testing things for ogra)...  For reference my 'nightly' builds are here.. http://rcn-ee.homeip.net:81/dl/daily/ubuntu-lucid.log  i need to do a bzr pull thou, it's karmic + lucid tweak...
[14:07] <lool> The userspace bits seem to happen fine, but it doesn't actually reboot/stop
[14:07] <ogra> i think reboot never worked
[14:07] <ogra> at least with the archive kernels
[14:08] <persia> Is this an issue with qemu, or with the kernel?
[14:08] <apw> ok .. i guess i am trying to ensure its not a regressing kernel for you guys
[14:08] <lool> persia: I don't know, and it's a case where it's hard for me to tell
[14:08] <lool> I do see "Restarting" on the console, and then nothing happens
[14:08] <ogra> ah, no shutdown never worked for me ...
[14:08] <cooloney> asac: no problem, but I need to setup my bb1 board tomorrow.
[14:08] <lool> apw: I really don't think it's a regression, but I never paid attention
[14:08] <lool> apw: The current archive kernel doesn't work at all, so... :)
[14:09] <ogra> its very likely not a regression
[14:09] <apw> thats fine with me, as long as ogra is happy i'll call it good
[14:09] <ogra> apw, just upload, if it works for lool it will surely work for me too (i use way less features)
[14:10]  * ogra only needs ext2/NIC and serial console
[14:12] <ogra> lool,  rm /bin/installer && reboot -fp ... thats in rootstock since day one ... i wouldnt have used -f if it would power doen properly
[14:12] <ogra> *down
[14:13] <ogra> not clear though if its qemu ...
[14:32] <ogra> weird, i cant get it to boot
[14:32] <ogra> it works if i dont use serial
[14:32] <ogra> apw, lool ^^^
[14:33]  * apw puts those changes on one side
[14:34] <ogra> hrm
[14:34] <ogra> if i add mem=256M to the append line it works
[14:37] <ogra> weird
[14:39] <persia> So it just can't handle much memory?  I thiought there was a patch for 512M (and seem to remember fiddling with it in jaunty)
[14:39] <ogra> no, its not that, i copied another append line that differs in ro vs rw and mem=256M
[14:40] <ogra> its not the mem but the ro/rw
[14:40] <ogra> it boots fine with ro
[14:40] <persia> Aha.
[14:40] <ogra> but not with rw
[14:40] <persia> Very odd.
[14:40] <ogra> apw, i can work around that in the script
[14:40] <ogra> so please upload
[14:40] <ogra> yes, odd indeed
[14:40] <apw> hrm, ok i suppose
[14:40] <lool> ogra: How much memory are you using?
[14:40] <ogra> lool, 256M
[14:40] <ogra> but see above
[14:41] <ogra> its not that
[14:41] <lool> That works for me without mem=
[14:41] <ogra> it seems it cant boot with rw on the cmdline
[14:41] <lool> qemu-system-arm -m 256  -drive file=rootfs.img,media=disk -M versatilepb -cpu cortex-a8 -kernel vmlinuz-2.6.32-13-versatile -append 'rootwait root=/dev/sda 2' is what I use
[14:41]  * ogra tries with dropping ro/rw completely
[14:42] <ogra> [    5.451770] VFS: Mounted root (ext2 filesystem) readonly on device 8:0.
[14:42] <ogra> ok, it defaults to ro
[14:42] <ogra> lool, does it boot if you add rw ?
[14:42] <lool> Yes
[14:42] <ogra> for me it panics with "cant find rootfs"
[14:42] <lool> It works fine here
[14:43]  * ogra tries rootwait, probably a race
[14:43] <lool> Err yes if you don't have a large rootdelay or rootwait it wont find your rootfs in time
[14:43] <lool> the scsi disk typically appears a couple of seconds after the kernel tries mounting the rootfs
[14:44] <ogra> [    5.430661] VFS: Cannot open root device "sda" or unknown-block(8,0)
[14:44] <ogra> [    5.430938] Please append a correct "root=" boot option; here are the available partitions:
[14:44] <ogra> nope
[14:44] <ogra> i usually dont need rootwait or anything ... never did
[14:45] <ogra> qemu-system-arm -M versatilepb -cpu cortex-a8 -kernel tmp/boot/vmlinuz-2.6.32-13-versatile -hda /var/build/qemu-armel-201002081506.img -m 256 -nographic -append "console=ttyAMA0,115200n8 root=/dev/sda rootwait rw"
[14:45] <ogra> doesnt work
[14:45] <ogra> exactly the same line but dropping rw works
[14:46] <ogra> lool, can you try adding rw ?
[14:46] <lool> ogra: I already did
[14:47] <ogra> hmm
[14:47] <ogra> i wonder why it reliably breaks here
[14:47] <lool> Do you actually have read/write on /var/build/qemu-armel-201002081506.img?
[14:47] <ogra> heh
[14:47] <ogra> no, indeed
[14:47] <lool> pfff
[14:47]  * ogra re-adds the sudo bit to the README ...
[14:47] <lool> You don't need sudo to run qemu-system-arm
[14:47] <lool> Just move your images to your home
[14:48] <ogra> i just removed that from the rootstock doc ... now i remember again why i added it
[14:48] <lool> Advising sudo is actually dangerous
[14:48] <ogra> well, the image is created  as root
[14:48] <ogra> so owned by root
[14:48] <lool> Well you don't need to
[14:48] <lool> You just need to mount the file as root and run debootstrap as root, but you don't need to dd the file as root
[14:48] <ogra> i do
[14:49] <lool> Look, I just created this file as user
[14:49] <lool> And it worked
[14:49] <ogra> yes, but you dont use it loop mounted until you finished
[14:49] <lool> I sudo loop mount it
[14:49] <ogra> it is loop mounted during rootstock
[14:49] <lool> Yes, so $sudo loop mount it
[14:49] <ogra> hrm
[14:49] <lool> Here's an example script I use http://paste.ubuntu.com/371731/
[14:50] <lool> You can run it as root or not, it will call sudo when it needs to
[14:50] <ogra> thats ugly because i will pop passwd prompts all the time
[14:50] <persia> Actually, one should put a check on that class of script to fail if run as root (see mk-sbuild-lv for a nice check)
[14:50] <lool> There is some caching, so it will only prompt if it's too late; you can workaround that with a helper
[14:50]  * ogra sighs
[14:50] <lool> persia: That's an option; you can easily flip the check
[14:51] <ogra> i will not stop running the script as root
[14:51] <ogra> i want it to run automated if needed
[14:51] <lool> ogra: So run qemu-system-arm as root then, but don't advise people to do so by default
[14:51] <lool> ogra: So how are you going to automate running your script as root?
[14:51] <ogra> yeah, i'll add inof the the doc
[14:52] <ogra> i dont, users do
[14:52] <ogra> and they usually set up root cronjobs
[14:52] <ogra> i'll just add info to the doc ... i wont scatter sudo calls across the script
[14:59] <lool> did you actually read the link?
[14:59] <lool> it doesn't call sudo if called as root...
[15:01] <ogra> i have the very same check in rootstock ... just not the $sudo var
[15:02]  * ogra curses about broken userspace
[15:02] <ogra>  * Starting init crypto disks...                                         [ OK ]
[15:02] <ogra> hangs :(
[15:02] <ogra> silly ubiquity -> oem-config merge
[15:03] <ogra> pulls in half the world and breaks ... old oem-config worked
[15:03] <ogra> and didnt pull in many deps
[15:05] <ogra> if [ $(id -u) != 0 ];then
[15:05] <ogra>     echo "must be run as root"
[15:05] <ogra>     exit 2
[15:05] <ogra> fi
[15:05] <ogra> lool, ^^^ fyi
[15:53] <ogra> bah, so oem-config goes into an endless loop on my rootstock image
[17:41] <ogra> i think we need to forget about oem-config usage in rootstock thats way to messed up and only focused on d-i installs it seems
[17:41] <ogra> s/d-i/d-i or ubiquity/
[17:42] <ogra> the ui requires metacity which in turn pulls in 400M of deps
[17:42] <ogra> the debconf frontend doesnt finish and goes into an endless loop
[17:46] <ogra> ah, well, without recommends its less but still 30MB
[17:51] <cwillu_at_work> rcn-ee, had disk transfers running over the weekend on that kernel, no random usb reconnects or errors that I can see
[17:51] <cwillu_at_work> rcn-ee, i.e., looks great :)
[18:28] <ogra> lool, hmm, did you try running any X programs in qemu yet ?
[18:28] <ogra> specifically pygtk stuff
[18:28] <ogra> seems to fail pretty badly here
[18:31] <ogra> ugh, even metacity
[18:47] <ogra> i dont think its actually happy with the faked cortex-a8
[18:53] <ogra> hmm, cpuinfo thinks its capable of thumb and neon
[19:00]  * ogra calls it a day
[22:25] <lool> persia: According to linux/Documentation/binfmt_misc.txt, one can set a flag to preserve the original security bits of a program
[22:25] <lool> persia: It changes the calling convention though, so I don't think it would work with out current qemu-system-arm
[22:25] <persia> lool: Cool!
[22:26] <persia> Aha.
[22:38] <persia> lool: Reading the docs, I'm not sure I understand why we can't just pass the 'C' flag and have it work.
[22:38] <lool> persia: Because it doesn't pass a real file to the qemu-arm command-line
[22:38] <persia> It is because of the implied 'O'?
[22:39] <lool> persia: Currently, when the binfmt hook is triggered for e.g. /bin/sh, what happens is that the kernel calls qemu-arm /bin/sh
[22:39] <lool> persia: Yes
[22:39] <persia> Ah, so we'd need to modify qemu-arm-static to take file descriptors rather than file names.
[22:40] <lool> Yes
[22:40] <lool> Or have a wrapper
[22:41] <persia> A wrapper can do FD -> path changes?
[22:42] <persia> That's more shell than I know, or do you mean a compiled wrapper?
[22:50] <persia> lool: Reading the docs more carefully, I think we do want to change the calling convention.  I can well imagine cases where a user wants to execute a file to which that user doesn't have read access when dealing with nested chroots, etc.
[22:51] <persia> But I'm entirely unsure how to do that with a wrapper: I suspect it needs changes to qemu-arm-static itself.  I'd appreciate any pointers if you have them.
[22:57] <lool> persia: I'm trying to write such a wrapper, but I fail miserably
[22:58] <lool> When trying to run my x86-64 static wrapper under an armel chroot I get: Error -8 while loading /usr/bin/qemu-arm-static
[22:59] <lool> persia: I think we would just need a wrapper which passes /dev/fd/N to qemu-system-arm, but I'm not sure; that's what I wanted to verify
[22:59] <lool> But in the end we would likely patch qemu
[23:00] <persia> I thought that /dev/fd/N was defined on a per-process basis.
[23:00] <lool> It is  :-)
[23:01] <persia> In that case, we can't pass it to a new process :)
[23:01] <persia> So a qemu patch *is* required.
[23:01] <lool> persia: exec is the same process
[23:01] <lool> I think my exec doesn't work because it needs to be handled by binfmt
[23:02] <persia> Hrm?
[23:03] <lool> persia: exec() is implemented with binfmt, if my wrapper called from binfmt tries to exec it wont work (well that's my guess)
[23:03] <lool> not sure it's correct
[23:04] <lool> Another static utility which just puts() argv / argc works, so it's not my build
[23:04]  * lool will check this out tomorrow &
[23:04] <persia> Have a good night :)


[12:14] <shailangsa> anybody know why the repo init command is giving permission denied when following the steps from http://whereisdarran.com/2019/07/how-to-build-twrp-for-the-tb-8504x-f/ , the error can be seen here https://pastebin.com/7MycejfM ?
[14:54] <znf> Still struggling with that DVB-C card
[14:55] <znf> I had someone test for power today, the boards are getting power
[14:55] <znf> It's just the driver not wanting to do... anything


[08:29] <didrocks> hi folks :)
[08:29] <mvo> hey didrocks
[08:29] <mvo> hey huats
[08:29] <didrocks> hi mvo
[08:30] <seb128> lut didrocks huats
[08:30] <seb128> hey mvo
[08:30] <didrocks> plop seb128 ;)
[08:30] <mvo> seb128: I have a very strange issue wihen I login via gdm in latest jaunty, my mouse is broken, can left click on anything. but when I kill gdm and just run startx everything is normal? it could be my HW, but I suspect its something else
[08:30] <huats> hey seb128 and mvo
[08:30] <huats> morning everyone
[08:32] <seb128> mvo: the mouse is broken on the gdm screen or in your session?
[08:32] <mvo> in the session
[08:32] <mvo> I think its fine in gdm
[08:32] <seb128> weird
[08:32] <mvo> but i need to verify, I never use it there
[08:33] <seb128> since GNOME didn't change recently I would tend to blame xorg rather than GNOME
[08:33] <mvo> it seems to be happening after something is loaded
[08:33] <mvo> right
[08:33] <mvo> I only recently upgraded this machine
[08:33] <seb128> any mouse error in Xorg.0.log?
[08:33] <seb128> you can move the mouse pointer and right click?
[08:33] <mvo> I can move the pointer, haven't tried right click
[08:34] <mvo> I will do that soonish (after applying todays updates and reboot) :)
[08:34] <mvo> thanks!
[08:35] <didrocks> seb128: I tried to work on bit on gnome-games' package and I have two question
[08:35] <seb128> didrocks: tried a bit? that's not enough ;-)
[08:36] <didrocks> ;-)
[08:36] <seb128> just ask ;-)
[08:36] <didrocks> seb128: the libtool version is not bumped to the right version, even in jaunty (I just realized it after pbuilder login, apt-get install build-dep... :( and tried to autoreconf..)
[08:36] <didrocks> http://paste.ubuntu.com/105460/
[08:37] <didrocks> so, I have to update the libtool for it, I think
[08:37] <seb128> didrocks: ?
[08:37] <seb128> didrocks: do you are an autoconf patch?
[08:37] <seb128> have
[08:37] <didrocks> yes
[08:37] <didrocks> and generate it
[08:37] <seb128> that means you didn't do it correctly
[08:37] <didrocks> hum
[08:37] <seb128> try running autoreconf rather to update it
[08:38] <didrocks> so, what I do is the following:
[08:38] <didrocks> apply the patch to the configure.in (with the right patch system)
[08:38] <didrocks> then "autoreconf -i --force"
[08:38] <didrocks> and generate the new patch against ./configure
[08:39] <seb128> Keybuk: hey
[08:39] <seb128> Keybuk: do you have some clue about what to do when running into a such error, I got that recently on a package too I think and autoreconf didn't solve it either
[08:39] <didrocks> (and I also tried, in the case, to remove aclocal.m4, as I had no trace of change against it, but it is regenerate)
[08:39] <seb128> didrocks: Keybuk knows about libtool so he might be helpful there
[08:39] <didrocks> great, will wait for him
[08:40] <didrocks> but you see nothing's wrong with this procedure?
[08:40] <didrocks> nothing*
[08:41] <seb128> didrocks: no, autoreconf should be updating everything that needs to be updated
[08:41] <seb128> didrocks: what do you call against configure? you need to get the changes for all the files autoreconf updates
[08:42] <didrocks> seb128: ok, will see Keybuk's hints so
[08:42] <seb128> if the package is using quilt that's the suck, either do a find . and quilt add everything or update the patch using some other way
[08:43] <didrocks> seb128: that's what I did (and yeah, it is using quilt). I think I have missed nothing
[08:43] <didrocks> (and it is shouting at aclocal.m4, which I remember, I have explicitely "quilt add" it)
[08:47] <didrocks> seb128: my second question was to activate or not cluttering
[08:47] <didrocks> from NEWS file:
[08:47] <didrocks> Therefore, at this time, we recommend that clutter only be enabled by default
[08:48] <didrocks> by distributors that ensure that OpenGL acceleration is working for hardware
[08:48] <didrocks> from the three major vendors: Intel, NVidia and ATI.
[08:48] <didrocks> but we are not sure that OpenGL acceleration is activated on the final user desktop
[08:48] <didrocks> so, I think we don't have to activate it
[08:48] <seb128> don't no
[08:49] <seb128> we don't have lot of CD space to waste anyway
[08:49] <seb128> let's wait for upstream to stabilize that before using it in ubuntu
[08:49] <didrocks> seb128: we agree, but I prefer to have your ack :)
[09:25] <Keybuk> yeah
[09:25] <Keybuk> that error is because you used --force
[09:28] <seb128> Keybuk: shouldn't autoreconf update everything when you use the force option?
[09:38] <Keybuk> yes
[09:38] <Keybuk> except it won't downgrade aclocal files
[09:38] <Keybuk> (because it can't)
[09:39] <seb128> ah
[09:39] <Keybuk> you generally don't want --force
[09:39] <Keybuk> that would have not downgraded libtool
[09:39] <seb128> Keybuk: you could perhaps update libtool to 2.2.6 to avoid such issues? ;-)
[09:39] <Keybuk> (without that)
[09:39] <Keybuk> yes, I should
[09:39] <seb128> that's what debian experimental has
[09:39] <seb128> and those tarballs are rolled on debian experience install apparently
[09:40] <seb128> experience -> experimental
[09:40] <didrocks> Keybuk: so, why I still have this issue when I rm aclocal.m4 ?
[09:41] <didrocks> (aclocal.m4 is then generated)
[09:41] <didrocks> sorry, I must admit my knowledge in autoconf tools are quite limited :/
[09:43] <Keybuk> didrocks: does the package have an m4 directory?
[09:43] <Keybuk> (ie. are the contents of aclocal just include lines)
[09:43] <didrocks> Keybuk: can't look at the aclocal file right now, but yeah, there is an m4 directory
[09:44] <Keybuk> you'd need to remove the files from there too
[09:44] <didrocks> so, while libtool is not update. I have to rm this directory as --force will not downgrade them?
[09:44] <didrocks> ok, right :)
[09:44] <didrocks> thanks a lot!
[09:45] <didrocks> (oh, without the "!", I learnt some days ago, it was rude in English ;))
[09:45] <seb128> I doubt that will work correctly
[09:45] <didrocks> seb128: you think that the new configure.in is dependant of the new libtool version?
[09:45] <didrocks> dependent*
[09:45] <seb128> no, but the m4 directory is not only autotools files, it has some specific macros defined there
[09:46] <Keybuk> yeah, you need to only rm specific ones
[09:46] <seb128> the easier way is really to get Keybuk to do the libtool update and use that version ;-)
[09:46] <didrocks> ok, will give it a try. But if I can help to update libtool package...
[09:47] <didrocks> seb128: you're right, less work for me :)
[09:47] <seb128> ok, I'm away for half an hour, bbl
[10:15] <Keybuk> new libtool uploaded
[10:19] <seb128> Keybuk: thanks
[10:33] <didrocks> Keybuk: thanks :)
[10:34] <didrocks> seb128: so, I have some work to do this week-end :) I am pretty confident with the new libtool version now
[10:34] <seb128> didrocks: ok good ;-)
[11:37] <mpt> ArneGoetje, I've updated the mockups in <https://wiki.ubuntu.com/JauntyLanguageSelectorImprovements> and specified the behavior details.
[11:44] <mpt> ArneGoetje, I don't see a spec for the font settings anywhere
[17:48] <mpt> asac, rickspencer32: Do 3G connections have signal strength in the same way wireless connections do?
[17:56] <rickspencer32> mpt: not that I can see
[17:56] <rickspencer32> mpt: http://theravingrick.blogspot.com/2009/01/ubuntu-rocks-mobile-broadband.html
[18:07] <Nafallo> haha. I'm SO going to plug in my parents 3G dongle and show them why they are wrong.
[18:12] <rickspencer32> Nafallo: note that Verizon implies to customers that they need that NZAccess Manager app
[18:12] <rickspencer32> I assume it's spy ware, but don't know that for a fact
[18:13] <Nafallo> doesn't all of them tell lies based of little knowledge? :-)
[18:13] <rickspencer32> I suppose
[18:14] <rickspencer32> I think that's part of what happened to that poor lady who got Ubuntu from Dell. Her ISP told her she couldn't connect to the internet without their software
[18:14] <rickspencer32> What reason would she have to doubt them?
[18:14] <Nafallo> yea. I assume so as well.
[18:28] <calc> rickspencer32: probably not spyware just lack of training employees to know how to do it any other way
[18:31] <dobey> rickspencer32: it's not so much spyware as it is a single point of failure for customer service to deal with. it's much easier to train your 10,000 people sitting in a call center to deal with issues from one program, rather than all the possible combinations of ways to configure networking across the board
[18:34] <rickspencer32> calc: dobey: you make me feel cynical
[18:35] <rickspencer32> I also suppose that Windows probably doesn't work well with 3g, so they had to do some plumbing themselves. They wouldn't expect an OS to be able to adapt fast enough to just work
[18:35] <dobey> rickspencer32: it's easy to feel cyncical about the corporate bottom dollar problem :)
[18:36] <dobey> rickspencer32: well, Vista probably has some built-in stuff, where XP does not, and so it's easier to just have the one program there again for support
[18:37] <Nafallo> dobey: Vista had problems with regular DHCP on my last flatmates laptop... just saying :-)
[18:37] <dobey> rickspencer32: i know for example, the WPA support in XP is rather crap, so even though the wireless card in my laptop works in XP without the special intel program, it won't work with WPA G networks
[18:37] <dobey> rickspencer32: so i have to use the intel program to use wireless
[18:38] <dobey> Nafallo: so does my xbox360. think MS just does some weird stuff to DHCP, and it breaks horribly in some cases
[18:38] <Nafallo> agreed :-)
[18:39] <dobey> it's like how outlook mobile on my phone doesn't seem to want to do smtp for some reason
[18:39] <Nafallo> and then you get some weird mode like restricted internet or whatever... which I think means that you're on local link.
[18:40] <dobey> yeah, it does a weird thing where it assigns a default local ip
[18:40] <Nafallo> oh. not link local then?
[18:41] <dobey> Nafallo: i've seen a similar problem before, but i'm pretty sure it was a hardware problem, because neither wireless nor hardwire would work, even if i manually configured the ip
[18:41] <Nafallo> this wasn't. it worked from time to time :-)
[18:41] <dobey> Nafallo: well it assigns a local ip, and i think actually doing zeroconf stuff over wireless depends on some other settings, and whether or not you set up a network
[18:42] <dobey> link local with only yourself isn't particularly useful
[18:42] <Nafallo> :-)
[18:42] <Nafallo> yea... well... my Ubuntu didn't fail so... ;-)
[18:43] <Nafallo> even if it had, I've de-installed the link local stuff :-)
[20:21] <chrisccoulson> ping mvo - i notice you've got a branch of update-notifier that uses EggSmClient. Is that going to appear in Jaunty at all?
[20:21] <mvo> chrisccoulson: I have not fully made up my mind about it
[20:22] <mvo> chrisccoulson: I created it to help the effort to get rid of libgnome as a dependenc
[20:22] <mvo> y
[20:22] <chrisccoulson> the only reason i ask is because of bug 302326
[20:22] <mvo> I also don't quite remember if that was all dependencies in u-n against libgnome
[20:23] <mvo> oh, thanks chrisccoulson
[20:23] <mvo> good catch
[20:23] <chrisccoulson> i just wrote a patch that uses DBus to restart the system
[20:23] <mvo> chrisccoulson: I think for now re-adding gnome_programm_init() is fine
[20:23] <chrisccoulson> but that was before i noticed your EggSMClient branch
[20:24] <mvo> I was thinking about the dbus approch
[20:24] <mvo> but I was afraid of breaking compatiblity with xubuntu
[20:24] <chrisccoulson> the dbus patch is quite small, and I just tested it out
[20:24] <mvo> (or kde)
[20:24] <chrisccoulson> ah, yeah, i hadnt thought of that
[20:24] <mvo> the nice thing about the current way is that its truely cross desktop
[20:24] <mvo> (everything else I dislike on the xmpp stuff) :)
[20:25] <chrisccoulson> yeah, it would be nicer if we could just use DBus
[20:25] <chrisccoulson> i can do a patch that reinstates gnome_program_init if you like?
[20:25] <mvo> chrisccoulson: that would be very nice
[20:25] <chrisccoulson> no problem, i'll work on that
[20:25] <mvo> chrisccoulson: its maintained in bzr, but normal diff is just fine as well
[20:26] <chrisccoulson> i did the Dbus patch in a bzr branch, so I can do the new patch there as well
[20:26] <mvo> chrisccoulson: nice
[20:27] <mvo> I will be around for another 1-2h - if I'm gone, just add main-sponsors to the report and someone will surely pick it up :)
[20:27] <chrisccoulson> i'll do that - thanks


 For a brief moment I thought it was lubuntu-grub-theme that failed.
[08:11] <The_LoudSpeaker> Anyone has the link to the upstream issue where the window sizes of terminal settings/panel settings etc ?
[15:55] <kc2bez> Lubuntu-grub-theme didn't break the iso, you haven't uploaded it yet @The_LoudSpeaker ;)
 It is there in rSEED
[15:56] <kc2bez> not I meta though
[15:56] <kc2bez> in
 Yup!
 If I am to upload it, It will have to wait till next year probably.
 @The_LoudSpeaker [If I am to upload it, It will have to wait till next year probably.], Why?
 @RikMills [Why?], It's 4 days until next year, mind
 @RikMills [Why?], Heading to Gopal's place for new year.
 @UniversalSuperBox [It's 4 days until next year, mind], I said probably.
 If it is not urgent, then best you wait and do it yourself then. Use your new powers!
 Yeah. I am eager but I can wait a few days.
 @UniversalSuperBox [It's 4 days until next year, mind], Next decade
 😱
 They fly by so fast XD
 I'm starting to feel old. I remember 2010...
 I remember 01/01/2010
 Hey, don't remind me of feeling old XD
 I can't party like it's 1999 anymore.
 If you are missing the referencehttps://m.youtube.com/watch?v=rblt2EtFfC4&feature=youtu.be
 @kc2bez [If you are missing the referencehttps://m.youtube.com/watch?v=rblt2EtFfC4&featur …], I get the reference XD
 :)
 @tsimonq2 [I'm starting to feel old. I remember 2010...], You are still young ra. I turn 20 next month. 👨🏻🦳


[12:13] <Evaso2> a sort of commit rollout + dependecies etc.
[12:14] <Evaso2> when the trasaction is stable in testing and compilant with the policies it will bel applied to the stable "trunk"
[12:14] <Evaso2> s/bel/be
[12:14] <LaserJock> seems like it requires a lot of "policing"
[12:15] <LaserJock> and I'm not seeing a clear advantage to a time-based release
[12:15] <Evaso2> not a lot of policiing somthing like in the wiki stub are already good
[12:15] <Evaso2> the trasaction is only a concept for loking packages with dependencies
[12:17] <Evaso2> you could not upload a new upstream release if the upload broke the trasaction already in testing (for example abi changes)
[12:17] <LaserJock> it would just seem to me that a constantly moving target would not be as stable, as supportable, nor able to make changes as well
[12:17] <LaserJock> at least to a "release" level
[12:17] <LaserJock> for development or "unstable" purposes it seem to make some sense
[12:18] <LaserJock> basically like what unstable is for the most part
[12:18] <Evaso2> probably but this work around many problem about backporting upstream bugs
[12:18] <Evaso2> we need an extra work for backporting upstream bug fixing in stable release
[12:19] <Evaso2> without a proper "stable" release we could try to itroduce slowly new upstream version in the trasaction
[12:19] <HrdwrBoB> I don't think people want that
[12:20] <Evaso2> HrdwrBob: probably :) we could talking also about this
[12:20] <HrdwrBoB> "I am running Ubuntu X.XX
[12:20] <HrdwrBoB> is a lot easier than
[12:20] <HrdwrBoB> "oh I last updated foo and bar, here is my complete system version list"
[12:21] <Evaso2> mhh... the alterative is I'am running Ubuntu without any X.XX
[12:21] <LaserJock> Evaso2: your idea is similar to Gentoo it would seem
[12:21] <LaserJock> Evaso2: but you have no idea what package versions you are running with that
[12:21] <LaserJock> what if a person doesn't have internet access
[12:21] <LaserJock> or limited access
[12:21] <TheMuso>
[12:21] <TheMuso>
[12:22] <LaserJock> they may still have whatever version was on the "snapshot"
[12:22] <ajmitch> TheMuso: I agree
[12:22] <TheMuso> ajmitch: lol
[12:22] <Evaso2> LaserJock the problem of internet access is relative also at security fix
[12:22] <TheMuso> speakup decided to screw with sticking keys again after switching to this box using a kvm
[12:22] <LaserJock> Evaso2: yes it is
[12:23] <Evaso2> LaserJock : or also at stable upgrade that fix bugs
[12:23] <LaserJock> sure
[12:23] <LaserJock> but if you have no internet wouldn't you rather have a tested, stabilized distro then the latest "daily"
[12:24] <Evaso2> we could simply have a checksum to know if we run the actual sistem
[12:24] <Evaso2> probably updates could will come 1 time at week
[12:24] <Evaso2> so trasaction will be committed to stable one time at week
[12:24] <Evaso2> when ready
[12:25] <LaserJock> well, I doubt that Debian or Ubuntu would be good fits for this system
[12:25] <LaserJock> but perhaps some derivatives might want to try it
[12:25] <LaserJock> it might have some advantages
[12:25] <LaserJock> for us I think the time based release also provide timelines for development
[12:25] <Evaso2> it is an alternative concept about not to compleetly break the upstream flow
[12:26] <LaserJock> it has both technical and social consequences
[12:27] <Evaso2> but the time based release will be relative to meet the periodical trasaction clock for prepare the trasaction from the devel system
[12:27] <Evaso2> the time based release could be fragmentated and not so monolitich
[12:29] <Evaso2> for example on the next transaction clock in the meeting we coiche to complete and polish the python x.x trasaction
[12:30] <Evaso2> naturally this transaction must be well tested in the dev system  (no rc or important bug) before could be committed
[12:31] <Evaso2> this could let also to us to shorting the time we could integrate upstream bugfixing instead to try to backporting it
[12:37] <Evaso2> LaserJock: There is still a some kind of weekly or monthly or clock time oriented goals
[12:38] <popey> if I want to report a bug in the gnome doofer that comes up when i press the volume control soft keys on my laptop, what would that be?
[12:38] <popey> hmm, hotkey-setup?
[12:43] <jdub> wow, just doing an upgrade and suddenly everything is totally gouging the cpu
[12:43] <jdub> like, gconftool-2 suching 80% over at least a minute
[12:44] <jdub> hrm, no, longer
[12:46] <cjwatson> Evaso2: you're free to start an Ubuntu derivative which works that way and try it out, but I'm pretty confident that Ubuntu isn't going to make that sort of change. Sorry.
[12:48] <Evaso2> cjwatson: it is only for talking about an issue i doesn't want to create a fork for a derivate only for test an idea
[12:48] <cjwatson> I'm sorry, but we're not going to do it within Ubuntu
[12:48] <jdub> Evaso2: i tend to think that method will eventually take over, but it would require an enormous amount of work right now
[12:49] <Evaso2> jdub: what do u mean for "take over"?
[12:50] <jdub> Evaso2: it will become the 'normal' way free software is delivered
[12:50] <Evaso2> jdub: really or are u joking? :)
[12:50] <cjwatson> it would not be compatible with Canonical's commercial processes without serious (and expensive) reengineering of those processes
[12:50] <cjwatson> it's much easier to do this sort of thing when you're starting a project
[12:51] <cjwatson> once the project is up and running, change at that sort of fundamental level is difficult and expensive
[12:51] <cjwatson> and once people's jobs are depending on success, there's more resistance to untried ideas
[12:51] <Evaso2> cjwatson: sure i'm also sure that it has too many reengineering
[12:51] <Evaso2> cjwatson: i agree with u on this two issues
[12:52] <jdub> Evaso2: no, i'm not joking; but that's just my take on what the future may bring
[12:53] <cjwatson> I'm not really convinced that it can supply coherent enough support commitments and user messaging
[12:53] <Evaso2> jdub: yes my was only a teoric discussion i doesn't think really that ubuntu or debian could really partical try somthing like this
[12:53] <cjwatson> but this is the wrong forum to go into it in detail
[12:54] <Evaso2> there are already support problem in ubuntu because it cannot control time freeze release for all the foss apps
[12:55] <Evaso2> this is issue was already in a Mark post on his blog
[12:56] <Evaso2> mainly the ubuntu choiche is to sync with gnome time release clock
[12:56] <cjwatson> "the current system is imperfect" does not imply "any other possible choice is better"
[12:56] <cjwatson> I was not arguing that the current system was perfect
[12:57] <cjwatson> but, within the context of Ubuntu, efforts are better spent on minor tweaks than on total scorched-earth release process redesign, at this point
[12:57] <Evaso2> i think that no one system is perfect and mainly is not perfect forever for an evolving word :)
[12:57] <cjwatson> by necessity, the latter will essentially produce no useful results except for possibly the founding of a new project to experiment with it
[12:57] <cjwatson> warty was when we were free to experiment :)
[12:58] <jdub> within the context of "we release in six months... starting from before X people were even here" ;-)
[12:58] <Evaso2> i think that probably could be experimented only with a little number of packages to try to test the system
[12:58] <cjwatson> I'm aware that the current process has its trade-offs; I was there (and argued about them) when it was set up
[12:58] <cjwatson> (as was jdub)
[12:59] <cjwatson> but you need to recognise that every process has its trade-offs, and you would simply be exchanging one set of disadvantages for another
[12:59] <Evaso2> i think that actually the problem is every distro is overloaded on distro vs upstream issue
[01:00] <cjwatson> pages about release processes need to explicitly acknowledge the disadvantages as well as the advantages, otherwise they're just advocacy
[01:00] <Evaso2> yes for my stub i see problem with debian (but less with ubuntu)
[01:01] <Evaso2> for debian a see a problem to try to put in a good state a trasaction that keep too many time
[01:01] <Evaso2> so begin to missing many upstream releases
[01:02] <Evaso2> and this problem could be the same with the universe side of ubuntu
[01:02] <jdub> brr, this cpu hogging business is bizaare
[01:03] <Evaso2> upstream has its work time but if you are to slow to but dependecies trasaction in a good shape you begin to miss upstream release while you fix package with dependecies (what i call a trasaction ecosystem)
[01:04] <Evaso2> s/too slow to put
[01:06] <cyberix> https://bugs.launchpad.net/gnome-panel/+bug/81205
[01:06] <Ubugtu> Malone bug 81205 in gnome-panel "Clock applet doesn't allow me to choose Monday as the starting day of the week" [Unknown,Unknown]
[01:07] <popey> hmm, do only *some* bugs appear here?
[01:07] <popey> oh, sorry, that's ubunu-bugs isn't i
[01:07] <mdke> popey: only ones which people call. Such as bug 12345
[01:07] <Ubugtu> Malone bug 12345 in isdnutils "isdn does not work, fritz avm (pnp?)" [Medium,Fix released]  https://launchpad.net/bugs/12345
[01:07] <popey>  /ignore popey
[01:07] <Evaso2> but probably in the future the  new linuxfoundation (osdl + fsg) with the lsb a linux kernell could try to begin to define a universal linux syncro clock to sync all the major linux distro (and problably many little opensource project begin to sync releases to this clock)
[01:09] <Evaso2> so we will have a sort of universal timeline to sync (the opposit of tha actual FOSS asyncro system)
[04:15] <Hobbsee> any core dev people around?  i'm looking for a sponsor
[09:11] <dholbach> good morning
[09:13] <cjwatson> pitti: you're in ubuntu-archive in LP now too, so you should be a full archive admin; let me know if there's anything you can't do
[09:13] <Mithrandir> pitti: you want to subscribe to<EMAIL_ADDRESS>probably.
[09:14] <pitti> cjwatson: just checked, account seems to be ok; thanks
[09:14] <pitti> Mithrandir: alright
[09:17] <pitti> ah, thanks for adding me to the team, just appeared
[09:21] <Keybuk> pitti: what's wrong with this picture? -- http://people.ubuntu.com/~scott/feisty-20070123-7.png
[09:22] <Mithrandir> Keybuk: your machine seems to be bored for a while while booting.
[09:22] <Treenaks> Mithrandir: bored with S08loopback even
[09:22] <Mithrandir> yeah, seems like it can't resolve its own hostname
[09:23] <Mithrandir> "host" is running for exactly ten seconds.
[09:25] <Keybuk> Mithrandir: yes
[09:25] <Keybuk> it's not unusual to have no DNS server when you're only bringing up lo :p
[09:26] <Keybuk> it's not trying to resolve its hostname, but looking for a local SOA
[09:26] <Treenaks> Keybuk: ifrename... ;)
[09:27] <Keybuk> Treenaks: ?
[09:28] <Treenaks> Keybuk: isn't it possible to rename the 'lo' device to something else?
[09:28] <Treenaks> Or will that break other things horribly too?
[09:28] <Keybuk> I don't think it's possible
[09:28] <Treenaks> ok, nevermind then
[09:28] <pitti> Keybuk: yup, there's a bug about it
[09:29] <pitti> Keybuk: bug 80268
[09:29] <Ubugtu> Malone bug 80268 in avahi "Avahi daemon should not try to resolve hostnames during bootup" [Undecided,Unconfirmed]  https://launchpad.net/bugs/80268
[09:30] <Mithrandir> seb128: if you could come over here afterwards and I'll fix up the rest of the bits of the greasemonkey script for you.
[09:31] <seb128> Mithrandir: now or after the debhelper demo?
[09:32] <Mithrandir> seb128: whenever you want. :-)
[09:32] <seb128> ok, after the demo then ;)
[09:33] <Hobbsee> hey Mithrandir, seb128, and Keybuk
[09:33] <seb128> hi Hobbsee
[09:33] <Mithrandir> morning, Hobbsee
[09:34] <Hobbsee> ;)
[09:37] <Mithrandir> Riddell: do you want to add knetwork-manager to your -desktop seed yourself or should I do it?
[09:37] <pitti> lifeless: look at bug 81237, that's a funny one
[09:37] <Ubugtu> Malone bug 81237 in apport "Errors from python interpreter give apport crash dialog!" [Undecided,Unconfirmed]  https://launchpad.net/bugs/81237
[09:38] <pitti> lifeless: (just to amuse you, I'll fix it)
[09:41] <lifeless> pitti: ah yeah, jamesh and I had a fix for it
[09:42] <lifeless> pitti: its not trivial to fix. I'll dig up the log about the right way later
[09:42] <pitti> lifeless: oh, I thought about something like 'InterpreterPath == ExecutablePath -> ignore'
[09:42] <lifeless> pitti: 'python foo.py' -> foo.py may be packaged
[09:43] <pitti> lifeless: check the arguments then, too? hmm
[09:43] <lifeless> there are a couple of variables we can cross check though
[09:43] <lifeless> its in my irc logs from las year somewhere ;)'
[09:46] <pitti> lifeless: if I run python in /usr/lib, I get ExecutablePath == /usr/lib
[09:50] <Keybuk> you don't exclude /usr/local from that?
[09:50] <Keybuk> I've had that dialog at least once for a python script in /usr/local/bin
[09:50] <pitti> Keybuk: I do
[09:50] <pitti> Keybuk: ah, probably not for interpreted scripts
[09:51] <lifeless> Keybuk: this is about interactive python, but if you get a dialog when you shouldn't, file a bug with some details ;)
[09:52] <Keybuk> lifeless: bug #81244
[09:52] <Ubugtu> Malone bug 81244 in apport "Is run for programs in /usr/local" [Undecided,Unconfirmed]  https://launchpad.net/bugs/81244
[09:52] <pitti> Keybuk: thanks
[09:53] <cjwatson> dholbach: does <or> work yet?
[09:54] <dholbach> cjwatson: yes
[09:54] <cjwatson> hmm
[09:54] <dholbach> cjwatson: 'not' too
[09:54] <cjwatson> can't get 79029 to match "no active autopartitioning choice"
[09:54] <dholbach> do you have the clue file for that somewhere so I can try myself?
[09:54] <dholbach> cjwatson: ^
[09:55] <cjwatson> (that would be a false positive as it happens, but still)
[09:55] <\sh> moins
[09:55] <cjwatson> dholbach: http://people.ubuntu.com/~cjwatson/tmp/ubiquity.info
[09:56] <cjwatson> I'd suggest hacking bughelper to limit to just bug 79029 or it'll take forever
[09:56] <Ubugtu> Malone bug 79029 in ubiquity "Feisty Herd2 - Installer crashed" [Undecided,Unconfirmed]  https://launchpad.net/bugs/79029
[09:56] <\sh> sabdfl, thank you for your mail :)
[09:56] <dholbach> cjwatson: i'll give it a special bug list url but thanks for the hint
[09:57] <Riddell> Mithrandir: it's already in
[09:57] <Mithrandir> Riddell: coolie
[09:59] <dholbach> cjwatson: working on it
[10:04] <dholbach> cjwatson: can you try  http://daniel.holba.ch/temp/possiblefix.patch ?
[10:06] <cjwatson> trying
[10:08] <dholbach> cjwatson: does   ./bughelper -A -l http://tinyurl.com/2ykot4   work for you?
[10:57] <\sh> doko: if you have time, can you look at http://librarian.launchpad.net/5720669/buildlog_ubuntu-feisty-i386.ldaptor_0.0.43-0.4ubuntu2_FAILEDTOBUILD.txt.gz and tell me how can we fix it (e.g. setting it back to python2.4)
[11:00] <StevenK> I note the command that fails is dia -t png-libart --export=ldap-is-a-tree.dia.png.tmp ldap-is-a-tree.dia
[11:01] <\sh> oh my god...right..i didn't see the glibc warning...
[11:04] <StevenK> There's no bug against it, either.
[11:05] <fabbione> *** glibc detected *** dia: free(): invalid pointer: 0x09392ea0 ***
[11:05] <fabbione> fix dia :)
[11:05] <Treenaks> StevenK: there is a bug against dia for that..
[11:06] <StevenK> Treenaks: Oh? I must of missed it.
[11:06] <Treenaks> StevenK: https://bugs.launchpad.net/ubuntu/+source/dia/+bug/79188
[11:06] <Ubugtu> Malone bug 79188 in dia "Dia hangs while starting" [High,Confirmed]
[11:06] <StevenK> Ah, I was looking for bugs mentioning glibc
[11:06] <Treenaks> StevenK: well, it does mention it.. in the description text
[11:07] <StevenK> So, which lucky person gets to valgrind dia? :-)
[11:07] <seb128> fabbione: what about you fixing bugs instead of just pointing them? ;)
[11:07] <Treenaks> StevenK: seb128 ;)
[11:08] <StevenK> Actually, doko touched it last. :-)
[11:08] <seb128> StevenK: the upstream SVN has the required changes, that's a "work with new python" change
[11:08] <seb128> it's trivial to backport probably
[11:08] <StevenK> seb128: Point me at the patch, and I'm happy to throw you a debdiff?
[11:08] <seb128> the problem is that it has been commited to CVS and touch like 15 files, and there is not an unique changeset
[11:09] <seb128> you need to look at every file change and collect the diffs, which I've been to busy or lazy to do
[11:09] <seb128> wait
[11:09] <seb128> http://svn.gnome.org/viewcvs/dia/trunk/plug-ins/python/
[11:09] <seb128> "	* plug-ins/python/*.c : don't mix PyObject_NEW() with PyMem_DEL()"
[11:10] <seb128> grab that diff for every file
[11:10] <seb128> that will probably work
[11:15] <fabbione> seb128: because it's part of my new job to just point them out :)
[11:15] <seb128> that's not support request
[11:15] <seb128> what other new job did you get?
[11:16] <fabbione> seb128: handing over all my stuff to you ;)
[11:16] <seb128> I don't think so
[11:17] <fabbione> seb128: it's fun tho :)
[11:18] <seb128> I don't doubt of it :p
[11:22] <StevenK> Come on librarian, send me data slower.
[11:22] <saispo> hi
[11:23] <doko> \sh, StevenK: reverting to 2.4 is not an option; better fix the 2.5 bugs
[11:24] <StevenK> doko: Doing so now
[11:24] <doko> StevenK: thanks
[11:24] <StevenK> doko: I shall bug either you or seb128 when I have a debdiff for dia
[11:24] <seb128> StevenK: attach it to the bug, I'll do the upload
[11:24] <StevenK> seb128: Aye. I'll poke you here when I've done so
[11:24] <seb128> cool
[11:27] <tkamppeter> I have a question about getting new packages from universe to main. I have made the appropriate reports and added the packages to the queue, but when I announce it on ubuntu-devel, I get messages that my postings await moderator approval because I am not a developer. Where should I announce my main inclusion requests?
[11:27] <kylem> ubuntu-devel-discuss is the open list and probably the best place.
[11:29] <tkamppeter> Then I think the instructions on https://wiki.ubuntu.com/UbuntuMainInclusionRequirements should be appropriately changed.
[11:29] <\sh> doko, thx :)
[11:29] <seb128> mdke: around?
[11:29] <mdke> seb128: (In case I'm not around at the moment, please provide a bit of information about what you want and I will respond when I get back)
[11:30] <seb128> mdke: have your changes for the help menu been approved and need to be applied?
[11:30] <tkamppeter> Like: 3. #
[11:30] <tkamppeter> The request and the link to the report are sent to<EMAIL_ADDRESS>or<EMAIL_ADDRESS>[11:38] <cjwatson> tkamppeter: I think ubuntu-devel is appropriate.
[11:38] <cjwatson> although there is an open question of whether it makes sense to post MIRs to a mailing list at all
[11:40] <lifeless> sfllaw: I have the edit back.ping me when you want this meeting
[11:41] <tkamppeter> cjwatson, then we should really change the instructions on https://wiki.ubuntu.com/UbuntuMainInclusionRequirements. Which address do you like should I send the announcements of main inlusion requests to?
[11:41] <cjwatson> tkamppeter: I have updated the process following a brief discussion here
[11:42] <cjwatson> tkamppeter: you do not need to announce it anywhere; Martin Pitt (the primary reviewer) gets notified via a wiki subscription
[11:43] <cjwatson> https://wiki.ubuntu.com/UbuntuMainInclusionRequirements fixed
[11:44] <tkamppeter> cjwatson, thanks.
[11:56] <pitti> lifeless: seems that sys.argv == ['']  for interactive python sessions even if I run 'python -O -E'
[11:57] <pitti> lifeless: that's why your binary = os.path.join(cwd,argv[0] ) produces '/usr/local'
[12:14] <StevenK> seb128: Bug 79188 updated with my debdiff. I have tested that I can reproduce the problem, and also that my fix does indeed fix the problem.
[12:14] <Ubugtu> Malone bug 79188 in dia "Dia hangs while starting" [High,Confirmed]  https://launchpad.net/bugs/79188
[12:14] <seb128> StevenK: good, I'll have a look now, thank you
[12:15] <StevenK> seb128: Great, thanks. And no problem. :-)
[12:19] <ogra> seb128, StevenK, i'm just trying to get the dia from experimental building ... i'd assume that patch is included
[12:19] <seb128> right
[12:20] <seb128> ogra: let me know if it works fine, otherwise I'll upload the patched package
[12:20] <ogra> yep
[12:20] <Hobbsee> Mithrandir: or another archive admin, ping?
[12:20] <ogra> only finishing the tuxtype build ...
[12:27] <Mithrandir> Hobbsee: humm?
[12:27] <Hobbsee> Mithrandir: i think there were two uploads of murrine today?   can you make sure the last one gets uploaded please?  :)
[12:29] <Mithrandir>   159376 | S- | murrine              | 0.41-0ubuntu1        | 7 hours 30 minutes
[12:29] <Mithrandir>   | * murrine/0.41-0ubuntu1 Component: main Section: gnome
[12:29] <Mithrandir>   159377 | S- | murrine              | 0.41-0ubuntu1        | 7 hours 20 minutes
[12:29] <Mithrandir>   | * murrine/0.41-0ubuntu1 Component: main Section: gnome
[12:29] <Mithrandir> so yes, two uploads. :-P
[12:30] <Mithrandir> I'm merging casper now, I can do it afterwards.
[12:32] <Hobbsee> Mithrandir: :(  realised after i'd uploaded the first one, went "bugger"
[12:32] <Hobbsee> cool, thanks :)
[12:40] <frennkie> Hello, does anybody know how likely it is that there will be a backport of libc6-xen for Dapper Drake LTS (6.06) (see: https://launchpad.net/ubuntu/+source/glibc/+bug/50331/+viewstatus)
[12:40] <Ubugtu> Malone bug 50331 in glibc "Please backport libc6-xen" [Wishlist,Unconfirmed]
[12:42] <frennkie> okay, so what does unconfirmed mean ?
[12:48] <mneptok> what is the nature of the breakage on Dapper? does it affect security?
[12:51] <Mithrandir> frennkie: not going to happen.
[12:51] <frennkie> *cry* why not, do you know?
[12:51] <Hobbsee> Mithrandir: well, the backporters might decide to smoke their crack pipe, again...
[12:52] <Mithrandir> Hobbsee: well, I just rejected it and I would be really, really surprised if any other archive admin though it was a good idea.
[12:52] <Mithrandir> frennkie: because we don't backport core libraries like, glibc.
[12:53] <Hobbsee> Mithrandir: heh, yes, i know.  i thougth the ubuntu backporters were separate to you guys - jdong's team
[12:53] <Mithrandir> Hobbsee: they're still subject to ubuntu-archive approval.
[12:53] <Hobbsee> ah :)
[12:54] <frennkie> ok, thats a point.. but as dapper, will be around and used for another 4 Years maybe it would be good to have proper xen supoort in it..
[12:54] <Hobbsee> frennkie: i believe you just got told by one of the 3 archive admins "no" - that's very very unlikely to change...
[12:54] <Mithrandir> frennkie: sure, that would be nice.  Unfortunately, as long as that means backporting glibc, it's not going to happen.
[12:56] <frennkie> okay, got it now. thx!
[01:02] <StevenK> ogra: Any news, re: dia?
[01:03] <ogra> StevenK, seems 0.96-pre1 is gone ... seb128 will apply your patch
[01:03] <ogra> (i got it from alioth some weeks ago ... it ftbfs'ed ... seems they didnt get it fixed)
[01:03] <StevenK> ogra: Great, thanks
[01:04] <seb128> ogra: you can also grab the new tarball and do the update if you want ;)
[01:04] <ogra> after lunch then :)
[01:56] <h4writer> (gnome) can I ask here how come that a list of anything sometimes shows white places? Like the user list in Gaim. Or the list of menus in "menu layout". If I'm not wrong those are created with python: treeview (treestore)
[01:57] <cjwatson> does anyone here have moderator privileges on the "Installation and Upgrades" forum on ubuntuforums.org? I need a comment marked sticky
[01:57] <h4writer> But it is annoying and I need to be fixed
[01:57] <h4writer> *it
[01:58] <Treenaks> h4writer: this is not a support channel
[01:58] <Treenaks> h4writer: also, use launchpad.net to file bugs
[01:58] <h4writer> ok
[01:58] <h4writer> thanks
[02:38] <ogra> StevenK, seb128, do we have a bug for the dia segfault ? i just uploaded
[02:38] <seb128> ogra: uploaded what?
[02:38] <ogra> dia
[02:38] <seb128> what version?
[02:39] <ogra> 0.95.0-4.1ubuntu3
[02:39] <seb128> grumpf
[02:39] <ogra> the patched one with StevenK's patch ...
[02:39] <seb128> I had that ready
[02:39] <ogra> i told you i'D do it after lunch when you asked
[02:40] <seb128> ogra: https://launchpad.net/ubuntu/+source/dia/+bug/79188
[02:40] <Ubugtu> Malone bug 79188 in dia "Dia hangs while starting" [High,Confirmed]
[02:40] <ogra> thx
[02:40] <seb128> np
[02:41] <Stargazers> Hi. I have a question about Python and Feisty. Is there problems with Feisty locales or something, cause jBrout should add IPTC as UTF-8, but it won't do it on Feisty?
[02:42] <Stargazers> And always I get errormessage in Feisty, I paste a url of errormessage, moment.
[02:42] <Stargazers> http://stargazers.kapsi.fi/screenshots/errormessage.jpg <-- This kind. This won't appear on Dapper or Edgy.
[02:44] <Stargazers> I mean, if I write IPTC-tags with DigiKam 0.9.0 and then look in jBrout, scandinavian chars won't work. And same if I add tags with jBrout and then look them DigiKam, scandinavian chars won't work. But it seems that problem is on jBrout that writes tags without UTF-8, but programmer said that it does. So, is there problem in Python packages in Feisty now?
[03:06] <alex-weej> grr
[03:06] <alex-weej> every time i try to install build dependencies
[03:06] <alex-weej> i just get a message like
[03:06] <alex-weej> E: Build-dependencies for gossip could not be satisfied.
[03:06] <alex-weej> i have no idea what's going on, anyone got an idea?
[03:06] <Hobbsee> alex-weej: not enough info
[03:06] <Hobbsee> alex-weej: means that one of the build deps is broken
[03:06] <seb128> alex-weej: that's not an user support chan
[03:06] <Hobbsee> ie, not installable
[03:07] <Hobbsee> and it's the wrong channel
[03:07] <alex-weej> seb128: i'm trying to "develop"
[03:07] <seb128> alex-weej: still not the right chan, that's not a chan to ask how to build a package
[03:07] <alex-weej> whatever
[03:07] <Hobbsee> heh
[03:15] <cjwatson> mvo: you can close bug 81225
[03:15] <Ubugtu> Malone bug 81225 in realplayer "realplay requires libc6 2.5" [Undecided,Unconfirmed]  https://launchpad.net/bugs/81225
[03:23] <erdinc> crimsun got a sec?
[03:29] <alsaberk> hi erdinc
[03:41] <ogra> seb128, http://people.ubuntu.com/~ogra/dia/
[03:48] <erdinc> cliebow use this: http://cekirdek.pardus.org.tr/~ismail/dist/bcm43xx-firmware-<IP_ADDRESS>.tar.bz2
[03:54] <bddebian> Heya
[03:56] <jdong> are you guys aware that libc6-dev from archive.ubuntu.com main is unfetchable...
[03:57] <jdong> http://archive.ubuntu.com/ubuntu/pool/main/g/glibc/libc6-dev_2.4-1ubuntu12.2_i386.deb
[03:57] <jdong> that URL
[03:57] <jdong> generates 403/forbidden
[03:57] <elmo> yes, it's deliberate
[03:58] <jdong> ah
[03:58] <jdong> recalling an update?
[03:58] <lifeless> elmo: is it listed in Packages at all ?
[03:58] <elmo> lifeless: yes
[03:58] <lifeless> meep. analyzer fall down go boom
[03:59] <elmo> jdong: yes
[04:00] <jdong> is this related to the libc6 update not liking libpthread.so.20 thing?
[04:00] <Mithrandir> yes
[04:01] <jdong> ah, ok
[04:01] <jdong> lovely :)
[04:01] <lifeless> and the toe bone is conneted to the foot bone
[04:01] <bddebian> hehe
[04:02] <lifeless> jdong: dont you mean .20 questions ?
[04:02] <jdong> LOL
[04:02] <jdong> BOO
[04:05] <Keybuk> or why anyone would have a /usr/lib/libc.so.6 symlink
[04:06] <Mithrandir> Keybuk: it gets pulled in by gnupg-agent, for instance.
[04:06] <Mithrandir> hmm, no
[04:06] <Mithrandir> that's libpth2
[04:06] <Keybuk> Mithrandir: no, that's libpth20
[04:06] <jdong> Mithrandir: I can't find anything that rdepends libpthread20....
[04:06] <jdong> but I have come across 3 users that experienced the update problem
[04:06] <lifeless> perhaps its installed from $old-version
[04:07] <jdong> perhaps
[04:07] <jdong> what is the officially sane workaround for this, BTW
[04:08] <lifeless> wait
[04:08] <jdong> mmm :)
[04:13] <Mithrandir> ogra: I can accept python-ltsp on the condition that you clean up debian/ ; you're shipping effectively empty post- and preinsts (remove them), same goes for README.Debian, your debian/rules file has a configure target, but the package has no configure program, so it's useless.
[04:14] <ogra> Mithrandir, python-central rewrites the postinst files during build
[04:15] <ogra> but i'm fine dropping README.Debian and cleaning rules
[04:15] <ogra> (python-central through dh_pycentral)
[04:16] <Mithrandir> ogra: yes, it replaces the #DEBHELPER# token.  If you don't have any live code in there yourself, remove the file.
[04:17] <ogra> does it still create it ? i thought it needs a skeleton ...
[04:17] <ogra> but if that works i'll remove it
[04:19] <Keybuk> *confused*
[04:20] <froud> whose the best person to speak to about packaging of docbook and docbook-xsl?
[04:20] <jdong> cjwatson: ping; did you find the moderators you were looking for?
[04:23] <_MMA_> Mithrandir: Have you had a chance to look at the ubuntustudio-meta package again or will someone else be looking at it?
[04:24] <Mithrandir> _MMA_: it was accepted half an hour ago.
[04:24] <froud> Over at docbook project we're trying to contact all package maintainers for DocBook. How can I discover who is doing this for Ubuntu?
[04:24] <_MMA_> Thank you. Ill let my team know. ;)
[04:26] <MikeSmith> I do the docbook-xsl builds and releases
[04:26] <MikeSmith> the upstream ones
[04:27] <MikeSmith> I'd like to help get the edgy docbook-xsl package more up-to-date/synced up with the Debian one
[04:27] <ogra> Mithrandir, all fixed, want me to upload the fixed one before you approve ?
[04:27] <Mithrandir> ogra: nah, I put it in, but please upload the new one.
[04:27] <MikeSmith> Debian docbook-xsl is at 1.71.0.dfsg.1-1.1
[04:27] <ogra> Mithrandir, will do as soon as the accepted mail is here ... thansk a lot
[04:27] <ogra> *thanks
[04:27] <MikeSmith> edgy one is at 1.68.1.dfsg.1-0.2
[04:28] <MikeSmith> which is very very old now
[04:28] <MikeSmith> 18 months or more old
[04:29] <froud> MikeSmith: apt-cache show says Adam Di Carlo<EMAIL_ADDRESS>[04:29] <froud> for docbook
[04:29] <froud> and Mark Johnson<EMAIL_ADDRESS>for docbook-xsl
[04:30] <Mithrandir> MikeSmith: docbook-xsl in feisty is 1.71.0.dfsg.1-1.1
[04:30] <froud> Mithrandir: yes, but dapper ppl what repository updated ... what to do?
[04:31] <Mithrandir> froud: nothing?  We're not introducing new upstream versions in released distributions.
[04:31] <MikeSmith> froud - DocBook stylesheet package is docbook-xsl
[04:31] <MikeSmith> and I know the Debian packager for it quite well
[04:32] <MikeSmith> my concern is just about making sure that Ubuntu users have easy access to the latest
[04:32] <MikeSmith> Mithrandir - thanks
[04:32] <froud> MikeSmith: seams they must install manual or dist-upgrade :-)
[04:33] <ogra> Mithrandir, hmm, i had the accepted message from soyuz ... but get a NEW message for the next upload ... seems i had a little race condition here ... sorry
[04:33] <MikeSmith> froud, Mithrandir - OK. So updated package don't get backported to dapper and edgy?
[04:34] <Mithrandir> MikeSmith: correct.  That is, they can be requested, but they're not automatically backported.
[04:34] <Mithrandir> (requested into -backports, not into the normal repo)
[04:34] <froud> Mithrandir: who does that?
[04:35] <Mithrandir> froud: https://wiki.ubuntu.com/BackportsHowto
[04:36] <Keybuk> jdong: ping ping ping ping ping
[04:36] <jdong> Keybuk: pong pong pong pong pong pong?
[04:36] <jdong> -1
[04:36] <Keybuk> jdong: don't suppose you have a record of when you installed libpthread20 ?
[04:36] <Keybuk> e.g. in /var/log/dpkg.log* ?
[04:36] <jdong> Keybuk: I was not affected....
[04:37] <MikeSmith> Mithrandir - so I guess I should file a bug if I want to request it be backported?
[04:37] <Keybuk> jdong: oh, bah
[04:37] <Mithrandir> MikeSmith: correct.
[04:37] <jdong> Keybuk: some people who were affected came to me :(
[04:37] <Keybuk> jdong: do you know of them?
[04:37] <MikeSmith> Mithrandir, froud - big thanks
[04:37] <jdong> Keybuk: wildtangent on #ubuntuforums (currently not on there; he had this problem yesterday), and a forum search can yield quite some more :)
[04:38] <Keybuk> jdong: can't find why anyone would have that installed though
[04:39] <jdong> Keybuk: heh, I'm just as puzzled
[04:42] <jdong> Keybuk: when the fixed libc6 package is released, will that automatically apply OK for people who already attempted applying the broken update?
[04:43] <jdong> i.e. will any apt-get -f install coercing be necessary?
[04:43] <Keybuk> jdong: the fix will automatically apply; assuming users haven't tried to force the issue themselves
[04:45] <jdong> ok
[04:46] <popey> who looks after planet.ubuntu.com?
[04:47] <popey> I have moved my domain but the rss planet doofer is still going to the wrong host for updates
[04:47] <Spads> popey: Any ubuntu-member can update it
[04:47] <Spads> popey: see https://wiki.ubuntu.com/PlanetUbuntu
[04:47] <popey> no, you don't understand
[04:47] <popey> the entry is correct
[04:48] <popey> but their box is doing incorrect dns lookup
[04:48] <popey> caching the old IP
[04:48] <lifeless> how long  ago did you move host ?
[04:48] <popey> last week
[04:48] <popey> its the only thing still hitting my apache logs
[04:48] <lifeless> what was your TTL before you moved ?
[04:48] <popey> good question
[04:48] <popey> i don't know
[04:49] <Spads> what's the hostname in question?
[04:49] <Spads> I can take a look
[04:49] <popey> popey.com
[04:49] <lifeless> planet runs a new process each time, so any caching is oming from the datacentre NS servers
[04:49] <popey> it is of course not a big deal, but I want to shut that apache down
[04:52] <lifeless> popey: what ip should it resolve to ?
[04:52] <jdong> Keybuk: I've posted a forumwide announcement urging people not to try their own ways of "fixing" the problem; also quoted your post asking for grepping of dpkg.log -- will ping you if any meaningful replies show up :)
[04:52] <popey> <IP_ADDRESS>
[04:52] <lifeless> Spads: ^
[04:52] <Spads> popey: is there another FQDN for the IP in question you could use?
[04:52] <popey> bishop.popey.com
[04:53] <Spads> bishop.popey.com has address <IP_ADDRESS>
[04:53] <Spads> that's on the planet host
[04:53] <Spads> so if you change it to that it should fix your problem for now
[04:53] <popey> that wont work
[04:54] <popey> apache will send that request elsewhere
[04:54] <Spads> I see.
[04:54] <popey> different virtual host
[05:00] <Spads> popey: I've put in a bit of a workaround.  /msg me if you still see hits from the planet system on the wrong host over the next hour
[05:00] <popey> thanks Spads
[05:02] <lifeless> Spads: bind is over enthusiastic ?
[05:03] <Spads> lifeless: it's a little more complicated than that
[05:03] <lifeless> Spads: ah well. over a beer sometime perhaps
[05:17] <seb128> ogra: the upstream build works fine, the debian build call "xmlto -o doc/en/manual html doc/en/dia.xml" though
[05:18] <seb128> ogra: change doc/en/usage-layers.xml to be valid UTF-8 (quotes around the background word to change) and it builds fine
[05:18] <ogra> seb128, oh, then its a leftover from the old packaging
[05:18] <seb128> or drop the xmlto call
[05:18] <ogra> right ... do we need it at all ?
[05:18] <ogra> hmm, well, if i drop it it will be a delta ... i'll rather do the quoting
[05:19] <seb128> ogra: doesn't look like
[05:19] <seb128> ok
[05:20] <seb128> ogra: from the changelog previous version lacked that xml, maybe that's why they built it with the package
[05:21] <seb128> ogra: the current tarball ships it though
[05:21] <ogra> ah
[05:21] <seb128> I would just comment the xmlto calls for the moment
[05:21] <seb128> we will adapt when syncing with Debian next time
[05:25] <ogra> yep, already testbuilding
[05:26] <AnAnt> I got a question about python: why isn't there a /usr/lib/python.so that can be set using /etc/alternatives/ ?
[05:29] <AnAnt> hello
[05:29] <AnAnt> ?
[05:38] <\sh> Mithrandir, can you give-back again ldaptor? :) thx
[05:47] <\sh> StevenK, doko, ldaptor compiles fine now with the StevenKs dia fix :)
[05:47] <\sh> StevenK, thx for that :)
[06:13] <kylem> morning kees.
[06:13] <keescook> hiya kylem
[06:13] <ogra> hey keescook
[06:13] <keescook> hiya ogra
[06:19] <pitti> hey keescook
[06:22] <jdong> keybuk... argh, come back :)
[06:22] <jdong> http://ubuntuforums.org/showpost.php?p=2057950&postcount=2
[06:22] <jdong> ^^ you've got one person whose dpkg.log shows a libpthread20 being installed
[06:23] <cjwatson> jdong: no, I didn't
[06:24] <jdong> cjwatson: I've posted a forum-wide announcement regarding not trying workarounds for the libc6 thing
[06:24] <jdong> hope that suffices
[06:24] <cjwatson> jdong: yeah, I saw - I think that will suffice, thanks
[06:24] <jdong> np :)
[06:24] <cjwatson> jdong: a rebuild is in progress that removes the check
[06:24] <jdong> good to hear
[06:25] <cjwatson> jdong: regarding http://ubuntuforums.org/showpost.php?p=2057950&postcount=2, the entire dpkg.log would be useful
[06:25] <cjwatson> jdong: Keybuk will be travelling for a while now, so I'd better take that over
[06:26] <lifeless> mdz: cjwatson: http://people.ubuntu.com/~robertc/possible-conflicts/
[06:26] <jdong> cjwatson: yeah, just told the guy to attach the log to the LP bug report
[06:27] <cjwatson> jdong: thanks, much appreciated
[06:27] <jdong> not a problem, glad to help
[06:27] <mdz> lifeless: greatly improved!
[06:27] <mdz> lifeless: can we collapse the cases which are identical across architectures into a single line?
[06:40] <lifeless> mdz: yes, that will happen another day though, as it does not currently buffer - which is needed to detect that
[06:45] <cjwatson> pitti: I was wondering if it'd be possible for ubiquity to use its own crash handler iff apport won't be around to catch the crash
[06:45] <cjwatson> pitti: do you think just skipping the crash handler if apport can be imported would do the job?
[06:45] <seb128> cjwatson: stop reassigning bugs to GNOME packages :p
[06:45] <cjwatson> seb128: hey, they were yours :-)
[06:45] <cjwatson> seb128: you can always get revenge by finding unassigned installer bugs
[06:46] <pitti> cjwatson: either that, or just checking whether apport-gtk package is installed, or /usr/share/apport/apport-gtk exists?
[06:46] <seb128> looks like indeed :p
[06:46] <cjwatson> pitti: or maybe apport to be frontend-agnostic
[06:46] <cjwatson> /usr/share/apport/apport?
[06:46] <pitti> cjwatson: right, just mentioning that people can uninstall apport-gtk but have apport installed
[06:46] <pitti> cjwatson: right
[06:46] <cjwatson> mm
[06:46] <cjwatson> right, I see your point
[06:46] <pitti> cjwatson: however, that shouldn't be an issue in the live system
[06:47] <cjwatson> I guess the gtk frontend can check for apport-gtk and the kde frontend can do similarly when there's a kde frontend
[06:47] <pitti> cjwatson: I can add Provides: apport-frontend if it helps
[06:47] <pitti> or that
[06:47] <cjwatson> I'm happier with checking a file than the dpkg database, as it'll be faster
[06:47] <pitti> right
[06:47] <mdz> lifeless: if you fix the '-' delimiter and remove the header ('possible conflict:') I think we can get what we need by post-processing against a whitelist
[06:47] <cjwatson> plus I prefer to do as little work as possible in an exception handler
[06:48] <pitti> cjwatson: I think in general, checking for /u/s/a/apport is equivalent to checking for import apport; the latter doesn't check for GUI existance either
[06:48] <lifeless> sabdfl: this was fun
[06:48] <cjwatson> mkay, I'll check for /usr/share/apport/apport-gtk I think
[07:13] <ogra> seb128, g-p-m uploaded
[07:14] <seb128> cool
[07:14] <ogra> my pbuilder took nearly 2h to resolve the deps ... something is wrong here
[09:44] <Mithrandir> \sh_away: given-back
[11:12] <RememberPOL> ffmpeg in mainstream repo is outtdated causing a lack of support for video is FLV files (audio works, [in VLC] )
[11:14] <Burgwork> RememberPOL: ffmpeg in which distro?
[11:15] <RememberPOL> well
[11:15] <RememberPOL> I'm running Xubuntu 6.10
[11:15] <RememberPOL> but it uses the mainstream ubntu distro
[11:15] <RememberPOL> *mainstream ubuntu repo
[11:15] <RememberPOL> http://slexy.org/paste/1074
[11:17] <Burgwork> ffmpeg is updated for the upcomign 7.04
[11:18] <RememberPOL> yes but can't it be put into the existing repo so i don't have to wait three months and upgrade my OS, or compile ffmpeg myself?
[11:19] <RememberPOL> or maybe i can find a fiesty deb instead of compiling
[11:19] <RememberPOL> heh
[11:20] <Burgwork> the issue is that newer ffmpeg breaks api/abi, so you need to recompile a bunch of other things
[11:20] <Burgwork> that being said, it may be backported
[11:21] <RememberPOL> abi?
[11:21] <Burgwork> application binary interface
[11:21] <LaserJock> I don't think libraries are that likely to be backported
[11:21] <RememberPOL> so installing a fiesty ffmpeg deb won't really help here?
[11:21] <Burgwork> not unless you have all of the depends of ffmpeg from feisty as well
[11:22] <Burgwork> the issue is not Ubuntus. It is that the ffmpeg upstream doesn't understand how ffmpeg is really used
[11:22] <RememberPOL> so all non-fiesty ubuntu users have to upgrade to fiesty before being able to play flv files.
[11:22] <RememberPOL> :x
[11:23] <LaserJock> well, software progresses. Sometimes you have to upgrade to get what you want
[11:23] <Burgwork> yes
[11:23] <RememberPOL> k
[11:23] <lamont> so how come my phone will pair  with my home machine, but not with my laptop?
[11:23] <Burgwork> I would write the ffmpeg people and complain to them about how they cannot keep api/abi stability
[11:23] <RememberPOL> i guess i'll just install vlc/flash on my windows vm
[11:23] <Burgwork> and what it hell is causes end users
[11:23] <lamont> Burgwork: or at least learn about sonames
[11:24] <LaserJock> RememberPOL: we would have to also update every package that is built using ffmpeg
[11:24] <Burgwork> lamont: anything at all, besides "install from cvs"
[11:24] <lamont> that is, they can change the abi if they must,  but they should version the soname
[11:24] <lamont> right
[11:24] <lamont> certain distros are prone to produce "what's an soname?" type questions from the developers... kinda scary
[12:03] <RememberPOL> Sweet I solved my issue (of FLV video not playing in Xubuntu 6.10 due to outdated ffmpeg [fixed in fiesty-7.04, not being backported because ffmpeg breaks api/abi] ) by downloading http://download.macromedia.com/pub/flashplayer/updaters/9/flash_player_9_linux_dev.tar.gz then extracting libflashplayer.so and flashplayer.xpt from /flash_player_9_linux_dev/plugin/debugger/install_flash_player_9_linux.tar.gz/install_flash_player_9_linu