[06:07] <zyga> o/
[06:08] <zyga> good morning
[06:08] <mvo> hey zyga
[06:08] <zyga> hey :)
[06:09] <mborzecki> zyga: mvo: morning guys
[06:09] <zyga> good morning
[06:09] <mvo> hey mborzecki
[06:10] <zyga> mborzecki: please wait on the opens use review, I found some things to change last night that I didn't address yet
[06:10] <mborzecki> zyga: ok
[06:16] <mvo> zyga: your opensuse build update shows "+ echo 'Package build incorrect, '\''snap --version'\'' mentions '\''unknown'\'''"
[06:16] <mvo> zyga: in the spread tests
[06:16] <zyga> yeah, I saw that
[06:17] <zyga> that's what I meant :)
[06:17] <mvo> ok
[06:17] <mvo> zyga: oh, sorry, missed that I guess
[06:17] <zyga> it works fine in casual testing but I wanted to see spread run before releasing this
[06:17] <zyga> no worries, thank you for looking
[07:35] <mborzecki> https://github.com/snapcore/snapd/pull/6094 could use another review
[07:36] <mup> PR #6094: wrappers: fix generating of service units with multiple `before` dependencies <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6094>
[07:36] <mborzecki> then we can land it and pick it for 2.36
[07:49] <zyga> yep
[07:51] <zyga> mborzecki: interesting, in my local build I see the correct version on "snap version"
[08:07] <pstolowski> good morning!
[08:09] <zyga> --debug session shows unknown
[08:09] <zyga> so odd, let's see why
[08:10] <zyga> ah
[08:10] <zyga> because of how we build in spread
[08:11] <zyga> normal builds are fine
[08:14] <mborzecki> hm i'm debugging why #5896 spread test for device keys seeminglly doesn't work
[08:14] <mup> PR #5896: snapcraft.yaml: set grade to stable <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5896>
[08:15] <mborzecki> the test snap finds a device /dev/input/by-path/platform-i8042-serio-0-event-kbd which as it turns out has all the attributes that make it match with device-buttons interface :/
[08:23] <mborzecki> hm no it doesn't match, but the snap can still access it
[08:24] <mborzecki> zyga: any clues, there's a device /dev/input/event2 maj:min is 13:66, it's not listed in devices.list for that snap, but when running under --shell i can still open it
[08:36] <zyga> mborzecki: _hmm_
[08:36] <zyga> mborzecki: when you open shell can you see the process listed in the control group?
[08:38] <mborzecki> zyga: heh, no cgroup.procs is empty
[08:39] <zyga> what system is that?
[08:39] <zyga> is that devmode system?
[08:39] <mborzecki> zyga: 18.04
[08:40] <zyga> that's interesting
[08:40] <zyga> ah
[08:40] <zyga> well
[08:40] <zyga> there's this one old odd behavior
[08:40] <zyga> if you have no device tags for a given security tag
[08:40] <zyga> then we don't use cgroups
[08:40] <zyga> no tagging == no device cgroup
[08:42] <mborzecki> zyga: sounds like a problem, with this interface you could get access to all /dev/input/*
[08:43] <zyga> yes, it feels like we should make it unconditional
[08:43] <zyga> can you check if that's still the case
[08:43] <zyga> the code is in snap-confine/ in udev-support AFAIR
[08:45] <mborzecki> zyga: feels like this is going to be fun, i need some coffee first
[08:47] <zyga> uh, I forgot about dentist appointment
[08:47] <zyga> need to go
[08:50] <mvo> pstolowski: quick question: we only run the post-refresh hook on refreshes, right? not on a fresh install? so if I want something that run on a fresh install and a refresh I need to install two hook hanlders?
[08:53] <pstolowski> mvo: correct, pre- and post-refresh hooks run only on refreshes. and install hook is run only on fresh install
[08:54] <doko> mvo, zyga: the snapd autopkg tests are not happy with python 3.7 in disco. please fix
[08:54] <mvo> pstolowski: ta
[08:55] <mvo> doko: sure, looking
[09:10] <zyga> Thank you doko
[09:10]  * zyga is at the dentist
[09:13] <doko> is snapd such a pain?
[09:15] <mwhudson> zyga: thanks for https://bugs.launchpad.net/ubuntu/+source/plainbox/+bug/1801687
[09:15] <mup> Bug #1801687: Please remove the plainbox package <plainbox (Ubuntu):New> <https://launchpad.net/bugs/1801687>
[09:19] <Chipaca> morning from the summit
[09:28] <mborzecki> Chipaca: hey, what's the turnout?
[09:29] <Chipaca> mborzecki: ~100,000 people
[09:29] <mborzecki> Chipaca: over 9000 ;)
[09:29] <Chipaca> mborzecki: :-)
[09:33] <mvo> Chipaca: good morning! how are things there? anything exciting happening already?
[09:46] <diddledan> mvo: popey is playing with his nipple already
[09:47] <popey> !
[09:47] <ogra> in public ?!?!
[09:47] <diddledan> INORITE
[09:48] <mvo> diddledan: *cough*
[09:59] <mup> PR snapd#6096 opened: spread.yaml: add more systems to the autopkgtest and qemu backends <Created by mvo5> <https://github.com/snapcore/snapd/pull/6096>
[10:00] <mup> PR snapd#6097 opened: interfaces/tests: MockHotplugSlot test helper <Hotplug 🔌> <Simple 😃> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6097>
[10:06] <mvo> doko: I uploaded a new snapd into disco that should now run the adt tests, will be interessting to see if they fail or pass so maybe there is more work needed but this should at least unblock things
[10:06] <zyga> Dentist over, heading home
[10:06] <mvo> zyga: welcome back
[10:06] <zyga> What was the issue with python 3.7?
[10:07] <mvo> zyga: pr is 6096
[10:07] <mvo> zyga: its an internal issue might be worth reworking how we drive adt
[10:08] <doko> I love it when you have to do things like that for every release ... maybe just do the reverse, where it's *not* supported?
[10:08] <mvo> doko: sure, let me look what we can do to make this simpler
[10:09] <mvo> doko: thanks for approving it though
[10:09]  * mvo looks into reworking that code
[10:15] <popey> degville: https://snapcraft.io/docs/reference/env is referenced in a few places and redirects to a 410 page https://docs.snapcraft.io/reference/env
[10:21] <degville> ooh, thanks popey.
[10:23] <pedronis> mvo: what's the status of 2.36?  is there anything immediately blocked on me?
[10:24] <mvo> pedronis: we need confirmation about the 2.36 API of "system" vs "core"
[10:25] <mvo> pedronis: I sent a mail about this but no reply yet
[10:25] <mup> PR snapd#6098 opened: interfaces/builtin: support hotplug for camera interface <Hotplug 🔌> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6098>
[10:27] <mborzecki> zyga: about that cgroup & apparmor, i think now with the process ending up in devices cgroup always, accessing /dev/input/event2 is blocked before lsm gets to have a say on this
[10:28] <zyga> and back home now
[10:28] <zyga> mborzecki: that's correct
[10:29] <mborzecki> zyga: ok, i'll push the change for s-c as separate PR, some tests may need to be updated, especially the ones where we check between EPERM and EACCESS
[10:30] <zyga> aha, that makes sense
[10:30] <zyga> thank you
[10:30] <ogra> mvo, i'm recently working a lot with x86 images ... was there any actual reason that we show the grub menu there ?
[10:31] <ogra> i mean ... you normally dont select anything there anyway ...
[10:33] <mvo> ogra: no real reason, it may become more interessting once we provide recovery via this mechanism but even then its not a huge reason
[10:33] <mvo> ogra: also kind of nice to show people what system they use but *shrug* really no strong reason :)
[10:34] <ogra> it feel like wasted boot time
[10:34] <ogra> *feels
[10:51] <zyga> I built the package locally out of a release tarball and the version is correct
[10:51] <zyga> the issue must be related to how we build the tarball inside spread
[11:02] <mup> PR snapd#6099 opened: cmd/snap-confine: always put the snap process under a device cgroup <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6099>
[11:06] <zyga> mborzecki: interesting, let's see what we get
[11:06] <zyga> (from tests)
[11:07] <mborzecki> zyga: yeah, much fun
[11:08] <Chipaca> hmm
[11:08] <Chipaca> mborzecki: https://forum.snapcraft.io/t/parallel-installs/7679
[11:09] <Chipaca> mborzecki: says 1. parallel installs are experimental and you need to 'snap set hose-my-system=very-yes'
[11:09] <Chipaca> mborzecki: but also, 2. you need 2.36
[11:09] <mborzecki> Chipaca: yes
[11:09] <mborzecki> Chipaca: 2*yes
[11:09] <Chipaca> mborzecki: I thought 2.36 marked them non-experimental?
[11:09] <mborzecki> Chipaca: no, we delayed that to 2.37
[11:09] <Chipaca> ah, missed that
[11:09] <Chipaca> ok
[11:10] <Chipaca> mborzecki: are the store-side limitations still true?
[11:10] <mborzecki> Chipaca: no, there's a note from wgrant, i should probably update the first message
[11:11] <Chipaca> mborzecki: yes please :-)
[11:12] <mborzecki> Chipaca: aand done
[11:12] <mborzecki> Chipaca: are you guys actively trying to break it? :)
[11:12] <Chipaca> mborzecki: 👍
[11:12] <Chipaca> mborzecki: people are being told it works /o\
[11:13] <mborzecki> Chipaca: good, good, ping me if there are any questions
[11:13] <Chipaca> will do :-)
[11:15] <mborzecki> zyga: that device cgroup change, i think it's more of a 2.37 material, wdyt?
[11:16] <zyga> mborzecki: not for 2.36 for sure
[11:16] <zyga> we need to discuss with jdstrand and pedronis
[11:18] <mup> PR snapd#5946 closed: cmd/snap: unhide --name parameter to snap install, tweak help message <Parallel installs ⛓> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5946>
[11:24] <pedronis> zyga: I'm going a bit through my email etc backlog and some travel admin stuff, but I should be available later in the week to discuss things
[11:24] <Chipaca> mvo: https://pastebin.ubuntu.com/p/4hpHK8MRHq/
[11:26] <Chipaca> niemeyer: ^ i really wish we could do smarter formatting of tables on the terminal :-(
[11:26] <mvo> Chipaca: woah
[11:26] <Chipaca> (granted that message is longer than it needs to be :) )
[11:29] <zyga> pedronis: thank you
[11:29] <zyga> Chipaca: use case for those ultra crazy wide monitors ;)
[11:39] <ogra> 80 chars are enough for everyone !
[11:49] <mup> PR snapd#5916 closed: data: run snapd.autoimport.service only after seeding <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5916>
[11:49] <mborzecki> zyga: a bunch of tests failed in 6099
[11:50] <Chipaca> zyga: I see your wide monitor use case, and I raise you a use case for in-snap sub-mount namespaces
[11:50] <zyga> Chipaca: whaaat?
[11:50] <Chipaca> zyga: also in-snap network namespaces
[11:50] <Chipaca> zyga: you started! this is all your fault
[11:50] <zyga> that I actually want
[11:50] <zyga> app firewall
[11:51] <zyga> looking at logs there maciej
[11:51] <zyga> eh
[11:51] <zyga> log too long
[11:51] <zyga> mborzecki: Ensure we can run a statically linked binary from an empty base <- this failed, interesting
[11:51] <mborzecki> zyga: yeah, the log hit travis limits
[11:52] <zyga> mborzecki: I think at this point you need to see what happens until you can run the statically linked echo test
[11:52] <mborzecki> zyga: anyways, Operation not permitted popping up quite frequently, must have been blocked by device cgroups then
[11:53] <zyga> yeah
[11:57] <Chipaca> pedronis: o/
[12:07] <mborzecki> Chipaca: error: invalid argument for flag `--id' (expected main.snapshotID): strconv.ParseUint: parsing "": invalid syntax, is this something you were looking for?
[12:09] <Chipaca> mborzecki: you should have logs
[12:10] <Chipaca> mborzecki: if it's amazon telling you about id -2, take its vodka away
[12:10] <Chipaca> mborzecki: uid -2 that is
[12:10] <mborzecki> Chipaca: yes, it is https://paste.ubuntu.com/p/Ms9jXqvH6V/
[12:10] <Chipaca> bah
[12:10] <Chipaca> bah²
[12:10] <Chipaca> bah³
[12:10] <Chipaca> bah⁹⁹
[12:11] <Chipaca> mborzecki: i'm not sure i can handle it better than just failing
[12:11] <Chipaca> mborzecki: but also i don't know why i'm getting that -2
[12:11] <Chipaca> mborzecki: I do know why it's a -2 :-)
[12:11] <Chipaca> mborzecki: amazon linux 2, yes?
[12:11] <mborzecki> Chipaca: yes
[12:12] <mborzecki> hm we could dump /etc/passwd in debug
[12:13] <Chipaca> mborzecki: AIUI it's a manifestation of https://github.com/golang/go/issues/22739
[12:13] <Chipaca> mborzecki: the -2, i mean
[12:14] <zyga> Chipaca: it is an off-by-one issue :)
[12:14] <Chipaca> nope, it's golang's syscall return value munging
[12:14] <Chipaca> so
[12:14] <Chipaca> that -2 comes from os.Getuid() returning something too big
[12:14] <Chipaca> for go
[12:15] <pedronis> Chipaca: hi
[12:15] <Chipaca> which doesn't make sense on itself
[12:15] <Chipaca> but ¯\_(ツ)_/¯
[12:15] <mborzecki> Chipaca: although it's globbed, the path i mean
[12:15] <Chipaca> pedronis: hi! welcome back. Random question about aliases  (from a user at the summit): are multiple snaps having the same alias supported ok store-side?
[12:15] <mborzecki> Chipaca: some stat maybe? uid/gid handled incorrectly
[12:15] <Chipaca> pedronis: i assume yes but dunno how tested it is :-)
[12:16] <Chipaca> mborzecki: i literally just remembered where the -2 comes from today, so i need to comb it
[12:16] <pedronis> Chipaca: yes, you'll need to use snap prefer  and --unaliased in case you want them both on the same system
[12:18] <Chipaca> pedronis: yep
[12:19] <niemeyer> Chipaca: Yeah, that looks pretty bad
[12:19] <niemeyer> Chipaca: We need something significantly more polished
[12:19] <Chipaca> niemeyer: I can make it shorter, but I can't make it short enough without giving the user context about why they're being warned
[12:20] <Chipaca> i mean, short,  or with context
[12:20] <Chipaca> just saying "this app is devmode" isn't enough imo
[12:20] <niemeyer> Chipaca: The date formating is also breaking our old rule about having no spaces before the last item
[12:20] <cachio> niemeyer, hey, when you have some time, could you please take a look to this PR? https://github.com/snapcore/spread/pull/70
[12:20] <mup> PR spread#70: Reboot on backgraound to avoid spread wait for long time <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/70>
[12:20] <niemeyer> Making it even harder to read
[12:20] <niemeyer> cachio: Sure
[12:21] <niemeyer> I have some time now, but it'll be hard to review it while in line at the border :)
[12:22] <niemeyer> Chipaca: We might have a short description and a link
[12:22] <Chipaca> niemeyer: i was thinking of "snap help devmode"
[12:22] <Chipaca> ie having topics
[12:23] <Chipaca> as well as commands
[12:23] <niemeyer> That sounds nice!
[12:23] <niemeyer> Chipaca: Perhaps just some twist on it so it doesn't look like a command?
[12:24] <niemeyer> Do we support that today?
[12:24] <niemeyer> snap help <cmd>?
[12:24] <Chipaca> niemeyer: yes
[12:24] <niemeyer> Yeah, so we need to disambiguate
[12:24] <Chipaca> niemeyer: and snap help --all  is how you get the long list of everything
[12:24] <Chipaca> so 'snap' on its own tells you to 'snap help --all' for ex
[12:25] <cachio> niemeyer, great, thanks
[12:25] <niemeyer> snap about devmode
[12:25] <Chipaca> niemeyer: wrt the timestamp, i'll change it to use the shorter format we discussed for 'snap saved'
[12:25] <niemeyer> Chipaca: Sounds good
[12:26] <Chipaca> that one doesn't have spaces
[12:26] <niemeyer> Chipaca: Or we could really use the link for the detailing of an issue
[12:27] <niemeyer> Chipaca: Or alternatively, transform the output of warnings into yaml
[12:27] <niemeyer> So we can actually read it
[12:33] <mup> PR snapd#6100 opened: overlord/ifacestate: hotplug-remove-slot task handler <Hotplug 🔌> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6100>
[12:34] <mup> PR snapd#6101 opened: switch travis unit tests to xenial <Created by chipaca> <https://github.com/snapcore/snapd/pull/6101>
[12:35] <zyga> sigh
[12:35]  * zyga tries again
[12:35] <pedronis> Chipaca: I remember we do line wrapping for some errors, either way the super informative warning is good if it's are, but will get annoying if the warning is very common
[12:35] <mup> PR snapd#5963 closed: tests/hotplug: spread test for hotplug based on dummy interface <Hotplug 🔌> <⛔ Blocked> <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/5963>
[12:35] <pedronis> s/it's are/it's rare/
[12:41] <Chipaca> pedronis: agreed about that
[12:42] <zyga> https://www.irccloud.com/pastebin/mEgjLBWg/
[12:42] <zyga> mborzecki: ^ weird, right?
[12:43] <zyga> info file is correct too
[12:43] <mborzecki> zyga: 1337 version is better than none :)
[12:43] <mborzecki> 31337
[12:44] <mborzecki> zyga: the one i have here locally is ok
[12:44] <zyga> yeah
[12:45] <mborzecki> zyga: from what i see we change it in prepare when bulding rpms
[12:45] <zyga> I think I know what's wrong now
[12:46] <zyga> copy
[12:46] <mborzecki> zyga: are you calling go generate as part of the build?
[12:46] <zyga> I call mkversion.sh in prepare
[12:46] <zyga> google:opensuse-42.3-64 /# find -name version_generated.go
[12:46] <zyga> ./usr/src/packages/BUILD/snapd-1337.2.36/gopath/src/github.com/snapcore/snapd/cmd/version_generated.go
[12:46] <zyga> so this file is good
[12:47] <Chipaca> niemeyer: some cool people from travis-ci are here
[12:47] <Chipaca> niemeyer: it turns out we can throw money at them and get more concurrent runs
[12:47] <mborzecki> zyga: then why it's unknown in snap version output?
[12:47] <Chipaca> niemeyer: it's just a bit messy and requires a human, because we're using .org
[12:47] <zyga> ./usr/src/packages/BUILD/snapd-1337.2.36/gopath/src/github.com/snapcore/snapd/cmd/VERSION
[12:47] <Chipaca> niemeyer: let's chat
[12:47] <zyga> there's also this which is equally correct
[12:48] <zyga> mborzecki: now I'm confused :/
[12:48]  * zyga looks
[12:49] <Chipaca> grr, unit tests are 8 minutes again :-(
[12:49] <mborzecki> zyga: in arch i'm calling ./mkversion.sh $pkgver-$pkgrel
[12:49] <mborzecki> zyga: so it's not guessing the version
[12:49] <pedronis> mborzecki: hi, was https://forum.snapcraft.io/t/cross-snap-service-ordering/8319 discussed with niemeyer, it doesn't seem to match the brief discussion we had in SLC
[12:50] <zyga> the version is fine in VERSION and in go so it's not that
[12:50] <mborzecki> pedronis: hi, no hence the forum topic, could you leave a comment with what you discussed in slc there?
[12:50] <zyga> must be something I'm missing :/
[12:50] <zyga> I was thinking it must be a copy
[12:50] <zyga> C and Go are built differently
[12:50] <zyga> C picks up the version okay
[12:50] <zyga> go uses import paths to build stuff
[12:51] <zyga> so I was thinking there must be a bit of copy that was not changed with mkversion somewhere
[12:51] <pedronis> mborzecki: I'll try to put something there today or tomorrow, we just sketched some ideas
[12:51] <pedronis> it will need further discussion
[12:51] <zyga> google:opensuse-42.3-64 /root# GOPATH=/usr/src/packages/BUILD/snapd-1337.2.36/gopath go build -buildmode=pie github.com/snapcore/snapd/cmd/snap
[12:51] <zyga> https://www.irccloud.com/pastebin/szuxkg0r/
[12:51] <zyga> so this worked okay
[12:51] <mborzecki> pedronis: fair enough, i'm out to conference on wed and thu so no rush
[12:51] <niemeyer> Chipaca: Ack
[12:51] <zyga> I'll add a sanity check in %build to see what version we se
[12:53] <zyga> mborzecki: ah, there _is_ a copy
[12:53] <zyga> wtf?
[12:53] <zyga> we have /home/gopath
[12:53] <zyga> and /usr/src/
[12:53]  * zyga looks
[12:53] <zyga> but this is why this happened
[12:53] <mborzecki> src.rpm got installed?
[12:54] <zyga> no, I think that's our spread hacking magic
[12:54] <zyga> aka mess
[12:55] <zyga> hmm
[12:55] <zyga> mborzecki: what is GOHOME?
[12:56] <mborzecki> GOHOME?
[12:56] <zyga> it's set in spread.yaml
[12:56] <zyga> git grep GOHOME
[12:56] <zyga> looks like our invention
[12:56] <mborzecki> zyga: right, but we set GOPATH using that
[12:56] <zyga> that's fine though
[12:56] <zyga> I wonder where /usr/src came from
[12:57] <zyga> specifically usr/src/packages/BUILD
[12:57] <zyga> doesn't feel like something out of srcrpm
[12:58]  * zyga looks
[12:58] <zyga> quick coffee while spread starts up
[12:59] <Chipaca> zyga: /usr/src is GOROOT
[12:59] <Chipaca> I'm guessing
[13:02] <zyga> Chipaca: nope, suse sets GOROOT in the environment to something like /usr/lib64/go/1.11
[13:02] <zyga> there is no match for /usr/src in our tree so I'm puzzled
[13:03] <pedronis> mvo: I pinged you from a couple of unanswered forum topics
[13:05] <mborzecki> off to pick up the kids
[13:13] <zyga> I see what's going on now
[13:14] <zyga> just not sure how /usr/share/packages is defined
[13:14] <zyga> but that's fine
[13:14] <zyga> got it!
[13:14] <zyga> # rpm -E '%{_topdir}'
[13:14] <zyga> /usr/src/packages
[13:14] <zyga> so
[13:14] <zyga> we have a copy there in BUILD
[13:15] <zyga> and we have a copy in /home/gopath
[13:15] <zyga> now just to untangle that
[13:18] <Son_Goku> zyga, it's /usr/lib/rpm/macros
[13:18] <Son_Goku> SUSE patches rpm to force that
[13:18] <zyga> yeah, I know now :)
[13:19] <Son_Goku> what it does is that if ~/rpmbuild doesn't exist, it will use that directory instead
[13:19] <Son_Goku> (IMO, that's broken, but whatever...)
[13:19] <Son_Goku> also... zyga: https://twitter.com/fedora/status/1059728342666989568
[13:19] <Son_Goku> looky, you're in the picture :D
[13:20] <zyga> Niiiice :)
[13:20] <Son_Goku> as am I! weee! :D
[13:20] <ogra> seems he surrenders
[13:20] <ogra> :)
[13:21] <Son_Goku> yep, he's now a Fedora man
[13:21] <Son_Goku> no more Ubuntu for him :D
[13:21] <ogra> go IBM !
[13:21] <ogra> :P
[13:22] <Son_Goku> :S
[13:32] <jdstrand> mborzecki: fyi, the fuse-support test in your cgroup PR is failing cause you're checking for Permission Denied (as you said above)
[13:34] <Son_Goku> zyga, mborzecki, you guys will want to look into this: https://bugzilla.redhat.com/show_bug.cgi?id=1438079#c4
[13:35] <Son_Goku> I have a feeling we're switching the unified hierarchy for cgroups (aka cgroups v2) very soon
[13:35] <mvo> pedronis: thanks for the pings, I'm replying now
[13:35] <zyga> Son_Goku: I know about it, I talked to zbyszek
[13:35] <zyga> I think that v2 is not ready yet
[13:35] <zyga> it doesn't have the controllers we need
[13:36] <Son_Goku> ok
[13:38] <mborzecki> jdstrand: a couple of tests fail the same way, and i have some issues with devmode, we do not generate udev rules in that case but with the PR s-c will still put the snap under a cgroup
[13:38] <mborzecki> Son_Goku: thanks for the heads up
[13:39] <mborzecki> zyga: iirc we're only missing freezer at this point, aren't we?
[13:39] <zyga> mborzecki: haha, not sure if only but the freezer is the first one I noticed
[13:40] <Son_Goku> zyga, need karma for this: https://bodhi.fedoraproject.org/updates/FEDORA-2018-48cc10ba1d
[13:40] <zyga> ack, I'll test it today
[13:40] <mborzecki> zyga: maybe it'd be a good idea to check what's in there already and what we're missing
[13:41] <mborzecki> zyga: switching will be proobably held for as long as docker dones not support v2
[13:41] <zyga> mborzecki: based on my discussion with zbyszek there is really no rush for this, it will likely take years
[13:42] <ogra> ppisati, did you take a look at the pi3 b+ NIC-LED isues described in https://forum.snapcraft.io/t/support-for-raspberry-pi-3-model-b/4509 ?
[13:42] <ogra> (i think the patchset i pointed to initially had fixes for that too)
[13:44] <jdstrand> mborzecki: I understand the PR and the motivation. Please see my comments in both PR 5897 and PR 6099. 5897 can land if we force the use of the cgroup, like we did with joystick (see comment)
[13:44] <mup> PR #5897: interfaces/builtin: add device-buttons interface for accessing events <⛔ Blocked> <Created by bergotorino> <https://github.com/snapcore/snapd/pull/5897>
[13:44] <mup> PR #6099: cmd/snap-confine: always put the snap process under a device cgroup <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6099>
[13:51] <mborzecki> jdstrand: thanks! will do
[13:51] <zyga> mborzecki: fixed, I think
[13:52] <zyga> just quick local spread run before pushing
[13:52] <mborzecki> zyga: what was it?
[13:52] <zyga> mborzecki: GOPATH takes priority over what we want to build
[13:52] <mup> PR snapd#6094 closed: wrappers: fix generating of service units with multiple `before` dependencies <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6094>
[13:52] <zyga> I swapped GOPATH with indigo_gopath
[13:52] <zyga> https://www.irccloud.com/pastebin/wYHe3zeU/
[13:52] <zyga> mborzecki: ^ my notes from this session
[13:55] <ppisati> ogra: i'm looking into it - the led patches are already there, but one of the function (lan78xx_otp_read()) is buggy, or to better - if i apply the correct fix, then leds are working but the entire chip stops working (we don't get any phy interrupt when packate arrives at the interface)
[13:55] <ppisati> *packets
[13:56] <ogra> ok ...
[13:56]  * ogra comments in the forum thread
[13:56] <ppisati> ogra: IOW, the lan78xx driver in 4.4 relies on the buggy behaviour of that function
[13:57] <zyga> mborzecki: in distro builds this doesn't happen because osc uses a chroot and controls GOPATH
[13:59] <Chipaca> zyga: pstolowski: using a serial port on classic, does it need hotplug or is it alredy there?
[13:59] <zyga> Chipaca: you need hotplug
[14:00] <pedronis> mvo: thanks for answering those topics
[14:01] <mborzecki> mvo: can you cherry pic https://github.com/snapcore/snapd/pull/6094 to 2.36?
[14:01] <jdstrand> mborzecki: ok, and now you have my code review for 6099. thanks again for picking that up
[14:01] <mup> PR #6094: wrappers: fix generating of service units with multiple `before` dependencies <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6094>
[14:01] <zyga> (new old standup time)
[14:01] <mborzecki> jdstrand: thanks, it was fun to look into this :)
[14:01] <zyga> Chipaca mvo pstolowski pedronis  ^
[14:03] <ogra> mvo, couldnt you just remove the state.json to get back into console-conf (effectively doing a fake "factory reset") ?
[14:09] <zyga> mborzecki: can you look at https://github.com/snapcore/snapd/pull/6095 after the call please
[14:09] <zyga> I think it should pass now
[14:09] <mup> PR #6095: packaging/opensuse: stop using golang-packaging <Created by zyga> <https://github.com/snapcore/snapd/pull/6095>
[14:10] <Chipaca> pedronis: another question
[14:11] <pedronis> Chipaca: in the standup, but do ask, I will come back later
[14:11] <mvo> ogra: yeah, that should work as well, I didn't suggest it in the forum because I wasn't sure if there were any "precious" things on the system, maybe he has some snaps he does not want to lose, but yeah, if not its a solution too
[14:12] <Chipaca> pedronis: ok
[14:12] <mvo> mborzecki: 6094 is cherry-picked
[14:12] <mborzecki> mvo: thanks!
[14:13] <Chipaca> pedronis: if somebody wanted to use snaps in a cloudy context where they want the image to boot and have a number of snaps already installed
[14:13] <Chipaca> pedronis: they feel they could just install them, snapshot the disk, and then just run with it
[14:14] <Chipaca> pedronis: seeding is too slow, installing from zero is too slow
[14:16] <mvo> I wonder if we could put things on disk in the prepare image state and just run the hooks at "seeding" time. probably needs careful thinking but my gut feeling is that everyone wants faster seeding
[14:18] <Chipaca> ye
[14:18] <Chipaca> mborzecki: also also
[14:18] <Chipaca> mborzecki: you lied to me: the " Due to the current limitations in the store, multiple instances of a snap need to be installed from the same single command, as shown above." thing is still on https://forum.snapcraft.io/t/parallel-installs/7679
[14:19] <cachio> Chipaca, https://paste.ubuntu.com/p/XjP3hcFr4P/
[14:19] <cachio> I saw this one today
[14:19] <Chipaca> cachio: yes
[14:19] <Chipaca> cachio: thank you
[14:19] <Chipaca> cachio: it's the -2 user id, i need to look into it
[14:19] <Chipaca> not today
[14:19] <cachio> sure
[14:19] <Chipaca> cachio: restart, but thank you for the paste (is it set to expire?)
[14:20] <cachio> no
[14:20] <cachio> Chipaca,
[14:21] <Chipaca> cachio: tks
[14:23] <Chipaca> mborzecki: i edited
[14:31] <mborzecki> Chipaca: thanks
[14:31] <mborzecki> Chipaca: does it work so far for you guys? :)
[14:32] <Chipaca> mborzecki: i have not been lynched yet
[14:32] <Chipaca> mborzecki: and i get to keep _most_ of my fingers!
[14:32] <mborzecki> Chipaca: maybe they're still building the pyre
[14:32] <Chipaca> mborzecki: they're still drunk from guy fawkes last night
[14:45] <zyga> Pharaoh_Atem: what's the difference between %{!?... and %{?!...} ?
[14:46] <Pharaoh_Atem> preference, mainly
[14:46] <Pharaoh_Atem> some broken spec parsers handle them differently
[14:46] <Pharaoh_Atem> both otherwise they should behave the same
[14:46] <zyga> why do we use both?
[14:46] <zyga> should we use the same syntax or is there a good reason to keep the difference
[14:47] <zyga> I just noticed because of a bug that affected leap
[14:48] <Pharaoh_Atem> I just switched everything in the fedora spec to %{!?...}
[14:48] <zyga> thanks
[14:48] <zyga> I'll do the same
[14:49] <Pharaoh_Atem> it makes more sense in my head anyway
[14:49] <Pharaoh_Atem> "does not exist" vs "exists, not?"
[14:49] <mup> PR snapcraft#2392 opened: ci: update travis.yaml to use xenial <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2392>
[14:55] <Chipaca> chesty: https://bugs.libssh.org/T118
[14:58] <pedronis> Chipaca: if they use a prebooted image the serial number would be wrong,  we don't have an answer at the moment except you do need to do seeding, but is an open question, we discussed about it a bit with mvo etc in SLC
[15:00] <Chipaca> pedronis: yeah, seeding is going to be too slow
[15:00] <Chipaca> pedronis: we're talking about a 14 seconds boot being omg slow
[15:01] <Chipaca> pedronis: not a blocker but we really need to address this soonish
[15:07] <chesty> Chipaca, nice. why struct passwd *pwdbuf = NULL; ? is extra precaution in case  of a bug in getpwuid_r ?
[15:08] <Chipaca> chesty: i guess so yes
[15:22] <jdstrand> roadmr: fyi, finally got all the revisions before r79 of pivx and now I was able to run the automated tools again on 79
[15:22] <roadmr> \o/
[15:22] <roadmr> thanks for checking.
[15:24] <Chipaca> hmmmmmmmmmmmmₘₘₘₘₘₘₘₘₘₘ
[15:25] <mvo> Chipaca: well, I think we should thing about putting things on disk in prepare image and just running the hooks but its a bigger change and needs careful investigation
[15:25] <Chipaca> mvo: ₘₘₘₘₘₘ
[15:25] <Chipaca> mvo: :-)
[15:26] <Chipaca> mvo: why run the hooks?
[15:27] <mvo> Chipaca: running the hooks in prepare image is going to be a challenge - we may create an arm image with a amd64 host
[15:33] <Chipaca> mvo: we could also not support doing the whole fast boot set up on an m×n arch grid
[15:34] <Chipaca> anyway i figured out where the snapshot -2 uid error comes from, probably™
[15:34] <pedronis> Chipaca: we can add some constraints, but we cannot be fully arbitrary or hackish either
[15:34] <pedronis> it needs some toughts
[15:34] <Chipaca> pedronis: yes
[15:42] <ogra> zyga, are layouts on by default in 2.36 ?
[15:44] <zyga> yes
[15:45] <ogra> so i can drop the passthrough in my snapcraft.yaml ?
[15:45] <roadmr> ogra: try dropping it; if snapcraft complains, then you'll still need it :)
[15:45] <pedronis> the passthrough is about snapcraft, not snapd
[15:45] <roadmr> ^^ this
[15:45] <ogra> hahaha
[15:46] <zyga> ogra: that's a question for kyrofa and sergiusens
[15:46] <zyga> roadmr: processing...
[15:46] <roadmr> zyga: yay!
[15:46] <zyga> it worked!
[15:46] <roadmr> of course ;) thanks to the work jdstrand did yesterday
[15:48] <zyga> and released!
[15:48] <zyga> (to beta)
[15:52] <kyrofa> zyga, ogra layouts are supported in 3.0 as long as you specify a base
[15:52] <zyga> woot
[15:52] <kyrofa> Otherwise passthrough is still required
[15:52] <ogra> urgh
[15:52] <roadmr> zyga: yay \o/
[15:52] <ogra> kyrofa, how does that work for all my exiting snaps ... is a default base picked when i do a rebuild ?
[15:53] <ogra> *existing (even though some are exciting :P )
[15:54] <zyga> ogra: you need to pick base: core
[15:54] <zyga> ogra: or core18
[15:55] <ogra> zyga, so i need to update all exiting snapcraft.yamls ?!?!
[15:55] <zyga> yes
[15:55] <zyga> that's intentional
[15:55] <ogra> sigh ...
[15:55] <zyga> to opt into the new build semantics
[15:55] <kyrofa> zyga, no, "core" is not a valid base, "core16" is. But that isn't really a thing yet
[15:55] <ogra> you mean build.s.io will fall back to snapcraft 2.x if i dont ?
[15:56] <kyrofa> Bingo
[15:56] <ogra> phew
[15:56] <ogra> k
[15:56] <zyga> kyrofa: why core is not a valid base?
[15:56] <kyrofa> ogra, we really didn't want to break folks
[15:56] <zyga> (core is a valid base in snapd)
[15:56] <kyrofa> zyga, isn't core going to only contain snapd?
[15:56] <zyga> no
[15:57] <kyrofa> Eh?
[15:57] <zyga> kyrofa: you are talking about the snapd snap
[15:57] <ogra> kyrofa, yeah, i would have been surprised if you did ... i trust you and sergio blindly normally ;)
[15:57] <zyga> kyrofa: core will contain snapd and core16
[15:57] <zyga> (and does so today)
[15:57] <zyga> kyrofa: core16 is just core sans snapd
[15:57] <kyrofa> zyga, core isn't being renamed to core16, then?
[15:57] <zyga> kyrofa: no
[15:57] <zyga> kyrofa: core16, core and core18 are separate snaps
[15:57] <ogra> they dropped that renaming idea
[15:57] <zyga> kyrofa: core16 and core18 don't have snapd anymore
[15:57] <kyrofa> Yikes. All three will need to be maintained?
[15:57] <zyga> kyrofa: snapd snap is a separate required snap in that case
[15:57] <zyga> kyrofa: for now yes
[15:58] <zyga> kyrofa: we will transition people from core to core16
[15:58] <zyga> (that is core to core16 + snapd)
[15:58] <kyrofa> Okay, I wasn't clued into the dropping of the rename. Still though, I think "core" shouldn't be used as a base
[15:58] <zyga> pedronis: ^ in case I'm mistaken
[15:58] <kyrofa> We should steer people toward core16
[15:58] <zyga> pedronis: core, core16 and core18 will be maintained until we complete the transition
[15:59] <zyga> kyrofa: sync with pedronis and mvo on timing please
[15:59] <zyga> kyrofa: core16 can be used as a base AFAIK (correctly)
[15:59] <zyga> kyrofa: as can core18
[15:59] <kyrofa> Which means the only supported bases for now (at least in snapcraft, given that it's a new feature) should be core16 and core18
[15:59] <kyrofa> zyga, it's not stable yet though, no?
[15:59] <zyga> the transition is moving people away from core as the holder of snapd
[15:59] <kyrofa> (core16, I mean)
[15:59] <zyga> kyrofa: I think it is equally stable
[15:59] <zyga> kyrofa: we just don't have the migration code in place
[16:00] <zyga> but operationally it is just like core
[16:00] <kyrofa> zyga, I mean it literally isn't in the stable channel
[16:00] <kyrofa> It's edge only
[16:00] <pedronis> kyrofa: I don't think core can be used as a base explicitly
[16:00] <zyga> kyrofa: note that core16 and core18 are AFAIK maintained by foundations
[16:00] <zyga> kyrofa: I see
[16:00] <kyrofa> pedronis, agreed
[16:00] <kyrofa> As it should be
[16:01] <kyrofa> Any ETA for when core16 will be stable?
[16:03] <zyga> kyrofa: I honestly don't know
[16:03] <zyga> it probably should be now
[16:03] <zyga> but it depends on the transition process
[16:03] <zyga> (perhaps)
[16:03] <ogra> so if i want to use layouts in my snaps that are built specifically for Ubuntu Core 16, what would i do (and note in no casse ever i want core18 to end up on a core16 install)
[16:06] <pedronis> ogra: the decision to connect layouts to 3.0 and base is a bit strange, not sure what was the rationale there
[16:07] <ogra> yeah
[16:08] <ogra> we'll definitely want to use it for existing customer ... and many of them will never go to 18 ... (and wont want an additional core18 base nasp installed either)
[16:08] <ogra> *cusstomerss
[16:08] <ogra> (GRRR ... broken kbd)
[16:13] <sparkiegeek> sergiusens: https://paste.ubuntu.com/p/ZFKJXbVMSj/
[16:14] <sparkiegeek> sergiusens: 95% sure that's not related to my change
[16:14] <sergiusens> pedronis: we did not have anyone request it, it can be done
[16:15] <sergiusens> pedronis: that said, folks can still use passthrough and should be fine for the time being
[16:22] <pedronis> sergiusens: I understand but given it might take a bit fore core16 to go stable, first class support might make sense
[16:23]  * cachio lunch
[16:23] <zyga> ogra: for ubuntu core 16 - can you use core18 base?
[16:24] <ogra> zyga, i personally might ... 90% of our customers wont want to yet
[16:24] <mup> PR snapd#6102 opened: overlord/snapshots: survive an unknown user <Created by chipaca> <https://github.com/snapcore/snapd/pull/6102>
[16:24] <zyga> ogra: note that it doesn't imply booting core18
[16:24] <Chipaca> ^ that should fix the weird amazon issue
[16:24] <zyga> ogra: but sure, I'm just curious
[16:24] <Chipaca> I still don't know _why_ amazon would trigger it, nor why with -2, but, there ya go
[16:24] <zyga> Chipaca: do you know why the uid is unknown?
[16:25] <ogra> zyga, it talke disk space on a already size limited device
[16:25] <Chipaca> zyga: so there's a /home/foo/snap directory owned by uid -2
[16:25] <Chipaca> zyga: that bit, i have no idea why
[16:25] <zyga> aha...
[16:25] <zyga> hmm
[16:25] <Chipaca> zyga: espeially because the uid comes from stat
[16:25] <zyga> that's indeed curious
[16:25] <Chipaca> zyga: so it's not the syscall.Getuid bug
[16:25] <zyga> I mean, if you stat it in a shell you see -2?
[16:25] <zyga> !
[16:26] <Chipaca> zyga: I haven't been able to reproduce it wiht -debug,  but if I could, I'd see the big uid
[16:31] <bashfulrobot> niemeyer:
[16:31] <Chipaca> bashfulrobot: ssh
[16:31] <Chipaca> :-)
[16:32] <ogra> Chipaca, he should ssh into gustavo ?!
[16:32] <ogra> is there a pub-key available for that ?
[16:32] <Chipaca> bashfulrobot: g.ustavo is presenting and has irc on
[16:32] <Chipaca> bashfulrobot: what could go wrong
[16:33] <bashfulrobot> Chipaca: sorry accidental. Apologies.
[16:33]  * zyga dinner
[16:58] <mup> PR snapcraft#2393 opened: lifecycle: make snapcraft init template use > not | <Created by sparkiegeek> <https://github.com/snapcore/snapcraft/pull/2393>
[17:31] <mup> PR snapcraft#2388 closed: project: early snapcraft.yaml validation <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2388>
[17:31] <mup> PR snapcraft#2391 closed: runtests: run black with --diff <Created by abitrolly> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2391>
[17:32] <zyga> re
[18:19] <pedronis> mvo: https://github.com/snapcore/snapd/pull/6093 , is this really for 2.36 ?
[18:19] <mup> PR #6093: daemon: spool sideloaded snap into blob dir <Created by chipaca> <https://github.com/snapcore/snapd/pull/6093>
[18:20] <mvo> pedronis: yeah, we got a message from field (CE) that it affected a customer
[18:20] <pedronis> ah, ok
[18:20] <mvo> pedronis: if you feel uneasy about this please let me know
[18:21] <mvo> pedronis: it seems relatively harmless (famous last words)
[18:21] <pedronis> mvo: I haven't actually looked at it yet, just wondered to see something still under 2.36
[18:22] <mvo> pedronis: ok
[18:55] <pedronis> mvo: I can look at it in the morning
[18:56] <mvo> pedronis: as you wish - I will leave it until then
[19:07] <zyga> urgh
[19:07] <zyga> rpm -q --whatprovides /usr/share/pkgconfig/systemd.pc
[19:36] <zyga> and now all three suse releases have working snapd
[19:49] <zyga> cachio: hey, do we have opensuse leap 15?
[19:49] <zyga> cachio: and opensuse tumbleweed
[19:50] <zyga> leap 42.3 is a bit dated now
[20:01] <sunesito> hi all
[20:02] <sunesito> i have installed snapd on ubuntu and when i try to run an app i have that error:Gtk-Message: Failed to load module "gail" Gtk-Message: Failed to load module "atk-bridge" Gtk-Message: Failed to load module "unity-gtk-module"  (acestreamplayer:5130): GLib-GIO-ERROR **: No GSettings schemas are installed on the system
[20:02] <sunesito> what am i missing?
[20:11] <zyga> sunesito: hey
[20:11] <zyga> I assume the app doesn't start at all
[20:11] <zyga> what is the name of that app?
[20:11] <sunesito> no
[20:12] <sunesito> acestreamplayer
[20:14] <ogra> you should be using a desktop launcher part for snapcraft
[20:14] <zyga> ogra: I'm not sure if sunesito is the developer of that app
[20:14] <ogra> oh
[20:14] <ogra> yeah, ignore me then (giving developer tips :) )
[20:15] <sunesito> ¿? ill try it
[20:15] <ogra> well, are you the developer of that snap ?
[20:16] <ogra> (i was refrerring to code changes in the snap package)
[20:16] <sunesito> ahhh...no...im not the developer...only a user
[20:17] <ogra> https://snapcraft.io/acestreamplayer ...
[20:17] <ogra> Last updated	Feb 21 2017
[20:17] <ogra> hmm
[20:17] <sunesito> sorry...is this a developers chanel?
[20:17] <ogra> hasnt been touched in nearly two years
[20:17] <ogra> sunesito, no, not at all
[20:17] <ogra> (well ... too ... but as well for user questions/support)
[20:18] <sunesito> thanks...i will investigate under ubuntu problem...because i have running it on debian os
[20:19] <ogra> the snap ?
[20:20] <sunesito> no....the error
[20:20] <ogra> do you have the snap running on debian ?
[20:20] <sunesito> @ogra sorry....yes, the snap with acestreamplayer
[20:20] <ogra> aha
[20:20] <ogra> thats an interesting datapoint
[20:21] <ogra> whats the output of: snap version
[20:21] <ogra> on your ubuntu
[20:21] <sunesito> 2.35.5
[20:21] <ogra> the full output please
[20:21] <sunesito> ok
[20:21] <sunesito> ubuntu_1604:~$ snap version snap    2.35.5 snapd   2.35.5 series  16 ubuntu  16.04 kernel  4.2.8
[20:22] <ogra> where does that kernel come from ?
[20:22] <ogra> thats not an ubuntu kernel
[20:22] <ogra> (and likely the reason for your issue)
[20:23] <ogra> zyga, wasnt there a fix in snapd that warns you if you use an unsupported kernel ? or is that not in stable yet ?? (see above)
[20:23] <sunesito> this is an qnap
[20:23] <sunesito> NAS
[20:23] <zyga> ogra: not exactly, there's only one specific version we warn about
[20:23] <ogra> ah
[20:23] <zyga> on 14.04 that is still on 3.14
[20:23] <sunesito> but i have running snap correctly in this system
[20:23] <zyga> sunesito: interesting, did you install snapd yourself or did it come with it?
[20:24] <zyga> and wait, didn't you say this is a desktop app?
[20:24] <sunesito> i install via apt-get
[20:24] <zyga> is this a NAS with a screen?
[20:24] <sunesito> yes...
[20:24] <sunesito> hdmi port
[20:24] <zyga> :D
[20:24] <zyga> nice, so a nas / desktop :)
[20:24] <sunesito> yes
[20:25] <sunesito> i need to reinstall the ubuntu....and now i have this problem...but i think the problem is in the ubuntu packages
[21:15] <mup> PR snapd#6103 opened: tests: split nested vm suite on core and classic and new snapshots test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6103>


[04:37] <foo> I am helping someone install ubuntu on a Dell PowerEdge SC1435 (http://www.dell.com/content/products/productdetails.aspx/pedge_sc1435) - the system has a SAS 5iR RAID controller. During ubuntu, on the partition screen... it hangs. We tried this: http://ubuntuforums.org/showpost.php?p=1575949&postcount=20 .. any idea why the hang? ALT+F2 didn't show any verbosity or anything, hmm.
[04:48] <foo> Would you guys recommend ubuntu 6.06 LTS AMD64 or x86? I've been told AMD64 isn't too stable... thoughts?
[07:02] <shawarma> foo: amd64 is stable. The only issue with amd64 I'm familiar with is stuff like plugins for firefox, but that's hardly relevant on servers. :-)
[07:03] <foo> shawarma: ahh, yeah. :)
[07:03] <foo> shawarma: thank you :)
[07:03] <shawarma> foo: Where does the boot hang?
[07:04] <foo> shawarma: Right before the partitioner, after he presses enter on the web proxy set up
[07:05] <foo> Someone else suggested to boot with the ubuntu live cd and do the partitioning prior to the install, which isn't a bad idea
[07:05] <foo> Any two cents appreciated :)
[07:22] <shawarma> I'm sorry, I've got to run. I'll be around later, though.
[07:50] <foo> shawarma: alrighty, hit me up if you have some input - thanks
[09:20] <Burgundavia> ivoks: it was you who was discussing network management tools ala zabbix the other day, no?
[09:20] <ivoks> yes
[09:21] <Burgundavia> you looked into that python based one, no
[09:21] <Burgundavia> ?
[09:22] <ivoks> hm.. zenoss?
[09:22] <Burgundavia> yep
[09:22] <ivoks> zenoss requests NOPASSWD in sudoers for /bin/kill
[09:22] <Burgundavia> ya
[09:23] <ivoks> i've asked on devel list about this, but no one responded yet
[09:23] <Burgundavia> ah
[09:23] <ivoks> as soon as i catch some free time, i'll investigate why is this needed
[09:23] <ivoks> i guess there are some processes that run as zenoss user
[09:23] <ivoks> which try to kill processes runed by root
[09:23] <ivoks> this is someting i dislike
[09:24] <ivoks> if that's the case, i'll work on a workaround
[09:24] <foo> Strange
[09:24] <foo> I run nagios now..
[09:24] <foo> I've seen zenoss (and have a zenoss) hat at the socal linux expo... and was going to migrate my stuff to it
[09:24] <Burgundavia> http://dev.zenoss.org/trac/search?q=sudoers&wiki=on&changeset=on&ticket=on
[09:26] <Burgundavia> ivoks: where is the link to the devel list?
[09:26] <ivoks> they got forum :)
[09:26] <Burgundavia> are their any other gotchas in the code that we have picked up?
[09:26] <ivoks> i didn't look at it yet
[09:27] <Burgundavia> ah, I see
[09:27] <ivoks> i started to read INSTALL and saw this
[09:27] <Burgundavia> ok
[09:27] <Burgundavia> I am going to write the asterisk MIR now
[09:27] <ivoks> http://community.zenoss.com/forums/viewforum.php?f=3&sid=8720860bbc055abbbdb95b4b31429498
[09:27] <ivoks> great
[09:27] <Burgundavia> yep, got it
[09:32] <Burgundavia> wow, the zaptel installation method is hideously ugly
[09:48] <foo> Burgundavia: Setting up asterisk or something?
[09:48] <Burgundavia> I already have an asterisk box at work
[09:53] <Burgundavia> it has uptime measured in hours
[09:53] <Burgundavia> and it is built on 2 years old cvs asterisk code
[09:53] <Burgundavia> on White Box EL 3
[09:53] <Burgundavia> but apparently my gf is nagging me to come to bed
[09:53] <ivoks> Burg. have a good night :)
[09:53] <foo> haha
[09:53] <foo> women. *shrug*
[09:53] <foo> :)
[09:53] <foo> ivoks: Heya, you work with dell servers by any chance?
[09:53] <ivoks> couple of them, yes
[09:53] <ivoks> 1600sc and 1500sc
[09:53] <ivoks> that reminded me, i should put back cover on one of them :D
[09:53] <foo> haha!
[09:53] <foo> Sweet!
[09:55] <foo> I'm dealing with the 1435C. trying to help someone get ubuntu on it
[09:56] <foo> Haven't had luck getting RAID0 and RAID1 to work
[09:56] <foo> http://ubuntuforums.org/showpost.php?p=1575949&postcount=20
[09:56] <foo> Going to give that a shot
[09:56] <foo> Any two cents ivoks ?
[10:03] <ivoks> sorry, wasn't here
[10:03] <ivoks> let me see...
[10:04] <ivoks> what raid controler is that?
[10:04] <foo> SAS 5iR
[10:04] <foo> I know that's not what the article shows that I linked, but a friend (lullabud) said it might do the trick
[10:05] <ivoks> ok, that's a hardware raid
[10:05] <ivoks> and megaraid_sas isn't included in initrd? hm...
[10:06] <foo> yu
[10:06] <foo> p
[10:06] <ivoks> but this page is for software raid
[10:06] <foo> ahh
[10:06] <foo> Hmm, we were just going to try it, I had  no idea
[10:07] <ivoks> i.e. if you have hardware raid
[10:07] <foo> I had them try with ubuntu 6.06 and guy said it hung when he got to the partitions part of the install
[10:07] <maswan> a real raid doesn't need any support, it should just appear as normal scsi devices
[10:07] <ivoks> linux will see only one disk (assuming you set up raid before installing)
[10:07] <foo> maswan: agreed.
[10:07] <ivoks> and one can't expirience thise problems
[10:07] <foo> ivoks: ahh
[10:07] <ivoks> these
[10:07] <foo> Alright.. so, I probably need to tell the guy to set up RAID in the RAID BIOS?
[10:08] <foo> er, I shouldn't assume he did that, I did
[10:08] <ivoks> if you can't set it up in bios, than it's software raid
[10:08] <ivoks> right
[10:08] <ivoks> i preferre hw raid, but there are some that preferre linux software raid
[10:08] <maswan> if you want to set it up from inside the OS, it depends on alot of factor
[10:08] <foo> Should SAS 5iR be hardware RAID?
[10:08] <foo> I would prefer hw raid
[10:09] <maswan> probably, yes
[10:09] <ivoks> http://lists.centos.org/pipermail/centos/2006-October/070929.html
[10:09] <ivoks> yes, it is
[10:09] <foo> I see
[10:09] <maswan> handling them from inside the OS usually depends on you finding a management tool and hope it runs on your distribution (and not just red hat 7.2)
[10:10] <foo> hah, I see
[10:10] <foo> We're going with ubuntu
[10:10] <ivoks> good choice :D
[10:10] <foo> Eh, I've gotten so much crap for using ubuntu.
[10:10] <foo> I'm all for giving things a chance...
[10:10] <maswan> It shouldn't be a problem to set it up in bios, you probably want to look for the management tool anyway though
[10:10] <foo> And ubuntus support and everything is just great
[10:10] <maswan> but that's a later problem, not for install
[10:10] <foo> The common answer I get is "it's a desktop distro"
[10:10] <foo> eh, I take it as ignorance and move on.
[10:11] <foo> I see
[10:11] <ivoks> when i installed ubuntu on dells
[10:11] <ivoks> i got setup CD with server
[10:11] <ivoks> whit it i've created raid
[10:11] <ivoks> and then rebooted and started installer
[10:11] <ivoks> iirc, it didn't have raid bios :/
[10:11] <foo> ahh
[10:12] <foo> This should have a raid bios
[10:12] <ivoks> IIRC!
[10:12] <foo> I'm just telling someone, I hope it does
[10:13] <foo> ivoks: You run ubuntu on those other SC servers?
[10:13] <ivoks> yes
[10:13] <ivoks> i run ubuntu only
[10:13] <ivoks> :)
[10:13] <foo> nice. What are your primary reasons for running ubuntu?
[10:13] <foo> (I will use these when I talk to folks as well)
[10:13] <ivoks> personal reasons...
[10:14] <ivoks> i worked with debian for 8 years
[10:14] <foo> I love debian.
[10:14] <ivoks> i do have RHCE, but i find ubuntu to be superior in things i do
[10:14] <foo> hehe
[10:14] <foo> I see
[10:14] <ivoks> for example...
[10:14] <ivoks> rhel 4 has very old samba
[10:15] <ivoks> this samba doesn't work with some versions of MacOSX
[10:15] <maswan> ubuntu on the server is like debian, except it "just works", and we have a bit better experience in speedy security upgrades
[10:15] <maswan> (speaking as to why we use it at work)
[10:15] <[miles] > mornign guys
[10:15] <ivoks> foo: if you need a reason:
[10:15] <[miles] > erm, question:
[10:15] <ivoks> http://www.google.com/trends?q=ubuntu%2C+redhat
[10:15] <ivoks> :)
[10:16] <maswan> oh, and a resonable upgrade schedule, so that when you feel like doing a site upgrade, there is always something _resonably_ fresh around
[10:16] <[miles] > I've just put in a ubuntu server 6.06, and it's fine...
[10:16] <ivoks> right
[10:16] <[miles] > but, I have a fwbuilder script that I execute on boot, and it's churning all the logs to the terminal
[10:16] <[miles] > is there no syslog installed by default?
[10:16] <ivoks> i could go with newer apache, php etc on redhat
[10:16] <ivoks> but i loose support then
[10:16] <ivoks> and i'm on my own...
[10:16] <ivoks> with ubuntu i'm safer
[10:17] <ivoks> i can go with dapper or some newer version for 'edgy' setups
[10:17] <foo> ivoks: thank you! Hm, where are you located? If you don't mind me asking
[10:17] <ivoks> foo: zagreb, croatia
[10:17] <ivoks> foo: with clients even outside croatia :)
[10:17] <foo> hm, never heard of .. either of those... hehe, anyways, cool! Thanks, I'll hang around here.
[10:18] <[miles] > ivoks: you know nxor?
[10:18] <ivoks> [miles] : no
[10:18] <ivoks> [miles] : maybe, but not by nickname
[10:18] <[miles] > he's a SUSE guy
[10:18] <[miles] > Daniel Radic
[10:18] <ivoks> no, i'm afraid not...
[10:19] <[miles] > http://smeet.zeilers.net/2006/attendees
[10:19] <[miles] > right... coffee time
[10:19] <[miles] > bbiab
[10:19] <ivoks> [miles] : yes, there is syslog
[10:19] <ivoks> [miles] : you should set it up to not display iptables messages to console
[10:19] <[miles] > ivoks: weird, cos on the other box, it's not doing it
[10:19] <[miles] > just the UBS 6.06 one
[10:20] <ivoks> well, i can't check it out now, cause i have to go...
[10:20] <ivoks> bbl
[11:03] <[miles] > yo
[11:03] <lionel> hey [miles]
[11:03] <[miles] > mmm syslog was installed.. how strange... I have no idea why the firewall logs are getting outputed to the console :-|
[11:04] <[miles] > bonjour lionel
[11:05] <[miles] > lionel: do you have any idea as to why this might be happening please?
[11:08] <lionel> firewall usually log on console and syslog
[11:09] <lionel> iirc it is log priority related
[11:10] <lionel> dmesg -n 1 should prevent this
[11:10] <[miles] > sorry back now
[11:11] <[miles] > it's a fwbuilder script
[11:12] <[miles] > lionel: is there a configuration file where I should specify the -n 1
[11:12] <[miles] > ?
[11:12] <lionel> I don't know :-(
[11:13] <[miles] > lionel: ok, np, I'll google around, for sure you've hit the nail on the head tho
[11:13] <lionel> let me know if you find a solution :)
[11:13] <[miles] > nod, thanks dude
[11:13] <[miles] > I will
[11:15] <[miles] > I can't check it until nearly 14:00
[11:15] <[miles] > damn it
[11:15] <[miles] > cos it's the firewall for the internel network... got 2 x boxes... can't swap'em around
[11:45] <[miles] > lionel: FYI, I just made some modifications, simply adding /bin/dmesg -n 1 did work, many thanks for that info dude
[11:45] <[miles] > I placed it in the .fw script btw
[11:45] <lionel> hehe ;)
[11:45] <lionel> that's a solution
[11:45] <[miles] > seems thats what everyone does
[11:46] <[miles] > lionel: UBS 6.06 makes a nice firewall...
[11:46] <[miles] > lionel: bare min... superb
[11:46] <lionel> UBS ?
[11:46] <[miles] > lionel: may I ask you, your relations with ubuntu are at a personal level or business?
[11:46] <[miles] > Ubuntu Server
[11:46] <lionel> both
[11:46] <[miles] > lol
[11:47] <lionel> I have about 20 servers here under Ubuntu
[11:47] <lionel> (here = at work)
[11:48] <[miles] > ah ok
[11:48] <lionel> most of my servers in fact (some still in Debian and very few run Windows)
[11:48] <[miles] > lionel: may I pm you?
[11:48] <lionel> sure !
[12:17] <foo> [miles] : Would you happen to run the servers with ubuntu on dell hardware?
[12:19] <[miles] > yes
[12:20] <[miles] > foo: our hwp is dell
[12:20] <foo> sweet, which ones?
[12:20] <[miles] > poweredge
[12:23] <ivoks> foo: no luck with dell?
[12:28] <lionel> here also i use Dell Powerdge
[12:29] <foo> ahhh, sweet... you guys rock
[12:29] <foo> ivoks: ah, I've shot him an e-mail - he's going to try it tomorrow, I don't have physical access, just remote
[12:29] <foo> [miles] : 1435SC by any chance?
[12:30] <[miles] > mmm will have to check
[12:30] <[miles] > foo: gimme 5 mins please
[12:30] <foo> [miles] : ah, no problem - thanks!!
[12:35] <foo> lionel: What about you? Dell poweredge 1535SC by any chance
[12:35] <foo> ?
[12:35] <foo> (if you'd happen to knw0
[12:36] <foo> know)
[12:36] <lionel> no, I have only 850, 860, 1850, 1950 :-(
[12:37] <lionel> foo: what is your problem ?
[12:37] <davekempe> foo is the 1535c a new model? what problems are you having with it?
[12:37] <foo> lionel: Had some issues with the SAS 5iR RAID Controller... was just looking for living proof that someone got it working, hehe
[12:38] <lionel> foo with Dapper ?
[12:38] <foo> Ubuntu 6.06 LTS AMD64 hung after the proxy setup... which is right before the partitioning part
[12:38] <davekempe> do you have the lspci output?
[12:38] <foo> I'm helping someone set it up and I'm thinking he didn't configure the RAID array in the RAID BIOS
[12:39] <foo> davekempe: Can't get that far :) Might try the ubuntu live cd tomorrow if he did build the raid array
[12:39] <davekempe> yeah. feisty kubuntu or knoppix 5.8 might be a good source of info
[12:39] <davekempe> whats your target distro? dapper?
[12:40] <lionel> davekempe: kubuntu ? :)
[12:40] <foo> haha.
[12:40] <foo> Would like to get dapper LTS AMD64 working if possibly
[12:40] <foo> If need be, 6.10... but starting with that
[12:40] <foo> I'd be able to troubleshoot more if I had physical access to the server, but since I don't - I'm trying to ask around to make it easy on the guy, hehe
[12:40] <davekempe> lionel, kubuntu cos i prefer konsole, and cos its the best amd64 livecd around
[12:41] <lionel> davekempe: no problem, I would have said "Feisty live CD" to avoid (k)Ubuntu troll ;)
[12:41] <davekempe> foo, when this has happened to me (quite a few times now) I have needed a lengthy session at the console to get things work
[12:41] <davekempe> lionel,  :)
[12:42] <lionel> Time for lunch here. bbl
[12:42] <foo> davekempe: eek. To my understanding the SAS 5iR RAID card is true hardware RAID... so, if the RAID array is built successfully, it should work fine... I assumed he built the array, but have not confirmed
[12:42] <davekempe> foo - SAS is a new storage mechanism, so 'true' or not, dapper might not support it nicely
[12:42] <ivoks> is there realy something to troubleshot or you are just guessing?
[12:43] <foo> davekempe: I see
[12:43] <ivoks> davekempe: it does
[12:43] <foo> ivoks: Wha? Yeah, it hung after the http proxy setup, right before the partition
[12:43] <ivoks> sas has little to non impact on OS
[12:43] <foo> I see
[12:44] <foo> ivoks: hehe, I don't doubt ya, just askin' around.
[12:44] <foo> Anywho, hopefully he just needs to build the array and we can be on our merry way
[12:44] <foo> lionel: Lunch? Geez, it's 4am here. hah
[12:44] <davekempe> ivoks, i have had plenty of trouble with various sas controllers and dapper, not sure what you are getting at
[12:44] <ivoks> foo: i'm just interested if you tried to install ubuntu or just asking random people do they have problems with dell? :)
[12:44] <[miles] > sorry I have to run out of the office to meet the wife... foo, I'll be back shortly
[12:44] <ivoks> davekempe: lol... well, i had none :)
[12:45] <foo> [miles] : np
[12:45] <foo> ivoks: ah, we've tried... hence how I know it froze. It was explained to me, though, and I have to maybe explain to him how to build the RAID array, we'll see
[12:45] <ivoks> it froze?
[12:45] <ivoks> i doubt it frozed cause of raid controller
[12:45] <foo> froze... hung .. no progress bar movement.. yeah.
[12:45] <ivoks> did you try booting it with pci=nommconf?
[12:45] <davekempe> foo, the exact same thing happens to me on a Sun 4100 SAS, but only when the mirror was configured
[12:45] <foo> It was right before partition setup.. don't know.
[12:46] <foo> ivoks: nope, should we try that?
[12:46] <ivoks> ah.. i see
[12:46] <foo> I see
[12:46] <davekempe> the ibm base model server x405 i think did something simiilar as well
[12:46] <davekempe> and adaptec sas controller in that one
[12:47] <davekempe> you gotta get in front of the machine, switch to alternate console and go from there
[12:47] <foo> alternate console = alt+f2 ?
[12:47] <davekempe> on the Suns, the installer sits there spewing messages about a floppy controller or something, then finally gets there.... but seriously, we need more info before we can help you
[12:47] <davekempe> or alt+f3 or F4
[12:47] <ivoks> right
[12:47] <foo> Right, I told him to do that.. said it was just a normal login.
[12:48] <foo> I have seen verbosity there myself, which is why I asked him
[12:48] <foo> Hm, I'm assuming a DRAC card would allow me to do this all remotely, right?
[12:48] <ivoks> what else do you need except normal login?
[12:48] <ivoks> then you have dmesg
[12:48] <ivoks> lsmod and all the tools for diagnose
[12:48] <foo> ivoks: err, good point, I'm used to just seeing dmesg on that console. I'll have him do that tomorrow
[12:48] <foo> for sure
[12:49] <foo> hm, can he set up ssh too, hehe
[12:49] <ivoks> yes
[12:49] <davekempe> alt+f3 might do it, or F4 I can't remember. i just do its instinctively
[12:49] <foo> ahh, sweet. thanks guys
[12:49] <ivoks> err... no, only if he install it first :)
[12:49] <foo> ah, yeah, he can probably bring the network up and get me in, nice
[12:49] <davekempe> if you really can't get it working, boot off a livecd, install ssh an get in from there
[12:49] <foo> heh, no need for a livecd, then
[12:50] <foo> yeah
[12:50] <davekempe> then you can use debootstrap to install dapper
[12:50] <davekempe> and even build a custom kernel
[12:50] <ivoks> or build custom kernel and do net boot
[12:50] <ivoks> anyway... bll
[01:02] <foo> ah, turns out he did set up the RAID array
[01:09] <dballester> hi to all
[03:22] <Odd_Bloke> Hi guys, I'm running kernel 2.6.15-26-server (Dapper) and need the kernel headers. There is not, however, an equivalent headers package. Can I get headers for this kernel or do I need to upgrade to a (marginally) more recent kernel?
[03:23] <ivoks> huh?
[03:23] <ivoks> linux-headers-2.6.15-26-server
[03:24] <ivoks> and... that's old kernel
[03:24] <ivoks> you should update your server
[03:24] <Odd_Bloke> Hmm, I appear to be going insane.
[03:24] <Odd_Bloke> ivoks: I've just installed it, and it didn't upgrade it automatically...
[03:25] <ivoks> it won't do that
[03:25] <ivoks> you have to manually update it
[03:26] <ivoks> i would suggest installing linux-server package
[03:27] <Odd_Bloke> ivoks: Already installed.
[03:27] <ivoks> then apt-get update
[03:27] <ivoks> apt-get dist-upgrade
[03:27] <ivoks> ?
[03:28] <Odd_Bloke> I've never had a dist-upgrade work in my life.
[03:28] <ivoks> this will not install newer distribution
[03:28] <ivoks> but a upgrade for kernel
[03:28] <ivoks> s/a/an
[03:29] <Odd_Bloke> It didn't install anything.
[03:30] <mralphabet> did you do the update first?
[03:30] <Odd_Bloke> Yup.
[03:30] <ivoks> are you sure you aren't running 2.6.15-28?
[03:31] <Odd_Bloke> I am.
[03:31] <Odd_Bloke> (Sure)
[03:31] <ivoks> so... you don't have internet repositories enabled?
[03:31] <Odd_Bloke> Though, looking at /boot, I do have 2.6.15-28 installed.
[03:31] <ivoks> ok...
[03:32] <Odd_Bloke> OK, now it's booting with 2.6.15-28
[03:38] <[miles] > mmm anyone having problems accessing security.ubuntu.com
[03:38] <[miles] > ?
[03:39] <[miles] > mmm anyone having problems accessing security.ubuntu.com
[03:40] <lionel> it is very slow / unavailable for me since this morning
[03:44] <[miles] > ah ok, not just me then
[03:44] <[miles] > lol
[03:52] <ivoks> i use mirrors archive
[04:06] <[miles] > guys, u know a way to view the cache in bind?
[04:08] <ivoks> dig @localhost :)
[04:08] <ivoks> dig @localhost [domain]
[04:09] <ivoks> actualy, <domain>
[04:11] <[miles] > nah, rndc dumpdb
[04:11] <[miles] > :)
[04:12] <[miles] > works perfectly
[04:40] <[miles] > jesus, the update servers are slowww today
[04:40] <[miles] > gonna have to setup a proxy cache
[04:41] <[miles] > mmm whats better, apt-proxy or apt-cacher ?
[04:42] <lionel> hey ;)
[04:42] <[miles] > :P
[04:42] <lionel> If you have bw, the best is probabily a local miror
[04:43] <[miles] > really?
[04:43] <[miles] > lionel: you don't use apt-proxy or apt-cacher?
[04:43] <lionel> from what I have seen, squid tends to replace apt-proxy/apt-cacher
[04:43] <lionel> no
[04:44] <lionel> Dapper i386 is "only" 9G of disk
[04:44] <lionel> if you have many system with that...
[04:44] <[miles] > ok
[04:44] <lionel> I have a boubt on 9...
[04:44] <lionel> may be 13
[04:44] <lionel> but with some bandwith, it should not be a problem
[04:45] <ivoks> i would suggest squid too
[04:59] <[miles] > ivoks: :-|
[04:59] <[miles] > mmm
[08:40] <EtienneG> miles, we use apt-cacher here with good success
[09:49] <coNP> hey
[09:49] <coNP> is it possible to install a ubuntu server (in fact the alternate, because I need RAID as well) from a running system?
[09:50] <coNP> just as I were using ubiquity (that is not a solution, however, because it does not support RAID if I am right)
[09:52] <mralphabet> coNP: without a reboot?
[09:52] <mralphabet> or rather, what do you mean by running?
[09:52] <coNP> I have a desktop machine
[09:53] <coNP> I have a hard disk installed on that  I want to have the new system
[09:53] <coNP> I want to boot my desktop machine and then install the new system
[09:53] <coNP> while I am able to perform regular tasks as answering e-mails, etc.
[09:54] <coNP> finally I remove the hard disk and put it back to the new machine
[09:56] <mralphabet> I do not understand why you just can't install ubuntu on the new machine, it takes 15 minutes
[09:57] <coNP> because I only have the hard disk here:)
[09:57] <coNP> and I don't want to move the whole big machine
[09:57] <Burgwork> you can do that
[09:57] <Burgwork> grab the alternate, install on it
[09:57] <Burgwork> swap the harddrive
[09:57] <Burgwork> go
[09:57] <coNP> sure that is what I wanted
[09:58] <coNP> but then I imagined that it might be possible to install from my desktop
[09:58] <shawarma> coNP: It is. You can use debootstrap.
[09:59] <coNP> oh, thanks
[10:01] <coNP> I install the hard disk and -- hopefully :) -- come back
[10:02] <mralphabet> is it me or is that just overcomplicating the process
[10:05] <shawarma> mralphabet: Probably.
[10:05] <radevil_> hello
[10:06] <radevil> hello
[10:07] <radevil> I want to apply to the ubuntu server developer team
[10:07] <radevil> is there anybody here that works for canonical in that position that can gives me some information please?
[10:11] <mralphabet> http://www.ubuntu.com/employment#head-9a9627b56fd16e9c958afc0774a78ef29d3c9098
[10:11] <mralphabet> not sure if you have seen that
[10:37] <radevil> well i wanted to know about the job
[10:37] <radevil> how much time does it takes
[10:38] <radevil> schedule
[10:40] <mralphabet> I don't know that anyone here works for canonical
[10:41] <radevil> mmm so you're all colaborating with support
[10:42] <Burgwork> radevil: which job?
[10:42] <mralphabet> I could easily be wrong, but it isn't something that has been brought up
[10:42] <radevil> ubuntu server developer
[10:44] <Burgwork> right
[10:44] <Burgwork> for that you would need to talk to canonical direclty
[10:44] <radevil> do yuo wirk for canonical??
[10:44] <Burgwork> no
[10:45] <radevil> you work*
[10:46] <radevil> mm ok, well i though i could find someone that works for them to find some more information about the schedule, and some other stuffs
[10:46] <radevil> thanks a lot for the help
[10:46] <Burgwork> radevil: wait
[10:46] <Burgwork> basically, the job requires you to have some debian skills and lot of server experience
[10:46] <Burgwork> you can work from home
[10:47] <Burgwork> there are a minimum of two international conferences you would need to attend each year, called Ubuntu Development Summits
[10:47] <Burgwork> do you have experience with open source in general?
[10:48] <radevil> yes, i have experience working with debian servers
[10:49] <radevil> LDAP, Bind DNS, iptables, apache, etc ...
[11:05] <shawarma> Burgwork: Why would you want general support to go to #ubuntu-server-admin instead of #ubuntu ?
[11:06] <Burgwork> because #ubuntu is completely and totallly full
[11:06] <Burgwork> I would rather have -admin merge into here, as we are not busy here
[11:07] <shawarma> Oh, #ubuntu-server-admin is not new?
[11:07] <shawarma> I just never heard about it before.
[11:08] <shawarma> Burgwork: Even though #ubuntu is full, it's still the proper place to ask how to install nvidia drivers and whatnot.
[11:08] <Burgwork> is new
[11:09] <Burgwork> if we are trying to promote Ubuntu on the server, throwing them to #ubuntu is not a good way to do it
[11:09] <shawarma> Definitely not.
[11:09] <Burgwork> I suspect that most people running on Ubuntu ont he server know those basic things
[11:09] <shawarma> But this channel is for server support, too?
[11:09] <Burgwork> they are looking for higher level advice
[11:09] <Burgwork> oh, right
[11:09] <ivoks> :)
[11:09] <Burgwork> I didn't read the topic before I changed it
[11:10] <ivoks> this is dev+support channel :)
[11:10] <radevil> lol
[11:10] <ivoks> Burgwork: is good to know that we all think a like :)
[11:11] <Burgwork> shall we merge -server-admin into this one?
[11:11] <ivoks> sure
[11:12] <Burgwork> innatech registered it


[10:07] <RikMills> 5.25.1 is now landed in kinetic release
[10:57] <keithzg[m]> Wait lock and logout are being removed from right-click on the desktop? Damn, if KDE was still on Phabricator I'd be complaining about this, but I can never figure out how to navigate GitLab so I'll just briefly whinge here and move on I guess ;)
[12:18] <BluesKaj> Hi all
[15:27] <mmikowski> RikMills: Got 5.21.1. Thank  you! Plasma still crashy when changing themes. Vertical panels look less broken, *possibly* unbroken. Testing is ongoing...
[16:42] <Eickmeyer> keithzg[m]: So, it *can* be added back, but removing it by default does seem like a bad move.
[19:50] <bkovacs7> Is KDE 5.25 still in the landing backports?.
[19:59] <RikMills> bkovacs7: yes, as there are still some bugs of concern
[20:00] <RikMills> though if you want to test, feedback is great
[20:12] <bkovacs7> Thx


[00:09] <Unit193> canthus13: So if I move your keyboard, you're really messed up?
[00:23] <canthus13> Unit193: nah.   I just went beta
[02:26] <Unit193> Ubuntu 11.04? Xubuntu is nice too
[02:27] <TheErk> yes 11.04
[03:05] <BiosElement> Anyone need a Humble Indie Bundle key? I've still got some gift codes I never got around to using. >.>
[03:06]  * Cheri703 has a friend who gave access to both bundles :)
[03:06] <Unit193> What games are even on there?
[03:06] <BiosElement> Unit193: http://humblebundle.com/
[03:09] <Unit193> Never heard of those games... how are they?
[03:09] <Cheri703> world of goo = fun!
[03:10]  * Unit193 just looked at that and remembered my cousin had/has that
[03:12]  * Cheri703 got enough donations to cover the cost of the passport!!
[03:12] <Cheri703> \o/
[03:12] <Unit193> That's great! do you know how many people helped?
[03:13] <Cheri703> 5
[04:42] <Unit193> Cheri703: http://viralintrospection.wordpress.com/2010/09/06/a-different-philosophy-in-designing-keyboard-layouts/
[04:45] <Cheri703> interesting
[04:45] <Unit193> You'll never be able to use another keyboard...
[04:46] <Cheri703> eh, I'm familiar enough with qwerty
[04:46] <Cheri703> I don't think I'll lose that
[04:46] <Unit193> I would think about switching, but I don't want to figure another layout or have it change depending where I am...
[04:47] <canthus13> bah. why won't rsync sync mp3s that have had the tags changed? :(
[06:24] <Unit193> Not too fond of season 3 of BSG...
[06:24] <sethly> BSG gets kinda weird somewhere around the middle of the series
[06:24] <Cheri703> yeah, it got weird
[06:24] <Cheri703> heh
[06:27] <Unit193> I kinda liked how it was going...
[06:30] <sethly> what's happening in the 3rd season?
[06:38] <Unit193> I just started, but that's when they skip a year and they are on New Caprica
[06:39] <sethly> ah with fat apollo
[06:40] <Unit193> Yeah... what the heck went on in that year?
[06:40] <Cheri703> ohhh, yeah, I remember
[06:40] <Cheri703> you'll see :)
[06:40] <Unit193> PLEASE Don't tell me...
[07:02] <Unit193> Cheri703: The LUG here: http://www.facebook.com/group.php?gid=339594106111 - http://ncolug.net/ - http://www.freelists.org/list/ncolug
[07:06] <Cheri703> kk
[17:45] <Unit193> Yay for bloody noses in the middle of the night!
[17:45] <Unit193> Also, good morning Ohio!