[00:00] <james_w> the LOSAs have permissions to control IIRC
[00:00] <james_w> knowing what to do is a little more tricky :-)
[00:00] <lifeless> spm: could you start glib2.0 off please ;)
[00:00]  * lifeless finds out by experiment
[00:01] <spm> james_w: any docco you can point me at? :-)
[00:01] <james_w> spm: I can do it
[00:02] <james_w> done
[00:02] <spm> ta muchly - if you can just dump a copy of your commands used to losas@c.c, I'll add to our wiki.
[00:03] <lifeless> thanks james_w
[02:29] <lamont> so... how do I get sound back on this computer now that it's running karmic?
[02:29] <ebroder> lamont: You ask in #ubuntu
[02:30] <lamont> meh
[02:30] <ebroder> Sorry - it's an impulse these days
[02:30] <ebroder> I don't actually know
[02:32] <lamont> I'm guessing it has something to do with pulseaudio not showing any hardware, while lspci shows an Intel 82801JI providing the Audio controller...  but enough for tonight
[02:33] <stgraber> lamont: might be an issue with pulseaudio's udev plugin
[02:33] <lifeless> lamont: hi
[02:34] <lifeless> lamont: several things:
[02:34] <lifeless> lamont: check you have an up to date kernel.
[02:34] <lifeless> lamont: check that the sound isn't simply muted
[02:34] <lifeless> lamont: and something hda related I don't really know about
[02:36] <lamont> lifeless: fresh upgrade on the machine to karmic+security+updates
[02:36] <ajmitch> there's also a useful linux-backports-modules-alsa-karmic-generic package if it's really recent hardware
[02:37] <lamont> ajmitch: ISTR buying it about 6-7 months ago... kinda ancient by most standards
[02:37] <lamont> lifeless: the sound prefs menu shows no hardware - I'm guessing that it has something to do with udev etc
[02:37] <ajmitch> even if it's not recent & buggy like mine, there may be driver fixes in there if it's not something as simple as being muted in the wrong place
[02:39] <lamont> well, cat /vmlinuz > /dev/dsp does generate some sound-like stuff in the speakers...
[02:39] <lamont> so I suspect the kernel will talk to it
[02:39] <lifeless> lamont: what kernel version do you have?
[02:39] <lifeless> specifically, uname -a
[02:40] <lamont> 2.6.28-15-generic #52-Ubuntu SMP Wed Sep 9 10:48:52 UTC 2009 x86_64 GNU/Linux
[02:40] <lifeless> so
[02:40] <lamont> so WTF am I running a jaunty kernel?
[02:40] <lifeless> please try to figure that out
[02:40] <lifeless> a number of folk have had this happen
[02:40] <ajmitch> there was a bug about grub not being updated, iirc
[02:40] <lifeless> my cause was a missing hook in kernel-img.conf
[02:41] <lifeless> what does grep hook /etc/kernel-img.conf show?
[02:41] <lamont> do_symlinks = yes
[02:41] <lamont> relative_links = yes
[02:41] <lamont> do_bootloader = no
[02:41] <lamont> do_bootfloppy = no
[02:41] <lamont> do_initrd = yes
[02:41] <lamont> link_in_boot = no
[02:41] <lifeless> slangasek: ^ same symptoms I have.
[02:41] <lamont> and update-grub seems to correct menu.lst.  rebooting now.
[02:42] <ajmitch> I know I changed kernel-img.conf manually some time ago, perhaps this only affects people who've upgraded through a few releases?
[02:42] <lifeless> lamont: please add any data you can gather to  https://bugs.edge.launchpad.net/ubuntu/+source/grub/+bug/470265
[02:42] <lifeless> lamont: you want to add these to your kernel-img.conf too:
[02:42] <lifeless> postinst_hook = update-grub
[02:42] <lifeless> postrm_hook   = update-grub
[02:57] <lifeless> james_w: any reason we can't just upgrade the branch?
[03:00] <james_w> lifeless: because the upgrade guide tells me not to?
[03:04] <lamont> lifeless: the karmic kernel has the amusing(?) feature of not having a working network.  OTOH, after rebooting into the jaunty kernel, bip won't connect
[03:07] <lamont> heh
[03:17] <lifeless> james_w: the guide is overly cautious
[03:17] <lifeless> james_w: bzr-builder and builddeb are very small communities
[03:17] <RAOF> There isn't an update-manager script for lucid yet, is there?
[03:20] <StevenK> RAOF: Not that I recall
[03:22] <RAOF> Curses.  I seem to have killed the rtc backup battery on this laptop.
[03:24] <lifeless> Laney: https://bugs.edge.launchpad.net/ubuntu/+source/grub/+bug/470265 <-
[03:24] <lifeless> bah
[03:24] <lifeless> Laney: sorry
[03:35] <lamont> _there_.
[03:35] <stgraber> lamont: On which kernel ?
[03:36] <lifeless> lamont: https://bugs.edge.launchpad.net/ubuntu/+source/grub/+bug/470265 <-
[03:37] <lamont> karmic kernel, adding a pre-up in interfaces to bring up the physical dev beneath the bridge so I can have networking (jaunty did OK without that), and for bonus, I get sound again
[03:37] <lamont> well, after nuking network mangler with prejudice
[03:37] <lamont> it very politely generated an empty resolv.conf
[03:37] <lamont> for values of "empty" == just the comment that NM created it
[03:43] <lifeless> lamont: have a look at that bug if you would, as your surface symptoms are identical and we need to figure out why the hooks are not present
[03:44] <lamont> well.. the machine started life as hardy, and has dist-upgraded from there
[03:44]  * lamont looks at the bug
[03:44] <lifeless> lamont: thats good to know, mine was a fresh install of jaunty
[03:45] <lamont> -rw-r--r-- 1 root root 184 2009-02-10 01:02 /etc/kernel-img.conf
[03:45] <lamont> totally recent
[03:45] <lamont> :-(
[03:46] <lamont> interesting.
[03:47] <lamont> feb 21 was when I flattened the box and rebuilt it as an amd64 box instead of an i386 box.  In the course of that, my diff has:
[03:47] <lamont>  link_in_boot = no
[03:47] <lamont> -postinst_hook = update-grub
[03:47] <lamont> -postrm_hook   = update-grub
[04:01] <slangasek> lifeless: right, so what do you and lamont have in common when you're installing, that no one else does? :)
[04:01] <lifeless> slangasek: we're DD's?
[04:02] <lifeless> lamont: how did you do the rebuild?
[04:02] <slangasek> siretart: libbar's soname doesn't need to be bumped in the /general/ case, but versioned symbols are pretty important for avoiding segfaults there
[04:03] <lamont> it's an ugly raid 6 box - pretty sure I alternate-installed onto a new partition on the lvm mess
[04:04] <lamont> slangasek: it was nothing like the crossgrade I did on my laptop.  honest.
[04:27] <ebroder> Can I actually tell them to leave the AP unplugged?
[04:28] <ebroder> Whoops! Wrong window :)
[04:38] <slangasek> lamont: do you have a /var/log/installer?
[05:05] <lamont> slangasek: I'll dig for it in a moment
[05:08] <lamont> slangasek: it even has a right-sounding date
[05:27] <stephenahpohliss> hellp
[05:27] <stephenahpohliss> *hello
[05:32] <stephenahpohliss> developer?
[06:04] <slangasek> lamont: post it to bug #470265?
[06:11] <lamont> slangasek: meh.  will do so in the morning when I can think again
[06:11]  * lamont -> bed
[07:02] <George_E> Is there an easy way to take the output of ldd and determine package dependencies?
[07:04] <RAOF> George_E: Reasonably so, yes.  dpkg-shlibdeps does something pretty much like that.  What are you aiming for, though?
[07:06] <George_E> Just to create a DEB file with proper dependency info.
[07:06] <RAOF> Oh.  Then call dh_shlibdeps, and it'll be done automatically.
[07:06] <George_E> Just to create a DEB file with proper dependency info.
[07:06] <RAOF> We don't manually work out package runtime dependencies ourselves, generally :)
[07:07] <Chipzz> George_E: 08:06 < RAOF> Oh.  Then call dh_shlibdeps, and it'll be done automatically.
[07:07] <George_E> Oh good. I was worried Id have to manually do it.
[07:07] <RAOF> Well, not entirely automatically, I guess.  You'll need ${shlibs:Depends} in your Depends: field, but that'll be filled in automatically.
[07:08] <George_E> Thanks.
[07:59] <dholbach> good morning
[08:17] <siretart`> slangasek: unfortunately in my case, upstream doesn't use symbol versioning. :(
[08:17] <siretart`> morning folks!
[08:17] <Tm_T> good morning
[08:38] <\sh> moins
[08:38] <pitti> Good morning
[08:48] <Dajago> Can someone help me in the direction of debugging/fixing certain issues with Ubuntu (Gnome and others)? What I need, what the best tools are, etc?
[08:58] <siretart`> has mass-autosyncing from debian/testing started yet?
[08:59] <\sh> siretart, I wonder if deb source format 3 is already supported on LP
[08:59] <siretart`> \sh: it isn't
[09:18] <pitti> \sh: should be supported in the LP December 11th rollout, AFAIR
[09:18] <pitti> siretart`: yes, autosyncs were already started
[09:19] <siretart`> pitti: is it just me or do we have considerably less syncs than in karmic up to now?
[09:19] <pitti> may be; I didn't follow them really
[09:32] <seb128> siretart`, syncs are done on testing it changes less quickly
[10:21] <Keybuk> pitti: did the -proposed kernel make it to -updates yet?
[10:25] <pitti> Keybuk: just copied over
[10:26] <Keybuk> yay
[10:30] <\sh> Keybuk, did you find the time to check bug #446031 ? it would be really important to get that fixed and provide a update for karmic
[10:31] <Keybuk> \sh: there was this little thing called "UDS" last week
[10:34] <\sh> Keybuk, I know I know, was wondering if nobody was discussing those upstart issues @UDS with you? :) anyways..there are more problems with the handling of /e/n/i inside upstart...
[10:34] <Keybuk> \sh: there was an entire session on such issues?
[10:35] <Keybuk> did you not remotely participate in it, if it interested you so much?
[10:35] <\sh> Keybuk, dunno..didn't have the time to follow UDS at all...timezone and work related issues :(
[10:38] <\sh> Keybuk, i think you mean https://blueprints.edge.launchpad.net/ubuntu/+spec/foundations-lucid-upstart-server-review
[10:38] <Keybuk> \sh: that's the one
[10:39] <\sh> Keybuk, any notes on this...I would like to take a look on it :)
[10:39] <Keybuk> \sh: the notes will be at that URL, or on gobby
[10:39] <\sh> Keybuk, url not set...let's see on gobby
[10:40] <soren> They're on gobby.
[10:40] <soren> Name matches blueprint name.
[10:40] <\sh> soren, thx :)
[10:45] <\sh> soren, do we have somehow an overview of how many people are affected by this bonding problem? if the fix of mkdir -p /var/run/network helps most of them, I would like to create an update for karmic...(just forgetting people with hotplug interfaces, who are not catched by this effectively)
[10:46] <soren> Absolutely no clue.
[10:50] <Keybuk> \sh: there's no fix in lucid to backport to updates yet
[10:51] <\sh> Keybuk, right, that's why there's a debdiff for lucid on bug #446031 and ubuntu main sponsors subscribed ;)
[10:53] <\sh> Keybuk, but really it's just only a workaround which helps right now for people like me or other server people, for a really serious problem (which does affect not only server people but also desktop/laptop people)
[11:01] <Keybuk> \sh: what's the not-a-workaround?
[11:03] <\sh> Keybuk, not-a-workaround? hmm? elaborate pls :)
[11:06] <Keybuk> \sh: you said it's only a workaround
[11:06] <Keybuk> I'm obviously more interested in the fix that's not just a workaround
[11:06] <Keybuk> what is it?
[11:08] <\sh> Keybuk, you tell me ;) soren and I tried many possibilities which were not helping...so regarding this, the attached /etc/init/networking.conf patch in ifupdown package is the only way to go for a working bonding setup (on servers where this setup is used), it could help people now for karmic
[11:08] <Keybuk> \sh: in other words, we don't fully understand this problem
[11:09] <Keybuk> in which case rushing a "workaround" into a *stable* release is a very bad thing to do
[11:23] <\sh> Keybuk, I don't fully understand how upstart works in this case, that's right, but I do understand that there is a timing problem between /etc/init/network-interface.conf and /etc/init/networking.conf triggers and that creating the directory for ifup helps here, because for the bonding driver it's not necessary that the hw nics are already initialized, but it needs to know which hw nics it should use, and that doesn't really work right now, because
[11:23] <\sh>  of the missing directory (ifup -a fails when /var/run/network/ is not available)
[11:25] <\sh> Keybuk, I tested the change on 10 servers and it helped to boot into a usable server environment so I think this "workaround" is a good solution for now, to make the upgrade from releases < karmic work
[11:28] <\sh> Keybuk, and I'm happy to help to find a better solution for lucid, if there is any in the small timeframe we have until lucids release :)
[11:29] <Keybuk> \sh: have you tested it on any machines which didn't have the original bug?
[11:29] <Keybuk> can you safely say that there aren't *other* bugs that won't be introduced by this change?
[11:30] <\sh> Keybuk, I tested the patched package on my laptop (which has -desktop flavour) and didn't see anything which fails
[11:31] <Keybuk> so no, you haven't tested it then
[11:31] <Keybuk> seriously
[11:31] <\sh> Keybuk, Lars W. tested it with his setup (original bug) this works, too, has he wrote in his comment
[11:31] <\sh> s/has/as/
[11:31] <Keybuk> it's better to have a known bug that bonded interfaces don't work
[11:31] <Keybuk> than to introduce unknown bugs
[11:33] <\sh> Keybuk, well, how would you test it better then that? mkdir -p /var/run/network in /etc/init/networking.conf is not much different from the mkdir -p /var/run/network in /etc/init/network-interface.conf
[11:33] <\sh> Keybuk, and to know that the networking.conf service is triggered earlier then network-interface.conf (whysoever)
[11:33] <Keybuk> \sh: exactly, and by fixing this bug, you introduce an untested condition where two ifup's for the same device may be happening at the same time
[11:34] <Keybuk> if networking is honestly being started before network-interface for lo
[11:34] <Keybuk> then you introduce a new condition where "ifup lo" (from ifup -a) happens *before* network-interface lo
[11:34] <Keybuk> which could cause a whole new set of bugs
[11:36] <\sh> Keybuk, ok...regarding the special case of "lo", do you think it's better to introduce an network-interface-lo.conf, which only calls "ifup lo", before network-interfaces.conf and/or networking.conf? (i mean if we are on this track, we could as well fix ntp to be restarted everytime ifup is called ;))
[11:36] <Keybuk> no, I don't think that's better
[11:36] <Keybuk> furthermore
[11:36] <Keybuk> networking.conf has "stopped udevtrigger" in its start condition
[11:36] <Keybuk> this should mean that lo has already been created
[11:36] <Keybuk> (but isn't due to upstart not getting there yet)
[11:37] <Keybuk> maybe "and net-device-up IFACE=lo" is also needed in networking.conf, instead of that mkdir
[11:37] <Keybuk> there's a whole lot of "ifs" and "maybes" here
[11:37] <Keybuk> there should be an automatic SRU rejection for any "if" and "maybe"
[11:38] <\sh> Keybuk, that's why I don't do "SRU"s ;)
[11:39] <\sh> Keybuk, which service should emit "net-device-up" right now if not udev?
[11:39] <Keybuk> our situation, right now, is that there is a known bug in karmic
[11:39] <Keybuk> and that there's a workaround on the bug report that many people claim fixes it for them
[11:39] <Keybuk> but that workaround may introduce additional problems for people who aren't
[11:39] <Keybuk> the prudent course of action here is to release note the known bug
[11:40] <Keybuk> refer people to the bug report (with the workaround)
[11:40] <Keybuk> while the problem is studied in lucid, and fixed in lucid properly
[11:40] <Keybuk> (which may not be suitable for SRU)
[11:40] <\sh> Keybuk, wasn't that the reason to introduce "-proposed" to check that an update doesn't harm anyone?
[11:40] <Keybuk> no
[11:43] <\sh> Keybuk, then I don't understand -proposed at all...
[11:45] <ion> The addition of -proposed shouldn’t change the acceptable basis for SRUs at all. It’s just a safety buffer for what are thought to be safe for -updates in the first place. Or i could be wrong. :-)
[11:48] <\sh> reading https://wiki.ubuntu.com/Testing/EnableProposed it should be a way to test if a serious regression is fixed with a -proposed update (which will eventually become an SRU)...but that's me...the other way is to test dist-upgrades with a tweaked d-i installer preseed where a PPA is enabled...
[11:51] <sebner> huhu \sh :D
[11:51] <\sh> gugucks sebner
[13:54] <seb128> does anybody plan to run an autosync today?
[13:56] <geser> seb128: do you know when were new packages (missing in Ubuntu) synced from Debian testing the last time?
[13:56] <seb128> do we still have issues due to the new source format and soyuz?
[13:56] <seb128> geser, no
[13:56] <seb128> I expect archive admin activy has been somewhat low due to uds
[13:56] <geser> I guess that too when looking at the NEW queue
[13:59] <seb128> ok, slangasek is on holidays apparently
[14:00] <seb128> pitti, ^ do you know about syncs?
[14:06] <ebroder> Oh, wait, I guess not actually. Never mind
[14:06] <ebroder> Wrong window again, sorry
[14:22] <pitti> seb128: they can happen, you just have to blacklist 3.0 format packages (sync will fail on them)
[14:23] <seb128> ok thanks
[14:23] <seb128> pitti, no objection to me running an autosync run?
[14:23] <pitti> seb128: no, please go ahead
[14:23] <seb128> ok
[14:23] <seb128> thanks
[15:16] <gwadeloop> Hello good morning
[15:16] <gwadeloop> since this morning I can only boot in "gnome failsafe" mode
[15:17] <gwadeloop> the nividia driver is not working anymore as well as the broadcom proprietary driver
[15:18] <gwadeloop> I am using an HP dv6 laptop
[15:19] <seb128> what version of ubuntu do you use?
[15:19] <gwadeloop> is there any reason that would explain this situation?
[15:19] <seb128> what did you upgrade before rebooting?
[15:19] <gwadeloop> seb128: I am using 9.10
[15:19] <Keybuk> funnily enough, the nvidia driver didn't work for me this morning either
[15:20] <Keybuk> (on 9.10)
[15:20] <gwadeloop> and I did  update/upgrade before rebooting
[15:20] <gwadeloop> Keybuk: this is not really funny :-(
[15:20] <gwadeloop> Keybuk: but I am glad to not be the only one
[15:20] <Keybuk> the primary difference, I suspect, being that I didn't upgrade anything
[15:21] <Keybuk> it works if I don't boot with "splash" on the kernel command-line, maybe try that?
[15:22] <gwadeloop> Keybuk: you mean startx ?
[15:22] <Keybuk> no
[15:35] <amgarching> Hi, will dd if=/dev/zero of=/root/BIGFILE actualy fill the disk with zeros on ext4? Need it for compression of images.
[15:39] <zul> dholbach: how do you unsubscribe main-sponsors from the bug?
[15:40] <dholbach> zul: you need to be member of the team
[15:40] <zul> dholbach: i thought i was a member of the team
[15:40] <dholbach> added you
[15:40] <zul> thanks
[15:40] <dholbach> reload the bug :)
[15:41]  * nixternal hugs dholbach 
[15:43]  * dholbach hugs nixternal back
[15:47]  * fagan did enough hugging of dholbach 
[15:47]  * dholbach hugs fagan some more :)
[15:47] <fagan> :)
[15:48] <blackxored> hello, I have always used sbuild with an apt-cacher-ng setup but now since I upgraded to 64 bits I'm recreating them, and passing --debootstrap-mirror to the mk-sbuild-lvm script fails to get the Release file, any clues?
[15:48] <maco> fagan: so you made it to the plane, then? laura was flippin out, thinking youd gone back to sleep and were gonna miss it
[15:49] <fagan> maco: I did something dumb there
[15:50] <fagan> I did a quick scan for laura and then got in the first taxi because I thought she went off without me
[15:50] <fagan> she was angry
[15:50] <blackxored> anyone?
[16:16] <primes2h> apw: Hello, could you please have a look at bug #441835? There are still issues with floppy (seems that a brand new one come up every release unfortunately :( ). There are enough info attached (even on duplicate bugs) and I'm investigating on other bug reports that are probably duplicate as well.
[16:16]  * apw sends a usb stick to everyone
[16:18] <apw> primes2h, do you have this issue?
[16:19]  * fagan hasnt seen a floppy in 7 years
[16:21]  * apw pokes primes2h 
[16:21] <apw> fagan, not sure i own any machines even having a controller let alone a drive ...
[16:22] <primes2h> apw: Yes, in a few pc that have floppy device, and I have friends that have it as well, unfortunately floppy is still quite common here in Italy and in other country, especially on desktop pc.
[16:22] <primes2h> countries
[16:23] <primes2h> apw: people complains a lot on bug reports too
[16:24] <primes2h> apw: They have old data or other stuff still on floppy. It's hard to believe but it's true.
[16:26] <primes2h> This is true especially in poor countries where there are old pcs still with floppy
[16:28] <apw> primes2h, yeah i am sure there are a lot about
[16:28] <apw> in the bug report it talks about being able to just use the device using moutn?
[16:28] <apw> can you confirm that behaviour
[16:32] <primes2h> apw: sorry, I was on the phone
[16:32] <primes2h> apw: yes, I confirm it
[16:32] <primes2h> apw: I can mount it via terminal
[16:33] <primes2h> apw: mount /dev/fd0 /media/floppy0 etc.
[16:33] <primes2h> sudo
[16:36] <apw> primes2h, ok so that is not a kernel issue i shouldn't think
[16:36] <primes2h> apw: but it creates another icon on Places->
[16:37] <apw> as you have a /dev/fd0 to mount from
[16:37] <primes2h> apw: different from Places->Floppy Device
[16:37] <apw> the kernel has done its bit, as has udev as you have a /dev/fd0 in the first place
[16:37] <apw> and as it works, that also sounds liek the kernel did the right thing
[16:37] <apw> so i would assume its gvfs or similar which is unhappy
[16:38] <apw> primes2h, can you unmount the mount you did by hand and try
[16:38] <apw> gfvs-mount -d /dev/fd0
[16:38] <apw> and tell me what happens
[16:41] <primes2h> apw: as a user, it tells me "no volume for device file /dev/fd0"
[16:42] <primes2h> apw: as root (sudo) it mounts the floppy as mount did
[16:42] <primes2h> apw: still creating another icon
[16:42] <primes2h> apw: with some errors. on the terminal
[16:43] <primes2h> apw: but floppy is mounted and I can browse it
[16:45] <JanC> sounds like a problem with permissions then?
[16:45] <primes2h> JanC: Seems to be
[16:45] <apw> perhaps so
[16:46] <apw> primes2h, ok could you attach the dmesg output and the logs from udev (/var/log/udev) and the output you see from testing gvfs-mount as  yourself and as sudo
[16:50] <apw> primes2h, oh and an ls -l /dev/fd0 as well
[16:54] <primes2h> apw: Ok.
[17:01] <dpm> pitti, hey, I
[17:01] <dpm> I've got a question on langpacks on the livecd
[17:02] <dpm> for the languages with language packs on the ISO
[17:02] <dpm> are the full translations (the PO files) included?
[17:15] <pitti> dpm: yes, that's what the langpacks are about
[17:15] <pitti> dpm: well, the .mo files of course, not the .po files
[17:16] <primes2h> apw: done. Thank you very much. :)
[17:17] <dpm> pitti, thanks, that's what I thought (and I meant mo files, as you correctly point out), I was just wondering if those few langpacks were put fully on the CD.
[17:18] <dpm> anyway, did you have a good trip back?
[17:22] <pitti> dpm: yes, went fine; how about you?
[17:46] <dpm> pitti, oh, fine as well. happy that I didn't get any jet lag on the way back :)
[20:45] <micahg> so there are 5 versions of python now?
[20:46] <ebroder> Apparently
[21:32] <mneptok> http://theoatmeal.com/comics/pony
[21:32] <mneptok> go forth, Ubuntu developers, and ride for Lucid.
[21:41] <ajmitch> mneptok: that page is suitably odd to be recommended by you
[22:26] <hedkandi> how do you link against a shared object at build time?
[22:48] <mneptok> ajmitch: i love you, too. :)
[22:48] <ajmitch> aw thanks :)
[23:00] <bdrung> seb128: refering to bug #482886. the debian maintainer did not want to make the test suite failing.
[23:01] <seb128> bdrung, is slomo the debian maintainer?
[23:01] <bdrung> seb128: he is one of them
[23:02] <seb128> bdrung, who did you talk to?
[23:02] <seb128> ie who said no?
[23:02] <seb128> I will talk to slomo when he's around
[23:02]  * bdrung searches the mail
[23:03] <bdrung> seb128: i only wrote to their mailing list.
[23:03] <bdrung> seb128: the response: "Why? Could you file a bug for this with some explanations why you need this?"
[23:04] <seb128> ok
[23:04] <seb128> I will talk to slomo tomorrow
[23:04] <seb128> the rational is that testsuites are good to avoid breakage in stable updates for example
[23:50] <ari-tczew> seb128, thanks for syncs!
[23:51] <seb128> ari-tczew, you're welcome