[01:23] <ArneGoetje> apachelogger: thanks a lot. :)
[02:15] <morfic> is ARM here to stay? somehow had the idea i read ubuntu dropped ARM support, i would love to be totally wrong on this though :)
[02:17] <directhex> morfic, ubuntu/arm hardware will be in the shops for xmas
[02:18] <morfic> i'd be happy to just keep ubuntu on this device if ubuntu is supporting it for a while
[03:05] <kees> jcastro: in http://identi.ca/notice/9803393 did you mean you were trying to _raise_ your vrms score?  :)
[03:36] <greg-g> kees: he's an instigator like that :)
[03:36] <kees> I suspected.  :)
[03:42] <LaserJock> I wonder how high I can get mine?
[03:42] <kees> that's the meme I'm working on now.  ;)
[03:43] <LaserJock> darn, only 0.7%
[03:43] <LaserJock> how the heck am I gonna tick off the FSF with that low of a score!!
[03:44] <LaserJock> and 1/2 of my score is from ATI/nvidia drivers, which I don't need
[03:45]  * kees is waiting for a massive apt-get to finish...
[03:45] <superm1> i dont think it's fair to count the modaliases
[03:45] <superm1> they're flat text files, nothing non-free about them
[03:45] <jcastro> you need all the sun java stuff to really make a difference
[03:46] <stooj> Does anyone know of a python programme that uses policy kit?
[03:47] <kees> I'm attempting to install all of multiverse and partner.  ;)
[03:48] <LaserJock> so if I install all of multiverse I can get to 30%
[03:48] <LaserJock> what we really need is a web-vrms that looks for non-free web apps
[03:48] <kees>   342 non-free packages, 15.2% of 2252 installed packages.
[03:48] <kees>   172 contrib packages, 7.6% of 2252 installed packages.
[03:49] <greg-g> nice
[03:49] <greg-g> LaserJock: that sounds like a great Fx plugin: "Sorry, vrms says that this site has non-free javascript and runs on .NET, you can't go here"
[03:50] <[reed]> kees: what program is that?
[03:50] <kees> [reed]: vrms
[03:50] <[reed]> ah
[03:53] <LaserJock> I'd love to run vrms on the Windows Vista desktop I just got today for work
[03:53] <LaserJock> I'm sure I'd have a slightly higher score ;-)
[06:28] <dholbach> good morning
[07:04] <billybigrigger> so i ibus taking over for xorg for input?
[07:04] <billybigrigger> now any keyboard and mouse issues should be attempted to be debugged through it?
[07:21] <YokoZar> Does anyone else have Applications->Accessories->gedit instead of Applications->Accessories->Text editor?
[07:28] <billybigrigger> i have gedit
[07:47] <poolie> doko: thanks for the fix for bug 392355, i'll test it
[08:45] <directhex> hm. one of my syncs seems to have evaporated
[08:46] <directhex> https://bugs.launchpad.net/ubuntu/+source/mono/+bug/426759 is "Fix Released", but I can't find it on the package publishing history nor the karmic queue
[08:58] <ogra> cjwatson, "Run usplash at the native resolution if KMS is available." where does usplash get the info about the theme/resolution to use for that ?
[08:59] <ogra> (i'm trying to convince it to use the matching framebuffer res on armel without defaulting to 640x480 and without making Keybuk unhappy by looking for a file that holds the res from initramfs)
[09:04] <cjwatson> ogra: can you use bzr log / bzr diff? the patch is fairly simple
[09:05] <cjwatson> if you read the diff and still don't understand, then ask me :)
[09:07] <directhex> blarg, why is my system so much less stable post-format?
[09:08] <Laney> you should have installed warty and upgraded
[09:09] <directhex> this system has never had warty
[09:09] <Laney> thats your problem right there
[09:10]  * Laney runs
[09:10] <pitti> Good morning
[09:13] <simon-o> Hi, I fixed a bug and uploaded the branch. It is enough to file a merge proposal or do I need to subscribe ubuntu-main-sponsors to the bug?
[09:14] <mvo> simon-o: for what package and bug?
[09:15] <simon-o> mvo: bug 376400 package graphviz
[09:15] <mvo> simon-o: subscribing ubuntu-main-sponsors is probably a good idea then
[09:16] <mvo> to ensure it is picked up by the sponsoring queue
[09:16] <simon-o> mvo: thanks, I just subscribed them.
[09:21] <mvo> simon-o: thank you for working on it!
[09:23] <slytherin> are there any rescue images for karmic? I got a unbootable PC because of bug 424503 and I don't want to download whole karmic daily CD. :-(
[09:25] <YokoZar> slytherin: you could try a stick image...but those are larger than the CD
[09:25] <YokoZar> so not really ;)
[09:25] <slytherin> ahh, I will download the CD image.
[09:26] <slytherin> sad thing is I didn't even have backup of old cd image (2 days old). So I can not even use jigdo/zsync.
[09:29] <cjwatson> you can use the netboot image to rescue
[09:29] <cjwatson> in a pinch
[09:29] <cjwatson> http://cdimage.ubuntu.com/netboot/
[09:35] <slytherin> cjwatson: I will try when I go home. Thanks for info.
[09:35] <slytherin> cjwatson: mini.iso is the image, right?
[09:37] <cjwatson> yeah
[09:55] <zyga> mvo: hello
[09:55] <zyga> mvo: is there any list of small tasks that 3rd parties could help you with the app store?
[09:56] <mvo> zyga: I have a "TODO" file in the source, there is also the "bitesize" tag in the bugreport
[09:56] <mvo> zyga: the bugreports of software-store
[09:56] <zyga> mvo: let me check that! :-)
[09:56] <mvo> zyga: there are quite a few smallish UI bits that are not done exactly as the spec says
[09:56] <mvo> :)
[09:56] <zyga> mvo: is it possible to do development on jaunty?
[09:57] <mvo> zyga: difficult, it uses aptdaemon and that is not available on jaunty
[09:57] <mvo> zyga: it would be a good idea to isolate that into a common class that can then be exchanged for a Mock class (or even a synaptic backend ;)
[09:57] <mvo> zyga: then it can be run under jaunty just fine AFAICS
[09:57] <mvo> zyga: that would be a nice task, something like the backend/ dir in update-manager
[09:58] <zyga> mvo: I'm fine with karmic kvm but I'll reinspect in a second - I need to find & fetch sources first
[09:58] <mvo> zyga: bzr get lp:software-store should do the trick
[09:59]  * mvo hugs zyga - great to have you back here :)
[09:59] <zyga> :-)
[09:59] <zyga> I'm ill so I have some time off from my regular work
[10:00] <zyga> mvo: I've got it - let me have a look at what's already there
[10:02] <lool> cjwatson: hola
[10:02] <lool> cjwatson: You might remember chaning usplash to use the native kms resolution
[10:02] <mvo> zyga: oh, get well
[10:02] <lool> cjwatson: (I do see that usplash is not that much relevant anymore but still)
[10:02] <lool> cjwatson: You actually changed the init/shutdown scripts to not pass -x / -y
[10:03] <lool> cjwatson: But that causes usplash to try to modeset to the first res in the linked list of themes
[10:03] <lool> cjwatson: Which is 640x400
[10:03] <lool> cjwatson: So we're actually using 640x400
[10:03] <lool> cjwatson: I tried an ugly patch to use the /sys values from the native kms virtual size and pass these as usplash xres/yres
[10:03] <lool> cjwatson: And result was nice
[10:04] <lool> cjwatson: So I wanted to double check whether it was intentional or not to use 640x400 (ogra suggested it might be to get the 640x400 centered around black)
[10:04] <cjwatson> lool: I thought that it would normally simply use the boot resolution
[10:04] <cjwatson> the intent was that it would do so
[10:04] <ogra> usplash does only what you tell it :)
[10:04] <ogra> and uses 640x400 if you dont tell it anything
[10:04] <cjwatson> that isn't really true, when it comes up bogl_xres is set to the native resolution
[10:05] <cjwatson> something slightly odd is happening if that isn't the case
[10:05] <lool> cjwatson: if there's no -x/-y and no usplash.conf, usplash uses the first theme res as default xres/yres and modesets to that
[10:05] <cjwatson> ok, that was not my expectation. feel free to fix
[10:05] <lool> cjwatson: Ok thanks
[10:05] <cjwatson> I don't think you should use /sys though; it would be better to have an option to usplash to use whatever resolution the framebuffer is currently in
[10:05] <lool> cjwatson: Do you see any issues with reading these values from /sys?
[10:05] <cjwatson> I do, it's ugly :)
[10:05] <lool> cjwatson: I absolutely agree
[10:06] <cjwatson> usplash is perfectly capable of figuring out the current fb resolution - it's just a matter of picking a theme based on that
[10:06] <cjwatson> I'd absolutely be in favour of such a change
[10:06] <lool> Ok
[10:06] <lool> It's not a 5 minutes change like reading from /sys though but I agree it's the right thing to do
[10:08]  * ogra only sees usplash_bogl_set_resolution(int xres, int yres) but no "get_resolution" in usplash_bogl.c
[10:08] <cjwatson> getdimensions
[10:08] <zyga> mvo: is it possible to replace aptdaemon with something like packagekit?
[10:08] <ogra> ah, right, i see it
[10:08] <zyga> mvo: I'm just wondering how to run it right now
[10:08] <zyga> mvo: is it conceptually the same thing?
[10:13] <mvo> zyga: yeah, packagekit, synaptic, aptdaemon, its just the install backend
[10:14] <mvo> zyga: ideally it should be a backend class so that the backend can easily be switched
[10:14] <zyga> mvo: it looks like atpdaemon is used everywhere, including the ui
[10:14] <zyga> mvo: if that's what you want I could try to hack it to move all stuff to backend and just glue the current code to use that backend
[10:15] <zyga> I'll probably move to karmic to get aptdaemon though
[10:15] <zyga> i'll be easier this way
[10:15] <zyga> mvo: is there any particular abstract interface thingy you like (like from abc import ... ) ?
[10:16] <mvo> zyga: ok, my plan is to eventually move the aptdaemon stuff all out into a single place, but I have not had time for that, so just using karmic is easier for now :)
[10:16] <mvo> zyga: no preferences here
[10:16] <zyga> mvo: okay
[10:28] <lool> cjwatson: the svga backend (but not the bogl backend) sets the res on init; should I care about that backend or is it ok if I only cover the bogl one?  I dont know whether the SVGA backend is actively used and whether it's important that it sets the res
[10:29] <cjwatson> lool: svga is used on x86
[10:29] <cjwatson> lool: for arm you don't need to worry
[10:43] <lool> Pff bogl does a kernel ioctl with xres/yres set to the defaults of 0 and this is kernel driver specific
[10:49] <zyga> I've got karmic :-)
[11:12] <geser> looking at http://launchpadlibrarian.net/31587515/buildlog_ubuntu-karmic-amd64.cmake_2.6.4-1ubuntu2_FAILEDTOBUILD.txt.gz I wonder what's the right fix. Move the missing header file from libxmlrpc-c3-dev to libxmlrpc-core-c3-dev or merge both -dev packages again as it was split so libxmlrpc-core-c3-dev could get into main but currently both libxmlrpc-c3 and libxmlrpc-core-c3 are in main so there is no
[11:12] <geser>  real reason for the split.
[11:24] <Keybuk> kees: yes, I do mind
[11:29] <Keybuk> kees: pulling random patches makes it hard to test things, and in general I do not want any patches in the Ubuntu package - we should only ship the upstream releases with no changes
[11:29] <Keybuk> there will be a new upstream release rsn, I will package that as soon as it's out
[11:29] <Keybuk> so be patient
[11:29] <Keybuk> we are not releasing *tomorrow*, there is plenty of time
[11:43] <james_w> I'm looking for other opinions from other devs on https://code.launchpad.net/~statik/ubuntu/karmic/couchdb/fix-bug427036/+merge/11543
[11:46] <lool> cjwatson: (I'm moving ogra's /sys reading from initramfs-tools to usplash but still intend to replace that stuff with proper usplash code)
[11:47] <ogra> lool, but please remove the dependency on mxcfb (else you need to read /proc/cmdline again from the usplash script) and make it look more like cjwatson's fix
[11:49] <lool> ogra: ?
[11:49] <lool> ogra: I'll show you what I have
[11:49] <ogra> ok
[11:49] <ion> keybuk: Do you have time to review the current mountall patches?
[11:49] <ogra> i have the code pretty much in my head (how i would do it)
[11:50] <ogra> lets see if we match :)
[11:50] <lool> ogra: http://paste.ubuntu.com/269076/
[11:50] <lool> ogra: I'm still finishing it, there's a typo (res instead of virtual_size)
[11:50] <ogra> even better than mine (i wouldnt have touched colins part :) )
[11:51] <ogra> yours fixes both :)
[11:51] <lool> Well I know it's ugly but at least it's consistent and will use the right res immediately for everybody and we used to check /sys for kms already
[11:51] <lool> But I intend to remove the /sys checks when I'm done
[11:52] <ogra> yeah
[11:52] <ogra> hacing it all in the C code will even make usplash.conf obsolete :)
[11:52] <ogra> *having
[11:52] <Keybuk> ion: not yet; I'm working on the network stuff
[11:53] <Keybuk> ion: but I did briefly look through them and they looked ok
[11:53] <Keybuk> ion: can't find the URL?
[11:54] <lool> ogra: I dont really know why we bother with usplash.conf in the usplash init-top and _down scripts since usplash will parse the .conf by itself if we dont set it on the cmdline
[11:54] <pitti> james_w: replied in the merge request
[11:55] <james_w> thanks pitti
[11:56] <james_w> pitti: tangential question, could you tell me what led you to vote "Abstain" on that request
[11:56] <ogra> lool, yeah, thats redundant
[11:56] <james_w> (so I can pass on the feedback to the LP devs as I think this is a failing in the UI)
[11:58] <ion> keybuk: http://heh.fi/patches/mountall/
[11:58] <Keybuk> ion: yeah found it
[11:58]  * Keybuk has a weird issue where if I reply to a mail, it appears to get deleted
[11:58] <ion> Huh
[11:58] <Keybuk> I'm not convinced it's not PEBCAK
[11:59] <pitti> james_w: there wasn't anything else that said "I just want to add a comment"
[11:59] <pitti> james_w: perhaps I should just have left it as "Select.."
[11:59] <james_w> did you use one of the "Reply" links, or something from the table at the top?
[12:00] <pitti> james_w: "reply"
[12:01] <james_w> ok
[12:01] <james_w> thank
[12:01] <james_w> s
[12:02] <pitti> james_w: in retrospect I should probably have voted "needs fixing", but I set it first before typing the comment
[12:05] <lool> Can usplash.conf have anything else than xres and yres?
[12:05] <lool> like verbose or something
[12:06] <lool> I think not but perhaps I'm wrong
[12:06]  * ogra thinks not either
[12:06] <Amaranth> verbose is a grub boot line thing
[12:06] <Amaranth> afaik usplash only has those two options
[12:07] <ogra> well, usplash has three more options beyond -x and -y
[12:07] <ogra> but i dont think it is able to read any of them from usplash.conf
[12:08] <ogra> (only -p and -c would be relevant at all even)
[12:08] <ogra> ah, no -v probably too :P
[12:10] <ogra> lool, the code in libusplash.c only reads x/y it seems
[12:34] <Keybuk> ion: they look ok to me
[12:34] <Keybuk> thanks for your hard work on that
[12:35] <Keybuk> I shall merge those in once I've finished the network testing :D
[12:35] <ion> np
[12:35] <ion> Aye :-)
[12:41] <sridhar> hii
[12:58] <cjwatson> soren: do the walrus/cluster/sc have to be running in order to register them, or is it better if they aren't?
[13:04] <ogra> cjwatson, what do we do about the binfmt/mono/chroot issue, do you agree its worth having a bug for it ? (probably even security flagged)
[13:07] <cjwatson> ogra: sure, seems like a kernel bug, though it would really be best to take it up with upstream
[13:07] <ogra> hmm
[13:09] <ogra> i still need to do a proof of concept first before i like to go upstream (set the interpreter in binfmt/cli to $chroot/$path_to_interpreter instead of /$path_to_interpreter to trigger teh right magic bit)
[13:12] <cjwatson> ogra: it won't work
[13:12] <cjwatson> the interpreter will look for files in the host system if you do that
[13:13] <pacopil> online boxing game http://www.kobox.org/kobox-fande-Nourine.html
[13:31] <lool> pitti: I see you were working on usplash changes; FYI I pushed some changes
[13:31] <lool> pitti: is this for A6?
[13:32] <pitti> lool: maybe, need to wait on some input from design team
[13:32] <pitti> lool: I don't mind it being uploaded now, though
[13:33] <lool> pitti: So your changes are uploadable?
[13:33] <pitti> lool: yes, they are
[13:33] <lool> Ok cool
[14:10] <ogra> cjwatson, https://bugs.launchpad.net/linux/+bug/427863 in case you are intrested (linked to the upstream report)
[14:11] <kirkland> pitti: did you get a chance to look at Bug #426724 ?
[14:11] <pitti> kirkland: still on my list; I reviewed the patch and left a comment there
[14:11] <pitti> kirkland: I'm way too busy today, I'm afraid, but I hope I can slip it in next week
[14:11] <kirkland> pitti: cool
[14:12] <kirkland> pitti: hmm, for some reason, LP didn't email your comments
[14:12] <bigon> https://edge.launchpad.net/ubuntu/+source/kvm O_o disapears from karmic?
[14:12] <kirkland> pitti: i'll drop the asprintf part, and resubmit
[14:13] <MacSlow> pitti, seb128: where's the gnome-session type (vanilla vs. stratiatella) selected (in which file)?
[14:13] <pitti> kirkland: right, that's the easy part; I need to do the same for ~/.dmrc (feel free to beat me to it, of course)
[14:13] <kirkland> pitti: i couldn't immeidately find that code ...
[14:14] <pitti> MacSlow: argh, I think stracciatella-session still needs porting to the new gdm as well
[14:14] <kirkland> pitti: the part that reads/writes dmrc.  .face was much more obvious
[14:14] <pitti> kirkland: hm, I don't know it off-hand either, I'm afraid (I'm not very familiar with the gdm code base yet)
[14:14] <pitti> MacSlow: but it should actually be pretty easy, it's just dropping a new file into /usr/share/xsessions/
[14:14] <kirkland> pitti: alrighty, i'll take another look while i'm fixing asprintf()
[14:14] <MacSlow> pitti, ah ok
[14:15] <MacSlow> thanks
[14:16] <cjwatson> bigon: qemu-kvm
[14:18] <bigon> cjwatson: oh right thx
[14:18] <bigon> :)
[14:20] <pitti> kirkland: cheers
[14:32] <kirkland> pitti: okay, i found the dmrc load and save code, that's pretty straightforward
[14:32] <pitti> kirkland: so if you can read ~/.dmrc, use that, otherwise fall back to ~/.ecryptfs/.dmrc?
[14:32] <kirkland> pitti: unfortunately, though, we don't have the user's name easily on hand at that point, only their home
[14:33] <kirkland> hmm, that should work
[14:33] <kirkland> pitti: thanks
[14:37] <cumulus007> Hi, how often are updates of ubuntu translations from launchpad distributed?
[14:38] <soren> cjwatson: Uh... I'm not sure to be honest.
[14:38] <dpm> cumulus007: for development releases, every few days, unless there is a freeze in between. For stable releases, approx. monthly. You might also want to check out the #ubuntu-translators channel if you're interested in Ubuntu translations
[14:39] <cumulus007> dpm: Thanks for the info :)
[15:14] <jdstrand> seb128: this may not be your area, it might be devicekit's, but nautilus shows under Places all my schroots that are under /dev/mapper. This is somewhat undesirable as I have 13 of them. Is this a known bug? is there a preference I can set somewhere?
[15:15] <seb128> jdstrand, it's probably a gvfs issue
[15:15] <seb128> can you open a bug with a gvfs-mount -li log and maybe a testcase?
[15:15] <jdstrand> ok
[15:42] <ogra> Keybuk, are there plans to pull insserv in ? seemingly debootstrap adds a dep on it ( NCommander told me )
[15:42] <cjwatson> (fwiw this is not something that is up to debootstrap, it's just the messenger)
[15:42] <soren> upstart depends on it as well, doesn't it? By way of sysvinit or something?
[15:43] <NCommander> soren, it looks like it's been living in universe though
[15:43] <soren> NCommander: It's a new dependency,presumably.
[15:44] <NCommander> soren, right. As it stands, modules-tools-init fails to configure since update-rc.d tries to use insserv, and boom, broken base system
[15:44] <cjwatson> sysv-rc Depends: insserv; perhaps a mismerge
[15:44] <soren> cjwatson: I'm not sure. Keybuk recently uploaded a new insserv, so it's definitely on his radar :)
[15:44] <NCommander> cjwatson, update-rc.d tries to call it :-/
[15:44] <cjwatson>   * debian/sysv-rc.postinst: Don't try and use insserv by default, though
[15:44] <cjwatson>     everything's in place for you to try if you like.  It can be activated
[15:44] <cjwatson>     with:
[15:44] <cjwatson>         USEINSSERV=yes dpkg-reconfigure sysv-rc
[15:45] <cjwatson> so I think the dependency and the attempt of update-rc.d to use it is a mistake
[15:45] <soren> Ah.
[15:45] <ogra> definately :)
[15:45] <cjwatson> I'm not going to touch it at the moment though, leave it to Scott :)
[15:46] <NCommander> :-)
[15:46] <cjwatson> since there's a sysvinit in the ubuntu-boot PPA
[15:55] <mneptok> cjwatson: do you know who is building Empathy packages for Karmic?
[15:56] <mneptok> Empathy was removed during a dist-upgrade >12h ago due to a shared lib problem. no sign of a rebuilt version based on the newer libs.
[15:57] <cjwatson> https://launchpad.net/ubuntu/+source/empathy says bigon was the last uploader
[15:57] <mneptok> k
[15:58] <mneptok> thanks. still working on the first cuppa, so LP is too much for my fingers just yet. :)
[16:04] <seb128> mneptok, what architecture do you use?
[16:04] <mneptok> seb128: amd64
[16:04] <mneptok> seb128: i had trouble finding a HPPA laptop
[16:04] <mneptok> :/
[16:04] <seb128> was probably an arch all any mismatch
[16:04] <ogra> use a sparc one
[16:05] <mneptok> ogra: i tried. Larry Ellison came in the night and stole it.
[16:05] <ogra> bah, bad guy
[16:08] <bigon> mneptok: some pkg are still stuck in new queue
[16:10] <bigon> seb128: did you had the time to let pass empathy trough the new queue?
[16:13] <mneptok> bigon: d'accord. j'attend.
[16:17] <Turl> fta: can you have a look at https://bugs.launchpad.net/ubuntu/+source/prism/+bug/246822 ?
[16:38] <seb128> bigon, mneptok: done now
[16:39] <kees> Keybuk: argh, sorry, I had already uploaded.  I only did it because it was causing me a lot of problems in my VMs (since all the signal handlers where broken, and doing dist-upgrades over ssh was tanking)
[16:39] <mneptok> seb128: thanks. waiting for it to trickle down, i guess. no updates to install here.
[16:39] <seb128> mneptok, right, you need to wait an hour for next publisher run
[16:41] <mneptok> seb128: you expect an American to *wait*?! ;)
[16:42]  * mneptok scrambles the bombers
[16:58] <jdstrand> cjwatson: I am either doing something wrong or mass-sync/backport.py is busted: http://paste.ubuntu.com/269246/
[16:58] <jdstrand> cjwatson: hi btw!
[16:58] <jdstrand> cjwatson: I tried with '-l production' too, but got the same error
[16:58] <cjwatson> err, blink, didn't see that when I last used it
[16:59]  * jdstrand scratches head
[17:00] <jdstrand> cjwatson: I did just get python upgraded on my machine...
[17:00] <cjwatson> jdstrand: who's the requestor of this particular bug? (LP id)
[17:00] <jdstrand> cjwatson: dobey
[17:00] <jdstrand> cjwatson: bug #397431
[17:01] <jdstrand> cjwatson: my backport.py invocation is in the paste
[17:02] <ScottK> slangasek had an interest in that one too.
[17:02] <cjwatson> it's not just backport.py anyway
[17:02] <cjwatson> >>> launchpad.people['dobey'].preferred_email_address
[17:02] <cjwatson> Traceback (most recent call last):
[17:02] <cjwatson> so it's either a launchpadlib (or deps) bug or an LP bug
[17:03] <jdstrand> yeah, hmm
[17:03] <jdstrand> I hate those
[17:03] <jdstrand> cjwatson: ok, thanks. I'll get this to the attention of the right people
[17:03] <cjwatson> ta
[17:04] <lool> doko: lp:~lool/glibc/eglibc-vfp-testsuite-updates
[17:04] <lool> doko: Could you please merge this when you upload ubuntu9?
[17:04] <lool> I created an ubuntu10 on top
[17:04] <lool> doko: Fixes testsuite failures on armel
[17:05] <lool> NCommander: ^
[17:07] <lool> Keybuk: Can you help with the insserv MIR?  LP #427709
[17:07] <lool> I can guess the rationale etc. but it's a bit weird that I document why it's needed myself and then tend to the review
[17:08] <ogra> you could as well just shove it in and write "because"
[17:18] <NCommander> doko, this is low priority, but I'll see if I can do something to help fix powerpc failures (I'm not sure if I'll have any free cycles in the near future to look at it :-/)
[17:35] <doko> lool: done
[17:39] <lool> doko: thanks!
[17:39] <lool> doko: Are you uploading this today BTW?
[17:39] <lool> doko: Or shall we revert the glib changes on armel
[17:39] <pitti> stgraber: sabayon was removed from Debian, with "ROM; almost completely broken"; should we follow suit? are you using it in edubuntu?
[17:39] <pitti> it doesn't have any rdepends
[17:39] <pitti> ./ubuntu.karmic/dvd: * sabayon            # desktop profile management
[17:39] <pitti> ./edubuntu.karmic/supported: * sabayon            # desktop profile management
[17:39] <pitti> that's it
[17:39] <pitti> seb128: ^
[17:40] <doko> lool: I'll upload, just finished testing on lpia
[17:43] <jdstrand> cjwatson: fyi, the backport.py issue is bug #319432
[17:43] <lool> doko: ok thanks!
[17:44] <cjwatson> thanks
[17:44] <cjwatson> mvo: do you have any idea what it is that causes all these "Package foo is already installed and configured" bug reports?
[17:49] <RainCT> seb128: Hey. I've got a question. The Zeitgeist binary package is currently called 'zeitgeist-core' but I think I'd better have it as just 'zeitgeist' now, any opinions on this? (basically what I'm wondering is whether a transitional package would be needed)
[17:49]  * pitti chuckles
[17:50] <seb128> RainCT, don't bother doing a transitional package no if was never in stable
[17:50] <pitti> Removing candidates:
[17:50] <pitti> ia32-libs-tools 14 in karmic
[17:50] <pitti> ment: (From Debian) RoThe Project; Most idiotic breakage ever
[17:50] <pitti> oops :/
[17:50]  * pitti wonders whether to remove it from karmic as well
[17:50] <pitti> cjwatson, slangasek: does that touch our multiarch efforts? ^
[17:50] <RainCT> seb128: Great, so I can just rename it with the next revision?
[17:51] <seb128> yes
[17:51] <cjwatson> ia32-libs-tools is the ia32-apt-get thing, isn't it? I didn't think that we'd changed our ia32-libs to use that (intentionally not)
[17:52] <RainCT> seb128: ok, thanks :)
[17:53] <cjwatson> jdstrand: you could always edit the script temporarily and hardcode an e-mail address :)
[17:53] <pitti> cjwatson: right
[17:54] <pitti> cjwatson: no, we didn't, we still have the usual mega-.deb with the .so files included
[17:54]  * pitti kills it, easy enough to revive
[17:55] <slangasek> pitti: doesn't affect us in the least
[17:59] <ulaas_> hi. what is the default theme for karmic gnome desktop?
[18:00] <ulaas_> still human?
[18:00] <slangasek> cjwatson: geser is reporting that a large number of the rebuild failures are false positives due to bug #412933; can we stop the rebuild run if it's ongoing, and do another one once that's fixed?
[18:00] <slangasek> (I'll look at fixing that in eglibc today)
[18:02] <cjwatson> slangasek: I'd be happy to stop it, but LP timeouts loading the relevant page at the moment
[18:03] <slangasek> heh, ok
[18:03] <slangasek> geser: ^^ :)
[18:04] <cjwatson> I don't get it though, eglibc is clearly trying to arrange for C++ strchr(const char *) -> const char * and strchr(char *) -> char *, and the prototypes look right for that. What's wrong with it?
[18:05] <cjwatson> obviously that makes no sense in C :-)
[18:08] <cjwatson> it appears to have been a change made for ISO C++ conformance
[18:11] <slangasek> oh, really?
[18:12] <jdstrand> cjwatson: is backport.py supposed to be able to handle backporting to a suite where the package doesn't already exist?
[18:12] <jdstrand> cjwatson: eg, foo is in karmic, but not in hardy. should backport.py be able to put foo in hardy-backports?
[18:12] <mvo> cjwatson: "foo already install and configured"> I think I have a fix in bzr
[18:12] <slangasek> cjwatson: do you have a reference handy?  (And if that's the reason, why is the eglibc code #if gcc_4_4'ed?)
[18:13] <jdstrand> cjwatson: it doesn't now, and I am deciding if I should error out more clearly or fix it so it works
[18:14] <cjwatson> jdstrand: it ought to just land in NEW; if it doesn't, that's a bug
[18:14] <jdstrand> cjwatson: ok, thanks
[18:14] <cjwatson> mvo: yay, I'd been wondering about that. Where, update-manager or elsewhere?
[18:14] <cjwatson> slangasek: no, I'm just inferring from the fact that the relevant prototypes are guarded by #ifdef __CORRECT_ISO_CPP_STRING_H_PROTO
[18:15] <cjwatson> slangasek: note that /usr/include/c++/4.4.1/cstring does stuff with that definition as well, so I infer that glibc and libstdc++ needed to cooperate on it, which is probably why it's specific to g++ 4.4
[18:15] <mvo> cjwatson: in apt itself, it seems to mis-interpret a dpkg state
[18:16] <slangasek> I think when I was looking at it before, I didn't even notice the difference in the argument type
[18:16] <geser> slangasek: might not be the best reference but http://www.cplusplus.com/reference/clibrary/cstring/strchr/ talks also about two declarations for strchr() in C++
[18:16] <slangasek> oops
[18:16] <cjwatson> mvo: oh, neat
[18:16] <slangasek> geser: right - sorry for steering you wrong
[18:17] <geser> slangasek: so I can continue fixing it?
[18:17] <doko> lool: I don't rush the upload now, I'm going to upload gcc-4.4 before the glibc build. will do that tomorrow, leaving now
[18:17] <slangasek> geser: yes
[18:17] <slangasek> geser: and I need to re-do a fix to kismet, reopen a bug, and apologize to quadrispro when I see him :)
[18:18] <geser> slangasek: and you could also sponsor bug #427791
[18:18] <cjwatson> right, so the problem in bayonne is that strchr(tone, '/') returns const char * - i.e. the warning is regarding the return value, not the first argument
[18:18] <cjwatson> or the error, rather
[18:19] <statik> hi doko, i'm having some problems with the latest python2.6 upload, bug #428004
[18:19] <slangasek> geser: ack
[18:19] <cjwatson> (it's being assigned to a char *)
[18:19] <slangasek> cjwatson: yes, now that I've been pointed at the real difference between the difference in the prototypes, I grok why it's a bug
[18:20] <statik> doko, i don't know enough about setuptools to fix it myself, but i think that bug report shows exactly what is failing
[18:20] <doko> statik: hmm, poolie did acknowledge that something like this was fixed with the recent upload
[18:20] <cjwatson> slangasek: *nod* just spelling it out since I'd gone to the effort of looking :-)
[18:20] <slangasek> geser: ack, will grab after I unblock some folks waiting on FFes
[18:20] <oussama> hello everybody
[18:20] <statik> doko, yes thats what is so interesting about it! building in place was working fine for my team until today/yesterday
[18:21] <doko> statik: will try to look at the weekend. I'm away now
[18:21] <cjwatson> (p.s. I *love* being able to do https://code.launchpad.net/ubuntu/+source/bayonne rather than having to download the whole source
[18:21] <cjwatson> )
[18:22] <lamont> bug 396700
[18:27] <cody-somerville> pitti, Does apport include the contents of the DCD file in bug reports?
[18:27] <geser> cjwatson: I hope you didn't manage to stop the rebuild
[18:34] <ScottK> statik: I can build C extenstions that don't use setuptools, FYI.
[18:34] <cjwatson> mvo: have lots of duplicates ;-)
[18:34] <lool> pitti: Pushing new glib2.0 without --enable-assert-messages on armel as doko indicated he will only upload eglibc tomorrow
[18:34] <cjwatson> geser: no
[18:34] <slangasek> wgrant: I don't suppose http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20090909.html has a way to incorporate successful archive builds from later versions of the package?  (i.e., auto-detect that the bugs have been fixed)
[18:37] <geser> slangasek: unless uploads to the main archive propagate also to this rebuild archive, a change in the script would be needed to check if there is newer version in the main archive than the rebuild archive and omit those packages
[18:38] <slangasek> geser: sure - that seems like an obviously beneficial change to make to the script, though :)
[18:42] <ogra> pitti, you guys discussed sabayon today ? i know sbalneav puts a lot of time into it but doesnt know much about packaging, it would be a shame to lose it
[18:43] <ogra> pitti, he does all his work upstream and provides ppa's with our packages including his patches, i know it works fine for many people from his ppa, he just needs someone to spnsor and do the packaging from the motu crowd
[18:43] <geser> can anyone advise me what would be the best fix for http://launchpadlibrarian.net/31643733/buildlog_ubuntu-karmic-i386.cmake_2.6.4-1ubuntu2_FAILEDTOBUILD.txt.gz? libxmlrpc-c3-dev got split into libxmlrpc-c3-dev and libxmlrpc-core-c3-dev to let libxmlrpc-core-c3-dev into main. cmake build-depends on libxmlrpc-core-c3-dev and the missing header is in libxmlrpc-c3-dev. The options are now to move the
[18:43] <geser> missing header to -core-c3-dev or merge the both -dev packages again as both are now in main (don't know why)
[18:43] <cjwatson> mvo: should we consider a stable update for that apt bug at some point, perhaps?
[18:47] <mvo> cjwatson: yeah, I think that is a good idea, lets see if its really fully fixed or if there are other corner cases too
[18:50] <jdstrand> cjwatson: fyi, updated backport.py to workaround the bug we discussed earlier and fixed synclib.py to handle NEW packages. backport.py and mass-sync both are working now
[18:50] <jdstrand> (commits 68 and 69)
[18:53] <cjwatson> jdstrand: thanks
[18:53] <mneptok> bigon: FYI, i needed to manually re-install Empathy once the libs were updated.
[18:56] <cjwatson> mvo: would you expect to see that bug on a package that does *not* have triggers itself?
[19:01] <cjwatson> mvo: I've found lots on packages shipping triggers, which are presumably the same thing - but also lots on packages that don't seem to have triggers of their own
[19:01] <cjwatson> mvo: I just searched for "already installed and configured" on https://bugs.launchpad.net/ubuntu
[19:02] <mvo> cjwatson: the bug for packages that are shipping triggers (like man-db) should be fixed with bug #414631 (in bzr)
[19:02] <mvo> cjwatson: the others will need extra analysis
[19:02] <cjwatson> ok, I won't dup those
[19:02]  * mvo looks at the output
[19:03] <mvo> uh, many
[19:04] <statik> ScottK: ah thanks for pointing that out about non-setuptools, I'll amend the bug summary
[19:04] <mvo> cjwatson: I can do that monday, sorry that I have not gotten around to that apt upload yet :(
[19:05] <cjwatson> no problem, thanks
[19:21] <lool> jdstrand: I dont get the changes in 427663??
[19:22] <jdstrand> lool: no, you wouldn't. the reporter was paulliu
[19:22] <jdstrand> lool: if you ack I'll process
[19:23] <jdstrand> lool: heh, that didn't come out quite right
[19:23] <jdstrand> lool: I was answering your question in the bug:
[19:23] <lool> jdstrand: oh sorry
[19:23] <jdstrand> Jamie, I'm core dev so I dont think I need universe-sponsors?
[19:24] <jdstrand> 13:22 < jdstrand> lool: no, you wouldn't. the reporter was paulliu
[19:24] <lool> jdstrand: I mixed it with my own syncs
[19:24]  * jdstrand didn't mean to come of snarky :)
[19:24] <lool> jdstrand: let me approve it hold on
[19:24] <jdstrand> off
[19:25] <lool> jdstrand: approved thanks
[19:25] <lool> jdstrand: and sorry
[19:25] <jdstrand> lool: sure! glad to help :)
[19:27] <paulliu> lool: thanks.
[19:50] <NCommander> Does anyone know how big the entire archive is ATM?
[19:52] <sebner> NCommander: ah good to see you, Did you get my mail a couple of days ago (about vtk) ?
[19:52] <NCommander> sebner, no
[19:52] <sebner> :(
[19:53] <sebner> NCommander: I wrote to<EMAIL_ADDRESS>[19:53] <NCommander> sebner, might have missed it (all the LP bug mail goes there)
[19:53] <NCommander> sebner, what was it?
[19:53] <RainCT> Uhm.. Somehow knows how I can get apport to catch crashes of unpackaged stuff?
[19:53] <NCommander> RainCT, package it :-)?
[19:54] <sistpoty> RainCT: use gdb :P
[19:54] <RainCT> NCommander: Heh. No, I want it for stuff under development
[19:54] <RainCT> sistpoty: Tried that, but gdb loves freezing my session when the app it's running crashes
[19:55] <sebner> NCommander: vtk ftbfs on armel, lpia and powerpc and at least there seems to exist a fix in debian bts for armel and I asked if you can take a look at it. (and maybe the other platforms (They ftbfs on another position))
[19:55] <sebner> huhi sistpoty =)
[19:55] <sistpoty> hi sebner
[19:55] <sistpoty> RainCT: oh, that doesn't sound healthy for gdb
[19:55] <sebner> sistpoty: debian websvn telle me: Prepare nexuiz 2.5.1! \o/
[19:56] <sebner> *tells
[19:56] <sistpoty> sebner: heh... must admit I've lost track a little bit of nexuiz
[19:56] <NCommander> sebner, looks like an EJAVAPROBLEM
[19:56] <RainCT> sistpoty: at least it's doing that for both gnome-shell and gnome-voice-control. Maybe it only happens with panel-related stuff :P
[19:56] <NCommander> sebner, got a debdiff? I'll sposnor it
[19:56] <NCommander> (after confirming a test build on armel or powerpc)
[19:56] <sebner> NCommander: nothing yet because I don't have an armel machine to test so I wrote you a mail ;)
[19:56] <sistpoty> RainCT: you could set a limit for coredumpsize (with limit) and look at the core dump?
[19:56] <sebner> sistpoty: no worries, the commit message is 1h old ^^
[19:57] <NCommander> sebner, hrm, odd
[19:57] <NCommander> sebner, it was marked as NEW, but I didn't see it in my inbox
[19:57] <sebner> NCommander: heh, no worries :)
[19:57] <sebner> NCommander: I make a debdiff and you testbuild it? deal?
[19:58] <NCommander> sebner, how big of a diff do we have from Debian?
[19:58] <NCommander> sebner, I rather just NMU in Debian and sync it
[19:59] <sebner> NCommander: aha! I just noticed that it seems debian fixed the issues
[19:59] <sebner> NCommander: will need a merge though
[20:00] <sebner> NCommander: dependency thing and python2.6
[20:00] <RainCT> sistpoty: uhm I've done "ulimit -c 1000000", now what?
[20:00] <NCommander> sebner, do that, I'll sponsor the change
[20:01] <sebner> NCommander: well, you can review if you want, I can sponsor myself ^^
[20:03] <NCommander> sebner, :-P
[20:03] <sebner> NCommander: you are just the "armel" guy :P
[20:04] <NCommander> and the powerpc, ia64, and sparc guy
[20:04]  * NCommander kicks debbugs
[20:04]  * sebner hugs NCommander :)
[20:06] <sistpoty> RainCT: yep, then you should get a coredump if you start it from a shell and it crashes. You can then inspect the coredump with gdb
[20:06] <sistpoty> RainCT: unless there's another limit that you also need to set, and which I constantly forget *g*
[20:07] <RainCT> sistpoty: ah, where is this file supposed to appear? didn't get anything in the cwd
[20:08] <sistpoty> RainCT: in cwd actually
[20:08] <geser> ulimit -c?
[20:09] <RainCT> 1000000
[20:09] <sistpoty> RainCT: works for me at least: zsh: segmentation fault (core dumped)  ./test.bin
[20:10] <sistpoty> RainCT: unless the program you try to debug has its own segfault handler
[20:12] <geser> sistpoty: what's your value for /proc/sys/kernel/core_pattern?
[20:12] <sistpoty> geser: core
[20:12] <geser> RainCT: and you?
[20:13] <sistpoty> (I don't have apport installed, maybe that makes a difference?)
[20:13] <RainCT> geser: |/usr/share/apport/apport %p %s %c
[20:13] <geser> set it to core
[20:13] <geser> see man 5 core
[20:14] <sistpoty> geser: nice, thanks for the info
[20:14] <geser> if you pipe it to a command it doesn't get written to disk
[20:15] <RainCT> maybe it just doesn't work with shell (it has a wrapper script and works as a plugin upon mutter or some weird stuff), I'll try it with gnome-voice-control but first I've got to eat something :P
[20:15] <RainCT> sistpoty, geser: thanks for your help :)
[20:16] <sistpoty> np ;)
[20:22] <sebner> NCommander: http://paste.ubuntu.com/269358/ <-- if you are fine with it I'll upload it after a testbuild
[20:29] <NCommander> sebner, uploading to my PPA
[20:32] <sebner> NCommander: I don't have any space left on / so pbuilder dies. Let's wait for your ppa ^^
[20:33] <NCommander> sebner, one of the joys of having a devirtualized PPA is that I can test it on all architectures at once
[20:34] <sebner> NCommander: that's why you are the guy whom I wrote a mail :P
[20:34] <NCommander> sebner, ;-)
[20:37] <ScottK> NCommander: Would you please rescore r-cran-timedate?  I'm very curious to know if my sparc hack worked or not.
[20:38] <NCommander> ScottK, https://edge.launchpad.net/ubuntu/+source/r-cran-timedate/290.85-1ubuntu1/+build/1238939
[20:39] <ScottK> NCommander: That should be enough.  Thanks.
[20:39] <ScottK> BTW, edge doesn't show the build score anymore.  Someone should complain about that
[20:39] <NCommander> ScottK, I see it
[20:39] <NCommander>     *   Start in 1 minute (7098709) Rescore build
[20:39]  * ScottK looks again
[20:39] <dutchie> is this the right place to poke my branch getting merged?
[20:40] <ScottK> Urgh.  Started already
[20:40] <NCommander> ScottK, if it still fails, I'll have to look at it manually; my SPARC box crashed while updating upstart
[20:40] <NCommander> the upshot is it doesn't boot anymore
[20:41] <soren> dutchie: Depends on what it's a branch of.
[20:42] <dutchie> update-manager
[20:43] <ScottK> NCommander: If you want to work on sparc, figure out why xvfb segfaults (see the previous revision's build log)
[20:43] <soren> mvo: ^^ That's your cue :)
[20:43] <NCommander> ScottK, sparc a miserable pile of fail ATM sadly
[20:43] <NCommander> ScottK, I'm trying to work out why silo is crying in the corner
[20:43] <dutchie> https://code.edge.launchpad.net/~jshholland/update-manager/string-fixes
[20:43] <ScottK> That's definitely I higher priority
[20:44] <ScottK> I/A
[22:00] <mvo> dutchie: I'm having a look at the branch now
[22:16] <mvo> dutchie: could you mail the translators too that some strings change due to this? Or maybe manual unfuzzing in the po files is enough, it seems that not many user affect strings are affected (just ~3?)
[22:20] <dutchie> mvo: is that a translator's team?
[22:21] <mvo> dutchie: there is a mailing list, give me a sec
[22:21] <mvo> dutchie: https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
[22:22] <mvo> dutchie: that is the mailing list - I upload the new pot to rosetta now
[22:22] <mvo> dutchie: thanks very much for the branch, its merged now
[22:22] <dutchie> \o/
[22:23] <dutchie> i think that's my first contribution to a FOSS project that's been merged
[22:23] <mvo> *woooohhh*
[22:23]  * mvo hugs dutchie
[22:43] <wgrant> slangasek: That's on my todo-list after I finish exams and stuff in a few hours.
[22:43] <slangasek> wgrant: cheers :)
[22:57] <simon-o> cody-somerville: bug 428104: I don't know why --without-ssl was in debian/rules and why it worked before
[22:58] <cody-somerville> simon-o, I noticed that as well. autotools bug or something maybe
[23:01] <zegusty> Does anyone know the driver level keyboard buffer size?
[23:07] <cody-somerville> simon-o, ah, I see why
[23:07] <cody-somerville> simon-o, new version of gnutls no longer ship libgnutls-extra-config
[23:08] <cody-somerville> however, lftp doesn't FTBFS it just happily continues with ssl support dropped.
[23:09] <simon-o> cody-somerville: ok, I see. but the --without-ssl is still nonsense. It should be --without-openssl
[23:09]  * cody-somerville nods.
[23:09] <cody-somerville> simon-o, just about to say that :)
[23:16] <simon-o> cody-somerville: I don't see where libgnutls-extra-config is used. Just libgnutls-config (which was also dropped)
[23:17] <cody-somerville> simon-o, sorry, I meant to say libgnutls-extra-config and libgnutls-config
[23:17] <cody-somerville> Just libgnutls-config is used
[23:17] <cody-somerville> I have a patch but I'm having trouble running autoreconf
[23:26] <simon-o> cody-somerville: ftp://ftp.yar.ru/lftp/devel/lftp-3.99.14.tar.gz You can also check that package, it uses pkg-config to check for gnutls
[23:26] <simon-o> let me know if I can help out
[23:27]  * cody-somerville nods.
[23:27] <cody-somerville> Thats how I'm doing it.
[23:28] <cody-somerville> running autoreconf on that results in the same errors so I think there is a bug in autotools or something
[23:29] <cody-somerville> I'll have to patch configure its self I guess
[23:31] <sistpoty> cody-somerville: can you pastebin the errors (for my experience, usually it's not autotools that produce the error, but rather broken Makefile.am's or configure.ac's)


[15:30] <beisner> o/
[15:35] <beisner> oh, i'm 30 minutes early.
[15:35]  * beisner goes back to work
[15:58] <kickinz1> o/
[15:59] <beisner> o/   hey kick!
[15:59] <matsubara> o/
[16:00] <smoser> o/
[16:00] <rbasak> #startmeeting ubuntu-server-team
[16:00] <meetingology> Meeting started Tue Mar 24 16:00:06 2015 UTC.  The chair is rbasak. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[16:00] <meetingology> Available commands: action commands idea info link nick
[16:00] <rbasak> #topic Review ACTION points from previous meeting
[16:00] <rbasak> everyone look at server guide and look for areas which need updating
[16:00] <gaughen> 0/
[16:00] <strikov> 0/
[16:01] <rbasak> I'm not sure what further action to take here, apart from reminding everyone to do this.
[16:01] <rbasak> hallyn to talk with dannf about bug 1427406
[16:01] <gnuoy> o/
[16:01] <rbasak> This one has been assigned to me, but I don't really have any action to take unless someone can present a patch.
[16:01] <zul> hi
[16:02] <rbasak> If it's MySQL upstream related, then trying ryeng on #debian-mysql on OFTC may be helpful.
[16:02] <hallyn> dannf: says he can look at it in a few days (i believe)
[16:02] <hallyn> otherwise i can try to look deeper next week.  but i'm really out o fmy element there
[16:02] <dannf> hallyn, rbasak - yes, which will likely start with me asking upstream
[16:02] <rbasak> OK. I'll unassign for now.
[16:03] <rbasak> hallyn to look at bug 1432715
[16:03] <hallyn> it's present in debian as well
[16:04] <hallyn> the debian bug hopes to post a fix over the weekend
[16:04] <gnuoy> o/
[16:04] <hallyn> (of course that was last weekend)
[16:05] <rbasak> hallyn to update QA Team section assignee to matsubara
[16:05] <hallyn> done
[16:05] <rbasak> matsubara to file a bug for libpam-systemd's dependency problem
[16:05] <jamespage> o/
[16:05] <jamespage> late as usual - sorry
[16:05] <matsubara> rbasak, I filed bug 1433190 but that's been invalidated
[16:06] <matsubara> rbasak, and the smoke tests are not failing anymore with that error
[16:06] <rbasak> matsubara: OK, it should be safe to leave it then? Thanks.
[16:06] <matsubara> they are failing for other reasons now which I'll raise in the QA section
[16:06] <matsubara> yep, I think so
[16:06] <rbasak> OK
[16:06] <rbasak> #topic Vivid Development
[16:06] <rbasak> #link https://wiki.ubuntu.com/VividVervet/ReleaseSchedule
[16:06] <rbasak> #subtopic Release Bugs
[16:06] <rbasak> #link http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-v-tracking-bug-tasks.html#ubuntu-server
[16:07] <rbasak> Anything in that list that needs discussion?
[16:08] <rbasak> #subtopic Blueprints
[16:08] <rbasak> #link http://status.ubuntu.com/ubuntu-v/group/topic-v-server.html
[16:08] <rbasak> #link https://blueprints.launchpad.net/ubuntu/+spec/topic-v-server
[16:08] <rbasak> Any blueprints that need discussion?
[16:09] <rbasak> caribou is out this week, so we'll skip the Server and Cloud Bugs topic unless anyone else wants to step up?
[16:09] <rbasak> #topic Weekly Updates & Questions for the QA Team (matsubara)
[16:09] <matsubara> rbasak, some smoke tests are failing due to a UTAH time out
[16:10] <matsubara> for example http://d-jenkins.ubuntu-ci:8080/job/vivid-server-amd64-smoke-dns-server/113/console
[16:10] <matsubara> in general the test pass, so I think this is due to failure to reach the archive (scroll up in that console log)
[16:10] <rbasak> #link https://jenkins.qa.ubuntu.com/job/vivid-server-amd64-smoke-dns-server/113/console
[16:11] <matsubara> not sure if there's an action here other than keeping looking at the logs and see if any of those are real failures
[16:11] <rbasak> matsubara: can you request a retest?
[16:12] <matsubara> I don't seem to have that permission
[16:12] <rbasak> It certainly does look like a test environment connectivity issue to me.
[16:12] <rbasak> matsubara: shall we leave it to you to get a message to the right person to request a retest?
[16:12] <rbasak> Let's move on for now.
[16:12] <rbasak> #topic Weekly Updates & Questions for the Kernel Team (smb, sforshee, arges)
[16:12] <matsubara> rbasak, ok
[16:12] <matsubara> thanks rbasak
[16:12] <smb> The Utopic+ nested issues on Precise host fix should be on its way into Precise. Beside that any other reports are still ongoing. There were recent updates to nested kvm softlockups (bug 1413540) and some container netdevice cleanup (bug 1403152) bug which we still need to evaluate. The KSM issue (bug 1435363) which was recently reported needs feedback on latest kernel.
[16:13] <rbasak> Thanks. Any questions for smb?
[16:13] <rbasak> Any other discussion on this topic?
[16:14] <rbasak> #topic Ubuntu Server Team Events
[16:14] <rbasak> I'm not aware of anything coming up. Does anyone have any events to add?
[16:14] <rbasak> #topic Open Discussion
[16:14] <rbasak> Anything else from anyone before we close?
[16:15] <rbasak> #topic Announce next meeting date and time
[16:15] <rbasak> The next meeting will be at Tue Mar 31 16:00:00 UTC 2015. matsubara will be chairing.
[16:16] <rbasak> Thanks all!
[16:16] <rbasak> #endmeeting
[16:16] <meetingology> Meeting ended Tue Mar 24 16:16:04 2015 UTC.
[16:16] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting/2015/ubuntu-meeting.2015-03-24-16.00.moin.txt
[16:16] <matsubara> thanks rbasak
[16:16] <beisner> thanks, rbasak
[16:18] <kickinz1> thanks
[16:30] <hallyn> j/wc
[17:00] <jsalisbury> ##
[17:00] <jsalisbury> ##
[17:00] <jsalisbury> [LINK] https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Vivid
[17:00] <meetingology> Meeting started Tue Mar 24 17:00:14 2015 UTC.  The chair is jsalisbury. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[17:00] <meetingology> Available commands: action commands idea info link nick
[17:00] <cking> o/
[17:00] <apw> o/
[17:00] <henrix> o/
[17:00] <kamal> o/
[17:00] <bjf> o/
[17:00] <ppisati> o/
[17:00] <smb> o/
[17:00] <jsalisbury> [TOPIC] Release Metrics and Incoming Bugs (jsalisbury)
[17:00] <sforshee> o/
[17:01] <jsalisbury> Release metrics and incoming bug data can be reviewed at the following link:
[17:01] <jsalisbury> [LINK] http://people.canonical.com/~kernel/reports/kt-meeting.txt
[17:01] <jsalisbury> ..
[17:01] <jsalisbury> [TOPIC] Status: Vivid Development Kernel (ogasawara)
[17:01] <ogasawara> Our Vivid kernel has been rebased to v3.19.2 and uploaded, ie
[17:01] <ogasawara> 3.19.0-10.10.  We are approaching kernel freeze for Vivid.  It is
[17:01] <ogasawara> ~2 weeks away on Thurs Apr 9.  If you have any patches which need to
[17:01] <ogasawara> land for 15.04's release, please make sure to submit those asap.
[17:01] <ogasawara> -----
[17:01] <ogasawara> Important upcoming dates:
[17:01] <ogasawara> [LINK] https://wiki.ubuntu.com/VividVervet/ReleaseSchedule
[17:01] <ogasawara> Thurs Mar 26 - Final Beta (~2 days away)
[17:01] <ogasawara> Thurs Apr 09 - Kernel Freeze (~2 weeks away)
[17:01] <ogasawara> Thurs Apr 23 - 15.04 Release (~4 weeks away)
[17:01] <ogasawara> ..
[17:01] <jsalisbury> [TOPIC] Status: CVE's
[17:02] <jsalisbury> The current CVE status can be reviewed at the following link:
[17:02] <jsalisbury> http://people.canonical.com/~kernel/cve/pkg/ALL-linux.html
[17:02] <jsalisbury> ..
[17:02] <jsalisbury> [TOPIC] Status: Stable, Security, and Bugfix Kernel Updates - Utopic/Trusty/Precise/Lucid (bjf/henrix/kamal/arges)
[17:02] <bjf> Status for the main kernels, until today:
[17:02] <bjf>   *   Lucid - None (no update)
[17:02] <bjf>   * Precise - Prep
[17:02] <bjf>   *  Trusty - Prep
[17:02] <bjf>   *  Utopic - Prep
[17:02] <bjf>
[17:02] <bjf> Current opened tracking bugs details:
[17:02] <bjf>   * http://kernel.ubuntu.com/sru/kernel-sru-workflow.html
[17:02] <bjf> For SRUs, SRU report is a good source of information:
[17:02] <bjf>   * http://kernel.ubuntu.com/sru/sru-report.html
[17:02] <bjf>
[17:02] <bjf>
[17:02] <bjf> Schedule:
[17:02] <bjf>
[17:02] <bjf> Current cycle: 20-Mar through 11-Apr
[17:02] <bjf> [17:02] <bjf>          20-Mar   Last day for kernel commits for this cycle
[17:02] <bjf> 22-Mar - 28-Mar   Kernel prep week.
[17:02] <bjf> 29-Mar - 11-Apr   Bug verification; Regression testing; Release
[17:02] <bjf> ..
[17:02] <jsalisbury> [TOPIC] Review of sforshee upload rights
[17:02] <apw> sforshee, hi
[17:03] <sforshee> apw: hello
[17:03] <apw> could you introduce yourself, perhaps tell us a little about yourself
[17:03] <kamal> *cough*
[17:03] <apw> (for the record)
[17:03] <sforshee> I've been a member of the kernel team for 4 years now
[17:04] <sforshee> working on various and sundry things, including some packaging of kernels and related packages
[17:04] <sforshee> https://wiki.ubuntu.com/SethForshee/PerPackageUploaderApplication
[17:04] <sforshee> I'm looking to get PPU rights to the linux-* packages to ease the work I've been doing
[17:05] <apw> i believe we have most of your sponsors here today, so if anyone wants to comment now is the time
[17:06] <apw> otherwise i think the majority of the approvers have works with you over the last few months
[17:07] <kamal> I stand by my sponsorship statment:  Seth is diligent and careful:  all good for linux-* ppu upload rights :-)
[17:07] <kamal> ..
[17:07] <ogasawara> I have not specifically sponsored a package of seth's but I've seen the work he's been doing (turning the crank on stable trees, handling linux-firmware, etc.).  He's being doing a great job..consistent, methodical, careful.  I'm +1.
[17:07] <ogasawara> ..
[17:08] <kamal> +1 from me
[17:08] <henrix> +1 from me too!
[17:08] <arges> From an SRU perspective, sforshee has generally shown attention to detail. The debdiffs I've reviewed have been free of cruft and look good. +1
[17:08]  * smb would +1 as well despite being no sponsor either
[17:08]  * apw has worked with him on a number of packages and feel he has the appropriate level of fear and self doubt: +1
[17:08] <bjf> +1
[17:08] <cking> +1
[17:09]  * apw counts ... that appears to be +1 from all present approvers and a slew of additional approvals
[17:09] <apw> sforshee, welcome to the team
[17:09] <sforshee> thanks all!
[17:09] <cking> \o/
[17:09] <henrix> \o/
[17:09] <apw> thank you ...
[17:09] <kamal> \o/
[17:09] <ogasawara> congrats sforshee!
[17:09] <arges> good job
[17:09] <apw> jsalisbury, all yours ...
[17:09] <jsalisbury> apw, thanks.  and congrats to sforshee
[17:10] <jsalisbury> [TOPIC] Open Discussion or Questions? Raise your hand to be recognized (o/)
[17:10] <jsalisbury> Thanks everyone
[17:10] <jsalisbury> #endmeeting
[17:10] <meetingology> Meeting ended Tue Mar 24 17:10:33 2015 UTC.
[17:10] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting/2015/ubuntu-meeting.2015-03-24-17.00.moin.txt
[17:10] <kamal> thanks jsalisbury!


[02:41] <Kamping_Kaiser>  /topic's answerd the question. thanks :)
[02:41] <ion_> What? Someone reads topics?


[00:17] <mdeslaur> twb: oem-install
[00:18] <twb> Thanks.  Is that still "a thing", and/or what's the current equivalent?
[00:19] <twb> This is definitely what I remember: https://help.ubuntu.com/community/Ubuntu_OEM_Installer_Overview
[00:19] <mdeslaur> hrm, yeah, that's what I was thinking of
[00:20] <mdeslaur> I think it's still there in the old installer, not sure about the new one
[00:20] <twb> That page says "illustration from 22.04" but the last screenshot clearly says 12.10
[00:21] <twb> The context of this is someone who is used to Debian d-i + preseed, and is cranky that "can you do Ubuntu as well?" is not just "sure just pass the preseed to Ubuntu's d-i"
[00:21] <mdeslaur> preseeding works
[00:22] <twb> I thought Ubuntu didn't support d-i at all anymore?
[00:22] <mdeslaur> the old installer supports preseeding, the new installer supports cloud-init autoinstall https://ubuntu.com/server/docs/install/autoinstall
[00:23] <twb> Ah I thought the old one was completely gone
[00:23] <twb> Let me see if I can find the current LTS equivalent of https://deb.debian.org/debian/dists/stable/main/installer-amd64/current/images/netboot/gtk/mini.iso ...
[00:25] <mdeslaur> hrm, not sure if jammy still has the old installer still
[00:25] <twb> Haha http://archive.ubuntu.com/ubuntu/dists/jammy/main/installer-amd64/current/ redirecs to "Try the New Ubuntu Server Installer"
[00:25] <twb> That is roughly what I thought
[00:27] <mdeslaur> yeah, so cloud-init autoinstall would be want you want for jammy


[04:50] <brobostigon> morning boys and girls.
[05:09] <zmoylan-pi> o/
[05:15] <brobostigon> \o
[05:28] <brobostigon> it works, my handywork, "talk to taylorworld star trek trivia" :)
[14:32] <daftykins> just contacted these jokers to suggest they stop storing passwords in plain text - https://www.charitydigitalexchange.org/


[00:41] <Unit193> bluesabre: Will you folks stop doing releases?!  We just opened the cycle and I've already got 12 packages to update! /s
[00:41] <Unit193> (I'd say "good job, keep it up" but releases for the sake of releasing isn't needed.  But great work so far!)
[11:58]  * guiverc thanks you all (esp. Gaël Bonithon as I just noted a requested feature is there!)
[12:18] <bluesabre> Unit193: maybe it's time to build a release bot to package automatically... what could possibly go wrong? >.>
[12:19] <bluesabre> jphilipz: while we did switch to ayatana indicators, we don't ship any of them by default
[12:20] <jphilipz> bluesabre: thanks
[12:22] <bluesabre> I updated all of our release-specific branches and tagged hirsute/impish where needed. I'm doing some other repo maintenance as well, but should have a 21.10 github project up sometime this weekend.
[12:24] <bluesabre> I wonder how the team feels about GitHub discussions? https://docs.github.com/en/discussions


[10:42] <fadZzZ> hi, im using linux 13, i'm trying to open a folder in terminal but I can't find the "open in terminal" option in the right click menu.....help plz..


[00:39] <pleia2> Welcome to the Ubuntu Weekly Newsletter, Issue 384 for the week September 15 - 21, 2014 https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Issue384


[00:56] <broder> Laney (and other backporters): can you think of common stock responses you have to write up on backport requests? so far i've got "this package isn't in ubuntu", "this version isn't in ubuntu", and "backports aren't srus". any others?
[01:35] <micahg> broder: uploaded to PPA foo, please install and run
[01:36] <broder> ah yes, of course :)
[01:57] <iamfuzz> lifeless, oh sorry, was referring back to installing launchpad locally
[01:58] <iamfuzz> lifeless, does the ability to create private PPAs in the soyuz implementation exist there?
[02:10] <blair> suggestions on which debian IRC channel to discuss a non-responsive debian package maintainer?  i've put together a patch for review.  looking to get them to update a package so it can be synced into precise
[02:10] <lifeless> iamfuzz: we deploy the same code we develop
[02:10] <lifeless> iamfuzz: no changes
[02:11] <iamfuzz> very nice
[03:39] <Resistance> since i got no answers from #launchpad...
 do recipe builds and what not get a lower build / ppa-build priority?
 the same source package uploaded by hand myself gets a sooner build time than the recipe build on lp
[03:39] <Resistance> in case someone here knows
[04:09] <micahg> Resistance: makes sense that automatic builds are after manual ones
[07:51] <dholbach> good morning
[09:25] <Laney> broder: blah blah upgrade path
[15:18] <l3on> Hey guys... do you suggest to add NO_PKG_MANGLE=1 in Makefile or in debian/rules ?
[15:19] <l3on> the first choice means I have to create a patch... the second one should be a inline editing... what do you suggest ?
[15:19] <l3on> (package I'm merging is cdebootstrap)
[15:19] <l3on> -	dpkg-deb --build temp-$(PACKAGE) $(PACKAGE).deb
[15:19] <l3on> +	NO_PKG_MANGLE=1 dpkg-deb --build temp-$(PACKAGE) $(PACKAGE).deb
[15:20] <l3on> that's the change at Makefile
[15:20] <geser> how is it currently done?
[15:21] <l3on> changing Makefile
[15:22] <l3on> that → helper/Makefile.{in,am}
[15:25] <l3on> anyway... this package has '3.0 (native)' format...
[15:25] <l3on> What's the best way to apply patches ?
[15:25] <l3on> I mean.. if I switch format to 'quilt' I need .orig.tar.gz
[15:26] <l3on> that's not provided by debian :/
[16:29] <Laney> l3on: I suggest you read up on what a native package is :-)
[16:30] <Laney> specifically that applying patches is not quite the same thing when the package is native
[16:33] <l3on> Laney, I read.. but I'm not sure to understand how to apply patches :).. so, I switched to online changes ...
[17:09] <and`> didrocks: any reason for keeping libbamf outside Debian?
[17:12] <didrocks> and`: not outside that Debian didn't need it until now
[17:13] <and`> didrocks: I maintain the gnome-pie package and while looking at its new upstream release today, I noticed it requiring libbamf :)
[17:13] <didrocks> oh, interesting :)
[17:13] <didrocks> so please, feel free to push it to debian
[17:14] <and`> do you want to maintain it there as well?
[17:15] <and`> if yes, I can sponsor the upload for you if you want.
[17:16] <and`> didrocks: ^^
[17:18] <didrocks> and`: I would be happy to do that, I can't though affirm that I can give the same QA level on debian
[17:19] <and`> didrocks: I can help you if needed, i.e forwarding stuff etc. but keeping the package in sync would be a nice thing
[17:19] <and`> didrocks: drop me a mail with a dgettable dsc and I'll push it either today or tomorrow, is that OK for you?
[17:20] <didrocks> and`: can we plan that on Monday? I'm about to leave and will be off for a FLOSS event this week-end
[17:21] <and`> didrocks: sure, but if there are no big deltas (apart changelog, maintainer stuff etc.), I can grab Ubuntu's package myself and upload it to Debian
[17:22] <didrocks> and`: you should be able to grab the current version in ubuntu and be fine with it
[17:22] <didrocks> and`: 0.2.104-0ubuntu1
[17:22] <didrocks> so I guess 0.2.104-1 and I can sync back in ubuntu
[17:23] <and`> didrocks: awesome, will add you as main maintainer.
[17:24] <didrocks> thanks and` :)
[17:24] <and`> yw!
[17:58] <CarlFK> is there a guid for getting source, fixing bug, uploading to my PPA, testing, and submitting the patch on my ppa?
[17:59] <CarlFK> I have submitted patches and put stuff on my PPA, wondering if there is a smooth way to do them both
[21:55] <achiang> barry: ping, do you know how to steer setup.py to install python modules in /usr/share/appname/xxx instead of dist-packages dir?
[21:56] <barry> achiang: is this for a package using dh_python2?
[21:57] <achiang> barry: yeah
[21:57] <barry> achiang: do a man dh_python2 and search for "private dirs"
[21:58] <achiang> barry: the package wants to install some private modules, and per policy, they should go into  /usr/share/module
[21:58] <barry> achiang: yep, dh_python2 supports that
[21:58] <achiang> barry: hm, so i'm talking with my upstream and they want to make setup.py do it, so this works on fedora too
[22:00] <barry> achiang: hmm, okay.  try this: `python setup.py install --help`.  there are a number of options available to control where stuff gets installed, so upstream will have to poke through those and figure out what works best for them
[22:01] <achiang> barry: ok, will pass on, thanks
[22:01] <barry> achiang: np. hth.
[23:12] <iamfuzz> lifeless, got LP up and running locally \o/
[23:12] <iamfuzz> lifeless, how does one go about adding userS?
[23:13] <iamfuzz> lifeless, when I acess Login/Register, it only gives me the option to login
[23:13] <StevenK> iamfuzz: utilites/make-lp-user <name>
[23:13] <Laney><EMAIL_ADDRESS>/ test
[23:13] <lifeless> there are some scripts in bin/ and utilities/
[23:13] <Laney> is the default, but ^
[23:13] <iamfuzz> many thanks
[23:14]  * iamfuzz wonders why canonical doesn't offer installation and setup of this as a paid service like LDS
[23:14] <StevenK> Because we'd prefer you use launchpad.net
[23:14] <StevenK> But we understand that isn't possible all the time
[23:15] <iamfuzz> we likely would, other than the bandwidth issues as a result of a hosted service
[23:15] <Laney> I tried to get soyuz working but it bob the builder had some phantom mozilla build going on so it never got any build jobs
[23:15] <Laney> how do I kill that?
[23:15] <StevenK> Laney: Hack the DB
[23:15] <iamfuzz> Laney, lmk how it works out - thats my next step too :-)
[23:16] <Laney> hmm
[23:17]  * StevenK tries to remember the runes
[23:17] <Laney> no worries, I don't have it up atm :-)
[23:17] <lifeless> actually thats not why we don't do an LDS like thing
[23:17] <StevenK> Either way lib/lp/buildmaster/enums.py has the magical values
[23:18] <StevenK> Laney: So you have a build in status 0 (NEEDSBUILD), you want to update the DB so that they are all 2 (FAILEDTOBUILD)
[23:18] <Laney> i think it is currently building actually
[23:18] <StevenK> Then 6 to 2
[23:19] <Laney> but I get the idea
[23:19] <Laney> thank you :>
[23:19] <StevenK> Laney: #launchpad-dev on this network. We'd be delighted to answer any questions you have.
[23:19] <StevenK> iamfuzz: ^
[23:19] <Laney> am there, idling
[23:19] <Laney> will surely have questions when i come to actually do something
[23:22] <iamfuzz> Laney, you have any problems importing your gpg key?
[23:22] <Laney> nope
[23:22] <Laney> i think you have to make sure gpg knows about it
[23:23] <Laney> on the host, for that script
[23:24] <lifeless> the idea of on-site launchpads was mooted way back at the london exhibition hotel LP sprint
[23:24] <lifeless> never seemed to get the resourcing needed, and doing it from the existing dev team would slow down features
[23:28] <ajmitch> Laney: you're making progress now? :)
[23:29] <Laney> too tired to boot the vm and check
[23:29] <Laney> should have done it in an lxc
[23:32] <lifeless> lxc++
[23:33] <ajmitch> better than messing up your live system
[23:34] <iamfuzz> where are the logs stored?  I can't get it to import my key for the life of me
[23:55] <iamfuzz> lifeless, StevenK I apparently have something with my bazaar alias screwed up.  When I click on the logout button, it takes me to the "Lost something?" page with broken images
[23:55] <iamfuzz> and when trying to import a key, I get this fun: 2011-11-17 15:33:21-0800 [HTTPChannel,4,<IP_ADDRESS>] <IP_ADDRESS> - - [17/Nov/2011:23:33:20 +0000] "GET /pks/lookup?search=0xD69FC46438D3A33619E5577D39BE3335F26A3797&op=get HTTP/1.1" 500 145 "-" "Python-urllib/2.6"
[23:55] <iamfuzz> any ideas?
[23:56] <StevenK> iamfuzz: Does the URL start with bazaar.launchpad.dev?
[23:57] <iamfuzz> StevenK, yes
[23:57] <iamfuzz> StevenK, https://bazaar.launchpad.dev/+logout?next_to=https%3A%2F%2Ftestopenid.dev%2F%2Blogout
[23:57] <StevenK> iamfuzz: It's LP attempting to log you out of loggerhead too, you'll hit it if you use make run, rather than make run_codehosting
[23:57] <StevenK> iamfuzz: It's ignorable
[23:58] <iamfuzz> StevenK, ah, thought it might be related to my key import issue as well


[18:27] <sdhd-sascha> hello, are the any repos for  "ubuntu-18.04.3-preinstalled-server" for raspberry pi ?
[18:27] <sdhd-sascha> there ?
[19:41] <RoyK> sdhd-sascha: try #raspberrypi
[19:49] <sdhd-sascha> RoyK: well, i found this blog post from ubuntu. With 19.10 there should be a offical ubuntu support for raspberry pi 4. Now i wonder where the source for this project is ?  ... https://ubuntu.com/blog/roadmap-for-official-support-for-the-raspberry-pi-4
[19:53] <RoyK> sdhd-sascha: I'd use 19.10 https://ubuntu.com/download/iot/raspberry-pi
[19:55] <sdhd-sascha> RoyK: thank you. I will have a look. I hope this image is able to boot over network. Currently i have booted Debian-Buster over network with pi4
[19:55] <RoyK> sdhd-sascha: probably better to flash an sd card
[20:00] <sdhd-sascha> RoyK: oh, i already tried this image ... well, then i need to compile u-boot and/or the kernel myself. I also asked at @raspberrypi for the offical source repo... thank you
[20:09] <RoyK> sdhd-sascha: it's in the sources repos
[20:10] <sdhd-sascha> RoyK: awkward ;-) you are right ;-D
[20:23] <RoyK> sdhd-sascha: good luck :)
[21:39] <lopta> Does the installer help if I want to install onto a mirrored pair of SATA disks?
[21:39] <lopta> (md, not ZFS)
[21:41] <tomreyn> should. if you want it more customized, use the alternative installer. if you want it even more customized, use debootstrap.
[21:41] <tomreyn> i'm referring to ubuntu server 18.04.3+
[21:43]  * lopta checks his iso directory
[21:43] <lopta> Is 19.10 out yet?
[21:43] <tomreyn> which year and month is it?
[21:43] <lopta> November 2019
[21:44] <tomreyn> so the year 2019, month 11, hmm
[21:44]  * lopta interprets that as a "yes"
[21:44] <tomreyn> well done!
[21:47] <lopta> Sounds as though you chaps stick fairly rigidly to your release schedule.
[21:49] <lopta> Do I need a text installer to install onto a mirror or is the server installer always text?
[21:50] <tomreyn> lopta: it's always text. and it can create the mirror for you (in fact i think it will want to)
[21:51] <lopta> Thanks, that sounds great.
[21:53] <RoyK> lopta: the "alternate" installer should do fine here - that's the old one. the new one sucks outright
[21:53] <lopta> RoyK: That's handy to know!
[21:54] <RoyK> no idea why they made it - it's flashy, looks good, blablabla, but it stops there
[21:55] <lopta> Is that on a separate .iso?
[21:55] <RoyK> lopta: if I were you, I'd use LVM on top of md as well, but then, people sometimes disagree there
[21:55] <lopta> Ah, found it.
[21:56] <RoyK> goodie
[21:57] <mwhudson> RoyK: do you have specific complaints about the new installer?
[21:58] <RoyK> I just realised it must be right about now it's 25 years since I installed Linux for the first time :D
[21:58] <lopta> I'm an old fart, if that helps.
[21:58] <lopta> ...first installed Linux for a friend from a stack of 5.25" 1200K floppies.
[21:59] <RoyK> mwhudson: I had when I first tried it, and when I tried the v1.1, and then I didn't care, since either I used the alternate installer or just debian
[21:59] <mwhudson> RoyK: ok, well it is hopefully better now
[21:59] <RoyK> mwhudson: I hope so
[21:59] <mwhudson> hmm 21 years since my first install i think
[21:59] <mwhudson> rh5
[22:00] <RoyK> lopta: are you sure?
[22:00] <lopta> RoyK: I'm sure they weren't 1.2M ;-)
[22:00] <RoyK> those 5.25 floppies went out of style in the eightees and the initial linux kernel came out in 1991
[22:01] <lopta> RoyK: I didn't say we were fashionable.
[22:01] <RoyK> mwhudson: so just old buggers hanging around here, then :D
[22:12] <lopta> I haven't done a lot with Linux in the years since that first install.
[22:12] <lopta> ...but I do have an Ubuntu Server box in the office running a utility thing
[22:13] <lopta> ...and I'm about to try it on an actual server.
[22:13] <RoyK> probably works
[22:13] <RoyK> what are the plans for the server? storage or application?
[22:14] <RoyK> or just "misc"? ;)
[22:14] <lopta> RoyK: Short term storage and just to familiarise myself with Ubuntu Server, if possible.
[22:14] <RoyK> ok
[22:15] <RoyK> one advice - if you want to install things like a web server, perhaps nextcloud, something else, do it in a VM if you have sufficient memory
[22:15] <lordcirth_> Or LXC container, they are lighter
[22:15] <RoyK> if something goes wrong in that vm, well, it's just a vm, not a big issue
[22:15]  * lopta nods
[22:15] <RoyK> lordcirth_: same thing, really - but I stick to kvm still
[22:16] <lopta> brb, plugging in a USB flash drive to write the image to.
[22:16] <RoyK> kernel stuff is hard or impossible in lxc
[22:16] <lordcirth_> Yeah, but nextcloud, etc don't need "kernel stuff"
[22:16] <lordcirth_> I do have ip_vs loaded by the host so that HAProxy works in LXC.
[22:18] <RoyK> lordcirth_: I know, perhaps I'm just lazy or that I like to sometimes have different distros or versions installed, and the isolation is still far better on kvm - but hell - both work
[22:18] <lordcirth_> Ubuntu 18.04 containers do run on 16.04 hosts, btw.
[22:19] <lordcirth_> Quite handy at $WORK
[22:21] <RoyK> whatever you fancy :)
[22:21]  * RoyK sticks to kvm
[22:31] <lopta> I suppose I should learn containers too, at some point.
[22:31] <lopta> Probably Ubuntu Server first though.
[22:32] <lopta> ...should be back tomorrow, hopefully.


[07:07] <mborzecki> morning
[08:02] <zyga> good morning
[08:07] <pstolowski> morning
[08:09] <zyga> hey pstolowski
[08:18] <mborzecki> zyga: pstolowski: hey guys
[09:04] <mborzecki> heh, so another bunch of rebuilds and had to go retrigger the builds on obs
[09:04] <mborzecki> i guess it's time i tweaked those client timeouts
[09:09] <mup> PR snapd#10059 opened: cmd/snap: use less aggressive client timeouts in unit tests <Simple 😃> <Skip spread> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/10059>
[10:04] <mup> PR snapd#10060 opened: boot: extend set try recovery system unit tests <Simple 😃> <Skip spread> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/10060>
[10:12] <pedronis> mborzecki: hi, should we close 100055,  as it's replaced by 100056 ?
[10:16] <mborzecki> pedronis: yeah, closed 10055 just now
[10:16] <pedronis> thx
[10:16] <mborzecki> pedronis: shall we sync with mvo/ijohnson about the issue today?
[10:16] <pedronis> mvo is still off
[10:16] <pedronis> but yes we should sync
[10:16] <mborzecki> ah
[10:19] <mup> PR snapd#10055 closed: wrappers: launch apps through /usr/lib/snapd/snap on core with snapd snap <⛔ Blocked> <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/10055>
[10:33] <pedronis> mborzecki: we can chat before or after the standup
[10:33] <mborzecki> pedronis: let's try before
[10:34] <pedronis> pstolowski: hi, maybe you could review https://github.com/snapcore/snapd/pull/10040 ?
[10:34] <mup> PR #10040: daemon: switch api_test.go to daemon_test and various other cleanups <Cleanup :broom:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/10040>
[10:34] <pstolowski> pedronis: sure
[10:44] <mborzecki> pedronis: i've updated https://github.com/snapcore/snapd/pull/10037
[10:44] <mup> PR #10037: boot: export helper for clearing tried system state, add tests <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/10037>
[10:53] <pedronis> mborzecki: thanks, +1
[10:53] <mborzecki> thanks for the review
[11:11] <jamesh> alan_g: I proposed some more fixes to help with #8699 here: https://github.com/MirServer/snapd/pull/5 -- there is still a bit more to address, but this should resolve most of the open threads
[11:11] <mup> PR #8699: interfaces/desktop-launch: support confined snaps launching other snaps <Needs Samuele review> <Created by AlanGriffiths> <https://github.com/snapcore/snapd/pull/8699>
[11:11] <mup> PR MirServer/snapd#5: usersession/userd: fix some of the review comments for #8699 <Created by jhenstridge> <https://github.com/MirServer/snapd/pull/5>
[11:12] <alan_g> jamesh, thanks. Will take a look
[11:14] <jamesh> alan_g: I did a merge from master though, which complicates the diff.  The changes in usersession/userd should be relatively clean though
[11:14] <alan_g> jamesh, Ack. I spotted that already
[11:50] <mup> PR snapcraft#3480 opened: ci: spread testing <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3480>
[12:00]  * cachio afk
[12:00] <mup> PR snapcraft#3480 closed: ci: spread testing <Created by cjp256> <Closed by cjp256> <https://github.com/snapcore/snapcraft/pull/3480>
[12:02] <pedronis> mborzecki: I scheduled something
[12:02] <mborzecki> thanks!
[12:15] <mup> PR snapcraft#3481 opened: tests: stub job to get autokpgtest for edge <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3481>
[13:05] <ijohnson> cachio: hey it seems we may have hit our image limit again, I see `2021-03-22 04:12:51 Cannot allocate google-nested:ubuntu-18.04-64: cannot find any Google image matching "ubuntu-1804-64-virt-enabled" on project "computeengine" or "ubuntu-os-cloud"`
[13:05] <ijohnson> can you clean up some images on gCE?
[13:17] <cachio> ijohnson, hi
[13:17] <cachio> let me check
[13:27] <ijohnson> thanks
[13:28] <cachio> ijohnson, it is done
[13:28] <cachio> try again please
[13:28] <ijohnson> great, thanks I will run it again
[14:20] <mup> PR snapd#10061 opened: interfaces/pwm: add PWM interface <Created by woodrow-shen> <https://github.com/snapcore/snapd/pull/10061>
[15:10] <mup> PR snapcraft#3482 opened: Support install-mode option for apps <Created by cmatsuoka> <https://github.com/snapcore/snapcraft/pull/3482>
[15:29] <mborzecki> pedronis , ijohnson : i've pushed the version using findmnt to https://github.com/snapcore/core20/pull/100
[15:29] <mup> PR core20#100: Add a wrapper for invoking the snap binary <Created by bboozzoo> <https://github.com/snapcore/core20/pull/100>
[15:31] <ijohnson> mborzecki: great I'll have a look in a bit
[15:37] <pedronis> mborzecki: it's better :)
[15:40] <mborzecki> pedronis: i'll force push that || -> &&
[16:17] <pedronis> pstolowski: I did a first on affectedByRefresh PR
[16:17] <pedronis> *pass
[16:20] <pstolowski> pedronis: thank you
[16:21] <mup> PR snapd#10062 opened: tests: validation sets spread test <validation-sets :white_check_mark:> <Created by stolowski> <https://github.com/snapcore/snapd/pull/10062>
[16:36] <mup> PR snapd#10063 opened: o/{device,hook}state: encode fde-setup-request key as base64 string  <Bug> <Run nested> <UC20> <⚠ Critical> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/10063>
[16:42] <pstolowski> ijohnson: hey, do you have a moment to do 2nd review of https://github.com/snapcore/snapd/pull/10048 ?
[16:42] <mup> PR #10048: o/configstate: deal with no longer valid refresh.timer=managed <Bug> <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/10048>
[16:44] <ijohnson> pstolowski: sure I will add it to my queue
[16:44] <pstolowski> thanks
[18:06] <cachio> ijohnson|lunch, hi, did you start taking a look to the auto-refresh test?
[18:09] <ijohnson> cachio: sorry can you remind me which test?
[18:09] <cachio> ijohnson, auto-refresh
[18:10] <ijohnson> cachio: you mean tests/main/auto-refresh ?
[18:10] <cachio> tes
[18:10] <cachio> yes
[18:17] <cachio> ijohnson, the snap refresh --time is showind a different output
[18:17] <cachio> https://paste.ubuntu.com/p/ykkrp3Xcqc/
[18:18] <cachio> dependening if we run in the first test suite or in the second one
[18:18] <cachio> the test suite clean up it messing up something I guess
[18:19] <ijohnson> cachio: the test runs `    snap set core refresh.schedule="0:00-23:59"`
[18:20] <ijohnson> cachio: the test needs to do in the restore sectoin `snap unset core refresh.schedule`
[18:21] <cachio> the problem is before taht
[18:22] <cachio> first thing the test does is
[18:22] <cachio>  echo "Auto refresh information is shown"
[18:22] <cachio>     output=$(snap refresh --time)
[18:22] <cachio> well
[18:22] <ijohnson> cachio: but what you are saying is that the `snap refresh --time` fails in the _second_ instance of running the test right ?
[18:22] <cachio> ijohnson, no
[18:22] <cachio> it fails at the beginning
[18:22] <ijohnson> I guess I'm confused how the test is failing then
[18:23] <ijohnson> also confused when the test is failing
[18:23] <cachio> in fact I shell the test and I see the diferent output
[18:23] <cachio> if I run
[18:23] <cachio> spread2 -debug -order -single-worker google:arch-linux-64:tests/completion/indirect:funkyfunc google:arch-linux-64:tests/main/auto-refresh:parallel
[18:23] <cachio> so then the output for nap refresh --time
[18:24] <cachio> contains timer: 00:00~24:00/4
[18:24] <cachio> if I run
[18:24] <cachio> spread2 -debug -order -single-worker google:arch-linux-64:tests/completion/indirect:funkyfunc google:arch-linux-64:tests/main/auto-refresh:parallel
[18:24] <cachio> spread2 -debug -order -single-worker google:arch-linux-64:tests/main/auto-refresh:parallel
[18:24] <cachio> last one
[18:24] <cachio> so then the output for nap refresh --time
[18:24] <cachio> contains schedule: 00:00-23:59
[18:25] <ijohnson> hmm
[18:25] <ijohnson> so the test fails not when the auto-refresh test is run twice, but when any other test is run before it ?
[18:25] <cachio> another test in another suite
[18:25] <cachio> yes
[18:26] <ijohnson> I see
[18:26] <cachio> I ran in a loop and the test works well
[18:26] <ijohnson> I wonder what the restore logic is doing
[18:26] <cachio> any idea what could be affecting this?
[18:26] <ijohnson> cachio: where do we have the magical code that resets snapd state that is run after every spread test?
[18:27] <cachio> tests/lib/reset.sh
[18:31] <cachio> ijohnson, after the last change the reset houldn't be needed
[18:31] <cachio> because we reaet after running the last test
[18:33] <ijohnson> cachio: when you see the auto-refresh test fail, can you get an output of `snap get system` ?
[18:33] <cachio> ijohnson, https://paste.ubuntu.com/p/s7ccZcPHdY/
[18:35] <ijohnson> cachio: sorry `snap get system -d`
[18:36] <cachio> ijohnson, https://paste.ubuntu.com/p/pn2MD2FSSR/
[18:36] <ijohnson> cachio: something set `snap set core refresh.hold=...` on that system
[18:38] <ijohnson> cachio: can you check what cloud-init scripts / datasources are doing for the system
[18:38] <ijohnson> ?
[18:38] <ijohnson> maybe someone added to the image something which calls `snap set core refresh.hold=...`
[18:38] <cachio> let me check
[18:45] <cachio> ijohnson, cloud init is not
[18:48] <ijohnson> cachio: you mean cloud-init is not running `snap set core refresh.hold=` ?
[18:49] <ijohnson> also cachio can you please review https://github.com/snapcore/snapd/pull/10044 and +1 if it it makes sense to you ?
[18:49] <mup> PR #10044: packaging: drop dh-systemd from build-depends on ubuntu-16.04+ <⚠ Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/10044>
[18:50] <cachio> ijohnson, sure
[18:52] <cachio> ijohnson, cloud init is not setting snap set core refresh.hold=
[18:52] <ijohnson> hmm
[18:52] <cachio> I'll continue working on this
[18:52] <cachio> don't worry
[18:56] <ijohnson> ok, thanks I don't have much bandwidth for this auto-refresh thing right now, and I think it's more pressing for me to get you a fix for the uevent spread test instead of debugging this
[18:56] <mup> PR snapd#10064 opened: tests: simplify the reset.sh logic by removing not needed command <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/10064>
[18:56] <ijohnson> but obviously feel free to reach out to others tomorrow morning about auto-refresh maybe someone else has an idea about what is going on
[19:04] <cachio> ijohnson, sure, thanks a lot
[20:51] <mup> PR snapcraft#3483 opened: requirements: use PyNaCl 1.3.0 and ensure is compiled on linux <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3483>
[21:47]  * cachio afk
[21:51] <mup> PR snapcraft#3484 opened: tests: crystal 1.0.0 requires shard.lock <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3484>
[21:52] <mup> PR snapd#10065 opened: tests: reset the system while preparing the test suite <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/10065>
[22:41] <mup> PR snapcraft#3484 closed: tests: crystal 1.0.0 requires shard.lock <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3484>


[03:01] <Lauren__> Anyone here to assist?
[03:07] <krytarik> Lauren__: Just asking the actual question right away usually works out better.
[03:08] <Lauren__> lol ok
[03:10] <Lauren__> xinput set-prop 13 "Device Enabled" 0 works to disable the trackpad on this hp but I need to run that each time it reboots. Can someone help?
[03:10] <krytarik> Just add it to your autostart items?
[03:12] <Lauren__> Yeah I've tried that and it doesn't disable it.
[03:14] <Lauren__> It's been in the "Manual autostarted applications" section of "Default applications for LXSession"
[03:29] <krytarik> Lauren__: Sounds about right, thanks for being more specific.  Do you see the command in '~/.config/lxsession/Lubuntu/autostart' after adding it there then?
[03:30] <Lauren__> No, I just looked there. Permission issue?
[03:30] <Lauren__> oh wait
[03:31] <Lauren__> I was looking in /etc/xdg/lxsession/Lubuntu
[03:32] <Lauren__> I don't see this path: ~/.config/lxsession/Lubuntu/autostart
[03:34] <krytarik> That's a file fwiw.  Also, what version of Lubuntu are you on?
[03:37] <Lauren__> 17.10
[03:38] <Lauren__> krytarik: I added the line to autostart...should I try rebooting to see if that works?
[03:39] <Lauren__> brb
[03:44] <Lauren__> krytarik: Didn't work
[03:44] <Lauren__> Had to manually run the command in terminal after it rebooted
[03:55] <krytarik> Lauren__: I don't know what further to suggest then, sorry.
[14:19] <DonVlad> How can I remove a PPA?
[14:20] <tsimonq2> sudo add-apt-repository -r ppa:USER/PPA-NAME
[14:20] <tsimonq2> Or, manually remove the file under /etc/apt/sources.list.d
[14:21] <DonVlad> ok
[14:21] <DonVlad> thanks!
[14:21] <tsimonq2> No problem, have a nice day :)
[17:37] <laptop_> why does lubuntu not auto update apps like manjaro
[17:37] <tsimonq2> Because Lubuntu's not Manjaro.
[17:38] <laptop_> how do you autoupdate apps, is there a debian distribution that does this for you
[17:38] <tsimonq2> What do you mean by "autoupdate"?
[17:38] <laptop_> like it will say 64 updates are ready and one of them say is your browser or an app installed ony our computer
[17:38] <laptop_> it will update chromium rather than youu manually downloading and updating
[17:39] <tsimonq2> There's an option similar to that in the GUI.
[17:40] <tsimonq2> Otherwise, I'd look into unattended-upgrades.
[17:40] <tsimonq2> But, Lubuntu isn't a rolling distro.
[17:41] <laptop_> which one is for debian bodhi?
[17:41] <tsimonq2> ?
[17:42] <laptop_> like which ubuntu/debian distro has a rolling release
[17:42] <tsimonq2> Debian Sid is rolling.
[17:42] <tsimonq2> The Ubuntu development release is technically rolling.
[17:43] <laptop_> is debian sid low spec like bodhi
[17:44] <tsimonq2> It's what you want it to be. ;)
[17:57] <laptop_> do you know if the software store will update apps or download the updated version
[17:57] <tsimonq2> Yes.
[17:59] <laptop_> really so if install chromium and a new version comes out the store will alert me that it needs to update chromium and if I click okay it will download it
[17:59] <laptop_> do you find ubuntu or debian releases to be more secure than arch
[18:00] <tsimonq2> It depends.
[18:00] <tsimonq2> Ubuntu is much more secure in some packages, Arch in others.
[18:00] <laptop_> what about from hackers or viruses
[18:00] <laptop_> for example take the latest malware exploit on the intel chips
[18:01] <tsimonq2> Again, it depends, but I think both do a decent enough job at things.
[18:01] <laptop_> ubuntu is not volunteer based so probably more incentive
[18:02] <tsimonq2> Ubuntu is volunteer based.
[18:02] <tsimonq2> I'm a volunteer.
[18:02] <laptop_> oh I see
[18:03] <tsimonq2> Yes, we have corporate backing that hires some Ubuntu developers, but the Ubuntu hierarchy is completely independent from Canonical's.
[18:03] <laptop_> i see


[12:47] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/4526 Diff missing (focal/dpdk). Needs rebuild due to higher version at destination (focal/openvswitch)
[12:51] -queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/3690 Needs rebuild due to higher version at destination (groovy/dpdk, groovy/openvswitch). Ready to build (groovy/ovn, groovy/paramiko, groovy/python-bleach)
[12:53] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/4252 Needs rebuild due to higher version at destination
[13:00] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/4239 Needs rebuild due to higher version at destination
[13:01] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/4260 Failed to build (groovy/dpdk). Needs rebuild due to higher version at destination (groovy/openvswitch)
[13:03] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/4222 Needs rebuild due to higher version at destination
[13:19] -queuebot:#ubuntu-ci-eng- rbalint, https://bileto.ubuntu.com/#/ticket/4159 Ready to build


[12:58] <XenomorphCmputin> whats the name of upcoming releases after Z? trees or maybe funghi?
[13:17] <BluesKaj> who knows what direction the naming will go next
[20:08] <dax> i commented asking on his blog, but he didn't approve it or reply ;(
[20:13] <valorie> undersea creatures!