[03:40] <brlin> Any chance SNAPCRAFT_BUILD_ENVIRONMENT=lxd get re-implemented in snapcraft?
[06:06] <mborzecki> morning
[07:24] <mborzecki> mvo: morning
[07:25] <mvo> mborzecki: hey, good morning
[07:28] <mborzecki> mvo: left a comment in your dns retry pr
[07:28] <mborzecki> i think it's a bit tricky, especially when there are 2 resolves that could run
[07:37] <mvo> mborzecki: yeah, its nasty
[08:03] <pstolowski> morning
[08:06] <mup> PR snapd#6292 opened: spread: record each tests/upgrade job <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6292>
[08:08] <mborzecki> super simple PR ^^
[08:08] <mborzecki> pstolowski: hey
[08:16] <pstolowski> mborzecki: question there
[08:16] <jamesh> mvo: I got my dbus activation tests working on everything except ubuntu-14.04-64 and ubuntu-core-18-64 now -- I think the ubuntu-core-18-64 failure would be best solved by adding some extra symlinks to the core18 snap
[08:17] <mvo> jamesh: ok, we can do that - could you add details what is needed into the PR?
[08:17] <mvo> jamesh: then I can prepare a PR for core18 :) you are welcome of course to do the pr too if you don't mind digging into the (not very complicated) core18 build (github.com/snapcore/core18)
[08:21] <mborzecki> pstolowski: left a note, we're not running prepare-restore.sh --prepare-suite-each there, idk why, maybe because it'd need some changes internally as it seems to assume snapd is installed
[08:22] <pstolowski> k
[08:23] <mborzecki> pstolowski: and i don't want to go into the process of debugging the whole suite now, just need this little piece to figure out why #6270 fails, i belive it's because the upgrade test runs and since it had the old policy /run/snapd is incorrectly labeled, but the test it's not logged  :/
[08:23] <mup> PR #6270: data/selinux, tests: refactor SELinux policy, add minimal tests <SELinux> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6270>
[08:27] <pstolowski> mborzecki: sure, replied
[08:36] <pedronis> zyga: hi, I did another pass on #6190
[08:36] <mup> PR #6190: overlord/configstate,features: expose features to snapd tools <⛔ Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/6190>
[08:37] <zyga> Thank you, looking
[08:38] <pedronis> mvo: morning, we have a meeting overlapping the standup today :/
[08:38] <zyga> I’ll add the remaining test and tweak the things you pointed out
[08:38] <mvo> pedronis: yeah, I noticed as well
[08:38] <mvo> pedronis: unfortunate
[08:38] <pedronis> zyga: thx
[08:39] <mborzecki> need to go out for a bit, back in an hour or so
[08:41] <pedronis> mvo: can we have a chat (hopefully short) about state of various things in a bit?
[08:44] <pstolowski> pedronis: hello, updated #6268
[08:44] <mup> PR #6268: overlord/ifacestate: helpers for serializing hotplug changes <Hotplug 🔌> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6268>
[08:45] <mvo> pedronis: yes, just wrestling with core18 and cloud-init and ordering right now but I think I'm almost done
[08:45] <pedronis> ok
[08:46] <pedronis> pstolowski: I'll look
[08:46] <pedronis> thx
[08:47] <mup> PR snapd#6209 closed: run-checks: discard test good/bad banner <Created by zyga> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/6209>
[08:48] <mup> PR core18#97 opened: hooks: add hook to ensure cloud-config runs in the right order <Created by mvo5> <https://github.com/snapcore/core18/pull/97>
[08:51] <zyga> master is still broken?
[08:54] <pedronis> apparently  https://api.travis-ci.org/v3/job/466661285/log.txt
[08:54] <pedronis> still issues with seeded and core18
[08:54] <pedronis> mvo: ^
[08:55] <mvo> pedronis: looking
[08:56] <mvo> pedronis: this is different from what sergio reported: Dec 11 19:49:27 dec111939-540068 systemd[1]: snapd.seeded.service: Main process exited, code=killed, status=15/TERM
[08:57] <mup> PR core18#98 opened: hooks: add symlinks for snapd's D-Bus configuration files <Created by jhenstridge> <https://github.com/snapcore/core18/pull/98>
[08:57] <jamesh> mvo: I think this should fix dbus activation for core18.  I haven't tested it yet though: https://github.com/snapcore/core18/pull/98
[08:57] <mup> PR core18#98: hooks: add symlinks for snapd's D-Bus configuration files <Created by jhenstridge> <https://github.com/snapcore/core18/pull/98>
[08:57] <mvo> jamesh: nice, thank you
[08:57] <pedronis> mvo: this is the degraded test, not sure I know what it does
[08:57] <pedronis> mvo: maybe you other fix, makes this one flaky?
[08:58] <mvo> pedronis: yeah, what I mean is that the error looks different, I will poke at it
[08:58] <mvo> pedronis: could be fallout from the previous change of course :/
[08:58] <pedronis> mvo: I'm slightly worried about the hacks and counter hacks that seeded as is and the snapd being a snap are creating in core18
[08:59] <pedronis> seeded = the service
[08:59] <mvo> pedronis: yeah, I'm unhappy too, what shall we do? I can write up what is happening and we can discuss what the best option is?
[09:00] <mvo> pedronis: i.e. I write down the details and we have a HO once you had a chance to look at it?
[09:00] <zyga> Im happy to help as we
[09:00] <zyga> well
[09:01] <mvo> zyga: sounds great
[09:01] <zyga> nothing brings the mood down as the eternal red cross
[09:12] <pedronis> mvo: also will not the bug about the snapd socket changing affect also other operations, not just the seeded service?
[09:13] <mvo> pedronis: maybe, this happens very early, I'm writing down the sequence then hopefully things are clearer
[09:14] <zyga> mborzecki: updated https://github.com/snapcore/snapd/pull/6288
[09:14] <mup> PR #6288: cmd/snap-confine: refactor call to snap-update-ns --user-mounts <Per-user mount ns  🐎> <Created by zyga> <https://github.com/snapcore/snapd/pull/6288>
[09:21] <pedronis> pstolowski: done
[09:21] <pstolowski> thx
[09:22] <pedronis> thank you
[09:24] <mvo> pedronis, zyga here is the overview, I will write the problems with snapd.seeding next
[09:24] <mvo> snapd.seeded
[09:24] <mvo> pedronis, zyga https://gist.github.com/mvo5/12632c729f07c3b02fa3d0e7383439d5/edit
[09:24] <zyga> looking
[09:28] <zyga> mvo: point 5, typo, I think you mean "then snapd exits"
[09:29] <mvo> zyga: indeed, sorry
[09:29] <zyga> mvo: point 8, I'm always confused by various systemd features, specifically those that relate to ordering and dependencies, is After the one that says something when starting together, runs after, or is it the one that says that it has a hard dependency on something (here core18.start-snapd) and it will not run unless that other unit is started
[09:30] <mvo> zyga: its the "start-after", it does not have any dependency implications
[09:30] <zyga> mvo: question about core81.start-snapd: when does it become ready in sysytemd terms?
[09:30] <mvo> zyga: i.e. it will happily run if the after=nonexisting
[09:30] <mvo> zyga: after seeding is done
[09:30] <zyga> is it using sd-notify?
[09:30] <mvo> zyga: snap watch --last=seed :)
[09:31] <mvo> zyga: should I add it to the gist?
[09:31] <zyga> is it a type oneshot service?
[09:31] <mvo> zyga: correct
[09:31] <mvo> zyga: with remainafter=true
[09:31] <zyga>            Behavior of oneshot is similar to simple; however, it is expected that the process has to exit before systemd starts follow-up units.  RemainAfterExit= is particularly
[09:31] <zyga>            useful for this type of service. This is the implied default if neither Type= nor ExecStart= are specified.
[09:31] <zyga> ^ from the man page
[09:31] <zyga> so that seems all is good
[09:32] <zyga> thank you mvo
[09:32] <mvo> zyga: yeah, I'm writing the problematic parts down now, the first part is mostly to give a good understanding how things work
[09:33] <zyga> thank you for that, it is very useful
[09:33] <zyga> I would love to have a man page for each unit we have
[09:33] <zyga> and what you pasted above could live there
[09:33] <zyga> in that good old unix tradition
[09:38] <pedronis> mvo: read it, I was not aware of this, it seems problematic in many ways tbh
[09:39] <pedronis> I mean fully aware of this
[09:39] <mvo> pedronis: ok, writing down some more, lets talk in a HO then
[09:41] <pedronis> mvo: I have another meeting in 20 but let's see what we can do
[09:41] <popey> What's the minimum allowed length of a snap name?
[09:42] <mvo> pedronis: https://gist.github.com/mvo5/12632c729f07c3b02fa3d0e7383439d5
[09:42] <mvo> pedronis: I can jump in HO now, we can try to make it quick
[09:42] <mvo> pedronis: I'm in the standup channel now
[09:43] <mvo> pedronis: ready when you are
[09:54] <niemeyer> Heya
[09:54] <niemeyer> I've created a team for the base snaps (core18 and 16)
[09:54] <mup> PR core18#97 closed: hooks: add hook to ensure cloud-config runs in the right order <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/core18/pull/97>
[09:54] <niemeyer> So all the right people have access to both
[10:07] <mborzecki> re
[10:07] <zyga> thank you niemeyer!
[10:07] <popey> zyga: do you know if there's code somewhere that constrains the length of a snap?
[10:08] <zyga> length of what exactly?
[10:08] <zyga> the file size?
[10:08] <popey> the snap name
[10:08] <zyga> ah
[10:08] <zyga> yes
[10:08] <zyga> it is limited
[10:08] <popey> a, aa, aaa
[10:08] <zyga> in snapcraft, snapd and the store
[10:08] <popey> what's the limit?
[10:08] <zyga> let me look
[10:08] <zyga> AFAIK 40
[10:08] <popey> thanks
[10:08] <zyga> but looking
[10:08] <popey> what's the minimum?
[10:09] <zyga> 2
[10:09] <zyga> max is 40 as I said
[10:09] <zyga> https://github.com/snapcore/snapd/blob/master/snap/validate.go#L94
[10:09] <zyga> this is the logic in snapd
[10:10] <popey> is there a reason why 2 was selected?
[10:10] <zyga> I'm sure there was
[10:10] <zyga> I think a one character command name is pretty unexpected
[10:10] <zyga> and would be filled with spam
[10:10] <popey> "filled" - there's not a lot of single characters available ;)
[10:10] <popey> around 26 or so in English
[10:11] <zyga> snapcraft register a
[10:11] <zyga> ;-)
[10:11] <zyga> anyway, that's that
[10:11] <popey> Ok. I am not sure what to do as I have found a project which I have snapped, but it's one letter long
[10:11] <popey> Am I expected to tell an upstream to rename their project?
[10:12] <zyga> what's the project name?
[10:12] <popey> s
[10:12] <zyga> wow
[10:12] <zyga> what is it?
[10:12] <popey> https://github.com/zquestz/s
[10:12] <popey> open a web search from the command line
[10:12] <popey> so you'd want it to be short
[10:13] <zyga> popey: I suggest that you escalate this to niemeyer
[10:13] <zyga> popey: it could be called the-s
[10:13] <zyga> with an alias perhaps
[10:14] <niemeyer> popey: There's a long culture in Debian of fixing upstream names when they are unfit for purpose
[10:14] <niemeyer> popey: This seems no different
[10:15] <popey> This seems very different. Part of the selling point of snaps is there's not someone in the middle between them and users.
[10:15] <niemeyer> I suffered from that myself.. my old school "smart" project, as in Smart Package Manager, wasn't accepted as "smart"
[10:15] <niemeyer> It was too general
[10:15] <niemeyer> Ended up as "smartpm" in Debian
[10:15] <niemeyer> I can't imagine they'd take "s" :)
[10:15] <popey> Ok
[10:16] <niemeyer> popey: Our infrastructure is a middle man.. we need to balance the voices of publishers with the voice of users
[10:16] <niemeyer> and manufacturers etc
[10:16] <popey> I'll offer a suggestion to them.
[10:17] <niemeyer> popey: Thanks
[10:17] <zyga> niemeyer, popey: do you think the alias idea is workable?
[10:18] <niemeyer> zyga: I don't know to be honest.. it depends a bit more on the context
[10:23] <mborzecki> zyga: can you take a look at https://github.com/snapcore/snapd/pull/6292 it's your favourite topic :)
[10:23] <mup> PR #6292: spread: record each tests/upgrade job <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6292>
[10:23] <zyga> mmm
[10:24] <zyga> gaaah
[10:24] <zyga> you want me to look even older
[10:24] <zyga> the reason for upgrade not using that
[10:24] <zyga> is that they setup is quite different
[10:24]  * zyga is sad
[10:25] <zyga> done
[10:25] <mborzecki> zyga: heh, i was tracking a problem in one of the selinux prs, and the only explanation was that the upgrade test ran, turn out those weren't logged like the rest
[10:26] <pedronis> mvo: could you also follow up on that email to foundation you sent, or should I?
[10:26] <mvo> pedronis: I will do that, thank you
[10:26] <mvo> pedronis: just finishing my work on the unit, then I will follow up
[10:27] <pedronis> mvo: thx, also I'm out of the meeting, so we can HO a bit more when you have time
[10:27] <zyga> mborzecki: upgrade tests are very much distinct
[10:27] <zyga> mborzecki: I wonder if it would make sense to run them on a speparate pass
[10:27] <zyga> mborzecki: until we are sure they are not leaving garbage behind
[10:27] <zyga> or vice versa
[10:27] <mborzecki> zyga: committed your suggestion
[10:27] <zyga> thank youu
[10:28] <mborzecki> zyga: i hope that the PR confirms my suspicions as to why https://github.com/snapcore/snapd/pull/6265 fails
[10:28] <mup> PR #6265: cmd/snap: attempt to restore SELinux context of snap user directories <SELinux> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6265>
[10:30] <mvo> pedronis: I think I found a good solution, will push in a bit and then we can HO again
[10:35] <pedronis> pstolowski: any new findings on the slow remove bug? are you blocked on hot plug stuff? missing 2nd reviews?
[10:37] <pedronis> mvo: https://forum.snapcraft.io/t/auto-import-doesnt-work-with-uc18/8960
[10:37] <pstolowski> pedronis: no news yet, investigating. i need 2nd reviews from mvo, yes
[10:37] <mvo> pstolowski: sorry!
[10:38] <pstolowski> pedronis: i'll land hotplug seq soon once travis is green, that one got enough reviews
[10:38] <mvo> pedronis: uh, not more bugs :(
[10:38] <pstolowski> mvo: don't be, i know you have lots of more important stuff atm, np
[10:38] <mvo> pedronis: yeah, the udev auto-import it is, looking at it next
[10:39] <pedronis> mvo: let's chat first tough
[10:39] <pedronis> I mean before you start on something next ...
[10:41] <mup> PR core18#99 opened: static: add snapd.seeded.service to core18 <Created by mvo5> <https://github.com/snapcore/core18/pull/99>
[10:43] <mvo> pedronis: HO?
[10:43] <pedronis> yes
[10:43] <mup> PR core18#100 opened: static: add missing /lib/udev/rules.d/66-snapd-autoimport.rules <Created by mvo5> <https://github.com/snapcore/core18/pull/100>
[10:50] <mborzecki> zyga: added the renames you suggested
[10:51] <mborzecki> anyone interested in doing a 2nd review of #6285 ?
[10:51] <mup> PR #6285: selinux: package to query SELinux status and verify/restore file contexts <SELinux> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6285>
[10:58] <zyga> mborzecki: thank you :)
[11:00] <mborzecki> zyga: can you take a look at the release bits in #6286 too?
[11:00] <mup> PR #6286: release: support probing SELinux state <SELinux> <⛔ Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6286>
[11:01] <zyga> emmm
[11:01] <zyga> sure
[11:02] <zyga> mborzecki: question about package layout
[11:02] <zyga> mborzecki: or tree layout perhaps
[11:02] <zyga> mborzecki: pkg/selinux, pkg/apparmor, pkg/foo
[11:02] <zyga> instead of top-levels
[11:02] <zyga> ?
[11:03] <mborzecki> zyga: hm that discussion would need to involve the whole team probably
[11:03] <zyga> yes
[11:03] <mborzecki> zyga: can you bring it up during the standup maybe?
[11:03] <zyga> today is not the best moment because pedronis will be off
[11:04] <zyga> and mvo's last day this year
[11:04] <zyga> but next year sure
[11:04] <zyga> nothing urgent
[11:04] <mborzecki> januarny then :) new year resolution
[11:04] <zyga> mborzecki: +1 with the request to make selinux probe lazy
[11:04] <zyga> haha, sounds good :)
[11:04] <zyga> I'd love to shuffle the apparmor package around
[11:04] <zyga> have one pkg/apparmor
[11:04] <zyga> and use it from release and interfaces/apparmor
[11:14] <zyga> brb
[11:25]  * pstolowski lunch
[11:26] <mup> PR core18#100 closed: static: add missing /lib/udev/rules.d/66-snapd-autoimport.rules <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core18/pull/100>
[11:39] <zyga> re
[11:42] <ackk> hi, I'm trying to build a snap in jenkins, when I run "snapcraft --destructive-mode" it fails with no output at all. tried --debug as well, still no output. how can I debug further? if I access the jenkins slave and run the comand as the same user it works
[11:50] <mup> PR core18#99 closed: static: add snapd.seeded.service to core18 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core18/pull/99>
[11:52] <zyga> pedronis: updated https://github.com/snapcore/snapd/pull/6190
[11:52] <mup> PR #6190: overlord/configstate,features: expose features to snapd tools <Created by zyga> <https://github.com/snapcore/snapd/pull/6190>
[12:05] <zyga> mvo: is this useful for you or can I re-trigger? https://www.irccloud.com/pastebin/WSgr3x1G/
[12:14] <mvo> zyga: kill it, I think this is understood now, the next core18 should have a fix
[12:15] <zyga> thank you
[12:34] <zyga> mborzecki: another small cleanup from my pile https://github.com/snapcore/snapd/pull/6293
[12:34] <mup> PR #6293: cmd/snap-confine: remove unused sc_discard_preserved_mount_ns <Per-user mount ns  🐎> <Created by zyga> <https://github.com/snapcore/snapd/pull/6293>
[12:35] <zyga> removing dead code
[12:35] <zyga> mborzecki: and if you have a sec, this is green too :-) https://github.com/snapcore/snapd/pull/6278
[12:35] <mup> PR snapd#6293 opened: cmd/snap-confine: remove unused sc_discard_preserved_mount_ns <Per-user mount ns  🐎> <Created by zyga> <https://github.com/snapcore/snapd/pull/6293>
[12:35] <mup> PR #6278: cmd/snap: modularize snap list processing <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/6278>
[12:35] <zyga> Chipaca: ^ if you ack this I'll feel better asking for it to be merged
[12:42] <Chipaca> zyga: I looked at that yesterday, I wanted to talk with you about it
[12:42] <Chipaca> or was it Monday i looked at it
[12:42] <zyga> sure
[12:42] <Chipaca> anyway
[12:42] <Chipaca> zyga: how is that "modularised"?
[12:42] <zyga> it's easier to make changes without editing those pesky long lines :)"
[12:43] <Chipaca> zyga: +1 for doing that to the header
[12:43] <Chipaca> zyga: the rows, I'm not sure it's a win vs what's there
[12:43] <zyga> Chipaca: or maybe going full in
[12:43] <zyga> and having a struct column {  name string, value func(...) }
[12:45] <pedronis> zyga: I +1ed  6190 with a comment, it needs a 2nd review as well
[12:46] <zyga> pedronis: thank you, I can remove the snap name from that patch set to avoid any controversy and let it move on
[12:46] <zyga> who do you think should perform the 2nd review?
[12:47] <pedronis> no strong preference on that
[12:47] <Chipaca> zyga: as it stands, i'm -1 on that pr, fwiw
[12:47] <mborzecki> Chipaca: zyga: fwiw i'd prefer to use the template engine there
[12:48] <Chipaca> zyga: but I'll admit I might be missing the point
[12:48] <Chipaca> mborzecki: does the template engine handle alignment?
[12:48] <zyga> Chipaca: if you think that's not the way forward, let's then close it
[12:48] <mborzecki> idk, needs checking
[12:48] <zyga> it was a small thing I wanted to explore
[12:48] <Chipaca> mborzecki: I think it doesn't :-)
[12:48] <pedronis> mborzecki: we had a PR about that
[12:48] <zyga> as you know :)
[12:48] <zyga> but not essential
[12:48] <pedronis> and it went in circles
[12:49] <mborzecki> ah
[12:49] <mborzecki> haha
[12:49] <pedronis> I have an ongoing discussion with Chipaca about what to do with our output more in general
[12:49] <pedronis> but next year stuff at this point
[12:49] <Chipaca> pedronis: which reminds me, was that topic post all you hoped for, or did I miss the point?
[12:50] <pedronis> Chipaca: it touches the right things, I don't agree 100% with the conclusion, as I just said, I plan to get back to it
[12:50] <pedronis> is not top priority right now
[12:50] <pedronis> (because so many things)
[12:50] <Chipaca> agreed about so-many-things
[12:50] <pedronis> Chipaca: I tought I mentioned this already with you
[12:50] <Chipaca> but yeah, not completely happy with it myself
[12:50] <pedronis> but maybe I didn't
[12:50] <Chipaca> pedronis: maybe you did, i'm dropping packets myself
[12:52] <zyga> Chipaca, mborzecki: I need a 2nd review on https://github.com/snapcore/snapd/pull/6190
[12:52] <mup> PR #6190: overlord/configstate,features: expose features to snapd tools <Created by zyga> <https://github.com/snapcore/snapd/pull/6190>
[12:54] <pedronis> I think Chipaca is off today, no?
[12:55] <Chipaca> I am
[12:55] <zyga> Chipaca: oh, sorry then
[12:55] <Chipaca> no worries
[12:55] <zyga> Chipaca: what are you doing here dear sir?
[12:55] <Chipaca> happy to chat
[12:56] <Chipaca> zyga: chatting with friends?
[12:56] <Chipaca> but maybe also having lunch
[12:56] <zyga> Chipaca: btw, watching parliament TV is interesting
[12:56] <Chipaca> hah, today it might be yes
[12:56] <zyga> Chipaca: fair enough, I do that myself more often than not :)
[12:56] <zyga> Chipaca: 8PM is it?
[12:56] <Chipaca> although they behave like badly-mannered school children
[12:57] <zyga> I beg to differ, they behave like well taught, kindly speaking, badly mannered school children
[12:57] <Chipaca> you forgot pompous, pretentious, and pedantic
[12:57] <Chipaca> and probably other things that start with P
[12:58] <zyga> "my right and honourable friend the douchebag"
[12:58] <zyga> ;-)
[12:58] <zyga> still
[12:58] <zyga> that sentence is far better than typical time-squandering insults I hear from the benches in our own government
[13:01] <pedronis> zyga: I closed that PR btw
[13:01] <mup> PR snapd#6278 closed: cmd/snap: modularize snap list processing <Simple 😃> <Created by zyga> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/6278>
[13:01] <pedronis> with comment
[13:02] <zyga> +1
[13:09] <pedronis> mborzecki: are you exploding and cleaning up6238 in smaller PRs, is that right?
[13:09] <pedronis> #6238
[13:09] <mup> PR #6238: [WIP] many: add minimal SELinux support, refactor the policy <SELinux> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6238>
[13:09] <mborzecki> pedronis: yes, all the PRs tagged with selinux label are about that
[13:09] <zyga> some more test woes
[13:09] <zyga> https://www.irccloud.com/pastebin/z2HoQxdq/
[13:09] <zyga> https://api.travis-ci.org/v3/job/466903966/log.txt is full of that
[13:09] <zyga> not sure what to make of this
[13:10] <zyga> away, I was meaning to take a break for coffee / dog
[13:10] <zyga> cachio: if you are around, could you have a look?
[13:12] <cachio> zyga, hey
[13:12] <cachio> sure
[13:12] <cachio> zyga, nice error
[13:13] <zyga> perhaps that's the same issue that mvo is fighting
[13:13] <zyga> with seeding
[13:15] <cachio> zyga, is it happening on master?
[13:20] <zyga> I don't know, I've seen this error today before but perhaps on this branch as well
[13:22] <mborzecki> i have a feeling that the spread jobs only succeed by acccident, and the default state of things is to fail
[13:25] <pedronis> pstolowski: I +1ed #6180 with some final comments
[13:25] <mborzecki> ever seen a failure like this? https://api.travis-ci.org/v3/job/466929872/log.txt
[13:25] <mup> PR #6180: snap/info: bind global plugs/slots to implicit hooks <Created by stolowski> <https://github.com/snapcore/snapd/pull/6180>
[13:26] <cachio> zyga, last error on master for core18 on degraded test is the same than mvo is working I think
[13:27] <zyga> thank you
[13:27] <cachio> zyga, snapd.seeded service failed to start
[13:27] <pstolowski> pedronis: thanks
[13:27] <cachio> zyga, I'll try to reproduce this one
[13:29] <pedronis> zyga: the gpio enable/disable fix we did only for 2.37 in the end, right?
[13:40] <ackk> does anyone run snapcraft in jenkins?
[13:45] <thresh> ackk, I do for VLC, why
[13:46] <ackk> it seems snapcraft doesn't handle well non-interactive shells
[13:46] <ackk> I'm running it on a slave via ssh
[13:46] <thresh> it does show quite a bit of output
[13:46] <ackk> I had to snapcraft | cat, otherwise I don't get any output
[13:46] <ackk> but it seems now the yarn plugin fails, I suspect because it doesnt' use --non-interactive when calling yarn
[13:46] <thresh> oh?
[13:47] <thresh> I definitely do not do it :)
[13:49] <thresh> ah, "Allocate a pseudo-TTY" is checked for that particular docker container I use to build VLC snap in
[13:49] <thresh> so probably that's hwy
[13:50] <ackk> mhm I wonder if I can do something like that
[13:50] <pedronis> mborzecki: did a pass on #6285
[13:50] <ackk> thresh, do you use a custom image to build with snapcraft in docker?
[13:50] <thresh> ackk, yeah
[13:50] <mup> PR #6285: selinux: package to query SELinux status and verify/restore file contexts <SELinux> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6285>
[13:51] <mborzecki> pedronis: thanks!
[13:52] <thresh> ackk, https://code.videolan.org/videolan/docker-images/blob/master/vlc-ubuntu-xenial/Dockerfile and https://code.videolan.org/videolan/docker-images/blob/master/videolan-base-xenial/Dockerfile
[13:52] <ackk> thresh, ah yeah we can't use docker like that since we're using jenkins-job-builder and you can't really pass a dockerfile that way
[13:53] <thresh> surely you can pass the image
[13:53] <thresh> but I doubt vlc's one will be handy
[13:53] <zyga> Yes pedronis
[13:54] <pedronis> thx
[13:56] <pedronis> mvo: have you seen that core18 is also red?
[13:57] <pedronis> mvo: I mean,  https://github.com/snapcore/core18/commits/master
[13:57] <pedronis> sorry
[13:57] <ackk> thresh, yeah we currently have a (container) slave dedicated to it, but because of this issue it's failing to build
[13:58] <mvo> pedronis: yes :(
[14:00] <mvo> cachio, degville zyga, mborzecki, pstolowski I can't join the standup today, have a conflicting meeting
[14:00] <thresh> ackk, do you have templates defined in your docker jenkins plugin?  or it works some other way?
[14:00] <cachio> mvo, np
[14:01] <ackk> thresh, no we're not using docker at the moment. but I didn't know you could do that
[14:02] <ackk> thresh, where we use docker, we have a pipeline with a Dockerfile in the repo, which is used by the corrsponding Jenkinsfile
[14:02] <thresh> I wouldnt recommend my way :)
[14:02] <thresh> I'm slowly migrating all that crap to gitlab ci atm
[14:18] <mup> PR core18#101 opened: static: add missing systemd symlinks <Created by mvo5> <https://github.com/snapcore/core18/pull/101>
[14:22]  * cachio afk
[14:23] <mup> PR core18#101 closed: static: add missing systemd symlinks <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/core18/pull/101>
[14:28] <mup> PR snapd#6292 closed: spread: record each tests/upgrade job <Simple 😃> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6292>
[14:28] <mborzecki> zyga: pushed a smarter way of relabeling to https://github.com/snapcore/snapd/pull/6265
[14:28] <mup> PR #6265: cmd/snap: attempt to restore SELinux context of snap user directories <SELinux> <⛔ Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6265>
[14:29] <mborzecki> zyga: the relevant changes are in cmd/snap/cmd_run*
[14:29] <zyga> Ack
[15:28]  * cachio lunch
[15:39] <mup> PR snapd#6289 closed: cmd/snap-confine: remove SC_NS_MNT_FILE <Simple 😃> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6289>
[15:39] <zyga> mborzecki: hey
[15:39] <zyga> mborzecki: quick review request for -55,+0 in 6293
[15:44] <pstolowski> pedronis: do you have a moment for HO? i've some observations & interesting log about task runner
[16:15] <ackk> sergiusens, I see that the multipass provider passes user-data.yaml to multipass when building, is there a way to inject cloud-init configs in there?
[16:18] <kyrofa> noise][, can I use a brand store in classic Ubuntu?
[16:23] <sergiusens> ackk there is not
[16:23] <ackk> sergiusens, I see, thanks
[16:28] <noise][> kyrofa, yes that can be done
[16:29] <kyrofa> noise][, how?
[16:30] <noise][> same as with core basically, you need a model
[16:31] <kyrofa> You can have a model assertion on classic? How is that setup?
[16:33] <pedronis> pstolowski: was having a break, now back but it's a bit late, we should talk tomorrow morning I suppose
[16:34] <pstolowski> pedronis: ok, makes sense
[16:37] <noise][> kyrofa, yes - e.g. do `snap known model` on your classic system. Not sure if we have good docs for setting that up, maybe pedronis would know
[16:38] <pedronis> you can but is fixed unless you make your own image (which there is no simple tooling for for that case), until we introduce remodeling
[16:39] <pedronis> and decide what is possible
[16:40] <kyrofa> Interesting, okay, thanks
[16:50] <pedronis> pstolowski: I answered your question in 6180
[16:51] <pstolowski> pedronis: aha!
[16:51] <pstolowski> thx
[17:00] <zyga> pedronis: FYI https://github.com/snapcore/snapd/pull/6294 is super special experiment, let's see if it passes
[17:00] <mup> PR #6294: packaging/ubuntu: build with golang 1.10 <Core18> <Created by zyga> <https://github.com/snapcore/snapd/pull/6294>
[17:00] <mup> PR snapd#6294 opened: packaging/ubuntu: build with golang 1.10 <Core18> <Created by zyga> <https://github.com/snapcore/snapd/pull/6294>
[17:01] <mup> PR snapcraft#2424 closed: nodejs plugin: fail gracefully when a package.json is missing <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2424>
[17:02] <pedronis> zyga: are blocked?
[17:02] <pedronis> *are you blocked?
[17:02] <zyga> pedronis: no, not at the moment :)
[17:02] <zyga> pedronis: only by master being flaky
[17:02] <pedronis> zyga: we just discussed that indeed we want to switch to 1.9 or 1.10
[17:02] <pedronis> but for 2.38
[17:02] <pedronis> I mean with mvo
[17:02] <zyga> pedronis: this is an experiment to see if this could help with core 18 issue that I discussed with mvo
[17:03] <zyga> to see if there's a long term better way to do something
[17:25] <mup> PR core18#102 opened: static: run snapd for the first time with systemd-run <Created by mvo5> <https://github.com/snapcore/core18/pull/102>
[17:30]  * cachio afk
[17:51]  * zyga afk
[18:43] <mup> PR core18#102 closed: static: run snapd for the first time with systemd-run <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core18/pull/102>
[18:43] <mup> PR snapd#6103 closed: tests: split nested vm suite on core and classic and new snapshots test <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6103>
[18:45] <mup> PR snapd#6295 opened: systemd: start snapd.autoimport.service in --no-block mode <⚠ Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6295>
[18:49] <mup> PR snapd#5714 closed: tests: new test for cifs-mount interface <⛔ Blocked> <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5714>
[18:50] <cachio> zyga, I was reviewing upgrade test suite and I think it is important to run in every PR
[18:50] <zyga> cachio: I didn't want to change that
[18:50] <mup> PR core18#103 opened: static: add missing systemd symlinks <Created by mvo5> <https://github.com/snapcore/core18/pull/103>
[18:50] <zyga> cachio: I wanted it to run on separate VMs
[18:50] <zyga> by starting spread with update suite separately
[18:51] <zyga> mvo: hey
[18:51] <zyga> back?
[18:51] <mvo> zyga: yes
[18:51] <cachio> zyga, ahh, ok, so run that suite first in the vm?
[18:51] <zyga> cachio: no
[18:51] <cachio> just run that suite on the vm?
[18:51] <zyga> really, just spread -v foo:tests/upgrade
[18:51] <mvo> zyga: I think the open PRs things should be good again, but I'm trying now
[18:52] <zyga> and spread -v tests:/everything-but-upgrade
[18:52] <zyga> separate invocations of spread
[18:52] <zyga> what are the symlinks for mvo?
[18:52] <zyga> ah
[18:52] <zyga> wanted!
[18:53] <zyga> mvo: so we need new snapd release?
[18:53] <cachio> zyga, ok, so first everything-but-upgrade and then upgrade is ok?
[18:54] <zyga> cachio: you can even run them in parallel
[18:54] <zyga> spread foo &
[18:54] <zyga> spread bar &
[18:54] <zyga> wait
[18:54] <mvo> zyga: yes
[18:54] <cachio> zyga, sorry, I don't see how that helps
[18:54] <zyga> cachio: it makes it faster
[18:55] <zyga> cachio: separately invoked spread will not reuse any vms
[18:55] <pedronis> mvo: I'm working on the retry PR btw
[18:55] <zyga> and foo and bar above were selectors needed to run the update suite vs other stuff
[18:56] <cachio> zyga, adding more workers shouldn't help to make that faster?
[18:56] <zyga> cachio: not really
[18:56] <zyga> cachio: starting parallel work in parallel will
[18:57] <mvo> pedronis: \o/
[18:57] <zyga> cachio: do you understand what I'm trying to achieve?
[18:57] <cachio> because if we have 1 maniche which has to prepare the suite, build snapd and then run just 2 tests, then the instance spending to much time preparing compare with running tests
[18:58] <cachio> zyga, not really
[18:58] <cachio> zyga, well you said "run faster"
[18:58] <zyga> cachio: running update suite separately will prevent intermixing it with other suites, we have plenty of issues as is so this is a simple low cost solution to avoiding some
[18:58] <Son_Goku> zyga, what distros do we have left that offer golang < 1.10?
[18:59] <zyga> cachio: running spread twice will need to wait for the first run to finish before starting the first run
[18:59] <zyga> cachio: so the suggestion was to run spread foo &; spread bar &; wait;
[18:59] <zyga> cachio: to start two runs in parallel on two sets of machines
[18:59] <zyga> cachio: does that make sense?
[19:00] <zyga> Son_Goku: nothing, this is just about building with newer golang in ubuntu
[19:00] <cachio> zyga, what will happen with the logging?
[19:00] <cachio> zyga, it could be very confusing
[19:00] <zyga> cachio: it will be sent to stdout, you can obviously redirect it and cat both logs in the end
[19:00] <zyga> cachio: it could also be very sensible :) it depends on how it is done
[19:01] <zyga> cachio: master being broken because of things we don't understand every day is worse than confusing
[19:02] <mup> PR core18#104 opened: static: snapd.seeded.service needs the right After= dependency <Created by mvo5> <https://github.com/snapcore/core18/pull/104>
[19:02] <mvo> zyga: ^- one more trivial one
[19:03] <zyga> yeah, makes sense
[19:03] <mvo> ta!
[19:03] <cachio> zyga, ok, I get the idea but I am not sure running in parallel is the best solution, I'll see if there is another way to force the upgrade suite to run in a separeta vm
[19:04] <cachio> zyga, perhaps to add a new backend attached to the suite
[19:04] <cachio> something like
[19:04] <cachio> spread google: google-upgrade:
[19:05] <cachio> so we have a single spread run
[19:06] <cachio> and single spread logs
[19:07] <cachio> zyga, does it make sense?
[19:07] <mup> PR snapcraft#2425 opened: snap: re-add pyc files for snapcraft <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2425>
[19:08] <pedronis> mvo: pushed
[19:09] <mup> PR core18#104 closed: static: snapd.seeded.service needs the right After= dependency <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core18/pull/104>
[19:09] <mvo> cachio: we need one more commit, building now
[19:12] <cachio> mvo, good
[19:13] <zyga> cachio: yes it does
[19:13] <pedronis> #6287 needs 2nd reviews, now it also code by me
[19:13] <mup> PR #6287: httputil: retry on temporary net errors <Squash-merge> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6287>
[19:27] <zyga> mvo: we need one more patch for 2.36
[19:28] <pedronis> core18 CI failures look a bit messy:  https://api.travis-ci.org/v3/job/467148384/log.txt
[19:29] <mup> PR snapd#6296 opened: tests: new backend used to run upgrade test suite <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6296>
[19:29] <pedronis> zyga: ?
[19:30] <zyga> pedronis: we broke fedora, one sec
[19:30] <mvo> zyga: which one?
[19:30] <zyga> mvo: maciej is making the patch
[19:31] <mborzecki> evenin
[19:31] <zyga> https://bugzilla.redhat.com/show_bug.cgi?id=1658152
[19:32] <zyga> hey
[19:32] <zyga> it seems that we need one ' to fix it
[19:32] <zyga> ideal for 2.36
[19:32] <cachio> zyga, #6296
[19:33] <mup> PR #6296: tests: new backend used to run upgrade test suite <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6296>
[19:33] <cachio> let's see
[19:33] <zyga> super, thanks
[19:33] <zyga> let's see how this behaves
[19:33] <mborzecki> zyga: Pharaoh_Atem: https://github.com/snapcore/snapd/pull/6297
[19:33] <mup> PR #6297: data/selinux: fix syntax error in definition of snappy_admin interface <SELinux> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6297>
[19:33] <cachio> mvo, core18 rev 491 is the one I should test?
[19:34] <cachio> it is on beta now
[19:34] <mup> PR snapd#6297 opened: data/selinux: fix syntax error in definition of snappy_admin interface <SELinux> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6297>
[19:35] <mborzecki> zyga: ^^
[19:36] <zyga> mborzecki: are the whitespace changes deliberate?
[19:37] <mborzecki> zyga: not necessary, but made it look like the rest of the code there which is using tabs for indentation
[19:37] <zyga> +1
[19:38] <mvo> cachio: I think this will be a step forward
[19:38] <mvo> but there is one more thing I'm looking at :(
[19:41] <zyga> mvo:  ^ can we cherry pick that into 2.36
[19:42] <mvo> zyga: yes, please mark it
[19:42] <zyga> it's marked
[19:42] <zyga> thank you
[19:45] <zyga> hmm, I log into FAS and yet bugzilla thinks I'm not logged in
[19:45] <zyga> eh
[20:01] <cachio> mvo, last core18 from beta work much better
[20:01] <cachio> could not reproduce the error anymore
[20:02] <mvo> cachio: that sounds very encouraging
[20:03] <zyga> degville: it's almost time
[20:20] <mvo> fwiw, I updated 6243 while waiting for tests but not urgent
[20:20] <pedronis> cachio: mvo: encouraging/good
[20:21] <cachio> pedronis, mvo tests are going well so far
[20:23] <mvo> cachio: cool
[20:24] <degville> thanks for the reminder zyga :) I reckon she'll make it through to the next level.
[20:31] <pedronis> mvo: that change in 6243 seems in the right direction, but copying mutexes by value is not supported afaik and go vet should be unhappy, it will need tweaking
[20:31] <pedronis> (go vet was unhappy here when I tried something like that)
[20:32] <pedronis> cachio: another run dying without actually starting tests: https://api.travis-ci.org/v3/job/467159346/log.txt
[20:32] <pedronis> this was the selinux PR
[20:32] <pedronis> for 2.36
[20:33] <cachio> pedronis, taking a look
[20:34] <cachio> pedronis, this failed on 1 test
[20:34] <cachio> google:ubuntu-core-16-64:tests/main/ubuntu-core-upgrade
[20:35] <pedronis> it didn't reboot?
[20:37] <cachio> pedronis, mmmm, I think it lost connection on reboot
[20:37] <cachio> pedronis, ot os weord
[20:37] <cachio> weird
[20:39] <mvo> pedronis: oh, I thought I did pointers, maybe I was dreaming
[20:40] <cachio> pedronis, perhaps it is related to the error on spread rebooting machines
[20:41] <cachio> pedronis, it is not returning from the reboot
[20:42] <cachio> I'll try  to reproduce it
[20:46] <mvo> pedronis: aha, I see what you mean now. do we actually copy this backend around? I thought we only had a single one, let me look at the code
[20:47] <mvo> pedronis: (maybe I'm just tired :)
[20:58] <pedronis> mvo: the methods on it are by value, so yes, in principle is copied
[20:58] <pedronis> before it was an empty struct so didn't matter
[20:58] <pedronis> much either way
[21:02] <cwayne> mvo: cachio core18 498/497 looks good from our end
[21:03] <cachio> cwayne, nice
[21:03] <pedronis> mvo: so retry logic is not working on arch
[21:03] <pedronis> even newer go?
[21:03] <mvo> pedronis: indeed, I was a bit blind, updated it
[21:03] <mvo> cwayne: thanks, great to hear
[21:03] <mvo> pedronis: oh, I have no idea, let me look at arch
[21:04] <cachio> cwayne, mvo I see 494 on beta
[21:04] <pedronis> mvo: https://api.travis-ci.org/v3/job/467160635/log.txt  also the setup of the test doesn't work on core
[21:04] <cwayne> cachio: armhf/arm64
[21:04] <mvo> cwayne: \o/
[21:04] <cachio> ahh, ok
[21:04] <mvo> pedronis: aha, yes, I think its ok to blacklist core for this test
[21:04] <cwayne> cachio: dont have an x86 device for core18 yet
[21:04] <cachio> cwayne, nice
[21:05] <cachio> mvo, do we need to cover all the architectures for core18?
[21:05] <pedronis> mvo: mv: cannot move '/etc/resolv.conf' to '/etc/resolv.conf.save': Read-only file system
[21:05] <mvo> cachio: yes, eventually, not tonight though
[21:05] <mvo> pedronis: exactly
[21:06] <pedronis> mvo: we can move the file it points to no?
[21:06] <cachio> mvo, ok
[21:07] <mvo> pedronis: yes
[21:07] <pedronis> maybe
[21:07] <pedronis> it just feels strange to skip on core if possible
[21:07] <mvo> pedronis: I think on arch we get "Temporary failure in name resolution" :(
[21:08] <pedronis> but IsTemporary is not set?
[21:08] <mvo> pedronis: it looks like it is not which is ironic given the error text
[21:08] <pedronis> what go does it have?
[21:08] <mvo> pedronis: I try to figure that out now but I don't see it in the output, I may need to run spread with it
[21:09]  * mvo runs in google to find out
[21:13] <pedronis> mvo: seems it might be a cgo error actually
[21:14] <pedronis> so maybe maciej was right, and it's used sometimes
[21:14] <zyga> re
[21:14] <zyga> it seems it's not EOD, or EOY yet
[21:16] <mvo> pedronis: yeah, will you add code to detect it or shall I?
[21:16] <mvo> zyga: not quite
[21:18] <mvo> pedronis: anyway,I can check tomorrow in my morning, I think I need some sleep :) thanks for all your help (and to you zyga,cachio and cwayne as well!)
[21:18] <pedronis> mvo: yes, it's a bit late to try to fix this
[21:18] <pedronis> I'm also not sure how stable/where that message exactly comes from
[21:18] <pedronis> go runtime code? resolver code?
[21:18] <mvo> pedronis: arch has go1.11.2 fwiw
[21:19] <mvo> pedronis: I suspect resolver but we can dig into it tomorrow (grep -r glibc- :)
[21:19] <pedronis> I suspect the same
[21:19] <pedronis> also calling it a day
[21:19] <mvo> pedronis: ttfn!
[21:19] <zyga> mvo: gai error
[21:20] <zyga> I’m on the phone now
[21:20] <cachio> mvo, good sleep
[21:20] <cachio> mvo, see you tomorrow
[21:22] <mvo> cachio: see you
[21:22] <mvo> zyga: gai?
[21:25] <pedronis> anyway seems indeed from libc
[21:39] <zyga> pedronis: yes, the error is from https://linux.die.net/man/3/gai_strerror
[23:13] <mup> PR snapd#6180 closed: snap/info: bind global plugs/slots to implicit hooks <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6180>


[02:52] <AfC> Hi
[05:05] <jelmer> Amoz: that issue should be fixed in unstable
[07:09] <vivekimsit1> Hii, Everyone :)
[07:10] <vivekimsit1> I am new to bazaar and looking forward to use it for and my projects, But first of all I want that there are some existing projects which I would like to convert into the bazaar repository but when I do bzr init-repo it creates a new repository!
[07:26] <lifeless> vivekimsit1: hi, that is what init-repo is meant to do. What were you expecting ?
[07:26] <vivekimsit1> lifeless: init-repo is creating a new dir!
[07:28] <vivekimsit1> lifeless: but I want that the I have one project folder already and I would like to convert it into the bzr repo
[07:29] <lifeless> 'bzr init' on its own will bzr-ise an existing directory
[07:35] <vivekimsit1> lifeless: ok! let me conform, Go to the existing directory run the command bzr init inside it and this will make the parent directory a bazaar repo..! am i right?
[07:39] <lifeless> yes; you might like to read the manual, it give a guided introduction
[07:40] <lifeless> vivekimsit1: e.g. http://doc.bazaar.canonical.com/latest/en/user-guide/starting_a_project.html
[07:46] <vivekimsit1> lifeless:Thanks :)
[08:33] <vivekimsit1> How can I know how many repositories I have
[08:33] <vivekimsit1> or how to see the list of all the repos
[08:36] <wilx> repositories are just directories
[08:36] <wilx> If you want to bzr'ize a single directory, that means you will want to create a stand alone branch.
[08:36] <wilx> Just cd ~/mycode and then bzr init .
[08:36] <wilx> bzr add .
[08:36] <wilx> bzr commit .
[08:36] <wilx> Done.
[08:37] <wilx> I am pretty sure the basics are well enough described in the docs.
[09:50] <vivekimsit1> Is there any doc related to launchpad?
[10:02] <wilx> help.launchpad.net
[10:02] <wilx> ?
[10:24] <vivekimsit1> ok'
[10:59] <goddard> can some one explain something to me
[11:00] <goddard> if I am creating a new branch and then I use bzr-upload
[11:00] <goddard> it will upload that branch
[11:00] <goddard> what happens if i create a new branch?
[11:35] <wilx> goddard: Then you will have two? :)
[11:35] <wilx> I have never tried bzr-upload.
[11:36] <wilx> I see, it is pure copy upload.
[11:37] <wilx> Why don't you use bzr branch/push instead?
[18:06] <Amoz> jelmer: so that issue is already taken care of? will it be automatically synced to build in LP?
[19:21] <M-Boy> Hello all
[19:22] <M-Boy> is there somewhere I can chat with ?
[19:22] <M-Boy> someone*
[19:22] <M-Boy> sorry
[19:22] <jelmer> hi
[19:22] <M-Boy> for instance; I know the "don't ask to ask" rule but every time I come over and just ask I see all people are dead so am checking first ^^
[19:22] <M-Boy> Hi jelmer what up ?
[19:22] <M-Boy> I mean how are you...
[19:23] <jelmer> alright, how are you?
[19:23] <jelmer> Amoz: hi
[19:23] <jelmer> Amoz: let mec heck
[19:24] <M-Boy> jelmer, I got a straight forward question. I am looking for a "tool" that would replace the linux shell in order to administrate and manage bazaar branches :/
[19:25] <jelmer> M-Boy: what do you mean with replace the shell, what would you like to do?
[19:25] <M-Boy> launchpad is a hell therefore I cannot really manage to clone it on my private server, hence I am looking for something else
[19:25] <M-Boy> jelmer, let's see I have set up a quick dev environement for a team of 3 developers
[19:26] <M-Boy> we have agreed on a straight forward version control workflow: Local branches map on remote branches + 1 remote branch (so called mainline) for global merges
[19:26] <M-Boy> the issue is that we keep struggling with permissions...
[19:26] <M-Boy> I litteraly spent the whole afternoon trying to figure out how to achieve the best organization but each time I keep fighting with folders' permissions
[19:41] <M-Boy> jelmer, any advice?
[19:43] <jelmer> M-Boy: what have you set up exactly?
[19:43] <jelmer> M-Boy: how are you sharing the branches?
[19:43]  * jelmer back in ~15 min
[19:45] <M-Boy> jelmer, I am using bzr+ssh
[19:45] <M-Boy> I simply created /bazaar/project_repositoru/branches...
[20:25]  * jelmer is back
[20:26] <jelmer> M-Boy: you might want to adjust the permission mask that's used for those users
[20:26] <jelmer> so that the group automatically gets write access to new files
[20:26] <M-Boy> jelmer, so there is nothing that does this for me through a simple user interface for example?
[20:27] <M-Boy> i only found bazaar explorer and it doesn't
[20:32] <wilx> Can I remove an entire branch on bzr+ssh:// repo?
[20:32] <wilx> Remotely.
[20:45] <M-Boy> nvm
[20:45] <M-Boy> see ya
[20:52] <jelmer> wilx: yes, "bzr rmbranch" can do that
[21:53] <kbulgrien> say I want to have --no-recurse whenever I add a directory.  Is there an easy way to set stuff like that up?
[21:56] <Kamping_Kaiser> kbulgrien: you can add aliases to ~/.bazaarbazaar.conf
[22:00]  * kbulgrien reading up on alias
[22:01] <kbulgrien> bleah. As with other VCS, don't much care for personal alias because it makes you not know how to do things native.
[22:02] <kbulgrien> If I go somewhere my aliases aren't set up, that is a pain.  I'd rather know how to do it without an alias.
[22:02] <kbulgrien> (It's also a pain that --no-recurse has no shortcut)
[22:04] <kbulgrien> Tho I guess its the same if I have to do something else to set up a different default.
[22:20] <jelmer> kbulgrien: I guess we could add a short option for it, but I think it's generally not used very often
[22:22] <AfC> jelmer: I'd vote for a short option; --no-recurse is something I use a great deal and yeah, it's a pain to type.
[22:23] <kbulgrien> Use it heavily ... coming to bzr from other vcs, this is a great pain.
[22:24] <kbulgrien> It at least needs a short option, IMO.
[22:24] <jelmer> is this --no-recuse for 'bzr ls', 'bzr add', 'bzr status' or all?
[22:24] <AfC> jelmer: I personally am describing my use of add
[22:25] <kbulgrien> Mostly add is where it bugs me the most.
[22:25] <kbulgrien> but if added, I'd probably vote for consistency.
[22:26] <jelmer> yeah, I agree if we add it we should add it consistently
[22:26] <AfC> jelmer: my complaint is that in the case of add (one of your first experiences with bzr,) would be more along the lines that most Unix commands require you to specify ls -R or grep -r to make it recursive.
[22:26] <AfC> jelmer: but it is what it is
[22:27] <kbulgrien> AfC: I agree
[22:27] <jelmer> AfC: I think one of the issues there is also that all other VCS tools seem to be recursive by default
[22:27] <jelmer> and other bzr commands are recursive by default
[22:27] <kbulgrien> jelmer: also agree, but short option then.
[22:28] <AfC> jelmer: {shrug} then bzr has to be. Put another way, bzr was recursive before any of the others :)
[22:28] <jelmer> bug 945904
[22:28] <jelmer> AfC: not before svn (or CVS?)
[22:28] <AfC> modern 3rd generation DVCSen
[22:28] <kbulgrien> CVS was recursive, but not for add
[22:28] <kbulgrien> of directory
[22:28] <kbulgrien> recursive add of all directory contents is bad imo
[22:28] <kbulgrien> very bad
[22:29] <kbulgrien> recursive for anything I'm largely okay with.
[22:29] <kbulgrien> (else)
[22:29] <kbulgrien> but to add new stuff recursively to the vcs is a big giant pain more often than not.
[22:30] <jelmer> why would you have non-versioned and non-ignored files under a VCS directory?
[22:30] <kbulgrien> many reasons
[22:30] <AfC> jelmer: it's incremental;
[22:30] <AfC> jelmer: as you're building a new project
[22:31] <AfC> jelmer: you add a little bit at a time; and I am constantly surprised that "oops!" it went deep.
[22:31] <kbulgrien> exactly
[22:31] <AfC> jelmer: especially when you're being careful trying to add the bits you know you should have under version control
[22:31] <kbulgrien> now try to vcs your OS
[22:31] <kbulgrien> bzr add etc
[22:31] <kbulgrien> oh crap
[22:31] <AfC> jelmer: the END RESULT is yes, you might have added everything, but that's not a conclusion you immediately come to
[22:32] <AfC> jelmer: also things like "yes, I should add the log/ directory as an empty stub... ooops, oh crap"
[22:32] <AfC> anyway
[22:32] <kbulgrien> AfC: you and I think alike.  yes. stubs is another reason.
[22:33] <AfC> I doubt you will be able to change the default behaviour, but a short alias would indeed be lovely.
[22:33] <jelmer> AfC: bug 945904
[22:33] <AfC> jelmer: already subscribed :)
[22:37] <kbulgrien> svn is -N for the same thing
[22:37] <kbulgrien> not that I think we should copy svn
[22:37] <kbulgrien> btw, lest it be seen I popped in to complain, I have been looking for new vcs for a long time. bzr is it.
[22:37] <AfC> kbulgrien: it's a good choice.
[22:37] <jelmer> ... and branch attached
[22:38] <jelmer> we just need to wait for a bzr reviewer to approve it now, and it will be in 2.6
[22:38] <kbulgrien> :-)
[22:38] <kbulgrien> Am slated to convert my work over sometime in not too distant future.
[22:40] <kbulgrien> of all the newfangled vcs, bzr is the most natural progression imo. All others have made me work to adopt. bzr just fits like a glove.  A bit uncomfortable, but just what it seems a vcs should be.
[22:42] <kbulgrien> uncomfortable primarily just like anything new with a lot of stuff in it is uncomfortable, not bad kind of discomfort.
[22:43] <AfC> kbulgrien: our contribution to getting people going on using bzr with our project was http://java-gnome.sourceforge.net/HACKING.html You might find some useful tidbits there.
[22:47] <kbulgrien> bookmarked
[22:49] <kbulgrien> I tried git for a few weeks and borked things up several times while learning and it was hard all the way.  one night I tried to do something I was used to doing in another vcs.  After a long time I found git will not do it.
[22:49] <kbulgrien> I started reading and found probably hg wouldn't either.
[22:49] <kbulgrien> I d/l bzr and it was done in 15 minutes.
[22:49] <kbulgrien> None of the pain of git at all.
[22:50] <kbulgrien> I had never used distributed vcs before.
[22:50] <wilx> Hg and Bzr seem largly equal though.
[22:50] <kbulgrien> treating dirs as explicit versioned resources.
[22:51] <wilx> I have picked Bazaar over Mercurial mainly because the ecosystem seems stronger.
[22:51] <kbulgrien> hg didn't used to.  maybe they changed.
[22:53] <kbulgrien> i didn't even have to look in the manual... what I wanted to do "just worked" when I figured out what to type from built in help.


[02:59] <ace_suares> !seen ogra
[02:59] <ace_suares> You mean: I didn't see the command.
[02:59] <ace_suares> Or are you polish ?
[03:08] <mhall119> are you talking to the bot again?
[03:19] <sbalneav> Evening all
[03:33] <ace_suares> `bot?
[03:33] <ace_suares> what bot?
[03:33]  * ace_suares winks at Alan
[03:33] <sbalneav> The info bot running in the channel
[03:34] <ace_suares> cant we use the ltsp bot, that has the !seen command (ubottu has not)
[03:34] <ace_suares> Hey I am forfeiting a trip to a small uninhabited island tomorrow, so the meeting better be good!
[03:41] <sbalneav> Awwwwww
[03:42] <sbalneav> If it isn't, you gonna get your money back? :)
[03:42] <ace_suares> Just the tought of it being not, is making me reconsider :-)
[03:45] <sbalneav> What would make it NOT worth it, I wonder?
[03:45] <ace_suares> Low attendace, dwindling focus, multitasking...
[03:46] <sbalneav> Multitasking?
[03:47] <ace_suares> Yeah like playing warzone and debugging IO.string.jar and phoning your mom during the meeting
[03:48] <sbalneav> As for low attendence, even if everyone shows up, it's low attendance.
[03:48] <ace_suares> oh yah, i don't agree with that, work with wath you have eh.
[03:49] <ace_suares> I am going to watch some tedtalks. See you tamara!
[03:49] <sbalneav> If I make it.  I may be talking to my mom.
[03:51] <sbalneav> highvoltage: About?
[05:36] <alkisg> Good morning
[06:17] <highvoltage> good morning alkisg
[14:42] <sbalneav> Morning all
[14:43] <sbalneav> So, what time's the meeting today?
[14:46] <alkisg1> Hi sbalneav! 17:00 utc, wasn't it?
[14:47] <alkisg1> !date
[14:51] <sbalneav> !meeting
[14:51] <sbalneav> @schedule
[15:06] <highvoltage> heh, that was some time ago
[16:03] <ace_suares> man the meeting isnt even listed in the fridge
[16:04] <sbalneav> ace_suares: No-ones listed it there, I guess
[16:05] <ace_suares> sbalneav: logical, so locgical
[16:05] <sbalneav> Occam's razor is so very, very sharp :)
[16:06] <sbalneav> LaserJock usually handles a lot of the "administrivia" of Edubuntu.  Since he's in the process of moving, some of that sort of thing isn't getting done.
[16:08] <ace_suares> 17:00 utc is 13:00  GMT-4, right?
[16:10] <alkisg> ace_suares: give date -u in a terminal
[16:14] <ace_suares> Fri Aug 28 15:14:37 UTC 2009
[16:15] <ace_suares> and it's Fri Aug 28 11:15:00 AST 2009
[16:15] <ace_suares> so 4 hrs difference
[16:15] <ace_suares> 13+4=17
[16:15] <ace_suares> I added it to the fridge as in the wiki mentioned it doesn't show up yet
[17:30] <Svenstaro> Meeting in 30m?
[17:37] <sbalneav> Svenstaro: yep
[18:05] <Svenstaro> So meeting on?
[18:05] <sbalneav> Svenstaro: yes, in #ubuntu-meeing
[18:05] <sbalneav> meeting
[18:31] <mercurous23> hi everyone
[18:31] <mercurous23> i need some help
[18:32] <alkisg> !ask | mercurous23
[18:34] <mercurous23> i have problems with the quit button, it is just closing the toolbar without showing the logoff, shutdown and restart window.
[18:34] <sbalneav> This on a full desktop, or on a thin client?
[18:35] <mercurous23> full desktp
[18:38] <sbalneav> What happens if you hit control-alt-del?
[18:39] <mercurous23> it shows the shutdown options
[18:39] <mercurous23> it might be just the quit applet?
[18:40] <sbalneav> Could be.  Does this happen all the time, or after a reboot it's ok?
[18:42] <mercurous23> yes it happens all the time
[18:43] <sbalneav> Then I'd remove the app from the panel, and try re-adding it.
[18:43] <mercurous23> i already tried that
[18:44] <mercurous23> didnt solve it
[18:45] <sbalneav> Hm
[18:45] <alkisg> Does the logout dialog from the system menu work?
[18:45] <sbalneav> All your updates are up to date?
[18:45] <sbalneav> Sounds like some kind of dbus monkeyshines.
[18:46] <mercurous23> yes all are up to date
[18:46] <mercurous23> well i could just use the ctl-alt-del command to shutdown
[18:46] <sbalneav> Does alkisg's suggestion work?
[18:47] <mercurous23> yes it does work
[18:47] <sbalneav> Hm, so it's just the app on the panel, eh?
[18:47] <alkisg> mercurous23: do you mind resetting the panels? should I give you the command?
[18:47] <sbalneav> Weird.
[18:47] <mercurous23> okay
[18:47] <sbalneav> Yeah, that was what I was going to suggest next.
[18:48] <sbalneav> A --recursive-unset
[18:48] <alkisg> gconftool-2 --recursive-unset /apps/panel && killall gnome-panel
[18:50] <mercurous23> thank you guys it is working now
[18:50] <mercurous23> i am also having problem with firefox
[18:51] <mercurous23> i could not run it with going to terminal and using the sudo command
[18:52] <alkisg> Running firefox with sudo? Why?!!!
[18:55] <mercurous23> it will always say that firefox is already running when i tried to do normal launch
[18:55] <mercurous23> sorry i am still new with ubuntu
[18:57] <sbalneav> Then you've probably got a dead one in the background somewhere
[18:57] <sbalneav> ps -ef | grep firefox
[19:01] <mercurous23> it will always say that firefox is already running but is not responding even if I restart the system
[19:01] <sbalneav> ah
[19:02] <sbalneav> ok. lets do this:
[19:02] <sbalneav> cd .mozilla/firefox
[19:02] <sbalneav> ls
[19:03] <sbalneav> should have something like wdiudv75.default
[19:03] <sbalneav> some seqence of random numbers/letters.default
[19:03] <mercurous23> yes
[19:03] <sbalneav> cd into that
[19:03] <mercurous23> i think that is the profile
[19:03] <mercurous23> right?
[19:03] <sbalneav> you got it
[19:03] <sbalneav> ls -l .parentlock lock
[19:04] <sbalneav> got a .parentlock?
[19:05] <sbalneav> if so, just rm .parentlock
[19:05] <mercurous23> yes
[19:05] <sbalneav> then you should be able to start firefox normally
[19:06] <sbalneav> ok, I have to head out.  alkisg, can you give mercurous23 any more help he needs?
[19:07] <alkisg> Sure sbalneav, have a nice afternoon
[19:07] <sbalneav> Never trust greeks bearing gifts, but *always* trust greeks in IRC channels :)
[19:07] <sbalneav> Have fun my friend.
[19:08] <alkisg> Heh :) bye bye
[19:11] <mercurous23> i still got the same problem. I think i got 2 profiles on it. Do you know the command to delete the profile?
[19:12] <alkisg> mercurous23: firefox -ProfileManager
[19:15] <mercurous23> do you know this sqlite files are for?
[19:16] <mercurous23> alkisg my firefox is now working
[19:16] <mercurous23> thanks
[19:16] <mercurous23> great help
[19:16] <alkisg> The sqlite files are there to store your bookmarks and other stuff, don't delete them
[19:16] <alkisg> You're welcome
[19:17] <mercurous23> bye need to get some sleep it is 2am here =)
[22:17] <nubae> aaarcgh... missed the meeting
[22:17] <nubae> jeez, I slept through it
[22:17] <nubae> can someone tell me what I missed
[22:17] <nubae> I read from the email something about Sugar
[22:18] <nubae> I'd like to be involved with that as I need to package it for guadalinex anyway, which is based on Ubuntu
[22:27] <alkisg> nubae: you didn't miss much, except maybe for your membership once again :P
[22:27] <alkisg> ace_suares is going to work on the wiki, and sbalneav on sabayon & docs
[22:27] <nubae> well, i seee there is another meet for next week
[22:27] <alkisg> Sugar was mentioned, but just barely at the end
[22:27] <nubae> which is better for me as Ill have pyclic ready by then
[22:28] <nubae> so can get some people psyched to test it
[22:28] <alkisg> Nice.
[22:28] <alkisg> nubae: I tried with nbd instead of nfs. Yeah, it was twice as fast
[22:29] <alkisg> hdparm -tT /dev/nbd0 showed 10MB/sec for 100mbps network
[22:29] <alkisg> That's good. But of course gigabit would be like a native disk
[22:30] <alkisg> The downside is that it's not really live (the partition must not be mounted). The good side is that one can boot with that partition and administer it as usual
[22:30] <alkisg> ...and of course ltsp-update-image etc isn't needed.
[22:37] <nubae> right... cool
[22:37] <nubae> the biggest isue with nfs isnt even speed though
[22:37] <nubae> its reliability
[22:37] <nubae> it will disconnect, and when it does make the systems temporarily unusable... teachers reallly dont like that
[22:37] <alkisg> Sounds strange though, for such a widely-used file system...
[22:37] <nubae> well, its an old system
[22:38] <nubae> times have changed
[22:38] <alkisg> :-/ I mostly don't like this because of /home, I don't like rsynching stuff...
[22:38] <nubae> i have personally always see it have problems, and talking to the guadalinex folks that created this special local cache using rsync and reconnecting to nfs every 5 mins... guaranteed me that it has always had problems
[22:39] <nubae> well... its a patch hack for sure... the solution uis not to use nfs
[22:39] <nubae> anyways decision was made today here to NOT use ltsp becuase it was too reliant on the network
[22:40] <alkisg> So what will you use?
[22:40] <nubae> and we cant be sure our province wide networks are all cabled properlz
[22:40] <nubae> the simples solution possible
[22:40] <alkisg> xrdp? freenx?
[22:40] <alkisg> Or just cloning?
[22:40] <nubae> xmpp, and totally local machines
[22:41] <nubae> yeah net based cloning, we have a customised system
[22:41] <alkisg> Hm? you mean xdmcp?
[22:41] <nubae> thopugh we are looking for a c coder that could implement p2p like distribution within debinstaller
[22:41] <nubae> no I mean xmpp
[22:41] <nubae> jabber
[22:41] <alkisg> Jabber?
[22:41] <nubae> yes... ud be amazed what that protocol can do
[22:41] <nubae> everyone thinks its just a chat server
[22:42] <nubae> but its a hell of a lot more
[22:42] <nubae> and its super stable, very scalable
[22:42] <nubae> and not reliant on a constant net connection
[22:42] <alkisg> ...but what can it do? Can it expose a file system?
[22:45] <nubae> think of it like tcp
[22:46] <nubae> u set up a xmpp serve
[22:46] <nubae> server
[22:46] <asanchez> hi nubae, what are you doing!
[22:46] <nubae> and using the xep extensions, there are hundreds
[22:46] <nubae> hey hey....
[22:46] <nubae> asanchez: is one of my coworkers at guadalinex
[22:46] <alkisg> hi
[22:46] <nubae> my boss!
[22:46] <asanchez> hi all!
[22:46] <nubae> ;-)
[22:46] <asanchez> I'm your partner, not your boss!
[22:47] <nubae> yeah yeah :-)
[22:47] <nubae> paractically partner
[22:47] <nubae> technically boss
[22:47] <nubae> ;-)
[22:47] <asanchez> :)
[22:47] <nubae> alkisg was working on a fatclient realtime partition system
[22:48] <nubae> or... how would u describe it alkisg
[22:48] <nubae> ?
[22:48] <alkisg> Hmmm I can see a lot of extensions there: http://xmpp.org/extensions/ but are they implemented somehow?
[22:48] <alkisg> Yup, that describes it about right
[22:48] <nubae> i told him maybe we are interested in seeing what it is
[22:48] <nubae> alkisg: yeah many clients have them implemented... even things like share desktop, whiteboard
[22:48] <nubae> collaboration
[22:48] <asanchez> of course, any knowledge is welcome
[22:49] <nubae> video, audio sophisticated chatrooms
[22:49] <alkisg> It seems easy to handle, as it doesn't involve a chroot. The teacher just manages a desktop pc, and it's disk is shared with the other PCs
[22:49] <nubae> sharing of files from a bot like service
[22:49] <nubae> liek config files could be sent for example... imagine the italc stucture being sent for each classroom
[22:49] <nubae> asanchez: alkisg works in the Greek school systenm+
[22:50] <nubae> has the ear of many greek teachers
[22:50] <asanchez> interesting!
[22:50] <nubae> he has done some interesting hacks to italc too
[22:50] <alkisg> The problem is that ltsp, and linux in general, is not very widely used in greece :(
[22:51] <nubae> ?lkisg: whjat was it u did for italc again
[22:51] <nubae> we use it quite  lot at guadalinex
[22:51] <alkisg> But there's interest in it from the ministry and from some teachers... I hope it get used more in the future
[22:51] <alkisg> nubae: just some bug fixes, I didn't do much for it
[22:52] <nubae> i thought u added some feature
[22:52] <nubae> and also ure work on dnsmasq
[22:52] <alkisg> Nah... yeah, mostly dhcp-related stuff, for remote booting
[22:52] <nubae> to stabalise network right?
[22:53] <alkisg> And to make remote booting easier. E.g. here we use dual boot machines, windows + ltsp
[22:53] <nubae> ah yeah, we force users to use linux or linux
[22:53] <alkisg> So I did what I could to make it easier to install gpxe to the windows bootloader...
[22:54] <nubae> asanchez: u know sabayon?
[22:54] <alkisg> Also, we use cheap routers as dhcp servers, so I asked the dnsmasq and gpxe developers to implement a part of the pxe standard that would make it easier to boot ltsp clients without adding a second dhcp server
[22:54] <asanchez> we use an older version of ItalC because we made some hard code to fit our needs, maybe we could take a look at the new versions
[22:55] <asanchez> nubae,  I do
[22:55] <nubae> its been quit improved now
[22:55] <nubae> though i guess itn doest have much use in guadalinex
[22:55] <alkisg> iTlac 2.0 will have some major improvements, to speed as well. I hope it gets out soon...
[22:57] <nubae> asanchez: vagrant cascadian put me in contact with the main tech guy at linex
[22:57] <nubae> i'll cc u correspondence ok?
[22:57] <asanchez> ok, thanks
[22:58] <nubae> alkisg: can u list some of the improvements of italc 2.0?
[22:59] <nubae> btw.. asanchez = Technical director of Guadalinex-edu
[22:59] <alkisg><EMAIL_ADDRESS>[22:59] <asanchez> audio troubleshooting classroom starts at #ubuntu-classroom, see u later
[22:59] <alkisg> bye
[23:01] <nubae> wow management interface for italc 2 sounds nice
[23:03]  * alkisg doesn't really like vnc... I'd prefer a freenx-based solution, or even better something with multicasting for demo mode :)
[23:04] <nubae> freenx wojuld rock.... guadalinex has a multicasting app, but just for vlc i believe
[23:04] <nubae> an inhouse app
[23:04] <nubae> think u ended up doing something similar
[23:05] <alkisg> It didn't use multicasting. Just plain old gstreamer pipelines...
[23:06] <nubae> thats what we did i believe... we call it virtual net cannon
[23:06] <nubae> as it shoots out to the machines in question
[23:07] <nubae> but allows teacher to control session
[23:07] <alkisg> A program that would *multicast* (so that it would give 30+ fps) the teacher screen would be priceless...
[23:07] <nubae> welll maybe tke a look at this program
[23:07] <nubae> might give ideas... think its python based
[23:08] <alkisg> Are the sources available?
[23:08] <nubae> very popular with the teachers
[23:08] <nubae> everything we do is software libre so shol
[23:08] <nubae> should be
[23:08] <asanchez> yeah, we could upload sources to launchpad
[23:08] <alkisg> "virtual net cannon" doesn't return anything in google....
[23:09] <nubae> asanchez: would be good, u never know people might improve on it
[23:09] <alkisg> asanchez: that'd be nice
[23:09] <nubae> or give ideas
[23:10] <asanchez> yeah, maybe a new project at lauchpad could be the easiest way to do that
[23:10] <asanchez> everything is in spanish: http://murgitic.blogspot.com/2007/02/crv-can-de-red-virtual.html
[23:11] <nubae> bueno, I can translate it
[23:11] <alkisg> sweet google translate :)
[23:12] <asanchez> yes, but i think code is in spanish too
[23:12] <asanchez> our coworker luis is the main coder of CRV
[23:15] <alkisg> I like your education submenus... ours is flat :) http://users.sch.gr/alkisg/temp/education-menu.png
[23:18] <nubae> yes edu menus in guadalinex-edu are indeed very well thought out
[23:18] <nubae> we had input from teachers I thnk
[23:18] <nubae> think
[23:18] <asanchez> we have recently adopted edubuntu menu system in Guadalinex
[23:20] <alkisg> So how many PCs use linux in spain, approximately?
[23:20] <alkisg> (in education)
[23:22] <nubae> well.... think of it this way, we manage 4400 schools
[23:23] <nubae> or some number close to that
[23:23] <asanchez> in spain i don't know exactly
[23:23] <alkisg> Woah... that's a lot of schools
[23:23] <nubae> schools have between 100-600 students I think
[23:23] <nubae> asanchez knows better though
[23:23] <nubae> he can confirm
[23:23] <asanchez> in Andalusia we have nowadays 265.000 and we are going to increment this number before end of this year with 187.100 netbooks
[23:24] <nubae> yes, we are amongst the largest edu distributions in practice in the world
[23:24] <nubae> end goal is every student with a netbook, verdad?
[23:24] <alkisg> I hope Greece can learn something from you :(
[23:24] <nubae> asanchez mentioned something very interesting todaz
[23:24] <nubae> today
[23:25] <alkisg> Heh german layout ?
[23:25] <asanchez> before 2012, our goal is 1 computer per 2 students
[23:25] <nubae> basically, everyone is looking to see what we do
[23:25] <nubae> with our netbook deal
[23:25] <nubae> forced guinny pigs
[23:25] <nubae> guinea pigs
[23:25] <asanchez> although we are going to start to give 1 netbook per children at primary school
[23:26] <alkisg> Greece will also offer netbooks this September, but only for 1 class (= kids 13 y.o.)
[23:26] <alkisg> But I don't know if that will continue next year...
[23:26] <nubae> our system is, the gov. gives the netbooks to the students and teachers
[23:26] <nubae> so they can take them home, etc
[23:27] <asanchez> we have to change our model because now students are going to use netbook also at home
[23:27] <nubae> but we only support linux, so if they install windows they are on their own
[23:27] <nubae> this will be a big rpoblem
[23:27] <nubae> the other problem is connectivity to the net from home
[23:28] <nubae> like... should we alow them to connect to any place... (should there be flters hardcoded in?)
[23:28] <asanchez> after 6 years of experience, here people prefer linux because they have direct support
[23:28] <nubae> its all totally poltiical
[23:28] <asanchez> nubae, i think this is one way to give support at home
[23:29] <nubae> that is the real advantage... students when going into uni actually ask for linux
[23:29] <asanchez> and at home to their parents
[23:29] <nubae> trhez wont tolerate windoze
[23:29] <nubae> thats super duper!
[23:29] <alkisg> All that in 6 years? !!!
[23:29] <asanchez> why computer at home are so bored? where is tuxracer? :D
[23:30] <nubae> hey... theyve done a hell of a lot... most of the group (at least in development / tech) are some of the best in their fields
[23:30] <nubae> they really know their suff
[23:31] <asanchez> yeah, we are so lucky with our team and with nubae now!
[23:31] <nubae> so we work within the absurd demands of the ministry (asanches can give u horror stories for hours)
[23:31] <nubae> hehe
[23:31] <nubae> aww.....
[23:31] <asanchez> hahaha
[23:31]  * nubae blushes
[23:32] <nubae> yeah the team rocks... being able to bounce ideas off each other like that rocks
[23:33] <nubae> in all the other situations I was in, I was almost always working alone
[23:33] <nubae> much harder and half the fun
[23:33] <alkisg> It's really nice that you also do developement, and it would be even better if you could share it somehow...
[23:33] <alkisg> I think you're going to send some fixes for the ecubuntu education menus?
[23:34] <asanchez> yeah, I think we are now at good political situation to publish part of our work
[23:34] <nubae> heh, I was told today that we have a fulltime canonical dev that kinda works for us, based on the money he is paid for an official support contract
[23:34] <nubae> asanchez: thats a really good point
[23:35] <nubae> we need to some whitepapers and start sending to journals/magazines
[23:35] <nubae> get our name (guadalinex-edu) out there
[23:35] <asanchez> I think our deployment system its suitable for a paper (and we need this paper to :D)
[23:36] <nubae> I hav contacts with British press, but article in wired, linux format, new scientist, etc would be unbeliavably cool
[23:36]  * nubae hides from the documentation work
[23:36] <asanchez> our "public relations man" has a lot of contacts
[23:36] <nubae> constant struggle here
[23:37] <asanchez> no problem, I like doc and slides, I can do that work
[23:38]  * nubae and asanchez are kinda PR men too but from a tech perspective
[23:39] <nubae> me cuase somehow I got sucked into ubuntu, oopensuse, and wired membership
[23:39] <nubae> btw.... totally oiff note, did u see SCO is suing novell and IBM again
[23:39] <nubae> some court somewhere overturned their appeal to the ownership of unix and linux
[23:40] <nubae> emm..... wired should = sugar membership
[23:40] <nubae> doh
[23:45] <nubae> asanchez: una cosa.,... si me invitan a conferencias (un ejemplo es una para suse en Octubre) hay forma de tomar parte, reresentando guadalinex y haceindo una presentation?
[23:46] <nubae> me imagino que a la mejor podria coger esos dias, pero no se pagaria nada, verdad?
[23:48] <nubae> lo mismo con un despliege /infrstructuración en Madgascar
[23:48] <asanchez> nubae, todas las salidas por parte del proyecto tienen que ser aprobadas por la dirección, si la dirección la aprueba no hay problema
[23:49] <nubae> vale eso lo entiendo, pero es algo que puede pasar, o es muy dificil??
[23:49] <nubae> es que yo veo que asi ganamos información muy importante
[23:50] <nubae> y la verdad es que es ipmortante que alguien que este metido de verdad en estas comunidades vaya... es decir... no solo para el tema de marketing
[23:50] <nubae> more information sourcing, intellegence gathering
[23:52] <asanchez> i think it could be possible if your company is agree
[23:53] <nubae> sadiel in this case?
[23:53] <asanchez> yes
[23:53] <nubae> ok, I would have to talk to them?
[23:53] <asanchez> sorry, i have to help my brother with his final degree project at university
[23:54] <nubae> ah no problem... good luck, I go to bed now anyway
[23:54] <nubae> Ilöl ask another day
[23:54] <asanchez> yes, i think Jorge could have more information, i don't know exactly how that works in your co.
[23:55]  * nubae waves and tunes out


[14:09] <dhiraj> Please suggest which is best ubuntu mate vs lubuntu
[15:06] <tijara> lubuntu is aimed at older hardware
[15:23] <kc2bez> tijara: Is that a question or a statement?
[15:23] <kc2bez> You may want to read this blog post: https://lubuntu.me/taking-a-new-direction/
[15:24] <kc2bez> That being said, Lubuntu is still very lightweight.
[16:47] <leet_sleepyhead> hey
[16:47] <leet_sleepyhead> hello
 hi
 @leet_sleepyhead [<leet_sleepyhead> hello], hi
[17:42] <tijara> kc2bez: thanks for the info, I´m out of the loop I admit