[16:31] <superm1> xivulon, <tgm4883_laptop> superm1, can you find the dir that wubi looks in? .... <tgm4883_laptop> is it release/ or releases/
[17:01] <xivulon> superm1 1s
[17:03] <xivulon> superm1: metalink=http://www.mythbuntu.org/releases/mythbuntu-8.10-desktop-i386.metalink
[17:03] <superm1> xivulon, okay thanks
[17:35] <CIA-2> ubiquity: evand * r2936 ubiquity/ (debian/changelog scripts/install.py):
[17:35] <CIA-2> ubiquity: Save an apt.cache.Cache() so we retain the package information on
[17:35] <CIA-2> ubiquity: restricted packages even after removing restricted from the
[17:35] <CIA-2> ubiquity: sources.list (LP: #290925).
[23:44] <CarlFK> how do I install the most recient 2.26 kernel?
[23:45] <CarlFK> on never mind.  the driver I am looking at is compiled against an FC kernel


[00:02] <zul>  /msg kees wth with the mod_cache stuff?
[00:03] <kees> :)
[00:03] <kees> I need to sort it out with slangasek
[00:03] <kees> zul: ^^
[00:18] <emgent> heya
[01:54] <moosepants> Hi guys. I see someone has published Subversion 1.5 for Intrepid. I downloaded the source this morning and built it for Hardy.  Should I bother?
[01:55] <moosepants> source package etc that is
[02:00] <zul> moosepants: you can place it in your ppa if you wish
[02:00] <moosepants> zul: Yes might do that, at least for the guys here at work anyway
[02:48] <pwnguin> hey, if i see a change log that goes (in increasing chronological order) unstable, feisty, unstable, feisty, does that mean debian pulled from ubuntu?
[02:52] <ScottK> pwnguin: No.  It means it's been merged from Debian multiple times.
[02:53] <pwnguin> ok
[02:54] <ScottK> If you want to see a package where Debian pulled from Ubuntu, look at klamav.
[02:54] <ScottK> You won't be suprised when you see who did it.
[02:55] <pwnguin> klam or clam?
[02:55] <ScottK> klam
[02:55] <pwnguin> i see
[02:58] <moosepants> Hi, perhaps someone here can help. I downloaded a package source for Intrepid, and pbuilt it under Hardy. I have discovered a problem now, and would like to build it against a different library
[02:59] <moosepants> The source.orig doesn't have the /debian directory, so do I edit the .dsc file?
[02:59] <moosepants> or can debuild create the /debian from the dsc?
[03:02] <Laney> moosepants: You can use dpkg -x <.dsc file> to unpack the source package.
[03:04] <moosepants> Laney: Thanks, I'll give it a whirl
[03:06] <arvind_khadri> hi...i wanted to know that how do we create a *.deb out of say a text editor code written in C
[03:07] <moosepants> Laney: Sorry, I think I already have the contents of the source package - the source.orig.tar.gz, the source.dsc and source.diff.gz file. However, the source.orig.tar.gz file doesn't contain a /debian directory. I presume the debuild process creates the .dsc from the /debian directory - I want to do the reverse
[03:07] <Laney> moosepants: The diff.gz will contain the debian changes.
[03:08] <Laney> So if you unpack the source package using the command I gave you then you'll get a package-version directory which will have a debian/ subdirectory that you can edit
[03:08] <ScottK> moosepants: dpkg-source -x FILENAME.dsc will unpack the source package with the debian dir in it.
[03:08] <ScottK> Laney: It is dpkg-source though, not dpkg.
[03:08] <Laney> ScottK: Yes, of course.
[03:09] <RAOF> arvind_khadri: By making a source package based on the C source code.  You probably want to check out the PackagingGuide.
[03:09] <moosepants> ScottK, Laney: Thanks, I'll give this a go and see how I fare. Cheers
[03:09] <ScottK> Cheers.
[03:09] <arvind_khadri> RAOF thanks...can you please direct me there
[03:10] <RAOF> arvind_khadri: https://help.ubuntu.com/6.10/ubuntu/packagingguide/C/index.html
[03:11] <arvind_khadri> RAOF, thanks a lot
[03:11] <RAOF> There may be a newer version; that was just the first one I stumbled upon when browsing wiki.ubuntu.com/MOTU
[03:11] <arvind_khadri> RAOF, oh ok...i would check out for the new version
[03:12] <ScottK> RAOF and arvind_khadri: https://wiki.ubuntu.com/PackagingGuide
[03:12] <ScottK> That's the most current.
[03:13] <arvind_khadri> ScottK, thanks to you too
[03:20] <moosepants> ScottK: After changing the library in the control, rebuilding the dsc and trying to pbuild it again I get a unmet dependency because the library I have changed to is a virtual package.  Why is this failing?
[03:20] <ScottK> What library?
[03:22] <moosepants> ScottK: libneon26-gnutls-dev (the package source I originally grabbed from Intrepid uses libneon27-gnutls-dev, and am backporting to Hardy). The package is Subversion, and I have seen a bug (that I am experiencing also) that is likely caused by libneon27-gnutls
[03:22] <arvind_khadri> is it necessary that we have a make file in *.deb too...it is only meant for the *.tar right??
[03:23] <ScottK> arvind_khadri: It's not needed unless you can't use the upstream one.
[03:23] <ScottK> moosepants: What is the exact error you get?
[03:24] <persia> arvind_khadri: debian/rules is traditionally a Makefile, which often makes an additional Makefile unnecessary.
[03:24] <ScottK> IIRC it's required by policy to be a make file.
[03:25] <arvind_khadri> persia, oh ok...
[03:25] <moosepants> ScottK: Well I run pbuild and it does the thing where it grabs the deps. And I get the line "E: pbuilder-satisfydepends failed." before it cleans up and exits. Further up I read "The following packages have unmet dependencies:  pbuilder-satisfydepends-dummy: Depends: libneon26-gnutls-dev which is a virtual package."
[03:26] <moosepants> I can epaste it (or whatever its called if you like... ?)
[03:26] <persia> ScottK: Thanks.  I've seen packages with different interpreters, but hadn't realised those were policy violations.
[03:26] <ScottK> Pastebin.
[03:26] <moosepants> ScottK: ;)
[03:26] <ScottK> persia: There are a few of those.  I can't remember for sure if it is policy or it will soon be policy.
[03:27] <ScottK> !pastebin | moosepants
[03:27] <persia> ScottK: It's listed as "must" in 3.8.0.
[03:27] <ScottK> OK.
[03:27] <ScottK> There we have it.
[03:27]  * persia hasn't checked diffs to determine when it became policy
[03:28] <moosepants> ScottK: http://paste.ubuntu.com/22762/
[03:28]  * ScottK wrote his first README.source this week.
[03:28] <ScottK> The short version is see man cdbs-edit-patch.
[03:28]  * ScottK looks
[03:29] <ScottK> moosepants: My recommendation is modify your pbuilder to use the 'classic' version of satisfydepends.
[03:29] <moosepants> ScottK: Thanks, I'll look into it (I only started using it yesterday =] )
[03:30] <ScottK> Look in /etc/pbuilderrc
[03:30] <crimsun_> libneon26-gnutls-dev is in universe.
[03:30] <ScottK> Ah.  moosepants Is universe enabled on your pbuilder?
[03:30] <moosepants> ScottK: Ah.. probably not. I'll have a look in the rc file
[03:31] <ScottK> crimsun_ may have it figured out better than I do.  I'd look at that first.
[03:35]  * ScottK wonders why "Launchpad Design and Usability Engineer" is listed as an Ubuntu job?
[03:37] <pwnguin> because canonical is special, duh.
[03:38] <moosepants> ScottK, crimsun_: After uncommenting the line that specifies the components, and do a pbuilder update, it still only pulls from main. Do I have to do a complete pbuilder create again?
[03:39] <ScottK> No.
[03:39] <crimsun_> update --override-config
[05:01] <nxvl> when are revu days?
[05:02] <nxvl> are there some programmed already?
[05:02] <persia> nxvl: They were once announced for every wednesday, but nobody has been leading them.
[05:05] <persia> nxvl: This being wednesday somewhere, you might advertise your package, and see if anyone comments.
[05:10] <nxvl> persia: i have, on the server-team list
[05:10] <nxvl> :D
[05:11] <ajmitch> then hope that the small overlap of people will look at your package
[05:12] <nxvl> yep
[05:12] <nxvl> also they talked about it in today's server meeting
[05:13]  * ajmitch decided to miss that meeting
[05:20] <persia> nxvl: Asking here is more likely to target a MOTU to review, unless it's server-team specific :)
[05:26] <Hobbsee> ScottK: it's because canonical have a wish to hire inside the ubuntu community, if they can.
[05:27]  * ScottK doesn't think it's accurate to describe it as an Ubuntu job.
[05:28] <persia> That page is frustrating for all sorts of reasons.
[05:29] <persia> I liked it better when there was another position posted, but it went away.
[05:29] <ajmitch> hello Hobbsee
[05:30] <Hobbsee> heya ajmitch
[05:30] <ajmitch> talking about the LP jobs?
[05:30] <Hobbsee> yeah
[06:30] <dholbach> good morning
[06:35] <nxvl> dholbach: good $TZ_TIME_OF_DAY
[06:35] <nxvl> dholbach: i was waiting for you
[06:35] <nxvl> dholbach: i replied to you on revu
[06:35] <nxvl> dholbach: the amd64 error seems to be a weird/random error
[06:36] <dholbach> nxvl: aha?
[06:36] <wgrant> It's not OOo, so it can't have weird/random errors!
[06:36] <nxvl> dholbach: i have build augeas on my ppa and it build for amd64
[06:37] <dholbach> nxvl: alright - I'll take a look later on
[06:38] <nxvl> dholbach: i also made some changes early today (in this tz) and uploaded again, maybe it fixes the build error
[06:38] <nxvl> but, how did you build it? pbuilder or just debuild
[06:38] <nxvl> ?
[06:38] <dholbach> pbuilder
[06:39] <nxvl> mm
[06:39] <nxvl> weird
[07:11] <wgrant> jpds: Are you planning to have Bugzilla 3.0.4 synced from Debian? It's there now.
[07:30] <kirkland> dholbach: hi there, would you have time to review a package merge of mine, and sponsor an upload?
[07:31] <kirkland> (or anyone else for that matter...)
[07:32] <kirkland> http://people.ubuntu.com/~kirkland/audacious/
[07:32] <kirkland> ^ audacious merged for intrepid
[07:33] <kirkland> tjaalton: hey, it looks like you were the last one to upload, perhaps you might reivew?
[07:33] <persia> kirkland: It still needs a merge?  I thought nenolod had put together the necessary distribution detection in the build system.
[07:34] <kirkland> persia: http://merges.ubuntu.com/a/audacious/REPORT
[07:34] <persia> nenolod: ?
[07:34] <nenolod> i haven't had an opportunity yet.
[07:34] <nenolod> it'll be in 1.5.2.
[07:35] <persia> nenolod: Is that likely in a few weeks, or should we merge again for now?
[07:35] <nenolod> i'd merge, cause 1.5.2 does not have a set release date yet.
[07:35] <nenolod> we're looking at mid-july probably.
[07:36] <persia> nenolod: Makes sense.  Thanks.
[07:37] <dholbach> kirkland: would you mind following  http://wiki.ubuntu.com/SponsorshipProcess ? I'm doing a bunch of sponsoring right now and I'd process it in the queue (or somebody else if I'm too slow) :)
[07:37] <kirkland> dholbach: oh, sure, no problemo!
[07:38] <dholbach> rock on!
[07:42] <wgrant> Hmm, I find it interesting that (on LP) canonical-server's emblem is ubuntu-server's emblem but with an Ubuntu logo on top.
[07:42] <kirkland> nenolod: persia: any chance one of you can review/upload?  I have filed a bug in LP: https://bugs.edge.launchpad.net/ubuntu/+source/audacious/+bug/242841
[07:42] <ubott2> Launchpad bug 242841 in audacious "please merge audacious_1.5.1-1" [Undecided,New]
[07:45] <persia> kirkland: neither of us has permission to upload that :)
[07:45] <kirkland> ah, okay, no worries
[07:46] <persia> Wait, it's in universe?  I thought it was in main.
[07:46] <kirkland> i should call it a night anyway
[07:46] <kirkland> persia: yeah, universe
[07:46] <persia> kirkland: I'll look at it later then.
[07:47] <nenolod> the merge is fine
[07:47] <nenolod> bbl
[07:57]  * dholbach takes a look at libjibx-java
[08:10] <wgrant> ScottK: Bug #217256 has CVE-2008-183[5-7] associated with it, but I can't see any relevance. Can you please confirm their status?
[08:10] <ubott2> Launchpad bug 217256 in clamav "ClamAV Upack Processing Buffer Overflow Vulnerability" [Medium,Fix released] https://launchpad.net/bugs/217256
[08:20] <pwnguin> gah i hate the forums
[08:21] <pwnguin> there's a bug report in a closed forum that's valid; i'd like to add a reply to tell him to subscribe in LP, but it's closed so no comments =(
[08:43] <persia> wgrant: Would you mind reminding me of the incantation to allow Java to work in a build chroot?  I'm not finding your several prior repetitions in my logs.  I promise to write it down somewhere useful this time :)
[08:46] <slytherin> persia: Just got your mail. Is the time for meeting in UTC?
[08:47] <persia> slytherin: Yes.  You may also want to join #ubuntu-java, which seems to have a little more traffic now, although still not much.
[08:55] <wgrant> persia: echo "buildd shared/accepted-sun-dlj-v1-1 boolean true" | debconf-set-selections
[08:55] <wgrant> That's what I've found from my logs, though there might be something else - I'll check the rebuildd chroots.
[08:57] <persia> wgrant: Thank you very much.
[08:57] <wgrant> That seems to be all.
[08:58] <directhex> i think the opensuse build service has a package to set that setting as part of their debbuntu buildds
[08:59] <wgrant> Hopefully it will be unnecessary soon, anyway.
[09:29] <jpds> wgrant: yes, I know, I haven't had time to file the request tho..
[09:30] <wgrant> jpds: Thanks.
[09:30] <pwnguin> wgrant: ive a question about xournal -- have we really not merged with debian since feisty?
[09:30] <wgrant> Just wondering, as it has its share of CVEs.
[09:31] <wgrant> pwnguin: We have new upstream releases, but have not merged with Debian.
[09:31] <wgrant> And I'm not TIL any more, so...
[09:31] <pwnguin> right, but you started it ;)
[09:32] <pwnguin> we're fine
[09:32] <wgrant> I did introduce a new upstream release, but merged with Debian soon after.
[09:32] <pwnguin> i just wanted to make sure i wasnt crazy
[09:32] <wgrant> Has there been anything to merge?
[09:32] <pwnguin> doubt it
[09:33] <wgrant> It seems odd that we've had two well-spaced uploads by different people, but no merges.
[09:33] <pwnguin> the latest debian upload happened in  june 3rd
[09:33] <pwnguin> as an NMU
[09:33] <wgrant> Aha.
[09:33] <wgrant> New upstream release?
[09:34] <wgrant> (sorry, eating at the moment, so can't really check much)
[09:34] <pwnguin> basically they're catching up with ubuntu ;)
[09:34] <wgrant> We're ahead in something? That'd be a first.
[09:34] <pwnguin> well
[09:34] <pwnguin> i was reluctant about it, but we've got precedent and a really angry upstream
[09:35] <wgrant> Oh, did you NMU it?
[09:35] <pwnguin> nope
[09:35] <wgrant> Or angry about us?
[09:35] <pwnguin> angry about us
[09:35] <wgrant> With our X changes?
[09:35] <pwnguin> for not shipping a new version in hardy
[09:35] <wgrant> Did they bother to tell us pre-release?
[09:35] <pwnguin> nope
[09:36] <wgrant> Then they should run off and complain to themselves.
[09:36] <pwnguin> heh
[09:36] <pwnguin> i might ask in a week or so if there's any plans
[09:36] <pwnguin> for intrepid
[09:37] <wgrant> We can't actually feasibly monitor 12000 upstreams, I'm sorry.
[09:37] <pwnguin> but they're really not what you'd call a reliable upstream release engineer
[09:37] <wgrant> Heh.
[09:37] <pwnguin> two releases in the past year shipped with point releases days later because of terrible bugs
[09:38] <pwnguin> with simple fixes at least
[09:38] <wgrant> If they want to interact with Launchpad and get somebody on their side to upload it, that might be good.
[09:38] <pwnguin> im reluctant to suggest to an MIT math professor and fedora user that they should switch to a closed source LP
[09:39] <pwnguin> what does this "interact with launchpad" entail for them?
[09:39] <DktrKranz> Does anybody know if there's a list of compatible hardware for Ubuntu Mobile Edition?
[09:39] <wgrant> File bugs if they notice issues with the Ubuntu package, I guess.
[09:39] <wgrant> persia: ^^?
[09:40] <pwnguin> theres tons of bug reports in the xournal sourceforge related to ubuntu, but mostly it looks like its because we're the only usable group around ^_^
[09:40] <pwnguin> DktrKranz: you'll know its compatible because it was sold to you preinstalled, I'd say
[09:40] <wgrant> Does his pet distro not have it?
[09:41] <wgrant> pwnguin: I know persia runs it on some strange hardware.
[09:44] <pwnguin> wgrant: xournal appears to only be available in fedora 7
[09:44] <pwnguin> but maybe im reading their website wrong
[09:46] <wgrant> Aren't we up to Fedora 9?
[09:46] <directhex> yes
[09:46] <pwnguin> i think so?
[09:46] <wgrant> Oh, Fedora 7 and only 7?
[09:47] <directhex> nice to see fedora's met its goal of having a proper ps3 version by fedora 7
[09:47] <directhex> (/sarcasm)
[09:47] <directhex> of course, ubuntu's now officially junk on that front, so glass houses & all that
[09:47] <wgrant> directhex: I believe that kernel fixes are on the way, though they won't make 8.04.1.
[09:48] <pwnguin> how do you upgrade a kernel fix when it wont boot?
[09:48] <pwnguin> dist-upgrade from 7.10?
[09:48] <wgrant> pwnguin: By waiting for 8.04.2 or a specially-rolled PS3 image, I would suggest.
[09:48] <directhex> wgrant, perhaps one day the ps3 will be a second class citizen, rather than third class
[09:49] <wgrant> directhex: Or perhaps people should be using proper PCs.
[09:49] <wgrant> And leaving gaming consoles to be gaming consoles.
[09:49] <pwnguin> directhex: wake me up when ubuntu runs on the wii :P
[09:50] <pwnguin> till then, go bug BenC, since he's the one who's using a PS3 as a video player
[09:51] <slytherin> how are the ps3 kernel images compiled?
[09:52] <wgrant> Same way as the rest, no?
[09:52] <pwnguin> one bit at a time?
[09:52] <pwnguin> or maybe byte
[09:52] <pwnguin> it should just be a ppc image
[09:53] <pwnguin> its not like you get great access to the awesome hardware underneath
[09:54] <directhex> you get some cell access, which makes for an interesting tinker toyu
[09:54] <Hobbsee> directhex: of course, this is the advantage in not having totally-volunteer based stuff, instead of only mostly-volunteer based stuff.
[09:54] <Hobbsee> directhex: still, you can be one of the ones who is personally responsible for it, if you want it
[09:55] <Hobbsee> there's another guy already doing stuff with it, and has been in #ubuntu-devel over the past few weeks about it, iirc.
[09:56] <directhex> i lack the required kernel wrangling knowledge
[09:56] <Hobbsee> then get it.
[09:56] <Hobbsee> armchair wishing, while it might be fun, really doesn't get you anywhere.
[09:57]  * Hobbsee is sure there's documentation around, if you're determined enough to find it.
[09:57]  * ajmitch wanders in, sees a whole lot of complaining, wanders out again
[09:58]  * wgrant complains about ajmitch's hasty exit.
[09:58] <Hobbsee> but, y'know, clearly it's unfair that a volunteer hasn't put in the time and effort to do what you want to see done...
[09:58] <pwnguin> which volunteer?
[09:59] <pwnguin> its just a slight bit unfair when colin and ben start something and walk away. but not enough to trigger my sympathy gland :)
[10:00] <Hobbsee> pwnguin: i thought it started with an X.
[10:01] <pwnguin> i dont follow
[10:01] <Hobbsee> pwnguin: yeah.  likewise, it's unfair when any person stops writing a program or functionality that I want.  Or don't start writing it in the first place.
[10:01] <Hobbsee> pwnguin: oh, right.  any volunteer.
[10:01] <Hobbsee> the guy who keeps being in -devel about it starts with an x, iirc.
[10:01] <pwnguin> Hobbsee: well, there's this bit nobody rembers about the CoC
[10:02] <Hobbsee> pwnguin: stepping down responsibly means not getting rid of mission criticla systems.
[10:02] <pwnguin> where it says step down gracefuly. i'd argue that looking for replacements is part of that
[10:02] <Hobbsee> and such
[10:03] <directhex> there's work, and there's banging your head against a brick wall. using the fedora example, patches to get the distro working "out of the box" have been festering in the fedora bugzilla for over a year, but those who can implement the back-end changes required are disinterested in doing so
[10:03] <directhex> at any rate, moaning about ps3 linux feels FAR more productive than fighting with kerberos on mac right now.
[10:03] <pwnguin> but this is a bit unfair. colin did notify everyone that he was stepping down, to my recollection
[10:03] <Hobbsee> so, what you're syaing is that anyone who develops something, and has it in ubuntu, is required to provide support for it indefinetly, and to give users other possibilities for it, indefinetly, no matter when the last time they did something on it was.
[10:04] <Hobbsee> i'm afraid i can't agree with your interpretation of the CoC then.
[10:04] <pwnguin> yes, you've perfectly summarized my sentence with a paragraph
[10:04] <Hobbsee> the GPL doesn't even require that, to my knowledge.
[10:05] <pwnguin> i dont know enough about the ps3 situation to really place any blame for the state of the community (or lack thereof)
[10:05] <pwnguin> being that i lack 600 dollars
[10:06]  * Hobbsee wonders how many of the ubuntu developers are prepared to support anything they write, for the rest of their earthly lives.
[10:06] <pwnguin> i never said that, you did :P
[10:06] <StevenK> pwnguin: Right, so I wrote Linda, a package checker, and it was in Ubuntu. It's since been removed, but if you want to use it, you'll ask me for support because I wrote it?
[10:06] <Hobbsee> as a summary of your statement, yes.  Which you then agreed with.
[10:07] <pwnguin> theres no reason to get snippy; apparently i misplaced a </sarcasm> tag
[10:08] <directhex> it's the "if it doesn't work for you, fix it or bugger off" snippiness. i use it all the time in #mythtv-users
[10:08] <pwnguin> directhex: no its "sarcasm reads like idiocy online" snippiness
[10:09] <directhex> i assume everything i read is idiocy. especially on docs.info.apple.com
[10:09] <pwnguin> well thanks.
[10:11] <pwnguin> anyways, im of the general put up or shut up scenario with a community supported ps3 image. colin's a smart person, i imagine he made it clear how things stood when he started it and how things stood when he left
[10:11] <Hobbsee> pwnguin: interesting that you class things as snipy and as sarcasm, when people naturally pull apart your claims.
[10:11] <pwnguin> ^ that is missing some thougt
[10:11] <Hobbsee> gives you a great way of not expanding your views at all.
[10:11] <Hobbsee> s/expanding/supporting/
[11:04] <sebner> damn wlan -.-
[11:08] <james_w> persia: hi, are you still ok for tomorrow?
[11:08] <sebner> \sh: you seem to have great fun with Leonov, hmm :)
[11:17] <sebner> dholbach: linkchecker fixed and uploaded. \o/
[11:18] <dholbach> sebner: I uploaded it :)
[11:18] <sebner> dholbach: ha! nice. I never know if nobody comments. and I couldn't find a changes_file
[11:20] <sebner> dholbach: anyway. dirty but working :D
[11:21] <dholbach> no, that's fine
[11:21] <sebner> dholbach: but strange since in Debian it doesn't FTBFS but also there it should :\
[11:40] <sistpoty|work> hi folks
[11:40] <james_w> hi sistpoty|work
[11:40] <sistpoty|work> hi james_w
[11:42] <sebner> huhu sistpoty|work :)
[11:42] <sistpoty|work> hi sebner
[11:44] <\sh> sebner: you not? :)
[11:45] <sebner> \sh: I didn't use it yet. I can't even start it ^^
[11:46] <\sh> sebner: why not? what's the problem? read the README ;)
[11:46] <sebner> lol
[11:48] <sebner> \sh: ah. readme seems to be interesting xD
[11:54] <sebner> \sh: nice but it seems that the Qt version is somehow forwad
[11:55] <jdstrand> \sh: hi! are you working on the ruby1.9 merge?
[11:59] <jdstrand> \sh: I am going to take it if not
[12:00] <\sh> jdstrand: please do :)
[12:00] <jdstrand> \sh: ok
[12:01]  * sebner is too afraid to take on of \sh merges ^^
[12:29] <tjaalton> TheMuso: re: vdr-plugin-console; I think that merging vdr (which I'll do next week) should make the change obsolete. After that, most of the plugins should be syncable
[12:44] <kostmo> how does one make a newline in the package description in debian/control?
[12:44] <kostmo> the method described in http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Description doesn't work for me
[12:45] <sistpoty|work> kostmo: with " ."
[12:45] <geser> " ." doesn't work for you?
[12:45] <kostmo> lol my bad
[12:45] <kostmo> i forgot "." was a "full-stop character"
[12:45] <kostmo> I was thinking "newline" for some reason
[12:47] <kostmo> can text be bolded or formatted in any other way in the description?
[12:48] <sebner> geser: fire up your ACK-script. I have some syncs in u-u-s queue :P
[12:48] <sistpoty|work> kostmo: not really. only thing is that two leading spaces will iirc create verbatim text (useful for e.g. lists)
[12:49] <kostmo> ok, thanks
[12:52] <kostmo> so I finally got all the kinks worked out of my package and successfully uploaded it to my PPA, I would now like to get it into Universe
[12:54] <kostmo> it says that one should file a Launchpad bug for needs-packaging -- is there a template for this kind of bug?
[12:57] <geser> kostmo: https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages/ExamplePackageRequest
[12:57] <kostmo> ah, thanks!
[13:25] <tjaalton> siretart: re:vdr; yes, I am. mostly offline this week, but if you have questions you can mail me and I'll answer when I get back
[13:49] <siretart> tjaalton: I wanted to ask you to provide backports of your vdr packages for hardy, if applicable/necessary
[13:49] <siretart> tjaalton: in the MOTUMedia ppa. I started to do so in the past, but if you are preparing uploads to intrepid it would be less efford to upload them to the ppa as well
[13:51] <tjaalton> siretart: right. I'll merge vdr next week and file sync-requests for the plugins as necessary. backporting should be easy
[13:52] <siretart> tjaalton: cool. I'll add you them to the motumedia team, so that you can upload yourself. just apply to the team and I'll approve you
[13:53] <tjaalton> siretart: ok, I'll apply next week when I have more bandwith ;)
[13:53] <siretart> ok
[13:54] <DktrKranz> soren: new network-manager-vpnc snapshot uploaded to intrepid. You maintain it in Debian, biebl was thinking to move it to collaborative maintenance under pkg-utopia team, can I be of any help?
[13:55] <soren> DktrKranz: Er... It's already there.
[13:55] <soren> DktrKranz: "Maintain it in Debian" is not exactly accurate, though.
[13:56] <soren> I'm *supposed* to.
[13:56] <DktrKranz> soren: ah, I noticed right now...
[13:56] <soren> Every time I have to work on it, I end up spending a few hours yelling and screaming at GNOME's svn and then at svn-buildpackage and more often than not, I give up at some point.
[13:58] <DktrKranz> soren: anyway, if you need help/manpower/anything, I'd like to help
[13:58] <sebner> DktrKranz: huhu, so new debdiff for libnxml? yes or no?
[13:59] <DktrKranz> sebner: prepare it, so sponsors will choose between them :)
[13:59] <sebner> DktrKranz: *you* are my sponsor :P
[14:00]  * DktrKranz looks at his reference book, no indication he is sebner's soley sponsor :P
[14:01] <geser> DktrKranz: your copy is outdated :)
[14:01] <sebner> geser: ha! thx :P
[14:02] <DktrKranz> geser: already? damn!
[14:02] <DktrKranz> wasn't it 0.6.6?
[14:11] <sebner> geser: thx for ACKing my syncs. How big is the queue currently?
[14:12] <DktrKranz> sebner: I see 64 bugs waiting
[14:13] <sebner> DktrKranz: great. so the times are over with >300 waiting bugs ^^
[14:15] <DktrKranz> well... if you look at subscribed bugs you'll get 92, but I usually look at http://tinyurl.com/6dawf8
[14:16] <sebner> I see :)
[14:17] <DktrKranz> and it was > 300 because of DebianMaintainerField bugs :P
[14:19] <sebner> ^^
[14:19] <DktrKranz> now they're gone (only 2 missing, but pending upload)
[14:20] <sebner> good we fixed them *grins*
[14:24] <DktrKranz> sebner: don't worry, there will always be :)
[14:24] <sebner> ^^
[14:24]  * directhex awaits a merge in main. and one in debian
[15:26] <azeem> anybody whether LaserJock is really busy recently, or just not on IRC a lot?
[15:27] <sistpoty|work> azeem: afaict he's really busy with his PhD
[15:27] <wgrant> azeem: He is taking a break from Ubuntu, for reasons which sistpoty|work has mentioned.
[15:28] <azeem> k, I shall send him a mail then
[15:44] <sebner> persia: uqm-music and *-voice is debian new \o/
[15:51] <wgrant> sebner: Didn't we just sync from Mithrandir's repo within the last couple of days?
[15:51] <sebner> wgrant: yes
[15:51] <sebner> wgrant: but Debian didn't want to include them because they are so big but now it's in new
[15:55] <wgrant> sebner: Aren't they no more than a couple of dozen megabytes?
[15:55]  * wgrant looks.
[15:56] <sebner> wgrant: dunno. but Debian didn't want them. They are/were talking about a data repo. dunno
[16:15] <james_w> \sh: isn't there a typo in the Replaces: of clalsadrv?
[16:15] <james_w> libclasadrvc2 instead of libclalsadrvc2
[16:16] <james_w> I assume it's no longer important, as now we are post-hardy these can be dropped?
[16:17] <\sh> think so
[16:17] <james_w> it appears the packages in question were pre-dapper.
[16:27] <mouz> I packaged touchfreeze (with apachelogger's help). I hope one or two motu would like to review the packaging. The needs-packaging bug is bug 240636. I uploaded it to revu (http://revu.ubuntuwire.com/details.py?package=touchfreeze).
[16:27] <mouz> oeps wrong bug
[16:28] <mouz> bug 240637
[16:28] <Jazzva> I have prepared 3 merges, if anyone is willing to review. All of them are mozilla extensions, and since our and Debian packaging for extensions differs a lot, all are prepared by grabbing orig.tar.gz from debian, updating the source, and then modifying our packaging, if needed. The packaging is available in bzr branches mentioned in the bugreport.
[16:29] <Jazzva> bug 241160, bug 241669, bug 241671
[16:29] <Jazzva> Thanks :)
[16:31] <wgrant> Jazzva: Is it really necessary to have such a deviation from Debian?
[16:31] <wgrant> That is generally strongly frowned upon.
[16:32] <Jazzva> wgrant, mozilla team prepared package mozilla-devscripts, which contains xpi.mk script. It makes extension packaging and maintaining a lot easier
[16:32] <wgrant> Jazzva: Are you attempting to push this to Debian?
[16:32] <Jazzva> wgrant, there are plans to include mozilla-devscripts package in Debian, but for now it doesn't exist there. That's why such a big difference exists
[16:33] <wgrant> Jazzva: Right, that's fine then.
[16:33] <Jazzva> wgrant, yes, when mozilla-devscripts is included in debian, I suppose they'll start using xpi.mk, so the merge changes won't be so big.
[16:34] <Jazzva> s/is/gets
[17:09]  * sistpoty|work heads home... cya
[17:59] <norsetto> hallo all
[18:00] <geser> Hallo norsetto
[18:00] <norsetto> hi geser
[18:02] <persia> DktrKranz: There's not a list, but it ought at least boot on anything McCaslin or Menlow.
[18:02]  * persia should put up a wiki page
[18:02] <persia> james_w: Certainly.  10:00, right?
[18:03] <persia> sebner: Indeed.  Life is amusing that way.  Anyway, we'll pull from Debian when we can, as the err.no packages are likely to not be there after lenny (as the domain is changing).
[18:03] <james_w> persia: great. My email says "10:00 UTC on Thu 26th June"
[18:04] <persia> james_w: Right.  Any pet bug you want reviewed in the session?
[18:06] <james_w> persia: not that I can think of. Perhaps petitioning #ubuntu-bugs might get you something.
[18:06] <persia> james_w: Good idea
[18:06]  * persia is happy at the idea of someone else picking the stacktrace
[18:40] <slytherin> Can anyone please tell me where has this document moved - http://doc.ubuntu.com/ubuntu/packagingguide/C/index.html ?
[18:40] <jpds> slytherin: https://wiki.ubuntu.com/PackagingGuide
[18:43] <persia> Well, it didn't exactly move, but it's roughly the same content.
[18:56] <slytherin> In the packaging guide the example copyright file contains word 'The Ubuntu Packaging:', is it appropriate?
[18:57] <persia> slytherin: In which context?  At the top, or at the bottom?
[18:57] <slytherin> persia: at bottom, where it specifies packaging copyright
[18:58] <slytherin> I mean shouldn't it be debian packaging or simply packaging
[18:58] <persia> slytherin: I usually just say "Packaging" there.
[18:58] <slytherin> persia: thanks
[18:58] <persia> On the other hand, it's not wrong as long as the package is only done for Ubuntu: someone ought negotiate or change it if they want to put it somewhere else.
[18:58] <persia> Probably better if the guide dropped the word "Ubuntu" in that context.
[18:59] <persia> slytherin: Would you mind fixing that?
[18:59] <slytherin> persia: I will do it.
[19:00] <persia> slytherin: Thanks.
[19:36] <slytherin> geser: had advocated my package on revu and left minor comments. I fixed those and re-uploaded it. Now the main page says no advocates. Ii is a problem, isn't it?
[19:38] <geser> slytherin: not really, I just need to check the package again and readvocate it
[19:38] <slytherin> geser: Ok. Take your time, I am in no hurry. :-)
[19:39] <persia> slytherin: More generally, when you update a package, previous advocations are removed, as there is no guarantee your changes are also advocated.  As you've just seen, often a quick ping will get you back your advocation.
[19:39] <slytherin> :-D
[19:42] <geser> slytherin: as your changes were minimal a look at the debdiff was enough for me to check the changes and readvocate.
[19:42] <slytherin> geser: Thanks. :-)
[20:27] <tarheelcoxn> I have a pbuilder problem. http://pastebin.com/f59859618 ... Could someone please tell me why the install of the pbuilder-satisfydepends-dummy.deb package fails the way it does? more importantly, how do I fix it?
[20:29] <Jazzva> norsetto, for bug 227577, when you say to just keep Ubuntu package as is and the rest, you mean not to mention Debian's changelog entries?
[20:30] <norsetto> Jazzva: yes, forget debian, keep the package as an ubuntu one
[20:31] <norsetto> Jazzva: just bump version to 0.3.1-0ubuntu2 with those changes and its good to go
[20:32] <Jazzva> norsetto, but maybe it's better to mention it as a merge (true, a big one), and get our version higher than Debian's, which will remove it from MoM.
[20:33] <DRebellion> tarheelcoxn, I have had a very similar problem today with pbuilder.
[20:33] <DRebellion> Will post my log
[20:33] <Jazzva> norsetto, also, when we start merging with Debian at some point in future, their changelog entries we skipped will show up.
[20:33] <tarheelcoxn> DRebellion: excellent
[20:34] <DRebellion> http://paste.ubuntu.com/22939/
[20:34] <DRebellion> Any ideas?
[20:35] <norsetto> jazzva: so what? It doesn't make any sense to marge with debian if the only diff is that they add the homepage field in debian/control.
[20:36] <geser> tarheelcoxn: have you universe enabled in your pbuilder?
[20:38] <geser> DRebellion: the same question for you too ^^
[20:38] <Jazzva> norsetto, I thought it might be confusing for someone who works later on this (or similar) package, when our and Debian's changelog entries get mixed up.
[20:38] <DRebellion> geser, I have this in /etc/pbuilderrc: COMPONENTS="main restricted universe multiverse"
[20:39] <DRebellion> geser, I have to go for a short while. tarheelcoxn, I will be interested to see the outcome. ;)
[20:39]  * tarheelcoxn looks at his rc
[20:39] <geser> DRebellion: please also check inside your pbuilder: pbuilder login and then "cat /etc/apt/sources.list" and check if universe is also listed
[20:41] <tarheelcoxn> looks like I only had main enabled
[20:41] <tarheelcoxn> geser: thanks good catch.
[20:41]  * tarheelcoxn tries again
[20:44] <tarheelcoxn> it works this time
[20:44] <tarheelcoxn> @geser++
[20:44] <tarheelcoxn> DRebellion: edit your /etc/pbuilderrc and try again
[20:49] <DRebellion> geser, will do
[20:53] <DRebellion> geser, hmm, only main is listed
[20:53] <DRebellion> geser, after I changed the /etc/pbuilderrc , I just did pbuilder update. Should I have created a brand new chroot?
[20:55] <geser> DRebellion: try pbuilder update --overwrite-config
[20:56] <DRebellion> geser, I have just edited the /etc/apt/sources.list inside the chroot and am now running apt-get update
[20:56] <DRebellion> geser, that should fix it, right?
[20:56] <geser> DRebellion: that works too but only if you do pbuilder login --save-after-login else your changes get discarded
[20:57] <DRebellion> geser, damn
[20:57] <DRebellion> geser, okay, will do pbuilder update --overwrite-config
[20:58] <tarheelcoxn> after I had changed mine I did a sudo pbuilder create --debootstrapopts --variant=buildd
[20:58] <tarheelcoxn> now I know about --overwrite-config :)
[20:58] <DRebellion> tarheelcoxn, i believe there is also --override-config
[20:59] <DRebellion> geser, Error: Unknown option [--overwrite-config] was specified
[20:59] <geser> DRebellion: then it's --override-config :)
[21:00] <DRebellion> geser, right
[21:00] <geser> I didn't look it up in the manpage and apparently remembered it wrongly
[21:15] <DRebellion> geser, thanks. Its working now. :D
[21:17] <tarheelcoxn> @geser++
[22:07] <LimCore> hi, is this a good place to discuss general ubuntu "wish" idea?
[22:19] <directhex> LimCore, depends. what's your opinion of "patches accepted" as a reply?
[23:52] <Falken> Hi everyone
[23:53] <Falken> I'm still looking for MOTUs to review my package. Can someone have a look at http://revu.ubuntuwire.com/details.py?package=flabber
[23:53] <Falken> thanks in advance !
[23:54]  * cody-somerville takes a peek.
[23:56] <cody-somerville> Falken, maintainer field must be a Ubuntu e-mail address if I remember correctly.
[23:56] <cody-somerville> Falken, see your e-mail to: XSCB-Original-Maintainer
[23:56] <cody-somerville> and Maintainer to: Ubuntu MOTU Developers<EMAIL_ADDRESS>(or whatever it is).
[23:58]  * ScottK hands Falken and cody-somerville https://wiki.ubuntu.com/DebianMaintainerField
[23:59] <Falken> thanks for the advice, I'm having a look
[23:59] <ogra> well, only for packages that are actually in debian, no ?
[23:59] <ScottK> ogra: No.  All packages.
[23:59] <ogra> huh?


[05:17] -BottyMcBotFace:#ubuntu-news- ::Softpedia:: iPhone 7 Becomes a Linux Phone Thanks to postmarketOS Hack @ https://news.softpedia.com/news/iphone-7-becomes-a-linux-phone-thanks-to-postmarketos-hack-529778.shtml (by Bogdan Popa, Microsoft News Editor)
[05:47] -BottyMcBotFace:#ubuntu-news- ::Softpedia:: Ubuntu Touch OTA-12 Launch Date Announced @ https://news.softpedia.com/news/ubuntu-touch-ota-12-launch-date-announced-529780.shtml (by Bogdan Popa, Microsoft News Editor)
[09:47] -BottyMcBotFace:#ubuntu-news- ::Planet:: Ubuntu Blog: 2004 to 20.04 LTS: Ubuntu in popular culture @ https://ubuntu.com/blog/2004-to-20-04-lts-ubuntu-in-popular-culture
[10:23] -BottyMcBotFace:#ubuntu-news- ::Portugal:: Ep 86 – Engenharia em directo @ https://podcastubuntuportugal.org/e86/
[10:35] -BottyMcBotFace:#ubuntu-news- ::Planet:: Podcast Ubuntu Portugal: Ep 86 – Engenharia em directo @ https://podcastubuntuportugal.org/e86/
[11:20] -BottyMcBotFace:#ubuntu-news- ::Planet:: Ubuntu Podcast from the UK LoCo: S13E04 – Indoor umbrellas @ https://ubuntupodcast.org/2020/04/21/s13e04-indoor-umbrellas/
[12:11] -BottyMcBotFace:#ubuntu-news- ::Fridge:: Ubuntu Weekly Newsletter Issue 627 @ http://fridge.ubuntu.com/2020/04/20/ubuntu-weekly-newsletter-issue-627/ (by wildmanne39)
[21:16] -BottyMcBotFace:#ubuntu-news- ::Planet:: Ubuntu Blog: WSLConf: Sessions Part 1 @ https://ubuntu.com/blog/wslconf-sessions-part-1


[00:36] <qengho> ayan: Yes. Instead of extending snapcraft.BasePlugin, extend snapcraft.plugins.existingpluginmodulename.ExistingPluginClassName
[00:42] <ayan> ah  -- so also import snapcraft.plugins.existingplugin as well?
[00:43] <ayan> for for nil:
[00:43] <ayan> import snapcraft.plugins.nil
[00:43] <ayan> class Foo(snapcraft.plugins.nil.NilPlugin):
[00:43] <ayan>   ...
[00:46] <qengho> ayan: Yeah, s.plugins doesn't import all of its children or something, perhaps because it's trying not to pretend to know all of them that could be found, because plugins. Import the whole thing instead of trying to walk down the path from "snapcraft".
[00:47] <qengho> ^whole thing^specific thing
[00:47] <qengho> Zzzz
[00:47]  * ayan nods.
[05:13] <lathiat> when does snappy day start, uk time?
[05:20] <Hichhiker> do snaps allow/designed for permanent data storage across updates? I see $SNAP_APP_DATA_PATH - but it appears that that is a per-version location. Where does one place data to be kept with the app but not be lost due to update
[05:49] <didrocks> good morning
[06:01] <stevebiscuit> lathiat: the core team is mostly in mainland Europe, UK and S. America
[06:42] <popey> morning
[06:43] <didrocks> hey popey
[06:50] <dholbach> hello hello
[06:51] <didrocks> hey dholbach
[06:55] <popey> what's the most advanced (in terms of working) GTK app which has been snappified, which I could use as a template for another app? Is it seb128's GNOME calculator work from Prague?
[06:55] <popey> I assume Krita is the most advanced (in terms of working) KDE app?
[06:58] <dpm> good question - I think we really need at least one GTK app in the playpen, seb128 (morning!) where does the code for the desktop's team snaps live?
[06:59] <didrocks> argh, if I snapcraft clean an older project with newer snapcraft, it doesn't clean the parts/ directory
[06:59] <didrocks> I guess it's because they renamed it to prime but didn't handle older formats
[07:01] <dholbach> dpm, https://code.launchpad.net/~ubuntu-desktop/+junk/gnome-calculator-snap
[07:02] <dpm> thanks dholbach :)
[07:02] <dpm> I wonder if we should make http://bazaar.launchpad.net/~ubuntu-desktop/+junk/gnome-calculator-snap/view/head:/calc a part as we did with the qt5 wrapper
[07:03] <dpm> I mean a wiki part
[07:04] <didrocks> that was my plan (but it seems my plan for the day changed)
[07:05] <dpm> hey, morning didrocks! - you mean you no longer think it's a good idea, or something in snapd has changed... or that you've got other things to do for the day?
[07:05] <didrocks> dpm: other things that happened unexpectly
[07:05] <dpm> ok ok
[07:06] <dpm> I was originally planning to have a go ad snapping Dekko, but I might actually give this a go instead
[07:15] <popey> The reason I asked is because there's a couple of gnomeish apps like Ardour and Inkscape which would be interesting to snap.
[07:16] <popey> and some KDEish ones like Kdenlive.
[07:16]  * dpm tries to build GNOME calc first
[07:39] <seb128> hey dpm dholbach popey
[07:39] <dholbach> salut seb128
[07:40] <popey> morning!
[07:40] <seb128> dpm, we don't have a shared space for snaps, just one main example which is the one dholbach pointed
[07:40] <seb128> and it's not hackish enough yet
[07:40] <dholbach> maybe we can add it to snappy playpen too?
[07:40] <seb128> like translations, input methods, etc don't work
[07:40] <dholbach> it'll be a WIP snap
[07:40] <seb128> dholbach, your call, as long as those ^ are not working I'm not "advertizing" anything
[07:41] <dholbach> right
[07:41] <dholbach> we want to collect best practices in there
[07:41] <seb128> "best"
[07:41] <seb128> don't use that calculator snap then :p
[07:41] <seb128> that's hackiest hacks
[07:43] <dholbach> I feel like we're currently in the stage, where we need to find hacks to make stuff work
[07:43] <dholbach> and then figure out how to make things work more generally
[07:43] <dpm> indeed
[07:46] <seb128> yeah, I'm just not able to find hacks that work for some of the things
[07:46] <seb128> I feel like hacks are not enough to get things fully working
[07:47] <seb128> we need more support from snappy itself
[07:52] <seb128> dpm, dholbach, I'm fine moving things to another place if you feel like it would be better
[07:55] <dpm> thanks seb128, for now we'll try to make a gtk part that can be edited in one place and reused by gtk apps
[07:56] <seb128> good luck getting one to work
[07:56] <seb128> I'm not wanting to recommend anyone to copy the shell hacks in the calculator used to copy schemas&co though
[07:58] <dpm> ok ok :)
[09:50] <d_ed> is there a way of handling i18n in the snapcraft descriptions?
[09:57] <ogra_> d_ed, see http://bazaar.launchpad.net/~ogra/+junk/nethack/view/head:/nethack.sh and http://bazaar.launchpad.net/~ogra/+junk/nethack/view/head:/snapcraft.yaml
[09:57] <ogra_> that deals with basic locale support
[09:58] <didrocks> ogra_: I think d_ed is asking about the snapcraft.yaml file itself
[09:58] <didrocks> getting that translated
[09:58] <ogra_> didrocks,  well, there was support added for env vars inside snapcraft.yaml ....
[09:58] <ogra_> but i'm not sure that got released yet
[09:59] <didrocks> ogra_: how is it related to translating strings in snapcraft.yaml itself?
[09:59] <didrocks> like description
[09:59] <didrocks> or summary
[09:59] <ogra_> so 2/3 from the script above could live in snapcraft.yaml
[09:59] <ogra_> didrocks, aaah !
[09:59] <ogra_> got it :)
[10:00] <ogra_> (ignore me then :) )
[10:00] <d_ed> AFAIK debian packages didn't, but it's an important part of appstream
[10:00] <didrocks> :p
[10:00] <d_ed> and snapcraft metadata is sort of halfway between the two
[10:01] <ogra_> d_ed, definitely worth having a whishlist bug against snapcraft for that
[10:01] <didrocks> yeah
[10:03] <JamesTait> 👋  Morning, folks!
[10:04] <d_ed> ack, will do
[10:04] <d_ed> launchpad?
[10:05] <ogra_> yep
[10:05] <JamesTait> Can anybody offer advice to help me package ejabberd? https://github.com/jamestait/snappy-playpen/blob/master/ejabberd/snapcraft.yaml is what I have so far, but I then need to tweak a couple of files in snap/ to prepend $SNAP to some file locations.
[10:05] <ogra_> https://bugs.launchpad.net/snapcraft
[10:06] <JamesTait> I've got as far as an installable snap for amd64 with that, but only with the default config (I just need to relocate the config dir to $SNAP_DATA I think).
[10:12] <ogra_> JamesTait, use a wrapper script that parses the config ?
[10:14] <ogra_> (i'd use the config from SNAP_DATA, then have a startup wrapper script that checks if the target has a config file, if not, parse $SNAP/etc/ejabberd into $SNAP_DATA/etc/ejabberd and adjust the paths)
[10:16] <JamesTait> ogra_, maybe!  I'm not quite sure what the "standard" approach would be.  ejabberdctl is a bash script, which sets up some environemtn and calls erl, which is another bash script that sets up some environment and calls erlexec.
[10:17] <JamesTait> ogra_, so a wrapper would definitely work, but I wasn't sure it was the right approach - it feels a lot like replicating the functionality of ejabberdctl, so I wondered if I could just set some autoconf parameters and have it all magically work.
[10:18] <JamesTait> But for handling the config file, that makes a lot of sense - "if none exists, copy from the default location."
[10:20] <ogra_> well, if the builtin scripts can be handled by vars you can indeed just set the vars
[10:20] <ogra_> and use the default scripts
[10:23] <JamesTait> I'll give that a try then, as a next step.  I think I tentatively poked at that before and got some complaint about something needing to be an absolute path.
[10:51] <sabdfl> hi all, nice to be visiting the playpen from tokyo :)
[10:52] <dpm> \o/
[10:53] <sabdfl> hi dpm
[10:53] <dpm> hi
[10:56] <dpm> we're at https://gitter.im/ubuntu/snappy-playpen too, getting more apps added to the playpen
[11:38] <sabdfl> sergiusens, you were right, moving those deps to build-packages cleared the issue on gpsd
[11:43] <ogra_> hmm, i wonder ... if i put a desktop ... say lubuntu inside a snap ... and add aethercast and bluetooth support and some scrpitery ... if that could become a wireless thing client server ...
[11:44] <ogra_> thin
[11:55] <kyrofa> Too many chat clients open...
[11:56] <ogra_> heh
[12:00] <AndyWojo> Are system monitoring tools not great to make snaps of? Can they see the performance counters within the kernel?
[12:01] <AndyWojo> I wanted to create a snap of nmon
[12:01] <ogra_> you will definitely bbe able to use it in --devmode
[12:02] <ogra_> beyond that you will likely need some interfaces that might not be there yet ... (but without you creating a snap we wont know which ones you need, so go ahead, start with the snap and file bugs for the non --devmode cases)
[12:03] <AndyWojo> Great
[12:03] <AndyWojo> Thanks
[12:19] <sgclark> hi all
[12:20] <kyrofa> Hey there sgclark
[12:21] <dpm> morning sgclark o/
[12:25] <dpm> d_ed, not as far as I know. However, the store supports translations for descriptions of phone clicks, so I'm thinking it should support translations for descriptions of snaps too
[12:25] <dpm> JamesTait, that might be a question for you? ^
[12:50] <netphreak> Hi, guys!
[12:53] <ogra_> hey netphreak
[12:54] <dpm> hi netphreak :)
[12:54] <kgunn> mvo: you about?
[12:56] <kgunn> mvo: not sure what's going on (altho i was an early user?) but snap on classic i'm getting
[12:56] <kgunn> https://pastebin.canonical.com/158168/
[12:57] <JamesTait> dpm, sorry, what was the question?
[12:57] <mvo> kgunn: does it make a difference if you run this with sudo?
[12:58] <JamesTait> Metadata translations?
[12:58] <d_ed> JamesTait: yeah
[12:59] <JamesTait> There's a translations section in the package details page on myapps where you can add localised metadata for the phone scope and snap client to use.
[12:59] <dpm> JamesTait, exactly, are these supported in the store for snaps?
[12:59] <dpm> excellent
[13:00] <JamesTait> The snaps API works in exactly the same way as the clicks API in that regard - if the client sends the Accept-Language header, the response should be automatically translated.
[13:00] <JamesTait> Assuming the developer has entered the translations, of course.
[13:01] <kgunn> mvo: nope, same response
[13:01] <JamesTait> We currently don't support extracting translations from, say, snap.yaml or .desktop files.
[13:01] <ogra_> looks like snapd isnt running ?
[13:06] <mvo> kgunn: hm, in a meeting right now, could you please check the last few lines of /var/log/syslog
[13:06] <kgunn> ack
[13:06] <mvo> kgunn: and if there is nothing interessting in there, could you mail me the full syslog ? I will inspect it then and see if it gives me some clues
[13:07] <dpm> thanks JamesTait, d_ed hopefully that answers your question?
[13:07] <d_ed> yep
[13:07] <dpm> in short, you can enter translations in the store's web UI
[13:07] <dpm> ok, cool
[13:11] <kgunn> mvo: ta
[13:11] <kgunn> mvo: i just uploaded it here https://drive.google.com/a/canonical.com/file/d/0B4GvOYxwuvpFTllJdk9QYS1vQUk/view?usp=sharing
[13:12] <kgunn> mvo: fwiw, a couple of confessions...i have stable-phone-overlay ppa applied
[13:12] <kgunn> for unity8
[13:12] <kgunn> desktop-session-mir, and i also ran the little script for "early users" as advertised in
[13:13] <kgunn> https://docs.google.com/document/d/1LsWd76jH9pEep8tz1SI4UPBFmbFTJGec9u518UJnW9Y/edit#heading=h.qxx7ico5okhd
[13:14] <mvo> kgunn: ta, I can't see anything obvious here, hmmm
[13:15] <slvn> sergiusens, Hello! you suggested me to set an env variable for this issue. https://bugs.launchpad.net/snapcraft/+bug/1575582
[13:15] <slvn> I tried, but there is still some erros ... If you have some more ideas ..
[13:16] <sergiusens> slvn have you checked for any errors and/or debug messages?
[13:17] <sergiusens> so vejmarie solve gl a while back, my recomendation was based on what was done for freecad
[13:18] <slvn> sergiusens, I don't know much about gl ... I have written the new errors on the tickets
[13:18] <sergiusens> sabdfl using build-packages you also get a smaller snap :-)
[13:19] <sergiusens> kyrofa agreed, it is like to many channels but worse as each has its own mechanics :-P
[13:19] <kyrofa> sergiusens, no kidding
[13:24] <ogra_> hmm, so how do i convinnce my snap to have a .desktop file
[13:27] <kgunn> mvo: i'll take any advice, i did a remove and reinstall of ubuntu-snappy-cli and ubuntu-core.... but i'd like to get back to a state where i can work on unity8 interfaces with ted
[13:29] <dpm> ogra_, perhaps with something like this? (files under setup/gui) -> http://bazaar.launchpad.net/~dpm/ubuntu-clock-app/snap-all-things/files/head:/setup/gui/
[13:29] <ogra_> dpm, ah, that was the bit i was missing
[13:29] <ogra_> thanks
[13:29] <dpm> excellent
[13:32] <netphreak> Has the classic mode been reintroduced again?
[13:32] <mvo> kgunn: can you please run sudo systemctl stop snapd.service snapd.socket  ;  sudo /lib/systemd/systemd-activate -E SNAPD_DEBUG=1 -l /run/snapd.socket /usr/lib/snapd/snapd on a terminal and run snap list in a different terminal and see if this debug switch helps and prints something useful?
[13:38] <kyrofa> stevebiscuit, I forgot we had wgrant there, he could tell you everything about the builders
[13:38] <kyrofa> stevebiscuit, https://kyrofa.com/posts/building-your-snap-on-device-there-s-a-better-way if you haven't done it before
[13:39] <kgunn> mvo: hmmm, now list works :) https://pastebin.canonical.com/158171/
[13:39] <kgunn> the debug out for snapd is here https://pastebin.canonical.com/158172/
[13:39] <kgunn> in case your interested
[13:42] <sergiusens> ogra_ if you need help go to gitter :-P
[13:48] <ogra_> sergiusens, i am there ...
[13:52] <ogra_> sergiusens, my prob is that i start running out of free space on my desktop for the different chat clients :P
[13:52] <Mikaela> is gitter also open for curious idlers?
[13:52] <kyrofa> ogra_, make more virtual workspaces, duh
[13:52] <kyrofa> Mikaela, certainly!
[13:53] <ogra_> kyrofa, i have 6 already :)
[13:53] <kyrofa> Mikaela, https://gitter.im/ubuntu/snappy-playpen
[13:53] <ogra_> Mikaela, definitely !
[13:53] <kyrofa> ogra_, try 9
[13:53] <ogra_> haha
[13:53] <Mikaela> thanks, I will take a look on PC
[13:53] <kyrofa> ogra_, it will satisfy your desire for symmetry
[13:53] <ogra_> i guess then i'll slowly start running out of ram for snapcraft
[13:53] <kyrofa> Hahaha
[14:23] <kyrofa> And now my wife starts talking to me on hangouts. Now I have telegram, xchat, gitter, and hangouts
[14:24] <ogra_> kyrofa, join us on slack in the warthogs chat !
[14:25] <ogra_> :P
[14:25] <kyrofa> Oh man, I was on there but forgot about it
[14:29] <mvo> kgunn: hm, list works but it is empty, is that expected?
[14:30] <kgunn> mvo: got distracted with a meeting...lemme check more
[14:30] <mvo> kgunn: same problem, long phonecall :)
[14:35] <kgunn> mvo: so weird, find worked ok, but install problematic
[14:36] <kgunn> https://pastebin.canonical.com/158177/
[14:36] <mvo> kgunn: hm, 500 error is a store side thing
[14:36] <mvo> kgunn: is that reproducable?
[14:37] <seb128> kgunn, is your (hotel?) internet filtered in some ways?
[14:39] <kgunn> seb128: well, we're on classic canonical wifi
[14:39] <seb128> k, asking in case
[14:39] <seb128> you might have reconnected to the hotel one or something
[14:40] <seb128> oh
[14:40] <seb128> kgunn, mvo, install errors 500 here as well
[14:41] <seb128> seems like a store issue
[14:41] <seb128> nessita, ^
[14:46] <sergiusens> kyrofa tell her to use telegram :-P
[14:46] <kgunn> dpm: hey what's the lp branch where i can rebuild calc/clock snap to attempt side load ?
[14:47] <dpm> kgunn, `bzr branch lp:~dpm/ubuntu-clock-app/snap-all-things`
[14:47] <kgunn> ta
[14:47] <dpm> `bzr branch lp:~dpm/ubuntu-calculator-app/snap-all-things`
[14:47] <dpm> np
[14:47] <kyrofa> sergiusens, :P
[14:48] <nessita> seb128, sorry otp, can you please join the internal store channel and report there?
[14:49] <seb128> kgunn, ^
[14:53] <Sutter> Hi!..
[14:55] <Sutter> So... How Can i Do a snappy app?:D
[14:59] <elopio> Sutter: hello.
[15:00] <elopio> Sutter: you can start here: https://developer.ubuntu.com/en/snappy/build-apps/
[15:01] <jamieben_> Sutter: you could also join the playpen initiative going on right now with experts to guide you through the experience - https://lists.ubuntu.com/archives/snapcraft/2016-June/000090.html
[15:01] <jamieben_> Sutter: and the details on how to connect - https://lists.ubuntu.com/archives/snapcraft/2016-June/000119.html
[15:01] <Sutter> wow!..ok! tnx
[15:19] <ogra_> Sutter, all conversation currently happens in https://gitter.im/ubuntu/snappy-playpen
[15:19] <ogra_> oh, he's gone
[15:20] <ogra_> (or she)
[15:25] <ev> kgunn: is snap install working for you now?
[15:29] <kgunn> bout to check
[15:30] <ev> cheers
[15:31] <kgunn> ev: appears to be working....
[15:31] <ev> excellent
[15:31] <ev> really sorry that this happened. We’re working on an incident report now to ensure it doesn’t repeat
[15:32] <kgunn> ev mvo fwiw, interesting i was trying to install sideload style...but grabbed from the store?
[15:32] <kgunn> https://pastebin.canonical.com/158193/
[15:38] <kgunn> but at least the store works ;)
[15:41] <sethj> can someone confirm this is a bug in snapcraft and not in Unity Tweak Tool? https://bugs.launchpad.net/snapcraft/+bug/1587193
[15:45] <ev> kgunn: I don’t think that’s correct. Your first pastebin tries to install a snap from the store and fails
[15:45] <ev> oh wow no
[15:45] <ev> I see what you mean now
[15:46] <ev> mvo: https://pastebin.canonical.com/158193/ - any idea why it’s fetching from the store instead of sideloading here?
[15:47] <mvo> ev: does it make a difference if you do sudo snap install ./ubuntu-calculator-app_2.1+snap3_amd64.snap
[15:47] <mvo> kgunn: -^
[15:47] <mvo> ev: this looks like a bug I'm not entirely sure yet about the details
[15:48] <kgunn> mvo: yes, ./ worked to sideload...i shoulda tried that
[15:49] <dpm> hey, can someone help us answer this question from the community team Q&A?
 QUESTION: Due to snappy using A/B partitioning, when we get system updates will that mean that we will have to reboot to install these? Or will we be able to have live system updates?
[15:49] <dholbach> hey attente - how are you? do you have any experience with qt4 apps?
[15:49] <dpm> ahayzen, ^ :-)
[15:49] <dholbach> qt4 snaps I should say
[15:49] <ahayzen> dpm, \o/
[15:49] <dholbach> I'm working on https://github.com/ubuntu/snappy-playpen/tree/musique right now
[15:50] <dholbach> and it looks for /etc/xdg/Trolltech.conf instead of its $SNAP/... counterpart
[15:50] <dholbach> and I can't find that in its source code
[15:51] <mvo> kgunn: thanks for confirming still a bug on our side
[15:51] <kgunn> mvo: want me to file one?
[15:51] <kgunn> just to have it...
[15:51] <kgunn> realize not a huge deal
[15:54] <dpm> dholbach, you might wanto to have a look at how we deal with qt5.conf in the qt5-launcher part. Perhaps we can do something similar for qt4 apps?
[15:54] <dholbach> dpm, it's what I borrowed a lot of ideas from :)
[15:55] <dpm> ok ok :)
[15:55] <attente> dholbach: can you try setting $XDG_CONFIG_DIRS in the wrapper script?
[15:56] <attente> dholbach: alternatively, maybe there's some way to set $sysconfdir at build time?
[15:56] <dholbach> attente, like this?
[15:56] <dholbach> export XDG_CONFIG_DIRS=$SNAP/etc/xdg:$XDG_CONFIG_DIRS
[15:56] <dholbach> export XDG_CONFIG_DIRS=$SNAP/usr/xdg:$XDG_CONFIG_DIRS
[15:57] <attente> dholbach: yeah, does that do anything?
[15:57] <dholbach> no
[15:57] <dholbach> I couldn't find the lookup in the source, so I suspect its further down the stack somewhere
[15:57] <dholbach> but $sysconfdir sounds like something I should try
[15:59] <dholbach> no mention of sysconf anywhere
[16:06] <dholbach> attente, ^ do you know of any other qt4 snaps?
[16:09] <attente> dholbach: no, sorry. if you want, i can help take a look at your snap
[16:11] <verterok> mvo: doing a rollout, might get a couple 500's from downloads ATM
[16:12] <dholbach> attente, I'll need to run in a few, but if you have a bit of time, that'd be great
[16:12] <dholbach> I suspect this might be similar in other qt4 apps
[16:13] <seb128> dholbach, attente, http://sources.debian.net/src/qt4-x11/4:4.8.7%2Bdfsg-8/src/corelib/io/qsettings.cpp/?hl=2672#L3531
[16:13] <seb128> dholbach, attente, basically you need to rebuild your qt4 with different buildtime option
[16:14] <dholbach> ouch
[16:14] <attente> seb128: thanks
[16:14] <seb128> that's back to the issue I'm trying to point on the mailing list
[16:14] <ogra_> seb128, well, but datadir is defined at build time ... you can just set it to the right snap dir :)
[16:14] <dholbach> ok, I'll take a look at that tomorrow morning
[16:14] <dholbach> and see if that helps
[16:14] <seb128> rebuilding?
[16:14] <seb128> or the list discussion?
[16:15] <ogra_> seb128, all your complaints assume you just (ab)use the debs
[16:15] <seb128> ogra_, no they don't
[16:15] <ogra_> would you build from source you could adjust the built time env
[16:15] <seb128> right
[16:15] <seb128> but that wouldn't work
[16:15] <ogra_> which would immediately solve all yoour issues
[16:15] <ogra_> why not ?
[16:15] <seb128> no
[16:15] <seb128> because what value would you use?
[16:16] <seb128> --sysconfdir=/snap/currrent/software/etc ?
[16:16] <ogra_> yeah,something like that ...
[16:16] <seb128> that directory has no garantie to not change in a futur snapd version
[16:16] <seb128> and that would make the file installed in "/snap/currrent/software/etc
[16:16] <ogra_> i thinnk it is supposed to stay stable over the iteration of 16
[16:16] <seb128> in the squashfs
[16:17] <seb128> so be on "/snap/currrent/software//snap/currrent/software/etc"
[16:17] <seb128> in the mounted snap
[16:17] <ogra_> an you cant use ./software/etc ?
[16:17] <seb128> well then the code would try to open /software/etc/config
[16:17] <seb128> which doesn't exist
[16:18] <ogra_> it would remove the dot ?
[16:18] <ogra_> that sounds like a broken build system
[16:18] <seb128> I don't understand what you mean
[16:18] <seb128> it tries to open the conf at $sysconfdir/config
[16:18] <ogra_> make your dirs relative, cd too the workdir from a wrapper script
[16:18] <attente> think ogra_ is suggesting using a relative path for $sysconfdir
[16:18] <ogra_> yeah
[16:19] <ogra_> for all dirs
[16:19] <seb128> so your program would only work if you start if from some specific dir?
[16:19] <seb128> also I don't think that would work
[16:19] <ogra_> well, from its confined dir ...
[16:19] <seb128> make install would get confused
[16:19] <ogra_> it cant work anywhere else anyway
[16:19] <zyga> o/
[16:19] <seb128> k
[16:19] <seb128> well, make install is the issue there
[16:20] <seb128> it's going to try to install to a relative path
[16:20] <ogra_> i'm sure you can trick it sommehow to DTRT
[16:20] <seb128> it's like the locales right?
[16:20] <seb128> again I'm happy if you find the "somehow"
[16:20] <attente> is there a way to tell qt4 to check a different dir at runtime? no envvar?
[16:20] <ogra_> (i totally agree about the distro patch complaint btw)
[16:21] <ogra_> qt4 ? is that still a thing ?
[16:21] <seb128> attente, seems not, did you see the url I shared?
[16:21]  * ogra_ thought qt4 would have been gone the way of gtk1.2 by now :)
[16:21] <attente> seb128: yeah, i saw. but i was wondering if there's some codepath that overrides it at runtime
[16:21] <seb128> not that I found
[16:23] <attente> seb128: what about https://sources.debian.net/src/qt4-x11/4:4.8.7%2Bdfsg-8/src/corelib/io/qsettings.cpp/?hl=2672#L1107
[16:24] <seb128> attente, that's only for the user config?
[16:25] <ogra_> grrr ... upstreams ... even canonical peoplle hardcode paths in their upstream code !!!
[16:25]  * ogra_ tries to cook up a patch for the webbrowser app so it becomes usable in snaps
[16:25] <seb128> lol
[16:27] <ogra_> and this one is really evil ... "cant find my app in /usr/share/webbrowser-app ... so i *must* be on a developer system ... lets hardcode all paths to ./src then !"
[16:27] <seb128> that's common practice
[16:28] <seb128> well not unseen at least
[16:28] <ogra_> (but indeed lets expand the path to the full absolute one starting at / before we inject it into the binary)
[16:28] <attente> seb128: XDG_CONFIG_HOME=/ASDF strace musique 2>&1 | grep ASDF
[16:28] <ev> mvo, kgunn: heads up that the store is down again
[16:28] <attente> it seems to be looking there after defining it
[16:28] <ev> we’re in the process of rolling back the bad deployment
[16:29] <seb128> attente, yes, that's what the url I share was documenting?
[16:29] <attente> seb128: yes, but it doesn't require a rebuild of qt4
[16:31] <seb128> attente, well it's the user config
[16:31] <seb128> attente, it's trying to append .config to it no?
[16:31] <seb128> like /ASDF/.config/Trolltech.conf ?
[16:31] <seb128> (I didn't try here, just my reading)
[16:32] <seb128> unsure if relative paths would work
[16:32] <attente> seb128: it looks at "/ASDF/Trolltech.conf" for me
[16:32] <seb128> oh oh
[16:32] <seb128> ah, makes sense
[16:32] <attente> so i guess just defining XDG_CONFIG_HOME=/snap/<name>/current/etc/xdg should work
[16:33] <seb128> that seems wrong
[16:33] <seb128> but yeah, could work
[16:33] <seb128> well it would need to be made a list
[16:33] <seb128> so it still find the real user config if there is one
[16:34] <attente> yeah
[16:42] <wililupy> Question: Is anyone else getting http error 500 when trying to snap refresh ubuntu-core?
[16:42] <wililupy> I'm getting this error on my 16.04 laptop and from my Ubuntu-core KVM's.
[16:44] <popey> wililupy: i just tried and it worked here
[16:44] <wililupy> Interresting....
[16:45] <popey> not in a kvm, but on bare metal, if that matters
[16:45] <wililupy> That is so weird, I have been trying for 30 minutes and as soon as I question it here it is working.
[16:45] <popey> hah
[16:45] <popey> magic
[16:45] <wililupy> I should have asked sooner ;P
[16:46] <wililupy> Thanks popey
[16:46] <seb128> there was an issue with the store earlier it seems
[16:46] <seb128> but yeah, it has been fixed
[16:46] <popey> np
[17:17] <ogra_> ev, is the store supposed to be ok again ? all my phones just spin endless "looking for updates" now
[17:19] <ogra_> hmm, snap find on the desktop also hangs hard
[17:20] <noise][> ogra_: looks like a connectivity outage
[17:20] <ogra_> ah, finally timed out with a horrible 5 line traceback error message
[17:20] <ogra_> Chipaca, ^^ could we make that a little less scary looking ?
[17:21] <ogra_> noise][, lovely
[17:22] <hichhiker> hi, what is the _proper_ location to store snap-specific data to make it keep across version updates (in Snappy)? Specifically I am playing around with making a Redis snap package - but want to know where do I put the data dumps, etc
[17:23] <hichhiker> APP_USER_DATA seems to be versioned along with the app, so each time I update the app I seem to get a new user data directory :-(
[17:26] <kyrofa> hichhiker, indeed, each version gets a new directory, but the old version's data should be copied into the new one
[17:26] <kyrofa> hichhiker, this helps in case the snap needs to be rolled back
[17:27] <hichhiker> hmm,  I will check on that. How does old data in USER_DATA is cleaned up then? I get current and 1 last version of the app, but it seems that every version of the user data is still there
[17:28] <kyrofa> hichhiker, I believe it will keep three versions before pruning them
[17:29] <hichhiker> kyrofa, thanks, I am just starting out with Core/Snappy and find the learning curve is a bit steep - (mostly because of lack of documentation and conflicting docs)
[17:29] <kyrofa> hichhiker, yeah docs are a known weak point-- we're working on that :)
[17:30] <hichhiker> kyrofa, not the case on my box, I get at least 16 versions of data
[17:30] <kyrofa> hichhiker, hmm, that may have changed. Or it may only apply to snaps in the store
[17:34] <hichhiker> kyrofa, could be... I am on 15.04 if it matters (could not find 16.04 release to download) - also, for whatever reason my snap version is ignored and version looks like a hash of some sort - like this: 'IVMeYWXTaHdc' - the package.yaml has the right value, so not sure why that is happening
[17:34] <kyrofa> Oh!
[17:34] <kyrofa> That's the difference then
[17:34] <hichhiker> 15.04 or hash?
[17:34] <kyrofa> You should just use snappy on 16.04 desktop or server while waiting for images
[17:35] <kyrofa> The fact that you're using 15.04 invalidates a lot of assumptions I was making. The hash means your app is sideloaded
[17:35] <hichhiker> the key thing I need from it is the Core read-only OS deployment - is that part of desktop now?
[17:36] <kyrofa> No, the desktop OS is not read-only, but you can use snaps on it just like you can in the images
[17:36] <hichhiker> BTW, the device I am working on will not be connected directly(or more likely at all) to internet - is there a way to deliver snaps beside sideloading?
[17:37] <kyrofa> There are probably other ways that will be supported, but sideloading is likely the easiest
[17:39] <hichhiker> Ok, my hope is to deliver snaps (preferably signed/encrypted) on removable media that is automatically recognized on insert and updated if needed - but I am sure we are far away from that dream yet :-)
[17:41] <hichhiker> 16.04 seems like it is going to be drastically different, but since it is not out yet, I may switch back to using ubuntu server for now as a half-way step. It is just too tempting to just give up on snaps and go back to .debs once I do that :-/ I really like the Core idea for appliances
[17:41] <hichhiker> I assume server 16.04 has snappy as well?
[17:41] <qengho> Yes.
[17:42] <qengho> Not "snappy" program. Some renaming. Just "snap".
[17:43] <hichhiker> quengho - is that true of Core 16.04 as well?
[17:44] <hichhiker> one more question, is the Grub for Core custom or off-the-shelf? It is possible to replace it with another grub fork or is there Core specific stuff there?
[17:45] <sergiusens> hichhiker if you do snaps now, you will be ready for when ubuntu core comes out
[17:45] <sergiusens> you will be able to migrate transparently
[17:45] <gouchi> is it possible to know if you are in mobile or desktop environment with snapcraft ? So that we can push different configuration file ?
[17:45] <qengho> hichhiker: Yes. Ubuntu 16.04 was released with our progressing work on snappy. It's the best place to work on snaps.
[17:46] <hichhiker> Thanks
[17:47] <kyrofa> hichhiker, the grub question is one for ogra_ I think
[17:48] <qengho> hichhiker: ubuntu-core will want to manage the bootloader configuration, so I would be scared of messing around with it much.
[17:50] <hichhiker> qungho - I wanted to see if I can get TrustedGrub(1 or 2) to work (it uses TPM to store drive encryption/boot signing keys) - but it is another pipe dream :-/
[17:53] <qengho> hichhiker: I know pretty much nothing about this, but I am pretty sure there will be a way for you. It might be that you create your own os or grub package too.
[19:03] <wililupy> I'm trying to build a .snap for armhf so I tried snapcraft --target-arch armhf snap and I get the following error: http://pastebin.ubuntu.com/17098210/
[19:03] <wililupy> its the hello world example from snapcraft-examples git.
[19:04] <wililupy> Not sure what it means. Do I need to add the arch to the snapcraft.yaml for the hello part?
[19:05] <qengho> wililupy: The "hello" plugin doesn't implement building another architecture. It lacks a function that says it supports it, and it lacks test and settings in build() that implement it.
[19:05] <mrasif> hello sir
[19:06] <mrasif> I developed an app.
[19:06] <qengho> wililupy: You need a armhf machine or to borrow one from launchpad's builders for branches there.
[19:06] <sergiusens> wililupy is there a hello plugin in there?
[19:07] <mrasif> then I upload it to ubuntu distro
[19:07] <mrasif> but it still in review section
[19:07] <wililupy> sergiusens: no, the hello-world example uses cmake plugin
[19:10] <niemeyer_> jdstrand: Curious about why my spread snap hit the review queue
[19:10] <wililupy> qengho: so your saying I should build my .snap on an armhf device instead of an amd64 server?
[19:10] <niemeyer_> jdstrand: Are we reviewing for home?
[19:11] <qengho> wililupy: The best thing is to help implement cross-platform support, but the fastest thing is to use a real or virtual machine to make your package.
[19:14] <dpm> jdstrand, do you use askubuntu?
[19:14] <dpm> jdstrand, if so, what you just posted in the mailing list would be a perfect answer to http://askubuntu.com/questions/783979/how-to-debug-snaps ? :)
[19:17] <jdstrand> niemeyer_: I approved
[19:25] <qengho> wililupy: in a plugin, implement enable_cross_compilation(), which peeks at self.project to set values in self that inform the build() about architecture.
[19:26] <wililupy> I'm using the cmake plugin, shouldn't that already be implemented?
[19:26] <wililupy> qengho ^^
[19:27] <qengho> wililupy: cmake doesn't mean anything about what you're compiling. Are you passing the right flags to the Fortran compiler or whatever?
[19:29] <qengho> wililupy: That's my way of saying, no, knowing that you're running cmake to run a compiler doesn't mean the compiler knows enough to switch architecture targets.
[19:29] <qengho> It *could* be enough. It might not be.
[19:30] <wililupy> qengho, that makes sense, which is why snapcraft wants me to make sure that I have the arch in the hello parts section.
[19:30] <qengho> wililupy: and today, the cmake plugin doesn't try to know...
[19:30] <wililupy> That is extremely helpful qengho.
[19:31] <qengho> wililupy: waaaait, snapcraft doesn't require arch. Not any recent version. Are you on 16.04?
[19:31] <wililupy> qengho. Yes.
[19:32] <qengho> wililupy: make a new dir. and cd there. Run "snapcraft init". Does the new yaml have arch in it?
[19:33] <wililupy> qengho no.
[19:33] <qengho> wililupy: it's not required.
[19:34] <wililupy> the snapcraft.yaml file I was using was from a clone from github.com/ubuntu-core/snapcraft-examples
[19:34] <wililupy> I'm just trying to snap the hello world cli example, which works fine from amd64, but when I try to make it for armhf I get the errors.
[19:35] <qengho> wililupy: I'm very sorry, but that example must be older than dirt.
[19:35] <wililupy> most of the examples are ;)
[19:36] <sergiusens> wililupy cmake plugin has no cross compilation support either
[19:36] <sergiusens> wililupy we don't expect it any time soon either
[19:36] <wililupy> sergiusens: ok. I'm going to try to build my .snap on my pi2 running 16.04 server.
[20:52] <erio> Hello
[20:52] <erio> Couldn't solve the locale error the other day
[20:52] <erio> http://askubuntu.com/questions/783758/snap-build-fail-on-locale-error
[20:53] <erio> Leaving here in case someone has seen this already and know how to solve
[21:45] <wililupy> sergiusens, qengho: I successfully got the hello world example to build on my pi2 and it works on my test device. I'm going to read more up on the --target-arc flag on snapcraft to see what exactly it does work on.
[21:51] <sergiusens> wililupy it only really works for building kernels
[21:51] <sergiusens> it is rather low priority everywhere else
[21:54] <wililupy> sergiusens: Ok. I was just hoping that porting a app snap or gadget snap from one arch to another would be as simple as just the --target-arch flag in snapcraft. Its like you say, not a high priority since I can build on either arm or x86.
[21:59] <eriow> Could one use ELDK to build, throw the binaries in the same folder and call snapcraft snap after?
[22:04] <eriow> https://wiki.ubuntu.com/ARM/RootfsFromScratch
[22:04] <eriow> Good luck wililupy