[04:43] <balders> Hello, is there any readily available cross compile toolchains for arm?
[04:44] <balders> i.e. I would like to be able to type something like... apt-get install arm-linux-gcc on my host system and get a recent (4.2 or newer) toolchain
[04:47] <cooloney> balders: oh, there is no such deb package for apt-get install,
[04:47] <cooloney> balders: but you can download it from Code Sourcery website
[04:47] <cooloney> balders: we use their cross toolchains to build kernel just for testing
[04:47] <balders> ok, is the emdebain sources up to date or are they old?
[04:48] <balders> deb http://www.emdebian.org/debian/ lenny main
[04:48] <cooloney> balders: did not tried emdebian toolchain before.
[04:48] <cooloney> balders: for fsl-imx51 and mvl-dove, we are using 4.4 gcc now
[04:49] <balders> ok, what is fsl-imx51?
[04:49] <cooloney> balders: freescale imx51 soc, fsl-imx51 is a branch of our lucid kernel tree
[04:49] <balders> ahh ok
[04:49] <cooloney> balders: mvl-dove is marvell dove, which is also a branch of our lucid kernel tree
[04:50] <cooloney> balders: ok, good luck, has to leave for lunch
[04:50] <balders> thanks for the tip
[04:50] <balders> I will check out the code sourcery toolchain
[09:38] <ogra> cooloney, https://launchpad.net/~lool/+archive/ppa/+packages .... there is a cross compiler
[09:51] <Spyzer> hello
[09:51] <Spyzer> hello, I am trying to load up precompiled gpe jffs image and the zimage kernel for arm versatile with the following command <qemu-system-arm -M versatilepb -kernel zImage -hda gpe-image-micro2440.jffs2 -append initrd="noinitrd"> and I get the error <VFS: Cannot open root device "<NULL>" or unkown-block(2,0)> I have no idea as to how am I supposed to boot the jffs image. Let me mention the fact that this gpe image has been compiled for ARM9 Micro2440 and
[09:52] <Spyzer> any help would be greatly appreciated
[09:52] <Spyzer> ............................
[09:58] <Spyzer> anyone please
[10:08] <Spyzer> anyone please
[10:34] <asac> ogra: bug 514215
[10:34] <ubot4> Launchpad bug 514215 in mono "mono ftbfs with thumb2 on armel" [Critical,Triaged] https://launchpad.net/bugs/514215
[10:34] <ogra> ah, good
[10:36] <asac> lets hope i can install all b-d
[10:36] <asac> on jocote
[10:36] <ogra> why shouldnt you
[10:36] <asac> you cannot remove packages ;)
[10:36] <asac> so if there is a package that conflicts
[10:36] <ogra> IS can
[10:36] <asac> then #is is needed
[10:36] <ogra> right
[10:37] <asac> apt-get build-dep doesnt work either ;)
[10:37] <ogra> oh ?
[10:37] <ogra> i thought it did
[10:37] <asac> no you have to manually do apt-get install ;)
[10:38] <ogra> sudo apt-get install ... will now work inside the dchroots on the porter
[10:38] <ogra> boxes, providing that nothing would be removed.
[10:38] <ogra> from lamonts mail
[10:38] <ogra> oh
[10:38] <ogra> thats not build-dep indeed
[10:38] <asac> yeah
[10:38] <asac> just inconvenient ... but not blocking ;)
[10:39] <ogra> yeah
[10:55] <asac> ok lets see if that builds ;)
[10:58] <asac> slow slow slow the boat
[11:08] <asac> wonder if i really should have run debuild -S ... doesnt finish
[11:10] <asac> hmm seems i am fighting with doko there ;)
[11:19] <asac> ok aborted lintian ... thats just tooooo slow ;)
[11:22] <ogra> heh
[11:22] <ogra> fighting with doko is never good
[11:22] <asac> he is building gcc ;)
[11:22] <asac> i just want mono
[11:23] <asac> most likely he is even using -j100
[11:23] <ogra> unlikely, its an arm machine :)
[11:23] <ogra> do a local build
[11:23] <ogra> or is your babbage already packed
[11:23] <asac> fighting with the rootfs from scratch
[11:23] <asac> ;)
[11:23] <ogra> oh
[11:24] <ogra> whats wrong ?
[11:24] <asac> somehow the kernel .deb didnt get installed :(
[11:24] <asac> and initrd etc.
[11:24] <ogra> no, thats deliberate
[11:24] <asac> i used --kernel-image
[11:24] <ogra> it gerenates a "rootfs" not a complete image (yet)
[11:24] <ogra> ouch
[11:24] <ogra> i should mark that as beagleboard only
[11:24] <ogra> its from the beagle guys
[11:25] <asac> so you cannot create a usable image ;)
[11:25] <asac> nice
[11:25] <ogra> for their kernel that doesnt use initramfs nor postinst
[11:25] <ogra> it creates a rootfs
[11:25] <ogra> nothing more
[11:25] <asac> right. so one cannot create a working image ;)
[11:25] <ogra> kernel and initrd is usually completely board specific
[11:25] <asac> right. thats why i want to specify the .deb i want to run
[11:25] <ogra> the tool was written for boards we dont suppport :)
[11:26] <asac> yes, but installing an image is annoying. i want ubuntu-minimal
[11:26] <asac> i dont have any big storage
[11:26] <ogra> initially it wasnt inteded for boards for which we have images
[11:26] <asac> so all space counts
[11:26] <ogra> alternate ;)
[11:26] <asac> also i want everything on the same sd
[11:26] <asac> rootfs + bootfloppy
[11:26] <ogra> right
[11:26] <ogra> so use redboot-install for the bootfloppy part
[11:27] <ogra> then cfdisk to create the second partition
[11:27] <asac> well ;)
[11:27] <asac> i have the partition and stuff
[11:27] <ogra> then dump the rootfs onto the second partition
[11:27] <asac> what i really neded was a kernel
[11:27] <ogra> right, buut you need to do the kernel stuff first
[11:27] <asac> can i chroot into the mounted rootfs?
[11:27] <ogra> then create the rootfs partition
[11:27] <ogra> sure
[11:27] <asac> hmm
[11:27] <asac> how?
[11:28] <ogra> https://wiki.ubuntu.com/ARM/BabbageImageFromScratch
[11:28] <ogra> note its outdated
[11:28] <ogra> (i.e. kernel and initranfs need to come from elsewhere)
[11:29] <ogra> and the config changes work better with redboot-cmdline now
[11:29] <asac> do you have an up to date initram fs?
[11:30] <asac> etc. at ~ogra?
[11:30] <ogra> nope
[11:30] <ogra> use your qemu chroot ;)
[11:30] <asac> why cant i chroot in to the rootfs?
[11:30] <asac> with qemu?
[11:30] <asac> and then install the normal image?
[11:30] <ogra> oh, indeed you should be able to even boot it from SD with qemu
[11:30] <asac> ogra: how do i use that qemu chroot? i cannot chroot into it
[11:30] <asac> i mean ... the rootfs
[11:30] <ogra> huh ?
[11:31] <asac> i cannot chroot into it
[11:31] <asac> what command?
[11:31] <ogra> mount your SD
[11:31] <ogra> the just chroot into it
[11:31] <asac> that doesnt work ;)
[11:31] <asac> let me try again
[11:31] <ogra> it should
[11:31] <ogra> at least if you have qemu-arm-static installed
[11:31] <ogra> binfmt should just switch the arch
[11:31] <asac> ok me starts a new rootstock
[11:32] <asac> lost my other rootfs
[11:32] <asac> during reboot (/tmp)
[11:32] <ogra> ouch
[11:33] <ogra> qemu-arm-static makes no difference on SD or on local disk, it should always work to chroot into an arm root
[11:34] <ogra> btw, you could test my new redboot build while you're at it :)
[11:35] <asac> sure ;)
[11:36] <ogra> http://people.canonical.com/~ogra/arm/redboot-imx51-babbage_200952-0ubuntu1_armel.deb
[11:36] <asac> anyway. i have the feeling that all the docs should be consolidated ;)
[11:36] <asac> its all spread apart ;)
[11:36] <ogra> yes, they need updating
[11:36] <asac> and nothing on its own is as useful as it could be
[11:36] <ogra> no, its all in the /ARM namespace
[11:36] <asac> i didnt find the babbageimagefromscratch one
[11:36] <asac> but some other babbage thing ... which explained how to flash
[11:37] <asac> right. i will clean it up after going through it while i still see the problems with the docs
[11:37] <ogra> https://wiki.ubuntu.com/ARM/BabbageImageFromScratch?action=fullsearch&context=180&value=babbage&titlesearch=Titel
[11:37] <asac> ogra: hwat is new?
[11:37] <ogra> second hit if i search for babbage
[11:37] <ogra> titlesearch
[11:37] <asac> yes, but not if you search for rootfs ;)
[11:37] <ogra> heh, indeed
[11:38]  * ogra wonders where RootfsOnSDForBabbage comes from
[11:38] <asac> hmm there is https://wiki.ubuntu.com/ARM/RootfsOnSDForBabbage
[11:38] <asac> that wasnt there yesterday ;) ... at least for me
[11:39] <ogra> last change 2009-07-20
[11:39] <ogra> created by dyfet
[11:39] <ogra> BuildingBabbageRedBoot eek
[11:39] <ogra> that should vanish
[11:39] <asac> so it doesnt say anything about the kernel again
[11:39] <asac> RootfsOnSDForBabbage
[11:39] <ogra> people should use the packaged binaries
[11:39] <asac> e.g. again one part missing ;)
[11:40] <ogra> i'll update BabbageImageFromScratch soon
[11:40] <ogra> and drop all the old jaunty cruft
[11:40] <asac> maybe ...
[11:40] <ogra> its linked everywhere i post babbage instructions
[11:40] <asac> i think what should really be done is that rootstock can produce images ... or we write a roothouse wrapper  that does that
[11:41] <ogra> but was written for jaunty and updated for karmic
[11:41] <asac> yes.
[11:41] <ogra> right, but rootstock creating full images is rathera L+1 task
[11:41] <ogra> for now i'm happy if i switch to a plugin system and get the basics from the spec done
[11:42] <ogra> before lucid releases :)
[11:42] <asac> i can write the UI if you dont have time ... that should be quick
[11:42] <ogra> once thats there its easy to write a kernel plugin specific to the board you build for
[11:42] <ogra> yeah, lets sit down at the sprint for the UI
[11:42] <asac> right. pure C ;)
[11:43] <asac> lol
[11:43] <ogra> the changes i planned below UI are more elementar
[11:43] <ogra> so these need to be in place first
[11:43] <ogra> we have a wonderful plugin system developed for ltsp-build-client which essentially does the same as rootstock
[11:43] <ogra> i want to port rootstock to this
[11:44] <asac> some build systems just dont get it
[11:44] <ogra> the plugin system in ltsp enabled it to be distro agnostic
[11:44] <asac> mono always reconfigures on debuild -nc
[11:44] <asac> after a build failure
[11:44] <ogra> yeah
[11:44] <ogra> mono is evil
[11:44] <ogra> i maintained back in breezy and hoary
[11:44] <asac> thats a packaging bug
[11:44] <ogra> and was really happy to get rid of it
[11:44] <asac> config.status should be honoured
[11:45] <ogra> after that the packaging was completely taken over by debian
[11:45] <asac> yeah
[11:45] <ogra> and they completely redidi everything
[11:45] <ogra> i would have expected it to improve
[11:45] <ogra> but somehow that didnt happen
[11:45] <asac> as long as we can sync ;)
[11:45] <ogra> as long as it doesnt ftbfs :)
[11:46] <asac> haha .. yeah. but this is thumb2 ;)
[11:47] <ogra> hmm, for creating an initramfs inside a chroot for babbage we need to hack flash-kernel
[11:47] <ogra> or divert it to /bin/true
[11:48]  * ogra tries
[11:49] <asac> argh
[11:49] <ogra> ?
[11:49] <asac> so after reboot qemu is broken again
[11:49] <asac> ;)
[11:49] <asac> chroot: cannot run command `debootstrap/debootstrap': Exec format error
[11:49] <ogra> run the binfmt initscript
[11:50] <ogra> and try again
[11:50] <asac> seems all this doesnt like different kernels
[11:50] <asac> ok
[11:50] <ogra> i never had probs
[11:50] <ogra> and in karmic i even switched between -generic and -pae all the time
[11:50] <asac> umount: /proc/sys/fs/binfmt_misc: not mounted
[11:50] <asac> update-binfmts: warning: Couldn't unmount the binfmt_misc filesystem from
[11:50] <asac> /proc/sys/fs/binfmt_misc.
[11:50] <asac> i think i didnt even switch kernel
[11:50] <ogra> weird
[11:50] <asac> so guess its not related
[11:51] <ogra> smells buggy
[11:51] <asac> now binfmt is mounted at least
[11:51]  * asac runs again
[11:51] <ogra> we need to talk to cjwatson at the sprint about that
[11:51] <ogra> and take a deep look at your system
[11:52] <asac> if it works everywhere but here, i wont bother too much. probably has something to do with the upstream/init stuff
[11:52] <asac> upstart
[11:52] <ogra> well, do you run a different upstart than i ?
[11:52] <asac> not that i know ;)
[11:52] <asac> i try to keep my fingers off from that
[11:55] <ogra> heh
[11:55] <ogra> well, then it should cause this
[11:55] <ogra> i could imagine a mountall bug or something
[11:55] <ogra> that still seems shaky
[11:55] <asac> hmm. yeah
[11:55] <asac> but i don really mount much
[11:56] <ogra> but umount: /proc/sys/fs/binfmt_misc: not mounted somehow indictaes that something went wrong with mounting the binfmt handler fs
[11:58] <ogra> update-initramfs: Generating /boot/initrd.img-2.6.31-603-imx51
[11:58] <ogra> /bin/grep: /proc/cpuinfo: No such file or directory
[11:59] <ogra> mumble
[12:02] <ogra> asac, http://paste.ubuntu.com/365144/
[12:04] <ogra> surely not complete but the initrd creation works
[12:04] <asac> nice
[12:05] <ogra> and indeed you cant just use the chroot right away, there are a good bunch of config files missing and no user is created etc ... all the stuff rootstock does
[12:06] <asac> well. i want to use the rootstock fs
[12:06] <asac> not a manual chroot
[12:06] <asac> lets see ;)
[12:06] <ogra> but thate above could easily become a rootstock plugin later :)
[12:07] <asac> right
[12:07] <ogra> the prob is that redboot-install needs to repartition the SD
[12:07] <asac> ok unpacking the rootfs on sd
[12:07] <ogra> but to run it you need the initrd in advance
[12:07] <asac> hmm
[12:07] <ogra> so keep the tgz :)
[12:07] <asac> yeah
[12:07] <asac> lets see what happens ;)
[12:07] <ogra> run the above in the chrooted SD
[12:08] <ogra> or better tar the chrooted Sd up after running the above steps
[12:08] <ogra> then run redboot-install, create a new rootfs partition and untar it again
[12:08] <asac> so redboot-install will wipe all partitions?
[12:08] <ogra> yes
[12:08] <asac> ok
[12:08] <ogra> it needs to create a new MBR
[12:09] <asac> even if its mounted?
[12:09] <ogra> and a raw partiton
[12:09] <ogra> no idea, i guess parted will complain anyway
[12:09] <asac> will see
[12:09] <ogra> its a bunch of parted and dd calls
[12:09] <ogra> and fis
[12:09] <asac> so i rather should unpack the tgz on a host filesytem
[12:10] <asac> hmm
[12:10] <ogra> i should probably add a check that if the first parted call fails it exitst if it doesnt do that already
[12:10] <asac> nevermind ;)
[12:10] <ogra> i havent looked at redboot-tools for quite a while
[12:10] <ogra> but i'll do that during the sprint
[12:10] <asac> ok mono build continued long enough
[12:10] <asac> creating diff
[12:10] <asac> and checking if there are any logical bugs ;)
[12:11] <ogra> i plan to mostly do redboot, rootstock and powermanagement
[12:11] <ogra> and at least one build of the uboot git tree to check it
[12:11] <asac> ack
[12:11] <asac> nah. lets do uboot after a3
[12:11] <ogra> well, if its good enough i'D like to upgrade the poackage in the archive to the latest at least
[12:11] <asac> you can do that after a3 ;)
[12:12] <asac> plenty of time
[12:12] <ogra> to have a proper base in case we will need/use it later
[12:12] <ogra> yes, indeed
[12:12] <asac> lets try to make release team happy by getting the still important specs done as good as possible
[12:12] <ogra> uboot doesnt need to be sprint stuff ... but i'd like to check it before release
[12:12] <asac> and then do more after a3 without a blueprint ;)
[12:12] <ogra> right
[12:12] <asac> sure ... do that after a3 .. or even after beta1 .. depending how up-to-date we are
[12:13] <ogra> right
[12:13] <asac> argh
[12:13] <asac> the mono package sucks
[12:13] <asac> dpkg-source: error:   old version is plain file
[12:13] <asac> dpkg-source: error: cannot represent change to mono-2.4.3+dfsg/libgc/config.guess:
[12:13] <ogra> heh
[12:13] <asac> dpkg-source: error:   new version is symlink to /usr/share/automake-1.11/config.guess
[12:13] <asac> dpkg-source: error:   old version is plain file
[12:13] <asac> dpkg-source: error: cannot represent change to mono-2.4.3+dfsg/libgc/config.sub:
[12:13] <asac> dpkg-source: error:   new version is symlink to /usr/share/automake-1.11/config.sub
[12:13] <ogra> fun
[12:13] <asac> dpkg-source: error:   old version is plain file
[12:13] <asac> dpkg-source: error: cannot represent change to mono-2.4.3+dfsg/libgc/install-sh:
[12:13] <asac> trying to produce sources of a half build tree
[12:13] <asac> so i can get the diff out of the debdiff
[12:13] <asac> annoying
[12:13] <ogra> yeah
[12:13] <asac> cani tell debuild -S to ignore that?
[12:14] <ogra> i dont think so
[12:14] <asac> if it was quilt i would have everything done by now :(
[12:14] <ogra> depends on the packaging system i guess ... there is that cdbs-autotools crap that re-copies these files from the system ... i think that also adds such a check
[12:15] <asac> they dont use -c for autotools
[12:15] <asac> so it creates symlinks ;)
[12:15] <ogra> but it seems to use dh and autoconf, automake directly
[12:15] <asac> obviously ;)
[12:15] <ogra> should be possible to edit rules
[12:16] <asac> well ... non of my business ;)
[12:16] <asac> just want to get the diff :-P
[12:16] <ogra> unless there is a debhelper module
[12:16] <asac> you need to ask the dh7 fanatics ;)
[12:16] <ogra> well, dont make a debdiff, just make a diff :)
[12:16] <lool> ogra: I didn't break qemu-arm-static; it worked for me yesterday evening
[12:16] <ogra> and then ping directhex
[12:16] <ogra> lool, i was kidding :)
[12:16] <lool> I didn't do any repackaging recently; only FTBFS fixes
[12:17] <ogra> i know you didnt break it
[12:17] <ogra> we all do :)
[12:17] <ogra> lool, asac's machine soemhow doesnt properly set up binfmt on boot ... no issue with qemu-arm-static at all here
[12:18] <asac> yeah. we moved that in the "mountall" busted corner for now
[12:18] <ogra> heh
[12:18] <asac> hell. i feel like filing a serious bug against mono ;)
[12:18] <asac> more and more autotools symlinks left over after clean
[12:20] <asac> debian bug 528090
[12:20] <ubot4> Debian bug 528090 in mono-gac "mono-gac/mono-runtime: mini circular dependency hell" [Important,Fixed] http://bugs.debian.org/528090
[12:21] <asac> lol
[12:21] <ogra> hahaha
[12:21] <asac> bug 539807
[12:21] <asac> debian bug 539807
[12:21] <ubot4> Debian bug 539807 in mono "needlessly executable stack" [Normal,Open] http://bugs.debian.org/539807
[12:21] <asac> and we have that in main?
[12:22] <asac> o reported by kees ;)
[12:23] <ogra> even on the CD
[12:26] <asac> ogra: http://people.canonical.com/~pitti/workitems/canonical-mobile-lucid-alpha-3.html ... seems the status shows up there
[12:26] <asac> "blocked on uboot bugs."
[12:27] <ogra> sweet
[12:27] <asac> maybe i should maintain the status for the specs properly
[12:27] <ogra> and we're below trend
[12:28] <asac> ogra: hmm. i dont think that foreign can be discarded
[12:28] <ogra> but i still have three todo's on the list
[12:28] <ogra> for that spec
[12:28] <ogra> the two bugs and the MIR
[12:28] <asac> also ... we are posponing all the time ;)
[12:28] <asac> i am not sure what to do for the bugs
[12:28] <asac> let me check
[12:28] <ogra> we need to somehow postpone these three too
[12:29] <ogra> i think its because they are duplicated under "Work items lucid-alpha-3"
[12:29] <ogra> delete that section and we should be fine
[12:30] <ogra> ah, no, the bugs need to be unmilestoned
[12:30] <ogra> and the INPROGRESS item needs to become POSTPONED
[12:30] <ogra> then they should be gone
[12:33] <asac> ok another batch of symlinks removed from mono :(
[12:33] <asac> guess it would have been faster to copy the .h files i changed
[12:33] <asac> ogra: i set to wont fix and milestone later for the main task now
[12:33] <asac> lets see
[12:34] <ogra> if that works
[12:34]  * ogra tries to find his ESTA number for his travel notes
[12:37] <ogra> asac, i'll be at the vet. from 16:15 on, i might be to late for the release meeting (though trying to make it and indeed we're usually up at 17:30 anyway)
[12:38] <asac> JamieBennett: maybe here
[12:38] <asac> ogra: thx for heads up. i will survive without you i guess ;)
[12:38] <ogra> yeah, i guess i'm there anyway, but you never know
[12:38] <asac> ogra: btw, NCommander said that dove X0 doesnt fix things :(
[12:38] <ogra> hmm, ericm_ said something different
[12:39] <asac> when?
[12:39] <ogra> when he tested at marvell directly
[12:39] <ogra> he was over there working with a marvell engineer
[12:39] <asac> right. but the news from yesterday came through NCommander but he said that that was new findings from ericm_
[12:39] <ogra> bah
[12:39] <asac> anyway. dont panic ;)
[12:42] <JamieBennett> I'm here
[12:44] <ogra> i never panic
[12:44] <ogra> people just accuse me to
[13:29] <lool> asac, ogra: I think you guys asked for devtmpfs to be backported; could you tell me who told you that was the only way?  I'm interested in the rationale because I hit this too and I've filed a bug about this, but couldn't find yours
[13:29] <lool> Also which kernel is this and why isn't it .32?
[13:33] <asac> lool: for fsl we go for .31
[13:33] <asac> thats where the backporting effort stems from
[13:34] <asac> persia: did a website with the items
[13:34] <asac> guess we didnt open bugs
[13:56] <lool> asac: What was the rationale for the backport?
[13:57] <lool> That it didn't boot with mountall/upstart
[13:57] <lool> ?
[14:09] <asac> lool: ogra requested it iirc
[14:10] <asac> let me see if i can find the wiki
[14:20] <ogra> lool, it did boot, it just boots 2 sec slower if the udev scripts are used instead of devtmpfs and initramfs's init spits out an error on boot
[14:20] <ogra> lool, Bug 512321
[14:20] <ubot4> Launchpad bug 512321 in linux-mvl-dove "please backport devtmpfs to the lucid linux-imx51 kernel tree" [Undecided,Fix committed] https://launchpad.net/bugs/512321
[14:21] <lool> Oh you're using an initramfs too
[14:22] <lool> That's why it booted
[14:22] <lool> Ah!  mknod /dev/console and /dev/null; exactly the problem I was hitting
[14:23] <lool> I'm pretty sure not having the devtmpfs slows down by much more than 2 seconds
[14:23] <lool> MAKEDEV on so many devices takes two seconds on my x86-64 laptop!!
[14:23] <ogra> well, 2sec was what i could measure on the babbage using a stopwatch
[14:23] <lool> In qemu, it's more in the 20 seconds
[14:23] <ogra> phew
[14:24] <ogra> was that your issue with the in-archive versatile kernel ?
[14:24] <ogra> i.e. does it fix it ?
[14:24] <ogra> we should just enable it in versatile by default
[14:24] <ogra> since thats .32 there shouldnt be an issue
[14:24] <lool> I don't know what prevents the in-archive versatile kernel from booting; the biggest issue I have is that it lacks video output
[14:24] <lool> The config for that is pl110 IIRC
[14:25] <ogra> well, i still havent tried it and i doubt i'll get to it today, but i'm planning a lot of rootstock work during the sprint so we'll get it sorted there
[14:26] <lool> pl110
[14:41]  * asac wonders if its worth adding a configure test for gcc intrinsics to mono ... or just use ith if __thumb__
[14:42] <asac> #ifdef __thumb__
[14:45] <asac> what arm/thumb asm reference is good?
[15:23] <asac> bug 511197
[15:23] <ubot4> Launchpad bug 511197 in busybox "fails to build on arm lucid (thumb2)" [Undecided,Fix released] https://launchpad.net/bugs/511197
[15:27] <dmart> asac: Take a look at https://wiki.ubuntu.com/ARM/Thumb2PortingHowto - I'm still writing it, so any comments on whether this is any use / what else we need are welcome.
[15:29] <asac> dmart: too bad you havent written the swp instructions yet ;)
[15:29] <asac> could have checked if i did it right
[15:30] <asac> dmart: do you thin its worth hacking configure to check for gcc atomic builtins?
[15:30] <asac> or just __thumb__ ?
[15:30] <dmart> You might be able to pull the atomic builtin check out of glib2.0
[15:30] <asac> hmm. yeah
[15:31] <asac> patching configure is always annoying ;)
[15:31] <asac> packaing wise ... but ok
[15:36] <asac> bug 456659
[15:36] <ubot4> Launchpad bug 456659 in linux-fsl-imx51 "suspend/resume failure on imx51" [High,Confirmed] https://launchpad.net/bugs/456659
[15:37] <ogra> fixed
[15:38] <ogra> why is that confirmed ... hrm
[15:38] <ogra> oh, the bot reads the karmic info
[15:41] <dmart> asac: the main issue is people using tools which may not have the atomic builtins support (Debian possibly, and other 3rd parties).  I think pretty much everyone is on a new enough kernel these days (2.6.16?)
[15:43] <asac> plars: do you have the nautilus crasher at hand?
[15:43] <asac> the bug id ;)
[15:43] <asac> chromiums awesome bar is not that great i have to say
[15:43] <ogra>  Bug 512959
[15:43] <ubot4> Launchpad bug 512959 in gvfs "nautilus assert failure: *** stack smashing detected ***: nautilus terminated" [High,Confirmed] https://launchpad.net/bugs/512959
[15:43] <ogra> asac, did your imx SD experiment work ?
[15:43] <asac> yeah
[15:46] <asac> did i say yeah
[15:46] <asac> not to that
[15:46] <asac> i didnt finish that yet :)
[15:46] <ogra> ah
[15:46] <ogra> i noticed the yeah came to fast to refer to that :)
[16:02] <plars> asac: do you want me to go through and target all of those "port to thumb2" bugs?
[16:02] <plars> asac: milestone them rather?
[16:05] <ogra> hrm, my löaptop doesnt see its LCD panel anymore
[16:05] <asac> plars: good question
[16:05] <ogra> only the external monitor
[16:06]  * ogra wonders if he should travel with his 24" screen now
[16:06] <asac> plars: i think so ...
[16:06] <asac> plars: i think we can mark the mono bug as a dupe
[16:08] <plars> asac: are you talking about bug 514215 and bug 513736 ?
[16:08] <ubot4> Launchpad bug 514215 in mono "mono ftbfs with thumb2 on armel" [Critical,Triaged] https://launchpad.net/bugs/514215
[16:08] <ubot4> Launchpad bug 513736 in mono "[arm] needs porting to thumb2" [Undecided,New] https://launchpad.net/bugs/513736
[16:10] <asac> plars: yeah
[16:10] <asac> i documented 514215 in the upload i was preparing
[16:11] <asac> but i can use the other
[16:11] <asac> though the other is now on release page
[16:11] <plars> asac: ok, I'll milestone them all for A3 for now, we can push later if we need to but these might be a good thing to assign out to people and try to hammer them out next week
[16:12] <plars> asac: np, I'll make 514215 the master and dup the other one to it
[16:12] <asac> thx
[16:26] <plars> asac: bug 514252
[16:26] <ubot4> Launchpad bug 514252 in qemu-kvm "[arm] (might) need porting to thumb2" [High,Triaged] https://launchpad.net/bugs/514252
[16:26] <plars> asac: qemu-kvm? why are we even trying to build that on armel?
[16:28] <ogra> plars, lool would like to sse it working and at some point when armel HW is powerful enough it might help with apps that cant be ported
[16:28] <ogra> *see
[16:28] <ogra> i.e. wine
[16:29] <plars> ogra: interesting, so we expect to maybe have kvm support on arm someday? that would be cool
[16:29] <asac> hmm. not sure
[16:29] <asac> just made the bugs from the review list
[16:29] <asac> feel free to move that to medium or something
[16:29] <ogra> i would have taken it off armel long ago but technically there is no actual reason to do so, lool is right here
[16:29] <asac> if its currently not runnig at all
[16:29] <asac> or even low
[16:29] <ogra> plars, there are roumors about kvm being ported to armel but i have never actually seen any work on it
[16:30] <ogra> for a start it would have to build even without kvm
[16:30] <ogra> asac, plars, low feel appropriate
[16:30] <ogra> *feels
[16:31]  * ogra tries to get used to his laptop kbd again
[16:31] <ogra> havent used that for a while
[16:49] <dmart> plars: Hi - SHouldn't we be cautious about marking the new Thumb-2 porting bugs as duplicates of existing bugs?  The new porting bugs are more general; I'm wondering if there's a risk if addressing only the more specific issues in the pre-existing bug and forgetting about the rest.
[16:49] <dmart> The new porting bugs are not just about ftbfs; there are also some "may build but might not work properly" and some future proofing issues.
[16:50] <plars> dmart: I copied over the information from the old bug to make sure that not only the ftbfs was addressed, but also the more general porting issues.
[16:51] <plars> dmart: asac mentioned to me that he thought it was good to combine the two, perhaps it warrants further discussion though
[16:51] <dmart> Oh, OK - that's fine.  I hadn't read everything yet, just saw the mails coming in.
[16:51] <plars> dmart: yeah, sorry for the spamfest :)
[16:51] <dmart> Yes, I think combining them is sensible
[16:51] <dmart> No problem about the spam, I started this off anyway :)
[16:53] <ogra> in cases where ftbfs can only be fixed to full porting work i guess it ok to merg such bugs
[16:53] <ogra> s/to/through/
[16:56] <dmart> Anyone interested, please take a look at https://wiki.ubuntu.com/ARM/Thumb2PortingHowto and see whether it looks likely to be useful and understandable, whether it looks like there's anything missing (bearing in mind I'm still writing...)
[16:56] <dmart> We can link this from the porting bugs (though I don't mind doing that later)
[17:24] <asac_> err
[17:24] <asac_> ogra: http://paste.ubuntu.com/365282/ :/
[17:51] <lool> asac, ogra: Note that qemu-kvm is not only about kvm but also about qemu, and qemu builds on all arches in Debian
[17:57] <asac> lool: yes. what we found was arm code that wouldnt be thumb safe ... thats all. if you know thats used/not used, fix/invalidate the bug etc.
[17:57] <asac> also unassign etc. ... whatever you think is ok ;)
[18:03] <lool> asac: Well I think it's a real bug that our Ubuntu qemu doesn't build on an official arch (armel) when it does in Debian; it didn't build in karmic either though
[18:04] <asac> lool: anything we can do there?
[18:04] <asac> remember that there was kind of a tie
[18:04] <asac> with server team wanting something that breaks us
[18:05] <lool> I don't remember that
[18:05] <lool> I know we're not using the exact same upstream as Debian (qemu-kvm !- qemu)
[18:05] <lool> s/!-/!=
[18:05] <asac> yeah
[18:05] <asac> and that was done by server team, right?
[18:05] <lool> Yes
[18:05] <asac> so thats what i remember ;)
[18:06] <asac> why didnt they add a second source package?
[18:06] <lool> Well my point stands: this program should build on armel, even if it's a slightly different branch
[18:06] <asac> hmm. they did it seems
[18:06] <lool> qemu-kvm pulls fomr qemu regularly
[18:06] <asac> ;)
[18:06] <asac> yeah
[18:06] <asac> agreed
[18:06] <asac> so we have it on ftbfs list?
[18:06]  * asac checks
[18:06] <lool> Yes
[18:07] <asac> ok its not armel only
[18:07] <asac> thats probably why noone started on that
[18:07] <lool> I'm just explaining why it deserves to be tracked: it's a real bug and regression over Debian caused by the Ubuntu changes
[18:07] <lool> The issues are wildly different depending on the arch
[18:07] <asac> ok the build failure we have atm is atomics
[18:07] <asac> so covered by the thumb2 bug
[18:08] <lool> I looked at all Ubuntu arches in karmic and fixed the first issue of each arch, but there was at least one more issue on each arch after each fix
[18:08]  * asac checks what broke karmic
[18:08] <lool> And each fix I applied was different
[18:08] <lool> The current failure is earlier than the karmic one, so it's *another* regression on top of the karmic one, introduced by T2
[18:08] <asac> /build/buildd/qemu-kvm-0.11.0/linux-user/elfload.c:289: error: conflicting types for 'elf_greg_t'
[18:08] <asac> /usr/include/sys/procfs.h:39: note: previous declaration of 'elf_greg_t' was here
[18:08] <asac> /build/buildd/qemu-kvm-0.11.0/linux-user/elfload.c:295: error: conflicting types for 'elf_gregset_t'
[18:08] <asac> /usr/include/sys/procfs.h:46: note: previous declaration of 'elf_gregset_t' was here
[18:08] <asac> /build/buildd/qemu-kvm-0.11.0/linux-user/elfload.c:1782: error: redefinition of 'struct elf_siginfo'
[18:09] <asac> /build/buildd/qemu-kvm-0.11.0/linux-user/elfload.c:1788: error: redefinition of 'struct elf_prstatus'
[18:09] <asac> /build/buildd/qemu-kvm-0.11.0/linux-user/elfload.c:1807: error: redefinition of 'struct elf_prpsinfo'
[18:09] <asac> yeah
[18:09] <asac> is linux-user a copy of some other package/source ?
[18:09] <asac> hmm
[18:12] <lool> linux-user is the qemu mode used in qemu-arm-static
[18:12] <lool> It's the syscall emulation mode
[18:13] <lool> It's copied during the build for all targets


[00:04] <Len-nb> zequence, kdenlive pushed iso size up 0.1G, no complaints from me.
[00:05] <Len-nb> Now that we have crossed the kde libs bridge... there may be other kde apps that make sense.  ;)
[00:06] <Len-nb> It seems to me there was a photography app we did not include for the same reason.
[00:13] <Len-nb> digikam maybe?
[00:34] <falktx> digikam is very nice
[00:34] <falktx> k3b maybe?
[00:36] <Len-nb> :) I wondered how log it would take .
[00:37] <Len-nb> I never did check if bassero got fixed.
[00:38] <Len-nb> *brasero
[00:38] <Len-nb> I have heard good things about K3B though.
[00:39] <Len-nb> Still would like something like gdcmaster.
[03:00]  * holstein is about to paste some info here
[03:01] <holstein> 21:59 < las> Thu Dec 27 20:15:43 2012: Starting jack server... Thu Dec 27 20:15:43 2012: JACK server starting in realtime mode  with priority 1 Thu Dec 27 20:15:43 2012: control device hw:0 Thu Dec 27 20:15:43 2012: control device hw:0 Thu  Dec 27 20:15:43 2012: ERROR: Failed to acquire device name : Audio0 error : Cannot allocate memory Thu Dec 27
[03:01] <holstein>  20:15:43 201: ERROR: Audio device hw:0 cannot be 1acquired... Thu Dec 27 20
[03:01] <holstein> appologies for the formatting.. i just want us to look it over
[03:02] <holstein> 21:57 < las> holstein: it apears from several reports here and on #jack recently that ub 12.04 has been packaged so that if  you only install pulse + jack, device negotiation does not work
[03:02] <holstein> 22:00 < las> holstein: then you install pulseaudio-jack-sink or whatever it is called and the "Failed to acquire device name"  starts working
[03:03] <holstein> ScottL__ Len-nb zequence  ...any ideas?
[03:03] <holstein> las says its a packaging issue on our end
[03:04] <holstein> if this is the case, we could just ask JACK to pull in the *-sink package as a dep
[03:19] <ScottL__> holstein, i don't have a clue to be honest
[03:20] <ScottL__> are they installing jack & pulse in vanilla ubuntu 12.04, holstein ?
[04:15] <falktx> why not just put the pa*-jack stuff in the metas?
[06:47] <len-1304> I had ubiquity use our logo for ubuntustudio partitions today.
[06:48] <len-1304> Just waiting for the -settings to get uploaded.
[09:33] <zequence> holstein: That's more of a packaging issue on Debian end
[09:33] <zequence> and I'm not sure if that's a problame with jackd or pulseaudio
[10:05] <zequence> Len-nb: training.linuxfoundation.org/free-linux-training/linux-tutorials-and-videos/diagnose-power-consumption-with-powertop
[10:24] <zequence> OSX apps on Linux http://darling.dolezel.info/en/Darling
[13:09] <scott-work> holstein: did we ever find out if people experiencing the pulse-jack issue were starting with vanilla ubuntu? also do we know what card is being used?
[13:10] <scott-work> in my half-awake/half-asleep state before the alarm i thought about the audio group as well
[13:10] <scott-work> i'm not sure what data laz is using to determine this may be a packaging bug
[14:10] <len-1304> zequence, scott-work I think what is happening when installing jackd over a generic kernel is that it does not even ask if it will run realtime because it can't.
[14:10] <len-1304> So the lowlatency kernel needs to be installed _and_ booted before jackd is installed
[14:12] <len-1304> or we need a script that fixes things or informs the user what they need to do.
[14:14] <len-1304> It could be called packaging, except that jackd can run in a non-rt environment.
[14:14] <len-1304> For example just to allow the use of a FW audio IF.
[14:15] <len-1304> The thing is, there is no such thing as having jackd just work out of the box in all conceivable applications.
[14:19] <len-1304> The instructions for putting US audio over vanilla should be:
[14:20] <len-1304> install lowlatency kernel
[14:20] <len-1304> remove generic kernel
[14:20] <len-1304> then install metas
[14:20] <len-1304> oopps... reboot then install metas.
[14:26] <scott-work> hmmmm. i have installed jack over a vanilla install before, added myself to the audio group, and had jack start with -rt privileges
[14:27] <scott-work> otherwise jack throw error messages and fail to start
[14:27] <scott-work> i wonder if something has changed
[14:45] <len-1304> scott-work, it seems if jackd can't lock memory for buffering when in RT mode it fails.
[14:46] <len-1304> Rather than trying with non-lockable memory and starting in non-rt it just fails.
[14:47] <len-1304> but it doesn't stop at the memory alloc, it keeps going and because there is no memory set aside for the device, the device is "not there"
[14:50] <len-1304> With jackd, the first error message has to be dealt with first, but most users look at the last error message. (which they understand)
[16:08] <zequence> len-1304: scott-work There are different issues being discussed here, but what las was talking about was..
[16:08] <zequence> when starting jackd, pulseaudio should release the audio device
[16:08] <zequence> with or without pulseaudio-module-jack
[16:08] <zequence> as for realtime privilege, that is another issue all together
[16:10] <zequence> I don't know what code was responsible in letting jackd grab the card from PA in the past, but it seems this may have changed recently
[16:10] <zequence> There is also the bug with jackdbus not closing properly to take into account
[16:11] <zequence> and to clarify, I'm not talking about the pulseaudio-module-jack module
[16:11] <zequence> or, it is not a factor in this problem
[16:12] <zequence> It should only need to be installed if one wants to have PA auto connect to jack
[16:15] <zequence> len-1304: jackd realtime operation is not depending on the kernel
[16:15] <zequence> you can achieve realtime with any kekrnel
[16:15] <zequence> kernel*
[16:16] <zequence> It's just that you get better performance at lower latencies with -lowlatency
[16:17] <zequence> installing jackd is the same on any kernel
[16:47] <scott-work> zequence: "letting jackd grab the card from PA" - i believe starting at 8.04, qjackctl including a wrapper script that would run 'pasuspender' that would suspend pulse audio
[16:48] <scott-work> i forget when, but i think it was when jackd starting using dbus that this practice stopped, david h. made that change i believe
[16:49] <scott-work> zequence: also, your description of -rt behaviour aligns with my experience as well with regards to kernels, the -pa module
[17:15] <zequence> the use of the wrapperpper did stop at some point
[17:15] <zequence> But, I don't think it was related to dbus
[17:15] <zequence> and definately not pulseaudio-module-jack
[17:18] <zequence> starting jackd (not jackdbus) and without pulseaudio-module-jack lets jackd grab the audio device from pulseaudio on 12.04
[17:19] <scott-work> ach. webchat dropped me and i missed conversation. i'll check logs.
[17:19] <zequence> scott-work: you didn't miss anything
[17:19] <scott-work> oh. good :)
[17:20] <zequence> the only time when it fails is when PA is using the device for something
[17:21] <scott-work> zequence: oh. i just thought of something. qjackctl uses dbus by default (i believe). if paul (and others) are starting jackd wihtout qjackctl then we may have a problem
[17:21] <zequence> scott-work: It's not related to qjackctl
[17:22] <zequence> jackd, without dbus grabs the card on 12.04. no problem. unless PA is busy streaming audio to the device
[17:23] <scott-work> does that address paul's question or error? i don't remember the exact error actually
[17:23] <zequence> I don't think las actually knows how jackd is configured on Debian/Ubuntu
[17:24] <zequence> scott-work: las arguments about Debian packaging problems holds little weight without a further explanation of the problem. Right now, it could be someone just misunderstood something, and there's no bug at all
[17:24] <zequence> what holstein pasted about the error does not tell much
[17:25] <zequence> Let me check jackd behaviour on 12.10 and 13.04 when I come home
[17:25] <zequence> I'm still in Switzerland
[17:27] <zequence> I remember someone saying something about the device grabbing being coded either into jackd or PA
[17:27] <zequence> on 12.04, it works as expected
[17:33] <scott-work> my thought was that if debian/ubuntu expected users to default to qjackctl to start/use jack and therefore use dbus, then perhaps pulse was configured to only play nice with dbus. therefore, if paul or others start jack from command line or ardour without dbus then pulse may not let the device go
[17:33] <scott-work> of course, i am neither an expert or played much with pulse/jack in recent version as i had in the past
[17:34] <zequence> scott-work: As I said, jackd starts just fine from the command line
[17:34] <zequence> And I don't think las uses Ubuntu. That's the impression I get
[17:35] <zequence> I still need to check 12.10 and 13.04. There's a newere pulseaudio to consider also
[17:40] <zequence> seems that jackd1 does not start for me either way, and it objects about bad settings, but by looking in the wrong place
[17:43] <zequence> the jackd1 problem is unrelated to PA alltogether though
[17:48] <zequence> falktx: Do you know how jackd negotiates with pulseaudio to have it release the audio device
[17:49] <falktx> I know it uses dbus
[17:49] <falktx> so it only works with jack2 and with dbus version
[17:50] <zequence> falktx: but it's not just when starting jackdbus. also when starting jackd (jackd2)
[17:51] <falktx> no
[17:51] <falktx> starting jackd the usual way, ie:
[17:51] <falktx> jackd -d alsa ...
[17:52] <falktx> will not work
[17:52] <falktx> if it does, it's pure luck
[17:52] <zequence> falktx: It works everytime, unless PA is streaming audio
[17:53] <falktx> afaik it's not how it was supposed to work
[17:53] <falktx> this are different things then
[17:53] <falktx> the jackdbus reservation trick works even when pulseaudio apps are running
[17:54] <zequence> I'm not talking about the PA sink and source. Just having PA release the audio device
[17:54] <falktx> in which case pulseaudio lets jackdbus start with its device and then pulseaudio auto-activates its jack PA sink/source
[17:54] <falktx> oh, ok
[17:58] <zequence> maybe PA is not actually grabbing it, when idle. I'll look into it some day. Now I'm eating pancakes
[18:00] <falktx_> damn my internet
[21:19] <zequence> In jackd2 source, there's some Poettering code, for letting PA and jackd negotiate for an audio device
[21:19] <zequence> http://git.0pointer.de/?p=reserve.git;a=blob;f=reserve.txt
[21:20] <zequence> in the jackd2 source, it's in dbus/reserve.c, dbus/reserve.h
[21:23] <zequence> Whatever audio server that has the highest priority (not sure yet how and where prio is set for this particular parameter), will get control of the audio devicce
[21:25] <zequence> It's done through dBus, but this is not to be mixed up with pulseaudio-module-jack, which is something entirely different
[21:30] <astraljava> Damn. I've been away for the True Programming for too long. Your analytical bisecting of the audio stack makes me wet myself. I need to get back in the game, NOW!
[21:32] <zequence> :(. I wish one had more lives to spend on learning this stuff..
[21:35] <astraljava> Indeed. I have had the passion to really get into the linux audio for so long, but I've had too many obstacles (mostly in my mind). And yet again I'm fighting professional issues, that take away from the technical pool, not allowing to concentrate on Stuff That Matter™.


[12:57] <Riddell> anyone doing ubuntu weekly newsletter this week?
[01:00] <LaserJock> have no idea
[02:06] <Burgundavia> Riddell, LaserJock: yes, myself, but I will working on it later
[02:07] <Burgundavia> feel free to work on it
[10:15] <rob> hey, is the wiki down at the moment?
[10:26] <poningru> yeah
[10:26] <poningru> cant do uwn :(
[11:21] <mdke> nixternal: I didn't say it was acceptable, you asked why so I told you
[08:42] <fredl> is anybody here with access to www.ubuntu.com ?
[08:43] <Burgundavia> fredl: yes, what is the issue?
[08:43] <fredl> Burgundavia, yesterday I helped somebody solve the xorg problem, he only had access to a http proxy server.
[08:44] <Burgundavia> yep
[08:44] <fredl> The document at http://www.ubuntu.com/FixForUpgradeIssue could be updated to have 'export http_proxy=http://server:port' in there so people who only have access through a proxy can upgrade the server
[08:46] <fredl> most people don't know that apt supports that, although I'm not sure many people will read that page from textmode.
[08:47] <Burgundavia> right
[08:47] <Burgundavia> can you file a bug against ubuntu-website?
[08:47] <Burgundavia> I am not really wanting to change that page
[08:48] <fredl> sure I can, but how come you don't want to?
[08:48] <Burgundavia> because I didn't create or edit that page
[08:48] <Burgundavia> and I don't have time to test what you just said, so I won't add it
[08:49] <trappist> I didn't know apt respected http_proxy - I thought it had to be configured specifically for apt
[08:50] <Burgundavia> trappist: indded
[08:51] <fredl> trappist - nope, it works. I dunno if #ubuntu is logged, but you can check it in the log if it's there. The guy was going through pains to get the newest xorg through his iPod, and I told him to just export http_proxy instead and it worked.
[08:51] <trappist> fredl: I have logs, but... please feel free to file that bug yourself.  I file bugs all the time on things I have no involvement in.
[08:51] <fredl> anyway, where do I file a bug against ubuntu-website?
[08:52] <Burgundavia> on launchpad, against the product ubuntu-website
[08:55] <fredl> hmm can't find that package...
[08:58] <fredl> ok filed.
[08:58] <fredl> ciao
[09:44] <Burgundavia> crimsun: you around?
[10:47] <nalioth> howdy y'all
[10:47] <nalioth> is the wiki undergoing downtime or something?
[11:06] <nalioth> is there anyone here?
[11:06] <LaserJock> kinda
[11:06] <nalioth> the *#&&@#$($ bug reporting site won't let me file a bug
[11:07] <LaserJock> and I have no idea
[11:19] <mdke> the wiki works fine for me
[11:19] <mdke> it was down yesterday but is up since this morning
[11:20] <nalioth> i just got a wildly colored moinmoin breakdown.  i filed a bug
[11:21] <mdke> you got a traceback?
[11:22] <mdke> where did you file the bug, and do you know what caused the problem?
[11:23] <mdke> is it like bug 57894?
[11:23] <Ubugtu> Malone bug 57894 in ubuntu-website "Ubuntu Wiki Error: "IndexErrorstring index out of range"" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/57894
[11:23] <nalioth> why am i getting an email for the bug i filed?
[11:24] <mdke> that's how the bug tracker works, it sends you email
[11:24] <nalioth> mdke:  it's number 57920
[11:26] <mdke> yes, looks the same as the one above
[11:26] <nalioth> i didn't understand the above description, or i'd have confirmed it instead of filing a new one
[11:27] <mdke> well, the error is identical
[11:29] <mdke> hopefully someone will look at it soon
[11:30] <nalioth> i prefer plain english descriptions to the above (which i can't understand)
[11:31] <mdke> jolly good
[11:43] <nalioth> ok, "This bug is not an ubuntu error."  WHERE does one file bugs against the websites ?
[11:45] <LaserJock> the ubuntu website
[11:45] <LaserJock> ?
[11:45] <LaserJock> I think that is ubuntu-website
[11:45] <nalioth> LaserJock: that doesnt work, seveas suggested it
[11:46] <Seveas> nalioth, I gave you the complete url later on
[11:46] <Seveas> /products/ubuntu-website/+filebug
[11:47] <nalioth> Seveas: ty
[12:02] <crimsun> Burgundavia: pong