[00:00] <RAOF> Wayland :)
[00:00] <slangasek> sigh
[00:00] <lifeless> gl is overrated
[00:00] <slangasek> RAOF: well I don't see wayland on the CD either, so let's split it into a separate Conflicts/Replaces/Provides: libcairo2 build? :)
[00:01] <RAOF> slangasek: Things will undoubtebly have versioned depends on libcairo2.  I guess we could rebuild all the rdepends, though.
[01:08] <ohsix> is there a way to get aptitude to say what source a package is from, like -proposed or whatnot
[01:10] <ohsix> also theres a new debdiff on #651931 sponsors was only just removed not long ago, can someone look and see if it's appropriate to re-add them?
[01:10] <ScottK> appropriate to readd is you think so.
[01:12] <ohsix> ok, wasn't sure; don't want to annoy the subscribers :]
[01:13] <ohsix> and sponsors is already back on there, so nevermind me
[01:13] <broder> i don't think anybody gets e-mailed directly from being on ~ubuntu-sponsors
[01:13] <broder> but subscribing sponsors causes it to show up on the sponsorship queue (http://reports.qa.ubuntu.com/reports/sponsoring/index.html)
[01:14] <ohsix> ok good to know
[02:36] <basix> can someone please take a look at this bug? https://bugs.launchpad.net/unity/+bug/791660 It needs triaging.
[02:44] <micahg> basix: #ubuntu-bugs is generally for bug triage
[02:44] <basix> micahg, thanks
[03:35] <fattire> holy crap...  this 9 year old issue is STILL  not patched https://bugzilla.gnome.org/show_bug.cgi?id=86382
[03:36] <fattire> nothing big-- just vertical gnoem-panels.
[03:36] <fattire> "new" hah
[03:39] <charlie-tca> That's Gnome bugzilla, new doesn't always mean "new"
[03:40] <ScottK> That and you probably want to troll in #gnome or wherever they hang out.
[03:40] <ScottK> There are bugs I filed in the mozilla bugzilla in the 90s that are still open.
[03:40] <ScottK> Or pre mozilla 1.0, whatever decade that was in.
[03:41] <ajmitch> back when it crashed every 30 seconds
[03:41] <ScottK> No.  Pre-mozilla 1.0, not pre-firefox 1.0.
[03:42]  * ajmitch is remembering the mozilla milestone releases, long before firefox was around
[03:42] <ScottK> OL
[03:42] <ScottK> OK
[03:42] <ajmitch> I probably still have them on an old computer
[03:42] <ScottK> It seemed reasonably stable to me, but that was a long time ago and I was probably comparing it to IE.
[03:43] <ajmitch> this was also when I was building KDE from CVS HEAD & using it as my main desktop
[03:43] <ajmitch> the days of being young & foolish
[04:56] <micahg> pitti: BTW, the retracer never made it to my lightdm bugs
[05:56] <pitti> apw: I restarted it
[05:57] <pitti> cjwatson: oh, thanks! we can still compare them to the regular daily ones on cdimage, or are they disabled now?
[05:57] <pitti> micahg: presumably these are for oneiric? we don't have an oneiric retracer yet, and apport disabled still
[06:03] <micahg> pitti: ah, yes, when do the retracers for oneiric get started?  I figured apport's disabled because you don't want a flood of crashes, but if one enabled it retraces would occur
[06:03] <pitti> micahg: mostly because in the first weeks of a release, the maintenance of the chroots is quite horrible, and not worth the effort
[06:04] <pitti> micahg: we usually enable them around alpha-2
[06:04] <pitti> before that, the daily churn of updates is so high that we often get fixes before even seeing reports
[06:04] <micahg> pitti: hmm, what should I do in the mean time, lightdm keeps crashing :)
[06:06] <pitti> you can still report it with a locally generated stack trace
[06:07] <micahg> robert_ancell: ^^^
[06:08] <robert_ancell> micahg, ah, that explains it
[06:08] <robert_ancell> micahg, are you still getting crashes in 0.3.7-0ubuntu2?
[06:08] <micahg> yep
[06:09] <robert_ancell> micahg, :( I'm in the process of finishing off 0.4.0.  Has a few small fixes and lots more paranoid code.  Hoping this will help, if not need those stack traces!
[06:10] <micahg> robert_ancell: k ,I'll close the bugs and wait for 0.4.0, if I still get the crash, I"ll retrace locally and file, BTW, I gave you a bug on icons earlier
[06:11] <robert_ancell> micahg, yeah I think the icons have moved around in GNOME3, haven't looked into it yet
[06:11] <pitti> micahg: oh, does it stop crashing if you install gnome-icon-theme-full?
[06:12] <micahg> pitti: idk, I can install that and see what happens
[06:18] <pitti> cjwatson: congrats for getting live-build working! yay for shared code
[06:58] <didrocks> good morning
[07:01] <dholbach> good morning
[07:33] <geser> tkamppeter: Hi, is it expected in oneiric that my printer stops printing until I modify the queue to have the uri contain the serial number?
[07:42] <apw> pitti, thanks
[07:57] <pitti> RAOF, directhex: hmm, is libmono-dev obsolete? I can't install cli-common-dev and libmono-dev at the same time now, but packages like launchpad-integration b-dep on both
[08:00] <RAOF> pitti: Yes.  It's now libmono-2.0-dev.  But launchpad-integration shouldn't really b/d on it; it's for apps which *embed* a mono runtime.
[08:00] <RAOF> And I presume that launchpad-integration doesn't embed a JIT engine :)
[08:00] <StevenK> ... it might
[08:00] <StevenK> :-)
[08:01] <RAOF> pitti: libmono-cil-dev contains mono.pc, for those cases where libraries want to go ‘do I have a mono runtime, should I build CIL bindings?’.
[08:02] <pitti> RAOF: ah, that's the one that Breaks: libmono-dev (<< 2.10~)
[08:02] <pitti> but libmono-dev is NBS, so there is no 2.10 version
[08:03] <pitti> so that Breaks: looks wrong
[08:04] <RAOF> Well, it contains a file conflict, so it declares a Replaces: libmono-dev (<< 2.10~), but it doesn't actually provide the things that libmono-dev provides (ie: the ability to link to the JIT engine).
[08:05] <pitti> RAOF: right, but mono stopped building libmono-dev
[08:07] <RAOF> Yeah.  It got renamed to libmono-2.0-dev
[08:07] <pitti> RAOF: ah, thanks; I'll update l-i's b-deps then
[08:08] <RAOF> Anything that *actually* build-depends on libmono-dev as an embed-mono-into-my-app library isn't satisfied by libmono-cil-dev, and should go to libmono-2.0-dev.  Anything that build-depended on libmono-dev to pick up mono.pc should build-depend on libmono-cil-dev.
[08:28] <apachelogger> robert_ancell: ping
[08:48] <cjwatson> pitti: compare> live-build images *are* the regular daily builds now
[08:52] <robert_ancell> apachelogger, hi
[08:53] <apachelogger> robert_ancell: ahoy, is LightDM covered by the canonical contributor agreement?
[08:53] <robert_ancell> apachelogger, no
[08:54] <apachelogger> robert_ancell: ever going to be?
[08:54] <robert_ancell> apachelogger, no
[08:54] <apachelogger> ok, thanks :)
[08:54] <robert_ancell> apachelogger, the greeter we develop will be afaik, but the rest of it now
[08:54] <robert_ancell> now
[08:54] <robert_ancell> no
[08:54] <robert_ancell> ignore those extra w's
[08:54] <apachelogger> robert_ancell: http://lists.kde.org/?t=130799239200004&r=1&w=2
[08:55] <apachelogger> robert_ancell: you might have a comment on http://lists.kde.org/?l=kde-core-devel&m=130803242022398&w=2
[08:57] <RAOF> slangasek: Incidentally, rock on the multiarch.  Mesa works very nicely.
[09:46] <seb128> ev, hey, let me know when you are around to speak about cheese
[09:47] <seb128> pitti, so new cheese depends on the clutter stack as you noticed, we wouldn't really need it in main out of the fact that ev wants to use it in ubiquity to take user pictures
[09:48] <pitti> *nod*
[10:43] <ev> hi seb128, I'm around now
[10:43] <seb128> hey ev
[10:45] <seb128> ev, the discussion shifted a bit since, new totem will use clutter-gst as well and empathy will use libcheese in at least an optional way
[10:53] <pitti> tseliot: hm, I just fixed the FTBFS of xorg-options-editor-gtk, and converted to dh7+dh_python2, but it's still broken
[10:54] <pitti> tseliot: it depends on libpolkit-gnome0 (which was dropped ages ago), and uses glade, etc.
[10:54] <pitti> this would need some serious porting
[10:54] <pitti> is it actually still useful? we don't even have binaries of this package for any supported release, last upload was in jaunty
[10:56] <tseliot> pitti: probably not. bryce should write a better tool for failsafe-x
[10:57] <pitti> tseliot: so it seems we should just remove the source instead?
[10:57] <pitti> it wouldn't actually change anythign visible for users, as there are no .debs anyway
[10:57] <ev> seb128: okay, I'll pay close attention to that thread on warthogs.
[10:57] <tseliot> pitti: yes, that would be fine
[10:57] <pitti> tseliot: ok, doing; thanks!
[10:57] <ev> seb128: ultimately we need this functionality, whether it comes from cheese or not.
[10:57] <tseliot> pitti: thanks for your help
[10:57] <seb128> ev, right
[10:57] <ev> I talked to the design team yesterday (John Lea) and he said it was a requirement for their ongoing work
[10:57] <ev> okay
[10:58] <seb128> ev, well clutter is probably fine for your usecase
[11:00] <seb128> we have 2 discussions to have there, one being a CD space one for clutter, the second one being about whether we consider clutter going enough to handle our video rendering
[11:00] <ev> right
[11:59] <Daviey> cjwatson: thanks for attacking the sync queue.
[11:59] <cjwatson> np
[12:28] <tkamppeter> pitti, Mike Sweet accepted my USB URI migration patch and my patch to support USB-to-parallel adapters.
[12:31] <geser> tkamppeter: Hi, is it expected in oneiric that my printer stops printing until I modify the queue to have the uri contain the serial number?
[12:41] <tkamppeter> geser, no. It should simply print.
[12:42] <tkamppeter> geser, if you have a cheapo laser from HP, you will need an additional foo2zjs update depending on your configuration.
[12:47] <geser> tkamppeter: no, a Kyocera FS-1010
[12:48] <geser> the printer got stopped because the "usb backend failed", the cups log suggested to readd the queue to get the serial number added
[12:48] <geser> and after modifying the queue the printer started to print again
[12:49] <geser> the queue changed from "usb://Kyocera/FS-1010" to "usb://Kyocera/FS-1010?serial=..." (can diff the printers.conf again when I'm home again)
[12:52] <mdeslaur> !pilot in
[12:52] <mdeslaur> @pilot in
[13:15] <pitti> tkamppeter: oh, nice!
[13:17] <juliank> sabdfl: Could oneiric + 1 include penguin in the name please?
[13:18] <juliank> That's a chance you don't get every time.
[13:19] <ogra_> heh
[13:28] <juliank> ogra_: I just don't want to wait until "tinkering tux"
[13:32] <lynxman> ping Daviey
[13:34] <sabdfl> juliank: maaaayybe
[14:10] <smoser> stgraber, was i mistaken ? i thought you had loaded x2go client into the archive.
[14:35] <stgraber> smoser: I have python-x2go in the archive, not x2goclient (yet)
[14:38] <smoser> i was under the impression that python-x2go sat on top of x2go-client.
[14:39] <stgraber> nope, it uses python-paramiko for ssh and nxproxy for the X rendering part
[14:57] <Cas07> hi im trying to backport a PPA to lucid and karmic but i get this error in buildlog
[14:58] <Cas07> dh clean --with python2; dh: unable to load addon python2
[14:58] <OdyX> Cas07: dh_python2 has not been backported yet.
[14:59] <tumbleweed> Cas07: dh_python2 hasn't been backported to lucid yet (bug 788524), and won't be backported to karmit (out of support)
[14:59] <Cas07> hrmm
[15:00] <Cas07> thanks for that, OdyX, tumbleweed
[15:12] <Cas07> the old package used --with quilt what is the difference?
[15:16] <tumbleweed> Cas07: two, unrelated changes. First it must have switched from using quilt explicitly to source format 3.0 (quilt) where the patching is handled by dpkg-source. Second: it switched from (presumably) python-support to dh_python2
[15:16] <Cas07> ahh silly me
[15:17] <Cas07> so if i add python-support as a build dep and just remove python2 is should be ok
[15:20] <tumbleweed> Cas07: it may easily be more complicated than that, I'm afraid
[15:21] <Cas07> is there any way to test the build other that sending to launchpad?
[15:23] <Cas07> oh i suppose if i make those changes it would complain on my system if it was wrong
[15:38] <tumbleweed> Cas07: you can test build on your own hardware, yes
[15:39] <Cas07> how would i get that same error for karmic or lucid builds? as they build the debs fine for me
[15:40] <Cas07> obviously i now know the issue but its more for the future
[15:40] <tumbleweed> Cas07: about time to move this out of #ubuntu-devel, I think. #ubuntu-packaging?
[15:40] <Cas07> oh sorry
[16:14] <lynxman> ping slangasek
[16:28] <frafu> Hi pitti. We have an error building onboard (trunk) with dist-utils-extra and we are wondering whether we should work around it or whether dist-utils-extra is going to be adapted. marmuta, who is working on onboard left a comment about it in a bug thread marked as fixed: https://bugs.launchpad.net/python-distutils-extra/+bug/746565 Could you please have a look at it if you have time? Thanks.
[16:28] <pitti> frafu: hi
[16:28] <pitti> frafu: if it's a regression in -proposed, then we'll fix it of course (and not publish it to -updates)
[16:31] <frafu> The problem is happening also in oneiric.
[16:32] <pitti> right, because the change landed in oneiric first
[16:35] <frafu> pitti: Do you need more information to fix it? In that case, I will tell marmuta to provide it in the bug thread mentioned above.
[16:36] <pitti> frafu: this can be reproduced just by trying to build onboard in oneiric?
[16:36] <mdeslaur> @pilot out
[16:36] <pitti> frafu: if it requires more steps, a reproduction recipe would be appreciated
[16:40] <slangasek> lynxman: hi there
[16:41] <lynxman> slangasek: morning :)
[16:41] <lynxman> slangasek: I uploaded a new package to the ppa with all the corrections, let me know what you think
[16:41] <lynxman> slangasek: https://launchpad.net/~lynxman/+archive/ppa
[16:41] <slangasek> lynxman: sorry, what ppa is that?  The package I was reviewing was in the Ubuntu NEW queue... ah :)
[16:42] <lynxman> slangasek: that's where zul got the one that he sponsored from :)
[16:44] <frafu> pitti: Yes, it is reproducible by simply trying to build a checkout of the trunk of onboard. Thanks for fixing it when you have time.
[16:45] <pitti> frafu: https://code.launchpad.net/~onboard/onboard/main?
[16:45] <frafu> pitti: yes
[16:49] <free`> hello anyone using bzr merge-upstream?
[16:50] <free`> I'm trying to run a command like "bzr merge-upstream --version 0.18.1+bzr393 ../storm-0.18.1+bzr393.tar.gz" but it looks I don't get tags created properly
[16:50] <free`> http://pastebin.ubuntu.com/626639/
[16:50] <free`> maybe I'm doing something wrong?
[16:50] <free`> (see "upstream-0.18.1+bzr393 ?" I assume it should be "upstream-0.18.1+bzr393 1.1.5")
[17:03] <ondrej> Hi, when and how is new Debian packages pulled to Ubuntu?
[17:03] <ondrej> I wonder why golang hasn't been picked up yet.
[17:04] <free`> nevermind, solved, I had to commit the packaging head
[17:04] <mterry> doko, heyo, sorry if this is a repeat, but I'd like a MIR review for bug 491644 when you get a chance
[17:05] <doko> mterry: yes, seen. yesterday was bank holiday. will do it later today
[17:06] <mterry> doko, yar, figured
[17:06] <mterry> doko, thanks!
[17:16] <pitti> mterry: it actually is oneiric-alpha-1, just the betas lose the code name :)
[17:16] <mterry> pitti, guh!
[17:16] <pitti> mterry: I fixed your spec harder
[17:17] <mterry> pitti, :)  thanks.  Seems confusing?  Is there a reason we don't accept either form?
[17:17] <pitti> mterry: it's just what LP defines
[17:17] <pitti> look at the spec's milestone selector
[17:18]  * mterry grumbles
[17:18] <pitti> https://launchpad.net/ubuntu/oneiric, see "Milestones"
[17:19] <Kaleo> I get an error during the setup of the 'at' package in an Oneiric freshly created chroot: chown: invalid user: `daemon:daemon'
[17:19] <pitti> oh-uh -- daemon is a static uid
[17:19] <Kaleo> the schroot was created with debootstrap on lucid
[17:19] <pitti> debootstrap should create it
[17:19] <mterry> pitti, I would almost accept that there is some method to that madness (like, a progression from development to 'baked') if the updates weren't called oneiric-updates
[17:20] <pitti> mterry: oh no, that would be consistent!
[17:23] <Kaleo> pitti: what's even more odd is that there is no user daemon on the host machine
[17:29] <Keybuk> IP=`ifconfig  | grep 'inet addr:'| grep -v '127.0.0.1' | cut -d: -f2 | awk '{ print $1}'|head -n 1`
[17:29] <Keybuk> kirkland: seriously, you put ^ *that* in a shell script this year?
[17:30] <kirkland> Keybuk: not *I*
[17:30] <kirkland> Keybuk: just shit I found
[17:30] <kirkland> Keybuk: in packages I've reviewed
[17:30] <Keybuk> hey, it's in your branch ;)
[17:30] <Keybuk> http://bazaar.launchpad.net/~kirkland/principia/oneiric/musica/trunk/view/head:/hooks/website-relation-joined
[17:31] <kirkland> Keybuk: right, from SpamapS :-)  which is the straw that broke the camels back, and forced me to post https://lists.ubuntu.com/archives/ubuntu-devel/2011-June/033459.html
[17:31] <kirkland> Keybuk: so yes, i duplicated the mistake
[17:32] <Keybuk> tsk tsk
[17:32] <kirkland> Keybuk: on purpose to demonstrate the need for a better, unified utility
[17:32] <Keybuk> re: your mail - again, any utility written this year should not default to IPv4
[17:32] <kirkland> Keybuk: here's what I want to use: http://people.canonical.com/~kirkland/ipaddr
[17:34] <kirkland> Keybuk: i agree with supporting ipv6;  but by default?  i question the utility of that
[17:35] <Keybuk> kirkland: well, otherwise I'd have to go around and edit all the scripts that don't pass -6 to your utility
[17:35] <Keybuk> if you're writing a tool to "return the address of the interface" it should return the address(es) of the interface
[17:35] <Keybuk> if the interface only has IPv6, it should return it
[17:36] <kirkland> Keybuk: right and then we're back in piping to awk/sed :-)
[17:37] <Keybuk> since the IPv4 address space is nearly exhausted, you have to assume at this point that any new servers are going to be 6 only
[17:37] <kirkland> Keybuk: since the utility is not yet in the archive, you're already "going around and editing all the scripts"
[17:37] <kirkland> Keybuk: to use the utility
[17:37] <Keybuk> kirkland: actually, I'm mostly just deleting them
[17:37] <micahg> kirkland: apparently broder found a utility that already does most of what you're looking for
[17:37] <Keybuk> it turns out that all the tools that want your IP address don't need it
[17:38] <Keybuk> and that it's already a bad sign if they do
[17:38] <kirkland> micahg: it does not detect the default route
[17:38] <Keybuk> and that there's a *great* tool for determining an interface name
[17:38] <Keybuk> it's called DNS
[17:38] <Keybuk> ;-)
[17:38] <kirkland> Keybuk: okay, what if the tool *required* either a -4 or a -6 parameter?
[17:39] <kirkland> Keybuk: and dumped you to a usage statement with out it
[17:39] <kirkland> Keybuk: 'ipaddr -4'
[17:39] <kirkland> Keybuk: 'ipaddr -6'
[17:39] <kirkland> Keybuk: 'ipaddr -6 wlan0'
[17:39] <Keybuk> portal has IPv6 address 2600:3c01::f03c:18a9:0524:3620
[17:39] <kirkland> Keybuk: 'ipaddr -4 eth1'
[17:39] <Keybuk> kirkland: then the tool would be mis-used by all the scripts
[17:39] <Keybuk> and again, pointless
[17:39] <Keybuk> all the scripts would call it with just -4
[17:40] <Keybuk> ^ no IPv4 address for this machine
[17:40] <kirkland> Keybuk: great, then the tool should return the ipv6 address if there is no ipv4 address
[17:40] <kirkland> Keybuk: DWIMNWIS
[17:40] <james_w> why would anything care which type of address it got? Is the most likely reason that it doesn't support v6 yet?
[17:41] <Keybuk> kirkland: I think with -4 it should only return v4, with -6 it should return only v6
[17:41] <Keybuk> without arguments, it should examine many factors to determine the best address
[17:41] <Keybuk> and it may well be the IPv6 address rather the IPv4 if it's a global scope address
[17:41] <kirkland> Keybuk: i can go with that
[17:42] <Keybuk> because you can *use* the IPv6 address to access both v6 and v4 hosts
[17:42] <kirkland> Keybuk: again, i'm good with that
[17:42] <Keybuk> if you returned the v4 address in that situation, you'd be cutting yourself off from the v6 Internet
[17:42] <Keybuk> (default configured inet6 addresses have a Link scope - if someone has a Global scope v6, it means they really can do v6)
[17:43] <kirkland> Keybuk: taking a step back, do you agree with the usefulness/mission of such a utility?
[17:44] <Keybuk> kirkland: well, I'm not sure why things want the IP
[17:44] <Keybuk> if things want the IP, having a tool to return it would be useful
[17:44] <Keybuk> it may be better as a patch to "ip" mind you, but ...
[17:44] <Keybuk> but maybe all those things that think they want the IP really really don't
[17:44] <kirkland> Keybuk: configuration, setup of server utiltiies
[17:46] <cjwatson> the notion that you have a single one true IP address is wrong
[17:46] <Keybuk> kirkland: what configuration requires the IP?
[17:46] <lool> right, if they query the IP once on startup, what will happen if you reconnect and get a different one, or get additional ones for random reasons
[17:48] <cjwatson> a sane server default is usually just to listen on all interfaces, not to try to figure out the IP address in advance and listen on that
[17:49] <Keybuk> cjwatson: yeah, certainly by default
[17:49] <Keybuk> listening on selected interfaces is not a good default
[17:50] <Keybuk> and as for communicating between ports on the server
[17:50] <Keybuk> e.g. one service talking to each other
[17:51] <Keybuk> that's *WHY* we have a files nsswitch
[17:51] <Keybuk> use "http://localhost/..."
[17:51] <Keybuk> localhost will be magically resolved to MAGIC
[17:51] <cjwatson> other IPC methods may well be better than IP for that anyway
[17:51] <Keybuk> (in my server's case ::1, in other's maybe 127/8 somewhere)
[17:51] <Keybuk> cjwatson: sometimes; though there are lots of services that use HTTP to each other
[17:52] <Keybuk> e.g. the whole Web 2.0 stack, where it's your Javascript making HTTP requests to your Node.js backend making HTTP requests to your database server, etc.
[17:52] <cjwatson> yeah
[17:52] <micahg> kenvandine: if folks only had a diff of the vcs-bzr, why was it a merge?
[17:53] <kirkland> Keybuk: in several examples, we have a number of different services (cobbler, puppet, eucalyptus) that provision systems, and need to tell those systems (by serving a configuration file, or a preseed) where some resource lives; that location is the IP address of the server providing that configuration or preseed
[17:53] <Keybuk> kirkland: no, that location should be "localhost"
[17:54] <kirkland> Keybuk: sorry, no
[17:54] <Keybuk> kirkland: sorry, yes
[17:54] <kirkland> Keybuk: localhost then on that node will be its dumb self
[17:54] <Keybuk> yes
[17:54] <kirkland> Keybuk: rather than the server that it needs to federate against
[17:54] <Keybuk> if you have two servers A, and B
[17:54] <kirkland> Keybuk: server A provides service foo
[17:54] <Keybuk> there is NO WAY for server A to know what IP address server B needs to contact it
[17:55] <Keybuk> the only correct and canon way to do that is for server A to contact server B
[17:55] <Keybuk> and then server B to note the IP address that server A appears as
[17:55] <Keybuk> running a shell script on server A does not work
[17:55] <Keybuk> let me give you a simple example that doesn't even require a 1-to-1 NAT
[17:55] <Keybuk> I have three interfaces
[17:56] <Keybuk> lan0, wan0, wan1
[17:56] <Keybuk> wan0 and wan1 both have public IPs
[17:56] <Keybuk> and both have default routes with different metrics
[17:56] <Keybuk> lan0 has a private IP
[17:56] <Keybuk> which IP do I give to the other server?
[17:56] <cjwatson> my concern about trying to promote a standard way to get your IP address is that it takes the case of a weird multi-server setup that's making assumptions about everything being on the same subnet, and promoting it as a correct and reasonable thing to do in general
[17:56] <cjwatson> in most cases where you think you need to get your IP address, it's better to redesign
[17:58] <Keybuk> another example (common)
[17:58] <Keybuk> I have two IPs
[17:58] <Keybuk> one is a multi-homed IP which is the public address of the server
[17:58] <Keybuk> this same IP is configured on 1,000 different boxes
[17:58] <Keybuk> and I have a private IP which is the address of the host
[17:58] <Keybuk> which IP do I give to the service?
[17:58] <Keybuk> and then obviously there's the 1-to-1 NAT example, which is pretty much the defacto configuration of most data centers
[17:59] <cjwatson> even on private subnets: my little house server has four interfaces one might care about, but if you're talking about stuff on a private network, there are two: one wired, one wireless, different IP addresses.  there's no useful way to say which one is more relevant without knowing what it's going to be doing
[18:01] <kirkland> cjwatson: Keybuk: geez guys, I know that there are an infinite number of non-standard scenarios;  I'm simply trying to do what we do in Ubuntu all day every day -- offer a reasonable default when some other 3rd party package *requires* an ip address to be functional
[18:01] <Keybuk> kirkland: no, these are *standard* scenarios
[18:01] <Keybuk> "I have one true IP address that never changes" is the *non-standard* scenario
[18:01] <cjwatson> your reasonable default is better handled by redesigning, honestly
[18:02] <cjwatson> not by presenting a tool that fundamentally can't handle many real-world situations and never could
[18:03] <cjwatson> if we present such a tool, lots of things will likely start using it instead of doing their network configuration properly
[18:03] <cjwatson> and in particular this is very likely to produce things that don't work properly on v6
[18:03] <infinity> The majority of times something thinks it needs to know any/all of the local IPs, it's just plain wrong on that score.
[18:04] <cjwatson> I am *happier* with nasty shell hacks for non-standard servers that can't be fixed in other ways, than with presenting a standard tool that misleads people as to the right way to write network service
[18:04] <cjwatson> s
[18:04]  * kirkland renames his tool nasty_shell_hack_for_non_standard_servers
[18:05] <cjwatson> sigh
[18:05]  * cjwatson goes and eats dinner, which is going to be more productive
[18:05] <kirkland> perhaps this is a matter of setting expectation
[18:06] <kirkland> sometimes knowing a) the default route, and b) the ip (v4 or v6) is sufficient to accomplish a particular task
[18:06] <cjwatson> honestly this is something I would leave alone.  it's better to have fundamentally dirty things look dirty, rather than putting a veneer of cleanliness over them
[18:06] <kirkland> things that we're doing in ec2 all the time
[18:07] <kirkland> i'm admitting i'm wrong, and retracting my suggestion to recommend this to all of Ubuntu
[18:07] <cjwatson> see also the theory that proofreading badly-written wikipedia pages isn't always actually a good thing to do, because spelling errors can be a quick cognitive sign of a deeper problem ...
[18:08] <kirkland> lool: agreed;  and for that reason, I regret suggesting this for general purposes
[18:09] <kirkland> lool: but for an ec2 instances that's going to live a few minutes or hours ....
[18:09] <kirkland> lool: and lots and lots of similar instances
[18:09] <kirkland> lool: that have identical (or nearly identical) networking configurations
[18:10] <lool> cjwatson: haha
[18:10] <psusi> Keybuk: are you still maintaining the upstream ureadahead?  or is it basically defunct and I should just merge my changes into lp:ubuntu/ureadahead?
[18:10] <lool> kirkland: perhaps the cases you mention need a bigger hammer like ensemble?
[18:10] <kirkland> lool: ensemble is a place where knowing your ipaddress is necessary
[18:11] <Keybuk> psusi: there isn't an upstream ureadahead
[18:11] <kirkland> lool: in fact, writing an ensemble formula is the trigger for this conversation
[18:11] <Keybuk> and there never has been a maintainer
[18:11] <Keybuk> ureadahead is a tarball of code that worked for me once
[18:11] <Keybuk> and I've always said, if others can do better, they should go right ahead
[18:11] <kirkland> lool: I need to do the following, at the end of my formula:
[18:11] <kirkland> relation-set ip=$IP port=80 hostname=`hostname -s`
[18:12]  * lool isn't intimate enough to understand what this means
[18:12] <lool> I actually need to disappear; I'll come in a couple of hours check whether my machine burnt building OE
[18:13] <psusi> Keybuk: launchpad.net/ureadahead seems to be the upstream.. so you are saying just merge it into the ubuntu branch and don't worry about lp:ureadhead?
[18:13] <Keybuk> psusi: if you like
[18:14] <psusi> Keybuk: I'd be happy to push it upstream if you're still maintaining it... that's what I'm trying to figure out...
[18:16] <Keybuk> psusi: well, there isn't an upstream
[18:16] <Keybuk> as I said
[18:17] <psusi> Keybuk: then what is lp:ureadahead?
[18:17] <psusi> sure looks like an upstream
[18:17] <Keybuk> psusi: I'm lazy and didn't like typing lp:ubuntu/
[18:17] <Keybuk> and lp:ubuntu/ branches have a habit of vanishing
[18:17] <Keybuk> or being replaced with something that wasn't your branch
[18:18] <Keybuk> with totally different file-ids
[18:18] <psusi> so is lp:ureadahead defunct?
[18:20] <Keybuk> psusi: no, I'd say you should use lp:ureadahead as prime
[18:21] <Keybuk> because anything you commit to lp:ubuntu/ureadhead might be replaced at any moment with something else
[18:21] <Keybuk> <-- does not trust james_w's importer anymore
[18:21] <Keybuk> I lost far too many branches to it
[19:14] <juliank> On this side, would adding support for patching ltmain.sh files in dh-autoreconf be useful? http://anonscm.debian.org/gitweb/?p=collab-maint/dh-autoreconf.git;a=commit;h=f390910194262610cd7f059c17224989a192c965
[19:30] <directhex> CFLAGS="-O1 -fcse-follow-jumps -frerun-cse-after-loop -g"
[19:30] <directhex> cjwatson: reckon that's minimal enough for a bug report?
[19:31] <directhex> cjwatson: those two flags together cause failure... but i haven't looked through what -O1 includes yet
[19:31] <lool> haha and I thought I was kidding kernel: [17077.066227] CPU3: Core temperature above threshold, cpu clock throttled
[19:32] <cjwatson> directhex: well, I don't actually deal with gcc bug reports, but I guess it's a good start
[19:32] <directhex> maybe i should be asking a gcc maintainer instead... doko?
[19:32] <cjwatson> directhex: they may need a rather more reduced version of the code triggering it ...
[19:33] <directhex> cjwatson: reducing the signal handler in a jitter? @_@
[19:33] <cjwatson> directhex: are you planning to upload mono to use -O1 on armel in the meantime?
[19:33] <directhex> cjwatson: is that what you'd suggest? i can do that
[19:33] <cjwatson> yes
[19:38] <directhex> hm, an updated gcc within the past few days. i should update & re-test
[19:55] <pseudonymous> Anyone know of any guides for UCK (ubuntu customization kit)? I'm trying to remaster from a Ubuntu Mini image (no X, down to 160mb) but neither UCK nor the mini ubuntu image site actually finds it worthwhile to describe how one would go about remastering a ubuntu livecd which has not X install
[20:28] <ahasenack> hi guys, quick version comparison question
[20:28] <ahasenack> I have a package versioned 11.06~bzr331-0ubuntu0.10.04
[20:28] <ahasenack> it's 11.06, but not final yet
[20:28] <ahasenack> in another package, I need to have that 11.06~bzr331-0ubuntu0.10.04 or higher
[20:28] <ahasenack> so how would the depends look like? using >> 11.06~bzr331-0ubuntu0.10.04?
[20:28] <ahasenack> or just >> 11.06?
[20:28] <ahasenack> I mean, >=
[20:29] <ahasenack> not >>
[20:29] <tumbleweed> >= 11.06 won't watch that. but >= 11.06~ will
[20:29] <ahasenack> ah, a trailing ~
[20:30] <ahasenack> tumbleweed: thanks
[20:30] <micahg> 11.06~bzr331~ should be sufficient if you're looking for that bzr version, if there's something in the packaging, then use the whole version, also, I'd suggest adding a .1 at the end of that version string in case you need to update it
[20:30] <tumbleweed> err *match. Yes one often uses trailing ~ when you want to be able to match backports
[20:41] <jelmer> 'evening
[20:42] <bdrung> ahasenack: 11.06~bzr331 should do it.
[20:42] <bdrung> a backport would only modify the debian revision
[20:43] <bdrung> for example, we use >= 1.2.3 (no ~) and >= 1.2.3-0ubuntu3~ (with ~)
[20:43] <tumbleweed> basically depend on the minimum version you need, and if it may have a ~ at the end, then include one
[21:58] <Daviey> stgraber: around?
[22:03] <stgraber> Daviey: yep (though I guess you noticed that from the discussion in -server) :)
[22:04] <Daviey> heh... stgraber two things... Do you plan to merge nbd.. and do you know how the translations got changed in the last merge?
[22:05] <Daviey> (i'm happy to do it, just wanted to check with you first as i see you have history with it)
[22:05] <stgraber> Daviey: I was planning on quickly doing it last week, then I noticed that the package currently in Debian seems to be a bit of a mess :)
[22:06] <stgraber> Daviey: it's really a trivial merge except the mess with the latest orig tarball, so if you have time, feel free to go ahead
[22:10] <Daviey> stgraber: i noticed the tarball seemed a bit whacky
[22:11] <Daviey> If it is on your radar, i'm happy to leave it..   The "fix data corruption" looked worthwhile.
[22:12] <stgraber> Daviey: Now that I finally got the new arkose out, I should have some time to go through the two pending merges I have (nbd and something else). I'll probably have to poke Debian to figure out exactly what happened :)
[22:27] <Daviey> stgraber: super!  thanks
[23:06] <broder> hmm...it looks like usb-creator expects an ISO using grub to have a core.img and boot.img. how is the core.img supposed to be generated, though? grub-mkrescue doesn't seem to create one...
[23:14] <bdrung> tumbleweed: can you  review https://code.launchpad.net/~broder/ubuntu-dev-tools/debian-backport/+merge/64318 too?
[23:14] <soren> Is the server side of our rmadison thing having problems?
[23:15] <tumbleweed> bdrung: I had issues with the first version, but it looks much better now. Haven't read it in detail / tested it, yet
[23:15] <soren> cjwatson: ISTR this being part of (one of) your (many) area(s) of expertise? ^
[23:15] <bdrung> tumbleweed: please do so. if you have time, please add online tests
[23:16] <soren> cjwatson: Sorry, seems to have been transient. I coulnd't connect for about three minutes, now it's snappier than ever.
[23:17] <soren> cjwatson: Ah, no, now I'm asking about a different source package, and it's hanging for a whole minute (so far).
[23:19] <soren> Meh. /me goes to bed instead
[23:38] <d_ed> apachelogger: you about?
[23:38] <apachelogger> d_ed: and already a bit drunk
[23:39] <d_ed> oh, well that's fair enough. I'll start drinking soon. I was just replying to the kde-core-devel ML.
[23:40] <d_ed> I'm not on kde-core-devel,what's the general feedback been like?
[23:42] <apachelogger> d_ed: doomed
[23:42] <apachelogger> well
[23:43] <apachelogger> first they were ranting away as usual, until I jumped in and let my insane verbosity of arguments out, we are on a good way to discussion now
[23:43] <d_ed> I found a web link with people just bitching about bzr.
[23:43] <apachelogger> d_ed: generally I believe that everyone who contributed to the discussion (that is me, mgraesslin and sreich) agrees that a first option should be to try get KDM to do awesomeness
[23:44] <d_ed> you agree the first option should be to try and get KDM to do awesomeness?
[23:44] <d_ed> I can see why sreich does - he's writing KDM Plasma.
[23:45] <apachelogger> d_ed: well, yes, as upstream developer I do from a reliability and code control POV
[23:46] <apachelogger> d_ed: I do not know nearly enough about DMs to make educated decisions really, all I can do is argue about the advantages and disadvantages of both and then draw a conclusion from the overall picture outlined by everyone in the discussion
[23:47] <d_ed> ok
[23:47] <apachelogger> to that extent I believe that there is no actually solid technical reason for not using LightDM, equally there is no solid technical reason for not trying to fix KDM
[23:47] <d_ed> fair.
[23:47] <d_ed> I'm 100% with the "go with whichever is better" argument.
[23:48] <d_ed> and right now, that is KDM
[23:49] <apachelogger> yeah, I am not sure KDM is fixable to the degree that it can actually compete with the other pre-login experiences though, perhaps the plasma stuff will help with that (power management, visual appeal, accessibility and what not)
[23:49] <apachelogger> maco might have an opinion on KDM and accessibility ^^
[23:52] <maco> apachelogger: last i checked you couldnt use an onscreen keyboard with kdm. don't know about getting kaccessible to work with it
[23:54] <apachelogger> well, it is qwidgets, so that should be possible, on screen should also be possible with weird hackery *brrr*