[22:14] <Viktors> I just tried 16.04 desktop amd64 trial on my Thinkpad T420 and it just comes up with icons on the desktop... mouse moves but clikcking or any keyboard actions do nothing.  Works ok with 14.04/


 Happy Friday, and happy Carrot Cake Day! 😃
[10:11]  * zmoylan-pi has no carrot cake but knows were there's a wounded dangerous cheesecake that needs to be taken care of
[13:17] <dogmatic69> trying to find a PCIe wifi card http://i.imgur.com/9GITpEd.png
[13:17] <dogmatic69> :D
[13:18] <foobarry> trying to find a wing mirror cover
[13:18] <foobarry> :(
[13:19] <zmoylan-pi> ...at least things have moved on from audio on linux... :-P
[13:19] <foobarry> also, not broadcom
[13:26] <dogmatic69> probably will get this one, seems ok https://www.amazon.co.uk/gp/product/B00TZJYRF6
[13:27] <zmoylan-pi> take 1 antennae into the pc, not anymore...
[13:28] <dogmatic69> ?
[13:28] <dogmatic69> what you mean zmoylan-pi
[13:29] <zmoylan-pi> the card you linked has 3 antennae... just seems bit razor bladey advertising...
[13:30] <zmoylan-pi> but considering that pcs are often big metal cases there have been times internal or short antennaes have require some weird positioning of pcs
[15:47] <foobarry_> diplo: had terrible network issue, so not sure if u replied to me yseterday about systemd...
[15:52] <foobarry_> errm since when did sudo echo ***** on screen?
[15:59] <popey> it doesn't on ubuntu 16.04
[16:00] <foobarry_> nervous now
[16:00] <popey> you're running elementary?
[16:01] <foobarry_> installed 1.8.16-0ubuntu1.2
[16:01] <popey> 1.8.16-0ubuntu1.2 here
[16:01] <popey> it's an option in sudoers
[16:01] <popey> pwfeedback
[16:03] <foobarry_> ah, nice one
[16:03] <foobarry_> datestamp 25 jan
[16:03] <foobarry_> looks like elementary did some things
[16:03] <popey> i remember seeing it mentioned somewhere
[16:04] <foobarry_> also my laptop fails to suspend now
[16:04] <popey> https://bugs.launchpad.net/elementaryos/+bug/1611934
[16:04] <foobarry_> so yay
[16:04] <popey> fails to suspend or fails to resume?
[16:04] <foobarry_> fails to suspend properly i think
[16:04] <foobarry_> defintiely fails to resume
[16:04] <foobarry_> now working >50% of the time,
[16:05] <foobarry_> was 100% fail earlier
[16:05] <foobarry_> strange thing is, nothing obvious triggers it
[16:05] <foobarry_> it can't shut down graphics device on something like that
[16:07] <foobarry_> ACPI errors and all sorts of munge
[16:08] <popey> filed a bug?
[16:08] <foobarry_> very hard to debug
[16:08] <foobarry_> linus has the i915 bar 6 errors
[16:08] <foobarry_> too
[16:08] <popey> https://wiki.ubuntu.com/DebuggingKernelSuspend
[16:09] <foobarry_> tried all that in the past, had to resort to sort romanian script like a noob
[16:09] <foobarry_> only thing that fixed it
[16:11] <diplo> I said a few things, but not sure how relevant they were to you.
[16:11] <diplo> Have you tried After=network.target gvfs.target ?
[16:13] <foobarry_> turns out gpfs sucks
[16:14] <foobarry_> https://lists.freedesktop.org/archives/systemd-devel/2016-August/037295.html
[17:37] <daftykins> £5 SCART cable came for the ol' Sega Mega Drive i have kicking around :)
[17:37] <daftykins> http://imgur.com/a/YiwQz
[17:38] <zmoylan-pi> the light gun games won't work on the modern flat panels will they?
[17:39] <popey> sadly not
[17:39] <zmoylan-pi> :-(
[17:39]  * zmoylan-pi had great fun with time crisis on ps1
[17:39] <popey> i have a crt tv which i have carefully placed at my mums house on long term loan for when the day comes when i dig out my light gun based games :)
[17:39] <popey> same :)
[17:39] <daftykins> could've sworn i'd heard of a mod
[17:40] <zmoylan-pi> i have seen people /appear/to be playing light gun games on lcd screens....
[17:40] <daftykins> anyone wanna take my clients 3 year old son? this is what i found the big LG OLED TV like today - http://i.imgur.com/2J7I8Lg.jpg
[17:41] <zmoylan-pi> at least it didn't have chocolate hobnobs stuck in usb/hdmi ports...
[17:42] <daftykins> well one of the devices won't play sound anymore
[17:45] <popey> here's what i found inside my subwoofer one day http://imgur.com/a/BqrvD
[17:46] <daftykins> :>


[15:24] <mup> Bug #1696108 opened: Interface model validates the MAC address twice <MAAS:In Progress by ack> <https://launchpad.net/bugs/1696108>
[15:27] <mup> Bug #1696108 changed: Interface model validates the MAC address twice <MAAS:In Progress by ack> <https://launchpad.net/bugs/1696108>
[15:30] <mup> Bug #1696108 opened: Interface model validates the MAC address twice <MAAS:In Progress by ack> <https://launchpad.net/bugs/1696108>
[15:36] <mup> Bug #1696108 changed: Interface model validates the MAC address twice <MAAS:In Progress by ack> <https://launchpad.net/bugs/1696108>
[15:39] <mup> Bug #1696108 opened: Interface model validates the MAC address twice <MAAS:In Progress by ack> <https://launchpad.net/bugs/1696108>


[19:49] <lunapersa> Hello!
[23:46] <kremlin> Hi, a couple weeks ago I moved to Jakarta looking for loco team in Indonesia. Anyone can give me pointers?
[23:47] <kremlin> Interestingly, I found this: http://ubuntu.id with super ugly logo!
[23:47] <nhandler> kremlin: Have you seen http://loco.ubuntu.com/teams/ubuntu-id/ ?
[23:48] <kremlin> nhandler: saw that, but confused that they have http://ubuntu.id too
[23:50] <nhandler> kremlin: loco.ubuntu.com is a portal for all LoCo teams. ubuntu.id appears to be some Indonesian version of Ubuntu for government/companies there. ubuntu-id.org (linked from loco.ubuntu.com) appears to be the site for the team (but I am relying on Google Translate here)


[02:30] <bluesabre> ali1324: http://worldofgnome.org/running-gtk-applications-different-themes-per-app/
[02:30] <bluesabre> this may only work for gtk 3.12+, maybe 3.10
[02:36] <bluesabre> it looks like gksu was removed upstream in favor of pkexec, no real reason other than that. I think we just followed lead (I was asked to remove gksudo from catfish)
[02:36] <bluesabre> ... which led to me implementing my own sort of gksudo in python for catfish and any other apps that need to authenticate
[11:33] <bluesabre> Noskcaj: Since you did the initial packaging for whiskermenu in debian, thought you might be interested in the new (1.4.0) release http://gottcode.org/xfce4-whiskermenu-plugin/
[11:34] <bluesabre> I'll add the new release to xubuntu-staging this evening
[11:35] <bluesabre> Also, going to add mousepad daily builds to xubuntu-staging, lots of development happening there currently
[11:35] <bluesabre> gotta run to work, bbl
[19:47] <andreipath> anyone can help ?
[19:48] <andreipath> wifi swiched off by hardware switch but i cant find a way to turn it on
[19:48] <andreipath> it works fine in recovery mode though
[19:49] <knome> andreipath, this isn't a support channel
[19:50] <andreipath> i figured
[19:50] <andreipath> bu no one on the support channel has any ideea on how to solve this
[19:50] <andreipath> so i hope a developer might know something i dont :P
[20:05] <Noskcaj> bluesabre, It's been in debian svn for some time
[22:52] <bluesabre> this channel is surprisingly quiet today


[00:33] <matv1> hi all
[00:33] <matv1> does anyone know of a working qml app that does xmlhttp requests ?
[00:35] <matv1> or alternatively: does anyone know of a way to use it without apparmor messing it up
[00:35] <sarnold> what are your DENIED lines?
[00:37] <matv1> hi sarnold hang on i'll chuck it in a pastebin
[00:38] <matv1> http://pastebin.com/xGXphnEi
[00:39] <matv1> i have to add that it only fails when i deploy the app to the phone. running it in the sdk on the desktop, it does great
[00:40] <sarnold> heh I hadn't expected dbus errors...
[00:41] <sarnold> matv1: could you file a bug against click-apparmor source package, include these lines, any DENIED lines from syslog, and perhaps a small copy/paste of the function that generated these errors? thanks
[00:42] <sarnold> matv1: either 'ubuntu-bug click-apparmor' (if that works on the phone?) or https://bugs.launchpad.net/ubuntu/+source/click-apparmor/+filebug
[00:42] <matv1> sarnold sure. no problem
[00:43] <matv1> sarnold are you canonical if i may ask?
[00:43] <sarnold> matv1: I am
[00:43] <matv1> sarnold great thanks :)
[00:44] <sarnold> matv1: you're welcome, I hope this helps sort it out ;) I don' tknow much about the wrappers around the apparmor policy, but I'm pretty sure filing a bug there will sort things out :)
[00:45] <matv1> hmm not sure about that :) but i will stay hopefull
[00:47] <matv1> i had been tinkering with this a while back. about 6 months ago. gave up on it then. hope it would have been better now. because there is a bug about this where at least jamie strandboge participated in, I recall
[00:48] <sarnold> yeah, and he'll probably participate in this one too :) but the trick is there's a huge amount of qml/qt infrastructure and it doesn't all fit with our security goals. so some APis are allowed, some are forbidden, and mostly we only investigate adding ones as people run into them
[00:49] <sarnold> there's some connectivity API with Qt that apparently allows way too much personally identifiable information or similar to be handed to confined apps, which is why we block it, but nothing prevents rewriting the APIs or services to expose only what's needed. the trouble is there's only so many hours per day and so many people to work on things..
[00:52] <matv1> sarnold I appreciate that. I will do that bug report. let's see how it goes. Thanks again
[00:52] <sarnold> thanks matv1 :) have fun
[06:31] <ginggs> mdeslaur: is the "Ubuntu Wine Team" https://launchpad.net/~ubuntu-wine no more?
[07:59] <pitti> Good morning
[08:01] <caribou> pitti: I'm done with the rsyslog merge, just want a second look before uploading; hopefully today
[08:01] <pitti> caribou: yay, great
[08:35] <dholbach> good morning
[09:57] <sil2100> @pilot in
[10:08]  * dholbach hugs sil2100
[10:10]  * sil2100 hugs dholbach back
[10:16] <Mirv> pitti: hey, could you consider retrying some https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-023/excuses.html related results and maybe overriding kwin and/or hinting it not to try it together with the hybris update? and also i386 qtmir retry at https://requests.ci-train.ubuntu.com/static/britney/vivid/landing-023/excuses.html
[10:16] <Mirv> I'm hearing rob_ru might be bringing "retry" button to those pages in a few weeks, which sounds wonderful
[10:17] <pitti> Mirv: retry button> that needs some legwork on my side first, but yes, we should do that
[10:17] <dholbach> can somebody moderate my mail on u-d-a through?
[10:20] <ginggs> Is it possible to get the armhf binary for julia 0.4.2-3 removed? it is holding up the suitesparse transition. i don't yet know why 0.4.3 FTBFS on armhf in ubuntu (debian is fine), and 0.4.2-3 now also FTBFS on  armhf.
[10:20] <pitti> Mirv: I retried the armhf failures (xenial, will do vivid in a sec); but kwin passes in Ubuntu
[10:21] <pitti> Mirv: and that failure looks like some API change, not a transient issue?
[10:21] <pitti> dholbach: done
[10:22] <Mirv> pitti: it's when it's tested with the new libhybris, not because of qtdeclarative changes
[10:22] <dholbach> thanks pitti
[10:22] <Mirv> pitti: thanks.
[10:22] <Mirv> pitti: there are also older failures in archive when the new libhybris is being tested.
[10:23] <pitti> Mirv: qtmir retried for the vivid PPA
[10:25] <pitti> ginggs: yes, there are no reverse depends (just some reverse recommends from science-* metapackages)
[10:25] <pitti> Mirv: ah, I guess robru tests PPAs against all -proposed
[10:26] <pitti> Mirv: so, I don't want to override that in ubuntu as it's clearly a regression, and either libhybris or kwin needs to be updated
[10:26] <pitti> and by overriding we would let libhybris in and land the regression
[10:26] <ginggs> pitti, ok, can you do remove it please, or shall i file a bug?
[10:28] <pitti> Mirv: so I'd recommend to just ignore that one failure for this landing
[10:29] <pitti> ginggs: removed
[10:29] <Mirv> pitti: the problem is convincing QA to get that silo manually in to their consideration :) but I believe they might believe me if I quote you, and if the other non-overridden tests pass. thank you again.
[10:29] <ginggs> pitti: thanks!
[10:29] <pitti> Mirv: yes, you have my blessing and you can quote me on that :)
[10:30] <pitti> Mirv: it would probably be better if we tested PPAs not against the entirety of -proposed, so that they are better isolated against such unrelated breakage
[10:31] <pitti> or, once someone fixes libhybris or kwin, we can retry it and then it'll work too
[10:33] <Mirv> pitti: ok, robru could change the behavior so that not all of -proposed would be used
[10:55] <pitti> Mirv: https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-023/excuses.html looks better now
[10:58] <Mirv> pitti: indeed it does! just waiting for the vivid i386 qtmir still.
[11:03] <Mirv> ..and it updated
[11:05] <pitti> yay
[11:16] <rharper> hi, I've been working on a libnl sru into trusty (https://bugs.launchpad.net/ubuntu/trusty/+source/libnl3/+bug/1511735) ; the update is in trusty-proposed and the new package exposed a bug in NetworkManager (https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1539634) which has been fixed and pushed into trusty-proposed as well;  One of the users suggested that we add a Breaks: and release an update to libn
[11:16] <rharper> l with the Break to ensure that no users get the older networkmanager and the newer libnl;  is network-manager (<< <IP_ADDRESS>-0ubuntu7.3) sufficient ? and is this something we should do to ensure users install the newer NM before upgrading libnl ?
[11:17] <cjwatson> rharper: Breaks sounds correct and sufficient
[11:17] <rharper> cjwatson: and should I limit the Breaks to the packages that NM depends upon ?
[11:18] <rharper> libnl provides more than just those 3
[11:18] <cjwatson> rharper: I don't quite understand the question
[11:18] <rharper> in libnl debian/control, we list multiple binary packages, do I apply the Breaks: line to each of those or only the entries for the packages that NM actually depends up (and installs)
[11:19] <cjwatson> rharper: Put it at the root of the dependency hierarchy; since there is a root here, you only need it in a single place
[11:19] <rharper> cjwatson: ok, thanks!
[11:19] <cjwatson> rharper: That is, you only need it on libnl-3-200, not anywhere else
[11:20] <cjwatson> rharper: Well, strictly, it should be on the package where the actual code that breaks is shipped, but I'm guessing that's in the core library
[11:20] <rharper> ok
[11:25] <smoser> hey. i'm in need of some help.
[11:25] <smoser> https://platform-qa-jenkins.ubuntu.com/view/smoke-default/job/ubuntu-xenial-server-amd64-smoke-default/34/consoleFull
[11:25] <smoser> thats a log of a seeded install
[11:25] <smoser> my understanding is at that end of that install, it tries (reasonably) to unmount the target
[11:26] <smoser> i think that umount_active is asking us a question because it tried to unmount the target and failed
[11:26] <smoser> ie, the target was "active" because some process was running there and had open file handles.
[11:29] <smoser> can someone at least verifiy that my understanding of 'umount_active's purpose for that question is right ?
[11:31] <cjwatson> No, that isn't correct
[11:31] <smoser> ]o/!
[11:31] <cjwatson> Let me find you the code
[11:31] <smoser> thank you!
[11:32] <cjwatson> An important thing to understand is that this is during partitioning, not at the end of the installation process; processes shouldn't generally be running that aren't the installer (and there are no such process checks)
[11:32] <cjwatson> http://bazaar.launchpad.net/~ubuntu-core-dev/partman-base/ubuntu/view/head:/init.d/parted#L154
[11:33] <cjwatson> The second comment there basically explains the idea
[11:34] <smoser> its not during the partitioning tough
[11:34] <smoser> look at that log, cjwatson
[11:34] <smoser> oh. maybe.
[11:34] <cjwatson> I have, and you are incorrect.
[11:35] <smoser> :)
[11:35] <cjwatson> The last menu item that is logged as selected is partman-base.
[11:36] <smoser> so what else would be mounted ?
[11:36] <cjwatson> So the question is ... that
[11:36] <smoser> this is a transient failure
[11:36] <smoser> that is what is really odd
[11:37] <smoser> and i'm pretty sure the input disk to the installer is full of zeros
[11:37] <smoser> (ie, no old filesystem or swap or antying like that that could possibly get mounted)
[11:37] <cjwatson> Is /var/log/partman from this install logged somewhere?
[11:38] <cjwatson> Can't see it directly in the build artifacts
[11:39] <smoser> well, that one got killed
[11:40] <cjwatson> smoser: This log seems to contain two runs of the installer
[11:40] <smoser> i dont know that the file is collected.
[11:40] <smoser> interesting. so it rebooted to the installer, and the second time then found a disk that got automatically mouinted or something
[11:40] <cjwatson> There are two hits for "Menu item 'partman-base' selected", and the first is followed by the installer doing more stuff after that
[11:41] <smoser> definitely
[11:41] <smoser> and 2 kernel boot logs
[11:42] <cjwatson> Yeah.  Race in the reboot arrangements?
[11:42] <smoser> thank you colin. that is at least somethigng to look at
[11:44] <sil2100> @pilot out
[11:48] <cjwatson> smoser: I'm a little surprised by the automounting too, since the second install hasn't reached the point where it would do the automounting I'm aware of yet, and in any case that automounting is off by default ... but it could be somewhere else I'm not remembering, and who cares really since this is all in the land of consequential failures
[11:53]  * dholbach hugs sil2100
[12:06] <mdeslaur> ginggs: oh, I was going to say no, but it does look like mlankhorst uploaded to the ppa in december
[12:06] <mdeslaur> (re: wine)
[12:45] <ginggs> mdeslaur: i noticed the Ubuntu Wine Team PPA is no longer listed on the WineHQ download page, but instead a new team https://launchpad.net/~wine
[13:02] <doko> tinoco, xnox: https://launchpad.net/ubuntu/+source/llvm-toolchain-3.8/1:3.8~+rc1-1~exp1
[13:03] <smoser> cjwatson, are you sure it woudl be a mount ? if it would notice that lvm had holders and fail, thent that coudl be it.
[13:12] <cjwatson> smoser: yeah, that information is read from /proc/mounts if you look at the code, it has to be a mount
[13:13] <rharper> trying to build a source package (libnl) and getting an error from debuild -S, complaining: dpkg-source: warning: unknown information field 'Dm-Upload-Allowed' in input data in general section of control info file (http://paste.ubuntu.com/14865920/)
[13:13] <rharper> xenial host
[13:13] <cjwatson> rharper: ignore
[13:13] <cjwatson> that's a warning not an error
[13:13] <rharper> ok, error further down
[13:13] <cjwatson> rharper: oh, you are seeing an error but it's not the one you summarised here
[13:14] <cjwatson> rharper: debuild -S -nc
[13:14] <cjwatson> rharper: you need to have the build-depends satisfied if you aren't using -nc; using -nc avoids that requirement but means you need to be more careful to ensure that your source tree is clean
[13:14] <rharper> ah
[13:15] <cjwatson> given that you just pulled a fresh source package here and modified it, -nc is safe (but remember to edit the changelog too!)
[13:16] <rharper> cjwatson: thanks for the tip; I though I had build-deps satisfied but I did not;  yep will update changelog too
[13:20] <tinoco> doko: o/
[13:22] <tinoco> doko: i dont think ocaml is available on s390
[13:25] <doko> tinoco, it is available. disabling lldb works around the build failure
[13:25] <tinoco> cool!
[13:59] <LocutusOfBorg> doko, hi, do you plan to sync llvm-toolchain-3.8 from experimental?
[13:59] <LocutusOfBorg> I might give some time in fixing build failures
[13:59] <LocutusOfBorg> oh well, already there, sorry
[14:01] <LocutusOfBorg> amd64 failed for ENOSPACE
[14:17] <seb128> barry, hey, bug #1541407 seems due to your python3 changes, can you have a look?
[14:19] <seb128> barry, bug #1541408 also seems to be due to the xapian update
[14:19] <seb128> 'xapian' has no attribute 'DatabaseOpeningError'
[14:22] <xnox> rbasak, is it normal that we have php5 and php5.6 packages which are both php 5.6?
[14:24] <nacc> xnox: it's 'normal' in that debian has it that way .... what's a bit weird is that php5.6' version is different than php5
[14:24] <nacc> i believe php5.6 is a metapackage, as well
[14:24] <barry> seb128: okay, thanks.  i'll take a look
[14:24] <seb128> barry, thank you!
[14:26] <xnox> nacc, i shall slowly back away then =)
[14:27] <nacc> xnox: yeah, it's quite gross
[14:27] <nacc> xnox: hopefully, we'll just drop it all :)
[14:36] <barry> seb128: LP: #1541407 is an easy fix.  LP: ##1541408 doesn't yet make sense ;)
[14:37] <barry> LP: #1541408
[14:37] <seb128> barry, yeah, the syntax error looked like a simple one, thanks for fixing it!
[14:37] <barry> seb128: if i can't figure out the session installer one before i have to start sprinting, i'll upload the fix for the first one and come back to it
[14:37] <seb128> barry, unsure about the other one, either there was an incompatible change in the bindings or something weird?
[14:38] <seb128> barry, yeah, it's less of an issue, I would say that can wait for after ff
[14:38] <barry> seb128: that's the thing, from the cli the imports work fine
[14:38] <barry> cool
[14:38] <seb128> k, don't bother for now then
[14:38] <seb128> the syntax error is the important one
[14:38] <seb128> it prevents that file to work at all
[14:38] <barry> seb128: cool.  let me upload that one right now then
[14:38] <seb128> thanks
[14:38] <barry> cheers
[14:44] <scaldwell> Does anyone know if Ubuntu is planning a dynamic /etc/fstab similar to what has been done for /etc/motd?  This would make it much easier to build cloud environments.
[14:44] <jrwren> scaldwell: to what end, and how would it make it easier?
[14:44] <ogra_> probably not soon ...
[14:45] <ogra_> but i could imagin that we switch to systemd mount units at some day
[14:45] <ogra_> pitti might know if there are any plans
[14:46] <pitti> not really a "plan", but you can do this today if you want
[14:46] <ogra_> technically you can boot without fstab today already as long as you have a single partition setup .... ubuntu will happily boot using /dev/root
[14:46] <scaldwell> It would allow me to parameterize EFS volumes.
[14:46] <pitti> i. e. create .mount units instead of fstab entries
[14:46] <pitti> systemd itself does that via a generator which reads fstab and synthesizes .mount units in /run/systemd/generator/*.mount
[14:46] <scaldwell> true.  I just was talking about the new dynamic /etc/motd and we started discussing IRL how it would be nice to have one way to rule them all.
[14:47] <xnox> pitti, cyphermox, we activate lvm volume groups with udev rules, by default, including inside d-i. Which when done on s390x dasd drive, make it impossible to format it. Should we disable udev rules that auto-activate lvm volumes in lvm2 udeb?
[14:47] <xnox> bug #1536664
[14:47] <pitti> for EFI systems systemd can also read their partition UUIDs, and as long as they are correct, auto-mount them
[14:47] <pitti> but to this date our installer still writes wrong UUIDs, so that doesn't work
[14:47] <xnox> oh
[14:47] <pitti> cyphermox: ^ which reminds me, we quickly talked about that ages ago, but never got around to it..
[14:47] <xnox> pitti, i can fix the installer uuids, i think.
[14:48] <cyphermox> hum, what?
[14:48] <jrwren> scaldwell: on ec2?
[14:49] <cyphermox> xnox: so you're installing on a system where the drives were used for LVM before, they got auto-activated, and now you can't remove the volumes to format the drives?
[14:49] <cyphermox> pitti: wrong UUIDs?
[14:49] <pitti> https://en.wikipedia.org/wiki/GUID_Partition_Table#Partition_type_GUIDs ← this
[14:49] <ogra_> pitti, but that will only work with GPT
[14:50] <cyphermox> ah, jes
[14:50] <pitti> cyphermox: last time I checked, all GUID partitions that d-i created were of the generic type "Linux filesystem data", not "root partition", "home partition", "swap", etc.
[14:50] <cyphermox> the UUID for the EFI partition
[14:50] <cyphermox> ah
[14:50] <ogra_> pitti, also parted doesnt know about GUIDs
[14:50] <pitti> ogra_: sure; there is no counterpart to do that with MBR, for that you need fstab
[14:50] <xnox> cyphermox, yes, and where "format" i mean "mainframe specific operation for dasd drive specifically to `format` them with dasdfmt before partman was even run"
[14:50] <ogra_> pitti, i just had to move all of snappy to sgdisk thanks to that lack
[14:50] <xnox> cyphermox, aka re-initialise the drive
[14:51] <cyphermox> xnox: does it have to run before partman runs?
[14:51] <pitti> ogra_: indeed, it's annoying; I didn't find a good CLI way to change partition type UUIDs
[14:51] <pitti> ogra_: sgdisk does that? good to know
[14:51] <ogra_> pitti, sgdisk ;)
[14:51] <pitti> xnox: how does it prevent formatting? You mean you want to re-format a PV into e. g. a plain ext4 partition?
[14:51] <cjwatson> ogra_: It kind of does, they're just mapped into parted-speak
[14:51] <cjwatson> And maybe not completely so
[14:51] <xnox> cyphermox, yes, otherwise partman will see gibberish on the disk, and will not be able to e.g. create a valid parition table on it, or write a valid partition table.
[14:52] <cjwatson> e.g. I'm pretty sure we do actually set a swap GUID
[14:52] <xnox> pitti, prevents "dasdfmt" to succeed, if one chooses to reinitialise the drive (dasdfmt)
[14:52] <cyphermox> cjwatson: I think that might be the only one
[14:52] <ogra_> cjwatson, well, i needed to dynamically set them to certain values to create the proper boot setup for the dragonboard (each bootloader bit checks for the next piece to load by GUID there)
[14:52] <pitti> xnox: ah, and it's not an option to run vgremove/pvremove before either, I suppose?
[14:52] <cyphermox> xnox: in such a case, partman does not see the drives at all?
[14:53] <cjwatson> cyphermox: possibly, yes
[14:53] <pitti> xnox: if you remove the udev rules in d-i, then you can't re-install onto an existing LVM, or d-i needs to be modified to piece them together manually?
[14:53] <xnox> pitti, cyphermox - it's a step/udeb/menu before partman.
[14:53] <ogra_> cjwatson, and i didnt find anything in parted itself for this ...
[14:53] <cjwatson> tricky though, because parted isn't really told about the purpose of the partition, only (at best, and probably not always) what FS type it's going to contain
[14:53] <xnox> pitti, no. as debian-installer has all that. E.g. in partman, you enter lvm menu, activate volume group, etc.
[14:54] <cjwatson> somebody should take this to parted-devel to discuss requirements
[14:54] <cyphermox> xnox: seems to me like it shouldn't care that there are LVM volumes, and that if it does it could just as well be told to disable then before doing whatever it does
[14:54] <nacc> xnox: question for you on one of your merges for bacula from 2013 :)
[14:54]  * ogra_ points to http://bazaar.launchpad.net/~ogra/+junk/dragonboard/view/head:/partitioner.sh ... which uses http://bazaar.launchpad.net/~ogra/+junk/dragonboard/view/head:/parts.txt to create the bootloader setup required
[14:54] <xnox> cjwatson, in clearlinux, after partitioning, i would reset the part-type uuid with the "systemdish" ones, cause at that point i had the information "yeap, this will be rootfs partuuid".
[14:55] <cjwatson> it would perhaps be possible to do that in partman-target
[14:55] <cjwatson> it has the mount information
[14:55] <cyphermox> yeah
[14:55] <xnox> cyphermox, pitti - i think it's wrong to auto-activate lvm groups with udev, and thus interfeering with d-i state machine.
[14:55] <pitti> xnox: you know d-i much better than I, I trust your word :)
[14:56] <xnox> pitti, i wonder if desktop/ubiquity breaks if i change the udeb udev rules though =)
[14:56] <cyphermox> I wouldn't expect it to
[14:56] <pitti> xnox: what do you want to change there?
[14:56] <cjwatson> this is why we generally try to beat the udev rules into submission rather than removing them
[14:56] <pitti> xnox: (LVM auto-activation is in lvm, not udev)
[14:56] <cjwatson> to avoid having to have a different workflow in ubiquity
[14:56] <xnox> ude B i meant.
[14:56] <xnox> as in lvm2.udeb
[14:57] <pitti> debian/{dmsetup,lvm2}-udeb.install
[14:57] <pitti> xnox: so, that reduces one line of delta :)
[14:57] <xnox> oh.
[14:58] <barry> seb128: fixed a couple other problems with -dbus while i was at it <wink>
[14:58] <pitti> two actually (one for each udeb)
[14:58] <seb128> barry, great :-)
[14:59] <xnox> pitti, well, debian doesn't have udev rules for lvm full stop.
[14:59] <pitti> xnox: right, this is an ancient delta of our's
[14:59] <pitti> xnox: these days they have a lot of fancy units, but I never looked at those in detail
[15:00] <xnox> pitti, surely we don't care about lvm on the phone, and we should drop this stuff and use something systemd-ish? a generator?
[15:00] <pitti> xnox: I suppose easiest thing might be to install Debian sid on LVM into a VM and see how it works there?
[15:01] <xnox> hm, yeah.
[15:01] <pitti> i. e. what puzzles together VGs there; it ships the units, but no udev rules
[15:01] <xnox> they still have some udev rules, but not the activation ones.
[15:01] <pitti> or maybe it's still just the scripts/units that run once on boot, but that'd be rather poor
[15:01] <xnox> pitti, i wonder if it's best to eg. look at upstream and/or fedora.
[15:01] <pitti> i. e. this ought to work for hotplugged drives too
[15:01] <nacc> xnox: specifically if you knew why the postgres dependency was bumped to 9.3 .. we're going to move bacula to universe, so it might be nice to remove that from the delta
[15:03] <xnox> nacc, if it builds and runs unmodified, and e.g. "libncurses-dev" and "liblzo2-dev" build depends are present in bacula.
[15:03] <xnox> nacc, one can just sync it, and demote it to universe.
[15:04] <xnox> nacc, as far as i can tell all our changes were done to make it suitable for main.
[15:04] <nacc> xnox: ok, i'll make a note of that; it seems like the upstream code has fixed the ncurses dependency
[15:05] <xnox> nacc, cool.
[15:05] <nacc> and liblzo2 is merged
[15:05] <nacc> upstream, i mean
[15:06] <xnox> pitti, looking at upstream alone, there is a systemd instance unit that binds to all block devices to scan and activate them.
[15:07] <xnox> pitti, which is nice, cause then one can stop the unit.
[15:07] <pitti> xnox: that unit gets activated via udev, I figure
[15:07] <xnox> which would fix the https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1088081
[15:07] <xnox> pitti, yeap, udev->systemd-> generate the fake .device units that these things bind to.
[15:08] <pitti> they aren't "fake" :)
[15:08] <xnox> which would still be ubuntu-ish "auto-enable all the lvm groups" but "without bugs"
[15:08] <pitti> if you tag an udev device with "systemd", you will get a systemd .device unit for it with proper state, and can then make that trigger services or other stuff
[15:08] <xnox> pitti, i'm also pointed at lvmetad thing
[15:10] <xnox> oooh lvmetad does nested lvm properly.
[15:22] <xnox> right, i think i have screwed up this d-i bad enough. let me reboot it.
[15:23] <xnox> cyphermox, pitti: i wonder if i should use the force, when doing dasdfmt.
[15:23] <xnox> and that's it.
[15:46] <cjwatson> Laney: http://archive.ubuntu.com/ubuntu/dists/xenial/main/dep11/ etc. if you fancy having a look
[16:09] <caribou> pitti: newest rsyslog has made it to the archive, you may want to update & retest your juju bug
[16:17] <pitti> caribou: cool, thanks
[17:03] <hallyn> dpm: hey,
[17:05] <hallyn> whois dpm
[17:05] <hallyn> d'oh
[17:05] <dpm> that'd be me :)
[17:05] <hallyn> just making sur ei'm buggin ther ight person :)
[17:05] <dpm> but I'm on the phone
[17:05] <hallyn> dpm: if you need help with cgmanger ping me when you're off the phone
[17:05] <dpm> awesome, thanks
[17:11] <smoser> cjwatson, back on that partman failure thing...
[17:12] <smoser> in d-i, if there was swap partition would boot magically use it and then d-i see it busy? i suspect not, but grasping at what would have mounted something on that disk
[17:12] <smoser> as that seems completely non-sensical (and is probably a bug)
[17:23] <cjwatson> smoser: that wouldn't show up in /proc/mounts, so cannot be relevant
[17:29] <smoser> does it dump /proc/mounts anywahere or could it ?
[17:29] <smoser> on failure to find a disk, that'd likely be useful.
[17:38] <cjwatson> smoser: I don't think it does right now; it would be a reasonably easy patch to partman-base to make it log that in the cases where it asks a question
[17:40] <smoser> yea. thanks for your help cjwatson
[17:40] <smoser> since you're here.... and you're last touch (in gutsy)
[17:40] <smoser> https://code.launchpad.net/~smoser/ubuntu-seeds/platform.xenial-drop-ppp/+merge/284941
[17:41] <smoser> https://code.launchpad.net/~smoser/ubuntu-seeds/platform.xenial-ppp-to-server-ship/+merge/284943
[17:41] <smoser> your thoughts are very appreciated there.
[17:44] <ginggs> doko: i see you uploaded mpi-defaults recently, do we need debian bug #813494 fixed as well?
[17:58] <dpm> hallyn, so, to debug why apps don't start on unity 8, is it essentially these steps? http://pastebin.ubuntu.com/14868891
[17:58] <cjwatson> smoser: I don't really have an opinion on that
[17:59] <hallyn> dpm: the cgmanager debug step isn't quite right.  but hold on, you're on xenial?
[17:59] <dpm> hallyn, yes I am
[18:00] <hallyn> dpm: ok, libpam-cgfs is replacing libpam-cgm there.
[18:00] <hallyn> we can still test with libpam-cgm, but...
[18:01] <hallyn> dpm: your original failure was with libpam-cgfs installed?
[18:01] <dpm> tried both
[18:02] <hallyn> dpm: and right now you have libpam-cgm installed?  ok, lets proceed with that then.  systemd is running, right?
[18:03] <dpm> hallyn, hold on, otp again, sorry
[18:03] <hallyn> inthat case, do 'sudo systemctl stop cgmanager', then 'sudo /sbin/cgmanager -m name=systemd --debug' (in a term with scrollback or piping into a file)
[18:03] <hallyn> dpm: np.  anyway, ^ do that and then try again starting the app and pastebin the cgmanager debug output
[18:09]  * hallyn biab
[18:42] <dpm> hallyn, ok, back if you are around. I've got libpam-cgfs installed
[18:53] <Laney> cjwatson: thanks - now to find out why apt doesn't download it. :)
[18:55] <Laney> it knows about the indextarget and the URL seems right
[18:56] <Laney> juliank: if you're around, is it you who knows about IndexTargets?
[18:57] <hallyn> dpm: ok, and it still fails?
[18:57] <hallyn> with the new version?
[18:57] <hallyn> (0.17-0ubuntu3)
[18:58] <Laney> juliank: I install appstream on xenial and update, and apt-get indextargets --no-release-info shows it with the right URL (without .gz but that appears to be correct), yet it's not downloaded
[19:04] <dobey> pitti: hey. who all has access to do autopkgtest retries for britney on silos?
[19:05] <sarnold> I thuoght it was anyone who could upload the package or the triggers..
[19:05] <pitti> dobey: those: ubuntu_archive:x:2552:cjwatson,seb128,doko,pitti,adconrad,vorlon,didrocks,stgraber,laney
[19:05] <pitti> sarnold: for ubuntu yes, but web retry isn't implemented yet for silos
[19:06] <sarnold> ahhhh
[19:06] <dobey> oh, only archive admins? ok
[19:06] <hallyn> dpm: libpam-cgfs does not use cgmanager at all.  So if it fails with libpam-cgfs and with the '-c freezer' removed from the line in /etc/pam.d/common-session, that'll be very curious
[19:07] <dobey> sarnold: well, i don't have permissions to upload the package or the triggers, i don't think; but at least "any motu" would probably work for that situation
[19:07] <hallyn> dpm: in that case we'll have to assume that libpam-cgfs is not being called, and look into why.  (we'll have to verify that by having the app launcher sleep right before final exec of the app and look at /proc/pid/cgroup)
[19:08] <dobey> pitti: well, since you're here, can you rerun the unity-scope-click test on xenial armhf for silo 41?
[19:10] <pitti> $ run-autopkgtest -s xenial -a armhf --ppa ci-train-ppa-service/stable-phone-overlay --ppa ci-train-ppa-service/landing-042 --trigger pay-service/15.10+16.04.20160114-0ubuntu1 unity-scope-click
[19:10] <pitti> dobey: ^ done
[19:10] <dobey> pitti: 41 not 42 :)
[19:10] <dobey> but thanks
[19:11] <pitti> dobey: that cannot be -- 42 is TEH RIGHT ANSWER!
[19:11] <dobey> heh
[19:11] <pitti> (kicked the right one)
[19:13] <dpm> hallyn, ok, then I'll give libpam-cgfs another go and double-check sure I've got -c freezer removed
[19:26] <dpm> hallyn, so with libpam-cgfs installed, having removed '-c freezer', still same result: apps won't start
[19:27] <dpm> hallyn, installed libpam-c* packages -> http://pastebin.ubuntu.com/14870814
[19:28] <dpm> and contents of /etc/pam.d/common-session -> http://pastebin.ubuntu.com/14870817
[19:30] <juliank> Laney: Is it listed in the Release file?
[19:31] <juliank> No entry there, no fetching
[19:33]  * juliank is a little bit slow right now with writing as he just cut into his right thumb
[19:35] <hallyn> dpm: ok, so let's try restarting cgmanager with --debug as i described above, and change the pam.d/common-session line from pam_cgfs to pam_cgm
[19:36] <juliank> Hmm, it seems to be listed
[19:36] <hallyn> dpm: that way we can see whether any requests are being made of pam
[19:36] <Laney> juliank: Yeah, http://archive.ubuntu.com/ubuntu/dists/xenial/Release
[19:36] <juliank> Laney: But only the compressed dep11 files are listed in the xenial Release file, APT probably needs the uncompressed  ones as well
[19:37] <dpm> hallyn, would you mind re-pasting the cmanager restart command? I'm on my laptop now and don't have the scrollback
[19:37] <Laney> o rly?
[19:38] <hallyn> dpm: 'sudo systemctl stop cgmanager;  sudo cgmanager -m name=systemd --debug'
[19:38] <Laney> juliank: actually I don't even - Debian lists them in there but they don't exist?
[19:39] <juliank> Laney: Sure uncompressed Contents and Packages files don't exist either.
[19:39] <dpm> hallyn, and do I need to install libpam-cgm before changing the common-session file?
[19:40] <dpm> hallyn, it seems at least I need to install the 'cmanager' package to get the cmanager command
[19:40] <hallyn> dpm: i thought you said you had libpam-cgm installed
[19:40] <hallyn> yes.  so install cgmanager and libpam-cgm i guess
[19:41] <hallyn> actually maybe it would have been easier to strace -f -p pid-of-launcher (upstart?) and look at that strace
[19:41] <dpm> hallyn, no, I had -cgfs installed, IIRC (see pastebin above)
[19:41] <hallyn> i was looking at http://pastebin.ubuntu.com/14870814/
[19:42] <hallyn> but no matter - actually can you do the strace first instead?  it may tell us what we need
[19:42] <Laney> juliank: ok, so Launchpad should be generating this?
[19:43] <hallyn> dpm: that's assuming you know which task fires off the app, which ia ssume you do.  (upstart user session?)
[19:43] <juliank> Laney: I think so, yes
[19:43] <Laney> cjwatson: ^- apparently you need to list the files uncompressed too
[19:43] <hallyn> back in 5
[19:43] <Laney> cf Packages
[19:43] <dpm> hallyn, right, on http://pastebin.ubuntu.com/14870814 I've got -cgfs installed (just making sure I've got the right one)
[19:43] <dpm> hallyn, I've no clue which task fires the app, no
[19:44]  * juliank would also list checksum for uncompressed Contents files while at it
[19:45] <dpm> hallyn, nm, I need to run, thanks for the help and let's continue tomorrow
[19:56] <hallyn> d'oh.  who would know...
[19:57] <lpotter> wish I could edit comments in launchpad
[20:06] <cjwatson> Laney: Ah, I wondered, but wanted to see whether it was needed
[20:06] <cjwatson> Laney: I came up with a plan for that, so I'll put that into practice later
[20:07] <cjwatson> juliank: that's a little more effort for reasons, but will see what I can do
[20:08] <cjwatson> I guess if I need it for Contents as well then maybe I should deal with it in the publisher itself rather than hacking around it in ubuntu-archive-publishing scripts as I'd initially planned
[20:12] <juliank> cjwatson: It will be needed for Contents for apt-file 3.0 to work
[20:13] <juliank> I suppose it's possible to hack around things by including .gz in the APT configuration and removing the setting to keep files compressed, but that's somewhat ugly.
[20:13] <juliank> That is, in the files shipped by appstream and apt-file 3
[20:18]  * juliank is afk for 45 minutes
[20:39] <cjwatson> juliank: Yeah, historically we've hacked around it in a fairly ugly way for Packages (we generate uncompressed Packages and then remove them in postprocessing) but that isn't done for Contents and I think it's time to fix it in a more graceful way
[20:39] <cjwatson> bah, timing
[20:50] <mwhudson> infinity: ping
[20:57] <mterry> robert_ancell, hello!
[20:57] <mterry> robert_ancell, limba looks kinda nuts is all
[20:57] <robert_ancell> mterry, hi!
[20:58] <robert_ancell> mterry, yeah, thought that might be a little like that. Just say no in the MIR and we'll take it as a packaging issue.
[20:58] <mterry> robert_ancell, well I'm expecting security to say no.  But that no might take a while to get to you, they're quite busy
[20:59] <robert_ancell> mterry, thanks for the review
[20:59] <mterry> robert_ancell, I can review the packaging to try to find an early reason to say no  :)
[20:59] <mterry> robert_ancell, or maybe just patch it out for now and if they come back and say it's fine after all, add it back
[20:59] <robert_ancell> mterry, yeah
[20:59] <robert_ancell> mterry, there's plenty of other MIRs that need doing first
[20:59] <mterry> truth
[21:00] <mterry> robert_ancell, I'd never heard of limba.  Is it popular?
[21:00] <robert_ancell> mterry, no, it's new
[21:02] <mterry> robert_ancell, is packagekit 1.0 being packaged shortly?
[21:02] <robert_ancell> mterry, we're having issues tracking down all the loose ends. We may have to drop PK1.0 and work around it.
[21:03] <robert_ancell> mterry, it is packaged in the sense that the Debian version is what we'd use
[21:03] <mterry> robert_ancell, gotcha
[21:03] <cjwatson> maybe I'm going to have to take a day and sort out the click native-dbus branch, since apparently nobody else is
[21:04] <cjwatson> (re pk 1.0)
[21:05] <robert_ancell> cjwatson, wasn't it decided to drop PK support? (but fixing is better obviously)
[21:07] <cjwatson> robert_ancell: err
[21:07] <cjwatson> robert_ancell: the way to drop PK support is to land the native-dbus branch
[21:07] <cjwatson> robert_ancell: that's the point of it
[21:07] <cjwatson> robert_ancell: can't just drop it otherwise since click currently entirely relies on it
[21:07] <robert_ancell> cjwatson, oh ok
[21:35] <mwhudson> has something changed in xenial in the last few days that means it's now required to add -lpthread to a link?
[21:36] <sarnold> did one of the libraries you require suddenly add pthread support?
[21:55] <mwhudson> sarnold: i guess i should check
[21:57] <mwhudson> liblxc maybe?
[21:59] <jtaylor> -lpthread should never be required
[21:59] <jtaylor> -pthread maybe
[22:03] <mwhudson> huh the package versions for the successful and failed builds are the same
[22:03] <mwhudson> wtf is going on
[22:03] <mwhudson> failed: https://launchpadlibrarian.net/235984198/buildlog_ubuntu-xenial-amd64.lxd_2.0.0~beta1-0ubuntu6_BUILDING.txt.gz
[22:03] <mwhudson> succeeded: https://launchpadlibrarian.net/235963097/buildlog_ubuntu-xenial-amd64.lxd_2.0.0~beta1-0ubuntu5_BUILDING.txt.gz
[22:03]  * mwhudson aft
[22:27] <mwhudson> ohh i know what the difference is
[22:27] <mwhudson> i don't know why it's a problem, but i expect that's easier to figure out


[00:37] <LaserJock> ScottK: you doin' FTBFS again tonight?
[00:37] <ScottK> Just looking at it a bit.
[00:37] <ScottK> We also have the archive rebuild test going on now https://launchpad.net/ubuntu/+archive/test-rebuild-20090909
[00:38] <ScottK> Not much in the way of results yet, but what there is can be found here http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20090909.html
[00:40] <LaserJock> ScottK: I'm looking at a FTBFS one right now where a python package failed because of a doctest failure
[00:40] <ScottK> Ah.
[00:41] <LaserJock> but the doc test fails because it's looking at a list of modules
[00:41] <LaserJock> and it expects a certain set, but the set that's returned is longer
[00:54] <LaserJock> ScottK: that link you gave for the latest rebuild test looks like something's messed up with amd64
[00:55] <ScottK> LaserJock: Why do you say that?
[00:56] <ScottK> It's been running ahead of i386 from almost the start
[00:56] <ScottK> Most of the builds that are done are amd64, so it's no suprise that's where the failures are.
[00:56] <LaserJock> well, it looks like an awful lot are failing
[00:57] <LaserJock> in particular 9base is the first Universe package I believe alphabetically
[00:58] <LaserJock> well, close to the first
[00:58] <LaserJock> just seems like a pretty high FTBFS rate
[01:10] <ScottK> Dunno
[01:21] <LordMetroid> http://concise-software.blogspot.com/2009/08/concise-howtos-install-erlangotp-r13b01.html is reporting that JInterface is missing from the Erlang packages, is this still the case with Karmic?
[01:22] <LordMetroid> How do I figure that out?
[01:41] <wgrant> LaserJock: Those are all legit failures. i386 is just backlogged because it's i386.
[01:41] <wgrant> And the failure rate isn't much higher than expected.
[01:41] <wgrant> It was often around 10% in rebuildd, IIRC.
[01:42] <LaserJock> I was thinking it was looking like 20-30%
[01:42] <LaserJock> but upon relooking at the list of packages it's probably more like 10%
[01:42] <wgrant> LaserJock: We have gcc4.4.
[01:44] <wgrant> It's actually sitting slightly under 4% right now, but there are langpacks involved.
[01:44] <wgrant> I noticed they built first.
[01:44] <wgrant> Which makes no sense.
[01:44] <wgrant> Ah. Of course.
[01:44] <wgrant> THey're forced to a score of 0 before the rebuild archive score is forced to -10
[01:45] <wgrant> So they will have monopolised the i386 builders, and they are unlikely to fail.
[01:45] <wgrant> Hence the large number of amd64 failures.
[02:41] <qiy> !casper
[02:42] <micahg> !info casper > qiy
[02:42] <qiy> micahg: is casper dead or not?
[02:42] <micahg> !info casper
[02:43] <qiy> micahg: casper and live-initamfs, which is the future?
[02:43] <micahg> idk
[02:43] <qiy> !info live-initramfs
[02:43] <micahg> !info casper karmic
[02:43] <qiy> which is default/offical? micahg
[02:43] <micahg> idk
[02:44]  * micahg is looking for a blueprint
[02:44] <qiy> live-initramfs universe optional
[02:44] <qiy> casper main extra
[02:45] <qiy> so casper is offical
[02:49] <superm1> qiy, for the forseeable future ubuntu will be using casper
[02:49] <qiy> superm1: why they fork?
[02:50] <superm1> qiy, i'm not too sure on the history, you'll probably want to look in debian/changelog for hints and talk to those who were the initial committers
[02:50] <cody-somerville> It got forked because Ubuntu was unresponsive at the time cause Colin, the maintainer of Casper, was busy.
[02:51] <cody-somerville> live-initramfs in universe probably won't even work with Ubuntu but I saw a few weeks ago patches discussed in Debian to add support for Ubuntu to live-initramfs
[02:52] <qiy> cody-somerville: so casper is not dead
[02:53] <cody-somerville> Correct
[02:58] <qiy> cody-somerville: are they still look and work similar ?
[02:58] <cody-somerville> not at all
[02:58] <qiy> what about that live-helper? cody-somerville
[02:59] <cody-somerville> what about it?
[03:00] <qiy> !info live-helper
[03:01] <cody-somerville> qiy, live-helper 1.0.5-1 supports building live images for Ubuntu
[03:06] <qiy> cody-somerville: imo, live-helper is used with live-initramfs
[03:07] <qiy> cody-somerville: how is casper? does casper need a live-helper?
[03:07] <cody-somerville> Its nice that you have that opinion
[03:07] <cody-somerville> but live-helper supports both live-initramfs and casper
[03:08] <qiy> cody-somerville: so casper users should use live-helper too?
[03:08] <cody-somerville> qiy, To do what? Create a customized live image? They can if they want to
[03:12] <qiy> cody-somerville: yeah, to create a customized live image or ubuntu/debian create their images
[03:36] <qiy> cody-somerville: casper conflicts live-initramfs
[03:36] <cody-somerville> qiy, right - you can't use both at the same time naturally
[03:36] <qiy> it is trying to overwrite /usr/share/initramfs-tools/conf.d/compcache from live-initramfs
[03:37] <qiy> cody-somerville: ^
[03:43] <StevenK> qiy: As cody-somerville says, you can't have both installed at the same time.
[06:40] <dholbach> good morning
[07:06] <mruiz> hi all
[07:06] <mruiz> what "debuild -sa" does ?
[07:10] <randomaction> man dpkg-buildpackage
[07:12] <mruiz> randomaction, thanks
[07:13] <fabrice_sp> Hi dholbach !
[07:14] <fabrice_sp> about bug #427025, could you post the full log? I've been building this package several time, in karmic, and never got this error
[07:14] <dholbach> fabrice_sp: sure, just a sec
[07:14] <fabrice_sp> thanks :-)
[07:15] <mruiz> What is the default command to build a package: debuild -S -k<my_key> or debuild -S -sa -K<my_key> ?
[07:16] <dholbach> mruiz: -k<keyid> shouldn't be necessary if you set up DEBEMAIL and DEBFULLNAME in ~/.bashrc properly (and your gpg key)
[07:16] <dholbach> the "-sa" is only relevant if you intend to upload the package somewhere
[07:19] <mruiz> dholbach, thanks
[07:19]  * mruiz writing it down
[07:19] <mruiz> dholbach, news about the mentoring program ?
[07:20] <dholbach> mruiz: no and I'm not running it anymore
[07:20] <fabrice_sp> have to go now. CU later
[07:20] <mruiz> dholbach, who is on charge?
[07:21] <dholbach> mruiz: https://wiki.ubuntu.com/MOTU/Mentoring/Reception
[08:26] <sivang> hi all
[08:27] <sivang> is there anybody interested in packaging a very useful utility written in twisted ?
[08:29] <slytherin> sivang: Are you paying for it? :-P
[08:30] <sivang> slytherin: hmm, I would have - but now that I'm unemployed it might be a bit a problem
[08:30] <sivang> aren't there new MOTUs wanting to package their first python software ?
[08:31] <slytherin> I am not one of them. I stay away from python.
[08:31] <slytherin> And those who want to package python software have probably already done so. :-)
[08:54] <sivang> slytherin: then I guess I should do it myself
[08:54] <sivang> what's the protocol these days for upload something to unierse if my ubuntu-devel membership expired ?
[09:06] <dholbach_> sivang: 1) https://wiki.ubuntu.com/SponsorshipProcess 2) send a quick email to<EMAIL_ADDRESS>saying that you want to rejoin the team and what your plans are
[09:06] <dholbach_> sivang: how are you doing? :)
[09:06] <dholbach_> tseliot: can you take a look at bug 411915 when you have a bit of time?
[09:07] <sivang> dholbach_: my health poor, but I'm trying to hang there
[09:07]  * sivang hugs dholbach
[09:07] <sivang> and misses him
[09:07] <dholbach> long time no see :)
[09:07] <sivang> indeed
[09:08] <sivang> I worked for stupid company for the last year
[09:08] <sivang> was very busy
[09:08] <sivang> at least I became a plone expert
[09:08] <sivang> :)
[09:08] <sivang> so something good came out of it
[09:08] <tseliot> dholbach: I approved the merge proposed by james_w and he volunteered to upload the fix: https://code.edge.launchpad.net/~arky/ubuntu/karmic/envyng-core/fix-411915/+merge/11231
[09:08] <dholbach> ah ok
[09:08] <dholbach> super
[09:10] <tseliot> :-)
[09:11] <nicolasvw> :P
[09:21] <slytherin> How can I separate  the build process so that the targets for required by arch:all packages are not run when doing only arch:any build?
[09:23] <geser> does the upstream build process support it? e.g. a seperate target to build only the documention
[09:24] <qiy> !info gfxboot
[09:24] <qiy> !info grub-gfxboot
[09:25] <slytherin> geser: yes it does.
[09:27]  * slangasek hates curl for making the libkrb53 transition 3x harder than it should have been
[09:28]  * slangasek hates cups for ensuring the next transition will be hard too
[09:37] <geser> slytherin: then you use the binary-arch and binary-indep target and the binary target depending on both
[09:40] <slangasek> well, ultimately the right solution is to use build-arch and build-indep targets; that doesn't work today because there's a messy transition involved
[09:41] <slangasek> so you have to specifically do your building of the arch-indep stuff in the binary-indep target, and *not* in the build target where it would normally be
[09:42] <slytherin> slangasek: Thanks. And I thought I was doing something wrong. I tried putting the 'make doc' command in build-indep but it was getting built even when doing arch:any only build.
[09:42] <slytherin> slangasek: I will follow your suggestion now.
[09:43] <slangasek> yeah, because dpkg-buildpackage (which everything is based on) always calls ./debian/rules build :(
[09:43] <slytherin> slangasek: even when you say dpkg-buildpackage -B?
[09:43] <slangasek> yep
[09:43] <slytherin> that is a bug then isn't it?
[09:43] <slangasek> it's a... historical wart
[09:44] <slytherin> And that probably adds overhead on buildd. Because the even if we split the builds, build-indep gets executed on all archs.
[09:44] <slangasek> it's how things were done in the distant past; then Build-Depends-Indep were introduced but the build target wasn't split; now the only way to have dpkg-buildpackage start calling build-arch is by breaking things
[09:45] <slangasek> i.e., all packages that don't support a build-arch target today will FTBFS, there's no reliable way to detect whether the target exists and fall back to build
[09:45] <slytherin> But isn't it better to break sooner than later?

[09:46] <slangasek> the default conclusion has been that no one finds the problem important enough to break anything at all :)
[09:50] <slytherin> slangasek: The problem is usually seen with packages that have both arch:all and arch:any packages and failure in build-indep causes the whole build to fail.
[09:52] <slangasek> slytherin: if it's a build failure because of dependencies not installed, that's really a package bug at present
[09:53] <slytherin> Not because of build-deps. Consider this, javadoc generation is really 'god-knows-if-it-will-work' in some archs. So failure in generating javadoc causes problem for whole build.
[09:54] <directhex> ikvm is suitably abusive
[09:54] <directhex> i.e. the "build" target only calls build-arch
[09:54] <directhex> because the build-indep rule only works on buildds with over a gig of ram
[09:55] <directhex> since the ubuntu buildd calls build-indep separately, it works well
[09:55] <directhex> don;t know whether it works on debian as expected, but with binary uploading, doesn't really matter
[10:15] <slytherin> directhex: that is why it is hard to find a solution that works for both Debian/Ubuntu.
[10:17] <quadrispro> nhandler: ping
[10:21] <dholbach> quadrispro: I guess nhandler is sleeping now
[10:21] <dholbach> quadrispro: did you see bug 306399?
[10:22] <quadrispro> dholbach: i'm reading right now
[10:23] <quadrispro> I think we should wait for a siretart's opinion
[10:23] <andv> quadrispro, siretart left for his honey moon ;)
[10:24] <andv> quadrispro, so he won't be back in few days
[10:29] <quadrispro> after the upgrade, there's a good number of packages that would need a rebuild, and, as Loic said, siretart is looking over that
[10:32] <quadrispro> if I had some spare time, I would make more testing
[11:05] <kaushal> hi
[11:06] <kaushal> when i try to install apt-get install ssmtp
[11:06] <kaushal> i get http://paste.ubuntu.com/268493/
[11:21] <hyperair> looks like a prerm remove script problem
[11:21] <hyperair> s/remove//
[11:22] <hyperair> kaushal: file a bug
[14:35] <slytherin> slangasek: the trick you mentioned does not seem to work for some reason. My document generation target is getting called after the -doc package is created. So all the generated content is missing from -doc package.
[14:45] <bddebian> Heya gang
[14:46] <ScottK> Heya bddebian.
[14:46] <bddebian> Hi ScottK
[15:01] <dholbach> porthose: #ubuntu-meeting?
[15:01] <hjmf> dholbach: me I ask you a shameful and offtopic question?
[15:01] <dholbach> hjmf: try it and I'll see if I answer :)
[15:02] <hjmf> yesterday I noticed that my ubuntu membership expired :-(
[15:02] <hjmf> dholbach: the fact is that I didn't noticed the automatic renew emails that I received days before
[15:02] <hjmf> dholbach: can I do something about it?
[15:03] <dholbach> just a sec
[15:03] <hjmf> dholbach: k
[15:04] <dholbach> send a quick mail to<EMAIL_ADDRESS>[15:04] <dholbach> they'll fix you up
[15:05] <dholbach> tell them your launchpad id and stuff and they'll take care of it
[15:05] <hjmf> dholbach, asac OK I'll do; thank you both
[15:05] <asac> great
[15:05]  * asac happy that this moves forward
[15:05] <dholbach> no worries
[15:05] <dholbach> should be quick
[15:05] <asac> dholbach: the email looks cryptic
[15:05] <asac> board-emea
[15:06] <hjmf> yes, a bit cryptic
[15:06] <dholbach> https://wiki.ubuntu.com/Membership has more info on the split
[15:06] <dholbach> and why
[15:06] <asac> ok ... so probably ok ;)
[15:07] <hjmf> dholbach: looking and sending
[15:13] <the-dude> will becomming a ubuntu maintainer be much easyer then becomming a debian maintainer?
[15:14] <slytherin> the-dude: There is no such thing as Ubuntu Maintainer. There is Ubuntu Developer. And I believe becoming Debian Maintainer (DM) is easier.
[15:15] <dholbach> basically you work on things in Ubuntu, you work with reviewers who upload changes for you, once they tell you how much great work you do, you can apply for Ubuntu developer membership
[15:16] <dholbach> https://wiki.ubuntu.com/MOTU/GettingStarted will link to all the important stuff
[15:16] <hjmf> dholbach: delivery failed to<EMAIL_ADDRESS>DNS error
[15:16] <dholbach> hjmf: lists.ubuntu.com, right?
[15:16] <the-dude> becomming a debian maintainer seems so formal and official
[15:16] <hjmf> my bad :-)
[15:18] <the-dude> so its building a new package and finding someone to review it ? thats all it takes?
[15:18] <dholbach> the-dude: not necessarily a new package - if you work on existing packages and improve them, that's even better :)
[15:19] <dholbach> we don't have the concept of "package maintainer" - it's not like you own a package in Ubuntu
[15:19] <dholbach> but we work on them as a team
[15:19] <dholbach> I encourage you to check out the link above
[15:19] <the-dude> but I want to add new new packages instead of fixing bugs
[15:19] <dholbach> and have a look at https://wiki.ubuntu.com/UbuntuDevelopment - it explains a lot about how things work
[15:19] <dholbach> you can do that too
[15:20] <the-dude> finding a new package which I like seems a lot easyer then waiting for a bug in a existing package I like
[15:21] <dholbach> well, I'll leave that decision to you, but I found it much easier to work on existing packages and fix a small bug here, and another small bug there instead of starting to package an application and really take care of it
[15:22] <the-dude> I already have experiance with packaging
[15:23] <the-dude> im just searching for a way to get it in to debian or ubuntu
[15:23] <the-dude> ubuntu seems a bit easyer but I have a sponsor for debian
[15:23] <the-dude> so im not sure yet
[15:25] <hjmf> dholbach: issue fixed, thank you
[15:25] <dholbach> hjmf: rock and roll!
[15:25] <hjmf> :-D
[15:50] <Laney> who's our LP liaison?
[15:56] <soren> Laney: You. Didn't you get the memo?
[15:56] <soren> :p
[15:56] <Laney> Awesome!
[15:57]  * Laney kicks some ass
[15:57] <quadrispro> nhandler: ping
[15:57] <quadrispro> iulian: ping
[16:02] <Laney> the-dude: if you have a sponsor then Debian is easier
[16:02] <Laney> finding MOTU reviewers can be really hard
[16:02] <Laney> (plus we are in a freeze now)
[16:03] <Laney> ...also I think having a human responsible for each package is a massive win - we have a bit of a problem with fire-and-forget packagers sometimes
[16:07] <bdrung> dholbach: jippi
[16:09] <dholbach> bdrung: congratulations!
[16:09] <bdrung> thanks
[16:10] <bdrung> finally i can screw ubuntu up. ;)
[16:10] <highvoltage> bdrung: jus saw daniels mail. congrats!
[16:11] <bdrung> highvoltage: thanks
[16:24] <the-dude> Laney: so what would you suggest? wait for a while?
[16:25] <Laney> use your debian sponsor
[16:26] <the-dude> aight
[16:26] <the-dude> but then I won't get a @ubuntu alias ;)
[16:26] <sebner> bdrung: congrats :)
[16:27] <bdrung> sebner: thanks
[16:27] <Laney> the-dude: you can fix things in Ubuntu, but I really wholeheartedly recommend packaging *new* things in Debian
[16:27] <Laney> the majority of what we do applies equally over there anyway
[16:30] <the-dude> Laney: ok thanks, will get the package in sid then
[16:30] <Laney> good good
[16:36] <slytherin> Laney: Why do you think 'fire-and-forget' is not problem in Debian?
[16:39] <Laney> slytherin: I didn't say that. I think that having a named maintainer responsible for each package helps when problems come up though.
[16:40]  * directhex names Laney
[16:40]  * Laney leaves the chamber :(
[16:41] <slytherin> Laney: Both methods have their own disadvantages. You can find many packages in debian not updated for long time with many bugs open because there is only one maintainer.
[16:42] <slytherin> I prefer Ubuntu method. It's disadvantages are lesser of the two evils IMHO
[16:42] <Laney> I don't think we're particularly good at handling our bugs in general
[16:43] <slytherin> well, I am not talking about all bugs, just bugs that arise out of packaging problems.
[16:43] <directhex> i want a median
[16:43] <directhex> every package should be "owned" by a team
[16:43] <ScottK> No way
[16:44] <directhex> individuals are blockers in debian, and motu si too large to give lovin' to everything in ubuntu
[16:44] <the-dude> so ubuntu packages don't have official owners?
[16:45] <directhex> no. in ubuntu everything is owned by everyone. comrade.
[16:45] <geser> directhex: "motu is too large"?
[16:45] <directhex> geser, i mean their remit. the number of things the motu people need to look after is too large
[16:45] <directhex> geser, too thinly spread
[16:46] <slytherin> directhex: MOTU is not too large. Number of packages owned bu MOTU are too large. MOTU team is too small to handle all that.
[16:46] <directhex> slytherin, that's what i meant. i phrased it badly
[16:47] <the-dude> so how does it work? anyone with access can just upload en new package if they feel like it?
[16:47] <directhex> right
[16:47] <directhex> ehm, i mean an *updated package* there
[16:48] <directhex> for brand new packages, yes they can go in directly for those with appropriate rights, but sometimes it's better to do the peer review thing via revu
[16:48]  * ScottK has always done so even though it's not required.
[16:49] <the-dude> hmm it sounds a bit weird
[16:49] <the-dude> sounds like something that could get messy
[16:50] <directhex> it tends to work. ish.
[16:50] <ScottK> It could, but we generally work as a team and communicate a lot when needed, so it rarely has problems.
[16:50] <slytherin> the-dude: Not when everyone is co-operative and no one goes into uploading packages at random without asking previous uploaders.
[16:50] <directhex> we're all one big huggy family!
[16:51]  * geser hugs directhex :)
[16:51]  * slytherin got to go
[16:51] <the-dude> it sounds to good to be true ;)
[16:52] <directhex> to an extent, what happens is a package doesn't *formally* have an owner, but there's an unofficial "who touched it last" thing where it ends up being considered as someone's "area of expertise". such that even though you can update it directly for something, you may just want to double-check with whomever touched it last over things they might be more knowledgable about
[16:52] <directhex> which works for me
[16:53] <Laney> I just think we need better processes for taking care of our local packages
[16:53] <the-dude> but do developers get access to all branches?
[16:53] <directhex> this is my package. there are many like it but this one is mine
[16:58] <geser> the-dude: what you mean with branches in the packages context?
[17:15] <the-dude> geser: development testing stable
[17:16] <the-dude> like jaunty en hardy en inteprid?
[17:18] <geser> for the development version any developer can upload
[17:19] <ScottK> Also true for stable release, just nothing gets accepted without archive admin approval.
[17:36] <ScottK> Someone who cares about Gnome might want to go through gnome-core-devel and remove obsolete (no longer in the archive) packages as it's currently uninstallable in Karmic
[17:48] <ScottK> I'd be willing to help a newcomer with this if they are interested in doing it.
[18:18] <jbernard_> ScottK: im happy to take a look
[18:18] <ScottK> jbernard_: Great.
[18:18] <jbernard_> ScottK: libeel2-dev needs to be removed
[18:18] <ScottK> jbernard_: At least.  Not sure what else.
[18:19] <jbernard_> ScottK: what is the workflow for making sure i've found them all?
[18:19] <ScottK> jbernard_: Are you on karmic?
[18:19] <jbernard_> ScottK: yep
[18:19] <jbernard_> ScottK: i suppose i could keep rebuilding the package without the missing depends
[18:20] <jbernard_> ScottK: until all can be resolved
[18:20] <jbernard_> ScottK: is there a better way?
[18:20] <ScottK> That or look up to see that the all still exist in LP or using rmadison would be the other choice.
[18:20] <ScottK> Neither one is particulalry appealing, but up to you
[18:21] <jbernard_> ok, ill take a look and see what i can come up with
[18:21] <ScottK> Great.    I do read the scrollback if I'm pinged.
[18:25] <ahe> i uploaded a package of a pure ruby application to my ppa and it was built fine and the packages platform is all but still on my ppa page it is shown under i386 build
[18:25] <ahe> is this normal or is there something wrong?
[18:26] <jacob> ahe: if the arch is "all" then they always seem to build on the i386 machines
[18:26] <jacob> just make sure that the output packages end in _all.deb and you should be fine
[18:27] <ahe> ah ok
[18:27] <ahe> thx, so everything is ok
[18:27] <jacob> yep
[18:38] <jbernard_> ScottK: just libeel2-dev
[18:38] <ScottK> jbernard_: Excellent.  Make a debdiff in a bug and ping me with the bug number.  I'll send it right up.
[18:39] <jbernard_> ScottK: im on it
[18:39]  * ScottK out for a bit jbernard_.
[18:46] <jbernard_> ScottK: bug #393834
[19:05] <RoAkSoAx> bdrung, congrats!!
[19:06] <bdrung> RoAkSoAx: dito
[19:06] <fabrice_sp> RoAkSoAx, congrats also to you!
[19:06] <fabrice_sp> bdrung, congrats :-)
[19:06] <RoAkSoAx> thanks fabrice_sp :)
[19:06] <bdrung> thanks
[19:07] <mfoster> hi folks, I have a question. If I have want to overlay a patchset (from a tarball) onto a package prior to building what's the right way to do that?
[19:07] <bdrung> mfoster: using a patch system
[19:08]  * RainCT ended up compeletely messing up his system (or maybe not, but anyway) and decided it's time to try out Debian for another week :P
[19:08] <mfoster> would I put the tarball into the patch folder and extract it in the rules file?
[19:08] <bdrung> cdbs'es simple-patchsys, quilt or dpatch
[19:08] <fabrice_sp> somebody willing to testbuild the fix in bug #427025 ? I've been able to build it in 2 different computers, but it's FTBFS to Daneil
[19:09] <RainCT> But Lenny feels outdated, how does one live in testing (eg. compared to a late Ubuntu alpha)?
[19:09] <fabrice_sp> or even upload it ;-) (after building it)
[19:11] <mfoster> let me rephrase my question a little. I have a tarball containing source code (not patches), how do I incorporate it into my package. The URL is http://www.grid.net.ru/nginx/upload.en.html (it's a 3rd party module for nginx)
[19:14] <bdrung> fabrice_sp: i test it now
[19:14] <fabrice_sp> cool thanks!
[19:15] <bdrung> mfoster: you can create a patch out of it
[19:16] <DktrKranz> hey RoAkSoAx, congrats!
[19:17] <sluimers> Hello, I've got a question, how do I get a screenshot in my package? You know, the one you see in the desciption of a package.
[19:17] <DktrKranz> sluimers: screenshots.debian.net
[19:17] <RainCT> sluimers: upload it to http://screenshots.debian.net/
[19:17] <RainCT> DktrKranz: *grrr* :)
[19:17] <DktrKranz> RainCT: slooooooooow :P
[19:17] <sluimers> thanks guys :)
[19:18] <RoAkSoAx> DktrKranz, thanks man :)
[19:18] <DktrKranz> so you don't need me to stress your packages anymore :P
[19:19] <bdrung> fabrice_sp: i get the same error like dholbach. i used pbuilder on amd64
[19:20] <RoAkSoAx> DktrKranz, haha :)
[19:21] <POX> fabrice_sp: fix for 427025 will be uploaded to Debian in ~15 minutes
[19:22] <DktrKranz> RoAkSoAx: you probably will on Debian side, but you're safe at least on Ubuntu :)
[19:23] <RoAkSoAx> DktrKranz, haha yeah. I actually have to get lekhonee into Debian xD
[19:23] <DktrKranz> whooops
[19:32] <fabrice_sp> bdrung, I've used sbuild on amd64 and pbuilder on i386. Strange. Anyway, I'll wait for the fix in Debian and request the sync then
[19:32] <fabrice_sp> thanks bdrung and POX
[19:32] <randomaction> fabrice_sp: it FTBFS, I get the same error as dholbach but on i386
[19:38] <Laney> RainCT: did you roll back those ubuntu-boot packages?
[19:39] <RainCT> Laney: Yeah, reverted them using a server CD in rescue mode, but then I got an error about /proc being a symlink. I've removed that now so maybe it'd work now, but I'll give Debian another try anyway :P
[19:39] <Laney> haha
[19:39] <Laney> I was hoping for a handy command to copy
[19:40] <RainCT> Laney: Heh. Same problem??
[19:40] <Laney> it's unbootable
[19:40] <Laney> sreadahead problems or something
[19:40] <RainCT> I understand how you feel... *g*
[19:41] <RainCT> Laney: well what I've done is just   sudo dpkg -i /var/cache/apt/archives/<previous package>.deb   inside a chroot
[19:41] <fabrice_sp> POX, do you mean the problem in pycryptopp or the problem in the build (KeyError:...)?
[19:42] <fabrice_sp> because the package was building fine yesterday, and it fails now
[19:43] <fabrice_sp> by the way, it's failing also now in my sbuild
[19:46] <POX> fabrice_sp: works fine with python2.6 from experimental
[19:47] <randomaction> could that be caused by new python packages in karmic?
[19:48] <fabrice_sp> surely: it was buillding yesterday, and it's failing today
[19:49] <blackxored> hi, I could probably spent some more time maintaining my packages as a MOTU in ubuntu, are you interested????
[19:51] <RainCT> blackxored: I'm not sure if I follow.. But, help is always welcome :)
[19:51] <blackxored> RainCT, probably focused the statement wrongly, so here it goes again
[19:52] <blackxored> I could probably use some of my time to contribute to ubuntu as well, initially syncing or merging my debian packages there, got it?
[19:52] <blackxored> on a regular basis
[19:53] <blackxored> and I was wondered if that could be useful, so, if you guys are interested
[19:53] <blackxored> s/wondered/wondering
[19:55] <fabrice_sp> blackxored, as stated RainCT, any help is welcome :-)
[19:55] <blackxored> fabrice_sp, fine then\
[19:55] <blackxored> although slytherin has taken this round
[19:55] <blackxored> I'll be up for the next one ;)
[19:56] <fabrice_sp> blackxored, did you subscribed to bug mail of your package?
[19:56] <blackxored> fabrice_sp, (s) yes
[19:57] <fabrice_sp> good starting point :-)
[19:57] <blackxored> fabrice_sp, I've been marking fixing bugs there
[19:57] <fabrice_sp> ok
[19:59] <blackxored> fabrice_sp, great then
[19:59] <fabrice_sp> also, do you know about the FTBFS page?
[20:00] <blackxored> fabrice_sp, sure
[20:00] <fabrice_sp> so you already know everything :-)
[20:00] <blackxored> fabrice_sp, far from that :D
[20:02] <fabrice_sp> :-)
[20:04] <blackxored> fabrice_sp, ok, back to work, glad to know i can contribute here too :D
[20:05] <fabrice_sp> thanks for your contributions :-)
[20:05] <fabrice_sp> (in advance ;-) )
[20:05] <bdrung> blackxored: have fun with digging through eclipse bug reports
[20:06] <blackxored> bdrung, hi, no that's nthykier's job :D hehehe
[20:06] <fabrice_sp> python2.6 has been updated yesterday, and I supect to be that upgrade the root cause of the new FTBFS
[20:06]  * fabrice_sp reports a bug againt pyton2.6
[20:06] <bdrung> blackxored: then you can digg through the vlc bugs :p
[20:07] <bdrung> fabrice_sp: sounds plausible
[20:07] <blackxored> bdrung, I love vlc :D
[20:07] <blackxored> bdrung, did you manage to fix the bug that prevents eclipse-platform from building???
[20:08] <fabrice_sp> bdrung, I've both logs, and it's the only difference (in term of versions)
[20:10] <blackxored> bdrung, ???
[20:11] <bdrung> yes
[20:11] <bdrung> it builds
[20:11] <blackxored> bdrung, ^^^^
[20:11] <blackxored> great, so that lets only eclipse left
[20:11] <bdrung> blackxored: do you like this bug list, too? https://launchpad.net/ubuntu/+source/vlc/+bugs
[20:12]  * blackxored has no comments about that list ;)
[20:13]  * blackxored thanks an entire bugsquad team should be created for that :D
[20:13] <bdrung> then have a look at the linux package: 5780 bugs
[20:14] <blackxored> bdrung, yes but that is sort of general
[20:14] <blackxored> bdrung, and thanks for the bug survey :D you almost made me cry
[20:15] <bdrung> blackxored: ubuntu has more users than debian and therefore more bug reports
[20:16] <blackxored> bdrung, yes I know, I'm one of them :D
[20:17]  * bdrung will now install karmic
[20:46] <ScottK> jbernard_: Looking.
[20:47] <ScottK> jbernard_: Generally I'd prefer to include why in debian/changelog and also close the bug in changelog too.  Care to fix it up or would you rather i  did?
[20:47] <jbernard_> ScottK: im on it
[20:47] <ScottK> jbernard_: Great.  Ping me again when ready.
[20:59] <jbernard_> ScottK: ok, that should be much better
[20:59]  * ScottK looks again
[21:00] <ScottK> Looks much better.
[21:00] <jbernard_> thanks!
[21:01] <fabrice_sp> Can some MOTU have a look at sync request in bug #416262 ? It would allow us to close most of the bugs in aptoncd.
[21:10] <ScottK> jbernard_: Uploaded.  Thank you for your contribution to Ubuntu.
[21:11] <ScottK> jbernard_: A couple of comments for you ....
[21:11] <ScottK> 1.  No need to edit both control.in and control.  If control.in is changed, control will get regenerated automatically.
[21:11] <ScottK> 2.  There's a new poilcy on maintainer, and all Ubuntu packages (Universe and Main) should now be Ubuntu Developers<EMAIL_ADDRESS>[21:12] <ScottK> I fixed the second one before I uploaded.
[21:12] <ScottK> jbernard_: Want another one?
[21:14] <jbernard_> ScottK: Re: #1, that is true but both control and control.in were present in the source so I figured I'd be thourough
[21:14] <ScottK> jbernard_: It doesn't hurt, but it's extra work.
[21:14] <jbernard_> ScottK: sure, whaddya got?
[21:14] <ScottK> jbernard_: Make gwp buildable.
[21:16] <jbernard_> ScottK: ill take a look
[21:16] <jbernard_> ScottK: how long before the new gnome-core-devel hits the archive?
[21:16] <ScottK> Likely an hour and a half for fast archs.
[21:17] <jbernard_> ok, lemme see what i can come up with
[21:18] <ScottK> jbernard_: It's about built on i386: https://launchpad.net/ubuntu/+source/meta-gnome2/1:2.22.2~4ubuntu7/+build/1238038
[21:18] <ScottK> So publisher run starts at :03 and finishes ~:45, so ~2145 UTC.
[21:51] <jbernard_> ScottK: with gnome-core-devel in incoming, gwp builds successful
[21:52] <jbernard_> ScottK: ive got version 0.4.0-1.2
[22:36] <segler> hello, i programmed a rhythmbox plugin, and i want it to get into universe. i uploaded it to revu. but it says to me, that i should use another maintainer e-mail address. something with  @ubuntu.com. what should i do? which adress is the right one?
[22:45] <jbernard_> segler: i believe the maintainer field should be: "Ubuntu Developers<EMAIL_ADDRESS>[23:13] <soren> How many release team members need to ACK an FFe?
[23:14] <arand> Does Hardy handle the ~ in package vsersion differently? Since I have a Hardy box where it prefers *-0ubuntu1.1 over *-0ubuntu1.1~arand-* ¤ Whereas on intrepid, it prefers *-0ubuntu2.1~arand-* over *-0ubuntu2.1
[23:14] <Laney> arand: do some dpkg --compare-versions experimentation
[23:19] <arand> Laney: oh, nvm, it was the right way around on hardy, /me is blind.
[23:20] <Laney> soren: always was 2 previously
[23:20] <Laney> related, do release teams need to ack removals? I guess yes
[23:21] <soren> Laney: I see. I couldn't find that mentioned anywhere on the wiki.
[23:21] <soren> It's a big wiki, though. I may have missed it.
[23:22] <Laney> soren: https://wiki.ubuntu.com/FreezeExceptionProcess#Exceptions%20for%20Universe/Multiverse
[23:22] <soren> Laney: Oh, there it is.
[23:23] <soren> Laney: Ah, no, that's for new upstream versions.
[23:23] <soren> Laney: This is a new package.
[23:23] <Laney> I don't know why it always talks about new upstream releases
[23:23] <soren> Anyhow, if a friendly motu-release team member would be so kind to give bug #427581 a quick glance, it would be much appreciated.
[23:23] <Laney> I think it's the policy for all FFes
[23:23] <Laney> but what do I know!
[23:23] <soren> Laney: Possiblu.
[23:23] <soren> Bah.
[23:23] <soren> Possibly, even.
[23:24] <soren> Blimey, that's a long list! https://bugs.edge.launchpad.net/~motu-release/+subscribedbugs
[23:26] <Laney> motu-release: please make the page clearer :)
[23:31] <chrisccoulson> i take it that motu-release need to ACK package removals too?
[23:33] <Laney> trying to find out
[23:33] <chrisccoulson> Laney - thanks. Did I ask you a similar question earlier? sorry if I already did - it's been a busy day ;)
[23:43] <segler> please motu team, comment on my small rhythmbox plugin i uploaded http://revu.ubuntuwire.com/p/rhythmbox-radio-browser
[23:47] <Laney> chrisccoulson: You mentioned it, and I'm interested in finding out the answer too