=== eights is now known as Guest12696 === mbiebl_ is now known as mbiebl [01:38] Laney: You around? [01:38] Laney: Do you know, off-hand, if revving fpc from 2.4.x to 2.6 will require any sort of revdep rebuild transition? [01:39] Laney: I'm seriously considering the version bump to get the armhf port included. [01:40] Laney: And you're my resident "guy who keeps track of weird languages and compilers". :P === eights is now known as Guest63380 === dantti_away is now known as dantti [03:59] good morning [05:17] is there an AA around i could get to binNEW the mosh backports? [05:29] Good morning [05:52] good morning pitti [05:52] no unstable job, no archive problems? [05:52] nice [05:52] hey rickspencer3 [05:52] I don't intend to introduce any :) [05:53] pitti, does that mean you are using precise -proposed for everything now? [05:55] rickspencer3: not for everything, too much overhead; but we can use it for all the bits which are prone to introduce problems [05:55] awesome [05:56] pitti: oh, -proposed is available again? [05:56] micahg: bug 930217 :) [05:56] Launchpad bug 930217 in Launchpad itself "Make proposed pocket useful for staging uploads" [Low,Fix released] https://launchpad.net/bugs/930217 [05:57] ooh, great [05:57] it got set to "fix released" over the weekend [05:57] so apparetnly rolled out now [05:58] We're not thinking of rolling a full unstable→testing like promotion system, I take it? [05:58] rickspencer3: need to ask jibel to restart the upgrade tests; they haven't run for 4 days now, and we have two major fixes rolled out now [05:58] RAOF: eventually, but we don't have that yet [05:58] RAOF: just with immediate migration, not with 10 days of waiting or so [05:58] thanks pitti [05:58] That sounds like a fairly large amount of work. [05:58] RAOF: we currently move stuff to precise from -proposed as soon as it built everywhere and doesn't introduce uninstallability [05:59] RAOF: it's nontrivial, but not huge really -- britney in Debian does that all the time, and we use it to produce http://people.canonical.com/~ubuntu-archive/testing/precise-proposed_probs.html, etc. [05:59] Having a staging area will be awesome. [06:26] not sure if this is the right channel but I've noted really wrong translations in oneiric (not as opposed to other versions) [06:26] rosetta is nice but it can't do the entire job [06:27] gettext is not so good and we often need to refer to the source code for translating stuff correctly [06:27] filenames in LP's po files are not big help... [06:27] what effort is being done to fix this situation? [06:28] because untranslated strings seem much better than absolutely wrong translations [07:13] good morning === smb` is now known as smb [07:33] pitti, thumbs up for the systemd investigation! [08:15] "Sometimes I have the impression that Martin Pitt is doing everything in Ubuntu." (https://plus.google.com/115547683951727699051/posts/MuB3MkCnieK) [08:17] that's not too far off the truth [08:18] except the bit about hte last bastion crumbling [08:25] jibel: do you know why the jenkins upgrade jobs haven't run for four days? [08:27] so http://www.ubuntu.com/ still has the goggles [08:27] so is it real after all!?! [08:27] hi [08:27] does someone uses apt-cacher-ng? [08:27] well, I guess it's still April 1 on some distant islands in the pacific [08:28] pitti, they are running, but results are not published. I think that's the follow up of the maintenance of last week but I don't have access to the public jenkins [08:28] infinity: no idea I'm afraid (even I'm not crazy enough to touch pascal :P). I suggest asking the Debian maintainer [08:28] hrw: yes, I use it for my pbuilder and my packaging chroot [08:30] geser: I use a-c-ng on precise machines and 'W: Failed to fetch bzip2:/var/lib/apt/lists/partial/de.archive.ubuntu.com_ubuntu_dists_precise_universe_binary-i386_Packages Hash Sum mismatch' started to be daily norm ;( [08:31] hrw: I've seen that with some upstream mirrors. Deleting dists from the cache and restarting it helps :/ [08:32] tumbleweed: will try other mirror then cause removal+restart did not help [08:32] is the file actually correct on the mirror? [08:33] forcing a check has always fixed it for me [08:33] but the fact that it happens at all (every 2-3 weeks here) is annoying, granted [08:33] hrw: I use archive.u.c to no to have to wait on the mirror pulse and updated yesterday my precise box without problems [08:34] ok, changed from de to pl mirror and it works [08:34] 516MB update is fetching ow [08:39] jibel: ah, thanks; so I'll just wait for that to come back online before I bother you again [08:39] pitti: hi! i was checking the kernel pkgs status, and there are a few still to be copied into -proposed [08:39] jibel: I'm just curious to see whether the LibO and at-spi stuff have worked :) [08:40] pitti: is there any problem with them, or they're just on the queue? [08:40] henrix: just on the queue; I don't look at them every day, and I seem to be the only one who does.. [08:40] pitti: ah, ok :) [08:40] * pitti does now [08:40] pitti: great, thanks [08:41] @pilot in === udevbot changed the topic of #ubuntu-devel to: 12.04 Beta 2 Released! Precise: UI and feature freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/xmGdCW | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: Riddell [08:41] Riddell: happy flying [08:42] whee [08:43] Who are patch pilots? [08:44] henrix: there will be some packages again which will land in main instead of universe; I'll clean up after them once your bot complains [08:45] henrix: i. e. that's a normal part of the workflow for lucid (unfortunately..) [08:45] vibhav: hi [08:45] pitti: ok, no prob. do you receive the bot notifications? or do you want me to ping you back? [08:45] henrix: I do get the notifications [08:46] hi Riddell [08:46] pitti: ok, cool. [08:46] pitti: thanks [08:49] pitti, lucid universe failed http://paste.ubuntu.com/911209/ [08:49] pitti, lucid server, desktop and main pass [08:50] jibel: does oneiric pass again, with the LibO fix? [08:50] pitti, oneiric desktop failed with bug 969707 [08:50] Launchpad bug 969707 in libreoffice (Ubuntu Precise) "package python-uno 1:3.4.4-0ubuntu1 failed to install/upgrade: sub-processo novo script pre-installation retornou estado de saída de erro 1" [Critical,Confirmed] https://launchpad.net/bugs/969707 [08:50] argh, that [08:51] jibel: ok, I just discussed that with Sweetshark [08:51] same for oneiric main [08:51] and same for universe === doko_ is now known as doko [08:53] jibel: erk, seems the at-spi fix didn't work; thanks for the log [08:54] ah, python-pyatspi has a versioned dependency on at-spi, so Provides: isn't enough [08:54] TheMuso: ^ FYI [08:56] larsduesing, around? [08:57] jibel: reopened bug 966845 [08:57] Launchpad bug 966845 in pyatspi (Ubuntu Precise) "lucid->precise upgrade wants to remove ubuntu-desktop" [High,Triaged] https://launchpad.net/bugs/966845 === htorque__ is now known as htorque [10:21] dholbach: Who is patch piloting on Wednesday April 11? I need to arrange a swap as I am on holiday the week after. [10:25] TheMuso, the calendar is public, https://www.google.com/calendar/embed?src=6k1e5rq45m1bdqq0n1ge3oqaok@group.calendar.google.com&ctz=Europe/Berlin&gsessionid=OK [10:44] TheMuso, you can just move the shift to another day if you like [10:57] pitti: sorry for bothering again, but i still can't see the new packages on -proposed. is that normal to take that long? [10:57] henrix: indeed, it's a bit weird -- the SRU page did not yet update either [10:57] it normally takes half an hour [10:57] pitti: yeah, that's what i though. any ideas about what's going on? [10:58] henrix: not off-hand, need to check [10:58] pitti: thanks [10:58] We missed a couple of publisher runs, possibly due to LP maintenance. [10:58] 2012-04-02 08:57:33 DEBUG Removing lock file: /var/lock/launchpad-publisher.lock [10:58] 2012-04-02 10:33:04 DEBUG Cronscript control file not found at file:cronscripts.ini [10:58] But it's running now. [11:00] pitti - may I ask you a really dumb question? === _salem is now known as salem_ [11:19] smoser: i rewrote distro-info in C. it is way faster than shell. [11:19] larsduesing: at lunch, just ask :) [11:20] pitti: sorry.. problem was on my side, cleared seconds ago [11:20] :) [11:25] bdrung, pitti dholbach do you know off the tops of your heads a 3.0 (quilt)/dh package that does per-architecture application of a patch? [11:27] janimo`: if you find out, please tell me [11:27] janimo`: just wondering, what's your package ? [11:28] AnAnt, mongodb [11:39] pitti: the bot just complained about wrong component :) [11:40] janimo`: sorry, i can't remember one that uses per-arch or per-distro patches [11:47] åñòü êòî ïî ðóññêè [11:58] pitti: can you tell debfx how your qt 4.8.1 tests went? === MacSlow is now known as MacSlow|lunch [12:07] janimo`, no, unfortunately not [12:08] dholbach, bdrung thanks anyway [12:09] janimo`: no, I don't know one off-hand, I'm afraid [12:10] janimo`: in many cases it is useful to have a patch that supports all architectures. per-arch patches are unlikely to get accepted by upstreams. [12:11] bdrung, I know, but sometimes for too invasive patches which upstream does not take in this form it still make sense to have a fix for arm or other targets [12:11] Riddell, debfx: I haven't done exhaustive testing, but unity-2d starts just fine with qt 4.8.1, and basic functionality (indicators, launcher, dash, hud) is working fine [12:11] surely #ifdef isn't too hard [12:12] cjwatson, doable in most cases [12:12] I could not do it last time I needed this (in ghc) [12:13] most arm patches of course use ifdefs but for the few exceptions I was curious if per-arch is possible === smb` is now known as smb [12:14] is there a channel where I can ask ubuntu wiki questions about posting a "FreeNX is dead, here's a list of alternatives" on the FreeNX page? [12:14] I don't want to piss people off :3 but FreeNX has been inactive since 08' [12:24] pitti: thanks for testing [12:33] bdrung: swt-gtk is an example of an upstream that provides two source tarballs, one for 32-bit arch, another for 64-bit arch [12:34] btw, I have sync'ed/merged TeXLive pre-2012 package from Debian for Precise on my PPA: ppa:aelmahmoudy/tl2009 , please note that a couple of packages (cm-super & texlive-base) were sync'ed rather than merged, probably I would merge texlive-base on next Debian upload. === tkamppeter_ is now known as tkamppeter [13:24] bdrung, really? wow. cool. [13:25] smoser: ubuntu-distro-info passes all test. i am cleaning up the code and then work on debian-distro-info [13:25] i woudl guess you could do a run in 20% of the sh. [13:26] smoser: 25x times faster without startup time and 3.8x times faster with startup time. [13:26] what is "without startup time" ? [13:26] smoser: a for loop in C calling main multiple times [13:27] i guess that fork takes too long [13:27] yeah. fork is heavy. [13:27] by guess of 5x was based on the fact that /bin/true is 6x faster than the shell version [13:27] :) [13:27] smoser: 1000x times u-d-t in C: 0.037s (without fork) and 0.4 s (with fork) === bladernr_afk is now known as bladernr_ [13:33] smoser: the fork takes longer that running u-d-i [13:39] bdrung, right. thats the case for loads of utilities. [13:39] fork is very heavy [13:40] although extremely performant on linux compared to other unixes [13:41] the 'date' fork in the shell version accounts for 30% of its execution time. [13:47] anyone know of a way to get a list of supported locales ? [13:48] er... i guess more explicitly i'm looking for a list of all 'language-pack-XX' === MacSlow|lunch is now known as MacSlow [13:55] smoser: the binary is 3x bigger [13:59] bdrung, i'm perfectly fine with you replacing shell with c. I wont have my feelings hurt if you replace it. I suspect that in any real world usage, the current version is not likely to bottleneck anything. (unlikely that tab completion is going to be affected by a reduction in run time from 1/100th of a second to 1/1000th) === bladernr_ is now known as bladernr_afk === bladernr_afk is now known as bladernr_ [14:00] smoser: i don't wanted to make your work wasted, but i had some free time and was curious about the possible speed improvement. [14:00] pitti, i suspect maybe you know about a list of supported language packs ^ [14:00] bdrung, yeah. i get itches like that too :) [14:01] directhex: were you intending to backport https://github.com/mono/mono-tools/commit/59e0b16bff03d0df812d62a6ac71ce373d6d5cc4 to the package in precise, or do you want me to do it? [14:01] bdrung, really, i'm perfectly ok if you want to use the C version. i would suggest not bothering for 12.04 though. [14:01] directhex: (failed in the test rebuild) [14:02] smoser: apt-cache search language-pack | grep ^language-pack ? [14:02] smoser: you could sell the shell version as learning experience. ;) distro-info was written in python, haskell, shell, and C with interesting results. [14:02] cjwatson, curse automake upstream with the fire of 10,000 suns (i believe grub was also hit by this idiocy) [14:02] pitti, yeah, ubt i wondered if there was a cleaner way. i shouldhave said that: apt-cache search ^language-pack-[a-z][a-z]$ | sed 's, .*,,; s,language-pack-,,' [14:02] cjwatson, i think the sid package has that backported change [14:02] directhex: I fixed it in grub2 a little while back, yes [14:03] i just wondered if there was some list that i could definitively reference. [14:03] cjwatson, sync from sid should be all you need. http://packages.debian.org/changelogs/pool/main/m/mono-tools/mono-tools_2.10-2/changelog [14:03] directhex: ah yes, good point. will sync [14:03] looked for bug reports but not uploads, duh [14:05] cjohnston, if you hit more 1.11.2 issues in mono packages, fix likely contains a fix [14:05] er, cjwatson [14:09] directhex: sure, thanks [14:10] *sid* contains a fix. can't type today [14:10] computers are hard [14:10] mmm fix [14:13] smoser: if this is for a seed, why not just use germinate's globbing capability? [14:13] cjwatson, not for a seed. [14:13] cjwatson, for https://code.launchpad.net/~utlemming/cloud-init/cloud-init.locale/+merge/100257 [14:14] can't you use python-apt? [14:15] >>> import apt [14:15] >>> cache = apt.Cache() [14:15] >>> len([pkg for pkg in cache if pkg.name.startswith('language-pack-')]) [14:15] 826 [14:15] obv. something a bit more sophisticated :) [14:16] bkerensa, you pinged me the other day. I'm around now, but not for that much longer today. [14:16] cjwatson, smoser: I'm missing the back drop here, but I assume the issue is the list of valid locales? [14:16] cjwatson, yeah, that might be preferable. [14:17] utlemming, well, i was just not interested in hard coding if i didn't have to. [14:19] smoser: fair enough...I put the list of locales for two reasons 1) simplisitity and; 2) since another merge proposal which used a dynamic discover method was nixed [14:20] smoser: I'm not opposed to a dynamic discovery method and would actually like to have that bit of code dynamic. But in looking at it, you have to us a regex because you have kde and gnome language packs. [14:30] utlemming, well, use python-apt. but i'm not beng on that. i added some comments there. [14:37] I'm seeing a fantastically weird problem on a Lucid install in a particular virtualised environment where eth0 and eth0:1 (same interface) both have static IPs in /etc/network/interfaces, eth0 is numbered immediately on boot, but eth0:1 takes **OVER TWO MINUTES** to get its IP address. Any idea where in upstart or whatever I should even start looking to find what's causing this? [14:47] smoser: oldstable breaks my algorithm [14:58] alexbligh: (that's just from memory, things may be slightly different in 10.04) I suspect that eth0 being a physical interface it gets setup as soon as we get the kernel udev event (so very early) [14:59] alexbligh: but eth0:0 being a label on eth0, it only gets configured when we hit the fallback /etc/init/networking.conf, so once we start calling the sysvinit stuff [14:59] alexbligh: which means that if you have any upstart job/ifupdown script/... that takes a long time to start, it'll delay the setup of eth0:0 === yofel_ is now known as yofel [15:10] stgraber, it's an ordering problem. We have stuff which should run after the interfaces have been configured (which is what is causing us the problem). Specifically, rc2.d seems to be being run before all the interfaces are configured. [15:11] stgraber, that appears to be because rc-sysinit.conf is "start on filesystem and net-device-up IFACE=lo" [15:12] alexbligh: yeah, we fixed that in 11.10 [15:12] alexbligh: /etc/init/rc-sysinit.conf:start on (filesystem and static-network-up) or failsafe-boot [15:12] stgraber, oh really? [15:12] janimo`: I think firefox is doing per arch patches at the moment [15:12] alexbligh: and static-network-up is emitted once all static entries in /etc/network/interfaces have been configured [15:12] stgraber, is that safe to backport to Lucid? [15:13] alexbligh: so you shouldn't have that problem with 11.10 or 12.04 (though I'm not too sure about our behaviour with labels, would have to check) [15:13] stgraber, i.e. is it just the one line change in rc-sysinit.conf or do I have to emit the event too? [15:13] alexbligh: no, it's unfortunately not safe to backport to Lucid and that's why we didn't [15:13] stgraber, unfortunately we are stuck with Lucid for the time being (until precise is out). [15:14] micahg, thanks. I was hoping a 'sane' package can be used as an example, I don't think firefox uses 3.0 and dh [15:14] but then again, 'sane' packages do not need per-arch patches :) [15:14] stgraber, is a safe hack to put an interface up script for eth0 which does 'ifup eth0:1'? [15:14] alexbligh: you'd have to backport a few upstart jobs, some ifupdown hooks and maybe even some udev hooks, I spent a few days considering doing that when working on other issues (bonding and bridging mostly) but the risk of regression was considered too high [15:15] alexbligh: "up ifup eth0:1 || true" would be better. It's an hack but should be safe, yes [15:15] Or actually I can take them up from the thing running from sysvinit, can't I (doh). [15:16] stgraber, thanks, that's really helpful. [15:17] alexbligh: you're welcome. Would be great if you could test your setup with 12.04 beta2 (in a VM or something) to make sure your issue was indeed taken care of [15:17] alexbligh: if it didn't then file a bug against "ifupdown" so we can take a look before 12.04 is released [15:18] stgraber, we need to do precise testing at some point. Annoyingly our next version release date is just before precise, so we are stuck with Lucid + Oneiric backport kernel :-/ === dendro-afk is now known as dendrobates [15:33] sconklin: hey Steve [15:33] Hi pitti [15:33] sconklin: did you notice that I had a question for you on bug 955111 ? [15:33] Launchpad bug 955111 in apport (Ubuntu) "Apport including error messages in tags" [Low,Incomplete] https://launchpad.net/bugs/955111 [15:33] no, thank you. I'l plowing through email still [15:34] looking [15:34] hi, I just read about capsicum and was wondering whether capsicum support will come to ubuntu, if it is on your todo/wishlist. [15:35] pitti, well, this is interesting, look at what I got - I mistyped lsb-release the first time http://pastebin.ubuntu.com/911614/ [15:36] sconklin: can you check whether this goes to stdout or stderr? [15:36] I get is if I type anything into the shell [15:36] stand by [15:36] yes, anything that calls python [15:36] it's an error message that python itself prints [15:36] and I suspect it's going to stdout [15:37] sconklin: the first one was from command-not-found, FYI [15:37] pitti: stderr [15:37] sconklin: i. e. you don't see them with lsb_release -si 2>/dev/null ? [15:38] you'll probably just need to upgrade those local libraries [15:38] I do not see them with stdout directed to null. I do see them in a file I piped from stderr. Two test cases, same result [15:39] cjwatson: I have an app with a fixed version edpendency, that's why I installed those locally [15:39] not a good idea to have them in place for all applications though ...? [15:39] agreed [15:40] I should shell up an env for the app [15:42] sconklin: hm, I checked both calls to lsb_release, and in both it just grabs stdout; very weird [15:42] sconklin: anyway, I'll try to reproduce this by adding some gibberish to lsb_release [15:42] pitti: but remember it happens for anything I pass to the shell, it doesn't even have to be lsb_release [15:44] sconklin: thanks for checking [15:44] sconklin: ah, found it; it's in our ubuntu package hook only, that's why I didn't find it in trunk === bladernr_ is now known as bladernr_afk [15:47] pitti, cjwatson: and I just pulled the LD_LIBRARY_PATH change out of my bashrc and put it in a script that invokes the app. That removed the error. === deryck is now known as deryck[lunch] [15:48] and fixed in bzr [15:48] with that, good night everyone! [15:48] Thanks! [15:53] ia32-libs ia32-libs-multiarch:i386 <-- is this something i am expecting to be REMOVED [15:55] pitti: so the issue is, the extension is still assumed to be register, so we kill it and reinstall the extension. _rene_ then says unopkg then thinks the extension is already there so it noops. which is why he wants to run sync_extensions before installing to make unopkg notice it has to reregister. === zyga is now known as zyga-food === bladernr_afk is now known as bladernr_ [16:27] ev, you've fixed bug 737791 [16:27] Launchpad bug 737791 in apport (Ubuntu) "need to be able to "Report Bug, then Reopen"" [Undecided,New] https://launchpad.net/bugs/737791 [16:27] nice [16:27] closing === zyga-food is now known as zyga [16:36] hallyn: re libnl3; did you make any progress? === htorque_ is now known as htorque [16:38] hallyn: I have an updated patch, though it doesn't include the changes to generated files (http://people.ubuntu.com/~mathieu-tl/libnl3-updated.patch). Adding the other changes should be as easy as doing a diff of configure and src/Makefile.in, daemon/Makefile.in after configure [16:40] cyphermox: no, i'm afraid there are plenty of higher prio bugs first :( Note that waht upstream wants to see is a patch that allows the choice of libnl-1 or libnl-3. Then they'd be willing to take it. how hard would that be to do? [16:43] cyphermox: so the patch above should fix the -I path to include /usr/include/libnl3? === deryck[lunch] is now known as deryck [16:53] hallyn: yes, if there aren't other instances where a netlink/msg.h file is needed and doesn't have LIBNL_CFLAGS [16:53] cyphermox: thanks [16:54] hallyn: fixing it to choose the version is pretty simple, yes, just needs a bit more code since there are some different calls between NL1 and NL3 [17:02] cyphermox: i assume the configure.ac bit will be the ugliest :) I do intend to give it a try arounds uds time. if no kind soul beats me to it :) [17:02] what's the purpose for the update, just preparing for precise+1? [17:03] otherwise we can sit together at some point at UDS around a beer and I'll be happy explain the details [17:05] cyphermox: right, well, just to get the patch upstream so we don't have to carry delta and worry about regressions. sitting down at uds sounds great :) [17:05] cool === Ursinha` is now known as Ursinha === Ursinha is now known as Guest60849 === Guest60849 is now known as Ursula___ === Ursula___ is now known as Ursinha === pp7 is now known as malkauns [18:18] What's with all the non-deterministic status indicators? [18:18] Back when Ubuntu started, it would blurt all kinds of boot indicators to the screen [18:19] Removing all that was a mistake, but I was assured quite firmly that this was inconsequential because, "unlike Windows," the status indicator for boot was a deterministic progress meter. [18:20] Now there's no such thing, the download progress meters for i.e. Update Manager are non-deterministic things that bounce back and forth, and everything leaves me wondering how fast and how far [18:20] Is Ubuntu hanging on boot? It seems to be taking longer today... maybe I'm just bored, I dunno. [18:20] Is my ISP being slow, or is this just the normal 2 minute download? [18:20] etc [18:21] You may as well not give any indication that anything's going on at all: if the application hangs, the status bar will gleefully bounce back and forth while nothing happens [18:49] @pilot out === udevbot changed the topic of #ubuntu-devel to: 12.04 Beta 2 Released! Precise: UI and feature freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/xmGdCW | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: === zyga is now known as zyga-afk [19:16] mvo, i'd really appreciate you looking at https://bugs.launchpad.net/ubuntu/+source/squid-deb-proxy/+bug/971820 [19:16] Launchpad bug 971820 in squid-deb-proxy (Ubuntu) "squid-deb-proxy needs special handling of Release, Packages, Source" [Undecided,New] [19:16] smoser: sure! === dendrobates is now known as dendro-afk [19:48] mvo, do you understand the problem there? [19:48] yes [19:48] the issue is that those files get cached and cached stale, and there is nothing that you can do (from the other side of the mirror) to resolve it. [19:48] s/mirror/proxy/ [19:50] smoser: http://bazaar.launchpad.net/~racb/squid-deb-proxy/apt_refresh/revision/16 <- that is pretty much what you need, right? [19:51] yeah, i think so. i'm of course going to defer to your better knowledge of apt [19:52] mvo, i swear there is a setting tha tyou can tell squid... [19:52] to check the headers every time [19:52] (and maybe this is it) [19:52] but rather than downloading the whole thing every time, check the headers. [19:53] mvo: while you're in there and want to sort https://bugs.launchpad.net/ubuntu/+source/squid-deb-proxy/+bug/952364 that would be great too. :) [19:53] Launchpad bug 952364 in squid-deb-proxy (Ubuntu) "Default to not caching a deb instead of 403'ing." [Undecided,New] [19:53] smoser: for squid question, I always ask lifeless :) he knows all about it [19:53] exactly. [19:54] jcastro: right, that would be a great feature too, I don't know if squid can be configured to do that, but I can dig around a bit [19:56] mvo, if you just deny, i think that files dont get cached. [19:56] its weird. [19:56] orchestra used to deny the packages.gz and such. [19:56] they still came through [19:58] smoser: yes, that's exactly what my squid.conf lines do in http://bazaar.launchpad.net/~racb/squid-deb-proxy/apt_refresh/revision/16 - they will only download the files if they're newer, otherwise will use the cache. But they will check every time. [19:59] rbasak, thank you. [20:01] mvo, jcastro fwiw, orchestra used to do this: [20:01] http://paste.ubuntu.com/911976/ [20:01] and iiuic that basically does what castro wanted. [20:01] of course, you stil spend bandwidth as a proxy for those things that you weren't going to cache. [20:02] right, but it beats having the thing being totally unreachable, like it is now\ [20:05] I'm not aware of a single situation where using squid with http://bazaar.launchpad.net/~racb/squid-deb-proxy/apt_refresh/revision/16 can fail when going direct will work. [20:10] smoser, rbasak: its uploaded now with the changes in rev16, thanks! [20:10] thanks mvo! [20:11] gracias. [20:11] jcastro: so the only reason unrestricted access is not enabled by default currently is to allow this to be dropped into a already restricted network without opening up generic http access via this squid-deb-proxy, I guess it could be argued that this is something that a admin should restirct himself/herself and that convinence is better. or we add another debconf question, but that is not very discoverable either :/ === dendro-afk is now known as dendrobates [20:13] I think not having an unrestricted proxy is reasonable; ideally the proxy saying "fine, go download from this random repository, I will neither help you nor hinder you" sounds like a good middle ground to me [20:18] jcastro: the security issue isn't whether it caches your deb or not (pretty minor, just a DoS of the cache), but whether you can get the deb or not (pretty major - could subvert an existing security policy controlling general access). I favour a debconf option. [20:18] jcastro: right, my thinking (but bear in mind that I'm not a sysadmin :) was that the proxy host has usually different network restrictions than the regular clients, so opening up the proxy sounds potentially dangerous to me [20:19] mvo: we should just ask elmo what to do. :) Or perhaps grab a -security guy at UDS or something, whatever works for me. [20:20] jcastro: yeah, someone more experienced than me on this and I will happly implement whatever they suggest, for now I'm totally fine with a debconf prompt [20:20] jcastro: note that I want this to be as simple as possible really [20:20] If we want full access through the proxy, why not just use the main squid package? === popey_ is now known as popey === stgraber_ is now known as stgrber === stgrber is now known as stgraber === Daviey_ is now known as Daviey === tumbleweed_ is now known as tumbleweed === mnepton is now known as mneptok === Beret- is now known as Beret [21:03] pitti: ping (TB -> #ubuntu-meeting) [21:04] kees: ^ [21:09] ah! [21:11] slangasek, hey [21:12] seb128: hey there [21:12] slangasek, how responsive is freetype upstream to issues they would create for i.e gtk? ;-) [21:12] seb128: they should be responsive... but there's no test suite to catch regressions, so you can expect any fix for an issue you're seeing to be bundled with another regression or two somewhere else :P [21:13] slangasek, underlining is broken in some cases in gtk (reported by mvo today), I tracked it down to freetype [21:13] is this with the 2.4.8+security fixes? [21:13] slangasek, i.e ld preloading the oneiric version fixes it up, .9 doesn't fix it [21:13] ok [21:13] slangasek, it's between oneiric 2.4.2 and precise [21:14] upstream git should be reasonably bisectable, I guess [21:16] slangasek, there is quite some commit between those versions, would have been nice to not skip 6 versions :p [21:16] slangasek, anyway I will try to figure when it started and come back ;-) [21:16] 4,6,7 were all uploaded to Debian, I don't recall if they made it into precise === s1aden is now known as sladen === dendrobates is now known as dendro-afk === dendro-afk is now known as dendrobates === salem_ is now known as _salem [22:18] slangasek, ok, found the commit, it's http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=b0962ac34e66052ccfee7996e5468f30d4bd5a72 [22:19] hmm [22:19] ok, that's the second regression I've seen from that committer in the past year [22:19] slangasek, not sure how to process next, it could be that freetype is right and that something else needs fixing :-( [22:19] s/committer/author/ [22:19] yes, that's always the concern :/ [22:20] slangasek, but applying that patch to 2.4.5 creates the bug, or reverting it in newer version fixes the bug [22:21] slangasek, the testcase from mvo is https://bugs.launchpad.net/ubuntu/+source/software-center/+bug/955030/+attachment/2988350/+files/lala.py [22:21] Launchpad bug 955030 in software-center (Ubuntu) ""Show N technical items" doesnt look clickable" [High,Triaged] [22:21] seb128: ah, no, that's the *same* commit that was earlier reported as a regression: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=636776 [22:21] Debian bug 636776 in libfreetype6 "libfreetype6: Line height squeezed in GNU Emacs" [Normal,Open] [22:21] in fact, that's the exact commit why oneiric stuck with 2.4.4 [22:22] slangasek, that breaks the underlining in that gtk example [22:22] * slangasek nods [22:22] slangasek, can we revert that commit in precise? ;-) [22:23] seb128: sure - you want to do it, or do you want me to? [22:23] seb128: can you also take that test case to upstream? freetype-devel@nongnu.org [22:23] slangasek, it's time to bed for me but I can do it tomorrow if you want [22:23] that'd be fine [22:23] slangasek, ok, I can do that as well tomorrow [22:23] slangasek, ok, I will do the commit revert and email the upstream list tomorrow, thanks! [22:26] seb128: thanks for tracking this down... maybe we can talk upstream into implementing a proper test suite :P [22:26] let's see, I would be happy enough if they come with an upstream fix for the regression to start ;-) [22:29] cjwatson: can you approve my e-mail to ubuntu-devel-announce? [22:31] stgraber: done === dendrobates is now known as dendro-afk [22:35] cjwatson: thanks === eights is now known as Guest23956 === infinity1 is now known as infinity [23:04] smoser: http://anonscm.debian.org/gitweb/?p=collab-maint/distro-info.git;a=commitdiff;h=c4f8e5dc44b6dec640c3222becc9d11d21a84078 [23:05] smoser: i moved your shell scripts into the script/ subdirectory. [23:06] slangasek, would you mind perusing bug #971767? I'm wondering if it might be due to something lower down than X, but I'm not sure where to look. [23:06] Launchpad bug 971767 in xorg-server (Ubuntu) "Xorg crashed with SIGSEGV in __GI___libc_malloc()" [High,Triaged] https://launchpad.net/bugs/971767 [23:06] sure, lookin' [23:07] slangasek, we're seeing a spate of vaguely similar-ish bugs against xserver, that seem to involve weird memory corruption, double-free'd pointers, and so on, but for ones we have good traces the code where the crash occurs looks fine. But makes me thing something just is not right in the stack. [23:08] (e.g. bug 943880 which seems relatively common) [23:08] Launchpad bug 943880 in xorg-server (Ubuntu) "Xorg crashed with SIGABRT in __libc_message() from XIDestroyDeviceProperty" [High,Confirmed] https://launchpad.net/bugs/943880 [23:08] bryceh: well, you have a binary blob video driver that has access to the stack, right? That would be my first guess... [23:08] bryceh: will X run under valgrind? [23:09] slangasek, it will [23:09] slangasek, in fact cnd was just doing that for debugging the latter bug [23:09] * slangasek nods [23:09] so it's exceedingly unlikely that malloc itself is broken here [23:10] * cnd hopes so [23:10] I think you have heap corruption, and valgrind's the best tool for finding that [23:10] slangasek, ok, thanks [23:10] I should have guessed ScottK would be the curmudgeon to reject my beautiful package ;) [23:11] slangasek, ok, so it's not an obvious bug you already know of in say libc [23:11] nope [23:29] slangasek, due to a miscommunication in our team, the latest utouch-frame was uploaded this past friday with a switch to dh 9 and multiarch [23:29] should we revert the change, or let it slide, or? [23:30] How many rdeps does it have, and have they all been tested? [23:30] cnd: ^ [23:30] cnd: ^^ what infinity asked [23:30] we need to follow through to make sure the revdeps don't regress [23:31] utouch-grail, utouch-geis, unity, libgrip, evince, eog [23:31] I actually don't see the last four as deps [23:31] unity still works, that takes care of grail and geis [23:32] utouch-grail, utouch-geis, mtview [23:32] those are what we have to care about from a build perspective [23:32] slangasek, is it just building that we are worried about? [23:32] or runtime too? [23:32] If everything still works, both at buildtime and runtime, reverting would be gratuitously perverse. But please do make sure. [23:32] for multiarch, it's just a build issue [23:33] (But yeah, for C libs, runtime should always Just Work) [23:33] ok, well we'll watch the precise archive rebuilds [23:33] Unless you've done something horribly hackishly wrong. [23:33] and fix up anything that breaks [23:33] but I would expect things to just work [23:33] cnd: the archive rebuild already started before Friday - please do your own rebuild tests of these packages [23:33] oh, ok [23:33]