[00:01] <Diddleha> Cosmic Coala... everything is AllRight but .VOBS. Tell me how i can enjoy my evening if you please ?
[00:01] <MsMaco> Diddleha: this still isnt a support channel...
[00:02] <Diddleha> Ive coded way many more lines then you ever have. Infest me not ;)
[00:03] <wgrant> Still not a support channel.
[00:03] <Diddleha> Ms: You have something twitchingly wrong about you ?
[00:04] <Diddleha> wgrant, Sorry... we make this work
[00:04] <lifeless> #ubuntu for support
[00:04] <wgrant> Diddleha: Be nice, thankyou.
[00:04] <Diddleha> Accepted
[00:04] <Diddleha> .
[00:04] <MsMaco> did you just read Ms as multiple sclerosis?
[00:04] <Diddleha> wgrant: I suggest AbbA ?
[00:05] <wgrant> Diddleha: Pardon?
[00:05] <Diddleha> MsMaco: You arent even close
[00:05] <sistpoty> Diddleha: please, that's all not helpful
[00:08] <Diddleha> I like to donate billions each year from your tax paying dollars ;)
[00:08] <sistpoty> !ops
[00:08] <sistpoty> enough of that, Diddleha
[00:09] <Diddleha> sistpoty: Some appear not as they seem to be. Request acknowledged.
[00:11] <Turl> hello, anyone who knows how to read bootcharts?
[00:21] <Diddleha> sistpoty: I cannot work for you given the tools you give me. If this didnt sadden me i dont know what would. Pardon me if i need to takedown some evils. My quest has just begun to make codings and coders the main men and wimen of the irken worlds. We are sorry for the takedowns so far, we loved them.
[00:21] <Diddleha> sistpoty: Its how it always was.
[00:26] <Diddleha> ryu2 <- begone
[00:27] <ryu2> ähm?
[00:27] <Diddleha> Ähem
[00:27] <Diddleha> ryu2: You can stay for a while
[00:27] <Diddleha> :)
[00:28] <bazhang> Diddleha, please desist
[00:28] <ryu> it may be the time, but i cannot follow you
[00:29] <Diddleha> Bballhang seems frisky tonight :)
[00:30] <Diddleha> Cosmic Coala has issues, please save the Coalas
[00:30] <niko> Diddleha: please can you keep this channel friendly ?
[00:30] <Diddleha> niko: keep it GNU/Linux friewndly
[00:31] <Diddleha> niko: keep it GNU/Linux friendly.
[00:31] <nalioth> hi niko
[00:31] <geofft> !ops
[00:31] <nalioth> geofft: hi
[00:31] <niko> hi
[00:31] <nalioth> why all the excitement?
[00:31] <niko> Diddleha: what's wrong please ?
[00:32] <Diddleha> you seem to be angry at something you know little about, such as GNU/Linux and or BSD ?
[00:32] <Diddleha> nalioth: *Yawn* as usual
[00:32] <nalioth> geofft: why are you calling the ops?
[00:32] <niko> not really, but can you read the topic Diddleha ?
[00:33] <geofft> see sistpoty's summon earlier, and logs
[00:33] <Diddleha> niko: Are you saying im blind but all ive done for the past 10 years is code for OSS ?
[00:33] <nalioth> geofft: :(  i just got here  :(
[00:33] <Diddleha> niko: Are you my grandma or something ?
[00:34] <Diddleha> :)
[00:34] <nalioth> Diddleha: are you trolling?
[00:34] <joaopinto> just ignore him until a op joins, he is just trolling, don't feed him
[00:34] <nalioth> joaopinto: i am an op
[00:34] <niko> Diddleha: please, follow channel topic or /part from here
[00:34] <joaopinto> oh, so what are you waitinf for :P ?
[00:34] <lifeless> nalioth: hi, Diddleha is being disruptive, and we're failing at communicating this to them
[00:35] <nalioth> Diddleha: is this true?
[00:35] <lifeless> nalioth: I can paste you a recent log if that would help, from before you joined
[00:35] <Diddleha> nalioth: Well, if you wanted to boot non-microsoft coders... i guess they can win this one ?
[00:36] <nalioth> lifeless: irclogs has it  :)
[00:38] <Diddleha> For 25 years you have not yet learned. Im looking forward to coding for you for the next 55 years
[00:38] <Diddleha> :)
[00:38] <Diddleha> Some of you seem weird though :)
[00:39] <MsMaco> O_o
[00:39]  * nalioth prefers "eccentric"  :P
[00:39] <sistpoty> thanks again, nalioth... and sorry again for feeding the trolll in teh first place
[00:41] <nalioth> sistpoty: they can sneak up on ya  :)
[00:41] <sistpoty> heh
[01:51] <damo22> i just created a working kernel module patch to support a new high end sound card... how do i package it into an ubuntu kernel module?
[01:52] <damo22> eg, i dont want to have to tell people to recompile an entire kernel just to use my module, i would like them to be able to compile it using module-assistant
[01:55] <Turl> damo22: they can just reinstall alsa-driver
[04:19] <emgent> ccheney: ping :)
[04:19] <emgent> i prefer talk here, do not like facebook simil messaging
[04:33] <ccheney> emgent: ah ok :)
[04:34] <ccheney> http://www.openofficemouse.com/ <- thinks usability people would die after seeing this
[04:35] <emgent> ;)
[04:35] <emgent> big lol
[04:36] <emgent> ccheney: how goes?
[04:37] <ccheney> pretty good, getting ready for my trip, printing out everything i need :)
[04:38] <lifeless> ccheney: a spoof :)
[04:38] <emgent> heheh nice ;)
[04:38] <ccheney> lifeless: uh i'm pretty sure its real, there is a talk about it at OOoCon
[04:38] <ccheney> lifeless: it should be a spoof
[04:39] <lifeless> ccheney: the links at the bottom go nowhere
[04:39] <emgent> ccheney: i suggest to you to prepare your body to dring a really nice wine ;)
[04:39] <lifeless> ccheney: except one to 'intellivision lives'
[04:39] <ccheney> lifeless: ah, heh :)
[04:39] <ccheney> emgent: ok
[04:49] <emgent> ah ccheney, i do not know if you know, but seems that Microsoft people come to ODF Plug Fest
[07:16] <wolfe> thank you all who contributed :) Just upgraded, spectacular. First thing I tried was plugging up a monitor on my intel based gfx card on my notebook, worked without restarting the X server.
[08:43] <dupondje> hmz, can't even bugreport anymore on lauchpad
[08:43] <dupondje> timeout ...
[08:44] <dupondje> https://bugs.launchpad.net/ubuntu/+source/firefox-3.5/+bug/466228
[08:45] <dupondje> asac: you might want to check it
[08:45] <dupondje> already added the fix ;)
[11:10] <mdz> dtchen, I've sent some email regarding the kernel version issue, which according to maco seems to be fixed by running update-grub
[11:11] <mdz> dtchen, regarding verbose logging for PA, we could set up an interactive apport hook which would restart pulseaudio with debugging enabled, prompt the user to reproduce their bug, then put everything back and attach the logs
[12:32] <caio> i'm having some troubles with karmic upgrade
[12:33] <caio> http://img405.imageshack.us/img405/1355/karmicgnomepanel.png
[12:34] <caio> can't understand this "line" over the panel, and it appears on login screen too..
[12:34] <caio> and this network icon is so ugly, lol
[12:35] <caio> most ugly think that I ever see
[12:35] <caio> and programs "closes unexpected" every time
[13:05] <asac> dupondje: please subscribe jdstrand to that bug
[13:53] <Shockrates> hello developers. sagemath 4.2 is available in the site, and we still have 3.1 in our repos.
[13:53] <Shockrates> do something.....
[13:55] <joaopinto> Shockrates, the best place to talk about universe repos packages is #ubuntu-motu :)
[13:55] <Shockrates> but you are the maintainers
[13:55] <Shockrates> so this is the best place
[14:16] <cjwatson> Shockrates: #ubuntu-motu maintains packages in universe
[14:16] <Shockrates> ok
[14:17] <Shockrates> fedora is way ahead of us
[14:18] <cjwatson> actually, in general it's best to simply file a bug
[14:18] <cjwatson> IRC is very dependent on somebody who's interested happening to be online at the right time
[14:18] <cjwatson> and indeed there is bug 369089
[14:25] <ebroder> Any ubuntu-installer experts around? I'm trying to do an unattended install of Hardy, but with no bootloader. grub-installer/skip works, but even if I set lilo-installer/skip, it still tries to install LILO
[14:27] <ebroder> I tried comparing the lilo-installer and grub-installer source, but I can't figure out where the skip options are supposed to trigger in the first place
[14:31] <cjwatson> ebroder: that feature wasn't in hardy
[14:31] <cjwatson> it was added in intrepid
[14:31] <ebroder> cjwatson: Huh - really? It's in the Hardy docs
[14:32] <cjwatson> yes, but the code was broken
[14:32] <cjwatson> lilo-installer (1.27) unstable; urgency=low
[14:32] <cjwatson>   * Fix check for lilo-installer/skip. Closes: #471130.
[14:32] <ebroder> Damn
[14:33] <ebroder> Is it worth even trying to put an SRU together, or would people be too sketched out by it?
[14:33] <cjwatson> I'd be OK with that
[14:33] <ebroder> Ok, I'll see what I can come up with
[14:34] <cjwatson> you can work around it though
[14:35] <cjwatson> d-i preseed/early_command string echo "sed -i '1a. /usr/share/debconf/confmodule' /var/lib/dpkg/info/lilo-installer.isinstallable" >> /var/lib/dpkg/info/download-installer.postinst
[14:35] <cjwatson> ... I think
[14:36] <ebroder> Haha, ok. I'll play around with that
[14:36] <cjwatson> the fix is revision 373.1.491 in lp:~ubuntu-core-dev/lilo-installer/ubuntu
[14:37] <sebner> dtchen: ok, I newly installed karmic and have no sound (jaunty yes) anything I can do?
[14:39] <SingAlong> is there anyway to disable notifications or atleast change its settings?
[14:50] <dupondje> asac: done
[14:50] <dupondje> :)
[15:02] <caio> can anyone help? http://img405.imageshack.us/img405/1355/karmicgnomepanel.png
[15:36] <dtchen> mdz: what does "put everything back" mean? Are you proposing restarting PA?
[15:37] <dtchen> sebner: err, I don't understand. Do you mean that you dist-upgraded from 9.04?
[15:39] <sebner> dtchen: no, new install but I found the "workaround" in your blog. killall slmodemd
[15:39] <dtchen> sebner: well, you could also use module-detect instead of module-udev-detect
[15:40] <sebner> dtchen: how where?
[15:40] <dtchen> also covered in the blog post
[15:40] <dtchen> i.e., edit ~/.pulse/default.pa or /etc/pulse/default.pa
[15:41] <sebner> dtchen: well, documented to edit the files but not what ^^
[15:41] <dtchen> sebner: sorry, but is "use module-detect instead of module-udev-detect" unclear? The file has a pretty distinct section for it.
[15:41] <sebner> dtchen: just comment out the 3 lines of *udev?
[15:42] <dtchen> sebner: sure, including the appropriate conditional
[15:42] <dtchen> sebner: it's also possible to avoid editing /etc/pulse/default.pa and use pacmd/pactl
[15:42] <sebner> dtchen: wondering about the .else since it didn't work evidently ^^
[15:43] <mdz> dtchen, yes, restarting PA
[15:43] <mdz> dtchen, is there a reason why that might not be a good idea?
[15:43] <sebner> dtchen: btw, it shows me -30dB
[15:44] <dtchen> mdz: I presume we'd tell the user that everything connected to PA will die?
[15:45] <dtchen> sebner: you could also do something at runtime like (hacky): pactl unload-module $(pactl list|grep -B1 'Name: module-udev-detect'|head -1|awk -F# '{print $2}') && pactl load-module module-detect
[15:45] <mdz> dtchen, yes, this would be an apport-driven debugging session
[15:46] <sebner> dtchen: nah, I'll stick with edited pulse conf then ^^
[15:46] <mdz> (I'm assuming it's not possible to adjust the logging level at runtime; if it is, we don't need to restart)
[15:46] <dtchen> mdz: not that I've seen
[15:47] <dtchen> also, I should push my one-liner against lp:~ubuntu-core-dev/ubuntu/karmic/apport/ubuntu/
[15:47] <dtchen> +    report['AlsaVersion'] = command_output(['cat','/proc/asound/version'])
[15:48] <dtchen> e.g., this is necessary to direct people to install linux-backports-modules-alsa-karmic-generic
[15:49] <dtchen> mdz: WRT JackSense, I don't know if the best place is via an apport hook -- maybe checkbox instead?
[15:49] <sebner> dtchen: anyways, thanks for your help! :)
[15:51] <dtchen> sebner: np
[15:52] <dtchen> sebner: be aware that using module-detect will lose hot(un)plugging of audio devices
[15:52] <sebner> dtchen: grrr. define "audio devices" I'm just using a laptop
[15:53] <dtchen> sebner: well, anything capable of audio playback or capture, e.g., usb headset, webcam, etc.
[15:53] <sebner> grml
[15:53] <dtchen> i.e., if you use module-detect, plugging in (or removing) a usb headset won't register automatically
[15:53] <sebner> dtchen: wondering about jaunty where everything worked
[15:54] <dtchen> sebner: welcome to the world of upgrades involving udev changes, linux changes, and pulseaudio changes
[15:54] <sebner> dtchen: heh, I suppose the motto is : "With lucid it'll get better" ?
[15:54] <dtchen> it's pretty simple though -- just unload and reload module-detect to pick it up
[15:55] <dtchen> heh, yeah, "better with lucid"
[15:57] <sebner> ^^
[17:08] <dtchen> hmm
[17:09] <dtchen> it appears that some users are choosing to keep an existing grub conffile when prompted during upgrade
[17:10] <dtchen> e.g., https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/465937/comments/3
[17:11] <amgarchIn9> hi, is there a way to get a better diagnostic of system freezes? How do you usually trace bugs in the kernel?
[17:14] <MsMaco> dtchen: i dont remember being asked that when i upgraded ada...
[17:15] <dtchen> I haven't ever been prompted either
[17:15] <dtchen> anyhow, trying to reproduce in vbox
[17:22] <tormod> amgarchIn9, see https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies (maybe also https://wiki.ubuntu.com/DebuggingKernelOops)
[18:03] <Gizmo_the_Great> \join #ubuntu-devel
[18:04] <Gizmo_the_Great> oops :-)
[18:04] <hyperair>  / not \
[18:04] <hyperair> and you're already in to begin with..
[18:05] <Gizmo_the_Great> Hi. Doing some work using the memory analysis tool 'pcat' (part of The Coroners Toolkit). Using following syntax to analyse memory of the process : pcat 1234 | strings | less (where 1234 is the process ID of ecryptfs-kthrea). But it seems to prevent it. Am I doing something wrong, or is this part of eCryptFS, for security reasons?
[18:06] <Gizmo_the_Great> I am asking at #ecryptsfs too, but that only has a few members
[18:11] <geofft> Did you say kthread?
[18:11] <geofft> I would be highly surprised if pcat works on kthreads. kthreads live entirely in kernelspace and IIRC have no userspace mm structure at all
[18:14] <Gizmo_the_Great> geofft: It returns : "pcat: ptrace PTRACE_ATTACH : Operation not permitted". IS that a permissions thing, or due to the fact that it's empty (as you say) do you think?
[18:15] <Gizmo_the_Great> Also, what is a userspace mm structure (forgive me, relatively new to this area)
[18:16] <geofft> oh, you're ptracing it. Yeah, that won't work either
[18:16] <geofft> For normal processes, the kernel keeps track of a bunch of information userspace needs, including what memory userspace has mapped
[18:17] <geofft> For kernel threads, because they only have kernel memory, the structure to track userspace memory doesn't exist
[18:17] <geofft> Also, ptrace works for the most part by tracking system calls. Since kernel threads never work in userspace, system calls don't exist for them
[18:18] <Gizmo_the_Great> geofft: I have just read this : http://www.linfo.org/kernel_space.html and that all makes sense now, along with your explanation. Many thanks
[18:18] <geofft> Basically all the usual things you can do to processes other than look at them in ps don't apply to kernel threads.
[18:18] <geofft> Sure, np
[18:18] <geofft> Ah, yes, the definition of kernelspace is useful :)
[18:19] <Gizmo_the_Great> So are we saying, basically, that because ecryptfs is part of the Linux Kernel, it is effectively inaccessible by the normal user?
[18:21] <jdong> not by the normal user (well for non-root users that's pretty true too), but not by the tools you are using which are designed primarily for userspace processes
[18:25] <Gizmo_the_Great> can I was what ptrace is? If you were writing a paper, and you started with "The Pcat program uses ptrace which is a...."
[18:25] <Gizmo_the_Great> ?
[18:26] <jdong> more or less a process debugger/manipulator/inspecter.
[18:26] <geofft> interface for one process to inspect (and modify) other processes
[18:27] <geofft> Hm, between those two answers I think we paraphrased the first paragraph of the manpage :)
[18:27] <jdong> lol indeed
[18:34] <Gizmo_the_Great> many thanks gents
[18:36] <jdong> no probs. Happy exploring :)
[18:53] <Gizmo_the_Great> how can you capture ram on Linux using dd? dd if=/dev/mem of=test results in only a 1Mb file?
[18:53] <Gizmo_the_Great> guess I am capturing the wrong thing?
[18:58] <geofft> I kind of doubt that will work... (also, last time I checked, either mem or kmem was broken. dunno if that's been fixed or WONTFIXed)
[18:58] <geofft> are you familiar with the distinction between physical and virtual memory?
[18:59] <geofft> and how different processes can see different views of memory?
[19:00] <Gizmo_the_Great> geofft: not massively, no. I am using virtual machines (VMWare) to conduct my tests, so I could examine the vmem file of a puased virtual machine. But I was hoping to do it 'neat' on a Linux machine.
[19:07] <geofft> mmm. I'm trying to find a good reference but I'm having trouble finding one that's concise
[19:07] <geofft> I guess for /dev/mem it doesn't much apply...
[19:36] <dtchen> pitti: / mdz: sorry about the spurious merge proposal. Apparently the wrong radio button was selected. :(
[20:37] <sebner> dtchen: the problem I'm seeing now that the gnome-volume-applet disappered, terminal says: ** (gnome-volume-control-applet:2511): WARNING **: Connection failed, reconnecting...
[20:43] <sebner> dtchen: also suffering from bug #301755
[21:06] <mdke> cjwatson: I'm building the installation-guide for help.u.c from lp:~ubuntu-core-dev/installation-guide/ubuntu but it seems to be for jaunty? am i getting it from the wrong place/
[21:21] <dupondje> jdstrand: you checked the bug ? ;à
[22:10] <sebner> dtchen: uhh. fixed the issue. completly removed the software modem stuff (Never used it anyways)
[22:32] <hyperair> dtchen: there?
[22:32] <hyperair> dtchen: is headphone jack detection in between suspend/resume supposed to work?
[22:32] <hyperair> i.e. stick in the headphones so speakers get muted, suspend, unplug headphones, and resume like that (speakers end up staying muted)
[22:37] <kklimonda> what is the most probable cause of user running 2.6.28 kernel on 9.10 after upgrade?
[22:38] <dupondje> how you mean ?
[22:39] <kklimonda> dupondje, well, they are still running 9.04 kernel on 9.10 system (2.6.28 instead of 2.6.31)
[22:39] <dupondje> all packages upgraded ?
[22:42] <kklimonda> dupondje, they say that it's upgraded system - I assume that they are
[22:42] <dupondje> dpkg --list |grep linux-image ?
[22:42] <kklimonda> dupondje, I'm just trying to find out :)
[22:54] <kklimonda> dupondje, he has .31 installed but his menu.lst only have .28 listed..
[22:54] <dupondje> update-grub
[22:54] <dupondje> :)
[22:54] <kklimonda> grub.conf is empty.. don't know if it's right after upgrade from 9.04
[22:55] <dupondje> grub.conf ?!
[22:55] <kklimonda> .cfg
[22:56] <dupondje> grub2 or grub1 using ?
[22:56] <kklimonda> dupondje, I guess he's using grub1 - wasn't it supposed to stay after upgrade?
[22:57] <dupondje> yea prolly
[22:57] <dupondje> but then why is there grub.cfg :)
[22:57] <dupondje> dpkg --list |grep grub
[23:18] <JanC> kklimonda: it's a well-known bug by now, but AFAIK it's not known yet what causes it  ;)
[23:19] <JanC> kklimonda: at least some of them had grub2 installed before upgrade
[23:20] <dupondje> well known bug ?
[23:20] <JanC> as in: a lot of people reported it  ツ
[23:20] <ion> tsu?
[23:21] <JanC> dupondje: it breaks audio & other things because of udev changes & such, so peopel report bugs agains audio...
[23:22] <JanC> ion: sorry for the Katakana "smiley" abuse  ;-)
[23:22] <dupondje> some people :)
[23:22] <dupondje> btw, you know how to debug nautilus ?
[23:23] <dupondje> trying to debug SynCE gvfs plugin :P
[23:26] <cjwatson> mdke: *blush* I never did get round to updating it non-trivially this cycle
[23:26] <cjwatson> wow, that was kind of crap of me
[23:33] <eboyjr> I made a patch (kinda) for appearance-effects.c in gnome-control-center: http://pastie.org/678374
[23:33] <eboyjr> A simple change for a simple settings manager
[23:36] <eboyjr> I haven't tested it since I am not familiar enough with Debian's system (how to compile it and run it)
[23:37] <JanC> there is some explanation on the wiki about how to do that
[23:38] <eboyjr> JanC: Okay /PackagingGuide/PatchSystems looks good


[10:53] <leon_pegg> Good morning all, I would like to apply a patch to the kernel package and would like some guidance could someone please advise.
[10:55] <leon_pegg> to provide a bit more information I am looking to patch the kernel with grsecurity
[10:56] <apw> ok, ask ay specific questions you have and we'll try and answer
[10:56] <apw> *any
[10:57] <leon_pegg> How do i apply a patch to the kernel source package
[10:58] <apw> leon_pegg, to be honest if applying a patch is a new thing you are going to find applying a monster like grsecurity a huge effort
[10:59] <apw> leon_pegg, but ... i would start by checking out our git repository for the release to which you intend to apply it
[11:00] <leon_pegg> apw: I have applied patches to raw source before but never to packages, and have built custom kernels before just not applied patches to deb packages
[11:00] <leon_pegg> apw: whats the git repo address?
[11:01] <apw> leon_pegg, was struggling to find it in our wiki *sigh* ... https://wiki.ubuntu.com/Kernel/SourceCode see the git bit there
[11:01] <apw> leon_pegg, i would then apply the patch in git and build the source package from that
[11:01] <leon_pegg> apw: thanks
[11:02] <leon_pegg> apw: fingers crossed it all goes well :D
[11:04] <apw> leon_pegg, also, didn't grseurity stop producing patches in public anyhow ?
[11:05] <leon_pegg> apw: they still provide the testing patches to keep supporting arch-hardened
[11:06] <apw> leon_pegg, against what kernel versions though
[11:07] <leon_pegg> apw: kernel versions 3.1-4.3.4
[11:13] <apw> so you might have some luck on 4.2 in wily then, but xenial is too new
[11:19] <leon_pegg> apw: using wily on the desktops in the office so we should be good, we are still is discussions about applying grsec on the servers
[11:19] <apw> leon_pegg, that is a big committment for sure, as you'll need to keep up to date with security release cadance
[11:24] <leon_pegg> apw: exactly it is a huge commitment, and keeping up with security updates adds additional work. the plan at the moment it to trial on some of the desktops and progress from there after
[13:27] <MaikZ> Hi, is there an escalation procedure we could follow to get some more attention on https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1398465 ?
[13:27] <MaikZ> Oops wrong bug sorry
[13:28] <MaikZ> Well actually same bug, but https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1505948 is the version we reported :-)
[13:28] <MaikZ> There is an out of bounds write somewhere in fuse_direct_io on 4.1 and higher that can panic the kernel (and reliably does, on our virtualization hosts)
[13:29] <MaikZ> We're working around it by staying on 3.19, but that is coming uncomfortably close to being out of support we think
[13:29] <apw> MaikZ, that doesn't look like a memory allocation failure, more like a memory arena corruption, a double free or something
[13:29] <MaikZ> apw: Yes
[13:29] <MaikZ> We booted a test machine with slub_debug
[13:29] <MaikZ> And it confirms that something in fuse_direct_io wrote zero bytes into the "poison" areas
[13:30] <MaikZ> Without slub_debug, that makes the kernel panic on some future allocation or deallocation.
[13:30] <apw> is that info in the bug (save me reading it)
[13:31] <apw> MaikZ, also are you able to test the 4.4 kernel in xenial-proposed easily for this ?
[13:31] <MaikZ> If there's a .deb that installs on trusty, we should be able to do that fairly quickly yes
[13:32] <MaikZ> Not yet, our storage vendor was supposed to add it but apparently didn't. I'll attach it.
[13:32] <apw> MaikZ, well in principle those are nistallable there with lick
[13:32] <apw> luck
[13:33] <apw> MaikZ, and this won't affect "regular" consumers of ubuntu i assume, as you need to use fuse 3.0 to get async io right ?
[13:35] <MaikZ> Not sure about the FUSE versioning, but I can confirm that the specific FUSE file system we use ships with its own, very recent libfuse.
[13:35] <apw> and presumably you do not see this without
[13:36] <MaikZ> We have been able to reproduce the kernel crash using ntfs-3g because fuse-devel was unhappy about a closed-source userspace part
[13:36] <MaikZ> But that was also a fresh build
[13:44] <MaikZ> So for testing 4.4, we could try grabbing .debs from this build: https://launchpad.net/ubuntu/+source/linux/4.4.0-1.15/+build/8880824
[13:44] <MaikZ> And they should sort of work on trusty because kernel packaging hasn't fundamentally changed?
[13:47] <apw> MaikZ, that would be my expectation, do get -extra if you need it
[13:59] <MaikZ> Okay, one machine cleared of production workloads and 4.4 installed, let's see what happens.
[13:59] <apw> MaikZ, i think it will break just the same, but that a good data point, i have found a suspicious  looking async path
[14:01] <Madkiss> g'day
[14:07] <apw> Madkiss, ?
[14:09] <Madkiss> apw: MaikZ told me there's an interesting conversation going on here about a bug we reported several months ago, so I just thought i'd join and read :)
[14:10] <apw> MaikZ, assuming that machine also goes pop, i might have a guess as to the cuase of this, if so then i might have a test kernel to try (soon)
[14:11] <apw> MaikZ, if so, 1) would you be able to test it, and 2) i would need to confirm its not leaking instead of blowing up, so it'd need some monitoring
[14:12] <MaikZ> We can install a custom build. What monitoring do you have in mind?
[14:12] <MaikZ> There is sadly no metrics collection in that cluster.
[14:12] <MaikZ> So I can't draw you pretty memory usage graphs.
[14:18] <apw> MaikZ, well if it is the right fix then the machine will not blow up and things will be fine, if it is not then the machine may work fine and leak 96 byte memory blocks for every async IO and lose memeory over time
[14:18] <apw> MaikZ, so I guess I am syaing we need to monitor the slabs are not growing out of control in this case
[14:19] <apw> MaikZ, if your screenshot is accurate then like:  while :; do grep kmalloc-96 /proc/slabinfo; sleep 5; done
[14:20] <apw> would be something to watch is similar to other machines
[14:21] <apw> MaikZ, i assume if i am wrong then it will literally lose an entry for every single IO, so it should be obvious and spectacular
[14:21] <MaikZ> Spectacular failure is our core business!
[14:33] <MaikZ> I'm so far failing to reproduce the previous issue (slub_debug is silent, also no panic), but instead I/O has totally frozen on the test VM.
[14:33] <MaikZ> With the 4.4 kernel.
[14:34] <MaikZ> Or looks like it...some ops are getting through according to storage metrics.
[14:42] <gQuigs> any thoughts on disabling mtrr for xenial?   https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1163587
[15:33] <apw> MaikZ, ok, after some further reading it doesn't look like that suspicious thing is suspicious
[15:56] <MaikZ> I will let the 4.4 tests run overnight, the kernel might panic after a couple of hours. It usually happens within minutes but not always.
[16:02] <apw> MaikZ, sounds good thanks
[16:02] <apw> MaikZ, put any result info in the bug and let us know too here
[16:04] <MaikZ> Sure.


[10:56] <sami> hihaho
[10:57] <Fatal_Sushi> sami: hi and welcome. If you have a Lubuntu support question just ask and wait for someone to respond. Casual chit chat is in #lubuntu-offtopic
[11:03] <sami> nope i dont
[11:04] <sami> i have linux mint cinnamon 20.2
[11:04] <sami> i installed quassel on it
[11:04] <sami> am i only talking with you!?
[11:05] <Fatal_Sushi> if you use Linux Mint you're in the wrong network and channel
[11:06] <Fatal_Sushi> thought so....
[14:10] <gustavoalecrim> hi... anybody speeak portuguese?
[14:11] <Fatal_Sushi> nope, not me
[14:12] <Fatal_Sushi> If you have a Lubuntu support question just ask and wait for someone to respond. Casual chit chat is in #lubuntu-offtopic
[14:12] <oerheks> !pt
[14:15] <gustavoalecrim> ok thanks!
[15:56] <profetik777_> so i installed openconnect and network-manager-openconnect
[15:56] <profetik777_> but don't really see the same prompt i usually get to configure my settings
[15:57] <profetik777_> as i do in this video https://www.youtube.com/watch?v=6igRW2cfF-8&t=140s
[15:57] <profetik777_> or in gnome
[15:57] <profetik777_> i just need a gateway input and a password, and second password input for the 2fa
[15:58] <Fatal_Sushi> -_-
[16:04] <profetik777_> i was able to see open connect to choose from in adding vpns which is a good start
 Had to add network-manager-openconnect-plugin
 And install that too for it to give me input fields
 Buuut window was too long , so couldn't confirm my settings lol so gotta write up a bug report
 I had a small 11 inch yoga flip
 @profetik777 you always talk to yourself here and on IRC?
 Well, i can't give him too much advice on the VPN stuff, they all operate very differently. I do know nm-tray has some terrible support for it. We filed this upstream bug 2 years ago https://github.com/palinek/nm-tray/issues/44
[16:57] <oerheks> weird, the credentials are stored in your setup
 I entered it before the video but couldn't save since the size of the window was too long. The confirmation button to save and close was below my bottom panel and I couldn't decide to get it to fit. I probably could but external monitor and get it going or make the default font size super small and maybe that can help with the spacing where I can save it. But at least I know how to get to the settings I need
[17:03] <oerheks> Press Alt + F7 to move a window or Alt + F8 to resize.
 It physically can't shrink the contents.  It isn't about moving it technically bc it will run up against top end of display border.  But I can give it another go
[17:14] <oerheks> alt tab should work too
 F8 one did the trick thank you! (re @lubuntu_bot: (irc) <oerheks> Press Alt + F7 to move a window or Alt + F8 to resize.)
[22:15] <oerheks> have fun!
 The day LXQt DE switched to Wayland
 Will it then be using Waybox instead of Openbox?
[22:23] <oerheks> OpenLand
 How do I initialize VPN credential entry?
 https://matterbridge.lubuntu.me/70e3d2ed/file_3553.jpg
 I click that and I get this
 https://matterbridge.lubuntu.me/d44e81ae/file_3554.jpg
 {note I never signed in it}
 So I never lost the connect technically
 Never had it to begin w
 The window manager hasn't been decided yet for Lubuntu. LXQt is agnostic when it comes to the window manager. (re @Michaël: The day LXQt DE switched to Wayland
 Will it then be using Waybox instead of Openbox?)
 thank you
 I was curious (re @kc2bez: The window manager hasn't been decided yet for Lubuntu. LXQt is agnostic when it comes to the window manager.)
 right, that was basically what the upstream bug report I linked earlier was about. (re @profetik777: Never had it to begin w)
 Ah okay
 You might be able to use the right click menu and edit connection. I am not sure. (re @profetik777: Ah okay)
 Hi there, I have a question, just to learn. When you press Ctrl+Alt+Fx you are presented with a command line in another dimension. But you can still make actions on your previous world, like killing apps, etc. What is this kind of alternate session, or just non- graphical interphase and why there's a few and what is the intended use?
 This ask Ubuntu question might help answer that. https://askubuntu.com/questions/66195/what-is-a-tty-and-how-do-i-access-a-tty (re @Rodrigo: Hi there, I have a question, just to learn. When you press Ctrl+Alt+Fx you are presented with a command line in another dimension. But you can still make actions on your previous world, like killing apps, etc. What is this kind of alternate session, or just non- graphical interphase and why there's a fe
[23:23] <guiverc> @Rodrigo, Unix started as a multi-user OS; the plumbing is still there; with virtual terminals available via Ctrl+Alt+Fn.... Myself, I find it useful if the GUI is having issues (thrashing etc) to explore issues & resolve.. In this example (thrashing) the text terminal generally needs to be already logged in (ie. I have to predict issues for it to be really useful; but I again like it..
 Thanks, actually I also like it and have used in the same situations you mention. It saved me many times. I just wondered about it 😊 (re @lubuntu_bot: (irc) <guiverc> @Rodrigo, Unix started as a multi-user OS; the plumbing is still there; with virtual terminals available via Ctrl+Alt+Fn.... Myself, I find it useful if the GUI is having issues (thrashing etc) to explore issues & resolve.. In this example (thrashing) the text terminal gene


[03:13] -queuebot:#ubuntu-release- Unapproved: blueman (focal-proposed/universe) [2.1.2-1ubuntu0.2 => 2.1.2-1ubuntu0.3] (ubuntu-mate, ubuntukylin, ubuntustudio, xubuntu)
[04:43] -queuebot:#ubuntu-release- Unapproved: ruby-mysql2 (focal-proposed/universe) [0.5.2-1ubuntu3 => 0.5.2-1ubuntu<IP_ADDRESS>] (no packageset)
[05:24] -queuebot:#ubuntu-release- Unapproved: ruby-mysql2 (hirsute-proposed/universe) [0.5.2-1ubuntu3 => 0.5.2-1ubuntu<IP_ADDRESS>] (no packageset)
[06:01] -queuebot:#ubuntu-release- Unapproved: libvirt (focal-proposed/main) [6.0.0-0ubuntu8.13 => 6.0.0-0ubuntu8.14] (ubuntu-server, virt)
[06:07] <cpaelzer> RAOF: hiho, I read that you are on SRU rota today
[06:08] <cpaelzer> There is an regression-update case that people worked on the last few hours and that now is ready
[06:08] <cpaelzer> That is in bug 1943481
[06:08] <cpaelzer> the queuebot ping above is the related upload into focal-unapproved
[06:08] <RAOF> cpaelzer: Hey, lo! *Technically*, I observe North American Tuesday, but I'm happy to be pinged :)
[06:09] <cpaelzer> RAOF: since we do not want to loose too mcuh time on regression updates I wanted to ping if you could have a look
[06:09] <cpaelzer> Oh I thought you observe your tuesday and thought that is some kind of "after noon, but not too late to ping" - in any case thanks in advance for having a look
[06:10] <cpaelzer> and if you can't make it let me know so that I can ping others later today
[06:15] <RAOF> I'm always happy to receive pings in working hours. It's 16:15 here, so that's fine :)
[06:15] -queuebot:#ubuntu-release- Unapproved: accepted libvirt [source] (focal-proposed) [6.0.0-0ubuntu8.14]
[06:15] <RAOF> That seems perfectly sensible. Accepted.
[06:16] <cpaelzer> Thank you so much RAOF!
[08:21] -queuebot:#ubuntu-release- Unapproved: accepted grub2-unsigned [amd64] (impish-proposed) [2.04-1ubuntu47]
[08:23] -queuebot:#ubuntu-release- New source: xlnx-kria-firmware (impish-proposed/primary) [0.6]
[08:25] -queuebot:#ubuntu-release- New: rejected xlnx-kria-firmware [source] (impish-proposed) [0.5]
[08:27] -queuebot:#ubuntu-release- New source: xlnx-kria-firmware (impish-proposed/primary) [0.6]
[08:28] -queuebot:#ubuntu-release- New: rejected xlnx-kria-firmware [source] (impish-proposed) [0.6]
[08:28] -queuebot:#ubuntu-release- New: accepted xlnx-kria-firmware [source] (impish-proposed) [0.6]
[08:36] -queuebot:#ubuntu-release- New binary: xlnx-kria-firmware [arm64] (impish-proposed/universe) [0.6] (no packageset)
[08:45] -queuebot:#ubuntu-release- New: accepted xlnx-kria-firmware [arm64] (impish-proposed) [0.6]
[09:59] -queuebot:#ubuntu-release- New source: xlnx-kria-firmware (focal-proposed/primary) [0.6~20.04.1]
[10:08]  * enyc meows
[10:37] <paride> sil2100, hi! How will you handle the fact that 18.04.6 are only going to be released for a subset of the archs? Is it just a matter of not manually blessing the ppc/s390x .6 images as released?
[10:41] -queuebot:#ubuntu-release- Unapproved: xrt (focal-proposed/universe) [202<IP_ADDRESS>6-0ubuntu7~20.04 => 202<IP_ADDRESS>3-0ubuntu1~20.04] (no packageset)
[10:42] <guiverc> sil2100, when is 18.04.6 (likely?) to be released?   (I see the request for testing RC; wondering about ubuntu_news post..)
[10:45] <paride> guiverc, see https://lists.ubuntu.com/archives/ubuntu-devel/2021-September/041613.html
[10:46] <guiverc> yeah thanks, I have the quality one, but it was release date (or ETA) that interested me... if in UWN it won't publish till next Monday for example.. no point if already released...
[10:48] <paride> that's another email and it says: our estimated release date is this Thursday (16th of September)
[10:49] <guiverc> thanks, yep that's the date I was interested in.. (I missed the ETA email).. thank you paride
[10:50] <paride> yw!
[11:06] <sil2100> paride: hey! The publication scripts offer quite some freedom in which arches we want to publish, so we can do it only for a subset
[11:07] <sil2100> I'm still trying to reach Steve to see if he's okay with just releasing amd64 and arm64
[11:07] <sil2100> Anyway, looks like there might be a respin for the desktop images at least, because I think I found a bug related to ubuntu-drivers
[11:15] <ricotz> sil2100, hey, "expat" went through without issues
[11:38] <paride> sil2100, the old "MinimalVirtual" install now exceeds what we set to be the limit for Bionic (limit was: 2080MB, installed size is now: 2162MB)
[11:39] <paride> that's something we stopped checking when the d-i server images were phased out
[11:40] <paride> however for Focal the limit was 2360MB
[11:44] <paride> sil2100, this ~80MB difference looks physiological (general increase of package size over the years), but before bumping the test limit I'd like an ACK
[11:44] <paride> just in case we wanted that to be a harder limit for any reason
[11:59] <sil2100> ricotz: \o/
[12:00] <sil2100> paride: I think that's fine, we also saw a size increase for desktop but didn't see anything malicious with that
[12:00] <paride> sil2100, good! thanks
[12:00]  * paride goes to tweak the limits
[12:16] <paride> sil2100, we're all green in platform-qa \o/
[12:32] <sil2100> \o/
[13:42] <seb128> hum, is that an autopkgtest bug that the first try on https://autopkgtest.ubuntu.com/packages/a/autopilot-gtk/impish/amd64 which has triggers 'glib2.0/2.68.4-1build1 libffi/3.4.2-1ubuntu3' is blocking the new glib but not libffi?
[13:43] <seb128> https://autopkgtest.ubuntu.com/packages/d/dbus-python/impish/amd64
[13:43] <seb128> https://autopkgtest.ubuntu.com/packages/b/bolt/impish/amd64
[13:44] <seb128> checking those it seems more likely than libffi is creating the regressions than glib
[13:44] <seb128> yet the update_excuse for libffi flags none of those, which means it could probably migrate despite the issues?
[13:45] <seb128> @juliank, ^
[13:51] <juliank> seb128: that vrsion of libffi is no longer in proposed
[13:51] <juliank> seb128: presumably libffi is not a trigger for those packages
[13:52] <juliank> seb128: but the new python3.9 needs new libffi to migrate, so it becomes added to set of triggers
[13:52] <seb128> juliank, I guess that's because it's through a transient package?
[13:53] <seb128> juliank, would doing a manual trigger get those failures added to the libffi section?
[13:53] <juliank> seb128: I don't know
[13:53] <juliank> seb128: try it out with -1ubuntu4 and see?
[13:53] <seb128> juliank, k, trying, thanks
[14:11] <sil2100> grrrr git clone of ubiquity taking ages
[14:11] <seb128> someone mentioned slowness issues on ~Launchpad
[14:12] <seb128> juliank, do you know how we get libffi updates to trigger tests, for example gjs? (without adding a depends manually that would encode a soname)
[14:25] <juliank> seb128: with a depends
[14:26] <seb128> juliank, depends on what? we don't want to hardcode the soname there...
[14:26] <juliank> seb128: just test depend on libffi-dev?
[14:26] <seb128> I guess that would work despite being a bit hackish?
[14:27] <juliank> that's the way it goes :D
[14:27] <seb128> alright, thanks for the advice ;-)
[14:39] <bdmurray> sil2100: I wrote some code to look at the sizes of the packages in the manifest files and I didn't see anything overly large in them.
[14:39] <sil2100> bdmurray: hey! I fixed one critical issue in ubiquity for 18.04.6 - https://git.launchpad.net/ubiquity/commit/?id=28779054c060dea4fe2376b8e7275a634fbfa949
[14:39] <sil2100> bdmurray: I'm filling in a bug with another critical issue, but for that one maybe I'll poke around for help
[14:40] <ginggs> seb128: juliank: there's a better way: 'Restrictions: hint-testsuite-triggers' https://salsa.debian.org/apparmor-team/apparmor/-/blob/debian/master/debian/tests/control#L9
[14:40] <bdmurray> sil2100: nice
[14:41] <juliank> ginggs: nice
[14:42] <sil2100> bdmurray: I'll report it but first I need to check if it's a new bug or an old one
[14:45] <seb128> ginggs, thanks, it seems a bit more complicated than adding a depends but I guess it has the advantage of not imposing extra unneeded depends to the tests and making it clearer why they are listed
[14:45] <ginggs> seb128: also adding an extra depends might hide a missing depends
[14:45] <seb128> right
[15:36] <cpaelzer> are there shorter aging periods for regression updates like https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1943481
[15:36] <cpaelzer> or would that be like removing the current -updates restoring the former, and then once aged enough push the new one?
[15:44] <bdmurray> cpaelzer: in the event that an update is fixing a regression there can be shorter aging periods
[15:58] <bdmurray> cpaelzer: has there been any additional testing besides the test case in that bug?
[16:06] <sil2100> eh, so many issues
[16:11] <vorlon> ?
[16:11] <sil2100> bdmurray, vorlon: hey, do you guys remember if in bionic it was possible to install nvidia drivers without network enabled? Asking since right now (after my fixes) this fails as there is no nvidia drivers on the cd pool (and cannot be fetched)
[16:11] <sil2100> I tried looking at the .list for 18.04.5 and didn't see nvidia drivers there either
[16:12] <vorlon> I believe that was something that was addressed in focal
[16:12] <bdmurray> I don't think it was possible and something we fixed in Eoan
[16:12] <bdmurray> The last time we were in London
[16:12] <vorlon> hence all the late-in-release bugs in focal around making sure we always install matching nvidia drivers and kernel
[16:12] <vorlon> ok, eoan then :)
[16:12] <sil2100> Ok, phew, then not a regression!
[16:13] <sil2100> I got confused since the damn isotracker test-case mentions to use offline mode for this test, but we possibly modified the test case for future releases and it just stayed this way
[16:13] <vorlon> right, because we were never going to release bionic again so we didn't care ;p
[16:14] <sil2100> ;)
[16:14] <sil2100> Ok, so the only real blocker (or at least worth investigation) IMO is this:
[16:14] <sil2100> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1943614
[16:15] <sil2100> I'll update the tracking document
[16:15] <sil2100> This I confirmed does seem to be a regression, as it seemed to work for .5, but I only briefly looked at it
[16:15] <vorlon> výborně
[16:15] <sil2100> It's not very important, but then again people from Poland installing drivers will just fail and have to do it on their own ;)
[16:16] <sil2100> And I assume more languages like these are affected
[16:16] <sil2100> Only similar bug in the past I saw was LP: #1797579, but that one is a bit different
[16:17] <sil2100> Since there's no removals from what I see
[16:20] <vorlon> do you have a minimum reproducer from the commandline for the ubuntu-drivers crash?
[16:20] <vorlon> 'ubuntu-drivers autoinstall' here in a bionic chroot just spits out 'No drivers found for installation'
[16:20] <vorlon> maybe I need to enable restricted
[16:21] <bdmurray> I thought Martin Pitt had a way of faking hardware that requires restricted
[16:21] <vorlon> well I do have nvidia hardware outside the chroot, so now that I've added restricted, things are happening
[16:21] <vorlon> but no crashes yet
[16:23] <vorlon> possibly all thanks to the python3 "is this in utf8 or ascii mode? depends on if it's a tty or a file" nonsense
[16:24] <vorlon> oh, but the error message is even weirder, "you exported a locale but it doesn't exist"
[16:25] <vorlon> ok yes I can reproduce it with 'LANG=pl_PL.UTF-8 ubuntu-drivers autoinstall' when I *don't* install the locale
[16:26] <vorlon> hairy
[16:26] <bdmurray> hirsute?
[16:26] <vorlon> yes
[16:51] -queuebot:#ubuntu-release- Unapproved: accepted ruby-mysql2 [source] (hirsute-proposed) [0.5.2-1ubuntu<IP_ADDRESS>]
[16:53] -queuebot:#ubuntu-release- Unapproved: accepted ruby-mysql2 [source] (focal-proposed) [0.5.2-1ubuntu<IP_ADDRESS>]
[16:54] <vorlon> problem not reproducible for me on hirsute, yet I don't see any relevant code differences in python3-click or ubuntu-drivers-common...
[16:57] <vorlon> hmm but installing hirsute versions of python3-click and ubuntu-drivers-common on bionic, I can still reproduce it
[17:01] <vorlon> python3 behavior change, whee
[17:01] <vorlon> (newer python3 falls back to C.UTF-8 automatically on invalid locale)
[17:02] <vorlon> so not really a solution for bionic
[17:05] <bdmurray> vorlon: which issue are you looking at?
[17:05] <vorlon> bdmurray: LP: #1943614
[17:05] <vorlon> and I have a prospective patch
[17:06] <bdmurray> Oh, I thought it meant a literal click! I should have looked at the bug. ;-)
[17:12] -queuebot:#ubuntu-release- Unapproved: accepted linux-firmware [source] (focal-proposed) [1.187.17]
[17:12] <vorlon> bdmurray, sil2100: I've uploaded my proposed workaround for ubuntu-drivers-common; please have a look.  If you think this is something we need to fix in ubiquity instead, more digging required
[17:12] <vorlon> (I found it a lot easier to make ubuntu-drivers not crash than to figure out why ubiquity is generating locales at the wrong point in time, but if the latter has other knock-on effects we should revisit)
[17:13] <vorlon> bah ok my upload was rejected because tseliot's git tree seems to be out of date vs the archive
[17:13] <vorlon> rebasing
[17:14] <vorlon> in the meantime, perhaps you can look at the PR and weigh in
[17:15] -queuebot:#ubuntu-release- Unapproved: stress-ng (focal-proposed/universe) [0.11.07-1 => 0.11.07-1ubuntu1] (no packageset)
[17:22] <sil2100> vorlon: looking!
[17:23] -queuebot:#ubuntu-release- Unapproved: stress-ng (hirsute-proposed/universe) [0.12.06-1 => 0.12.06-1ubuntu1] (no packageset)
[17:26] <sil2100> vorlon: ok, code wise looks good, but let me give it a spin
[17:50] <vorlon> sil2100: ok, reuploading
[17:50] -queuebot:#ubuntu-release- Unapproved: ubuntu-drivers-common (bionic-proposed/main) [1:0.9.0~<IP_ADDRESS> => 1:0.9.0~<IP_ADDRESS>] (desktop-core, ubuntu-server)
[18:06] <bdmurray> vorlon: what's this .orig file?
[18:11] -queuebot:#ubuntu-release- Unapproved: accepted zfs-linux [source] (hirsute-proposed) [2.0.2-1ubuntu5.2]
[18:24] <sil2100> vorlon: ok, seems to work as expected!
[18:25] <sil2100> So I'm +1 on this change, tho it would be nice to have the .orig cleaned up!
[18:25] <sil2100> bdmurray: since vorlon is busy, I'll re-upload this with the orig removed
[18:27] <bdmurray> sil2100: okay, let me know when to review it
[18:29] -queuebot:#ubuntu-release- Unapproved: ubuntu-drivers-common (bionic-proposed/main) [1:0.9.0~<IP_ADDRESS> => 1:0.9.0~<IP_ADDRESS>] (desktop-core, ubuntu-server)
[18:30] -queuebot:#ubuntu-release- Unapproved: rejected ubuntu-drivers-common [source] (bionic-proposed) [1:0.9.0~<IP_ADDRESS>]
[18:31] <sil2100> bdmurray: ready ^
[18:31] <sil2100> Ok, in that case I'll also upload ubiquity with that other fix
[18:31] -queuebot:#ubuntu-release- Unapproved: accepted stress-ng [source] (focal-proposed) [0.11.07-1ubuntu1]
[18:34] <bdmurray> sil2100: aw man, there already is an ubuntu-drivers-common in bionic-proposed and its very underverified
[18:34] <sil2100> Aw come ooon
[18:34] <sil2100> Same version?
[18:35] <sil2100> Ah, .3
[18:35] <sil2100> grrr
[18:35] <sil2100> I feel as if in this case we should just drop .3 from -proposed, upload .4 with *ONLY* the change from vorlon and then ask tseliot to rebase on top
[18:36] <bdmurray> I'm looking at some of the bugs
[18:37] <sil2100> Uploaded ubiquity just now, if you could take a look at that one too
[18:37] -queuebot:#ubuntu-release- Unapproved: ubiquity (bionic-proposed/main) [<IP_ADDRESS> => <IP_ADDRESS>] (core)
[18:38] <bdmurray> I'm a +1 for dropping .3 from -proposed.
[18:44] <bdmurray> sil2100: autoinstall seems like it should still work given the ubuntu-drivers code
[18:44] <sil2100> bdmurray: sadly it doesn't, because the current ubuntu-drivers version fails when you give --package-list option to it
[18:45] <sil2100> I didn't dive into the details, but since it's deprecated anyway I didn't feel like debugging the deprecated command!
[18:45] <sil2100> bdmurray: it basically crashes with the error '--package-list unknown argument' or something like that
[18:45] <bdmurray> okay
[18:46] <sil2100> I vaguely remember us having a similar issue during some release already, hm
[18:47] <bdmurray> oh the @click.option() list is much smaller for the autoinstall function
[18:48] -queuebot:#ubuntu-release- Unapproved: accepted ubiquity [source] (bionic-proposed) [<IP_ADDRESS>]
[18:56] <sil2100> bdmurray: eh, so the ubuntu-drivers-common thing won't be that easy - the version that's in -updates is an older version number
[18:57] <sil2100> 1:<IP_ADDRESS> instead of 1:0.9.0
[18:57] <sil2100> So we'd have to do a dummy version with the whole .is. or similar notation
[18:58] <sil2100> hm, or guess I could just remove it from -proposed like with remove-package
[18:59] <sil2100> And just push a 1:<IP_ADDRESS>~<IP_ADDRESS>
[18:59] <sil2100> vorlon: ^
[19:00] <sil2100> I'll start preparing that
[19:07] <bdmurray> sil2100: but then people with the current version from -proposed installed won't have an upgrade path until a new ubuntu-drivers-common is uploaded right? I guess we could just do the upload early next week
[19:08] <sil2100> bdmurray: yeah, we could do that. It's not the first time when we get a new upstream version to -proposed and then drop it for the previous one and just continue from there
[19:08] <sil2100> I suppose it's the risk of -proposed
[19:09] <vorlon> furthermore, they probably don't need an upgrade path for this issue; having a locale set in the environment but not existing seems like very niche behavior outside of this ubiquity issue
[19:12] <sil2100> Ok, pushed the old version with vorlon's change on top + removing the old sru with sru-remove
[19:12] <bdmurray> vorlon: I mean the people who already have the version of the package from -proposed installed
[19:13] <vorlon> bdmurray: of course; I'm saying that if we remove that, and replace it with this one change, there's nothing currently that they /need/ to upgrade to, and we can merge the two after .6
[19:14] <bdmurray> vorlon: got it, we just need to remember to do the merge after .6!
[19:15]  * vorlon nods
[19:17]  * sil2100 needs to wait for the removal to be processed before pushing the new version to the queue
[19:18] -queuebot:#ubuntu-release- Unapproved: ubuntu-drivers-common (bionic-proposed/main) [1:<IP_ADDRESS>~<IP_ADDRESS> => 1:<IP_ADDRESS>~<IP_ADDRESS>] (desktop-core, ubuntu-server)
[19:21] <bdmurray> I'm rejecting the older one
[19:22] <sil2100> Yes plz
[19:23] -queuebot:#ubuntu-release- Unapproved: rejected ubuntu-drivers-common [source] (bionic-proposed) [1:0.9.0~<IP_ADDRESS>]
[19:31] <sil2100> Let's get those reviewed and building in -proposed - if someone could help with the verification of the -proposed packages, that would be awesome as well
[19:31] <sil2100> I need to AFK now, but I'll be back later :)
[19:33] <sil2100> Updated the tracking document as well
[19:34] <bdmurray> I'm reviewing the package now
[19:44] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-drivers-common [source] (bionic-proposed) [1:<IP_ADDRESS>~<IP_ADDRESS>]
[21:38] -queuebot:#ubuntu-release- Unapproved: accepted stress-ng [source] (hirsute-proposed) [0.12.06-1ubuntu1]
[21:38] -queuebot:#ubuntu-release- Unapproved: debian-installer (bionic-proposed/main) [20101020ubuntu543.18 => 20101020ubuntu543.19] (core)
[21:38] <vorlon> bdmurray: ^^
[21:42] -queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (bionic-proposed) [20101020ubuntu543.19]
[21:58] <bdmurray> Oh testing ubuntu-drivers-common it became clear what added python3-click and python3-colorama to the bionic ioss
[21:58] <bdmurray> isos
[22:02] <vorlon> :)
[22:10] -queuebot:#ubuntu-release- Unapproved: accepted gnutls28 [sync] (bionic-proposed) [3.5.18-1ubuntu1.5]
[22:17] -queuebot:#ubuntu-release- Unapproved: accepted gnutls28 [sync] (xenial-proposed) [3.4.10-4ubuntu1.9]
[22:20] <vorlon> ^ useful to include gnutls28 in 18.04.6, so that apt on the image can access https sources
[23:31] <sil2100> List of changes keeps on growing ;) But +1 for that one
[23:31] <sil2100> o/


[07:47] <dholbach> good morning
[15:39] <ESphynx> dholbach: good morning :)
[15:40] <dholbach> hi ESphynx
[15:40] <ESphynx> hi :) is there anything I should do to make that bug fix progress? :)
[15:40] <ESphynx> I did the +repack thing the other day


[08:12] <alkisg> !info udhcp maverick
[08:12] <alkisg> !info udhcpc maverick
[15:35] <gnoob> Hi guys:) Is edulinux and edubuntu basicly the same thing? Or is edulinux redhat'ish and not ubuntu based?  Or you know if edulinux is existing at all?
[15:45] <highvoltage> gnoob: hey! I work for the company that used to maintain edulinux
[15:46] <highvoltage> gnoob: and I'm currently and edubuntu contributor
[15:46] <highvoltage> edulinux doesn't really exist anymore and the contributors got absorbed into edubuntu, although personally I wasn't involved with edulinux at that time
[15:59] <alkisg> highvoltage: will there be a meeting tonight?
[16:00] <highvoltage> alkisg: yep
[16:00] <alkisg> Ty
[16:00]  * highvoltage checks calendar to not be confused by time-zone differences again
[16:01] <coz_> hey guys... I have edubuntu / lucid on one machine and downloaded the edubuntu maverick dvd...I tried several ways to mount the dvd iso to do an upgrade with no success... am I missing something?
[16:13] <gnoob> highvoltage  OK, thanks:)   Im planning to toss out windows from a computerlab and want a linux terminalserver solution. Is edubuntu easy to set up and maintain?  I see that edulinux had a nice http interface for configuring server and for blocking sites and stuff,  this is very interesting, do edubuntu got this posibility too?
[16:14] <highvoltage> gnoob: not really, but there are other alternatives
[16:15] <highvoltage> gnoob: I'm wondering if we could get something like http://www.tectonic.co.za/2010/06/gnome-nanny/ into the archives in time for maverick, it seems quite handy
[16:18] <gnoob> cool :) gnome nanny looks nice
[16:42] <gnoob> Anyone knows whats the best way to run cad software on edubuntu clients?  Is it as easy as this?? : chroot /somewhere/clientOS/ ; aptitude install qcad (or freecad or whatever?)?
[16:43] <alkisg> gnoob: chroot? are you using ltsp?
[16:43] <alkisg> With ltsp, you just install qcad on the server normally, from synaptic
[16:44] <gnoob> no,  but read about ltsp.. thought it was basicly the same thing..
[16:44] <gnoob> ok so ltsp and edubuntu have completely different ways of managing client OS's  (no wonder why I got confused :P)
[16:45] <alkisg> gnoob: erm, no
[16:45] <alkisg> There's no "client os" concent in edubuntu
[16:45] <alkisg> There's no client/server concept in edubuntu
[16:45] <alkisg> You can use LTSP on edubuntu of course
[16:46] <alkisg> But edubuntu by itself doesn't have a chroot or anything like that. When we need a client/server model, we use LTSP on edubuntu for that.
[16:48] <gnoob> Edubuntu used as a server needs LTSP to serve thin clients then?
[16:49] <alkisg> Erm, yes, it includes ltsp
[16:49] <alkisg> (when checked during the installation)
[16:51] <gnoob> thanks for clearing things up alkisg :)
[16:51] <alkisg> gnoob: no problem. For ltsp questions, you can ask either here or in #ltsp
[16:55] <gnoob> For installing a linux terminal server with edubuntu what iso should I install from?  ubuntu-alternate?  My dream would be something installed on a debian server with no X, and a web interface for the simple configuring. (and a good howto for a vanilla install) :)
[16:56] <alkisg> You can install debian/ltsp, but X and gnome will be required to be installed on the server, to show a GUI on the clients
[16:56] <alkisg> Because the clients get the server's desktop environment
[16:57] <alkisg> You can install either with the edubuntu dvd (contains ltsp) or with the ubuntu alternate cd (press F4 during boot) or even with the ubuntu desktop cd (install ltsp afterwards) or with debian, whatever you like.
[16:58] <gnoob> ok :)   I will defenitely go for edubuntu then
[17:03] <gnoob> https://help.ubuntu.com/community/UbuntuLTSP/LTSPQuickInstall     I will try to follow this howto. Looks extremely easy! I hope its as easy as it looks :)
[17:04] <gnoob> Thanks for great help alkisg and highvoltage:)  Going to start setting up a test server soon
[17:28] <dgroos> Howdy All
[17:28] <dgroos> Meeting later?
[17:28] <dgroos> ... in about 2.5 hours?
[17:40] <highvoltage> dgroos: yep!
[18:28] <gnoob> sudo ltsp-build-client     Can someone help a little on this command. Does it take the server installation and make the client from that?  So if I install qcad e.g,  then Ill have to build client afterward?
[18:29] <highvoltage> gnoob: the client only contains enough data to make a system that makes the thin client boot up
[18:29] <highvoltage> gnoob: you just need to have qcad installed on your server and the thin client will run it from there
[18:29] <gnoob> ohh ok :D
[18:30] <highvoltage> it builds the thin client environment using ubuntu packages, so you'll just need an internet connection
[18:30] <gnoob> a lot easier than I thought
[19:28] <Lns> Did I miss the meeting? :/
[19:31] <highvoltage> Lns: it's in 30 mins
[19:31] <Lns> highvoltage: cool thanks :)
[19:53] <highvoltage> alkisg, dgroos, dinda, Lns, mhall119, ogra, stgraber: edubuntu meeting in #ubuntu-meeting inabout 8 minutes!
[19:53] <alkisg> Ty :)
[19:55] <mhall119> ok
[19:55] <mhall119> I'll be in and out
[20:57] <dgroos> Thanks highvoltage for making this meeting happen.  Like you, I'd like to see more teachers voices, here.  Seems like there has recently been a lull in edubuntu noise.  Excepting alkisg's multitudes of posts yesterday!
[20:57] <alkisg> dgroos: heh sorry those are generated automatically from launchpad
[20:57] <highvoltage> hehe :)
[20:57] <alkisg> I didn't mail anything :)
[20:58] <dgroos> go for it, then!
[20:58] <highvoltage> I have a bunch of alkisg's posts marked as unread that I've read but still want to respond to :)
[20:58] <highvoltage> dgroos: oh, I mean, your mails, actually :)
[20:58] <highvoltage> dgroos: especially your documentation ideas
[20:58] <highvoltage> (sorry that I thought that was alkisg :))
[20:59] <dgroos> I'm honored!
[21:00]  * highvoltage goes back to -meeting for a bit to finish taking notes
[21:01] <dgroos> If we had a central area that isn't overly large to organize a concise set of essential how-to's along with a set of less-essential but still important how-tos, that would be widely useful, I'd say.
[21:03] <dgroos> https://help.ubuntu.com/community/EdubuntuDocumentation/EdubuntuCookbook/BasicSetup
[22:20] <uros1> highvoltage, please i can`t login in this site http://learn.ufbt.net/user/policy.php
[22:23] <highvoltage> uros1: ah, I had some problems earlier as well
[22:23] <uros1> ok next time
[22:23] <highvoltage> it seems to fail when you register, but it sends you an e-mail with a link that works when you click on it
[22:23] <highvoltage> it will then give you a page to update your details, then you just have to click on submit and you should be logged in then
[22:24] <uros1> ok
[22:30] <Darkfull> help http://www.4security.com.br/2010/08/04/um-servidor-perfeito-debian-lenny-ispconfig-2/
[22:33] <Darkfull> ou http://www.4security.com.br/tube/2010/07/31/realvnc-v4-bypass-authentication-exploit/


[15:00] <barry> #startmeeting
[15:00] <MootBot> Meeting started at 15:00. The chair is barry.
[15:00] <barry> hi everybody, and welcome to this week's ameu reviewer's meeting
[15:01] <barry> who's here today?
[15:01] <bigjools> me
[15:01] <gmb> me
[15:01] <schwuk> me
[15:01] <sinzui> me
[15:01] <BjornT> me
[15:01] <bac> me
[15:01] <danilo_> me
[15:01] <allenap> me
[15:02] <barry> [TOPIC] agenda
[15:02] <MootBot> New Topic:  agenda
[15:02] <intellectronica> me
[15:02] <barry> == Agenda ==
[15:02] <barry>  * Roll call
[15:02] <barry>  * Next meeting
[15:02] <barry>  * Action items
[15:02] <barry>  * Queue status
[15:02] <barry>  * Mentoring update
[15:02] <barry>    * gmb graduates
[15:02] <barry>  * Review process
[15:02] <barry> [TOPIC] next meeting
[15:02] <MootBot> New Topic:  next meeting
[15:03] <barry> same time next week?  anybody know they won't be able to attend?
[15:03] <allenap> I won't be here.
[15:03] <barry> allenap: k, thanks
[15:03] <allenap> On holiday all week to move house.
[15:03] <flacoste> me?
[15:04] <barry> okay, same time next week
[15:04] <barry> flacoste: hi! :)
[15:04] <danilos> flacoste: yes, you!
[15:04] <barry> [TOPIC]  * Action items
[15:04] <MootBot> New Topic:   * Action items
[15:04] <barry>  * (continued) intellectronica to put cover letter draft on wiki
[15:04]  * intellectronica stares at the floor silently
[15:04] <intellectronica> carry over - i'll get to it one day :(
[15:05] <barry> intellectronica: ;)  ok
[15:05] <barry>  * (continued) sinzui to look into running `make lint` and output PR stanza by default in `review-submit`
[15:05] <sinzui> mwhudson accepted by `make lint addition` I have not checked if it is in trunk
[15:05] <flacoste> output PR stanza by default is still pending?
[15:06] <sinzui> I have not added the PR stanza by default. I'll submit that one line change next
[15:07] <barry> sinzui: great.  i'll leave this item on the list one more week.  sounds like next week we can kill it!
[15:07] <flacoste> barry: you can edit it though
[15:07] <barry> flacoste: yes, i'll remove the 'make lint' part
[15:08] <barry> [TOPIC] queue status
[15:08] <MootBot> New Topic:  queue status
[15:08] <barry> the queue looks pretty good from where i stand
[15:09] <barry> the general queue has two 1.2.3 branches
[15:09] <barry> and only sinzui's branch is over the sla
[15:09] <sinzui> My branch is really needs-reply
[15:09] <barry> cool
[15:09]  * sinzui was replying before the meeting
[15:09] <intellectronica> yeah, danilo and i should be able to finish the general queue by the end of today, if no one requests on call reviews
[15:10] <barry> intellectronica: excellent!
[15:10] <barry> any other comments on the queue status?
[15:11] <barry> 5
[15:11] <barry> 4
[15:11] <sinzui> Should we have a limit to how long a branch can be
[15:11] <sinzui> in work in progress
[15:11] <flacoste> 3 days
[15:11] <flacoste> :-)
[15:11] <intellectronica> sinzui: and if you're over the limit then what, you have to delete the branch and start from scratch?
[15:11] <barry> intellectronica: from PR at least :)
[15:12] <bigjools> guidelines are better than limits
[15:12] <sinzui> intellectronica: I'm not certain some of these branches are valid
[15:12] <barry> we should probably at least remove wips from people who are no longer with the company <wink>
[15:12] <gmb> I think it depends upon how people are actually using the WIP section.
[15:13] <danilos> I don't see how's that bothering us?
[15:13] <gmb> When I use it, it's to register that a branch which has been looked at by a reviewer needs more work before it can really be reviewed (i.e. it's been rejected for some reason).
[15:13] <gmb> Does anyone use it for any other reason? For example, does anyone track every branch through WIP?
[15:13] <barry> i use it just to get pending-reviews to start tracking it
[15:13] <intellectronica> gmb: same. i never put a branch there until it's already entered the review process
[15:13] <danilos> gmb: it used to be a recommended practice to do that
[15:14] <sinzui> gmb: I have used it when I had to rethink a branch when the first review required a reimplementation
[15:14] <gmb> sinzui: Yes, I've encountered that situation too.
[15:14] <danilos> for the reason barry mentioned (put it on pending-reviews, get more visibility to a branch, etc.)
[15:14] <gmb> danilos: Well, that's okay, but does anyone here actually look at WIP regularly? It's not on my radar.
[15:15] <barry> gmb: i don't, and i don't think it /needs/ to be, except for the occasionally culling by the dev, or maybe in general to remove ex-employee branches
[15:15] <barry> [ACTION] barry will cull ex-employee branches from wip
[15:15] <MootBot> ACTION received:  barry will cull ex-employee branches from wip
[15:16] <BjornT> i do look at wip branches
[15:16] <barry> BjornT: you mean you look at the diffs?
[15:17] <BjornT> barry: yeah. to see that the implementation approach is sane.
[15:18] <BjornT> i don't do it that frequently, but it happens.
[15:18] <barry> BjornT: do you usually have contact with the dev first, to get some context for the branch?
[15:19] <barry> does anybody think we need to do more about wip?
[15:20] <BjornT> barry: it depends. i usually contact the developer, since the branch might not be on pending-reviews, or it might not be up-to-date
[15:20] <salgado> me!
[15:20] <barry> salgado: hi!
[15:20] <barry> anything more about wip branches?
[15:20] <barry> or the queue in general?
[15:21] <BjornT> well, speaking of wip branches
[15:21] <BjornT> i wouldn't mind if there was an easy way of looking at current diffs. i don't think PendingReviews is the way to go, though; i rarely add my branches there, since i'm too lazy
[15:22] <danilos> BjornT: do it for all branches in /code/*/launchpad/*?
[15:22] <gmb> That's a looooot of branches.
[15:22] <danilos> i.e. show diffs for them, having developers move them out once they land
[15:22] <barry> danilos: but devs would have to be more diligent about clearing out devpad (which i don't do very often)
[15:23] <danilos> barry: I don't either, but I know some who do (like jtv :))
[15:23] <danilos> it shouldn't be too hard to do a 'mv branch archive/' once you land something, imo
[15:23]  * barry only does it when there's a naming conflict with one of his old branches ;)
[15:23] <BjornT> danilos: no. i'd rather have some meta-data to track which branches are wip
[15:23] <gmb> barry: push --overwrite ;)
[15:24] <barry> gmb: yay!
[15:24] <danilos> BjornT: people will still be lazy to update meta-data
[15:24] <BjornT> danilos: not if it's done pretty much automatically :)
[15:25] <danilos> BjornT: I guess you have some idea about how that would work then
[15:25] <BjornT> for example. when a branch is created, it's wip. when it's submitted for review, it's needs-review.
[15:25] <salgado> all branches could be considered wip until you review-submit them
[15:25] <bigjools> flipping a state from wip to needs-review would be nice
[15:26] <danilos> that's meta-data saying that a branch is _not_ wip :0
[15:26] <danilos> s/0/)/
[15:27] <barry> well, unless there's a specific proposal, maybe we should move on?
[15:28] <barry> 5
[15:28] <barry> 4
[15:28] <barry> 3
[15:28] <barry> 2
[15:28] <barry> 1
[15:28] <barry> [TOPIC] mentoring update
[15:28] <MootBot> New Topic:  mentoring update
[15:28] <barry>    * gmb graduates
[15:28] <barry> yay, gmb!
[15:28]  * flacoste cheers
[15:28] <gmb> \0/
[15:28] <intellectronica> excellent
[15:28] <bigjools> well done
[15:28] <intellectronica> gmb: do you keep the same review shift?
[15:29] <allenap> hurrah!
[15:29] <salgado> intellectronica, good question
[15:29] <salgado> gmb, I think one of us should change the shift
[15:29] <gmb> salgado: I agree.
[15:30] <salgado> since always when we were doing the same shift I was mostly mentoring your reviews and there as nothing else for me to review
[15:30] <gmb> Actually, we've got pretty good coverage on most days. Hmm.
[15:30] <gmb> salgado: I'll change shift. I think it's better that you stay on on Thursdays.
[15:30] <bigjools> we need more on-call euro reviewers monday, tuesday and Friday for Europe AM
[15:30] <salgado> if that's the case I guess we could both stay on Thusday...
[15:31]  * flacoste votes for friday
[15:31] <danilos> yeah, before sinzui arrives on Friday :)
[15:31] <bigjools> monday only has barry PM
[15:31] <flacoste> yeah, but nothign is left on monday :-)
[15:31] <bigjools> lol
[15:31] <gmb> I'll happily take Friday if that's okay with sinzui.
[15:31] <flacoste> and nobody is ever rushed to get something reviewed on monday
[15:31] <barry> gmb: i'd love to get another monday asiapac or eu slot at least to cover for us holidays, which tend to be on monday
[15:31] <sinzui> flacoste: I leave branches that are over 800 lines for barry
[15:31] <gmb> barry: Monday's good for me too.
[15:31] <barry> sinzui: :)
[15:32] <sinzui> gmb: \o/
[15:32] <gmb> barry: I'll leave the choice to you; you're best placed to know where I'd be more useful.
[15:32] <barry> sinzui: you gotta stop working weekends, man!
[15:32] <sinzui> barry: ...and do what, crosswords?
[15:32]  * sinzui hacked on his editor on the weekend
[15:32] <barry> gmb: let's try mondays and see how it goes.  it's easy to switch
[15:32] <intellectronica> sinzui: i hear gedit development is stalled since you started doing review shifts ;)
[15:33] <gmb> barry: Okay. I'll update the OCR page.
[15:33] <barry> gmb: thanks!  though i think it's gonna be a while before the next us holiday (easter maybe?)
[15:34] <barry> [ACTION] gmb to take eu monday OCR slot
[15:34] <MootBot> ACTION received:  gmb to take eu monday OCR slot
[15:34] <barry> [TOPIC] review process
[15:34] <MootBot> New Topic:  review process
[15:34] <barry> well, i really have nothing here.  anybody have any further comments or observations?
[15:35] <flacoste> our review team tocks!
[15:35] <gmb> And ticks
[15:35] <flacoste> rocks even!
[15:35] <barry> indeed!
[15:35] <flacoste> big round of applause for the team!
[15:36]  * barry claps
[15:36] <bac> hurrah
[15:36] <flacoste> not golf applause barry: footban hooligans style please!
[15:37]  * barry slams his hands raw and screams his voice hoarse
[15:37]  * flacoste rocks the casbah
[15:37]  * barry ignores the concerned look from his cat
[15:37]  * sinzui just bangs the rocks together.
[15:37]  * bigjools sings songs about the referee being a wanker
[15:37] <barry> :)
[15:38]  * barry thinks this meeting might be over
[15:38] <barry> anything else?
[15:38] <barry> 5
[15:38] <barry> 4
[15:38] <barry> 3
[15:38] <danilos> 3
[15:38] <danilos> 2
[15:38] <danilos> 1
[15:39] <danilos> :)
[15:39] <barry> #endmeeting
[15:39] <MootBot> Meeting finished at 15:39.
[15:39] <bigjools> thanks barry
[15:39] <intellectronica> thanks barry
[15:39] <barry> yay, thanks everyone... especially danilos :)
[15:39] <danilos> thanks guys, especially barry :)
[15:39] <kiko> ciao
[15:39] <barry> see ya


[16:00] <matsubara> #startmeeting
[16:00] <MootBot> Meeting started at 10:00. The chair is matsubara.
[16:00] <matsubara> Welcome to this week's Launchpad Production Meeting. For the next 45 minutes or so, we'll be coordinating the resolution of specific Launchpad bugs and issues.
[16:00] <matsubara> [TOPIC] Roll Call
[16:00] <MootBot> New Topic:  Roll Call
[16:00] <matsubara> Not on the Launchpad Dev team? Welcome! Come "me" with the rest of us!
[16:01] <Chex> here
[16:01] <gary_poster> me
[16:01] <abentley> matsubara, hello, my name is rockstar
[16:01] <gary_poster> heh
[16:01] <matsubara> hi abentley, welcome :-)
[16:01] <abentley> (rockstar is not well)
[16:01] <flacoste> me
[16:01] <matsubara> just saw his email, thanks for standing in
[16:02] <matsubara> bigjools, danilos, Ursinha, sinzui, allenap: hi
[16:02] <bigjools> o/
[16:02] <allenap> me
[16:03] <matsubara> ok, let's move on while others can join in later
[16:03] <matsubara> [TOPIC] Agenda
[16:03] <MootBot> New Topic:  Agenda
[16:03] <matsubara>  * Actions from last meeting
[16:03] <matsubara>  * Oops report & Critical Bugs & Broken scripts
[16:03] <matsubara>  * Operations report (mthaddon/Chex/spm/mbarnett)
[16:03] <matsubara>  * DBA report (stub)
[16:03] <matsubara>  * Proposed items
[16:03] <matsubara> [TOPIC] * Actions from last meeting
[16:03] <MootBot> New Topic:  * Actions from last meeting
[16:04] <matsubara>  * matsubara to email Tim about https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1488EA174 and
[16:04] <matsubara>     * Filed bug 520446 and emailed Tim about it.
[16:04] <matsubara>  * matsubara to talk to leonard about https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1488EA884
[16:04] <matsubara>     * Talked to leonard about this one, details added to bug https://bugs.edge.launchpad.net/launchpad-foundations/+bug/271029
[16:04] <matsubara>  * rockstar to investigate OOPS-1480CMP1 and fill in details on bug 517126
[16:04] <matsubara>  * matsubara to ask stub to send the dba report to the list
[16:04] <matsubara>     * emailed stub about this week and last week report (2010-02-11)
[16:04] <matsubara>  * rockstar to raise the importance of ensuring sufficient monitoring of this part (i.e. branch updates emails failing to be delivered) of code-hosting by thumper
[16:04] <matsubara>  * Gary talk about "too many different kinds of moving parts" in our architecture. If we have fewer moving parts then we can institute more uniform nagios-like-checks.
[16:04] <matsubara>  * Ursinha to talk to rockstar about bug 514461
[16:04] <matsubara>    * rockstar said: "yes, I have been trying to get it landed for a week.  If it got into production-stable, then I'm going to have it CP'd today (02/04)."
[16:04] <matsubara>  * Ursinha to talk to mwhudson about bug 513412
[16:04] <matsubara> gary_poster, did you talk about your meeting action during the TLs meeting?
[16:05] <gary_poster> matsubara: yes I did.  It is now in BjornT's hands to decide what, if anything, we do about it, I think
[16:05] <Ursinha> matsubara: I talked to rockstar but not with mwhudson, sorry
[16:05] <matsubara> gary_poster, ok, thanks for bringing that up
[16:05] <matsubara> [action] * Ursinha to talk to mwhudson about bug 513412
[16:05] <MootBot> ACTION received:  * Ursinha to talk to mwhudson about bug 513412
[16:06] <matsubara> [action] * rockstar to investigate OOPS-1480CMP1 and fill in details on bug 517126
[16:06] <MootBot> ACTION received:  * rockstar to investigate OOPS-1480CMP1 and fill in details on bug 517126
[16:06] <abentley> matsubara, it appears this was not completed.
[16:07] <matsubara> it wasn't. I'm re-adding it to the meeting action items so I can bring it up again next week
[16:07] <matsubara> I think that's it for actions from the last meeting
[16:07] <matsubara> let's move on
[16:08] <matsubara> [TOPIC] * Oops report & Critical Bugs & Broken scripts
[16:08] <MootBot> New Topic:  * Oops report & Critical Bugs & Broken scripts
[16:08] <matsubara> abentley, I filed bug https://bugs.edge.launchpad.net/launchpad-code/+bug/520482
[16:08] <abentley> matsubara, rockstar did raise the oops issue with us.
[16:08] <matsubara> ubuntu bug?
[16:09] <abentley> matsubara, okay, is there something you want me to do about that bug?
[16:10] <matsubara> abentley, could you please fill in the details in the bug report?
[16:10] <matsubara> abentley, fill in the details about the oops rockstar discussed in the code team
[16:10] <matsubara> about bug 520482, could you triage and get that one assigned?
[16:11] <matsubara> there's another one related to that bug 520446, which I emailed tim about today
[16:11] <abentley> matsubara, sorry, I meant that rockstar raised the issue of monitoring emails.
[16:12] <matsubara> abentley, cool.
[16:12] <abentley> matsubara, sure I can set the status high, but why do you believe it should be assigned immediately?
[16:13] <matsubara> abentley, setting it to high and nobody taking ownership means it'll stay there forever
[16:13] <matsubara> abentley, otoh, maybe it's not a big deal
[16:14] <matsubara> although it's the second top oops on yesterday's lpnet report
[16:14] <abentley> matsubara, no, it doesn't.  I have been working on high bugs this week and last.
[16:14] <abentley> matsubara, and there are oops bugs that I think should be fixed before this one.
[16:15] <matsubara> abentley, that's cool. setting it to triaged and some status according to your teams priority is already good enough for me, as long as those oopses don't fall through the cracks
[16:15] <matsubara> gary_poster, any news about bug 450593?
[16:16] <matsubara> still seeing some DE errors on lpnet summaries
[16:17] <gary_poster> matsubara: I don't think that's the most up-to-date bug on this, but could be wrong.  I'll investigate for next mtg
[16:17] <matsubara> gary_poster, and bug https://bugs.edge.launchpad.net/launchpad-foundations/+bug/403618 ? it's the top one on edge summaries. can we get someone assigned to fix that one?
[16:18] <gary_poster> matsubara: ack
[16:18] <gary_poster> will do
[16:19] <matsubara> [action] gary_poster to check status on work for DisconnectionErrors (bug 450593) and assign bug 403618 to someone in foundations
[16:19] <MootBot> ACTION received:  gary_poster to check status on work for DisconnectionErrors (bug 450593) and assign bug 403618 to someone in foundations
[16:20] <matsubara> ok, that's all for oops
[16:20] <matsubara> let's see the scripts and critical bugs
[16:20] <matsubara> karma-updater failing again, which sinzui already replied to
[16:21] <matsubara> checkwatches hung and killed by spm
[16:22] <matsubara> allenap, is someone chekcing that checkwatches issues? can you reply to the email spm sent to the list?
[16:22] <allenap> matsubara: I haven't seen that message, unless it was some time ago?
[16:22] <matsubara> allenap, my email client says spm sent his email 11 hours ago
[16:23] <matsubara> allenap, subject	Re: Scripts failed to run: loganberry:karma-update, loganberry:allocate-revision-karma, loganberry:launchpad-stats, loganberry:expire-questions, loganberry:checkwatches, loganberry:productreleasefinder, loganberry:update-cache, loganberry:launchpad-targetnamecacheupdater
[16:23] <allenap> matsubara: Cool, found it. I'll reply.
[16:23] <matsubara> thanks allenap
[16:24] <matsubara> we have 5 critical bugs
[16:24] <matsubara> 3 fix committed and 2 triaged
[16:24] <matsubara> https://bugs.edge.launchpad.net/launchpad-foundations/+bug/511567
[16:24] <matsubara> https://bugs.edge.launchpad.net/launchpad-foundations/+bug/514267
[16:24] <matsubara> the latter one seems to be in progress
[16:25] <matsubara> gary_poster, and the former one doesn't seem critical. is it really?
[16:26] <gary_poster> matsubara: no.
[16:27] <matsubara> ok. set to high then. IIRC, Curtis had a branch to fix that one
[16:27] <matsubara> I'll assign to him
[16:27] <gary_poster> ah ok, thanks
[16:28] <matsubara> ok, thanks everyone. let's move on
[16:28] <matsubara> [TOPIC] * Operations report (mthaddon/Chex/spm/mbarnett)
[16:28] <MootBot> New Topic:  * Operations report (mthaddon/Chex/spm/mbarnett)
[16:28] <Chex> hello everyone
[16:28] <Ursinha> wq
[16:28] <Ursinha> oops, sorry :/
[16:29] <Chex> - New branch-scanner setup again with 8944 CP; seems to be working well now.
[16:29] <Chex> - DB Relication Lag/Slave-master issue: We are still running on the fake lag script pointing all traffic at the main
[16:29] <Chex>         production db.  It appears as though we are blocked on Stuart's return before any progress is likely to be made
[16:29] <Chex>         on this.
[16:29] <Chex> - LP incidents of note:
[16:29] <Chex>         ; LP Cherry-picks: 8944 to Codehost; loganberry bzrsyncd on 08-Feb,
[16:29] <Chex>             CP 8945; rolled out to: germanium/ppa respectively on 10-Feb
[16:29] <Chex> anyone have questions/comments on this?
[16:32] <matsubara> thanks Chex
[16:32] <matsubara> [TOPIC] * DBA report (stub)
[16:32] <MootBot> New Topic:  * DBA report (stub)
[16:32] <matsubara> I emailed stub to sent the DBA report to the list
[16:32] <matsubara> [TOPIC] * Proposed items
[16:32] <MootBot> New Topic:  * Proposed items
[16:32] <matsubara> no new proposed items
[16:32] <matsubara> anything else before I close?
[16:33] <sinzui> yes
[16:33] <matsubara> go ahead sinzui
[16:33] <sinzui> http://people.canonical.com/~lpqateam/test-plan-report-10.02.html
[16:33] <sinzui> ^ Is every team looking at this every day?
[16:33] <MootBot> LINK received:  http://people.canonical.com/~lpqateam/test-plan-report-10.02.html
[16:34] <abentley> sinzui, no idea.
[16:34] <jtv> sinzui: cool, I wasn't aware of that one... will there be a single link for the current milestone?
[16:35] <sinzui> matsubara: I moved some contributor landings from other testplans listed on to the wiki to my teams wiki page because I was tracking the bug on my teams milestone...there is a disconnect between where the wiki entry is and the qa-needtesting bug tag
[16:36] <sinzui> jtv: I added the link to milestones I watch so that I am reminded of this: https://edge.launchpad.net/launchpad-registry/+milestone/10.02
[16:37] <matsubara> sinzui, what do you mean by disconnect between the wiki entry and the qa-needstesting tag?
[16:37] <jtv> sinzui: I hope this will become fully LP-native at some point, it's very cool!
[16:37] <matsubara> sinzui, AFAICT, only translations is using the qa-needstesting tag
[16:37] <Ursinha> sinzui: that happens because the scripts track the committers and not the teams
[16:37] <sinzui> matsubara: jpds's bugs are on ^ my milestone page, but his entries are added to a different wiki page tan my entires, so I must hunt for them
[16:38] <matsubara> sinzui, you mean LaunchpadTestPlan wiki page?
[16:38] <bigjools> that will get even more disconnected as we do more feature-based teams
[16:38] <sinzui> We agreed we would all use them starting in 10.02
[16:38] <Ursinha> sinzui: so if henninge commits a fix for a bug in registry, it will show up in translations test plan
[16:38] <matsubara> that's because external contributors don't have a team
[16:38] <matsubara> they work on whatever they want
[16:38] <sinzui> matsubara: correct
[16:38] <abentley> jml is showing up under code team, but he isn't part of that team anymore.
[16:38] <sinzui> Ursinha: Correct
[16:38] <matsubara> so, that's why they end up in the LP test plan wiki page
[16:38] <Ursinha> matsubara: correct :)
[16:39] <matsubara> do I get a A+ for all the above correct answers?
[16:39] <Ursinha> sinzui: this can be changed if needed, it's just a matter of thinking about how
[16:39] <Ursinha> matsubara: :)
[16:40] <sinzui> I would prefer to never visit the wiki. I need to visit the wiki to prove QA is being done
[16:40] <jml> please give me my own page! :)
[16:40] <Ursinha> sinzui: I'm working on it
[16:41] <bigjools> jml: would it have anything on it?  /me hides
[16:41] <Ursinha> sinzui: and I thought that the migration would be done after all possible problems pointed in the experiment being fixed
[16:41] <sinzui> actually, jml and mrevell do need a page
[16:42] <sinzui> or something that makes it easy to see that they have verified their work this cycle
[16:42] <sinzui> I do not think mrevell knows he has lots of entries hidden on a page from last release
[16:42] <matsubara> [action] Ursinha to set up StrategyTeamTestPlan wiki for jml,mrevell
[16:42] <MootBot> ACTION received:  Ursinha to set up StrategyTeamTestPlan wiki for jml,mrevell
[16:42] <mrevell> sinzui, Hidden entries?
[16:43] <matsubara> sinzui, I usually remind him
[16:43] <Ursinha> sinzui: if you're talking about the Launchpad testplan, we usually poke him for that
[16:43] <matsubara> but it's better if the strategy team has their own TP
[16:43] <matsubara> hi mrevell  :-)
[16:43] <Ursinha> matsubara: sinzui, that would be easy to do
[16:43] <Ursinha> but the idea is to get rid of wikis, right?
[16:43] <mrevell> hey matsubara, I'll talk to you outside the meeting
[16:43] <sinzui> mrevell: https://dev.launchpad.net/LaunchpadTestPlan/10.01
[16:44] <Ursinha> I thought there was an agreement on it! Or maybe I got it wrong
[16:45] <Ursinha> I'll set up the page for them to use while we don't migrate
[16:45] <abentley> kanban is also supposed to be tracking QA.  Do we have a plan to keep everything in sync?
[16:46] <matsubara> Ursinha, we will get rid of the wiki once the work on bug tagging is done. if that's not ready yet, my suggestion is to create the wiki page for jml and mrevell so they will be able to track the QA needed for their work
[16:46] <matsubara> kanban too?
[16:46] <matsubara> that's new to me
[16:46] <Ursinha> so to me
[16:46] <sinzui> abentley: BjornT will be working on syncing via API
[16:46] <Ursinha> ah
[16:46] <Ursinha> ok
[16:47] <sinzui> abentley: BjornT wants every change in LP sent to the kanban boards
[16:47] <matsubara> oh
[16:47] <matsubara> Ursinha, I guess you'll need to talk to BjornT then
[16:47] <matsubara> before working on the qa tagging thing
[16:47] <mrjazzcat> matsubara: or me :-)
[16:47] <Ursinha> matsubara: actually no
[16:48] <Ursinha> matsubara: well, he's going to perform a search on bugs with tags and yada
[16:48] <Ursinha> matsubara: I'll talk to him to confirm that :)
[16:48] <matsubara> my point exactly :-)
[16:49] <matsubara> anyway, sinzui, do you have anything else?
[16:49] <sinzui> matsubara: no
[16:50] <matsubara> thanks. as a general reminder, please try to keep an eye on the test plan report page for the current cycle, and spread the word to your teammates: http://people.canonical.com/~lpqateam/test-plan-report-10.02.html
[16:50] <matsubara> I think that brings the meeting to an end
[16:51] <matsubara> Thank you all for attending this week's Launchpad Production Meeting. See https://dev.launchpad.net/MeetingAgenda for the logs.
[16:51] <matsubara> #endmeeting
[16:51] <MootBot> Meeting finished at 10:51.
[16:51] <Ursinha> thanks matsubara
[16:51] <abentley> thanks matsubara.
[19:18] <mwhudson> Ursinha: i can't see that bug you're supposed to talk to me about


[04:01] <studio-user875> Helllo, is ubuntu social media kit snap good?
[22:36] <MaynardWaters> hi guys, I'm trying to get a behringer UMC404HD to work with audacity in ubuntn stdio
[22:36] <MaynardWaters> anyone able to help me trouble shoot recording clicking?


[12:59] <Laney> Hi, was trying to push to the Ubuntu git repository for a package but I get an error "fatal: remote error: Cannot automatically set the default repository for this target; push to a named repository instead."
[12:59] <Laney> I don't quite understand the terminology yet - what's it telling me?
[13:02] <Laney> That I can't push to an unnamed repository and have to use a team instead?
[13:02] <Laney> I was trying to create the equivalent of the default UDD branch
[13:05] <cjwatson> Laney: We don't have everything hooked up properly for package repositories yet
[13:05] <cjwatson> Laney: I think we need to work out what to do with permissions for them - like, anyone who can upload the package should be able to push to the default repository
[13:06] <cjwatson> Laney: What's the package so I can give a recommendation for the time being?
[13:06] <Laney> Indeed. OK, so it's just not there yet - that's fine.
[13:06] <Laney> gst-plugins-base1.0
[13:07] <cjwatson> Laney: Maybe git+ssh://git.launchpad.net/~ubuntu-desktop/ubuntu/+source/gst-plugins-base1.0 then
[13:08] <cjwatson> That's ~ubuntu-desktop's default repository for that source package
[13:08] <cjwatson> You're one of the first people using package repositories, so expect misc oddities
[13:09] <Laney> Seems to have pushed, at least
[13:09]  * Laney looks for this on the web UI
[13:09] <cjwatson> It should be https://code.launchpad.net/~ubuntu-desktop/ubuntu/+source/gst-plugins-base1.0, but that isn't hooked up yet
[13:09] <cjwatson> See oddities
[13:09] <cjwatson> But https://code.launchpad.net/~ubuntu-desktop/ubuntu/+source/gst-plugins-base1.0/+git/gst-plugins-base1.0 works
[13:10] <Laney> Nod, I was trying the former
[13:11] <Laney> Hmm. I wonder how to mangle gbp.conf.
[13:11] <cjwatson> (The latter's the unique name, but once everything is hooked up you'll only have to use that fully-qualified form for personal repositories (equiv of +junk) and for some cases where you're doing odd things)
[13:11] <Laney> I'm pushing ubuntu:master
[15:11] <leftyfb> Is there any sort of rss feed that triggers on any updates to any of the bugs you're subscribed to? Not just status for bugs like http://feeds.launchpad.net/~leftyfb/latest-bugs.atom
[15:15] <cjwatson> I don't believe so.  The bug feed template only contains id, title, target display name, importance, status.
[15:16] <cjwatson> ICBW but my instinct is that generating a much more detailed feed would be very expensive in terms of database workload.
[21:12] <shadeslayer> cjwatson: poke?
[21:30] <cjwatson> shadeslayer: I'd suggest you ask wgrant about the bzr-git tag import thing; I don't know it well enough
[21:33] <shadeslayer> wgrant: poke poke, how does one import git tags into bzr launchpad
[22:41] <wgrant> shadeslayer: That should work automatically for any tags that are in the imported branch's history.
[22:41] <shadeslayer> wgrant: right, but I want to specifically checkout a tag
[22:43] <wgrant> shadeslayer: I don't think it's possible to directly import a tag.
[22:43] <shadeslayer> oh :(
[22:43] <shadeslayer> means scripterooing on my side
[22:44] <dobey> yeah, i think it only works with svn by virtue of how svn itself works
[22:44] <dobey> i don't think lp code importing is designed to generally work that way
[22:44] <shadeslayer> *nod*