| didrocks | good morning | 05:41 |
|---|---|---|
| duflu | Morning didrocks | 05:46 |
| jibel | morning all | 05:50 |
| didrocks | hey duflu, jibel | 05:50 |
| duflu | Morning jibel | 05:56 |
| oSoMoN | good morning desktoppers | 06:36 |
| didrocks | salut oSoMoN | 06:42 |
| duflu | Morning oSoMoN | 06:44 |
| oSoMoN | salut didrocks, hey duflu | 06:46 |
| seb128 | gooood morning desktopers | 07:18 |
| oSoMoN | salut seb128 | 07:18 |
| seb128 | lut oSoMoN, wb! did you have good holidays? | 07:19 |
| oSoMoN | yes, I had a really good time off. what about you? | 07:19 |
| seb128 | same, no computer, nice weather, being outside was good and food was great | 07:24 |
| seb128 | my shoulders were glad when we stopped walking though, the kid didn't want to walk much and ended up spending most of the days in the backpack | 07:25 |
| didrocks | hey seb128 | 07:25 |
| seb128 | lut didrocks, en forme ? | 07:25 |
| didrocks | ça va, et toi ? | 07:25 |
| seb128 | ça va bien :) | 07:29 |
| seb128 | busy week though, post holidays catchup + new GNOME + Paris to prepare | 07:30 |
| didrocks | still on catchup? good luck! | 07:30 |
| seb128 | I did email/trello/active topics on monday and I'm done with those | 07:34 |
| seb128 | I didn't look at bugs reports and such though, which I want to do at this point of the cycle to have an idea where we stand and potential bugs to rls tag at least | 07:34 |
| Laney | 0\ 0\ 0\ | 08:00 |
| marcustomlinson | morning seb128 didrocks willcooke Laney and wb oSoMoN | 08:01 |
| Laney | good anticipation marcustomlinson | 08:01 |
| willcooke | morning all y'all | 08:01 |
| seb128 | hey marcustomlinson, willcooke, Laney | 08:01 |
| oSoMoN | good morning marcustomlinson | 08:01 |
| oSoMoN | good morning willcooke | 08:01 |
| didrocks | hey marcustomlinson, Laney, willcooke | 08:01 |
| marcustomlinson | what a friendly bunch :) | 08:03 |
| seb128 | Laney, I think we should maybe skip at-spi2-atk/s390X (http://autopkgtest.ubuntu.com/packages/a/at-spi2-atk/eoan/s390x) autopkgtests, they worked once but they are new and I don't think they are indicating any real regression by failing atm | 08:23 |
| seb128 | we should still figure that out, but debugging accessiblity on s390x is probalby not our priority atm | 08:23 |
| seb128 | wdyt? | 08:23 |
| Laney | maybe | 08:27 |
| Laney | especially if you can say that it's a problem that doesn't affect other arches | 08:28 |
| Laney | not just e.g. because s390x is way fast | 08:28 |
| seb128 | the tests hit a SIGTRAP on s390x so probably a really binary problem than timing | 08:29 |
| seb128 | well could be resulting from timing issues... | 08:30 |
| seb128 | I didn't debug much so far | 08:30 |
| Laney | ok | 08:35 |
| Laney | looks like gvfs has become sad | 08:59 |
| seb128 | samba? | 09:01 |
| seb128 | not only | 09:01 |
| seb128 | bah :-/ | 09:01 |
| Laney | :( | 09:07 |
| seb128 | no, it's the trash test, but diffing the last good and failing log I can't see a lot of depends changed | 09:07 |
| seb128 | gcc, cups, mesa | 09:08 |
| seb128 | but that looks like the same flackyness we have been having for a while | 09:09 |
| Laney | more ignoring of it? | 09:10 |
| seb128 | or retrying | 09:10 |
| seb128 | I mean https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan/eoan/amd64/g/gvfs/20190826_213835_f43da@/log.gz | 09:10 |
| seb128 | from aug 26 was the same error | 09:10 |
| seb128 | and it worked after retrying | 09:10 |
| seb128 | but yeah, another one we should probably look at once rush of updates & co is over | 09:11 |
| Laney | I've been flagging gvfs for a long time now, so agreed it would be good to actually do it | 09:12 |
| seb128 | agreed, let's deal with that once GNOME 3.34 is done | 09:14 |
| === JanC_ is now known as JanC | ||
| oSoMoN | ricotz, hey, could you please push your changes to the firefox-beta.* branches? | 10:53 |
| frederikf[m] | test | 11:46 |
| seb128 | hey frederikf[m] :) | 11:46 |
| frederikf[m] | omg... hi! I wont tell how long it took me to connect freednode to riot... | 11:47 |
| seb128 | frederikf[m], trying matrix? ;) | 11:51 |
| willcooke | hi frederikf[m] | 11:52 |
| frederikf[m] | Yeah :| I thought it's so easy but it looks like I am a spoiled telegram user being too stupid to use all these stuff.. irc... matrix :) | 11:53 |
| clobrano | frederikf[m]: hi! may I suggest you irccloud? :) | 12:03 |
| frederikf[m] | <clobrano "frederik.f: hi! may I suggest yo"> I think I got it now thanks to this tutorial: https://jon.sprig.gs/blog/post/497 | 12:20 |
| Trevinho | weechat and a bouncer is the way :-P. I spent days in getting riot to behave as I wanted with a custom irc server but no.... | 12:34 |
| Trevinho | BTW hi :-) | 12:35 |
| frederikf[m] | hi :) | 12:39 |
| seb128 | hey Trevinho, how are you? | 12:41 |
| Trevinho | seb128: hi Seb, all good... | 12:59 |
| Trevinho | you? | 12:59 |
| seb128 | Trevinho, I blocked a bit my back which is annoying but otherwise good! | 13:00 |
| ricotz | oSoMoN, hi, will try to push it in the evening | 13:09 |
| ricotz | oSoMoN, regarding the clang usage, I am not so convinced with your approach, while this can all be done in debian/config/mozconfig.in ? | 13:11 |
| === jdstrand_ is now known as jdstrand | ||
| willcooke | hey marcustomlinson, did you snap up a gnome extension? | 13:38 |
| willcooke | ever | 13:39 |
| marcustomlinson | willcooke: I haven't myself, I know ken has done at least one | 13:39 |
| willcooke | oki, np | 13:40 |
| kenvandine | not an extension :) | 13:40 |
| marcustomlinson | (I read that differently from how it was written - assuming what was meant was snapped something using the extension) | 13:40 |
| willcooke | So general question then... frederikf[m] has written a gnome extension to allow you to easily switch themes. He was asking about getting it packaged. I wondered if we could snap it, could be a whole lot quicker | 13:40 |
| marcustomlinson | oh! | 13:41 |
| marcustomlinson | right, confusing the snapcraft gnome-extension | 13:41 |
| willcooke | oh, sorry :) | 13:41 |
| kenvandine | yeah :) | 13:42 |
| kenvandine | so i think it might iterate $XDG_DATA_DIRS | 13:43 |
| seb128 | makes things easier :) | 13:43 |
| kenvandine | but not a silver bullet | 13:43 |
| frederikf[m] | I forked it and changed it to work for ubuntu: | 13:44 |
| frederikf[m] | https://i.imgur.com/OQamWtx.gif | 13:44 |
| marcustomlinson | frederikf[m]: nice | 13:46 |
| mgedmin | nice | 13:47 |
| marcustomlinson | I'm just trying to think now how a snap could be installed such that gnome could discover the extension inside | 13:49 |
| marcustomlinson | will likely need a post-install script | 13:54 |
| clobrano | frederikf[m]: very nice! Does it change gtk variant only, or also shell one? | 13:55 |
| frederikf[m] | only the gtk theme sadly | 13:55 |
| clobrano | I see | 13:55 |
| oSoMoN | ricotz, thanks. agreed that if everything can be done in d/config/mozconfig.in, that's better, let's tweak this in the beta branches once you have pushed your changes | 14:04 |
| frederikf[m] | <marcustomlinson "frederik.f: nice"> here is the repo https://github.com/Feichtmeier/gnome-shell-extension-dark-theme-toggle | 14:12 |
| xnox | willcooke: error: cannot validate seed: | 14:25 |
| xnox | - cannot use snap "gnome-calculator": default provider "gtk-common-themes" is missing | 14:25 |
| xnox | willcooke: is layered images work maintained at all? or is it dead? | 14:26 |
| xnox | hmmm | 14:28 |
| xnox | but looks like above was fixed in https://bugs.launchpad.net/bugs/1772844 | 14:28 |
| ubot5 | Launchpad bug 1772844 in snapd "snapd didn't initialize all the seeded snaps" [High,Fix released] | 14:28 |
| xnox | hm | 14:28 |
| Laney | no it's not | 14:28 |
| Laney | this is something else - livecd-rootfs is validating the snapd seed.yaml as it is being created | 14:29 |
| Laney | and it must be that some of the intermediate steps here are invalid | 14:29 |
| Laney | we turned off that for regular distro image builds but I guess this one is using something else | 14:31 |
| ricotz | oSoMoN, ok, I will force push the beta branches | 14:32 |
| oSoMoN | ricotz, I think I merged back the changes from the stable branch only for xenial, the others shouldn't require a force-push | 14:33 |
| xnox | Laney: looks like it's sorted wrong. | 14:33 |
| xnox | Laney: https://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.eoan/desktop-minimal.snaps has things not in the order of seed text =/ | 14:33 |
| xnox | and the order matters | 14:34 |
| ricotz | oSoMoN, ok | 14:34 |
| xnox | Laney: do you remember where/how "turned off that for regular distro image builds" => was that in livecd-rootfs? | 14:34 |
| Laney | yes | 14:35 |
| Laney | "wrong" | 14:35 |
| Laney | the order doesn't really matter | 14:36 |
| Laney | desktop isos do work | 14:36 |
| xnox | Laney: well, the snap seed validation code, tries to validate that seed yaml is correct after every snap download, instead of "in the end" because it doesn't know if something is "the end" or not. | 14:36 |
| Laney | it's just bogus for livecd-rootfs to be enforcing that every intermediate step is a valid seed | 14:36 |
| xnox | yeah that | 14:36 |
| Laney | but I didn't win that one with CPC so I just turned it off selectively | 14:37 |
| xnox | twats | 14:37 |
| Laney | :) | 14:37 |
| Laney | not sure which path this image is using for seeding though :( | 14:37 |
| xnox | so | 14:38 |
| xnox | hm | 14:39 |
| xnox | Laney: possibly found the "one more code path" | 14:42 |
| Laney | lb_chroot_layered? | 14:43 |
| xnox | yes.... | 14:45 |
| xnox | Laney: does desktop team maintain that at all still? | 14:45 |
| Laney | not sure | 14:45 |
| Laney | I think it's not a top top priority right now | 14:45 |
| seb128 | didrocks, do you know if there is anything I can do to unblock the rygel MIR? security team gave their +1 some weeks ago, should it auto-bounce to MIR/be discussed in the next meeting? (was it since if you had a meeting?) | 14:45 |
| xnox | Laney: or is it the case of something actually needs to use that, as in "make ubiquity build/use a two layer image" | 14:45 |
| Laney | check with jibel and/or didrocks | 14:45 |
| willcooke | xnox, Laney - from what I can remember we were told that Ubiquiuty should not use the multi lat | 14:46 |
| seb128 | xnox, good discussion for Paris maybe? but afaik we have been asked to not spend efforts on ubiquity, that was some of the first step toward the new installer which was put in standby for now | 14:47 |
| willcooke | *layer stuff, only subiquity when used in desktop mode. And that got dropped as a requirement for 20.04 | 14:47 |
| Laney | right, but there's a canary image being built still | 14:47 |
| seb128 | did we get that build fixed? | 14:47 |
| Laney | that's the conversation | 14:47 |
| seb128 | it was buggy since july after some changes from xnox | 14:47 |
| xnox | seb128: wrong =) on june 14th i explained to didrocks & jibel and coached them that layered images are executing certain hooks at the wrong layers and use the wrong initrd extracted from the wrong layer. | 14:49 |
| xnox | seb128: and i was awaiting to review the patch to extract initrd from the live layer, instead of the first one. | 14:49 |
| xnox | seb128: and i am confused why 3line patch did not emerge from desktop team since....... | 14:50 |
| xnox | willcooke: right, i was hoping that we could use layer image in at least one type of image, such that it does not regress. | 14:50 |
| seb128 | xnox, from your hangout they understood you said you would fix it | 14:50 |
| xnox | seb128: ?! | 14:50 |
| seb128 | xnox, since it's your changes who broke the build | 14:50 |
| seb128 | xnox, is that the bug you assigned to willcooke? ;) | 14:51 |
| xnox | seb128: dude no. my changes didn't break stuff. layered images have never had initrd with expected content to begin with. | 14:51 |
| seb128 | xnox, let's not have that discussion again | 14:51 |
| Laney | you're off topic from snap stuff now so I'll go away and do something else if you don't mind :-) | 14:51 |
| jibel | xnox, our implementation of layered image have been reviewed and merged, then your change breaks it, my understanding is that you break it you fix it | 14:51 |
| xnox | seb128: they always used root layer initrd, expecting it to work, without any detection of matching iso & initrd ever ;-) | 14:51 |
| xnox | jibel: the bug exists in layered image work, and it never worked correctly. | 14:52 |
| seb128 | xnox, that's not going to be a constructive discussion to have here so let's stop please | 14:52 |
| seb128 | and talk in person in Paris | 14:52 |
| jibel | yeah lets do that | 14:52 |
| seb128 | that's going to be easier than wasting an hour arguing over IRC typing | 14:52 |
| xnox | jibel: as in, if one burns two different builds of layered images on two usb sticks, and boots with both plugged in, a random one gets mounted, instead of a matching one. Ie. resulting in missmatch of booted kernel & modules available. | 14:53 |
| xnox | jibel: so layered images work has always been buggy. despite reviews and merged. | 14:53 |
| xnox | jibel: and my understanding was that desktop team committed to maintain that part of livecd-rootfs codebase. | 14:53 |
| xnox | jibel: not just throw it over the wall =) | 14:54 |
| xnox | jibel: and it looks like it's bitrotting now, given that snap validation stuff is broken for it now, and was only fixed for non-layered case. | 14:54 |
| xnox | so someone has to maintain layered code in livecd-rootfs codebase on ongoing basis. cause foudnations/cpc does not do that. | 14:54 |
| willcooke | This can be a 20 min conversation face to face, lets do that please | 14:55 |
| seb128 | +1 | 14:55 |
| seb128 | xnox, Laney, sorry I didn't mean to derail the initial snap problem which from I understand now is another problem | 14:55 |
| seb128 | but sounds like we had multilayer image buggy still even without the snap problem then | 14:56 |
| xnox | well always, just nobody noticied that it was lacking uuid stamps, and later in eoan further checks got added to enforce requiring them, since we included them for years at this point. | 14:57 |
| xnox | at which point it became evident that layered features has never been correct | 14:58 |
| xnox | (but kind of operational, if one didn't happen to hit archive when kernel changes) | 14:58 |
| jibel | Trevinho, I've just got another gnome-shell crash. All the crashes point to bug 1736664 which is not very useful. | 14:59 |
| ubot5 | bug 1736664 in gnome-shell (Ubuntu) "gnome-shell crashed with SIGTRAP in _g_log_abort() from g_log_default_handler() from default_log_handler() from g_logv() from g_log() from gjs_callback_closure() from ffi_closure_unix64_inner() [any error message logged from JavaScript will look like this]" [Low,Confirmed] https://launchpad.net/bugs/1736664 | 14:59 |
| jibel | Trevinho, how can I help getting more interesting data? | 14:59 |
| seb128 | xnox, as said let's discuss that nex tweek please | 14:59 |
| xnox | willcooke: seb128: either any image should use layered code-path for something, or it should be removed and dropped. It could be as simple as, building ubiquity image via layered codepath with just two layers "full" and "live" overlay. That alone would be enough to keep that code-path of livecd-rootfs hot and alive. | 15:02 |
| xnox | (not the whole subiquity-for-desktop stuff) | 15:02 |
| willcooke | oki, we can look at that next week then | 15:03 |
| seb128 | that's for sure doable for next cycle | 15:03 |
| xnox | willcooke: seb128: so if you schedule that the agenda would be to identify a usecase/scope/resource-allocation. Or writting off layered work, which will make it more expensive to resurrect later (well obvious statement) | 15:06 |
| willcooke | ack | 15:06 |
| seb128 | xnox, well I though our usecase when we previously talked about it was to make the minimal install do less work than the normal install | 15:06 |
| seb128 | willcooke, ^ | 15:07 |
| willcooke | yeah, but that got nacked for ubiquiuty. Maybe we JFDI? | 15:07 |
| seb128 | well, that's what we can discuss in Paris | 15:07 |
| willcooke | yeah | 15:07 |
| willcooke | oki | 15:07 |
| * willcooke draws a line under it | 15:08 | |
| seb128 | looks like the fix from rober_ancell for the g-c-c/sound missing slider didn't work... | 15:23 |
| didrocks | right, it worked for all bars but the sound top one | 15:26 |
| seb128 | the other bar is Laney's fix | 15:27 |
| seb128 | that one works it looks like :) | 15:27 |
| didrocks | yeah ;) | 15:27 |
| Trevinho | jibel: try follow https://wiki.gnome.org/Projects/GnomeShell/Debugging#Starting_GNOME_Shell_under_gdb | 15:31 |
| Laney | the global slider works ok for me | 15:31 |
| didrocks | Laney: are you in the ubuntu session, with the amplification setting visible? | 15:31 |
| Laney | no | 15:32 |
| didrocks | maybe you should :) | 15:32 |
| Laney | no thanks | 15:32 |
| didrocks | shrugh | 15:32 |
| Laney | if it's that, sounds like a distro patch bug though | 15:33 |
| seb128 | still needs fixing? | 15:33 |
| seb128 | I'm going to drop an email to Robert | 15:33 |
| seb128 | right, works with XDG_CURRENT_DESKTOP=GNOME | 15:35 |
| seb128 | (done) | 15:39 |
| Laney | this is probably a trivial fix | 15:41 |
| jibel | the global slider doesn't work for me | 15:43 |
| seb128 | jibel, yeah, we confirmed it's an issue with our ubuntu session change | 15:43 |
| seb128 | Laney, agreed, I trust Robert should be able to fix easily :) | 15:43 |
| Laney | done it | 15:43 |
| Laney | you can unemail him | 15:43 |
| seb128 | thx, doing so | 15:43 |
| seb128 | sorry I though you said you were not interested, misunderstanding | 15:44 |
| seb128 | (&done) | 15:44 |
| jibel | Trevinho, I don't have a reliable way to reproduce the crash. It's just random and I cannot run all day under gdb. Any other suggestion? | 15:44 |
| seb128 | jibel, does gdb create any problem? | 15:45 |
| seb128 | if it doesn't stop you should be able to have it attached all day long without noticing | 15:45 |
| jibel | seb128, my system's quite slow already. I'll try gdb anyway see if it's still usable | 15:48 |
| seb128 | gbp isn't valgrind | 15:48 |
| seb128 | bah | 15:48 |
| seb128 | too much packaging recently! | 15:48 |
| seb128 | gdb | 15:48 |
| seb128 | it shouldn't have any impact on performances | 15:48 |
| seb128 | or I never had cases where I could see performances problems once it's done loading the symbols | 15:49 |
| marcustomlinson | frederikf[m]: sorry for the delay, so interestingly I developed a very similar extension which I've just added snap packaging to. Here's how: https://bit.ly/2kFWL5g | 16:01 |
| GunnarHj | Hi seb128, still there? | 16:01 |
| seb128 | GunnarHj, hey, yes but probably going to step our for dinner&co in not long, why? | 16:01 |
| GunnarHj | seb128: I started to play with the docs repos at Debian, but I'm not sure you want me to push. :) What I did was taking the tarball, making the repo equal it, which means that the new upstream is only reflected via one single commit. | 16:03 |
| seb128 | GunnarHj, it's not in a vcs yet? what package is that? | 16:04 |
| GunnarHj | seb128: I'm basically talking about gnome-user-docs. | 16:04 |
| seb128 | GunnarHj, basically https://salsa.debian.org/gnome-team/gnome-user-docs then? | 16:05 |
| GunnarHj | seb128: Yes. | 16:05 |
| seb128 | updating it should be done following https://wiki.debian.org/Gnome/Git | 16:06 |
| seb128 | basucally gbp import-orig | 16:06 |
| seb128 | that should update the different branches | 16:06 |
| seb128 | (I need to step out for a bit, I will read the backlog and comment back if needed in a bit) | 16:06 |
| GunnarHj | seb128: Ok, I'll check out that and make a new try. | 16:07 |
| === pstolowski is now known as pstolowski|afk | ||
| frederikf[m] | <marcustomlinson "frederik.f: sorry for the delay,"> Oh nice! I personally would prefer yours then, because I only forked an existing one. Don't know how the others feel about that? | 16:40 |
| marcustomlinson | frederikf[m]: I don't know, I like the one you had better actually :) simpler | 16:41 |
| frederikf[m] | <marcustomlinson "frederik.f: I don't know, I like"> Sorry how could I try it? with "sudo snap install gnome-shell-extension-theme-indicator"? | 16:43 |
| marcustomlinson | frederikf[m]: it's not been uploaded to the store, so to try mine out you'll have to pull the source, build, and install | 16:45 |
| marcustomlinson | https://pastebin.ubuntu.com/p/2d8nSCmjZz/ | 16:45 |
| marcustomlinson | frederikf[m]: this extension was a proof of concept, not something I've seriously considered releasing. If you test it you'll see it needs love | 16:47 |
| marcustomlinson | frederikf[m]: I just added snap packaging to it today to give you a working example from which you could learn from to package yours :) | 16:48 |
| frederikf[m] | thanks! trying it now in my eoan vm! | 16:49 |
| frederikf[m] | Not sure if I could take over the packaging part though 😕 I fear someone else would need to do the packaging | 16:49 |
| frederikf[m] | wow actually that's very cool 😇 We would need to blacklist "emacs" "raleigh" and "default" I think | 16:55 |
| marcustomlinson | frederikf[m]: https://github.com/Feichtmeier/gnome-shell-extension-dark-theme-toggle/pull/1/files | 17:07 |
| frederikf[m] | woah merged ^^ you're fast | 17:09 |
| marcustomlinson | frederikf[m]: https://snapcraft.io/docs/releasing-your-app | 17:09 |
| marcustomlinson | :) | 17:09 |
| willcooke | very cool! thanks guys | 17:14 |
| willcooke | I gotta go | 17:14 |
| willcooke | night all | 17:14 |
| frederikf[m] | <marcustomlinson "frederik.f: https://snapcraft.io"> thank you very much I will try this tutorial | 17:21 |
| frederikf[m] | marcustomlinson: Ok I've built and uploadeded the snap to the store. "a human will soon review your snap" : ) Let's see! | 18:39 |
| frederikf[m] | What are the next steps now to get it installed by default in 19.10? Or did I misunderstand something and that was not the plan for you guys? | 18:39 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
