[12:07] <mup> PR snapcraft#4030 opened: requirements: update craft-parts to 1.15.3 <Created by cmatsuoka> <https://github.com/snapcore/snapcraft/pull/4030>
[12:09] <mup> PR snapd#12358 closed: apparmor: revert "apparmor: disable vendoring again" <⛔ Blocked> <Run nested> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/12358>
[12:59] <mup> PR snapd#12545 opened: i/b/fwupd: allow reading host os-release <Created by valentindavid> <https://github.com/snapcore/snapd/pull/12545>
[16:40] <mup> PR snapd#12546 opened: interfaces/network-manager: do not show ptrace read denials <Needs security review> <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/12546>
[18:28] <mup> PR snapcraft#4029 closed: lint: reformat for black 23.1.0 <Created by mr-cal> <Merged by mr-cal> <https://github.com/snapcore/snapcraft/pull/4029>
[18:33] <mup> PR snapcraft#4031 opened: requirements: pin setuptools<66 <Created by mr-cal> <https://github.com/snapcore/snapcraft/pull/4031>
[19:31] <mup> PR snapd#12547 opened: apparmor: allow to read /proc/self/map_files <Created by sergio-costas> <https://github.com/snapcore/snapd/pull/12547>
[19:48] <mup> PR snapcraft#4032 opened: requirements: update craft-providers to 1.7.2 <Created by mr-cal> <https://github.com/snapcore/snapcraft/pull/4032>
[22:43] <mup> PR snapcraft#4031 closed: requirements: pin setuptools<66 <Created by mr-cal> <Merged by mr-cal> <https://github.com/snapcore/snapcraft/pull/4031>
[22:43] <mup> PR snapcraft#4033 opened: build(deps): bump cryptography from 3.4 to 39.0.1 <dependencies> <python> <Created by dependabot[bot]> <https://github.com/snapcore/snapcraft/pull/4033>


[01:04]  * BUGabundo make.clone( BUGabundo ) | /dev/bed/BUGabundo
[10:18] <andv> eagles0513875, you can't push stuff to ~mozilla-extensions-dev branches
[10:18] <eagles0513875> andv: O_o i thought i did something wrong
[10:19] <andv> plus please do not push stuff there
[10:19] <andv> it's for team members only and for mature branches
[10:19] <eagles0513875> andv: asac told me to make the commit
[10:19] <andv> yes, on your own branch maybe
[10:20] <andv> anyway you just started using bzr, I don't want all branches to be messed up
[10:20] <andv> :)
[10:20] <eagles0513875> sry
[10:20] <eagles0513875> :(
[10:20] <eagles0513875> does it need to be recommitted?
[10:20] <andv> where?
[10:20] <eagles0513875> to bzr does bindwood need to be recommited in the right location or did you fix it
[10:21] <andv> which is the right location?
[10:21] <andv> if you pushed it to your own branch, you should see it
[10:21] <eagles0513875> when i did it i typed this bzr commit lp:~eagles051387........  thing is see it where
[10:21] <andv> anyway I saw some errors in the log I saw from you
[10:21] <eagles0513875> andv: asac said it was ok
[10:22] <eagles0513875> i was pastebinning it to him before committing
[10:22] <andv> it's not ok
[10:22] <andv> ;)
[10:23] <eagles0513875> O_o im confused andv
[10:23] <andv> plus you don't use bzr commit to push stuff
[10:23] <andv> it's bzr push lp:what/ever
[10:24] <andv> eagles0513875:
[10:24] <eagles0513875> humm
[10:24] <andv> 1) bzr branch name is wrong
[10:24] <eagles0513875> i copied what asac had posted here in chat
[10:24] <andv> 2) mozilla-devscripts should be 0.15~
[10:24] <andv> 3) changelog is not well formatted
[10:24] <andv> 4) xpi:depends should *not* be in depends
[10:25] <eagles0513875> then what on earth was asac saying it was alright for O_o
[10:25] <andv> jonathan<EMAIL_ADDRESS>[10:25] <andv> is wrong
[10:25] <andv> should be name surname<EMAIL_ADDRESS>[10:26] <andv> you don't need to add [ Jonathan Aquilina ]
[10:26] <andv> if you are the only one who touched it
[10:26] <andv> that's needed when there are more than 2 ppl touching the package
[10:26] <eagles0513875> ahhh ok
[10:26] <andv> e.g [ name surname ]
[10:26] <andv> changes
[10:26] <andv> [ name1 surname1 ]
[10:26] <eagles0513875> so when there is a version change for instance
[10:26] <andv> changes
[10:27] <andv> no
[10:27] <andv> when there are more than one-two ppl touching the package
[10:27] <eagles0513875> ok
[10:27] <andv> so that everyone knows who worked on what
[10:27] <eagles0513875> ok
[10:28] <andv> that's why I told you to not push on team branch
[10:28] <andv> (you can't anyway)
[10:28] <eagles0513875> ahhhh ok well my apologies :(
[10:28] <eagles0513875> if you will be here this afternoon ill correct my mistakes
[10:28] <andv> np, you didnt push to the team so it's ok
[10:29] <andv> dunno, don't think so, maybe this evening yes
[10:30] <eagles0513875> ok just ping me i got nothing planned cept to get ready for part 2 of my linux cert
[10:30] <eagles0513875> where did bzr commit put it anyway
[10:31] <andv> to bindwood.ubuntu.lp21345 (some numbers)
[10:31] <andv> http://bazaar.launchpad.net/~eagles051387/bindwood/bindwood.ubuntu.lp425631/revision/19
[10:37] <eagles0513875> thats where it went to
[10:39] <andv> yep
[10:40] <eagles0513875> wass trying to find where it went
[13:05] <BUGabundo> morning
[13:15] <BUGabundo> asac: here is a fresh trace http://paste.ubuntu.com/274627/
[13:15] <BUGabundo> :((((
[13:16] <BUGabundo> please HELP me target this segfaults
[19:35] <BUGabundo> asac: fta: http://paste.ubuntu.com/274824/ fresh. firefox 3.7, no addons enabled, turned off wifi, ff dumped :D
[19:43] <[reed]> note that stack is completely useless
[19:43] <[reed]> :)
[19:45] <BUGabundo> :(
[19:45] <BUGabundo> [reed]: I installed what ever dbg packages this guys asked me too
[20:46] <fta> what is this? https://edge.launchpad.net/flash-ubuntu
[20:47] <BUGabundo> no idea
[20:49] <BUGabundo>                  Licenses:                                                         Other/Proprietary                                                                              (Canonical Internal)                                                                        Commercial subscription expires                   2010-06-29                                                     This project’s license is proprietary.
[20:49] <BUGabundo> scary
[20:49] <fta> yep
[20:49] <BUGabundo> I know some of the names
[20:49] <BUGabundo> seems to be canonical ppl
[20:50] <fta> https://edge.launchpad.net/~flash-ubuntu-team
[20:50] <BUGabundo> either OEM stuff
[20:50] <BUGabundo> 23 ??
[20:50] <BUGabundo> a lot of ppl
[20:50] <BUGabundo> what project is this ????
[20:51] <BUGabundo> https://edge.launchpad.net/~michaelforrest
[20:51] <BUGabundo> design stuff ppl
[20:51] <BUGabundo> Ubuntu Twitterscape
[20:51] <BUGabundo> WTF
[20:51] <BUGabundo> https://edge.launchpad.net/ubuntu-twitterscape
[20:51] <BUGabundo>                    Processing sketch to show what people are  saying about Ubuntu.          To run, download Processing from http://processing.org  or try one of the OS-specific executables


[01:36] <gnomefreak> people dont listen
[01:39] <jpds> gnomefreak: http://www.n3kl.org/sun/noaa.html
[01:41] <gnomefreak> :)
[01:41] <gnomefreak> i like
[01:42] <gnomefreak> be back i need to figure this out
[07:49] <jussi> tonyyarusso: about still?
[07:58] <tonyyarusso> jussi: yeah
[07:59] <jussi> tonyyarusso: As you may have noted in #u, I remove a few bans of yours that were covered by a blanket ban you set.
[07:59] <jussi> Just wanted to give a heads up
[07:59] <tonyyarusso> righto, thanks
[08:00] <tonyyarusso> Whatsisname from earlier this week.
[08:00] <jussi> could you take a look at anything else thats in there, banlist needs cleaning again.
[08:01] <tonyyarusso> sure, probably have two or three more
[08:01] <tonyyarusso> @login
[08:01] <tonyyarusso> @btlogin
[08:05] <tonyyarusso> all set
[08:14] <jussi> excellent. If anyone else is about, please go through your bans.
[10:16] <elky> Why... are there still vanity factoids?
[10:16] <jussi> elky: ?
[10:16] <Tm_T> like?
[10:17] <bazhang> lies
[10:17] <elky> !lies and !nixternal
[10:17] <elky> !lies
[10:17] <elky> !nixternal
[10:17] <jussi> elky: and Tm_T, if you havent already, please check your bans in #u - bazhang also
[10:17] <elky> mostly !lies though
[10:17] <jussi> !forget lies
[10:18] <Tm_T> jussi: will do as soon as I get desktop session back
[10:18] <jussi> !forget nixternal
[10:18] <elky> jussi, i already did. I removed the whole of 4 bans. The floodbot lists are the problem, not ops
[10:18] <bazhang> jussi, just the two I'd like to keep
[10:18] <jussi> if someone has extra time, please go through some of the old ones.
[10:19] <elky> Not before I've eaten. Been asleep all day thanks to sinuses, now I want bacon.
[10:19] <jussi> elky: ++
[10:19] <jussi> bacon ftw
[10:19] <elky> But still can't decide if I want $20 bacon in a pizza box, or $5 bacon that I have to go outside for.
[10:20] <jussi> elky: the 5$ one, its likely to be better
[10:20] <bazhang> * dhanesh<EMAIL_ADDRESS>has joined #ubuntu up to more nonsense as freak
[10:21] <elky> Yeah. But it /does/ involve going outside. And more cleaning up. Though, I could get a $2 pack of paper plates and absolve the latter with microwave usage...
[10:21] <jussi> heh
[10:40] <Tm_T> jussi: I have only one ban in #u ?
[10:43] <ikonia> I'm sorry to say this but #ubuntu is not a good support place at the moment
[10:45] <bazhang> dhanesh is asking how to /ignore ops was banned earlier as bnmk and just removed as 'freak'
[10:46] <ikonia> chum_chum is back as professor_g too
[10:46] <bazhang> aka nerml bolt etc
[10:46] <ikonia> yup
[10:46] <ikonia> I think we need to look at maybe using #ubuntu-irc-helpers more to try to get people to help others well, rather than just giving them blind answers
[10:48] <Tm_T> ikonia: yup
[10:48] <ikonia> someone installing netbeans because he doesn't know how to install a .sh file should not be just given ./netbeans.sh as the changes that makes at install time is not good
[11:39] <bazhang> ubiman aka dhanesh bnmk freak vbmn (and others) in PM he was quieted in #ubuntu for repeatedly offtopic/piracy type behaviour, not responding any more and appears to be trying to quit and rejoin to get around the quiet
[11:40] <ikonia> worth noting
[11:40] <bazhang> go him back again now
[12:00] <ubiman> PLEASE GIVE ME A GUIDANCE
[12:01] <elky> !guidelines
[12:02] <ubiman> UNMUTE ME
[12:02] <elky> Why are you muted?
[12:03] <jpds> Prehaps the usage of caps was contrary to our interests.
[12:04] <ubiman> elky:i played in irc.but i said that i will not repeat it again then also they muted me iam very sad now
[12:05] <ubiman> give one more chance
[12:07] <jpds> bazhang: ↑
[12:07] <elky> bazhang? Is there more than in the BT?
[12:08] <ikonia> elky: look under Dhanesh too
[12:08] <knome> elky, see his message about half an hour ago
[12:08] <ikonia> many chances have already been given
[12:08] <knome> elky, "-- bnmk freak vbmn (and others) --"
[12:09] <ubiman> one more chance
[12:09] <ubiman> please
[12:09] <ubiman> unmute me
[12:09] <ubiman>  i dont repeat again
[12:12] <ubiman> give an answer
[12:13] <knome> not being patient now won't help your situation much
[12:13] <elky> ubiman, I think your mute stays for a while. You can still read the channel and you can still ask on the forums.
[12:14] <elky> And PMing me isn't going to change my decision
[12:14] <jpds> Quite right.
[12:15] <elky> PMing others and asking for phonecalls isn't going to change my decision either. You can come back in 48hrs and ask again, but the mute stays for now.
[12:17] <elky> Stop PMing me, ubiman, the negotiation belongs here, and only in 48hrs time.
[12:17] <elky> In 2 days, return and ask for a review. Until then, you should /part this channel.
[12:19] <elky> You know the difference between PMs and channels. Don't be...
[12:19] <ikonia> he'll try to dodge in a minute
[12:19] <ikonia> that's his standard practice
[12:41] <bazhang> sorry was away
[15:28] <jrib> !!!
[15:29] <ikonia> ?
[15:29] <Pici> !helpersnack | jrib
[15:29] <jrib> ikonia: just getting frustrated in #ubuntu
[15:30] <Pici> I was getting frustrated just watching.
[15:30] <ikonia> I missed it
[16:07] <Pici> jpds: do you have a moment?
[20:12] <rww> FYI, hoober in #ubuntu has the same hostmask as that Prosper_ idiot from #ubuntu-offtopic the other day who was asking people to track down some woman he met on Diablo.
[20:14] <rww> I don't think he's actually banned, but I'd keep an eye on him.
[20:33] <Pici> jussi: around? Looks like http://apt.alturl.com/ is failing now, did you happen to change anything with apache/trac?
[20:34] <Pici> jussi: thats http://jussi01.com/ljl
[22:21] <rww> Hola:
[22:21] <rww> 14:19:07 -!- Aragon<EMAIL_ADDRESS>has quit [Ping timeout: 276 seconds]
[22:22] <rww> Google Translate turns that into "I lick you if you swallow my engelchen tm info", and I get the impression that if Google Translate were perfect, engelchen would translate as something problematic.
[22:23] <Tm_T> prolly
[22:23] <Tm_T> which channel that was?
[22:23] <rww> #ubuntu
[22:25] <Tm_T> I'll banforward here
[22:25] <rww> ta


[10:02] <lool> apw: Heya
[10:03] <lool> apw: On https://bugs.launchpad.net/ubuntu/+source/linux/+bug/524893 the config change can actually be reverted; it didn't help and wasn't actually needed once the fix was found
[10:03] <ubot4`> Launchpad bug 524893 in qemu-kvm (Ubuntu Lucid) (and 3 other projects) "versatile: Can't boot initramfses (affects: 1)" [Low,Fix released]
[10:04] <lool> I also had in mind to kill the default cmdline from the config, it overrides the ATAG mem information and qemu-ssytem-arm uselessly defaults to 32MB of RAM
[10:04] <lool> (that is, passing -m foo to qemu-system-arm isn't enough, one has to pass mem=foo too)
[10:04] <persia> 32MB!!!!!
[10:04] <lool> Yup
[10:05] <lool> triggers d-i "Low mem mode"
[10:05] <lool> persia: It's from the defconfig
[10:05] <lool> it's an old board
[10:09] <persia> right.
[10:17] <lool> apw: sent to the list
[10:18] <lool> persia: BTW did you get a chance to go over the /Ports page?
[10:18] <lool> persia: I'd like to hook it up from the /Development page now
[10:21] <persia> Unfortunately not.  It was top-of-my-list for Saturday, until something else intervened.  I'll look at it as soon as I've eaten.
[10:21] <lool> Ok thanks
[11:57] <nosse1> Are there any good reasons for me to up my host to Lucid to develop/build Luicid ARM targets (w/rootstock)?
[11:58] <rcn-ee> nosse1, depends if you also want to test x86 lucid. ;) otherwise karmic works fine, just use the bzr trunk of rootstock
[11:59] <nosse1> of course I want to test Lucid x86 as well... ;)
[12:00] <nosse1> rcn-ee: rootstock is one, script right? Not spread across several files?
[12:00] <rcn-ee> yeah, it's just a script that access qemu..
[12:01] <nosse1> excellent. I think I got it then.
[12:01] <nosse1> Now I'm this close to attempt to run Lucid on TI AM3517 Zoom eval kit
[12:04] <rcn-ee> it should work as i run it on a varity of omap35x targets... just make sure you config meets these requirements http://bazaar.launchpad.net/~beagleboard-kernel/%2Bjunk/2.6-stable/annotate/head%3A/readme.txt
[12:06] <nosse1> rcn-ee: Have you deployed Ubuntu on any omap35x targets for production environments, or just still development?
[12:09] <rcn-ee> nah, i haven't pushed my customers off karmic yet, as lucid just hit beta-1 last week..
[12:09] <rcn-ee> i have two internal development beagles running it 24/7 thou, testing different things..
[13:07] <nosse1> Ush... ARM Lucid didn't work out-of the box... Well, I didn't really expect that either...
[13:08] <ogra> works here :)
[13:09] <nosse1> It boots the kernel, and head into NFS, but then it just sits there after "init: ureadahead main process (552) terminated with status 5"
[13:09] <ogra> ah, NFS
[13:10] <ogra> there might be mountall bugs with NFS, check launchpad
[13:10] <nosse1> Are there any good tools for debugging nfs-links? i.e. smart cmd options for tcpdump
[13:10] <nosse1> I'd like to see what specific files are being accessed
[13:10] <ogra> well, try to reach your server from the busybox shell in your initramfs etc
[13:11] <ogra> thats why ubuntu uses initramfs all over the place ... makes debugging so easy :)
[13:11] <nosse1> hehe: That might just be it then. I tried without initramfs :o
[13:12] <ogra> well, depending on your kernel it should work even without initramfs
[13:12] <ogra> its years ago i used rootfs on NFS so i wont be a big help
[13:13] <nosse1> Because you dont really need the initramfs if everything is build statically in the kernel, right. Theres nothing special the distro requires?
[13:13] <ogra> there is
[13:13] <ogra> lost of packages place stuff inside the initramfs in ubuntu
[13:13] <ogra> *lots
[13:14] <nosse1> How do you build one then?
[13:14] <ogra> update-initramfs -c -k <your kernel version>
[13:14] <ogra> on a running system
[13:14] <nosse1> Thats assuming a running system, yes
[13:15] <ogra> (prefix that with sudo)
[13:15] <ogra> if you dont have a running system, take your sd make sure to have qemu-arm-static installed and run the command in a chroot on the SD
[13:15] <ogra> (on your x86 system)
[13:16]  * nosse1 noob, SD=?
[13:17] <ogra> Sd card
[13:17] <ogra> oh, you probably dont use one if you use NFS :)
[13:17] <ogra> just chroot into your exported rootfs then
[13:17] <nosse1> Ah. So thats how you run instead of NFS?
[13:20] <ogra> using an SD card, yes
[13:21] <nosse1> I recon, since you compile packages natively, moving files back and forth to x86 isn't made as often as you would on a purely crossed target
[13:21] <nosse1> ..so a SD card is fine
[13:22] <ogra> right, i usually only use x86 for bringup and building a booting image
[13:23] <nosse1> i have to admit my other colleagues are sceptical to build the apps natively on a 500MHz ARM target
[13:24] <ogra> well, if you use ubuntu as ubuntu developer you can just develop under x86 :)
[13:24] <ogra> the packages are built automatically on all arches anyway
[13:25] <nosse1> yes, I see both advantages and disadvantages of doing it like this
[13:25] <ogra> it really depends *what* kind of app you buiuld natively though
[13:26] <nosse1> I'm a little worried that vanilla ubuntu becomes too heavy for a small ARM target, yet it is nice to not have to worry about the system
[13:26] <ogra> if its just a desktop app it surely is a lot easier to build it natively and have all dependencies already available
[13:26] <ogra> well, define *small*
[13:26] <nosse1> The other alternative is some kind of LFS in a cross build environment
[13:26] <nosse1> Our product will have a sys-flash of 1G
[13:27] <ogra> LFS cross building might gain you incompatible binaries
[13:27] <ogra> 1G flash isnt enough for any of the ubuntu desktops
[13:28] <ogra> not sure about LXDE but even if that would fit it wouldnt leave you much space for user data
[13:29] <nosse1> Yes. Package and product upgrade feats of distro like Ubuntu is very tempting
[13:29] <ogra> indeed
[13:29] <nosse1> No desktop (sort of). The product will be a end-user product where the user shall not know that Ubuntu is running behind the curtain
[13:30] <nosse1> But it will be a Qt app running either on X11 or directly to fbdev
[13:30] <nosse1> Size isn't that critical (shoult fit into 1G), but startup-time into final application is far more critical.
[13:30] <ogra> well, if you only compile your app, i would go with natively ...
[13:31] <ogra> whats the desired time you have ?
[13:31] <ogra> and with which bootloader ? :)
[13:31] <nosse1> Q is then how much tweeking to Ubuntu is needed to make the app start fast enough
[13:31] <nosse1> TI uses U-boot
[13:32] <ogra> which is a fairly slow thing in itself
[13:32] <nosse1> Lets say 10-30 secs is fine
[13:32] <ogra> thats half of it for uboot
[13:32] <nosse1> Uboot will be optimized in order to speed things up
[13:33] <nosse1> thats the easy part
[13:33] <ogra> if you only fire up your app 15sec should beeasily doable
[13:33] <ogra> my laptop takes 8 from grub to gnome desktop atm ...
[13:34] <nosse1> Ah, but it's a laptop.. What are we talking about on your ARM targets?
[13:34] <ogra> and that starts a lot more stuff, even though its x86 and 4G RAM and a fast SSD, 15sec for u-boot-end to app-on-screen will be achievable
[13:35] <ogra> ARM targets are depending on the disk you run your system off
[13:35] <ogra> mainly
[13:35] <ogra> ubuntu-netbook on a babbage board takes from 35 to 45sec
[13:35] <ogra> (thats imx51 from USB key or USB attached SATA disk)
[13:36] <ogra> though imx51 loses nearly no time to the bootloader ... (6-10sec)
[13:36] <ogra> redboot is a lot faster than u-boot ... but a lot less flexible
[13:37] <nosse1> BTW: Those ARM targets used in the Launchpad build farm, what kind of machine/specs are we talking about? Some of these compiles must take a while?
[13:37] <ogra> (and very painful)
[13:37] <ogra> the ARM buildds are all imx51 800MHz 512M machines
[13:37] <nosse1> Yeah, I know. I've been working with imx35 previously and thus redboot
[13:37] <ogra> with USB disks
[15:01] <persia`> lool: Regarding Development/Ports : there's a lot of TODOs left: are you sure you want to strong-link it already?
[15:01] <persia`> Also, there are N ways to set up schroots: I'm unsure I want to document all of the manual methods (and they're all painful).
[15:01] <lool> persia`: We could hide them as comments
[15:01] <persia`> Yeah, hiding them works.
[15:01] <lool> persia`: Well, I'd like to document how you use sbuild for arm development
[15:02] <persia`> I can document use easily.
[15:02] <persia`> For creation, I can't recommend mk-sbuild enough.
[15:02] <lool> persia`: hidden now
[15:02] <lool> persia`: Oh ok, I thought you tested mk-sbuild successfully?
[15:03] <persia`> Sorry: translation error.  I mean to say that not using mk-sbuild is so painful that there is no limit to the degree to which I will recommend it to any schroot/sbuild users
[15:04] <lool> persia`: Do you consider the sbuild section good enough?
[15:04] <persia`> Basically, one has to create the (directory, tarball, LV snapshot, etc.) manually, and then stick it somewhere, and then write the configuration manually.
[15:04] <persia`> I'll add in some notes on usage with schroot and sbuild.
[15:05] <lool> persia`: I'm not a regular sbuild user; I have it installed and now how it can overall work, albeit not the latest features thereof
[15:05] <lool> persia`: Ok good
[15:05] <lool> persia`: When you're done, just remove the commented-out TODO
[15:24] <nosse1> Where does rootstock stage its files?
[16:02] <nosse1> OK, sorry for my elementary questions: If I have a rootstock/qemu image either as .img or as tar.gz, how can I invoke qemu to boot from that image/root?
[16:02] <nosse1> I.e. I need a kernel and I need to make the kernel load the root from the image, I presume
[16:03] <ogra> nosse1, see the rootfs from scratch wikipage (from the channel topic)
[16:05] <nosse1> ogra: embarrasing. Of course, thanks!
[16:09] <persia`> lool: Sorry that took so long.  Use of schroot/sbuild documented : please take a look to make sure it makes sense to you.
[16:15] <lool> persia`: Looks good
[16:15] <persia`> lool: What I wonder is if we need to go to any more effort to make clear that these procedures (should) work for armel/powerpc/sparc
[16:16] <persia`> (getting a little off-topic for this channel)
[16:16] <persia`> I don't want to create the impression that one must use pbuilder for armel and sbuild for powerpc, nor the impression that this is armel only.
[16:16] <lool> persia`: Let's hope that the people reading it are technical enough to understand that, and fix it if we discover it's a problem
[16:16] <persia`> That sounds reasonable :)
[16:17] <lool> I don't think it's off topic for this chan since we're trying to improve ports documentation as driven by the lack thereof for arm  ;-)
[16:17] <persia`> heh
[16:17] <persia`> Do you happen to know if qemu-system-ppc needs as many special arguments as qemu-system-arm ?
[16:18] <lool> persia`: I happen not to know
[16:18]  * persia` either
[16:18] <persia`> Oh well, there's enough fast ppc HW out there that most folks use native anyway.
[16:18] <lool> ISTR seeing people run qemu-system-ppc without any -M arg, but I don't know what kernel's we're building for
[16:19] <lool> Wow powerpc has a vmlinux and armel a vmlinuz, how odd
[16:22] <nosse1> ogra: Now this is interesting. Earlier this day I failed getting lucid to run on target. Kernel booted, but failed in userspace. When I now start qemu, I get the same failure
[16:32] <ogra> nosse1, whats the failure ?
[16:35] <nosse1> Hold on. I hoped I could get the console output with -nographic, but it only dumps the pre-linux bootloader
[16:39] <persia`> nosse1: I often find "-monitor stdio" to be  useful argument when I'm having issues, as this lets me manipulate the session in the terminal whilst it executes in the SDL environment.
[16:42] <nosse1> ogra: From the start of init, I see the following messages 1) modprobe: Could not load ...modules.dep  2) init: ureadahead main process (381) term. with status 5   3) mountall: Could not connect to Plymouth     4) Same as 1 again
[16:42] <ogra> thats all fine
[16:42] <ogra> nothing to worry about
[16:43] <nosse1> Then nothing. After a while I get sda sense key errors in qemu
[16:43] <ogra> thats something to worry about :)
[16:44] <nosse1> This time I'm running from ext3 file-image
[16:44] <ogra> how did you build your image ? just using rootstock --notarball ?
[16:44] <nosse1> Yup
[16:45] <ogra> and then the commandline from the wiki ?
[16:45] <ogra> with the kernel from there ?
[16:45] <nosse1> Hold on, I'm getting lots of errors on e2fsck of the image
[16:45] <nosse1> yes
[16:46] <ogra> i dont see that here
[16:46] <ogra> what was the exact commandline you used with rootstock ?
[16:46] <nosse1> Hoi.. Here I got a tracedump of something in the console
[16:46] <nosse1> I used "sudo ./rootstock --imagesize 1G --seed ubuntu-minimal --dist lucid --notarball"
[16:47] <ogra> ah
[16:47] <ogra> well, that will fire up oem-config
[16:47] <nosse1> rootstock is the patched one to be able to use my karmic against lucid
[16:47] <ogra> which can take a few minutes to start
[16:47] <lool> persia`: Apparently, one needs to pass -M prep to qemu-system-ppc, and one needs a BIOS which we lack in Ubuntu; see https://bugs.launchpad.net/ubuntu/+source/openbios-sparc/+bug/183495
[16:47] <ubot4`> Launchpad bug 183495 in openbios-sparc (Ubuntu) "[FTBFS] openbios-sparc (1.0~alpha2+20070816-1) fails to build in hardy (affects: 3) (dups: 1)" [Medium,Confirmed]
[16:48] <ogra> nosse1, if you want to prevent oem-config just use th e-l and -p options for rootstock
[16:48] <ogra> *the -l
[16:48] <lool> persia`: surprisingly, the two files mentionned by https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/60478 are around on my system
[16:48] <ubot4`> Launchpad bug 60478 in qemu (Debian) (and 1 other project) "Missing files for qemu-system-ppc (dup-of: 183495)" [Unknown,Fix released]
[16:48] <ubot4`> Launchpad bug 183495 in openbios-sparc (Ubuntu) "[FTBFS] openbios-sparc (1.0~alpha2+20070816-1) fails to build in hardy (affects: 3) (dups: 1)" [Medium,Confirmed]
[16:49] <nosse1> ogra, thanks I'll try. My end objective is to get a working image for me to be able to use on target.
[16:49] <persia`> lool: I have them both as well.
[16:50] <ogra> nosse1, well, if you boot it on the target system, just wait a little longer, it will bring up oem-config after a while
[16:50] <persia`> lool: I know far too much about the openhackware and openbiod-sparc issues.  They aren't fixable with current Soyuz.
[16:50] <ogra> to configure user, language, keymap etc
[16:51] <ogra> W: u-boot-omap3 source: quilt-build-dep-but-no-series-file
[16:51] <persia`> lool: OK, so qemu-system-foo really only works for armel right now.  That makes it easy.  Thanks for checking.
[16:51] <ogra> hmm, is that new ?
[16:51] <persia`> ogra: No.
[16:51] <ogra> i never needed debian/patches/series before
[16:51] <nosse1> ogra, I have to admit I perhaps didn't wait long enough to determine whether the target was busy or dead.
[16:51] <ogra> persia`, well, the complaint is
[16:51] <persia`> quilt creates it automatically.
[16:51] <persia`> No, it's been around since jaunty, at least.
[16:52] <nosse1> ogra, but the output was the same on targes as on qemu
[16:52] <ogra> weird, i never saw that before when building a package and picking quilt
[16:52] <ogra> nosse1, on qemu it will take even longer until oem-config comes up
[16:52] <persia`> You probably never didn't have a series file before.  Like I said, quilt does it automatically.
[16:53] <persia`> ogra: I've found quilt incredibly easier to use since adding http://paste.ubuntu.com/399386/ as my ~/.quiltrc
[16:54] <ogra> ah, thats nearly the same cjwatson gave me
[16:55] <persia`> His was from /usr/share/doc/quit/README.source
[16:56] <persia`> Which works exactly the same, only faster for 90% of cases.
[16:56] <nosse1> The kernels you build for target, do you cross compile them or do you also do that natively?
[16:57] <ogra> nosse1, see /topic :)
[16:57] <persia`> nosse1: Everything is natively compiled.
[16:57] <ogra> bah, sigh ... series needs to contain a comment
[16:58] <persia`> No it doesn't.
[16:58] <nosse1> What happens if I install gcc from my qemu. Will it be capable of generating code for real target?
[16:59] <persia`> nosse1: As long as your target is compatible with the instruction set gcc is targeting, yes.
[16:59] <ogra> persia`, diff.gz wont represent empty files
[16:59] <ogra> so lintian still complains
[16:59] <ogra> unless i add a comment or something
[16:59] <persia`> ogra: series shouldn't be empty unless you have no patches, and if you have no patches, you shouldn't have a build-dep on quilt.
[17:00] <ogra> persia`, i want the new packages i build to reflect a selection for the patchsystem
[17:00] <ogra> so people touching the package know what to use
[17:00] <ogra> ogra@babbage2:~/u-boot-omap3-2010.3git20100315$ lintian -i ../u-boot-omap3_2010.3git20100315-0ubuntu1_source.changes
[17:00] <ogra> ogra@babbage2:~/u-boot-omap3-2010.3git20100315$
[17:00] <ogra> there we go :)
[17:00] <persia`> Just use Format: 3.0 (quilt) then.  No build depenency required.  No debian/rules magic.  Expresses the preference for quilt.
[17:00]  * ogra builds a binary
[17:01] <ogra> persia`, i wont revert what i did now :)
[17:01]  * ogra has to get the thing done today
[17:01] <persia`> anyway, you're supposed to express that preference in debian/README.source
[17:01] <persia`> Just ask first next time :p
[17:02] <ogra> expressing that preference in README.source doesnt quiet down lintian
[17:02] <ogra> i want the package to be ready so people can just drop in diffs
[17:03] <ogra> as i do with i.e. dpatch
[17:03] <ogra> and given that asac perfers quilt and i get heat from people that i use dpatch everywhere i thought i should start switching to quilt
[17:03] <ogra> even though i dont like it
[17:04] <ogra> in any case i want my packages to be ready for patching right away, without having to fiddle with build-deps
[17:04] <persia`> Fair enough.  Next time you do a package, make me walk you through using format 3.0(quilt) so you have it easy.
[17:04] <ogra> ok
[17:04] <persia`> (which never requires build-dep on quilt and still uses quilt)
[17:10] <ogra> ogra@babbage2:~/u-boot-omap3-2010.3git20100315$ lintian -i ../u-boot-omap3_2010.3git20100315-0ubuntu1_armel.deb
[17:10] <ogra> W: u-boot-omap3: wrong-bug-number-in-closes l3:#XXXXXX
[17:10] <ogra> PFFT !
[17:13] <persia`> ogra: You want (LP: #...) anyway.  This is the pain of dh_make
[17:14] <persia`> Don't forget to make it not Priority: extra too.
[17:14] <ogra> i know, i just havent filed a bug yet
[17:14] <ogra> err, what prio should it have ?
[17:14]  * ogra always leaves it extra
[17:16] <nosse1> Can I shutdown qemu/debian from the monitor gracefully? I notice the ext2 img is easily corrupted
[17:16] <ogra> persia`, what but debootstrap uses the priority field anyway ?
[17:16] <nosse1> errr  ubuntu NOT debian. Sorry.  (Don't throw any stones.)
[17:17] <ogra> nosse1, we wouldnt exist without debian, why would we throw anything ? :)
[17:17] <nosse1> :D
[17:17] <persia`> ogra: Every package manager displays it
[17:18] <ogra> nosse1, the karmic version used ext2 and i'm not sure you can do anything beyond "sudo halt" ... afaik the kernel wont power off the VM, you need to close it then
[17:18] <ogra> persia`, so suggest a prio :)
[17:18] <ogra> its a bootloader that only exists on arm and shouldnt be used anyway unless you build images
[17:18] <persia`> ogra: "optional" is correct for nearly all new packages
[17:18] <ogra> ok
[17:19] <persia`> Wait.
[17:19] <persia`> "shouldn't be used anyway unless you build images"?  Is it not useful for installed devices?
[17:19] <nosse1> ogra, the login/pwd of my image doesnt work so I cannot login. And the image runs when using -snapshop. The kernel crashes without it
[17:20] <ogra> persia`, well you can use it if you roll your own beagle images
[17:20] <ogra> theoretically
[17:21] <ogra> but for ubuntu installs we'll use flash-kernel anyway to write u-boot to NAND
[17:21]  * nosse1 trying rootstock again
[17:21] <ogra> so there is no real point in actually using it for anyone (while you *can* if you want to)
[17:22] <ogra> persia`, main point of the package is to make d-i and live images using the u-boot-beagle.bin file from this package (along with the MLO file from the x-loader package thats already in the archive)
[17:22] <persia`> ogra: OK. YOu have a special package where "extra" happens to be correct.  This is very rare :)
[17:22] <ogra> ah
[17:23] <ogra> persia`, you have to teach me one day how to make proper dh7 packages that can do multiple runs for different configs on the same source
[17:24] <ogra> eventually i want the u-boot-omap3 package to support all omap targets but that needs several builds
[17:25] <ogra> (with one binary for each target)
[17:25] <persia`> ogra: That's going to take time, and is best done with physical presence I think.  That is the sort of thing where looking over a shoulder is useful.
[17:26] <ogra> i know how to do it the old way but dh7 is rather blurry to me
[17:27] <persia`> Yeah.  dh(1) is just as flexible as dh_*, but most folk get confused because of the CDBS-like features.
[17:27] <ogra> yeah
[17:27] <ogra> its not important now though ... rather a L+1 thing
[17:28] <ogra> beagle only is sufficient atm
[17:29] <ogra> but given the source can also build for zoom1/2 and EVM boards i'D like to sopport them one day
[17:44] <nosse1> Must qemu be run as root?
[17:48] <nosse1> According to e2fsck, the images produced by rootstock have fs-errors
[17:48] <persia`> qemu definitely doesn't need to be run as root.
[17:49] <rcn-ee> nosse1, that's pretty normal, just let it clean it up...
[17:50] <rcn-ee> e2fsck is usually not happy with the time variances so it checks just in case..
[17:50] <ogra> or use lucids rootstock (since you build minimal images anyway)
[17:50] <nosse1> Yes, but it seems to be coinciding with crashes of apps inside qemu. I'm not sure, it just seems that way
[17:50] <ogra> in lucid rootstock defaults to ext3
[17:50] <nosse1> I'm getting inode count errors and such
[17:54] <rcn-ee> nosse1, does it clear up on the next reboot?
[17:54] <nosse1> Sometimes I get kernel crashes, sometimes stack dumps in the console and other times I get "I/O error, dev sda"
[17:54] <nosse1> Using -snapshot seems to remedy all of these errors
[17:55] <rcn-ee> sounds fun, which kernel you using?
[17:55] <nosse1> vmlinuz-2.6.31-rc3versatile1-cortex-a8
[17:56] <ogra> nosse1, thats definately not the one from the wiki
[17:57] <ogra> (i asked you before if you use the one from the wiki)
[17:58] <nosse1> Yes, you're right. I have no clue where this vmlinuz-2.6.31 came from. It was just lying in my dir.
[17:58] <nosse1> But using the one from the wiki, I still have the sda I/O error issue
[17:59] <ogra> heh
[18:00] <rcn-ee> hey ogra, just catching up on the backlog, you guys really planning to put the kernel in nand?
[18:00] <rcn-ee> (omap's)
[18:00] <ogra> rcn-ee, likely, yes
[18:00] <ogra> as long as kernel and initramfs actually fit
[18:01] <rcn-ee> okay.. yeah they should... but as side note, the xm might come with no nand.. (to get 1Gb ram..)
[18:01] <ogra> i need to do some measuring ... my last days were busy with packaging x-loader and u-boot and starting to design the live images
[18:02] <ogra> from tomorrow on i'll start working on the flash-kernel changes we need and on the actual image builds
[18:03] <ogra> we will definately flash x-loader and u-boot with the versions from the image during install
[18:03] <ogra> i'm not 100% sure about kernel and initramfs yet
[18:04] <ogra> (for now my focus is to have *something* ready by end of the week ... we'll be able to make changes to that before beta2)
[18:04] <asac> ogra: use deb3
[18:04] <ogra> asac, ??
[18:05] <asac> err source format 3.0 ... that comes with great quilt integration
[18:05] <ogra> asac, for my next packages i will ... to late now :)
[18:05] <asac> you dont need to know how to use it in order to work with it
[18:05] <ogra> thats evil !
[18:05] <asac> ogra: if you used quilt we can just convert it easily
[18:05] <rcn-ee> true.. ;)  btw, i got my iegp2 working over the weekend.. with 500.2  it'll need about 4-5 backports from 2.6.34-rc2 for dss2/ethernet.. ;)
[18:05] <ogra> right
[18:05] <asac> cool
[18:06] <ogra> asac, i'm trying to use quilt by default now even though i hate it
[18:06] <ogra> rcn-ee, do you know if iegp2 uses the same x-loader and u-boot ?
[18:06] <nosse1> ogra, I still get I/O error on sda using qemu and this time the kernel from the wiki ( ;) )
[18:07] <rcn-ee> it's different... ;)
[18:07] <ogra> nosse1, sorry i have no idea whats going on there, does your user own the disk image ?
[18:07] <ogra> (i.e. does he have write access to it)
[18:07] <ogra> rcn-ee, sad
[18:07] <nosse1> ogra, yes
[18:07]  * ogra would love to have one generic omap image that works everywhere
[18:08] <rcn-ee> It's using 1.4.2 x-loader, but i'm not sure if it's the same as beagle.. (it does use OneNAND Flash, so that's different..) the U-boot is 2009.08 and uses boot.ini scripts at boot. (instead of beagles boot.scr) same format thou..
[18:08] <nosse1> I'll search around
[18:09] <ogra> nosse1, worst case you could grab rootstock from lucid
[18:09] <rcn-ee> but 720mhz & 512Mb ram, so it's going into my gcc farm after i get lucid booting.. ;)
[18:09] <ogra> or just change ext2 to ext3 inside the rootstock script manually
[18:09] <ogra> rcn-ee, hey, thats nearly as good as the babbage board :)
[18:10] <ogra> you just need SATA ;)
[18:10] <ogra> ok, my revC4 boots with x-loader and u-boot from the archive ...
[18:10] <rcn-ee> yeap it is.. ;)  yeap no sata, but onboard wifi and bluetooth.. ;)
[18:10] <ogra> time to call it a day ... i was up early
[18:11] <ogra> wifi ++
[18:11] <rcn-ee> sound cool, you have c4 usb patches right?
[18:11] <ogra> i havent booted to a rootfs
[18:12] <ogra> amitk would know if we have all patches
[18:12] <rcn-ee> u-boot set's up the regulator for the ehci port on the c4, that's why i asked.. i don't think they are in u-boot mainline yet...
[18:12] <ogra> rcn-ee, do you know if the board initalizes the framebuffer if you dont give any omapfb options on cmdline ?
[18:13] <ogra> oh, i packaged u-boot-omap3 ;)
[18:13] <rcn-ee> okay, that should work then..
[18:13] <ogra> didnt touch mainline
[18:13] <ogra> sarkomans tree
[18:14] <rcn-ee> i was thinking that over the weekend..  it didn't in the past... and we've always defined it on the command line...
[18:14] <nosse1> ogra, I'm using a rootstock patch which i got from asac. I needed it to be able to run qemu for a lucid target on a karmic (64-bit) machine
[18:14] <rcn-ee> so i would say no...
[18:14] <ogra> crap
[18:15] <rcn-ee> there is a read edid script in angstrom.......
[18:15] <ogra> thats really messy behavior ... it should jut read EDID
[18:15] <ogra> yeah, that was dropped years ago from ubuntu
[18:15] <ogra> doesnt help me if i need the value on cmdline
[18:16] <ogra> the driver should just check the monitors capabilities and set the highest resolution by default
[18:16] <rcn-ee> the other issue, the omapfb comand also allocates kernel memory too for the frame buffer...
[18:16] <ogra> i wonder why that seems to be so hard
[18:16] <rcn-ee> Well, there is a big limitation on the screen size... (hardware pixel clock)
[18:16] <ogra> that should also have a default value
[18:17] <asac> i think starting with fbfev isnt good to add EDID - but have not looked closely
[18:17] <ogra> well, but you know your pixel clock capability
[18:17] <rcn-ee> that's one reason i always recommend the 720p value, it's the most compaitable and biggest..
[18:17] <ogra> so you can fall back to something hardcoded
[18:17] <ogra> its just evil to have to define *defaults* on the cmdline
[18:17] <ogra> at least these should be there automatically
[18:17] <ogra> i find it ok to *override* on cmdline
[18:18] <ogra> but making it a requirement is just bad habit
[18:18] <rcn-ee> pixel clock limitation is here; http://elinux.org/BeagleBoardFAQ#Display_resolutions_.232
[18:18] <asac> ogra: do we have graphics drivers for beagle already?
[18:18] <ogra> asac, from debian, yes
[18:19] <asac> ogra: is that in archive and just works?
[18:19] <rcn-ee> it's a sudo neon optimzed framebuffer driver...
[18:19] <ogra> asac, havent tried yet
[18:19] <rcn-ee> the guys at allwaysinnovating also did their own varient of that too..
[18:19] <ogra> but yes, there is omapfb and omapfb with NEON
[18:20] <ogra> we have two to pick from, not sure how good they are
[18:20] <ogra> i'll test that once we have a working image
[18:20] <rcn-ee> use the neon one...
[18:20] <ogra> one step at a time :)
[18:20] <asac> ogra: i guess we have neon in cpuinfo?
[18:20] <ogra> if thats stable i will :)
[18:20] <asac> shouldnt we just install both and it will pick the right one?
[18:20] <ogra> asac, at least with the pre-built kernel amitk gave me
[18:20] <rcn-ee> it's been the default in angstrom for a good year and half.. ;)
[18:20] <asac> sounds promissing. nice
[18:21] <ogra> rcn-ee, angstrom uses different toolchain
[18:21] <ogra> so i wont say hooray until i tested it ;)
[18:21] <rcn-ee> yeap, 4.3.3 vs 4.4.x..
[18:21] <ogra> but yes, promising for sure
[18:22]  * ogra wonders if 500.2 finally made it to the archive
[18:22] <asac> ogra: does JamieBennett has a usable environment alöready? maybe he can check that?
[18:22] <ogra> asac, he should have everything he needs
[18:22] <asac> ogra: whats the status on imx kernel in -proposed ?
[18:22] <asac> :-P
[18:22] <ogra> no idea, was it uploaded already ?
[18:22]  * ogra didnt get any pings yet /me thinks
[18:23] <rcn-ee> which reminds me.. did amit put the vfp patches you used for imx in omap's branch?  it needs it to..
[18:23] <JamieBennett> asac, ogra, ping me in the morning if you want me to check something, about to leave the house in 10 minutes
[18:23] <ogra> no idea, that kernel is fully his work, i only saw two binaries yet
[18:24] <ogra> JamieBennett, just bring up your board tomorrow so you can test stuff
[18:24] <asac> JamieBennett: ok. would like to have the omap x drivers checked ...
[18:24] <asac> JamieBennett: 1. do both (neon + non neon) work
[18:24] <rcn-ee> okay, well it's no in mainline yet either, so it would be easy to spot in the log..
[18:24] <JamieBennett> ogra: will do, first thing I'll do in the morning
[18:24] <asac> 2. is the right driver automatically selected if we install both
[18:24] <ogra> asac, given the kernel is stable enough to even try :)
[18:24] <asac> ogra: thought we are already there?
[18:25] <rcn-ee> no, it won't... i had a user with that problem on karmic..
[18:25] <ogra> for me 500.2 has multiple issues
[18:25] <asac> hmm
[18:25] <ogra> asac, its there but buggy
[18:25] <ogra> usb didnt work
[18:25] <ogra> which is somewhat essential on a beagle :)
[18:25] <asac> did we backport their patches or just took the right upstream branch for .32?
[18:25] <ogra> ext4 wipes the FS
[18:25] <ogra> i think its plain mainline .33
[18:25] <rcn-ee> asac, just a config issue on the usb..
[18:26] <ogra> i see the modules loaded
[18:26] <ogra> it oopsed when i unloaded
[18:26] <asac> rcn-ee: cool. can you give ogra or kernel team pointers?
[18:26] <ogra> though i didnt put much time into it yet, booting and image rolling is my current main concern
[18:27] <ogra> once thats ready we can fiddle with the rest
[18:27] <asac> ogra: right focus on that. jamie and rcn-ee can probably help if you spit out first iamges ;)
[18:27] <ogra> especially *everyone* can as soon as we have daily builds :)
[18:27] <rcn-ee> yeap, that's my goal.. ;) my staging area is here: https://code.launchpad.net/~beagleboard-kernel/+junk/lucid-ti-omap  and i got a good number of random omap boards.. ;)
[18:27] <ogra> i want to extend our user base first :)
[18:28] <asac> rcn-ee: can you reproduce the issues ogra mentioned?
[18:28] <ogra> anyway, i'm really done now ...
[18:28] <asac> ogra: see you tomorrow
[18:28]  * ogra calls it beer o clock for real now
[18:28] <rcn-ee> but we don't have enough boards yet for new users.. ;)
[18:28] <rcn-ee> take it easy ogra.. ;)
[18:28] <ogra> rcn-ee, revC
[18:28] <ogra> there are lots and lots of users :)
[18:28] <rcn-ee> asac, i forgot, what issue? ;)
[18:29] <asac> rcn-ee: he said his beagleboard is unstable with current kernel in lucid
[18:29] <ogra> USB and ext4 are the things i spotted yet
[18:29] <rcn-ee> That's strange.. although i have ran 500.2 more then 5 minutes.. (boot [x], things work [x])
[18:29] <ogra> unloading the twl driver makes it oops
[18:29] <rcn-ee> but mailine 2.6.33 is stable for me..
[18:30] <asac> rcn-ee: are you using lucid packages etc.?
[18:30] <ogra> they are here if you look for them http://people.canonical.com/~amitk/ti/
[18:30] <rcn-ee> yeap...  one beagle it's all chroots, another beagle it's different partitions with each dist
[18:30] <rcn-ee> thanks ogra, will test those...
[18:31] <ogra> i think at least ...
[18:31] <ogra> i hust noticed they still say 500.1
[18:31] <asac> thats 500.1
[18:31] <asac> ack
[18:31] <asac> where is 500.2
[18:31] <asac> ?
[18:31] <asac> in archive?
[18:31] <ogra> i think that *is* 500.2 just wrongly versioned
[18:31] <ogra> 500.2 was FTBFS this morning
[18:31] <rcn-ee> i know amit was testing scripts...
[18:33] <rcn-ee> asac, i know usb can be solved with: https://lists.ubuntu.com/archives/kernel-team/2010-March/009484.html  but the question is why desn't the twl stuff like being moderlized...
[18:34] <rcn-ee> it could be timing with specially since CONFIG_TWL4030_USB sets the power regulator on the musb...
[18:34] <nosse1> Are there any real speed or size differences between ARMv7 and earlier?
[18:35] <rcn-ee> nosse1, think 486/686/etc.. ;)
[18:35] <nosse1> heh
[18:35] <nosse1> good answer ;)
[18:36] <rcn-ee> it just gets more complicated since there are alot of x's.. x86...
[18:37] <nosse1> theres an opinion here claiming that the 'x' of the distro doesnt really matter. The important stuff is the end-user app
[18:38] <nosse1> so out of curiosity I was wondering if there had been any real (linux) benchmarking to it
[18:38] <rcn-ee> nosse1, take a look at these, sheevaplug is armv5 and debian squeeze is built for armv4 http://global.phoronix-test-suite.com/?k=profile&u=robertcnelson-3173-25135-22766
[18:41] <nosse1> rcn-ee, thanks
[18:42] <rcn-ee> no problem, it was a fun comparsion test, i'm planning to redo it again, and add a iegp2 for comparsion, it has the same clock speed as the c4, but double the ram..
[18:47] <comradekingu> I sent a mail to phoronix asking for them to test various arm distros and settings
[18:48] <comradekingu> seeing they already have..
[18:48] <rcn-ee> oh they haven't yet... ;)
[18:49] <rcn-ee> I've talked with a couple of them at phoronix, they do have access to some arm boards..
[18:50] <comradekingu> I asked about the latest developer boards, so i guess my question is still valid
[18:51] <rcn-ee> yeap it is..  if you search for arm under their search_results, there is another anonymous user running tests other then me...
[18:52] <comradekingu> With the barrage of ARM cellphones being released and the ever increasing software stack on there is think they should allot more time for it
[18:52] <rcn-ee> yeap..  but you get these funny comparisions.. http://global.phoronix-test-suite.com/?k=profile&u=linuxeasecom-14106-16996-6522
[18:54] <rcn-ee> (the lame and ogg) results are invalid on that one.. i should bug phronix, they are missing a dependicy..
[18:58] <nosse1> Don't you think that there's a lot LFS out there for embedded targets such as ARM phones?
[18:59] <comradekingu> Exactly
[18:59] <nosse1> I mean in our product, it is quite new to endorse a distro. I'm living in the LFS/busybox compile-all-in-a-large-image kind of thing
[18:59] <nosse1> I'm still not 100% convinced to deploy ubuntu into our product
[19:01] <nosse1> Hopefully my playing around with ubuntu can change that. I'm certainly happy with Ub. on hosts
[19:02] <comradekingu> Even nokia isnt alone in the mobile linuxworld anymore
[19:03] <comradekingu> Only palm is i think
[19:05] <nosse1> Since ubuntu is built natively, this implies that you build your own toolchains as well (don't use the popular CodeSourcery, or do you)?
[19:58] <nosse1> All right, I think I finally got the qemu thing going. Tomorrow I will try it on real target.
[19:59] <nosse1> If it still doesnt work, what is my approach for figuring it out? I know it started init, but I didn't get a login prompt
[20:04] <nosse1> For all you guys helping me out: I hope I haven't annoyed too much. Thanks a lot for you help!
[20:20] <jim_rees> How hard would it be to get ubuntu running on this? http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=170414804289


[04:56] <ScottK> Riddelll: Looks like we forgot to update bluedevil to the current release.
[07:17] <soee> good morning
[07:29] <lordievader> Good morning
[08:41] <jussi> anyone remember the Qt/html in a web browser thing ?
[10:22] <agateau> jussi: emscripten-qt?
[11:36] <Riddelll> jussi: Wt?
[11:44] <BluesKaj> Howdy folks
[12:54] <Darkwing> Morning
[12:54] <Riddelll> hi Darkwing
[12:54] <Darkwing> Riddelll: you have 3 'l' :D
[12:55] <Riddelll> gosh how special of me
[12:55] <Darkwing> Riddelll: Also, does it look like we are going to be heading toward a "rolling release"?
[12:55] <ScottK> Darkwing: No.
[12:55] <Riddell> Darkwing: nope
[12:55] <Darkwing> Really... Nothing changing then? :D
[12:56] <Riddell> shorter support period and more encouragement for people to use development version
[12:56] <Darkwing> ahhhh...
[12:56]  * Darkwing poders the docs
[12:58]  * ScottK hands Darkwing an "n".
[12:59] <Darkwing> s/poders/ponders/
[12:59] <kubotu> Darkwing meant: "ponders the docs"
[12:59] <Darkwing> I want to switch to an online docs system, then pull them, fix the XML and upload. This way we can get more people in without forcing them to write Docbook...
[13:00] <Riddell> and we can get them online for free \o/
[13:00] <Darkwing> Yup
[13:00] <Darkwing> I just need to find the right software to use... Plus, something with a translation api built in.
[13:01] <Darkwing> or, just straight translations.
[13:01] <Riddell> mm, tricksy
[13:01] <Darkwing> I would also love a "Did this article help" button at the bottom.
[13:12] <Riddell> Darkwing: seen ubuntu-manual?
[13:13] <Riddell> that's quite accessible compared to the official docs
[13:27] <Darkwing> Aye... hmmz.
[13:28] <Riddell> there was a technical docs writer at the hack event I was at this weekend who commented on it as a good manual
[13:29] <Riddell> she also says she'd be happy to do some for kubuntu if she was told what 1 hour job to do
[13:29] <Riddell> which is a bit limited usefulness alas
[13:29] <Darkwing> You have an email addy?
[13:29] <Darkwing> Not really... If she can write in ODT or any text format, I'll drop it into XML/Docbook for her
[13:37] <Riddell> Darkwing: http://www.techaddiction.co.uk/contact/
[13:37] <Riddell> i think it'll need a specific appropach "update this article" etc rather than anything vauge
[13:38] <Riddell> and we'll need to convince her to install kubuntu but she's in the market for upgrading from 10.04 :)
[13:39] <Darkwing> I run the LTS on my desktop but, VM is good for it because it gives me a non-custom install
[13:40] <Darkwing> Riddell: I'll orgonaize the todo list better.
[13:55] <Mamarok> I have no more notifications since my upgrade to 13.04 beta1
[13:55] <soee> :D
[13:55] <jussi> agateau: itwas emscripten, thanks
[13:56] <agateau> yw
[13:57] <Mamarok> gah, apparently the Notifications widget is not on the panel anymore by default
[13:57] <Riddell> umm
[13:58] <Riddell> /usr/share/kubuntu-default-settings/kde4-profile/default/share/apps/plasma-desktop/init/00-defaultLayout.js does still say notifier
[14:00] <soee> Riddell, todays updates make my system beta1 version ?
[14:00] <Mamarok> for some obscure reason it was not in my panel anymore, and I have started with a fresh ~/.kde/ when I upgraded
[14:00] <Riddell> soee: beta 1 and a week
[14:00] <Riddell> Mamarok: mm needs testing
[14:01] <Riddell> I mean I'll do testing to confirm
[14:01] <Riddell> we also need to ensure the print applet gets added on upgrade
[14:21] <soee> how can i clone git specific branch ?
[14:30] <ryanakca> Riddell: Seeing that I haven't made any proper changes to www.k.o in years and don't even know the current www-admin passwords, my name on http://www.kubuntu.org/contact-us should probably be replaced by whoever's currently taking care of things...
[14:35] <ScottK> ryanakca: Or you should start contributing again would be another option ...
[14:36] <Riddell> ryanakca: you're assuming someone is taking care of things :)
[14:37] <ryanakca> ScottK: Does the work breakdown still include 80% of time dedicated to nagging sysadmins?
[14:37] <ScottK> Only when we want to change stuff they need to change.
[14:37] <ScottK> Mostly we try to avoid that.
[15:30] <Riddell> ScottK: want to review bug 1159262 so I can review it for New?
[15:30] <ScottK> Riddell: Done.
[15:31] <ScottK> Riddell: What do you think about updating bluedevil?  We're a major release behind ATM.
[15:31]  * ScottK thinks we probably should, but can't test it.
[15:31] <Riddell> ScottK: yeah was going to look at that shortly, I see alex blogged about it too
[15:32] <ScottK> Thanks.
[15:35] <Darkwing> I have a couple of BlueTooth dongles...
[15:35] <Darkwing> and a laptop with bluetooth built is.
[15:35] <Darkwing> s/is/in/
[15:35] <kubotu> Darkwing meant: "and a laptop with bluetooth built in."
[15:36] <Darkwing> Precise, Quantal and Raring
[16:59] <Riddell> ScottK: do you agree this new bluedevil doesn't need a FFe? http://www.afiestas.org/bluedevil-1-3-released/
[16:59] <Riddell> it's just bugfixes according to that post
[17:01] <ScottK> Riddell: Agreed.
[17:02] <xnox> so in gtk world libindicate got deprecated in favor of using messaging-menu-dev (~quantal FFe). I'm now looking at reverse dependenices and I'm now finding: libindicate -> plasma-widget-message-indicator -> kopete-message-indicator.
[17:03] <Riddell> afiestas_: why the new version number for bluedevil 1.3?
[17:03] <xnox> Now I am confused, is this meant to integrate kopete with indicator in a gnome DE -> in that case it needs porting to messaging-menu.
[17:03] <afiestas_> Riddell: what do you mean?
[17:03] <Riddell> agateau: ^^
[17:03] <Riddell> afiestas_: why 1.3 rather than 1.2.2?
[17:03] <xnox> and is plasma-widget-message-indicator -> dissplay libindicate in a KDE DE? -> in that case it should be ported to display messaging-menu
[17:03] <Riddell> afiestas_: it looks like bug fixes only
[17:04]  * xnox ponders what should I be porting to what =)
[17:04] <afiestas_> Riddell: because there is a huge patch that I did not wanted in 1.2
[17:04] <xnox> unless this is all kde specific and nothing to do with gtk side of things.
[17:04] <afiestas_> removing the thread from KDED and use async dbus api instead
[17:04] <agateau> xnox: plasma-widget-message-indicator is the kde equivalent of the message menu
[17:05] <agateau> xnox: it is based on libindicate-qt, which is a wrapper for libindicate
[17:05] <Riddell> kopete-message-indicator recommends plasma-widget-message-indicator but it can aso work with unity messaging applet
[17:05] <agateau> xnox: and kopete-message-indicator is a kopete plugins which makes it work with those message menus
[17:06] <xnox> cool, thanks.
[17:06] <xnox> Now libindicate is depreated in favor or "src:indicator-messages" & libmessaging-menu-dev, which doesn't seem to have a -qt variant =( *sigh*
[17:07]  * xnox wishes gir could generate C++/Qt style bindings.
[17:07] <Riddell> the seems like quite an oversight from the people who did that deprecation
[17:08] <xnox> Riddell: it really means that all the apps that got ported to messaging-menu work in Gnome/Unity, but don't work in KDE. And only "legacy" unported work in KDE, but not GNOME/Unity.
[17:08]  * xnox is dizzy and day-dreaming about XOR function
[17:09] <Riddell> time to remove the whole messaging menu from KDE then?  what a shame
[17:56] <ScottK> xnox: It means Canonical is consistent in how good a job they do of coordination can working with others.
[17:56] <ScottK> Riddell: Unfortunately, I think that's true.
[17:56] <murthy> hello everyone
[18:10] <murthy> Riddell: did smartboyhw change his nick?
[18:14] <Riddell> murthy: no don't think so
[18:14] <Riddell> he's just not online much at the minute
[18:14] <Riddell> he did say something about nookita at the weekend
[18:14] <Riddell> not sure the current status of that
[18:16] <ScottK> He was asking for reviews.
[18:17] <murthy> Riddell: are we allowed to use the latest standards for new packages and can we update the standards of the present packages to the latest?
[18:18] <murthy> Riddell: last time i was told not to do that, but i saw in a changelog that smartboyhw has updated the standards to the latest
[18:19] <Riddell> murthy: of course you're allowed to and encouraged to update them but not if it makes a diff compared to debian
[18:19] <Riddell> you should read over the current debian standard to ensure it complies with it
[18:20] <murthy> Riddell: that implies we can use the latest standards for new packaging?
[18:20] <Riddell> murthy: of course
[19:06] <xnox> murthy: i started to always do it, just to get matching/latest lintian nitpicks.
[19:13] <murthy> xnox: ok
[19:34] <sudeep> Hi. I am an undergraduate student. I have worked with Qt and C++ to create small applicationsn like games, music players, hotel automation softwares etc. Can somebody recommend me a open source project in KDE for me to begin? Ideally the priject should be small scaled so that there is a lot of scope of contribution.
[19:52] <murthy> sudeep: did you take a look at the kde gsoc 2013?
[19:53] <murthy> sudeep: http://community.kde.org/GSoC/2013/Ideas
[19:55] <murthy> sudeep: kmix is in need for devs
[19:56] <sudeep> murthy: Actually I am new to open source and want to proceed slowly i.e. by starting of by fixing bugs etc.
[19:56] <murthy> sudeep: ya, kmix is one such
[19:57] <sudeep> any more? Like I had a look at arora browser. It was really nice but was dead.
[19:59] <murthy> sudeep: do you want to work for kde or do you want to work for kubuntu particularly?
[20:01] <sudeep> murthy: Anyone. I have mostly being doing GUI programming. Now I am looking for something application like a web browser or music player or desktop manipulator wherein I can add features.
[20:03] <murthy> sudeep: do you know python?
[20:04] <sudeep> murthy: yup!
[20:05] <murthy> sudeep: in that case what about the kubuntu installer ubiquity?
[20:07] <sudeep> murthy: Ok. I am sorry but I would like to work in C++. I will have a look at ubiquity anyway. Anymore suggestion in c++?
[20:10] <murthy> sudeep: have you seen this http://community.kde.org/KDE/Junior_Jobs   ?
[20:11] <murthy> sudeep: ignore kopete in that list
[20:13] <murthy> sudeep: plasma media center is also one
[20:14] <murthy> sudeep: if you know qml you could port some of the plasma widgets
[20:24] <ScottK> shadeslayer: I may have been blaming you unfairly.  This exam thing must be cultural.  vibhav was just blaming exams for lack of contribution.
[20:25] <ScottK> :-)
[20:32] <murthy> ScottK: same condition here
[20:37] <ScottK> murthy: shadeslayer was the master of the things he could do, but not for exams.
[20:37] <ScottK> Now it's usually something about sleep.
[20:39] <murthy> ScottK: ya, but he is not Mr. unstoppable :D
[20:43] <Quintasan> yofel: ping
[20:44] <yofel> Quintasan: pong, more or less
[20:44] <Quintasan> yofel: Do you have problems when trying to unlock from suspend?
[20:44] <murthy> yofel: hi
[20:45] <murthy> Quintasan: you are not able to unlock?
[20:45] <yofel> nope, works for me always. It's more a questiong whether it *locks*
[20:46] <Quintasan> murthy: More precisely -> I open the lid -> get the password promt for unlock -> I can input the password but pressing unlock does nothing
[20:46] <Quintasan> I finally killed it with dbus
[20:47] <murthy> Quintasan: let me check
[20:47] <murthy> Quintasan: works here
[20:48] <Quintasan> It doesn't tirgger every time here
[20:48] <murthy> Quintasan: trigger what?
[20:49] <Quintasan> the bug...
[20:50] <murthy> Quintasan: anything in the logs?
[20:50] <Quintasan> Can't say anything for sure, .xsession-errors yields nothing
[20:51] <murthy> Quintasan: kde version?
[20:51] <Quintasan> 4.10.1
[20:52] <murthy> same here
[20:53] <murthy> do you have some component from masters installed? i guess that may be a cause
[20:53] <Quintasan> That's a wild (and incorrect guess)
[20:53] <Quintasan> I thought you have an idea but I guess you're as clueless as me about that
[20:54] <murthy> I haven't come across the bug yet
[21:16] <yofel> Quintasan: ping
[21:16] <Quintasan> one more time in 3 seconds :P
[21:16] <yofel> !ping | Quintasan
[21:17] <Quintasan> hurrrrrrrrrrrr
[21:17] <jussi> Quintasan: its all your fault...
[21:17] <Quintasan> yofel: I have no fucking idea why but sometimes my plasma notification get misplaced
[21:17] <Quintasan> Like, they go to the middle of the screen instead of right above the task bar
[21:17] <Quintasan> !ping
[21:17] <yofel> if you mean top-middle with different style then knotify is not running
[21:17] <Quintasan> hurr
[21:18] <Quintasan> yofel: no, the style is oxygen
[21:18] <yofel> Quintasan: weird
[21:18] <jussi> Quintasan: evil
[21:18] <Quintasan> !ping | Quintasan
[21:18] <Quintasan> yeah
[21:18] <jussi> Quintasan: I had that on an older release
[21:18] <jussi> Quintasan: because I can...
[21:18] <Quintasan> I just removed the damn notification from systray and readded it and now it works
[21:19] <jussi> Quintasan: Im going to bed, good night
[21:19] <jussi> :D
[21:19] <Quintasan> jussi: Well you've been so long here
[21:19] <Quintasan> :P
[21:19] <jussi> lol
[21:19] <Quintasan> jussi: Good night then
[21:19] <jussi> nini
[22:54] <Quintasan> well
[22:54] <Quintasan> I'm off to bed too
[23:00] <yofel> nini Quintasan


[04:33] <phillw> Hi bug people.. This is a new bug to me, but will affect bug reporting
[04:33] <phillw> (04:02:10) Suxxxxxx: The current allocation for the crashkernel value is too low to correctly load the default initrd.img. This means that the OOM killer will break the crash dump capture procedure. While the bug is being worked on, you can increase the value of crashkernel to something more than 150Mb to work around the bug.
[04:33] <phillw> (04:02:30) Suxxxxxx: even the bug reporting tool is bugged!


[14:57] <balloons> 3 mins left . ..
[14:58] <phillw> balloons: take it to #ubuntu-testing?
[14:59] <balloons> yes -- astraljava just pinged me.. I've been sitting here.. I don't know why my reminder didn't pop on my desktop.. I'm not used to the new time.. sorry guys :-(
[15:00] <balloons> hggdh, jibel, Effenberg0x0, roignac, txomon|afk care to join in #ubuntu-testing.. we'll meet a bit late :-(
[15:01] <Effenberg0x0> balloons, if you want to use #U+1, in case #ubuntu-testing is too crowded, please feel free.
[15:02]  * slangasek waves
[15:03] <jodh> o/
[15:04]  * ogra_ moos
[15:06] <slangasek> #startmeeting
[15:06] <meetingology> Meeting started Wed Apr 18 15:06:01 2012 UTC.  The chair is slangasek. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[15:06] <meetingology> Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired
[15:06] <slangasek> [TOPIC] lightning round
[15:07] <slangasek> $ echo $(shuf -e barry doko stgraber jodh ev bdmurray slangasek ogra infinity cjwatson)
[15:07] <slangasek> jodh ev stgraber doko barry cjwatson ogra infinity bdmurray slangasek
[15:07] <jodh> * [boot]
[15:07] <jodh>   - plymouth: Sent a real fix for bug 553745 upstream (awaiting
[15:07] <jodh>     feedback). Hopefully, we'll be able to close the 270 duplicate bugs
[15:07] <jodh>     real soon now :)
[15:07] <jodh>   - lightdm: Comments on bug 969489. Needs more thought.
[15:07] <jodh> * [doc]
[15:07] <jodh>   - Cookbook updates (the cookbook now appears to have broken rst2pdf :()
[15:07] <jodh> * [misc]
[15:07] <jodh>   - Updated https://wiki.ubuntu.com/FoundationsTeam/PreferredTechnologies
[15:07] <jodh> * [release]
[15:07] <jodh>   - Lots of work on Upstart Release Notes
[15:07] <jodh>     https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/TechnicalOverviewUpstart
[15:07] <jodh> ⠕
[15:08] <ev> - Finished the apport branch that handles breaks/replaces in the retrace cache
[15:08] <ev>   which I mentioned last week.
[15:08] <ev> - Continued to shop the crash database statistics website design around.
[15:08] <ev>   Please give me your feedback as time allows.
[15:08] <ev> - Meeting with the good folks at Acunu on Friday to discuss their Acunu
[15:08] <ev>   Anayltics project which we may use as the foundation of our metrics service.
[15:08] <ev>   They're debating internally whether or not to open source it, with some
[15:08] <ev>   people pushing hard for it to be open. Unfortunately it's a bit of a black
[15:08] <ev>   box at the moment as the copy they're distributing is binary-only. I've put
[15:08] <ev>   it up in the Canonicloud with a public IP and am working on instructions for
[15:08] <ev>   those that want to test metrics collection against it.
[15:08] <ev> - Built a mean time between failures graph using sample data and the very cool
[15:08] <ev>   nvd3 that itself builds on the even cooler d3.js:
[15:08] <ev>   http://novus.github.com/nvd3/examples/cumulativeLine.html
[15:08] <ev> - Built out support in oops-repository for collecting mean time between
[15:08] <ev>   failures in real time. Worked with webops to get this deployed.
[15:08] <ev> - Fought CSS to the death (and lost) attempting to get our most common
[15:08] <ev>   problems table to use 100% of the available width, giving as little as it
[15:08] <ev>   can to all the columns except for the signature one. Hacking around for now.
[15:08] <ev> - Dug at the whoopsie build failures on PPC and ARM. Traced the cause to a
[15:08] <ev>   non-boolean function used as a glib callback. Fixed.
[15:08] <ev> - Changed our retracing code to use the new cached sandboxes and manage their
[15:08] <ev>   creation and removal. This had a slight bug in that it was creating
[15:08] <ev>   sandboxes for every single crash it retraced, quickly eating up the space on
[15:08] <ev>   that production machine. I've fixed this and webops are working on deploying
[15:08] <ev>   it.
[15:08] <ev> - Sat in on a FY11 presentation given by Rick.
[15:09] <ev> - Meeting with the design team to discuss an improved mockup and specification
[15:09] <ev>   process.
[15:09] <ev> (done)
[15:09] <stgraber> Very short week, was off on Friday, Monday and Tuesday
[15:09] <stgraber> - ISO tracker
[15:09] <stgraber>  - Minor bug reporting bugfix pushed to production
[15:09] <stgraber> - Containers
[15:09] <stgraber>  - Minor LXC fixes
[15:09] <stgraber> - Installer
[15:09] <stgraber>  - Fixed bug 966294!
[15:09] <stgraber>  - Fixed some more installer bugs (bug 973794, bug 984883)
[15:09] <stgraber> - Release
[15:09] <stgraber>  - Code review for unapproved uploads
[15:09] <barry> stgraber: \o/
[15:09] <stgraber>  - ISO testing
[15:09] <stgraber> - TODO this week (today/tomorrow)
[15:09] <stgraber>  - Continue bug fixing and testing images.
[15:09] <stgraber> (DONE)
[15:10] <doko> - ARM dynamic linker path - call and updates.
[15:10] <doko> - python2.6 rebuilds and removals
[15:10] <doko> - python 2.7.3 and 3.2.3 final releases
[15:10] <doko> - prepared sru updates for python-defaults and gcc-4.6
[15:10] <doko> - prepare toolchain opening for q (gcc-4.7 ARM fixes, fixed or sent patches for all gcc-4.7
[15:10] <doko>  ftbfs (main), work done in unstable).
[15:10] <doko> - Linaro gcc-4.6 and 4.7 merges
[15:10] <doko> - gdb Linaro update (rejected)
[15:10] <doko> - best guesses on bug 983981.
[15:10] <doko> (done)
[15:11] <barry> bug 975417; bug 873468; debian bug 585145; python issue 9762; unity 2d HUD testing; more python3 transition work for 12.10; done.
[15:11] <ev> jodh: thanks for those updates to PreferredTechnologies!
[15:11] <jodh> ev: np
[15:11] <jodh> ev: I feel that page could one day outgrow the cookbook :)
[15:12] <ev> I sure hope so :)
[15:12] <slangasek> jodh: 969489> I had talked with bryce and apw about that the other day; the real problem seems to be that the graphics-device-added event happens before the device is actually ready, for obscure kernel reasons, and we don't have a reliable event that things can wait on
[15:12] <ev> there's already lots of good pointers in there about things I was completely unaware of.
[15:12] <cjwatson> Some more installer translation merges.  Tweaked partman-auto to reduce risk.
[15:12] <barry> indeed
[15:12] <cjwatson> Add hd-media/non-pae installer build (bug 977568).
[15:12] <cjwatson> Spent Thursday in London, mostly helping James track down the famous plymouth crash.
[15:12] <cjwatson> Fixed mountall and NTFS not being friends when pass!=0 (bug 838091).
[15:12] <cjwatson> Fixed the last two powerpc-specific build failures in main.  Cleaned up a few other NBS and FTBFS bits and pieces.
[15:12] <jodh> slangasek: ugh!
[15:12] <cjwatson> Add manual download verification pass to ubiquity to work around apt bug 922949.
[15:12] <cjwatson> Disable webkit cache in installer slideshow in an attempt to work around bug 979350.  That's still outstanding and tricky, though.
[15:12] <cjwatson> Holiday on Monday.
[15:13] <cjwatson> Miscellaneous command-not-found cleanups.
[15:13] <cjwatson> grub2 EFI backports to fix bug 975061.
[15:13] <cjwatson> Fix broken panel colour in ubiquity (bug 982883).
[15:13] <cjwatson> Fix broken location of kernel/initrd symlinks on powerpc (bug 958839).
[15:13] <cjwatson> Worked on analysing various upgrade bugs, and generally tried to clean up our rls-p-tracking list.
[15:13] <cjwatson> Working with dpkg upstream on bug 983187.
[15:13] <cjwatson> ..
[15:13] <ogra_> done:
[15:13] <ogra_> * many many hours spent on more compiz issues (actually nearly all my week, i'm in the last stages of testing it in the images,
[15:13] <ogra_>   seems there are still minor issues with gtk-window-decorator)
[15:13] <ogra_> * had long discussions with linaro about possible blueprints for arm bits (summary mail to platfound ML pending)
[15:13] <ogra_> * tons of user support over the weekend to nail down why suddenly initramfs doesnt find /init anymore on arm (fixed by infinity)
[15:13] <ogra_> * did some peer reviews
[15:13] <ogra_> * partman-uboot will have to be either SRU or go into 12.10 proper, compiz just stole to much of my time :(
[15:13] <ogra_> todo:
[15:13] <ogra_> * finish peer reviews
[15:13] <ogra_> * finish ubuntu-core wikipage rewrite
[15:13] <ogra_> * look into fsck slowdown (sorry steve, still didnt get to it :/ )
[15:13] <ogra_> UDS:
[15:13] <ogra_> * linaro would like to:
[15:13] <ogra_>   a) have truely embedded image possibilities and closer integration for any embedded stuff (like dev environments
[15:13] <ogra_>     (i.e. board specific eclipse plugins) but also the opportunity to build actual embedded images (i.e. for systems
[15:13] <ogra_>     with only 64M ram and 128M flash space)
[15:13] <ogra_>   b) see us integrate HW-pack usage into our build system (to drop duplication, we all seem to build the same stuff)
[15:14] <ogra_>     both should become blueprints imho.
[15:14] <ogra_> ..
[15:14] <jodh> ogra_: what was the cause of the inaccessible /init ?
[15:15] <ogra_> jodh, linker path breakage in initramfs-tools and d-i
[15:15] <ogra_> well, fsvo breakage :)
[15:15] <cjwatson> aka fallout from change in progress
[15:15] <ogra_> right
[15:16] <ogra_> well, i dont think adam expected that he had to touch it
[15:16] <ogra_> oh
[15:16] <ogra_> ..
[15:20] <slangasek> ogra_: fsck slowdown> well if people would just be happy running metacity on arm... ;)
[15:20] <ogra_> haha
[15:20] <slangasek> ogra_: please get blueprints registered for both of those topics and targeted to the sprint
[15:20] <ogra_> well, its not off my TODO
[15:20] <ogra_> yeah, will do
[15:20] <slangasek> bdmurray:
[15:21] <ogra_> fsck can well be SRUed ... sadly partman-uboot is useless as SUR until 12.04.1
[15:21] <bdmurray> bug triage of update-manager and ubiquity bug reports
[15:21] <bdmurray> uploaded an apport change to check /cdrom fullness for package install failures
[15:22] <bdmurray> uploaded update-manager patch in bug 945536
[15:22] <bdmurray> reported ubiquity bug 979350 regarding out of memory
[15:22] <bdmurray> reported casper bug 984276 regarding installing casper on non-live systems
[15:22] <slangasek> well, and also useful for people building other images out of the precise archive (i.e., OEMs)... so still worth doing even if it slips
[15:22] <bdmurray> consolidation of duplicates of bug 984276 and bug 902603
[15:22] <bdmurray> bug triage of ubiquity bug 980676 and finding duplicates of it
[15:22] <bdmurray> wrote a flashplugin-nonfree bug pattern for bug 876298 (dupe cleanup too)
[15:22] <bdmurray> added a bug pattern for bug 975320 regarding update-manager / aptdaemon
[15:22] <bdmurray> converted some harvest opportunities to output json data instead of csv files
[15:22] <bdmurray> wrote code to query ultimate debian database for duplicate title bugs by the same reporter
[15:24] <slangasek> bdmurray: done?
[15:25] <bdmurray> .. done ..
[15:25] <slangasek>  * release queue reviews
[15:25] <slangasek>  * follow through on update-notifier for the downloader changes (bug #979477, bug #979426, bug #976761)
[15:25] <slangasek>  * fixed busybox creating directories with wrong perms on 64-bit (bug #980772)
[15:25] <slangasek>  * fixed race condition in crypted swap on boot (bug #874774)
[15:25] <slangasek>  * followed through on the insserv breakage cleanup (bug #941867)
[15:25] <slangasek>  * killed defoma out of main
[15:25] <slangasek>  * trimmed plymouth bug pattern to not match on precise, now that we think the bugs are fixed (so we can see any reports that they aren't)
[15:25] <slangasek> done
[15:27] <slangasek> any questions anywhere?
[15:27] <slangasek> [TOPIC] Bugs
[15:28] <bdmurray> I've tried recreating bug 978181 and bug 974402 without any luck
[15:28] <bdmurray> I don't think many people choose btrfs but it is still worrisome
[15:29] <slangasek> encrypted home would never prevent the directory from being created, AFAIK
[15:29] <slangasek> though I guess ecryptfs+btrfs could be making the filesystem explode
[15:29] <cjwatson> this sort of thing can happen if user-setup-apply runs into an error and bails out early
[15:31] <cjwatson> but that's not what's happening in 978181 at least
[15:31] <slangasek> I have a vague memory of seeing something else on IRC about btrfs this week
[15:31] <cjwatson> oh eep the @home madness
[15:31] <slangasek> something about problems when /home is on btrfs and you're installing over an existing system?
[15:31] <cjwatson> it might make a difference if you're reusing an existing @home, yes
[15:33] <slangasek> bdmurray: is it worth testing that?
[15:34] <slangasek> i.e., install, then try to install again over it
[15:34] <bdmurray> I'll look for more duplicates but I don't think so
[15:34] <slangasek> you don't think it's worth testing?
[15:35] <bdmurray> slangasek: I don't think its worth testing before release
[15:35] <slangasek> ok
[15:36]  * slangasek asks on the bug then
[15:36] <slangasek> moving on
[15:36] <bdmurray> I previously mentioned bug 984276
[15:37] <bdmurray> I was surprised by the number of people who install casper
[15:37] <ogra_> yeah, but there is no easy solution apart from making it uninstallable on non live fses
[15:37] <ogra_> i mean, if users want to shoot both their feet, who are we to stop them
[15:37] <slangasek> the question is why they're doing so
[15:38] <ogra_> indeed
[15:38] <slangasek> do they have a fondness for friendly ghosts, or is some web page telling them to, or...
[15:39] <ogra_> hmm, wasnt there another bug that was actually community reported ?
[15:39] <ogra_> oh, sorry, i'm blind .. just a master
[15:40] <bdmurray> casper shows up in software center fwiw
[15:40] <slangasek> bdmurray: how should we approach this to figure out where this problem is coming from?
[15:40] <slangasek> in software-center> doh
[15:40] <slangasek> bdmurray: can you open a bug report on software-center about getting that fixed?
[15:41] <bdmurray> slangasek: sure
[15:41] <ogra_> we could possibly make casper chack something like "is a bootloader configured" and make it become a no-op then
[15:41] <ogra_> *check
[15:41] <slangasek> hmm, seems to be a general problem
[15:42] <slangasek> 'fontconfig' also shows up in casper
[15:42] <bdmurray> ogra_: yes, I think something like that may help too
[15:42] <slangasek> ogra_: do you want to take that one?
[15:42] <ogra_> i can, sure ... i guess thats supposed to happen before release ? :)
[15:43] <ogra_> since SRUing it seems to make not much sense
[15:43] <slangasek> ogra_: best-effort
[15:43] <ogra_> k
[15:43] <slangasek> it still gives benefit if we get it in SRU, and it's not the highest priority issue
[15:44] <slangasek> btw, as far as bugs go... we have http://reports.qa.ubuntu.com/reports/kernel-bugs/reports/rls-p-tracking-bugs.html down about where we want it, and if we're taking any more bugs that it's critical to fix for .0, they'll probably be so critical that we don't even need to track them on there :-P
[15:44] <ogra_> yeah, with luck people with casper installed get the updated version before their system breaks :)
[15:44] <slangasek> so how should we be tracking bugs that are priorities but that aren't tied to .0?
[15:44] <slangasek> rls-p-tracking, target to precise-updates?
[15:44] <ogra_> ++
[15:44] <cjwatson> I think so
[15:44] <slangasek> bdmurray: ^^ does that sound good to you?
[15:46] <bdmurray> slangasek: both? yes that's fine
[15:46] <slangasek> yeah, both
[15:48] <slangasek> bdmurray: any other new issues popping up?
[15:48] <bdmurray> bug 984593 was just reported
[15:48] <bdmurray> I haven't looked at it thoroughly yet
[15:50] <slangasek> so far I don't see anything wubi related in the bug... and the submitter broke it out into per-issue bugs for us already?
[15:50] <slangasek> i.e., all the issues he had look like upgrade issues, not wubi issues
[15:50] <bdmurray> I think they initially installed from wubi then upgraded to precise
[15:51] <slangasek> yep... I just don't see anything (yet) to make me think he actually had wubi-specific problems
[15:51] <slangasek> bug #984932 - hah
[15:51] <slangasek> cjwatson: ^^ missing image again? :)
[15:51] <cjwatson> hmm
[15:51] <slangasek> (oem-config vs. ubiquity?)
[15:52] <bdmurray> slangasek: okay, I'll dig into it and the related bugs more
[15:52] <cjwatson> different weirdness
[15:52] <slangasek> bdmurray: cheers
[15:52] <cjwatson> oem-config-gtk depends: ubiquity-frontend-gtk so I don't think it's missing image
[15:52] <slangasek> so does everyone have enough bugs to keep themselves feeling productive between now and release?
[15:52] <cjwatson> more than
[15:52] <slangasek> does anyone want to take some bugs from cjwatson? :P
[15:53] <stgraber> I'll take bug 984932
[15:53] <slangasek> stgraber: thanks
[15:53] <cjwatson> cool, that should be fine, just generally fielding installer things that come up in QA
[15:54] <slangasek> fwiw, if anyone's not finding bugs to work on, another source for them is http://reports.qa.ubuntu.com/reports/foundations-bugs/foundations-bugs-packages-hottest-bugs.html ... don't remember if this has been passed around to the team yet
[15:54] <slangasek> great report by bdmurray that shows the hottest bugs across all the foundations packages he's tracking
[15:54] <bdmurray> I'd hope I passed it around ;-)
[15:54] <cjwatson> bug 984989 needs attention (from me)
[15:54] <slangasek> [LINK] http://reports.qa.ubuntu.com/reports/foundations-bugs/foundations-bugs-packages-hottest-bugs.html
[15:55] <barry> computer-janitor makes me sad ;)
[15:55] <slangasek> but you can safely assume that any of the bugs on that graph have a significant user impact and are worth fixing
[15:55] <slangasek> heh
[15:56] <slangasek> cjwatson: rls-p-tracking?
[15:56] <ev> ooooh jquery
[15:56] <bdmurray> sssh
[15:56] <cjwatson> slangasek: why not, added
[15:56] <ev> that's going to get a shouty response
[15:56] <ev> bdmurray: ;)
[15:57] <slangasek> ev: grandfathered :P
[15:57] <ev> heh
[15:58] <slangasek> don't worry, I'll take the heat for the graph not being suitable for integrating into our webapps
[15:58] <ev> there's always d3.js...
[15:58] <bdmurray> slangasek: you'll take the heat for the heat graph? ;-)
[15:58] <slangasek> I will!
[15:59] <slangasek> bdmurray: any other bugs?
[15:59] <bdmurray> not that I know of yet
[15:59] <ev> so I've just discovered that if you download and run wubi when you have a cd in the drive, you now helpfully get the autorun menu
[15:59] <ev> this is probably my fault
[15:59] <slangasek> !!
[15:59] <slangasek> fix it fix it
[16:00] <ev> my whole day has been fixing things! Can't I just break things for a little while?
[16:00] <slangasek> no, break things on your own time
[16:00] <ev> lol, damn
[16:00] <slangasek> preferably in some other OS ;)
[16:00] <slangasek> [TOPIC] AOB
[16:00] <slangasek> anything else?
[16:00] <cjwatson> who's going to the release sprint from our team?
[16:00] <ev> would still appreciate your collective feedback on that email I sent
[16:01] <cjwatson> I believe I am
[16:01] <ev> o/
[16:01] <slangasek> infinity is
[16:01] <cjwatson> hm, looks like I need to ask about accom
[16:01] <ev> who's going to be here not from our team? Rick and Kate?
[16:02] <ev> and presumably andy for comedy value
[16:02] <slangasek> heh
[16:02] <cjwatson> Pete too
[16:02] <ev> awesome!
[16:03] <slangasek> #endmeeting
[16:03] <ev> cjwatson: skaet and I are going to block out some time at the release sprint to discuss the crashdb website design. Care to join us?
[16:03] <meetingology> Meeting ended Wed Apr 18 16:03:57 2012 UTC.
[16:03] <meetingology> Minutes (wiki):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-04-18-15.06.moin.txt
[16:03] <meetingology> Minutes (html):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-04-18-15.06.html
[16:04] <ogra_> thanks slangasek
[16:04] <slangasek> thanks ;)
[16:04] <cjwatson> ev: sure
[16:04] <stgraber> thanks!
[16:04] <ev> cool
[16:04] <ev> thanks!
[16:05] <barry> thanks!
[17:01] <bdmurray> anyone here for the bug squad meeting?
[19:58]  * phillw shushhh... don't tell anyone I'm here :P
[19:58] <MrChrisDruif> I'll won't phillw
[20:02] <gilir> #startmeeting Lubuntu Team Meeting
[20:02] <meetingology> Meeting started Wed Apr 18 20:02:59 2012 UTC.  The chair is gilir. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[20:02] <meetingology> Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired
[20:03] <gilir> hi :)
[20:03] <kanliot> o/
[20:03] <phillw> o/
[20:03] <MrChrisDruif> \o
[20:03] <Yorvyk> o/
[20:03] <gilir> Agenda is still at the same place : https://wiki.ubuntu.com/Lubuntu/IRC%20Meetings/Agenda
[20:05] <gilir> #topic gilir - Review ACTIONS from the last meeting
[20:05]  * phillw phew... nothing I have not done
[20:06] <gilir> MrChrisDruif, any progress for offline documentation ?
[20:06] <MrChrisDruif> Nope, sorry about that
[20:06] <MrChrisDruif> Week was crazy busy
[20:07] <phillw> MrChrisDruif: plenty of time, not needed for about 3 months for 12.10 :)
[20:07] <gilir> MrChrisDruif, no problem, I think it's already too late for 12.04
[20:08] <gilir> let's add it to the TODO list for 12?10 :)
[20:08] <MrChrisDruif> True, but still it's better to get it done so we only need to add it! ^_^
[20:08] <gilir> ok, let's move to the next topic
[20:09] <phillw> MrChrisDruif: let's see what UDS-Q decide on the matter
[20:09] <PereZ> hi =P
[20:09] <gilir> #topic kanliot - Weekly report - Update from QA meeting and team
[20:09] <MrChrisDruif> Aloha PereZ
[20:09] <kanliot> ok phil sent me an email i'm working from that
[20:09] <kanliot> https://lists.launchpad.net/lubuntu-qa/msg00598.html
[20:09] <kanliot> a
[20:09] <kanliot> 1.thanks to the devs, and the hard-working release team
[20:09] <kanliot> 2. we need more testers: please read
[20:09] <kanliot> https://wiki.ubuntu.com/Lubuntu/Testing
[20:09] <kanliot> 3.there's a bug with 32 bit apt.  So people with 32 bit applications installed will have problems with those applications when they upgrade.  see
[20:09] <kanliot> https://bugs.launchpad.net/ubuntu/+source/apt/+bug/850264
[20:09] <kanliot> any questions before i move on?
[20:10] <kanliot> k
[20:10] <kanliot> 4.
[20:10] <kanliot> the release of 12.04 will have  a bug
[20:10] <kanliot> unfixed bug
[20:11] <kanliot> full disk encryption will not be working, and you can install with full disk encryption selected
[20:11] <kanliot> so installs in that case will not work
[20:11] <kanliot> I'm looking for help. i donno how to document this
[20:11] <kanliot> since fixing it is not possible
[20:11] <kanliot> any comments phillw?
[20:11] <gilir> it's affecting only us or all ISO ?
[20:11] <kanliot> good question
[20:11] <kanliot> i donno
[20:12] <kanliot> but it's real enough
[20:12] <phillw> kanliot: there is work-around
[20:12] <MrChrisDruif> gilir; all releases
[20:12] <MrChrisDruif> It's just not affecting a lot of people due to how the bug happens
[20:12] <phillw> gilir: it is a kernel bug, for limited number of set ups. but is expected to affect everyone
[20:12] <gilir> so it shoudl be documented in the Ubuntu release notes
[20:13] <phillw> gilir: do you now have my emails go to spam :(
[20:13] <phillw> I did explain it earlier as to what was decided.
[20:13] <gilir> adding a note on the release notes sounds enough for me, since we can't fix it, we can't do better IMO
[20:14] <MrChrisDruif> Shouldn't it be on the "main" Ubuntu release notes if it affects us all?
[20:14] <phillw> gilir: no, they do not see it as warranted at this point, just that we have the work-around documented, in case it goes viral.
[20:14] <gilir> MrChrisDruif, yes, it should be
[20:15] <phillw> MrChrisDruif: it affects, so far, one person. It is a confirmed bug, but only only on that set up. They are wathing for dupes arriving.
[20:15] <phillw> *watching*
[20:16] <gilir> ok, so if it's not mentionned on the main releases notes, we can still add it on ours if we think it's necessary
[20:16] <MrChrisDruif> So for now only document the work-around and if it's confirmed it'll be put on Ubuntu's release notes?
[20:16] <MrChrisDruif> Yup
[20:16] <gilir> we are quite free for our release notes :)
[20:17] <gilir> kanliot, phillw, anything else ?
[20:17] <kanliot> no
[20:17] <phillw> gilir: ATM, just register it at FAQ/WorkAround
[20:18] <phillw> we can always move it higher if it does become a major problem for the entire *butnu release.
[20:18] <gilir> ok thanks kanliot and phillw :)
[20:18] <kanliot> wwia
[20:18] <kanliot> wait
[20:19] <kanliot> 1 more thing
[20:19] <phillw> https://bugs.launchpad.net/ubuntu/+source/apt/+bug/850264
[20:19] <kanliot> uh
[20:19] <kanliot> nvidia drivers are really bad
[20:19] <kanliot> phillw how bad are they?
[20:19] <kanliot> apparently tons of crashes
[20:19] <kanliot> anyhow thats all i have
[20:19] <phillw> I am on the previous bug, that messes up any upgrade from 11.10--> 12.04?
[20:20] <kanliot> and it's never clear that it's not the applications that are crashing
[20:20] <kanliot> ok you go first
[20:20] <gilir> phillw told us that it should be fixed soon
[20:21] <gilir> well, already fixed, just need to be uploaded,  anything to add ?
[20:21] <phillw> The fix for that is out and about, but it does REALLY need testing, we are running out of time for the RC's
[20:21] <phillw> gilir: , yes - it needs testing & proven as a fix.
[20:22] <gilir> phillw, ping me when it's in, and if you need test
[20:22] <phillw> it will be in the next respin
[20:22] <gilir> ok
[20:22] <phillw> which *should* be there now.
[20:23] <gilir> anything to add ?
[20:24] <phillw> kanliot: anything else to add? this time next week, it is D-Day+1 :)
[20:24] <kanliot> no thanks
[20:24] <kanliot> you should be studying phillw
[20:24] <kanliot> do your homework
[20:25] <gilir> ok, let's move to the next topic
[20:25] <phillw> gilir: I'll keep people updated for anything important.
[20:25] <gilir> #topic kanliot - Weekly report - Update from Comms team
[20:25] <kanliot> Mario Behling quickly replied to my email, he says the osuosl people will put up a test site soon.  (this allows us to test the new lubuntu.net website)
[20:25] <kanliot> end of report
[20:26] <gilir> thanks kanliot
[20:27] <gilir> #topic gilir - Weekly report - Update from Devs teams
[20:28] <gilir> nothing on 12.04 this week, it shoudl be ready for our part :)
[20:29] <gilir> I started the preparation for 12.10
[20:29] <gilir> nothing spectacular so far
[20:29] <gilir> #link https://blueprints.launchpad.net/ubuntu/+spec/lubuntu-q-work-items
[20:30] <gilir> if you want to look at it ^^
[20:30] <gilir> you can also add comments on the whiteboard section
[20:31] <gilir> the goal is to prepare all importants items to discuss for UDS
[20:31] <MrChrisDruif> Good to hear gilir
[20:31] <gilir> any questions ?
[20:32] <gilir> of course, it's still not compete, I have still some suprises hidden ;)
[20:32] <phillw> when do we start the bi-anual discussions about what goes in to the next release?
[20:33] <gilir> phillw, you can start it on the blueprint
[20:33] <phillw> *bi-annual*\
[20:33] <gilir> ideally, I would like to start it right after the 12.04 release, and to end it just after UDS
[20:34] <phillw> gilir: less of the 'me' bit.... I'm holding back a queue :P
[20:34] <gilir> phillw, feel free to put them on the whiteboard, to be sure we don't forget them
[20:34] <phillw> that is a massive +1 from me :)
[20:35] <phillw> not from me, from others!
[20:35] <gilir> just, if you want to start discussion for application by default, do it with some arguments :)
[20:37] <gilir> any others questions ?
[20:37] <gilir> I forgot, you can subscribe to the blueprint, to be aware of any modifications
[20:38] <gilir> #topic MrChrisDruif - Weekly report - Update from Docs team
[20:38] <phillw> gilir: are you sure you want to let the people on the facebook page know of this?
[20:39] <MrChrisDruif> Ali started communicating again and in turn added a section about what differs us from Ubuntu and what we have in common. I can't remember anything else, so nothing to report
[20:39] <gilir> phillw, it's not a secret, but keep the warning I made about applications by default
[20:40] <MrChrisDruif> phillw; why not? The more people contributing the better right?
[20:41] <gilir> thanks MrChrisDruif
[20:42] <phillw> MrChrisDruif: gilir I was being light hearted.... the fb people would love to contribute..... sorry if you took it the wrong way :-(
[20:42] <gilir> #topic Any Other Business
[20:43] <MrChrisDruif> Yes, add the Actions from Meetings to the Agenda gilir
[20:43] <gilir> next meeting is the last meeting before the release
[20:43] <MrChrisDruif> Already?
[20:43] <MrChrisDruif> =(
[20:43] <phillw> gilir: it is? Release is tuesday?\
[20:44] <MrChrisDruif> phillw; Thursday!
[20:44] <gilir> phillw, usually it's on thurday, no ?
[20:44] <phillw> Or, so I was told
[20:44] <gilir> https://wiki.ubuntu.com/PrecisePangolin/ReleaseSchedule
[20:44] <ScottK> It's always Thursday unless it's 10-10-10.
[20:45] <phillw> This will be news to the Canonical team, then :P
[20:45] <phillw> RC tomorrow, release tuesday.
[20:45] <stgraber> RC tomorrow, release Thursday
[20:45] <ScottK> See the spate of late FFes from Canonical development projects over multiple releases.  The schedule is always a surprise to them.
[20:46] <gilir> phillw, you see, you have 2 days more, let's relax :)
[20:47] <MrChrisDruif> Ghehe
[20:47] <gilir> anyway, for the next meeting, let's make sure all it's ready for the release
[20:47] <gilir> documentation, release notes, news article, coffee ... :)
[20:49] <gilir> anything to add before the end of the meeting ?
[20:49] <MrChrisDruif> gilir; you got my note?
[20:49] <phillw> ScottK: when balloons announced release was on tuesday, we just accepted it as so :P
[20:49] <gilir> MrChrisDruif, about what ?
[20:50] <MrChrisDruif> Yes, add the Actions from Meetings to the Agenda gilir
[20:50] <MrChrisDruif> That one
[20:50] <gilir> MrChrisDruif, what do you mean by this ?
[20:51] <MrChrisDruif> Add the Actions from previous meeting(s) to the Agenda
[20:51] <MrChrisDruif> That way it's more easy to see what actions should be done
[20:52] <gilir> ah ok, I'll do it next time we have actions in the meeting
[20:52] <MrChrisDruif> Thanks ^_^
[20:52] <phillw> MrChrisDruif: make gilir to #action it :P
[20:53] <MrChrisDruif> #action gilir Add the Actions from meetings to the Agenda
[20:53] <meetingology> ACTION: gilir Add the Actions from meetings to the Agenda
[20:53] <MrChrisDruif> phillw; like so?
[20:53] <phillw> indeed :)
[20:54] <gilir> unless I end the meeting before this :)
[20:54] <gilir> #endmeeting
[20:54] <meetingology> Meeting ended Wed Apr 18 20:54:37 2012 UTC.
[20:54] <meetingology> Minutes (wiki):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-04-18-20.02.moin.txt
[20:54] <meetingology> Minutes (html):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-04-18-20.02.html
[20:54] <MrChrisDruif> You'd have to do more then just cut the meeting log gilir ;-)
[20:54] <MrChrisDruif> Anyhow, thanks again for chairing
[20:55] <phillw> gilir: ditto
[23:02] <icallitvera> is this the lubutnu meeting chat?
[23:03] <MrChrisDruif> icallitvera; this is the proper channel, however the meeting was a few hours ago
[23:03] <MrChrisDruif> 3 hours to be precise
[23:03] <icallitvera> shoot
[23:03] <icallitvera> ha precise
[23:03] <MrChrisDruif> icallitvera; but the team is always "available" on #lubuntu-offtopic
[23:04] <MrChrisDruif> Yeah, pun intended ;-)
[23:05] <MrChrisDruif> icallitvera; /join #lubuntu-offtopic
[23:05] <icallitvera> k thanks