[15:06] <thebwt> Good morning Texas
[15:07]  * thebwt thinks he'll start just chatting the channel randomly seeing if we can shake any sort of conversation out of us.


[17:05]  * mpt closes one Launchpad bug report before reporting another, thereby keeping czajkowski happy
[17:12] <czajkowski> mpt: the only thing going to make me happy today is a very large JD and maybe I'll have some coke
[17:12] <czajkowski> either that mpt or you owe me cake :)
[17:12] <mpt> czajkowski, I can't give you cake if you aren't here
[17:13] <czajkowski> mpt: I was there and there was still no cake
[17:13] <czajkowski> cake is a lie :(
[17:13] <mpt> was?
[17:13]  * mpt wonders if JD and Coke mix
[17:14] <czajkowski> mpt: do you lke the new G+ themee
[17:14] <mpt> czajkowski, I haven't seen it
[17:14] <czajkowski> :o
[18:15] <mpt> Don't look at me like that, czajkowski, I don't use Google Plus
[22:50] <jelmer> hmm, has the inline replying to bugzilla bugs been there for a while or is that new?
[22:50] <jelmer> it looks pretty nifty
[23:05] <cjwatson> jelmer: a while
[23:05] <cjwatson> if you mean the way it's imported
[23:06] <jelmer> also the fact that it lets you reply to the upstream bug directly from launchpad
[23:07] <cjwatson> ah, that I'm not sure about, though doesn't sound like the sort of thing that'd have been done recently
[23:45] <wgrant> jelmer, cjwatson: That's been there for a few years
[23:45] <jelmer> oh, hmm. I guess I just never came across it :)
[23:47] <wgrant> Early 2010 :)


[07:40] (Mithrandir/#ubuntu-mobile) hmm, I wonder if we can drop the osso-gwconnect dependency, as bluez itself provides that functionality now.
[07:41] (Mithrandir/#ubuntu-mobile) it'd require some source code changes, but should be relativetly easy.
[07:49] (tko/#ubuntu-mobile) Mithrandir: can you ask on the mailing list? I can then forward it to the gwconnect maintainer
[07:51] (Mithrandir/#ubuntu-mobile) yes, I was planning to.
[07:51] (tko/#ubuntu-mobile) there was some connectivity stuff that was moving towards bluez, but I can't recall what exactly it was
[07:51] (Mithrandir/#ubuntu-mobile) he suggested it in a comment to a blog post of James Henstridge about half a year ago, so I wouldn't think he'd be opposed to it
[07:51] (Mithrandir/#ubuntu-mobile) http://blogs.gnome.org/view/jamesh/2006/10/5/0
[08:04] (Mithrandir/#ubuntu-mobile) there, sent.  I Cc-ed Johan Hedberg.
[08:08] (tko/#ubuntu-mobile) ah, cool, saved me the trouble :)
[08:08] (tko/#ubuntu-mobile) ok, time to go to the office :-/
[08:08] (Mithrandir/#ubuntu-mobile) given he's upstream of the code and I reference his comment, I only found it polite to do so.
[08:09] (Mithrandir/#ubuntu-mobile) hmm, hildon-fm seems to need a bit of love in order to compile here.
[08:09] (tko/#ubuntu-mobile) Mithrandir: yes, hildon-fm requires exporting some private stuff from gtk
[08:10] (Mithrandir/#ubuntu-mobile) see you
[08:10] (Mithrandir/#ubuntu-mobile) I've ifdef-ed out the tap-and-hold bits, but it seems to be caught up in some file chooser bits.
[12:56] <PP3-Man> how difficult is it to compile a kernel module in Ubuntu Mobile?
[12:57] <PP3-Man> Hello?
[12:58] <agoliveira> PP3-Man:Hi. When it came along, should be no different than the usual.
[12:58] <agoliveira> s/cames/comes
[01:18] (Mithrandir/#ubuntu-mobile) mdz: do you have the moderator password for the mobile list?
[02:05] <mdz> Mithrandir: I do, yes.  I tend to it pretty much every day
[02:05] <mdz> Mithrandir: I'm happy to share that responsibility with you if you're willing
[02:05] <ferulo> mdz, what python policy is ubuntu following?
[02:06] <mdz> ferulo: essentially the debian python policy
[02:06] <ferulo> the latest one?
[02:06] <mdz> further to that, we make efforts to, e.g., ensure that all python modules in main use python-central or similar, to ease transitions
[02:06] (Mithrandir/#ubuntu-mobile) mdz: I'd be happy to
[02:06] <mdz> ferulo: if something significant has changed just recently, I'm not aware of it yet
[02:07] <mdz> ferulo: doko is our python czar
[02:07] <ferulo> I guess that our maemo python bindings packages doesn't comply that policy at all:
[02:07] <ferulo> https://garage.maemo.org/plugins/scmsvn/viewcvs.php/packages/?root=pymaemo
[02:08] <doko> ferulo: are all these packages maintained independently?
[02:09] <ferulo> currently yes, they are a garage project
[02:09] <ferulo> and they are available on the extras repository
[02:09] <ferulo> not in our official images
[02:09] <doko> looks like most of them are in the ubuntu archive as well
[02:09] <ferulo> however they are included on sardine and our upcoming releases
[02:10] <ferulo> well, most of them are "empty" packages just including patches
[02:10] <ferulo> but some of them modified upstream stuff so we have our own tree
[02:10] <ferulo> (and python-hildon) is 100% new stuff
[02:11] <doko> is there a reason why your upstream changes can't go into the ubuntu packages?
[02:13] <ferulo> well, for the python runtime we have specific patches for low memory/cpu devices
[02:13] <ferulo> for gtk... as we are shipping a modified version of gtk, some non-upstream changes are also needed
[02:19] <ferulo> gnome-python is a subset of upstream gnome-python bindings, only gnome-vfs and gconf
[02:20] <lool> ferulo: Indeed, I had a look at python-hildon, and I don't think it's compliant with the second version of the debian python policy
[02:21] <ferulo> what tools does that 2nd version of debian python policy require?
[02:21] <lool> ferulo: Basically, the version 2 encourages packages to avoid any hardcoding of the Python versions, and encourages supporting multiple Python versions at the same time
[02:21] <lool> ferulo: For example, instead of building public Python extension for a fixed version of python, you build them for "all currently supported python versions"
[02:22] <lool> Which is returned by the pyversions tool
[02:22] <lool> ferulo: http://wiki.debian.org/DebianPython/NewPolicy gives a good overview of the required changes
[02:23] <lool> There are two competing implementations of the Python Policy support infrastructure: python-central and python-support; they are hooked in the build process in approximatively the same way, but they have subtle differences which you probably don't need to care about
[02:23] <ferulo> #
[02:23] <ferulo> Build-Depends on "debhelper (>= 5.0.38)".
[02:23] <ferulo> #
[02:23] <ferulo> Add a Build-Depends on python-central (>= 0.5.6).
[02:24] <ferulo> that debhelper is going to be a problem to us for following debian python policy :(
[02:24] (Mithrandir/#ubuntu-mobile) ferulo: why is debhelper 5 a problem?
[02:24] <lool> (One small warning, the python-support documentation tends to suggest doing things which are not compatible with python-central; I recommend sticking to the general guidelines instead of following the specialized python-support advice, for example use a debian/pycompat file)
[02:25] <ferulo> currently for sardine/our internal integration is
[02:25] <ferulo> but let me try
[02:25] <lool> ferulo: debhelper isn't too much of a problem I think
[02:25] <doko> ferulo: for ubuntu we prefer to use python-central
[02:25] <lool> ferulo: Basically, Python stuff moved away from Debhelper, and you don't need to call "dh_python" anymore
[02:26] <lool> doko: haha :)
[02:26] <lool> ferulo: So I expect it will work with older Debhelper too
[02:26] <doko> lool: no haha
[02:26] <ferulo> oh, nice
[02:26] <ferulo> I would try then to convert those packages to python-central
[02:27] <lool> doko: Perhaps a small bitter chuckle?
[02:28] <doko> lool: =)
[02:29] <lool> doko: (I added the python policy stuff and python-central preference to <https://wiki.ubuntu.com/MobileAndEmbedded/MaemoPackagingCleanup>)
[02:31] <mdz> lool: thanks
[06:14] <adilson> Mithrandir: If you have a few minutes to spare, I would like to discuss a few quick issues, if you please.
[06:24] <gotnix> hey. Can someone if possible tell me what exactly will the ume be able to run on?
[06:25] <gotnix> I'm hoping that it extends to smart phones such as the qtek. and so on
[07:04] <gotnix> hello
[07:05] <adilson> gotnix: We are still too in the beginning of the project to be able to tell anything for sure but AFAICT, the idea is to have everything from the desktop.
[07:06] <gotnix> thats what i thought? which leads me to the question of why?
[07:07] <gotnix> If there is already ubuntu for the desktop why make another edition called mobile
[07:07] <gotnix> I'm not against it. I"m very excited about the project.. and have high hopes (hoping it extends to the mobile device market, pda's etc)
[07:09] <adilson> gotnix: because the requirements for the hardware are different. The UI has to have specific features like support for small screens and touch. The kernel has to fit those requirements also and so on...
[07:10] <gotnix> Meaning if that is going to be a possibility it might not be anywhere in the immediate future.
[07:10] <gotnix> okay... fair enough. Small steps I can only hope Ubuntu will make its way to the pda market eventually
[07:11] <adilson> gotnix: The schedule is to have the first version lauched at the same time as the next desktop version: october.
[07:12] <gotnix> yeah i read about simultaneous launching of the ume with gutsy. but I mean for pda's and so on.
[07:15] <adilson> gotnix:Our first target are devices like x86 webpads. Things like PDAs are different beasts. Of course we want to cover them also but can't say right now when.
[07:16] <gotnix> Oh. Okay. That was what iw as asking initially. My apologies for asking the question wrong i guess
[07:16] <gotnix> Are you apart of the development team btw? I'm a blogger and i was just trying to garner further information before doing a blog entry
[07:22] <gotnix> well are you?
[07:23] <adilson> gotnix: Yes, I'm in the dev team.
[07:25] <gotnix> K. thanks for all the info just wanna make sure my source is a viable / valuable one. mind if i use your name in the blog entry i'm gonna do?
[07:28] <adilson> gotnix: Not at all.
[07:28] <gotnix> Thanks alot man. Thanks for the dime
[07:31] <adilson> gotnix:No problem.
[10:01] (Mithrandir/#ubuntu-mobile) adilson: I'm here now.
[10:02] <adilson> Mithrandir: fine. Can I go over a few itens with you?
[10:02] (Mithrandir/#ubuntu-mobile) sure
[10:02] <adilson> Mithrandir:Did you start to check the osso-gw-connect problem?
[10:04] (Mithrandir/#ubuntu-mobile) not really, hildon-fm doesn't compile as-is
[10:05] <adilson> Mithrandir:Fine. Well, I did and I was thinking, for now, just keep it as is and ignore the functions that calls the proprietary stuff. What do you think?
[10:07] (tko/#ubuntu-mobile) I think if you skip the gwconnect stuff, you'll only miss the bottommost icon in the filechooser which would be your paired bluetooth device
[10:09] (tko/#ubuntu-mobile) OTOH if you already have the UI for pairing with BT devices, changing the code to use the bluez APIs instead would be nice
[10:09] <adilson> Yes, the idea would be change for bluez I was thinking if it worth the trouble do it right now.
[10:10] (Mithrandir/#ubuntu-mobile) I think just note it somewhere and move on
[10:10] (Mithrandir/#ubuntu-mobile) I'd like to do a first sweep so we have something that can display a hildon desktop in an xnest, then we fix all the missing bits and brokenness
[10:11] <adilson> I tought the same: go into bluez right now would delay the whole thing quite a bit.
[10:13] (Mithrandir/#ubuntu-mobile) agreed.
[10:13] <adilson> Mithrandir: Great. Thanks.
[10:19] <adilson> Mithrandir:another thing.  Thanks.
[11:05] <adilson> Mithrandir: Is there a way to checkout all the components under ~ubuntu-mobile?
[11:35] <lool> I can a snippet to list bzr branches for a launchpad people page if you like
[11:35] <lool> Hmm too late


[05:42] <Merc> merc@thinkpad:~$ sudo apt upgrade
[05:42] <Merc> [...]
[05:42] <Merc> The following packages have been kept back:
[05:42] <Merc>   kwin-common kwin-data kwin-x11 libkwin4-effect-builtins1
[05:42] <Merc> 0 upgraded, 0 newly installed, 0 to remove and 4 not upgraded.
[05:42] <Merc> any clues?  fairly standard kubuntu 18.10 install
[05:42] <Merc> ohhh wait, hmm, i think im using the "super up to date" kde packages
[05:43] <Merc> backports
[05:53] <krytarik> Merc: Try "sudo apt full-upgrade" instead then.
[06:01] <Merc> ahh i see, it would require the removal of some other packages
[06:01] <Merc> im thinking maybe there's a conflict between current kubuntu and the backports?
[06:02] <Merc> The following packages will be REMOVED:
[06:02] <Merc>   libkwineffects11 libkwinglutils11 libkwinxrenderutils11
[06:02] <Merc> The following NEW packages will be installed:
[06:02] <Merc>   libkwineffects12 libkwinglutils12 libkwinxrenderutils12
[06:02] <Merc> might that break other things linking to 11?
[06:02] <Merc> everything's working fine as of right now...
[06:04] <diogenes_> it might break some apps that depend on older libs
[06:08] <Merc> yeah
[06:08] <Merc> i mean there must be some reason 'upgrade' is holding it back
[06:08] <Merc> i'll just leave it for now
[06:08] <Merc> i dont know enough dpkg/apt commands to see what packages depend on another package
[06:09] <Merc> and i dont care enough to rtfm at the moment
[06:09] <Merc> thanks diogenes_
[06:09] <diogenes_> yw
[06:16] <krytarik> Merc: If indeed other packages would depend on the ones up for replacement, they'd turn up in the removal list too though.  And any APT upgrade operation that requires the removal of other packages can only be done via "full-upgrade" (or "dist-upgrade" on apt-get) - as simple as that.
[06:22] <Merc> hmm, ok
[06:23] <Merc> i guess ill do it then
[06:23] <Merc> and be brave
[06:24] <Merc> be a man about it
[07:17] <lordievader> Good morning
[11:25] <BluesKaj> HI folks
[11:31] <Alexfrench> hi
[11:38] <BluesKaj> hi Alexfrench
[11:38] <Alexfrench> fine ?
[11:41] <BluesKaj> yup, anf you?
[11:41] <BluesKaj> and
[11:41] <Alexfrench> fine too thanks
[15:06] <Alexfrench> hello, from a broken laptop i have a hdd with kubuntu on it
[15:08] <Alexfrench> if i get another pc with for exemple windows on, can i put the kubuntu hdd in it and make a double boot ?
[15:08] <Alexfrench> is it possible like msdos age to add a line somewhere ?
[15:10] <genii> In that case, you'd make the Kubuntu hdd the primary boot drive, then boot up to it, then issue: sudo update-grub ...which would then find the Windows install on the other drive, and add it to the GRUB boot menu
[15:10] <Alexfrench> in the bios ?
[15:11] <Alexfrench> ok i understand in the bios kubuntu boot first
[15:11] <Alexfrench> then from terminal the command
[15:12] <genii> Yes
[15:14] <Alexfrench> ok thanks i note this
[16:42] <IrcsomeBot1> H R was added by: H R


[07:02] <fgimenez> good morning
[07:21] <dholbach> good morning
[09:19] <Chipaca> o/ !
[09:20] <Chipaca> good morning snappy'ers!
[09:20] <longsleep> hey
[09:20] <longsleep> question - do all installed snapps get passed all configs to the config hook?
[09:20] <Chipaca> longsleep: hi! how's things
[09:21] <longsleep> trying to understand snappy config :)
[09:21] <Chipaca> longsleep: "all configs", as in configs for all apps?
[09:21] <longsleep> err yes
[09:21] <Chipaca> longsleep: err no :)
[09:21] <Chipaca> there was an example somewhere
[09:21] <longsleep> so how does webdm know the ports of all the apps?
[09:21] <longsleep> snaps
[09:22] <Chipaca> longsleep: webdm cheats (it has a handcrafted security policy)
[09:22] <Chipaca> longsleep: it can call "snappy config" for every app
[09:22] <longsleep> ah ok
[09:22] <Chipaca> longsleep: and that would print out the config
[09:22] <Chipaca> it doesn't *actually* exec out snappy config
[09:22] <Chipaca> it links against snappy-the-library
[09:23] <longsleep> got it - so then the problem is how i can share config between multiple snaps?
[09:23] <Chipaca> tricky
[09:24] <Chipaca> longsleep: can you explain a little of why you need it?
[09:24] <longsleep> well i for example i have to share secrets between snaps - to make shared secret auth work
[09:24] <Chipaca> ah
[09:25] <Chipaca> longsleep: and there isn't a logical "owner" of the secrets?
[09:25] <longsleep> and i might have to know what ports another snap is using to connect to the services there
[09:25] <longsleep> Chipaca: well i assume someone could be made the logical owner, but how does the information get to the snaps which need it
[09:26] <longsleep> i mean i could put it all into a single snap - thats what i would try to avoid though
[09:27] <Chipaca> longsleep: make the owner a framework, so the others can depend on it, and give it a command that prints out the needed info?
[09:27] <Chipaca> longsleep: i'm not sure that would work, but i think maybe we should make that work if it doesn't
[09:27] <Chipaca> :)
[09:27] <longsleep> yes i think that would work
[09:28] <longsleep> at least for the configuration stuff where each snap is not the logical owner
[09:28] <longsleep> ports are a different story
[09:28] <Chipaca> wrt ports, you need a discovery mechanism, or making them non-negotiable
[09:29] <longsleep> i want to make them configurable and negotiable
[09:29] <Chipaca> the discovery mechanism can be a script as per above, or something like avahi
[09:30] <longsleep> you mean a snap could provide a script that prints ot the information other snaps might want?
[09:30] <longsleep> can i call stuff provided as binaries of snap-a from snap-b then?
[09:31] <Chipaca> i should know that, but i'm rusty from my holidays. let me check.
[09:31] <longsleep> heh :) these are good suggestions - i will try them for sure
[09:32] <ogra_> Chipaca is back \o/
[09:32] <longsleep> for now i just want to make the ports for spreed-webrtc a configuration
[09:32] <Chipaca> ogra_: allegedly :)
[09:32] <ogra_> :)
[09:32] <Chipaca> we'll see for how long (!)
[09:32] <ogra_> hey !
[09:33] <Chipaca> ogra_: just before going away i was asked if i was willing and able to work on a zomg urgent thing
[09:33] <Chipaca> ogra_: as per
[09:33] <Chipaca> ogra_: so i don't know how it's played out yet :)
[09:34] <longsleep> other question - the internal ports in package.yaml, these are the ports supposed to listen on local interface only or what is the meaning of internal in that context?
[09:35] <Chipaca> eep! snappy update just got 'no space left on device'
[09:35] <ogra_> as i understand it it is for "package intercommunication"
[09:35] <longsleep> ogra_: thats good then - so i should probably add that as well
[09:40] <longsleep> What about the ports in package.yaml if i make those configuration, would webdm know about it? I am still unsure what the ports section in package.yaml actually is doing
[09:40] <ogra_> webdm uses the external port for the "open" link in the details page
[09:41] <longsleep> yes the one marked external/ui - but what if that is a configuration ?
[09:42] <longsleep> i mean i currently ship with port 8000 as webdm does not support https links. But now i want to add configuration so people can choose to expose this on port 80
[09:42] <longsleep> then webdm would have to link there
[09:43] <longsleep> and i want to have an option to disable all the external ports and only keep the internal one so a reverse proxy can take it over
[10:00] <biezpal> hey! how cron works in Snappy? Tried to add crontab job - everything is read-only :(
[10:01] <ogra_> it will use whatever systemd provides as cron replacement ...
[10:01] <ogra_> not sure where we stand with that thouh
[10:02] <biezpal> ogra_, thanks!
[10:02] <Chipaca> i think we plan to expose timers
[10:02] <Chipaca> but haven't done so yet
[10:02] <Chipaca> timers as in systemd.timer(5)
[10:03] <biezpal> Chipaca, but it's not implemented yet?
[10:04] <biezpal> ok, got it, thx
[10:11] <Chipaca> biezpal: ubuntu-core itself installs a timer, if you need an example (it's /lib/systemd/system/snappy-autopilot.timer; when we expose this, yours would be installed to a different directory, but would be the same thing) (it'd be exposed in a way that we generate the timer ourselves, so if for any reason we need to port snappy to a non-systemd system we could still do it)
[10:18] <biezpal> Chipaca, thanks a lot
[10:26] <longsleep> ah i just found a interesting line in the docs: Some key/value pairs in the configuration are fixed, for example all applications that listen to a port must support the "ports" config option.
[10:27] <longsleep> is that the same ports as found in package.yaml?
[10:30] <Rlyeh> I want remove docker, but since some apps are using docker, it will not remove
[10:30] <Rlyeh> (BeagleBoneBlack)ubuntu@localhost:~$ sudo snappy remove docker
[10:30] <Rlyeh> Removing docker
[10:30] <Rlyeh> framework still in use by: owncloud
[10:31] <Chipaca> Rlyeh: remove the dependencies first
[10:32] <Chipaca> Rlyeh: sudo snappy remove owncloud docker
[10:32] <Chipaca> Rlyeh: will work
[10:33] <Rlyeh> I won't remove owncloud
[10:33] <Rlyeh> I don't know owncloud service name to stop
[10:33] <Chipaca> Rlyeh: sorry, i don't understand
[10:33] <Chipaca> Rlyeh: why won't you remove owncloud?
[10:34] <Rlyeh> I just want to reinstall docker
[10:35] <Rlyeh> I think it will be remove if I stop owncloud service, right?
[10:36] <Rlyeh> It seems docker doesn't work properly
[10:36] <Chipaca> Rlyeh: still not understanding, here; sorry :-(
[10:36] <Chipaca> Rlyeh: you want to reinstall docker because it's not working properly?
[10:38] <Rlyeh> yes
[10:38] <Rlyeh> I updated docker from 1.6.1 to 1.6.2 to day
[10:39] <Rlyeh> After reboot, owncloud was not working
[10:39] <Chipaca> Rlyeh: and how is it not working properly?
[10:39] <Rlyeh> I checked and port 443 was close
[10:40] <Chipaca> Rlyeh: and if you roll back docker does owncloud work again?
[10:40] <Rlyeh> Rollbacks the docker, but still docker not working
[10:40] <dholbach> hum.......
[10:40] <Chipaca> dholbach: 'sup?
[10:41] <Rlyeh> I don't know what happened but I have to fix this
[10:41] <Rlyeh> Because of owncloud
[10:41] <dholbach> Chipaca, have you seen something like this before? http://pastebin.ubuntu.com/12070190/
[10:41] <Chipaca> dholbach: it's a pastebin link. I've seen many of those!
[10:41] <Chipaca> :-p
[10:42] <dholbach> riiiiiiiiiiight
[10:42] <ogra_> dholbach, yeah., we require that you run snapcraft on your phone now for building so we check the system-image config :P
[10:43] <Rlyeh> Do you know owncloud service name to stop ?
[10:43] <ogra_> Rlyeh, systemctl|grep owncloud
[10:43] <ogra_> then just use systemctl stop
[10:44] <Rlyeh> Thank you ogra
[10:44] <Chipaca> or snappy service owncloud stop
[10:44] <Chipaca> in new enough snappys
[10:44] <ogra_> dholbach, you get that error only by running add-apt-repo ? thats really odd
[10:45] <dholbach> ogra_, it is
[10:45] <Chipaca> dholbach: i hadn't seen it, but it seems you can ignore it
[10:45] <Chipaca> it's probably aptsources.sourceslist or softwareproperties.ppa calling out to system-image-cli erroneously
[10:45] <Chipaca> deffinitely a bug, but seems add-apt-repo is still doing the right thing
[10:46] <Chipaca> aptsources
[10:46] <Chipaca> dholbach: so
[10:47] <Chipaca> dholbach: file a bug against aptsources
[10:47] <Chipaca> dholbach: then continue with your day :)
[10:47] <dholbach> ok cool, will do
[10:47] <Chipaca> in fact i can probably provide a patch for you to include in your bug
[10:48] <Chipaca> gimme a sec, then i'll give you a diff, if you could try that it'd be nice
[10:50] <dholbach> Chipaca, https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/1484470
[10:50] <Chipaca> dholbach: could you try http://pastebin.ubuntu.com/12070228/ ?
[10:52] <Chipaca> wait, that's wrong
[10:52] <Chipaca> dholbach: hold it
[10:52] <Chipaca> dholbach: ETOORUSHED
[10:54] <Chipaca> dholbach: http://pastebin.ubuntu.com/12070249/
[10:54] <dholbach> Chipaca, fixed
[10:55] <dholbach> at least there's no message now
[10:55] <Chipaca> exactly :)
[10:55] <dholbach> judging by "usage: system-image-cli  ......."
[10:55] <dholbach> it might be that s-i-c is called with the wrong parameters?
[10:55] <dholbach> h no
[10:55] <dholbach> ah no
[10:55] <dholbach> nevermind :)
[10:56] <Chipaca> dholbach: config not found
[10:56] <dholbach> yep
[10:57] <Chipaca> dholbach: should i make this a merge against python-apt, or just include the diff in the bug and let somebody else handle it?
[10:57] <dholbach> that's a question for mvo :)
[10:57] <Chipaca> making an MP then
[10:58] <Chipaca> eep
[10:58] <Chipaca> never change gpg keys the week before your holidays
[10:59] <dholbach> oops
[11:00] <Chipaca> https://code.launchpad.net/~chipaca/python-apt/no-stderr-for-you-mister-system-image-cli/+merge/267935
[11:40] <ogra_> hmm
[11:41] <ogra_> was there a way to make ubuntu-core-launcher output verbose in syslog ?
[11:41] <ogra_> Aug 13 11:40:24 localhost ubuntu-core-launcher[1761]: execv failed: Permission denied
[11:41] <ogra_> not actually helpful ...
[11:44] <Chipaca> ogra_: you probably got something in syslog about that
[11:44] <ogra_> no, thats my issue :)
[11:45] <ogra_> nothing beyond that and the .service then tellin me it exited 1
[11:47] <Chipaca> ogra_: can you actually exec the thing you're trying to exec?
[11:47] <ogra_> hard to tell ... my LD_LIBRARY_PATH is like 1000 pages long :P
[11:48]  * ogra_ tries to get xfbdev to run on a rpi
[11:48] <ogra_> mainly as "lunch exercise"
[11:49] <Chipaca> ogra_: ahhh
[11:50] <Chipaca> ogra_: did you check the obvious, ie unix perms for executables and dynamic libraries?
[11:50] <ogra_> sure, the tree loosk fine
[11:50] <longsleep> so anyome has thoughts if the config hooks port yaml format is the same as of package.yaml - i did it that way now but does it make sense?
[11:50] <ogra_> i think it is
[11:52] <Chipaca> ah! i was going to check that, and got dragged into this python-apt madness
[11:52] <Chipaca> longsleep: if you install webdm, what does 'snappy config webdm' spit out?
[11:52] <Chipaca> longsleep: because it's got a port
[11:53] <longsleep> that is broken
[11:53] <longsleep> i thnk i have added a bug for this already
[11:54] <longsleep> Cn
[11:55] <longsleep> Chipaca: ah yes https://bugs.launchpad.net/webdm/+bug/1482720
[11:55] <ogra_> ARGH !
[11:55] <Chipaca> WAT
[11:55]  * ogra_ bangs head against wall
[11:55] <longsleep> Chipaca: but from the code at http://bazaar.launchpad.net/~snappy-dev/webdm/trunk/view/head:/pkg/meta/hooks/config it does nothing related to ports
[11:55]  * Chipaca quickly slips pillow between ogra and wall
[11:55] <ogra_> start-service.sh .... not executable ... sigh ... so silly
[11:56] <Chipaca> ogra_: \o/
[11:56] <Chipaca> ogra_: glad i asked the silly question first, then :)
[11:56] <ogra_> yeah, thanks !
[11:57] <Chipaca> longsleep: can you add a try/except around lines 64 and 65, just to see the output?
[11:57] <Chipaca> longsleep: i can provide a patch if you don't python
[11:58] <longsleep> Chipaca: i have many years python history - going for lunch now but will check in 20 minutes or so thanks!
[12:02] <Chipaca> longsleep: excellent! and buen provecho :)
[12:04] <Chipaca> I say "buen provecho", and dpm comes in
[12:05] <Chipaca> i'm not a suspicious person, but ... :-p
[12:14] <longsleep> Chipaca: i am back with lunch - config is empty as is expected from reading the hook code (it only exposes avahi-hostname)
[12:16] <longsleep> Chipaca: if you are intersted, my hook now returns this yaml: http://paste.ubuntu.com/12070607/ - what do you say?
[12:19] <Chipaca> longsleep: and assigning them works?
[12:19] <Chipaca> sergiusens: longsleep is trying to make external ports configurable and negotiable
[12:20] <longsleep> Chipaca: well, i am just writing that part but i would not see why not as this is all in my hook and just a matter of my applying them to the service config.
[12:22] <sergiusens> longsleep: Chipaca we don't have the backend ready for that so doing it through config seems fine
[12:22] <sergiusens> Chipaca: are you back at work? Or just leasure?
[12:25] <Chipaca> sergiusens: back at work!
[12:25] <Chipaca> sergiusens: already having two simultaneous meetings (if you don't count this)
[12:39] <kyrofa> ogra_, I also can report piglow success using your rpi2 image :)
[12:39] <ogra_> yippie !
[12:40] <kyrofa> ogra_, but of course, when I package as a snap, I get apparmor denials. Are there any templates or caps I can use that will grant me access?
[12:40] <kyrofa> (to the i2c device, I mean)
[12:41] <ogra_> https://developer.ubuntu.com/en/snappy/guides/appliance-builder-guide-webcam/ take a look at the webcam example
[12:44] <kyrofa> ogra_, ah, perfect, thank you :)
[12:46] <kyrofa> ogra_, well, not quite. Is making an OEM snap the only way to provision hardware like that?
[12:56] <ogra_> kyrofa, where does it say it is an oem snap ?
[12:56] <ogra_> should be just a normal snap but you need to manually enable the hw access after install
[12:57] <kyrofa> ogra_, oh okay. The first bit of the document talks about manually enabling hw access, but then it goes through the process of creating an OEM snap to do it automatically
[12:57] <kyrofa> ogra_, so there's no way to request hw access from a regular snap?
[13:08] <sergiusens> kyrofa: the manual process is the "trusted helper" or lack thereof ;-)
[13:09] <kyrofa> sergiusens, ah, okay so that's the vision for how regular old snaps can get hw access?
[13:12] <sergiusens> kyrofa: depends; on personal I guess it would be through the trusted helper system
[13:12] <sergiusens> on custom devices, you would build your custom gadget
[13:13] <kyrofa> sergiusens, gadget being another kind of snap? I've not gotten into that just yet
[13:15] <sergiusens> kyrofa: it's what is the oem today
[13:15] <kyrofa> sergiusens, gotcha
[13:29] <kyrofa> sergiusens, I have a snap for arm that uses the piglow (via i2c). Knowing that it requires i2c support and requires explicit hw access granting, is that something I can submit to the store?
[13:30] <sergiusens> kyrofa: yes you can
[13:31] <sergiusens> kyrofa: users of it just need to explicitly allow the crazy things it would do with your hardware
[13:32] <ogra_> now it would be really great if webdm would actually show the description for packages ... then youo could even tell the users what they need to do :P
[13:40] <kyrofa> ogra_, no... that would be too much...
[13:40] <ogra_> heh
[13:43] <kyrofa> ogra_, the description should be in debian/control of the generated snap, right?
[13:43] <kyrofa> ogra_, ah, nevermind. The manifest
[13:57] <sergiusens> ogra_: in rolling that should all work; once we have snap uploads per release it can go into 15.04
[14:01] <kyrofa> sergiusens, why is only the first two paragraphs of the meta/readme used? Makes it tough to format things decently
[14:01] <kyrofa> sergiusens, just space concerns?
[14:01] <sergiusens> kyrofa: don't get me started on how much I dislike that readme.md ;)
[14:02] <kyrofa> sergiusens, ah, okay. As long as I'm not the only one ;)
[14:21] <ogra_> hmm, why can i not set TMPDIR in my service start script ?
[14:21] <ogra_> seems to still point to /tmp ... no matter what i do
[14:24] <sergiusens> ogra_: I thought Chipaca worked on mounting tmp for snaps into a new namespace
[14:24] <Chipaca> yep
[14:25] <Chipaca> you get a private tmp
[14:25] <Chipaca> and you like it
[14:25] <sergiusens> so you need to define "see" ;-)
[14:25] <ogra_> i do, xorg doesnt :P
[14:25] <Chipaca> ogra_: what's xorg trying to do?
[14:25] <ogra_> http://paste.ubuntu.com/12071355/
[14:25] <ogra_> compiling a keymap in /tmp
[14:25] <ogra_> trying to set TMPDIR doesnt make it pick up any different dir
[14:26] <ogra_> and it also doesnt seem to pick up whatever is set by the launcher
[14:26] <Chipaca> ogra_: could you list /tmp/ for me please?
[14:26] <ogra_> oh, wait ...
[14:26] <ogra_> did the tmpdir cange land in 15.04 ?
[14:27] <Chipaca> ogra_: quisió! but maybe not
[14:27] <Chipaca> ogra_: but looking at /tmp/ after a run will tell you
[14:27] <elopio> fgimenez: my throat hurst a little. Lets talk here today.
[14:28] <ogra_> Chipaca, hmm ... might be helpful if it also cleaned up after itself http://paste.ubuntu.com/12071402/
[14:28] <ogra_> only 500 tmpdirs :P
[14:29] <fgimenez> elopio, ok take care!
[14:29] <elopio> fgimenez: I agree that parsing the writer output is the most simple thing to do now.
[14:30] <fgimenez> elopio, ok, the outputWriter type is what we need, but now is difficult to use
[14:30] <Chipaca> ogra_: that's the private tmp signature there
[14:30] <Chipaca> ogra_: look inside those, at permissions
[14:30] <elopio> fgimenez: yes, we need help from niemayer there.
[14:30] <Chipaca> hopefully we haven't broken that (!!)
[14:31] <ogra_> Chipaca, but why does itr leave them behind ?
[14:31] <fgimenez> elopio, hopefully i'll push something today for the parsing approach, it's quite easy given the current output
[14:31] <ogra_> (and inside which of them would i look now, so many choices !)
[14:32] <ogra_> (RaspberryPi2)ubuntu@localhost:~$ sudo ls -l /tmp/snap.0_xserver-fbdev.sideload_zoK1gY/
[14:32] <ogra_> total 0
[14:32] <ogra_> drwxrwxrwt 3 root root 60 Aug 13 14:04 tmp
[14:32] <ogra_> (RaspberryPi2)ubuntu@localhost:~$ sudo ls -l /tmp/snap.0_xserver-fbdev.sideload_zoK1gY/tmp/
[14:32] <ogra_> total 0
[14:32] <ogra_> permissions seem fine
[14:32] <Chipaca> ogra_: i think the consensus was we wanted to clean them up with something like tmpreaper, not right after things stopped
[14:32] <ogra_> hmm, k
[14:33] <fgimenez> elopio, good news, we have a new docker framework version ready thanks to kickinz1 :)
[14:33] <fgimenez> elopio, http://<IP_ADDRESS>:8080/job/daily-1504/
[14:33] <elopio> plars: the ppa is updated. Here's the script: http://people.ubuntu.com/~elopio/spi_scripts/snappy-tests-job.sh
[14:33] <ogra_> the prob is that if you develop and your service crashes in a loop you might end up with 500 dirs there :)
[14:34] <elopio> fgimenez: cool. One failure in there in a restart, I haven't seen that one.
[14:34] <Chipaca> ogra_: conversely, if your app crashes in a loop and we clean up tmp, and the crash was because of tmp wackiness, ...
[14:34] <elopio> but it's nice, we can start collecting stats :)
[14:34] <ogra_> Chipaca, well, anyway, xkb doesnt seem to see the TMPDIR at all according to the log
[14:34] <ogra_> (II) XKB: generating xkmfile /tmp/server-B20D7FC79C7F597315E3E501AEF10E0D866E8E92.xkm
[14:34] <fgimenez> elopio, yes :) that execution was strange, it got stuck in the first update for almost one hour, then it gave that error...
[14:35] <ogra_> that doesnt look like it uses TMPDIR
[14:35] <fgimenez> elopio, enyway, if you can put an instance to execute the tests it would be great to compare results
[14:35] <fgimenez> *anyway
[14:36] <Chipaca> ogra_: which is weird, because it doesn't have to
[14:36] <elopio> fgimenez: ok, let me trigger one.
[14:36] <Chipaca> ogra_: that is, you have a private /tmp/
[14:36] <ogra_> Chipaca, ah, so /tmp should be transparent ?
[14:36] <Chipaca> ogra_: you don't need to "see" TMPDIR or anything
[14:36] <ogra_> ok
[14:36] <Chipaca> ogra_: the env vars were left for backwards compat, but enough things ignore them that you have a whole /tmp just for you
[14:36] <plars> elopio: cool, I'll check it out in just a bit
[14:36] <Chipaca> that just happens to be a subdir of /tmp/ :)
[14:37] <kickinz1> o/
[14:37] <ogra_> right
[14:37] <elopio> plars: you wget that script, and run it passing the ip. Let me know what happens..
[14:37] <ogra_> probably thats a red herring
[14:39] <plars> elopio: a lot of errors it looks like
[14:41] <elopio> plars: paste please.
[14:42] <plars> elopio: I'm working through them... it looks like the first was because I needed bzr, now it seems to want golang installed
[14:43] <elopio> um, that's right, it will need debs.
[14:43] <elopio> I didn't take thata into account... so not really that different from installing from the ppa.
[14:44] <plars> elopio: will it also need autopkgtest?
[14:44] <plars> I suspect it won't need some of those things
[14:44] <plars> since I'm not using it for provisioning
[14:44] <plars> I had hoped all the go build pieces could be skipped - I thought that was the point of providing the go binary
[14:45] <plars> oh, it needs git also
[14:45] <plars> elopio: ^ I didn't even see git mentioned in the control file
[14:48] <elopio> plars: yes, autopkgtest from wily.
[14:48] <plars> ok
[14:48] <elopio> plars: that was my naive idea yesterday. Now I realize it makes no sense.
[14:48] <plars> so it seems that one way or another, this is going to need a lot of customization on the host ahead of time
[14:49] <elopio> we could reduce the set up needed by providing also a binary for snappy tests, but not much.
[14:49] <elopio> plars: yes.
[14:49] <plars> elopio: if we install from your ppa, does it automatically get the right version of autopkgtest?
[14:49] <elopio> plars: only if the host is in wily.
[14:50] <plars> elopio: I'm not opposed to setting it up on the test hosts, but I do worry it will cause you some pain in the future to do it this way. Having everything self-contained means you can make fewer assumptions about the test environment, and separates concerns about the tests vs. hardware much better
[14:50] <plars> elopio: no, the host is on trusty here
[14:51] <elopio> plars: even if we don't use autopkgtest for provisioning, we need it for reboots. So that's one dependency we can't easily work around.
[14:51] <plars> elopio: so installing from the ppa wouldn't help us anyway
[14:51] <elopio> plars: so install it as explained in _integration-tests/README.mf
[14:51] <elopio> *md
[14:51] <plars> elopio: how often do you think this package will change?
[14:52] <elopio> plars: very often, but we won't need to update it every time.
[14:56] <plars> https://www.irccloud.com/pastebin/IA0r1xOX/
[14:56] <plars> elopio: ^
[15:01] <ogra_> mterry to the rescue !
[15:01] <mterry> ogra_, what's up?
[15:02] <ogra_> mterry, you packaged some xorg snap once ... how did you havdle the keymap generation ?
[15:02] <ogra_> *handle
[15:02]  * ogra_ is stuck with that ... and i cant convince xorg to not try to use a kbd at all
[15:03] <mterry> ogra_, I believe deb2snap has a hack for that.  In tools/fixes, it copies over /var/lib/xkb/*.xkm into the snap
[15:03] <ogra_> oh, so you generate them in advance ?
[15:03] <ogra_> i'll take a look
[15:04] <mterry> ogra_, and then another hack that places them in $SNAP_APP_DATA_PATH (since that's where the ld-preload code looks for them
[15:04] <mterry> ogra_, yeah, they are just sitting there on the system that runs deb2snap, so I figured we'd just use those
[15:04] <ogra_> ah, i'm trying to get along without any preloading (works fine apart from that one thing)
[15:08] <elopio> plars: sorry, I'm on the stand up. Let me try...
[15:09] <plars> elopio: no rush
[15:20] <elopio> plars: I don't get that error. fgimenez: any ideas? https://www.irccloud.com/pastebin/IA0r1xOX/
[15:25] <fgimenez> elopio, never seen before, "Syntax error: Unterminated quoted string"
[15:26] <kyrofa> sergiusens, does hw-assign not take effect on a running process? I always have to restart it in order for it to access the hw
[15:26]  * ogra_ sends the terminator ovber
[15:27] <elopio> fgimenez: this looks just fine: go run ./_integration-tests/main.go -ip <IP_ADDRESS>. No idea what might be wrong in there.
[15:27] <sergiusens> kyrofa: I am not sure, but I guess so since the apparmor profile is extended and needs to re run so it is reconfined
[15:27] <sergiusens> not sure you can reconfine on the fly
[15:27] <sergiusens> jdstrand: ? ^
[15:28] <elopio> plars: can you set up your GOPATH, branch snappy and run the tests from there? That will give us a better clue of where's the problem.
[15:28] <kyrofa> sergiusens, this gave me the impression it was possible: https://developer.ubuntu.com/en/snappy/guides/appliance-builder-guide-webcam/
[15:29] <kyrofa> Notice how it assigns the hw and voila, it works
[15:29] <kyrofa> But mine doesn't work that way :P
[15:29] <fgimenez> elopio, the testbed is amd64, right?
[15:29] <elopio> fgimenez: yes according to plars.
[15:29] <elopio> ah, wait, we are not building for arm.
[15:30] <elopio> the host is amd64, the test bed is arm.
[15:31] <jdstrand> hw-assign does more than apparmor-- it will setup the device cgroup and add the device to that cgroup. as such, I believe you much relaunch the process (unless there is a way to update the cgroups for a running process-- I don't know)
[15:31] <elopio> fgimenez: in the end, we need snappy-test-job to receive all the flags that snappy integration tests receive. Is there a better way to do it instead of copying everything?
[15:31] <jdstrand> possibly worth a bug for the core guys to look at
[15:31] <plars> elopio: fgimenez: no, the testbed is bbb
[15:32] <plars> elopio: fgimenez: I said the test host is amd64
[15:32] <plars> the agent host that is
[15:32] <elopio> plars: yes, my mistake.
[15:32] <kyrofa> jdstrand, so the link above must have missed a step?
[15:32] <plars> bbb, obviously, is not
[15:32] <fgimenez> plars, elopio then we need an -arch flag too
[15:32] <elopio> fgimenez: adding it...
[15:33] <jdstrand> kyrofa: yes. that may have been written before mvo implemented the cgroup bits (things were landing hot at the time)
[15:34] <kyrofa> jdstrand, ah, okay. Thank you!
[15:35] <fgimenez> elopio, flag.Visit could be handy for passing the options around, but anyway the flags should be defined in the entrypoint, and we have two of them now...
[15:37] <kyrofa> jdstrand, is the only way to do that via a reboot?
[15:37] <kyrofa> jdstrand, or can I request a service restart via snappy?
[15:37] <jdstrand> oh no, just restart the service
[15:38] <ogra_> HEY ! everyone congratulate longsleep !!! seems we'll have the first snappy based commercial device on the market soon ;)
[15:39] <jdstrand> congrats!
[15:39] <jdstrand> kyrofa: give me a moment
[15:39] <ogra_> secure videochat FTW !
[15:39] <ogra_> screw these hangouts :)
[15:41] <jdstrand> kyrofa: systemctl -a | grep <your service>
[15:41] <jdstrand> kyrofa: then restart with:
[15:41] <jdstrand> sudo systemctl stop <service name>
[15:41] <jdstrand> sudo systemctl start <service name>
[15:41] <kyrofa> jdstrand, alright, thanks!
[15:43] <kyrofa> jdstrand, I saw some mailing list noise about auto-restart a while back. Was that ever implemented?
[15:43] <jdstrand> I'm not sure. I think there was a branch. sergiusens ^
[15:44] <jdstrand> kyrofa: I think that would still require you to kill the process
[15:44] <jdstrand> (so it could restart)
[15:44] <kyrofa> jdstrand, which is easy. If I'm denied access, die
[15:44] <jdstrand> but maybe more was exposed
[15:44] <jdstrand> yes, but then you will be auto restarted
[15:45] <kyrofa> Which would solve this problem, wouldn't it?
[15:45] <kyrofa> Or are you saying the parent process wouldn't let the confinement happen?
[15:45] <jdstrand> so, I'll defer to the people who implemented/are implementing the feature to explain how it works :)
[15:45] <jdstrand> kyrofa: I'm saying if you never ran hw-assign, it would loop until you did
[15:45] <kyrofa> Ah right, agreed
[15:46] <jdstrand> but ceratinly that was thought about
[15:46] <sergiusens> jdstrand: that was for config changes and the idea was that services would HUP
[15:47] <kyrofa> sergiusens, ah, so that won't help me eh?
[15:47] <jdstrand> there are config changes, but there is also the bit about services autorestarting if they die
[15:47]  * ogra_ remembers that too
[15:48] <sergiusens> jdstrand: that should be in already
[15:48] <jdstrand> https://bugs.launchpad.net/snappy/+bug/1461917
[15:48] <sergiusens> jdstrand: I have my services under dev dying and respawning all the time now
[15:48] <ogra_> not released :)
[15:48] <jdstrand> and for 15.04, it says it is fixed
[15:48] <ogra_> oh, right
[15:49] <jdstrand> kyrofa: so, maybe just kill your process and it will come up
[15:49] <ogra_> well, my xserver snap here dies all the time and restarts in a loop ... so yes, seems to work :)
[15:49] <kyrofa> jdstrand, trying
[15:49] <jdstrand> sergiusens: hw-assign probably needs to HUP things
[15:50] <kyrofa> jdstrand, no such luck. ogra_ think your i2c image included those changes?
[15:50] <jdstrand> kyrofa: summary of backscroll-- kyrofa has a service that is denied access. he uses hw-assign. that does not take effect until the process is restarted. this is certainly because of the running process' cgroup and it not picking up the device cgroup change until the next invocation
[15:50] <ogra_> kyrofa, i'm staring at a syslog where a broken snap gets permanently restarted in a loop, so yes, i thnk they are in
[15:50] <jdstrand> err
[15:51] <jdstrand> sergiusens: ^
[15:51] <jdstrand> kyrofa: are you on 15.04?
[15:52] <kyrofa> jdstrand, yeah. Let me see what happens if I just exit with a non-zero status...
[15:53] <jdstrand> that may do it
[15:53] <jdstrand> Restart=on-failure
[15:54] <sergiusens> jdstrand: that's automatic now
[15:54] <jdstrand> right, that is what I'm saying
[15:54] <jdstrand> I'm looking at the diff and see that was added
[15:54] <jdstrand> sergiusens: oh wait, what are you referring to, the on-failure or the cgroup?
[15:56] <ogra_> http://paste.ubuntu.com/12071972/ on failure works fine ...
[15:56] <kyrofa> jdstrand, interesting, it DOES work, but I get this after a few times: start request repeated too quickly
[15:56] <ogra_> if the executable dies it gets auto respawned
[15:56] <kyrofa> There seems to be some sort of rate limiting or something
[15:57] <dholbach> mterry, if you have a quick look at bug 1484515 and bug 1484538 can you maybe tell me if I'm doing it wrong? :)
[15:57] <jdstrand> kyrofa: yeah. so I see in http://www.freedesktop.org/software/systemd/man/systemd.service.html that on-failure ignores if the process is sent TERM (the default by kill)
[15:57] <jdstrand> kyrofa: I bet if you do kill -9 it would work
[15:58] <fgimenez> elopio, ping me if you need the ppa to be rebuilt
[15:59] <elopio> fgimenez: https://code.launchpad.net/~elopio/snappy-tests-job/arch/+merge/267969
[16:00] <kyrofa> jdstrand, that was with a non-zero exit status
[16:00] <kyrofa> jdstrand, so if it dies quickly it will only do it a few times
[16:00] <jdstrand> kyrofa: right. I'm saying, remove the non-zero exit status bit (it detected the loop I mentioned before), and simply send it kill -9
[16:01] <jdstrand> I bet that will work
[16:03] <jdstrand> I imagine the fix for this is that after hw-assign, have snappy simply restart the affected services. that probably makes most sense anyway cause if the sevice started without access to the device, it may not notice it all of a sudden has access
[16:03] <kyrofa> jdstrand, you're right, that works
[16:03] <jdstrand> cool
[16:04] <kyrofa> jdstrand, yeah, that's the position I'm in now. I mean, it's impossible for it to notice that it all of a sudden has access since it's effectively still confined
[16:04] <jdstrand> kyrofa: would you mind filing a bug on this? https://bugs.launchpad.net/snappy/+filebug
[16:04] <kyrofa> jdstrand, definitey
[16:04] <jdstrand> kyrofa: feel free to copy/paste from the irc backscroll
[16:05] <elopio> fgimenez: thanks for the review. And yes, now I need a ppa rebuild.
[16:07] <fgimenez> elopio, ok :) https://code.launchpad.net/~fgimenez/+recipe/snappy-tests-job-daily
[16:07] <elopio> fgimenez: thanks! sorry for keeping you late.
[16:07] <joc_> hi, could any members of Snappy Devs have a look at my snapcraft branch? i have attempted to add a new plugin and would appreciate any feedback before requesting a merge lp:~jocave/snapcraft/plainbox-provider-plugin
[16:08] <fgimenez> elopio, np at all, how could we transfer the ppa to the team?
[16:08] <elopio> fgimenez: I think these packages should go to the tools ppa.
[16:11] <kyrofa> jdstrand, even with hw-assign restarting affected processes, I'm still not sure how I'm supposed to write a service that requires a hw resource
[16:11] <fgimenez> elopio, ok, let me know if something is needed from my side o/
[16:12] <kyrofa> jdstrand, if I die immediately I'll get restart throttled by systemd. If I retry constantly I know I'll never get access to it due to confinement not changing on a running process
[16:12] <kyrofa> jdstrand, what's the best way to handle this?
[16:20] <mterry> dholbach, heyo!  Saw your message.  I switched off the snappy team back to unity8.  Looks like you figured out the meta package one a bit more tho
[16:20] <dholbach> wow, ok
[16:20] <dholbach> all the best with unity8!
[16:21] <mterry> dholbach, the file-exists one is weird, since we use exist_ok=True when making the directory
[16:22] <dholbach> mterry, it's a link - that's probably why
[16:22] <kyrofa> sergiusens, any opinion on how to best write a service that requires access to hw? ^^
[16:27] <jdstrand> kyrofa: I suggest checking the return code of the open. if it fails, you can choose to die hard with exit 1 (perhaps logging to use hw-assign) or to fail gracefully and keep trying to access it
[16:28] <jdstrand> kyrofa: the hw-assign restart should do a stop/start, so if you are already stopped (ie, you failed with non-zero) you should be ok
[16:28] <elopio> plars: script updated.
[16:28] <jdstrand> but really it is up to you as the app author
[16:28] <plars> elopio: ack, thanks
[16:29] <kyrofa> jdstrand, very good. I think the best solution there is probably to exit with a good log message then
[16:35] <kyrofa> jdstrand, crap, except the nice log message gets eaten by systemd's "ack! it's restarting too fast" errors: http://pastebin.ubuntu.com/12072279/
[16:36] <jdstrand> kyrofa: you could exit 0
[16:36] <jdstrand> kyrofa: that won't trigger on-failure
[16:36] <plars> elopio: this seems to be working a lot better so far
[16:36] <kyrofa> Oh. Yeah, good idea
[16:36] <plars> elopio: any thoughts on how you might get the results out?
[16:36] <plars> elopio: that's something that could be added to the script
[16:37] <elopio> plars: autopkgtest saves them in the output directory, which I think is set to /tmp/snappy-test
[16:37] <elopio> let me confirm.
[16:37] <plars> elopio: right, but that doesn't help you any
[16:37] <plars> elopio: you'll want to upload them somewhere I assume?
[16:37] <plars> elopio: get them back into a jenkins job, or something like that?
[16:38] <elopio> plars: yes, I need the agent to send them back to me.
[16:38] <elopio> plars: you can put them anywhere, and save the url in the result payload.
[16:38] <plars> elopio: talk to ev to be sure, but I don't think there's any plans for SPI to do that.  The agent can pick up a json file with a limited amount of data in it, but probably not your full results that you care about
[16:39] <plars> elopio: it's not really up to me - it's what ever you define in your script about where to put them. I'm just saying, saving them to /tmp is probably not going to help you here
[16:39] <elopio> plars: so far, I just need a true or false in that json. Federico is working on saving the results as subunit, which we can translate to junit if you want. That's all we need.
[16:40] <elopio> maybe for things like snapcraft we'll need other artifacts.
[16:40] <kyrofa> jdstrand, should hw-assign start a service that has exited without error though?
[16:40] <kyrofa> jdstrand, or is it a case of "Well, it's a snappy service. It should expect to always be running"
[16:41] <plars> elopio: so for that, you'll want to have your script output something called 'spi_test_result.json' at the end
[16:41] <jdstrand> I think it is the latter. it is an interesting discussion point
[16:41] <elopio> plars: sure. But the agent should take care of the upload. Otherwise we'll have to pass the credentials in the script.
[16:42] <plars> elopio: upload to where? I don't think they have plans to define where you store your results - at least that's what I've always heard, but you could ask
[16:42] <kyrofa> jdstrand, I'll make a note of it on the bug
[16:43] <kyrofa> jdstrand, thanks for all your help :)
[16:43] <jdstrand> np
[16:43] <elopio> plars: anywhere you want. This is not upload to spi, this is upload to any storage. What we pass to spi is only the url to that storage.
[16:44] <plars> elopio: it's not up to me either
[16:44] <plars> elopio: I am just providing the hardware
[16:44] <elopio> when we talked to ev and noise][, I was thinking I was going to control the agent so I thought about uploading to swift.
[16:44] <plars> elopio: as far as I care, you can put them in /tmp... they'll likely get lost there, but I'm not the one that needs to see them :)
[16:44] <elopio> now that I don't control the agent, I can't control the upload either.
[16:45] <plars> elopio: no, but you control your script - and that's where the upload happens from
[16:45] <plars> elopio: all the agent can do is run the commands defined - which for this one gives you a list of commands to run
[16:45] <elopio> plars: but I certainly shouldn't send my canonistack credentials on this script.
[16:45] <plars> elopio: which is why I recommended putting it in a script like that
[16:45] <plars> elopio: I don't have canonistack credentials here either, or any intention of using it
[16:46] <plars> elopio: nor do I know where you want them, how long to retain data, whether the data is private...
[16:46] <plars> elopio: only you can know what you want done with your results, or even which results you want to collect
[16:46] <elopio> plars: just give me true of false for now.
[16:47] <plars> elopio: otherwise, I'm either just guessing, or having to be way over-concerned with what each particular test wants and where they want it - rather than providing the hardware service
[16:47] <plars> elopio: I can't even give you a true or false - I'm telling you what you need to do to get that though
[16:48] <plars> elopio: you need to export that file mentioned earlier, and the spi agent itself (not anything I control) picks that up to provide a result back to SPI
[16:48] <plars> elopio: afaik, it's arbitrary json up to some limit in size, so you can put whatever you want in it
[16:48] <elopio> plars: you can tell me if the script I gave you exit with 0 or not. That's the only thing I need for now.
[16:49] <plars> elopio: I can't do that in my stuff, because then it would override what anybody does
[16:49] <plars> elopio: and I don't know how to interpret your results
[16:49] <plars> elopio: is it not just as easy for you, and more beneficial, to add an echo at the end of your script?
[16:50] <elopio> plars: ok, then we'll wait for the subunit change.
[16:50] <plars> elopio: if that's all you need, then you could add a last line in your .sh file to do something like echo "{'result': '$?'}" > spi_test_result.json
[16:51] <plars> elopio: and then later, you can have it actually save a url there, if you push it somewhere, or add an image #, or whatever you like
[16:51] <elopio> plars: ok. is that the name you want?
[16:51] <noise][> elopio: the agent will send test_status="PASSED" if the testcommand exits w/0
[16:51] <plars> elopio: it's not what I want, it's the name defined in the documentation - I have no control over this part
[16:52] <elopio> I can't upload anything to an URL, because I won't send the password to the SPI server. But I don't need that yet either, so no point on discussing about it.
[16:52] <plars> elopio: but you can put whatever you like in there, up to 4000 bytes iirc? (noise][ is that right?)
[16:52] <noise][> elopio: see the "Actors and Results" section at the very bottom of the docs
[16:52] <noise][> plars: correct.
[16:52] <plars> elopio: nor do I, but the spi server doesn't store stuff like that anyway
[16:52] <ev> Yes, separation of concerns. SPI is not offering test artefact storage; that's something you need to give your tests the smarts to handle. Neither SPI nor the Lab should have any knowledge about how test results or result metadata is formatted.
[16:52] <plars> elopio: you're results server does
[16:53] <plars> elopio: for instance, cert team will almost certainly have the results from plainbox uploaded to the certification server
[16:53] <plars> the tool they use to run tests has some sort of exporter module (not a checkbox dev, so I'm fuzzy on this) to push the results there
[16:54] <plars> I think it can export other things too, but that's the one that would make sense, because it saves it off to a remote result server
[16:54] <plars> but you wouldn't care to have that
[16:54] <plars> or if you do, you can I guess, but you'd probably want to run your tests in a plainbox provider
[16:54] <elopio> at this moment, I just care about true or false, and get subunit working.
[16:54] <plars> but neither the agent, nor the provisioning kit know anything about that
[16:55] <elopio> then I'll care about other things, and we'll figure out how to get them.
[16:57] <ev> plars: I think a reasonable compromise might be that the credentials live on disk where they're used
[16:57] <ev> Like how mojo specs are done
[16:58] <plars> elopio: cool, these tests still seem to be running well, but they take a while. Any idea how long on bbb?
[16:58] <ev> So the tests might know the path to creds, but they're stored on the agent's host
[16:58] <ev> Reasonable, or are you worried this breaks separation of concerns?
[16:59] <elopio> plars: with my new microsd that says something like hc1, around 30 minutes.
[16:59] <elopio> with my old one, more close to 1 hour.
[16:59] <plars> ev: it certainly breaks separation of concerns, but so does the local setup needed on the agent host so that his tests will run. It might be nicer if we could find some other way, but I'm happy to make it work for now as long as everyone understands the inherent fragility of doing it that way
[17:00] <elopio> noise][: ok, I updated the script with set -e. That's good enough for me now.
[17:00] <plars> ev: ^ tests > 1hour still a problem?
[17:00] <plars> elopio: I don't think it automatically saves the output
[17:01] <plars> elopio: oh, sorry I misread. nm :)
[17:01] <plars> somehow I thought you said -x
[17:06] <ev> plars, elopio: tests greater than an hour are a problem, yes
[17:06] <elopio> the tests that take a lot of time are the failover tests, which are the useful ones.
[17:07] <elopio> and currently we have only like 4.
[17:07] <elopio> we could just run them on the cloud, but then the usefulness of the bbb lab is not that much.
[17:07] <plars> ev: is there any way for the test spec to give it better hints about how long it should run?
[17:08] <elopio> there are some things that will reduce the time, like caching the update download. But I'm not sure when we'll have that.
[17:08] <ev> plars: not yet, but it's intended: https://trello.com/c/eJF6ngJs/110-story-document-intended-behaviour-of-long-running-tests-exceeding-the-timeout
[17:09] <plars> elopio: I think, iiuc, it would work right now, but if it takes too long it could end up looping
[17:09] <ev> (see Celso's comment in that card)
[17:09] <ev> yeah, it'd loop
[17:10] <elopio> another thing we have in mind is to deploy many cloud instances and run the tests in parallel. But with the current agent approach for bbbs, we have access to only one.
[17:10] <ev> I'm going to book us a meeting to discuss the credentials thing and setupcommand/testcommand being pushed a bit more towards the tests
[17:11] <plars> ev: is there some way to uniquely identify the agent? One big hint that could make this more efficient is if the agent requests a test opp, never acks, and requests one again
[17:11] <elopio> ev: ok. If possible, please make it around this time.
[17:12] <elopio> ev: even better if you can make it at 14:00 utc, so we have federico.
[17:12] <plars> then we could be more permissive with the timeout, default it to 2 days or something crazy
[17:13] <plars> should still be possible to override though I think, since there could be a test spec that wants to run some long stress test for a month
[17:16] <ev> elopio, plars, noise][: invite sent
[17:16] <ev> plars: I've added your thoughts to the card
[17:17] <ev> and I've moved it up, as this is going to bite us quick it seems
[17:17] <ev> elopio, plars: is that your assessment as well?
[17:19] <plars> ev: I hope so, if it bites us soon then it means we're making great progress on fully getting these things running and doing something useful :)
[17:21] <elopio> ev: yes, we want to add more tests, so the time will definitely increase even if we find a way to run the current tests faster.
[17:22] <ev> thanks guys
[17:43] <plars> https://www.irccloud.com/pastebin/rH0vRoXl/
[17:44] <plars> elopio: some more errors after running for a little over an hour ^
[17:44] <plars> elopio: I'm just running the script by hand for now
[17:44] <elopio> plars: that script is for rolling
[17:44] <elopio> your bbb is in 15.04. We need a different script, or to pass an argument to that script.
[17:45] <plars> elopio: oh cool. Well that will be controlled by what image we tell it to install, so that's no problem then
[17:45] <plars> cool
[17:47] <elopio> plars: yes, I suppose it's better to make a different test image, different script.
[17:56] <longsleep> Mhm snapp config docs say that the service will be restarted by snappy automatically. Does not seem to be true.
[17:57] <plars> elopio: either would work fine. That would be in the spec to tell it which to call, and the spec is defined for a given image type
[17:58] <plars> so it could call different scripts or pass different args, or whatever makes sense
[18:03] <ogra_> longsleep, file it :)
[18:35] <kyrofa> sergiusens, jdstrand Restart=on-failure is only put in the .service file for a sideloaded snap, not for one installed from the store. Is that on purpose?
[18:36]  * jdstrand did not implement this feature, but this sounds like a bug
[18:40] <kyrofa> jdstrand, alright, I'll log that one as well
[18:44] <longsleep> ogra_: filed bug #1484641
[18:44] <nothal> Bug #1484641: snappy config command does not restart service after setting the configuration <Snappy:New> <http://launchpad.net/bugs/1484641>
[18:45] <longsleep> But i pushed a new Spreed WebRTC version with configuration hook to the store nethertheless. Works fine as long as you know how to get the systemd service named and to restart it.
[18:57] <kyrofa> sergiusens, double-checking before I log a bug: https://bugs.launchpad.net/snappy/+bug/1461917 is fixed for `snap:qpy install` invocations (from the store or
[18:57] <kyrofa> Argh
[18:58] <kyrofa> sergiusens, double-checking before I log a bug: https://bugs.launchpad.net/snappy/+bug/1461917 is fixed for `snappy install` invocations (from the store or sideloaded), but NOT for things installed via webdm
[18:58] <kyrofa> sergiusens, I thought those followed the same execution path through the snappy lib
[19:05] <sergiusens> kyrofa: right, but webdm would need to be rebuilt, so log a webdm bug ;)
[19:06] <kyrofa> sergiusens, I just added webdm as an also-effects. Is that okay?
[19:06] <sergiusens> yeah
[19:06] <kyrofa> sergiusens, ooooooh right... static linking....
[19:07] <kyrofa> sergiusens, man that takes a while to get your head around
[20:15] <pcoca> Hi everyone, I'm using snapcraft and using the ubuntu pluging I got error about files in common
[20:15] <pcoca> Is there any way to fix that problem?
[20:26] <ted> pcoca, They're probably trying to install the same thing, so for instance if you were using a python3-project and installed python-dev they'd conflict.
[20:27] <pcoca> ted: so, I should get rid of some of the packages
[20:27] <pcoca> ted: thanks!
[20:27] <pcoca> ted: Let's see if I can get the functionality getting rid of some packages :)
[20:27] <ted> Heh, you don't need packages! ;-)
[22:24] <pcoca> ted: Hi Ted, Still with the same issue, I'm not able to make a snapcraft out of a python script that requires opencv, I've tried several plugins python2-project, python3-project, ubuntu
[22:26] <pcoca> ted: I'm almost thinking about converting the python script to a deb, and then deb2snap, instead of snapcraft :)


[22:23] <DaveMorris> it's created with a patch
[22:24] <jdong> c!
[22:25]  * DaveMorris wonders if anyone has 3/4 hrs to review his package. http://revu.tauware.de/details.py?package=opensg
[22:25] <saivann> DaveMorris : Ok I found the patch, this patch creates the man file template at the root of the package?
[22:27] <emgent> lol
[22:27] <DaveMorris> yeah, I use cdbs patches,  to create it for me
[22:27] <DaveMorris> but you can do it different ways
[22:30] <saivann> DaveMorris : All I need to do to use that patch system is to respect names in the patches folder and add this to the rules file? : include /usr/share/cdbs/1/rules/simple-patchsys.mk
[22:32] <DaveMorris> saivann: best way is to 1.) create your man file and make sure it works. 2.) incldue the line you mention in rules. 3.) in the root of your package do "cdbs-edit-patch 01-add-simdock-manpage.patch" This will give you a clean source package to create your patch in. 4.) copy your manpage in and exit the patch shell ( ^D I think)
[22:33] <DaveMorris> this will give you your patch in debian/patches then
[22:33] <saivann> DaveMorris : Wow.. I don't get how the man template finally get in the /usr/share/man folder
[22:33] <DaveMorris> cdbs does it for you with the help of the .manpages file
[22:34] <saivann> DaveMorris : Ok thanks, I copied your instructions and I'll explore this. If you're here in more than 1 hour, perhaps that I'll finished my work on this
[22:34] <DaveMorris> I've got to go now, but I check it tomorrow at work.
[22:47] <RAOF> saivann: More explicitly, cdbs always calls dh_installman, which looks at debian/manpages
[22:48] <RAOF> saivann: CDBS is only magic in that it calls a whole bunch of debhelper (dh_foo) scripts for you automatically.
[22:51] <saivann> RAOF : Thanks for that informations :) I need to learn more about these.
[22:51] <saivann> DaveMorris : Thanks for all the help you gave to me today, I'll continue my work on this
[23:29] <LaserJock> what would -dh_strip do?
[23:29] <LaserJock> I've not seen putting a - before a dh_*
[23:29] <LaserJock> is it just disabling it?
[23:30] <persia> LaserJock: Makes rules not exit when stripping fails.  Shouldn't be there, or we don't see bugs in dh_strip.
[23:30] <LaserJock> hmmpf
[23:31] <LaserJock> well, wine had .debs about 3x larger than it used to
[23:31] <LaserJock> it looks to me like the debugging symbols aren't being stripped
[23:32] <LaserJock> I found that dh_strip was changed to -dh_strip
[23:32] <LaserJock> with the following changelog entry:
[23:32] <LaserJock> * debian/rules: ignore dh_strip errors to fix FTBFS in buildds
[23:33] <LaserJock> so does that mean dh_strip was erroring out hence not stripping all the binaries?
[23:33] <RAOF> Sounds like a plausible hypothesis.
[23:39] <RainCT> good night
[23:39] <mcisbackuk> Evening all! Quick question on packaging if there's anyone to answer?
[23:41] <RainCT> Hi mcisbackuk
[23:41] <RainCT> !ask > mcisbackuk
[23:41] <mcisbackuk> RainCT: Hi
[23:42] <RainCT> !ask | mcisbackuk
[23:42] <ubotu> mcisbackuk: Please don't ask to ask a question, ask the question (all on ONE line, so others can read and follow it easily). If anyone knows the answer they will most likely answer. :-)
[23:42]  * RainCT goes to bed.. good night :)
[23:43] <mcisbackuk> OK...I was packaging scummvm from the latest upstream release, the sources are packaged and there didn't seem to be any problems, just wanted to know if I've done it right....I created the diff and interdiff, and I've uploaded them both to Launchpad, bug #183976. Is there anything else that needs to go on there?
[23:43] <ubotu> Launchpad bug 183976 in scummvm "new upstream version 0.11" [Undecided,Confirmed] https://launchpad.net/bugs/183976
[23:44] <persia> mcisbackuk: That's a well formed upgrade bug.
[23:44] <mcisbackuk> persia: What's that mean?
[23:45] <persia> mcisbackuk: You have done what you need.  You are now waiting for a sponsor to review.
[23:46] <mcisbackuk> persia: Wow, I actually contributed! So there's no further steps for me until it's been reviewed? That's me happy :)
[23:49] <mcisbackuk> Well its thanks to you guys that I've learnt a few things to do with packaging, so for that thank you to the guys who helped its much appreciated :) Hope to be working with you all more often :)
[23:58] <rexbron> persia, I have been reading http://wiki.debian.org/RpathIssue and I believe that the current use of
[23:58] <rexbron> rpath in openlibs is acceptable
[23:59] <rexbron> as it is only between libraries in the same source package and they are installed to a non-standard directory


[01:04] <guiverc> A quick scan of https://ubuntu.com/kernel/lifecycle doesn't provide a means to install 20.04 & stay on GA kernel stack (HWE now the default)... anyone aware of a good link for 20.04 users wishing to stay on 5.4/GA stack (issues with 5.8 in support)
[01:13] <sarnold> guiverc: try: apt install linux-generic linux-generic-hwe-20.04-
[01:19] <guiverc> thanks sarnold... I don't have a box to test on (not for me, link intended for support comments).. a QA-test install of 20.04.2 daily yesterday still used 5.4 so HWE wasn't installed anyway.   Thank you
[01:31] <Bashing-om> guiverc: Ubuntu 20.04.1 LTS: https://ubuntu.com/download/desktop - need other ?
[01:36] <guiverc> something somewhere is causing users to bump to HWE I'm guessing post-install & ending up with 5.8 kernel already (last ~32 hours) & thus having issues.. Much of the wiki etc pages assume what was standard up to & including 18.04 (GA kernel default except for .2 & later media; no longer the case with 20.04/focal). Regardless 5.4 should still be default so users have switched to what lotus called edge/5.8.  I was after a link that allows
[01:36] <guiverc> them to switch a 20.04/focal install to GA kernel only.
[01:38] <Bashing-om> guiverc: Historically the .1 release has the GA kernel - that is not the case ?
[01:39] <guiverc> I've already used sarnold's suggestion in a comment. I was hoping for a URL.   No longer starting with 20.04 (default is now HWE, not GA)
[01:39] <guiverc> 20.04.2 hasn't hit streets yet,  so not obvious yet.
[01:40] <guiverc> Bashing-om, https://wiki.ubuntu.com/FocalFossa/ReleaseNotes  "Ubuntu Desktop flavour now always tracks HWE kernel (hardware enablement). It means that from 20.04.2 release Ubuntu Desktop will gain new major kernel versions every 6 months through to summer of 2022"
[01:40] <sarnold> oh nice
[01:40] <guiverc> these users however are still getting the HWE kernel early!
[01:43] <guiverc> Summer of 2022 is unfortunate wording.. summer down here in the deep-deep-south is december-..
[01:54] <Bashing-om> guiverc: Early is a bummer to me - 20.04 release: http://old-releases.ubuntu.com/releases/20.04/ .
[02:28] <Bashing-om> guiverc: Hummm ... HWE in focal is a fact - "sysop@2004x-c:~$ apt list linux-modules-extra-5.8.0-34-generic >> linux-modules-extra-5.8.0-34-generic/focal-security,focal-updates 5.8.0-34.37~20.04.2 amd64 ; sysop@2004x-c:~$ apt list linux-image-virtual-hwe-20.04-edge >> linux-image-virtual-hwe-20.04-edge/focal-security,focal-updates <IP_ADDRESS>.37~20.04.20 amd64" . As I live and learn.
[02:30] <guiverc> I'm on hirsute here, but none of my tested boxes yesterday detected it..   I'll look again on the box besides me when I can.  Thanks Bashing-om
[02:36] <Bashing-om> guiverc: Something amiss in 20.04 - 2 great testers report the same issue as you: https://ubuntuforums.org/showthread.php?t=2456225 .
[02:37] <guiverc> I've seen 9+ reports last ~32 hours..
[03:00] <lotuspsychje> good morning
[03:37] <Bashing-om> !info linux-image-virtual-hwe-20.04-edge focal
[03:37] <guiverc> Bashing-om, fyi: updated my 20.04 system, it's still on 5.4[.0-60]
[03:38] <Bashing-om> guiverc: If we have 5.4 originally and do not opt in for HWE we should remain on that GA kernel.
[03:40] <guiverc> yeah but as I pasted before from release notes "Ubuntu Desktop flavour now always tracks HWE kernel (hardware enablement)"   which to me meant early Feb-21 (feb 11 is scheduled 20.04.2 from memory)
[03:40] <Bashing-om> guiverc: Hummm ,,, Hummm .. my focal fully updated: 5.4.0-59-generic.
[03:40] <lotuspsychje> Bashing-om: before these bugs, there was HWE edge available for 20.04 i used it to fix a 5.4 bug to goto 5.8
[03:41] <guiverc> 5.4.0-60[.67] (.67 package. -60 only installed) but only just installed
[03:41] <Bashing-om> lotuspsychje: But that was an optin on your part .. updates are going HWE without permission !
[03:41] <lotuspsychje> yeah so i notice
[03:45] <Bashing-om> !info linux-image-generic-hwe-20.04
[03:46] <Bashing-om> ^^ We need a bot fix. "sysop@2004x-c:~$ apt list linux-image-generic-hwe-20.04 >> linux-image-generic-hwe-20.04/focal-security,focal-updates <IP_ADDRESS>.37~20.04.20 amd64".
[05:58] <ducasse> good morning
[07:49] <lordievader> Good morning
[12:53] <lotuspsychje> added bug #1910555 to the discuss team, this bug can be used to dupe all the recent 5.8 broadcom bugs to
[15:42] <jeremy31> So why are 20.04 users being updated to 5.8 when that used to be just an option
[15:52] <leftyfb> jeremy31: do you have linux-generic-hwe-20.04  installed?
[16:03] <Maik> jeremy31: it's a ongoing thing isn't it? I still have 5.4.0-60 on my Ubuntu MATE 20.04.1 install. No 5.8 in sight
[17:27] <oerheks> they all have HWE installed, and refuse to mention it.. or
[17:27] <oerheks> 20.04.1 fresh install gets the HWE kernel automaticly, like 18.04.1 did
[17:28] <oerheks> but no post saying this https://wiki.ubuntu.com/FocalFossa/ReleaseNotes/ChangeSummary/20.04.1
[17:32] <Maik> https://wiki.ubuntu.com/Kernel/LTSEnablementStack#Ubuntu_20_LTS_-_Focal_Fossa
[17:32] <Maik> "The 20.04.2 and newer point releases will ship with an updated kernel and X stack by default for the desktop. Server installations will default to the GA kernel and provide the enablement kernel as optional. "
[17:37] <oerheks> ah good spot
[17:38] <Maik> :)
[17:39] <oerheks> sudo apt autoremove
[17:42] <oerheks> hmm .. "sudo apt-get install --install-recommends linux-generic-hwe-20.04 xserver-xorg-hwe-20.04" does not find any package..
[17:43] <oerheks>  linux-generic-hwe-20.04 is there, xserver-xorg-hwe-20.04 missing
[18:10] <daftykins> Maik's quote isn't news, it's been like that forever
[19:08] <jeremy31> leftyfb:  I think the hwe was installed by user ubuntu during the install
[19:16] <jeremy31> I might have to install 20.04 again without internet and see what it does when I update
[19:47] <oerheks> ah a clue; Livepatch pushed OS update 5.8.0-34
[19:47] <oerheks> see #u
[19:50] <Maik> does kubuntu 20.04 support Livepatch?
[19:51] <Maik> most complaints came from those users
[19:51] <daftykins> it's not flavour specific
[19:51] <Maik> even KDE Neon users reported it so i don't think it has anything to do with the Livepatch
[19:52] <daftykins> eh, why do you feel that excludes it? that's available via PPA for kubuntu no?
[19:52] <daftykins> maybe not even PPA, but available


[02:58] <lotuspsychje> good morning
[06:37] <marcoagpinto> Heya!
[07:32] <ducasse> good morning
[11:30] <StupidDanbo> maybe I should look into different desktop environments.
[11:30] <lotuspsychje> !flavours
[11:31] <TimothyP> What do you want to do with your computer and how old is the hardware
[11:32] <StupidDanbo> I do a mix of stuff. but mostly I game in Wine, watch streaming video, and browse the internet collecting pictures.
[11:32] <StupidDanbo> I dunno how old my hardware is.
[11:33] <TimothyP> Then you're probably good with Xubuntu, light on the hardware and suitable for everything you do
[11:33] <StupidDanbo> I think only a few years. when did I replace most of it...
[11:33] <lotuspsychje> inxi -F StupidDanbo
[11:34] <TimothyP> lotusspy what voodoo magic are you invoking ?
[11:34] <lotuspsychje> hardware lookup
[11:34] <TimothyP> wow
[11:34] <StupidDanbo> WAT. why did inxi -F say I have a laptop?
[11:34] <TimothyP> ah
[11:34] <TimothyP> ok I thought it was a command for irc here
[11:34] <TimothyP> lol
[11:36] <StupidDanbo> AMD Ryzen 5 1600. 16GB of RAM? GeForce GTX 1060
[11:37] <TimothyP> hah ! you can run anything :D
[11:38] <StupidDanbo> haha yeah. *stuttering randomly when playing WoW in Wine while watching a video on 2nd monitor*
[11:39] <TimothyP> if you have enough desktop space you can simply apt install ubuntu-desktop plasma-desktop etc... and try multiple desktop environments
[11:39] <StupidDanbo> I wonder if it's because one monitor is plugged in using the older cable with the rows of pins.
[11:39] <TimothyP> I usually stick with Steam for games (handles wine etc... in the background)
[11:40] <TimothyP> 1k, 2k or 4k your screens? the 1060 can be a bit slugish with 2 4k screens and 3d + video ( have the same card)
[11:40] <StupidDanbo> I'm using DVI on one monitor and uh.... DisplayPort? on the other.
[11:41] <StupidDanbo> nothing that big. just 1920x1200 + 1920x1080
[11:41] <TimothyP> vlc?
[11:41] <StupidDanbo> for video? no, streaming video. either Twitch or YouTube
[11:42] <TimothyP> ah
[11:42] <TimothyP> maybe the browser and wow are both fighting for your gpu
[11:42] <StupidDanbo> Yeah. What's strange is that WoW reports over 60fps while I'm clearly NOT having 60fps
[11:42] <TimothyP> perhaps average?
[11:42] <StupidDanbo> nope
[11:42] <TimothyP> altough that would go up and down
[11:43] <StupidDanbo> not when it stutters for a bunch of seconds
[11:43] <TimothyP> ow that's a lot
[11:43] <StupidDanbo> yeah it seems to go away after a while, and it's not often but... annoying enough.
[11:43] <TimothyP> when it does you should check memory usage, cpu usage and gpu usage
[11:43] <TimothyP> maybe that can tell you where the bottleneck is
[11:44] <StupidDanbo> I think I've opened task manager before and not noticed anything. but I don't know how to check my GPU usage
[11:44] <TimothyP> you should have the NVDIA X Server Settings app
[11:45] <TimothyP> that one  can show a lot of gpu info
[11:45] <StupidDanbo> oh. so I do.
[11:46] <TimothyP> and in the terminal
[11:46] <TimothyP> nvidia-smi
[11:46] <TimothyP> watch -1 nvidia-smi
[11:47] <TimothyP> that will show you which process is using it and how much
[11:47] <StupidDanbo> invalid option
[11:47] <TimothyP> sorry
[11:47] <TimothyP> watch -n 1 nvidia-smi
[11:48] <TimothyP> afk for a while
[11:49] <StupidDanbo> Interesting. ah now I can see more info on one page.
[20:14] <Bashing-om> UWN: Issue 672 is on the streets: https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Issue672 :D
[21:45] <oerheks> happy monday, Bashing-om


[05:54] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2914 Needs rebuild due to higher version at destination
[07:55] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2917 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
[08:17] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2917 Diff missing
[14:26] -queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2916 Generating diffs
[14:28] -queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2916 Failed to build (artful/gnome-shell). Successfully built (artful/budgie-desktop, artful/gnome-shell-extensions, artful/mutter)
[16:02] -queuebot:#ubuntu-ci-eng- tsimonq2 mitya57 locutusofborg, https://bileto.ubuntu.com/#/ticket/2819 Needs rebuild due to higher version at destination (artful/akonadi, artful/frameworkintegration, artful/kdeclarative, artful/kguiaddons, artful/kwayland, artful/kwin, artful/libqtxdg, artful/lxqt-session, artful/musescore, artful/openorienteering-mapper, artful/plasma-integration, artful/pyqt5, artful/qt3d-opensource-src, artful/qtcharts-opensource-src, artful/qtconnectivit
[16:17] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2917 UNAPPROVED queue
[17:01] -queuebot:#ubuntu-ci-eng- tsimonq2 mitya57 locutusofborg, https://bileto.ubuntu.com/#/ticket/2819 Needs rebuild due to higher version at destination (artful/akonadi, artful/frameworkintegration, artful/kdeclarative, artful/kguiaddons, artful/kwayland, artful/kwin, artful/libqtxdg, artful/lxqt-session, artful/musescore, artful/openorienteering-mapper, artful/plasma-integration, artful/pyqt5, artful/qt3d-opensource-src, artful/qtcharts-opensource-src, artful/qtconnectivit
[17:09] -queuebot:#ubuntu-ci-eng- tsimonq2 mitya57 locutusofborg, https://bileto.ubuntu.com/#/ticket/2819 Preparing packages
[17:22] -queuebot:#ubuntu-ci-eng- tsimonq2 mitya57 locutusofborg, https://bileto.ubuntu.com/#/ticket/2819 Diff missing (artful/gsettings-qt). Needs rebuild due to higher version at destination (artful/akonadi, artful/frameworkintegration, artful/kdeclarative, artful/kguiaddons, artful/kwayland, artful/kwin, artful/libqtxdg, artful/lxqt-session, artful/musescore, artful/openorienteering-mapper, artful/plasma-integration, artful/pyqt5, artful/qt3d-opensource-src, artful/qtcharts-
[17:42] -queuebot:#ubuntu-ci-eng- tsimonq2 mitya57 locutusofborg, https://bileto.ubuntu.com/#/ticket/2819 Needs rebuild due to higher version at destination (artful/akonadi, artful/frameworkintegration, artful/kdeclarative, artful/kguiaddons, artful/kwayland, artful/kwin, artful/libqtxdg, artful/lxqt-session, artful/musescore, artful/openorienteering-mapper, artful/plasma-integration, artful/pyqt5, artful/qt3d-opensource-src, artful/qtcharts-opensource-src, artful/qtconnectivit


[03:23] <NoCode> Hi. Few questions about the bot. Anyone around?
[03:28] <benonsoftware> NoCode: What questions do you have?
[03:28] <NoCode> I'm wondering what has been enabled to use pipe commands.
[03:31] <benonsoftware> NoCode: I would assume that it's the Encyclopedia plugin is what you want to look into.
[03:31] <NoCode> "!test | NoCode" for example. So with such a command, the bot would reply the factoid back to the user. "Ubottu: Success!" The factoid being, "!test is <reply> Success!".
[03:31] <Unit193> It's a factoid bot.
[03:32] <NoCode> !COC | NoCode
[03:34] <NoCode> I remember years ago there were two different types of pipes. | would provide the factoid to the user whereas > would reply to the user *in* query.
[03:39] <benonsoftware> NoCode: If you're looking for the code for it, http://bazaar.launchpad.net/~ubuntu-bots/ubuntu-bots/devel/files/head:/Encyclopedia/ is where it lies.
[03:43] <NoCode> benonsoftware, Thanks a lot. I'll look into that.
[03:52] <NoCode> Anyway, thanks a lot. Tell Topyli I said Hi. (it's J-_) I kinda miss that dude. Cheers.
[04:06] <Unit193> It does, '|' addresses whereas '>' PMs.


[03:43] <hackfu> Hello
[18:55] <hackfu> Good morning.
[19:40] <FunnyLookinHat> Yo
[20:18] <joey> hackfu the dragon
[20:29] <hackfu> :D
[20:29] <hackfu> How is it going joey & co?
[20:29] <joey> well thanks, you?


[10:50] <PaulW2U> pleia2: issue #492, last one of the year?
[15:59] <pleia2> PaulW2U: good idea, we'll go ahead and plan on that
[16:59] <pleia2> PaulW2U: hm, now that I'm looking at it, I'm wondering if we should do 492 and 493 will be the one covering xmas and new years weeks, but we'll see how things look on friday
[16:59] <pleia2> otherwise we either release the day after xmas, or have an edition covering 3 weeks (eek)
[17:08] <PaulW2U> pleia2: I think release 492 on 19th and then 493 on 2nd would be best but if there's not much happening this week then as you say it can be decided on Friday
[17:09]  * pleia2 thumbs up
[17:16] <pleia2> we should also think about what we want to do for issue 500
[17:17] <pleia2> I'm sending a mail to the list momentarily
[17:37]  * PaulW2U thinks a competition, prizes  :)
[18:06] <pleia2> I'm happy to gather and send out said prizes (probably ask Ubuntu community fund for a few bucks) if you have ideas as to what kind of competition to do :)
[18:19] <PaulW2U> I'm thinking along the lines of 10 questions about UWN itself. Might also encourage some new contributors.
[18:39] <pleia2> wfm
[19:39] <PaulW2U> I'll let you havr some questions
[19:39] <PaulW2U> over the coming weeks
[19:43] <pleia2> ty