[00:12] <ebroder> cjwatson: Figured out bdrung's grub issue. The lua warning was a red herring. It was actually erroring out because older versions of grub can't handle if statements in menuentry blocks
[00:14] <bdrung> ebroder: so it was an issue that multiple user will face.
[00:15] <ebroder> bdrung: Only if they, like you, clicked through the screen where cjwatson yelled at you for leaving grub-pc/install_devices blank
[00:15] <ebroder> bdrung: I think we can work around it fairly easy and build a configuration that's backwards compatible
[00:16] <ebroder> *easily
[00:17] <ari-tczew> grub2 in natty is corrupteD?
[00:17] <ari-tczew> I saw some messages there and I'm afraid to install upgrades
[00:17] <ari-tczew> now I have grub2 1.98 and it going to be upgraded to 1.99
[00:17] <ebroder> If you upgraded from an older release and you agreed to the debconf prompt that warned you you were shooting yourself in the foot
[00:19] <ebroder> ari-tczew: if "debconf-show grub-pc | grep 'grub-pc/install_devices:'" is not empty, you should be fine
[00:20] <ebroder> But I'm going to send cjwatson a patch to fix the issue anyway
[00:21] <ari-tczew> ebroder: * grub-pc/install_devices: /dev/disk/by-id/ata blah blah blah ;)
[00:21] <ari-tczew> but what about upgrade to grub2 1.99?
[00:21] <ebroder> ari-tczew: Then you are safe, at least from this issue
[00:21] <ari-tczew> it will lost this file?
[00:31] <ebroder> bdrung: You didn't find or open a bug about the GRUB thing, did you?
[00:34] <bdrung> ebroder: nope, i didn't
[04:39] <robert_ancell> @pilot in
[04:41] <leftyfb> I created a new project on launchpad which will use the pidgin code-base as it's base with a bunch of patches and rebranding. Do I want to "mirror" the pidgin bzr in lp or import it into my project? And after that, do I branch from there to apply my patches?
[07:13] <pitti> Good morning
[07:16] <bilalakhtar> Good morning pitti !
[07:16] <bilalakhtar> pitti: And, thanks for that ureadahead upload! I had almost forgotten that I had worked on it
[07:16] <pitti> hey bilalakhtar, how are you? had a nice weekend?
[07:17] <bilalakhtar> pitti: Fine, you? How was your weekend?
[07:21] <pitti> bilalakhtar: quite nice! went to Munich with my wife (she's doing her final thesis here)
[07:22] <bilalakhtar> Munich! wow! I guess you live in berlin?
[07:22] <bilalakhtar> (or somewhere else in Germany)
[07:22] <pitti> in Dresden
[07:22] <bilalakhtar> hmm
[07:24] <pitti> cjwatson: can I just bzr commit in cdimage@antimony:~/cdimage ? I want to remove the ubuntu-netbook cronjob
[07:37] <micahg> pitti: good morning
[07:39] <micahg> is there any trick to not regenerate PO files if there's a clean rule to regenerate or do I just have to edit the .debian.tar.gz and resign?
[07:45] <pitti> micahg: the buildd cleans, as far as I know, so no
[07:45] <pitti> but updating po files on clean is pretty nasty anyway
[07:45] <pitti> this shouldn't ever be done automatically IMHO
[07:46] <micahg> pitti: should I bother editing the .diff.gz then?  it makes a useless diff with Debian
[07:46] <micahg> I'll file a bug with Debian about the rule
[07:46] <pitti> micahg: and sending the fix to Debian?
[07:46] <pitti> micahg: does it actually cause a build failure?
[07:47] <pitti> if not, and it's just about the noise, then I would just ask Debian to fix that and not bother
[07:47] <micahg> pitti: well, I was just going to delete the PO stuff from the diff.gz and resign, no, it shouldn't it just updates the create date
[07:47] <pitti> they asked for it, they got it :)
[07:47] <didrocks> good morning
[07:47] <pitti> that should work, too
[07:47] <pitti> hey didrocks
[07:47] <micahg> ok, thanks pitti
[07:47] <didrocks> Guten Morgen pitti, did you have a good week-end?
[07:49]  * micahg forgot, there's not a diff in this case :(
[07:53] <pitti> didrocks: I disabled the ubuntu-netbook CD cron job now, FYI
[07:54] <didrocks> pitti: oh, I was thinking it was done already (disabled for i386 and amd64/powerpc), will it still build armel?
[07:54] <pitti> cjwatson, didrocks: I'd like to remove the entire cdimage/www/full/ubuntu-netbook/ directory to avoid confusion, is that ok for you?
[07:54] <pitti> didrocks: oh, it's still supposed to build for armel?
[07:55] <pitti> didrocks: ah, that's daily-preinstalled, right?
[07:55] <pitti> not daily-live
[07:55] <didrocks> pitti: yeah, hence my all headaches in transitionning for the seed/meta/netbook-default-settings
[07:55] <didrocks> daily-live IIRC, but better to check with ogra
[07:55] <pitti> cjwatson: ok, so we should just remove daily-live, but keep daily-preinstalled and ports
[07:56] <dholbach> good morning!
[07:56] <didrocks> hey dholbach
[09:26] <quadrispro> hi all!
[09:27] <quadrispro> pitti, I've been working on scour for Debian, I cannot find any copyright/license information about debian/* files
[09:27] <quadrispro> (I mean: in Natty's package)
[09:28] <pitti> quadrispro: I don't like separate licenses for debian/* stuff, I usually want them to have the same license as the main source
[09:28] <pitti> quadrispro: so it's meant to fall under the "*" catch-all
[09:28] <pitti> quadrispro: but if you care, I can add a separate stanza for debian/*, with Canonical copyright and Apache license
[09:30] <quadrispro> pitti, I'm going to push the packaging to collab-maint's git area, so feel free so add whatever you want :) (including your name <email> in the Uploaders field)
[09:30] <pitti> quadrispro: I'd like to be an uploader indeed; then I can upload to Debian and sync
[09:30] <pitti> quadrispro: cool, thank you!
[09:35] <quadrispro> pitti, you're welcome -> http://git.debian.org/?p=collab-maint/scour.git
[09:39] <pitti> quadrispro: pushed my "Uploaders:" addition
[09:40] <pitti> quadrispro: pushed debian/copyright update, too
[09:41] <pitti> quadrispro: hm, which version did you take? dh_scour is too old in the Debian version
[09:41] <pitti> quadrispro: and it seems it's missing the dh sequencer?
[09:41] <pitti> quadrispro: please don't upload this yet, I want to update these
[09:42] <quadrispro> oh yes, it is so, I've taken an old one
[09:43] <pitti> quadrispro: ok, all pushed, I'm happy now
[09:44] <pitti> quadrispro: thanks for bringing this to Debian
[09:44] <quadrispro> pitti, thanks for the great work!
[09:49] <xxtjaxx> fabbione: ping
[09:58] <quadrispro> pitti, we could grab new upstream releases by uscan --force-download --repack --rename so we don't need the current get-orig-source
[09:59] <dholbach> bdrung, thanks a lot for making http://reqorts.qa.ubuntu.com/reports/sponsoring/ more readable!
[09:59] <quadrispro> pitti, maybe would be more useful a snippet to repack sources grab'd from bazaar
[09:59] <pitti> quadrispro: ah, nice; feel free to drop it
[10:01] <seb128> dholbach, what changed? out of the weird alignment of stats?
[10:02] <seb128> like the title are on the right columns and the values on the left one? it's weird
[10:03] <dholbach> seb128, the stats I don't know, but the rest is more compact and more readable
[10:09] <fabbione> xxtjaxx: pong
[10:12] <xxtjaxx> fabbione: magnificent! Say you packaged corosync didnt you?
[10:13] <fabbione> xxtjaxx: many many moons ago....
[10:13] <fabbione> xxtjaxx: haven't touched it in ages
[10:13] <fabbione> xxtjaxx: I am fairly confident debian has newer packages than the ones I did
[10:15] <fabbione> xxtjaxx: so what's the question? :)
[10:16] <xxtjaxx> fabbione: I try wrapping my head around it. seems different from a lot Im used to normally around debian.
[10:16] <xxtjaxx> its kinda hard to grasp. with the little documentation that is there. specially that the main goal is sheepdog. (for me)
[10:18] <fabbione> xxtjaxx: are you referring to the package itself or the upstream?
[10:19] <fabbione> xxtjaxx: the package is relatively straight forward IMHO. Understanding what corosync does no, it needs lots of reading about virtual syncrony and clusters
[10:19] <fabbione> xxtjaxx: and it's not something you learn from one day to another just because you wish to package somehting that uses it
[10:20] <fabbione> xxtjaxx: your average application runs on one machine, done. corosync is cluster.. runs on multiple machines at the same time, interact in real time, etc.
[10:20] <fabbione> xxtjaxx: it involves an extra level of complexity that's the whole cluster status/configuration/architecture/requirement/design/you_name_it
[10:21] <fabbione> xxtjaxx: but if you need more upstream docs, www.corosync.org -> get the latest and greatest and the complain to upstream mailing list :)
[10:21] <fabbione> xxtjaxx: upstream is also on #linux-cluster on freenode
[10:23] <xxtjaxx> fabbione: its eval...*ahem*
[10:24] <xxtjaxx> not packaging
[10:24] <fabbione> xxtjaxx: also note, that recent versions of corosync (aka get the latest and greatest) have more docs
[10:25] <fabbione> debian/ubuntu have been shipping ancient versions for sometime
[10:25] <xxtjaxx> at points I actually resorted to reading the code instead which made me cry at times :/
[10:26] <xxtjaxx> though that might have been sheepdog though.
[10:26] <fabbione> xxtjaxx: just go to upstream and ask for more docs, also look at the openais mailing list. that's a very good start
[10:26] <fabbione> upstream is not bad :)
[10:26] <fabbione> just overloaded with work
[10:26] <\sh> fabbione: corosync is only complicated when you run it with a Cisco ASA FW and the ASA runs in Multiple FW Context Setup...then you have problems with multicast, and you need to do some blackmagic on your switches to convert multicasts into broadcasts ;)
[10:27] <fabbione> \sh: not anymore.. corosync 1.3.0 will support other transport methods than multicast (like point to point)
[10:27] <xxtjaxx> interesting \sh
[10:27] <fabbione> \sh: plus.. corosync supports broadcast by default
[10:28] <fabbione> \sh: but 1.3.0 will have normal udp connections between nodes, no need of either multicast or broadcast
[10:28] <fabbione> alternatively go Infibarf^WInfiniband
[10:28] <\sh> fabbione: yes...but not when you want multicast by default...but you bought very big cisco foo ;) and this is the problem...not corosync ;)
[10:29] <fabbione> \sh: well multicast is problematic on many hw implementations. that's why we are adding also p2p
[10:29] <fabbione> tho I agree with you, multicast performs the best
[10:30] <fabbione> xxtjaxx: any more quick questions? gotta commute to the office :)
[10:31] <xxtjaxx> fabbione: go go Gonna poke them a'lil
[10:32] <fabbione> xxtjaxx: ok :)
[11:12] <cjwatson> pitti: no, please don't ever commit in ~/cdimage - 'bzr co bzr+ssh://antimony/srv/cdimage.ubuntu.com/bzr/private/cdimage' on your local system and work on it there, then 'bzr pull' in ~/cdimage after committing
[11:12] <cjwatson> pitti: removing the daily-live directory is fine - not the whole of ubuntu-netbook, as you say
[11:13] <pitti> cjwatson: ah, thanks for the heads-up
[11:16] <pitti> cjwatson: bzr diff currently shows some stuff in cdimage/, is that expected?
[11:17] <cjwatson> for the moment, yes
[11:17] <pitti> ok, done
[11:18] <cjwatson> those will need some thought
[11:20] <cjwatson> (but no rush)
[11:23] <ogra_ac_> janimo1, hey
[11:28] <bdrung> dholbach: you're welcome. now the statistics at the bottom needs an optical facelift.
[11:29] <dholbach> seb128, ^
[11:29] <dholbach> thanks bdrung
[11:29] <seb128> dholbach, right
[11:29] <seb128> the columns are weird
[11:30] <janimo1> ogra_ac_: hello
[12:01] <ogra_ac_> can some archive admin remove the linux-headers-omap binary (it should be NBS currently)
[12:02] <ogra_ac_> (it prevents omap4 images from being built)
[12:02] <apw> ogra_ac_, can we tell what is pulling that package into the image?
[12:03] <apw> as i suspect even if it is removed, they dep which is trying to pull it will just fail as badly
[12:03] <ogra_ac_> linux-omap very likely
[12:03] <ogra_ac_> which should be NBS too
[12:03] <apw> and someone must be pulling that in for it to be an issue
[12:04] <apw> i assume there is a like 'netbook-meta' package somewhere which has these kinds of things in it ?
[12:04] <cjwatson> http://people.canonical.com/~ubuntu-archive/NBS/linux-headers-omap
[12:05] <ogra_ac_> LIST="$LIST minimal^ standard^ ubuntu-netbook^" is what livecd-rootfs installs on armel
[12:05] <cjwatson> once all those dependencies go away, we'll remove it without you needing to ask
[12:05] <ogra_ac_> hum
[12:05] <cjwatson> I can reupload netbook-meta
[12:06] <cjwatson> I have no idea what's involved with powervr-omap3-dkms
[12:06] <ogra_ac_> why do we have -headers in such a high level seed at all ?
[12:06] <apw> cjwatson, ogra_ac_, i suspect it is the linux-headers-omap in the netbook-meta which is pulling this in and causing ogra_ac_'s problem
[12:06] <ogra_ac_> cjwatson, can go until we have a decision about omap3 kernels
[12:06] <apw> i suspect if we remove that then his issue will go away and we don't need to worry about the NBS
[12:06] <cjwatson> there are comments in the seed ...
[12:07] <cjwatson> I'll remove linux-headers-omap
[12:07] <cjwatson> apw: correct
[12:07] <cjwatson> from the seed, I mean
[12:07] <ogra_ac_> cjwatson, oh, i see
[12:07]  * ogra_ac_ only grepped instead of reading the seed file
[12:07] <ogra_ac_> cjwatson, powervr-omap3-dkms can go temporary too
[12:08] <ogra_ac_> i'll take care about re-adding either once we have a kernel decision (for A2 most likely)
[12:08] <cjwatson> can go what?
[12:08] <ogra_ac_> oh, where does that dep come from, that must be an rdep
[12:09] <cjwatson> if you mean removing the powervr-omap3 source package, please file a bug with rationale
[12:09] <cjwatson> however, as apw says, it's not relevant to your image build issues anyway
[12:09] <apw> ogra_ac_, its in universe so it can't be in the seeds right?  so it should be ok
[12:09] <cjwatson> so you can just ignore it if it's only going to be temporary
[12:09] <ogra_ac_> no, i dont want to remove it, i'll check with ricardo what to do about the dep
[12:09] <ogra_ac_> yep
[12:09] <ogra_ac_> apw, yep
[12:11] <cjwatson> netbook-meta uploaded
[12:21] <cjwatson> @pilot in
[12:24] <bdrung> dholbach: what do you think about this column order: http://people.ubuntu.com/~bdrung/sponsoring/
[12:52] <bilalakhtar> cjwatson: Could you please look at bug #682644? (since you are patch pilot ATM)
[12:52] <Laney> bilalakhtar: why not just wait for sponsoring as normal?
[12:53] <bilalakhtar> Laney: of course I can wait
[12:53] <Laney> I don't think patch piloting is about pinging to have your stuff sponsored straight away
[12:53] <bilalakhtar> let us see his response, if he's busy then I will wait
[12:54] <bilalakhtar> Laney: Even if it isn't, I just asked: Can you look
[12:56] <cjwatson> https://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews "patch pilots make themselves available on IRC"
[12:57] <cjwatson> bilalakhtar: sure, thanks!  will look in a few minutes
[12:57] <bilalakhtar> thanks a lot cjwatson ! Take your time, even if you take a year its fine :)
[12:59] <Laney> alright, I just didn't think that it was supposed to be a programme to get your stuff sponsored immediately
[12:59] <Laney> but as you wish
[12:59] <bilalakhtar> Laney: it isn't for that
[12:59] <bilalakhtar> its just for confirmation
[12:59] <bilalakhtar> Reading that page, it says:
[13:00] <bilalakhtar> 'Patch pilots help make patches ready for inclusion'
[13:00] <bilalakhtar> Not necessarily sponsorship
[13:04] <cjwatson> bilalakhtar: acked
[13:05] <bilalakhtar> cjwatson: :o Thanks!
[13:10] <dholbach> bdrung, I have no objections
[13:40] <cjwatson> FYI: I won't be doing any more autosyncs from Debian until after alpha-1 at this point.  File bugs if you have syncs that are urgent for alpha-1, but otherwise they'll get picked up on Friday
[13:42] <ogra_ac> doko, is there any chance we could get the workaround from the past comment for bug 675347 inot the archive before A1 ?
[13:43] <ogra_ac> (else i need to unseed a lot of stuff thats ftbfs due to it for alpha1)
[13:46] <ScottK> I am seeing quite a number of cases where symbols on C++ packages change between i386 and amd64 such as http://launchpadlibrarian.net/59618185/buildlog_ubuntu-natty-amd64.phonon_4:4.7.0really4.4.3-0ubuntu2_FAILEDTOBUILD.txt.gz - Is this now intentional?  IIRC, gcc-4.4 doesn't do this.
[13:47] <pitti> I think didrocks stumbled over that as well
[13:47] <pitti> if it's intentional, it's highly annoying
[13:48] <didrocks> yeah, I got that in nux as well
[13:52] <doko> which encoding did change, the one for i386 or amd64?
[14:00] <doko> didrocks: could you/desktop take care of the libgweather merge?
[14:02] <doko> ogra_ac: it *is* fixed, please open your eyes on Monday mornings
[14:03] <ogra_ac> doko, hmm
[14:03] <pitti> doko, didrocks: I can merge libgweather
[14:03] <doko> cool, thanks
[14:04] <didrocks> doko: pitti: thanks (sorry on mumble)
[14:04] <ogra_ac> doko, the tasks on bug 675347 are "In progress" and "Confirmed"
[14:10] <ogra_ac> didrocks, hmm, why do you build nux with -Werror ?
[14:13] <jmux> Hi. I'm trying to fix LP #478392. My problem seems to be, that /tmp is on a seperate partition and also /usr.
[14:13] <jmux> For me /tmp is mounted before /usr, but the mounted-tmp script wants to use find to clean /tmp and fails.
[14:13] <jmux> I tried to "start on (mounted MOUNTPOINT=/tmp and mounted MOUNTPOINT=/usr), but this deadlocks the boot process.
[14:14] <jmux> Any idea what's going on here?
[14:21] <cjwatson> bug 523587 is possibly more directly accurate
[14:21] <cjwatson> see particularly comment #8 in that bug
[14:22] <cjwatson> I suspect we need a dedicated C program to do this job
[14:23] <jmux> cjwatson: didn't find that one - thanks
[14:25] <cjwatson> SpamapS: did you see the upstream developer's comment on http://sourceforge.net/tracker/?func=detail&aid=3089978&group_id=65979&atid=512948 ?
[14:26] <hallyn_> cjwatson: you mentioned working to re-integrate casper/liveinitramfs.  dunno what all that entails, but if i can help, please let me know.
[14:28] <cjwatson> hallyn_: it's somewhere on my queue, but not hugely far up :-/
[14:29] <cjwatson> massive three-way merge exercise
[14:31] <ogra_ac> didrocks, oh, "configure: WARNING: unrecognized options: --disable-maintainer-mode" something is worng in nux, the option seems to be --enable-maintainer-flags=no
[14:31] <ogra_ac> not sure why that is, but i suspect that causes the ftbfs on arm
[14:34] <cjwatson> a configure warning won't cause a build failure by itself
[14:34] <ScottK> doko: The one for ad64, AFAIK, but it's happening on symbols that are new in the new upstream release so all I can really say is they are different.
[14:40] <ogra_ac> cjwatson, it sets Werror
[14:41] <ogra_ac> cjwatson, which i thoght we dont do on released tarballs
[14:41] <ogra_ac> at least thats what seb128 always tells me
[14:41] <ogra_ac> and i'm sure we have some warnings on armel
[14:41] <seb128> ogra_ac, we being?
[14:42] <seb128> usually GNOME doesn't set Werror in tarballs
[14:42] <seb128> but it's only GNOME
[14:42] <ogra_ac> seb128, ah, i thought we do the same on tarballs where we are upstream
[14:42] <ogra_ac> we being canonical
[14:42] <cjwatson> ogra_ac: oh, well, it depends
[14:43] <seb128> ogra_ac, dx has no rules as far as I know
[14:43] <ogra_ac> hmm
[14:43] <seb128> depends of whoever is working on it
[14:43] <cjwatson> people are entitled to use -Werror and accept that they'll have to clean up more build failures, IMO
[14:43] <ogra_ac> anyways we seem to hand over the wrong option for this configure
[14:44] <ogra_ac> since it expects --enable-maintainer-flags=no (or --disable-maintainer-flags)
[14:44] <seb128> Werror doesn't apply to configure
[14:44] <seb128> it's a compiler thing
[14:44] <ogra_ac> configure sets it in this case
[14:45] <ogra_ac> configure:         MAINTAINER_CFLAGS+="-Werror -Wall -Wcast-align -Wno-uninitialized -Wempty-body -Wformat-security -Winit-self"
[14:45] <seb128> well --enable-maintainer-flags=no is not what breaks
[14:45] <seb128> or was that just a side comment?
[14:45] <ogra_ac> thats what is set if --enable-maintainer-flags=no isnt set
[14:46] <cjwatson> ogra_ac: gcc cflags don't cause configure failures
[14:46] <cjwatson> not even if configure sets them
[14:46] <seb128> no, what he's saying is that Werror is set because the maintainer mode is on
[14:46] <cjwatson> oh, right
[14:46] <ogra_ac> yes
[14:46] <ogra_ac>  -Werror -Wall -Wcast-align -Wno-uninitialized -Wempty-body -Wformat-security -Winit-self
[14:46] <ogra_ac> is what i see on the compiler line
[14:47] <cjwatson> well, trivial debian/rules change then.  or just fix the compiler warning. :)
[14:47] <ogra_ac> well, i wanted to know if we have a general rule here like gnome
[14:47] <cjwatson> since the warning is about alignment, it's possible that if you disregard it that the program will crash, is it not?
[14:47] <ogra_ac> it would be nice to set one
[14:47] <cjwatson> I disagree
[14:47] <seb128> ogra_ac, dx-ers disagree
[14:47] <cjwatson> it depends very clearly on the package and on its upstream maintenance practices
[14:48] <seb128> they prefer to know about issues and fix those
[14:48] <ogra_ac> i dont care if it crashes since we cant run it anyway on armel atm
[14:48] <ogra_ac> currently the ftbfs just breaks my images
[14:48] <seb128> or at least some do
[14:48] <ogra_ac> and tehre is no working GLES support in unity yet
[14:48] <ogra_ac> but i dont want to useed all of unity
[14:49] <cjwatson> TBPH, if we set a rule, I'd prefer it to be on the side of enforcing warnings and making sure they get fixed (i.e. -Werror)
[14:49] <cjwatson> wouldn't it be quicker to fix the warning than to have this discussion, anyway? :)
[14:49] <ogra_ac> well, dh seems to try to set one by default
[14:49] <seb128> ogra_ac, well send a patch to didrocks to fix the aligment bug
[14:49] <ogra_ac> --disable-maintainer-mode"
[14:50] <cjwatson> ogra_ac: --disable-maintainer-mode has nothing to do with -Werror
[14:50] <seb128> didrocks or dx
[14:50] <cjwatson> see the autoconf documentation
[14:50] <seb128> MAINTAINER_CFLAGS=""
[14:50] <seb128> AS_IF([test "x$enable_maintainer_flags" = "xyes" && test "x$GCC" = "xyes"],
[14:50] <seb128>       [
[14:50] <seb128>          MAINTAINER_CFLAGS+="-Werror -Wall -Wcast-align -Wno-uninitialized -Wempty-body -Wformat-security -Winit-self"
[14:50] <seb128> cjwatson, ^ nux does that
[14:50] <didrocks> sorry, on the phone, fallbacking
[14:50] <didrocks> backlogging rather :)
[14:50] <cjwatson> seb128: I know.  but ogra_ac has the wrong end of the stick about dh.
[14:50] <pitti> cjwatson: well, we actually (mis?)use maintainer mode in udisks upstream to enable -Werror
[14:50] <ogra_ac> hmm
[14:50] <cjwatson> sorry, the automake documentation, not the autoconf documentation
[14:51] <cjwatson> pitti: sure, but in general it has nothing to do with that
[14:51] <seb128> pitti, nux?
[14:51] <cjwatson> http://paste.ubuntu.com/537916/
[14:51] <seb128> pitti, or you say udisks does the same?
[14:51] <pitti> seb128: nux what?
[14:51] <seb128> pitti, it fails to build
[14:51] <pitti> seb128: in udisks, we want people building git head to use -Werror, but we disable it for releases (i. e. for "make dist")
[14:51] <pitti> this seems to provide the best of both worlds
[14:52] <ogra_ac> pitti, right, that seems sensible to me
[14:52] <pitti> but FWIW, if packages use -Werror, I applaud them in general
[14:52] <seb128> pitti, right, that's what GNOME do
[14:53] <ogra_ac> cjwatson, hmm, so its Makefile.in vs configure ?
[14:53] <cjwatson> ogra_ac: no?
[14:54] <cjwatson> automake defines some macros which can be used by configure.ac
[14:54] <ogra_ac> right
[14:55] <ogra_ac> cjwatson, but the configure in nux doesnt know about maintainer-mode at all
[14:55] <ogra_ac> it doestn know about maintainer-flags though
[14:55] <ogra_ac> *does
[14:55] <ogra_ac> so i dont get where i'm wrong here, configure uses some non-std stuff it seems
[14:56] <seb128> it does right
[14:56] <seb128> still not sure to get what you argue about
[14:56] <seb128> just fix the alignment issue and you are done
[14:56] <cjwatson> ogra_ac: maintainer-mode is a *complete red herring*.
[14:56] <seb128> there is a real bug there in the code
[14:56] <ogra_ac> cjwatson, ah, now i get what you mean, ok
[14:57] <ogra_ac> seb128, i know, i wasnt asking about the bug but about our policy for Werror ;)
[14:57] <seb128> there is no such policy
[14:57] <ogra_ac> right, thats what i know now
[14:57] <ogra_ac> thanks
[14:57] <seb128> the maintainers do what they want
[14:58] <seb128> yw ;-)
[14:58] <andreoli> hi, not sure if this has already been reported; I just downloaded latest Ubuntu kernel from git (the maverick repository) and the last changelog entry seems borked
[14:59] <andreoli> it says UBUNTU: Ubuntu-2.6.32-23.40
[14:59] <andreoli> Shouldn't it be Ubuntu-2.6.35-23.40?
[14:59] <andreoli> I guess this breaks debian/rules insertchanges too
[14:59] <andreoli> any thoughts? thanks in advance
[15:00] <seb128> ogra_ac, didrocks: there is a bug on the configure.ac there though
[15:00] <seb128> the intend reading it is to not set Werror on even versions
[15:02] <cjwatson> andreoli: #ubuntu-kernel is probably a better place to ask
[15:02] <didrocks> ogra_ac: well, you have your own seed now, right? you can remove unity if it doesn't work there for armel, but agreed, I'll fix the right variable in configure
[15:03] <didrocks> seb128: hum, let me check this
[15:03] <andreoli> thx, sorry
[15:04] <didrocks> seb128: ok, I'll fix configure.ac as well :)
[15:05] <seb128> didrocks, eval(nux_minor_version % 2), [1], [yes], [no])])
[15:05] <seb128> didrocks, should be "micro" I think
[15:05] <seb128> didrocks, not sure if the intend is to pikc 0.9 as an unstable serie?
[15:05] <seb128> or 0.9.5 unstable and 0.9.6 stable
[15:06] <ogra> didrocks, well, we aim to ship unity
[15:06] <didrocks> seb128: yeah, it wasn't the case with the first versionning :)
[15:06] <didrocks> ogra: right, but with alignment errors, you will ship a crashing unity
[15:06] <didrocks> seb128: so, changing to micro and testing there, thanks!
[15:06] <ogra> didrocks, right, as long as GLES doesnt work i dont really care
[15:08] <didrocks> ok :)
[15:08] <didrocks> anyway, there will be a new nux release tonight, will ship the fixes with the new upload
[15:17] <didrocks> ogra: where did you saw this maintainer-mode btw? debian/rules don't call it (only --enable-documentation)
[15:18] <ogra> didrocks, in the build log, dh sets it
[15:18] <didrocks> ok, so it should be maintainer mode, not maintainer-flags in configure.ac
[15:18] <didrocks> so, that + even/odd number handling
[15:18] <didrocks> ok, fixing in nux upstream
[15:18] <didrocks> thanks :)
[15:19] <didrocks> ogra: apart from that, all is working fine regards to -settings package, metapackage and seed? (as I couldn't test on armel)
[15:20] <ogra> didrocks, well, its still failing to build images due to to many ftbfs
[15:20] <ogra> just trying to sort these
[15:21] <didrocks> ogra: but not due to package I transitionned?
[15:21] <ogra> nope
[15:21] <didrocks> phew :)
[15:42] <xnox> bdrung, micahg: please sponsor xiphos for xulrunner-2.0 and gtkhtml transitions: https://launchpad.net/bugs/682704
[15:42] <xnox> or shall I ping patch pilots?
[15:47] <RoAkSoAx> kirkland- lp~andreserl/powernap/powernap-add-actions
[15:52] <cjwatson> xnox: if you already know whom to ask, you don't need a pilot to guide you :)
[15:52] <cjwatson> (don't believe that Robert has actually been on patch pilot duty for >11 hours)
[16:05] <cjwatson> pitti,dpm: looks like one of you guys would need to deal with bug 632760 - can you?
[16:05] <cjwatson> Arne's provided directions
[16:15] <dpm> thanks for the heads up cjwatson, I haven't got commit access to langpack-o-matic, and it also seems that upstream now packages xpi files differently, so I'm not sure if the fix will apply for natty. chrisccoulson, perhaps we could discuss this ^ on our call tomorrow?
[16:16] <chrisccoulson> i thought that one got fixed a while back
[16:17] <chrisccoulson> perhaps we still need to rebuild some language packs
[16:17] <chrisccoulson> now i'm confused
[16:18] <bdrung> xnox: i would if BlackZ wouldn't be faster than me. :)
[16:18] <chrisccoulson> i supplied a patch to po2xpi, which pitti applied (with a small correction), which fixed what i thought the problem was
[16:18] <chrisccoulson> this process is too complex ;)
[16:19] <dpm> chrisccoulson, let me ask the Brazilian guys if that bug was fixed for them in the final language packs and see if they can provide some feedback in the bug
[16:20] <xnox> cjwatson, kk =) lol.
[16:20] <chrisccoulson> the patch pitti applied definately fixed the en-GB one, once they were rebuilt
[16:20] <xnox> bdrung, =) Lol Thanks.
[16:21] <xnox> BlackZ, hello there =) thanks for xiphos sync ack.
[16:22] <bdrung> xnox: the response time for sync requests is very short in most cases (countable in hours)
[16:22] <dpm> chrisccoulson, it might have been something else, as it seems po2xpi hasn't had any changes for a while: https://code.launchpad.net/~mozillateam/rosetta/po2xpi, and Arne's branch wasn't merged, either: http://bazaar.launchpad.net/~arnegoetje/rosetta/po2xpi-arne/changes. pitti might be able to tell us more
[16:23] <xnox> bdrung, hmm =) ok. It's just that it did take a while to propagate in debian experimental and to lp.net/debian/experimental. So I couldn'† get syncrequest straight after upload to debian.
[16:23] <xnox> ~ 1 day in total then ;-)
[16:24] <chrisccoulson> this is why i'm so confused, it all seems to happen by magic atm ;)
[16:26] <RenatoSilva> cyphermox: I have a patch for a new feature on a specific project, but I'm lazy to create an account on their tracker and I think they don't care too much about it.
[16:27] <chrisccoulson> being lazy is no excuse ;)
[16:27] <chrisccoulson> and "i think" means that you aren't really all that sure that they don't care
[16:27] <RenatoSilva> living in the stone age of computing is
[16:28] <cyphermox> RenatoSilva, usually if the patch does something useful people will be happy to accept it.. but why don't you share a bit more... what did you patch? what does your patch do? :)
[16:29] <RenatoSilva> "I think" means I think, don't try guessing why I think that, thanks
[16:29] <cyphermox> RenatoSilva, we can certainly help you work on getting it upstream and in Ubuntu
[16:32] <RenatoSilva> cyphermox: I know people are usually happy, but it's purple/pidgin
[16:34] <RenatoSilva> they caused a regression in debian and ubuntu because their build doesn't fail if you tell configure to incude non-existing stuff in the build. They renamed a component  and deb packages started to not include it anymore
[16:35] <cyphermox> RenatoSilva, ah, ok. is there a bug on launchpad about this? I would think it can be fixed by updating the way we call configure
[16:36] <RenatoSilva> yes there is, but the patch in not about it, it's just an example on how buggy pidgin /purple is
[16:37] <RenatoSilva> and mainly on how much they like to spend time calling their users idiots when they ask for fixing bugs and adding features
[16:37] <cyphermox> RenatoSilva, is there one for the bug you're fixing? -- also, I don't think it's very constructive to say a piece of software is buggy or complaining about the developers
[16:38] <RenatoSilva> well I just said "I think they don't care", someone instigated me to provide a reason
[16:39] <RenatoSilva> https://code.launchpad.net/~renatosilva/+junk/irchelper
[16:40] <RenatoSilva> http://bazaar.launchpad.net/~renatosilva/+junk/irchelper/revision/2
[16:41] <RenatoSilva> they'll likely say I'm an idiot because I neither want to save my password nor type /msg nickserv identify, but just a password dialog
[16:43] <RenatoSilva> I just wanted to share this as I think it's *obvious* you should ask password with a dialog if not saved, and also for avoiding repatching on updates
[16:47] <SpamapS> cjwatson: re libdbi upstream bug. I did, and I had a discussion with Markus and Thomas Goirand (the debian libdbi-drivers maintainer) about the test suite. Its changing in 0.9, which is why I wrote it independent of that since 0.9 is unreleased.
[16:47] <cyphermox> RenatoSilva, no, I think you're right on, it's useful to show a dialog. I *guess* it would be possible to include this, but in parallel you should still post it to the pidgin bug tracker or to their mailing list; but first this will need to be made into a patch, rather than a new bzr branch.
[16:48] <cjwatson> SpamapS: OK, just couldn't tell since the last message on the upstream bug report was a request to you
[16:48] <RenatoSilva> cyphermox: indeed, the regression bug 680820 was fixed with updating deb's source with the new name, but the problem still remains. If they rename some plugin again, regression will come back because there's no way to get noticed other than manually checking. An error is a way to notice deb devs they need to update their sources too. That's bug 681680
[16:51] <SpamapS> cjwatson: it came right before UDS .. must have gotten lost in the fray.
[16:51] <SpamapS> cjwatson: thanks for the bump.. I'll respond and make sure it gets on my TODO
[16:54] <RenatoSilva> cyphermox: before creating the branch I had sent a patch to the last author
[16:56]  * SpamapS wishes gnome terminal could decouple the alt-#'s from the tabs.. so he could alt-2 to get to window 2, not tab 2.
[17:02] <Laney>  
[17:08] <cyphermox> RenatoSilva, please, check http://plugins.guifications.org/trac/wiki/MailingLists and send your patches to the devel mailing list for the plugin pack developers, if you don't want to create a trac ticket
[17:09] <RenatoSilva> cyphermox: so if (after) they ignore it, a local ubuntu version is a non-go?
[17:16] <micahg> RenatoSilva: I would have thought you had an account already on their tracker, I'd be happy to fwd the patch for you
[17:16] <debfx> RenatoSilva: i'll add your patch to the package if upstream doesn't accept it
[17:16] <RenatoSilva> so do I file a LP bug or not?
[17:17] <RenatoSilva> or just the mailing list (writing email)?
[17:17] <RoAkSoAx> howdy I was wondering who's reviewing the packages in the NEW queue? I've been waiting for some binary packages to be approved for quite a while now!!
[17:17] <micahg> RenatoSilva: you filed the LP bug already
[17:17] <micahg> or so I thought
[17:18] <RenatoSilva> micahg: no micahg that's a third bug, it's a feature addition (although I find not having so boring that I personally would call it a bug fix but whatever)
[17:18] <RenatoSilva> micahg: if you use pidgin for irc, it simply doesn't ask your password if you don't save it
[17:19] <RenatoSilva> micahg: you have to send a message to nickserv for authenticating
[17:20] <lifeless> whats the shell syntax for 'variable value if set else some default' again ?
[17:20] <RenatoSilva> micahg: so I patched the irchelper plugin to help more, performing authentication by asking the nick password with a dialog, not requiring the user to save it or type boring nickserv commands all the time
[17:20] <lifeless> ${foo:default} ?
[17:21] <ebroder> ${foo:-default}
[17:21] <micahg> RenatoSilva: yeah, that would be annoying to pop up on login for people that don't want to auth
[17:21] <lifeless> ebroder: thanks!
[17:21] <ebroder> lifeless: I...think that will get both unset and empty. Try ${foo-default} for just unset, I think?
[17:22] <ebroder> Yeah, that's right
[17:22] <lifeless> ebroder: unset and empty would be appropriate
[17:22] <kees> lifeless: I ♥ the new librarian code!!! Old time to download: 4.7 hours. New time to download: 0.5 hours.
[17:22] <RenatoSilva> lifeless: http://www.pixelbeat.org/programming/shell_script_mistakes.html, section "stylistic issues" 3rd subsection
[17:23] <lifeless> kees: we've had to switch it off again for a bit - http://www.facebook.com/lifeless/posts/176534199039647?notif_t=feed_comment
[17:23] <kees> lifeless: well, whatever's happening, I'm not currently seeing any 503s.
[17:23] <lifeless> kees: thats great
[17:23] <kees> lifeless: that url is not public?
[17:23] <lifeless> kees: we've got a bunch of things all cooperating to make it better, I don't know which sorted it ;)
[17:24] <kees> heh
[17:24] <RoAkSoAx> kirkland: Howdy!! Just want to make sure you know where my latest branch is in case you missed it :): lp:~andreserl/powernap/powernap-add-actions
[17:24] <lifeless> kees: do you use facebook?
[17:25] <lifeless> kees: https://bugs.launchpad.net/launchpad-foundations/+bug/677270
[17:25] <kees> lifeless: yup, but I stay logged out.
[17:25] <lifeless> kees: may be my privacy settings too :)
[17:25] <ebroder> lifeless: BTW, the reference on the ${foo-bar}, etc. syntax is in bash(1), a couple screenfuls into the "Parameter Expansion" section
[17:25] <kirkland> RoAkSoAx: yup, got it!  I'm going through it now
[17:25] <lifeless> kees: friend me, if you like.
[17:26] <lifeless> RenatoSilva: ebroder: thank you
[17:26] <kees> lifeless: will do. I need to set up a few extra FB personas first
[17:26] <lifeless> kees: good kees, evil case?
[17:26] <kees> hehe
[17:26] <RoAkSoAx> kirkland: cool then :) thanks!!
[17:26] <cjwatson> @pilot out
[17:31] <RoAkSoAx> I was wondering who's reviewing the packages in the NEW queue? I've been waiting for some binary packages to be approved for quite a while now!!
[17:32] <cjwatson> RoAkSoAx: which ones?
[17:33] <cjwatson> I don't have time to do the whole thing but can look at ones that are urgent
[17:34] <micahg> xnox: sorry, someone beat me to it :)
[17:35] <RoAkSoAx> cjwatson: pacemaker :)
[17:36] <RoAkSoAx> cjwatson: I'm waiting on the approval of the binaries of pacemaker source to be able to reques the MIR's and finally get the cluster-stack in Main :)
[17:43] <cjwatson> RoAkSoAx: done, sorry for the delay
[17:44] <RoAkSoAx> cjwatson: no worries :). Thank you though!!:)
[18:04] <RenatoSilva> cyphermox, micahg: bug 682780
[18:04] <RenatoSilva> cyphermox, micahg: also email sent to their mailing list
[18:04] <cyphermox> RenatoSilva, awesome, thanks!
[18:33] <bilalakhtar> jdstrand: there>
[18:33] <bilalakhtar> ?
[18:34] <jdstrand> bilalakhtar: yes
[18:35] <bilalakhtar> jdstrand: About that ufw sync, would preventing the profiles from being installed in the ubuntu package be the better solution?
[18:35] <bilalakhtar> s/ubuntu\ package/ubuntu\ ufw\ package/
[18:35] <jdstrand> bilalakhtar: that is what I did in the past, yes
[18:35] <chrisccoulson> doko - any ideas why this fails? http://launchpadlibrarian.net/59796768/buildlog_ubuntu-natty-i386.thunderbird_3.1.7%2Bbuild1%2Bnobinonly-0ubuntu1_FAILEDTOBUILD.txt.gz
[18:36] <chrisccoulson> note, it already passes -lplds4, and it passes that after -lxpcom_core too
[18:36] <jdstrand> bilalakhtar: it isn't really hurting anything atm, so there is no rush
[18:36] <jdstrand> there are just redundant entries
[18:36] <bilalakhtar> jdstrand: okay, I am preparing a patch for it
[18:37] <jdstrand> bilalakhtar: thanks. attach it to a bug and I'll look at it
[18:37] <bilalakhtar> jdstrand: okay, filing a bug then. BTW, it would be a branch merge, since I prefer those
[18:37] <doko> chrisccoulson: this is odd: /usr/lib/libplds4.so: could not read symbols: Invalid operation
[18:38] <jdstrand> bilalakhtar: that is fine
[18:38] <chrisccoulson> doko - yeah, i wasn't sure if that was relevant or not
[18:38] <chrisccoulson> i'm just trying it locally now, but i've got a little while to wait still
[18:41] <doko> chrisccoulson: it's interesting how often the system libs are added on the command line. not sure, if mentioning all the static components before the system components would help
[18:41] <chrisccoulson> doko - yeah, i will try that
[18:52] <bilalakhtar> jdstrand: Done, bug #682811 . Thanks!
[18:55] <jdstrand> bilalakhtar: thank you
[18:55] <bilalakhtar> jdstrand: I should thank you!
[19:03] <RenatoSilva> thanks all
[19:14] <bilalakhtar> How do I find reverse-build-deps on an Ubuntu package?
[19:14] <ebroder> bilalakhtar: I think there's a tool in ubuntu-dev-tools
[19:15] <bilalakhtar> ebroder: thanks, got it
[19:15] <bilalakhtar> its in the description of ubuntu-dev-tools package
[19:24] <bilalakhtar> When I try to find out gcc-4.3 reverse build-deps on maverick, I get none. Can a natty user check this?
[19:25] <ScottK> bilalakhtar: You can check it from Maverick for natty if you add natty sources to your sources.list
[19:27] <bilalakhtar> ScottK: oh yeah, thanks
[19:28] <bilalakhtar> BTW, I just got reminded of this: Doesn't every package build-depend on build-essential?
[19:30] <ebroder> bilalakhtar: Implicitly, yes
[19:30] <bilalakhtar> ebroder: and then I don't think any package would be build-depending on gcc-4.3 anymore
[19:31] <cjwatson> jdstrand: sorry I didn't spot that the ufw profiles thing was intentional divergence from Debian
[19:32] <bilalakhtar> cjwatson: not yours, but my fault
[19:32] <bilalakhtar> I know that sponsorship is a boring job and people like to do it in a hurry
[19:33] <cjwatson> depends on the bugs you pick :)
[19:33] <jdstrand> cjwatson: no worries. it's on my todo list to work out that delta, but just a bit busy
[19:33] <jdstrand> and it is just a small issue anyway...
[19:35]  * bilalakhtar reads http://raphaelhertzog.com/2010/11/25/people-behind-debian-colin-watson/ and applauds cjwatson 
[19:37] <cjwatson> ta :)
[20:12] <cjwatson> ScottK,doko: did you two figure out what needs to be done about phonon/amd64?  it looks like a blocker for Kubuntu alpha-1 on amd64, looking at the knock-on issues
[20:12] <ScottK> cjwatson: No.  It affects other packages higher up on the KDE stack too.
[20:12] <cjwatson> yes, kdepim
[20:13] <cjwatson> (is the one I noticed)
[20:13] <doko> hmm, I'm not aware of anything ...
[20:13] <ScottK> kdegraphics as well
[20:13] <cjwatson> I've moved libphononexperimental4 to main, so you should be able to retry kdepim in half an hour or so
[20:13] <cjwatson> on i386
[20:13] <ScottK> Thanks.
[20:13] <cjwatson> assuming that's the only problem, anyway.  it's the only one 'chdist apt-get' told me about
[20:13] <Riddell> mm, I didn't notice that phonon hadn't compiled on amd64
[20:13] <Riddell> but it's just a symbols file issue, that can be fixed easily enough
[20:14] <cjwatson> Riddell: divergent on i386/amd64, though ...?
[20:14] <Riddell> it's in a library called "experimental" I'm not too fussed
[20:14] <cjwatson> I see you did the same for kdegraphics
[20:16] <cjwatson> Kubuntu/powerpc really isn't happy with life at all, is it
[20:16] <doko> ahh, the symbols issue
[20:17] <doko> would it be possible to extract something where the mangling is different when built with 4.4/4.5?
[20:20] <cjwatson> looks to me as though kde4libs/powerpc just needs a retry (it was due to libhupnp-dev not depending on libhupnp0) - I've kicked that off
[20:27] <ScottK> Looks like opengtl is likely affected as well (on the symbols issue for amd64)
[20:52] <chrisccoulson> doko - hmmm, the error message is misleading with the thunderbird build failure ("libxpcom_core.so: undefined reference to symbol 'PL_HashTableRawLookup'"). There are static archives listed after -lplds4 on the command line which also use that symbol (eg, libgklayout.a), which seem to be the real problem.
[20:52] <chrisccoulson> ie, if i move -lplds4 to the end, i can make the error go away (although, i get other link failures instead)
[20:53] <chrisccoulson> i guess i've got some work to do tonight to figure out the right order ;)
[21:28] <chrisccoulson> doko - ok, i got it linked now by rearranging quite a lot of options. the original error message seemed to be a red herring though :/
[21:28] <doko> sounds like fun =)
[21:44] <dobey> hrmm; maybe i'm doing something totally wrong
[21:45] <dobey> i'm trying to upload a new ubuntuone-dev-tools package to natty to get sponsored, but i keep getting a rejection e-mail about signer not being recognized
[21:45] <lamont> gah.  besides "run windows", how do I read a pdf that has a modify password but no read-only password?  the UI only allows non-null passwords
[21:45] <ebroder> lamont: Check out pdftk and see if it'll let you strip the password?
[21:45] <lamont> dobey: I suspect that there's a different process for sponsored uploads... nfc what  though
[21:45] <ebroder> (I think it will; I just don't remember the details)
[21:46] <lamont> checking
[21:46] <dobey> lamont: ui == evince, or acroread?
[21:47] <lamont> evince
[21:47] <lamont> acroread feels too close to "run windows" in my head most of thetime
[21:47] <dobey> lamont: install acroread? :) i think it's in the partner repo
[21:47] <dobey> ah
[21:47] <lamont> ISTR "run hardy" is another option
[21:47] <ScottK> lamont: How about okular?
[21:48] <dobey> "reboot to osx"
[21:48] <ScottK> AFAIK lamont doesn't run hardware that comes with that option.
[21:49] <ScottK> dobey: Are you uploading it to revu or ubuntu?
[21:49] <dobey> ScottK: ubuntu
[21:49] <lamont> ScottK: I suspect it's a libpopplar change that's killing me
[21:49] <lamont> dobey: no osx here
[21:49] <lamont> though I do actually have a G3 in the house
[21:49] <ScottK> lamont: Perhaps KDE is sufficiently out of sync it'll work.
[21:49] <lamont> heh
[21:49] <lamont> not that far out of sync - i first noticed this issue in karmic
[21:49] <ScottK> OK.
[21:50] <ScottK> Worth a try though.
[21:50] <lamont> gah. how do I get X to release my *(^)*(^^ cursor from the xchat window?
[21:50] <dobey> it's probably a ui issue; common "keep the do it button disabled until text is entered in the password entry" thing perhaps
[21:51] <dobey> https://wiki.ubuntu.com/UbuntuDevelopment/Sponsorship
[21:51] <dobey> well that's utterly not helpful :(
[21:51] <lamont> dobey: good point.  for an additional data point, pdfcrack finds the password of '' almost immediately
[21:51] <ScottK> dobey: If you aren't an Ubuntu developer, that won't work.  File a bug on the package in launchpad, attach either a debdiff for a new revision or the diff.gz for a new upstream version, and subscribe ubuntu-sponsors to the bug.
[21:52] <ScottK> lamont: I think okular has a non-default option to completely ignore the existance of passwords and just open stuff, but I may misremember.
[21:53] <robert_ancell> @pilot in
[21:53] <lamont> pdftk 112620109206.pdf input_pw '' output foo.pdf
[21:53] <lamont> Error: Failed to open PDF file:
[21:53] <lamont>    112620109206.pdf
[21:53] <lamont>    OWNER PASSWORD REQUIRED, but not given (or incorrect)
[21:53] <lamont> ebroder: ^^ not a solution
[21:53] <lamont> ScottK: that would be interesting
[21:53]  * lamont notes that on $OTHEROS, it just opens fine, never asks for a password
[21:53] <lamont> just sayin'
[21:54] <dobey> ScottK: even if i have rights to some packages, i can't dput it with it getting held in moderation for sponsorship?
[21:54] <ScottK> dobey: No.
[21:55] <dobey> oh boo
[23:22] <lool> cjwatson: Is there a place to track P-a-s bugs in Launchpad?  https://launchpad.net/packages-arch-specific doens't have Bugs enabled
[23:33] <ScottK> lool: I'd just make the change in debian/control of the package and not worry about it.
[23:34] <lool> ScottK: Not sure what you mean
[23:34] <lool> ScottK: This wont help for Launchpad to actually build stuff, will it?
[23:34] <ScottK> lool: I know it works for restricting stuff.  I'm not sure what happens if you try to be less restrictive than p-a-s.
[23:34] <lool> The Ubuntu branch is at ~ubuntu-core-dev/packages-arch-specific but I don't know how to track bugs when someone asks for an update
[23:35] <lool> ScottK: whatever you put in control will be ignored; it's only considered much latter
[23:35] <ScottK> lool: Not anymore.
[23:35] <lool> ScottK: Well in this case, control already lists armel, and the package wasn't built
[23:35] <ScottK> OK.
[23:36] <ScottK> So that answers the less restrictive question.
[23:36] <lool> ScottK: But now I'm curious  :-)  what do you mean with not anymore?  which scenario did you mean?
[23:36] <ScottK> The process is probably something like PM lamont and wait for magic.
[23:37] <lool> ScottK: Yeah, I think the process is push a fixed branch, wait, and upload; or push, wait, and ping Lamont to create a build record by hand
[23:37] <ScottK> If you have an arch any package that you want to build for a subset of archs, you can specify the architecture list in debian/control and the binary will only be built on the listed archs.
[23:37]  * ScottK needs to go.
[23:37] <lool> Oh right
[23:38] <lamont> there is no creating build records by hand... if you didn't get one when you uploaded, you re-upload after fixing things so you get one
[23:38] <lamont> PaS updates are automagic, ISTR somewhere around 2PM london time daily.... so if you're in a hurry, you have to get someone to get out and push
[23:40] <lamont> and on that note, afk for me for a while