[00:18]  * RAOF is going to need to file *all* the logind bugs.
=== havenstance_ is now known as havenstance
[06:10] <jibel> hi, is there any known problem with radeon drivers on cosmic? my desktop doesn't start this morning
[06:10] <duflu> jibel, Morning. I haven't seen anything new in bug reports
[06:11] <jibel> or gnome shell
[06:11] <jibel> Morning duflu
[06:12] <jibel> I've this in the logs
[06:12] <jibel> sept. 06 08:11:27 sark kernel: [drm:r600_ib_test [radeon]] *ERROR* radeon: fence wait timed out.
[06:12] <jibel> sept. 06 08:11:27 sark kernel: [drm:radeon_ib_ring_tests [radeon]] *ERROR* radeon: failed testing IB on GFX ring (-110).
[06:12] <jibel> sept. 06 08:11:27 sark org.gnome.Shell.desktop[5362]: radeon: The kernel rejected CS, see dmesg for more information (-16).
[06:14] <duflu> jibel, I think "CS" is command stream so it would probably be a kernel regression
[06:15] <duflu> That error comes from Mesa, unknown to mutter or gnome-shell
[06:15] <jibel> last reboot was a month ago, it'll be harder to find the culprit
[06:15] <duflu> jibel, the proposed kernel or release?
[06:16] <jibel> release
[06:16] <jibel> I'll downgrade it
[06:16] <duflu> Either way, I would log a kernel [regression] bug
[06:16] <jibel> okay, thanks
[06:17] <duflu> Mesa is unchanged for the past month so that won't be it
[06:18] <duflu> Oh, actually, if you have been logged in for a month then maybe
[06:18] <duflu> But a mesa upgrade would take effect on login. No reboot required
[06:18] <jibel> I rarely log out, I just suspend the machine
[06:22] <jibel> hmm, usb keyboard is not enabled on grub screen, it makes it even more challenging
[06:24] <duflu> That's messed up. Also should be fixable in the BIOS
[06:25] <jibel> yeah but without a keyboard on boot it's hard to boot to the bios
[06:34] <oSoMoN> good morning desktoppers
[06:34] <jibel> duflu, no luck with last known good kernel
[06:34] <jibel> same issue
[06:35] <jibel> hi oSoMoN
[06:36] <duflu> Morning oSoMoN
[06:37] <oSoMoN> salut jibel
[06:37] <oSoMoN> hey duflu
[06:41] <didrocks> good morning
[06:45] <oSoMoN> salut didrocks
[06:49]  * jibel downgrades libdrm, xorg and mesa
[06:52] <jibel> Yay, wayland to the rescue :D
[06:52] <jibel> duflu, the session starts with wayland
[06:52] <jibel> but still broken with xorg
[06:54] <duflu> jibel, in that case Xorg 1.20 might be the cause
[06:55] <jibel> i'll just downgrade xorg
[07:03] <seb128> good morning desktopers
[07:05] <duflu> Morning seb128
=== pstolowski|afk is now known as pstolowski
[07:36] <oSoMoN> salut seb
[07:36] <oSoMoN> darn, he disappeared
[07:36] <oSoMoN> and I pressed enter too fast
[07:45] <RAOF> Mornin' everyone.
[07:46] <oSoMoN> good morning RAOF
[07:46] <oSoMoN> popey, what do you think of https://github.com/ubuntu/snapcraft-desktop-helpers/issues/151 ?
[07:47] <gitbot> ubuntu issue 151 in snapcraft-desktop-helpers "New logo/icon proposal" [Open]
[07:47] <duflu> Evening RAOF
[07:48] <RAOF> Hah. Just as I'm ready to push colord up for sponsoring, salsa.debian.org goes down!
[07:52] <willcooke> morning all
[07:52] <jamesh> oSoMoN: it looks like they've made the same proposal to many other projects, with no obvious pattern
[07:52] <willcooke> BIOS Update for my Thinkpad in G-Software this morning - but it fails
[07:52] <jamesh> I'm not sure why snapcraft-desktop-helpers would need a logo
[07:53] <oSoMoN> jamesh, yeah, not sure either
[07:53] <oSoMoN> good morning willcooke
[08:01] <willcooke> rebooting
[08:02] <Laney> hi thar
[08:03] <RAOF> seb128: Yo yo! If you want colord to drop off the orange list, pls be the sponsoring of https://salsa.debian.org/raof-guest/colord (and likewise plz be the pushing of it to https://salsa.debian.org/debian/colord, which I don't have access to)
[08:04] <duflu> Morning Laney
[08:05] <duflu> Try again. Hi willcooke
[08:06] <willcooke> phew.  That was a bit squeeky bum time
[08:06] <willcooke> Ran fwupdmgr and rebooted and it just sat there for 4 mins doing seemingly nothing
[08:06] <willcooke> but we're back with a new BIOS
[08:06] <willcooke> \o/
[08:06] <willcooke> and a bug: https://bugs.launchpad.net/ubuntu/+source/fwupd/+bug/1791024
[08:06] <ubot5> Ubuntu bug 1791024 in gnome-software (Ubuntu) "BIOS Update offered for Thinkpad X270 fails to update" [Undecided,New]
[08:07] <willcooke> afternoon duflu
[08:07] <duflu> You mean you don't want to download and burn a bootable ISO disc for each Lenovo BIOS update?
[08:07] <duflu> Yeah, fair enough
[08:08] <willcooke> :))
[08:08] <willcooke> Update like it's 1999
[08:09] <jamesh> does it do anything, or just boot normally?
[08:10] <duflu> Hell, a DOS EXE would be more convenient than the old Lenovo method. At least Dell and others offer that much
[08:10] <willcooke> I ran fwupdmgr update and it does a progress bar and then says "done, please reboot"
[08:11] <willcooke> then I rebooted and it just sat with the power light on, the fan on, and seemingly nothing else.  I decided that it was probably writing the BIOS at that point and that I shouldnt just power it off
[08:11] <jamesh> willcooke: looking at the log, it has added a new EFI boot entry that should perform the update
[08:11] <willcooke> and then it rebooted a few more times and it was done
[08:12] <willcooke> ah, so maybe if I had just rebooted it would have done it
[08:12] <jamesh> so I was wondering if it actually picked that, or did something else
[08:12] <jamesh> If you hit the key combo to bring up the boot selector, it should show configured EFI boot loaders
[08:25] <willcooke> jamesh, probably done now since it applied, I'll check next time I boot
[08:28] <jibel> is the network applet missing for anyone else on cosmic?
[08:31] <duflu> jibel, in theory Laney just fixed that, or similar
[08:33] <duflu> jibel, Oh actually the fix is _after_ 3.30.0  (bug 1774957)
[08:33] <ubot5> bug 1774957 in gnome-shell (Ubuntu) "Network icons in status menu disappearing" [Medium,In progress] https://launchpad.net/bugs/1774957
[08:34] <jibel> never seen that before.
[08:34] <jibel> duflu, is there a workaround? I cannot enable the vpn from the ui it's annoying
[08:34] <duflu> I don't know. Check the upstream bug
[08:35] <Laney> a workaround is to use the network panel in gnome-control-center
[08:35]  * didrocks opens the bug. I still see it here
[08:35]  * jibel starts nm-applet
[08:35] <didrocks> ah, it's quite old
[08:36] <didrocks> jibel: do it quickly before I update nm-applet :p
[08:43] <jibel> Laney, activating the vpn from control-center doesn't work. "Could not find source connection"
[08:51] <Laney> :( lame
[08:51] <Laney> I'll try updating everything and see if it still WFM
[08:51] <Laney> but right now I just dist-upgraded cosmic and now my desktop is a blinking cursor after rebooting
[08:52] <jibel> summary for today: no xorg, no network and no alt+tab. Nice morning :) I'll continue on xorg
[08:53] <Laney> Sep 06 09:50:42 raleigh.local /usr/lib/gdm3/gdm-wayland-session[4365]: Exited with an error
[08:53] <Laney> Sep 06 09:50:42 raleigh.local /usr/lib/gdm3/gdm-wayland-session[4365]: stdout:
[08:53] <Laney> Sep 06 09:50:42 raleigh.local /usr/lib/gdm3/gdm-wayland-session[4365]: stderr: Traceback (most recent call last):
[08:53] <Laney> Sep 06 09:50:42 raleigh.local /usr/lib/gdm3/gdm-wayland-session[4365]:   File "/usr/share/session-migration/scripts/ubuntu-settings-migrate-to-defaults.18.10.0.py", line 35, in <module>
[08:53] <Laney> Sep 06 09:50:42 raleigh.local /usr/lib/gdm3/gdm-wayland-session[4365]:     if os.environ['DESKTOP_SESSION'] != 'ubuntu':
[08:53] <Laney> Sep 06 09:50:42 raleigh.local /usr/lib/gdm3/gdm-wayland-session[4365]:   File "/usr/lib/python3.6/os.py", line 669, in __getitem__
[08:53] <Laney> Sep 06 09:50:42 raleigh.local /usr/lib/gdm3/gdm-wayland-session[4365]:     raise KeyError(key) from None
[08:53] <Laney> Sep 06 09:50:42 raleigh.local /usr/lib/gdm3/gdm-wayland-session[4365]: KeyError: 'DESKTOP_SESSION'
[08:53] <Laney> ...............
[08:54] <didrocks> interesting…
[08:55] <didrocks> ah, we didn't get it because this was added afterwards
[08:55] <didrocks> so, the stamp was already there
[08:55] <didrocks> but issues for anyone dist-upgrading (however, the fatal error shouldn't stop from logging)
[09:05] <Laney> yeh
[09:05] <Laney> not my real problem, that is that the x fallback isn't working
[09:39] <seb128> hey again desktopers :)
[09:39] <willcooke> hey seb128
[09:39] <seb128> no wifi in the train but apparently now orange allows tethering on their mobile data plan
[09:40] <seb128> which they didn't for years
[09:50] <seb128> so I was saying, no wifi in the train but tethering on orange mobile data plan seems to work now! (they used to block it)
[09:50] <seb128> still mobile data in train is not stable
[09:51] <seb128> RAOF, I can do sponsoring, unsure how to "enable" it to salsa, I just push to the right git url?
[09:52] <duflu> seb128, it's almost 8pm there
[09:52] <seb128> duflu, right, but I was offline when he asked, just read the log on irclgos.u.c
[09:52] <RAOF> <freenode_seb "RAOF, I can do sponsoring, unsur"> Yeah, just push to the right git url. That's how I got raof-guest/colord
[09:52] <duflu> Heh
[09:52] <seb128> RAOF, great, thx :)
[10:11] <didrocks> nm-applet is a complex merge… but I guess the only new feature is "Add an option to set a connection as Metered"
[10:11] <didrocks> will require a FFe thus
[10:22] <andyrock> does anyone know why we implemented XUbuntuCancel ?
[10:22] <andyrock> I mean why there is no need to forward it upstream?
[10:22] <didrocks> andyrock: I can fw you an email from Marco if you want
[10:22] <andyrock> didrocks: kk
[10:23] <didrocks> let me quote, easier
[10:24] <didrocks> "I've pushed few days ago these changes for supporting the XUbuntuCancel method on remote shell providers as per what was discussed with upstream and seb/laney (upstream is fine with a new search API, but introducing major changes that we won't be able to backport to bionic, so our solution is the only we can do for now)."
[10:29] <andyrock> kk makes sense
[10:30] <andyrock> thk
[10:30] <andyrock> *x
[10:34] <didrocks> yw
[10:36] <didrocks> ah, a meson introspect issue
[10:36] <didrocks> Laney!!!
[10:38] <Laney> what?
[10:40] <didrocks> unsure what the issue is (I just removed dh_translations for now to at least validate the package is complete), but dh_translation (meson introspect) call isn't happy with nm-applet
[10:43] <didrocks> ok, after the merge, we are only loosing the gsm-3g icons. /me looks if that was coming from our previous distro patch or upstream
[10:44] <didrocks> ah, it was one of distro patch
[10:44]  * didrocks wonders if we need it
[10:46] <didrocks> nothing in indicator*, unity or gnome-shell referencing it
[10:46] <didrocks> we provided some in ubuntu-mono, but not in Yaru
[10:47] <didrocks> I would be in favor of not including that diff and see how it goes, sounds like a minor case and none of our components are referencing them
[10:47] <didrocks> (at worse, we take back the ubuntu-mono ones and copy to Yaru)
[10:49] <didrocks> (and the comment was "natty fallback icons")
[10:50] <didrocks> Laney: ah, I know what the issue is
[10:51] <didrocks> Laney: for dh_translations, we have a meson.build but also some autotools
[10:51] <didrocks> it's using autotools to build
[10:51] <didrocks> but dh_translations is picking the meson.build path…
[10:52]  * didrocks feels he's going to need doing some perl debugging… "fun fun fun"
[10:53] <didrocks> ok, found the issue
[10:53] <didrocks> you didn't protect the meson check
[10:53] <didrocks> you need if !domain && <…file detection>
[10:53] <didrocks> (missing the domain check)
[10:53]  * didrocks will fix after a break
[10:55] <Laney> I actually think that was on purpose, to prefer meson over autotools if both exist
[10:55] <Laney> I suppose dh_translations needs to be told by debhelper what to look at actually
[10:56] <Laney> Or handling when there is no meson_builddir?
[10:56] <didrocks> hum, all the other tools have the !domain, and so, the order is what matters
[10:56] <Laney> yes that's why the meson bit was put at the end
[10:56] <didrocks> that's possible to add the meson_builddir detection
[10:56] <didrocks> you should have use !domain && meson at first if you wanted that logic
[10:56] <didrocks> (as the rest of the function is doing that)
[10:56] <didrocks> I'm unsure though, should we priviledge meson?
[10:57] <didrocks> I'm fine adding !domain at the end (and so, no meson priviledge)
[10:57] <Laney> Severl projects had both and we were generally switching things to use meson when they did.
[10:57] <didrocks> or add !domain && -e meson.build at first (priviledged, but at least, following the logic of the function)
[10:58] <didrocks> and add meson_builddir detection to get out of the first case
[10:58] <Laney> It does have detection but it looks like we weren't handling the case where no directory is found.
[10:58] <Laney> But I haven't seen the error you are getting so I don't know for sure if that is the actual problem
[10:58] <didrocks> yeah, it's complaining about directory not found
[10:59] <didrocks> (once ran manually)
[10:59] <didrocks> I would still suggest moving it at the top
[10:59] <didrocks> so that we don't have different logics
[11:00] <Laney> ok, but the problem I pointed out will still need to be fixed
[11:00] <didrocks> yeah, agreed
[11:00] <Laney> I think that's basically equivalent to what we currently have, so should be fine
[11:01] <didrocks> but I prefer having all tools following the same logic
[11:01] <didrocks> so, ok, moving it before configure.ac (just after the po/Makefile which has predecendence)
[11:01] <didrocks> adding !domain &&
[11:01] <didrocks> + handle the case when no builddir is found
[11:03] <didrocks> Laney: just one question, why do you do another check for $dh{DOMAIN} for meson and not let the overrides just overrides it unconditionally?
[11:03] <didrocks> sounds like otherwise we should do the check for all build-system?
[11:04] <duflu> Later all
[11:04] <duflu> in a sec
[11:06] <Laney> didrocks: We had the information to hand, so it was easily possible to do a better check there.
[11:07] <Laney> I wasn't about to make Gunnar (the contributor of the change) try to support all build systems, that didn't feel like a very reasonable ask
[11:08] <didrocks> Laney: hum, ok, I'm unsure how to translate that if moving it upwards, but we'll see
[11:34] <Trevinho> andyrock: it's how didier said... See also https://gitlab.gnome.org/GNOME/gnome-shell/issues/436
[11:35] <gitbot> GNOME issue 436 in gnome-shell "Shell Search Provider v3" [Opened]
[11:35] <Trevinho> I've proposed to add a Cancel method to the current one and Carlos was fine, but Florian preferred a proper solution... Then... so.
=== pstolowski is now known as pstolowski|lunch
[12:26] <Trevinho> tjaalton: hey I was upgrading a vm from bionic to cosmic, got this:
[12:26] <Trevinho> dpkg: error processing archive /tmp/apt-dpkg-install-bK08sf/08-libwayland-dev_1.15.0-2_amd64.deb (--unpack):
[12:26] <Trevinho>  trying to overwrite '/usr/lib/x86_64-linux-gnu/pkgconfig/wayland-egl.pc', which is also in package libegl1-mesa-dev:amd64 18.0.5-0ubuntu0~18.04.1
[12:26] <Trevinho> I guess there's a breaks missing?
=== pstolowski|lunch is now known as pstolowski
[12:46] <tjaalton> Trevinho: no, just needs to be bumped to 18.0.5
[13:05] <tjaalton> Trevinho: fix uploaded to cosmic
[13:05] <Trevinho> tjaalton: ah ok good...
[13:06] <Trevinho> tjaalton: actually launching apt install -f twice was enough here, and I had not to play too much with dpkg
[13:17] <Trevinho> Laney: as per https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/1789472/comments/3 I've noticed new stable version has some patches applied, do they cover those too?
[13:17] <ubot5> Ubuntu bug 1789472 in glib2.0 (Ubuntu) "SRU 2.56.2 to bionic" [Medium,In progress]
[13:18] <kenvandine> oSoMoN, i updated the gnome-3-28-1804-sdk build snap and setup CI
[13:18] <kenvandine> oSoMoN, but i'm thinking maybe we should create a new repository for it with branches for each version
[13:19] <kenvandine> oSoMoN, so gnome-devel maybe with gnome-3-28-1804-sdk and gnome-3-30-1804-sdk branches
[13:22] <oSoMoN> kenvandine, that makes sense
[13:23] <kenvandine> we already need to change it to gnome-3-30
[13:23] <kenvandine> and really it should be gnome-3-30-1604 not 1804 since it's not built on core18
[13:29] <oSoMoN> kenvandine, we still don't have documentation or examples of how to use a build snap though, do we?
[13:29] <oSoMoN> https://forum.snapcraft.io/t/docs-examples-for-build-snaps/2433
[13:29] <kenvandine> oSoMoN, nope
[13:30] <kenvandine> oSoMoN, it's really getting urgent now though
[13:30] <kenvandine> we need to start building for gnome 3.30
[13:30] <kenvandine> and it's quite a bit of work to backport all the libs needed for that to 16.04 in a PPA
[13:30] <kenvandine> getting the build snap rolling will really fix that
[13:31] <kenvandine> and i've been wanting to create the runtime snap as a fileset of files included in the build snap
[13:31] <kenvandine> oSoMoN, in fact, i'd like snapcraft to be able to build two snaps from one snap... the sdk and runtime snaps
[13:32] <kenvandine> just split from the same source
[13:32] <kenvandine> if we get something like that we could more easily automate the maintenance of our snaps
[13:40] <Laney> Trevinho: what patches?
[13:41] <Laney> he's asking you to look at the regressions on https://people.canonical.com/~ubuntu-archive/proposed-migration/bionic/update_excuses.html#glib2.0 and work out if they show a problem in the update
[14:25] <Trevinho> Laney: mh, well there are regressions for glib itself too, so maybe just better to get upstream on those
[14:26] <ricotz> chrisccoulson, hi, final request from my side that you push your packaging branches
[14:35] <Laney> Trevinho: Probably better to do a bit of analysis on our side first
[14:36] <Laney> Some of them might be crappy flaky tests or caused by something else
[14:36] <Trevinho> Laney: analysis is easy... need to backport stuff https://gitlab.gnome.org/GNOME/glib/commits/glib-2-56
[14:37] <Trevinho> Laney: at least for glib itself
[14:38] <Trevinho> let me prepare those then
[14:39] <Laney> which of those commits fixes GLib-GIO:ERROR:../../../../../gio/tests/gdbus-proxy.c:832:fail_test: code should not be reached ?
[14:44] <Trevinho> don't see that one, others yes... but for that one I should do some debugging locally if I can reproduce it
[14:46] <Laney> and the failures in other packages, they are quite likely to be flaky tests I should think or weren't introduced by glib (udisks2)
[14:47] <Laney> so I don't think "backport a few patches" (and have to SRU verify them explicitly) is the only solution to be looking for here
[14:49] <Laney> but it might be a part of it
[14:52] <Laney> I'll retry the glib2.0 tests, if it's a race we might get lucky next time (just did for ppc64el)
[14:59] <Trevinho> Laney: indeed they are races, I triggered a rebuild even on the ppa for one arch I remember.
[15:00] <Trevinho> but indeed we can't expect them to be fixed by only those
[15:11] <Laney> all going green after retrying
[15:11] <Laney> I think we can probably avoid doing another upload until .3 is out
[15:11] <Laney> assuming all of the other failures are shit tests in the other packages
[15:11] <Laney> (need to be looked at)
[15:11] <Laney> all -> all of glib's own tests
[16:24] <Trevinho> Laney: better... I also wanted my subprocess fix to land though, so another upload was in my list a otherwise the gnome-calculator SRU will crash
[16:24] <Laney> pwithnall just told you he's going to do a release soon
[16:25] <Trevinho> (only the search provider and only when cancelled..so not really a probelm)
[16:25] <Laney> I would recommend waiting for that
[16:25] <Trevinho> ah right just read that too
[16:25] <Trevinho> so yes
[16:25] <Laney> ++
[16:45] <seb128> hey again desktopers
[16:45] <seb128> that was a longer and more bumpy trip than expected
[16:46] <seb128> data in train on that line also sucks, I gave on IRC after a while, sorry
[16:46] <seb128> but at least offline was good for reading some emails I had in backlog and to do some hacking :)
[16:47] <oSoMoN> welcome back seb128
[16:48] <seb128> thanks oSoMoN!
[16:48] <seb128> how was the afternoon around here?
[16:48] <seb128> did I miss anything?
[16:48] <oSoMoN> it was rather quiet
[16:49] <oSoMoN> time for me to wrap up
[16:49] <seb128> :)
[16:49] <seb128> have a nice evening oSoMoN!
[16:49] <oSoMoN> thanks, you too
[17:14] <Laney> hey seb128, good train?
[17:18] <seb128> hey Laney! I had best but ok, it's still better than flying
[17:18] <seb128> the second train had a problem so we had to take another connecting line
[17:19] <seb128> which happens to have ongoing work so had to do one part with a bus
[17:19] <seb128> so a bit longer/more changes than expected
[17:21] <Laney> the dreaded Rail Replacement Bus
[17:22] <Laney> that's a swear word
[17:26] <Laney> time to climb for the first time in 3 weeks
[17:26] <Laney> byeeeeeeeeeee
[17:34] <seb128> enjoy Laney!
[17:38] <seb128> tjaalton, ah,someone did it, https://packages.qa.debian.org/libx/libxss/news/20180906T124932Z.html :)
[17:44] <tjaalton> seb128: yeah, jcristau
[17:46] <seb128> tjaalton, I know, names are in the changelog :)
[17:46] <tjaalton> of course..
[17:46] <seb128> tjaalton, thanks for dealing with all my annoying requests about those minors updates :)
[17:46] <tjaalton> np
[17:47] <tjaalton> there used to be a page on people.u.c for x-swat packages which showed if packages weren't merged or upstream had a newer release
[17:48] <tjaalton> but then bryce/mlankhorst left
[17:49] <tjaalton> udd.debian.org is good enough for me
=== pstolowski is now known as pstolowski|afk
[17:53] <seb128> tjaalton, we have an "xorg" set on versions ;)
[17:53] <seb128> tjaalton, http://people.canonical.com/~platform/desktop/xorg.html
[17:53] <seb128> tjaalton, that relies on packages in the list to be set to the right tag though, so that list might need an update, I don't think anyone has been keeping up with updating that set correctly but we could if it's useful
[17:54] <seb128> RAOF, colord sponsored but I could push the vcs, I might need to apply to some debian group
[17:54] <seb128> I've access to pkg-gnome but apparently not to debian/ there
[17:54] <seb128> that's for tomorrow
[17:54] <tjaalton> seb128: ah, nice
[17:55] <tjaalton> I've synced libdrm, libxss, libdmx
[17:55] <tjaalton> libdmx doesn't show on that list
[17:58] <seb128> tjaalton, great, I can fix libdmx
[17:58] <seb128> the script is hacking but it works well
[17:58] <seb128> the list is on https://bazaar.launchpad.net/~ubuntu-desktop/ubuntu-desktop-versions/trunk/view/head:/packages.py the packages have a tag
[17:59] <seb128> e.g https://bazaar.launchpad.net/~ubuntu-desktop/ubuntu-desktop-versions/trunk/view/head:/packages.py#L696 has ['xorg']
[17:59] <seb128> that's how the set is built
[17:59] <tjaalton> ok
[17:59] <seb128> libdmx is not in the list I can add it
[17:59] <seb128> but if you feel like doing tweaks to tag more packages or add, feel free
[18:00] <tjaalton> alright
[18:00] <seb128> or you can let me know which ones are missing and I can fix it for you :)
[18:03] <tjaalton> :)
[18:16] <seb128> tjaalton, libdmx added :)
[18:16] <seb128> on that note it's dinner time
[18:16] <seb128> bbl & have a nice evening desktopers
[21:37] <RAOF> seb128: oops. Apparently I failed to commit the debian/stamps directory, so all the builds failed 😐