[02:28] <mup> PR core#110 opened: Disable dynamic motd <Created by vorlonofportland> <https://github.com/snapcore/core/pull/110>
[06:12] <mborzecki> morning
[06:35] <mborzecki> zyga: https://www.redhat.com/sysadmin/fedora-31-control-group-v2 in case you missed it
[08:00] <pstolowski> mornings
[08:00] <mborzecki> pstolowski: hey
[08:01] <mborzecki> pstolowski: a trivial PR to start the day: https://github.com/snapcore/snapd/pull/7729
[08:01] <mup> PR #7729: cmd: fix a pair of typos <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/7729>
[08:04] <pstolowski> mborzecki: hey, sure
[08:06] <mup> PR snapd#7729 closed: cmd: fix a pair of typos <Simple 😃> <Created by zyga> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/7729>
[09:09] <mborzecki> got an errand to run, back in 2h or so
[10:58] <Chipaca> brb, need to take my laptop apart (???)
[11:09] <mborzecki> re
[12:52] <zyga> Good morning
[12:53] <mborzecki> zyga: hey
[12:54] <mborzecki> imo we should provide a `snap debug volume-layout` command for dumping what snapd thinks is the layout described by the gadget.yaml file
[12:55] <Chipaca> mborzecki: nice
[12:55] <Chipaca> zyga: it's not even 5am there?!?
[12:59] <zyga> Chipaca: it's 4:59 now
[12:59] <zyga> Chipaca: I woke up at 3:33 (no kidding!)
[12:59] <zyga> Chipaca: but hey, guess what
[13:00] <zyga> *no roommate* :)
[13:00] <ogra>  zyga dude ... melatonin ...
[13:01] <zyga> ogra: it's better, yesterday I slept for 0 hours
[13:01] <zyga> ogra: I just could not ... it's the first time this happened to me
[13:01] <zyga> is the standup in an hour?
[13:02] <zyga> yep, ok
[13:22] <mborzecki> degville: hi, i've created a docs page about the gadget assets update process, can you take a look? https://forum.snapcraft.io/t/gadget-assets-update/14117
[13:23] <degville> mborzecki: yes, of course - thanks for the heads-up!
[13:24] <mborzecki> degville: thanks!
[14:27]  * zyga goes for breakfast
[14:46] <mup> PR snapd#7693 closed: interfaces/gpg-keys: Enable access to system gpg_agent socket <Created by Kedstar99> <Closed by Kedstar99> <https://github.com/snapcore/snapd/pull/7693>
[14:57] <mup> PR snapcraft#2797 opened: meson plugin: add support for core20 <Created by sd-hd> <https://github.com/snapcore/snapcraft/pull/2797>
[15:07]  * cachio lunch
[17:05] <mup> PR snapd#7704 closed: snap: extract printInstallHint in cmd_download.go <Simple 😃> <Created by mvo5> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/7704>
[17:14] <pstolowski> zyga: the snap run --explain output looks super nice! (i looked at your snippet pasted earlier)
[17:38] <om26er> Hi! Does Travis CI support building snaps using multipass ?
[17:52] <mup> PR snapcraft#2796 closed: meta: ensure Snap's `assumes` is initialized as a set <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2796>
[18:13] <mup> PR snapcraft#2795 closed: manifest: track and annotate `primed-stage-packages` <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2795>
[18:24] <om26er> hey cjwatson, launchpad is having a hard time uploading my snap to store https://launchpad.net/~build.snapcraft.io/+snap/c7f9e9a2d76707f5da7a8175b964b834/+build/731604
[18:24] <om26er> its built but lp is trying to uploaded for quite a few minutes
[18:26] <roadmr> sergiusens: hey there! snapcraft is taking about 7 seconds to run (even something simple like snapcraft register), and this appears to have happened/regressed recently. Does this ring a bell?
[18:27] <sergiusens> roadmr: snapcraft from stable has not changed in the past two months
[18:27] <sergiusens> roadmr: but I did see it run slow yesterday
[18:27] <roadmr> (it's causing our store test run to fail because the "registers names too fast" behavior is not triggered with snapcraft taking this long for each name heheh
[18:28] <sergiusens> roadmr: oh, our integration tests were running just fine
[18:28] <roadmr> interesting.. do you run the store tests too?
[18:29] <roadmr> -vvv -b -s tests/integration/store -t .
[18:30] <sergiusens> roadmr: here's one from yesterday https://travis-ci.org/snapcore/snapcraft/jobs/610814226
[18:30] <roadmr> yay!
[18:30] <roadmr> right, test_registrations_in_a_row_fail_if_too_fast is what's failing for us but it passed here
[18:31] <roadmr> "snapcraft list" (does nothing, just prints an error) takes a full 4 seconds to run
[18:39] <om26er> all 4 jobs are "uploading build" https://launchpad.net/~build.snapcraft.io/+snap/c7f9e9a2d76707f5da7a8175b964b834 and I don't have admin permissions to force rebuild
[18:40] <om26er> :-(
[19:04]  * cachio afk
[19:53] <roadmr> hey folks - inside an lxc container snaps mounted with snapfuse are significantly slower than those mounted using squashfuse; but the only way I found to make a snap be mounted with squashfuse is by snap downloading and installing it --dangerously, which is icky. Is there a way to make them use squashfuse always?
[21:00] <zyga> roadmr: I think that was recently fixed
[21:01] <zyga> roadmr: ask mvo about it please
[21:13]  * cachio eod
[21:28] <roadmr> zyga: will do! we sort of fixed it by installing squashfuse *before* installing any snaps in the container, then they use squashfuse which is 3x faster for some reason
[21:28] <zyga> roadmr: there are two builds of squashfuse
[21:28] <zyga> roadmr: one is fast other is slow
[21:28] <zyga> roadmr: it's a build time option
[21:28] <zyga> roadmr: we flipped the switch on one of the builds
[21:29] <roadmr> zyga: ahh I see :)
[22:49] <mup> PR snapd#7730 opened: Fix typo in spread suite summary <Created by sparkiegeek> <https://github.com/snapcore/snapd/pull/7730>


[07:57] <dpm> good morning all
[09:28] <udienz> hello, last minute ago my friends tells me about Launchpad translations lisence
[09:28] <udienz> he make ubuntu derivative
[09:29] <udienz> and he tells me that his distro can not use translations that provided by rosetta
[09:29] <udienz> is that true?
[09:29] <danilos> udienz, that'd be very surprising because translations done in Launchpad are BSD-licensed
[09:29] <danilos> udienz, I think the only way for him not to be able to use them is to make his distro public domain
[09:30] <danilos> udienz, but I am pretty sure he can't do that because of other software :)
[09:31] <udienz> danilos: thanks but sorry i'm not understand about BSD -lisenced :(
[09:32] <udienz> hm.. he angry about it, well i suggest him to send an emails to ubuntu-stranslator or launchpad
[09:33] <udienz> and the distro have same license with Ubuntu and Debian
[09:34] <danilos> udienz, BSD license basically means "you can do whatever you want with it"
[09:35] <udienz> ah.. thats the point. so if i make new distro from ubuntu based. can i use translations from LP?
[09:36] <danilos> udienz, yes, just like you would use upstream translations
[09:36] <dpm> udienz, just to complement what danilos is saying: https://help.launchpad.net/Translations/LicensingFAQ - btw, there is no reason for your friend to be angry
[09:37] <danilos> udienz, basically, in layman terms, BSD-license is less restricting than *most* upstream licenses (like LGPL or GPL), so the combination of GPL and BSD gives you GPL as a result, and you can use LP translations for a GPL project under GPL license
[09:38] <udienz> dpm, danilos: thanks! i will tell my friends about that
[09:42] <danilos> udienz, have them also read https://help.launchpad.net/Translations/LicensingFAQ as dpm suggested
[09:45] <udienz> dalios: ok
[09:45] <udienz> oh.. my friends reply my emails
[09:45] <udienz> wait..
[09:51] <udienz> he said [in indonesian] they want to contibute (translations) to upstream. but translations from launchpad can't sending to upstream
[09:51] <udienz> because upstream *usually* not compatible with BSD. just like GNOME, translations from LP cannot send to upstream, and translations from GNOME can importing to LP
[09:51] <udienz> sorry for stupid questions :)
[09:51] <udienz> i'm don't know about license
[09:52] <udienz> what i know is contributing to Ubuntu :)
[09:53] <danilos> udienz, that's not true, we have chosen BSD license exactly so it can go back into *any* project
[09:59] <udienz> danilos: agreed, and i'm very very agree with this words (from LP TOS)
[09:59] <udienz> We require this so that other projects can use these translations as sources for their own translations, without suffering licensing incompatibilities
[10:06] <udienz> brb, Asia/Oceania membership board now.. my membership is expired last month :D
[10:24] <gtriderxc> should I translate this:
[10:24] <gtriderxc> https://translations.launchpad.net/checkbox/trunk/+pots/checkbox/pl/+translate?field.alternative_language-empty-marker=1&show=untranslated&start=0
[10:24] <gtriderxc> or that:
[10:24] <gtriderxc> https://translations.launchpad.net/ubuntu/natty/+source/checkbox/+pots/checkbox/pl/35/+translate
[10:24] <gtriderxc> ??
[10:27] <gtriderxc> there is a slite difference in search results
[10:28] <andrejz> the 1st version is the upstream. So if you translate that all distributions (which will be using checkbox offcourse) will be able to use your translations
[10:28] <gtriderxc> what's more interesting natty has more strings to translate than the origin package
[10:28] <andrejz> it's possible natty has also some ubuntu specific strings
[10:29] <gtriderxc> ok but  I'll check something again and then tell You one more interesting thing about it
[12:11] <gtriderxc> "the 1st version is the upstream. So if you translate that all distributions (which will be using checkbox offcourse) will be able to use your translations"
[12:11] <gtriderxc> when??
[12:11] <gtriderxc> i just made a translation of checkbox in natty and in upstrem
[12:11] <andrejz> that's even better :)
[12:11] <andrejz> you are translating the trunk of checkbox
[12:12] <gtriderxc> translations from checkbox are invisible in natty
[12:12] <gtriderxc> translations from natty are visibla in checkbox
[12:12] <andrejz> yes because natty probably doesn't use trunk but some stable version
[12:12] <gtriderxc> ain't silly a bit:/
[12:12] <gtriderxc> ok:/
[12:12] <andrejz> hm, this is the consequence of message sharing
[12:12] <gtriderxc> double work
[12:13] <andrejz> some of launchpad developers might now why this happens
[12:13] <gtriderxc> ok the karma will be bigger but i could use my time to do something else
[12:14] <andrejz> in theory when you translate some of the strings upstream they should be translated in natty as well
[12:14] <andrejz> probably a launchpad developer like danilos knows more about it ..
[12:15] <andrejz> why doesn't it work as it should
[12:15] <danilos> well, there is no translations sharing between upstreams and ubuntu *yet*
[12:15] <danilos> it's going to come around only next month :)
[12:15] <dpm> andrejz, yes, the theory is correct. However, for it to happen, the developer has to do the manual step of exporting the translations and put them in the code
[12:16] <danilos> for now, the regular process is that upstream translations are packaged for ubuntu, and that's when ubuntu gets them
[12:16] <andrejz> ok, good to know
[12:16] <gtriderxc> hey??!
[12:16] <gtriderxc> i just made a translation
[12:17] <gtriderxc> and I'd rather say the upstream takes suggestions from natty not natty from upstream
[12:17] <gtriderxc> so i'm gonna translate natty
[12:18] <gtriderxc> and then just one day approve the translation in upstream
[12:18] <danilos> gtriderxc, well, suggestions should show up both ways
[12:18] <gtriderxc> but they do not
[12:18] <gtriderxc> just checked it
[12:19] <gtriderxc> checked in checkbox:)
[12:22] <gtriderxc> perhaps because You write about suggestions. what i made was a approved translation right away
[12:24] <gtriderxc> *stright away
[12:28] <gtriderxc> ok, i'm gonna make a 100 suggestions for natty, then I'll approve 'em in upstream and then approve in natty:/ it's gonna cost time but has the most sense
[12:28] <danilos> gtriderxc, they should show up if they are "used" in one as suggestions in the other
[12:28] <danilos> gtriderxc, no need to make them only as suggestions
[12:29] <danilos> gtriderxc, also, here's another suggestion for you: translate in one place (eg. upstream), download a PO file, and then upload that PO file to the other place (i.e. ubuntu)
[12:29] <danilos> gtriderxc, that should be much quicker if that's what you want to achieve
[12:29] <gtriderxc> wow
[12:29] <gtriderxc> ok
[16:18] <andrejz> dpm are you there?
[16:31] <dpm> andrejz, I'm there, but about to go. If you've got a question, sjust shoot, and I'll try to answer when I'm back
[16:31] <andrejz> what does automated language pack test do ?
[16:31] <andrejz> https://code.launchpad.net/~dpm/ubuntu-translations/ul10n-tests
[16:34] <dpm> andrejz, there are instructions in the README file. But basically, to give you a bit of background: we talked at UDS about automated translation tests, so that it would be easier to e.g. test language packs. The idea is that a script is run that calls a localized application and runs some basic tests to make sure it's ok. Right now the scripts there are doing that job, but they are very very basic. The idea was to have something that anyone intere
[16:34] <dpm> sted can use as an example and expand on it. I'm not going to be working on it further this cycle, but perhaps we can do it next cycle
[16:35] <dpm> what they do right now is simply start the application, make sure it does not crash and dump all the strings from the first-level menus
[16:46] <dpm> see you all tomorrow, have a great rest of the day!
[16:49] <happyaron> good night everybody, :-)
[22:39] <gtriderxc> good night


[05:14] -queuebot:#ubuntu-release- New binary: python-markdown2 [amd64] (disco-proposed/universe) [2.3.7-1] (no packageset)
[05:14] -queuebot:#ubuntu-release- New binary: python-pywebview [amd64] (disco-proposed/universe) [2.2.1+dfsg-1] (no packageset)
[05:22] -queuebot:#ubuntu-release- New binary: openscad [s390x] (disco-proposed/universe) [2015.03-2+dfsg-2.2] (no packageset)
[05:26] -queuebot:#ubuntu-release- New binary: openscad [ppc64el] (disco-proposed/universe) [2015.03-2+dfsg-2.2] (no packageset)
[05:34] -queuebot:#ubuntu-release- New binary: openscad [i386] (disco-proposed/universe) [2015.03-2+dfsg-2.2] (no packageset)
[05:44] -queuebot:#ubuntu-release- New binary: openscad [amd64] (disco-proposed/universe) [2015.03-2+dfsg-2.2] (no packageset)
[23:15] -queuebot:#ubuntu-release- New binary: python-project-generator-definitions [amd64] (disco-proposed/universe) [0.2.38-1] (no packageset)
[23:15] -queuebot:#ubuntu-release- New binary: pyspectral [amd64] (disco-proposed/universe) [0.8.6+ds-1] (no packageset)
[23:16] -queuebot:#ubuntu-release- New binary: python-hgapi [amd64] (disco-proposed/universe) [1.7.3+git20170127.dd8fb7b-1] (no packageset)
[23:25] -queuebot:#ubuntu-release- New binary: gnss-sdr [amd64] (disco-proposed/universe) [0.0.10-2] (no packageset)
[23:48] -queuebot:#ubuntu-release- New binary: gnss-sdr [i386] (disco-proposed/universe) [0.0.10-2] (no packageset)
[23:54] -queuebot:#ubuntu-release- New binary: golang-github-nats-io-gnatsd [amd64] (disco-proposed/universe) [1.3.0+git20181112.3c52dc8-1ubuntu1] (no packageset)


[06:28] <AskUbuntu> simple MAAS setup in ubuntu 13.04 and virtual box | http://askubuntu.com/q/318032
[10:52] <sputnik13> hello?
[11:00] <sputnik13> anyone around?  I'm wondering if there's ways to use a hybrid virtual and real maas setup
[11:00] <sputnik13> I know there's a way to do virtual-maas but can you include real physical nodes as well?
[11:01] <sputnik13> or are they mutually exclusive
[13:10] <melmoth> sputnik13, if the real node are on the same network/bridge tje vm are on, it should work.
[13:10] <melmoth> i had some maas hosted in a vm, coping with other vms as node as well as real hardware one.
[14:03] <roaksoax> sputnik13: maas in reality sees VM's and physical machines as a machine. The only difference is how will it control the power
[22:02] <hazmat> roaksoax, around?
[22:06] <roaksoax> hazmat: here!
[22:06] <hazmat> roaksoax, awesome.. i'm trying to reset/debug a bespoke maas setup.
[22:06] <hazmat> with juan..
[22:06] <hazmat> if you've got a few m we're in a hangout
[22:07] <roaksoax> hazmat: sure,
[23:27] <hazmat> roaksoax, thanks.. i think i got it working.. all machines powered down minus juju bootstrapping
[23:28] <hazmat> roaksoax, that github ticket was key i think
[23:28] <hazmat> for the bot archive.. https://github.com/celery/celery/issues/984


[17:14] <Wiz_KeeD> hey fellas
[17:15] <Wiz_KeeD> I want to determine if the repo where I pulled my branch from is a older revision of the one I have currently how do I do it?
[17:15] <Wiz_KeeD> I
[17:16] <Wiz_KeeD> I'm doing a deployment script and want to push only if neccesairy?


[03:41] <eswenson> is this the right place to discuss getting an ubuntu distro for the igepv2 board?
[03:44] <eswenson> I have an old version of karmic running on my igepv2, but I'd like to upgrade to 12.04.  Can't seem to find any relevant instructions.  I built the omap kernel I used for my karmic install from source and used a stock rootfs.  Not sure how to get 12.04 installed.
[03:47] <infinity> eswenson: We used to support igepv2 out of the box (more or less), but I'm not sure how much of that has bitrotted.
[03:47] <infinity> eswenson: Have you tried a stock 12.04/omap image?
[03:48] <eswenson> I haven't yet.  If there is a prayer of a chance that it would work, I'll give it a whirl.
[03:49] <infinity> I don't have the hardware to test on, and precious few people ever ask about it, so the honest answer is "I have no idea, but maybe."
[03:49] <eswenson> I haven't played with the igepv2 for 2 years.  Is it "dead" (lost cause)?  Is there are better board that is similar that *is* actively supported?
[03:49] <infinity> The best bang for your buck these days would be the Pandaboard (or the PandaES, which is the slightly faster and newer version of the same)
[03:50] <eswenson> I'll check it out.  Thx.
[03:51] <infinity> If you want an omap3 (like your igepv2) instead of omap4 (which the Panda is), the Beagleboard community seems to be much more active (and we do support those in Ubuntu, though just barely, and some of us are getting sick of how awfully slow they are)
[03:51] <infinity> But if you're just looking for "a decent ARM device to play with", Pandas are great.
[03:54] <eswenson> Yes, the Pandaboard ES looks really nice.  Appears to cost about $180.
[03:56] <prp^2> infinity: beagle community is far more active as there are more people actually designing products around AM3xxx series
[04:02] <eswenson> prp^2 are you saying that the beagle community is more active than the panda board community?
[04:03] <prp^2> eswenson: yea it is about a 4 to 1 ration on activity
[04:03] <eswenson> Last time i checked beagle board, the board seemed quite inferior to the igepv2 board.  But I'll look again.
[04:04] <prpplague> eswenson: panda is far more active on the professional developer scene, but beagle is far more active on the low end, small volume oem, and hobbyist marked
[04:04] <prpplague> eswenson: igepv2 is basically a beagle, and many of the igepv2 folks share the beagle community areas
[04:05] <prpplague> eswenson: there is only the panda , no clones such as the igepv2 for beagle
[04:06] <eswenson> I have been looking around on the igepv2 forums/wikis and it doesn't seem very active, nor has there been much interest in ubuntu since karmic.
[04:06] <eswenson> But I  have this board (igepv2) and was hoping to bring it to life with a more current kernel/distro.
[04:06] <eswenson> But if it's really a waste of time, then I'd be up for getting another board....
[04:06] <prpplague> eswenson: basically what works for beagle works for igepv2
[04:07] <eswenson> So you're saying that if I took the 12.04 port for the beagle board, I should be able to get it running on the igepv2?
[04:07] <prpplague> eswenson: yea
[04:07] <eswenson> Same u-boot-arm and x-loader, or are these specific to the igepv2?
[04:08] <prpplague> http://www.elinux.org/BeagleBoard#IGEPv2
[04:09] <eswenson> So I'd probably need additional drivers for the on-board ethernet, wifi, and bluetooth...
[04:09] <prpplague> eswenson: probably not, most of the beagle builds have all the support for the clones as well
[04:09] <prpplague> eswenson: igepv2 has been around for some time
[04:10] <prpplague> iirc since aroun 2008
[04:10]  * prpplague checks
[04:10] <eswenson> yeah.  I bought mine in 2010.
[04:13] <eswenson> will armhf images work on the igepv2?  I thought I needed armel?
[04:21] <eswenson> the scripts I see for building the omap kernel on elinux.org suggest that while the igepv2 is weakly supported, it is supported with no video.  I'll need video.  My existing (karmic-era kernel) supports video fine on the igepv2.
[04:38] <prpplague> eswenson: thats probably long out of date
[04:38] <prpplague> eswenson: when was the page last updated?"
[06:25] <eswenson> Page was last modified on 12 June 2012.  (http://elinux.org/BeagleBoardUbuntu)
[09:03] <twb> tf101, running oneiric armel but with armhf and precise added in post-install.  apt.conf has APT::Default-Release "oneiric";
[09:03] <twb> When I pull in mplayer, I get: mplayer: Symbol `ff_codec_bmp_tags' has different size in shared object, consider re-linking
[09:03] <twb> ...and mplayer: relocation error: mplayer: symbol __aeabi_f2ulz, version LIBAVCODEC_53 not defined in file libavcodec.so.53 with link time reference
[09:04] <twb> Is it obvious to anyone which package(s) should be up/downgraded to address that?
[09:04] <twb> Plan B is to just poke at the libavcodec packages and see what happens.
[09:08] <twb> Ah, oops, I thought I was testing the mplayer from precise, but it was the oneiric mplayer, so no surprise it wasn't working.
[09:14] <twb> Cool, works now (apt-get install mplayer/precise --no-install-recommends libavformat53/precise libavcodec53/precise libva1/precise).
[09:44] <Orb> Having a problem with my Pi and getting my wifi dongle Netgear N150 wna1100 to work. New to using debian, have followed instruction on net but must be missing the point somewhere.
[09:47] <Orb> Can see dongle when using lsusb, but can not see after have done a update and install of firmware. Think it could be my interfaces file but have no idea
[09:48] <ogra_> you probably want to go to #debian-arm on oftc.net
[09:48] <Orb> thank you will do
[13:22] <angs> I installed the ubuntu desktop image for the beagleboard-xM. here is the command that I typed and its output http://paste.ubuntu.com/1062526/ after that I inserted the sd card into the board and powered it up. however, I dont see any output on the monitor. I use hdmi dvi-d cable for it.
[13:23] <angs> do I do something wrong?
[13:32] <angs> or what do I need to do next?
[13:35] <ogra_> it should just work, do you have a proper power supply attached ?
[13:36] <ogra_> iirc the bone uses a lot less power than the XM, you will need some decent PSU for driving the USB hub on board
[13:36] <angs> I am supplying it by a 5V, 1A adapter
[13:37] <ogra_> not sure 1A is sufficient
[13:37] <angs> user manual says 1A is minimum at some pages, on other pages 1.5A min
[13:37] <ogra_> i know  th epandaboard wont work with less then 2A
[13:38] <ogra_> minimum, yeah
[13:38] <angs> I saw youtube videos that they just supply with usb to mini usb
[13:38] <ogra_> that means with nothing attached at all
[13:38] <ogra_> right, but if you attach a USB keyboard and mouse the world looks different :)
[13:38] <angs> :)
[13:38] <ogra_> i can easily power my beagle C4 from mini USB
[13:38] <angs> so when I have a proper power supply, it should work fine, right?
[13:39] <ogra_> i dont think that works with my XM (though i must admit i never tried)
[13:39] <ogra_> well, if your issue is power, then it should, yeah
[13:39] <angs> so I need to wait one more day to try it :(
[13:40] <angs> thank you for your help
[13:40] <ogra_> the images are tested in a ton of different setups  and i'm positive they work out of the box if there isnt any HW issue
[13:40] <angs> I just wonder if there is any additional step that I need to do after booting it
[13:40] <ogra_> in any case you should see bootloader messages on the serial port
[13:40] <angs> I will have the serial cable tomorrow
[13:41] <ogra_> great
[13:41] <angs> I can not access it through the ethernet connection, right?
[13:41] <ogra_> ??
[13:41] <ogra_> nope
[13:41] <ogra_> you have to pulg it into the serial port of the beagle
[13:41] <ogra_> *plug
[13:42] <angs> got it. is there any video instruction for it?
[13:43] <ogra_> i dont think so ... and i would be surprised if you need it
[13:43] <ogra_> the cable usually only has a serial plug on one side and an USB plug on the other
[13:44] <ogra_> serial goes into the serial socket on the board, usb into your PC
[13:44] <angs> I wanted to mean the ubuntu installation to a beagleboard
[13:44] <ogra_> nope, no video of that either
[13:45] <ogra_> its boots into a graphical config tool (or console config tool if you use the server image) asks for timezone, keymap, language and user data, and thats is
[13:47] <angs> that was what I wondered :) so it is the reason that I can not use ssh before setting those settings, isn't it?
[13:47] <ogra_> you can not use ssh because there is no ssh server installed by default
[13:48] <angs> ah ok
[13:48] <angs> so I will wait for tomorrow to proceed. thanks a lot again
[13:50] <angs> do you know the reason why beagleboard links to elinux for ubuntu? http://beagleboard.org/project/ubuntu/
[13:50] <angs> why not https://wiki.ubuntu.com/ARM/
[13:50] <angs> I mean as a homepage
[13:51] <ogra_> nope, no idea
[13:51] <ogra_> ask in #beagle :)
[13:51] <angs> right:) thank you
[13:51] <ogra_> someone there likely maintains these links
[14:02] <janimo> marvin24, are the DRM patches being currently sent to the tegra part of fixing the graphics on tegra, and the biggest blocker yet before full support is ready?
[14:03] <janimo> marvin24, I know you told me before some large pieces of code are still needed for full support but I do not remember if you said exactly which
[14:04] <marvin24> janimo: drm is only a prove of concept and not planed to upstream in the current form
[14:04] <marvin24> on the tegra list there is a discussion on how to setup the device tree info currently
[14:04] <marvin24> and code comes after that ...
[14:05] <marvin24> also there is almost no power management support on mainline
[14:05] <janimo> marvin24, is that because overall PM framework has changes so much that the pm code in 3.1 is of no use?
[14:05] <janimo> 3.1 and 2.6.x which works on ac100
[14:08] <marvin24> janimo: I surely can't
[14:08] <marvin24> if you like to care for forward porting 6000 patches, you can try
[14:09] <janimo> marvin24, I mean the reason for PM framework changes between 3.1 and 3.6 is why it needs a complete rewrite?
[14:09] <marvin24> janimo: honestly, I don't know
[14:10] <marvin24> I guess it is more lag of developers
[14:10] <janimo> marvin24, I saw no clear tegra mainlining roadmap ever - if there is one - so I still have no idea what is planned for when and how much effort it is
[14:10] <janimo> so it makes planning for packaging a bit harder :)
[14:10] <marvin24> yes, nvidia never was very "communicative"
[14:11] <marvin24> janimo: did you saw the post of Stephen Warren on the xorg list?
[14:11] <janimo> marvin24, I am not following that list, so no
[14:11] <janimo> link?
[14:12] <marvin24> sorry, it was kernel summit: http://lists.linux-foundation.org/pipermail/ksummit-2012-discuss/2012-June/000304.html
[14:12] <marvin24> I think he is open for more responses
[15:03] <janimo> marvin24, thanks, reading now
[16:31] <robher> NCommander: the current highbank installer initrd appears to be corrupt. The kernel doesn't like it and "cpio -i --to-stdout < Downloads/initrd > /dev/null" gives "cpio: premature end of file"
[16:35] <robher> md5 sum is okay though...
[16:41] <infinity> robher: The initrd from the archive, or some homebrew thing from NCommander?
[16:43] <robher> infinity: from the archive. uploaded today.
[16:43] <infinity> robher: zcat initrd.gz | cpio -t looked fine to me.
[16:43] <infinity> As did actually extracting it.
[16:43] <infinity> (base)adconrad@cthulhu:~/hb$ zcat initrd.gz | cpio -i
[16:43] <infinity> cpio: dev/console: Cannot mknod: Operation not permitted
[16:43] <infinity> cpio: dev/null: Cannot mknod: Operation not permitted
[16:43] <infinity> 24314 blocks
[16:44] <infinity> ^-- Looks fine.
[16:45] <infinity> robher: 20101020ubuntu150?
[16:48] <robher> infinity: Those commands work for me too. Strange...
[16:48] <robher> infinity: yes, 20101020ubuntu150
[16:50] <robher> infinity: seems --to-stdout doesn't work. Other initrds that work have the same message. Back to u-boot debug...
[16:52] <RoyK> hm... is -d implicit with cpio these days?
[17:06] <janimo> marvin24, do you know ny tegra specific fbcon issues with 2.6.39?
[17:19] <gildean> nexus 7 live: https://developers.google.com/events/io/
[18:29] <robher> infinity: same problem with different kernels. other initrds work with installer kernel. I can reproduce the problem within qemu as well. If I gunzip the initrd and re-gzip it, it works fine.
[18:30] <infinity> robher: Seriously?  That's disconcerting.  And a much deeper bug, then.
[18:30] <infinity> robher: And I'm trying to decide if I blame it on gzip or the kernel.
[18:32] <infinity> robher: A rebuild will probably "fix" it, but boy, I'd like to know how it's breaking in ways that gzip doesn't mind but the kernel's internal zlib routines hate.
[18:32] <scientes> wow
[18:32] <scientes> could be the convervativeness of the offset on decompression
[18:32] <scientes> b/c its a one-shot decompressor and it decompresses in place in ram
[18:33] <infinity> Sure.  Could be a lot of things.
[18:33] <infinity> But this isn't exactly something we see often.
[18:33] <infinity> (In that, I've never seen it before at all, and we kinda rely on initrds for... Everything)
[18:33] <robher> infinity: perhaps the kernel's gunzip doesn't like something in newer gzip? I'm on precise.
[18:34] <scientes> oh wait, robher are you using 3.5?
[18:34] <infinity> Maybe I should just switch debian-installer to producing lzma initrds by default and scream "LA LA LA".
[18:34] <infinity> scientes: No, he's using 3.2
[18:34] <scientes> ok, cause there is a bug that was created in merging otherwise good code in 3.5, for arm compressoin
[18:34] <infinity> Or, wait.  This was highbank?
[18:34] <infinity> I've lost track.
[18:35] <robher> The kernel log has "rootfs image is not initramfs (no cpio magic); looks like an initrd" then later...
[18:35] <infinity> highbank is 3.5 in quantal, yes.
[18:35] <scientes> well that that is probably it
[18:35] <scientes> the problem is that the decompression stuff declres STRING_H
[18:35] <infinity> But he claimed he tried the initrd with older kernels.
[18:35] <scientes> and prevents the real string.h loading
[18:35] <infinity> robher: You tried the quantal initrd with a precise kernel and got the same error?
[18:35] <scientes> and linking with early boot/decompression stuff
[18:36] <scientes> now that was already there, but some new code now actually wants to use string.h
[18:36] <scientes> i did some messaging on the mailinglist of the person's code that was affected, but nothing came of it
[18:38] <robher> I've tried mainline 3.2 + highbank patches and see the problem.
[18:39] <infinity> Could the highbank patches be backporting this problematic bit that scientes speaks of?
[18:40] <scientes> > the recently added to arm, CONFIG_KERNEL_XZ is broken because
[18:40] <scientes> > arch/arm/boot/compressed/decompress.c defines _LINUX_STRING_H
[18:40] <scientes> > overriding <linux/string.h> used in include/linux/dynamic_debug.h:111
[18:41] <scientes> i didn't really research the scope, it could go beyond xz, a kernel i compiled with gzip didn't boot for me
[18:41] <infinity> scientes: And, despite that being an XZ patch, that breaks all compression methods?
[18:41] <infinity> Fun.
[18:41] <scientes> infinity, it was actually the debug patch that was broken
[18:41] <scientes> both were merged inthe same window
[18:41] <scientes> so both are to blame
[18:41] <scientes> it was a conflict that wasn't seen
[18:41] <infinity> Check.
[18:42] <infinity> Well, if this is the bug, we should report it, track it, and fix it.
[18:42] <infinity> robher: Is your "mainline+highbank" kernel a homebrew, or our 3.2.0 from precise-updates?
[18:42] <scientes> i send that to the debug person, but he didn't seem adament about fixing it, the STRING_H stuff was put there years ago, by Russel, but only now became a problem
[18:43] <scientes> i can only think that it was put there to try to make stuff leaner
[18:44] <scientes> anywas, may not be the problem, but its definitely a bug
[18:45] <robher> infinity: it is not an ubuntu kernel. It's roughly what I've published on our git tree.
[18:45] <robher> I did find this: I'm seeing where I have to remove CONFIG_BLK_DEV_RAM from the kernel
[18:45] <robher> to get it to boot with an external initramfs image. It says the image
[18:45] <robher> is not good (junk in it), but it boots.  The same image boots fine
[18:45] <robher> when built into the kernel using INITRAMFS_SOURCE, even with
[18:45] <robher> BLK_DEV_RAM in the kernel.
[18:46] <robher> from the lakml
[18:48] <infinity> robher: Can you check if it works with the precise 3.2.0 kernel?
[18:49] <infinity> robher: Just as a datapoint.
[18:49] <infinity> If the initramfs really doesn't load with ANY kernel, I'd be looking to blame gzip.
[18:49] <deviker> hello, what toolchain are you using for allwinnerA10 (it's an armv7 but the images people have built are for armv5)
[18:50] <scientes> deviker, all ubuntu is armv7, even the soft float armel
[18:50] <infinity> scientes: (sort of)
[18:50] <infinity> I guess I shouldn't confuse people, though.
[18:51] <scientes> infinity, are you referencing assembly that isn't ported?
[18:51] <scientes> or is certainly C compiled with differn't settings
[18:51] <infinity> deviker: We're not doing anything for the A10, but if someone were to do so on Ubuntu, our toolchain on armhf defaults to armv7-a.
[18:51] <infinity> scientes: No, I'm refering to the fact that quantal's armel toolchain is armv5t.
[18:51] <infinity> scientes: Shh, don't tell anyone.
[18:51] <scientes> oh wow
[18:52] <scientes> just the toolchain, or its settings?
[18:52] <deviker> thanks, I've to go I'll be back in a hour
[18:53] <scientes> cause you keep telling everyone they cant run ubuntu on their sheevaplugs or rasperri pis
[18:53] <infinity> scientes: The defaults in general.  It's been a silent rolling rebuild that is, well, "public" (cause people can read changelogs), but not "publicised", cause we don't want people getting all excited about it, in case we decide to just drop the port instead (which we may well do)
[18:53] <infinity> scientes: And yeah, booting quantal/armel on a Pi would fail miserably right now, cause half the archive is still v7. ;)
[18:54] <infinity> scientes: Lazy organic zero-effort rebuild, for the win.
[18:54] <infinity> scientes: If we decide to keep armel, I'll scan the archive a month before release for remaining v7 bits in main and rebuild them.
[18:54] <infinity> scientes: universe won't be so lucky.
[18:54] <scientes> well im liking my systemd setup on my sheevaplug ;)
[18:55] <scientes> (with debian)
[18:55] <infinity> I assumed, yes. ;)
[18:58] <robher> infinity: same problem with precise 3.2.0-26.41
[18:59]  * infinity grumps.
[18:59] <infinity> Of course, that still doesn't rule out the highbank sauce.
[18:59] <infinity> Someone should try it with an i386 kernel. :P
[19:05] <robher> infinity: the first version of the highbank installer posted worked fine. That was on 3.4, but the highbank parts haven't really changed.
[19:08] <infinity> robher: So, there is a kernel that will load that initrd?
[19:12] <robher> infinity: no, no. A previous quantal initrd for highbank worked.
[19:12] <infinity> robher: Oh, yeah, that's probably a less interesting datapoint.
[19:13] <infinity> robher: If I can find a round tuit, I'd like to know if *any* kernel can decompress the new initrd.
[19:13] <infinity> omap4, something not ARM at all, whatever.
[19:13] <infinity> If it universally explodes on everything, then it's obviously(ish) something wrong with how it's being generated.
[19:14] <infinity> If only highbank kernels complain about it, then there's something wonky in that patchset tickling a misbehaviour.
[19:14] <infinity> But, if there's something wrong with how we generate initrds, I'm frankly shocked that this is the very first one we've had that breaks.
[19:15] <infinity> (I suppose the other--really remote--possibility is that there was some subtle corruption when it was generated that doesn't bug gzip, but does bug the kernel, but what are the odds?)
[19:19] <robher> infinity: perhaps uncompress and recompress on quantal x86 and arm and make sure the results are the same as the original. I definitely got a different size with precise, but I haven't looked at the options used when building the installer
[19:23] <infinity> gzip -v9f ./tmp/highbank_netboot/initrd
[19:23] <infinity> ^-- From the log.
[19:23] <infinity> Nothing special.
[19:23] <infinity> Though the -9 may be why your size differed.
[19:25] <robher> infinity: with -9 the size is the same before and after and it doesn't work.
[19:26] <infinity> Curious indeed.
[19:26] <infinity> Cause we build all our initrds with -9
[19:26] <infinity> And always have.
[19:26] <infinity> So...
[19:30] <Neko> yerg, you know lzma or xz gets passed -9 too and this is hideous on ARM (since the dictionary size means the buffer required to compress is easily more than most ARM devices are capable of, let alone come with on most reference boards).
[19:31] <Neko> given it gets decompressed into memory anyway if it's just a compressed cpio archive, and the source data is freed up after that, does it really matter how big it is on disk?
[19:33] <infinity> Neko: It matters because uBoot sucks.
[19:34] <Neko> in what way?
[19:34] <Neko> u-boot doesn't decompress initrds
[19:34] <infinity> Neko: Smaller is much better, and I've never seen the decompression take anywhere near as long as the load.
[19:34] <Neko> or.. let me put that a better way. it damn well shouldn't.
[19:34] <infinity> Neko: No, uBoot does the load, and it's awful at it.
[19:34] <infinity> Neko: Hence, smaller better.
[19:34] <Neko> okay so you're generating uncompressed cpio initrds and then letting mkimage compress them?
[19:35] <infinity> Neko: No.  These ones aren't mkimaged.  highbank is a unique snowflake.
[19:35] <Neko> bootz? :)
[19:35] <infinity> Neko: Yeahp.  Though, feeding them raw to qemu appears to exibit the same issues, to it's not the bootloade doing bad things.
[19:36] <Neko> that's not really unique not to want to use uimage anymore. okay.. so you just want them as small as possible. well I'd try using something other than gzip for a start.
[19:36] <robher> infinity: u-boot is the snowflake. :)
[19:36] <Neko> kernel supports xz and xz initrds actually decompress faster than gzip ones somehow :)
[19:37] <infinity> Neko: Yeah, yeah.  None of this is news.
[19:37] <Neko> even at default settings you'll get better compression out of it and a slightly faster boot. it's really a no-brainer on what to do..
[19:37] <Neko> so xz initrd doesn't work either, or?
[19:38] <infinity> Neko: And moving our initrds to a newer compression method is something to look into, but hardly addresses this current issue, just sidesteps it, possibly.
[19:38] <Neko> what is the issue, just a random borkage?
[19:38] <infinity> Neko: The issue is the kernel refusing to load this particular initrd, full stop.
[19:38] <infinity> Neko: Talking about how to build it differently doesn't in any way change that the kernel doesn't like this one. :P
[19:38] <Neko> oh shit, we saw that a bunch of times on efika and 3.2/3.4/3.5 kernels..
[19:39] <Neko> at some point it just magically solved itself
[19:39] <Neko> I think we bumped a kernel version and redid our config..
[19:39] <infinity> That's comforting.
[19:40] <Neko> well, I wish you all the luck in the world, but we spent 2 weeks looking for the problem and once we decided 3.2 was too old, I think 3.4 it didsappeared and we saw a random occurance somewhere. it may be due to decompressing overitself or maybe some really highly esoteric cache problem.
[19:40] <infinity> Given that gzip -9 is still our default for initramfs-tools-generated initrds too, we can't just let this bug float out there and hope it only happens sometimes.
[19:40] <infinity> Creating unbootable systems on upgrades is, well, bad.
[19:40] <Neko> the problem is it's most likely some u-boot weirdness.
[19:41] <infinity> robher: Can you file a bug against "linux" (I kinda want to blame the kernel for now, until we have further data) and try to summarize this IRC backscroll mess a bit?
[19:41] <Neko> the kernel works fine no matter what we do right now.. I don't think we found a config item that changed anything, or at least, nothing changed that would make a bit of difference regarding boot. we added a few new drivers and removed the old implementations but they were thoroughly checked
[19:42] <Neko> does u-boot invalidate the caches over the kernel and ramdisk area as it puts them there, or before boot?
[19:42] <infinity> robher: However we fix and/or workaround this, we need it fixed before highbank hardware starts landing in the hands of "real people", cause "rebuild your initrd 4 times and do a magic dance, and it'll work sometimes" isn't quite enterprise-ready. ;)
[19:42] <Neko> for uimage it can know the sizes involved but for a zimage and raw initrd I wonder how it'd know what to invalidate
[19:43] <infinity> Neko: Yeah, I'm not sure what crazy uBoot does here.
[19:44] <Neko> sometimes just turning off the L2 cache completely before getting to Linux isn't the solution as it doesn't always go back to memory since it's in L1.. but Linux does give things a kick, there can still be some stale data in L1, plus god knows how many SCU and L2 errata on everyone's A9 implementations these days
[19:44] <Neko> did you enable all the arm errata in the kernel just in case? :)
[19:45] <robher> infinity: I'll file the bug. It's already in the hands of real people. I was just trying to figure out why a customer was getting the can't find kernel modules error message in the installer. But I never got there...
[19:45] <infinity> robher: Oh, we already have "real customers" installing precise on highbank despite the lack of installer?
[19:45] <infinity> robher: Or bleeding edge folks using quantal?
[19:46] <robher> Neko: L2 and L1 data caches are off in u-boot.
[19:46] <infinity> robher: Either way, fun.  Please file the bug, subscribe me (adconrad), and we'll see if we can find some sane resolution to this before we "officially" support highbank in 12.04.1
[19:48] <robher> infinity: we'd rather have them using precise and we ship systems with it, but you don't have the installer published yet. So for the ones that want to do installs, quantal is their only choice ATM.
[19:50] <infinity> robher: We should make sure we get the installer bits in precise-proposed ASAP, then.
[19:50] <NCommander> robher: precise highbank is dep-wait a kernel SRU at the moment
[19:50] <infinity> NCommander: One in the PPA, or one in proposed?
[19:51] <NCommander> infinity: in the PPA. The previous upload added highbank but forgot the udebs
[19:51] <infinity> NCommander: Oh, whoops.
[19:51] <NCommander> so the fix for that had to wait for the next SRU cycle; can't upload d-i without it since it wants udebs
[19:52] <infinity> NCommander: Right, well, I was going to backport some armadaxp and highbank d-i stuff to precise-proposed and then sit on it until it was ready to be uploaded.
[19:52] <infinity> NCommander: But are all the ducks in a row WRT flash-kernel and such?
[19:52] <NCommander> infinity: yeah, I'm sitting on it right now, though I haven't uploaded to proposed
[19:53] <NCommander> (guess it wouldn't actually interfere with anything so I could just "do it")
[19:53] <infinity> NCommander: Please do, so we can review in small chunks instead of one massive vomit of SRU.
[19:53] <NCommander> infinity: will try to get everything uploaded by EOD then
[19:58] <Neko> robher, turning them on might make it load faster :)
[20:04] <robher> infinity: this might be some brokenness in bootz cmd. Putting the initrd in an uInitrd works.
[20:05] <infinity> robher: That's doubly disconcerting.
[20:05] <infinity> robher: Also, I thought you said that feeding it raw to qemu also failed?
[20:05] <infinity> robher: Which would rule out uboot/bootz.
[20:06] <infinity> robher: Unless the highbank qemu actually starts by feeding the kernel/initrd arguments to uboot. :)
[20:06] <infinity> (I haven't played with it)
[20:13] <infinity> 14:12 <apw> when i was doign highbank config fixes we had a thing where the initramfs would fail decompression
[20:13] <infinity> 14:12 <apw> but if you then hit ^d it was all in there
[20:13] <infinity> 14:12 <apw> and it was caused by the length of the initrd being somehow out of sync with what was loaded
[20:14] <infinity> 14:12 <apw> the conjecture was the loader was rounding down the size and not loading enough blocks
[20:14] <apw> there was something a
[20:14] <apw> about the boot loader needing to be told the exact size or something
[20:15] <apw> rbasak i think you were involved and may be able to use the right words
[20:16] <infinity> apw: The problem is that if someone was hacking around this with boot.scr magic in flash-kernel, it will do exactly 0 good for people loading the kernel/initrd raw.
[20:16] <infinity> rbasak: ^
[20:16] <apw> right
[21:05] <robher> infinity: it could be related to that previous issue, but the work-arounds for it didn't help this time. Avoiding u-boot copying the initrd worked before. But like all mysterious problems that disappear or are fixed in unexplained ways, they always come back
[22:12] <rbasak> robher, infinity, apw: the workaround I used that worked was to manually increase the size of the initrd provided to the bootz command to round up to the next page. This was without robher's fix. That worked for some reason.
[22:20] <robher> rbasak, infinity: Looks like u-boot is overlapping its initrd copying with its stack.
[22:27] <infinity> rbasak: You mean increase the size that you tell u-boot, or pad the initrd.gz file with zeroes past an arbitrary boundary?
[22:27] <infinity> rbasak: Cause we could certainly incorporate the latter as a hack in the d-i builds, if it works.
[22:28] <infinity> robher: That sounds unpleasant.
[22:29] <infinity> robher: On the one hand, "yay, not my bug", on the other hand, if there's anything we can facilitate as a reliability workaround, let us know.
[22:30] <robher> sp start    = 0x1FF00F60  and  ramdisk load end = 0x1ff006c3
[22:31] <infinity> That doesn't look overlapped to me, unless 6 suddenly became larger than F when I wasn't looking.
[22:32] <robher> evidently the CONFIG_STACKSIZE value is no longer used and setting it to 128K is pointless
[22:32] <robher> stacks grow down
[22:32] <infinity> Ahh.  And it's larger than f60-6c3, I take it?
[22:34] <infinity> Anyhow.  Back to work.
[22:35] <infinity> robher: Happy bug hunting.  But yes, unless you're confident that you can push fixed firmware to everyone (which would be nice), if you can come up with some hackish workaround that makes it DTRT despite the bug, let me know.
[22:36] <robher> I'm guessing so at this point. But the copy aligns the start of the initrd to 4K and so you have a variable amount of space between the end and the stack which is why it is sometimes okay.
[22:39] <robher> setenv initrd_high 0xffffffff will prevent the copy and fix it. I think you have this in the boot.scr, so it will only be an issue for pxe boots. All the systems now can be updated, so getting updates out should not be a problem.
[22:48] <robher> infinity: this could affect any ARM board and may be same problem seen on efika boards
[22:50] <Neko> I thought of that but I couldn't prove it at all
[22:51] <Neko> the difference is we weren't copying any of the images around, u-boot dumped them where we told them, and that was well, well away from the stack
[22:52] <Neko> so, sp start = top of stack, growing down into memory?
[22:52] <robher> yes
[22:53] <Neko> if I fatload an initrd into ram and bootz it, it won't relocate it as u-boot can't relocate it based on any info. for a uimage that's different but a ramdisk has a load address of 0. it should leave it where you fatloaded it to
[22:53] <Neko> are you saying on bootm or bootz it's copying the ramdisk out of the way of the kernel or some shit?
[22:54] <Neko> I may have to go see the u-boot guys about this.. but before that, I'll buy a nice new hammer, one with a rubber handle so when the blood really starts to flow.....
[22:54] <infinity> robher: Yeah, setenv obviously doesn't help for either PXE or people booting "raw" from the uboot CLI (unless they know the trick).
[22:55] <Neko> just removing that copy will reduce boot time, if your caches are disabled then a memcpy of a 10MB ramdisk will take some time.. not as long as loading it from an SD card, but appreciable nontheless.
[22:55] <infinity> robher: But if getting firmware updates out seems reasonable, I'll just happily forget we had this conversation.
[22:55] <Neko> infinity, initrd_high seems like a stupid hack to me. we set it on our development u-boot in the environment.
[22:55] <Neko> is this documented somewhere?
[22:55] <robher> what conversation...
[22:56] <Neko> we're gonna update efikamx uboot to align our old boards with DT and get the FSL dev boards acting the same way for development and unify with our new products.... I don't think I'd want this stuff getting into production releases
[22:56] <robher> There is a CONFIG flag that does the same thing and I can set it in the default environment.
[22:56] <Neko> wiki page at denx, or on an ubuntu bug properly investigated?
[22:58] <robher> Neko, just like u-boot relocates itself to the end of memory, it wants to do that for the initrd and fdt. The flag is documented in the README and there is also fdt_high.
[23:00] <robher> Neko: can I borrow the hammer when you're done with it? ;)
[23:03] <rbasak> infinity: I was increasing the size that I told u-boot on the bootz command. No padding with zeroes. The kernel did complain, but it carries on anyway, and since the valid part was uncompressed, there wasn't a problem
[23:03] <rbasak> If it's stack memory overlap I'm not sure why that worked though
[23:04] <rbasak> Unless stack is being miscalculated and dependent on the initrd size?
[23:04] <rbasak> But if it grows down, that makes no sense
[23:04] <rbasak> (to me)
[23:04] <rbasak> Anyway, it sounds like robher has worked out the problem
[23:07] <robher> rbasak: the amount of stack size all depends on the initrd size % 4K. So if you are slightly over 4K, that will leave more stack space untouched. This may explain why uImages were not working either.
[23:09] <rbasak> So how come the stack is placed right next to the initrd, anyway? :)
[23:10] <robher> because u-boot is stupid
[23:11] <robher> at least everything will be better with uefi.
[23:13] <Neko> I found the docs, and the code itself is obtuse to say the least
[23:13] <Neko> they're saying your kernel needs to support "zero copy ramdisk" to make initrd_high=0xffffffff work but that doesn't make any sense.. what system is there on this planet that doesn't support a "zero copy ramdisk"?
[23:15] <Neko> kernel piggy decompresser extracts out of the way of it's compressed code.. and out of the way of any ramdisk loaded too. ramdisk gets extracted afterwards some way into boot time based on it's format.. if it's compressed it always gets moved but the kernel always knows where it is
[23:15] <Neko> the address you load the ramdisk to is basically irrelevant, I can't imagine why u-boot would copy it around at all
[23:18] <Neko> the way we're loading internally here is start-of-mem+128kb = where boot.scr goes, start-of-mem+172kb = uImage, +10mb = dt + 10mb+64kb = initrd... in a system with 512MB or 1GB RAM even with a huge initrd, there's 450MB+ available above that. u-boot's stack starts from near top-of-mem and works down, so why incur the possibility that the stack can overwrite your stuff? linux uses memory from bottom up, that's why you keep everything low and stack
[23:18] <Neko>  high so you don't LOAD over your stack. Copying is redundant
[23:19] <Neko> also why would a 128kb uboot stack copy over a moved ramdisk, at the point uboot is moving ramdisks how can it possibly use that much stack anyway?
[23:19] <Neko> even a 4kb stack
[23:20]  * Neko goes to buy some hammer polish
[23:20] <lilstevie> lol
[23:21] <Neko> I can't complain too much because our OpenFirmware implementation couldn't load more than a 14MB initrd because it kept all it's stuff within 32MB since it could not tell at the time it determined the stack location, how much ram you actually had..
[23:21] <Neko> but that's a restriction of systems with a dynamic amount of memory where 32MB is *normal*. that's just not true for these systems.
[23:21] <Neko> is this for situations where u-boot has no clue what the memory size is when it loads?
[23:22] <Neko> because that would make some sense... not a lot, but some. I mean why couldn't it just put the stack at the low 128kb+space for page tables and cause a massive fuss if you used more than the amount of stack allocated. surely u-boot has some canary crap to make sure of this :(
[23:23] <Neko> hell on mx51 etc. why not keep running u-boot out of iram, and put the stack in iram?
[23:24] <Neko> I think I might cry :(
[23:28] <lilstevie> Neko: running the stack out of iram makes sense really
[23:29] <lilstevie> depending how much there is of course
[23:32] <Neko> 128k in mx51, 256k in mx53, 272kb in theory in mx6. actually loading u-boot in there makes no sense since the average u-boot size is 240kb.
[23:32] <Neko> but by the time u-boot loads due to the imx boot process, memory size is well known
[23:32] <Neko> so it can go in ram. but still.. fucksake.
[23:33] <Neko> I wish someone would document this with pictures that said "u-boot will go here, and your stack needs to go here, and this range is a decent range of addresses to put your files" and hopefully automatically generate such stuff as to not have to guess a load address or relocate anything ever again
[23:34]  * Neko is wondering why u-boot doesn't build if you turn off zlib and gzip support even though it never uses it


[14:10] <cnd> dandrader, you're a bit quick on the merge trigger :)
[14:10] <dandrader> cnd, what happened?
[14:11] <cnd> I hadn't approved the MP from yesterday, cause I wasn't sure if your response to the GBE_MAX_TOUCHES would highlight a deeper issue
[14:12] <cnd> it's all good now for this MP, but please check the review status before merging
[14:12] <dandrader> ah, yeah. now that you said that. I didn't notice that you didn't set the comment as "Approve" and left it just as a comment
[14:13] <dandrader> I had it as 12 because I was thinking about the maximum number of simultaneous touches that could land on a device we support, not as the maximum number of touches on a single gesture
[14:14] <cnd> I wondered if that wasn't the case
[14:15] <cnd> tvoss, dandrader, bregma_, standups!
[14:15] <tvoss> kanban fun
[14:15] <tvoss> oh, and itv's
[14:15] <cnd> I'm going to be cleaning the utouch bugs today so we can easily see what we need to get to
[14:15] <dandrader> adding multitouch gestures to nux
[14:15] <dandrader> tvoss, what's an "itv"?
[14:16] <tvoss> dandrader, an interview
[14:16] <dandrader> ah, ok
[17:34] <cnd> dandrader, what's going on with bug 978378?
[17:36] <dandrader> cnd, not working on it. at the time is was depending on something from utouch stack to get fixed and released but when that finally happened there were other priorities and now with the plan to move gestures stuff from unity to nux that one will have to wait quite a bit more
[17:37] <dandrader> will update its status
[17:37] <cnd> ok
[17:37] <cnd> dandrader, be sure to remove the milestone
[17:38] <dandrader> cnd, can't do it myself
[17:38] <cnd> ok
[17:39] <cnd> I removed it
[17:39] <cnd> bregma, howdy, I'm cleaning up the utouch bugs
[17:40] <cnd> in particular, what's the status of bug 997630
[17:41] <bregma> I'm trying to see what's going on, there's nothing obvious in geis that would cause the described behaviour, but you never know
[17:41] <cnd> ok
[17:47] <cnd> bregma, I see you're assigned to bug 803408 and bug 901692
[17:47] <cnd> should you be removed from the assignee?
[17:48] <bregma> wait a bit, I still have some spare cycles over the next few days
[17:49] <cnd> ok
[20:49] <cnd> argh, ppa purging is a pain


[12:06] <mpt> Perhaps it was a keyboard layout that required Shift for "-"
[01:01] <cjwatson> mpt: I was about to claim without proof that there were no such layouts, but sadly there are ;-)
[01:02] <cjwatson> ca(multi-2gr) and ca(multix). Those freaky Canadians
[01:03] <cjwatson> and the user in question came from an IP owned by a Montreal ISP, so you might actually be right ...
[01:33] <Elwell> Hey folks, is there a way to dump out progress into a preseed file to use on other machines?
[01:33] <Elwell> explicitly d-i partman stuff :-)
[01:35] <cjwatson> you can run debconf-get-selections --installer after installation
[01:36] <Elwell> aha. ta
[01:36] <cjwatson> but in the case of partman that won't be very useful, since partman needs to be preseeded with a special recipe
[01:36] <cjwatson> and debconf-get-selections won't give you that, I'm afraid
[01:36] <cjwatson> it should be somewhat helpful with the rest, but do look through it in conjunction with the installation guide as it probably won't be appropriate exactly as-is
[01:36] <Elwell> I'm looking at the exanple expert_recipie parts
[01:36] <Elwell> but they don't have an LVM example
[01:37] <cjwatson> I know LVM preseeding is possible, but I'm afraid I'm not an expert on it yet
[01:37] <Elwell> :-) yeah - 'twas I who poked bigkevmcd earlier
[01:38] <cjwatson> there is some mention of lvm in the partman-auto-recipe.txt document
[01:38] <Elwell> I promise to write this up if I get it working
[01:38] <cjwatson> ah
[01:38] <cjwatson> yeah, I'm going to need to become an expert in order to get Kickstart going for it
[01:39] <Elwell> [background - was going to install 25 machines with Scientific Linux 5 (RHEL5 clone) then discovered that the bundled firefox is still <IP_ADDRESS>.
[01:39] <Elwell> so decided to go ubuntu as per my laptop]
[03:24] <blackskad> hi all
[03:24] <blackskad> cjwatson: I attached a patch to bug #45690, however it's not conform to the hig
[03:24] <blackskad> what would you propose so it conforms to the hig?
[03:26] <cjwatson> blackskad: would be better to have non-stock text and translate that in the same way we translate stuff like "Continue using the live CD" and "Restart now" (via debian/ubiquity.templates and special widget names that ubiquity knows to go and translate)
[03:28] <blackskad> cjwatson: ok, and what text would you use? I would use something as "continue" and "abort"
[03:30] <cjwatson> it's possibly worth noting that OOo uses save/discard/cancel and gedit uses close without saving / cancel / save as
[03:31] <cjwatson> so cancel doesn't *seem* to be forbidden there ..
[03:31] <cjwatson> but anyway, strings like "Continue installing" and "Abort the installation" sound like they'd work
[03:32] <cjwatson> or maybe
[03:32] <cjwatson> "Do you really want to abort the installation now, or would you like to continue?"
[03:32] <cjwatson> "Continue" "Abort"
[03:33] <cjwatson> (current dialog text is "Do you really want to abort the installation now?")
[03:33] <cjwatson> I like reusing the verbs from the text
[03:33] <cjwatson> only trick is to make sure the translators are aware of that, but that can be done with comments
[03:34] <blackskad> cancel sounds fine if the other choices are well defined, so that the meaning of cancel is clear too, which is not realy the case
[03:34] <cjwatson> maybe "... or would you like to continue installing?"
[03:34] <cjwatson> mm, abort and cancel are too similar in meaning for that to be clear I think
[03:34] <cjwatson> so I think abort and continue are fair enough
[03:35] <blackskad> yes, those continue and abort should do fine
[03:35] <blackskad> I'll try to make up a patch
[03:36] <blackskad> it might take a while though :)
[03:37] <cjwatson> grep for the ids of other widgets that are translated and it should help to understand how it works
[03:37] <cjwatson> these should be one of the widgets that are translated immediately when you select a language on the language page (before hitting next)
[03:40] <blackskad> ok, I'll try to figure it out
[03:40] <blackskad> can I ping you when I encounter a problem?
[03:44] <cjwatson> sure
[04:55] <mark> grr, dovecot in feisty is rather broken
[10:58] (cjwatson/#ubuntu-installer) one problem is that outside the installer what you want is for the LVM to be activated immediately
[10:59] (cjwatson/#ubuntu-installer) but inside the installer, that's not entirely obviously the case - I wanted to think about whether that would cause problems for the partitioner
[11:02] <Elwell> in my case I want to blow the HDD's completely and start afresh
[11:02] <Elwell> (preinstalled Dell XP stuff...)
[11:03] <Elwell> The reason for the delay is I'm rebuilding the same box over and over till I get the kickstart/preseed working
[11:03] <Elwell> so get bitten by the timeout
[11:04] <Elwell> tempted to see if I can do something like pxeboot into a "mini setup" system to get things laid out, then reboot into the ubuntu install
[11:05] <cjwatson> ok, check with Keybuk then
[11:05] <cjwatson> he's usually around UK business hours, or mail him
[11:05] <Elwell> ta. I suspect I'll still be working on this tomorrow
[11:16] <Elwell> OK - http://www.debian.org/releases/etch/amd64/apb.html.en -- has the ubuntu installer diverged wildly from the debian one?
[11:21] <cjwatson> Elwell: not *wildly*, but a bit; try https://help.ubuntu.com/7.04/installation-guide/i386/appendix-preseed.html
[11:24] <Elwell> ta. what package is the source for that - still "debian-installer"?
[11:46] <mirkobuholzer> where can I find a list of answers to run ubiquity with the <noui>?
[11:50] <superm1> cjwatson, were there any other rough edges you wanted me to look into before I attempted to cleanly add our files as deriving from your files' as base classes?


 Don't tell me to tell you why, just tell me how to do it"
[15:24] <oerheks> leftyfb, do visitors expect us to ask: what is your weird bug?
[15:44] <daftykins> :)
[17:08] <lotuspsychje> good evening to all
[17:08] <oerheks> heya lotuspsychje
[17:09] <oerheks> lotuspsychje, ducasse and me want you!
[17:09] <lotuspsychje> hey hey oerheks how are you
[17:09]  * oerheks firing up telegram
[17:09] <oerheks> You do have telegram don't you?
[17:09] <lotuspsychje> what you need from lotus :p
[17:09] <lotuspsychje> yeah on smartphone
[17:10] <oerheks> good, we want to know how it works
[17:10] <ducasse> hi lotus
[17:10] <ducasse> do you like it?
[17:10] <lotuspsychje> its simple, you need to add your cellphone number to it and first time get your code
[17:11] <lotuspsychje> to activate your telegram account (cellnumber)
[17:11] <lotuspsychje> hey ducase
[17:11] <lotuspsychje> then you can add your friends cellnumbers to it and chat
[17:12] <lotuspsychje> there is also a telegram snap on ubuntu desktop
[17:13] <lotuspsychje> !info telegram-sergiusens
[17:13] <lotuspsychje> snap find telegram
[17:13] <ducasse> i was hoping you didn't need to add phone numbers for contacts, that the account name or something would be enough
[17:14] <lotuspsychje> the #ubports group got a large telegram group also
[17:14] <lotuspsychje> ducasse: there is a way to add a nick aswell, check telegrams website, didnt do it that way yet
[17:14] <oerheks> sudo snap install  telegram-sergiusens
[17:14] <lotuspsychje> yep
[17:16] <lotuspsychje> ducasse: https://telegram.org/faq#q-what-are-usernames-how-do-i-get-one
[17:16] <lotuspsychje> but i pretty like the cell method
[17:18] <ducasse> bloody 'h' key sticks, just a sec
[17:18] <lotuspsychje> lol
[17:18]  * lotuspsychje gets a hammer ready
[17:18] <ducasse> there - compressed air ftw :)
[17:19] <ducasse> woke up the cat, though :)
[17:23] <lotuspsychje> :p
[17:25] <ducasse> lotuspsychje: didn't have time to wish you a good day at work this morning, you went so quick: "that'siti'mgoingtowork, *lotuspsychje has quit*" ;)
[17:25] <lotuspsychje> haha
[17:25] <lotuspsychje> yeah we always miss each other
[17:25] <lotuspsychje> time you wakeup im at breakfast then off to work
[17:25] <ducasse> just a couple more weeks now?
[17:25] <lotuspsychje> yeah it will change soon!
[17:26] <lotuspsychje> 2 oct!
[17:27] <ducasse> sounds good
[17:27] <lotuspsychje> will be good indeed
[17:28] <lotuspsychje> ducasse: the 9y old kid of my new boss slept at his friends house and they went sneaky to theaters watch the new 'IT' lol
[17:28] <lotuspsychje> that boy didnt sleep well that night
[17:30] <ducasse> lol
[17:31] <ducasse> turn up in a clown mask and knock on his window late tonight ;)
[17:31] <lotuspsychje_> lol
[17:34] <lotuspsychje> ducasse: so i might go look it with my gf :p
[17:34] <ducasse> tell me what you think
[17:34] <lotuspsychje> well if we cant go to dark tower
[17:35] <lotuspsychje> gf said, if ducasse doesnt like it, why pay money to go see
[17:35] <lotuspsychje> we can always 'hire' the dvd later
[17:37] <ducasse> smart girl ;) i might not be the best person to listen to about that movie, though, as i love the books so much. idris elba was fantastic though, i just thought the whole movie was a bit 'cheap' and chaotic.
[17:38] <lotuspsychje> i dont like cheap
[17:38] <lotuspsychje> espacially in theaters
[17:39] <ducasse> it was as if they had just thrown in everything and the kitchen sink without worrying about making a good story. the books make up a really good story.
[17:40] <lotuspsychje> usually stephen king movies are also longer in time
[17:44] <ducasse> very often, the original it was ~4 hours
[17:45] <lotuspsychje> now its gonna be in 2 parts right?
[17:45] <ducasse> no idea, but i didn't think so?
[17:46] <nacc> which? it?
[17:46] <lotuspsychje> i think it is, and film maker needs it to earn much to make part2
[17:46] <lotuspsychje> nacc: the new IT remake
[17:46] <nacc> It is a two-parter -- first is a prequel
[17:47] <nacc> well, 'prequel'
[17:47] <nacc> the original story (of the kids)
[17:47] <nacc> the second one is more of the remake of the original
[17:48] <lotuspsychje> cool
[20:11] <lotuspsychje> bbl guys sleep night :p
[20:11] <oerheks> nighty night lotus


[16:29] <jackweirdy> What's the preferred way to test juju deployments on a mac? Anyone deploy to Devstack within vagrant, or is something else better?
[18:08] <aisrael> jackweirdy: I typically do it all through Vagrant - https://jujucharms.com/docs/stable/howto-vagrant-workflow
[18:09] <aisrael> I use it for all of my initial dev/testing, and switch over to a public cloud as needed (like for big/complex bundles)