[06:13] <highvoltage> stgraber: nice!
[16:15] <reactor> Oh hi.
[16:15] <reactor> Is there a way to figure out the repositories server without downloading the image?
[16:36] <reactor> Alright then.


[00:03] <manjiri> Hello. I am running into bug https://bugs.launchpad.net/charms/+source/postgresql/+bug/1239681 which appears to have been fixed by sinzui. How can I get that fix?
[00:03] <_mup_> Bug #1239681: relation-get failing with 'permission denied' <regression> <juju-core:Triaged> <postgresql (Juju Charms Collection):Triaged> <https://launchpad.net/bugs/1239681>
[00:05] <marcoceppi_> manjiri: what version of juju are you using?
[00:07] <manjiri> marcoceppi_: ii  juju-core                                    1.16.6-0ubuntu1~ubuntu12.04.1~juju1              Juju is devops distilled - client
[00:10] <marcoceppi_> manjiri: also, it doesn't say it's been fixed, merely triaged for 1.18
[00:11] <manjiri> I think I recently upgraded juju-core. Do you recommend that I down-grade? To which?
[00:14] <hazmat> manjiri, can you reliably reproduce that?
[00:15] <hazmat> manjiri, are you running into that  with the postgresql charm?
[00:16] <manjiri> hazmat: I am not running postresql charm. I am developing my own (set of) charms for deploying Contrail software. I think the symptoms are the same.
[00:17] <hazmat> manjiri, namely that relation-get tosses an error?
[00:17] <manjiri> hazmat: yes. that is correct.
[00:18] <manjiri> hazmat: as to whether I can reproduce the problem - I am seeing it now. I was thinking of rebooting the machine in the hope that the problem would go away.
[00:18] <hazmat> manjiri, could you send the log for the unit in /var/log/juju/
[00:18] <hazmat> i'll try reproducing w/ the postgres charm | unit test
[00:19] <hazmat> i'm on 1.17/trunk though
[00:19] <manjiri> hazmat: I am new to IRC. When you say "send" the log - what do you mean?
[00:20] <hazmat> manjiri, typically pastebin.ubuntu.com if its not sensitive
[00:20] <sarnold> (the pastebinit tool is awesome for this)
[00:20] <hazmat> manjiri, welcome to irc btw.. also there's a command line client
[00:20] <hazmat> sudo apt-get install pastebinit
[00:21] <hazmat> you can point it to a file as a param or pipe data into the pastebinit cli
[00:22] <marcoceppi> hazmat: --wait in deployer just subscribes to the event stream from the API, right? It doesn't actually do proper "wait for 'idle' environment", does it?
[00:22] <hazmat> marcoceppi, the latter doesn't exist
[00:22] <hazmat> atm
[00:22] <hazmat> marcoceppi, yes.. its event stream wait and configurable timeout
[00:22] <marcoceppi> hazmat: didn't think so, that's why I got kind of excited when I saw the option
[00:22] <hazmat> marcoceppi, and stop/shortcircuit on error
[00:23] <hazmat> rephrasing its wait for x seconds without error post action
[00:23] <manjiri> hazmat: Please check out http://pastebin.ubuntu.com/6991890/
[00:24] <hazmat> manjiri, are you changing users in your charm?
[00:25] <hazmat> manjiri, the juju cli commands use a  unix socket owned by root. changing user would be the most likely cause.
[00:26] <manjiri> hazmat: no change in user
[00:27] <manjiri> hazmat: to which cli commands are you referring?
[00:27] <hazmat> manjiri, ok
[00:27] <hazmat> manjiri, all the commands used to interact with juju from a hook (relation-ids, relation-list, relation-get, relation-set, config-get, open-port, close-port, etc)
[00:28] <manjiri> hazmat: got it. to reconfirm, my charm does everything as 'root'
[00:34] <manjiri> hazmat: do you have a recommendation? Downgrade juju-core?
[00:37] <hazmat> manjiri, not atm
[00:37] <hazmat> still trying to understand root cause, but past eod, so intermixing other things
[00:39] <hazmat> manjiri, 1.14 is very old.. not recommened
[00:40] <manjiri> hazmat: I have 1.16.6-0ubuntu1~ubuntu12.04.1~juju1
[00:40] <hazmat> understood
[00:40] <hazmat> manjiri, is your charm opensource?
[00:40] <hazmat> if so where can i find it..
[00:40] <manjiri> hazmat: not yet
[00:40] <hazmat> currently trying to run the postgresql charm unit tests per the bug report
[00:41] <manjiri> hazmat: I can provide code snippet if you think that it will help
[00:44] <hazmat> manjiri, that would be helpful
[00:46] <manjiri> hazmat: Is it OK if I email it to you?
[00:46] <hazmat> manjiri, sure
[00:47] <manjiri> hazmat: Give me a few minutes
[00:47] <hazmat> manjiri, np
[00:48] <hazmat> stub, ping.. how do you run these postgresql charm tests
[01:29] <manjiri> hazmat: Sorry that took so long, but I have sent you the information in an email. I will reboot the machine to see if I can continue to make progress without being hit by this bug
[01:33] <hazmat> manjiri, got it.. i'll have to look at in the morning its late here.. and i'm done for the night
[04:54] <stub> hazmat: Bootstrap an environment, then 'make test'. tests/00_setup lists packages that might be needed
[04:54] <stub> hazmat: it has been a while since I tried anything but the local provider
[10:08] <hazmat> stub, thanks
[10:09] <hazmat> stub, i use a variation a manual provider variation on local provider with lxc btrfs snapshots.. should be about the same.
[10:11] <hazmat> stub, you still have that failing test per the bug report .. http://pad.lv/1239681
[10:11] <hazmat> ?
[18:41] <danob> i installed LXC container in my ubuntu desktop and when i start my desktop or restart my desktop, why i need to run a2ensite default everytime inside apache2/0 unit???
[18:51] <marcoceppi> danob: you shouldn't are you setting a vhost template?
[19:02] <chris38home> hi, I'm trying local provider with fresh checkout and juju add-machine lxc:0 stays in pending mod, is there any prerequisite to install ?
[19:09] <marcoceppi> chris38home: uh, I don't think you can LXC on LXC
[19:12] <sarnold> you can do nested lxc: https://www.stgraber.org/2013/12/21/lxc-1-0-advanced-container-usage/
[19:12] <chris38home> ok then juju add-machine should create a new lxc container ?
[19:12] <sarnold> no idea how well juju will handle it though :)
[19:13] <chris38home> non nested is also pending
[19:18] <marcoceppi> chris38home: well, non-nested needs to be instarted before nested can work
[19:18] <marcoceppi> chris38home: can you show your juju status in a pastebin?
[19:28] <chris38home> marcoceppi,  http://pastebin.com/AB8HDfZS
[19:43] <chris38home> maybe I have a problem with routing : cannot load index "http://<IP_ADDRESS>:8040/tools/streams/v1/index.sjson"
[20:21] <jcastro_> is this bucket thing still a thing? http://askubuntu.com/questions/425745/maas-juju-bootstrap-404
[20:21] <jcastro_> I haven't seen that one in a while
[20:52] <Lord_Set> Hello everyone
[20:52] <marcoceppi> o/ Lord_Set
[20:55] <Lord_Set> How is the world of Juju going?
[21:05] <marcoceppi> Lord_Set: really well, imo
[21:06] <Lord_Set> Glad to hear it. I am really enjoying using it as an app deployment platform. I am doing a pretty good sized test today with it.
[21:08] <Lord_Set> Going to be using MAAS and Juju to deploy a rack of 35 servers with Openstack and then a second rack of 20 servers to build a Hadoop Cluster. Also going to doing some multi-cluster controller between different sites tests. The locations are connected via VPN tunnels.
[21:08] <Lord_Set> We are upgrading to 100mbps burstable to 1gbps fiber soon between locations.
[21:08] <marcoceppi> Lord_Set: Sweet! Let us know if we can help in any way
[21:10] <Lord_Set> I will for sure. I got an email from Dustin Kirkland this morning saying he wanted to discuss what my team is doing with MAAS, Juju and Ubuntu. Was after a good and long conversation with Julian Edwards of the MAAS tema.
[21:10] <Lord_Set> err team
[21:12] <jcastro_> Lord_Set, this is awesome, let us know how it goes for you
[21:13] <jcastro_> marcoceppi, I hate to sound like a raving nut, but putting the docs on github makes things so easy now with the inline editing.
[21:13] <marcoceppi> jcastro_: you sound like a raving nut ;)
[21:14] <Lord_Set> I will
[21:14] <jcastro_> Apache Syncope charm incoming to the queue!
[21:15] <Lord_Set> I am hoping with this tech startup I am working with to form an awesome partnership with the MAAS and Juju teams. We have a lot of resources and big plans for deployment with 2 different tech startup companies we are moving forward with.
[21:16] <Lord_Set> Currently 4 geographical sites with a total of 12 racks currently. 2 of which are at Switch SuperNAP in Vegas
[21:16] <jcastro_> negronjl, I kind of need bug 1267222 fixed, could you possibly update it with what needs to be done and I can ask someone else to fix it?
[21:16] <_mup_> Bug #1267222: Race condition when deploying a simple replica set <audit> <mongodb (Juju Charms Collection):New for negronjl> <https://launchpad.net/bugs/1267222>
[21:17] <negronjl> jcastro_, sorry about that ... I'll update today
[21:17] <marcoceppi> jcastro_: didn't lazyPower fix that ?
[21:18] <jcastro_> I dunno, did he?
[21:18]  * marcoceppi waits for lazyPower
[21:19] <lazyPower> Nope, i fixed a race condition in mediawiki, and pointed it out back in the day
[21:19] <lazyPower> but have not applied any patches to mongodb charm
[21:37] <jcastro_> lazyPower, marcoceppi, mbruzek: hey when you guys get time can you go through and vote in the juju tag?
[21:37] <lazyPower> negronjl: I do however have tests in amulet to assert that it works - i think you already patched it.
[21:37] <jcastro_> dimiter is answering a ton but not really getting any upvotes
[21:38] <lazyPower> negronjl: latest bzr branch is lp:~lazypower/charms/precise/mongodb/ci-fix
[23:16] <jcastro_> mbruzek, marcoceppi: heya, looks like wildfly is ready to go
[23:16] <jcastro_> what do you say about some promulgation?
[23:17] <marcoceppi> jcastro_: needs a finaly review, but otherwise, sure
[23:17] <mbruzek> Yeah it needs to be reviewed by a charmer.
[23:17] <mbruzek> Marco let me know if you have any questions or find anything that I did not.


[03:31] <sergiusens> elopio: rollback fails for you, right?
[03:33] <rsalveti> sergiusens: fails for me as well
[03:33] <rsalveti> sergiusens: check https://bugs.launchpad.net/snappy/+bug/1474126
[03:33] <sergiusens> rsalveti: I have this fix I've been trying to test for a while now :-/
[03:34] <sergiusens> rsalveti: first a bad sdcard with fully corrupted content, now this...
[03:34] <rsalveti> right, this corruption issue seems to be quite normal
[03:34] <sergiusens> rsalveti: oh, and not sure I ever noticed, but it doesn't look like vfat
[03:34] <rsalveti> seems at the moment we call fsck for the vfat partition things break
[03:34] <sergiusens> rsalveti: HARDWA~1.YAM
[03:35] <rsalveti> sergiusens: that is vfat
[03:35] <sergiusens> yeah
[03:35] <sergiusens> rsalveti: don't we get long file names?
[03:36] <rsalveti> that's an extension
[03:36] <rsalveti> it seems fsck changed it
[03:36] <rsalveti> it is supported by the original flash
[03:36] <rsalveti> all good and so on, but at the time it runs fsck, boom
[03:37] <rsalveti> the time it worked fine I had a FSCK... file in the partition
[03:37] <rsalveti> FSCK0000.REC
[03:37] <rsalveti> when it failed I didn't get this file, but the content changed
[03:38] <rsalveti> not sure yet when we call fsck
[03:38] <sergiusens> rsalveti: fsck is part of our new init?
[03:38] <rsalveti> doesn't look like it
[03:38] <rsalveti> maybe part of the boot process, done by systemd, not sure
[03:40] <rsalveti> going to bed now, we can check tomorrow
[03:40] <sergiusens> rsalveti: ok, then you don't get to test my fix
[03:40] <sergiusens> :-P
[03:40] <sergiusens> until tomorrow
[03:40] <rsalveti> right :-)
[03:40] <sergiusens> rsalveti: smart in using the dup files btw ;-)
[03:40] <rsalveti> propose it anyway
[03:41] <rsalveti> great
[03:41] <sergiusens> rsalveti: I will, as soon as I can do some street testing
[03:41] <rsalveti> alright, later man, have a good night
[03:42] <sergiusens> good night
[07:02] <fgimenez> good morning
[07:12] <dholbach> good morning
[08:55] <ogra_> yippie !!!
[08:55] <ogra_> https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/wily/ubuntu-core-system-image/+build/32370
[08:55] <ogra_> we has arm64 images :)
[09:05] <tbr> ogra_: oh. does that mean I'll be able to try something on the dragonborad?
[09:06] <ogra_> tbr, well, no idea if it boots or how our bootloader setup on arm64 is at all
[09:06] <tbr> (yes, I'm able to bring my own hw-adaptation. Just rebuilt the kernel to get usb-networking)
[09:07] <tbr> the state of bootloaders on aargh64 is 'special'.
[09:07] <ogra_> at least all packages build and enable rolling a rootfs, not sure i can say more about these images :)
[09:07] <JamesTait> Good morning all; happy Pandemonium Day! ð
[09:08] <ogra_> uuuuuh
[09:08] <tbr> that's fine. I might give it a go, but will probably have some questions
[09:08]  * tbr wishes JamesTait a merry Setting Orange
[09:09]  * JamesTait sets his orange on the desk, to eat later.
[10:53] <Chipaca>             sourceFiles |= set([os.path.join(root, d) for d in dirs])
[10:53] <Chipaca> mterry:
[10:53] <Chipaca> oh, no mterry
[11:54] <rsalveti> morning
[11:54] <Chipaca> mo'in
[12:20] <rsalveti> ogra_: mvo: did you guys had time to check the email sergiusens sent yesterday?
[12:20] <rsalveti> about bug 1474126
[12:37] <mvo> rsalveti: not yet, sorry, let me do that now. I was absorbed in snapcraft stuff, mterry has too many good ideas :)
[12:37]  * mvo looks now
[12:37] <rsalveti> mvo: haha, no worries :-)
[12:38] <ogra_> hmm
[12:38]  * ogra_ didnt notice a mail
[12:38] <ogra_> checking again
[12:38] <rsalveti> ogra_: it seems sergiusens forgot to include you
[12:38] <rsalveti> but was basically about this bug ^
[12:39] <rsalveti> he created https://code.launchpad.net/~sergiusens/snappy/noUselessUpdate/+merge/264665 to fix 1474125
[12:39] <rsalveti> but we can't test it easily because of bug 1474126
[12:39] <ogra_> right, i saw that
[12:40] <ogra_> so as i commented on the bug, it could well be that fatwrite messes up the filesystem
[12:40]  * ogra_ doesnt really trust it
[12:40] <ogra_> still so new and rarely used anywhere
[12:44] <rsalveti> ogra_: yeah, looks like it
[12:44] <rsalveti> ogra_: I did the update, then decided to run fsck.vfat and it was all good
[12:44] <rsalveti> but once I rebooted, boom
[12:44] <ogra_> i wonder if it is something simple ... like fatwrite not being aboe to truncate files ...
[12:45] <ogra_> so you would have to delete them first
[12:45] <ogra_> i didnt really find many bugs though ... i guess it is really rarely used
[12:45] <rsalveti> ogra_: mvo: one other question I had, why do we keep /boot/uboot mounted all the time?
[12:45] <ogra_> we shouldnt (i dont know why, ask jodh ? )
[12:46] <mvo> rsalveti: I don't think there is a good reason
[12:46] <ogra_> also, why dont we sync mount it ?
[12:46] <mvo> I think we do that, no?
[12:46]  * ogra_ doesnt see a sync option
[12:46] <mvo> the sync mount I mean
[12:46] <rsalveti> /dev/mmcblk0p1 on /boot/uboot type vfat (rw,relatime,sync,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
[12:46] <rsalveti> we do use the sync option
[12:46] <ogra_> hmm
[12:46] <mvo> ogra_: outdated initrd ;) ?
[12:46] <rsalveti> let me remove the fatwrite piece and check again
[12:47] <ogra_> (RaspberryPi2)ubuntu@localhost:~$ mount|grep boot
[12:47] <ogra_> /dev/mmcblk0p1 on /boot/uboot type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)
[12:47] <ogra_> weird
[12:47] <rsalveti> it seems that makes fsck.vfat unhappy and then it changes the fs
[12:47] <ogra_> shouldnt be to outdated
[12:47] <rsalveti> I was on image 4 (bbb)
[12:48] <ogra_> (15.04 stable image 3 though)
[12:48] <ogra_> but i thought that should have sync set
[12:50] <mvo> ogra_: yeah, we set to sync a good while ago, in the 15.04 timeframe
[12:50] <mvo> odd
[12:50] <ogra_> right
[12:50] <ogra_> i use the initrd from cdimage with removed modules
[12:50] <ogra_> nothing else changed
[12:51] <ogra_> rsalveti, are our tools able to remount /boot rw before operating on it ?
[12:52] <ogra_> just switching it to ro might be a bit dangerous if they dont :)
[12:53] <rsalveti> /boot/uboot is always rw
[12:54] <ogra_> yes, it shouldnt
[12:54] <ogra_> but if we make it ro, can the tools deal with it ?
[12:55] <ogra_> hmm
[12:55] <ogra_>                 else
[12:55] <ogra_>                         bootdir="$ubootdir"
[12:55] <ogra_>                         echo "$boot_partition $bootdir auto sync 0 2" >> "$fstab"
[12:55] <ogra_>                 f
[12:55] <rsalveti> I'd expect it to only be mounted when needed, since it's a vfat partition
[12:55] <ogra_> so that is what it is supposed to write to fstab
[12:55] <rsalveti> yup
[12:55] <ogra_> (RaspberryPi2)ubuntu@localhost:~$ grep uboot /etc/fstab
[12:55] <ogra_> /dev/mmcblk0p1 /boot/uboot auto defaults 0 0
[12:55] <ogra_> and that is what my fstab has
[12:56] <rsalveti> /dev/mmcblk0p1 /boot/uboot auto sync 0 2
[12:56] <rsalveti> bbb, image 3
[12:56] <ogra_> rpi image 3
[12:56] <ogra_> how weird
[12:59] <ogra_> i wonder if systemd re-writes the fstab entry somehow
[12:59] <ogra_> i dont see any explanation in the code why it would be "auto default"
[13:21] <rsalveti> mvo: oh, and https://code.launchpad.net/~sergiusens/snappy/noUselessUpdate/+merge/264665 reminds me that we need to prioritize the work to update the upgrader before doing the upgrade
[13:21] <tedg> Morning folks
[13:21] <rsalveti> not super urgent, but would be good for us to put some hands on it later this month
[13:21] <tedg> Chipaca, Were you able to get a libxcbcommon patch working?
[13:21] <Chipaca> tedg: i'm not sure, right now
[13:22] <Chipaca> um
[13:22] <Chipaca> read: i have a working patch
[13:22] <Chipaca> but i'm not sure the patch works
[13:22] <Chipaca> is that clearer? i'm not sure :)
[13:22] <tedg> Hmm, how do you know it's a working patch then? :-)
[13:23] <mvo> rsalveti: indeed
[13:24] <mvo> tedg: it builds, so we shipped it.
[13:24] <tedg> \o/
[13:26] <Chipaca> tedg: and the not sure is because http://pastebin.ubuntu.com/11877692/
[13:27] <sergiusens> morning
[13:28] <tedg> Chipaca, There seems to be reads from /home/ubuntu/thing/lib and /apps/qmlapp.sideload/0/usr/lib, seems there should only be one of those?
[13:28] <rsalveti> sergiusens: morning :-)
[13:29] <Chipaca> tedg: it is one, there's a symlink but i'll unify so it melts minds less
[13:30] <tedg> If you're running confined, symlinks don't help.
[13:30] <Chipaca> not running confined
[13:31] <rsalveti> sergiusens: ogra_: mvo: yeah, if I remove the fatwrite command it all works fine
[13:32] <mvo> hey sergiusens, good morning
[13:32] <Chipaca> tedg: http://pastebin.ubuntu.com/11877734/
[13:35] <mvo> Chipaca: hm, that looks like progress compared to yesterday, no?
[13:35] <Chipaca> tedg: oh, wait, that one is using the wrong socket
[13:35] <tedg> Chipaca, Ah, so to the next step :-)  Looks like it can't find the Mir socket. Probably not running as user 1000
[13:35] <Chipaca> tedg: with the right socket: http://pastebin.ubuntu.com/11877746/
[13:35] <tedg> Yeah, need to set MIR_SOCKET probably.
[13:35] <ogra_> rsalveti, well, how do you switch ? by manually editing the file ?
[13:35] <Chipaca> yeh, i'd commented it out, because with that it finds it but still can't connect (?)
[13:36] <Chipaca> but it gets further ahead with it, so
[13:36] <Chipaca> permission denied
[13:36] <Chipaca> dammit
[13:36] <Chipaca> http://pastebin.ubuntu.com/11877751/
[13:36] <Chipaca> ^ with the right perms, and the right socket
[13:37] <tedg> What Mir server are we using? Demo Server? System compositor?
[13:37] <Chipaca> demo server
[13:37] <Chipaca> which is what is in the mir package
[13:38] <tedg> K, I don't think that it requires notification that we're going to connect. I think it stubs out the auth parts.
[13:38] <Chipaca> tedg: the permission denied was on the socket itself
[13:38] <Chipaca> tedg: but i don't know if you're talking about that :)
[13:39] <tedg> Kinda both :-)
[13:39] <tedg> Mir also does it's own auth depending on the server.
[13:39] <Chipaca> ah, ok
[13:39] <tedg> There are some MIR debugging environment variables, let me try to find them.
[13:40] <Chipaca> the mir wrapper does take care of the socket and its permissions, but i'm running it directly myself to have the console output
[13:40] <tedg> Well, you can get the console output from systemd
[13:42] <Chipaca> i know i should be able to, but couldn't find it in journalctl
[13:42] <tedg> Oh, my Mir branch was only 200K objects out of date...
[13:43] <ogra_> rsalveti, so i'd really like to get rid of using fatwrite, i wonder if we could ship a uboot.env file wih a binary environment instead ... only containing the a/b variable, that way we can just run saveenv to switch it (if anything reads the snappy_stamp.txt file from userspace we need to handle that separately though)
[13:44] <tedg> Chipaca, I think this is the useful variable: MIR_CLIENT_RPC_REPORT=log
[13:44] <Chipaca> tedg: in the environ of the server, client, both?
[13:45] <tedg> Chipaca, Client, though sever can also be used if we're confused still :-)
[13:45] <tedg> Chipaca, Here is what I wrote down: MIR_SERVER_{DISPLAY_REPORT,COMPOSITOR_REPORT,CONNECTOR_REPORT,MSG_PROCESSOR_REPORT,SESSION_MEDIATOR_REPORT}=log
[13:45] <mvo> sergiusens: thanks for your branch, I'm trying to reproduce this now
[13:45] <Chipaca> oh yeah baby
[13:46] <Chipaca> tedg: http://pastebin.ubuntu.com/11877784/
[13:46] <mvo> rsalveti: is there anything unusual about your sd card? particularly big maybe?
[13:47] <tedg> Chipaca, Huh, perhaps look at the server?
[13:47] <Chipaca> tedg: that was on the server, fwiw
[13:47] <tedg> Otherwise we're gonna need #ubuntu-mir's help
[13:47] <tedg> Oh, try on the client.
[13:48] <Chipaca> tedg: i get no extra input from the client with those, nor with MIR_CLIENT_ of same
[13:53] <Chipaca> tedg: i've got to run, will read when i return
[13:53] <tedg> Chipaca, K, I'll ping some central time folks when they log in as well.
[13:53] <Chipaca> ta
[13:54] <Chipaca> and i'll get the different bits and bobs up when i return, also, so others can reproduce
[13:55] <sergiusens> mvo: np
[13:59] <ogra_> pitti, could anything in systemd touch/modify fstab during boot ?
[14:00]  * ogra_ really doesnt get how the /boot/uboot entry can end up differently in fstab than what was echoed into it
[14:00] <pitti> ogra_: read for sure; changing, I'm not aware of anything
[14:01] <ogra_> i have this code ... echo "$boot_partition $bootdir auto sync 0 2" >> "$fstab"
[14:01] <ogra_> and end up with:
[14:01] <ogra_> (RaspberryPi2)ubuntu@localhost:~$ grep boot /etc/fstab
[14:01] <ogra_> /dev/mmcblk0p1 /boot/uboot auto defaults 0 0
[14:02] <ogra_> i dont get how that can happen
[14:02] <pitti> so that's not system-image writing fstab from a template and writable-paths or so?
[14:02] <pitti> and is /etc/fstab writable in the first place?
[14:02] <ogra_> no, it is the initrd script checking for uboot and then echoing this line into fstab
[14:03] <pitti> so /etc/fstab is a symlink to /etc/writable/fstab or so?
[14:03] <ogra_> to my knowledge thats the only place we handle /boot/uboot
[14:03] <ogra_> fstab is a bindmount
[14:03] <ogra_> into /run/image.fstab
[14:04] <pitti> so perhaps your echo happens before the bind mount?
[14:04] <ogra_> http://paste.ubuntu.com/11877845/
[14:04] <ogra_> thats the code snippet
[14:04] <ogra_> (it happens afterwards)
[14:06] <ogra_> i dont see anything wrong with that code
[14:06] <pitti> what does handle_writable_paths() do?
[14:06] <pitti> it doesn't happen to assign fstab= to something else by chance?
[14:06] <ogra_> it loops over the writable paths file and echos the lines as proper fstab lines
[14:06] <ogra_> oh
[14:06]  * ogra_ checks for uboot in writable-paths
[14:07] <ogra_> (RaspberryPi2)ubuntu@localhost:~$ grep boot /etc/system-image/writable-paths
[14:07] <ogra_> (RaspberryPi2)ubuntu@localhost:~$
[14:07] <ogra_> nope
[14:09] <rsalveti> mvo: nothing unusual, no
[14:09] <rsalveti> ogra_: we got logic from our userspace to check for that stamp file
[14:09] <rsalveti> to then change the boot mode because it was successful
[14:09] <rsalveti> since it boots with "try" first
[14:10] <ogra_> rsalveti, right, so the uboot.env would have to add it to cmdline and the initrd would have to echo that into the stamp file
[14:10] <ogra_> so that uboot.env still stays the master and writin only happens from the kernel vfat driver
[14:10] <ogra_> and not from uboot
[14:11] <rsalveti> right, I guess that's a way
[14:11] <rsalveti> env + kernel cmdline + logic in initrd
[14:11] <ogra_> yeah
[14:11] <ogra_> just requires that all uboots we support can handle such an env
[14:12] <ogra_> at least for upgradeable devices
[14:12] <rsalveti> ogra_: are we shipping uboot with bbb?
[14:12] <rsalveti> or are we booting the uboot that is already flashed in the board?
[14:12] <ogra_> we are shipping a uboot.img
[14:12] <ogra_> (and SPL too i think)
[14:12] <rsalveti> that uboot is super old
[14:13] <ogra_> hmm
[14:13] <ogra_> i wonder if you guys actually boot the EMMc one
[14:13] <rsalveti> easy to check
[14:14] <rsalveti> ogra_: yeah, we're loading the spl and uboot that is already flashed in the emmc
[14:14] <mvo> ogra_: I like your idea
[14:14] <ogra_> aha !
[14:15] <rsalveti> because to boot from the sd card completely you have to hold the button while turning on the board
[14:15] <ogra_> rsalveti, so likely a different fatwrite then
[14:15] <rsalveti> U-Boot SPL 2014.10-dirty (Dec 18 2014 - 22:07:26)
[14:15] <ogra_> or wipe the MMC
[14:15] <rsalveti> U-Boot 2014.10-dirty (Dec 18 2014 - 22:07:26)
[14:15] <rsalveti> the one we ship
[14:15] <rsalveti> right
[14:15] <rsalveti> U-Boot SPL 2014.04-00015-gb4422bd (Apr 22 2014 - 13:24:29)
[14:15] <rsalveti> U-Boot 2014.04-00015-gb4422bd (Apr 22 2014 - 13:24:29)
[14:15] <rsalveti> the one we boot
[14:16] <ogra_> well, less dirty at least :P
[14:16] <ogra_> damn ...
[14:16] <ogra_> didnt zyga's patch land that was supposed to enforce that ?
[14:16] <rsalveti> ogra_: nops
[14:17] <rsalveti> since the only way to force our bootloader is by not having the original one or by pressing the button
[14:17] <ogra_> https://code.launchpad.net/~zyga/snappy-hub/fix-1464275/+merge/261833
[14:17] <mvo> hm, I did a fresh flash of my sd card some minutes ago and I have: "U-Boot 2014.10-dirty (Dec 18 2014 - 22:07:26)" in my boot message - but I did press the button in the past, will it remember that?
[14:17] <rsalveti> maybe you wiped out your emmc
[14:17] <ogra_> well, it is supposed to remember it
[14:18] <ogra_> but i have no clue how that works
[14:18] <mvo> both is likely
[14:18] <rsalveti> don't think it remembers it
[14:18] <mvo> ok
[14:18] <rsalveti> at the moment you unplug power and plug it again, it should try emmc first again
[14:18] <ogra_> so looking at zyga'S patch there ... it would still use the MMC uboot
[14:18] <ogra_> but enforce loading the SD
[14:19] <ogra_> so that wouldnt actualyl help
[14:19] <rsalveti> no, when you run that you're already in uboot
[14:19] <ogra_> right :/
[14:19]  * ogra_ sees no way around this except wiping the MMC on first boto or some such
[14:20] <ogra_> *boot
[14:20] <ogra_> ... not great :/
[14:20] <rsalveti> ogra_: or do your env dance suggestion you said
[14:21] <rsalveti> I'm checking now if our fatwrite is better
[14:21] <ogra_> well, will that help ? are we sure the bootx command behaves the same ... etc etc ?
[14:21] <ogra_> its not only fatwrite
[14:22] <ogra_> i ean, we can indeed use my suggestion to take fatwrite out of the equation ... but there are 6 months between the two uboots ... i would be surprised if we wouldnt hit other issues
[14:22] <ogra_> *mean
[14:24] <ogra_> (8 monts actually ... temporary math weakness :P )
[14:25] <mvo> sergiusens, rsalveti: hrm, so I tried to test 15.04a3 -> 15.04a4 -> 15.04a3 but when I rollback I get the following error http://paste.ubuntu.com/11877942/ on boot. this is new, right?
[14:25] <mvo> ogra_: -^
[14:26] <ogra_> mvo, no, thats exactly the issue we are diuscussing
[14:26] <ogra_> *discussing
[14:26] <mvo> ogra_: thats the corruption?
[14:26] <ogra_> fatwrite updates the file and trashes the vfat
[14:26] <mvo> ok, cool
[14:26] <ogra_> if the fatwrite from the older uboot is used
[14:26] <mvo> so  â¦ I get this with "U-Boot 2014.10-dirty (Dec 18 2014 - 22:07:26)
[14:26] <mvo> "
[14:27] <rsalveti> yeah, so that shows that our uboot is busted as well
[14:27] <mvo> I never see a different U-Boot boot string
[14:27] <ogra_> yeah
[14:27] <mvo> *weeeh*
[14:27] <rsalveti> and another interesting thing, my ethernet doesn't work with our uboot
[14:27] <rsalveti> it only works with the uboot provided by the board
[14:28] <rsalveti> got bbb rev c
[14:28] <ogra_> wow. thats weird
[14:29] <rsalveti> mvo: that's the issue that elopio had for quite a while
[14:29] <rsalveti> but that we were never able to find out why
[14:29] <sergiusens> mvo: that's the second bug
[14:29] <sergiusens> mvo: to test the fix for the first bug, resync the kernel and initrd from /boot ;-)
[14:30] <elopio> good morning.
[14:31] <mvo> sergiusens: :) just commented, I will look into adding a test now, but a cup of tea first :)
[14:31] <elopio> fgimenez: looking at your failures, for some reason systemctl status docker_docker-daemon_*.service prints nothing for you on the stdout.
[14:31] <elopio> I'll check what's going on.
[14:31] <elopio> fgimenez: lets skip our meeting today, unless you want to discuss about something.
[14:31] <mvo> sergiusens: honestly this fatwrite thing is really alarming to me shows that we really need some bbb auto testing
[14:32] <fgimenez> elopio, ok np, i'll check the output of systemctl
[14:34] <rsalveti> mvo: yeah
[14:34] <rsalveti> on the good side plars is getting that going soon :-)
[14:34] <rsalveti> but yeah, it's super bad
[14:36] <sergiusens> mvo: to be fair, this is an untested code path
[14:36] <ogra_> sergiusens, rolling back and upgradin is untested ?
[14:36] <rsalveti> guess the main problem is when we're changing kernel versions
[14:37] <elopio> fgimenez: I see, the *.service seems to work on 15.04 but not on rolling.
[14:37] <rsalveti> when updating/rolling back with the same kernel version I think that's mostly fine
[14:37] <rsalveti> but might still get broken I believe, and why elopio got it from time to time
[14:37] <sergiusens> ogra_: for new kernels, yes
[14:37] <ogra_> ah, it is our first new kernel ?
[14:37] <ogra_> k
[14:38] <fgimenez> elopio, yes, the output is from rolling/edge 107
[14:39] <sergiusens> ogra_: I don't think so, but channel changing for testing this are all flawed IMO (unless it is indeed a channel change test)
[14:39] <fgimenez> elopio, btw i have a branch for selecting the release, branch and revision for the tests almost done, will ping you when pushed
[14:40] <elopio> fgimenez: nice.
[14:40] <mvo> rsalveti: yeah, thats the good part, we have the tests and a plan and all that :)
[14:41] <mvo> and thats probably what the erle guys also experienced from time to time
[14:41] <ogra_> yeah
[14:42] <elopio> pitti: do you know why this works on systemd 219 but not on 222?
[14:42] <elopio> systemctl status docker_docker-daemon_*.service
[14:48] <pitti> elopio: not off the top of my head; what does "not work" mean?
[14:48] <elopio> pitti: on 219 it returs the status. On 222 it returns nothing.
[14:52] <pitti> elopio: indeed; mind filing a bug about this, so that we can track this? (busy with something else right now)
[14:52] <elopio> pitti: sure thing.
[14:52] <pitti> elopio: thanks; I'll bisect it
[14:53] <sergiusens> rsalveti: ogra_ if we revert the fix in uenv.txt, will we get something workable again (wrt fatwrite)?
[14:53] <ogra_> sergiusens, no
[14:53] <ogra_> that fix wont change anything
[14:54] <sergiusens> ogra_: why did this only start now?
[14:54] <ogra_> sergiusens, dunno, did we do this kind of test before ? (multiple updates and rollbacks)
[14:55] <sergiusens> ogra_: yes we have
[14:56] <sergiusens> ogra_: just the previous release was a 3 to 4 jump between releases
[14:56] <ogra_> probably it only happenms if the fat content changes between two fatwrites
[14:56] <ogra_> which now happens due to the kernel upgrade
[14:58] <ogra_> (i'm really just guessing here ... fact is that it doesnt break if fatwrite isnt used at all)
[14:59] <rsalveti> right, I believe it's because of the newer kernel
[15:00] <ogra_> do we know if the uboot fat driver can handle long filenames  ?
[15:00] <elopio> pitti: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1474426
[15:00] <ogra_> we also started using the longer filenames for the kernel
[15:00] <elopio> fgimenez: for now, I'll modify GetCurrentVersion to get a packageName.
[15:01] <ogra_> (thanks to the version)
[15:03] <pitti> elopio: thanks
[15:16] <plars> ogra_: rsalveti: sorry, just now catching up after I got off a call - yes this is what I was complaining about a long time ago when trying to get BBB to boot properly - that we just accidentally boot snappy on it because we have a working uboot on emmc, and that uboot could easily break on the sd card if you don't force it to boot from there
[15:17] <ogra_> plars, yeah, but there is no way for us to enforce SD ...
[15:17] <ogra_> unless we wipe it
[15:17] <ogra_> well, wipe the MMC
[15:17] <plars> ogra_: there is one other way
[15:18] <mvo> ohhhh?
[15:18] <ogra_> how ?
[15:18] <plars> ogra_: holding the s2 button down, or jumpering lcd_data02 I think, to gnd will do it
[15:18] <ogra_> right
[15:18] <plars> it forces booting from the sd (including bootloader)
[15:18] <ogra_> or solder a wire ...
[15:18] <plars> ogra_: well, a jumper wire is so much easier :)
[15:18] <ogra_> not realy a softwareish solution :)
[15:19] <ogra_> and we cant really destroy peoples MMC installs
[15:19] <plars> ogra_: so my current plans for instrumenting bbb include this, and use s2 along with a stable image on emmc to flash the sd, then force booting onto the sd
[15:19] <plars> ogra_: but if/when we get the recovery stuff, then we won't want to do that of course - and it becomes really critical that we don't break uboot
[15:20] <ogra_> yeah :(
[15:20] <plars> ogra_: but that makes me wonder, do we really need to change the bootloader that often? except maybe at the beginning?
[15:20] <plars> ogra_: once it stabilizes shouldn't we be able to mostly leave it alone?
[15:21] <ogra_> well, its not our bootloader that has issues ... it is the case where we boot the onboard one and use fatwrite from it
[15:21] <plars> if you are updating it only ever 12-16 months, it's much easier to be super careful and make sure we don't break it before landing the change
[15:21] <plars> ah
[15:22] <plars> ogra_: why is it calling fatwrite from the onboard one?
[15:22] <ogra_> the uboot scripts execute it to set the a or b partition in a file on the boot partition
[15:22] <plars> oh, right
[15:23] <plars> so this is just the nature of bbb, by default it tries to load the bootloader from emmc, unless you press the s2 button after poweron
[15:24] <beuno> FWIW, in both my bbb
[15:24] <beuno> I didn't need to press anything
[15:24] <beuno> it boots from the SD if it's there
[15:24] <plars> beuno: yeah, that's accidental and the source of the problem :)
[15:25] <beuno> plars, this is why I don't do hardware  :p
[15:25] <plars> beuno: I've been complaining about this for a while now, what's happening is that it's loading the bootloader off of your emmc
[15:26] <plars> but the bbb default image is set up to check if there's something it can load from the sd
[15:26] <elopio> pitti: other question, is there a way to wait for a service to be loaded and running?
[15:27] <pitti> elopio: another unit should just have After=foo.service
[15:27] <elopio> pitti: but not inside a unit. Like I install a package, and I want a command to wait until it's up before using it.
[15:28] <pitti> elopio: other than polling "systemctl is-active foo.service" I don't know; usually invoke-rc.d waits until it's up already
[15:28] <pitti> elopio: asking on #systemd (freenode) might be useful, perhaps I'm missing some kind of "wait-active"
[15:28] <elopio> pitti: ack, thanks.
[15:29] <elopio> is-active is already an improvement to what I have :)
[15:29] <pitti> elopio: other than that a while/is-active/sleep loop would work for now
[15:30] <pitti> elopio: that smells a bit weird -- you  have a package whose postinst auto-starts a service, but it's not up when apt-get finishes?
[15:30] <plars> ogra_: if there's a known fix for this uboot bug, I'm sure rcn-ee would be open to adding it in his images, then we could point people who are running the default image on emmc to update to that?
[15:30] <pitti> elopio: packages are expected to do that; i. e. that sounds like a bug in that .service, or in the package
[15:30] <elopio> pitti: well, on snaps we don't have post-inst.
[15:30] <ogra_> plars, well, the issue is to use fatwrite at all :P
[15:31] <plars> oh
[15:31] <ogra_> plars, i'm looking at a way to not use it at all
[15:31] <elopio> I'm not sure if we can make something to wait on install.
[15:31] <plars> ok
[15:31] <pitti> elopio: ah, ok
[15:31] <pitti> elopio: but what would start the shipped units then?
[15:31] <pitti> elopio: whatever that ^ is, if it does "systemctl start", that's also synchronous, i. e. waits until it's started
[15:32] <pitti> elopio: unless you call it with --no-block
[15:34] <elopio> pitti: hum, so maybe that works. I'm just following this comment that says:
[15:34] <elopio> "FIXME: sucks, needed because "systemctl start" does not wait until the service is really started."
[15:34] <elopio> maybe that's not true anymore.
[15:34] <pitti> that has never been true
[15:34] <pitti> it might be true that the .sevice's Exec* commands do not wait
[15:35] <pitti> i. e. do whatever you need to do to wait until the started service is up
[15:35] <pitti> but then the polling loop doesn't help you either
[15:35] <pitti> or it specifies a wrong Type= (simple instead of forking, etc.)
[15:36] <elopio> pitti: I see. Oh, but here's another case where we do need to wait:
[15:36] <elopio> if ssh starts before the service starts, then the test might run before the service is running.
[15:37] <pitti> elopio: ah, this might be something to fix in autopkgtest
[15:37] <pitti> elopio: i. e. not start before systemctl list-jobs becomes empty
[15:38] <elopio> pitti: oh, I like that.
[15:38] <plars> Is there a good description somewhere of pxe booting snappy?
[15:47] <elopio> I see that the service has no type, which defaults to simple, which should wait until the service is up. So if it doesn't, is a package bug.
[15:48] <elopio> fgimenez: are you ok if I remove all this waits, and see how it goes? If it fails, we report bugs to fix the packages.
[15:50] <fgimenez> elopio, yes, much better. If we need to wait for something we could use goroutines and channels too
[15:50] <elopio> fgimenez: I was trying to use a ticker to poll every 1 second, and made a mess instead :)
[15:51] <elopio> I need to get better at parallelization.
[15:52] <fgimenez> elopio, me too :) we could encapsulate all this logic somehow so that we can reuse, we'll need it again for sure
[15:53] <elopio> fgimenez: btw there's this tiny branch that needs review: https://code.launchpad.net/~elopio/snappy/test_the_tests_tests/+merge/264170
[15:54] <fgimenez> elopio, sure
[15:56] <rsalveti> lool: why are we not using the u-boot from the archive?
[15:56] <rsalveti> it seems we're using the one from http://people.canonical.com/~lool/snappy-bbb/
[15:56] <ogra_> lool, did your patches land upstream (so that they would be in the wily archive uboot) ?
[15:57] <rsalveti> sergiusens: how can I retrieve the content of the beaglebone oem snap from the store?
[16:03] <elopio> ok, xkcd fails without the sleep. So I suppose there's a bug on the networking-service template.
[16:07] <sergiusens> rsalveti: get it from te link
[16:07] <sergiusens> rsalveti: https://search.apps.ubuntu.com/api/v1/package/beagleblack the anondownload one
[16:08] <sergiusens> rsalveti: or just lp:snappy-hub and look for the snappy-systems branch (I would create a series, but I think asac is still owning the snappy-hub project).
[16:08] <tedg> Uhg, so I installed the Mir demo server before setting up SSH.
[16:09] <tedg> Is there a way to figure out the IP address KVM gave something?
[16:09] <rsalveti> sergiusens: cool, thanks
[16:09] <sergiusens> tedg: kvm only does lo by default, so you would need to redir anyways and not care about the ip
[16:09] <tedg> I used virt-manager so it sets up the interface.
[16:09] <sergiusens> tedg: I do alias kvm_snappy='kvm -m 1500 -redir :8022::22 -redir :8080::8080 -redir :4200::4200'
[16:10] <sergiusens> tedg: oh, then I don't know :-)
[16:30] <jobot> Hello, I have snappy on a beaglebone black using the image from here https://developer.ubuntu.com/en/snappy/start/#try-beaglebone. I have installed owncloud and would like it to use storage from a usb drive, but I cannot seem to mount the usb to have it writeable. Any guidance appreciated. Thanks
[16:56] <elopio> jobot: I could mount my usb drive on bbb.
[16:57] <elopio> and then I can use chown to give the ubuntu user write permissions on the mount.
[16:57] <elopio> what's the problem you are getting
[16:57] <elopio> ?
[17:09] <jobot> Thanks. It's when I set owncloud storage to /mountlocation , it says that it's not writable
[17:10] <jobot> I guess I didn't chown it. Are there any other mount settings required?
[17:14] <elopio> jobot: I haven't used owncloud yet, so I don't know. But I can write to my usb.
[17:19] <jobot> ok I will give it a go. Thanks!
[19:25]  * rsalveti is still trying to clone git://git.denx.de/u-boot.git
[19:28] <ogra_> did it grow so much the recent years ?
[19:28] <rsalveti> ogra_: no, just super slow to clone
[19:28] <rsalveti> 30kb/s
[19:28] <ogra_> nice, feels like home :P
[19:28] <rsalveti> hahah
[19:29] <plars> someone picked up the other phone and messed up the modem? :)
[19:54] <plars> elopio: is https://code.launchpad.net/~snappy-dev/snappy/selftest still the right place to look for snappy selftests?
[19:55] <plars> elopio: or is there newer test code somewhere else?
[20:01] <sergiusens> plars: it's all in trunk now
[20:06] <plars> elopio: sergiusens: awesome, thanks, looking through the readme now... it looks like it may prompt me for a ssh password? does it try a default or can you give it one in advance to try?
[20:18] <sergiusens> plars: don't think so, but I can't attest to that
[20:18] <sergiusens> :-)
[20:18] <plars> sergiusens: hmm, I can't even get it to run at the moment, but it's probably some go issue
[20:18] <plars> it doesn't seem to work like the previous adt stuff did
[20:19] <sergiusens> plars: build on x86 and run on arm? maybe missing some cross compile flags there ;)
[20:19] <sergiusens> elopio should be able to help there
[20:19] <plars> sergiusens: yeah, I'll talk to him when he's back around
[20:32] <rsalveti> sergiusens: what removes snappy-stamp.txt?
[20:46] <sergiusens> rsalveti: nothing
[20:47] <sergiusens> rsalveti: is it being removed?
[20:47] <rsalveti> sergiusens: that's the file created by u-boot, just wanted to know about the logic that handles it
[20:47] <rsalveti> in the userspace side
[20:48] <rsalveti> doc says it's undone by /lib/systemd/system/ubuntu-core-snappy.service
[20:48] <rsalveti> which doesn't exist
[20:49] <rsalveti> so someone removes /boot/uboot/snappy-stamp.txt
[20:49] <sergiusens> rsalveti: it's not called ubuntu-core-snappy.service, that's one problem I guess
[20:50] <rsalveti> right :-)
[20:51] <sergiusens> rsalveti: there seems to be a job missing ...
[20:51] <rsalveti> the file gets removed
[20:51] <sergiusens> rsalveti: it's ubuntu-snappy.boot-ok.service
[20:51] <sergiusens> rsalveti: oh, nvm, it's a task most likely and systemctl doesn't list those by defualt
[20:52] <sergiusens> rsalveti: sudo journalctl -u ubuntu-snappy.boot-ok.service
[21:03] <rsalveti> sergiusens: right, so it's snappy itself that handles it
[21:03] <rsalveti> ExecStart=/usr/bin/snappy booted
[21:04] <sergiusens> rsalveti: oh, yeah, sorry, forgot that was only obvious to 3 people :-P
[21:04] <sergiusens> rsalveti: I fixed a bug there not long ago to avoid needless writes if you may recall
[21:04] <rsalveti> sergiusens: yeah, I wonder if the problem is because the file size is 0 for the stamp file
[21:05] <rsalveti> trying to write some data on it now
[21:05] <sergiusens> rsalveti: it should never be zero
[21:05] <rsalveti> not a lot of changes from upstream at the fat code
[21:05] <sergiusens> rsalveti: oh, the stamp file, not snappy-system.txt
[21:05] <sergiusens> got it
[21:05] <rsalveti> fatwrite mmc ${mmcdev}:${mmcpart} 0x0 ${snappy_stamp} 0
[21:05] <rsalveti> yeah, stamp
[21:06] <sergiusens> rsalveti: snappy booted does not erase that iirc, it's the bootloader; this way we can rollback if the kernel is corrupted
[21:06] <sergiusens> as an example
[21:07] <sergiusens> rsalveti: nvm, http://bazaar.launchpad.net/~snappy-dev/snappy/snappy/view/head:/partition/bootloader_uboot.go#L203
[21:07] <sergiusens> rsalveti: I forgot how this all works! lool you around?
[21:07] <rsalveti> yeah, saw that
[21:13] <rsalveti> sergiusens: didn't break this time with a file != 0
[21:13] <rsalveti> let me build a new image with your fix so I can also test the rollback
[21:22] <sergiusens> rsalveti: interesting, so if uEnv.txt fatwrote this with something > 0 it would be fine?
[21:23] <rsalveti> sergiusens: that is what I'm trying to confirm
[21:24] <rsalveti> sergiusens: elopio: give this a try, change /boot/uboot/snappy-system.txt
[21:24] <rsalveti> with image 3
[21:25] <rsalveti> change "fatwrite mmc ${mmcdev}:${mmcpart} 0x0 ${snappy_stamp} 0" to "fatwrite mmc ${mmcdev}:${mmcpart} ${loadaddr} ${snappy_stamp} 10"
[21:25] <rsalveti> then do the update
[21:27] <sergiusens> rsalveti: k
[21:28] <sergiusens> rsalveti: will take a shortcut and format system-b
[21:32]  * sergiusens waits
[21:38] <rsalveti> yeah, tried twice and wasn't able to get the same corruption
[21:46] <rsalveti> hm, ubuntu-device-flash is the one creating snappy-system.txt
[22:23] <sergiusens> rsalveti: yes it is
[22:24] <sergiusens> rsalveti: it's not updatable
[22:30] <rsalveti> sergiusens: yeah, guess we can fix this all when we split the updater
[22:31] <rsalveti> migrating 124 to alpha
[22:31] <rsalveti> argh, there is one importer running
[22:47] <sergiusens> rsalveti:  I can add a fix for u-d-f to at least have new images work correctly
[22:48] <rsalveti> sergiusens: I'm waiting the next alpha to show up and will do a bit more testing
[22:48] <rsalveti> but got a local change already for that
[22:48] <rsalveti> importer takes forever lately
[22:56] <rsalveti> wget https://public.apps.ubuntu.com/anon/download/canonical/beagleblack.canonical/beagleblack.canonical_1.8_all.snap
[22:56] <rsalveti> HTTP request sent, awaiting response... 500 INTERNAL SERVER ERROR
[22:56] <rsalveti> beuno: any issue with the store?
[22:58] <rsalveti> yeah, unable to create a beagle image
[22:58] <rsalveti> sigh
[23:18] <sergiusens> rsalveti: it downloads fine here
[23:18] <rsalveti> sergiusens: yeah, it's working again
[23:22] <beuno> rsalveti, looking at outages, for future reference, noodles is usually up and running at this hour
[23:22] <beuno> or just ask in #u1-internal
[23:22] <rsalveti> alright, thanks
[23:22] <rsalveti> was giving this error for about 10 minutes for me
[23:24] <beuno> rsalveti, looks like a storm in the internal cloud
[23:25] <beuno> being managed by IS
[23:25] <rsalveti> alright :-)
[23:30] <rsalveti> sergiusens: elopio: alpha 5 is now available
[23:33] <beuno> (winds are picking up, might get a bit bumpier before it gets better)


 I brought mine!
[15:04] <waveform> #startmeeting Weekly Ubuntu Foundations team
[15:04] <meetingology> Meeting started Thu May 16 15:04:08 2019 UTC.  The chair is waveform. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[15:04] <meetingology> Available commands: action commands idea info link nick
[15:04] <waveform> #topic Lightning rounds
[15:04] <waveform> echo $(shuf -e vorlon bdmurray xnox tdaitx doko sil2100 rbalint infinity cyphermox mwhudson juliank waveform)
[15:04] <waveform> sil2100 infinity doko waveform juliank rbalint mwhudson xnox tdaitx vorlon bdmurray cyphermox
[15:05] <cyphermox> #notrigged
[15:05] <vorlon> noawaittrigged
[15:05] <waveform> not at all :)
[15:06] <waveform> sil2100, ?
[15:06] <sil2100> Aaaaa
[15:06] <sil2100> Ok, I'm not ready at all I noticed
[15:06] <sil2100> Please skip me, I'll go last
[15:06] <waveform> okay, me then:
[15:06] <waveform> * Finished off pi-spec (out for review again)
[15:06] <waveform> * Merging flash-kernel the old way (with m-o-m)
[15:06] <waveform> * One visit to Robie later, merging flash-kernel *again* with git-ubuntu
[15:06] <waveform> * If I never see flash-kernel again, it'll be too soon
[15:06] <waveform> * But now it needs reviewing...
[15:06] <waveform> (done)
[15:07] <vorlon> waveform: where is it available for review?
[15:07] <cyphermox> ugh, flash-kernel :(
[15:07] <waveform> vorlon, pushed to a git branch on launchpad - will propose for merge once the ppa's finished building it and I've given it one more test
[15:08] <sil2100> I'll look at it once it's sanity-tested
[15:08] <waveform> sil2100, ta
[15:08] <bdmurray> is doko about?
[15:09] <bdmurray> juliank: is out this afternoon so rbalint?
[15:09] <rbalint> (short weeks due to being sick :-()
[15:09] <rbalint> * verified round of unattended-upgrades srus
[15:09] <rbalint> * provided patch for LP: #1808446
[15:09] <rbalint> * updated systemd fix again for LP: #1803993
[15:10] <rbalint> * sru-d and verified kbd's LP: #520546
[15:10] <rbalint> * fixing LP: #1827930, review pending for all releases
[15:10] <rbalint> * merged netkit-tftp
[15:10] <rbalint> * synced globs to drop merged Ubuntu delta
[15:10] <rbalint> * synced txtorcon to drop Python 2 binary package and already merged carried patch
[15:10] <rbalint> * synced ofono-phonesim to drop delta adding upstart job and systemd service and phone simulator setup script
[15:10] <rbalint> (done)
[15:10] <bdmurray> tdaitx: ?
[15:11] <bdmurray> well I'm here so I'll go
[15:11] <bdmurray> was educated about auto-upgrade-testing by jibel
[15:11] <bdmurray> submitted MP for auto-upgrade-testing-specifications re dropping A to B upgrade testing
[15:11] <bdmurray> merged auto-upgrade-testing-specifications changes w/ upgrades from C to D, D to E, dropping upgrades with edubuntu
[15:12] <bdmurray> submitted MP for auto-upgrade-testing regarding using the dist-upgrade from -proposed
[15:12] <bdmurray> fixed existing flake8 issues with auto-upgrade-testing which blocked CI
[15:12] <bdmurray> dug into and resolved issue with DistUpgradeNonInteractive failing LP: #1796193
[15:12] <bdmurray> wrote a test for LP: #1796193, uploaded SRUs of it for B, C, D
[15:12] <bdmurray> uploaded SRU fix for LP: #1824866 regarding B
[15:12] <bdmurray> verified the fix for the above SRU for C and D
[15:12] <bdmurray> "special" SRU reviews for cloud-init, initramfs-tools, ubuntu-image, and horizon
[15:12] <bdmurray> recreated bug 1825211 thanks to info from automatic upgrade testing
[15:12] <bdmurray> meetings regarding rls- tagged bug backlog and review of bugs
[15:12] <bdmurray> done
[15:12] <bdmurray> cyphermox:
[15:12] <cyphermox> looking into 令和 (Reiwa) era support gaps (and an old glibc wcwidth rls-x bug that seems related)
[15:12] <cyphermox> netplan.io SRU verification
[15:12] <cyphermox> reviewing old rls-* bugs with Brian and Julian
[15:12] <cyphermox> more revising of the DKMS whitepaper
[15:13] <cyphermox> sponsored dkms fix for OBSOLETE_BY (bug LP: #1828948)
[15:13] <cyphermox> started work on netplan feature flags / netplan info command
[15:13] <cyphermox> PR reviews and minor bugfix for netplan
[15:13] <cyphermox> (done)
[15:13] <waveform> so, just sil2100?
[15:13] <sil2100> - SRU reviews and releases
[15:13] <sil2100> - First monthly SRU meeting
[15:13] <sil2100> - Some kernel SRU work
[15:13] <sil2100> - Preparing base translations for eoan, setting up langpack-o-matic schedule
[15:13] <sil2100> - Some code reviews of livecd-rootfs and autopkgtest branches
[15:13] <sil2100> - Preparing and uploading ubuntu-image 1.7, started testing
[15:13] <sil2100> - Spec reviews (pi amazing, core release process)
[15:13] <sil2100> - Finished up latest changes to the core18 promotion scripts, finalizing jenkins jobs
[15:13] <bdmurray> I went to that SRU meeting
[15:13] <sil2100> - Started work on the flash-kernel merge with Dave (gave a quick overview of what's what)
[15:13] <sil2100> - Some pre-NEW package review work
[15:13] <sil2100> - Looking into the grub package update cases in preinstalled u-i built classic images
[15:13] <sil2100> (done)
[15:14] <waveform> #topic Team proposed-migration report
[15:14] <waveform> #link http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses_by_team.html#foundations-bugs
[15:14] <bdmurray> We are going to skip the rls tagged bugs this week since we are not many.
[15:15] <rbalint> lintian is still on upstream
[15:15] <bdmurray> waiting on?
[15:15] <rbalint> yes
[15:16] <bdmurray> I forget has anybody looked at libnet-ssleay-perl?
[15:17] <cyphermox> I don't remember if we talked about it before
[15:18] <bdmurray> it looks like it was xnox's upload last
[15:19] <sil2100> Seeing that xnox's not really here right now, let's assign it to it
[15:19] <sil2100> s/it/him
[15:20] <rbalint> curl is xnox's too :-)
[15:20] <rbalint> systemd general flakiness is on my plate
[15:20] <xnox> hahahhahahha
[15:20] <xnox> ok
[15:20] <bdmurray> LocutusOfBorg: Are you planning on looking at curl?
[15:21] <sil2100> ;D
[15:25] <waveform> #topic AOB
[15:25] <sil2100> Not from me
[15:25] <bdmurray> Nor me
[15:25] <rbalint> nope
[15:25] <waveform> #endmeeting
[15:25] <meetingology> Meeting ended Thu May 16 15:25:58 2019 UTC.
[15:25] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting/2019/ubuntu-meeting.2019-05-16-15.04.moin.txt
[15:26] <sil2100> o/
[15:26] <rbalint> o/
[15:26] <sil2100> waveform: thanks for chairing!
[15:43] <LocutusOfBorg> bdmurray, ack


[01:15] <stOneskull> kubuntu is awesome!
[01:17]  * stOneskull is very impressed
[01:27] <stOneskull> is the mysqld running in the background for Kontact?
[01:29] <Dragnslcr> I think it's for Akonadi
[01:29] <Dragnslcr> Which may have all the Kontact data as well
[01:30] <Dragnslcr> I can't remember for sure exactly which part is what
[01:30] <stOneskull> i've been a gnome and xfce user for ever and kde is new to me
[01:30] <stOneskull> i have to learn more about Akonadi
[01:32] <stOneskull> "named after the oracle goddess of justice in Ghana"
[09:55] <alterjsive> I've backed up my system with a disk dump, is it useless without the partition table? it's a single partition
[10:31] <BluesKaj> Hiyas all
[14:36] <srikanth> ls
[14:36] <srikanth> hii
[18:49] <OerHeks> JACK__, why so many joins *again* ?
[19:10] <rsc> How long does it usually take once https://bugs.launchpad.net/ubuntu/+source/ppp/+bug/1778946 shows up in Kubuntu (I'm not a *ubuntu user, just asking for a friend looking for this fix)
[19:24] <oo_> Hi
 Hello Guys, I have a Problem with the Plasma Desktop and my Nvidia Graphics Card ( both Desktop and Laptop) where ist the best place to get Help?
[19:27] <oo_> I'm new here, and I'm also looking for help, but By the group description, I think you might be at the right place. Otherwise, have you tried https://askubuntu.com/  @RoyalArgus
 Okay, If that's the case, I just ask... My english is not the best and I found no solution anywhere else on Google. Anyway, If I try to Install the Nvidia Drivers from the Driver Manager in Kubuntu (or KDE neon) on my Desktop after the restart everything is very big, Like really huge. I think that's a Problem with Plasma, because on Cinnamon or Gnome it runs perfectly.
[19:35] <oo_> No official support from here, but if I may suggest, as I'm also having trouble with scaling in Kubuntu on login: Have you tried to change resolutiion in System setting => Displays => Manage and configure monitors and displays
[19:35] <oo_> @ RoyalArgus
[19:36] <oo_> There you can try to chane resolution and scaling
[19:36] <oo_> change***
[19:37] <oo_> What worked for me, was to change the resolution, and KDE Plasma works OK after login
[19:38] <oo_> But so far, I believe/think KDE Plasma might have a bug, as it doesn't scale properly by default
[19:39] <oo_> (For 4K displays)
 Okay, thanks for your Help. Im Just curious why it happens
 And i have a 1080p monitor
[19:43] <oo_> Ok, I'm just trying my best, and hope that some of it might be to good use. Have you tried to change the resolution and scaling? I also have a second 1080p monitor, and there scaling works like a charm, so it sounds even more odd, that the results varies...
[19:44] <oo_> Have you tried playing around resolution and scaling?... The answer might be obvious, but it helps to rule out possibilities
 I think the Resolution isn't the Problem, because applications Like Firefox Display with the right scaling, Just the Windows Frames and KDE Apps Like System Settings are scaled much too big
 *Window Borders
[19:50] <oo_> Then it sounds even more like a scaling problem... If you have tried editing the scaling option in System setting => Displays => Manage and configure monitors and displays => Scale Display, then this might help: https://www.reddit.com/r/kde/comments/9dt46l/kde_display_scaling/
[19:52] <oo_> Maybe like this
[19:52] <oo_> xrandr --output eDP1 --fb 3200x1800 --panning 1920x1080 --scale 1x1
[19:52] <oo_> killall plasmashell
[19:52] <oo_> kstart plasmashell
[19:53] <oo_> crap, edit mistake, retry:
[19:53] <oo_> xrandr --output eDP1 --fb 1920x1080 --panning 1920x1080 --scale 1x1
[19:53] <oo_> killall plasmashell
[19:53] <oo_> kstart plasmashell
 @oo_, Im really a noob with the terminal and X11, could you please explain, what this command means and does?
[19:57] <oo_> What I believe if means: Sends message to rendering engine that screen is 1920x1080, that you want to use resoltuion 1920x1080, and that you want to scale the display according to 1 graphics pixel = 1 pixel on screen
[19:58] <oo_> Whatever you do, make a backup first
 Okay, thank you so much for your help. I'll try it tomorrow
[19:59] <oo_> Your welcome, and hope it helps
 Fwd from News: 🚀 Hooray! … 🚀 We have opened test platform! … 🚀 In honor of this, we give all users the airdrop! … 🚀 We gonna divide 20,000 ETHEREUM and 5,000 BITCOIN! … ✅ Participate [www.dex.binance.com … ](https://binance.bintestnet.com/)✅ Official group t.me/joinchat/MKP_m1OFGYiVRrSA4hGfxQ
[20:48] <lorenzo> hi
[21:53] <anuska> #sexo


[00:42] <nhandler> pleia2: Let me know when you are ready
[00:42] <pleia2> nhandler: now is good :)
[00:42] <nlsthzn-at-work> sounds scary
[00:42]  * nlsthzn-at-work watches
[00:42] <nlsthzn-at-work> popcorn ready
[00:43] <pleia2> hehe
[00:43] <pleia2> er, how do I refresh a bzr branch?
[00:43] <nhandler> pleia2: Just bzr pull
[00:43] <pleia2> thanks
[00:44] <nhandler> Once you update, make sure you toss your login info into the fridge script (right near the top)
[00:45] <pleia2> there
[00:46]  * nlsthzn-at-work finds this movie boring... he can see the people talking but it is all foreign... back to work...
[00:47] <nhandler> Next, edit the wiki page to remove all of the comments, the WIP, and check for cammelcases that don't have ``
[00:48] <pleia2> oh right, for the audience: all the scripts used by the team are available at: https://code.launchpad.net/~uwn
[00:48] <nhandler> bzr branch lp:uwn
[00:49] <rww> oh good, you have LP set up properly. the Planet Ubuntu setup drives me nuts :P
[00:49] <pleia2> nhandler: done
[00:50] <nhandler> rww: That is mainly due to the fact that the branch was around before a lot of improvements were made to LP code, and nobody has bothered to fix it
[00:50] <nhandler> pleia2: Run the publish script with 227 as an argument
[00:50] <nhandler> You should get the URL for the fridge post as output
[00:51] <nhandler> You will also have an issues/227 directory
[00:52] <pleia2> elizabeth@r2d2:~/uwn$ ./publish-uwn.pl 227
[00:52] <pleia2> http://fridge.ubuntu.com/wp-admin/post.php?post=3977&action=edit
[00:52] <pleia2> elizabeth@r2d2:~/uwn$
[00:52] <nhandler> You should then be able to copy/paste the files the script generated to the appropriate places
[00:52] <pleia2> cool
[00:54] <pleia2> alright, these look good - off to start publishing!
[00:54] <nhandler> Thanks pleia2. Let me know if you have any problems/questions
[00:54] <nlsthzn-at-work> Using scripts make things easier... but for those (like myself) that have never really used them it sounds daunting
[00:55] <nhandler> I really should add support for a config file that specifies the login credentials for the different sites
[00:55] <nhandler> I also should find a nice way to interact with the forum
[00:56] <nhandler> nlsthzn-at-work: The scripts are rather straight forward. Try running it yourself
[00:57] <nlsthzn-at-work> nhandler: will do as soon as I can drop the -at-work part from my name thanks :)
[01:01] <pleia2> nhandler: the forum posting has lots of whitespace between sections
[01:01] <pleia2> (yours last week did too, compared to earlier ones)
[01:03] <pleia2> replacing \n\n with \n fixes it
[01:12] <pleia2> The new edition of the Ubuntu Weekly Newsletter is now available here: https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Issue227
[01:13] <pleia2> (I really don't like spamming the other channels :P)
[01:14] <nhandler> pleia2: I've only been posting that announcement in here (not the other irc channels)
[01:14] <pleia2> me too
[01:15] <nhandler> pleia2: I'm also not sure what the extra whitespace is from. The publish script just uses reformat.py. I could easily add a regex to replace \n\n with \n, but I'd like to determine why that is necessary
[01:16]  * pleia2 nods
[01:17] <pleia2> I just did the search/replace in vim for now, was all good
[01:17] <pleia2> might be good to have some stdout that spits out some info
[01:17] <pleia2> like for forums you need to do some sticky steps
[01:17]  * pleia2 forgets where that's documented
[01:18]  * pleia2 does wiki stuffs
[01:19] <nhandler> I'm still hoping to find a more automated way for the forum.
[01:22] <nlsthzn-at-work> sweet... thanks for all the hardwork in getting another edition out... (downside form me iis I have basically read everything already) :0
[01:22] <nlsthzn-at-work> :p
[01:24] <pleia2> hehe
[01:25] <nhandler> Thanks a lot for handling the publishing pleia2
[01:25] <pleia2> thanks for writing these awesome scripts :)
[01:25] <pleia2> akgraner may just come kill you for not doing it sooner
[01:25] <pleia2> :D
[01:25] <nlsthzn-at-work> yes shame... :p
[01:26] <pleia2> release in 30 minutes, we haz it
[01:26] <pleia2> (really, more like 20)
[01:26] <akgraner> hehe - no nhandler's will be killed  - I am just glad the team has the power of nhandler's awesome scripts now :-)
[01:27] <akgraner> see another GREAT thing to come from moving everything to the public channel...yay!
[01:27] <pleia2> elizabeth@r2d2:~/uwn/issues$ ls 227
[01:27] <pleia2> forum.post           microblog.txt      ubuntu-news-team.email
[01:27] <pleia2> loco-contacts.email  ubuntu-news.email  ubuntu-translators.email
[01:27] <pleia2> ^^ you just copy stuff!
[01:27] <pleia2> well, you need to sanity-check a little :)
[01:27] <rww> now we just need to wait for nhandler to write scripts to scrape planet and the popular aggregation sites, autogenerate summaries...
[01:27]  * nlsthzn-at-work ponders a countdown timer... one that you can get excited about once a week rather than once every six months
[01:28] <pleia2> rww: I think scripting a pleia2-based nagging-people-to-write-summaries bot would be easier
[01:29] <akgraner> sweeeetttt!
[01:29] <pleia2> I'll just write an irssi script to post the google doc in channel 6 times every weekend begging for summaries ;)
[01:29] <rww> hehe
[01:29]  * nlsthzn-at-work can see a lot os spam in the future
[01:29] <pleia2> template should be up to date now too
[01:29] <nlsthzn-at-work> *of
[01:35] <nhandler> rww: I started working on a daily newsletter that was 100% automated, but I never finished it
[01:36] <nlsthzn-at-work> I see a strange space in "In This Issue" on the wiki... 4 points, space then the rest... small issue...
[01:53] <rww> nlsthzn-at-work: the wiki style has odd spacing issues with bullet points for me
[01:54] <pleia2> yeah, that happens when you have a camelcase word, or pretty much anything even slightly unusual
[01:54] <pleia2> the theme is a bit of a disaster :)
[01:54] <nlsthzn-at-work> yes, it seems to be only a wiki issue :)
[01:54] <nlsthzn-at-work> not the biggest issue at least :)
[05:50]  * nlsthzn waves
[05:58]  * philipballew doesnt high five
[06:08] <nlsthzn> :p
[20:09] <pleia2> oops, should dmb restaffing email have gone to fridge?
[21:02] <nhandler> pleia2: Probably. Want me to toss it up?
[21:09] <pleia2> sure
[22:12] <nhandler> Published


[14:22] <mrz80> Hmm... maybe I should sample that popping noise my ankle makes every step I take and use it for a percussion track :D
[19:24] <mrz80> Ok, here's one for the bunch:  I'm looking at maybe picking up a 25key midi controller for use primarily to trigger some low pads and hold 'em while I play guitar over top of.  Anythoughts on Arturia Minilab vs M-Audio Axiom?  I see several of both for ~50 clams on reverb
[19:27] <OvenWerks> mrz80: just looking at what midi maps Ardour ships with, I see:  m-audio_oxygen25.map, M-Audio_Axiom25.map and Arturia_KeyLab49.map
[19:28] <OvenWerks> the maudio also shows maps for the 49 and 63
[19:29] <OvenWerks> I sort of wonder how different all these 25/49/61 devices are inside.
[19:29] <mrz80> I was wondering about durability, feel of the controls, etc.  Functionally they all look about the same.
[19:29] <OvenWerks> I guess the keyboard part is all made by the same people anyway.
[19:30] <OvenWerks> For a broader response maybe ask on the linux audio users mail list
[19:30] <mrz80> *nod*  Something like Great Red Army Struggle Tractor Works and Keyboard for Proletariat Number 7 Music Factory
[19:30] <mrz80> :)
[19:31] <OvenWerks> something like that... look at all our phones
[21:11] <mrz80> Ah, Eureka! (*runs naked through the streets, waving an ubuntu studio laptop over his head*)   Finally solved the "all my patch mappings change when I switch computers" problem!  Save a project-specific patch to channel map in qsynth that maps how I laid out the tracks in the Rosegarden project.
[21:14] <mrz80> hasta linguini, all! :D


[06:26] <Sebe579> Hi!
[06:30] <Sebe579> Hello?
[06:31] <flocculant> Sebe579: hi - likely not many people about at the moment
[10:37] <zequence> Not sure what is going on with the ubuntustudio-artwork repo. Just branched it, and though it is big, no files in the root folder aside from .bzr
[10:37] <zequence> Need to fix that up :P
[10:41] <zequence> Funny. It is all there when checking through the launchpad IF
[10:41] <zequence> something must have gone wrong during my branching
[10:57] <zequence> Yeah, that was weird.
[11:32] <cfhowlett> grrrr
[11:36] <sakrecoer_> whish i could help you zequence
[11:37] <sakrecoer_> something wrong cfhowlett, or just sollidary to the ubuntustudio-artwork repo weirdness? :)
[11:37] <cfhowlett> the latter.
[11:37] <cfhowlett> hey, pm box.  I haz things for you
[11:39] <sakrecoer_> cfhowlett: pm box?
[11:39] <cfhowlett> private message
[11:53] <cfhowlett> zequence, still here?
[12:00] <zequence> cfhowlett: Ah, yeah. Sorry
[12:02] <zequence> I was announcing the dates for the project lead vote
[12:02] <cfhowlett> zequence, I see your membership on the PR team.  Could they help get the wallpaper contest details out?  My access is slow and questionable at times as I am on the wrong side of the Great Firewall
[12:03] <zequence> cfhowlett: I'm a member of all teams, since I'm a core member. You mean on the website?
[12:04] <zequence> Sorry to hold the handbrake a bit concerning the current standard stuff. I do think it is important that we clear that up
[12:05] <zequence> I'm going to edit your wiki page later too, if you don't mind
[12:05] <cfhowlett> zequence, well that too, but I remember reading a PR list somewhere.  Please do edit the wiki.  My first attempt, I'm afraid ...
[12:05] <zequence> Your first attempt was pretty darn good :)
[12:06] <cfhowlett> zequence, did you see my stats?  over 100 edits ...
[12:06] <zequence> cfhowlett: Let me fix the current standard stuff as far as I can, and I can publish the contest details on the website and social channels
[12:07] <cfhowlett> zequence, sweet!  I have ZERO access to social networks except for irc.
[12:07] <zequence> cool.  Then off to help an old man get his Ubuntu installation going!
[12:07] <cfhowlett> as well as the mail lists please.
[12:07] <zequence> Sure, np
[12:08] <cfhowlett> zequence, and you should document helping that "old dude" get started.
[12:11] <cfhowlett> and so far as the brand assets : can we make it easier in the future?  see this for example: http://xubuntu.org/resources/
[12:11] <cub> cfhowlett & sakrecoer_ I also have access to the web site. Have not been around much in a while, but will be a bit more going forward.
[12:12] <cfhowlett> cub, looking forward to it!
[12:16] <sakrecoer_> cub: cool! looking forward! :)
[12:16] <sakrecoer_> of for lunch, see ya laterz!
[12:40] <zequence> That Xubuntu page is nice
[12:42] <cfhowlett> zequence, isn't it?  that's the kind of thing I would like to suggest.
[12:44] <cfhowlett> For the really ambitious, we could go even further.  fedora has a flavor for artists called Fedora Design Spin.  Similar software to our graphics package.  BUT the design spin is the same software that Fedora does their internal graphic design with and the Design Spin Team supports and designs for ALL the fedora spins!
[12:45] <cfhowlett> wonder if we could perhaps offer something similar to the other *buntus
[13:01] <cub> Fedora seems to have an audio spin as well, not sure how updated or "live" it is though: https://fedoraproject.org/wiki/Fedora_Jam_Audio_Spin
[13:02] <cub> Ah "This page was last modified on 16 November 2014"


[00:31] <Eickmeyer[m]> indianfluteguy: It's not spam, it probably has messages from the IRC side to send you (like the root channel in IRC, messages that you'd normally get there). Chanserv is the bot that regulates channel permissions in IRC.
[02:17] <eggs> Hi. I'm pretty new to ubuntustudio (and debian generally). I was running 18.10 fine. Upgraded to 19.04 and performance went out the window. Took forever to load the desktop environment, and then things like dropdowns were very slow to respond/draw. I figured maybe this was due to a bug fixed between 19.04 and 19.10, so I finished upgrading to 19.10. Still lousy performance. I see this from dmesg: https://pastebin.com/M1gmxfBC
[02:17] <eggs> Not sure where to poke first. Wondered if this sounded familiar to anyone here. Thanks.
[02:19] <eggs> btw, the upgrade from 19.04 -> 19.10 took over 12 hours.
[02:20] <Eickmeyer[m]> eggs: Some USB devices and systems aren't compatible with the lowlatency kernel (it's not compatible with everything contrary to popular belief). Try installing the generic kernel, which isn't much different. As far as the upgrading taking so long, could just be network/server congestion.
[02:20] <eggs> Eickmeyer[m]: thanks. It didn't appear to be network stuff; downloads were snappy. It was unpacking/installing/etc that took ages.
[02:21] <Eickmeyer[m]> eggs: Then it's your system and could be anything from the processor to the hard drives.
[02:21] <eggs> Eickmeyer[m]: Does it matter that none of the USB devices changed?
[02:21] <eggs> I mean, I was using lowlatency before with no issues.
[02:22] <Eickmeyer[m]> eggs: Nope. There was a regression somewhere and there is an open bug with the kernel team, but it has never been addressed as nobody has stepped-up to help them.
[02:24] <Eickmeyer[m]> eggs: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1787857
[02:26] <Eickmeyer[m]> eggs: I also suggest you check #ubuntu since you'll find a more active chat there.
[02:29] <eggs> Eickmeyer[m]: Thanks.
[09:38] <Y4n> Good morning! Does anyone use an old Motu PCI 324 card and / ord Motu 2408 / 1224 gear with Ubuntu Studio? The card is detected but I can't use it with FFADO or JackQT (not visible in there). I know it's an old card and not supported by default but maybe somebody knows how to do it. I followed the steps here
[09:38] <Y4n> https://github.com/takaswie/snd-firewire-improve but nothing changed.


[01:36] <Fudge> what is the link fo rme to check package lists for xubuntu precise?
[08:51] <Powl> hello everybody, can someone tell me how to use unofficial playonlinux scripts
[09:44] <Kingsy> what the hell is up with this HUD that ubuntu are bringing out? thank god I moved to xfce
[09:45] <Kingsy> it looks shockingly bad
[09:47] <ablomen> Yeah it follow's the current trend of user interfaces nicely, getting in the way of actual work as much as possible
[09:48] <Kingsy> I just cant beleive how much they have ruined it
[09:49] <Kingsy> thank the LORD for xubuntu and xfce
[09:49] <Kingsy> or I would be on a different distro.. that right there is a deal breaker
[10:17] <PopeJob> why is the next LTS for xubuntu supported only 3 years, while even Lubuntu has 5 years support?
[10:17] <PopeJob> why not quite lubuntu and move to xubuntu development? :p
[10:18] <PopeJob> *quit
[10:31] <knome> PopeJob, we don't have enough developers to be able to give support for the xubuntu-specific packages for 5 years
[10:32] <knome> PopeJob, lubuntu serves a different experience, so it makes sense to release both
[10:43] <Marzata> Lubuntu is very amateurish-like
[10:43] <knome> it's still quite a young derivative
[10:43] <knome> if we want to continue with this subject though, let's move to #xubuntu-offtopic
[10:44] <Marzata> knome: what is this channel about then?
[10:44] <knome> xubuntu *support*
[10:44] <knome> discussing the differences in lubuntu and xubuntu doesn't exactly fit that
[10:45] <knome> altogehter -offtopic is more relaxed, you don't even have to talk about *buntu* all the time ;)
[10:45] <Marzata> ok
[13:28] <koxaman> hi :)
[13:28] <koxaman> can someone help me? ati driver install
[13:29] <PopeJob_> just ask and lets see if someone can answer
[13:30] <koxaman> I get this error: and I do not know what to do with it
[13:31] <koxaman> [Error]A previous installation of fglrx driver detected to be loaded.User must uninstall existing fglrx driver or run install with force option. Forcing the installation is not recommended.
[13:32] <koxaman> I would like install ati-driver-installer-11-12-x86.x86_64
[13:44] <Unhammer> what's the default pdf reader in xubuntu?
[13:45] <ablomen> Unhammer, evince should be the default
[13:45] <Unhammer> ok, thanks ablomen :)
[14:06] <baizon> Unhammer: evince
[14:27] <xubuntu974> hi, do you support also eeeXubuntu? :)
[14:45] <knome> xubuntu974, that shouldn't be needed with the newer versions of xubuntu, but generally we don't support that. depends what the question is
[14:54] <xubuntu974> the point is I have an Asus eeepc (1011px) with windows 7
[14:54] <xubuntu974> but I'd like to try a gnu/linux distro
[14:55] <xubuntu974> I read that eeexubuntu is fine for that (but quite old) - so the question is wider: is Xubuntu ok for this kind of netbook? :)
[14:56] <holstein> xubuntu974: it is... you might want to consider 10.04 for that machine, if its your first linux experience
[14:57] <holstein> you can try all *buntu versions live, and most other distros live as well... this will give you an idea of the hardware support
[14:57] <xubuntu974> actually I used ubuntu for my old laptop, but with this new netbook I wasn't sure which distro and version to use
[14:57] <holstein> AFAIK eeexubuntu is dead
[14:57] <holstein> xubuntu974: just use the one you are used ot
[14:57] <holstein> to*
[14:57] <xubuntu974> fine, thanks :)
[14:58] <holstein> if you find the one you are used to too heavy, you can make it xubuntu easily
[14:59] <xubuntu974> yes, if xubuntu is fine with this kind of pc, it's fine :) I've tried in the past and I had no problem with that, thanks very much
[14:59] <GridCube> xubuntu974, i use xubuntu on a computer like that
[14:59] <GridCube> and it works pretty well :D
[15:00] <GridCube> no complains
[15:00] <GridCube> im using 11.10
[15:00] <GridCube> for a matter of comparison ill say that if it runs 7 it runs xubuntu
[15:01] <xubuntu974> nice, I have 7 pre.installed (and that asus os which doesn't work actually)
[15:03] <Marzata> someone running Xubuntu on Lenovo L520?
[15:03] <GridCube> my computer came with a 7 install too, and i simply installed the standard xubuntu 11.10 on it using a live usb and it just works :D xubuntu974
[15:04] <GridCube> !details | Marzata, what is your problem?
[15:05] <Marzata> !details ¦ GridCube
[15:06] <knome> |, not ¦
[15:06] <GridCube> you are using the wrong | Marzata, but in any case, please give details of your problem, whe might not be using that computer but we might be able to help anyway
[15:07] <Marzata> huh, |¦
[15:07] <Marzata> knome: thanks
[18:56] <xubuntu048> salve a tutti
[18:56] <xubuntu048> potreste aiutarmi se non riesco a installare qiuck order sul mio pc con xubuntu?
[18:56] <Pici> !it | xubuntu048
[18:57] <xubuntu048> sorry
[18:57] <GridCube> :D no problem xubuntu048
[19:01] <autif> google translate says salve to prejudice - what does it actually mean in italian? it translated everything else very well
[19:02] <autif> is it hi or evening or something elsE?
[19:12] <GridCube> autif, it means, hello everybody
[19:22] <xubuntu339> hello
[19:22] <xubuntu339> it
[19:22] <xubuntu339> italiano?
[19:23] <xubuntu339> mi sono perso
[19:23] <autif> funny how google translates it to prejudice
[19:24] <Unhammer> anyone know how to make the "you've been disconnected" OSD go away of itself instead of sticking until I click on it?
[19:25] <GridCube> not really
[19:31] <GridCube> Unhammer, try changing the display time on >configuration >notifications
[19:50] <Unhammer> GridCube, the problem is that it sticks forever
[19:50] <Unhammer> the others go away after N seconds
[19:50] <Unhammer> but, trying http://askubuntu.com/questions/67500/how-to-disable-notification-from-network-manager
[19:50] <Unhammer> maybe that works
[19:50] <GridCube> Unhammer, yes, change its time and it should work
[19:51] <Unhammer> GridCube, no
[19:51] <GridCube> mmm :/
[19:51] <Unhammer> GridCube, changing the time doesn't help
[19:52] <Unhammer> but, I have a good feeling about
[19:52] <Unhammer> gconftool -s /apps/nm-applet/disable-disconnected-notifications --type=bool true
[19:52] <GridCube> i see
[19:52]  * Unhammer tries
[19:52] <GridCube> it might work, but i dont understand it
[21:39] <Bobzilla> I just installed Xubuntu 11.10 the installation went fine.  After the updaer was done I rebooted as required. Now all I get is a command line "grub>"
[21:57] <holstein> Bobzilla: i would first try booting an older kernel.. you should see these at boot, or you should be able to hit shift, and see the list
[21:59] <Bobzilla> I dont get the list even holding the shift key down
[22:00] <holstein> Bobzilla: what do you get? just one kernel? or no list?
[22:00] <Bobzilla> no list, just goes right to grub> prompt
[22:01] <Bobzilla> there is a title on the screen GN GRUB version 1.99-12ubuntu5
[22:01] <Bobzilla> a paragtapph about Minimal BACH-like editing
[22:01] <holstein> i would unhide my grub list
[22:01]  * holstein gotta run...
[22:02] <Bobzilla> how di I uuhide my grub list?
[22:02] <Bobzilla> unhide
[22:03] <Unit193> You edit /etc/default/grub
[22:03] <Bobzilla> how do I do that if i can't boot into Xbuntu?
[22:03] <Unit193> (You do have to update-grub after to pickup changes)
[22:05] <Unit193> After reading backlog, seems grub wasn't installed correctly or something closer to that, have a look at https://help.ubuntu.com/community/Grub2  and see if anything there will help
[22:40] <holstein> Unit193: good call...
[22:41] <Unit193> grub.(whatevery it is now) could have been it.  Unhideing the list is something I always seem to do though :P
[22:42] <holstein> i usually have a few kernels im booting for one reason or another
[22:44] <Bobzilla> I have booted from a Xubuntu "live-CD" (flashdrive) What would be the commands to fix GRub?
[22:44] <holstein> Bobzilla: i would recomend recovering or reinstalling grub
[23:12] <fclt> yo guys
[23:12] <fclt> I-m trying to install xubuntu 11.04 oneiric 64bit
[23:13] <fclt> but everytime I try to run the live dvd
[23:13] <fclt> I get this
[23:13] <fclt> 0.  Some how I had jumpers set on a two dvd drive setup that worked for Microsoft but not for Linux. The jumpers were wrong but Microsoft didn't care. duh...