| === yofel_ is now known as yofel | ||
| === tumbleweed_ is now known as tumbleweed | ||
| === 50UAAGBPG is now known as Amaranth | ||
| === ssweeny_ is now known as ssweeny | ||
| === Guest3036 is now known as jmarsden | ||
| dholbach | good morning | 08:07 |
|---|---|---|
| === javalogger is now known as apachelogger | ||
| === lool- is now known as lool | ||
| === runasand_ is now known as runasand | ||
| === jrib is now known as Guest31695 | ||
| === Guest31695 is now known as _jason | ||
| === _jason is now known as jrib | ||
| === apachelogger is now known as thresh_fan_fan | ||
| === chuck_ is now known as zul | ||
| ScottK | YokoZar: FYI, wine upload in the queue: http://launchpadlibrarian.net/67590683/wine1.2_1.2.2-0ubuntu3_1.2.2-0ubuntu4.diff.gz | 14:50 |
| === thresh_fan_fan is now known as apachelogger | ||
| === dantaliz1ng is now known as dantalizing | ||
| === Quintasan_ is now known as Quintasan | ||
| SpamapS | Hey, can somebody accept bug #483170 for lucid? | 16:55 |
| ubottu | Launchpad bug 483170 in courier-authlib (Ubuntu) "insufficient access permission for /var/run/courier/authdaemon" [Undecided,Fix released] https://launchpad.net/bugs/483170 | 16:55 |
| zul | SpamapS: possibly :) | 16:57 |
| YokoZar | ScottK: Please HOLD until ia32-libs upload completes | 17:10 |
| ScottK | YokoZar: I'm planning on holding it until after Beta 1. | 17:11 |
| YokoZar | ahh ok | 17:11 |
| YokoZar | And, likewise, please put ia32-libs into beta 1 ;) | 17:11 |
| ScottK | That should be fine, I think. | 17:11 |
| YokoZar | ScottK: I don't disagree with the changes per se since they're the same as I put into wine1.3 package (new lintian errors mainly), though likely I'll be making another upload right afterwards anyway ;) | 17:20 |
| ScottK | YokoZar: OK. Don't feel like you have to wait for that one to be in. Just incorporate his changes. | 17:20 |
| YokoZar | yup | 17:21 |
| ScottK | BTW, when is this ia32-libs upload happening? | 17:21 |
| ScottK | I don't see it in the queue yet. | 17:21 |
| YokoZar | ScottK: I just started it, and it's a 900 meg source package | 17:23 |
| ScottK | What's that, 10 minutes for you? | 17:23 |
| YokoZar | ScottK: 800 megs rather. From home, that should take the better part of a few hours. Unfortunately there's no way of telling how fast it's going since I have to sftp it and there's no progress indicator on dput | 17:24 |
| ScottK | Nice. | 17:25 |
| ScottK | Good luck. | 17:25 |
| Sarvatt | YokoZar: \o/ thank you thank you thank you for updating ia32-libs, it's causing all kinds of GPU hangs on intel due to the old mesa (with horribly buggy sandybridge support) in there being used with 32 bit flash | 17:35 |
| Sarvatt | bdrung: ^^ | 17:36 |
| * YokoZar notices he's been up a lot longer since the gnome clock applet mysteriously broke at last login... | 17:40 | |
| bdrung | Sarvatt: thanks | 17:45 |
| kklimonda | ScottK: wrt bug 745046, if gitolite depends on git-core >= 1.6.2 wouldn't it make more sense to backport the lowest possible version, from the oldest available release, in this case 1.6.3.3-2ubuntu0.1? This way we limit the amount of work, and testing required - the only available upgrade path from hardy is lucid, which already has 1.7.0.4. I know it's not your bug, and you didn't even comment on it - I'm just curious of what's the best | 18:00 |
| kklimonda | practice in your opinion. | 18:00 |
| ubottu | Launchpad bug 745046 in Hardy Backports "Please backport git-core" [Undecided,New] https://launchpad.net/bugs/745046 | 18:00 |
| ScottK | It depends. | 18:01 |
| ScottK | If 1.6.3.3 is available from a supported release, I'd go with that. | 18:01 |
| kklimonda | it's available in karmic | 18:01 |
| kklimonda | even 1.7.0.4 from lucid would be a better option in my opinion - it's going to be supported for a longer time than hardy, and we don't have to backport the latest git-core from natty to maverick, and lucid to support upgrades. | 18:02 |
| kklimonda | karmic is supported till april, and hardy is supported for two more years on servers, so it may not be a good idea to backport from karmic as gitosis is going to be used on servers. But it may be a good idea to backport a lucid package instead. | 18:04 |
| ricotz | kklimonda, hello | 18:09 |
| kklimonda | ricotz: hey | 18:10 |
| ricotz | kklimonda, i saw you worked on glibmm and gtkmm | 18:10 |
| kklimonda | ricotz: yess | 18:10 |
| ricotz | kklimonda, are there already packages for gtkmm 2.99.x? | 18:11 |
| ricotz | kklimonda, and glibmm 2.27.x | 18:12 |
| ricotz | kklimonda, ah just noticed glibmm is up2date | 18:15 |
| kklimonda | ricotz: there is an 2.27.99.1 update for glibmm pending I think. | 18:25 |
| kklimonda | I'm sure I've pushed 2.27.99 branch, but can't remember now if I've pushed 2.27.99.1 (the only difference is dropped mm-common dependency at the build time) | 18:26 |
| ricotz | kklimonda, glibmm is ok, i noticed it ;), but what about gtkmm 2.99? | 18:27 |
| kklimonda | ricotz: some preliminary packaging work for 2.99.x has been done by Andrew (he has a nick asomething on IRC) but last time I've checked he hasn't finished it. It's also based on 2.24 package, so all descriptions are not updated etc. I haven't had time to work on it so far. | 18:28 |
| kklimonda | ricotz: the 2.99 packaging is available at lp:~gnomemm/gtkmm/3.0-ubuntu | 18:28 |
| kklimonda | I was meaning to clean it up and push it to debian, but it hasn't been high on my list. Does something depend on it? If so, it would make it more urgent :) | 18:29 |
| ricotz | kklimonda, ok :), i might have a look, it is needed by gnome-system-monitor 2.91.x | 18:29 |
| ricotz | kklimonda, would be great if you could push it a bit ;) | 18:30 |
| ricotz | kklimonda, i will be installable parallel to gtkmm 2.24? | 18:30 |
| YokoZar | how big is the universe archive currently? (considering a mirror) | 18:30 |
| ricotz | i/it | 18:30 |
| kklimonda | ricotz: yes | 18:32 |
| ricotz | kklimonda, alright, thanks :) | 18:34 |
| ScottK | YokoZar: Even bigger than ia32-libs. | 18:47 |
| ScottK | :-) | 18:47 |
| YokoZar | ScottK: I would imagine a miracle of compression if it were smaller ;) | 18:47 |
| ScottK | In Ubuntu miracles of compression are a regular thing. That's how the install fits on one CD. | 18:48 |
| iulian | Heh. :) | 18:50 |
| blueyed | What about rebuilds for Python 2.7, e.g. https://bugs.launchpad.net/ubuntu/+source/mercurial/+bug/745250 ? It's universe, so I could upload it. | 22:01 |
| ubottu | Ubuntu bug 745250 in mercurial (Ubuntu) "Rebuild for/with Python 2.7" [High,New] | 22:01 |
| tumbleweed | blueyed: I suspect that'll require more than a rebuild | 22:03 |
| blueyed | tumbleweed: debian/pyversions says "2.4-" currently. Would that have to become "2.7-"? | 22:11 |
| tumbleweed | blueyed: that would workaround the bug, but it isn't the correct fix. | 22:16 |
| * tumbleweed has a proper look at it | 22:17 | |
| blueyed | tumbleweed: seems like /usr/bin/hg would have to use python2.6 - the same version as it adds to libdir. | 22:18 |
| blueyed | ..or drop the libdir line altogether. | 22:18 |
| tumbleweed | blueyed: add a --force to the setup.py install command | 22:23 |
| tumbleweed | although that's still a hack | 22:24 |
| tumbleweed | the problem is that 2.6 is getting built first, and the 2.7 version of the hg binary isn't replacing the 2.6 one | 22:24 |
| tumbleweed | we should rather just get rid of all the libdir stuff, it serves no purpose with the way we install it in debian/ubuntu | 22:26 |
| tumbleweed | (it's a bug in Debian too) | 22:26 |
| blueyed | what does --force do? | 22:27 |
| blueyed | I'll forward it to debian. | 22:27 |
| blueyed | it wouldn't be a bug if 2.6 was default, would it? | 22:28 |
| tumbleweed | --force makes the 2.7 install overwrite the common files written from the 2.6 install | 22:28 |
| blueyed | Is this ok to be uploaded? or does it need some acks? | 22:30 |
| tumbleweed | blueyed: what was the restult of this bug? What broke? | 22:30 |
| blueyed | "hg archive" at least. | 22:31 |
| blueyed | I am not a hg power user though, just wanted to build Vim from the Debian repo. | 22:31 |
| blueyed | diff: http://paste.ubuntu.com/587078/ | 22:32 |
| tumbleweed | hmm, archive works for me on debian | 22:32 |
| blueyed | is "python" "python 2.7" for you? | 22:32 |
| tumbleweed | no, it's 2.6, but hg contains a 2.5 libdir | 22:32 |
| tumbleweed | works on ubuntu too. | 22:33 |
| tumbleweed | anyway, it is certainly a bug, and I think it's a reasonable workaround. I'll happily commit a better fix in debian | 22:33 |
| blueyed | odd. io.py came from python2.6 for me (from the libdir line), python is 2.7 for me. | 22:34 |
| ScottK | tumbleweed: You should be able to make it where a rebuild is all that's needed. | 22:34 |
| tumbleweed | ScottK: the problem is that th eorder the python versions are installed in matters | 22:34 |
| ScottK | Not if you're doing it right. | 22:35 |
| ScottK | It can matter for building, so debian/rules can care, but not in the target system. | 22:35 |
| tumbleweed | ScottK: this setup.py writes the python version into a variable in /usr/bin/hg | 22:35 |
| ScottK | Right, so you've got an idea where to start looking for the bug. | 22:36 |
| tumbleweed | but it doesn't need to. I think that's a compatibility hack for broken systems | 22:36 |
| blueyed | I would say to patch the libdir line away.. but am not experienced with setup.py stuff. | 22:39 |
| blueyed | anyway, tumbleweed, are you fixing it for ubuntu, too? | 22:39 |
| blueyed | otherwise I would upload as-is for now. | 22:39 |
| tumbleweed | blueyed: untested but I think this is what I'd do in Debian: http://paste.ubuntu.com/587079 | 22:41 |
| tumbleweed | yeah, does the trick nicely and cleanly | 22:43 |
| blueyed | great. | 22:44 |
| blueyed | tumbleweed: wait, you may want to come over to #mercurial. | 22:46 |
| blueyed | I've asked there about the issue and fix. | 22:46 |
| Laney | Does anyone ever care for the fact that statoverrides can be added for files which don't exist on the system when creating files in maintainer scripts? | 22:53 |
| soren | Laney: What do you mean? | 22:56 |
| soren | Laney: Whether maintainer scripts ever make sure to apply statoverrides even on fresh installs? | 22:56 |
| Laney | I don't know. | 22:57 |
| soren | lol | 22:57 |
| Laney | That's pretty much my question — do they? | 22:57 |
| Laney | i.e. should I care? seems like a pain | 22:57 |
| soren | Ok, that's what I was asking if you were asking :) | 22:57 |
| soren | I believe I've done that in the past. | 22:57 |
| soren | I'm trying to remember which package. | 22:57 |
| blueyed | tumbleweed: will you upload the fix for ubuntu, too? | 22:58 |
| tumbleweed | blueyed: I can do | 22:58 |
| blueyed | tumbleweed: great, please do so. Thanks for getting this fixed. | 22:59 |
| tumbleweed | np | 22:59 |
| soren | Laney: I can't seem to find it. Anyways, regardless of whether or not they do, they should. | 23:00 |
| Laney | yeah. | 23:01 |
| blueyed | What does this mean? "configure: error: cannot run C compiled programs." from https://launchpadlibrarian.net/67625204/buildlog_ubuntu-natty-amd64.vim_2%3A7.3.138%2Bhg%7Eea399ac2c1b9-1%7Eblueyedppa1_FAILEDTOBUILD.txt.gz | 23:03 |
| tumbleweed | blueyed: if you don't mind waiting a day or two, I'll try and find out what preference the debian maintainers for this package have. | 23:03 |
| blueyed | tumbleweed: ok with me. Please assign the bug to you then. | 23:03 |
| blueyed | the vim source from above builds fine locally using sbuild. what't this issue? | 23:34 |
| blueyed | appears to be related to crosscompiling from googling.. | 23:34 |
| blueyed | the package is for debian.. something arch specific going wrong? | 23:36 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!