[09:33] <user|54247> what are the exact system requierments
[09:35] <user|54247> what are the exact system requirements
[12:10] <BluesKaj> Hiyas all
[18:55] <OnkelTem> Hi all
[18:56] <OnkelTem> So ssh-agent doesn't work on 16.04?
[18:56] <OnkelTem> Because I had it working like charm on 14.04
[18:56] <OnkelTem> And now I have to type my key password everytime I use the key
[19:07] <OnkelTem> How do you guys configure ssh-add/ssh-agent on your systems?
[19:08] <OnkelTem> On clean 16.04 this workflow just doesn't work
[19:08] <OnkelTem> I really pissed off that I have to configure such a basic trivial low-level things
[19:09] <OnkelTem> which have to work just from the beginning
[19:14] <Jarnevon> What channel would I go to for support/assistance?
[19:17] <OnkelTem> Jarnevon: try #ubuntu, cuz this one is not very active
[22:13] <lucas-arg> 17.04 will get libreoofice 5.4 and better support for kabylake gpu?
[23:24] <JonelethIrenicus> does Kube Mail have a snap?


[00:41] <stratus_ss> anyone about to help me work through some package build errors?
[09:12] <sazawal> I am using Ubuntu 13.04 64 bit with gnome-shell. My screen suddenly turns fuzzy with yellow-blue color and freezes. Keyboard-mouse stops working, even Ctrl Alt F1 doesnt work. Here is a video of the screen I shot with a camera https://www.youtube.com/watch?v=V1K0QYjon9I. I have looked at the system logs but couldnt find anything. Also before the crash I can see display tearing up with a flash in blue color 4-5 times. Please help.
[09:38] <darkxst> sazawal, please just file a bug 'ubuntu-bug gnome-shell'
[09:38] <darkxst> we cannot and don't track every random comment on IRC!
[09:39] <darkxst> and even if we did 99% of the time the OP is gone before we can even reply
[09:40] <sazawal> darkxst, I am not sure if it is a gnome-shell bug. May be it is due my graphics driver or something.
[09:40] <darkxst> sazawal, it may be, but that really isnt your concern
[09:41] <darkxst> file against gnome-shell, and it will get re-assigned if need be
[09:41] <sazawal> darkxst, right. Can you guide me through the process of filing a bug?
[09:41] <darkxst> I just did!
[09:41] <darkxst> 'ubuntu-bug gnome-shell'
[09:41] <sazawal> where I would file it? launchpad?
[09:41] <darkxst> from a terminal
[09:42] <darkxst> run that command
[09:42] <darkxst> or alt+f2
[09:42] <sazawal> Oh, I didnt know that
[09:42] <sazawal> Yes, something is going on
[09:44] <darkxst> out of curiosity what graphics driver are you using?
[09:45] <sazawal> My System Settings>Details>Graphics says Intel® Ivybridge Desktop
[09:45] <darkxst> odd, intel are usually pretty damn good (thats what most of the GNOME devs use)
[09:46] <darkxst> more often than not its the AMD proprietry blob (catalyst) that causes most issues
[09:47] <sazawal> darkxst, ok. So a launchpad page is opened and it is asking for a summary. Should I put the same question here?
[09:47] <darkxst> yah
[09:47] <sazawal> ok
[09:49] <darkxst> sazawal, also once you are done, can you try boot a new daily live CD (USB) and see if the problem persists there
[09:50] <sazawal> darkxst, I can but I am not really sure when the screen freeze happens. It happens all of a sudden. This means that I have to run Live-CD for a day or two.
[09:54] <sazawal> done
[09:54] <sazawal> Thanks darkxst
[10:02] <darkxst> sazawal, file a bug either way
[10:02] <sazawal> darkxst, done that Bug #1280162
[10:03] <sazawal> yes
[10:04] <darkxst> fwiw if Ctrl Alt F1 doesnt work its more likely a kernel of X bug
[10:06] <darkxst> ^*or*
[10:11] <sazawal> darkxst, I suspect it is due to failure of keyboard. I also tried to take screenshot while it is in freeze position but then when I restarted there was no screenshot in Pictures folder.
[10:12] <darkxst> sazawal, keyboards don't fail!
[10:12] <darkxst> well not like that on random occasions
[10:12] <sazawal> I mean it stopped working, the mouse as well.
[10:13] <darkxst> right you have something dead-locked
[10:13] <darkxst> either kernel or X
[10:14] <darkxst> if sys-rq keys dont work during freeze, then its kernel
[10:14] <sazawal> darkxst, shouldn't it appear in one or more system log files? I saw one but there was no warning or anything at that time.
[10:14] <sazawal> what are sys-rq keys?
[10:15] <darkxst> sazawal, its pretty rare, but how would kernel log errors if its dead-locked?
[10:15] <darkxst> sazawal, google it!
[10:16] <darkxst> maybe start here: http://en.wikipedia.org/wiki/Magic_SysRq_key
[10:17] <darkxst> but essentially they are key combos that should talk directly to the kernel
[10:17] <darkxst> if they don't work kernel is broken
[10:18] <darkxst> and.....
[10:18]  * darkxst has to go now
[10:23] <sazawal> darkxst, yes right.
[13:27] <somethingrandom> hello, i upgraded and downgraded gnome 3.10 under ubuntu gnome 13.10 and don't have a wallpaper on the desktop, what can i do to fix it?
[13:54] <somethingrandom> how can i get the default packages installed?


[02:21] <arinel> is this a good channel to ask about the ARM architecture?
[02:21] <twb> If it's ubuntu-related, sure
[02:22] <twb> If not, maaaybe
[02:22] <arinel> I'll take my chances then. I was wondering if the carry_out from the shifter is fed into the ALU?
[02:23] <arinel> in ARM v1-v5 (or so)
[02:23] <twb> Way above my head
[02:23] <arinel> I can't find a diagram that would show details on this
[02:24] <twb> ##workingset might know of an appropriate channel, also recommend you lurk here
[02:25] <arinel> aha, thx!
[09:19] <doko> infinity, can you see what is wrong with exo?
[09:21] <infinity> doko: Well, the log just looks like bad quoting in variable assignment...
[09:22] <infinity> FOO=bar baz ./quux ; bash: bar: No such file or directory
[09:22] <infinity> Err, "baz: No such"... But you get the idea.
[09:22] <infinity> Should be FOO="bar baz" ./quux
[09:28] <doko> must have been blind ...
[09:32] <ogra_> WOAH !
[09:32] <ogra_> 0 upgraded, 1021 newly installed, 0 to remove and 0 not upgraded.
[09:32] <ogra_> Need to get 325 MB of archives.
[09:32] <ogra_> After this operation, 955 MB of additional disk space will be used.
[09:32] <ogra_> ....
[09:32] <ogra_> thats from apt-get install ubuntu-desktop in my hf chroot !
[09:33] <ogra_> doko, infinity, you guys rock !
[09:33] <ogra_> janimo, can i have an armhf ac100 kernel ? :)
[09:37] <infinity> ppisati: Any progress on ti-omap4 kernels for armhf?
[09:37] <infinity> ogra_: 1021 newly installed?  What was that the build-deps for? :)
[09:37] <ogra_> build deps ?
[09:38] <ogra_> thats just a plain apt-get install ubuntu-desktop
[09:38] <ogra_> no build deps :)
[09:38] <ogra_> on top of -core btw
[09:41] <ogra_> abh, abootimg hasnt been built yet
[09:41] <ogra_> *bah even
[09:42] <infinity> Ahh.
[09:42] <infinity> Can fix.
[09:42] <infinity> Anything else you need?
[09:43] <ogra_> can you trigger a build without uploading a build1 version ?
[09:43] <ogra_> else i'm happy to do that
[09:43] <infinity> There's nothing to trigger, I just had to score it up.
[09:43] <infinity> https://launchpad.net/ubuntu/+source/abootimg/0.6-1/+build/2960109
[09:43] <ogra_> oh, ok
[09:43] <sefokuma> hi, i have a ecafe slim netbook with a A8 freescale i.MX515
[09:44] <infinity> Can I have it?
[09:44] <sefokuma> i'm triying to change OS to Ubuntu from this way https://wiki.ubuntu.com/ARM/MX5/QuickStart
[09:44] <ogra_> infinity, stay with the qiockstart :)
[09:44] <sefokuma> but when i try to boot system dont boot from sd crad
[09:44] <sefokuma> *card
[09:45] <infinity> sefokuma: The uBoot on that card won't boot your system.
[09:45] <infinity> And the kernel may or may not.
[09:45] <ogra_> unlikely that the kernel works, but you should be able to boot with the exiting kernel and bootloader the device ships with
[09:45] <ogra_> you will need to do a bit of fiddling
[09:46] <sefokuma> infinity i select boot from external card with dip switch, i think that netbook must boot from it
[09:46] <sefokuma> if ubuntu armel for MX5 its prepared with uboot bootable... why dont work?
[09:46] <ogra_> sefokuma, the bootloader on the SD wont support that hardware
[09:46] <infinity> ^
[09:46] <sefokuma> ogra_ ok
[09:47] <ogra_> you need to find a u-boot binary that does and replace the one on the SD
[09:47] <ogra_> same goes for the kernel i guess
[09:47] <sefokuma> ogra_ aham ok
[09:47] <ogra_> these images are specifically built for the quickstart board
[09:47] <sefokuma> oh! ok now i understand
[09:47] <ogra_> userspace will work on your device
[09:48] <sefokuma> i will try install image on SD but overwrite uboot and ulinuximage with originals from guillemot
[09:49] <ogra_> right
[09:49] <ppisati> infinity: i'm starting it now
[09:50] <ppisati> janimo: off topic
[09:50] <infinity> ppisati: Awesome.
[09:50] <infinity> ppisati: I uploaded meta that assumes 1401 will build on armhf.  So, now I just need a kernel. ;)
[09:50] <ppisati> janimo: is mosh micolay (whatever is the name/pronunciation) today?
[09:52] <ppisati> janimo: Nicolai Mosh actually
[09:52] <infinity> ppisati: It should just be a question of "for i in `rgrep -l armel *`; do sed -i -e 's/armel/armel armhf/'; done && for i in find . -name \*armel\*; do (I can't be bothered to type a decent automated version of "cp foo-armel foo-armhf"); done
[09:52] <ppisati> infinity: somehow :)
[09:53] <infinity> ppisati: I fact, I can do that right now, if you like, and you can work on newer ABIs and shiny feature merges with 3.2? ;)
[09:54] <ppisati> infinity: i'm doing it manuallu right now
[09:54] <infinity> ppisati: I would have done it already, but I didn't want to step on your toes and make you grumpy if you were half done.
[09:54] <infinity> ppisati: Alright, cool.
[09:54] <infinity> ppisati: Just watch for both "rgrep armel *" and "find . -name \*armel\*"... The file copies was what bit apw when he did it. :P
[09:54] <infinity> (As in, he forgot)
[09:55] <apw> ppisati, very true, you need the d-i bits as well which are in files by arch name
[09:57] <infinity> ogra_: https://launchpad.net/ubuntu/+source/abootimg/0.6-1/+build/2960109/+files/abootimg_0.6-1_armhf.deb
[09:58] <ogra_> yay, thanks !
[09:58] <ogra_> now i just need a kernel
[09:58] <infinity> You have omap.  Break out a Beagle.
[09:58]  * ogra_ would change the existing one himself but i really really dont want to touch git
[09:58] <infinity> But I can do ac100 on armhf, if you like.
[09:59] <ogra_> well, there is a 3.0 branch ready for testing
[09:59] <infinity> I wasn't going to touch git, I was just going to mangle the packaging and let jani sort it.  Not because I dislike git (I quite like it), but because I suspect I can't merge to whatever branch he's using anyway.
[09:59] <ogra_> i would assume that janimo is already on it and we get armhf with the next upload
[09:59] <infinity> 3.0 would be shiny, but any working kernel is good for now.
[09:59] <infinity> Though it's unsupported anyway, blah blha.
[09:59] <infinity> So.
[09:59] <ogra_> hmm, so you wouldnt touch git either
[09:59] <infinity> Wait for ppisati, and go armhf on your panda? :)
[09:59] <ogra_> then i can do it as well
[10:00] <ogra_> i want to upgrade my ac100 to precise anyway
[10:00] <ogra_> so i can as well try the adventurous cross grade :)
[10:02] <infinity> It won't even remotely work.
[10:02] <infinity> So, like.  Don't try.
[10:02] <ogra_> pfft
[10:02] <infinity> libc-bin makes the world explode.
[10:02] <infinity> Well, I guess you can try.  But be prepared to wipe and reinstall right after. :P
[10:02] <infinity> ogra_: Anyhow.  I'm about to do the ac100 armhf thing.  Unless you really want to.
[10:03] <ogra_> if i unpack -core over my rootfs and then do a simple desktop install ....
[10:03] <ogra_> no. do it if you feel like
[10:04] <infinity> Doing.
[10:04] <infinity> Build needed 45:44:37, 8327584k disk space
[10:04] <infinity> ^-- qt4-x11 on a babbage.
[10:04] <ogra_> nice
[10:04] <infinity> We can't get rid of those things fast enough...
[10:04] <infinity> It takes, like, 13 hours on a Panda.
[10:05] <ogra_> yeah
[10:05] <ogra_> and 10min on a calxeda :)
[10:05] <dmart> Build needed 45:44:37, 8327584k disk space> hah, I remember that.  Pretty painful
[10:06] <apw> ogra_, but do you have one
[10:06] <dmart> 10min> nice
[10:06] <apw> and indeed does anyone
[10:06]  * apw would like one to build kernels on
[10:06] <ogra_> apw, sadly not yet
[10:06] <ogra_> in a year from now though ....
[10:06] <ogra_> *g*
[10:07] <apw> then build time ->infinity right now on one ;/
[10:07] <xranby> yesterday i started a armhf deboostrap... http://paste.ubuntu.com/761449/   for some reason it stalled and have now been stuck for 12h I: Configuring console-setup...
[10:07] <dmart> Sure 1 year + 10 mins ?
[10:07] <xranby> am i the only one hitting this?
[10:07] <infinity> xranby: I've not seen it.
[10:08] <ogra_> xranby, did you mount /proc and /sys ?
[10:08] <ogra_> i had it doing weird things to my host when it configured procps
[10:08] <infinity> The procps madness only happens on upgrade.
[10:08] <infinity> Not on debootstrap.
[10:08] <xranby> ogra_: no i simply crated the precise-hf foler and executed sudo debootstrap --verbose --arch armhf precise /media/dh0/chroot/precise-hf
[10:08] <infinity> xranby: Ctrl-C and try harder? :P
[10:09] <ogra_> oh, right mine was an upgrade
[10:09] <infinity> xranby: Although, I haven't tried a full debootstrap yet.  I'm only using --variant=buildd and --variant=minbase
[10:09] <infinity> xranby: (I'd recommend one of those)
[10:09] <xranby> ok i have now used ctrl-c
[10:09] <xranby> will chroot into it and see if it are usable
[10:09] <infinity> It won't be.
[10:10] <infinity> Just wipe it and use --variant=buildd.
[10:10] <xranby> heh ok
[10:33] <soren> Would Ubuntu work on the new Eee Transformer Prime (including graphics support)?
[10:39] <infinity> soren: Graphics are a big "maybe, but not sure yet".  The bigger issue right now will be locked bootloaders.
[10:39] <infinity> soren: So, uhh.  We'll see.
[10:39] <infinity> soren: But I suspect a number of people will be buying them to make it happen. :P
[10:41] <soren> infinity: What will I need to keep an eye on? Is there a tegra X.org driver where this is likely to land (for the graphics stuff, obviously)?
[10:42] <soren> infinity: ...or is this all kernel-side these days, so keeping an eye on LKML will suffice?
[10:43] <infinity> soren: Oh, we'll probably have non-accelerate video out of the gate.  It's binary drivers that will be iffy.
[10:43] <xranby> infinity:  --variant=buildd = works for me
[10:43] <xranby> thanks
[10:43] <infinity> xranby: Figured it would.
[10:43] <infinity> soren: But, until we get past the bootloader, I make no promises about... Well... Anything. ;)
[10:44] <soren> infinity: Oh, cool. Is there a generic graphics sort of thing for ARM as well (akin to VESA)?
[10:44] <infinity> There are a few framebuffer drivers.
[10:44] <infinity> For some large value of "few".
[10:49] <infinity> ogra_: Running a test-build of linux-ac100...
[10:49] <infinity> ogra_: If it's good, I'll upload before bed.
[10:54] <soren> infinity: Using one of these framebuffer drivers instead of proper accelerated drivers, will that drain the battery with normal use, or only if I try to do a lot of OpenGL stuff, for instance?
[10:55] <infinity> soren: Who knows.  The hardware's still a mystery to me until I have one.
[10:55] <soren> infinity: Alright. I just thought that was the sort of thing you could answer based on past experience. No worries.
[10:56] <infinity> soren: Well, on the Tegra2 netbook I use, I don't use binary drivers, and I get insanely good battery life.  Not sure how useful that data point is, but I imagine Tegra3 stuff will play out similarly.
[10:57] <soren> infinity: Wicked. Thanks.
[11:09] <ogra_> infinity, awesome !
[11:09]  * infinity taps foot.
[11:10] <infinity> My Panda needs some go-faster juice.
[11:51] <ppisati> infinity: i want to do another thing to P/omap4 before i upload, but if you want i can give you an omap4 armhf kernel now
[11:51] <ogra_> ppisati, we need it in the archive
[11:51] <ogra_> to build images
[12:19] <sefokuma> hi again
[12:19] <sefokuma> i have now a ubuntu-core running on my arm
[12:19] <sefokuma> but.. i dont know default password of ubuntu-core fs lol
[12:19] <sefokuma> any idea?
[12:19] <ogra_> there is none
[12:19] <sefokuma> and user¿
[12:19] <ogra_> nor is there a user or any networking config
[12:19] <ogra_> you need to configure that by hand
[12:20] <ogra_> -core is to build images on top of it, not for plain usage
[12:21] <sefokuma> yes i know
[12:21] <sefokuma> but i need first boot and login
[12:21] <sefokuma> to continue making system
[12:21] <ogra_> if you want to use it you need to make a bunch of adjustments before using it (create a user, install the networking bits, configure the system etc
[12:21] <ogra_> (before booting into it)
[12:21] <sefokuma> ok
[12:21] <sefokuma> i was following his steps
[12:22] <sefokuma> https://wiki.ubuntu.com/Core - Deploying Ubuntu Core
[12:22] <ogra_> yeah, thats not complete yet
[12:22] <sefokuma> oh ok
[12:22] <ogra_> we have a task to update the documentation for precise
[12:25] <sefokuma_> sorry coniecction time out
[12:41] <sefokuma> ok works
[12:42] <sefokuma> but im thinking on copy armel MX5 rootfs directly to SD cardroot filesystem
[13:08] <lool> hey folks, does someone know whether someone still cares for the "mobile" packageset?
[13:08] <ogra_> nobody does
[13:08] <ogra_> same for netbook
[13:09] <ogra_> though i'm not sure kubuntu-mobile didnt migrate to just be called mobile
[13:09] <ogra_> better ask them :)
[13:11] <infinity> I'm not sure what mobile is anymore.
[13:11] <infinity> It has xfce stuff in it..
[13:12] <doko> xfce should build now, unless the desktop team hates xfce even more ...
[13:12] <lool> is there a web ui to check packagesets contents and upload permissions?
[13:12] <lool> I figure launchpadlib might expose it
[13:12] <infinity> lool: No idea.  I'm pretty packageset ignorant.
[13:13] <infinity> lool: I know that creating/managing them is still an annying by-hand affair with some voodoo.
[13:17] <Daviey> lool: edit_acl.py
[13:17] <lool> Daviey: I'm not an archive admin
[13:17] <Daviey> lool: neither am i, but you can use it to check who has upload access where
[13:17] <Daviey> and packageset contents
[13:18] <lool> Daviey: where is it?
[13:19] <lool> oh wow, lp:ubuntu-archive-tools is public and I never used it
[13:19] <Daviey> $ edit_acl.py -P mobile -S precise query
[13:19] <lool> worked fine, thanks
[13:20] <Daviey> groovy
[13:20] <infinity> hildon and xfce and other bits.
[13:20] <infinity> That's so painfully obsolete.
[13:20] <ogra_> kill it !
[13:21] <lool> it seems we don't have a process for removing sources from packagesets
[13:21] <lool> I mean binaries from packagesets when we remove sources
[13:21] <ogra_> but you should be able to remove the whole packageset
[13:21] <ogra_> which in this case would be proper
[13:22] <infinity> lool: Eh?  Binaries aren't in packagesets.
[13:22] <infinity> lool: Package set define archive rights, it's source-level ganularity.
[13:22] <lool> ah right
[13:23] <lool> indeed these are used for source upload rights
[13:27] <lool> Ok; going to lie down a bit, I feel too sick
[13:56] <infinity> top - 13:55:57 up  7:18,  0 users,  load average: 12.08, 10.66, 9.29
[13:56] <infinity> And they said the Panda wasn't server hardware...
[14:02] <ogra_> ha ha
[14:03] <Daviey> infinity: did you do mdad raid via partitions on a single sdcard?
[14:03] <Daviey> redundancy++
[15:04] <S0NiC> hi
[15:05] <S0NiC> can anyone help me to change some values for this tutorial https://wiki.ubuntu.com/ARM/BuildEABIChroot? because http://ports.ubuntu.com/ubuntu-ports/dists/karmic/Release doesnt exist
[15:13] <ogra_> S0NiC, that howto i sreally really outdated
[15:14] <ogra_> S0NiC, if you feel like, please delete it ....
[15:15] <ogra_> (else we will delete it along woth the rootfs from scratch page etc)
[15:15] <ogra_> *with
[15:21] <S0NiC> ogra_ can you tell me another howto?
[15:22] <ogra_> not yet, we will rework all this with the switch to live-build
[15:22] <ogra_> currently the existing howtos refer to obsolete tools adn the new tools arent properly documented yet
[15:22] <S0NiC> hmm shit i have to crosscompile a programm for amr7
[15:23] <ogra_> as for building a chroot, install qemu-user-static, run qemu-debootstrap
[15:23] <S0NiC> mom
[15:23] <ogra_> that will create an arm chroot on an x86 machine
[15:23] <ogra_> at least on systems newer than lucid
[15:24] <ogra_> for lucid ask in #linaro for the lucid PPA of qemu
[15:24] <S0NiC> i am useing maverick
[15:24] <S0NiC> -.e
[15:24] <ogra_> might be ok ...
[15:24] <S0NiC> have i to specifiy a target-arch=
[15:25] <S0NiC> http://nopaste.info/cae429e70f.html
[15:25] <S0NiC> because i get this error?
[15:25] <ogra_> i think aemu-debootstrap defaults to armel ... if not, the same options debootstrap uses apply
[15:25] <ogra_> *qemu
[15:26] <ogra_> yeah, try --arch armel
[15:26] <ogra_> beyond that, all other debootstrap options apply
[15:28] <S0NiC> ogra_ i tried... http://nopaste.info/4493dfff57.html but doesnt work ;(
[15:29] <ogra_> well, it tells you what you are missing
[15:29] <ogra_> just follow the suggestion the "usage" line gives you
[15:30] <ogra_> suite is the release name i.e. oneiric, maverick etc ...
[15:30] <ogra_> target is the dir relative to the dir you run the command in
[15:33]  * ogra_ hugs infinity
[15:33] <ogra_> so tomorrow is the image day :)
[15:34] <ogra_> ndec, before end of the week we should have armhf images for panda, beagle and ac100 ...
[15:35] <ndec> ogra_: hey! cool.
[15:35] <ogra_> ndec, an armhf  recompiled gles driver for panda would rock soooo hard :)
[15:40] <S0NiC> sorry i was away
[15:43] <S0NiC> ogra_ now it works. thanks
[15:43] <ogra_> :)
[15:44] <ogra_> S0NiC, does your project have heavy dependencies ? else you could just use the cross compiler
[15:44] <S0NiC> ogra_ i have a question for my understanding: if its finished i change to the directory and can compile there my program?
[15:44] <S0NiC> what do you mean by heavy depndencies?
[15:44] <ogra_> you can run: sudo chroot <path to your target dir>
[15:45] <ogra_> that will switch your filesystem root to the chroot
[15:45] <ogra_> well, libraries etc
[15:45] <S0NiC> ogra_ iam new to this ;D thanks, i read this already
[15:45] <S0NiC> i try to compile a qtwebkit program
[15:45] <S0NiC> i think, thats heavy? ;)
[15:45] <ogra_> ah, k, then the chroot approach is probably better
[15:46] <S0NiC> i did some tries but the conclusion was not soooooooooo good ;)
[15:46] <ogra_> if it would have been a cmdline thing that only needs libc that would be lightweight enough to not use a chroot
[15:47] <S0NiC> e.g. with make i can compile my program on my target (pandaboard) and on my desktop machine. i tried it with g++ and it doesnt work (its a little c++ program)
[15:47] <S0NiC> i see thx
[15:48] <ndec> ogra_: are armel PPA building for armhf by default as well?
[15:48] <ogra_> ndec, not yet
[15:48] <ogra_> all that armhf stuff went way faster than expected (after massive probs in the bringup phase we're suddenly far ahead of the plan)
[15:49] <ogra_> ndec, but whats there should be enough to re-roll the binary blob in preparation
[15:49] <ogra_> i'll take care for PPAs soon
[15:50] <ogra_> (i hope we can just make them dual build for both arm arches and be done)
[15:50] <S0NiC> ogra_ wow that needs a lot of time... to build the chroot
[15:50] <ogra_> S0NiC, well, it downloads all packages from the archive
[15:50] <S0NiC> yes
[15:50] <ogra_> then it unpacks them without using dpkg ...
[15:51] <ogra_> and then it configures them by running the maintainer scripts ... in a qemu chroot each process is wrapped by a qemu call ...
[15:51] <ogra_> so while thats a lot faster than running an actual qemu machine, its indeed a lot slower than if you would build an x86 chroot
[15:51] <S0NiC> sounds deep in the system ;D
[15:52] <ogra_> it is deep in the system ... actually on kernel level (for the wrapping of the processes)
[15:53] <S0NiC> okay finished no i try to chroot
[15:53] <S0NiC> okay i chrooted an now i can try to compile my program ?
[15:54] <ogra_> you will want to install some bits to actually be able to compile
[15:54] <infinity> ogra_: "dual build for both arches"?
[15:54] <ogra_> a chroot like this is a virgin system
[15:54] <ogra_> infinity, armel and armhf
[15:54] <ogra_> in two runs
[15:54] <ogra_> would that be very complex ?
[15:54] <infinity> ogra_: Yeah, I didn't quite get what you were driving at, though.
[15:54] <S0NiC> orga tahn apt-get updaten and so on?
[15:54] <infinity> ogra_: PPAs get armel and armhf build records.  Just like every other arch.
[15:54] <ogra_> S0NiC, apt-get update; apt-get install build-essential
[15:55] <ogra_> that should get you the very basics
[15:55] <S0NiC> ah thanks
[15:55] <ogra_> infinity, well, the armel ones are currently limited (artificailly i think) to build armel only
[15:55] <infinity> ogra_: Not entirely true.
[15:55] <ogra_> S0NiC, and then indeed the -dev packages for the libs your app needs
[15:55] <infinity> ogra_: There's been plenty of armhf PPA activite.
[15:55] <ogra_> infinity, ah, cool, i didnt know
[15:56] <S0NiC> orga thanks
[15:56] <infinity> ogra_: It's only the "virtual" ones that have that strange limitation (and they're not actuall virtual, obviously)
[15:56] <infinity> ogra_: It's... Messy.
[15:56] <ogra_> infinity, well, we need to enable ndec's PPA for hf then so he can build us the shiny for panda :)
[15:57] <infinity> Which team/ppa is that again?
[15:57] <ogra_> that has a physical builder attached
[15:57] <ogra_> TI
[15:57] <S0NiC> ogra_ sorry for interrupt your conversation but i get an E: Unable to locate package build-essential
[15:57] <infinity> ogra_: That was remarkably unhelpful.
[15:57] <ogra_> ti-omap-dev is teh team iirc
[15:57] <infinity> 404.
[15:57] <infinity> I'm thinking not. ;)
[15:57] <ogra_> S0NiC, hmm, did you apt-get update ?
[15:58]  * infinity asks his panda.
[15:58] <S0NiC> yes
[15:58] <S0NiC> nopaste.info/e869c03242.html
[16:00] <infinity> ogra_: Oh, I can't tell from looking at it what kind of PPA it is.  But it might just magically get armhf build records on the next upload.  Dunno.
[16:02] <infinity> ogra_: Oh, I can't tell from looking at it what kind of PPA it is.  But it might just magically get armhf build records on the next upload.  Dunno.
[16:03] <ogra_> infinity, https://launchpad.net/~tiomap-dev/+archive/release
[16:03]  * ogra_ had a crash here
[16:03] <ogra_> chromium actung up usually leads to OOM at some point
[16:04] <ogra_> i'll better buy a bucket to stop the leaking
[16:04] <ogra_> *acting
[16:04] <infinity> Or open fewer tabs.
[16:04] <S0NiC> ogra_ i have to leave now, it possible to talk later to you=?
[16:04] <ogra_> luckily i dont use a laptop ... so it doesnt leak on my lap ...
[16:04] <ogra_> a netbook must leak to the net, right ?
[16:06] <S0NiC> cu guys and thanks for the help
[16:06] <ogra_> ciao
[16:50] <doko> infinity, can you apply the mmap patch to the ac100 image too?
[16:50] <ogra_> doko, i guess thats rather a task for janimo
[16:51] <ogra_> (he maintains the git tree)
[16:51] <doko> ok
[16:51] <infinity> doko: Yeah, I was just enabling armhf in the packaging, jani's working on 3.x source mangling.
[16:51] <ogra_> and he doesnt seem around today
[16:51] <ogra_> (probably a holiday in romania)
[16:51] <infinity> I believe someone said it was, yeah.
[16:52] <infinity> Anyhow..
[16:52] <infinity> ogra_: You have an ac100 kernel.
[16:52] <ogra_> done already ?
[16:52] <ogra_> geez, these pandas are so fast
[16:52] <infinity> ogra_: Can't make images with it yet, cause I can't publish it until the librarian is recovered. :P
[16:52] <infinity> ogra_: But you can download it from LP and install it locally and such.
[16:52] <ogra_> right, i plan to roll manual builds tomorrow
[16:53] <ogra_> and will then test the full image
[16:53] <infinity> Builds should Just Work.
[16:53] <infinity> Unless I screwed up. ;)
[16:53] <ogra_> sure
[16:53] <infinity> But what are the odds, right?
[16:53] <ogra_> else i'll fix them
[16:54] <ogra_> if they all work fine i wonder how to make them autobuild ... i fear we are getting to a point where a full set of images will take 24h :)
[16:54] <ogra_> i guess we should just do some selected areches for the start
[16:54] <ogra_> ac100 and omap4 or so
[16:55] <infinity> Well, it's on a different machine.
[16:55] <ogra_> sure sure
[16:55] <infinity> And post-processing doesn't take long at all.
[16:55] <Xase> How do I mount the preinstalled image again to replace the kernel, i cant seem to find it on the wiki.
[16:55] <ogra_> Xase, just re-plug the card after writing it
[16:55] <infinity> I bet all 4 flavours on armhf will build in about the same time as they do on armel over two buildds.
[16:55] <ogra_> right
[16:56] <Xase> Oh lol..
[16:56] <ogra_> thats 4h per build and flavour
[16:56] <Xase> Never thought about tbhat
[16:56] <Xase> it's not even dd'd yet
[16:56] <Xase> klol
[16:56] <Xase> brb
[16:56] <ogra_> so 8h for two flavours of the same subarch
[16:56] <infinity> ogra_: Yes, but arches build in parallel.
[16:56] <ogra_> 16 for 4 etc etc
[16:56] <infinity> ogra_: My point is that armhf should be about the same speed as armel, so adding it slows nothing down.
[16:56] <ogra_> it fuills the few time gaps we have öeft
[16:57] <ogra_> *left
[16:57] <infinity> ...?
[16:57] <infinity> What?
[16:57] <infinity> Parallel.
[16:57] <infinity> Same time.
[16:57] <aquadran> hi, i'm sure it's good place to ask here. i have issue with hdmi audio working on pandabaord with ubuntu 11.10. analog audio works. for hdmi i get 0,5 sec proper sound then it cut and nothing and only some low clicks. worked fine on 10.10
[16:57] <ogra_> you can only build two in paralell
[16:57] <infinity> What are you talking about? :)
[16:57] <ogra_> omap4 is always built on the same builder
[16:57] <infinity> armel+omap4 is.
[16:57] <ogra_> we build at least four flavours of omap4 images atm
[16:57] <infinity> armhf+omap4 is another machine.
[16:58] <ogra_> we have new live builders ?!?
[16:58] <infinity> Adding armhf slows nothing.
[16:58] <infinity> Yes...
[16:58] <aquadran> is there know issue for hdmi audio, i know for some it works fine
[16:58] <ogra_> OH !
[16:58] <infinity> Lamont and I have been debugging the armhf builder for the last two days. :P
[16:58]  * ogra_ humps infinity's leg
[16:58] <ogra_> i DIDNT KNOW !
[16:58] <ogra_> whoops
[16:59] <ogra_> i would say disregard the caps but they somehow feel appropriate :)
[17:00] <lilstevie> haha
[17:05] <GrueMaster> Erm, ogra_, infinity.  Kernel panic with the omap armhf netinstall kernel.
[17:06] <ogra_> :(
[17:06] <ogra_> when ? did you get to any console or directly on boot
[17:07] <infinity> GrueMaster: Output of the panic would be nice.
[17:07] <GrueMaster> Working on it now.
[17:07] <infinity> GrueMaster: To see if it's the kernel's fault, or a userspace fuckup.
[17:08] <ogra_> or the bootloader probably :)
[17:08] <ogra_> on omap you never know
[17:08] <infinity> My bet's on userspace (well, the initramfs), but I'm blindly guessing. ;)
[17:08] <infinity> I haven't actually done a by-hand install yet.
[17:08] <ogra_> thats why i asked about console :)
[17:09] <infinity> I guess with the ti-omap4 kernel rolling, I can replace armel on my Panda with armhf.
[17:09] <ogra_> yeah
[17:09] <ogra_> how do we go forward btw
[17:09] <ogra_> do we concentrate all efforts on armhf and leave el be el ?
[17:10] <ogra_> given the state of it i would actually be in favour of that
[17:10] <GrueMaster> Hmmm.  Not finding init.
[17:10] <ogra_> OTOH, if we find a hard blocker we might be screwed
[17:11] <GrueMaster> http://paste.ubuntu.com/761820/
[17:11] <infinity> ogra_: I don't see why they're mutually exclusive.  99% of the work I've done for armhf was duplicating armel.
[17:12] <Xase> will renaming uInitrd to uRamdisk be the same thing or is it different?
[17:12] <infinity> ogra_: In rare cases, you need an entry for each in a rules file or something (a package that cares about float-abi), but that's 5 seconds of your time.
[17:12] <ogra_> well, i wouldnt like to duplicate testing efforts etc
[17:12] <infinity> ogra_: For testing efforts, that's tougher, I agree.
[17:12] <Xase> Because the u-boot on the nook color looks for uRamdisk
[17:12] <GrueMaster> Xase: ???
[17:12] <Xase> not uInitrd
[17:12] <GrueMaster> Ah.  Should
[17:12] <infinity> ogra_: Testing effectively 8 arches instead of 4 is daunting.
[17:12] <rcn-ee> GrueMaster, i'm seeing that same with Debian Sid armhf with mainline.. ;)
[17:12] <ogra_> infinity, plus the work janimo does on live images :) thats one more
[17:12] <GrueMaster> rcn-ee: ouch.
[17:13] <ogra_> and likely really slow
[17:14] <infinity> GrueMaster: Okay, I'll replace armel with armhf on my Panda today and figure out WTF that's all about.
[17:14] <GrueMaster> ogra_: I thought the live images were manually built for the moment.
[17:14] <infinity> GrueMaster: It's almost certainly userspace.
[17:14] <ogra_> GrueMaster, yes, currently
[17:15] <ogra_> infinity, i'm not sure
[17:15] <GrueMaster> As to image testing, I am working hard to get a lot of it automated.  All the headless testing should be automated by EOY.  That leave me with desktop to manually muck about.
[17:15] <infinity> ogra_: I did say "almost".
[17:15] <ogra_> "Trying to unpack rootfs image as initramfs..."
[17:15] <Xase> Lessee if udev crashes like crazy this time.
[17:15] <ogra_> thats usually the line before "freeing init memory"
[17:15] <GrueMaster> Although I will be short non-omap4 platforms for automated installs.
[17:15] <ogra_> i dotn see it in tobins paste
[17:16] <Xase> Nope... it seems to be working :D
[17:16] <Xase> YAY
[17:16] <Xase> Mouse
[17:16] <Xase> ubuntu on Nook Color with a mouse :p
[17:16] <ogra_> GrueMaster, well, omap4 should soon be netinstallable on hf too
[17:16] <Xase> Nothing else so far =/
[17:16] <Xase> Probably something else broke...
[17:16] <GrueMaster> Or equally broken.  :P
[17:17] <infinity> GrueMaster: Does current omap netinstall work on armel?
[17:17] <infinity> GrueMaster: Cause the kernel's identical.
[17:17] <Xase> but if it got past the kernel loading, I should now be able to retrieve some sort of log from the SDCard right?
[17:17] <Xase> Oh wait
[17:17] <GrueMaster> I wonder if the switch to no initrd has anything to do with this breakage?
[17:17] <Xase> Its still doing its thing
[17:17] <ogra_> Trying to unpack rootfs image as initramfs...
[17:17] <infinity> GrueMaster: That should be the nail in the coffin.
[17:17] <ogra_> hmm
[17:17] <Xase> Guest Session login ;)
[17:17] <GrueMaster> Will try armel.
[17:17] <ogra_> no error though
[17:17] <Xase> Hmmm. Ghetto. The touchscreen is nil working
[17:17] <GrueMaster> Xase: You have an ubuntu image on nook color????  COOL!!!
[17:18] <GrueMaster> Well, aside from touch.
[17:18] <Xase> Yeah, it needs cypress truetouch...
[17:18] <Xase> Hmm
[17:18] <Xase> I'm using Dalingrin CM sources plus some patches from a  mer developer.
[17:18] <Xase> But mer dies while loading udev.
[17:19] <Xase> Figured it'd continue on the Ubuntu image
[17:19] <Xase> Because the suspect in the Mer case is bad dding
[17:19] <Xase> However now it's time to see if I can recompile with TrueTouch in menuconfig :D
[17:19] <ogra_> GrueMaster, "switch to no initrd" ? do you refer to my spec ? nothing has been done for that yet
[17:20] <ogra_> so no worries
[17:20] <Xase> make ARCH=arm menuconfig right?
[17:20] <ogra_> i guess apw will explicitly tell us if he (potentially) breaks the world
[17:20] <GrueMaster> Ok, something broken on the hf image.  I'm in netinstall on armel on omap.
[17:21] <ogra_> k
[17:21] <ogra_> lets wait for omap4
[17:21] <ogra_> and see if thats omap3 specific
[17:21] <Xase> GrueMaster: the ubuntu image doesn't seem to see battery... something having to do with Kernel?
[17:21] <ogra_> rcn-ee, you dont happen to know a workaround ?
[17:22] <apw> GrueMaster, odd indeed as the armel and armhf should basically be the same bits
[17:22] <GrueMaster> Xase: Possibly.  Not sure, since I haven't had time to muck about on my NC.
[17:22] <Xase> also I  need SGX530, can I chroot into the ARM image from my machine and apt-get install that way?
[17:22] <ogra_> apw, well, compiled differently
[17:22] <ogra_> (theoretically that shouldnt have any impact indeed .... theoretically ...)
[17:22] <apw> ogra_, well not really the only change is the float interfaces, and they kernel doesn't use float ever
[17:22] <rcn-ee> ogra_, nope, debugging it too right now..  what's weird, it worked fine with the "debian unstable armhf" (sep time frame) repo's.. so something changed between that timeframe and the current sid repo.
[17:23] <ogra_> yeah
[17:23] <apw> kernel normally panics if you do use float as the fpu isn't available
[17:23] <ogra_> well, it doesnt seem to be the kernel
[17:23] <ogra_> and by the looks of it even the initrd is fine
[17:24] <apw> ogra_, well that is something at least
[17:24] <ogra_> it just chokes on "no init found"
[17:24] <apw> hmmm ... maybe we have no upstart
[17:24] <Xase> Hrmmm...
[17:25] <rcn-ee> GrueMaster, if it helps, my old armhf image is still available: http://elinux.org/BeagleBoardDebian#armhf_Demo_Image
[17:25] <Xase> Truetouch is enabled in my kernel already...
[17:25] <Xase> but I'm getting no response from the screen.
[17:25] <ogra_> i dont think d-i uses upstart
[17:25] <ogra_> (unless it has been ported recently)
[17:26] <apw> oh alternative cds are they, i was assuming live
[17:26] <ogra_> netinstall
[17:26] <ogra_> easiest to test :)
[17:27] <apw> could be a heap of things, do you have the network drivers in your initrd for instance
[17:27] <ogra_> it loads all fine, see the paste of the dmesg output
[17:27] <GrueMaster> What (if any) config changes to the kernel are in the armhf rev?
[17:27] <ogra_> GrueMaster, none
[17:27] <GrueMaster> apw: See my pastebin.
[17:27] <ogra_> its just a rebuilds for armhf
[17:28] <ogra_> *rebuild
[17:28] <apw> its configuration is identicle between armel and armhf
[17:28] <infinity> The kernels should be almost literally identical.
[17:28] <GrueMaster> ok
[17:28] <infinity> I'm sure the issue is userspace.
[17:28] <ogra_> probably d-i's init uses floating point :P
[17:28] <infinity> No.
[17:28] <ogra_> yeah, i know
[17:29] <infinity> My bet's on initramfs-tools, and possibly the interpreter not landing in the initramfs.
[17:29] <ogra_> well, lets see how desktop images behave tomorrow, could as well be a d-i issue
[17:29] <infinity> I haven't actually built an initramfs on armhf yet.
[17:29] <ogra_> d-i doesnt use initramfs-tools, does it ?
[17:30] <GrueMaster> I think it does.
[17:30]  * ogra_ thought it uses cpio and whatever compressor directly
[17:31] <ogra_> as it doesnt use upstarts init
[17:31] <infinity> It might do.
[17:31] <ogra_> so i would rather like to wait until we have desktop images and compare with that
[17:32] <GrueMaster> We have core, right?  I could muck something together that way.
[17:32] <infinity> 	initramfs) \
[17:32] <infinity> 		  (cd ./tmp/omap_netboot/tree && find . | cpio --quiet -o -H newc) >  ./tmp/omap_netboot/initrd; \
[17:32] <infinity> 		gzip -v9f ./tmp/omap_netboot/initrd; \
[17:32] <ogra_> yeah
[17:32] <infinity> So, how it's populating that will be interesting.
[17:32] <ogra_> from udebs indeed
[17:33] <ogra_> intresting would also be what init it uses
[17:33] <infinity> My bet's still on the linker.
[17:33] <GrueMaster> Could it be busybox?  How do I differentiate between armel and armhf versions?
[17:33] <infinity> Let me tear apar this initrd.
[17:34] <ogra_> hmm. good question, the file command doesnt know the difference
[17:34] <ogra_> at least not with std output
[17:35] <infinity> adconrad@cthulhu:~/ung$ cat initrd | cpio -t | grep ld-linux
[17:35] <infinity> lib/ld-linux.so.3
[17:35] <infinity> And that's the problem.
[17:35] <infinity> I figured.
[17:36] <infinity> Now to see if that's the udeb's fault, or d-i's build process.
[17:36] <GrueMaster> diff initrd/bin/busybox busybox/usr/lib/initramfs-tools/bin/busybox
[17:36] <GrueMaster> Binary files initrd/bin/busybox and busybox/usr/lib/initramfs-tools/bin/busybox differ
[17:36] <infinity> GrueMaster: Of course they differ.
[17:36] <ogra_> indeed
[17:36] <infinity> GrueMaster: But the problem is above.
[17:36] <infinity> Linker in the wrong place.
[17:37] <GrueMaster> Where should it be?
[17:38] <infinity>  /lib/arm-linux-gnueabihf/ld-linux.so.3
[17:38] <GrueMaster> in the initrd?
[17:38] <GrueMaster> Seems odd.
[17:38] <infinity> Yes.
[17:38] <infinity> And it's my fault.
[17:39] <infinity> The udeb has it in the wrong location.
[17:39] <GrueMaster> Ok.
[17:39] <infinity> eglibc upload incoming. :/
[17:39]  * GrueMaster points blame.
[17:39] <GrueMaster> :P
[17:39] <GrueMaster> In the meantime, I'll reassemble this and tally forth.
[17:39] <ogra_> awesome, that means desktop images wont be affected :D
[17:40] <infinity> Can you manually mangle the initrd to move ld-2.13.so and ls-linux.so.3 to that path?
[17:40] <ogra_> why not
[17:40] <ogra_> you can cat cpio archives together, the one you append acts like an overlay
[17:40] <infinity> I meant to be asking GrueMaster to try that. :P
[17:41] <infinity> Not asking if it was possible.
[17:41] <GrueMaster> I have a couple of scripts for exploding and reassembling initrd.img
[17:41] <infinity> GrueMaster: If you can move those two files (and make sure the symlink still resolves), and try again?
[17:41] <ogra_> so just pull both files out, roll a cpio archive witgh them in the right place, and just cat it at the end of the existing cpio initrd ... then compress it again
[17:42] <GrueMaster> ogra_: Don't over-complicate things.
[17:42] <ogra_> GrueMaster, huh ?
[17:42] <GrueMaster> Easier for me to reroll with my existing scripts.
[17:42] <Xase> So... I have my touch driver enabled in kernel... however, I don't know how to get xorg to use it.
[17:42] <ogra_> thats way faster than unpacking everything and re-rolling the whole thing
[17:43] <GrueMaster> ogra_: On a Core2Quad running at 3ghz?  Speed is not the issue.
[17:43] <ogra_> k
[17:43] <GrueMaster> (actually takes longer for this discussion).
[17:44] <GrueMaster> infinity: Not seeing ld-2.13.so.
[17:44] <ogra_> grab it from a -core image ?
[17:44] <infinity> GrueMaster: It's in lib...
[17:44] <infinity> GrueMaster: I see it here.
[17:44] <infinity> Oh.
[17:44] <infinity> No.
[17:44] <infinity> I'm looking at the udeb.
[17:45] <ogra_> IT SHOUDL ALSO BE IN /LIB/TRIPLET/
[17:45] <ogra_> argh
[17:45] <ogra_> sorry
[17:45] <GrueMaster> No /lib/triplet directory.
[17:45] <infinity> Yeah, nevermind.  d-i canonicalises the paths, so no ld-2.13.so
[17:45] <ogra_> lib/arm-blah-foo-bar
[17:45] <infinity> ld-linux.so.3 is a real file, not a symlink.
[17:45] <infinity> So just move that.
[17:45] <Xase> Bah.
[17:45] <infinity> GrueMaster: You have to create the directory, it's not there. :P
[17:46] <infinity> GrueMaster: /lib/arm-linux-gnueabihf/ld-linux.so.3 is where that one file needs to live.
[17:46] <ogra_> GrueMaster, lib/arm-linux-gnueabihf/ that is :)
[17:46] <GrueMaster> I know that part.  I was just looking for the other file.
[17:46] <infinity> Yeah, the other file isn't on the initrd.
[17:47] <infinity> On a real system, ld-linux.so.3 is a symlink to ld-2.13.so, in the initrd, ld-linux.so.3 *is* ld-2.13.so.
[17:47] <GrueMaster> Had me worried.  find was returning nothing in the initrd.
[17:47] <GrueMaster> Thought this was horribly broken.
[17:48] <infinity> Also, glibc's udeb building is making my eyes cross.
[17:48] <GrueMaster> ogra_: time pack-initrd initrd.img initrd
[17:48] <GrueMaster> real    0m1.341s
[17:48] <GrueMaster> user    0m1.340s
[17:48] <GrueMaster> sys     0m0.076s
[17:48] <GrueMaster> Just fyi.
[17:49] <ogra_> yeah yeaqh
[17:50] <GrueMaster> :P
[17:50] <ogra_> :)
[17:51] <GrueMaster> Much better.
[17:51] <ogra_> boots through `
[17:51] <ogra_> ?`
[17:51] <GrueMaster> I'm in the installer.
[17:51] <ogra_> yay
[17:51] <infinity> \o/
[17:52]  * ogra_ goes afk for an hour or so
[17:53] <GrueMaster> grrrr.
[17:54] <GrueMaster> I'm being hit by bug 838200 (not an armhf issue).
[17:54] <ubot2> Launchpad bug 838200 in u-boot-linaro "No network support on Beagle XM" [High,Confirmed] https://launchpad.net/bugs/838200
[17:55] <GrueMaster> Ok, moving forward again.
[17:55] <Xase> o.o
[17:56] <GrueMaster> Yea.  seems to only affect me, as I have a rev B beagleXM.  Rest of the world is on rev C.
[18:06] <GrueMaster> Hrm.  "No installable kernel was found in the defined APT sources."  Might need to fix this in d-i.
[18:06]  * GrueMaster can preseed around it for now.
[18:06] <infinity> That sounds like an oops.
[18:07] <GrueMaster> I think d-i has hardcoded arches.
[18:10] <infinity> It does.
[18:10] <infinity> I suspect Colin just missed a spot or something.
[18:10]  * GrueMaster facepalms
[18:11] <infinity> Let me guess, it's using archive instead of ports?
[18:11] <GrueMaster> No, actually it is using my local mirror.
[18:12] <GrueMaster> But it is updated every 2h, so that shouldn't be the issue.
[18:15] <GrueMaster> I think I had to do the same thing for omap4.  I know I have the linux-omap4 meta listed there.
[18:17] <rcn-ee> sweet, the /lib/ld-linux.so -> /lib/arm-linux-gnueabi fixes debian sid armhf.. ;)
[18:17] <infinity> rcn-ee: Yeah.  Working on fixing eglibc now, will push to Debian too.
[18:18] <rcn-ee> thanks infinity! was about to just figure out where to submit the bug.. ;)
[18:30] <Xase> is there a sample xorg.conf or some way of telling xorg to use evtouch?
[18:36] <Xase> No one? :(
[18:37] <GrueMaster> Xase: You might be better asking that in #ubuntu-desktop.  I think all the xorg guys hang out there.
[18:38] <Xase>  ok
[18:47] <GrueMaster> infinity: Rebooting into armhf.  Fingers crossed.
[18:48] <infinity> GrueMaster: If it installed, I'm confident it'll boot. ;)
[18:48] <infinity> (eglibc uploaded and building)
[18:50] <GrueMaster> Grr.  I hate that it sits and spins waiting for a network.  On this broken system, means I have to manually unplug/plug in the cable for link detect to work.
[18:51] <GrueMaster> Still waiting on something in init to finish.
[18:53] <GrueMaster> It is pingable, but no getty so far.  Will need to enable console logging in the boot.scr to see what is borked.
[19:00] <GrueMaster> Do I need the updated eglibc or something?  It is hanging after "Starting configure network device".  System is pingable, but no login.
[19:00] <infinity> Nope.  Not eglibc's fault there.
[19:00] <GrueMaster> ssh appears to work, but no shell.
[19:00] <infinity> No shell sounds ominous.
[19:01] <GrueMaster> ssh logs in, lays out the welcome mat, then closes.
[19:02] <GrueMaster> Hrm.  Appears there is no /bin/bash
[19:02] <infinity> That seems rather unlikely...
[19:06] <GrueMaster> Nothing stands out in syslog.
[19:06] <GrueMaster> I have the rootfs drive on my PC now, so I can root arount.
[19:06] <GrueMaster> *around
[19:13] <Xase> Well that's pretty useless no one helpful with X seems to be in #ubuntu at the moment
[19:14] <GrueMaster> Xase: Some of them may be on vacation.
[19:14] <Xase> just my luck.
[19:14] <Xase> I'm unsure why the already there evdev rules don't catch the screen
[19:18] <GrueMaster> It could need to be updated with your device info, and an xorg.conf file could work around it.  I am just not sure how to do that.
[19:19] <Xase> Well if I even try to add anything to a new rules file or an xorg.conf ubuntu fails to boot.
[19:26] <Xase> meh.
[19:34] <GrueMaster> Hmmm.
[19:35] <GrueMaster> Do you get an Xorg.0.log when you change the config or rules?
[19:35] <Xase> Well I have to change it on the sdcard but I'll check, I have no other way to input besides the non working touch screen ;)
[19:36] <Xase> Where would it exactly be located?
[19:36] <GrueMaster> Yea, I know (I have a Nook Color as well).
[19:36] <GrueMaster> Should be in /var/log
[19:37] <Xase> Nope it's blank.
[19:37] <Xase> I'm sure I'm editing them wrong anyways.
[19:37] <GrueMaster> Odd.
[19:37] <Xase> It gives me a very specific error
[19:37] <GrueMaster> It should at least complain.  Anything in /var/log/sysog?
[19:39] <Xase> When I mess with xorg it gives this during boot.
[19:39] <Xase> (stk) :line disc installation timed out
[19:39] <Xase> ti_st_open: st_register failed -22
[19:39] <GrueMaster> That looks like a bluetooth error.
[19:40] <Xase> Ah.
[19:40] <Xase> So I'm seeing something normally hidden by x
[19:40] <Xase> Then boot isn't crashing
[19:40] <Xase> X just isn't loading
[19:40] <Xase> I'm definitely editing things wrong :D
[19:41] <Xase> Nothing in syslog about x11 or xorg
[19:41] <GrueMaster> I just got a link from one of our devs.  https://help.ubuntu.com/community/EloTouchScreen
[19:41] <Xase> o.o
[19:41] <GrueMaster> Although he also says evtouch is obsolete.
[19:42] <Xase> yeah apparently just evdev is used
[19:42] <Xase> So try evtouch?
[19:42] <GrueMaster> I can't really answer.  But the link has some good pointers at least.
[19:42] <Xase> well I have no clue how to do that. as I have no idea how to chroot into this sdcard since it's arm.
[19:44] <GrueMaster> What are you using for a base image?
[19:44] <Xase> Ubuntu Preinstalled Omap3
[19:46] <GrueMaster> I don't know if the gadget port can be enabled or not, but if you could figure that out, you might be able to get a serial console working.
[19:46] <Xase> Someone else I'm working with had issues...
[19:46] <GrueMaster> Also, the preinstalled image will be a bit more difficult, as it resizes the rootfs and launches oem-config.
[19:47] <Xase> Hmm
[19:48] <GrueMaster> but if you are able to boot this far, there is a lot that can go forward.  I don't know how to do it, but I'm sure you could use qemu to chroot into the image for adding packages and such.
[19:48] <janimo> infinity, thanks for the armhf/ac100 bits, I'll add them to the packaging git tree (also I'll check if zinc is still alive in the meantime for user kernels trees)
[19:50] <Xase> would... syslog show what devices were detected at startup GrueMaster ?
[19:51] <GrueMaster> I would think so.  You could also edit one of the init scripts (/etc/init.d) to execute some discovery commands that pipe to a log file.
[19:52] <Xase> alright
[19:52] <Xase> sort of lshal >> /var/log/lshal
[19:52] <Xase> ?
[19:52] <GrueMaster> Can you give me a link to your kernel?  I'll try to muck with it a bit here in my spare time this week.
[19:53] <GrueMaster> Yea, something like that.
[19:53] <Xase> Sure, just my uImage?
[19:53] <GrueMaster> Actually, I would need that and any modules.  Or are they all built-in?
[19:54] <GrueMaster> Better still, if you can give me a dd of your sd boot partition, that would give me everything I need.
[19:55] <Xase> All bubuilt in sure
[19:55] <GrueMaster> dd bs=4M if=/dev/mmcblk0p1 |gzip boot.img.gz
[19:56] <Xase> ok I was just about to ask.
[19:58] <Xase> o.o
[19:58] <Xase> gzip: boot.img.gz: No such file or directory
[19:59] <GrueMaster> Oops.  dd bs=4M if=/dev/mmcblk0p1 |gzip >boot.img.gz
[19:59] <GrueMaster> Missed the >
[19:59] <GrueMaster> my bad
[20:01] <GrueMaster> infinity: Any hints for what to look for as to why the beaglexm won't boot all the way in armhf?
[20:01] <infinity> GrueMaster: Not sure off the top of my head.
[20:01] <GrueMaster> I can chroot into the image (using a preinstalled-server image).
[20:01] <infinity> GrueMaster: But I'm going to fiddle on my panda in a bit.
[20:03] <GrueMaster> Fiddler on the Root.
[20:03]  * GrueMaster is in a weirdish mood today.
[20:06] <Xase> Hold on.
[20:06] <janimo> infinity, do you know what's with many FTBFS (today at least) not having build logs available?
[20:08] <Xase> GrueMaster:  data.excloo.com/~jase/boot.img.gz
[20:09] <GrueMaster> Cool, got it.
[20:10] <Xase> Fack I can't remember how to add a host to known_hosts
[20:10] <GrueMaster> On your desktop?  Which release?
[20:11] <Xase> I have debian to be honest =/
[20:11] <Xase> I'm trying to ssh into my ipod
[20:11] <Xase> ad it's omplaining about it... probably because I downgraded its firmware
[20:13] <GrueMaster> I usually just delete the offending key entry.
[20:14] <Xase> Yeah
[20:14] <Xase> That's what I just did.
[20:21] <Xase> man sftp is frustrating
[20:21] <infinity> janimo: The librarian is down.
[20:21] <infinity> janimo: Or, rather, was.  It's being recovered.
[20:21] <janimo> infinity, I had moments today when it worked so I was not sure if it is down or just being flakey atm
[20:22] <janimo> it being LP, I do not know of intricacies such as the 'librarian'
[20:22] <infinity> janimo: The librarian is the massive back-end filesystem where large things that aren't database bits are kept.
[20:22] <infinity> janimo: packages, logs, etc.


[05:35] <lotuspsychje> hey dax should we remove 17.04 from topic?
[05:36] <lotuspsychje> deadline was 11 or 13?
[05:36] <dax> /topic #ubuntu? it's Saturday
[05:37] <dax> and yeah, that's one of the things we do when things go EOL. some factoid shuffling too
[05:37] <lotuspsychje> oh its 13
[05:37] <lotuspsychje> got some time then :p
[05:37] <flocculant> if the new 17.10 releases ...
[05:37] <lotuspsychje> flocculant: if?
[05:37] <flocculant> s/if/assuming
[05:38] <flocculant> well it should today I believe
[05:38] <lotuspsychje> ah
[05:39] <lotuspsychje> tombusby: did you bug it yesterday?
[05:43] <lotuspsychje> http://news.softpedia.com/news/intel-s-microcode-update-for-meltdown-and-spectre-now-available-in-ubuntu-linux-519340.shtml
[05:45] <flocculant> not sure about bionic
[05:45] <lotuspsychje> !info intel-microcode
[05:45] <lotuspsychje> .1 already
[05:45] <lotuspsychje> all the rest got updates to .0
[05:46] <flocculant> I got .1
[05:46] <lotuspsychje> yeah me too
[05:46] <flocculant> but I'm on a -proposed kernel :p
[05:46] <lotuspsychje> bionic already neat :p
[05:49] <valorie> I got it and am just stock kubuntu + backports
[05:49] <lotuspsychje> nice valorie
[05:49] <valorie> no special kernel
[05:49] <lotuspsychje> valorie: hows kde's smoothness on your side?
[05:49] <valorie> excellent
[05:50] <lotuspsychje> valorie: is that on wayland also?
[05:50] <valorie> I have nvidia, so I've not tried wayland
[05:50] <lotuspsychje> kk
[05:50] <valorie> many of the plasma devels are running wayland fulltime though
[05:50] <lotuspsychje> neat
[05:51] <lotuspsychje> cause i got 2 out of 3 boxes that doesnt like wayland
[05:51] <lotuspsychje> and the 1 box that runs smooth is an nvidia lol
[05:51] <valorie> nice!
[05:51] <valorie> I just haven't had a chance to try it
[05:52] <lotuspsychje> yeah not so much testers yet, but we still in early stage, more might come
[05:53] <lotuspsychje> valorie: how much ram you have on the kubuntu?
[05:53] <valorie> I have lots, so it's not really a fair test
[05:53] <valorie> Sysinfo for 'valorie-GT60-2PC': Running inside KDE Plasma 5.11.5 on Ubuntu 17.10 (Artful Aardvark) powered by Linux 4.13.0-25-generic, CPU: Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz at 2800/3800 MHz, RAM: 6651/32119 MB, Storage: 286/967 GB, 286 procs, 2.42h up
[05:54] <lotuspsychje> i7 and 3gig should be plenty yeah
[05:54] <lotuspsychje> mechanical or ssd?
[05:54] <valorie> just rebooted a bit ago to get that microcode update
[05:54] <valorie> ssd
[05:54] <lotuspsychje> wich brand valorie
[05:55] <valorie> System76
[05:55] <valorie> it's not really a gt60
[05:55] <valorie> I moved the drives from an MSI and never changed that
[05:55] <lotuspsychje> Client: HexChat 2.12.4 • OS: Ubuntu "bionic" 18.04 • CPU: AMD C-60 APU with Radeon(tm) HD Graphics (1000MHz) • Memory: Physical: 3,5 GiB Total (2,5 GiB Free) Swap: 2,0 GiB Total (2,0 GiB Free) • Storage: 40,7 GB / 129,3 GB (88,6 GB Free) • VGA: Advanced Micro Devices, Inc. [AMD/ATI] Wrestler [Radeon HD 6290] @ Advanced Micro Devices, Inc. [AMD] Family 12h/14h Processor Function 5 •
[05:55] <lotuspsychje>  Uptime: 25m 13s
[05:56] <lotuspsychje> this box needs xorg on gnome
[05:56] <lotuspsychje> wayland not really smooth
[05:58] <valorie> you must be glad you have AMD though
[05:59] <lotuspsychje> howso?
[06:00] <valorie> less susceptable to meltdown, is it not?
[06:00] <valorie> dunno about spectr
[06:00] <valorie> e
[06:00] <lotuspsychje> ah yeah, tested a command, cpu wasnt vulnarable
[06:05]  * flocculant did that - and cpu is :p
[06:08] <valorie> what's the test command?
[06:08] <lotuspsychje> lemme check history
[06:08] <valorie> I assume mine are
[06:09] <lotuspsychje> this was 1 of my tests
[06:09] <lotuspsychje> grep CONFIG_PAGE_TABLE_ISOLATION /boot/config-`uname -r`
[06:09] <lotuspsychje> CONFIG_PAGE_TABLE_ISOLATION=y
[06:10] <lotuspsychje> dmesg -wH | grep 'Kernel/User page tables isolation
[06:10] <lotuspsychje> if nothing shows your good
[06:10] <dax> there's https://github.com/speed47/spectre-meltdown-checker also
[06:11] <flocculant> dax: that's what I used
[06:12] <valorie> i'm not installing some script from github
[06:12] <lotuspsychje> cat /proc/cpuinfo
[06:12] <dax> valorie: i read it before i did, yeah
[06:12] <lotuspsychje> should show stuff on bugs=
[06:20] <dax> i assume flocculant already saw, but lotuspsychje: 17.10.1's out
[06:21] <dax> (oh, nvm, you're in -release too)
[06:21] <lotuspsychje> yeah
[06:25] <lotuspsychje> !lenovo
[06:25] <lotuspsychje> !lenovobug
[06:25] <lotuspsychje> all is good to go dax :p
[06:27] <dax> !-lenovobug
[06:27] <dax> ;)
[06:28] <flocculant> dax: :)
[06:28]  * flocculant will deal with the Xubuntu notices later


[16:01] <cjwatson> good afternoon
[16:01] <calc> hi
[16:01]  * slangasek waves
[16:01] <TheMuso> Greetings.
[16:01] <cjwatson> #startmeeting
[16:01] <MootBot> Meeting started at 10:01. The chair is cjwatson.
[16:01] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[16:01] <evand> hi
[16:01] <ArneGoetje> hi
[16:02] <liw> hi
[16:02] <cjwatson> asac,bryce_,doko,james_w: ping
[16:02] <doko> pong
[16:02] <james_w> hi, sorry I'm late
[16:04] <bryce_> heya
[16:04] <cjwatson> [TOPIC] Outstanding actions
[16:04] <MootBot> New Topic:  Outstanding actions
[16:04] <cjwatson> doko: this was just yours: doko to write up release notes item about Java bytecode generation
[16:04] <asac> hi
[16:05] <doko> cjwatson: ouch, will do it today
[16:05] <cjwatson> ok
[16:05] <cjwatson> [ACTION] doko to write up release notes item about Java bytecode generation (carried over)
[16:05] <MootBot> ACTION received:  doko to write up release notes item about Java bytecode generation (carried over)
[16:05] <cjwatson> [TOPIC] Targeted bugs
[16:05] <MootBot> New Topic:  Targeted bugs
[16:06] <cjwatson> otherwise, the above is about the only thing I care about right now :-)
[16:06] <cjwatson> [LINK] https://bugs.launchpad.net/ubuntu/intrepid/+bugs
[16:06] <MootBot> LINK received:  https://bugs.launchpad.net/ubuntu/intrepid/+bugs
[16:06] <cjwatson> we got that number down by about 15 last night, in a collective (though uncoordinated) effort
[16:07] <calc> i believe i got my targeted bugs taken care of last night :)
[16:07] <cjwatson> at this point we have to start figuring out which items on the list we simply can't do in time and should be deferred, and which need more effort
[16:07] <cjwatson> calc: I saw, thank you
[16:08] <cjwatson> so let's do a quick pass down everything relevant to this team
[16:08] <cjwatson> the template approvals are in progress; ArneGoetje, do you have an update there?
[16:09] <ArneGoetje> I think all important ones have been approved and are either already imported or waiting for import.
[16:11]  * cjwatson looks at the needs-review queue
[16:11] <cjwatson> 1  → 50  of 7783 results
[16:11] <cjwatson> meep
[16:11] <ArneGoetje> .pot files are the templates
[16:11] <asac> ArneGoetje: template approval == what needs to be done before a package can be translated/exported in rosetta?
[16:11] <ArneGoetje> asac: yes
[16:11] <cjwatson> oh yes, I can filter to only pot files
[16:13] <ArneGoetje> there are about 50 pot files left which need approval. For some I would need some help to decide what to de with them, if anyone can shed some light on those, please contact me after the meeting.
[16:13] <cjwatson> the only remaining ones that look relevant are elisa, kscreensaver, gtk2-engines, gnutls26, epiphany-extensions, gnome-control-center, software-properties, and I'm not sure about ooo-build.pot (calc?)
[16:14] <liw> a system-cleaner with a .pot was uploaded today, is that relevant?
[16:14] <cjwatson> the approved import queue is getting through several thousand a day and *may* be finished by RC
[16:14] <calc> i haven't done a openoffice.org-l10n update in a while so haven't worried with it
[16:14] <cjwatson> calc: isn't that needed?
[16:14] <ArneGoetje> what we need to know for approval is the final .mo file name for each .pot file.
[16:15] <cjwatson> calc: or have none of the localised strings changed recently?
[16:15] <cjwatson> liw: I didn't see it in the needs-review queue (though I might have missed it)
[16:15] <calc> cjwatson: well aiui would require changing how the export/import is done now with new lp release and since we were very close to freeze i didn't want to break anything
[16:15] <slangasek> "may be finished by RC" - what needs to happen in jaunty to ensure that the importing is done on schedule?
[16:16] <cjwatson> calc: you mean due to the queue being very slow, or because things have been rearranged?
[16:16] <calc> cjwatson: well both really, but yes there was a recent change to not look in the debian dir anymore
[16:16] <cjwatson> slangasek: I've had a conversation with Jeroen Vermeulen about this, and we've agreed that jaunty translations can open as part of the general jaunty opening process
[16:16]  * slangasek nods
[16:17] <cjwatson> slangasek: the problem was essentially that neither he nor I realised that the other was waiting for us
[16:17] <cjwatson> so I take responsibility for that screw-up
[16:17] <cjwatson> we've explained things to each other and now I think know what to do
[16:17] <cjwatson> and I've added an item to NewReleaseCycleProcess
[16:18] <slangasek> ok, great :)
[16:18] <cjwatson> calc: I'm mostly worried about what the effect of this is - does this mean that there'll be unlocalised strings? presumably any changes made in Rosetta will have no effect?
[16:18] <cjwatson> and do we have any opportunity to do anything about this post-release, without having to reupload all of OOo?
[16:19] <asac> uploading templates and tranlsations manually works too afaik
[16:20] <slangasek> asac: except that OOo doesn't use gettext .mo files
[16:20] <slangasek> OTOH, I think they have pretty thorough upstream translations?
[16:20] <asac> slangasek: well. but whatever gets uploaded by the built should be uploadable manually
[16:20] <calc> cjwatson: probably so, see my comment in the email about 2.4.2 that would be a good time to do it if we can
[16:21] <slangasek> asac: "uploadable manually" == "reupload of openoffice.org-l10n" <shrug>
[16:21] <asac> ok. if its not integrated with rosetta in any way, then probably yes.
[16:22] <cjwatson> calc: mm, I'm cautious about relying on that
[16:22] <cjwatson> there may not be a good answer here, given the translation import problems
[16:23] <calc> ok
[16:23] <calc> if we do decide to go that route it would need to be thoroughly tested
[16:23] <cjwatson> we'll have to move on, conscious of time
[16:24] <cjwatson> bryce_: 278963 looks like it may be fixed by the new fglrx - have you had much feedback on that yet?
[16:24] <cjwatson> bryce_: also, should we wontfix 185311 for intrepid? I don't think we have much opportunity to do anything about it now
[16:25] <liw> cjwatson, I'll re-test the upgrade with current packages tonight
[16:25] <cjwatson> liw: thanks
[16:25] <cjwatson> I'm interested in fglrx feedback in general, since the new fglrx is something we didn't think we were going to be able to get and then came through at the 11th hour
[16:26] <bryce_> cjwatson: we were just talking about 278963 last night
[16:26] <asac> i can test fglrx if its supposed to work again
[16:27] <bryce_> we've laid out some plans to retest upgrades, now that we can.
[16:27] <asac> bryce_: anything particular i should test? or just "does it work", "can you play quake" :)
[16:27] <bryce_> for 185311 - yeah, won'tfix is probably going to be necessary
[16:27] <cjwatson> bryce_: 185311> please do that then
[16:27] <cjwatson> evand: did you make any progress on 270423?
[16:28] <bryce_> asac, right, just go through an upgrade and make sure the graphics driver works smoothly through the process
[16:28] <asac> bryce_: what do you mean "go through an upgrade"?
[16:28] <asac> bryce_: i am running latest intrepid. do i need to start from hardy?
[16:28] <evand> cjwatson: no, unfortunately I can no longer reproduce it.
[16:29] <cjwatson> I know I could at the time, I suppose I can give it another try
[16:29] <bryce_> bug 278963 is in regards to crashes during upgrade from hardy to intrepid; so the testing we need on that bug is upgrade testing.  If you're already upgraded, don't worry about it :-)
[16:29] <evand> I've tried the KDE image I had, plus the latest i386 and amd64 images.
[16:29] <evand> several times, at that.
[16:29] <evand> ok
[16:29] <asac> bryce_: ok ... dont count on me then ;)
[16:29] <bryce_> asac: of course any general testing on -fglrx is appreciated, but I think at this point we're pretty content with it
[16:29] <asac> yeah. will do that ;)
[16:29] <cjwatson> asac: what's the current consensus on 259157?
[16:30] <mvo> cjwatson: fglrx> I installed it today and it works ok on my r500 based card
[16:30] <asac> cjwatson: orinoco: still not a single voice about whether it works or not. for athXk its mixed feedback
[16:30] <cjwatson> james_w has posted some patches to 274076 which look like they should do the trick
[16:31] <cjwatson> asac: more worried about athXk at this point
[16:31] <ogra> asac, you need someone with orinoco card ?
[16:31] <asac> cjwatson: but i dont see that we could do anything in NM for athXk anyway
[16:31] <cjwatson> asac: should the NM task remain open?
[16:31] <asac> cjwatson: the 0.6.6 workaround was to use the wpasupplicant madwifi
[16:31]  * ogra has an old pcmcia silver orinoco
[16:31] <asac> module ... but we dont even have that anymore and its unknown how that behaves with current ath drivers
[16:31] <asac> cjwatson: imo it can be closed. only thing we could do on NM side would be hacks for orinoco
[16:32] <asac> but i dont have any feedback for that. i will open a separate bug for orinoco i guess
[16:32] <asac> and close the other for NM
[16:32] <cjwatson> thanks, just want to keep the list well-gardened
[16:33] <cjwatson> bryce_: another set of X bugs: 207881 (intel), 264462 (ati), 261977 (nv/server), 281308 (metapackages)
[16:34] <cjwatson> TheMuso: 204272 pulseaudio bug with duplicate list of death
[16:34] <asac> cjwatson: for intel wifi i am quite concerned about bug 193970 ... basically it means that rfkill switch is broken for all ipw3/4 intel chipsets
[16:34] <asac> which is a regression over hardy
[16:34] <bryce_> 207881 is said to be fixed now by the O.R.  I just need to tie up some loose ends and close it.
[16:34] <bryce_> 264462 we're waiting on upstream; something HW-specific, but -radeonhd works
[16:34] <bryce_> 261977 Timo is working on and has a solution to brute force it to work
[16:34] <bryce_> 281308 looks like user confusion; probably not-a-bug.  I'll review/close/update.
[16:35] <slangasek> asac: that doesn't seem like the right bug number for a regression vs. hardy?
[16:35] <asac> slangasek: well. maybe it was reopened
[16:35] <ogra> asac, works fine for me
[16:35] <asac> ogra: ipw3 or ipw4?
[16:36] <ogra> 4965
[16:36] <ogra> driver seems to be iwlagn
[16:36] <asac> ogra: strange. doesnt work here :) ... lets talk about that in -devel ;)
[16:36] <slangasek> asac: ok, I think whoever reopened that bug did so by mistake, and that they should have either opened a new bug, or followed up to bug #267875, which I just fixed :)
[16:36] <ogra> yeah
[16:36] <cjwatson> asac: Jerone Young pointed out a laptop-mode-tools bug the other day due to the iwl4965->iwlagn renaming; I wonder if that was related
[16:36] <cjwatson> that was bug 275162
[16:36] <asac> slangasek: thanks. thats the right one then.
[16:36] <cjwatson> (I hoovered up the patch)
[16:37] <slangasek> er, the bug state on 193970 is quite a mess :/
[16:38] <cjwatson> evand: 282037, 150872, 180309, 272318 are mostly yours
[16:38] <evand> hooray
[16:38]  * evand digs quickly
[16:38] <cjwatson> TheMuso: 274124 is the other pulseaudio problem - I saw some IRC discussion there earlier, what's the current state?
[16:39] <evand> 282037> grub-installer change is still outstanding for alternate installs, but the code for desktop installs is present and working in ubiquity
[16:40] <evand> 150872> Still need to rework the patch to suit your concerns.  Working on that today.
[16:40] <TheMuso> cjwatson: Ideally what we need to do is to get pulse to try and connect to the sound card again if it fails the first time, and a new client wishes to play audio, however I haven't located the code which does that yet. I'm still working out the pulse code to the point where I know what needs changing yet.
[16:40] <evand> 180309> Might have to defer.  Though I'll try to get this in quickly.
[16:41] <TheMuso> cjwatson: As shown in the bug, I have an idea on how we can reduce the possibility of the race condition occuring, but as slangasek points out, it doesn't get rid of it entirely.
[16:41] <evand> 272318> Haven't had a chance to take a hard look at it yet.  Will do today.
[16:41] <slangasek> TheMuso: do you think you can have a fix for that ready for upload today/tomorrow?
[16:42] <TheMuso> slangasek: What, to reduce the race, or to fix pulseaudio as discussed?
[16:42] <slangasek> (the fix to have it retry the sink when a new client connection comes in)
[16:42] <TheMuso> slangasek: No. I am still getting my head around the code. Help is appreciated.
[16:43] <cjwatson> I'm going to skip the rest of the list for time reasons (and to allow time for AOB), but I hope you get the idea: please, please look through https://bugs.launchpad.net/ubuntu/intrepid/+bugs for anything that's related to your areas of expertise (or even just things nobody else is picking up)
[16:43] <slangasek> my cycles are spoken for; if nobody else volunteers, I suggest that we upload the Xsession.d fix after all
[16:43] <cjwatson> I'd also appreciate it if people could set priorities for the undecided items on the list; I tried to do some of that last night but it needs more work
[16:43] <bryce_> will do
[16:43] <cjwatson> sorry, I mean importance
[16:43] <cjwatson> nothing should be targeted without having an importance set
[16:44] <cjwatson> ok, that's enough of that
[16:44] <cjwatson> [TOPIC] AOB
[16:44] <MootBot> New Topic:  AOB
[16:45] <bryce_> yay -fglrx
[16:46] <cjwatson> indeed
[16:47] <calc> well this is the last meeting some of us will be in, i will be moving to desktop next monday
[16:47] <cjwatson> oh, absolutely, I forgot about that
[16:47] <calc> iirc asac as well
[16:48] <asac> oh right.
[16:48] <asac> ;)
[16:48] <ArneGoetje> me too
[16:48] <cjwatson> and bryce
[16:48] <cjwatson> good luck to all of you!
[16:48] <asac> thanks all for the great time ;)
[16:48]  * calc hugs the old crew ;-)
[16:48] <evand> best of luck!
[16:48] <TheMuso> Good luck gus.
[16:48] <cjwatson> I'll be speaking with Scott to bring him up to date on things
[16:48] <TheMuso> guys
[16:48] <cjwatson> may be speaking with various of you as well of course
[16:49] <calc> we'll be reporting to this Keybuk guy for a while :)
[16:49] <calc> heh
[16:49] <james_w> good luck
[16:49] <cjwatson> and we shall be welcoming mvo next week, and Keybuk at some point after that
[16:49] <cjwatson> it's all so complicated
[16:49] <liw> you all have fun in the new team, and may your power buttons never break
[16:49] <leoquant> @schedule
[16:49]  * mvo waves
[16:49] <slangasek> and keep in touch, guys :)
[16:51] <cjwatson> ok, then I think we're done
[16:51] <cjwatson> #endmeeting
[16:51] <MootBot> Meeting finished at 10:51.
[16:51] <asac> thanks all
[16:51] <evand> thanks!
[16:51] <liw> thank you
[16:51] <james_w> thanks
[16:51] <ArneGoetje> thanks
[16:51] <calc> thanks
[16:51] <TheMuso>  Good, sleep time again. :)
[16:51] <TheMuso> Thanks.
[16:56]  * bryce_ waves
[18:00] <bdmurray> Hello
[18:00] <pedro_> hey hey
[18:00] <ara> hey!
[18:01] <heno> hello!
[18:01] <schwuk> hi
[18:01] <mrooney> hello!
[18:01] <intellectronica> hya
[18:02] <heno> cr3, sbeattie: QA meeting ping
[18:02] <heno> #startmeeting
[18:02] <MootBot> Meeting started at 12:02. The chair is heno.
[18:02] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[18:02] <sbeattie> hey
[18:02] <heno> welcome everyone!
[18:02]  * cgregan waves
[18:02] <cr3> heno: hello
[18:03] <heno> agenda as usual: https://wiki.ubuntu.com/QATeam/Meetings
[18:04] <heno> Tomorrow we will be in final freeze
[18:04] <heno> which covers RC and final
[18:04] <heno> here are the main milestone bugs https://bugs.edge.launchpad.net/ubuntu/intrepid/+bugs?field.milestone=1326
[18:05] <heno> (there is also a target of opportunity list at https://bugs.launchpad.net/ubuntu/intrepid/+bugs)
[18:05] <heno> are there any bugs people know of that should be added to those lists?
[18:05] <heno> this would be a good time to promote those
[18:06] <mrooney> heno: I wonder about https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/145360
[18:07]  * ara reads the list
[18:07] <davmor21> hello
[18:07] <mrooney> We seem to be getting a couple me-toos on compiz crashes on fresh installs or upgrades daily.
[18:08] <heno> mvo: ^ that's not milestoned. is that because it's been difficult to reproduce?
[18:09] <mvo> heno: yes
[18:09] <mvo> I looked at it myself and talked to upstream
[18:10] <heno> mvo: any hint that it's hw specific ?
[18:10] <mvo> I suspect its something that is either triggered during a session shutdown
[18:10] <heno> if so could we try to reproduce it in Montreal?
[18:11] <mvo> or that its something that is triggered during a upgrade, i.e. old compiz gets upraded to newer (abi incompatible) compiz
[18:11]  * cr3 addes #145360 to his list
[18:12] <mvo> the backtrace is really impossible to hit with the code
[18:12] <mrooney> I think mvo's comment #54 is pretty dead on, it happens after login but with no apparent effect, and it seems to happen just once or perhaps in a subsequent login and then doesn't happen again, until perhaps another update
[18:12] <mvo> so it must be a memory corruption
[18:12] <davmor21> mvo: i got to run an upgrade tomorrow on request so i can check for you then
[18:12] <mvo> of some sort, e.g. triggered by oddness with the plugin loading or unloading
[18:13] <mvo> davmor21: that would be excellent
[18:13] <mvo> davmor21: could you check /var/crash before the inital reboot?
[18:13] <heno> it seems that it's just a crash report (perhaps there was a crash at some point) but that compiz mostly works and no data is lost -> so it should not block release, but may be a target of opportunity if we can reproduce it
[18:14] <mvo> heno: my view exactly. its *old* too
[18:14] <davmor21> np's
[18:14] <heno> great, so we have davmor2 and cr3 offering to try reproducing
[18:14] <heno> any other issues people see?
[18:15] <mrooney> mvo: I think it may have been incorrectly duped with an old bug, I am not sure I would trust the original bug, I would look at recent dupes instead
[18:15] <mvo> mrooney: the trouble with this is that I can not get the new backtraces
[18:15] <schwuk> mvo: I've seen it as well (happened either yesterday or monday after my daily update)
[18:15] <ara> has anybody experienced this in intrepid? seahorse does not store WEP passwords by default anymore
[18:15] <mvo> mrooney: the retracer does not show them it seems
[18:15] <sbeattie> bug 275233 crops up a lot, but may be directly related to bug 274124 which Luke is at least working to reduce the race condition, if not eliminate it.
[18:16] <mvo> schwuk: does the timestamp of the crashfile (roughtly) match your logout time?
[18:18] <heno> sbeattie: I've asked TheMuso to join us
[18:18] <heno> ara: is there a bug # for that?
[18:18] <ara> heno: I haven't found any, that's why I am asking
[18:18] <schwuk> mvo: yes, and I got the notification after logging back in
[18:19] <heno> cr3: do we have hw with a VIA 8237 sound card?
[18:20] <heno> as referenced in the alsa-plugin bug
[18:20] <cr3> heno: checking...
[18:21] <cr3> heno: yep, looks like it. I'll add 274124 to my list
[18:21] <mvo> schwuk: could you please check what compiz bits got upgraded (and from what version to what version?). if you used update-manager then synaptic file/history will tell you
[18:21] <heno> hm, seems to affect intel cards too though
[18:21] <heno> cr3: thanks
[18:22] <heno> ok, let's get back to this if Luke joins us later
[18:23] <heno> any other bugs before we move on?
[18:24] <sbeattie> did the manual partitioning bug get fixed?
[18:24] <schwuk> mvo: AFAICT, none
[18:24] <davmor2> mvo: any joy with the screensaver bug?
[18:24] <heno> there will be a need to test some of these fixes as they land
[18:25] <mvo> davmor2: yes, we have a fix that can be applied that will workaround the problem
[18:25] <mvo> davmor2: not ideal, but will work
[18:25] <heno> in the past we have tracked them here https://wiki.ubuntu.com/Testing/ISO/FixValidation
[18:27] <cjwatson> sbeattie: should be
[18:27] <cjwatson> that was bug 280900
[18:27] <heno> pedro_: you did some coordination of that last time, can you update the page for intrepid?
[18:27] <davmor2> ara: mine stored wep fine it was wpa that fell out a couple of times but that seemed to clear up
[18:28] <pedro_> heno: yup, i'll do it
[18:28] <cjwatson> sbeattie: one tester said it boots up veeeeeeeeeery sloooooooooowly for him now but that can't be anything to do with ubiquity
[18:28] <heno> I guess we just populate it with the milestone lists to start with
[18:28] <ara> davmor2: ok, weird, then
[18:28] <pedro_> alright
[18:29] <davmor2> schwuk: you got intrepid on your lappy right?
[18:29] <heno> and anyone who can hang around in #ubuntu-testing and hep with validation testing requests - that would be great
[18:29] <davmor2> cjwatson: I'll try it tomorrow it's worked for me each time I've done a manually install
[18:30] <schwuk> davmor2: YEP
[18:30] <heno> [TOPIC] iso.qa.ubuntu.com updates
[18:30] <MootBot> New Topic:  iso.qa.ubuntu.com updates
[18:30] <sbeattie> davmor2: I hit it last night
[18:30] <heno> stgraber: around?
[18:30] <heno> I added a JeOS request today
[18:30] <davmor2> sbeattie: I'll try it now infact
[18:30] <sbeattie> heno: yay! I knew I forgot something that needed to be removed.
[18:31] <sbeattie> davmor2: I'm trying again as well.
[18:31] <davmor2> sbeattie: you on hw or vm?
[18:31] <sbeattie> vm, but the disk has existing partitions.
[18:31] <heno> looks like the Mythubuntu and mobile/mid items are blocked on writing cases
[18:32] <sbeattie> heno: related, can you give me an action item to drop jeos and add the netboot isos to the dl-iso script?
[18:33] <heno> [ACTION] sbeattie to to drop jeos and add the netboot isos to the dl-iso script
[18:33] <MootBot> ACTION received:  sbeattie to to drop jeos and add the netboot isos to the dl-iso script
[18:33] <sbeattie> tnx
[18:33] <davmor2> sbeattie: the size of the netboot isos and the amount it is upgraded kind makes it pointless
[18:34] <heno> persia: can you help with the outstanding mobile test cases?
[18:34] <sbeattie> davmor2: it's more for consistency and a reminder to look at them than for saving any bandwidth.
[18:34] <davmor2> sbeattie: fair play and I do :)
[18:34] <heno> ah, the log tells me he added the requests :)
[18:35] <cjwatson> also the "Install a minimal virtual machine" mode on the server CD which is a direct replacement for JeOS
[18:36] <heno> cjwatson: I don't see it on https://wiki.ubuntu.com/Testing/Cases/ServerInstall
[18:37] <heno> I'll ask njaba to write it up
[18:37] <cjwatson> 's a bit new
[18:37] <heno> nijaba rather ^
[18:38] <heno> ok, next
[18:38] <heno> [TOPIC] RC ISO testing
[18:38] <MootBot> New Topic:  RC ISO testing
[18:38] <heno> Obviously, please prime your rsync caches, refresh your supply of blank CDs, etc.
[18:39] <heno> we'll probably see testable CDs Monday-ish
[18:39] <heno> davmor2: will you be doing some smoke testing running up to that?
[18:40] <heno> can anyone else contribute to that too?
[18:40] <davmor2> yes I need to update the smoke test wiki page it's starting to look a mess which is why I haven't
[18:40] <heno> https://wiki.ubuntu.com/Testing/DailySmoke
[18:41] <heno> davmor2: feel free to just flush it and start from current testing
[18:41] <davmor2> That was my plan
[18:42] <davmor2> I'm going to refresh it tonight.
[18:42] <heno> schwuk has set up a mirror-of-last-resort for ISO images
[18:42] <bdmurray> ara: maybe bug 281711
[18:42] <heno> please contact him for access details
[18:43] <heno> this is to work around bw problems on cdimage in the testing crunch
[18:43] <heno> it's not for the wider public, just active pre-release testers
[18:44] <sbeattie> cjwatson: re bug 280900 is bug 282756 different? I hit the error 141 issue with daily iso build 20081015
[18:44] <heno> ok, next
[18:44] <ara> bdmurray: thanks, the discussion in here seems to be what I experience http://ubuntuforums.org/showthread.php?t=934575
[18:44] <heno> [TOPIC] upgrade testing
[18:44] <MootBot> New Topic:  upgrade testing
[18:45] <heno> we should make a start on this earlier
[18:45] <heno> including preparations
[18:45] <heno> I've prepared a hardy kvm image here http://files.omma.net/kvm/
[18:46] <heno> it's a base install + updates and a bunch of extra packages
[18:46] <davmor2> schwuk: are you having issues with wep or wpa key being stored?
[18:46] <heno> feel free to download and extend that
[18:47] <heno> schwuk: did you get to setting up some upgrade KVM images?
[18:47] <heno> I intended to make 64-bit and kubuntu images too
[18:48] <heno> (but didn't get to it yet)
[18:48] <schwuk> heno: I have VMWare images for ubuntu hardy i386 and amd64. Base install on both. I'm putting together base kvm images for kubuntu and xubuntu (both archs).
[18:48] <sbeattie> heno: I've done a little upgrade testing; mvo is working on bug 282830 where etckeeper prevents update-manager from installing anything.
[18:48] <schwuk> I also have images for ubuntu-server (amd64)
[18:49] <cr3> heno and schwuk: I used to maintain isv-image.ubuntu.com/vmware for hosting such images. it might be worth reviving the site to include kvm images too
[18:49] <heno> schwuk, sbeattie: ok great
[18:49] <sbeattie> I have a virtualbox i386 image that's base + lots of other packages mostly from main (~2500 in total) that I could make available.
[18:50] <mvo> sbeattie: hm, how long would it take for me to download that (i.e. what uplink do you have?)
[18:50] <sbeattie> mvo: a while; 640kb up.
[18:51] <heno> sbeattie: can you prepare a file list for him?
[18:52] <heno> dpkg -l | grep '^ii' | awk '{print $2}' > packages-list.txt
[18:52] <heno> or so
[18:52] <mvo> heno: I have the dpkg -l output in the bug I think
[18:52] <heno> mvo: can you recreate his install with that?
[18:53] <mvo> I should be able to, yes
[18:53] <heno> for i in `cat packages-list.txt`; do apt-get install $i; done;
[18:53] <heno> :)
[18:53] <heno> (yes I was playing with this earlier)
[18:54] <heno> let's wrap up, we have an LP-QA meeting just after this
[18:54] <sbeattie> heno: yes, dpkg -l output is in http://launchpadlibrarian.net/18507713/dpkg.list
[18:54] <mvo> heno: import apt; cache=apt.Cache(); for pkg in open("packages-list.txt"): cache[pkg].markInstall(); cache.commit();" <- will be faster :)
[18:54] <heno> any other business?
[18:54]  * mvo puts off his show-off hat
[18:54] <heno> mvo: yes, silly me ;)
[18:54] <bdmurray> mvo: sweet
[18:54] <mrooney> This may be unrelated but the OO 3.0 request bug is getting rather loud
[18:55] <mrooney> bug 267376
[18:55] <pedro_> eek
[18:55] <sbeattie> heno: I've been playing a bit with edos-debcheck looking for uninstallable packages, found a few, particularly around kde.
[18:55] <mrooney> Is there a definitive answer to give in some sort of appeasing way?
[18:55] <heno> there was talk of a universe package or so for that (?)
[18:55] <sbeattie> all outside of main
[18:56] <bdmurray> mrooney: I think calc has sent some mails to u-devel or u-devel-discuss about it
[18:57] <mrooney> bdmurray: do you know if it is a definitive no way on 3.0 in Intrepid?
[18:57] <heno> sbeattie: interesting - have you passed that on to motu-release?
[18:57] <sbeattie> heno: in progress, but yes. Looking to automate it so we can detect when new ones occur.
[18:58] <bdmurray> mrooney: I think it would be either in a ppa or in universe, but would check the ml to confirm.
[18:58] <heno> mrooney: as the default option, yes - no way
[18:58] <heno> we have freezes for good reasons even if it's not always obvious how these things work
[18:58] <heno> ok, we're done!
[18:58] <heno> #endmeeting
[18:58] <MootBot> Meeting finished at 12:58.
[18:59] <ara> bye!
[18:59] <heno> (sorry to be hard line, but I don't want to block the next meeting start)
[18:59] <davmor2> bye
[18:59] <heno> intellectronica: you're up :)
[19:00] <intellectronica> oright guys, get your skypes going i'll connect you
[19:00] <mrooney> heno: no problem, I agree! I just wish there was a way to express the values of freezes to those users
[19:02] <heno> fwiw, we are talking about https://wiki.ubuntu.com/QATeam/LaunchpadBugsUbuntuQAMeeting
[20:20] <cjwatson> sbeattie: sorry, I wasn't very clear (or was confused), I did just upload the fix earlier today but it wouldn't have been on today's images
[20:20] <cjwatson> sbeattie: I haven't yet analysed 282756 to see if it's different


[02:01] <pleia2> in Montreal, not sure if that counts as a fantastic voyage, but I am here for Pycon, so that's cool :)
[02:43] <nhaines> pleia2: well python is pretty fantastic.  :)
[02:44] <nhaines> I just shared the OCLUG installfest flyers, talking points information sheet, and some other day-of forms on the mailing list.
[02:45] <`Fibz> if it weren't for my horse i never would have spent that year in college
[02:46] <`Fibz> -Luise Black
[02:47] <`Fibz> i just had one of those moments. some one was switching trough radio stations in their car and tuned a station that was advertising Ruby on Rails. then changed the station.   it's driving me nuts. why was the radio advertising Ruby on Rails?
[02:57] <nhaines> Ruby on Rails?  I know.  Should be advertising Django, right?
[03:05] <`Fibz> totally
[04:05] <nhaines> Huh, I thought my laptop was really hammering the internal drive.  Then I realized I was just hearing the carbonation excaping from the soda in my cup.
[04:35]  * ianorlin doesn't like carbonated drinks
[04:45] <nhaines> I love carbonated drinks.
[04:45] <nhaines> I'm going to have to look into buying a Sodastream purely to make seltzer water.
[04:45] <nhaines> That would cut my soda consumption to basically nothing.
[04:46] <nhaines> No projection on beer consumption though.  :P
[04:52]  * ianorlin wonders if anyone would bring a powerpc mac to the installfest
[04:59] <nhaines> They're getting Gentoo.
[05:01] <`Fibz> i just tossed one
[05:01] <nhaines> apt-get install gentoo
[05:11] <rww> just got back from san francisco :3
[05:11] <nhaines> rww: were there Ubuntu plushies?
[05:11] <rww> no. but there was a sign! but sudormrf found me without it!
[05:11] <rww> i guess i was the one looking like a nerd, idk
[05:12] <rww> 5 people at Ubuntu Hour (me, mpaoli, sudormrf, eps, jyo), 6 people at Debian Dinner (me, mpaoli, eps, Noodles, Ian Z, and someone whose name I forgot)
[05:13] <nhaines> yay
[05:13] <nhaines> That sounds like a decent turnout.
[05:14] <rww> Yep :)
[13:39] <pleia2> rww: nice turnout :)
[13:39] <pleia2> nhaines: <3 my soda stream, I mostly just make fizzy water


[02:42] <mup> Issue snapcraft#4190 closed: Improve error message when attempting to refreseh a local snap <Enhancement> <Created by sed-i> <Closed by lengau> <https://github.com/snapcore/snapcraft/issues/4190>


[18:57] <siganderson> hey, has anybody any problem with evolution saving passwords? I can't do it, as when mail authentication request window appears, click on cancel or accept doesn't have effect. In that  moment to go back to the desktop I need to kill gnome-keyring-d!


[09:21] <rmg51> Morning
[09:29] <JonathanD> Hello rmg51
[09:34] <rmg51> o/
[12:07] <teddy-dbear> Morning peoples and whatever else is around
[13:10] <WorkingTurkey> morning people? that's not me
[13:33] <teddy-dbear> your a whatever else ;-)
[22:30] <lazyPower> If you're not currently familiar with Squeezebox - i cannot recommend it enough https://www.youtube.com/watch?v=SFaREwbtKyY
[22:30] <lazyPower> DIY setup with mostly stuff on hand. Server software was free


[20:31] <balloons> ping veebers
[20:31] <veebers> Hey balloons o/ how's things
[20:32] <balloons> veebers, been far too long :-) So, how's AP 1.6? I know you have some porting stuff up and other things. I'm just curious on progress and how I might help communicate if needed
[20:32] <balloons> I
[20:32] <balloons> I've not personally looked into it or tried it yet, heh :p
[20:32] <balloons> also, good morning!
[20:34] <veebers> balloons: heh morning :-) It's currently sitting in a couple of MPs waiting for further review. I've gone ahead and ported UUITK and Unity8 tests and helpers to work with it
[20:34] <veebers> I've been talking with the a-squad guys to get some work done on the sanity suite and get some feedback on it
[20:35] <veebers> balloons: and I should be very shortly asking you for similar help (getting some apps ported to it and some dev feedback)
[20:36] <balloons> right-o. So it's feature complete if you will. nothing should change moving forward?
[20:44] <veebers> balloons: yeah feature complete and works, nothing will change going forward (unless a dev finds some really odd edge case issue, which I doubt would change many things)
[21:15] <balloons> veebers, ok.. I'll add a card for the next sprint (starting next week) to look into this
[21:16] <veebers> balloons: awesome