[00:00] <Unit193> (To further ammend Laney's pointing to #ubuntu, precise isn't supported anymore.
[00:00] <Unit193> )
[00:02] <dax> Unit193: so you could say you made the topic more precise by making the topic have less precise
[00:02] <sarnold> *groan*
[00:02] <Unit193> Hahaha. :D
[03:36] <ArMedic> Is there a way to display the battery meter with a numerical output in 17.10?
[03:41] <sarnold> ArMedic: you may have more luck in #ubuntu
[03:42] <ArMedic> sarnold, Thanks, but thats why I came in here, no luck there.
[03:43] <sarnold> oh. bummer.
[05:48] <RAOF> Oh, huh.
[05:48] <RAOF> I appear to have TIL-status on capnproto. Oops.
[06:06] <RAOF> Dear lord!
[06:06] <RAOF> Since when did C++ libraries start downloading code from github as a part of the build?!
[06:10] <juergh> Trevinho, did you see my gjs_dumpstack() trace  in LP: #1714989
[06:10] <Unit193> "Well golang does it!"
[06:11] <Trevinho> juergh: yes, and I submitted a fix on the extension for that right now
[06:11] <Trevinho> juergh: https://github.com/jderose9/dash-to-panel/pull/263
[06:11] <Trevinho> if you can test that change in your local extension it would be cool
[06:11] <Trevinho> (just apply that diff to your file should work)
[06:11] <juergh> Trevinho, sweet!
[06:11] <juergh> Trevinho, I'll give it a try
[06:11] <Trevinho> juergh: however I was askinf for other dumps to people having such issues with not that extension
[06:11] <Trevinho> juergh: thanks
[06:12] <juergh> Trevinho, I have another dash-to-panel dump. You don't need that, right?
[06:13] <Trevinho> juergh: oh, why not
[06:13] <Trevinho> juergh: feel free to send it
[06:16] <juergh> Trevinho, http://kernel.ubuntu.com/~juergh/1714989/
[06:17] <Trevinho> juergh: oh, that was the full crash i thought you menat a jhs_dumpstack
[06:17] <Trevinho> but ok, this should be enough
[06:18] <juergh> Trevinho, oh. :-P
[06:28] <Trevinho> juergh: for reference, you were getting the crash ina repeatible way, or just... it happens?
[06:43] <juergh> Trevinho, not repeatable but very frequent. there were actually two different types of crashes. 'simple' shell resets and real crashes that resulted in a dump.
[06:44] <juergh> I just had another crash and a new dump file. I'll upload it.
[06:44] <Trevinho> juergh: ok, using the patch I did or not?
[06:44] <juergh> This is with your patch. So there might be different issues.
[06:44] <Trevinho> ok, fair enough, let me know once you've it uploaded
[06:46] <Trevinho> juergh: you reloaded gnome-shell after updating the file, right?
[06:46] <juergh> Trevinho, yes
[06:46] <Trevinho> juergh: [or alt+f2 -> r -> enter if in X]
[06:46] <Trevinho> ok
[06:47] <juergh> and it just crashed again. oh boy.
[06:48] <juergh> Trevinho, http://kernel.ubuntu.com/~juergh/1714989/_usr_bin_gnome-shell.2000.crash-201710200842
[06:48] <juergh> oh hold on.
[06:48] <Trevinho> juergh: oh, if you can attach to gdb would probably be helpful
[06:48] <juergh> I think that dump was replaced while I was uploading
[06:49] <juergh> Trevinho, ack. let me attach gdb.
[06:49] <Trevinho> juergh: I'm getting 403 on it though
[06:49] <Trevinho> in both
[06:49] <Trevinho> (even the old one)
[06:49] <Trevinho> +r might be nice :)
[06:59] <juergh> Trevinho, maeh. sorry about that. fixed now. but I removed the latest one, not sure if it's in a coherent state.
[07:06] <Trevinho> juergh: well, is that unpacking with apport-unpack?
[07:07] <juergh> Trevinho, I don't know what apport-unpack is, so I guess the answer is no? :-)
[07:08] <Trevinho> it just unpacks your crash into usable data
[07:08] <Trevinho> juergh: i mean you can check if it is valid at elast
[07:08] <Trevinho> least*
[07:08] <juergh> btw, I just uploaded a new dumpfile and stacktrace.
[07:09] <juergh> this seems very unstable now...
[07:12] <juergh> Trevinho, I reverted your patch. I just had another crash.
[07:14] <Trevinho> juergh: so, the one I tested that was uploaded had the same issue..
[07:16] <Trevinho> juergh: http://kernel.ubuntu.com/~juergh/1714989/stacktrace.201710200903 this was referred to the one with my patch or not?
[07:17] <juergh> Trevinho, yes. with your patch.
[07:18] <Trevinho> juergh: can you pass me the file too, so I have proper lines?
[07:18] <Trevinho> home/juergh/.local/share/gnome-shell/extensions/dash-to-panel@jderose9.github.com/windowPreview.js
[07:33] <Trevinho> juergh: oh, i just noticed a typo in my patch
[07:39] <Trevinho> juergh: so the patch you should actually apply is https://pastebin.ubuntu.com/25777475/
[07:40] <Trevinho> for your version I mean
[07:40] <Trevinho> juergh: full file will be https://pastebin.ubuntu.com/25777478/
[07:40] <Trevinho> as extension stock version is different from master in GH
[07:57] <juergh> Trevinho, that looks vastly different from github master.
[07:58] <Trevinho> juergh: that's what is on gnome extension store
[08:01] <Trevinho> juergh: when you installed the extension you should have got that version (minus the fix) no?
[08:03] <juergh> Trevinho, at first yes. but when it kept crashing I switched to github master.
[08:21] <juergh> Trevinho, what do you want me to test?
[08:32] <Trevinho> juergh: oh, ok then try to use git master again with my patch
[08:32] <Trevinho> juergh: and see how it goes
[08:32] <Trevinho> juergh: (new patch, first one had a wrong leftover)
[08:32] <Trevinho> which didn't cause any fix for sure
[08:46] <juergh> Trevinho, just to be sure, you want me to test https://pastebin.ubuntu.com/25777475 ?
[09:54] <doko> rbasak, jamespage: are there any transitions you would like to start with for b?
[10:53] <Trevinho> juergh: that if you use the gnome-shell extensions website version, otherwise is https://github.com/jderose9/dash-to-panel/commit/1dfcd3e4b9e23fc2cd104be7a1e12c6fd4f18a46.diff
[11:45] <juergh> Trevinho, this looks promising. I haven't had a single reset/crash since 11am'ish.
[19:49] <andreas> hi, I want to SRU ubuntu-advantage-tools into trusty, xenial and zesty. The current version in artful is just "10", and t/x/z have "2". What should the version "template" be like for t/x/z? For example, considering x, 10~ubuntu0.16.04.1? Or 10~0ubuntu0.16.04.1? Summary: http://pastebin.ubuntu.com/25780812/
[19:50] <andreas> slangasek: do you have a tip? ^
[19:54] <johnnyfive> I am writing an implementation of the dpkg-scanpackages and other tools necessary for creating a full index in Go as a library. I am confused in one area. I can't seem to figure out which category/component (xenial-security/main) a package belongs to by reading the meta data from a .deb file. (
[19:55] <sarnold> johnnyfive: that information is recorded in the apt lists
[19:55] <nacc> johnnyfive: it's ot part of the deb
[19:55] <nacc> you were told this yesterday
[19:56] <nacc> (or whenever it was you asked the same thinng in #ubuntu)
[19:56] <johnnyfive> nacc, lol, yes I was, my question has moved on to where that data actually exists, which nobody had an answer for.
[19:56] <sarnold> johnnyfive: /var/lib/apt/lists/
[19:56] <nacc> johnnyfive: you were told where then, too
[19:56] <johnnyfive> ty
[19:56] <nacc> johnnyfive: it's stored in the package lists
[19:56] <johnnyfive> nacc, no I was not. sarnold, thanks!
[19:58] <nacc> johnnyfive: https://irclogs.ubuntu.com/2017/10/18/%23ubuntu.html#t19:43
[19:58] <nacc> took me a second to find it
[20:00] <slangasek> andreas: https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging as a guide; I think 10~ubuntu0.16.04.1 follows, but either of those numbers would work and I have no strong feeling
[20:01] <johnnyfive> nacc, I stand corrected. I did not see that. However there has to be something upstream that makes those lists, but it's obvious that information is not available here
[20:05] <nacc> johnnyfive: aiui, packages in main are seeded (see the seed files) or a dependency of a package in main.
[20:06] <nacc> johnnyfive: i believe germinate is what figures out that full list
[20:06] <nacc> universe is basically everything else, multiverse is non-free (from debian) and partner is a separate archive
[20:08] <sarnold> what's the goal here? if you want to make your own archive mirror but after rebuilding all the packages, you might have more success with https://www.aptly.info/ or the apt-ftparchive package
[20:08] <nacc> johnnyfive: as i said the other day, i thikn you're still better off workingn with ubuntu rather than forking if you think you are solvig a real security problem
[20:08] <nacc> sarnold: i believe johnnyfive is doig an archive rebuild internally to do something like source-address-randomization
[20:08] <nacc> where by source- i mean compile-time
[20:08] <sarnold> nacc: yeah, thanks for the log link :) quite handy
[20:09] <nacc> sarnold: aptly is a good reference, though, i forgot about that oe
[20:10] <johnnyfive> nacc and sarnold, thanks for the answers. Let me try again. My repo serves 100s of variations of the same package, to different customers. At some point, there will be a need for creating indexes of an entire repo on the fly. This is part of my job, to create these repos.
[20:11] <johnnyfive> and by "create these repos", I mean I'm given an output of /pool/main/<packages>, and I need to then create the appropriate index
[20:11] <johnnyfive> however, as you stated, there is no meta information on the deb to tell me whether the file should be indexed in /dists/xenial/main or /dists/xenial-updates/main
[20:12] <johnnyfive> if you run dpkg-scanpackages on /pool/main, it just shoves it all in the same index, without breaking it up into the correct categories
[20:12] <nacc> the package lists only tell you the components ... you would need to follow the publishing iformation, as i mentioned the other day too
[20:12] <nacc> or in your mirror + rebuild solution, save off the pocket things are in
[20:12] <sarnold> johnnyfive: right. the same binary package can be included in lucid, precise, trusty, xenial, zesty, artful, etc.
[20:13] <johnnyfive> so how does ubuntu/debian handle this? is there a build file when they are recreating an entire repo that tells the indexers which files to add to which pocket?
[20:14] <johnnyfive> I don't know what you mean by "publishing information", are you talked about the apt sources list data?
[20:14] <nacc> https://launchpad.net/ubuntu/+source/php7.0/+publishinghistory
[20:14] <nacc> e.g
[20:15] <sarnold> johnnyfive: if this were my problem to solve I thnk I'd skip launchpad, skip germinate, etc., and work strictly from the InRelease and Packages files from the mirrors
[20:16] <sarnold> johnnyfive: stuff in your per-customer md5, sha1, sha256, hashes for all the per-customer rebuilds
[20:17] <johnnyfive> sarnold, that's a def possibility. We have a few solutions, just really trying to understand how upstream does it.
[20:18] <nacc> johnnyfive: also, just to be clear, you very clearly indicate to your customers they are not running Ubuntu? :)
[20:18] <sarnold> heh I'm sure they pay enough to be sure of that :)
[20:18] <johnnyfive> I assume that during the build process, some database is queried to figure out which indexes it needs to be added to
[20:18] <nacc> sarnold: :)
[20:18] <johnnyfive> yes, they know exactly what they are getting
[20:19] <sarnold> johnnyfive: I think https://git.launchpad.net/germinate/tree/README?id=54c933eecf57cfa10526432740cc27f7b7671446 is the starting point..
[20:21] <johnnyfive> Thank you both
[20:21] <johnnyfive> i'll begin more digging. cheers
[20:22] <sarnold> (germinate -might- only do the .iso images! I've been happy to let others manage this ;)
[20:31] <cjwatson> johnnyfive: germinate is very probably too far back in the chain of events for your needs; for republishing an archive, you're better off looking at the override files in /ubuntu/indices/
[20:32] <cjwatson> (germinate is involved, but as the input to human decisions, so you don't want to use it here)
[20:33] <cjwatson> however, override files will tell you which component (main, restricted, universe, multiverse) things live in, but not which versions go in which suites (xenial, xenial-updates, zesty, etc.)
[20:34] <cjwatson> for that, I agree with sarnold - if you want to know what suites packages are published in in bulk, you should look at the published Packages etc. files
[20:34] <sarnold> cjwatson: oh cool, thanks. I've never actually looked in /ubuntu/indices/ before :)
[20:34] <cjwatson> it is possible to derive this from Launchpad queries, but it will be excruciatingly slow to try it that way via the webservice API when you're doing things in bulk
[20:35] <cjwatson> I mean, the Launchpad database is the ultimate source of truth on this and that's what we use, but it will be orders of magnitude faster to get that information from the Packages etc. files instead
[20:35] <cjwatson> because you don't have direct database access
[20:37] <Trevinho> juergh: cool, is it going smoothly still?
[20:37] <cjwatson> you don't need the overrides given the Packages files, though it may make life easier to feed them to apt-ftparchive
[21:39] <johnnyfive> cjwatson, awesome, ty for the info