| robert_ancell | attente, awesome, thanks | 00:31 |
|---|---|---|
| === duflu_ is now known as duflu | ||
| === maclin1 is now known as maclin | ||
| pitti | Good morning | 05:15 |
| hikiko | hi | 05:54 |
| hikiko | desrt, here? | 07:07 |
| hikiko | Trevinho, ? | 07:07 |
| hikiko | mmm too early :) | 07:07 |
| hikiko | I just saw your logs | 07:07 |
| hikiko | anyway, I didn't know gtk didn't provide shape information but anyway the shape is only needed to find the alpha regions, so if gtk has the alpha information we can support windows with alpha | 07:09 |
| hikiko | about the gtk side: I don't know if it's worth the pain to add it | 07:15 |
| hikiko | I just mentioned the problems it will fix | 07:15 |
| === ochosi_ is now known as ochosi | ||
| tjaalton | does anyone know why ~/.Xmodmap is not being used anymore? apparently it broke around 13.10 | 07:21 |
| tjaalton | I guess it's inherited from gnome | 07:26 |
| andyrock | good morning | 07:27 |
| seb128 | good morning desktopers | 08:16 |
| seb128 | hey andyrock tjaalton | 08:16 |
| seb128 | tjaalton, I think gnome(unity)-settings-daemon used to load it, but see https://bugzilla.gnome.org/show_bug.cgi?id=725038#c3 | 08:17 |
| ubot5 | Gnome bug 725038 in keyboard ".XCompose is ignored" [Normal,Resolved: notabug] | 08:17 |
| seb128 | need a script like https://git.gnome.org/browse/gnome-settings-daemon/tree/plugins/common/input-device-example.sh?h=gnome-3-18 it seems | 08:18 |
| tjaalton | seb128: well I meant .Xmodmap, and for that there's https://bugzilla.gnome.org/show_bug.cgi?id=721873 | 08:19 |
| ubot5 | Gnome bug 721873 in Config "xmodmap settings are reset after keyboard layout switching and resume" [Normal,New] | 08:19 |
| seb128 | tjaalton, right, read the bug comment, don't stop to the title :p | 08:19 |
| tjaalton | I did read it | 08:20 |
| tjaalton | that example script link from the bug didn't work | 08:20 |
| tjaalton | but ok | 08:20 |
| tjaalton | this might be a better approach than #6 from https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1243642 :) | 08:21 |
| ubot5 | Launchpad bug 1243642 in xorg (Ubuntu) ".Xmodmap not automatically loaded on start" [Undecided,Confirmed] | 08:21 |
| seb128 | tjaalton, yeah, they removed the file, see the url I copied, it's still in 3.18 | 08:22 |
| tjaalton | yep | 08:22 |
| tjaalton | so I think providing something installed by default that users can use to shoot their foot with might be in order. nothing would be used by default | 08:23 |
| Laney | hullo | 09:03 |
| seb128 | hey Laney! how are you? | 09:06 |
| Laney | hey seb128! | 09:12 |
| Laney | goooooooooooood thanks | 09:13 |
| Laney | although it is cold | 09:13 |
| Laney | we did alright at the quiz but didn't win :-( | 09:13 |
| Laney | how are you? | 09:13 |
| seb128 | it' sunny here! | 09:13 |
| seb128 | can't win everytime | 09:13 |
| seb128 | it wouldn't be special/so nice anymore otherwise! | 09:13 |
| Laney | yeah + everyone hates you then | 09:15 |
| seb128 | so I figured you the other gtk theming issue I was looking at, or at least I found the line to backport to fix it, even if I don't understand what a .entry.flat is :p | 09:18 |
| seb128 | or where the flat style is using for widgets | 09:18 |
| seb128 | but seems that listview is one of those cases and that styling it there fixes the entry height issue | 09:19 |
| ksamak | hoy all | 09:19 |
| Laney | A CSS class that is added when widgets that usually have a frame or border (like buttons or entries) should appear without it. | 09:20 |
| seb128 | where did you get that definition? | 09:24 |
| seb128 | but yeah, in any case it seems like listview editable row is built using a flat entry | 09:24 |
| seb128 | I just don't know if flat entries are used in other context and what side effect that might have :-/ | 09:25 |
| seb128 | but well, adwaita/high contrast have the line I copied so it should be right (but it doesn't mean there isn't some more special cases needed on top) | 09:25 |
| seb128 | the line was added as part of a big commit adding flat style | 09:26 |
| seb128 | so difficult to get a sense for a logic set for the entry case | 09:26 |
| seb128 | oh well, let's do those changes and see if everybody is happy or if we get new reports ;-) | 09:27 |
| Laney | what does the style do? | 09:27 |
| seb128 | it set the padding to 2px | 09:28 |
| seb128 | where normal entries have 5px 7px | 09:28 |
| seb128 | .entry { | 09:28 |
| seb128 | ... | 09:28 |
| seb128 | padding: 5px 7px; | 09:28 |
| seb128 | } | 09:28 |
| Laney | I suppose it makes sense | 09:28 |
| Laney | flat is an entry without a border | 09:28 |
| seb128 | .entry.flat, .entry.flat:focus { | 09:28 |
| seb128 | padding: 2px; | 09:28 |
| Laney | like an inline thingy in a treeview | 09:29 |
| seb128 | what I don't get is that if you set 3px there then it's back to being way to big | 09:29 |
| Laney | the thing I pasted was from devhelp | 09:29 |
| seb128 | 2px feels a bit too shrinked | 09:29 |
| seb128 | oh well, that's going to be good enough | 09:29 |
| seb128 | I wonder if there is an issue like "if it doesn't fit in the row then the un-flat version is used" | 09:30 |
| Laney | https://git.gnome.org/browse/gtk+/tree/gtk/gtkcellrenderertext.c?h=gtk-3-18#n2025 | 09:34 |
| seb128 | Laney, thanks, doesn't explain why 3px making it go unflat (or look like it does, maybe it's something else) though ... but I don't want to spend the week on that, so it's going to stay this way with the 2px which is working | 09:48 |
| alexarnaud | hello everyone ! | 10:07 |
| seb128 | hey alexarnaud | 10:10 |
| alexarnaud | hey seb128, how are you? | 10:17 |
| seb128 | alexarnaud, good, and you? | 10:32 |
| Laney | ricotz: hi, you do zeitgeist upstream stuff right? Trevinho wrote some patches - do you want them upstream? https://launchpadlibrarian.net/236160096/zeitgeist_0.9.16-upstart-and-vacuum-support.debdiff | 10:44 |
| === vrruiz_ is now known as rvr | ||
| desrt | hello world\n | 11:43 |
| desrt | hikiko: hey | 11:43 |
| ricotz | Laney, hi, interesting, the upstart parts not so, a systemd service for the vaccum part would be better | 11:44 |
| Trevinho | ricotz: well, I don't know much about systemd services (yet) :) | 11:44 |
| ricotz | Trevinho, ok, upstart is dead though | 11:45 |
| Trevinho | ricotz: well, not for us :) | 11:45 |
| Trevinho | at least, not in session | 11:45 |
| Trevinho | for some time | 11:45 |
| Trevinho | but I understand | 11:45 |
| ricotz | Trevinho, maybe you can take a look at making them systemd ones | 11:46 |
| Trevinho | ricotz: I could, but... Not in short time I think | 11:46 |
| Trevinho | ricotz: as for the vacuum side, I also was wondering whether removing some old data would be somewhat wanted... | 11:47 |
| Laney | ricotz: is systemd in the session a real thing yet? | 11:47 |
| Laney | it's not on our side, anwyay | 11:47 |
| Trevinho | ricotz: I mean, I've the same db here I had during 10.10... So it's getting about 95MB sqlite file... This causes my zeitgeist-fts to use about 700-800Mb of resident memory. Always. Not sure whether it's a leak or something wrong with that (I had no time to play with massif yet) | 11:48 |
| Trevinho | that indeed slows down the searches... | 11:48 |
| Trevinho | Laney: ah, not related to this, but if you can publish https://requests.ci-train.ubuntu.com/#/ticket/1029 then seb128 could get his GS icon before beta.. :) | 11:49 |
| ricotz | Trevinho, "vaccum" isnt removing real data, just reorganize and drop unlinked data from the persistent file? | 11:49 |
| Trevinho | ricotz: yes, no removal | 11:50 |
| ricotz | Laney, hmm, I thought so it would | 11:50 |
| Trevinho | ricotz: it rebuilds avoiding fragmentation | 11:50 |
| ricotz | Trevinho, right | 11:50 |
| Laney | ricotz: anyway, we can handle that in the package but the vacuum program is probably good for you | 11:51 |
| ricotz | Trevinho, so having an option to drop old data could be interesting too | 11:52 |
| ricotz | Laney, absolutely | 11:52 |
| Laney | Trevinho: the normal thing to do for upstart is to disable xdg autostart by putting a desktop file in /usr/share/upstart/xsg/autostart with Hidden=true | 11:55 |
| * Laney will change that | 11:55 | |
| Laney | s/xsg/xdg/ | 11:56 |
| Laney | Trevinho: what's with this runner stuff? | 12:06 |
| hikiko | hi desrt | 12:36 |
| desrt | hey hikiki.. wanted to talk about the shadows | 12:39 |
| desrt | you used xshape? | 12:40 |
| Laney | hey desrt! | 12:40 |
| * Laney missed your 'hi' | 12:40 | |
| desrt | morning, laney :) | 12:40 |
| seb128 | hey desrt | 12:44 |
| desrt | hello all you latecomers | 12:44 |
| === alan_g is now known as alan_g|lunch | ||
| === hikiko is now known as hikiko|ln | ||
| === hikiko|ln is now known as hikiko | ||
| hikiko | lol desrt say hikiko pls | 13:10 |
| hikiko | I didn't see it | 13:10 |
| desrt | oops. typo :) | 13:10 |
| hikiko | /nick hikiki | 13:11 |
| hikiko | yes I used xshape, to find the alpha | 13:11 |
| hikiko | there are 3 different bugs related to the gtk windows the 2 of them can be solved unity-compiz side | 13:12 |
| desrt | ah.... iirc that's not what we discussed | 13:12 |
| desrt | the idea was to use the content of the pixels | 13:12 |
| hikiko | that's what I used I took it from the shape rectangles, I just didn't know that gtk windows don't provide us with shape info so I have to do it 1 more time for windows with alpha and not shape | 13:13 |
| hikiko | this will fix the shadows shape | 13:14 |
| hikiko | but not the black dots | 13:14 |
| hikiko | which is a different prob I am trying to fix now | 13:14 |
| hikiko | black dots are caused by buggy alpha blending somewhere in compiz | 13:14 |
| hikiko | I am debugging the opengl plugin | 13:14 |
| hikiko | they should be transparent | 13:14 |
| hikiko | and there's a 3rd issue | 13:16 |
| hikiko | but I don't know if gtk is maintained by us and we should fix it | 13:16 |
| hikiko | ideally the alpha windows should provide the shape too | 13:16 |
| hikiko | because if they don't, window managers will consider the transparent parts parts of the window | 13:17 |
| hikiko | and will receive events there | 13:17 |
| hikiko | anyway I guess that's not very important | 13:17 |
| === Guest92168 is now known as fredp | ||
| === fredp is now known as Guest86707 | ||
| ricotz | Trevinho, btw, you should not leave those print() statements in | 13:38 |
| alexarnaud | seb128: very good thanks | 13:40 |
| Trevinho | Laney: so, I was having lunch... Well, in order to make sure that dbus launches the upstart instance we need that... I'm doing that also in bamf. Since there's no support for upstart to launch dbus daemons and controlling them (It was something planned in theory, and documented too, but reverted for some reason) | 13:45 |
| Trevinho | ricotz: well... I wanted to add some output... | 13:45 |
| Trevinho | ricotz: and without any other logging... It had to be a very simple script (which I couldn't do in python because of the gir dependency which I didn't want to include) | 13:46 |
| === hikiko is now known as hikiko|ln | ||
| Trevinho | hikiko|ln: let's go for a different solution, I'll work on it in the mean time... You can go back focusing in the ezoom thing since it's getting late. | 13:47 |
| ricotz | Trevinho, hmm, ok, FAIL needs a \n then | 13:54 |
| Trevinho | ricotz: no, because of the warning... It will add it | 13:54 |
| ricotz | or a some separation | 13:54 |
| Trevinho | I added that in both cases initially... Then, it wasn't needed. | 13:54 |
| Laney | Trevinho: https://paste.ubuntu.com/15187274/ ? | 13:56 |
| === alan_g|lunch is now known as alan_g | ||
| Trevinho | Laney: ehm, yeah, what? | 13:59 |
| Laney | what? | 13:59 |
| Trevinho | Laney: ah, you changed something? | 14:00 |
| Laney | yes, I eliminated all the upstart stuff | 14:00 |
| Trevinho | Laney: well, having upstart to manage it would have ensured that the service would have ran only when needed, and that could have been controlled by initctl... With actual respawn and such. | 14:01 |
| Laney | dbus will launch it again anyway | 14:02 |
| Trevinho | but if you prefer this way... | 14:03 |
| Laney | you only really needed it to make an event that the vacuum event could block | 14:03 |
| Trevinho | Yeah, well, it will relaunch it when invoked... | 14:03 |
| Trevinho | BUt it's fair, I would just have loved it to be controlled by upstart as it allows better management for us, and some logging... But indeed your version reduces a lot the diff with upstream and so it's more easy to manage (not that I expect many changes upstream side) | 14:04 |
| Laney | it goes in the journal if launched by dbus which is nice :-) | 14:10 |
| Laney | thanks, going to upload this | 14:10 |
| * Laney enjoys fast dash | 14:10 | |
| Laney | it feels like it makes a big difference | 14:10 |
| === hikiko|ln is now known as hikiko | ||
| seb128 | new snappy dash! ;-) | 14:15 |
| hikiko | Trevinho, let's wait for will because I think he expects that I solve the 2 issues | 14:17 |
| Laney | lunch then bike to tea shop in town | 14:22 |
| Laney | biab | 14:22 |
| seb128 | Laney, enjoy! | 14:22 |
| seb128 | hikiko, I think it has been ongoing for long enough that it seems at risk for this cycle (we are past ff) and that we look for a plan B, that doesn't stop you to keep working on it, once it's working well we can see what we do, either push it or keep it on the side and use it next cycle | 14:23 |
| hikiko | ok | 14:24 |
| seb128 | hikiko, but we are saying that it's almost ready to land since january, that proved to not be that simple and it's safe to have a fallback solution | 14:24 |
| hikiko | sure | 14:26 |
| hikiko | but I think I could give it a try | 14:27 |
| seb128 | hikiko, thanks for the work on fixing those issues btw ;-) | 14:27 |
| hikiko | until next week | 14:27 |
| hikiko | because, I think I'm close | 14:27 |
| seb128 | yeah, that seems ok if you look at it a bit more | 14:28 |
| hikiko | (I'm not opposed to plan B) | 14:28 |
| seb128 | Trevinho can think about plan B meanwhile | 14:28 |
| seb128 | and we can see what we do next week | 14:28 |
| hikiko | okie! | 14:28 |
| seb128 | Trevinho, andyrock, thanks for the unity/gnome-software integration landing! | 14:28 |
| desrt | what stops us from simply setting an xshape from gtk? | 14:47 |
| desrt | i mean, other than the "it will be hard" crap | 14:47 |
| desrt | "we may have to do some math" | 14:48 |
| desrt | i guess, in any case, i'd prefer not to do the math, given that we have a working solution in the form of Trevinho's property | 14:48 |
| Sweet5hark | seb128: so, seems I cant push to the seeds bzr repo directly (would have been surprised if I could really), so how do I get https://code.launchpad.net/~bjoern-michaelsen/ubuntu-meta/libreoffice-human-to-breeze merged for bug 1506544? | 14:56 |
| ubot5 | bug 1506544 in ubuntu-meta (Ubuntu) "Change default Theme for LibreOffice to Breeze for Ubuntu 16.04" [Undecided,New] https://launchpad.net/bugs/1506544 | 14:56 |
| seb128 | Sweet5hark, seems like from the url that you used the wrong vcs? | 14:57 |
| seb128 | Sweet5hark, you should branch lp:~ubuntu-core-dev/ubuntu-seeds/ubuntu.xenial edit, commit push to lp:~bjoern-michaelsen/ubuntu-seeds/<something> then merge propose it | 14:58 |
| seb128 | the deb is built from the seed then by whoever does an upload | 14:59 |
| seb128 | no need to merge anything to the source | 14:59 |
| Sweet5hark | seb128: I branched from that, but I _think_ lp was resisting pushing/creating that branch ... but it works now, so I must have gotten it wrong. | 15:03 |
| Sweet5hark | seb128: ok, pushed to ~bjoern-michaelsen/ubuntu-seeds/human-to-breeze now and added to bug, and now (after I pushed to the right location) it also works to merge propose it: https://code.launchpad.net/~bjoern-michaelsen/ubuntu-seeds/human-to-breeze/+merge/287035 | 15:08 |
| Sweet5hark | seb128: thx | 15:08 |
| seb128 | Sweet5hark, thanks | 15:08 |
| ricotz | Sweet5hark, seb128, hi, would it be possible to do something about the size of the libreoffice icons (svgs), they are way to huge to be rendered in a reasonable time | 15:40 |
| ricotz | https://paste.debian.net/plain/403057 | 15:42 |
| Sweet5hark | ricotz: hmmm, isnt that an upstream topic? I dont think only vendor patching that is helpful ... | 15:42 |
| ricotz | Sweet5hark, it is, and you are upstream ;) | 15:43 |
| Sweet5hark | ricotz: heh ;) | 15:43 |
| ricotz | I am wondering if there are complaints about it | 15:44 |
| ricotz | like 1.3M for an icon is insane | 15:44 |
| ricotz | given it takes like 200ms to render this *only* this single icon it should also effect the performance of unity's application dash | 15:45 |
| ricotz | (at least on the time if it gets cached afterwards) | 15:46 |
| Sweet5hark | ricotz: yeah, that is indeed unfortunate -- esp. since the icons arent really complex artwork anyway, so this is weird. | 15:57 |
| Sweet5hark | ricotz: https://github.com/LibreOffice/core/commit/250feedd8e50e5eb52682a194823567ba5287c60 <- take this as a starting point. doesnt seem to have been touched since then anymore (and pmladek isnt active on libreoffice anymore) | 15:58 |
| Sweet5hark | ricotz: would be something to bring up with https://wiki.documentfoundation.org/Design | 15:58 |
| ricotz | Sweet5hark, I see, could you make the current best person aware of that? | 16:13 |
| Sweet5hark | ricotz: best file a bug upsteam with component UX-advise ... | 16:16 |
| pitti | Laney: bah, these worker emails are annoying -- I want my scalingstacks cleaned!!! | 16:19 |
| Laney | pitti: indeed! | 16:19 |
| pitti | Laney: but the lxd upgrade one this morning was a good warning (as it was an actual upgrade failure), so I don't really want to quiesce them either | 16:19 |
| * Laney noticed that one | 16:19 | |
| Laney | are the rest just waiting for IS to whack stuff? | 16:19 |
| pitti | yeah, the two RTs I sent on Monday | 16:19 |
| pitti | there's always some DB resource leakage, but it went quite out of hand on lgw | 16:20 |
| pitti | with 0 instances it claims I use 43 GB RAM | 16:20 |
| Laney | awesome that it stores this separately in a buggy way | 16:21 |
| ricotz | Sweet5hark, https://bugs.documentfoundation.org/show_bug.cgi?id=98141 | 16:34 |
| ubot5 | bugs.documentfoundation.org bug 98141 in ux-advise "SVG application icons too large/detailed" [Normal,Unconfirmed] | 16:34 |
| Laney | pitti: OOI, do you know why this didn't take down the lxd tests themselves too? | 16:39 |
| Laney | it seems to not have been an upgrade there but I don't know why | 16:39 |
| pitti | Laney: good question | 16:40 |
| pitti | Laney: actually, the better question is why we got an upgrade of lxd during that (whatever) test | 16:40 |
| pitti | I purge lxc/lxd from the base images | 16:40 |
| Laney | I assumed it was in the... oh | 16:40 |
| pitti | so any test dependency should be a new install, not an upgrade | 16:40 |
| pitti | oh, wait | 16:41 |
| pitti | I purge lxd-client | 16:41 |
| pitti | and lxd doesn't depend on lxd-client (... any more), only recommends: | 16:41 |
| pitti | so I guess lxd is back in the base images | 16:41 |
| * pitti updates the setup script to purge it harder | 16:41 | |
| === davidcalle is now known as davidcalle_afk | ||
| Laney | so then why didn't it upgrade for lxd itself? | 16:42 |
| pitti | https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/l/lxd/20160224_051542@/log.gz | 16:44 |
| pitti | this was a new install of lxd (version 2.0.0~beta4-0ubuntu1, the broken one) | 16:44 |
| pitti | Laney: perhaps that was the version which demoted Depends: to Recommends:? | 16:44 |
| * pitti checks | 16:45 | |
| pitti | hm, no | 16:45 |
| pitti | so one way or the other it wasn't on the images on that run | 16:45 |
| Laney | just wondering if we could have caught the breakage before it got to release :) | 16:46 |
| pitti | if lxd *was* on the images, then yes | 16:47 |
| pitti | but my intention is that the images are minimal | 16:47 |
| pitti | so we indeed don't do upgrade testing in adt, except for stuff which is in the base system | 16:47 |
| pitti | The following packages will be upgraded: | 16:48 |
| pitti | apparmor bind9-host dnsutils fuse isc-dhcp-client isc-dhcp-common | 16:48 |
| pitti | libapparmor-perl libapparmor1 libelf1 libfuse2 lxd lxd-client os-prober | 16:48 |
| pitti | that was in the log of content-hub/i386 from this morning which exhibited the problem | 16:49 |
| pitti | hah! | 16:49 |
| * Laney ran away | 16:49 | |
| pitti | Laney: Creating nova instance adt-xenial-i386-content-hub-20160224-095421 from image ubuntu/ubuntu-xenial-daily-i386-server-20160223.1-disk1.img | 16:49 |
| pitti | Laney: got it | 16:49 |
| Laney | yes I was just looking to check that | 16:49 |
| Laney | Creating nova instance adt-xenial-amd64-lxd-20160224-051102 from image ubuntu/ubuntu-xenial-adt-amd64-server-20160224.img (UUID 18c30873-e2a8-4f44-80de-5e44b3cb3049)... | 16:49 |
| Laney | from lxd | 16:49 |
| pitti | Laney: content-hub used a standard image while the earlier lxd used an adt pre-prepared image | 16:49 |
| Laney | is that an accident? | 16:50 |
| pitti | on bos01 I actually fixed the configuration to only use *adt* images | 16:50 |
| pitti | but this morning building the adt i386 image failed on lgw | 16:50 |
| pitti | so we don't have recent adt ones everywhere | 16:50 |
| pitti | Laney: so I could do the same as on bos and create adt images for all stable releases, and only use adt images | 16:51 |
| pitti | normally, it's "all images which match $release-$arch, take the most recent one" | 16:51 |
| pitti | so that we can take the standard cloud images for stable (or for devel if the daily build fails) | 16:52 |
| pitti | I did that on bos for ppc64 as standard cloud images have been seriously broken for several weeks now | 16:52 |
| pitti | ok, so we know *why* it happened; it's less clear which way around we want to make that more predictable | 16:53 |
| pitti | we have the really expensive way of always building/using adt images | 16:54 |
| pitti | or live with that jitter | 16:55 |
| Laney | is it really costly to do it? | 16:55 |
| pitti | Laney: it's immense on lcy01 (as only one attempt out of 20 succeeds) | 16:55 |
| Laney | sigh | 16:55 |
| pitti | it's almost always failing on lgw (due to the resource scarcity) | 16:56 |
| pitti | and reasonably straightforward on bos | 16:56 |
| Laney | Maybe run a version of the setup script each time? | 16:56 |
| pitti | we do | 16:56 |
| pitti | so it'll do that removal dance | 16:57 |
| Laney | must be after dist-upgrading though | 16:57 |
| pitti | but so far I only purged lxd-client, not lxd | 16:57 |
| pitti | I just committed a fix to purge lxd and lxc too | 16:57 |
| Laney | or why was the adt image okay? | 16:57 |
| pitti | so in that sense that will make it predictable again | 16:57 |
| pitti | Laney: because that got dist-upgraded from like wily, where lxd wasn't on the default install yet | 16:57 |
| Laney | haha | 16:57 |
| pitti | (we've only had real xenial images for two or three weeks) | 16:58 |
| Laney | pitti: Okay, I guess this situation is good enough then until the l* regions get upgraded to a better openstack or whatever | 16:58 |
| pitti | Laney: with the setup script fix I just committted, lxd will at least be gone in both scenarios | 16:58 |
| pitti | thus be predictable, i. e. adt or standard image should behave the same again, except that tests with the latter take 3 mins longer | 16:59 |
| Laney | Can we ditch the adt image on bos01? | 16:59 |
| pitti | nooo | 16:59 |
| pitti | well, not for ppc64el | 16:59 |
| pitti | standard cloud ppc64 images are broken, they don't boot | 17:00 |
| pitti | my life is so much fun | 17:00 |
| * Laney screams | 17:00 | |
| pitti | Laney: https://bugs.launchpad.net/cpc-core/+bug/1541757 FYI | 17:00 |
| ubot5 | Error: launchpad bug 1541757 not found | 17:00 |
| pitti | yeah yeah, it's private but there | 17:01 |
| pitti | dinner o'clock | 17:01 |
| Laney | see you | 17:01 |
| * Laney just filed a bug about doing upgrade testing | 17:01 | |
| Laney | could be interesting | 17:01 |
| === alan_g is now known as alan_g|EOD | ||
| ximion | Laney, new AppStream release with all known bugs fixed will be out next weekend | 19:33 |
| ximion | meanwhile, removing the appstream-data package from Xenial would be helpful, because it causes the old data and the new data to collide (LP: #1548157) | 19:33 |
| ubot5 | Launchpad bug 1548157 in appstream-data (Ubuntu) "Remove appstream-data from Ubuntu (xenial)" [Undecided,New] https://launchpad.net/bugs/1548157 | 19:33 |
| ximion | is only noticed by people who have it installed, which is mainly KDE on Xenial | 19:34 |
| === ljp is now known as lpotter | ||
| Laney | thanks ximion! | 20:37 |
| Laney | I can't process that but maybe someone who can will see the link ;-) | 20:37 |
| ximion | Laney: that was my plan all along ;-) | 20:39 |
| ximion | I am also playing around with the idea of writing a more powerful data extractor in Go or D | 20:40 |
| ximion | not yet sure what will come out of this (if it's productive at all), but playing with new languages is fun :) | 20:40 |
| Laney | ximion: can we put a date into the yaml header please? | 20:44 |
| Laney | I have a suspicion that launchpad is being weird | 20:44 |
| ximion | Laney: I didn't want to put a date in there, since this will cause APT to re-download the data everytime, even if *only* the last-updated date has changed, causing useless downloads | 20:46 |
| Laney | ximion: couldn't you skip updating the file at all if nothing has changed? | 20:46 |
| ximion | implementing a way to find out if data has changed and only updating the date when the data actually changed would be the sane thing to do, but that is more work to implement | 20:46 |
| Laney | much more? | 20:47 |
| ximion | we would maybe need to hash all data and see if the hash has changed... - if LMDB returns components in a deterministic order | 20:47 |
| ximion | (which AFAIR it does...) | 20:47 |
| Laney | just thinking some flag if we found a component to update | 20:48 |
| ximion | atm, I would say quite some work, unless everything happens to work as one would expect ^^ | 20:48 |
| Laney | ximion: so here https://github.com/ximion/appstream-dep11/blob/master/dep11/generator.py#L51 return a tuple (msgtxt, len(cpts)) and then here https://github.com/ximion/appstream-dep11/blob/master/dep11/generator.py#L213 set a flag to tell you to skip writing if nothing changed | 20:55 |
| ximion | Laney: if you check whether the returned components are valid or not, this should work... | 21:00 |
| Laney | i'll try tomorrow or so | 21:01 |
| ximion | weird, my mind was thinking about a completely different project a few minutes ago :P | 21:01 |
| ximion | ok, a feature like this sounds sane to me | 21:01 |
| Laney | I'm just a bit suspicious | 21:01 |
| Laney | because I don't see apt downloading the new files for me very often | 21:01 |
| Laney | but maybe they didn't actually change, but then the mtime has changed | 21:02 |
| Laney | but that could be because we write them even if nothing changed | 21:02 |
| Laney | so! | 21:02 |
| ximion | Laney: could also be one of the terrible multiprocessing issues, e.g. the one eating up logging data | 21:02 |
| Laney | will at least be some information to go on | 21:03 |
| seb128 | robert_ancell, is there an easy way to tell what gnome-software bugs are downstream or upstream? | 22:00 |
| robert_ancell | seb128, you kind of need to know which plugin the bug is coming from | 22:02 |
| robert_ancell | seb128, Anything in particular you want triaged? | 22:02 |
| seb128 | robert_ancell, reported rather | 22:03 |
| robert_ancell | seb128, today, any bugs relating to apt installing / removing are us (distro patch), bugs relating to wrong information are probably appstream (not sure how much of that is us / upstream), though they may be incorrectly interpreted in g-s (us or upstream). Anything related to submitting reviews is us, downloading is technically upstream but practically us. | 22:04 |
| seb128 | robert_ancell, ok, some ones | 22:04 |
| robert_ancell | In short, just file against gnome-software and ping me is probably the safest method | 22:04 |
| seb128 | - clicking on updates give little details | 22:04 |
| seb128 | http://people.canonical.com/~seb128/gnomesoftware.png | 22:04 |
| seb128 | at less the (null) in the title is buggy | 22:04 |
| robert_ancell | seb128, I believe that content supposed to be provided in appstream, I haven't looked yet though. | 22:05 |
| seb128 | also could we fetch changelogs from the same server update-manager does (is that supposed to work?) | 22:05 |
| robert_ancell | The null is worrying, because that should show the package name | 22:05 |
| robert_ancell | seb128, this is where is gets complicated. The information can come from any plugin. So I think the vision is that appstream provides all opf this, it just doesn't do the actual installing / removing | 22:06 |
| robert_ancell | But we can provide all the information ourselves in the apt plugin. | 22:06 |
| robert_ancell | And I think that will be the practical solution for many cases. | 22:06 |
| seb128 | i think it was working when I tried a week or so ago | 22:06 |
| seb128 | k | 22:06 |
| seb128 | so like that one, I better report on launchpad? | 22:07 |
| seb128 | we can triage from there | 22:07 |
| robert_ancell | seb128, yes, definitely report on LP first | 22:07 |
| robert_ancell | Then ping Laney / ximion and say "should this info come from appstream?" | 22:07 |
| robert_ancell | seb128, then you can try appstreamcli/appstream-util to try and work out if that information is present. And if it is, then it's a GNOME Software bug | 22:08 |
| seb128 | things are listed fine in other sections | 22:09 |
| seb128 | the (null) is just in the update section | 22:09 |
| seb128 | robert_ancell, btw it still thinks that softwares come from third party/non free | 22:19 |
| robert_ancell | seb128, both third party and non-free? | 22:20 |
| robert_ancell | seb128, can you run with G_MESSAGES_DEBUG=all and check the app summary when you click on it? | 22:20 |
| robert_ancell | That will show all the metadata we have | 22:20 |
| seb128 | robert_ancell, http://people.canonical.com/~seb128/nonfree.png | 22:21 |
| robert_ancell | seb128, ah, the source field is blank for some reason | 22:22 |
| robert_ancell | That's the info that is used to determine where it came from | 22:22 |
| seb128 | oh | 22:22 |
| seb128 | I might have dpkg -i that one, sorry | 22:22 |
| robert_ancell | I'm thinking of just setting those in the apt plugin instead of relying on appstream | 22:22 |
| robert_ancell | seb128, as long as the package name is still standard it should show information | 22:23 |
| seb128 | ok, others seems just "non-free" | 22:23 |
| seb128 | sorry, closed wrong win | 22:25 |
| robert_ancell | But yeah, I suspect G-S picked up the .desktop file for that but there is no appstream data for some reason | 22:25 |
| seb128 | hum, it doesn't list evince | 22:39 |
| seb128 | (gnome-software:32072): Gs-DEBUG: ignoring duplicate evince.desktop | 22:40 |
| seb128 | that might be one for Laney | 22:41 |
| ximion | robert_ancell: might be due to Ubuntu wanting to keep the old .desktop filenames for eternity | 22:44 |
| ximion | AS and GS don't expect that | 22:45 |
| ximion | robert_ancell: might be due to Ubuntu wanting to keep the old .desktop filenames for eternity | 22:45 |
| ximion | AS and GS don't expect that | 22:45 |
| ximion | I'm just guessting though - components with an empty ID or name must never happen | 22:45 |
| Laney | ximion: stop trying to blame everything on that :( | 23:29 |
| Laney | it made duplicate applications show up, and should be patched now (with a different approach to my as-glib patch) | 23:30 |
| Laney | I just tried latest g-s and it doesn't show any uninstalled applications ("(gnome-software:13300): Gs-DEBUG: app invalid as state unknown robocode.desktop | 23:31 |
| Laney | ") | 23:31 |
| Laney | going back to https://launchpad.net/ubuntu/+source/gnome-software/3.19.5+git20160212.a64f331-0ubuntu1/+build/9000701 works | 23:31 |
| ximion | Laney: that robocode-is-missing issue strikes again? | 23:31 |
| Laney | yeah | 23:32 |
| Laney | and everything else | 23:32 |
| ximion | really weird... | 23:32 |
| ximion | appstream-glib hasn't changed, and that is the critical part when it comes to reading metadata properly | 23:32 |
| Laney | it's some g-s change between 3.19.5+git20160212.a64f331-0ubuntu1 and 3.19.91~git20160224.0779986-0ubuntu1 | 23:32 |
| Laney | because reverting makes it come back | 23:33 |
| ximion | does the apt backend set the app state to AVAILABLE or INSTALLED? | 23:33 |
| Laney | ximion: not sure, if you want to look I think https://git.gnome.org/browse/gnome-software/tree/?h=wip/rancell/apt should be current | 23:37 |
| * Laney has to go to bed now though, sorry! | 23:37 | |
| Laney | night | 23:37 |
| ximion | the message suggests that the app state is never set and remains on it's initial value | 23:38 |
| ximion | ok | 23:38 |
| * ximion should sleep too | 23:38 | |
| ximion | gn8 | 23:38 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
