[02:33] <mup> PR snapd#9830 opened: Clarify error message <Created by SeanColombo> <https://github.com/snapcore/snapd/pull/9830>
[06:18] <mborzecki> morning
[08:16] <pstolowski> morning
[08:19] <mvo> good morning pstolowski
[08:33] <mborzecki> pstolowski: mvo : hey
[08:33] <mvo> good morning mborzecki
[08:34] <mborzecki> pstolowski: can you take a look at https://github.com/snapcore/snapd/pull/9828 ?
[08:34] <mup> PR #9828: sandbox/cgroup, tess/main: fix unit tests on v2 system, disable broken tests on sid <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9828>
[08:36] <zyga> hey guys
[08:37] <zyga> I've sent some more patches for spread and I will continue until the CI systems fixed
[08:37] <mvo> good morning zyga
[08:37] <zyga> hey mvo, how are things?
[08:37] <pstolowski> +1
[08:37] <mvo> zyga: good, good, how are you?
[08:37] <pstolowski> hey zyga
[08:38]  * zyga starts first scrum-like cycle today, so some extra planning and non-coding work
[08:39] <mborzecki> heh, we keep on getting 429 Too Many Requests when tryting to pull the commands list from the store
[08:40] <mborzecki> and tests/main/snap-advise-command and apt-hooks keep failing because of that
[08:43] <mborzecki> hmm https://github.com/snapcore/snapd/pull/9830 looks off, or am i missing something?
[08:43] <mup> PR #9830: Clarify error message <Created by SeanColombo> <https://github.com/snapcore/snapd/pull/9830>
[09:20] <mborzecki> mvo: can we land https://github.com/snapcore/snapd/pull/9828 ?
[09:20] <mup> PR #9828: sandbox/cgroup, tess/main: fix unit tests on v2 system, disable broken tests on sid <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9828>
[09:20] <mborzecki> the failures are unrelated
[09:26] <mvo> mborzecki: sure
[09:26] <mborzecki> mvo: thanks!
[09:27] <zyga> mborzecki, it's really happening :)
[09:27] <mborzecki> zyga: hm?
[09:27] <mborzecki> what is happening?
[09:27] <zyga> v2 support
[09:27] <zyga> once debian gets it
[09:28] <zyga> ubuntu will have it sooner or later
[09:29] <mborzecki> zyga: rbalint wanted to enable it in 21.x, but we're still not ready in snapd
[09:30] <mborzecki> zyga: see https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1850667/
[09:30] <mup> Bug #1850667: cgroup v2 is not fully supported yet, proceeding with partial confinement <docker.io (Ubuntu):New> <lxc (Ubuntu):Fix Released> <lxcfs (Ubuntu):Fix Released> <lxd (Ubuntu):Fix Released> <snapd (Ubuntu):In Progress by maciek-borzecki> <https://launchpad.net/bugs/1850667>
[09:30] <mup> PR snapd#9828 closed: sandbox/cgroup, tess/main: fix unit tests on v2 system, disable broken tests on sid <Simple 😃> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9828>
[09:55] <mup> PR snapd#9803 closed: many: clarify gadget role-usage consistency checks for UC16/18 vs UC20 <Cleanup :broom:> <Run nested> <UC20> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/9803>
[10:03] <zyga> niemeyer, hello
[10:03] <zyga> niemeyer, I've sent a small PR to unbreak CI in spread: https://github.com/snapcore/spread/pull/112
[10:03] <mup> PR spread#112: Bump base version of go to 1.13 <Created by zyga> <https://github.com/snapcore/spread/pull/112>
[10:03] <zyga> niemeyer, and a small fix for one of the issues picked up by go vet: https://github.com/snapcore/spread/pull/111
[10:03] <mup> PR spread#111: Do not copy log.Logger and the contained sync.Mutex <Created by zyga> <https://github.com/snapcore/spread/pull/111>
[10:04] <niemeyer> zyga: Thanks!
[10:04] <zyga> niemeyer, I have one more for more go vet issues in humbox but I need to spend some more time on it
[11:01] <pstolowski> mborzecki: do you think you could take a look at #9732?
[11:01] <mup> PR #9732: asserts: snapasserts method to validate installed snaps against validation sets <validation-sets :white_check_mark:> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9732>
[11:02] <mborzecki> pstolowski: sure
[11:02] <pstolowski> ty!
[11:19] <pstolowski> should we disable snap-advise-command test temporarily?
[11:48] <mborzecki> pstolowski: idk, pedronis do you know more about store side of things? is this temporary?
[11:48] <mborzecki> pedronis: we're seeing 429 accessing /api/v1/snaps/names
[11:51] <mup> PR snapd#9457 closed: [RFC] o/snapshotstate: test for roundtrip with corrupted zip file inside exported snapshot <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/9457>
[11:53] <pstolowski> mborzecki, pedronis: i can also add an extra check in the test not to fail on 429
[11:53] <pstolowski> (just warn and exit)
[11:56] <mup> PR snapd#9831 opened: interfaces/builtin: fix unit test expecting snap-device-helper at /usr/lib/snapd <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9831>
[11:57] <pstolowski> i asked in the store channel
[12:26] <mup> PR snapd#9833 opened: tests: skip main part of snap-advise test if 429 error is encountered <Test Robustness> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9833>
[13:06]  * pstolowski lunch
[13:41] <mup> PR snapd#9834 opened: tests: normalize test tools - part 1 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9834>
[14:19] <mup> PR snapcraft#3413 opened: elf: add a class to check for dependency problems in a group of files <Created by jhenstridge> <https://github.com/snapcore/snapcraft/pull/3413>
[14:43] <pstolowski> pedronis: we ought to talk about validations sets, i wasn't pushing for it this morning because i still had stuff to do, but maybe later/tomorrow morning?
[14:44] <pedronis> pstolowski: yes, sorry
[15:09] <pstolowski> cachio: updated #9833
[15:09] <mup> PR #9833: tests: skip main part of snap-advise test if 429 error is encountered <Test Robustness> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9833>
[15:10] <cachio> pstolowski, thanks
[15:16] <cachio> pstolowski, +1
[15:17] <pstolowski> ty
[15:17] <cachio> pstolowski, apt-hooks test is havin same problem
[15:18] <cachio> I can replicate the solution for that as well
[15:19] <pstolowski> cachio: ah
[15:19] <pstolowski> cachio: ok, please do, thanks
[15:19] <cachio> pstolowski, sure
[15:20] <pstolowski> cachio: although - fingers crossed - it shouldn't be a problem for now after they changed store config
[15:20] <cachio> pstolowski, yes, but I just re run tests and failed with that error
[15:20] <cachio> re-ran
[15:21] <ijohnson> ogra: hey if you didn't already could you file a bug about snapctl needing CAP_NET_ADMIN ?
[15:21] <pstolowski> cachio: oh, so still an issue, not good
[15:22] <cachio> lets wait a bit
[15:23] <ogra> ijohnson, eventually ... 🙂
[15:23] <ijohnson> k, thanks
[15:23]  * cachio lunch
[15:57]  * ogra curses ...
[15:57] <ogra> so wh the heck does the python snapcraft plugin break in massive ways with each new base i need to port to
[16:03] <cjp256> :-( what's the problem ogra
[16:03] <ogra> cjp256, https://github.com/ogra1/nodered-snap/blob/master/snap/snapcraft.yaml#L130
[16:03] <ogra> i'm trying to move that somehow to core20
[16:04] <ogra> i'm at a point where, while getting a lot bdist_wheel errors at the start, the pip install seems to at least finish on the second run
[16:05] <ogra> (if i take oout the Adafruit DHT stuff that needs special treatment before building)
[16:05] <cjp256> python2 ?
[16:05] <ogra> yeah
[16:06] <cjp256> well i see a potential bug in python plugin for python2..
[16:06] <cjp256> as far as wheel, you can install that python package (it's no longer automatically installed)
[16:07] <ogra> yeah, i gathered that from the forum ... but i still get the bdist_wheel errors on first try ... it re-trie then and succeeds
[16:07] <ogra> *re-tries
[16:13] <cjp256> ogra: i'm not sure what you are seeing in your log, but the wheel errors generally can be ignored, python should still chug along without the wheels
[16:13] <ogra> okay ...
[16:14] <ogra> hmm there is no pip anymore in 20.04 it seems
[16:14] <ogra> (for py2)
[16:18]  * ogra doesnt see how he can ever get that to work
[16:21] <ogra> cjp256, so what i'm seeing when using py3 is https://paste.ubuntu.com/p/nHHsT5Kq4s/ ... but i doubt the modules will work since they are all written for py2 (and are unlikely to get ported)
[16:22] <ogra> when setting "SNAPCRAFT_PYTHON_INTERPRETER: "python2"" it just falls flat on its face telling me it doesnt have venv
[16:24] <cjp256> yeah, the core20 plugin really expects python3
[16:25] <mup> PR snapd#9835 opened: tests: apply workaround done for snap-advise-command to apt-hooks test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9835>
[16:32] <pstolowski> mvo: can you merge #9833 manually, there are a couple of unrelated failures
[16:32] <mup> PR #9833: tests: skip main part of snap-advise test if 429 error is encountered <Test Robustness> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9833>
[16:32] <cjp256> ogra: i think a custom override is in order for this, want me to help you create one?  might be worth creating a python2 plugin
[16:33] <ogra> cjp256, well, there is no venv in the archive at all ... how would i get that ?
[16:33] <cjp256> orgra: virtualenv
[16:33] <mvo> pstolowski: sure
[16:33] <cjp256> ogra: `python2 -m pip install virtual` if you used pip
[16:33] <ogra> cjp256, oh, that works for py2 still ?
[16:33] <cjp256> err virtualenv^
[16:34] <cjp256> yeah seems to for me
[16:34] <pstolowski> mvo: ty!
[16:34] <pstolowski> cachio: you may want to update your PR with master now
[16:34] <cjp256> ogra: you use the get-pip.py to install pip?
[16:35] <mup> PR snapd#9833 closed: tests: skip main part of snap-advise test if 429 error is encountered <Test Robustness> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9833>
[16:35] <ogra> not yet, wheer do i find that ?
[16:35] <ogra> *where
[16:36] <cjp256> `curl https://bootstrap.pypa.io/get-pip.py --output get-pip.py ; python2 get-pip.py`
[16:38] <ogra> that gets me pip, yeah ...
[16:38] <ogra> but then ...
[16:38] <ogra> + python2 -m venv /root/nodered-snap/parts/sensor-libs/install
[16:38] <ogra> Failed to build 'sensor-libs'.
[16:38] <ogra> grrr
[16:38] <ogra> /usr/bin/python2: No module named venv
[16:41] <cjp256> ogra: use nil plugin for now
[16:43] <cjp256> i'll ping sergio about adding an equivalent python2 plugin
[16:43] <ogra> heh ... symlinking venv to virtualenv in dist-packages helps
[16:43] <cjp256> hah yeah, that'd do it :P
[16:44] <ogra> so where are the python packages stored now ... i need to modify one of them before building
[16:45] <ogra> (there used to be a "python-packages" dir)
[16:46] <cjp256> should be in $SNAPCRAFT_PART_INSTALL if that's where you installed the virtualenv
[16:46] <cjp256> something like $SNAPCRAFT_PART_INSTALL/lib/python2.7/site-packages/...
[16:48] <ogra> well, i need the tarball ... before building anything ... in core18 this was downloaded during the pull step
[16:55] <ogra> oh my ...
[16:55] <ogra> it goes to /root/.cache ?!?
[16:55] <ogra> ah, no, thats the result ...
[17:05] <mup> PR snapd#9836 opened: cmd/snap-repair: save base snap and mode in device info; other misc cleanups <Simple 😃> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9836>
[17:20] <mup> PR snapcraft#3414 opened: project loader: export SNAPCRAFT_TARGET_ARCH in build environment <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3414>
[17:25] <mup> PR snapcraft#3415 opened: cli: enable SNAPCRAFT_TARGET_ARCH envvar matching --target-arch <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3415>
[17:50] <mup> PR snapcraft#3416 opened: repo: default to target arch for stage package cache <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3416>
[18:45] <mup> PR snapcraft#3409 closed: Fix a few licenses in ros-related test files <Created by artivis> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3409>
[18:55] <mup> PR snapcraft#3412 closed: grammar: ensure all dictionary primitives are captured <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3412>
[19:00] <mup> PR snapcraft#3343 closed: build providers: set snapd proxy settings prior to _setup_snapcraft() <Created by cjp256> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/3343>
[19:40] <mup> PR snapcraft#3414 closed: project loader: export SNAPCRAFT_TARGET_ARCH in build environment <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3414>
[19:55] <mup> PR snapcraft#3371 closed: snap: get legacy branch from local <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/3371>
[20:00] <mup> PR snapcraft#3198 closed: snap: drop legacy, switch to core20 for bootstrap <do-not-merge> <Created by xnox> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/3198>
[20:00] <mup> PR snapcraft#3407 closed: Add new gnome-3-38 extension which uses gnome-3-38-2004 and core20 <Created by kenvandine> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3407>
[20:35] <mup> PR snapcraft#3417 opened: Allow validation assertions to be revoked <Created by nessita> <https://github.com/snapcore/snapcraft/pull/3417>
[21:31] <mup> PR snapd#9837 opened: cmd/snap-repair: filter repair assertions based on bases + modes <Needs Samuele review> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9837>
[21:55] <mup> PR snapcraft#3418 opened: project: always set target arch even if not cross compiling <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3418>
[22:29] <mup> Bug #1911480 opened: cgroupv2 support <Snappy:New> <https://launchpad.net/bugs/1911480>
[22:59] <mup> Bug #1911480 changed: cgroupv2 support <Snappy:New> <https://launchpad.net/bugs/1911480>


[00:33] <ailo> This is the patch for threadirqs https://lkml.org/lkml/2011/2/23/513
[00:38] <len-dt> ailo,  I didn't think we were running a 2.6 kernel.. I guess we were at the time.
[00:41] <ailo> len-dt: Linus changed how the versioning is done after 2.6.39. In a way, the 3.x.x kernels are 2.6 kernels
[00:42] <TheMuso> ailo: No I don't know.
[00:44] <ailo> TheMuso: Thanks. Are very occupied in the coming future? I was thinking about maybe starting to document the kernel maintenance bit. At least it would be really helpful for me to get an idea of your current steps to update it
[00:44] <ailo> I mean to ask, are you very occupied in the coming future. Didn't realize I was leaking words
[00:46] <ailo> len-dt: Also, the threadirqs option was included with 2.6.39, if I remember correctly. Either that, or the version before
[00:46] <TheMuso> ailo: Its UDS this week, so will be flat out with that, probably not till I return, eta Monday week.
[00:47] <ailo> TheMuso: Ah, right. Well, I'm not in any particular hurry, so whenever you can is fine with me
[00:47] <TheMuso> Ok no problem.
[00:47] <len-dt> OK, ailo the network-manager is another of those respawn things.
[00:54] <ailo> len-dt: How's your skill in reading C?
[00:55] <len-dt> It has been a number of years to honest. No real training, just read the part of the book needed for the next project ;-)
[00:55] <len-dt> ailo, what would you like me to look at?
[00:56] <ailo> I'm looking at the kernel patch. Unfortunately, I don't read C very well. Trying to figure out where the threadirq function is defined, or whatever, and where it in that case could be enabled without having to add a boot option
[00:56] <ailo> len-dt: I pasted the patch here http://paste.ubuntu.com/972612/
[00:58] <ailo> The interesting part I guess starts at around line 87 .. linux-2.6-tip/kernel/irq/manage.c
[00:59] <len-dt> ailo, I had just sort of figured that out..
[01:02] <ailo> len-dt: I was just reading a comment there, which talks about some buses being slow, like maybe the irq for your network card
[01:03] <ailo> It's a little frustrating not having a good picture of the whole. I really should go to school and study these things
[01:04] <len-dt> ailo, I'm a bit old for that ;-) I've had enough school forever...
[01:19] <len-dt> ailo, it has to be the bit at the begining of manage.c (lines 95 to 105)
[01:20] <len-dt> To really tell I would have to know the way the kernel deals with CL parameters.
[01:24] <len-dt> ailo it seems to be a call to early_param()
[01:24] <ailo> len-dt: I think this might have to do with it too, lines 155,156
[01:24] <ailo>  	sched_setscheduler(current, SCHED_FIFO, &param);
[01:24] <ailo>  	current->irqaction = action;
[01:24] <ailo> Wondering about &param particularly
[01:24] <ailo> But then, I don't really know what I'm reading
[01:26] <ailo> SCHED_FIFO is important at least http://lwn.net/Articles/296419/
[01:26] <len-dt> Part of the problem is that the rest of the file is missing. It would be best to look at manage.c with the patch added. It would add context to things
[01:29] <ailo> len-dt: I suppose you are right
[01:29] <ailo> Still, the part which makes threadirqs option readable is in that patch
[01:31] <len-dt> Yes. but what it does with it is not.... maybe...
[01:38] <ailo> Well, it's always interesting to learn half a story of something new :P. I'm hoping someone will pick up on the subject on LAD and explain how the threadirq option can be added into the source.
[01:38] <ailo> Now it's time to go to bed!
[02:17] <len-dt> QasMixer has some nice features over the xfce mixer for setting levels while using jack.
[10:44] <ailo> len-dt: Well, it seems there is a way to add boot arguments to the source, without the need to hard code it. It can be done adding the argument to /arch/<arch>/Kconfig under a couple of places, but I don't think this is how -lowlatency does it
[12:47] <ailo> len-dt: I started a discussion about the rtirq script on LAD
[12:47] <ailo> http://lists.linuxaudio.org/pipermail/linux-audio-user/2012-May/084809.html
[12:47] <ailo> LAU, I mean
[12:47] <ailo> Anyway, I really want to get to the bottom with this
[12:47] <ailo> You have your NM causing problems in spite of the rtirq script
[12:48] <ailo> I want to know if we can make your problem go away without stopping NM
[12:55] <ailo> len-dt: Also, about the threadirq, it can be passed as a kernel config option argument. Just trying it now
[14:11] <len-dt>  ailo hi, just woke up. I am certainly willing to try things. My netbook is about the worst HW likely to be used for audio.
[14:20] <len-dt> ailo, there is probably slower HW around, but this is about as anti-audio as they get ;-)
[14:22] <ailo> len-dt: Sounds like a perfect machine for testing then
[14:23] <ailo> One thing I realized I haven't really tried is running stuff without realtime privilege, to see what the difference is
[14:24] <len-dt> ailo, I figure so. I played with recording using the internal audio IF and an external (cheap) mixer.
[14:25] <len-dt> I turned the internal card way down (mic boost off) and the mixer as high as I could with out clipping.
[14:26] <len-dt> I used a dynamic mic (no phantom power) with an xlr to phone jack adaptor.
[14:28] <ailo> Running jackd without privileges on -lowlatency is sort of like running jackd with privileges on -generic
[14:28] <ailo> Working pretty decently at -p 128
[14:28] <len-dt> I was able to record quite a quiet stuff. It is not studio quality for sure, but good enough pod caste for example.
[14:29] <ailo> Allthough, I believe -generic is worse
[14:29] <ailo> len-dt: Not bad :P
[14:29] <len-dt> -p 128 is the lowest jack will even start at on my netbook
[14:31] <ailo> I'm more and more thinking that when it comes to system configuration, only the kernel and privileges are absolutely needed. And that the rest is very hardware dependant. Perhaps solvable by hacking the kernel
[14:32] <ailo> It would be nice if the kernel could be easily made more audio friendly, either by patching the vanilla source, or by adding ways to tune the kernel easily either during boot, or runtime
[14:34] <ailo> By patching I mean making it permanent for all kernels that derive from the vanilla kernel
[14:35] <ailo> I don't see why we need to shut things off in order to get rid of xruns
[14:35] <ailo> If audio is prio, then it should be able to make it prio more easily
[14:47] <len-dt> ailo, sorry, I was helping someone on the other channel connect a midi keyboard to qsynth.
[14:48] <len-dt> ailo, I think part of my problem may be the wlan driver.
[14:51] <len-dt> I'm not sure how unless the irq top half has more in it than it should.
[14:59] <len-dt> There may also be internal bus issues.
[15:44] <len-dt> ailo, the netbook is all about doing things with the least. I wonder if the wlan chip(set) uses system bus for some things. So NM tells wlan to scan and waits for irq when done, but wlan uses system bus while scanning preempting the cpu for a short time.
[15:44] <len-dt> I do know the video chip uses system bus, but it knows how to interleave better.
[15:46] <ailo> len-dt: Perhaps it is a driver issue then, and that the wlan is being rude by taking up too much time, or something? But, how do drivers work? Aren't they limited by something else in the kernel, or can you really create havoc for realtime applications with badly written drivers
[15:47] <ailo> If it is driver specific, then all hardware using that drivers could have the same issue
[15:47] <ailo> And in that case it's a matter of doing something to the driver, which is probably not open source
[15:48] <len-dt> ailo, the driver is supposed to be divided into top half and bottom half. the Top half is supposed to answer/reset the interupt and call the bottom half.
[15:48] <len-dt> If the top half does too much that would be a problem.
[15:49] <len-dt> The netbooks share a lot of stuff. It may even be that the wlan chip and the sound chip share things too.
[15:50] <len-dt> ailo, it will be interesting to see how my USB audio IF handles things.
[15:53] <ailo> I'm not sure I got the right picture, but I'm guessing it's something like this. The bottom half is either activated by whatever it is physically connected to, and since it doesn't have it's own way of storing a lot of the data coming through, it will want to pass that on to the top half, which in turn tells the kernel it is ready to send it's data, no?
[15:53] <ailo> Either activated by that, or the top half which wants to send info out..
[15:54] <ailo> It seems to me the problem is not in managing what is coming to the device, but in how network-manager handles it
[15:57] <ailo> And that the kernel allows network-manager to do something odd
[15:58] <ailo> Or, allowing the wlan device to execute a number of tasks in que instead of breaking it up
[16:03] <ailo> I'm being unclear as usual. I need to start reading about this stuff. Never been interested in drivers, hardware and that sort of things before
[16:06] <ailo> len-dt: What did you say the driver was called?
[16:46] <ailo> Found a nice tutorial on how to write device drivers for linux, as well as modules. Both are something I don't really what they are right now. http://www.freesoftwaremagazine.com/articles/drivers_linux http://www.linuxtopia.org/online_books/linux_kernel/linux_kernel_module_programming_2.6/index.html
[16:47] <ailo> I'd love to learn all that right away, but it's time to do other things for a while
[17:00] <Len-nb> ailo, netbook driver is ath9k.
[17:03] <Len-nb> The list of modules is much longer... aht9k, mac80211, ath9k_common, ath9k_hw, ath, cfg80211
[17:09] <Len-nb> probably the ath9k_hw is probably the one that plays with the irq
[17:20] <ailo> Len-nb: Well, at least that driver is FOSS http://linuxwireless.org/en/users/Drivers/ath9k
[17:22] <len-dt> ailo,  the question is if the problem is that or NM
[17:28] <ailo> len-dt: What is the model name for that notebook. I had a crazy idea. I might try to find a used one and buy it :P
[17:29] <len-dt> It says KV60
[17:29] <ailo> And he brand?
[17:29] <len-dt> acer aspire one netbook
[17:30] <len-dt> the acer aspire is a series of netbook/laptops.
[17:33] <len-dt> ailo, I have found it is one of the more usable netbooks. My wife has the HP (don't buy one) which has had more HW problems and has no pgup or pgdn keys even with funct.
[17:34] <len-dt> As a small computer the netbook is wonderful, it is light and small and yet complete.
[17:35] <ailo> I've actually had good experience with HP's
[17:35] <len-dt> I think the HP laptops are probably better, it is the netbook I don't like.
[17:35] <ailo> And ACER I often find is cheap for the performance you get, but it gets hot and noisy instead
[17:35] <len-dt> Cut too many corners...
[17:37] <len-dt> I have not found it too hot... though it does get warm. The atom chip is cooler than others.
[17:40] <ailo> len-dt: The IEEE that I've been using gets pretty hot with the atom, though it's kind of old. More recent notebooks are pretty splendid for the cost
[17:40] <len-dt> ailo, I will say that the HP battery seems to be lasting longer. My 3.5 hour battery is down to about 1.5 or so hours.
[17:40] <ailo> The HP's I've seen around seem to last forever
[17:41] <ailo> A more recent HP was a lot worse quality wise. Really bad keyboard
[17:41] <ailo> But there are thousands of models. Some are bound to be bad
[17:42] <len-dt> ailo, The HP has a less nice wlan chip, it drops connection more often than the acer. Not a big thing though, might be antenna placement.
[17:42] <ailo> I think I need to change strategy. Perhaps assemble a list of computers that are know to cause problems, and then try to find one for sale.
[17:43] <ailo> I should put an ad: Looking for really badly behaving hardware. Will pay a reasonable amount for it!
[17:44] <len-dt> I just added a note to the ubuntu aspire page about the internal mic. The left and right have to be unloacked and one full one and the other full off.
[17:44] <len-dt> The HW sends left and right inverted and alsa mixes them...
[17:44] <ailo> len-dt: You should probably mention this at alsa-devel list, and maybe a pulse list as well
[17:45] <ailo> Or maybe a bug-report?
[17:45] <ailo> To alsa, I mean
[17:45] <len-dt> The pulse/alsa devs are aware. "there will be no fix"
[17:45] <ailo> ok
[17:45] <len-dt> The problem is that it can't be auto detected.
[17:46] <ailo> It's not the same at each boot?
[17:46] <len-dt> The same chip is used different in different models.
[17:46] <len-dt> So if they fix my problem they break someone elses box
[17:47] <ailo> And they don't do model specific fixes
[17:47] <ailo> Why did you think the HP was worse again? M)
[17:48] <ailo> ;)*
[17:48] <len-dt> I don't know if they can.
[17:49] <len-dt> keyboard is lacking keys I use all the time. wireless seems less sesitive. HD light is hard to see. no line in jack for audio.
[17:50] <len-dt> Seems to me I had problems with the card reader too at one point. I haven't tried it for a while though.
[17:50] <len-dt> the card reader on the acer had problems at one kernel release too.
[17:51] <len-dt> Its funny because the OS sees it as a usb device and a usb stick or a USB card reader works fine...
[17:51] <len-dt> even with the same SD card.
[17:53] <len-dt> HP has had problems with the sound. But not with 12.04, when we first got it I had to manually switch the output from headphone to speaker... some config change or something. It seems to be fixed though. I put 12.04 in and it just works.
[17:55] <ailo> I'm getting more and more convinced about the HP. At least for audio use :P. I would guess you can run jackd at a lower latency and without xruns caused by the network manager
[17:56] <len-dt> But no audio in.
[17:56] <len-dt> So what would the point be?
[17:59] <Len-nb> ailo, when I get the usb audio IF, I will try it on both.
[18:02] <ailo> Len-nb: I,ve rarely used builtin devices for recording, so that would be no problem for me. But, when usb is the only option otherwise, I guess that is a problem in itself. At least from how it seems
[18:02] <ailo> I think this must be the single biggest problem in the linux pro audio world right now in fact
[18:03] <ailo> In a modern world you'd like to be able to move away from pci cards
[18:04] <ailo> Firewire is great, if you have a port for it. For now, that is the only type of notebook I could imagine getting for audio use
[18:04] <ailo> Also since I already have a functioning firewire device
[18:05] <ailo> We use my friends macbook at times with it, since we only use puredata
[18:05] <ailo> I'd love to install linux on it, but it's not my hardware, so :D
[18:07] <Len-nb> ailo, the big plus with the netbook is size. If there was a proper USB2.0 audio standard then I think the max number of inputs likely to be used would be available.
[18:08] <Len-nb> Really, once I start carrying more than two mics, the size of a notebook computer doesn't matter and the advantage of using a netbook is gone.
[18:10] <Len-nb> ailo, having said that... the one port (fast even) that every computer has these days is Ethernet. It would be nice to see cheap ethernet sound IFs.
[18:12] <Len-nb> With an open standard. It should be possible to add an ethernet plug to any of the FW/USB sound IFs now available.
[18:13] <Len-nb> Just put jack-net on there....
[18:17] <Len-nb> ailo, how about a little box with two eth connectors and one FW connector.
[19:13] <Len-nb> ailo, just put a message on the list with some thoughts about latency and workflows.
[19:16] <ailo> I still don't believe in shutting down stuff that should work
[19:16] <ailo> Something like the NM should not be causing problems for audio
[19:16] <ailo> Nothing should
[19:17] <ailo> I can understand not including processes that are useless on a audio desktop
[19:17] <Len-nb> I conclude that the few uses where really low latency matters are not uses where networking needs to be on.
[19:17] <Len-nb> we have talked about a "record mode", but I think it makes more sense to think in terms of latency levels.
[19:17] <ailo> I don't agree with that
[19:18] <ailo> I think that is backwards thinking suitable for 2001
[19:18] <Len-nb> we have a new ISO in our daily.
[19:18] <ailo> A standard desktop is not causing any problems on most systems
[19:19] <ailo> I can put 100% load on both my cores, and that will not affect audio performance
[19:19] <ailo> Or not much
[19:19] <Len-nb> I agree with that because even my 8 year old desktop has no problems with it.
[19:20] <ailo> I'm more into not having to do any adjustments at all, and that someone can add stuff to their desktop without breaking audio performance
[19:20] <ailo> Since xruns aren't caused easily
[19:21] <ailo> All I need to do is add two config options to the kernel and recompile + add realtime privilege
[19:21] <ailo> That's it
[19:21] <ailo> All desktops work just as well. Gnome3, XFCE, Unity
[19:22] <Len-nb> ailo, for most uses, with latency set to reasonable levels. This netbook is fine.
[19:22] <ailo> No software that I know of is causing xruns for me
[19:22] <ailo> Instead of making things complicated for the user, it might be better to solve some techincally complicated problems
[19:23] <ailo> Since then there would be no need to fix anything from the user side
[19:24] <ailo> Also, I don't see why LTS 2012 should put too much weight on being compatible with machines from 1002
[19:24] <ailo> 2002*
[19:24] <ailo> It's going to be the LTS for 4 years
[19:25] <ailo> And 4 years from now, computers from 2002 will be 14 years old
[19:25] <ailo> That's pretty old
[19:25] <Len-nb> the only use that would cause problems with this netbook are live uses. And really i am not sure that this is the appropriate hardware for that seeing as HW synths are more robust anyway. and so are guitar effects. maybe cheaper too.
[19:25] <ailo> 5 years back makes more sense to me
[19:26] <Len-nb> ailo I was not suggesting making 8 year old machines work, only pointing out I have one that does... without any trouble or extra configuration.
[19:26] <ailo> The older netbooks are a bit like P3 computers, aside from having slightly better graphic cards
[19:27] <ailo> At least the single core ones
[19:27] <Len-nb> This Netbook is less than two years old
[19:28] <Len-nb> The new ones are not any better. They are not made for audio, but for browsing. I would not suggest that an audio distro be based on one.
[19:29] <ailo> I didn't mean to say we shouldn't support netbooks. I think they are fine, and support reasonable graphic load as well. Their weak point may be processing power, which is not really that much affected by the desktop and its processes in my experience
[19:29] <Len-nb> It is interesting to see how much can still be done. I just want to see how far I can push it.
[19:29] <ailo> So, they will perform poorly nevertheless, except they can support a more modern UI
[19:34] <Len-nb> The nice thing is that they can be used for audio at all. And they can do it reasonably well. One's expectations have to fit the HW.
[19:35] <Len-nb> ailo, anyway, assuming a reasonably new machine.... what changes should we be making for 12.11 now that there are daily builds...
[19:38] <Len-nb> ailo, I have been looking qasmixer for audio IF that do not need their own mixer.
[19:39] <Len-nb> This is not to replace pavucontrol, but to be in the mixers menu
[19:39] <Len-nb> for use when setting up levels to use with jack.
[19:44] <ailo> I'll have a look
[19:47] <ailo> Len-nb: Pretty neat
[19:48] <ailo> Nice to have both pulse and alsa there
[19:48] <ailo> Strange things happen when I move the pulse level
[19:49] <ailo> Both pcm and master are affected
[19:52] <ailo> I can see that some people would prefer that to the pulsemixer
[19:52] <Len-nb> ailo, try setting pavucontrol beside and control PA with that while watching what happens to the alsa levels.
[19:53] <Len-nb> I was not thinking to replace the pulse controller, but the xfce mixer
[19:54] <ailo> I didn't mean that you should replace it
[19:54] <ailo> But, I still think some people might use this one more often than pavulcontrol
[19:55] <Len-nb> It is nice to everything on one page.
[19:55] <Len-nb> I could even use it for the envy24 for most things.
[20:06] <ailo> I do think it would be good to have a trouble-shooting helper
[20:06] <ailo> Sort of like the "record mode" you have been talking about
[20:07] <ailo> I guess it would be convinient to be able to toggle many things with one button
[20:07] <ailo> But, I wouldn't want to call it "record mode", since it's really more of a last resort
[20:08] <ailo> More like a workaround for specific issues
[20:12] <Len-nb> ailo, "record mode" was not my name for it. just what was being used.
[20:12] <Len-nb> low latency tweak might be better.
[20:13] <ailo> I don't think it would get you lower latency either
[20:13] <ailo> Shutting off NM would only fix issues for normal latency on certain machines
[20:13] <ailo> It won't lower it for anyone
[20:14] <ailo> And I don't expect there are any other tweaks that will do that either
[20:14] <ailo> I don't expect there will be anything that will enhance performance much at all
[20:16] <ailo> That is why I object to the idea of having a "record mode" button, because it would be falsely suggesting that you do get a performance boost, when most likely it does nothing at all
[20:19] <ailo> Other than shut down things that you might now need to shut down
[20:25] <ailo> Just out of nowhere I'm having huge problems with xruns using my builtin card
[20:26] <Len-nb> ailo,  on this machine minimum latency without NM is -p128 but with, it is 1024 with no xruns.
[20:32] <ailo> Len-nb: Yes, and I'd say 128 is quite a high latency on a modern system, so we're not talking about improving latency. More so about fixing an uncommon problem which prevents you from having "normal" operation
[20:34] <ailo> The goal should be at least 64 on a fairly modern machines, like dual core and onwards
[20:35] <ailo> 128 to me is a bit too slow
[20:35] <ailo> Depending on the machine probably, but still
[20:36] <ailo> Netbooks are a bit like P3 when it comes to processing power, so 128 is probably a good lowest latency for them
[20:37] <ailo> That's what I would get with a P3 and a realtime kernel, not too long ago
[20:51] <len-dt> ailo, I will see what I get with the usb IF when I get it. The 128 may be a hardware thing to get away with a cheaper card.
[21:29] <ailo> 20
[21:41] <ailo> len-dt: Interesting. The kernel that had "threadirq" put as a config option for the build was giving me xruns like crazy
[21:42] <ailo> With the rtirq script using that kernel I got the opposite effect of what you would expect
[21:42] <ailo> I'm on the same exact kernel now with the only diff being that this boot option was not added during the build
[21:43] <ailo> "threadirqs"*
[21:50] <ailo> It's the same with using it during boot-time. Just checking to be sure :P. I didn't notice this before
[21:58] <len-dt> ailo, fun with tuning.
[21:59] <len-dt> amybe that option turns it off?
[21:59] <len-dt> s/amybe/maybe/
[22:11] <ailo> len-dt: No, it turns it on for sure
[22:11] <ailo> I've found that this machine will start misbehaving with the rtirq script enabled
[22:12] <ailo> I double-checked with the -lowlatency on Ubuntu Studio, and it's the same thing
[22:13] <ailo> Don't have the energy to find out why today. But I'm coming to the conclusion that in normal cases the rtirq script is superfluos and should perhaps only be used to fix problems
[22:14] <ailo> Having it on by default may cause just as many problems as it fixesa
[22:14] <ailo> Or the script just needs to be edited
[22:15] <ailo> len-dt: Did you ever try moving moving away the script and try without it?
[22:16] <ailo> All though, it doesn't fully help because threadirqs are enabled anyway
[22:16] <len-dt> ailo, no. I haven't. It doesn't seem to hurt this desktop anyway.... well I did move all the pci cards around.
[22:16] <ailo> We need a kernel to test without that option enabled, but with PREEMPT config
[22:17] <len-dt> ailo, the web pages to do with it do say that somethings are high with out the script.
[22:19] <len-dt> USB is kinda wonky anyway. on some machines some of the internal peripherals use USB ports too
[22:19] <ailo> len-dt: Normally the rtirq script should do nothing at all, since normally you don't have a problem. I never heard of someone getting problems because of it though, and this is the first for me. That is why I would like to see if it is the same for you
[22:19] <len-dt> ailo, How do I test then?
[22:20] <len-dt> How do I turn it off?
[22:20] <ailo> len-dt: First we need a kernel without the threadirqs enabled, since -lowlatency has it hardcoded
[22:20] <ailo> It's edited into the source code. I checked with abogani before
[22:21] <ailo> I could build one and pass a link later
[22:21] <ailo> Maybe tomorrow, or the next day
[22:21] <len-dt> OK, whenever.
[22:21] <len-dt> As always I'm not always available...
[22:24] <ailo> len-dt: What arch btw?
[22:24] <ailo> No matter. I should build both anyway
[22:26] <len-dt> ailo, 32 bit... both machines
[22:28] <len-dt> ailo, I just took out the yamaha rm602 mixer and put the mackie 1604 in...
[22:29] <len-dt> there is a big diff in sound even with an avi file.
[22:29] <ailo> len-dt: That Yamaha looks a bit old :)
[22:30] <len-dt> The mackie is not much newer actually. It is one of the first 1604s with the 6 mic preamps
[22:31] <ailo> I have an older Heath & Allen, which can be controlled with a commodore 64. Used to cost a whole lot. Got it cheap some years ago. Killed it unfortunately :(
[22:31] <ailo> Or is it Allen and Heath?
[22:31] <len-dt> ailo, the yamaha was made to use with an old cassette porta studio kind of setup.
[22:31] <ailo> Been mostly using a Behringer, 16 ch mixer. Not bad really
[22:32] <ailo> len-dt: Ok, so it wasn't exactly top notch
[22:32] <ailo> With our live setup with the band we're down to using only the firewire device
[22:33] <len-dt> It was easy to access and hook up when we moved in. There wasn't room for the mackie. Now that I need the phantom power...
[22:33] <ailo> That and a laptop, + our instruments
[22:33] <len-dt> Ya mixers are not really needed for recording any more.
[22:34] <len-dt> less stuff to hook up and everything.
[22:34] <ailo> I have a couple of really decent preamps, and mics to go with them, so vocals, and anything acoustic stereo is going to sound really ok
[22:35] <ailo> For the rest it's mostly sm58 and mics like that
[22:35] <ailo> A couple of audo line CM3's
[22:36] <len-dt> Thats why I'm getting the ART pre. It is a lot easier to lug around than the mackie.
[22:36] <ailo> You only need a lot of mics for drums, or when you record stuff live
[22:38] <len-dt> I started on drums, but I haven't had a kit for years now.... I have an 8pad box and hydrogen...
[22:39] <len-dt> I kind wish I at least had a snare... so many different sounds depending on how it is played.
[22:44] <ailo> I'm a drummer too, though I began plauying guitar at the same time. I also play piano. Have a trumpet, but haven't had the time to learn it. Strange instrument :P. Played some violin too
[22:44] <ailo> So, mostly string instruments and percussion


[00:01] <blahdeblah> We're done now
[00:01] <blahdeblah> (Took longer than expected)
[00:23] <hggdh> blahdeblah: thank you
[00:25] <Unit193> At this time, nobody in #ubuntu-devel is going to be very active anyway.
[00:25] <dax> two people noticed in #ubuntu
[00:25] <dax> quite underwhelming.
[00:25] <blahdeblah> Which is why we do it during APAC business hours. :-)
[00:26] <blahdeblah> thanks everyone - have a good day/night
[00:26] <Unit193> dax: Oh?  Now I have to search scrollback. :(
[02:23] <Unit193> Seems like PPAs are having issues with 403 errors.
[06:08] <sutehh> sveta is a marriage scammer
[06:08] <sutehh> sveta is a marriage scammer
[06:08] <sutehh> sveta is a marriage scammer
[06:08] <sutehh> sveta is a marriage scammer


[03:39] <lifeless> [03:39] <lifeless>     Hard / Soft  Page ID
[03:39] <lifeless>       32 /  174  BugTask:+index
[03:39] <lifeless>       13 /  203  Distribution:+bugs
[03:39] <lifeless>        9 /   59  MailingListApplication:MailingListAPIView
[03:39] <lifeless>        8 / 2453  Archive:+index
[03:39] <lifeless>        7 /    9  ProjectGroup:+milestones
[03:39] <lifeless>        6 /   14  DistroArchSeries:+index
[03:39] <lifeless>        6 /    3  Cve:+index
[03:39] <lifeless>        5 /    6  NullBugTask:+index
[03:39] <lifeless>        5 /    0  Distribution:+builds
[03:40] <lifeless>        4 /    0  Distribution:+ppas
[04:11] <StevenK> lifeless: Don't you have holiday stuff to do?
[04:30] <nigelb> lol
[04:45] <lifeless> StevenK: I hit 1000 valour points today
[04:48] <StevenK> It'd be nice if I could actually get into heroics
[06:13] <lifeless> why can't you?
[06:14] <lifeless> StevenK: ^
[06:29] <StevenK> lifeless: I've never finished a heroic
[07:48] <lifeless> StevenK: what happens?
[17:43] <LPCIBot> Project devel build (344): STILL FAILING in 3 hr 33 min: https://hudson.wedontsleep.org/job/devel/344/
[22:15] <LPCIBot> Project db-devel build (258): STILL FAILING in 3 hr 34 min: https://hudson.wedontsleep.org/job/db-devel/258/


[14:58] <tjaalton> hmm so multipath-udeb is in universe, and can't be directly used by the installer?
[15:01] <tjaalton> oh wait.. will try again
[15:40] <tjaalton> nope, still fails with "unknown udeb multipath-udeb"
[15:49] <tjaalton> ok, so the udeb is in universe, and so is partman-multipath.. now I just need to figure out how to use them :)
[23:52] <jjjjjjjdawwwwg> Hi
[23:53] <jjjjjjjdawwwwg> could somebody assist me please?
[23:57] <TheMuso> jjjjjjjdawwwwg: #ubuntu for support.
[23:57] <jjjjjjjdawwwwg> I can't I'm banned there
[23:57] <jjjjjjjdawwwwg> Please help me out
[23:58] <TheMuso> Well, what is your problem?


[05:22] <makdt> hi,
[05:22] <makdt> how do i submit a report for what I think is a bug in Kubuntu/Ubuntu?
[05:23] <micahg> makdt: ubuntu-bug
[05:24] <makdt> which is another channel?
[05:24] <micahg> makdt: no, a utility
[05:24] <makdt> ah ok thanks. I saw link at the top of the page. Will try that first
[11:48] <gtriderxc> will anyone help a neewbie??:-)
[16:58] <ElPasmo> hi, will the bugsquad meeting be now here?
[17:00] <pedro_> i think so , it says 1700 UTC
[17:01] <ElPasmo> great, thanks pedro_
[17:01] <pedro_> hggdh, are you chairing the meeting? the wiki says so :-P
[17:12] <c2tarun> anyone here?
[17:12] <yofel> c2tarun: we're searching for hggdh
[17:12] <c2tarun> ok :)
[17:13] <hggdh> oh
[17:13] <hggdh> sorry, busy
[17:13] <hggdh> so...
[17:13] <hggdh> #startmeeting
[17:13] <hggdh> hellooooo
[17:13] <pedro_> hi there!
[17:13] <gtriderxc> 8
[17:13] <hggdh> where's the bot?
[17:13] <ElPasmo> hi there :)
[17:13] <c2tarun> busy too .. :P
[17:14] <yofel> mistook the 1 in the date for a 2 and went on vacation too early
[17:14] <hggdh> OK. The meeting is officially started (late, though, sorry). The bot does not seem to be here
[17:15] <hggdh> first, on the actions from the previous meetings
[17:15] <hggdh> er. This does not seem to be correct, but there I go:
[17:16] <hggdh> 1. Bug Day to be created for regression-potential tags
[17:16] <hggdh> did we not already discuss this?
[17:16] <pedro_> i think we already did that, yes
[17:17] <hggdh> heh. So the agenda is out-of-date... at least for the "previous meetings"
[17:17] <hggdh> so let's jump over to Mentorship programme update
[17:17] <pedro_> it was ran on 2010 10 21
[17:18]  * charlie-tca waves
[17:18] <hggdh> mentors -- please update on status
[17:19] <hggdh> from my side: ojap is slowly going on
[17:20] <hggdh> pedro_, vish, charlie-tca, yofel, & co: any updates on mentorship
[17:20] <hggdh> ?
[17:20]  * yofel isn't a mentor
[17:20] <pedro_> as in now , i don't have any student
[17:20] <charlie-tca> I am going to have the logo images broken down for us
[17:20]  * hggdh considers yofel *should* be one ;-)
[17:20] <charlie-tca> I have no mentees
[17:20] <pedro_> yeah yofel, definitely ;-)
[17:20] <charlie-tca> +1 for yofel to have at least oen
[17:21]  * charlie-tca should hide now
[17:21] <ElPasmo> oen?
[17:21] <pedro_> heh
[17:21]  * yofel hides and put's on an invisibility cape before anything more happens..
[17:21] <pedro_> s/oen/one ? :-)
[17:21] <ElPasmo> :P
[17:21] <hggdh> dyslexia, please pardon me
[17:21] <charlie-tca> See, I knew you would know what I meant
[17:22] <hggdh> what I see: mentorship is still slow
[17:22]  * charlie-tca trying to use three keyboards and two mice at once again
[17:22] <hggdh> mentees propose themselves, but do not really devote time
[17:22] <charlie-tca> Have we added people to group A yet?
[17:23] <hggdh> we have two there, yes
[17:23] <yofel> did the beginners team cooperation result in anything yet btw.?
[17:23] <charlie-tca> Can't we add a few more to the team?
[17:24] <hggdh> yes, we should
[17:24] <hggdh> [ACTION] I will look at the pending list and add some more
[17:24] <hggdh> next
[17:24] <hggdh> nigelb to edit bugsquad headers to be similar or link to each other appropriately
[17:24] <pedro_> yofel, as far as i know there's no much input on that
[17:25] <hggdh> nigelb: how has that gone?
[17:25] <ElPasmo> In fact I have a question about mentees, Should I have done some contributions before asking for a mentor or anyone can ask without any previous contribution?
[17:25] <nigelb> hggdh: I delayed it waiting for wiki update.  NOw that the update has hit, I'll get on it.
[17:25] <charlie-tca> ElPasmo: ask anytime you desire a mentor. Experience is not needed first
[17:25] <hggdh> ElPasmo: anyone can ask, as long as the pre-requisites are fulfilled
[17:25] <pedro_> ElPasmo, anyone can ask for it
[17:25] <ElPasmo> thanks :)
[17:25] <pedro_> heh
[17:25] <mrand> charlie-tca: check into synergy for the multiple mouse and keyboards
[17:26] <pedro_> why i didn't say : no! ?
[17:26] <hggdh> [ACTION] nigelb to keep on with update of bug page headers
[17:26] <charlie-tca> mrand: on different computers with three monitors?
[17:26] <mrand> charlie-tca: yes
[17:26] <charlie-tca> okay
[17:26] <charlie-tca> thanks
[17:26] <hggdh> next: devildante to split HowToTriage page up into a simple page and an advanced page
[17:27] <hggdh> devildante is MIA today. Anybody knows how this is progressing?
[17:27] <pedro_> i know he was working on it, but don't know the real progress as in today
[17:27] <pedro_> we can ask him on the ML though
[17:27] <hggdh> yes
[17:28] <hggdh> [ACTION] check with devildante about the split on basic/advanced HowToTriage
[17:28] <hggdh> and before I forget
[17:29] <hggdh> [ACTION] find out what happened with the meetingcology bot
[17:29] <pedro_> indeed
[17:29] <hggdh> now
[17:29] <hggdh> GNOME3 bug handling -- micahg
[17:29] <hggdh> micahg: please take over
[17:30] <hggdh> heh. micahg seems to be here only physically, mind elsewhere
[17:31] <hggdh> so
[17:31] <hggdh> Open Discussions.
[17:31] <micahg> ok, sorry
[17:31] <hggdh> micahg: please go on
[17:31] <hggdh> :-)
[17:31] <hggdh> micahg: I did the same just a few ago
[17:32] <micahg> so, the desktop team would like a way to tag bugs for the GNOME3 transition, most of it won't happy until natty+1, but they would like to be able to track bugs against their GNOME3 staging PPA
[17:32] <micahg> I wanted to propose a GNOME3 tag to be official at least for the next 2 cycles, how does everyone feel about that
[17:33] <hggdh> only one tag?
[17:33] <micahg> do we need more?
[17:33] <pedro_> what for you'd need more?
[17:33] <hggdh> IDK, I am not familiar with the desktop effort on Gnome3
[17:34] <seb128> there is nothing specific there
[17:34] <bdmurray> a gnome3 tag works for me
[17:34] <seb128> rather than landing the usual GNOME updates to natty we use a ppa
[17:34] <seb128> we might decide to move the ppa to natty if it's ready
[17:34] <seb128> otherwise it will land in natty+1
[17:34] <seb128> it's just that we are not confident yet that GNOME3 will be ready for natty
[17:35] <hggdh> OK. So bugs on the Gnome3 PPA are valid Ubuntu bugs -- folks, please do not forget this
[17:35] <seb128> well, they are valid but not targetting natty so far
[17:35] <seb128> so the same settings might not apply
[17:35] <seb128> they should not show on the r-t list
[17:36] <seb128> or the rc bugs listing
[17:36] <hggdh> seb128: the warning was mostly due to the fact that PPA-based bugs usually are not accepted
[17:36] <hggdh> seb128: so no targeting/milestoning these bugs, correct?
[17:36] <seb128> yeah, I'm still not sure we want to accept bugs about upstream issues
[17:36] <seb128> we do want bugs about distribution integrations issues though
[17:37] <seb128> or patches to updates
[17:37] <yofel> seb128: can't you have your own project for that bugs like kubuntu-ppa does?
[17:37] <seb128> seems suboptimal
[17:37] <yofel> you'll need an apport hook anyway since they're ppa packages
[17:37] <hggdh> there is that, yes
[17:38] <seb128> not sure we want apport bugs
[17:38] <yofel> and if you add a hook, then you can make to hook add the gnome3 tag
[17:38] <yofel> s/to/the/
[17:39] <hggdh> seb128: it sounds to me that you expect most of these bugs to be opened by developers or "official" testers, is this correct?
[17:39] <hggdh> i.e. manually opening them
[17:39] <Pici> w/22
[17:39] <Pici> sorry.
[17:40] <seb128> hggdh, well micahg raised the topic
[17:40] <seb128> I didn't think about it yet
[17:40] <seb128> but we don't want to be spammed with upstream bugs
[17:40] <njin> hello to all, does we have a 2.6.37 kernel-pae ?
[17:40] <seb128> we just want to know about integration issues
[17:40] <hggdh> njin: please wait a bit, in the middle of a meeting
[17:41] <micahg> hggdh: I would think mostly yes, but some things like gnome-shell will only be in the PPA unless GNOME3 lands, so we might get some users as well
[17:41] <hggdh> OK. Would it be fair to say, then, that we are adding the gnome3 tag, and details on how to deal with the _triaging_ will be ironed out later?
[17:41] <charlie-tca> If we at least get them tagged for gnome3, the ones that are not ours, someone who knows the package could delete, couldn't they?
[17:42] <hggdh> sounds plausible, charlie-tca. But I worry about triagers doing the Wrong Thing
[17:43] <seb128> hggdh, well we can start by adding the tag and see how it goes
[17:43] <seb128> I'm wondering if we want the topic to reflect that as well
[17:43] <seb128> ups
[17:43] <seb128> topic -> title
[17:44] <seb128> so those bugs are spotted easily from a bug list
[17:44] <hggdh> micahg, seb128: how about adding the tag to the official list, and adding a note on the HowToTriage asking to leave these bugs alone right now?
[17:44] <charlie-tca> If the tag is added to the tags page, it can explain what is happening with it
[17:44] <seb128> hggdh, works for me
[17:45] <micahg> wfm, too
[17:45] <seb128> we can tweak later when required
[17:45] <charlie-tca> and, of course, there will be hundreds of bugs we get questions about :-)
[17:45] <seb128> or if required
[17:45] <hggdh> seb128: a [GNOME3] in the title would make is immediately visible
[17:45] <seb128> yes
[17:45] <charlie-tca> I like that
[17:45] <njin> yes
[17:46] <hggdh> and, since right now they would have to be entered manually (no apport hook), this limits the number of probable OPs
[17:46] <hggdh> these pretty much know what to do
[17:46] <hggdh> How will update the tag list?
[17:47] <hggdh> /How/who/
[17:47] <bdmurray> I will
[17:48] <hggdh> [ACTION] bdmurray to add 'gnome3' as an official (temporary) tag, with a comment to leave these bugs alone for now
[17:48] <hggdh> anything else on GNOME3?
[17:48] <micahg> thanks hggdh, bdmurray, seb128
[17:49] <hggdh> OK
[17:49] <hggdh> Open Discussion
[17:49] <hggdh> anyone would like to share/comment/ask anything related to triaging?
[17:50] <hggdh> <dead silence ensues/>
[17:50] <charlie-tca> o/
[17:50] <hggdh> charlie-tca: please go ahead
[17:50] <charlie-tca> Launchpad is having a 2010BugJam
[17:50] <charlie-tca> They would like to close 6500 bugs
[17:50] <hggdh> oooohhhh
[17:50] <hggdh> OOOOHHHH
[17:50] <hggdh> when?
[17:50] <charlie-tca> https://dev.launchpad.net/BugJam
[17:50] <charlie-tca> now
[17:51] <charlie-tca> 13th-24th December 2010
[17:51] <micahg> charlie-tca: I believe those are launchpad project bugs :)
[17:51] <ElPasmo> Is tomorrow a class at #ubuntu-classroom about Basic Triaging at 17:00 UTC?
[17:51] <charlie-tca> Does that mean we can't help?
[17:52] <hggdh> but important to us also ;-)
[17:52] <micahg> charlie-tca: no, it only means it's tangentially related ;)
[17:52] <hggdh> ElPasmo: I think yes
[17:52]  * micahg thought it was today
[17:52] <charlie-tca> I thought the class was today?
[17:52] <hggdh> charlie-tca: on the 15th
[17:52] <micahg> well, calendar says tomorrow, but I thought it was today
[17:53] <charlie-tca> Isn't that where devildante is today?
[17:53] <micahg> Yeah, I think the wrong date was entered
[17:53] <ElPasmo> oh no... I've missed it :(
[17:53] <yofel> classroom is dead silent though
[17:54] <hggdh> yes, nothing happening there
[17:54] <hggdh> and, on the Fridge calendar, it is scheduled for tomorrow
[17:55] <hggdh> so...
[17:55] <hggdh> ElPasmo: it is indeed tomorrow, I guess ;-)
[17:55] <ElPasmo> Well, and excuse my ignorance, but I  suppose that the mentoring processs you talked before is the motu mentoring process?
[17:55] <ElPasmo> Thanks hggdh
[17:55] <hggdh> ElPasmo: no, not at all
[17:56] <hggdh> we deal with *triaging*, not with packaging/development
[17:56] <hggdh> although a lot of us also do that
[17:56] <ElPasmo> I see, Are they incompatible?
[17:56] <hggdh> not incompatible, just two completely different things
[17:57] <hggdh> MOTUs also do triaging
[17:57] <hggdh> but not necessarily triagers do packaging/developing
[17:57] <ElPasmo> Can you point me a link with the bugsquad mentoring?
[17:57] <yofel> ElPasmo: https://wiki.ubuntu.com/BugSquad/Mentors
[17:57] <ElPasmo> thanks :)
[17:58] <hggdh> any other questions?
[17:59] <hggdh> given the silence...
[17:59] <hggdh> #endmeeting
[17:59] <hggdh> and yes, I know the bot is not there ;-)
[17:59] <hggdh> uffff
[17:59] <hggdh> sorry for the delay again, folks
[17:59] <ElPasmo> You have finished just in time :P
[18:00] <hggdh> well, I started it late also...
[18:01] <charlie-tca> Thanks for chairing, hggdh
[18:01] <charlie-tca> You done good!
[18:05] <hggdh> oh
[18:05] <hggdh> I forgot!
[18:06] <hggdh> Who will be the next chair... I will take it again
[18:06] <charlie-tca> Yeah, I got caught by that in the qa meetings
[18:07] <charlie-tca> chaired for two meetings in a row
[18:09] <charlie-tca> hggdh: add it to the agenda this time?
[18:09] <hggdh> charlie-tca: well, now you are asking for a LOT ;-)
[18:09] <hggdh> I will do it, of course
[18:09] <charlie-tca> heh, Just seemed like an idea ;-)
[19:53] <ScottK> Someone who looks after standard bug replies might want to look at the "sync request process" thread that just started on ubuntu-devel-discuss.
[20:07] <hggdh> ScottK: thank you for the heads up
[20:08] <ScottK> You're welcome.
[20:19] <hggdh> sigh. An over-entusiastic triager... we recommend sync/merge *not* to be touched by triagers...
[20:25] <Aqua> Help, I think I submitted a bug in a wrong category, or how do you call it
[20:25] <Aqua> https://bugs.launchpad.net/ubuntu/+bug/690334
[20:25] <ubot2> Launchpad bug 690334 in ubuntu (and 1 other project) "Some special keys Microsoft Digital Media Keyboard 3000 don't work (affects: 1) (heat: 6)" [Undecided,New]
[20:26] <Aqua> how do I transfer it to the general ubuntu bug queue?
[20:26] <Aqua> or just tell me what the fuck I have to do
[20:27] <charlie-tca> Aqua: it is already in the general queue.
[20:28] <charlie-tca> Please watch your language in this channel and keep it family friendly
[20:28] <Aqua> yes, but it is not supposed to be in release notes for Ubuntu I think
[20:28] <Aqua> lol
[20:29] <charlie-tca> fixed
[20:30] <Aqua> charlie-tca :  you put the status on invalid, that's all it takes?
[20:30] <Aqua> thanks
[20:30] <charlie-tca> You are welcome
[21:10] <njin> Problem in download page, iot refere to click the button to download the latest version, but iut will download 10.04.1 bug 690229, at wich assign ? thanks
[21:10] <ubot2> Launchpad bug 690229 in ubuntu "wrong wubi on Ubuntu download page (affects: 1) (heat: 8)" [Undecided,Confirmed] https://launchpad.net/bugs/690229
[21:21] <yofel> njin: close the ubuntu taks and open a task for the 'ubuntu-website' project
[21:21] <yofel> *task
[21:28] <njin> yofel:thanks


[04:42] <thorn> sets keyboard to "lurk" and says goodnight...
[05:11] <greg-g> huh, I'm reporting a bug with the title "Software Center SEGFAULTS when attempting to start" the night before release :(
[11:23] <iceroot> i want to create a debdiff for a package from 11.04 but i am using 11.10. is there an easy (and not space-intensiv) way to build up a 11.04 environment to build the source-package correctly?
[11:24] <iceroot> as it seems https://wiki.ubuntu.com/PackagingGuide/Recipes/Debdiff is down  :(
[11:57] <iceroot> how to get "kwallet-cli" as source-package for 11.04 when using 11.10? apt-get source will give me 11.10 version
[11:59] <iceroot> pull-lp-source kwalletcli natty
[12:00] <damg> should I branch off lp:ubuntu/${PROJECTNAME} or off lp:${PROJECT_NAME} on launchpad?
[12:22] <iceroot> maybe someone can have a look at my first debdiff for a security issue? feedback is very welcome  https://bugs.launchpad.net/ubuntu/+source/kwalletcli/+bug/802274
[12:22] <ubot4> Launchpad bug 802274 in kwalletcli (Ubuntu) "Security issue in kwalletcli_getpin(1): tty I/O now properly disables echoing input when asking for a passphrase is not fixed (affects: 1) (heat: 260)" [Low,Confirmed]
[12:26] <iceroot> also is it possible for me to upload packages to some testing repos instead of posting patch/diff on launchpad? or is this only for people from canocial? ( i am not talking about the real repos, just dev-repos)
[12:34] <hggdh> iceroot: ideally, you should have a local build environment -- look at pbuilder
[12:34] <iceroot> hggdh: so a complete chroot from 11.04
[12:34] <iceroot> or better a pbuilder-environment for 11.04, 10.10 and so onm
[12:35] <hggdh> iceroot: correct, only way to have a non-contamined environment
[12:35] <hggdh> and you can upload to a PPA for tests
[12:35] <iceroot> hggdh: are there pbuilder-images ready? or do i have to build it all myself?
[12:36] <hggdh> iceroot: unfortunately, you have to build them locally
[12:36] <iceroot> i guess pbuilder is downloading the dependecies with apt-get so i only need a very small environment to use it
[12:37] <hggdh> yes, it will.
[12:37] <iceroot> ok, then i will try it later
[12:37] <iceroot> but for just creating a debdiff, i dont need pbuilder. just build the dsc and use debdiff
[12:37] <iceroot> ?
[12:37] <hggdh> damg: lp:ubuntu/project is the Ubuntu localisation for the project; lp:project is the "upstream" project
[12:38] <hggdh> pbuilder is for _building_ the package; for a debdiff you only need the source packages
[12:38] <hggdh> iceroot: ^
[12:39] <damg> hggdh, thanks for the hint
[12:48] <iceroot> hggdh: thanks for the info
[13:30] <hggdh> alea jactas est, Oneiric is released
[13:31] <hggdh> s/jactas/jacta/
[13:40] <pedro_> \o/
[13:40] <pedro_> Thanks all for their contributions :-)
[13:40]  * pedro_ hugs the bugsquad
[13:47]  * hggdh hugs pedro_, so that he will not be feeling forgotten
[14:06] <roadmr> congrats all :)
[14:48] <bdmurray> mvo: Hi, about that apturl fix.  I end up getting a message saying that the package is virtual.
[14:55] <mvo> bdmurray: hm, what example are you using? I tested this with apt:libgl1-mesa-dri-experimental:i386 and it works for me
[14:55] <bdmurray> mvo: I tried skype as mentioned in the bug
[14:58] <bdmurray> mvo: I don't have partner in my sources.list though so that might be the issue
[14:58] <mvo> bdmurray: yeah, that is the issue, does apt:sykype:i386?channel=oneiric-partner
[14:59] <mvo> work
[15:01] <bdmurray> mvo: yes, that's great.  I was trying to fix this bug yesterday and missed that.  Could you sponsor my debdiff in bug 207065?
[15:01] <ubot4> Launchpad bug 207065 in compizconfig-backend-gconf (Ubuntu Lucid) (and 2 other projects) "Bad Compiz Bindings Bug (affects: 23) (dups: 2) (heat: 130)" [Low,Triaged] https://launchpad.net/bugs/207065
[15:03] <mvo> bdmurray: sure, hold on a minute
[16:32] <thorn> how do I share a screen shot of my computer so I can demonstrate a bug?
[16:36] <hggdh> thorn: you can use a graphical pastebin, or attach it to the bug
[17:03] <wagafo> Bug 873391 has an informative title :-! Is it OK if I change the title to "Failed to fetch packages" and tell the OP that he should try later because probably the server he tried didn't have yet the new packages?
[17:03] <ubot4> Launchpad bug 873391 in update-manager (Ubuntu) "Code: Failed to fetch http://gb.archive.ubuntu.com/ubuntu/pool/main/g/geoip/libgeoip1_1.4.8+dfsg-1ubuntu1_amd64.deb Unable to connect to gb.archive.ubuntu.com:http: Failed to fetch http://gb.archive.ubuntu.com/ubuntu/pool/main/b/bind9/bind9-host_9.7.3.dfsg-1ubuntu4_amd64.deb Unable to connect to gb.archive.ubuntu.com:http: Failed to fetch http://gb.archive.ubuntu.com/ubuntu/pool/main/b/bind9/dn
[17:05] <mvo> wagafo: sounds like the server is overloaded
[17:06] <wagafo> mvo: yes, that's more likely, I will tell also that possibility to the reporter
[17:08] <bdmurray> mvo: and a 503 might indicate the same thing yes?
[17:23] <SwitchDK> Could anybody tell me if the BugSquad mentorship team is still active? I just noticed that the "Proposed member" list contains application from April this year
[17:29] <bfwg> anybody seeing issues with the package 'ubuntu-minimal' when trying to upgrade?
[17:45] <ikt> SwitchDK: no it's not
[17:45] <ikt> afaik it's died
[17:49] <SwitchDK> ikt: that is sad news :(
[17:49] <SwitchDK> ikt: but thank you for letting me know
[17:50] <ikt> :D
[17:50] <bdmurray> That doesn't mean mentorship isn't available
[17:50] <bdmurray> Just that the whole team thing wasn't working out so well
[17:50] <ikt> are you interested in bug triage or just wondering?
[17:51] <SwitchDK> Ah ok, I would like to do triaging and just joined the BugSquad a month ago but I don't feel comfortable with triaging yet and was wondering how I could get to know the robes better
[17:51] <bdmurray> this channel is an excellent forum
[17:51] <ikt> forum of silence?
[17:52] <ikt> actually
[17:52] <SwitchDK> for a newbie it can be rather daunting to keep asking questions in the forum
[17:52] <ikt> why doesn't the bugsquad have a forum on the ubuntuforums?
[17:52] <SwitchDK> but if that is acceptable I will do that
[17:53] <greg-g> SwitchDK: a few of us in here usually try to respond to people's questions when they have them. Just ask and we'll respond when we see it
[17:54] <yofel> ikt: you want to split the information onto yet another medium?
[17:54] <SwitchDK> ok, thank you greg-g, ikt and bdmurray
[17:54] <ikt> yofel: that's classic
[17:54] <ikt> they said the exact same thing when I said we should make a forum for our loco team
[17:54] <yofel> heh
[17:55] <greg-g> ikt: which team are you from?
[17:55] <ikt> ubuntu australia
[17:55] <greg-g> awesome
[17:56] <ikt> yeah! our loco had the same problem as the bugsquad had
[17:56] <ikt> or has*
[17:58] <yofel> I just mean: what are you going to put on the forums and what on the ML once you have the forum?
[17:58] <yofel> you won't get everyone to use both
[17:59] <ikt> one sec, just grabbing the log, I swear this is deja-vu
[17:59] <yofel> I'm sure it is ^^
[18:01] <bil21al> hey congrats every body to oneiric release
[18:02] <SwitchDK> bil21al: indeed, I echo that, still downloading it though, the servers must be rather busy at the moment
[18:02] <yofel> use torrents, the main servers are totally overloaded today
[18:03] <bdmurray> additionally you might not want to choose to install 3rd party software
[18:03] <bil21al> yes torrent servers are quite faster.
[18:03] <SwitchDK> yofol: absolutely I agree, I guess it is an exciting "bad" thing the servers are overloaded. It means lots of interest
[18:04] <ikt> yofel: http://www.novarata.net/mootbot/ubuntu-au.log.20110208_0401.html <- search for "forum" should take you straight to the action
[18:04] <greg-g> bdmurray: are you referring to a specific issue with the 3rd party software comment?
[18:05] <bdmurray> greg-g: yes, archive.canonical.com is rather busy and install flash may not work
[18:06] <greg-g> ahhhhhh
[18:06] <greg-g> that installer option, gotcha
[18:07] <bil21al> bdmurray: you are the main person  here ,so congrats.and tomorrow i will give this new version to my cousins and relatives.oneiric rocks in pakistan also
[18:07] <hggdh> ikt: I see no reason why a forum would not work. But our base is IRC. I, for example, seldom go to the fora (no time)
[18:08] <yofel> ikt: well, I can agree that you'll see people on the forum that you won't see somewhere else. But IMO bugsquad members should learn to use IRC, as that's what we usually use
[18:08] <greg-g> I wonder if it might help the forum community when dealing with bugs (just thinking out loud here) because many times issues are discussed on a forum but there isn't always a bug reported/linked to.
[18:09] <greg-g> Have a place that is where people knowledgeable/want to help with bugs look might enable the forum to better react to bug reports happening on the forum
[18:09]  * greg-g shrugs
[18:09] <hggdh> greg-g: I think it would. This goes, partially, for the casual user -- good enought o use the forum, but daunted by LP
[18:09] <ikt> yeah exactly
[18:10] <yofel> you usually have some bug people in the +1 forum, but rarely somewhere else
[18:10] <greg-g> but, I'll be honest, I'll never read it :/
[18:10] <bdmurray> nor will I
[18:11] <yofel> +1
[18:11] <ikt> that's the problem :P
[18:11] <greg-g> yeah :/
[18:11] <ikt> but it doesn't need you guys to specifically read and take part in the forum
[18:11] <greg-g> my bug triage time is limited as it is
[18:11] <ikt> very similar to the hug a bug day
[18:12] <hggdh> no, it does not. But whoever is there responding for bugsquad/bugcontrol better know what they are talking about
[18:12] <greg-g> :)
[18:13] <hggdh> this is actually a discussion that has been going on and off for a while now -- LKP does not scale for the casual user
[18:13] <hggdh> so we need other venues
[18:13] <ikt> it's not about taking in bug requests and bugs on the forum
[18:14] <hggdh> dammit s/LKP/LP/
[18:14] <ikt> it's about communicating with people
[18:14] <ikt> anyways I gotta sleep, ttyl :)
[18:15] <hggdh> exactly. Communicating with people. And how, for example, does the fora scale for millions of users?
[18:15] <hggdh> (I know LP does not)
[18:17] <yofel> we have millions of users in the bugsquad? ^^
[18:17] <yofel> and no, please don't suggest aksubuntu for bugsquad communication...
[18:17] <yofel> *askubuntu
[18:18] <hggdh> no, we do not :-) But we have millions of users. Users have bugs/issues/problems/questions
[18:18] <hggdh> and, somehow, we should cater to them. I think ikt is absolutely right (if he meant this)
[18:22] <hggdh> er. Or she.
[19:06] <bdmurray> how can these launchpad users not put an irc nick on their launchpad page!
[19:09] <bdmurray> hrm
[19:35] <hjd> hi. Do we have a master bug for bug 873552 / bug 873420 already? (I suspect this might get a couple of duplicates)
[19:35] <ubot4> Launchpad bug 873552 in update-manager (Ubuntu) "check-new-release-gtk "remind me later" button not working (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/873552
[19:35] <ubot4> Launchpad bug 873420 in update-manager (Ubuntu) ""Remind me later" doesn't do anything (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/873420
[20:13] <hjd> I ended up marking one as a duplicate of the other, but I assume there will be more in the future ^
[20:57] <bil21al> bdmurray: r you a bot?
[20:59] <bdmurray> no but I have some
[21:00] <bil21al> hmmm gud you  work very fast so i asked.
[21:48] <kwisatzh4der4ch> Hi all. I was just wandering how ubuntu use Debian critical bugs report. Is there a chance that a debian packages with known critical bugs goes to an ubuntu releases with just a package rebuild ?
[21:56] <dtchen> kwisatzh4der4ch: currently, there is no formal process for reviewing http://bugs.debian.org/release-critical/ in Ubuntu. There is a 100% probability that RC bugs will ship in Ubuntu releases.
[21:57] <dtchen> kwisatzh4der4ch: for instance, I've spent the past several days triaging RC bugs in sid, and those bugs aren't closed in oneiric simply because the Ubuntu archive was in hard freeze.
[21:58] <dtchen> kwisatzh4der4ch: it would be great to have had them fixed before oneiric shipped, but as always, it's a matter of resources.
[21:58] <kwisatzh4der4ch> ok thanks. The positive aspect is that it will make more manpower on theses bugs, than if they stay only in Debian ;-).
[21:59] <dtchen> kwisatzh4der4ch: certainly there is strong encouragement to get such bugs fixed in sid then synced into the current Ubuntu development branch.
[22:00] <dtchen> (that's pretty much what I did this entire cycle)


[08:33] <flexiondotorg> Are Ubuntu Studio still planning to participate in 17.10 Beta 1?
[08:34] <flexiondotorg> No tests have been completed and the other flavours will all be marked ready in the next hour.
[10:22] <flexiondotorg> sakrecoer krytarik Are you guys going to complete any iso testing for Ubuntu Studio 17.10 beta 1?
[10:22] <flexiondotorg> The release is due today.
[13:19] <flexiondotorg> Anyone?
[15:09] <Rosco2> My email this morning did not make it to the list (from mobile phone with wrong From address for the list)
[15:10] <Rosco2> But we are testing Artful Beta 1 right now
[15:10] <Rosco2> They want to release in one hour
[15:10] <Rosco2> But if you want to test the ISO - please go ahead and let us know how you get on.
[15:25] <Rosco2> Sorry :-(