[02:33] <psusi> cjwatson, what do you think about adding a test to partman-ext3's check.d to tell you ( roughly ) "hey dummy, you didn't set up an efi system partition and mount it in /boot/grub/efi"?
[02:33] <psusi> err, partman-efi rather
[02:51] <happyaron> infinity: beta image
[03:17] <smoser> slangasek, https://pastebin.canonical.com/107156/
[03:17] <smoser> that make any sense to you?
[03:17] <smoser> or anhyone else have ideas on how /etc/mtab got foobar'd to not include /
[03:17] <smoser> that is precise
[03:30] <psusi> smoser, that's odd.. I don't have access to that pastebin
[03:30] <smoser> bah.
[03:30] <smoser> yeah, that sucks.
[03:30] <smoser> here, repaste
[03:30] <psusi> smoser, but as a general rule, mtab gets foobared all kinds of ways, which is why upstream removed it some time ago
[03:30] <psusi> but we're still stuck on a very old util-linux
[03:31] <smoser> and replaced with link to /proc/mounts ?
[03:31] <psusi> yep
[03:31] <smoser> http://paste.ubuntu.com/7154679/
[03:32] <psusi> I've been trying to get it updated for some time... spoke with infinity last week and he said he would block out some time to do it properly instead of my kind of hackish update soon
[03:34] <psusi> ( basically I gave up on trying to identify which of the 1000+ commits in the debian repo that diverge from upstream actually matter and aren't already upstreamed and just threw them all out and copied the debian/ dir into the new upstream source and changed it to 3.0 quilt format )
[03:36] <psusi> which probably would have introduced a regression or two, but I thought was worth it to get a clean start on an updated upstream rather than spending days analyzing that many bloody commits to pick out the handful that actually needed ported to quilt
[04:42] <slangasek> smoser: if the rootfs was already mounted rw in the initramfs; or if the rootfs isn't listed at all in /etc/fstab; maybe that would account for it?
[05:51] <pitti> Good morning
[06:01] <pitti> Noskcaj: oh, what were the objections against uploads for xubuntu?
[06:02] <Noskcaj> ?
[06:06] <Noskcaj> pitti, Do you mean in my dmb meeting?
[06:10] <pitti> Noskcaj: yes
[06:11] <Noskcaj> The exact same reasons as with motu. Three out of four present members said they thought my quality of work wasn't enough
[06:12] <Noskcaj> I ended up with rights for 4 packages, when i'm the debian maintainer for nearly all of xubuntu's apps
[06:13] <pitti> yeah, I can understand the reason for waiting with MOTU TBH, but the xubuntu apps are pretty much all the same, packaging and policy wise
[06:13] <pitti> anyway, just try again in half a year or so
[06:13] <Noskcaj> yep
[06:14] <pitti> Noskcaj: I'm curious, how well does the sponsoring process work from your perspective? I. e. whats the usual delay?
[06:14] <Noskcaj> pitti, anywhere from 12 hours (for easy syncs) to a month (merges and patches)
[06:15] <Noskcaj> The sponsoring process is good for syncs, since nearly all are done in a few days, but merges average 1 week or more
[06:15] <Noskcaj> Unrelated, would it be worth syncing gnome-icon-theme-extras? build fixes + icons for SSDs
[06:18] <pitti> sounds harmless enough
[06:30] <Noskcaj> pitti, Will you sync the new glib releases? glib2.0 is fixes to docs, tests, and translations, and -networking is just translations the depends change you made
[06:30] <Noskcaj> actual, beta freeze, so ignore the above for this week
[06:30] <Noskcaj> *actually
[06:41] <pitti> Noskcaj: yes, we most definitively want to do that; no worries, that's what we have -proposed for :)
[06:41]  * pitti will package gobject-introspection too and upload it to exp/sync to trusty
[06:41] <Noskcaj> ok. I'm just looking for 3.12 stuff we want.
[06:41] <pitti> ah, someone already did,  nice
[06:43] <pitti> Noskcaj: so yes, will do that tomorrow, when the images are set and there is no chance that we'll need -proposed for an urgent fix for beta-2
[06:43] <Noskcaj> ok, cool
[06:43] <Noskcaj> glibmm can probably get one more experimental point release (doc fixes) but not all the way to 3.12
[06:43] <Noskcaj> I'm just using the irc logs as a reminder to myself now
[07:37] <zyga> good morning
[07:57] <dholbach> good morning
[09:56] <menace> Hi, there were security announces about initramfs-tools and openssh on the Ubuntu Security Announce. But i see the updated packets for precise not in precise-security, but in precise-updates. Why? I would have assumed, it comes with the Security Repository? Do i understand something the wrong way?
[09:56] <pitti> menace: they should be in both repositories
[09:56] <pitti> menace: confirm with apt-cache policy openssh
[09:57] <pitti> menace: -updates are mirrored, so they can usually be downloaded faster than from security.u.c.
[09:57] <pitti> menace: I meant apt-cache policy openssh-server
[09:57] <menace> ah, okay, that could explain why it was not in my security mirror.
[09:58] <menace> another question: is there any "garantued" time from security announcement til appearance in the update/security repository?
[09:58] <pitti> menace: when the announcement goes out, the update is alreayd on security.u.c
[09:59] <pitti> menace: it of course may take some time until it is in -updates on your mirror
[09:59] <pitti> until then, you'll download from -security; from then on, you'll download from -updates
[09:59] <pitti> (that's the point of having it in both)
[10:00] <pitti> sforshee: can such an iwlfifi error be triggered synthetically for testing?
[10:01] <pitti> sforshee: e. g. on my system the /iwlwifi/iwlmvm/fw_error_dump path doesn't exist, I only have a "iwldvm" directory (not iwlmvm)
[10:04] <pitti> sforshee: I replied on the MP, better keep the discussion at one place
[10:09] <smoser> slangasek, possibly root was mounted rw in initramfs, but i'm not sure why that would have occurred. /etc/fstab never channged and the initramfs successfully found the root (missing data from that paste then is /proc/cmdline).
[10:40] <zyga> pitti: what decides which gettext domains are added to language packs? just being in main or is there a secondary mechanism
[10:46] <Saviq> can anyone make bug# 1232146 public please?
[10:47] <zyga> Saviq: I can, it seems
[10:47] <zyga> Saviq: are you sure?
[10:47] <Saviq> zyga, dunno, not my bug :D
[10:47] <Saviq> zyga, I can't see it
[10:47] <Laney> I did it
[10:47] <pitti> zyga: being in main, plus the ones whose source packages declare X-Ubuntu-Use-Langpack: yes
[10:47] <Saviq> Laney, thanks
[10:48] <zyga> oohhh
[10:48] <zyga> pitti: ah, I misread you, ok
[10:49] <zyga> pitti: so all I need is to wait for the next langpack rebuild, I was looking at plainbox packages and they lost their translations as compared to debian
[10:49] <pitti> zyga: i.e. "plus" == "or", not "and"
[10:49] <zyga> pitti: right
[10:49] <zyga> pitti: thanks
[10:49] <pitti> zyga: did plainbox recently move to main?
[10:50] <pitti> zyga: yesterday's langpack build (with data from March 20) does not  have any trace of "plainbox"
[10:50] <zyga> pitti: not recently, but only recently it gained i18n (after 0.5~b2 was synced to main by doko a few days ago)
[10:51] <pitti> zyga: no templates available: https://translations.launchpad.net/ubuntu/trusty/+source/plainbox
[10:51] <zyga> hmm
[10:51] <zyga> how can I debug that?
[10:51] <pitti> zyga: there are some at https://translations.launchpad.net/ubuntu/trusty/+source/plainbox/+imports
[10:51] <zyga> oh
[10:51] <zyga> so I need to manage that now?
[10:51] <pitti> at this point I don't know any more what needs to happen; dpm ^
[10:51] <pitti> zyga: that's an one-time thing AFAIK
[10:52] <zyga> pitti: I don't seem to have the rights to approve those
[10:52] <pitti> neither have I
[10:53] <zyga> pitti: thanks for helping, I'll try to understand how this works
[10:53] <pitti> zyga: dpm should know how to proceed from that
[10:58] <dpm> pitti, zyga, let me see if I can have a look before my next call in a few mins
[10:58] <zyga> dpm: thanks
[11:00] <dpm> zyga, ok, I've approved the po/plainbox.pot template. It's a bit of a pain that it's a manual approval for each new template, but it should be done now. I guess the other 2 .pot files are a product of the build and can be ignored?
[11:00] <dpm> https://translations.launchpad.net/ubuntu/trusty/+source/plainbox/+imports?field.filter_status=all&field.filter_extension=pot
[11:00] <zyga> yes
[11:00] <zyga> all the debian ones are dupes
[11:01] <zyga> (I wonder if we should strip those during the build now)
[11:08] <zyga> dpm: could you also approve 'stubbox.pot', the one in  plainbox/impl/providers/stubbox/po/stubbox.pot
[11:08] <zyga> dpm: it is a part of the same package
[11:17] <doko> will make a component-mismatch day today ...
[11:18] <zbenjamin> cjohnston: ping, can you help me with some ideas about a sdk-launcher, that allows me to run and monitor a application in a special way?
[11:18] <zbenjamin> cjohnston: sorry wrong nick
[11:18] <zbenjamin> cjwatson: ping, can you help me with some ideas about a sdk-launcher, that allows me to run and monitor a application in a special way?
[11:19] <zbenjamin> cjwatson: i wrote down what i need, its point 4 in this document: https://docs.google.com/a/canonical.com/document/d/1hCWBkCu81lEQMqhQ0TnxMvBmGrvsHnpBeWJmeXGDC8I/edit
[11:26] <dholbach> jodh, is anything else required on https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1256949?
[11:29] <jodh> dholbach: that's probably a question for the kernel team - maybe they need to blacklist the default driver for that users wifi card?
[11:30] <dholbach> jodh, it's just that the bug tasks both went to "expired"
[11:30] <dholbach> so I'm not quite sure what's still missing on there
[11:32] <jodh> dholbach: I too was slightly confused - the user found the solution to be a bad driver issue and already has a fix for it. It's not an upstart issue, hence my thought on the kernel team blacklisting.
[11:33] <dholbach> ok
[11:33] <dpm> zyga, done
[11:33] <dpm> https://translations.launchpad.net/ubuntu/trusty/+source/plainbox/+imports?field.filter_status=all&field.filter_extension=pot
[11:34] <zyga> dpm: thanks
[11:42] <zyga> dpm: do the two 'aubuntnu archive auto sync' templates also need to be imported?
[11:45] <dpm> zyga, yes. I approved the oldest ones and the newest will be imported subsequently. And from now on, no more manual approvals will be required, unless you change the name of the template or something like that
[11:46] <zyga> ok, that should be it then, thanks :)
[11:58] <cjwatson> zbenjamin: I would have thought that that should be done by extensions to upstart-app-launch (-> tedg)
[11:59] <zbenjamin> cjwatson: yeah basically i need something like upstart-app-launch <appid> <pkgdir> that does the same as launching a click package just from the given directory
[11:59] <zbenjamin> cjwatson: i can myself register listener for app-start stop signals
[11:59] <cjwatson> Seems like something UAL could probably support without too much trouble, but you should talk with Ted about it
[11:59] <zbenjamin> cjwatson: ok thx
[12:50] <seb128> zyga, hey, could you have a look to https://bugs.launchpad.net/ubuntu/+source/checkbox-ng/+bug/1297118 ? e.u.c suggest that started recently, it looks like it might be your plainbox sync
[12:52] <zyga> seb128: looking
[12:53] <zyga> seb128: I beliveve this will be fixed by checkbox-ng sync (there's a bug about that)
[12:54] <zyga> seb128: checkbox-ng and plainbox are closely tied and after the latter was synced into ubuntu we were doing our best to sync the former as well
[12:54] <zyga> seb128: note, there are also two merge requests to ubuntu branches to correct (one liners) some data sets to get the whole pack to work
[12:54] <zyga> seb128: can we sync it over and see if that goes away?
[12:54] <seb128> zyga, sure, you might want to ask #ubuntu-release to let that in for beta though
[12:55] <seb128> zyga, do you have the bug number for the sync?
[12:55] <zyga> yes looking
[12:55] <zyga> bug 1297665
[12:57]  * zyga looks at the crash dump to see if that might be anything other than misalignment
[13:00] <zyga> seb128: ok, I've asked in #ubuntu-release, I'll go to test locally built packages
[13:01] <seb128> zyga, I've synced checkbox
[13:01] <seb128> let's see what release does
[13:01] <seb128> zyga, thanks
[13:01] <zyga> seb128: thanks
[13:01] <zyga> seb128: can you look at the two merge requests listed in the same bug?
[13:02] <seb128> zyga, if you approve them can you comment saying so? I can sponsor an upload with those then
[13:03] <zyga> seb128: sure
[13:04] <zyga> seb128: done
[13:04] <seb128> zyga, thanks
[13:08] <zyga> seb128: yeah, that particular crash is gone
[13:09] <seb128> great
[13:10] <zyga> seb128: quick question about those ubuntu branches, how does that work, after they get merged, will launchpad automatically build packages and upload them to the archive or is that just source that needs to be uploaded separately?
[13:11] <cjwatson> it's just source
[13:11] <zyga> cjwatson: ok, so to finish that, we need someone to sponsor those upload, correct?
[13:11] <cjwatson> the automation is the other way round - the branches are (supposed to be) automatically updated from uploads
[13:11] <cjwatson> I expect so, I haven't followed this discussion
[13:12] <zyga> cjwatson: ok, the reason we poposed those changes  to ubuntu rather than debian is speed, we hoped that those could be quickly approved and land to trusty before beta (to fix the mismatch we're trying to resolve)
[13:12] <zyga> cjwatson: so after they are merged, how should we proceed? just ask for sponsorship here?
[13:13] <cjwatson> sorry, I was just drive-by commenting, don't have brainspace to think about this
[13:13] <zyga> cjwatson: understood, sorry for keeping you busy
[13:14] <cjwatson> but it does sound like you need a sponsor (not me :-) )
[13:14]  * cjwatson goes back to doing battle with ubiquity
[13:15] <seb128> zyga, don't worry about the lp:ubuntu vcs, we usually don't use those much, I'm going to sponsor the source and that should result in an autoimport in the vcs (if udd doesn't hit import bugs)
[13:18] <zyga> seb128: sponsor the source, -> upload the merged sources as packages (which will trigger that autoimport to bzr that you mentioned)
[13:19] <zyga> seb128: sorry for asking novice questions all the time, delivering *to* ubuntu wasn't something I did heavily before
[13:19] <seb128> zyga, right, I'm just going to take the diff from those merge requests, apply them to the current packages and dput that
[13:19] <zyga> ok
[13:19] <zyga> sounds good
[13:19] <seb128> I might just close the merge requests by hand with a comment when I do that
[13:19] <seb128> to avoid confusion
[13:19] <zyga> ok
[13:33] <zbenjamin> tedg: hey ted did you receive my mail ?
[13:33] <zbenjamin> tedg: it was about the sdk-launcher
[13:34] <tedg> zbenjamin, My mail is being wonky... so not yet.
[13:34] <zbenjamin> tedg: i can pastebin you the contents if you want
[13:34] <tedg> Sure
[13:34] <zbenjamin> tedg: http://pastebin.ubuntu.com/7156716/
[13:51] <tedg> zbenjamin, In general, I think what you're asking for is very orthogonal to what we're trying to achieve with application startup in general.
[13:51] <tedg> zbenjamin, Let me see if I can come up with some way for you guys to get what you need while not breaking standard startup.
[13:52] <tedg> zbenjamin, Is there a reason that you're not making a click package and installing that?
[13:56] <pitti> fginther, ev: does rabbitmq have some kind of builtin failover? or does every consumer just try to connect to a set of servers in an agreed-upon order, so that the primary queue server can go down?
[13:57] <pitti> (that would still not synchronize the queues between the different servers)
[13:58] <pitti> fginther, ev: my other question is: is there some best practice how to detect that a worker node went AWOL (grabbing but never ack'ing a ticket, or just stopped grabbing tickets), so that you get notified to fix it?
[13:58] <pitti> fginther, ev: where "worker node" == thing that consumes requests from a queue
[14:02] <zbenjamin> tedg: even if i would install the click package i still need to have that controller process and i still need to change the exec line
[14:02] <tedg> zbenjamin, You can change the exec line before building the click package.
[14:02] <zbenjamin> tedg: i think patching the desktop file would not be such a good idea for a installed click package
[14:03] <zbenjamin> tedg: that would force me to rebuild the package every time even if no code changed
[14:03] <tedg> zbenjamin, Yes
[14:03] <tedg> zbenjamin, Seems like that'll be lower cost that copying it over USB.
[14:04] <zbenjamin> tedg: its copying over ssh not over usb
[14:04] <tedg> zbenjamin, Oh, then building the package is much lower cost than networking.
[14:05] <zbenjamin> tedg: however we think it would be better to not install the package , because we would need to remove it later then again
[14:05] <zbenjamin> tedg: zoltan had some more comments on this, maybe he should join the discussion
[14:05] <tedg> zbenjamin, I would hope you already plan to remove what ever you install :-)
[14:05] <cjwatson> I don't know if it helps, but note that it would be entirely possible to create another click database just for tests and install packages in there
[14:06] <chrisccoulson> anyone have any idea why https://errors.ubuntu.com/oops/28760226-a973-11e3-b754-2c768aafd08c failed to retrace?
[14:06] <cjwatson> we already have three click databases (core, custom, default), doing one more on the fly isn't hard
[14:06] <chrisccoulson> note, this machine has submitted lots of thunderbird crashes, but all of the traces are useless :(
[14:06] <zbenjamin> tedg: with my approach the is no install ;)
[14:06] <tedg> cjwatson, Hmm, that's interesting. Not sure, it seems to me like people would have a test user, so putting it in that user's account is probably good.
[14:07] <cjwatson> I don't much care, just letting you know it's an option :)
[14:07] <tedg> zbenjamin, Copying is installing in your approach
[14:07] <zbenjamin> tedg: but only a directory in /home/phablet/dev_tmp
[14:07] <cjwatson> (since it isn't necessarily obvious to people)
[14:07] <tedg> cjwatson, Yes, thanks, it is an interesting idea.
[14:07] <zbenjamin> tedg: the current deploy method also just uploads what has changed, so that is very fast if only small parts have changed instead of the whole app
[14:08] <zbenjamin> tedg: i'll be back in a few, lunch is already waiting ;)
[14:08] <tedg> zbenjamin, K, bring bzoltan :-)
[14:21] <Laney> zyga: seb128: did those MRs get uploaded?
[14:22] <directhex> am i missing something, or do LTS enablement kernels not include firmware updates?
[14:25] <zyga> Laney: not sure,
[14:25] <Laney> Looks like not
[14:25] <seb128> Laney, zyga: sorry, I got sidetracked, doing it
[14:25] <Laney> If someone that's not me does it then I can review them
[14:25] <Laney> for slippage innage
[14:26] <infinity> directhex: Firmware updates happen in linux-firmware, generally.
[14:26] <infinity> directhex: Though, some stuff is in the linux-lts-* kernel image packages directly, sometimes.
[14:27] <directhex> infinity, i'm failing to see an iwlwifi-7260-*.ucode anywhere for precise :/
[14:27] <infinity> directhex: That's in proposed.
[14:27] <seb128> Laney, zyga, do you have changelog entries suggestion?
[14:27] <directhex> infinity, oh :)
[14:28] <infinity> directhex: Err, also in updates...
[14:28] <infinity> Binary files /tmp/nKPVQdZgw6/linux-firmware-1.79.9/iwlwifi-3160-7.ucode and /tmp/diu29w0zXj/linux-firmware-1.79.10/iwlwifi-3160-7.ucode differ
[14:28] <infinity> Binary files /tmp/nKPVQdZgw6/linux-firmware-1.79.9/iwlwifi-7260-7.ucode and /tmp/diu29w0zXj/linux-firmware-1.79.10/iwlwifi-7260-7.ucode differ
[14:28] <directhex> infinity, huh. wonder why packages.ubuntu.com doesn't find it
[14:29] <infinity> iwlwifi-7260-8.ucode in proposed.
[14:29] <infinity> So, depends on which one you need (-7 or -8)
[14:31] <directhex> does packages.u.c. file search not consider -updates?
[14:31] <infinity> directhex: I assume you need -7, if you're using it with lts-saucy (ie: 3.11)
[14:31] <seb128> zyga, btw, why did debian update checkbox but not plainbox-provider-checkbox? seems like that should be updated in debian and synced
[14:31] <infinity> directhex: If you're using lts-trusty from the kernel team PPA, you'll need the linux-firmware in proposed.
[14:32] <directhex> infinity, i'm working blind on new hardware, i don't know yet what level of kernel backportery it needs - just that the wifi is too new for the default kernel
[14:33] <directhex> canonical certified, apparently. huh. wonder when i last updated my base installer image
[14:33] <infinity> http://packages.ubuntu.com/search?searchon=contents&keywords=iwlwifi-7260-7.ucode&mode=exactfilename&suite=precise-updates&arch=any
[14:34] <infinity> directhex: Well, if you're using lts-saucy, you need linux-firmware from updates, if you use lts-trusty (which isn't in the archive yet), you'll need linux-firmware from proposed.  Now you know. :)
[14:34] <directhex> \o/
[14:35] <directhex> looks like currently my default install kernel is... linux-lts-quantal. guess that answers the "when did i last update it" question.
[14:38] <infinity> directhex: There's also the option of 3.2.0 or 3.5.0 with linux-backports-modules.
[14:38] <infinity> Oh, I guess just 3.2.0.  There's no LBM for lts-quantal.
[14:39] <directhex> infinity, i'm not at all opposed to a new kernel. using lts-quantal is because i haven't updated my installer image since raring shipped
[14:39]  * infinity nods.
[14:39] <directhex> anyway, thanks for the user support
[14:39] <infinity> Pay it forward by documenting something somewhere for someone. :P
[14:40] <zyga> seb128: we are working on updates to debian but we though that waiting for sponsorship was risky at this time
[14:40] <zyga> seb128: updates to debian will include more features, this is really a bugfix for trusty
[14:41] <seb128> zyga, how come debian doesn't have the same bug/need for fix if they have the same checkbox version
[14:41] <seb128> zyga, ok anyway, but having a changelog entry would be handy, I'm unsure how to describe the change
[14:41] <zyga> seb128: so it does but nobody needs that in debian yet :)
[14:41] <zyga> seb128: and the update will be ready in a few days
[14:42] <zyga> seb128: changelog 'correct namespace to match expected namespace in checkbox-ng'
[14:42] <seb128> zyga, thanks
[14:42] <zyga> seb128: that is fixed in trunk, we'll release updates to debian soon, this is safe to drop on next sync
[14:47] <ev> pitti: http://www.rabbitmq.com/ha.html - though I'm sure #webops will have some thoughts.
[14:47] <ev> possibly wgrant as well
[14:48] <ev> pitti: back in the day, lifeless' suggestion was to write to both rabbit and cassandra. That way you could replay from cassandra when rabbit came back into existence.
[14:48] <ev> I'd love to see that sort of thing generalised and reused in the many places we're using a queue model
[14:48] <wgrant> In LP we store all jobs in postgres, and the rabbitmq jobs reference those
[14:49] <wgrant> It's a bit bad, but less bad than rabbit HA was at the moment.
[14:49] <wgrant> s/moment/time/
[14:50] <ev> pitti: to your latter point, we probably want metrics of the workers via (tx)statsd. You could have another process watching the metrics for all the workers and if any of them failed to update the processed count in N minutes, you'd know it was wedged.
[14:50] <ev> or something less rube goldberg-y
[14:50] <ev> because when I think HA, I definitely think postgres :-P
[14:52] <maco> ev: weird the things hanging out with historical reenactors instead of programmers does to your brain. "because when I think historically accurate, I definitely think postgres"
[14:53] <cjwatson> kirkland: so, bug 1172014
[14:54] <cjwatson> kirkland: this change caused a regression in ubiquity; not really your fault, ubiquity needed to resolve the UUID= in crypttab because it explicitly zeroes the device
[14:54] <cjwatson> kirkland: but more importantly, I can't actually make the swap setup work properly even after fixing that ubiquity bug
[14:56] <cjwatson> kirkland: I think https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/1172014/comments/9 has the right of it; the swap space is set up with a random key, there's no container, so how can it have a stable UUID?
[14:57] <pitti> ev: thanks for the HA link, will digest in the next days
[14:57] <ev> maco: :)
[14:57] <bzoltan> zbenjamin: here
[14:57] <zbenjamin> bzoltan: meh [15:43:29] <-- tedg (~ted@ubuntu/member/ted) hat das Netzwerk verlassen (Quit: Ex-Chat)
[14:58] <cjwatson> kirkland: indeed when I reboot after installation, re-point crypttab to /dev/sda5 so that I can cryptdisks_start, copy the new UUID into /etc/crypttab, and reboot, it still doesn't work
[14:58] <pitti> ev: ack, so a monitoring cron job/process (and who watches the watchers? :-) )
[14:58] <zbenjamin> cjwatson: do you have a idea when tedg will be back?
[14:58] <cjwatson> zbenjamin: no, sory
[14:58] <cjwatson> *sorry
[14:59] <ev> pitti: you could equally make the processes watch themselves. Spin off a thread that does it.
[14:59] <ev> but python, threading, yay
[15:23] <zbenjamin> tedg: bzoltan: ping
[15:24] <tedg> zbenjamin, bzoltan, howdy folks
[15:25]  * zbenjamin just waits for zoltan to arrive
[15:32] <Chipaca> are files in /usr/share/upstart/sessions considered conffiles?
[15:32] <cjwatson> No
[15:33] <cjwatson> I mean, whether something is a conffile is governed by whether it's in the package's "conffiles" control file (/var/lib/dpkg/info/*.conffiles)
[15:33] <cjwatson> but conffiles are generally configuration files, and configuration files must reside in /etc
[15:33] <cjwatson> https://www.debian.org/doc/debian-policy/ch-files.html#s-config-files
[15:34] <Chipaca> right
[15:34] <Chipaca> cjwatson: i'm wondering how to point to a multiarch binary from an upstart session file
[15:34] <Chipaca> not finding much info
[15:34] <cjwatson> files in /usr/share shouldn't be architecture-specific
[15:34] <cjwatson> put a wrapper somewhere else?
[15:35] <cjwatson> I can't really fathom how being a conffile would help :)
[15:35] <zbenjamin> tedg: ok seems bzoltan is busy right now, lets move the discussion to tomorrow then, or maybe a ML don't know which approach is better
[15:35] <Chipaca> cjwatson: there seems to be support for having multiarch conffiles in multiple packages not break dpkg
[15:36] <cjwatson> you are going down a rabbit hole
[15:36] <Chipaca> cjwatson: yes
[15:36] <cjwatson> I suggest climbing the other way
[15:36] <cjwatson> conffiles will at best fail to hinder you
[15:36] <Chipaca> cjwatson: I'm not sure what value I'm giving users by making my package multiarch
[15:36] <cjwatson> (and even that is unlikely)
[15:36] <Chipaca> so I might just make it not be multiarch
[15:36] <cjwatson> could you make all this concrete, please?  what package is this?
[15:36] <Chipaca> cjwatson: ubuntu-push-client
[15:37] <tedg> zbenjamin, K, I'll reply to your mail and CC him.
[15:37] <cjwatson> Chipaca: does it have any reverse-dependencies?
[15:37] <zbenjamin> tedg: yeah thats maybe easier thx :)
[15:37] <cjwatson> it's not in the archive at the moment, I see
[15:37] <Chipaca> cjwatson: no
[15:37] <Chipaca> cjwatson: it's in NEW, afaik
[15:37] <Chipaca> or maybe in proposed?
[15:37] <cjwatson> Chipaca: I can't really see why a leaf client package would need to be Multi-Arch: same
[15:37]  * Chipaca looks
[15:38] <cjwatson> Chipaca: it perhaps ought to be Multi-Arch: foreign
[15:38] <cjwatson> huh, it is in trusty, I'm obviously just not quite up to date
[15:38] <Chipaca> it is?
[15:38] <pitti> ev: we could also think about a "ping" fanout queue (with timeout of e. g. 30 s) and find broken workers that way; no response -> really broken, and on ack the worker coudl check if it has a running job for more than N hours
[15:38]  * Chipaca refreshes
[15:39] <cjwatson> hah, that package is nonsensically laid out
[15:39] <cjwatson> it's using Multi-Arch: same style paths while being Multi-Arch: foreign
[15:39] <Chipaca> cjwatson: :) I am but an egg
[15:39] <cjwatson> move the executable to /usr/lib/ubuntu-push-client/ubuntu-push-client
[15:39] <cjwatson> this is probably just a libexecdir accident
[15:39] <ev> pitti: so the workers tell the watchdog about their state? And if the watchdog dies we just point a new one at the queue the workers are submitting state to?
[15:39] <cjwatson> perhaps dh_auto_configure -- --libexecdir=/usr/lib
[15:40] <Chipaca> cjwatson: i'm putting it there by hand
[15:40] <cjwatson> sorry,  dh_auto_configure -- --libexecdir=\$${prefix}/lib  I mean
[15:40] <cjwatson> ok, don't :)
[15:40] <Chipaca> cjwatson: ok :)
[15:40] <cjwatson> /usr/lib/<multiarch triplet> paths only make sense in Multi-Arch: same packages
[15:40] <cjwatson> which would generally be libraries
[15:41] <cjwatson> I see that /usr/share/upstart/sessions/ubuntu-push-client.conf already points to /usr/lib/ubuntu-push-client/ubuntu-push-client
[15:41] <pitti> ev: dying watchdog is of course a recursive problem; but cron failing ought to be a really rare event
[15:41] <cjwatson> Chipaca: so, the whole conffiles thing is a red herring anyway because /usr/share/upstart/sessions/ubuntu-push-client.conf is in the very same architecture-dependent package so it could just be built to embed whichever paths you need; but that would be a different kind of policy violation and as I say doesn't actually make sense, so better to simplify
[15:42] <pitti> ev: I mean, someome will notice if packages/MPs don't get through, it woudl just be nice to have a place to look for the worker status; so I think with statd or a ping queue or something similar whose ping fanout requests come from cron we should be good enough
[15:42] <Chipaca> cjohnston: and it's already multiarch:foreign, so all i ineed to du is remove the triplet
[15:42] <cjwatson> exactly
[15:42] <Chipaca> cjwatson: ^
[15:42] <pitti> ev: and we can figure out the set of "expected" workers from the existing logs (they contain host names)
[15:42] <Chipaca> cjohnston: sorry :)
[15:42] <ev> pitti: the watchdog dying due to busted code in it? Yeah, but the beauty of that is that all we lose is the ability to kill wedged workers
[15:42] <ev> we can have a nagios alert on the watchdog process
[15:42] <ev> which in turn sends to pagerduty
[15:43] <pitti> ev: so as soon as a worker submits one result into swift, it'll be in the set of "expected to be there" workers
[15:43] <cjwatson> golang-ubuntu-push-dev arguably ought to be M-A: foreign too, but that's not very important
[15:43] <pitti> ev: right; at that point I'll gladly hand that over to the CI experts for this :)
[15:43] <ev> and we get a text message saying, "hey fool, the watchdog is down. We're not going to kill any hung workers until you fix it. But take your time."
[15:43] <ev> heh
[15:43] <ev> the experts in being woken up in the middle of the night, you mean
[15:43] <pitti> ev: I'll think about a proper design on Friday when I'll be typing impaired anyway, just collecting various Lego blocks now to build it with :)
[15:44] <cjwatson> actually, since golang-ubuntu-push-dev has no dependencies it really doesn't matter
[15:44] <pitti> ev: no, I mean telling me how to design teh watching of the watchers, etc. :)
[15:44] <ev> I'll start putting that on job profiles. Must have skills in sleep deprivation.
[15:44] <ev> oh right
[15:44] <ev> vila: ^ you're the point of contact on this one :)
[15:44] <ev> I think we've got the outline of a sensible model there, but we'll need to make sure it's interfaced with nagios
[15:44] <pitti> ev: watchdog dying should be an once-in-a-year condition (unless it's the whole server itself which goes down), and then it shouldn't be a "ring people out of bed" conditiona s long as the actual tests still come in
[15:45] <ev> yeah
[15:45] <pitti> ev: i. e. we expect to have enough redundatn workers that we cna easily get along with 20% of them failing
[15:45] <ev> we can keep the watchdog code simple
[15:45]  * ev nods
[15:45]  * vila reads backlog
[15:45] <Chipaca> cjwatson: thanks a ton
[15:45] <cjwatson> np
[15:46] <ev> I'm super encouraged by how much you get this need for resilience to failure and graceful degradation
[15:46] <pitti> ev: yes, that was the idea; send a "ping" to a fanout queue, wait 30 s for acks, consider the missing ones as dead; sounds like a 15 line thing
[15:46]  * ev nods
[15:46] <pitti> ev: well, so far jibel and I have taken the penalty of not having such a system, so I'm notivated :)
[15:46] <ev> :)
[15:48] <pitti> ev: as for nagios: can we tell it something like "the latest report (URL to text file or so) from the watchdog is older than 30 minutes, it must be dead"?
[15:48] <ev> pitti: it's probably best to have the watchdog touch a file for that, but yes
[15:48] <pitti> ev: right, I meant something like that
[15:49] <ev> yeah, entirely doable
[15:51] <vila> pitti: so, as of today (things will change) the way we do that in the ci engine is to have the test runner monitor the testbed (where the test actually run) and we have a 'engine health' page monitoring the workers (the test runner is the worker reading the rabbit queue)
[15:52] <vila> pitti: so feedback from adt-run goes to the test runner which can decide the testbed is dead if nothing comes in for too long
[15:52] <pitti> vila: right, adt-run already has timeouts for everythign it does to the testbed
[15:53] <vila> pitti: in 2.3.7 already ?
[15:53] <pitti> vila: forever really
[15:55] <vila> pitti: hmm, never ran into them then
[15:55] <fginther> pitti, (sorry your ping was off my page).  rabbitmq can be built for HA, but I haven't looked into that yet. For the second question, there is a way for the server to know that a worker has died (the server recognizes that the other end of the connection is no longer active), but we're not using this now. I'd have to look it up again
[15:55] <pitti> fginther: thanks
[16:01] <vila> pitti: ack, I see them now, and the cmdline options too ;)
[16:11] <vila> exit
[16:12] <vila> damn focus
[16:22] <hallyn> if i need to ship a helper script for a udev hook to call, is there a particular place it should go?
[16:29] <stgraber> hallyn: /lib/udev I believe
[16:33] <hallyn> just right in there, no subdir?  cool, thanks.
[16:34] <mpt> “div.table-of-contents {…max-width: 50%;…}” — oh dear
[16:55] <xyzzymaze> Greetings ... trying to install Trusty BuildDate Mar 25 .. it boots, I can do disc-check, but selecting install ends up black screen. I have Nvidia Geforce 210 card installed. Live sys looks 'up' as ctrl-alt-F2 gets to a session prompt .. thank you!
[17:30] <doko> zul, python-oslotest wants a python3-hacking b-d ...
[17:31] <zul> doko:  ok ill fix it up
[17:34] <jamespage> jdstrand, slangasek: can we get a definitive position on the golang discussion in bug 1267393 for the context of 14.04 please?
[17:34] <jdstrand> I plan on responding soon-- I am looking into a few things
[17:34] <jamespage> jdstrand, thanks
[17:34] <jdstrand> it is very high on my todo
[17:34] <jamespage> jdstrand, appreciated
[17:46] <infinity> jdstrand: To be fair, even fixing dynamic linking in golang (which we're not going to do, and even if we help with, won't do in time) doesn't fix the biggest issue.
[17:47] <infinity> jdstrand: golang upstream is a typical Google project that gives exactly zero shits about stable release support, so we'd be on the hook for digging out and backporting fixes ourselves.  Or give it a firefox/chromium-style upstream version exception, which is madness for a compiler.
[17:50] <mdeslaur> hehe
[17:52] <infinity> I'm going to stay out of the compiler argument on that MIR, and jump on the whole "juju-core doesn't ship all its binaries in the archive" thing which, amazingly, no one's even mentioned.
[17:57] <jamespage> infinity, I think I've pointed at it enough
[18:03] <infinity> jamespage: Honestly, I think it's a major blocker, and I don't grasp why people seem to handwave over it with a "yeah, we'll fix it some day".
[18:04] <infinity> jamespage: Cause, either it's not a problem at all, and they can package the binaries, or it's an excuse to hide much bigger problems that need fixing.
[18:04] <infinity> jamespage: It's pretty black and white in my mind.
[18:04] <jamespage> infinity, I commented on how that binary is built; but I've left it to the upstream dev team to explain why
[18:20] <alow> infinity: looking at this patch stuff for libv8 again. You had mentioned whitespace issues, which files?
[18:23] <infinity> alow: Oh, err.  I'd given up caring and was going to just generate my patch with diff -w
[18:23] <infinity> alow: But there were a few bits.  Lemme find the tree.
[18:26] <alow> infinity: I suspect there were one or two
[18:26] <infinity> Argh.  Total context switch fail...
[18:26] <infinity> alow: Which branch is the branch I care about again?
[18:26] <alow> infinity: https://github.com/andrewlow/v8ppc/tree/libv8-3.14
[18:27] <infinity> src/jsregexp.cc
[18:28] <alow> yup - I can 'fix' that
[18:28] <infinity> src/objects.cc
[18:28] <infinity> src/serialize.cc
[18:28] <alow> infinity: what diff command are you using to compare the two git repos again?
[18:28] <infinity> Those three all have a few instances of indentation going wonky.
[18:28] <alow> infinity: let me fix those 3.. can't be hard
[18:28] <infinity> alow: That was 'git diff d8d994ca1752c530d2cbf8d9b43b1881b642ddf9 remotes/origin/libv8-3.14' (ie: the diff from my last update and your current HEAD)
[18:30] <infinity> alow: Of course, if those were whitespace cleanups that you missed in the last update, maybe it's actually fixing something.  Guess I should compare back to the original...
[18:30] <infinity> alow: Oh, and that might be the case.
[18:31] <infinity> alow: Yeah, ignore me.
[18:31] <infinity> alow: That was you cleaning up better, and my diff method finding the cleanups.
[18:31] <alow> infinity: I'm doing a diff from the original git://anonscm.debian.org/collab-maint/libv8.git and mine https://github.com/andrewlow/v8ppc/tree/libv8-3.14
[18:31] <infinity> alow: (ie: if I diff from 6b10fef46edfb4dc2a7aed389d75574c40a14243 to your HEAD, those changes aren't there)
[18:32] <infinity> alow: Diff from 6b10fef46edfb4dc2a7aed389d75574c40a14243 to you is what matters, as 6b10fef46edfb4dc2a7aed389d75574c40a14243 is what the orig.tar.gz is built against.
[18:32] <alow> infinity: shmm.. when I did this work a while back, I thought I had found more "whitespace" errors in mine.. that I was trying to correct
[18:33] <infinity> alow: Doing the full diff (instead of the incremental I shouldn't have been doing), the only wonky whitespace I see in your stuff is trailing spaces in a few places.
[18:33] <infinity> Like aix_gyp.patch, which shouldn't be in the tree at all, probably.
[18:33] <alow> true
[18:34] <infinity> alow: Do you know if bumping the v8 version like your current HEAD does has any actual impact on anything (symbol versions, etc), or if it's just cosmetic?
[18:36] <alow> infinity: it should be cosmetic
[18:36] <alow> infinity: it should be just the patch level we're bumping here
[18:36] <infinity> -#define IS_CANDIDATE_VERSION 1
[18:36] <infinity> +#define IS_CANDIDATE_VERSION 0
[18:36] <infinity> That may have an impact, though.
[18:36] <infinity> Ahh, but you backed that out.
[18:37] <alow> infinity: it was a series of commits I was applying
[18:37] <alow> infinity: this allowed me to keep the original commits from the master v8 repo
[18:37] <infinity> Or... IS_CANDIDATE_VERSION has always been 0 in our packages.  Whee.
[18:38] <infinity> So, neevrmind.
[18:38] <alow> infinity: exactly :)
[18:38] <infinity> Maybe I'm reading that boolean backwards, and "1" is used to define "RCs" or something.
[18:38] <infinity> Or, we've always shipped something that thinks it's a dev/trunk/beta thing.  Whatever.
[18:38] <infinity> If it works, it works.
[18:39] <alow> infinity: 0 should be the right value for libv8
[18:40] <infinity> alow: Anyhow, your current HEAD looks fine to me, now that I rediffed to my base instead of to our last update.  So, ignore my previous whining.
[18:40] <infinity> alow: I don't suppose you know much about Corentin's mongo/ppc port.  That's much scarier than your v8 stuff. :P
[18:41] <alow> infinity: uh... I think i've talked with him, but mostly to help him get libv8 building
[18:42] <infinity> alow: Do you know how much (if any) of it has been submitted/accepted upstream for future versions?
[18:42] <alow> infinity: of 'it' being what?
[18:42] <infinity> alow: He's pretty much wrapped every call to anything anywhere in some endian check/flip madness, which makes for a pretty hard to audit diff.
[18:42] <infinity> alow: "it" being his mongo work.
[18:42] <alow> infinity: oh.. the mongo stuff. no idea sorry
[18:43] <infinity> Also the occasional signed/unsigned char fix in here.  It's pretty clear that no one's heavily tested Mongo on ARM either, if they think any of this works today.
[18:44] <alow> infinity: I'm assuming you're looking at the mongo code. Again, it's pretty foreign to me, haven't looked at it in any detail
[18:44] <infinity> alow: It's foreign to me too.  And I wish it would stay that way. :)
[18:45] <infinity> alow: Anyhow, I don't think I have any more to bug you about WRT V8.  I might have questions about node if it doesn't Just Work later today, but the "port" seems pretty simple, given an externally-linked-and-functional libv8, so I doubt it'll give me troubles.
[18:46] <alow> infinity: sure.. catch me here or drop an email if node has problems
[18:46] <alow> infinity: oh.. you might need one or two endian changes for BE in the Node code
[18:47] <infinity> alow: Above and beyond the v0.10.25-release-ppc branch?
[18:47] <alow> infinity: You can sniff around here https://github.com/andrewlow/node for some of them.
[18:48] <alow> we have a v0.10.26-release-ppc branch - it includes the endian changes (as does 25)
[18:48] <alow> compare against v0.10.26-release
[18:48] <alow> to see the deltas
[18:48] <infinity> alow: Well, we ship .25, so that's the one I was looking in.
[18:48] <alow> we also have unstable 0.11.x
[18:50] <infinity> alow: So, my hope here is that " git diff remotes/origin/v0.10.25-release remotes/origin/v0.10.25-release-ppc | filterdiff -x '*deps/v8ppc/*'" gives me basically what I need.
[18:50] <seb128> cjwatson, stgraber: hey, could one of you have a look to https://bugs.launchpad.net/ubuntu/+source/gnome-session/+bug/1244736 ? there is a simple suggested change, not sure if it makes sense (basically bailing out of starting the agent if there is already another one running)
[18:51] <alow> infinity: I bow to your git diff mastery - yes, it should work
[18:55] <infinity> alow: Alright, cool.  Will whine later if we're wrong. ;)
[19:58] <kirkland> cjwatson: yes, this is an unfortunate one
[19:58] <kirkland> cjwatson: your analysis is correct, we use a random key (and throw that key away) at each boot
[19:59] <kirkland> cjwatson: otherwise, we have a key management problem
[21:17] <doko> zul, test failures, missing b-d on six? https://launchpad.net/ubuntu/+source/python-oslotest/0.1-1ubuntu1/+build/5851799


[03:34] <durksauce> So I'm pretty new to the gnome community and I've been interested in getting some projects under my belt. I have some programing experience, but I really want to do more and would like to contribute. Does anyone know of a noob friendly project that could use some help?
[15:36] <LaserAllan> hey guys is it possible to create shortcuts on ubuntu gnome?
[15:36] <LaserAllan> I've tried through wine but doesnt seem to show up on the workspace
[16:18] <mgedmin> like desktop shortcuts?
[16:18] <mgedmin> or like application launchers you expect to find in the overview's app menu?
[16:18] <mgedmin> (or drag them to your favourites etc)
[16:19] <mgedmin> for 1st I'm not sure -- it used to be possible to enable this in Tweak Tool
[16:19] <mgedmin> for 2nd it should Just Work, even with wine
[23:07] <LaserAllan> hey guys, is there any good SSH clien for linux? (I know i have only used Putty in the past for windows)


[12:15] <persia> geser: The original files are dropped in during package unpack, and deleted during clean, then the diff is generated, followed by the copy from autotools-dev during configure, and then the build.  config.sub and config.guess (I miss the close-bracket key) are never in the diffs, but present in the original.
[12:15] <geser> the README for autotools-dev suggest to add them to the clean target
[12:16] <owh> Greetings. I posted an email to ubuntu-devel about implementing a FAT dirty flag for dosfsck on January 2nd. It is still awaiting moderation. I'm not currently a developer, but I'm fixing bugs in dosfsck together with sistpoty (Stefan Potyra) and I wondered what I should do next. The email is here: http://paste.ubuntu-nl.org/880/
[12:17] <owh> BTW, on launchpad I am onno-itmaze.
[12:17] <LaserJock> geser: but the autotools-dev example rules puts it in configure :-)
[12:18] <LaserJock> owh: actually, you could email ubuntu-devel-discuss instead
[12:18] <LaserJock> owh: it's open to everybody
[12:18] <tenshu> Apologize me but is that normal if my packages are stuck in ftp://revu.tauware.de/incoming/ ?
[12:18] <bhale> hello LaserJock
[12:19] <LaserJock> hi brandon
[12:19] <owh> LaserJock: Would it not get lost in the noise?
[12:19] <LaserJock> owh: there's not a lot right now I don't think
[12:19] <geser> persia: as clean is called during source package building, aren't config.{guess,sub} missing when diffing against orig.tar.gz when they are removed in clean?
[12:20] <owh> LaserJock: Cool. Tah.
[12:20] <LaserJock> owh: you could also ask sistpoty to send it for you
[12:20] <LaserJock> tenshu: which package?
[12:20] <owh> LaserJock: sistpoty is writing a thesis and is a tad busy :-)
[12:21] <LaserJock> ah yes
[12:21] <tenshu> popstation & docmaker
[12:21] <LaserJock> hence why I see him normal hours in my time zone :-)
[12:21] <LaserJock> tenshu: you need to upload source packages, not .debs
[12:21] <tenshu> oh my mistake sorry :q
[12:22] <LaserJock> tenshu: you'll need to get a REVU admin to clear those out
[12:22] <LaserJock> tenshu: also, why do they have "oea" in the versioning?
[12:23] <tenshu> thats is the name from the upstream author
[12:23] <Lutin> tenshu: ask siretart for the pkges removal
[12:23] <tenshu> OE for open edition
[12:24] <LaserJock> interesting
[12:32] <geser> LaserJock: latest debdiff for g-c-u: http://pastebin.ca/310669
[12:32] <geser> something else to change before I upload it?
[12:39] <LaserJock> geser: looks good to me
[12:39] <LaserJock> geser: thanks a ton for your work on that
[01:04] <Lutin> LaserJock: could you check if gfaim is ok for you ?
[01:14] <somerville32> For versioning
[01:14] <somerville32> It goes: Major.Minor.Nano.Micro ?
[01:14] <somerville32> Or Major.Minor.Micro.Nano ?
[01:15] <azeem> probably the latter
[01:15] <Adri2000> nano < micro
[01:15] <azeem> but who nows, some projects might have strange versioning schemes ;)
[01:16] <LaserJock> hi azeem
[01:16] <LaserJock> Lutin: this is only for French?
[01:16] <LaserJock> :(
[01:17] <Lutin> LaserJock: yep
[01:17] <Lutin> LaserJock: on the other side, this can be translated
[01:18] <LaserJock> I was going to say, it might be a good way to get my wife to use Linux more
[01:18] <LaserJock> but she doesn't know any French
[01:18] <Adri2000> hehe :P
[01:18] <azeem> LaserJock: heya!
[01:19] <Lutin> hehe
[01:19] <LaserJock> azeem: geser has prepared (and is uploading) gchemutils 0.6.3 today
[01:19] <azeem> cool
[01:20] <LaserJock> azeem: yeah, he was able to patch it to work with our version of goffice
[01:20] <geser> it's already uploaded
[01:21] <azeem> excellent
[01:21] <LaserJock> the author of gchempaint and gchemutils hopes to have a stable release early to mid March
[01:21] <LaserJock> I'm hoping I can squeeze it into Feisty
[01:24] <ScottK> Anybody up for REVU of a simple Perl package? http://revu.tauware.de/details.py?upid=4004
[01:25] <Lutin> even if I was a motu, I can't even understand one line of perl ^^
[01:25] <ScottK> Version 1.6 of this program (I've packaged 1.8) in included in https://launchpad.net/ubuntu/+source/libmail-spf-query-perl/1:1.999.1-3, but since the main Mail::SPF::Query program won't be updated, this associated program needs to get pacakged separately to get updated.
[01:27] <LaserJock> Lutin: you realize gfaim-data is non-free?
[01:27] <persia> ScottK: I'm not a reviewer, but it's odd to see so much of debian/ in orig.tar.gz.
[01:27] <Lutin> LaserJock: suitable for multiverse though, isn't it ?
[01:28] <LaserJock> Lutin: I think so
[01:28] <ScottK> Well, as we discussed here a few days ago (when you weren't around) the upstream for this package and a couple of others I've done includes his own /debian in the release.
[01:28] <ScottK> First time around I was asked to ask him to remove it.  I asked.  He declined.  Makes my life easier anyway.
[01:28] <Lutin> LaserJock: at least when tfheen rejected it from entering the archive, ha didn"t told me about non-free issue related to the package
[01:29] <persia> ScottK: It's fine, just odd :)
[01:30] <ScottK> OK.
[01:31] <LaserJock> Lutin: he might not have ogtten that far
[01:31] <Lutin> LaserJock: indeed
[01:32] <Lutin> LaserJock: do you want me to pastebin his mail ?
[01:37] <persia> ls
[01:41] <LaserJock> Lutin: I somehow feel like you should make it clearer that the recipies are only in French
[01:42] <Lutin> LaserJock: ok, how can I do that ?
[01:43] <LaserJock> Lutin: well, I was thinking maybe you could put it in the short description
[01:43] <LaserJock> at least of gfaim-data
[01:43] <Lutin> ok
[01:44] <LaserJock> I think you should also include the GPL preample in debian/copyright
[01:44] <Lutin> didn't I ? damn ^^
[01:44] <LaserJock> well, you have a statement
[01:45] <LaserJock> that could be sufficient, I'm not sure
[01:45] <mwolson> you definitely don't need the GPL preamble there
[01:46] <LaserJock> I see it a lot though
[01:46] <LaserJock> and have wondered
[01:46] <mwolson> just something to the effect of "This package is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version."
[01:46] <LaserJock> but the Debian Policy just says to link to it
[01:47] <Lutin> ok, changed
[01:47] <mwolson> and maybe a warranty disclaimer
[01:49] <LaserJock> Lutin: well, it looks pretty ok to me
[01:49] <Lutin> LaserJock: ok, wait a minute before adding a comment ;)
[01:49] <Lutin> LaserJock: just uploaded the fixed desc and copyright
[02:02] <Lutin> LaserJock: should be ok now
[02:12] <LaserJock> Lutin: does imprec work still?
[02:17] <Lutin> LaserJock: I wanted to ask you =)
[02:18] <Lutin> LaserJock: imprec is called by a call to system()
[02:18] <Lutin> don"t know the way he gets the path
[02:19] <LaserJock> Lutin: when I try to print it segfaults
[02:19] <LaserJock> :-)
[02:20] <LaserJock> Lutin: it looks to me like he's just relying on it being in your path somewhere
[02:21] <Lutin> LaserJock: according to posix.1, system() calls exec sh -c, so it relies on the system path
[02:25] <Lutin> LaserJock: of course I could try to symlink /usr/lib/gfaim to /usr/bin/gfaim, but I wonder if it's worth it
[02:25] <Lutin> to move it, and then symlink its previous location would be kind of weird
[02:26] <Lutin> well, it's 2:25 here and I really need some sleep
[02:26] <LaserJock> other then that it seems ok
[02:26] <Lutin> ok
[02:26] <Lutin> well, gotta go
[02:26] <Lutin> see you later guys
[02:27] <Lutin> and thanks a lot LaserJock =)
[02:59] <bddebian> Heya gang
[02:59] <bhale> hi bddebian
[02:59] <chillywilly> hi
[03:00] <bddebian> Hi bhale, chillywilly
[03:05] <persia> hi bddebian
[03:05] <bddebian> Hi persia
[03:06] <ScottK> hi bbdebian: Got a moment to look at a very simple package with one tricky question? http://revu.tauware.de/details.py?upid=4004
[03:11] <bddebian> ScottK: What's the tricky question, I'm a little tied up with RL work atm :-(
[03:11] <ScottK> ...
[03:12] <Hobbsee> ScottK: tell what the questoin is, and you're more likely to get an answer
[03:12] <ScottK> The one actual program in that package was previously package in https://launchpad.net/ubuntu/+source/libmail-spf-query-perl/1:1.999.1-3.  The problem is that the main program in that package is not being updated and so this helper program has two more versions that I'd like to get released.
[03:13] <ScottK> Sorry. on other channels I've used ... means I'm busy typing the question, not ignoring you.
[03:13] <ScottK> So I'm not sure exactly what the right way to proceed is here.
[03:13] <Hobbsee> ah
[03:14] <ScottK> I expect I have to have a new package to continue with the one program, but I was hoping to find a way to avoid NEW since a program that's already been part of a larger package.
[03:18] <ScottK> If you look you'll see that the older, combined package is already two released behind.
[03:18] <zul> yay update-grub works
[03:19] <persia> ScottK: Perhaps in addition to postfix-policyd-spf-perl_1.08-0ubuntu1, you could upload libmail-spf-query-perl_1:1.999.1-4, which includes the split, and add appropriate conflicts for libmail-spf-query-perl=1:1.999.1-3 to postfix-policyd-spf-perl_1.08-0ubuntu1?   To avoid NEW, you could also include the new code directly in libmail-spf-query-perl/1:1.999.1-4 (with no new package), and just indicate the helper update in the cha
[03:25] <ScottK> I could probably get that done, but the other part is that while postfix-policyd-spf-perl currently with libmail-spf-query-perl. libmail-spf-query-perl is obsolescent and unmaintainable.  There's a new Perl implementation that I have in the queue http://revu.tauware.de/details.py?upid=3976 that will replace it.  So I don't want to keep the postfix policy daemon tied to the old library.
[03:28] <persia> ScottK: I think you have to go through NEW then :(  You still probably want a versioned conflicts to prevent dual installation: there's no requirement that conflicts targets be in the archive, so it won't have a lasting effect.
[03:36] <ScottK> OK.
[03:36] <ScottK> Well I was hoping.
[03:38] <Hobbsee> ScottK: it may not take that long - particularly if it's only for new binary, not new source
[03:39] <ScottK> Is there a way to indicate that in the package?
[03:40] <ScottK> Or does the big magic system in the sky figure that out?
[03:40] <persia> Hobbsee: It's the other way: old binary from new source.
[03:40] <Hobbsee> ah
[03:40] <ScottK> Yes.  Sorry.
[03:41] <ScottK> I'm still pretty new to packaging.
[03:41] <persia> ScottK: The big magic system in the sky is called LP.
[03:43] <ScottK> OK.  Does that mean I need to file a bug against the old package or some such thing to indicate the new source for the binary?  It sounds like I also ought to do a libmail-spf-query-perl/1:1.999.1-4 without the now separate program so things can stay in synch.
[03:44] <persia> ScottK: If the other binaries in libmail-spf-query-perl are still useful, you want to do that.  If you are replacing them with other new packages, it's probably better to raise a removal request (or just have everything conflict with it).
[03:45] <ScottK> Next question for the gurus...  If I am going to repackage libmail-spf-query-perl/1:1.999.1-3 this way for Ubuntu (I will also ask the Debian maintainainer to do a -4 there) what's the right ubuntu version number for my package?  is it -3ubuntu0 to stay below 4?
[03:46] <persia> ScottK: -3ubuntu1
[03:46] <ScottK> Thanks
[03:48] <ScottK> Eventually the other stuff will go away, but the new Perl library, http://revu.tauware.de/details.py?upid=3976, is new from the ground up so both the old and the new ought to be available for a transition period.  It sounds like conflicting is the way to go so people can pick.
[03:50] <persia> ScottK: In that case -3ubuntu1 probably wants to conflict with all the new packages, just to make that clear.  On the other hand, if the new packages conflict, the old package will fade into obscurity, especially if more important packages choose to recommend the new packages.
[03:51] <ScottK> Can I conflict with a package that isn't in the repository yet?
[03:52] <persia> ScottK: Yes.
[03:53] <ScottK> Thanks.
[05:27] <metres> I all, do anyone have an idea on fixing that bug ?  http://lists.gnupg.org/pipermail/gnupg-devel/2005-August/022279.html
[05:36] <nixternal> Laser_away: ^^ :)
[05:38] <persia> metres: You've come at the quietest point in the day (about 9-10 hours from now seems the most active).  My memory of earlier discussion about this issue was that seahorse required en environment variable to be set properly to work within a shell with redirected stdin and stdout.  Looking briefly at debuild, it appears to do make some fairly significant efforts to control which environment variables are passed to the build env
[05:44] <metres> persia : do an update of gnupg may help ?
[05:47] <persia> metres: I'm not sure.  If it works with --preserve-envvar, I would think a patch to devscripts to automatically preserve the necessary variable would be easiest.  If that doesn't work, I'm not sure where the fix should be applied.
[05:49] <metres> persia : I'll try to uncheck the ssh shell issue in the seahorse graphical config...
[05:51] <persia> metres: Looking at seahorse, it looks like you either want to start `seahorse-agent -A` (which is insecure) or pass "--preserve-envvars DISPLAY" to debuild.  I'm not sure what unchecking the ssh shell issue will do.
[05:52] <persia> BTW, there's a bug on the seahorse-agent manpage: it thinks it's a daemon :)
[05:56] <metres> Thank you for your hint persia... have a good day :)
[05:57] <persia> metres: Did it work?
[06:00] <LaserJock> hmm
[06:04] <Hobbsee> LaserJock!!!
[06:05] <LaserJock> Hobbsee!!!
[06:06] <LaserJock> somerville32: are you still up? or just getting up?
[06:06] <somerville32> Still up
[06:06] <somerville32> I never sleep :)
[06:06] <LaserJock> what TZ?
[06:06] <somerville32> ATS
[06:06] <somerville32> @now atlantic
[06:06] <Ubugtu> Current time in Canada/Atlantic: January 09 2007, 01:06:53
[06:07] <Fujitsu_> Afternoon, LaserJock/.
[06:07] <LaserJock> hi Fujitsu_
[06:07] <Hobbsee> somerville32: it doesnt kill you to read logs, you know
[06:07] <somerville32> Hobbsee, Which logs?
[06:08] <Hobbsee> meetings ones, whichever
[06:08] <somerville32> Did I miss a meeting?
[06:09] <Hobbsee> no
[06:10] <somerville32> \o/
[06:10] <LaserJock> hmm, so it seems the only one not confused is Hobbsee
[06:10] <LaserJock> women :/
[06:10] <LaserJock> ;-)
[06:17] <persia> Is there an easy way to download sid sources from a feisty workstation?  I'm going through my patchlist to file debian bugs, and downloading from packages.qa.debian.org is frustratingly inconvenient.
[06:18] <tepsipakki> persia: just add the deb-src line to sources.list
[06:19] <persia> tepsipakki: Doesn't that mean I get the newest available package when I apt-get source foo or aptitude download foo, rather than the sid package?
[06:19] <tepsipakki> and then use 'apt-get -t sid source foo' to download from sid
[06:19] <LaserJock> unfortunately it doesn't quite work like that
[06:19] <persia> tepsipakki: Thanks.
[06:19] <tepsipakki> works for me
[06:19] <persia> LaserJock: No?
[06:19] <LaserJock> there is a bug
[06:20] <tepsipakki> at least on dapper it does :)
[06:20] <LaserJock> well, what happens is it only grabs from one
[06:20] <tepsipakki> yes?
[06:20] <tepsipakki> is that a bug?
[06:21] <LaserJock> no, I mean it doesn't respect -t
[06:21] <LaserJock> it takes from the first deb-src line it finds the package
[06:21] <LaserJock> it works ok with deb lines
[06:22] <LaserJock> but not deb-src
[06:22] <persia> LaserJock: Is there another way that works?  I don't really want to build a sid chroot, but that would be easier than my current workflow.
[06:22] <tepsipakki> oh..
[06:22] <tepsipakki> hmm
[06:22] <LaserJock> persia: dget is at least easier
[06:22] <LaserJock> tepsipakki: yeah, I got all excited too :/
[06:22] <LaserJock> but then I started looking at where the packages were actually coming from
[06:23] <tepsipakki> well, this hasn't been a problem yet :P
[06:23] <tepsipakki> anyway, a bug, yse
[06:23] <tepsipakki> yes
[06:23] <LaserJock> I think if you only have 2 deb-src distros it might work a bit better
[06:23] <persia> LaserJock: So I set my browser to use dget for .dsc files, and continue downloading from packages.qa.debian.org?  I was hoping for mirrors.
[06:24] <LaserJock> persia: well, write something up :-)
[06:24] <persia> /persia starts inspecting at-spy
[06:25] <Hobbsee> persia: use /me
[06:25] <Hobbsee> ie, /me starts
[06:26] <persia> Hobbsee: It's the gap between the fingers and the brain, really.  It's just not automatic.
[06:27] <Hobbsee> hehe
[06:30] <tepsipakki> hmm, quite warm out there, so I'll grab my bike today as well
[06:31] <persia> tepsipakki: Depends where you are - it's only 10 here.
[06:31] <tepsipakki> +5.38C here
[06:31] <tepsipakki> normally s/+/-/
[06:32] <tepsipakki> in January..
[06:32] <persia> That's warm?  Never mind: depends who you are.
[06:32] <tepsipakki> heh
[06:34] <LaserJock> according to Debian bug #152129 you have to have corresponding deb lines for the deb-src lines to have the -t work right
[06:34] <tepsipakki> sucks
[06:36] <LaserJock> so I guess I could add the deb lines too
[06:36] <LaserJock> but that seems a bit messy
[06:36] <tepsipakki> yes, imagin dist-upgrade
[06:36] <LaserJock> I don't want it acidentally grabbing feisty .debs :-)
[06:36] <tepsipakki> +e
[06:36] <persia> LaserJock: Ah, so if you add the deb lines as well, it works?  The other options seem to be related to apt-src and apt-get -c.
[06:37] <LaserJock> persia: it's probably pretty straightforward to write a tool that keeps a local Sources cache
[06:37] <LaserJock> and then does the right dget
[06:38] <LaserJock> the really tricky one would be Launchpad
[06:38] <LaserJock> since it doesn't work with dget (grrr)
[06:38] <persia> LaserJock: apt-get can do that with -c, you just configure for alternate sources and an alternate cache directory.  I'm still playing, but I think it can be done with user-owned workspace (~/apt/...)
[06:39] <TheMuso>
[06:39] <persia> LaserJock: If I get a working wrapper script, I'll paste it somewhere.
[07:55] <persia> Does anyone know which APT option is used to prevent the dpkg run after update?
[07:56] <Hobbsee> dpkg run?
[07:56] <Hobbsee> as in, download only?
[07:58] <persia> Hobbsee: I'm writing a wrapper for apt-get that allows the download of sources or binaries from archives to which the system is not subscribed.  I'm using a local apt repository in the user's home directory, but when I run update, it complains about wanting to update /var/lib/dpkg/lock.  It works fine for downloading stuff after this failure, but I'd rather make it pretty.
[08:00] <persia> The goal is to easily download sid packages to make patches so I can submit things back to Debian, but it might also be useful for those who want to play with feisty sources from an edgy workstation without a chroot.
[08:00] <`6og> --download-only to only aquire packages, as Hobbsee said
[08:01] <persia> apt-get --download-only -c apt.conf update still complains about /var/lib/dpkg/lock.  I'm pretty sure I need something in apt.conf to prevent this behaviour.
[08:02] <Hobbsee> persia: -d
[08:02] <`6og> apt aquires the lock when its run, not when dpkg starts
[08:03] <JaeSharp> Is anyone packaging the Second Life Linux client now that it has been released under the GPL? I was wondering if anyone was already working on it?
[08:03] <somerville32> Interesting idea!
[08:03] <persia> `6og: apt aquires a lock on Dir::State/lists/lock.  This is for dpkg.
[08:49] <dholbach> good morning
[08:53] <somerville32> Morning! :)
[09:11] <\sh> moins
[09:44] <persia> I finished the wrapper.  src-get is available from https://wiki.ubuntu.com/EmmetHikory.  I'd be very happy if anyone could get binary download to work correctly (or knows a better way to do this easily).
[10:52] <somerville32> Gah
[10:52] <somerville32> The archive admins rejected my upload :
[10:54] <Adri2000> somerville32: who rejected your upload?
[10:54] <somerville32> Tollef Fog Heen
[10:54] <somerville32> Simple fix
[10:54] <somerville32> I just need someone to upload it for me
[10:55] <somerville32> debian/copyright had version 2 or later while the source code has version 2 only
[10:55] <Adri2000> okay
[10:55] <somerville32> I'm surprised it got reviewed so quickly by the archive admins
[10:56] <somerville32> I thought they had a big backlog
[11:08] <xerxas> Hi all
[11:08] <somerville32> hi
[11:12] <somerville32> Are there any MOTUs around? :)
[11:13] <somerville32> http://revu.tauware.de/details.py?upid=4009
[11:16] <Lutin> somerville32: not really sure that you should have autoadvocated your package
[11:17] <somerville32> Does it make a difference? :)
[11:17] <Lutin> I think it does, yes :)
[11:18] <Lutin> somerville32: afaik you're not a motu. only motus have to advocate packages
[11:19] <somerville32> Lutin: It doesn't really make a difference - or atleast I don't think it does.
[11:22] <Lutin> somerville32: do whatever you want then
[11:22] <mr_pouit> it's also a way for MOTUs to find quickly package that needs onyl 1 advocate left
[11:22] <mr_pouit> *only
[11:22] <somerville32> Right
[11:22] <somerville32> I just need a motu to upload
[11:22] <somerville32> the package has already been approved
[11:24] <mr_pouit> somerville32, if your package has already been, uploaded, you don't need 2 advocates anymore
[11:24] <somerville32> mr_puit: It was rejected by the archive admin.
[11:24] <mr_pouit> only 1, therefore you shouldn't auto-advocate ^^
[11:25] <mr_pouit> somerville32, I know, I have 3 packages rejected as well
[11:25] <somerville32> Anyhow, I need sleep
[01:48] <proppy> hi!
[01:50] <crimsun> sweet, the soyuz grue has reared its head again
[01:51] <\sh> is this possible: chroot <chroot_dir> SUDO_FORCE_REMOVE=yes apt-get --assume-yes install sudo-ldap ?
[02:21] <siretart> crimsun: you uploaded scorched3d? whats the diff to debian?
[02:26] <crimsun> siretart: dh_iconcache
[02:27] <siretart> oh. hm
[02:27] <siretart> does dh_iconcache exist in debian as well, or are there any plans for it in debian?
[02:27] <crimsun> it doesn't exist in Debian, and afaik people are still "discussing" what changes need to be made
[02:28] <crimsun> http://librarian.launchpad.net/5653813/M78523.patch is the diff I applied against Sid's current scorched3d source package
[02:28] <crimsun> not that it really matters, since soyuz has silently eaten both signed scorched3d uploads I've made in the past hour
[02:33] <siretart> crimsun: damn :/
[02:33] <crimsun> hehe, I'm used to it now
[02:33] <siretart> it would be great to have 40.1d in the archives, since most public servers are running it and won't accept connections from the older version
[02:34] <crimsun> I started writing a script last night to poll my inbox and automatically reupload if the accept doesn't show up within 17 minutes
[02:37] <StevenK> Hrm.
[02:37] <StevenK> Couldn't the time be better spent plotting ways to harm the Soyuz developers? :-P
[02:39] <crimsun> nah. They're paid to work on it; I'm just a grunt who chucks stuff at the archive every so often. ;)
[03:34] <bddebian> Heya gang
[03:46] <lupine_85> quick q., if anyone's willing :) - is ~0foo1 a higher or lower version than ~0foo1~bar ?
[03:50] <dholbach> daniel@lovegood:~$ dpkg --compare-versions ~0foo1 gt ~0foo1~bar; echo $?
[03:50] <dholbach> 0
[03:50] <dholbach> daniel@lovegood:~$
[03:51] <dholbach> ~0foo1 > ~0foo1~bar
[03:51] <lupine_85> ah, cool. thanks :)
[03:51] <dholbach> anytime :)
[03:51] <lupine_85> easier than building two packages and playing with them :D
[03:52] <dholbach> hgehehehe
[03:59] <effie_jayx> dholbach,  where can I find info on how to be a motu... or how to participate... :S?
[03:59] <\sh> wiki.ubuntu.com/MOTU/ ? :)
[03:59] <effie_jayx> the ubuntu-motu-school is it active?
[03:59] <effie_jayx> geee thanks
[03:59] <effie_jayx> :D
[04:00] <dholbach> http://wiki.ubuntu.com/MOTU/Documentation too
[04:00] <\sh> effie_jayx: you're welcome :)
[04:01] <\sh> ajmitch: how much I have to pay you to package more zope/plone packages? ,-)
[04:18] <jonibo> gtk for directfb does not seem to be available in Feisty...
[04:18] <jonibo> ...is it coming back?
[04:27] <Lutin> bddebian: around ?
[04:34] <ScottK> Is anybody available to delete one of my uploads? http://revu.tauware.de/details.py?upid=4008 I just discovered an issue that will require some upstream changes and I don't want anyone to waste their time REVUing it since it has to be updated anyway.
[04:34] <bddebian> Lutin: Sort of, what's up?
[04:34] <crimsun> ScottK: then just note it in a comment
[04:34] <Lutin> bddebian: nothing urgent, just wanted to say that finally gfaim should be ok for review :)
[04:35] <bddebian> Well my REVU records has been sucking lately :-(
[04:35] <ScottK> OK.  Will do.
[04:35] <crimsun> bddebian: at least you're reviewing
[04:37] <imbrandon> hrm something is wrong with the nuke script
[04:38] <imbrandon> its archived for now , i'll nuke it when i can poke siretart
[04:38] <imbrandon> ScottK, ^^
[04:39] <imbrandon> moins all
[04:39] <ScottK> Thanks.  No wonder I couldn't find it when I went to comment on it....
[04:45] <bddebian> crimsun: Thx but I'm not sure what good that is when I'm wrong all the time :(
[04:46] <crimsun> bddebian: you're not wrong at all
[04:46] <crimsun> your comments on revu are solid
[04:46] <bddebian> But I seem to miss a lot :-(
[04:47] <crimsun> that's the nice thing about peer reviews
[04:49] <bddebian> Not after I've already uploaded (aka murrine) :-)
[04:49] <bddebian> s/uploaded/advocated/
[04:52] <davromaniak> bddebian, I corrected ccd2iso, so when you will have some free time, would you take a look at it ?
[04:52] <bddebian> davromaniak: Sure
[04:52] <davromaniak> thanks
[06:21] <LaserJock> geser: oops, gchempaint FTBFS because libgcu-dev still has a dep on libgoffice-1
[06:21] <geser> already fixed
[06:22] <LaserJock> geser: really?
[06:22] <LaserJock> dang your good ;-)
[06:25] <bddebian> Yeah he is
[06:25] <crimsun> time to promote geser to deity status :P
[06:32] <LaserJock> man, I need more machines
[06:32] <LaserJock> too many pbuilder jobs to run at the same time :/
[06:32] <zul>  /join #ubuntu-meeting
[06:33] <LaserJock> zul: why?
[06:33] <LaserJock> :-)
[06:33] <zul> LaserJock: umm...er..
[06:39] <Nafallo> hehe
[06:47] <bddebian> LaserJock: I hear that man.  I need an amd64, a ppc, and a Sparc ;-P
[06:47] <Nafallo> I just need a new laptop :-/
[06:48] <LaserJock> bddebian: I'd just go for more i386's at this point
[06:48] <LaserJock> I'm using all I can at work
[06:48] <LaserJock> and my 2 home computers
[06:48] <crimsun> why don't you ask imbrandon for access?
[06:49] <zul> bddebian: you dont need you want
[06:49] <LaserJock> crimsun: come to think of it, I might already :/
[06:52] <bddebian> zul: No, I NEED :-)
[06:53] <LaserJock> bddebian: why? you keep saying you don't do anything. Which is it? ;-)
[06:53] <bddebian> So I can do nothing on more architectures ;-P
[06:53] <LaserJock> ah
[06:56] <Nafallo> lol
[06:56] <LaserJock> ok, I'd like to sync a NEW package from Debian experimental, do I just need to file a sync bug and subscribe ubuntu-archive?
[06:56] <LaserJock> I think that's right
[06:56] <bddebian> Yep afaik
[06:59] <LaserJock> geser: when did you upload the fix to gchemutils?
[07:03] <geser> LaserJock: https://lists.ubuntu.com/archives/feisty-changes/2007-January/003176.html
[07:04] <LaserJock> geser: ah, it just showed up in LP for me
[07:28] <Lutin> LaserJock: I fixed gfaim on revu, could you have a look ?
[07:29] <Lutin> LaserJock: I can't say the imprec script works fore sure cause I have no printer to test it, but at least the prog no longer segv and finds it properly
[07:30] <LaserJock> ok, I'll add it to the todo
[07:30] <Lutin> thanks :)
[07:31] <LaserJock> i've got a lot of things to do today, but I certainly try to get to it as soon as I can
[07:32] <Lutin> ok LaserJock, thx :]
[07:33] <nixternal> anyone know if a shirt is shipped from Germany to the US (DHL) if it is dutiable or non-dutiable?
[07:34] <LaserJock> I don't know :/
[07:34] <LaserJock> that's a long way to get a shirt
[07:34] <zorglu_> i believe that if you say it is a gift, it is not :)
[07:34] <nixternal> LaserJock: but they are way cheaper than we can get them for here
[07:34] <nixternal> zorglu_: orly
[07:34] <zorglu_> the us has some rules about that, if a gift, notax
[07:35] <nixternal> $50 shipped to Chicago for 1 Polo and 1 T-Shirt both embroidered
[07:35] <nixternal> you can't get screenpressed shirts that cheap here
[08:01] <zul> apple tv? so basically a tivo?
[08:06] <hub> no
[08:07] <ogra> a tv powered by applejuice ?
[08:08] <LaserJock> :)
[08:08] <LaserJock> so now I know why my iMac seems sticky
[08:11] <tenshu> hi all i received a mail from Tollef saying my upload of daxcr to Feisty has been rejected because the licence file was missing from the orig tarball. Since i have no right to upload to Ubuntu the only way to fix this is to send my package back to REVU?
[08:11] <LaserJock> tenshu: that's an easy way to do it
[08:12] <Adri2000> tenshu: yes, or you can ask directly the MOTU who uploaded the rejected package
[08:12] <LaserJock> or you could probably send a fix to the MOTU that uploaded it
[08:12] <Adri2000> LaserJock: :)
[08:12] <tenshu> :-/ erf
[08:12] <LaserJock> ogra: marble rocks!
[08:13] <ogra> LaserJock, ;)
[08:14] <ScottK> I got a similar message (package rejected due to license file missing in orig.tar.gz).
[08:14] <ScottK> I went back to the upstream and he added the URL of the license, but not the actual text.  That's as far as he'll go.
[08:15] <ScottK> There's no confusion about how the code is licensed, just how much bother upstream is willing to go to for Ubuntu.
[08:15] <ScottK> This isn't one of those times where I have to change orig.tar.gz is it?
[08:16] <tenshu> hard punishment to reject the upload for this, we already list it in debian copyright and provide a copy on the system and giving FSF adress
[08:16] <LaserJock> it's better to fix it now
[08:16] <ScottK> You go argue with Tollef and tell me how it comes out...
[08:17] <ScottK> OK.  Is the fix for me to add it to orig.tar.gz?
[08:17] <LaserJock> ScottK: you could probably just provide a patch that has the text from the URL
[08:17] <LaserJock> he might take that
[08:17] <LaserJock> but we do often times act as upstream police
[08:18] <LaserJock> making sure software authors provide good info and enough of it
[08:18] <ScottK> OK.  I was hoping for a more definitive answer than 'might'.  I searched on both the Debian and Ubuntu sites for definitive policy on what has to be in orig.tar.gz and didn't find anything.
[08:18] <LaserJock> ScottK: that's what an archive admin is for :-)
[08:19] <LaserJock> if the archive admin isn't ok with that software going into the repos then it doesnt go
[08:19] <ScottK> Yes, but I was REALLY hoping to be able to say "See, Debian says in xxyyz document that it HAS to be there..."
[08:19] <ScottK> Agreed.
[08:19] <LaserJock> yes, Debian packaging is more art than science, IMO
[08:20] <LaserJock> I would just ask tollef what he suggests
[08:20] <LaserJock> if the upstream refuses to add the file then you need to know what the archive admins will accept
[08:21] <tenshu> does the rules so "hard" on the debian-side?
[08:21] <LaserJock> tenshu: what do you mean by "hard"?
[08:22] <LaserJock> like what they accept and reject?
[08:22] <tenshu> yes
[08:23] <ogra> way harder
[08:23] <tenshu> ok
[08:23] <ScottK> I guess I already know the answer to the "what will the archive admins accept" question, since Tollef said, "rejected because..."
[08:23] <LaserJock> ScottK: well, there can certainly be some dialoge there
[08:24] <LaserJock> like, "Upstream won't put it in there, only a link, can I add the text in a patch or add it directly to the .orig.tar.gz?"
[08:24] <tenshu> ok i correct the upload, can a motu reupload it again? http://revu.tauware.de/details.py?upid=4017
[08:25] <LaserJock> tenshu & ScottK : a good resource for things the archive admins might be looking for is: http://ftp-master.debian.org/REJECT-FAQ.html
[08:25] <ScottK> LaserJock: Thanks.  I'll try that then...
[08:25] <tenshu> LaserJock: thanks too
[08:25] <LaserJock> in the past I've gotten good help from the archive admins when they rejected something of mine
[08:26] <LaserJock> as long as don't say something like "Fix it for me, pleeeease"
[08:26] <LaserJock> :-)
[08:41] <Lutin> Toadstool: around ?
[08:45] <Toadstool> Lutin: well, kinda busy at work right now..
[08:45] <Toadstool> hi everybody
[08:45] <Lutin> Toadstool: ok :)
[09:00] <Lutin> Toadstool: ping->when you'll see that, please tell me what you found wrong in kayali, apart the source tarball :)
[09:01] <Adri2000> crimsun, geser, bddebian: I'm applying for membership today (CC is at 2100UTC), since you have uploaded some packages/acked syncs for me, maybe you will want to say something :]
[09:01] <ajmitch> morning all
[09:02] <bddebian> Heya ajmitch
[09:02] <Lutin> 'morning ajmitch
[09:02] <bddebian> Adri2000: I'm swamped at work but I'll try
[09:02] <Adri2000> thanks
[09:11] <zul> hey ajmitch
[09:19] <Marsmensch> i, wie kann ich den die cpu temp leicht rausbekommen?
[09:19] <Nafallo> Marsmensch: du pratar utrikiska :-P
[09:19] <Marsmensch> h?
[09:20] <Marsmensch> ups wrong channel sorry
[09:20] <Nafallo> hehe :-)
[09:20] <Marsmensch> & wrong server
[09:20] <Marsmensch> wanted to ask on linux.de on quakenet ;)
[09:21] <Nafallo> Marsmensch: I just told you in Swedish that you were talking something other than English :-)
[09:23] <Marsmensch> i just startet xchat to get help with my laptop ... it has become so slow in the last days/week
[09:23] <Nafallo> :-)
[09:24] <Marsmensch> ok, so go on ;)
[09:25] <Nafallo> yay! back to idling ;-)
[09:33] <geser> Tonio_: is it ok if I merge yakuake?
[09:33] <Tonio_> geser: sure, is there a new version available ?
[09:34] <geser> only a new Debian revision
[09:34] <Tonio_> what are the changes ?
[09:35] <Tonio_> I'm not sure the packaging is the same, but if there is a new patch, it can be interesting to merge it indeed
[09:38] <Toadstool> Lutin: there is a bashism in your debian/rules
[09:39] <Lutin> Toadstool: where ?
[09:39] <Toadstool> when you remove the fonts
[09:39] <Toadstool> {font1,font2}.ttf
[09:40] <Lutin> eeek. yes
[09:40] <Toadstool> and why do you use install file dest/ and then mv dest/file dest/another_name?
[09:40] <Toadstool> you can simply use install file dest/another_name...
[09:41] <Lutin> Toadstool: I tried, but instead of changing the name, I was installed in dest/another_name
[09:41] <Toadstool> uh?
[09:41] <Lutin> (in the folder named another_name, with its original name)
[09:42] <Toadstool> that's weird
[09:42] <Toadstool> I'd take a closer look at this and I'd use kayali.dirs instead of adding a mkdir in debian/rules too
[09:43] <Lutin> Toadstool: would install -d be better ,
[09:43] <geser> Tonio_: looking at the changelog there aren't any interesting changes beside that Debian is now also at 2.7.5
[09:43] <Lutin> ?
[09:43] <Sp4rKy> Toadstool: heya
[09:43] <Toadstool> hey Sp4rKy
[09:43] <Tonio_> geser: no need to merge then...
[09:44] <geser> Toadstool: and it uses now quilt instead of simple-patch-system
[09:44] <Toadstool> geser: -EWRONGNICK :)
[09:44] <geser> indeed
[09:44] <Toadstool> Lutin: install -d for what?
[09:45] <Lutin> Toadstool: to create install dirs, instead of mkdir
[09:46] <Toadstool> well, you still have to put this in a target in your debian/rules... imo, the smaller the debian/rules the better when it comes to cdbs, you should use debian/kayali.dirs :)
[09:47] <Lutin> Toadstool: ok :)
[09:51] <Lutin> Toadstool: also asked upstream for the source tarball, he told me he was going to release a cleaner one :]
[09:52] <Toadstool> great! :)
[09:54] <Toadstool> Lutin: in your build-deps, you should move python-central from BUild-Depens-Indep to Build-Depends
[09:54] <Lutin> Toadstool: why ? it's an archindep package
[10:00] <Toadstool> Lutin: 'cause lintian complains about it? :)
[10:01] <Lutin> Toadstool: :/
[10:01] <Toadstool> Lutin: and also according to lintian and the python policy you should use debhelper (>= <IP_ADDRESS>) in debian/control
[10:01] <Lutin> oh thanks, didn't see that
[10:02] <LaserJock> well, lintian complainging about Build-Depends vs Build-Depends-Indep can sometimes be misleading
[10:04] <Lutin> hummm
[10:15] <metres> Hi all, i'm having a problem signin files with debuild... I had this error when trying..: http://paste.ubuntu-nl.org/986/
[10:17] <LaserJock> metres: that's a known bug with seahorse and debuild
[10:18] <metres> LaserJock : but it was working...
[10:18] <LaserJock> hmmm
[10:18] <metres> I think before changing locales
[10:18] <slomo> metres: hmm, works fine for me... is this on feisty?
[10:18] <metres> edgy
[10:19] <slomo> ok, worked on edgy too for me ;) i use it all the time... does seahorse-agent still run, is the file there present?
[10:19] <slomo> does restarting seahorse-agent (killall seahorse-agent && seahorse-agent) fix it?
[10:20] <metres> no seahorse running
[10:21] <slomo> ok so it was killed at some point for some reason... hm
[10:21] <slomo> probably fixed with 0.9.10 in feisty, the version in feisty has one million bugs fixed compared to edgy ;)
[10:21] <metres> doesnt fix the problem... gpg: problem with the agent - disabling agent use
[10:22] <metres> when executing debuild
[10:22] <slomo> how is it started for you? gnome session properties?
[10:23] <metres> I dont understand what you asked slomo...
[10:23] <metres> I also have this ewarning : gpg: WARNING: unsafe ownership on configuration file `/home/metres/.gnupg/gpg.conf'
[10:25] <guibis> hi slomo
[10:25] <slomo> hi guibis
[10:25] <slomo> metres: how do you start seahorse?
[10:26] <metres> automatically in the session , I supposed...
[10:26] <metres> I just start it in the shell but it does the same error
[10:27] <metres> If I want to update gnupg and seahorse, I on;y have to download source and install it ?
[10:28] <metres> or do I have to uninstall..? cause uninstalling gnupg uninstall lots of package including gnome.desktop...
[10:29] <metres> I try dpkg-reconfigure gnupg and seahorse...
[10:33] <Lutin> Toadstool: lintian doesn't say anything about python-central in B-D-Indep
[10:37] <Toadstool> Lutin: hmm?
[10:38] <Toadstool> Lutin: lintian -i kayali_0.3.1-0ubuntu1_i386.changes? :)
[10:41] <marola> hi people
[10:41] <marola> good evening for every body
[10:41] <Lutin> Toadstool: nope
[10:41] <Lutin> it's not listed
[10:42] <Toadstool> Sp4rKy: which version of lintian?
[10:42] <Toadstool> er
[10:42] <Toadstool> Lutin: ^
[10:42] <marola> anyone has ubuntu 6.10 installed on sony vaio?
[10:42] <Lutin> Toadstool: 1.23.16ubuntu2
[10:43] <Toadstool> Lutin: 1.23.27ubuntu1 here
[10:43] <Sp4rKy> Toadstool: :)
[10:43] <Toadstool> Sp4rKy: sorry ;)
[10:43] <Sp4rKy> np :d
[10:43] <Lutin> Toadstool: I run it on Sp4rKy's server, it runs dapper =)
[10:44] <Toadstool> well i run it on a sarge server but in a feisty chroot ;)
[10:44] <Lutin> :)
[10:47] <Lutin> Toadstool: ok, I can see it on my edgy box
[10:59] <crimsun> Adri2000: sorry, meetings IRL. Do you still need me to vouch?
[11:01] <Adri2000> crimsun: if you can't, no problem. it should be ok anyway (I have good comments from Gauvain on my wiki page :))
[11:02] <persia> crimsun: Thanks for all the uploads.  I'm curious, did I do something wrong with ksimus (74967), or did it just get lost in the u-u-s transition.
[11:03] <crimsun> bug 74967
[11:03] <Ubugtu> Malone bug 74967 in ksimus "Desktop entry not shown in GNOME" [Undecided,Confirmed]  https://launchpad.net/bugs/74967
[11:03] <crimsun> the latter
[11:03] <crimsun> it never crossed my inbox
[11:03] <persia> crimsun: OK.  Thanks.
[11:05] <crimsun> Adri2000: I won't be able to make it (particularly since you're fairly far down the list, and I have another lecture in 10 minutes)
[11:05] <crimsun> Adri2000: I'll leave some notes on your wiki page
[11:06] <Adri2000> great, thank you
[11:18] <Adri2000> crimsun: #ubuntu-bugs? you meant -motu?
[11:51] <allee> hi, what tool is used for the pkg merge at http://merges.ubuntu.com/ ?   I would like to use it to merge against debian experimental pkgs.
[11:52] <LaserJock> you mean, what tool is used to create merges.ubuntu.com?
[11:53] <LaserJock> allee: ^^?
[11:53] <allee> LaserJock: only the part that creates as output from three releases thttp://merges.ubuntu.com/d/digikam/
[11:54] <allee> LaserJock: I've the base, lasted kubuntu and experimental sources on disk.  now I would like to get what merges.u.c shows
[11:55] <persia> allee: Are you looking for debdiff?
[11:55] <LaserJock> allee: well, that is MoM (Merge-O-Matic) which is a proprietary app written by Keybuck
[11:56] <LaserJock> but you could probably at least script the debdiffing parts pretty easily
[11:56] <allee> persia: no. something like debmerge debian-base debian-lastest, kubuntu-lasted
[11:57] <persia> allee: I think you'd need to script that.
[11:57] <LaserJock> allee: you'd have to talk to Keybuck, but I think it's too tied to LP/Canonical to be useful outside
[11:57] <LaserJock> *Keybuk
[11:58] <allee> LaserJock: okay, thx.  I'll do it with old-bug-free tools ;)  Problem at hand is not complicated to merge.  but I'm lazy, so I thought I ask ;)
[11:58] <LaserJock> :-)
[11:59] <persia> allee: You might get something useful with `dpkg-source -x kubuntu-latest; debdiff debian-base debian-latest | patch`, but this only works if there's not a new upstream version.
[12:01] <LaserJock> dang, if only I could get sabdfl to ask me what my LP wishlist was :-)
[12:04] <persia> LaserJock: I'm reminded, did you want my script to collect alternate distribution sources?
[12:04] <Toadstool> LaserJock: what would you answer? :)
[12:07] <LaserJock> Toadstool: well, I'd have to collect my thoughts for a little bit
[12:07] <LaserJock> but +subscribedbugs by default
[12:08] <LaserJock> being able to subscribe to just tasks
[12:08] <LaserJock> dropdown menus for status changes
[12:08] <LaserJock> xml-rpc support
[12:08] <persia> ls
[12:09] <LaserJock> Toadstool: ^^ is a few
[12:09] <LaserJock> persia: sure
[12:10] <persia> LaserJock: https://wiki.ubuntu.com/EmmetHikory?action=AttachFile&do=get&target=src-get
[12:10] <Toadstool> LaserJock: yay for xml-rpc! :)
[12:10] <persia> It's not very robust, but it works for me.
[12:13] <Toadstool> persia: for the download part, you could use aptitude download
[12:13] <LaserJock> persia: interesting, thanks


[01:40] <Elliria> Hey there, does Kdialog no longer have an official page?
[01:40] <Elliria> Neither https://develop.kde.org/deploy/kdialog/ nor http://developer.kde.org/documentation/tutorials/kdialog/t1.html work for me.
[01:41] <Elliria> Also, the https://techbase.kde.org/Development/Tutorials/Shell_Scripting_with_KDE_Dialogs page, that used to be the main Kdialog page, now links to the first of those two links above, so I'm at an impasse.
[04:51] <Guest37> Hello, can someone help me? In this funny world of Linux/Kubuntu, everything works fine the other day, and one day not... Yesterday, my dual monitors worked perfect. I shut down the PC, and today, only 1 monitor detected
[04:52] <Guest37> In screen settings, the other monitor gets recognized, but is "Inactive". so i activate it, and set it as main monitor, but "Failed to save config due to error"-message pops up
[04:52] <Guest37> How can debug this?
[04:55] <Guest37> Nevermind! It was not an linux issue... it was the monitor who needed a cold reboot (unplug power and clear capacitors)
[08:38] <Carlos_HDG> to all, I have been searching a while, however I can't find anything info on it. Does any one has the default KDE theme of Bluestar Linux?
[09:38] <koffeinfriedhof> Carlos_HDG: Better ask at the Bluestar Linux channel if they have one. The default plasma themes are located in /usr/share/plasma/{look-and-feel,desktoptheme,…}.
[09:56] <Carlos_HDG> can anyone share that with me?
[09:56] <Carlos_HDG> thank you
[12:43] <BluesKaj> Hi all
[15:32] <vivek> hello
[15:32] <Guest8436> i am new in this conversattion
[15:32] <Guest8436> NickServ
[17:25] <mmikowski> Elliria: Ping me about kdialog if you return.
 Bg8k
 B98K
 I'm trying to use the video card in my lenovo e580, a Lexa PRO [Radeon 540/540X/550/550X / RX 540X/550/550X], as my main gpu, but I'm currently having problems in that I can't enable it.
 via lshw, I see it regularly, along with the internal cpu one.
 I tried installing the drivers on the site ( specific for the rx550, although I don't think they are the correct ones ), but even so nothing to do.
 i also tried forcing it from grub via the command
 amdgpu.dc=1 radeon.modeset=0
 but even so nothing to do. could anyone help me ?
 I am new to Kubuntu
 I choose the Kubuntu LTS
 Should i had to choose the latest one?