[12:42] <_ion> Hm, Keybuk hasn't been here for three days.
[02:16] <osx5> hello
[02:18] <osx5> anyone from freenode staff here?
[02:18] <AStorm> Md?
[02:19] <osx5> k
[02:26] <osx5>  Md must be afk
[02:27] <_ion> How may we help you with upstart?
[02:27] <osx5> I want a hostname cloak
[02:27] <osx5> but thanks
[02:28] <osx5> is upstart better/
[02:28] <osx5> ?
[02:28] <_ion> Well, yes. :-)
[02:29] <osx5> what makes it better?
[02:29] <osx5> I use darwin on mac osx
[02:32] <_ion> See the "How does it differ from launchd?" heading at http://www.netsplit.com/blog/articles/2006/08/26/upstart-in-universe
[02:32] <_ion> (Seems like the page's markup is broken)
[02:32] <osx5> k
[02:32] <osx5> I'm new to unix
[02:32] <osx5> and linux
[03:08] <osx5> will MD ever return?
[03:09] <_ion> Let me check his wereabouts from my surveillance equipment...
[03:09] <osx5> lol
[03:11] <osx5> oh he left
[03:11] <osx5> wonderful
[03:11] <osx5> lol
[10:35] <_ion> Welcome back, Keybuk :-)
[10:36] <Keybuk> heyhey
[10:36] <Keybuk> "welcome back" ? :P
[10:36] <Keybuk> did I go somewhere?
[10:37] <_ion> For almost 3 days you did. ;-)
[10:38] <Keybuk> we call that a "weekend" :p
[10:38] <_ion> Hehe
[11:05] <Keybuk> "until" is causing me issues
[11:07] <_ion> Why is that?
[11:07] <Keybuk> well, how it should behave
[11:07] <Keybuk> simplest example:
[11:07] <Keybuk>   foo until bar
[11:07] <Keybuk> I think it's pretty obvious that the job is running when foo happens, and stops running when bar happens
[11:08] <Keybuk> however ... if foo happens again after bar has happened, should the job be started again or not?
[11:08] <_ion> I do think it should.
[11:09] <Keybuk> I agree, simply on the basis that upstart shouldn't consider anything to be permanent
[11:09] <Keybuk> e.g. in an upstart system, you should be able to kill all processes, then issue the "startup" event again as a kind of soft reboot
[11:10] <_ion> Also, '(foo and baz) until bar': IMHO after bar, *both* foo and baz should happen again.
[11:10] <Keybuk> hang on, getting to that ;p
[11:10] <Keybuk> so, with the above example, we can implement until simply
[11:11] <Keybuk> it's just a tree node that is TRUE when the left becomes TRUE, and FALSE when the right becomes TRUE
[11:11] <Keybuk> no further handling is needed
[11:11] <Keybuk> so right, more complex example as you said
[11:11] <Keybuk>   (foo or bar) until baz
[11:11] <Keybuk> I think that's pretty obvious; either foo or bar must happen for it to be started, baz stops it, and either foo or baz can start it again
[11:12] <_ion> Yeah, with the 'and' case the implementation definitely becomes more complex.
[11:13] <Keybuk> right
[11:13] <Keybuk>   foo until (bar or baz)
[11:13] <Keybuk> that's still simple
[11:13] <Keybuk> and makes it more complex
[11:13] <Keybuk>   (foo and bar) until baz
[11:13] <Keybuk> now, I think this should behave thus:
[11:13] <Keybuk>  foo and bar need to happen in any order for the job to be started
[11:13] <Keybuk>  baz happening stops it
[11:14] <Keybuk>  after which, both foo and bar need to happen again
[11:14] <Keybuk> (rather than just one or the other happening)
[11:14] <_ion> Indeed.
[11:15] <Keybuk> so that makes the implementation a little more complex
[11:16] <Keybuk> when the right hand side is set to TRUE, the until node becomes FALSE *and* sets the left hand tree to FALSE
[11:17] <Keybuk> (ie. all nodes in the left hand tree)
[11:18] <Keybuk> does that sound sane?
[11:22] <_ion> Is '(foo until bar) until baz' supported? (I can't think of any use cases for it  wouldn't it be exactly equivalent to 'foo until baz'?)
[11:22] <Keybuk> we'll get to that in a bit, thinking this one step at a time
[11:22] <Keybuk>   foo until (bar and baz)
[11:23] <Keybuk> that's somewhat interesting
[11:23] <Keybuk> foo starts it, but bar and baz both need to happen to stop it
[11:23] <Keybuk> once stopped, only foo needs to happen to start it again; but both bar and baz need to happen again to stop it
[11:23] <Keybuk> so that implies that when the left hand side is set to TRUE, the until node becomes TRUE *and* sets all nodes on the right hand side to FALSE
[11:25] <_ion> Yes, it seems to me that nodes should be able to recursively set children to FALSE.
[11:25] <Keybuk> right
[11:25] <Keybuk> so (foo until bar) until baz
[11:26] <Keybuk>      until
[11:26] <Keybuk>   until  baz
[11:26] <Keybuk> foo  bar
[11:26] <Keybuk> foo has to happen for the tree to be TRUE
[11:26] <Keybuk> if either bar or baz happens, the tree becomes FALSE
[11:27] <_ion> Ah, right.
[11:27] <Keybuk> in either case, only foo needs to happen again for it to become TRUE again
[11:27] <Keybuk> so it's exactly equivalent to foo until (bar or baz)
[11:29] <_ion> So when baz happens, the topmost 'until' asks the child 'until' to set itself as FALSE, which doesn't need to do anything else than ask all its children to set themselves FALSE.
[11:30] <Keybuk> tight
[11:30] <Keybuk> right
[11:30] <_ion> (Thinking like OOP and recursive programming, of course the actual implementation doesn't need to be either object-oriented or recursive.)
[11:32] <Keybuk> *nods*
[11:32] <Keybuk> I actually have a non-recursive tree iterator in libnih
[11:32] <Keybuk> but anyway
[11:32] <Keybuk> right
[11:32] <Keybuk> so until is quite simple provided that all operators and operands are simple
[11:33] <_ion> Yeah, i remember skimming through that change.
[11:33] <Keybuk> lets introduce a less simple operator/operand
[11:33] <Keybuk> with JOB
[11:33] <Keybuk> how do we define that?
[11:33] <Keybuk> either its TRUE when the job's goal is START and FALSE when the job's goal is STOP
[11:33] <Keybuk> OR
[11:33] <Keybuk> its TRUE when the job's state is RUNNING and FALSE otherwise
[11:33] <Keybuk> OR
[11:34] <Keybuk> its FALSE when the job's state is WAITING and TRUE otherwise

[11:34] <_ion> :-)
[11:34] <_ion> Its use cases should probably be listed to find the answer.
[11:34] <Keybuk> the problem is it was defined over hot thai food
[11:34] <Keybuk> while we were crying and sweating
[11:35] <_ion> Hehe
[11:35] <Keybuk> and before we came up with the idea that "starting" and "stopping" should be blocking events
[11:35] <_ion> So, *are* there use cases for it that can't be done with the already existing things?
[11:35] <Keybuk> well...
[11:35] <Keybuk> obviously you can use until and the job events
[11:36] <Keybuk>   starting JOB until stopped JOB
[11:36] <Keybuk>   started JOB until stopping JOB
[11:36] <Keybuk> with the advantage that those retain the blocking behaviour
[11:36] <Keybuk> the actual use case for "with" was that you could place complex stanzas in a file that could be shared
[11:37] <Keybuk> and then just say "do whatever that one says"
[11:38] <Keybuk> it also happens to provide a "running with another job without blocking it" kind of syntax
[11:43] <_ion> What are the use cases for that? I.e. what are the jobs that should run 'with' another job without blocking it?
[11:44] <Keybuk> dunno
[11:44] <Keybuk> the main use case seems to be putting syntax in another file
[11:47] <_ion> For example, if there's a dummy job 'networking' with nothing but 'on' stanzas, i think it is good for a job using 'started networking until stopping networking' to block whatever 'networking' blocks.
[11:47] <Keybuk> a reasonable point
[11:58] <Keybuk> ok, so let's skip with for now
[11:58] <Keybuk> and think ahead to temporary events
[11:58] <Keybuk> "every hour" for example
[11:58] <Keybuk> every hour and network-up until network-down
[11:58] <Keybuk> pretty obvious; the "every hour" event triggers once an hour
[11:58] <Keybuk> and and combines that with the until, so it only gets used if the network is up
[11:58] <Keybuk> ...
[11:59] <Keybuk>   every hour until some-event
[11:59] <Keybuk> that one is a bastard :p
[11:59] <_ion> Hmm... :-)
[12:00] <Keybuk> I think some of the problem is the words we're using
[12:00] <_ion> I can't think of anything else than starting it at every hour and stopping it when some-event happens.
[12:01] <_ion> Sorry, i mean:
[12:01] <Keybuk> if "foo until bar and frodo until bilbo" was actually "between foo and bar while between frodo and bilbo", it makes more sense
[12:01] <Keybuk> so it'd be obvious that "between every hour and some-event" behaves as you describe (which is how it would behave)
[12:01] <_ion> Start it at 00:00. Nothing changes until 03:12, when some-event happens. Start it at 04:00, until some-event happens again
[12:01] <Keybuk> right
[12:02] <Keybuk> English and Logic don't collide adequately
[12:02] <_ion> Heh
[12:03] <Keybuk> (the fact that in English, "foo until bar and frodo until bilbo" describes a period where either of the two is active (where logically it's when both are active)
[12:03] <Keybuk> and "foo until bar or frodo until bilbo" describes a period where only one of the two is active (when logically it's when either are active))
[12:06] <_ion> Would substituting 'or', 'and', 'until' with |, &, -> respectively be too ugly?
[12:07] <_ion> The Finnish keymap also has  :-)
[12:08] <_ion> Although i don't use it for anything else than writing Finnish specifically, it sucks for general use. :-)
[12:10] <Keybuk> I don't think the punctuation changes anything, as you'd still read it in English
[12:11] <Keybuk> http://upstart.ubuntu.com/wiki/ComplexEventConfig
[12:11] <Keybuk> ^ so that's a reworked draft
[12:11] <_ion> True.
[02:30] <_ion> Looks nice.
[06:51] <_ion> keybuk: Have you had time to hack more on replacement-initscripts yet?
[06:52] <Keybuk> not yet
[06:52] <Keybuk> well
[06:52] <Keybuk> have been thinking and experimenting deeply with mounting filesystems
[06:52] <Keybuk> my original plan had been an instance job fired up each time a drive was mounted
[06:52] <_ion> That's actually what i wanted to ask about...
[06:52] <Keybuk> and the job was just to mount that path
[06:52] <Keybuk> and have a similar one for unmounting
[06:53] <Keybuk> but that doesn't work in the face of needing to mount /usr/local after /usr
[06:53] <_ion> Exactly. Have you got a solution yet?
[06:59] <_ion> An idea, probably filled with race conditions :-) : a file on RAM disk that contains the list of filesystems ready to be mounted. The 'fsck' job could contain 'echo "$DEVICE" | locked-write --append /ramdiskpath/mount; /sbin/initctl emit filesystem-checked -eDEVICE' and the 'mount' job would start on filesystem-checked and contain 'locked-read /ramdiskpath/mount | while read device ... ... for device in $ok_to_mount; do [mount them] '
[07:00] <_ion> Feel free to punch holes in it. :-)
[07:02] <_ion> whatever starts on block-device-removed would have to remove the devices from the list while locking it.
[07:03] <_ion> That's what the mount job should do on successful mount, too.
[07:09] <AStorm> Keybuk, what about using dependencies to do this? :>
[07:10] <AStorm> Just add parametrised dependencies (e.g. use of $VALUE in deps)
[07:30] <Keybuk> I'm vaguely leaning towards just having a "mount -a" job and make sure that fails if at least one filesystem could not be mounted
[07:32] <_ion> How about ones being fsck'd?
[07:33] <Keybuk> aye, tricky
[07:34] <Md> Keybuk: check what suse does, I know that for a long time they have been running fsck/mount on demand triggered by uevents
[07:40] <Keybuk> Md: good point
[07:43] <Md> if all else fails, sleep for a while in a loop if the mount point does not exist
[07:45] <_ion> mountd? :-)
[07:46] <Keybuk> HAL!
[07:46] <Keybuk> sometimes I wish I worked for Apple
[07:47] <Keybuk> then I'd know everything was on the one filesystem
[07:47] <Keybuk> :p
[07:47] <_ion> Heh
[07:49] <Keybuk> SUBSYSTEM=="block", ACTION=="add", KERNEL=="sd*[0-9] |hd*[0-9] ", RUN+="mount.sh"
[07:49] <_ion> mount.sh does the fscking, too?
[07:49] <Keybuk> yup
[07:50] <Keybuk> (not that I had a handy vmware instance of opensuse around or anything ...)
[07:50] <_ion> And what does it do when there's /usr/local waiting for /usr?
[07:50] <Keybuk> it just runs mount -a after each fsck
[07:52] <_ion> I take it udev has a command queue, multiple mount.shs are never started simultaneously?
[07:53] <Md> no, they are
[07:53] <_ion> Does mount.sh contain locking then?
[07:53] <_ion> I probably should just grab the script from somewhere myself. :-)
[09:14] <Keybuk> _ion: it calls mount -a $DEVNAME
[09:14] <Keybuk> which is interesting
[09:14] <Keybuk> it doesn't seem to account for mountpoint not existing at all


[01:04] <mhall119> MTecknology: you're working on the drupal theme, right?
[01:05] <mhall119> stas: and you the wordpress?
[01:05] <mhall119> I'm wondering how much you guys pull in from light-base-theme, if what we can do to make that easier for you
[01:54] <MTecknology> mhall119: I don't pull in much from that actually. It was great as a base to work from
[02:07] <stas> mhall119: yep
[02:08] <stas> i rewrote the css, cause
[02:08] <stas> body                                {color: #000;} /*sucked*/
[02:08] <stas> sorry, but it is true
[14:32] <mhall119> MTecknology: then I'd like to re-work the light-base-theme branch to let you guys use it more
[14:53] <mhall119> MTecknology: when you get a chance, can you look at http://paste.ubuntu.com/576479/
[14:53] <mhall119> I'm writing up the web-development pages for developer.ubuntu.com
[14:54] <mhall119> is there anything drupal-related in the Ubuntu repos that you think should be featured?
[14:54] <mhall119> or javascript libraries, or community resources I've left out
[14:55] <mhall119> newz2000: ^^


[04:31] <OvenWerks> well i managed to built a source package and upload it to a personal PPA
[04:31] <OvenWerks> it doesn't show yet
[04:42] <OvenWerks> I guess it doen't show till it builds
[04:43] <zequence> OvenWerks: If the upload worked, you should get a confirmation  withing a few minutes
[04:43] <zequence> withing 10 or so
[04:44] <zequence> and the package will appear before it's built
[04:44] <zequence> you can monitor the build progress in launchpad
[04:44] <OvenWerks> https://launchpad.net/~len-ovenwerks/+archive/ppa
[04:44] <OvenWerks> its there built and everything
[04:44] <zequence> great
[04:45] <zequence> feel free to add it here https://launchpad.net/~ubuntustudio-dev/+archive/devel
[04:46] <OvenWerks> Now I can try it against a fresh install
[04:46] <OvenWerks> Ya, when I know it works.
[04:46] <OvenWerks>  Actually I will probably just do a push when its ready
[04:48] <OvenWerks> There are some things I haven't worked out yet
[04:54] <zequence> I'm taking another exam today. security+. I don't understand the American fascination with abbreviations. Seems like half my studies is about learning all about them
[04:54] <zequence> I mean, learning all kinds of abbreviations. but also a little bit about what they stand for
[04:55] <zequence> I don't learn names and terms easily, so I don't really like this kind of education. makes me feel like a parrot
[04:58] <zequence> next exam will be a little more fun though. linux+
[06:23] <OvenWerks> zequence: ya, my wife is taking nursing and they have so many abbreviations... she sounds like she is spelling things out
[06:24]  * OvenWerks is going to bed
[11:03] <zequence> I passes my exam, all though it felt like I had studied the wrong book of abbreviations
[11:07] <astraljava> Hehe, yeah I got that every time. I hardly ever managed to participate the classes, what with living some 300 km away. So I used to just read the slides, and some odd material available in the 'net. It was usually just enough to get 51% or 52% scores.
[11:24] <zequence> astraljava: Have you done any comptia certificate exams? or any other kind of American based certs?
[11:28] <astraljava> zequence: No, I haven't.
[11:29] <zequence> astraljava: Well, if you ever do, you'll know what it feels like to be a parrot
[11:30] <astraljava> Hahah!
[14:35] <madeinkobaia> Hi all : )


 hello, can lubuntu be installed using dual displays / monitors? … I play games in Lubuntu, and it is very satisfying. I have a PC for gaming with 3 monitors. I want to install Lubuntu too, but can Lubuntu be used for dual monitors? (I'm too greedy to use another DE)
 https://manual.lubuntu.me/stable/3/3.2/3.2.10/monitor_settings.htmlyes for how to do thatn see yes
 @lynorian [https://manual.lubuntu.me/stable/3/3.2/3.2.10/monitor_settings.htmlyes for how t …], ow thx its great, i will try it
[14:21] <famubu> Hi. Can I install zenity in lubuntu 20.04 without having to install the bulk of gnome?
[14:25] <kc2bez> You may want to look at kdialog famubu
[14:27] <kc2bez> !info kdialog
[15:06] <pirx_> Hello!
[15:07] <pirx_> How can i add keyboard shortcuts to align windows to the left or to the right in Lubuntu 20.04?
[21:24] <bitblit> not sure if this is lubuntu related but my vm no longer dynamically resizes resolution. i have spice-vdagent installed.
[21:24] <bitblit> host is ubuntu 20.04 with sway, guest is lubuntu 20.04


[22:25] <Claudinux_> hi all, could someone tell me if there are known issue on the request of a new password on http://iso.qa.ubuntu.com
[22:26] <Claudinux_> i don't receive the mail


[00:12] <lool> wee, got an IP
[00:30] <ricmm> \o/
[00:31] <lool> ricmm: sent you a status email; some open questions for you
[00:32] <ricmm> lool: yea, just skimmed through it
[00:32] <lool> ricmm: if we're maintaining this, I might elect the ugly+complex but quick to deliver hacks on top of Ubuntu packages -- to avoid maintaining NM and deps twice
[00:33] <ricmm> I'll reply, keep an eye out
[00:33] <ricmm> lool: go sleep
[00:33] <lool> haha my inbox looks like a jungle now
[00:33] <lool> yeah, time for sleep
[01:30] <h00sier> I'm trying to add a user in snappy. I've already added lines to /var/lib/extrausers/{password,group,gshadow}, I don't know how to make the line for shadow. It's encrypted I guess, any help?
[06:23] <pitti> mvo: guten Morgen!
[06:24] <pitti> mvo: I reviewed the snappy classic dimension spec
[06:26] <mvo> pitti: great, thanks
[06:28] <mvo> pitti: I also have a systemd question again :) so I have this snappy-workaround.service and it needs to be completed before ppp-dns.service runs. in snappy-workarounds.service I used before=ppp-dns.service but thats not strong enough, I also added "wantedby=network-pre.target" to ensure its run earlier and indeed its run earlier but ppp-dns still starts in parallel, whats the best way to express that the unit has to have exited? (or the best way
[06:28] <mvo> to do what I want, namely that the workaround is applied before ppp-dns starts)?
[06:29] <pitti> mvo: before= does just that
[06:29] <pitti> mvo: but it only says that your unit must get *started* before the other one, not *ended*
[06:29] <pitti> mvo: maybe  you are missing a Type=oneshot?
[06:30] <pitti> mvo: for those, the unit only counts as "done" when all Exec= commands exited, not when they started
[06:31] <mvo> pitti: this is what it looks like http://paste.ubuntu.com/12551829/
[06:32] <mvo> pitti: is it the "remainafterexit"?
[06:32] <pitti> mvo: oh, when does ppp-dns.service get started?
[06:32] <mvo> iirc we added it to easily see the logs
[06:32] <pitti> mvo: my guess is that ppp-dns.service gets started in a target much ealier than multi-user.target
[06:33] <mvo> pitti: pps-dns is a old-school init script
[06:33] <pitti> mvo: and thus the snappy-workaround.service isn't even taken into account
[06:33] <pitti> mvo: in rcS?
[06:33] <pitti> oh, I have it
[06:33] <pitti> mvo: ah, rcS
[06:33] <mvo> pitti: indeed it is
[06:34] <pitti> mvo: ack, clear then; hang on
[06:34] <mvo> pitti: thanks!
[06:34] <mvo> pitti: would be nice if systemd would tell me in some way that the before= releation can not be satisfied or something :)
[06:35] <pitti> mvo: old-school init.d> err, is it? I have a /lib/systemd/system/pppd-dns.service which is in multi-user, but that might be new in wily
[06:35] <pitti> mvo: and indeed it being in rcS makes things unnecessarily hard :/
[06:35] <mvo> pitti: uh, I'm sorry, I have that in vivid too on my snappy image
[06:36] <mvo> pitti: but its also in rcS.d it seems, what happens in this case? will the native one always "win"?
[06:36] <pitti> mvo: http://paste.ubuntu.com/12551864/
[06:36] <pitti> mvo: yes, native always wins
[06:36] <pitti> ok, then I don't know -- journal SVP?
[06:37] <pitti> mvo: the above paste would be to start much earlier, in case pppd-dns already ran in rcS (aka sysinit.target)
[06:37] <mvo> pitti: sure, one sec and I can give you the journal and the systemd-analiyze output
[06:37] <pitti> mvo: systemd actually should tell you that, in that case you get a dependency cycle in journal and one service in the cycle doesn't start
[06:38] <pitti> mvo: so, given /lib/systemd/system/pppd-dns.service your wantedby=multi-user.target shoudl be fine
[06:38] <pitti> and the before=
[06:38] <mvo> pitti: http://paste.ubuntu.com/12551875/ is the journal
[06:39] <pitti> mvo: haha!
[06:40] <pitti> mvo: ppp-dns.service
[06:40] <pitti> mvo: spot the typo :)
[06:40]  * mvo drops dead
[06:40] <pitti> mvo: /me tosses mvo another 'd'
[06:40] <mvo> *cough* thanks, I guess I owe you one (or two)
[06:40] <pitti> and try to say "pppd-dns" very fast ten times
[06:40]  * pitti hugs mvo
[06:41] <pitti> no warning about this, as having an After=/Before= to nonexisting units is a common and legitimate use case
[06:41] <pitti> but we should maybe configure --enable-typo-detection
[06:42] <pitti> mvo: now that this is done, another thing: http://cdimage.ubuntu.com/ubuntu-core/vivid/daily-preinstalled/current/ is not actually a "classic" ubuntu tarball, it's snappy
[06:42] <pitti> mvo: fortunately it still has an intact dpkg database, but we need to remove the /usr/local/bin/apt* stuff at lesat
[06:42] <mvo> hmm
[06:42] <pitti> mvo: I was just wondering what these ubuntu core tarballs actually want to be -- a deb based minimal ubuntu, or classic
[06:42] <pitti> err, "or snappy"
[06:44] <mvo> pitti: indeed, I think we should find a real core tarball, the snappy one removes most of /usr/share/doc for example and iirc the man-pages so its not a great fit for the classic env
[06:45] <mvo> pitti: we could simply create another artifact with livecd-rootfs
[06:45] <mvo> pitti: I wonder what lxd is doing to build the ubuntu image? maybe we can use that?
[06:46] <pitti> mvo: I left a note and a TODO in the spec
[06:46] <pitti> mvo: lxc has pre-built images available for download, indeed
[06:46] <pitti> mvo: we don't have "lxc" installed to actually call the templates, but we could of coruse just hardcode the URL
[06:47] <pitti> mvo: but we would then depend on something.linuxcontainers.org, not on *.ubuntu.com infrastructure
[06:47] <pitti> http://images.linuxcontainers.org/images/ubuntu/vivid/amd64/default/
[06:48] <mvo> pitti: yeah, lets discuss in budapest, but my plan-b would be to just create another artifact on cdimage.u.c via livecd-rootfs
[06:48] <pitti> right
[06:48] <pitti> mvo: I'll adjust my prototype to use a hardcoded URL to the lxc tarballs for now
[06:50] <mvo> pitti: thanks!
[06:51] <mvo> elopio: I'm a idiot, the snappy-workaround issue is found and I uploaded a fix, thanks to pitti, will create a new image now
[06:51]  * yashi_ tring to send a fix to lp...
[06:52] <yashi_> https://code.launchpad.net/~yashi/snapcraft/snapcraft
[06:52] <mvo> pitti: thanks for the spec update, I just looked over it, you mostly replied to the comments, right? and the open question? the rest looks ok?
[06:52] <pitti> mvo: "making frustrating typos" != "idiot", happesn to everyone!
[06:52] <pitti> mvo: I also added some new comments, yes
[06:52] <pitti> mvo: open q?
[06:52] <mvo> pitti: indeed, thanks :) I feel a bit silly for not spotting it earlier
[06:53] <mvo> pitti: the open question about were to get the tarball from
[06:53] <pitti> mvo: ah, right
[06:53] <mvo> great, I think that spec is in good shape then
[06:53] <mvo> yashi_: nice!
[06:54] <mvo> yashi_: if you click on "prose for merging" and then propose to merge it into "lp:snapcraft" it will appear on the radar of the snapcraft developers automatically :)
[06:54] <pitti> mvo: meh, need to think about what to do with /etc/resolv.conf
[06:56] <mvo> pitti: oh, indeed :/
[06:58] <yashi_> mvo: done.  Thanks :)
[07:03] <fgimenez> good morning
[07:09] <mvo> hey fgimenez, good morning
[07:09] <fgimenez> hi mvo i'm going to check elopio's concerns. is all set in alpha, right?
[07:10] <mvo> fgimenez: yes, I found the bug why the workarounds ording was not quite correct and fixed it
[07:11] <mvo> fgimenez: the image is building right now in alpha
[07:11] <fgimenez> mvo, great! :) the image is ready for testing?
[07:11] <fgimenez> mvo, ah ok :)
[07:18] <pitti> mvo: btw, what does your workaround do?
[07:21] <dholbach> good morning
[07:22] <pitti> mvo: I mean, it's usually more elegant to create a /lib/systemd/system/pppd-dns.service.d/snappy.conf with an extra ExecStartPre=, or changing/deleting the ExecStart= command, or something
[07:22] <pitti> mvo: then you can restart/stop pppd-dns.service and things still work correctly; you don't need to be aware of re-running the workarounds.service as well, etc.
[07:23] <pitti> hey dholbach, wie gehts?
[07:25] <dholbach> hey pitti - sehr gut - und dir?
[07:25] <pitti> dholbach: prima, danke
[07:30] <mvo> pitti: aha, nice. I will keep that in mind
[07:31] <dholbach> pitti, thanks for looking at the ffe
[07:32] <pitti> dholbach: no worries, that's a trivial one
[07:32] <dholbach> yeah, I could imagine there's going to be another upload before release,  but it should be smaller to be reviewed
[07:32] <dholbach> mvo, asac: upload snapcraft 0.2 to wily
[07:33] <mvo> fgimenez: new image available, I do a quick test now
[07:33] <fgimenez> mvo, thanks on it
[07:35] <mvo> fgimenez: systemd analyize tells me the order is now correct
[07:39] <fgimenez> mvo, trying the update from 178 now. it's still not available on alpha, right?
[07:40] <mvo> fgimenez: not in alpha yet, I can do that now
[07:42] <mvo> fgimenez: there should be a new amd64 alpha now based on r185
[07:44] <fgimenez> mvo, thanks a lot, i'll try it now 178 -> 185 worked fine for ppp \o/ http://paste.ubuntu.com/12552242/
[07:45] <mvo> fgimenez: yay!
[07:45] <fictionedge> Hi everyone
[07:45] <fictionedge> Can anyone tell me what's the best way to submit a few suggestions to the developers team?
[07:47] <dholbach> fictionedge, if it's about snappy, the mailing list should be a good start: http://lists.ubuntu.com/mailman/listinfo/snappy-devel
[07:49] <asac> dholbach: uploaded or you want me to upload :)?
[07:54] <fictionedge> @dholbach it's about the general installation process for future releases
[07:54] <nothal> fictionedge: No such command!
[07:57] <fgimenez> mvo, 11 -> 13 worked fine too http://paste.ubuntu.com/12552292/ :)
[07:59] <fgimenez> mvo, i'll run the tests against 13 now
[07:59] <fictionedge> just joined the list thank you dholbach
[07:59] <mvo> cool
[08:04] <pitti> mvo: http://people.canonical.com/~pitti/tmp/setup-classic.sh updated for a few glitches
[08:04] <pitti> mvo: resolv.conf now works OOTB, I un-snappify the core tarball, and I added a policy-rc.d
[08:04] <pitti> mvo: so apt-get update/install postfix in the chroot now DTRT
[08:10] <mvo> pitti: nice! postfix DTRT means the service is not started but it does get started on the next reboot, right? (just to be sure I'm on the same page)
[08:10] <pitti> mvo: correct
[08:10] <pitti> mvo: or when you systemctl restart classic-container
[08:11] <pitti> mvo: I need to make this a bit more precise -- if you apt-get install in "machinectl login classic", it actually should start
[08:11] <pitti> mvo: but I don't think we want to advertise logging into the container too much
[08:12] <mvo> pitti: yeah, I would love to have a mechanism via policy-rc.d that would notify the host that it needs to do something like"machinectl login classic" to start it
[08:12] <mvo> pitti: but only if that can be made robust :)
[08:12] <mvo> pitti: but maybe its not feasible, not sure
[08:13] <pitti> mvo: that would be in invoke-rc.d
[08:13] <pitti> mvo: yeah, we could do something like that too
[08:13] <pitti> maybe it's even possible to do in policy-rc.d, that would be much nicer
[08:13] <mvo> probably not for now, I guess we should wait for the budapest discussion
[08:13] <pitti> right, before we waste too much time on the details of this
[08:14] <mvo> but it would be nice from a user experience point of view, but then we have the problem what systemctl inside the snappy classic env should show etc
[08:14] <mvo> so there are more questions :)
[08:24] <dholbach> asac, already uploaded
[08:27] <dholbach> pitti, snapcraft is in binNEW because of a new -examples package - could you take a look?
[08:32] <davidcalle> dholbach, I'm having issues with a snap, could you have a look?
[08:32] <dholbach> davidcalle, what's the issue?
[08:34] <davidcalle> dholbach, my "glue" bash script is calling bzr, and bzr has issues running (eg. can't find bzrlib), it's probably a path issue, I'm wondering if I'm doing things wrong in my snapcraft.yaml
[08:34] <davidcalle> dholbach, http://bazaar.launchpad.net/~davidc3/+junk/snapcraft-doc-snap/view/head:/snapcraft.yaml
[08:35] <davidcalle> dholbach, (the snap is pretty straightforward, go webserver + bzr imports snapcraft doc + script to convert it to html)
[08:37] <dholbach> taking a look in a bit
[08:37] <davidcalle> dholbach, thanks :)
[08:37] <pitti> dholbach: hm, shouldn't that be in /usr/share/doc/snapcraft/examples/ ?
[08:40] <dholbach> pitti, hmmm.... http://pastebin.ubuntu.com/12552504/
[08:40] <pitti> dholbach: right, I just checked the deb, hence my question
[08:41] <dholbach> ah ok, sorry
[08:41] <dholbach> my mistake
[08:41] <dholbach> I'll prepare 0.2.1
[08:41] <pitti> err, /usr/share/doc/snapcraft-examples/examples I meant
[08:42] <dholbach> I'm happy with whatever
[08:42] <dholbach> if it needs to be /usr/share/doc/snapcraft-examples/examples that works for me
[08:44] <pitti> dholbach: well, "needs to be" -> that's the standard path to put examples into
[08:44] <pitti> not a biggie, but that's what /usr/share/doc/ is for
[08:44] <dholbach> ok
[08:44] <pitti> dh_installexamples should DTRT
[08:44] <pitti> dholbach: danke!
[08:44] <dholbach> yep
[08:53] <dholbach> davidcalle, I'll get to it later, if that's all right - I have a few things to figure out first
[08:54] <dholbach> or ask m-vo or s-ergiusens
[08:54] <davidcalle> dholbach, no rush! Nothing urgent :)
[08:54] <dholbach> ok, good
[08:57] <JamesTait> Good morning all; happy Friday, and happy Comic Book Day! 😃
[09:49] <dholbach> mvo, pitti: https://code.launchpad.net/~dholbach/snapcraft/0.2.1/+merge/272362
[09:50] <dholbach> brb
[10:06] <mvo> timchen119: could you please try https://people.canonical.com/~mvo/tmp/ubuntu-device-flash-128mb-boot-plus-fw-dir
[10:08] <timchen119> mvo, ok
[10:55]  * Chipaca suddenly finds himself down a performance rabbithole and tries to get out
[10:56]  * ogra_ sends a fox to speed this up
[10:56] <clobrano> LOL
[10:59] <Chipaca> on the one hand, I just cut a test from 0m7.208s to 0m0.072s
[10:59] <Chipaca> so I basically just made snappy.VersionCompare 100× faster
[11:00] <Chipaca> on the *other* hand, not that many people have 10k versions of a package installed, that it would make a difference
[11:02] <Chipaca> ah, no, that's with 1k versions, not 10k. Much more real-world a test case.
[11:13] <mvo> Chipaca: woah!
[11:13] <mvo> Chipaca: \o/
[11:15] <Chipaca> mvo: and I can knock down the 100k testcase from 22 seconds to 15 seconds if i change snappy.chOrder to be a table
[11:15] <Chipaca> mvo: i think i might draw the line above this one though :)
[11:15] <mvo> Chipaca: I look forward to that branch
[11:17] <Chipaca> mvo: it's fun, but i'm glad i got to a table quickly (because tables are ugly) :)
[11:17] <Chipaca> otherwise i might've been trapped all day
[11:19]  * mvo nods
[11:20] <Chipaca> otoh if we were using go:generate the table is totally generate'able :)
[11:25] <Chipaca> mvo: https://code.launchpad.net/~chipaca/snappy/sort-perf/+merge/272372
[11:31] <Chipaca> clobrano: whenever you check whether a file exists and if it does not you then create it you are creating a race
[11:31] <Chipaca> clobrano: somebody can create the file (with content) between you checking and you creating
[11:32] <clobrano> Chipaca: ooh, right!
[11:32] <clobrano> Chipaca: thank you :)
[11:32] <Chipaca> clobrano: e.g. the write it out in file.tmp, then move it to file just after you checked and before you created
[11:32] <Chipaca> clobrano: boom, you just stomped on their file
[11:32] <clobrano> Chipaca: sure
[11:33] <Chipaca> clobrano: note that with snappy right now that's not as possible because it has a global lock, but the snappy rest api does not
[11:35] <clobrano> Chipaca: I understand, but (apart from snappy) is always something to think about :)
[11:35] <Chipaca> yep
[11:38] <Chipaca> clobrano: then there's the symlink considerations, and using openat instead of open, but i think we can leave those for now
[11:38] <Chipaca> probably need to comb the code to grab those at some point though
[11:39] <Chipaca> ah
[11:39] <Chipaca> clobrano: could you add O_NOFOLLOW to the O_CREAT etc ?
[11:39] <Chipaca> clobrano: that's syscall.O_NOFOLLOW
[11:39] <Chipaca> not portable :-/
[11:59] <clobrano> Chipaca: sure, but O_NOFOLLOW is for?
[12:00] <Chipaca> clobrano: i'll answer that in a bit
[12:00] <Chipaca> clobrano: meanwhile, let me ask
[12:00] <Chipaca> clobrano: how far away are you from me?
[12:00]  * Chipaca hides
[12:00] <Chipaca> clobrano: :)
[12:00] <Chipaca> clobrano: i thought of a better way of doing this thing
[12:01] <clobrano> Chipaca: far away? Do you mean geographically? :D
[12:01] <Chipaca> yeah, in case you wanted to throw something at me
[12:01] <Chipaca> clobrano: it's that i just realised there's no reason to create the file at all at that point
[12:02] <Chipaca> clobrano: unless i'm missing something?
[12:02] <clobrano> Chipaca: I'd like, but I'm in Italy
[12:02] <Chipaca> clobrano: just, try to read it, if you fail, move on
[12:02] <Chipaca> clobrano: so you start with “rules, err := ioutil.ReadFile(udevRulesFile)”
[12:03] <Chipaca> clobrano: and check err != nil && !os.IsNotExist(err)
[12:03] <Chipaca> clobrano: you'll have the content of the file, or an empty slice, in rules
[12:03] <Chipaca> clobrano: and that's all you need
[12:04] <clobrano> Chipaca: first, sorry I didn't get at all the joke before ;D. You're talking about addUdevRule right? What if it's the first rule? The file does not exist at all
[12:05] <Chipaca> yes, talking about addUdevRule
[12:05] <Chipaca> clobrano: if it's the first rule, ie if the file does not exist
[12:05] <Chipaca> clobrano: you're creating an empty file
[12:05] <Chipaca> clobrano: and then reading that with ioutil.ReadFile
[12:05] <Chipaca> clobrano: right?
[12:06] <clobrano> Chipaca: uhmm, I think you're right
[12:06] <Chipaca> clobrano: so ioutil.ReadFile will return an empty slice of bytes, because the file is empty
[12:06] <Chipaca> clobrano: but ioutil.ReadFile will return a nil slice when it can't open the file
[12:07] <Chipaca> clobrano: and appending to a nil slice, and appending to an empty slice, results in the same thing
[12:07] <clobrano> Chipaca: ReadFile will return no errors?
[12:07] <Chipaca> it will
[12:07] <Chipaca> it will return a non-nil error
[12:07] <Chipaca> but os.IsNotExist(err) will return true
[12:08] <Chipaca> hence, you'd do: rules, err := ioutil.ReadFile(...)
[12:08] <Chipaca> if err != nil && !os.IsNotExist(err) { return err }
[12:09] <Chipaca> capisci?
[12:09]  * Chipaca couldn't resist
[12:09] <clobrano> Chipaca: ahahahaha
[12:10] <clobrano> Chipaca: sorry, just a sec
[12:12] <clobrano> Chipaca: sure I think it's fine. AtomicWrite will create the file if it doesn't exist, right?
[12:12] <Chipaca> yes
[12:12] <clobrano> then ok, I couldn't see any drawback
[12:23] <clobrano> Chipaca: done it, test it, ready to push it (I just added a comment to the code, since that could be not immediate to understand)
[12:23] <clobrano> :)
[12:23] <Chipaca> L(
[12:23] <Chipaca> :) i mean
[12:23] <Chipaca> L( is an off-by-one :)
[12:24] <Chipaca> clobrano: did you follow up the .precommit thing?
[12:25] <clobrano> Chipaca: yes, I did. I still have to check something with Bazaar-explorer, since it fails to find golint, but bzr by command-line it's fine
[12:26] <Chipaca> clobrano: you probably need to manipulate PATH from your bzr plugin so it finds golint
[12:26] <Chipaca> clobrano: or install golint into ~/bin :)
[12:26] <Chipaca> (assuming ~/bin is in your PATH, which it is by default if it exists)
[12:26] <clobrano> Chipaca: yes, it should be something like that
[12:27] <clobrano> I set both GOPATH and GOBIN, but explorer seems to ignore it
[12:27] <clobrano> and added GOBIN to PATH
[12:27] <Chipaca> clobrano: where did you do those additions, and where do you start explorer from?
[12:28] <clobrano> Chipaca: that's the point. The definitions are in my bashrc, and I couldn't find the name of the explorer bin to run it from shell
[12:29] <Chipaca> clobrano: dpkg -L bzr-explorer | grep /bin/
[12:29] <clobrano> Chipaca: nada
[12:30] <Chipaca> clobrano: dpkg -L bzr-explorer | grep .desktop | xargs grep Exec=
[12:30] <clobrano> but I found the .desktop with your command! Thanks
[12:30] <Chipaca> heh :) yep
[12:30] <clobrano> yep ;)
[12:32] <clobrano> Chipaca: I think I could open another bug :p. Bzr does not list "explorer" as basic command in its help :D
[12:32]  * Chipaca gives up and installs bzr-explorer
[12:32] <Chipaca> clobrano: sure it does, it's right there
[12:33] <Chipaca> ah, as *basic* commands
[12:33] <Chipaca> well, it's hardly basic :)
[12:33] <clobrano> Chipaca: well, for a basic user, a GUI is better than a shell ;)
[12:34] <clobrano> Chipaca: but ok, the command its in the full list
[12:37] <clobrano> Chipaca: done. Let me know if it's fine now
[12:38] <Chipaca> augh!
[12:39] <clobrano> :D
[12:39] <Chipaca> clobrano: commented inline
[13:45] <ogra_> Chipaca, hmpf ... webdm doesnt start on my last Pi2 image
[13:45] <Chipaca> ogra_: i can't even get it to build here
[13:45] <ogra_> webdm ?
[13:45] <Chipaca> yes
[13:45] <Chipaca> i am not building raspberry pies
[13:45] <Chipaca> although i do have raspberry jam
[13:45] <ogra_> http://paste.ubuntu.com/12554435/
[13:46] <ogra_> thats during forst boot
[13:46] <ogra_> *first
[13:46] <Chipaca> ogra_: and did you?
[13:46] <ogra_> webdm_snappyd_0.9.service - Snappy WebDM
[13:46] <ogra_>    Loaded: loaded (/etc/systemd/system/webdm_snappyd_0.9.service; enabled; vendor preset: enabled)
[13:46] <ogra_>    Active: failed (Result: start-limit) since Fri 2015-09-25 13:43:14 UTC; 1min 13s ago
[13:46] <ogra_>   Process: 1072 ExecStart=/usr/bin/ubuntu-core-launcher webdm webdm_snappyd_0.9 /apps/webdm/0.9/snappyd (code=exited, status=1/FAILURE)
[13:46] <ogra_>  Main PID: 1072 (code=exited, status=1/FAILURE)
[13:46] <ogra_> not actually informative
[13:47] <ogra_> syslog has:
[13:47] <ogra_> Sep 25 13:44:57 localhost ubuntu-core-launcher[1230]: Snappy: 2015/09/25 13:44:57 handlers.go:52: Initializing HTTP handlers...
[13:47] <ogra_> Sep 25 13:44:57 localhost ubuntu-core-launcher[1230]: Snappy: 2015/09/25 13:44:57 handlers.go:59: decoding problem
[13:47] <ogra_> thats the most recent 15.04 image btw
[13:48] <ogra_> (which i thought we plan to release today :/ )
[13:48]  * ogra_ wonders why nobody did hit that during testing
[13:49] <ogra_> fgimenez, do you have webdm running on your armhf and amd64 tests for the last 15.04 edge or alpha image ?
[13:50] <fgimenez> ogra_ nope, i'll try to reproduce
[13:50] <ogra_> seems my amd64 auto-upgraded to 186 and there i see webdm run
[13:51] <ogra_> i dont have a BBB around to check if it is perhaps arm specific
[13:57] <fgimenez> ogra_ then flash alpha 11 for bbb, install webdm, update should be enough?
[13:57] <ogra_> fgimenez, yes
[13:57] <ogra_> well, i flashed edge
[13:58] <fgimenez> ogra_ ok, let me try
[13:58] <ogra_> and no upgrade ... i just used u-d-f on the last edge image
[14:08] <longsleep> ogra_: mhm webdm works fine in my 15.04/stable
[14:08]  * longsleep did not test edge yet
[14:08] <ogra_> weird
[14:09] <ogra_> i did build that image with --device raspi2_armhf ... i wonder if that forces an amd64 webdm to be installed or some such
[14:09] <longsleep> well id installed webdm later on the device
[14:09] <longsleep> -d
[14:09] <ogra_> ah, dd is done, lets see if it behaves differently without that option
[14:10] <ogra_> screen -r
[14:10] <ogra_> oops
[14:10] <ogra_> EFOCUS :P
[14:12] <ogra_> hmm, not caused by the --device option, still failing here
[14:13]  * ogra_ removes and reinstalls webdm
[14:14] <ogra_> nope, same issue
[14:38] <longsleep> ogra_: let me try mine
[14:38] <ogra_> trying with alpha 12 here now ...
[14:38]  * ogra_ waits for dd
[14:42] <longsleep> ogra_: webdm runs fine on my odroid
[14:42] <ogra_> sigh
[14:42] <longsleep> ubuntu-core   2015-09-17 5
[14:42] <longsleep> webdm         2015-09-24 0.9
[14:42] <ogra_> ah, but thats stable
[14:43] <longsleep> yeah
[14:43] <ogra_> havent gotten to that yet :)
[14:43] <ogra_> sigh, so alpha doesnt work either
[14:43] <Chipaca> clobrano: you need to set a commit message on the merge request
[14:44]  * longsleep builds an edge image now
[14:44]  * ogra_ builds stable
[14:49] <longsleep> damn .. no space left on device  - foo!
[14:50] <ogra_> bah
[14:50] <longsleep> too many kernel build trees :/
[14:50] <ogra_> heh
[14:51] <ogra_> sigh
[14:51] <ogra_> stable doesnt uncompress the kernel for me :/
[14:51]  * ogra_ re-tries
[14:53] <jbdatko> Anyone know if the snappy image for BBB needs the SD card to run or can it run completely from the eMMC? The instructions talk about replacing the bootloader on the emmc...
[14:57] <clobrano> Chipaca: what should the content be?
[14:57] <Chipaca> clobrano: a short description of the changes in the branch?
[14:57] <Chipaca> oh!
[14:57] <Chipaca> and one more thing
[14:58] <Chipaca> clobrano: make a nochange commit with --fixes lp:1497299
[14:58] <Chipaca> clobrano: e.g. bzr ci -m 'fixes lp:1497299' --fixes lp:1497299 --unchanged
[14:58] <Chipaca> clobrano: and push that also
[14:59] <clobrano> Chipaca: ook
[15:04] <zyga> morphis: hey, I'm back now
[15:04] <zyga> morphis: does the security template work for you?
[15:04] <zyga> morphis: I merged the documentation changes and I'm about to rebuild and see if the snap works with the template for me
[15:05] <morphis> zyga: I just applied the last changes I got from jdstrand
[15:05] <morphis> can report in some minutes
[15:05] <zyga> morphis: ok, thanks
[15:06] <morphis> zyga: but pushed the change so you can test too
[15:06]  * zyga builds
[15:06] <zyga> make clean; make
[15:06] <zyga> I love that
[15:07] <longsleep> ogra_: webdm works fine here with edge
[15:07] <longsleep> ubuntu-core 2015-09-25 170     ubuntu
[15:07] <longsleep> (installed via ssh though, not together with u-d-f)
[15:09] <clobrano> Chipaca: done
[15:32] <Chipaca> https://code.launchpad.net/~chipaca/snappy/dddddirs/+merge/272430 for great justice^Wduhr duhr
[15:34] <ogra_> mvo, so any idea about the oem snap ?
[15:35]  * ogra_ quickly gets some food
[15:37] <Chipaca> ogra_: so, you get ErrDecode from oem.Oem() in two cases: one is a bad package.yaml
[15:37] <Chipaca> ogra_: the other is an unreadable package.yaml
[15:37] <Chipaca> 	yamlPath := filepath.Join("/oem", oem[0].Name(), oem[0].Version(), "meta", "package.yaml")
[15:38] <Chipaca> which is rather circuitous, but there you go
[15:38] <Chipaca> ogra_: so
[15:38] <ogra_> http://paste.ubuntu.com/12555387/
[15:38] <Chipaca> ogra_:  if the version in the yaml does not match the directory
[15:38] <Chipaca> ogra_: would be one failure mode
[15:38] <ogra_> how would thw dir match anything ?
[15:38] <Chipaca> ogra_: that is
[15:39] <ogra_> (RaspberryPi2)ubuntu@localhost:~$ ls /oem/pi2/
[15:39] <ogra_> IBbBKVKXNDAQ  current
[15:39] <Chipaca> eep
[15:39] <Chipaca> why is it sideloaded?
[15:39] <ogra_> right, cant match :)
[15:39] <ogra_> because it is built using u-d-f --developer-mode
[15:39] <ogra_> with the --oem option
[15:40] <Chipaca> so
[15:40] <ogra_> thats how we port to new devices
[15:40] <Chipaca> something is out of sync
[15:40] <Chipaca> umm
[15:40] <Chipaca> ogra_: update snappy in webdm
[15:41] <Chipaca> ogra_: because oem[0].Version() should do the right thing here, and it isn't :)
[15:41] <ogra_> ??
[15:41] <ogra_> snappy in webdm ?
[15:41] <Chipaca> ogra_: you didn't rebuild webdm?
[15:42] <ogra_> why would i
[15:42] <Chipaca> ogra_: because it embeds snappy
[15:42] <Chipaca> ogra_: new snappy => new webdm
[15:42] <Chipaca> more or less
[15:42] <ogra_> i only use u-d-f like i did the last few releases for rpi
[15:42] <Chipaca> u-d-f *also* embeds snappy :)
[15:42] <ogra_> and bumped the version in the pi2 snap
[15:43] <Chipaca> but that's not here nor there
[15:43] <ogra_> and i'm using the lastes u-d-f i think
[15:43] <Chipaca> so
[15:43] <Chipaca> ogra_: webdm needs to be built agains the same version of snappy as the system snappy
[15:43] <Chipaca> ogra_: otherwise breakage happens
[15:43] <Chipaca> (you effectively have two different snappy implementations on the system)
[15:43] <ogra_> right, so we will see breakage on other systems too then
[15:43] <Chipaca> yes
[15:43] <Chipaca> or rather
[15:43] <Chipaca> no
[15:44] <ogra_> i mean, i'm not using anything special
[15:44] <Chipaca> because it doesn't understand the versioning thing
[15:44] <Chipaca> :)
[15:44] <Chipaca> so, webdm needs attention
[15:44] <ogra_> webdm hanst been rebuilt in months
[15:44] <Chipaca> yeh
[15:44] <Chipaca> this is not good :)
[15:44] <ogra_> right
[15:45] <Chipaca> ogra_: do you have vivid?
[15:45] <ogra_> trusty
[15:45]  * ogra_ isnt sure, probably vivid on the lappie
[15:45] <Chipaca> ricmm: where did you try to build webdm (and failed)?
[15:45] <Chipaca> i think it needs a vivid, but i might be wrong
[15:46] <Chipaca> and it might be broken beyond that :-/
[15:46] <Chipaca> ogra_: one of the reasons the rest api is important is to decouple webdm
[15:46] <ogra_> ah
[15:47]  * ogra_ is surprised to be the first one to actually hit an issue, these pieces must be massivel out of sync
[15:47] <ogra_> and that since a while
[15:49] <ogra_> i uess i could work around by pushing the 0.16 pi2 untested to the store then .... then it wouldnt be sideloaded
[15:49] <Chipaca> ogra_: i thought you'd tested it with everything except webdm?
[15:49] <ogra_> there is just something inside me screaming "dont upload untested, idiot !!!"
[15:50] <ogra_> well, yeah
[15:50] <Chipaca> ogra_: the broken bit here is webdm
[15:52] <Chipaca> clobrano: congratulations, btw :)
[16:07] <longsleep> ogra_: my version in /oem is just 0.3 - why is yours a hash version?
[16:08] <longsleep> ls /oem/odroidc/
[16:08] <longsleep> 0.3  current
[16:08] <longsleep> i am using vivid to build the images with ubuntu-device-flash 0.20snappy7-0ubuntu1.2
[16:09] <fgimenez> nice weekend everyone o/
[16:10] <ogra_> longsleep, all sideloaded snaps get a hash version nowadays
[16:10] <ogra_> so you are lucky because the snappy on the machine you called u-d-f on is old
[16:11] <longsleep> ogra_: um, i think it is the latest from the ppa
[16:15] <longsleep> aha - i am using snappy-dev-beta ppa - snappy-dev has newer :/
[16:18] <longsleep> ogra_: switched to snappy-dev/tools and now i have 0.31 - thanks for the hint!
[16:19] <ogra_> our PPAs are a mess :/
[16:34] <longsleep> ogra_: so the theory is that if i now create a new image with the newer u-d-f then webdm stops working for me as well?
[16:36] <ogra_> right
[16:36] <ogra_> well, if you use the --oem switch pointing to a local snap
[16:36] <ogra_> only sideloaded snaps get that hash version
[16:48] <longsleep> ogra_: yes thats what i am doing with the odroid oem snap, verifying now
[16:49] <ogra_> \o/
[16:49]  * ogra_ humps Chipaca's leg
[16:49] <ogra_> WOOF !
[16:49] <ogra_> i has workin webdm !!
[16:49]  * Chipaca has a headache
[16:50] <ogra_> so pushin the snap to the store and using that makes everything work fine
[16:50] <ogra_> wow ... what a waste of my afternoon :/
[16:51] <longsleep> ogra_: so webdm currently breaks for any sideloaded snaps ?
[16:51] <ogra_> oem snaps, yes
[16:51] <longsleep> ah only oem ok
[16:51] <longsleep> good that i used an old u-d-f to create my image then :)
[16:51] <ogra_> :)
[16:52] <Chipaca> no, it'll break for any snap
[16:52] <Chipaca> sideloaded
[16:52] <ogra_> oh
[16:52] <ogra_> ok
[16:52] <Chipaca> the services will be confused
[16:52] <ogra_> well, it will still start at least if the oem one isnt sideloaded
[16:52] <Chipaca> right, so i should qualify that
[16:52] <Chipaca> snappy and webdm will have different opinions of where things should go
[16:52] <longsleep> ah, well that image i built with new u-d-f does not even boot :/ seems like i just got some work todo :(
[16:53] <Chipaca> and will break if you mix and match
[16:53] <ogra_> yeah
[16:53] <Chipaca> but if you use webdm, it'll mostly work
[16:53] <Chipaca> except for the bugs due to not having random versions for sideloaded apps
[16:53] <Chipaca> also none of the fixes in snappy-the-binary will be used by webdm
[16:54] <Chipaca> some might say this is bad :)
[20:20]  * ogra_ curses
[20:20] <ogra_> this rpi image starts getting on my nerves
[20:28] <ricmm> ogra_: whats the matter with it
[20:29] <ogra_> well, i tried to build an image from the s-i srver bits and ended up with a generic kernel ...
[20:29] <ogra_> it funnily booted, i only noticed the wrong kernel after 30min testing :(
[20:29] <ricmm> lol
[20:29] <ricmm> should just merge into that generic then
[20:30] <ricmm> if it actually booted...
[20:31] <ogra_> we tried that but rickspencer3 would be really unhappy ... we needed to add a plethora of patches to make all the bits work he wants
[20:31] <rickspencer3> ruroh
[20:31] <rickspencer3> no pwm? no i2c, no spi?
[20:31]  * ogra_ doesnt really get how he ended up with the worng device tarball now :(
[20:32] <rickspencer3> what would you even do with that?
[20:32] <ogra_> run owncloud or kodi :)
[20:33] <rickspencer3> heh
[20:33] <ogra_> ogra@nusakan:~$ grep raspi2 /srv/system-image.ubuntu.com/etc/config|tail -1
[20:33] <ogra_> file_device,raspi2_armhf = http;http://people.canonical.com/~platform/snappy/raspberrypi2/device-pi2.tar.xz;name=device,monitor=http://people.canonical.com/~platform/snappy/raspberrypi2/builddid
[20:33]  * ogra_ slaps forehead ...
[20:33] <rickspencer3> poor ogra
[20:33] <ogra_> indeed the s-i server points to an unversioned tarball
[20:34] <ogra_> (i uploaded device-pi2-0.16.tar.xz)


[12:28] <\9> this 'signam' guy has been spamming #ubuntu with his shady website for days now
[12:29] <\9> it's gotten annoying to the point I took the time to comb through logs and compile a list of instances where he has spammed the channel https://tsp.kapsi.fi/temp/f991e46b146bac1c7479d0db63e83701.txt
[12:29] <\9> (timezone is gmt+3)
[12:30] <Myrtti> yup, I'm going to have a look properly today
[12:30] <Myrtti> thanks for reminding
[12:31] <\9> thanks for taking the time to deal with this
[12:38] <Myrtti> Imma carpet bomb that
[12:40] <Unit193> Thanks, it's pretty annoying elsewhere too.
[12:40] <Myrtti> I've already told them once to stop it
[12:41] <Myrtti> since the previous kline didn't seem to wake them up to smell the winds of change, let's see if more acute smack on the nose would do the job
[12:42] <Myrtti> (and let's see if I did it right)
[12:42] <Myrtti> hilight me if it looks like it didn't work
[12:42] <Unit193> Will do.
[22:01] <yofel> the allah guy was back in #kubuntu (as Guest_84843 (779de346@gateway/web/cgi-irc/kiwiirc.com/ip.<IP_ADDRESS>)), removed for now
[22:01] <k1l_> i just kicked him out of the -touch channel
[22:02] <ikonia> how tedious
[22:06] <k1l_> hi jimarvan
[22:06] <jimarvan> hello
[22:06] <k1l_> how can we help you?
[22:07] <jimarvan> just a quick question, if someone is harassing one of the ubuntu channels
[22:07] <jimarvan> I come in here and report, is that right?
[22:07] <k1l_> yeah
[22:07] <jimarvan> ok
[22:07] <jimarvan> thank you m8
[22:07] <jimarvan> :)


[01:49] <bandali> hey tsimonq2 sorry for the slow reply.  re bug 2043306, is there anything you'd wanted me to do, besides remembering to ask Seb to switch the translations config for the package on LP now that we've dropped 'X-Ubuntu-Use-Langpack: yes' for it?
[01:49] -ubottu:#ubuntu-devel- Bug 2043306 in tepl (Ubuntu) "Sync tepl 6.8.0-2 (universe) from Debian unstable (main)" [Undecided, Fix Released] https://launchpad.net/bugs/2043306
[03:36] <teward> kanashiro: [ot] you still willing to keysign my key and me sign yours?  Video call available if needed during the day tomorrow if so.  (Can always use more signatories on my keys!)
[03:36] <teward> Robie got me my minimum required key sigs to get my stuff fixed in Debian (key replacement in keyring), but always happy to get more signatories
[03:37] <teward> *disappears to the abyss for now*
[04:58] <kanashiro> teward yep, I am up for that :)
[09:20] <nteodosio> orndorffgrant, for your information https://canonical-ubuntu-pro-client.readthedocs-hosted.com/en/latest/references/api.html doesn't resolve, must drop ".html".
[09:22] <nteodosio> And that's what US078 links to.
[09:26] <bluca> hi, any patch pilot around?
[11:33] <ginggs> bluca: i believe the next scheduled flight is in about 4.5 hours :)
[11:36] <bluca> thanks!
[12:18] <ahasenack> starting my sru shift
[14:12] <ogayot> tsimonq2: thanks for sponsoring 🐱:)
[15:26] <nteodosio> Thanks tsimonq2 for https://lists.ubuntu.com/archives/ubuntu-devel/2023-November/042843.html!
[15:38] <adrien> all this finally forced me to investigate an issue I had with dput-ng: it probably doesn't appreciate my passphrase-protected SSH keys and their decryption method through a custom ${SSH_ASKPASS}
[16:04] <tsimonq2> ogayot: Of course! Happy to help :)
[16:05] <tsimonq2> nteodosio: Ditto, if you're reading logs. ;)
[16:06] <tsimonq2> bandali: Nothing directly actionable on your end. That being said, you are the Debian uploader (who also has upload rights in Ubuntu), so it's more of a "hey, just wanted to make sure you were aware of it" in case there *needs* to be some sort of Ubuntu delta. Thanks :)
[16:08] <tsimonq2> bdmurray, paride, qa-help: Are there any plans for some kind of build scoring on autopkgtest.u.c? For example, it would be nice to prioritize manual user requests over the usual Britney churn (but individual policy bits can be discussed). If there isn't anything you all are aware of, I'll file a bug.
[16:14] <paride> tsimonq2, we thought of that at some point, but that's not going to happen in the short term.
[16:17] <tsimonq2> paride: Makes sense :)
[16:18] <tsimonq2> paride: Is there a technical limitation to do that? I mean, there's already some interesting code around "reading" (really popping from) the RabbitMQ queue, I would imagine something like this would be inserted at that point.
[16:18] <tsimonq2> paride: Either way, this is just a casual ask, I'll happily file a wishlist bug report that can collect some dust until it's ready. ;)
[16:23] <tsimonq2> @pilot in
[16:24] <tsimonq2> I'll take bug 2043625 to start, let's see how far that gets me. As it has been recently, limited time, but I like to do, meh, one or two a day. :)
[16:24] -ubottu:#ubuntu-devel- Bug 2043625 in libsolv (Ubuntu Mantic) "libsolv: lack of zstd support makes it impossible to create SUSE Tumbleweed/Fedora Rawhide chroots with zypper/dnf" [Undecided, In Progress] https://launchpad.net/bugs/2043625
[16:27] <bluca> thanks tsimonq2, I am around if you need more info - I have opened that one
[16:39] <tsimonq2> bluca: Nice! I just responded to the bug report. Just looking for a little more verbosity on the regression potential. Let me know how I can help :)
[16:39] <tsimonq2> bluca: (I didn't consider this a blocker for sponsorship, though, so you're all set.)
[16:44]  * tsimonq2 looks at mitchdz's bug 2040370 next
[16:44] -ubottu:#ubuntu-devel- Bug 2040370 in checksecurity (Ubuntu) "Merge checksecurity from Debian unstable for noble" [Undecided, Confirmed] https://launchpad.net/bugs/2040370
[16:44] <bluca> ok will try to add some more details, thanks
[16:45] <mitchdz> thanks tsimonq2!
[16:47] <mitchdz> also adding a quick comment to 2040370
[16:50] <mitchdz> tsimonq2: I enjoy the ascii art :)
[16:50] <tsimonq2> mitchdz: No worries! I added one very small diff comment, it's just a weird element with grab-merge that you probably wouldn't know unless someone told you.
[16:50] <tsimonq2> mitchdz: It looks better on the email version ;D
[16:51] <mitchdz> ah that's fair. I did notice the extra newline in the diff but figured it might be intended. I'll remove those in the future when I see them!
[16:52] <tsimonq2> Thanks for your help! :)
[16:56] <tsimonq2> Looks like I'm getting pulled away; I idle if anyone needs anything. If someone is doing patch piloting today, I'd recommend bug 2008594 as a good starter package. Thanks!
[16:56] -ubottu:#ubuntu-devel- Bug 2008594 in getmail6 (Ubuntu) "[SRU] getmail_fetch crash, bugfix available upstream" [Undecided, New] https://launchpad.net/bugs/2008594
[16:56] <tsimonq2> @pilot out
[17:00] <paride> tsimonq2, well everything is doable, but we're working at making what we have more stable at the moment
[17:00] <tsimonq2> paride: Perfect, thanks :)
[17:03] <bluca> tsimonq2: added more details and a test for the previous functionality to 2040370
[17:04] <tsimonq2> bluca: Thank you! :)
[17:07] <bluca> anything else I can do before it can be uploaded?
[17:07] <bluca> we can also enable proposed-updates in the CI that uses jammy once it's there, to further test it
[17:08] <tsimonq2> Well, it has been uploaded, it's in the queue right now. :)
[17:09] <bluca> ah excellent, thank you
[17:09] <tsimonq2> Of course!
[17:10] <tsimonq2> bluca: One more specific element; the testing I'm seeing is great, but I believe they'll ask you to test the packages in -proposed once they're accepted/built/published.
[17:10] <bluca> yeah I can enable -proposed in the CI as mentioned, so it gets real-world testing
[17:10] <bluca> and we get the CI working again - win/win
[17:10] <tsimonq2> Perfect :D
[18:43] <bandali> tsimonq2, ah, ack; noted, thanks :-)
[19:12] <sergiodj> @pilot in
[21:32] <sergiodj> hm, shouldn't we remove the ~ubuntu-sponsors subscription to bugs whose packages have been uploaded?
[21:33] <sergiodj> in my understanding, if there's any problem with the upload (be it an SRU or not) the reporter will come back and nag us again, but maybe I'm assuming too much
[21:36] <ahasenack> I would think the report would skip fix committed/released bugs
[21:36] <sergiodj> http://reports.qa.ubuntu.com/reports/sponsoring/general -- it doesn't
[21:36] <sergiodj> not the Fix Committed
[21:36] <tsimonq2> I make the distinction between "packaging" approvals and general, wider-reaching Release Team or SRU Team approvals. The packaging could be good, and the SRU Team could reject it for another reason. I'd also consider it the responsibility of the sponsor, ultimately, to make sure the SRU template is ready.
[21:37] <tsimonq2> If we're talking about subscribing sponsors specifically, I usually unsubscribe them as soon as I confirm it's in the queue.
[21:37] <tsimonq2> If they need to iterate on it, they usually re-subscribe sponsors. That's just my two cents, there's exceptional circumstances and YMMV.
[21:37] <sergiodj> right, it is the sponsor's responsibility to make sure the SRU text is OK. my question is about what should happen _after_ you've uploaded the package
[21:38] <sergiodj> I've been unsubscribing ubuntu-sponsors when I do it
[21:38] <tsimonq2> But yeah, generally, once it hits the queue, I unsubscribe ubuntu-sponsors too.
[21:38] <sergiodj> yeah, that's my understanding as well. thanks tsimonq2
[21:39] <tsimonq2> 🦆🦆😁
[21:39] <mwhudson> @pilot in
[21:40] <sergiodj> I'm glad to share the pilot seat with mwhudson
[21:40] <sergiodj> this airplane is big enough
[21:41] <mwhudson> heh haven't looked at the queue yet!
[21:41] <mwhudson> ok there appears to be a few things :-)
[21:42] <sergiodj> I have one more hour to go; will let you know when I choose my next item so that we don't conflict :)
[21:42] <mwhudson> sergiodj: do you have anything on your radar?
[21:42] <sergiodj> mwhudson: I'm finishing dealing with https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/2038834 , not sure what I'll pick next yet
[21:42] -ubottu:#ubuntu-devel- Launchpad bug 2038834 in mesa (Ubuntu Mantic) "GPU acceleration via VirGL is broken in qemu" [Undecided, New]
[21:43] <mwhudson> ok
[21:43] <mwhudson> uh red needs-packaging items for optee stuff, not at all scary
[22:39] <sergiodj> @pilot out