| pitti | Good morning | 04:20 |
|---|---|---|
| ajmitch | morning pitti | 04:21 |
| didrocks | good morning | 05:45 |
| dholbach | good morning | 06:40 |
| McPeter | hi | 06:42 |
| === tkamppeter_ is now known as tkamppeter | ||
| hrw | precise opened - wonder how many people will switch to it during month | 07:11 |
| amitk | hrw: 5-6? :) | 07:14 |
| amitk | including you | 07:14 |
| dholbach | I switched a vm to precise :-) | 07:14 |
| amitk | dholbach: that's cheating :) | 07:16 |
| hrw | amitk: ;) | 07:16 |
| diwic | dholbach, what vm infrastructure do you use/recommend? | 07:25 |
| dholbach | I just use kvm - I used a normal .iso to install it there | 07:26 |
| dholbach | https://wiki.ubuntu.com/UsingDevelopmentReleases has a lot of different options | 07:26 |
| diwic | dholbach, okay, thanks | 07:26 |
| FourDollars | dholbach: Could you sponsor my patch at https://bugs.launchpad.net/ubuntu/+source/ibus-chewing/+bug/874028 ? | 07:35 |
| ubottu | Ubuntu bug 874028 in ibus-chewing (Ubuntu) "The preferences window of ibus-chewing crashed after clicking save button." [Undecided,Fix committed] | 07:35 |
| dholbach | FourDollars, I'm a bit busy with other stuff right now - maybe you could ping the patch pilot in the topic of the channel? | 07:38 |
| FourDollars | dholbach: I see. Thanks a lot. :) | 07:39 |
| dholbach | no problem | 07:39 |
| FourDollars | smoser: ping | 07:40 |
| janimo | FourDollars, from what I read here https://wiki.ubuntu.com/StableReleaseUpdates , it is better to have the fix already in the development series before requesting an update to the stable one | 07:47 |
| janimo | a fix for P should probably happen anyway right? | 07:48 |
| janimo | FourDollars, also the upload now targets a released version, so the changelog should have oneiric-proposed as the series name | 07:49 |
| FourDollars | janimo: Thanks you for your correcting. :) | 07:50 |
| janimo | FourDollars, I just read that doc now, I also need to work on a separate SRU :) | 07:50 |
| tumbleweed | I think in the first week, fixing relatively straightforward issues directly into -proposed is ok | 07:51 |
| tumbleweed | it's not like it would actually be tested by anyone in precise | 07:51 |
| tumbleweed | (assuming you copy-up from oneiric-proposed to precise) | 07:51 |
| FourDollars | ibus-chewing that I work on is the same version in precise and oeniric. | 07:52 |
| FourDollars | How should I do ? | 07:53 |
| FourDollars | Changing oneiric to oneiric-proposed ? Or oneiric to precise? | 07:53 |
| tumbleweed | upload to proposed as usual, and request that it be copyied to precise when accepted | 07:53 |
| FourDollars | I see. Thanks, tumbleweed. | 07:55 |
| janimo | tumbleweed, I am glad to hear there are some exceptions :) | 07:57 |
| * tumbleweed isn't in the SRU team, I just know what I've done in this situation :) | 07:58 | |
| FourDollars | I have changed bzr repo from oneiric to oneiric-proposed. | 07:59 |
| FourDollars | What should I do next? | 07:59 |
| FourDollars | What should I do in next step? | 07:59 |
| FourDollars | This patch should just be a Stable Fix . | 08:00 |
| tumbleweed | FourDollars: target oneric-proposed in the changelog, use 1.3.9.2-3ubuntu1.1 as your version, and get a sponsor to upload it. Then add a comment on the bug, asking the SRU team to copy it up when accepting it. | 08:02 |
| === jamespag` is now known as jamespage | ||
| FourDollars | tumbleweed: Should I use 1.3.9.2-3ubuntu1.1 because 1.3.9.2-3ubuntu1 is my upload? | 08:05 |
| FourDollars | tumbleweed: I just want to upload second patched version. | 08:05 |
| tumbleweed | FourDollars: the .1 makes it obvious that it was an SRU. See the security team's verisoning policy linked to from the SRU wiki page | 08:06 |
| FourDollars | tumbleweed: I see. Thanks for your explanation. | 08:07 |
| FourDollars | I have changed to 1.3.9.2-3ubuntu1.1 . | 08:09 |
| apw | mvo, i saw your analysis of the upgrade issue, do you want me to remove the package to confirm its my issue, or wait until you have something to test | 09:20 |
| mvo | apw: please remove I have the dpkg status file that was enough to reproduce the problem | 09:22 |
| apw | mvo, awsome preplanning ... will do and update theb ug | 09:23 |
| superm1 | mvo, i've been seeing people reporting in forums about 11.04->11.10 mythbuntu upgrades pulling in unity-greeter rather than mythbuntu-lightdm-theme. no one has filed a proper "bug" yet for it, but do you think this can be a side effect of calling do-release-upgrade without --mode=desktop? | 09:23 |
| mvo | superm1: it shouldn't be, the release-upgrader should figure this out automatically, it would be cool to get access to the logs when this happend | 09:26 |
| tjaalton | @pilot in | 09:29 |
| === udevbot_ changed the topic of #ubuntu-devel to: Precise open for uploads | Ubuntu 11.10 Released! | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: tjaalton, smo | ||
| * cjwatson flushes through an initial batch of mass syncs to precise, up to fonts-vlgothic | 09:30 | |
| cjwatson | I'll do the next batch after a publisher run has happened | 09:30 |
| pitti | cjwatson: oh, sync-source.py is working again? | 09:31 |
| pitti | or do we use an lplib tool now? | 09:31 |
| Laney | huzzah | 09:31 |
| === doko__ is now known as doko | ||
| Daviey | Hmm.. precise-changes mailing list doesn't seem to be showing everything. | 09:32 |
| pitti | WFM | 09:33 |
| pitti | Daviey: oh, "everything" -- what's missing? | 09:33 |
| Daviey | yeah, not me | 09:33 |
| Daviey | pitti: https://launchpad.net/ubuntu/+source/nova/2011.3-0ubuntu7 | 09:33 |
| Daviey | https://launchpad.net/ubuntu/+source/ajaxterm/0.10-12ubuntu1 | 09:33 |
| Daviey | https://launchpad.net/ubuntu/+source/antlr/2.7.7+dfsg-1 | 09:33 |
| Daviey | https://launchpad.net/ubuntu/+source/libxml-security-java/1.4.5-1 | 09:33 |
| Daviey | Infact, everything i have done.. :) | 09:34 |
| pitti | right, confirmed | 09:34 |
| Daviey | (including sponsorships.) | 09:34 |
| cjwatson | pitti: wgrant fixed sync-source | 09:34 |
| cjwatson | pitti: moving to an lplib tool is blocked | 09:35 |
| cjwatson | Daviey: #launchpad(-dev) might be better placed to look into this | 09:35 |
| wgrant | Daviey, cjwatson: I poked bigjools about that earlier, but I think he's distracted. | 09:35 |
| cjwatson | Daviey: FWIW I think I have been saying that I don't yet advise using syncpackage for sponsorships, and that people should continue to use old-style sync requests for those for now | 09:36 |
| wgrant | I don't know if mailman is stopping them, or LP isn't sending them, or... | 09:36 |
| Daviey | cjwatson / wgrant: ok, thanks | 09:36 |
| Daviey | cjwatson: Yeah, i'm not sponsoring sync's.. (although i did do one that someone had requested shortly before). | 09:37 |
| Tanguy | Hello. | 09:44 |
| Tanguy | I am the maintainer of the Debian package itstool, which is ahead from the one in Ubuntu. | 09:45 |
| Tanguy | So if someone is able to sync, please do so. :-) | 09:45 |
| cjwatson | Tanguy: https://wiki.ubuntu.com/SyncRequestProcess | 09:46 |
| cjwatson | somebody will need to verify that there are no Ubuntu-local changes lost by a sync | 09:46 |
| Tanguy | There are. | 09:46 |
| cjwatson | there are changes lost? | 09:46 |
| Tanguy | The package currently in Ubuntu was done for Ubuntu only. | 09:46 |
| Tanguy | Because at that time itstool was not in Debian. | 09:46 |
| cjwatson | I mean substantive changes, not changelog or whatever | 09:46 |
| Tanguy | I do not think there are. | 09:47 |
| cjwatson | please put this information in a sync request bug | 09:47 |
| cjwatson | we don't process syncs by IRC, it would get unwieldy :-) | 09:47 |
| cjwatson | definitely appreciate your interest though | 09:47 |
| cjwatson | hmm, why is merge-o-matic showing differences relative to unstable | 09:48 |
| cjwatson | I told it usto use testing | 09:48 |
| FourDollars | tjaalton: ping | 09:48 |
| tjaalton | FourDollars: pong | 09:49 |
| FourDollars | tjaalton: Could you help https://bugs.launchpad.net/ubuntu/+source/ibus-chewing/+bug/874028 ? | 09:49 |
| ubottu | Ubuntu bug 874028 in ibus-chewing (Ubuntu) "The preferences window of ibus-chewing crashed after clicking save button." [Undecided,Fix committed] | 09:49 |
| FourDollars | tjaalton: There is a crash bug existed in oneiric and precise. | 09:50 |
| Tanguy | cjwatson: Okay, as long as it is simple, for I have no specific interest in Ubuntu except the will to be nice. :-) | 09:50 |
| tjaalton | FourDollars: so upload to both oneiric-proposed and precise? | 09:50 |
| FourDollars | tjaalton: Yes, if it is ok. | 09:50 |
| tjaalton | FourDollars: sure, setting up chroots first | 09:50 |
| cjwatson | Tanguy: otherwise perhaps ask mterry, since he prepared the Ubuntu package | 09:51 |
| FourDollars | tjaalton: Are you asking me to set up chroots or you are setting up chroots? | 09:52 |
| Tanguy | cjwatson: I think I can assume he will see the sync request. | 09:52 |
| Laney | did we make syncpackage / requestsync default to testing? | 09:52 |
| tjaalton | FourDollars: no, I'm doing that right now, will get to your bug later | 09:52 |
| FourDollars | tjaalton: I see. Thanks. | 09:53 |
| cjwatson | Laney: not in oneiric at least | 09:53 |
| Laney | indeed | 09:53 |
| tumbleweed | Laney: I assumed we'd still want to default to unstable for manually requested syncs (or I would have made the change near the end of oneiric) | 09:57 |
| cjwatson | I can see that argument, certainly | 09:57 |
| tumbleweed | cjwatson: maybe you'll know: I noticed that lp doesn't have a release date for oneiric. Can someone set one? http://paste.ubuntu.com/710708/ (Asked a few times on the weekend, with no response) Should this be on one of the release checklists? | 09:58 |
| cjwatson | can't, requires an LP admin | 10:00 |
| tumbleweed | ok, I'll poke #launchpad, thanks | 10:00 |
| cjwatson | this went wrong in natty too, but IMO it shouldn't be checklisted, LP should be fixed to set it automatically when the distroseries goes to CURRENT | 10:00 |
| tumbleweed | right, a bug then :) | 10:01 |
| Laney | hmm, not bothered either way. At least for haskell that is true (because migrations are pretty awful there). | 10:01 |
| tumbleweed | filed bug 876345 | 10:07 |
| ubottu | Launchpad bug 876345 in Launchpad itself "distro series releasedate not automatically set" [Undecided,New] https://launchpad.net/bugs/876345 | 10:07 |
| cjwatson | ah, bzr update in mom's deployed branch failed | 10:07 |
| * cjwatson runs bzr upgrade to fix that | 10:07 | |
| cjwatson | with any luck it won't run out of disk | 10:09 |
| cjwatson | I've also fixed rmadison to not have stale data for precise (its mirror wasn't using --delete so it had stale uncompressed Packages/Sources lying around) | 10:10 |
| geser | tumbleweed: for the last lts where we also synced from testing, requestsync defaulted to testing. IMHO it should do it now too. It might not be important till DIF (when the tools are used seldomly) but more important after DIF. If someone sync from unstable it should be because they passed an option and not because they missed to tell it should sync from testing. | 10:13 |
| tumbleweed | hrm, u-d-t SRU time then | 10:16 |
| doko | cjwatson, is -Werror=format-security really that a good idea? | 10:16 |
| pitti | in general I appreciate these warnings, as they are often real bugs | 10:18 |
| cjwatson | doko: I think it is | 10:18 |
| pitti | did you find a case where it isn't? | 10:18 |
| cjwatson | it has a pretty good hit rate | 10:18 |
| cjwatson | sure, there's the odd FP, but also lots of cases where people assume that translators never get format strings wrong | 10:18 |
| cjwatson | (or are never malicious ...) | 10:18 |
| doko | well, what it the use for something like printf("foo\n"); ? | 10:19 |
| doko | just watching the ftbfs list grow because of this | 10:19 |
| pitti | if that generates an error, that indeed looks wrong | 10:19 |
| cjwatson | that shouldn't fail -Werror=format-security | 10:20 |
| cjwatson | it is certainly not documented to fail it | 10:20 |
| cjwatson | if gcc is failing that, that's a gcc bug | 10:20 |
| pitti | it doesn't here, at least not in precise | 10:21 |
| pitti | printf("foo\n"); | 10:21 |
| pitti | -> no error | 10:21 |
| pitti | printf(f); | 10:21 |
| pitti | -> error, as it should | 10:21 |
| pitti | sorry, s/not in precise/not in oneiric/ | 10:22 |
| doko | yes, it was the latter. however if we didn't have this until now, why for the lts? | 10:22 |
| cjwatson | we had it in oneiric, no? | 10:23 |
| doko | no | 10:23 |
| doko | this comes with the dpkg merge | 10:23 |
| cjwatson | oh, do you mean that this is a dpkg change? I wondered why you were asking me | 10:24 |
| cjwatson | context helps! | 10:24 |
| doko | sorry =) | 10:24 |
| cjwatson | if you want to back that out of dpkg for the LTS, feel free | 10:24 |
| pitti | is there a way that we could keep that for main packages only? | 10:24 |
| doko | let's see how many ftbfs we'll get with this | 10:24 |
| cjwatson | it was a 445000-line change, I didn't look at all of it :-) | 10:24 |
| doko | pitti: if you want to mess with dpkg-dev, maybe. | 10:25 |
| cjwatson | yeah, it would be nice to see if it's feasible to keep that; given that the change is in Debian we should not be getting new failures added from here on, only old ones | 10:25 |
| cjwatson | I wouldn't want to hack dpkg to know about different components | 10:26 |
| pitti | doko: too fiddly within dpkg-dev IMHO | 10:26 |
| cjwatson | it would be horribly confusing for local builds | 10:26 |
| pitti | I meant, could the buildds export a different CFLAGS depending on the components | 10:26 |
| pitti | but right, local reproducability | 10:27 |
| pitti | ok, ignore me then | 10:27 |
| ev | I don't suppose anyone has written a tool to unpack all the source for the base system? I'm trying to find out what packages use the automatic codec installation, and grepping for the header seems like the most straightforward approach. | 10:45 |
| pitti | yay @ component-mismatches explosion | 10:45 |
| pitti | ev: I have a little "for-srcarchive" script on lillypilly:~pitti/bin/ which you give an archive root (/srv/archive.ubuntu.com/ubuntu), a sources path (dists/precise/main/source/Sources.gz), and a command to run there (like grep ...) | 10:47 |
| pitti | ev: it outputs ==== pkgname === and then the output from the command | 10:48 |
| pitti | it runs a couple of hours for universe, though | 10:49 |
| seb128 | ev: it's likely going to be mostly totem, rhythmbox, banshee | 10:54 |
| seb128 | dunno about others | 10:54 |
| ev | pitti: awesome! | 10:55 |
| ev | seb128: indeed, thanks | 10:55 |
| McPeter | hi ev are you here ? | 11:22 |
| McPeter | grmlmgmr (sorry) | 11:25 |
| lool | slangasek: Hey there, I see "syncpackage: Source package u-boot is blacklisted." when using syncpackage on u-boot; I can't find it in the old http://people.canonical.com/~ubuntu-archive/sync-blacklist.txt and I can't find a link to an explanation at https://launchpad.net/ubuntu/+source/u-boot but would you remove it from the blacklist? I can't see a reason it should be blacklisted, we need it to provide mkimage in Ubuntu | 11:31 |
| lool | (and it's in already in Ubuntu since some cycles) | 11:31 |
| tumbleweed | lool: it's only blacklisted for a particular pair of versions | 11:32 |
| cjwatson | lool: that's just syncpackage/LP being obscure about the fact that it has Ubuntu changes. Use -f. | 11:33 |
| tumbleweed | LP does that automatically, and in a buggy way, this isn't the only package with that problem | 11:33 |
| lool | cjwatson: I checked on another package and didn't get this warning, maybe I picked my sample wrong though | 11:33 |
| cjwatson | lool: it's not blacklisted, anyway. | 11:33 |
| cjwatson | lool: use -f. | 11:33 |
| tumbleweed | lool: bug 841372 | 11:33 |
| ubottu | Launchpad bug 841372 in Launchpad itself "Incorrect auto-blacklisting in DSD?" [Low,Triaged] https://launchpad.net/bugs/841372 | 11:33 |
| lool | cjwatson: Yup, I actually sync-ed with with -f already | 11:33 |
| lool | tumbleweed: thanks | 11:34 |
| lool | tumbleweed: where did you find the list of blacklisted versions? | 11:35 |
| tumbleweed | you can do an api query | 11:35 |
| lool | slangasek: (never mind, apparently a known LP bug) | 11:44 |
| === MacSlow is now known as MacSlow|lunch | ||
| \sh | hmmm...oneiric and an asus pro 61S laptop is a total nogo | 12:24 |
| === MacSlow|lunch is now known as MacSlow | ||
| === smb` is now known as smb | ||
| === dendro-afk is now known as dendrobates | ||
| cjwatson | hm, I need to merge gnutls26 pronto apparently | 15:23 |
| Rantpaste | Looks like mono-xsp-base was deleted from Oneiric - anyone know if it was put in another repo? | 15:24 |
| Rantpaste | Alternatively, is there a better place to ask? | 15:24 |
| Laney | now that size of build queue is what I like to see | 15:25 |
| cjwatson | Laney: and I haven't even completed the mass sync ... | 15:25 |
| Laney | are you doing new packages at the same time? | 15:25 |
| cjwatson | * [9e2a65a] Move XSP4 features into a new mono-xsp4-base package, and | 15:26 |
| cjwatson | rename mono-xsp-base to dh-xsp since it only contains dh_installxsp. | 15:26 |
| cjwatson | Rantpaste: ^- | 15:26 |
| Laney | yeah, 1.1 has gone away | 15:26 |
| Laney | we have xsp2 and xsp4 now | 15:26 |
| Rantpaste | Cool | 15:26 |
| cjwatson | Laney: a few at a time, yes | 15:26 |
| Rantpaste | so my iFolder package needs updating :) | 15:26 |
| Laney | didn't that have license problems or something? | 15:27 |
| cjwatson | Laney: not terribly consistently, so shout if anything's urgent | 15:27 |
| Laney | can't think of anything major, there was some mono stuff that people wanted backporting but a) I can't remember what it was and b) it's not so urgent | 15:28 |
| Laney | if you could do haskell-* from unstable at some point though | 15:29 |
| cjwatson | I did :-) | 15:31 |
| cjwatson | oh, well, from testing | 15:31 |
| cjwatson | for stuff from unstable I'd prefer to have sync request bugs (or you can syncpackage them) | 15:31 |
| Laney | waiting for it to migrate is a pain | 15:32 |
| Laney | I'll sort something out at some point then | 15:32 |
| cjwatson | right, I don't mind people explicitly syncing stuff from unstable when they know what they're doing, I just don't want rationale/requestor hidden behind the autosync machinery | 15:32 |
| Laney | fair | 15:33 |
| Laney | maybe the clever new hinters will make migration behaviour nicer at some point | 15:34 |
| cjwatson | oh, BTW, I added http://people.canonical.com/~ubuntu-archive/transitions/libjpeg.html | 15:35 |
| kees | doko, cjwatson: yeah, the Werror=format-security caused about 120 ftbfses in the debian archive, iirc. most of them have been tagged in the bts and patches and being made. I think it's worth it too, but I did intentionally only turn it one in dpkg-buildflags so that it would slowly make it's way into the builds instead of putting it in the compiler like the others. | 15:37 |
| kees | it has a fair bit of FP, but catches enough real bugs to make it worthwhile | 15:38 |
| tkamppeter | pitti, hi | 15:41 |
| Laney | wait, I forgot, iulian wants to help look after Haskell this cycle :-) | 15:41 |
| tkamppeter | pitti, can you have a look at https://launchpadlibrarian.net/83022758/buildlog_ubuntu-precise-amd64.ghostscript_9.04%7Edfsg-0ubuntu12_FAILEDTOBUILD.txt.gz, seems that the buildds is not able to install CUPS on precise. | 15:42 |
| geser | Laney: any haskell transitions this time? | 15:42 |
| Laney | just the usual | 15:42 |
| Laney | probably get a new ghc with the new platform at some point | 15:43 |
| cjwatson | oh argh, gnutls26 indirectly self-build-depends and is currently uninstallable | 15:44 |
| geser | tkamppeter: this could be due to the gnutls merge cjwatson is working on | 15:44 |
| cjwatson | maybe it will build cleanly in an oneiric PPA? | 15:44 |
| cjwatson | tkamppeter: yeah, ignore it for now | 15:44 |
| tkamppeter | pitti, problem is on all supported archs. | 15:44 |
| cjwatson | tkamppeter: yes I know | 15:45 |
| tkamppeter | cjwatson, it builds cleanly in an Oneiric PPA, as the main change (liblcms1 -> liblcm2) I have already made available via PPA, the other differences to my PPA version are small patches. | 15:46 |
| tkamppeter | cjwatson, geser, it will be rebuilt after the buildds is fixed? | 15:47 |
| cjwatson | tkamppeter: yes, please leave me alone for now to work on it | 15:47 |
| geser | tkamppeter: yes if someone gives it back after the buildds got fixed | 15:48 |
| === dendrobates is now known as dendro-afk | ||
| cjwatson | I will take care of it | 15:49 |
| chrisccoulson | bdrung, do you look after vlc? | 15:54 |
| bdrung | chrisccoulson: you are thinking about 1.1.12 for oneiric? | 16:03 |
| chrisccoulson | bdrung, no, i just got pinged by someone from mozilla about bug 876625 ;) | 16:03 |
| ubottu | Launchpad bug 876625 in vlc (Ubuntu Oneiric) "VLC plugin is making Firefox crash" [Critical,Triaged] https://launchpad.net/bugs/876625 | 16:03 |
| bdrung | chrisccoulson: oh, haven't seen this bug yet. i am on amd64 | 16:05 |
| chrisccoulson | yeah, me too | 16:05 |
| bdrung | chrisccoulson: i have no time this week to look at it deeper | 16:05 |
| bdrung | chrisccoulson: can we get vlc 1.1.12-2~oneiric1~ppa1 from https://launchpad.net/~bdrung/+archive/ppa tested against this bug? | 16:06 |
| chrisccoulson | bdrung, if we can find someone to reproduce it :) | 16:06 |
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| superm1 | mvo, ok, i'be been trying to get people to file bugs, but nothing yet. with how prevalent it is, hopefully someone will | 16:14 |
| Daviey | slangasek: Hey, are you able to chime into bug 862129, would like to try and get this moving. Dupes are arriving quickly | 16:16 |
| ubottu | Launchpad bug 862129 in samba (Ubuntu Precise) "samba postrm depends on packages not guaranteed to be configured" [High,Triaged] https://launchpad.net/bugs/862129 | 16:16 |
| mvo | superm1: thanks, once there is a useful log, please let me know I will jump onto it | 16:16 |
| superm1 | ok | 16:16 |
| === firewave is now known as FireWaveJob | ||
| Q-FUNK | cjwatson: is there some special trick one must do to enable dh_apport or is dh7 supposed to call it automatically on ubuntu? | 16:40 |
| cjwatson | dh --with apport | 16:40 |
| cjwatson | and build-depend on dh-apport | 16:40 |
| cjwatson | (sorry, to be clearer, it's typically 'dh $@ --with apport' - I should mention that since the command-line ordering is counterintuitive) | 16:41 |
| Q-FUNK | cjwatson: ok. could it be a good idea to implement it by standard, witout the need to explicitely --enable-it or is there any particular reason for not doing it? | 16:42 |
| cjwatson | it's an Ubuntu-specific thing and I don't think we should change the default behaviour of debhelper | 16:43 |
| cjwatson | besides, --with is a common way to extend dh's behaviour | 16:43 |
| cjwatson | see e.g. --with python2 | 16:43 |
| Q-FUNK | yes, it's ubuntu-specific, but it would seem to make sense to auto-install any *.apport found whenever building for ubuntu. | 16:43 |
| Daviey | stgraber: Is merging fetchmail on your plan? | 16:43 |
| cjwatson | to do that it would have to be integrated into debhelper proper | 16:44 |
| cjwatson | which is not currently on my list of things to do | 16:44 |
| Q-FUNK | yes, it would, and it would make sense to include this as a standard part of the debhelper diff for ubuntu. | 16:45 |
| Q-FUNK | ah. oh well. | 16:45 |
| cjwatson | that's a guaranteed way to ensure it never gets into Debian | 16:45 |
| seb128 | cjwatson, is dh-apport doing anything out of installing the hooks? | 16:45 |
| cjwatson | so I'm not going to slam it into Ubuntu's debhelper, no | 16:45 |
| cjwatson | seb128: no | 16:45 |
| seb128 | cjwatson, I usually just list those in the .install, that seems smaller diff than adding a build-depends and a rules change but I might be overlooking something | 16:45 |
| seb128 | ok, thanks | 16:45 |
| cjwatson | I prefer having a dh_ command for it. you are welcome not to use it. | 16:46 |
| cjwatson | I really don't care :) | 16:46 |
| seb128 | yeah, I just wanted to check if I missed a good reason to use it ;-) | 16:46 |
| Q-FUNK | we welcome the command, not the extra build-deps. | 16:46 |
| Q-FUNK | but ok, fair enough :) | 16:46 |
| * cjwatson shrugs | 16:46 | |
| seb128 | don't count me in this "we", I'm fine with the build-depends being there ;-) | 16:47 |
| Q-FUNK | fair enough :) | 16:47 |
| cjwatson | it seems kind of bizarre to me to have an extension mechanism and then object to using it :-) | 16:47 |
| Q-FUNK | it seems even more bizare to not include it by standard in the ubuntu diff for debhelper. :) | 16:48 |
| cjwatson | politics, to some extent. | 16:49 |
| stgraber | Daviey: not really, am I touched-it-last on it? | 16:52 |
| Daviey | stgraber: looks like it :) | 16:52 |
| stgraber | Daviey: well, if you want to do it, feel free :) otherwise I'll look at all of these where I'm touched-it-last either this week or next | 16:53 |
| Daviey | stgraber: Are you attached to the delta, https://launchpad.net/ubuntu/+source/fetchmail/6.3.19-1ubuntu1 ? | 16:53 |
| slangasek | Daviey: what chiming are you looking for on bug #862129? I've commented on the historical reasoning for the package being the way it is, I don't really have input beyond that | 16:54 |
| ubottu | Launchpad bug 862129 in samba (Ubuntu Precise) "samba postrm depends on packages not guaranteed to be configured" [High,Triaged] https://launchpad.net/bugs/862129 | 16:54 |
| stgraber | Daviey: nope. I never used fetchmail as a daemon :) I think I'm touched-it-last on this one because I took all of Artur Rona's merges last cycle, so feel free to sync from Debian if you're not attached to that delta either | 16:55 |
| Daviey | stgraber: It doesn't look worthwhile to carry IMO, can always re-introduce it. | 16:55 |
| Daviey | thanks | 16:55 |
| stgraber | thanks for reducing my list of merges ;) | 16:56 |
| Daviey | (fwiw, i don't think the touched-it-last is the best way of allocating work.. but *shrug*) | 16:57 |
| cjwatson | it's not a way to allocate work | 16:58 |
| cjwatson | it's a way to avoid duplicating work | 16:58 |
| cjwatson | people are welcome to hand things over | 16:58 |
| cjwatson | "I'd like to do this merge; are you working on it?" is entirely reasonable | 16:59 |
| micahg | stgraber: I grabbed a few of those as well :), unless you're referring to main only | 16:59 |
| stgraber | micahg: I only looked at main, I'm sure he had a lot more in universe | 17:00 |
| micahg | pitti: would this be a good week to get Firefox 7/final langpack run for maverick going or would you like to wait until after UDS? | 17:00 |
| micahg | stgraber: ah, yeah | 17:00 |
| === beuno is now known as beuno-lunch | ||
| maco | tjaalton: still piloting? | 17:39 |
| hyperair | hmm the new umask in oneiric seems to be affecting the buildds. | 17:42 |
| geser | hyperair: how? some packages might be buggy by assuming a umask instead of setting the one they expect | 17:43 |
| hyperair | geser: no, it's a dh_thing | 17:43 |
| hyperair | geser: what's that dh_ thing that optimizes pngs? | 17:43 |
| tumbleweed | pkgbinarymangler | 17:43 |
| hyperair | -rw-rw-r-- root/root /usr/share/icons/hicolor/48x48/apps/gnome-mplayer.png | 17:43 |
| hyperair | see that? | 17:43 |
| hyperair | i suspect it's the same for all png files of packages using dh_blah that are built after the umask change | 17:44 |
| geser | file a bug against pkgbinarymangler and pitti will look at it | 17:45 |
| debfx | I think that pkgbinarymangler bugs has been fixed already | 17:47 |
| hyperair | hmm really? | 17:47 |
| hyperair | i had issues with sbuild very recently | 17:47 |
| hyperair | something like yesterday or the day before | 17:47 |
| maco | anyone want to sponsor a really simple fix for a main package for me? | 17:48 |
| debfx | bug #817792 | 17:48 |
| ubottu | Launchpad bug 817792 in pkgbinarymangler (Ubuntu) "pkgstripfiles doesn't preserve permissions of png files" [High,Fix released] https://launchpad.net/bugs/817792 | 17:48 |
| stgraber | maco: sure | 17:48 |
| maco | stgraber: thank you! https://code.launchpad.net/~maco.m/ubuntu/oneiric/nvidia-settings/fix-missing-dependencies-for-kubuntu/+merge/79588 | 17:48 |
| hyperair | debfx: oh nice. | 17:49 |
| stgraber | maco: was that uploaded to Precise already? | 17:50 |
| hyperair | debfx: would it be wise to rebuild the affected packages? | 17:50 |
| hyperair | a quick check of my /usr/share/icons reveals upwards of 600 affected icons. | 17:51 |
| maco | stgraber: no. i thought (from -devel ml) that syncs were busted on precise... are there packages there to futz with now? | 17:51 |
| debfx | I don't think so as long as the files are owned by root:root | 17:51 |
| maco | if so i guess i can make a merge proposal for that too, but itll be the exact same diff :P | 17:52 |
| stgraber | maco: I think syncs have been fixed today, though if that's in Debian it'll get synced automatically and fixed then. I just want to make sure we don't get a regression on Precise | 17:52 |
| hyperair | debfx: true that. i guess we can just leave it then | 17:52 |
| stgraber | maco: does 280.13-1 in Debian contain that fix? | 17:52 |
| geser | some mass-syncs from testing were done today | 17:52 |
| stgraber | maco: uploaded to oneiric-proposed | 17:55 |
| maco | im looking. i dont see anything in debian's changelog about it, but downloading to check the control file anyway | 17:56 |
| stgraber | maco: and also uploaded to precise so whoever ends up doing the merge won't iss it | 17:56 |
| stgraber | *miss | 17:56 |
| maco | debian's missing it too | 17:56 |
| maco | thanks | 17:56 |
| maco | guess i should talk to the debian maintainer | 17:57 |
| stgraber | yep, would be good to have that fixed in Debian | 17:57 |
| stgraber | maco: oops, that didn't quite work because of the package using a control.in... I should have seen that | 18:00 |
| stgraber | maco: I'll upload a new one to precise and -proposed | 18:01 |
| maco | crap :( | 18:01 |
| maco | hmm.... | 18:02 |
| maco | oh how odd | 18:02 |
| maco | debian's DOESNT use a control.in | 18:02 |
| maco | but ours does | 18:02 |
| === zyga is now known as zyga-afk | ||
| stgraber | SpamapS: Hi! There's currently two nvidia-settings package with the same version number in the proposed queue for Oneiric. Can you reject the first one (the one where the only change is debian/changelog)? | 18:10 |
| SpamapS | stgraber: ACK, will take a look shortly as I'm about to start doing SRU reviews | 18:11 |
| stgraber | SpamapS: thanks | 18:12 |
| === beuno-lunch is now known as beuno | ||
| maco | stgraber: thats confusing | 18:13 |
| maco | because lp's diff preview on the merge request shows changes in control | 18:14 |
| maco | or are control & control.in both in the source package even though control is generate? | 18:15 |
| stgraber | yeah, it's one of these cases where the branch looks good but running debuild drops the change... except that "bzr bd" runs outside of the branch so you really need to debdiff the result... | 18:15 |
| maco | i think i get why ScottK doesn't use bzr branches | 18:16 |
| maco | they're hell with quilt and sometimes hide problems | 18:16 |
| stgraber | both are in the source package with the real control being generated when you run debuild. I guess it would probably be better not to have debian/control in the branch at all as it's generated, that'd avoid the confusion | 18:16 |
| micahg | stgraber: I try to remember to debdiff the new version against the old before uploading in case something like this happens | 18:18 |
| stgraber | micahg: yeah me too, though this time I forgot and only did it post-upload... | 18:19 |
| micahg | stgraber: it happens :) | 18:19 |
| micahg | stgraber: if it's only -proposed, it can be rejected still if it hasn't been accepted yet | 18:19 |
| maco | i have a question | 18:19 |
| stgraber | micahg: it needs up taking quite a bit of bandwidth though when you need to: grab the branch, merge, commit, push the change, grab the current source package, diff the two and upload :) | 18:19 |
| maco | that answered it | 18:20 |
| maco | wanted to know how you debdiff when youre going from a branch | 18:20 |
| maco | i guess you could bzr branch, bzr bd, change, bzr bd, debdiff | 18:20 |
| micahg | maco: grab the old source :) pull-lp-source works for that | 18:20 |
| stgraber | micahg: yeah, I asked SpamapS to reject and I uploaded a clean one with the same version number. Though I had to do two uploads to Precise as I initially pushed to both -proposed and precise :) | 18:21 |
| stgraber | maco: yeah, that's assuming you trust the bzr branch ;) I prefer to trust what's in the archive | 18:21 |
| maco | at that point i wonder why use bzr then :-/ | 18:21 |
| maco | if youre gonna make a debdiff ANYWAY...might as well just submit that | 18:21 |
| maco | and then even the anti-bzr sponsors will take it | 18:22 |
| micahg | maco: exactly why I don't use it :) | 18:22 |
| geser | lool: can I take the vim merge of you? | 18:22 |
| stgraber | it's nice to stage changes and get more meta-data on what's been commited | 18:22 |
| micahg | maco: well, I don't use it for stuff that I don't actively maintain (random universe packages) | 18:24 |
| maco | oh right. maintain. i should fix that debian package... | 18:24 |
| maco | (not this one. the one im actually listed as an uploader on) | 18:24 |
| lool | geser: I've uploaded it already? | 18:26 |
| lool | geser: sorry, upload was rejected for some reason, but it's ready | 18:26 |
| geser | ok then | 18:26 |
| lool | re-uploaded | 18:27 |
| lool | it was missing the .orig.tar.gz the first time, I thought I had pushed it again, but apparently not | 18:27 |
| lool | geser: but in general, I wouldn't mind you caring for it in the future as you seem to be used to this diff ;-) | 18:27 |
| geser | sure, therefore I asked as I did the last merge but you did the last upload | 18:28 |
| lool | ack; thanks for the offer | 18:29 |
| geser | I need to shorten the diff to the changelog on the next merge as it is way longer than the actual changes | 18:31 |
| jbicha | quilt doesn't support binary diffs, right? | 18:33 |
| tumbleweed | jbicha: they can be included directly in the .debian.tar.gz with dpkg-source's included-binaries option | 18:37 |
| jbicha | tumbleweed: I'm trying to add a missing binary to a ubuntu-desktop branch, how would that work? | 18:39 |
| maco | jbicha: is the binary supposed to be in the source package? | 18:40 |
| lool | geser: Eh | 18:40 |
| lool | geser: If you're tempted to look into it, it FTBFSed due to other packages being uninstallable | 18:40 |
| lool | probably mass sync issues | 18:40 |
| jbicha | I'm trying to backport this commit which missed 3.2.1 by a few hours http://git.gnome.org/browse/aisleriot/commit/?h=gnome-3-2&id=b9a1f676657a729f1a3bfd0952879c25c9c74f76 | 18:41 |
| maco | oooh oggs | 18:41 |
| maco | yeah i think youre gonna have to go with what tumbleweed said | 18:42 |
| tumbleweed | jbicha: with svn, one just included them in the tree, outside the ubuntu dir. Never done it with bzr. /me looks | 18:42 |
| jbicha | I think it's a little more complicated since we generally only have debian/ in our packaging branches? | 18:43 |
| tumbleweed | no I'm also talking about merge mode in svn | 18:43 |
| jbicha | oh ok | 18:43 |
| geser | lool: the problem is the pending libgnutls merge but it's being worked on | 18:43 |
| micahg | jbicha: I think with source format 3, you can throw it in the debian dir and move it into place in .install | 18:44 |
| zimmerle | Hey kees, can you point me where i can find information about the AppArmor mediation of DBus communications? | 18:45 |
| zimmerle | i saw the blueprint, its says "Beta Available". Where i can find out this code? | 18:45 |
| zimmerle | jdstrand: ^ | 18:45 |
| micahg | zimmerle: jjohansen might be able to help you | 18:46 |
| jjohansen | zimmerle: ah, I still need to get the code posted | 18:46 |
| zimmerle | micahg: thanks ;) | 18:47 |
| * jjohansen keeps meaning too, but has treated posting as low priority, as it needs to be reworked | 18:47 | |
| zimmerle | jjohansen: cool, what is the current status? | 18:47 |
| jjohansen | zimmerle: its a direct dbus patch, it needs to be reworked into something less ugly. The plan was to make an lsm/xace type interface for dbus and push that upstream, so that selinux, apparmor and others can be plugins | 18:48 |
| kees | zimmerle: sorry for the delay :) yeah, jjohansen and jdstrand are the people to talk to (which you've found...) | 18:49 |
| jjohansen | zimmerle: beyond that, there is an outstanding bug that can't be fixed until the apparmor kernel module properly supports the get_peer_cred, and policy can't handle the task labeling yet | 18:49 |
| jjohansen | zimmerle: beyond that it seems to work okay. It fairly flexible, I can forward you the email I sent out about it | 18:50 |
| jjohansen | there were some testing packages I built | 18:50 |
| * jjohansen will try to get the code up to a bzr tree this afternoon | 18:51 | |
| jbicha | micahg: thanks, your suggestion works | 18:51 |
| jjohansen | zimmerle: the code rework I mentioned isn't strictly necessary, it just makes sense, and should make pushing upstream to dbus easier | 18:52 |
| micahg | jbicha: where in the debian directory I think is up to team policy, but not 100% sure on that | 18:53 |
| tjaalton | maco: "oops" | 18:53 |
| tjaalton | @pilot out | 18:53 |
| === udevbot_ changed the topic of #ubuntu-devel to: Precise open for uploads | Ubuntu 11.10 Released! | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: smo | ||
| zimmerle | jjohansen: would be nice to have your code, so I can see if I can help with anything. | 18:53 |
| jjohansen | zimmerle: oh I am sure we could find ways for you to help | 18:53 |
| jjohansen | :) | 18:53 |
| zimmerle | :) | 18:54 |
| tumbleweed | jbicha: for the record, I had to bzr-buildpackage -S -- -uc -us --source-option='--autocommit' --source-option=--include-binaries for it to work, so yes micahg's suggestion is preferable :) | 18:56 |
| tumbleweed | ah, I must have deen doing something wrong, once it was listed in include-binaries it worked without that... | 18:58 |
| cnd | @pilot in | 19:04 |
| === udevbot_ changed the topic of #ubuntu-devel to: Precise open for uploads | Ubuntu 11.10 Released! | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: smo, cnd | ||
| yofel | pitti: could one SRU the precise version of kdenlive to oneiric to fix bug 863186 - I have no idea what exact modification fixed the issue, but kdenlive in oneiric is unusable - unless you know how to manually write configuration files. | 19:06 |
| ubottu | Launchpad bug 863186 in kdenlive (Ubuntu) "[Oneiric] Kdenlive configuration vizard doesn't founding MLT SDK" [Medium,Fix released] https://launchpad.net/bugs/863186 | 19:06 |
| lool | jono: Hey there! Would you have some 5-10 minutes to discuss some UDS bits? | 19:29 |
| jono | lool, can you give me a few mins, just wrapping a call | 19:33 |
| lool | jono: Sure | 19:34 |
| jono | thanks! | 19:34 |
| jono | :-) | 19:34 |
| jono | lool, hey | 19:50 |
| jono | what's up? | 19:50 |
| lool | jono: where would I call you? | 19:53 |
| cjwatson | I think gnutls26 is disentangled now. I've given back everything in main that appeared to be affected and a fair bit of universe too. | 20:02 |
| geser | vim (i386) build succesfully now | 20:09 |
| geser | lool: ^^ | 20:09 |
| lool | geser: thanks a lot for looking after it | 20:10 |
| mdeslaur | cjwatson: I blame you for bug 876829 :) | 20:18 |
| ubottu | Launchpad bug 876829 in ifupdown (Ubuntu) "Oneiric's ifupdown breaks ip aliases" [Undecided,New] https://launchpad.net/bugs/876829 | 20:19 |
| stgraber | mdeslaur: and now he's gone ;) | 20:20 |
| mdeslaur | stgraber: coward :) | 20:20 |
| === zyga-afk is now known as zyga | ||
| stgraber | mdeslaur: though my guess is that you want to blame Debian on that one (well, we're shipping an alpha version of 0.7, so not entirely Debian's fault ;)) | 20:21 |
| slangasek | mdeslaur: if you run 'ifup -a' post-boot, does it work? | 20:21 |
| slangasek | i.e., does it bring up the alias | 20:21 |
| mdeslaur | slangasek: nope | 20:22 |
| slangasek | ok | 20:22 |
| slangasek | definitely an ifupdown bug, then | 20:22 |
| slangasek | can you note that on the bug please? | 20:22 |
| mdeslaur | slangasek: yes, thanks | 20:22 |
| slangasek | stgraber: regardless of who's to blame, could you please look into this :) | 20:23 |
| stgraber | mdeslaur: Debian ships 0.7~alpha5+really0.6.15 in wheezy/sid and has 0.7~beta1 in experimental, so quite likely that something was flagged as being wrong on their side too | 20:23 |
| mdeslaur | hehe, I was only joking about the blame part :) | 20:23 |
| stgraber | slangasek: happy to look at that tomorrow ;) enjoying my day off (kind of) today | 20:23 |
| slangasek | ack :) | 20:23 |
| stgraber | my guess is that the diff from 0.7~alpha5 and 0.7~beta1 may well contain the fix for mdeslaur's bug | 20:24 |
| seb128 | slangasek, hey, don't use "ubuntu-desktop" for bug assignments, that spams the ubuntu-desktop list ;-) Use canonical-desktop-team or desktop-bugs ;-) | 20:26 |
| slangasek | seb128: hmm, ok | 20:27 |
| slangasek | seb128: sorry | 20:27 |
| seb128 | slangasek, no worry, it's a frequent mistake, we should perhaps fix our list to block all launchpad emails ;-) | 20:27 |
| slangasek | seb128: well, or fix the team configuration in LP to not send mail to the list if that's not what you want to have happen :) | 20:28 |
| seb128 | slangasek, well if the team has no list it sends the emails to all members | 20:29 |
| slangasek | right | 20:29 |
| seb128 | not really better ;-) | 20:29 |
| slangasek | yeah, I dunno then | 20:29 |
| slangasek | cjwatson, TheMuso: e2fsprogs has a very old change to the optimization flags being passed on powerpc, to "avoid a suspected toolchain bug" when using -Os; but I don't find any references to this toolchain bug having ever been reported. I don't suppose one of you could follow through on that, so we can possibly drop that part of the delta? | 20:31 |
| slangasek | cjwatson, TheMuso: (low priority, best case we'll still have a delta due to dietlibc) | 20:31 |
| cjwatson | TBH I have no idea what that was, perhaps just drop it and let's see what gets reported? | 20:32 |
| cjwatson | it looks easy to reproduce at least ... | 20:33 |
| slangasek | cjwatson: I'm hesitant to just drop it and see what gets reported because I have the impression we don't get a lot of powerpc coverage, so I'm worried it might make it all the way into release without being noticed if I just drop it | 20:49 |
| slangasek | OTOH, I guess by this point if the bug were still present, Debian would have the same problem... | 20:51 |
| === yofel_ is now known as yofel | ||
| === emma_ is now known as emma | ||
| === emma is now known as EMMA | ||
| === EMMA is now known as emma | ||
| cjwatson | slangasek: I do know how to test powerpc installs in qemu nowadays (although it's really slow so I don't do it very often); one option would be to drop it and then assign me an alpha-1 bug or something to test if it's still needed, perhaps | 20:53 |
| slangasek | cjwatson: will do that then, thanks | 20:53 |
| cjwatson | sigh, it's amazing how quickly failed builds can rack up when core packages are broken | 20:54 |
| === emma is now known as em | ||
| geser | does somebody know if "INFO Require Pre-Depends: dpkg (>= 1.15.6) when using xz compression." from a "Failed upload" is an Ubuntu-specific error or does it apply to Debian too? | 20:56 |
| === Quintasan_ is now known as Quintasan | ||
| tumbleweed | geser: ubuntu-specific, we need it for LTS-to-LTS upgrades to precise | 20:57 |
| tumbleweed | squeeze supports xz, IIRC | 20:57 |
| geser | ok, so it doesn't need forwarding to Debian? | 20:57 |
| tumbleweed | don't think so. Saw grumbling about it in #debian-devel today... | 20:58 |
| micahg | !info dpkg squeeze | 20:59 |
| ubottu | 'squeeze' is not a valid distribution: hardy, hardy-backports, hardy-proposed, kubuntu-backports, kubuntu-experimental, kubuntu-updates, lucid, lucid-backports, lucid-proposed, maverick, maverick-backports, maverick-proposed, medibuntu, natty, natty-backports, natty-proposed, oneiric, oneiric-backports, oneiric-proposed, partner, stable, testing, unstable | 20:59 |
| micahg | !info dpkg stable | 20:59 |
| ubottu | dpkg (source: dpkg): Debian package management system. In component main, is required. Version 1.15.8.11 (stable), package size 2282 kB, installed size 6864 kB | 20:59 |
| geser | what is "kubuntu-experimental"? | 21:00 |
| cjwatson | geser: no, it doesn't need forwarding, because Debian's last release had xz support | 21:00 |
| cjwatson | we got unlucky | 21:00 |
| cjwatson | geser: I fixed five or so of those missing pre-depends this evening | 21:01 |
| cjwatson | e.g. altree | 21:02 |
| Daviey | seb128: We *want* people to use ~ubuntu-server, rather than ~canonical-server for server bugs.. People keep assigning bugs to ~canonical-server.. Desktop being opposite helps this confusion :) | 21:20 |
| === zyga is now known as zyga-break | ||
| micahg | Daviey: I know one Ubuntu Server team member that's quite opposed to that | 21:25 |
| Daviey | micahg: I don't care for annon opposition TBH :) | 21:25 |
| seb128 | micahg, hey, sorry I was away when you pinged, I've discussed with upstream webkitgtk about their schedule and they say they are strongly aligned on GNOME | 21:25 |
| seb128 | micahg, i.e we should track 1.8 next cycle | 21:26 |
| micahg | seb128: indeed, but if we're sticking with GNOME 3.2, shouldn't we track 1.6 by default? | 21:26 |
| seb128 | micahg, no session needed at UDS imho, it's a bit too technical to do an useful on schedule session, that was as well be discussed out of a session | 21:26 |
| micahg | seb128: re session> no disagreement here | 21:27 |
| seb128 | micahg, well, I'm usually in favor of updating the platform libs when we cna | 21:27 |
| seb128 | i.e we plan to update glib and gtk | 21:27 |
| seb128 | updating webkit should be fine, there is not a lot of GNOME depending on it and stuff like epiphany-browser can be updated as well | 21:27 |
| micahg | seb128: ok, then I can try to push for 1.8 as an LTS upstream as well (should work out about right for Debian as well, I guess I should ping them too) | 21:27 |
| seb128 | micahg, great | 21:27 |
| seb128 | Daviey, well I don't like much abusing the canonical teams for assignments but there is pro and con for each, including how we structure our desktop teams and lists ;-) | 21:29 |
| Daviey | seb128: sure. | 21:29 |
| seb128 | Daviey, usually we use assignment to canonical-desktop-team for issues somebody think our team should officially look at, i.e escalation, for the other desktop bugs we tend to nominate for a cycle but not assign | 21:29 |
| Daviey | seb128: makes sense. | 21:30 |
| cjwatson | kirkland: may I merge cdebconf? you're touched-it-last, but it's installer core and I'd like to get it merged | 21:41 |
| kirkland | cjwatson: sure thing! | 21:41 |
| kirkland | cjwatson: please | 21:41 |
| kirkland | cjwatson: fyi, newt upstream upstream released a modified version of my color changes | 21:41 |
| kirkland | cjwatson: we might be able to drop our patches against newt, though we'll need to rework the configuration file it reads, as the author chose a different format | 21:41 |
| kirkland | cjwatson: i've not checked to see if debian has the latest newt from upstream, though | 21:42 |
| cjwatson | I don't really need to look into that, I think | 21:43 |
| cjwatson | just focused on merging and getting everything building at the moment | 21:43 |
| kirkland | cjwatson: okay, sure, was just a related fyi, while i was thinking about it | 21:44 |
| cjwatson | yup, thanks | 21:45 |
| spickle | Can I post a crazy idea about ubuntu development in this channel? | 22:07 |
| === zyga-break is now known as zyga | ||
| === dendro-afk is now known as dendrobates | ||
| poolie | barry, hi? | 23:17 |
| barry | poolie: hi | 23:17 |
| poolie | hi there | 23:17 |
| poolie | jelmer just suggested in bug 794353 that perhaps ubuntu's sys.getfilesystemencoding() should be always utf-8 | 23:17 |
| ubottu | Launchpad bug 794353 in Bazaar "ascii is a bad default filesystem encoding" [High,Confirmed] https://launchpad.net/bugs/794353 | 23:17 |
| poolie | (or at least a fairly strong default) | 23:18 |
| poolie | at the moment it goes off $LANG (perhaps also other things) | 23:18 |
| poolie | istr ubuntu generally has a strong expectation it be utf-8? | 23:18 |
| poolie | obviously we can work around it | 23:19 |
| poolie | ah actually that's not totally obvious, but we probably can | 23:19 |
| barry | yeah, this is definitely not something i'd a) want ubuntu to deviate from debian; b) debian deviate from upstream | 23:19 |
| barry | i think it's just asking for trouble if we deviate | 23:20 |
| barry | e.g. what if someone installs python from source and runs bzr against that? you'd still have to work around it | 23:20 |
| cjwatson | "filesystem encoding" is a nonsense concept on Unix anyway (unfortunately) | 23:21 |
| lifeless | its bytes all the way down | 23:21 |
| cjwatson | file names are a byte stream, and encoding is up to the readers and writers | 23:22 |
| lifeless | cjwatson: except on darwin :) | 23:22 |
| poolie | cjwatson: i know, that's the problem | 23:22 |
| cjwatson | I don't think the situation would be improved by having Python lie about it | 23:22 |
| poolie | well | 23:23 |
| cjwatson | bzr is actually in a better position to say "screw it, I have a convention" than Python is | 23:23 |
| poolie | ubuntu has the choice to say "actually, it's normally utf8" | 23:23 |
| cjwatson | Ubuntu can't control what people have on disk | 23:23 |
| cjwatson | people might be using Python on their music collections with non-UTF-8 filenames | 23:23 |
| cjwatson | (a not entirely uncommon setup ...) | 23:23 |
| poolie | sure, they often are too | 23:23 |
| lifeless | perhaps Ubuntu could make it -hard- to get a non-utf8 locale though | 23:23 |
| cjwatson | it doe | 23:24 |
| cjwatson | s | 23:24 |
| poolie | there have been a bunch of u1 bugs about exactly that case | 23:24 |
| barry | iirc, nl_langinfo(3) isn't always accurate either | 23:24 |
| cjwatson | nl_langinfo is pretty good | 23:25 |
| poolie | python itself seems to have a default to utf-8, but people commonly accidentally have it set to ascii | 23:25 |
| cjwatson | I've never heard of it being wrong for this purpose | 23:25 |
| poolie | i guess specifically LANG=C will assume the filenames are ascii | 23:25 |
| tumbleweed | yay for C.UTF-8 | 23:26 |
| poolie | so the problem with bzr working around it is that there is a C variable inside python that holds the encoding, and no python api to reach it | 23:27 |
| poolie | (i think) | 23:27 |
| barry | sorry, i don't remember the details atm, but i do remember something weird with `locale charmap` not agreeing with nl_langinfo(CODESET) or somesuch | 23:27 |
| cjwatson | barry: ok, all I can say is I've never seen that in the programs I've written that use nl_langinfo(CODESET), so I wonder if perhaps it was on some other OS | 23:28 |
| poolie | i think the key issue on ubuntu is that LANG=C probably shouldn't mean "blow up on non-ascii filenames" | 23:28 |
| poolie | nl_lang(CODESET) is what python calls fwiw | 23:28 |
| barry | cjwatson: definitely ubuntu at some point, but no matter, i don't remember the exact details anyway ;) | 23:30 |
| poolie | so the answer is basically: ubuntu's going to do what upstream python does, upstream python's going to believe nl_langinfo(CODESET), and that's ascii for LANG=C | 23:33 |
| poolie | and other things people might set | 23:33 |
| poolie | so either bzr needs to work around it, or we need to make it obvious to people they ought to use a locale that can decode their filenames | 23:33 |
| barry | there's also $PYTHONIOENCODING if that helps | 23:35 |
| slangasek | the only potential gotcha I can think of with nl_langinfo(CODESET) is that sometimes the "native" names for encodings returned by glibc don't look like the strings you might expect elsewhere (e.g., ASCII is not called "ASCII") | 23:35 |
| slangasek | but in that case, it still matches 'locale charmap' anyway | 23:36 |
| slangasek | $ LANG=C locale charmap | 23:36 |
| poolie | barry: i think that's just the stream encoding not for filenames? | 23:36 |
| slangasek | ANSI_X3.4-1968 | 23:36 |
| slangasek | $ | 23:36 |
| poolie | also LANG='' | 23:37 |
| barry | slangasek: that could have been it | 23:38 |
| cjwatson | I do think using nl_langinfo(CODESET) for filename encoding and raising exceptions when it doesn't fit is basically brain-damaged, but I agree with barry that diverging from upstream Python here would probably be a cure worse than the disease | 23:38 |
| barry | i'm still trying to slog through the bug tracker to see if we have any related issues | 23:39 |
| poolie | it's pretty bad to assume the terminal encoding and the filesystem name encoding are always the same | 23:39 |
| cjwatson | and regrettably the right answer does quite often seem to be application-specific, so if there's a bug that you can't touch the filename encoding from applications, then I think that's what we (FSVO we) should fix | 23:39 |
| slangasek | it's pretty bad that we have filesystem encodings at all, since they're not enforced by the filesystem :) | 23:40 |
| slangasek | and we can't even sanely mount fat filesystems with utf8 as an encoding because of the case-smashing issue :P | 23:40 |
| cjwatson | there'd be a case for forcing all filename operations to happen using bytes, except that I suspect that breaks other OSes ... | 23:40 |
| barry | >>> import sys | 23:42 |
| barry | >>> sys.getfilesystemencoding() | 23:42 |
| barry | 'UTF-8' | 23:42 |
| barry | >>> import locale | 23:42 |
| barry | >>> locale.nl_langinfo(locale.CODESET) | 23:42 |
| barry | 'ANSI_X3.4-1968' | 23:42 |
| barry | >>> locale.setlocale(locale.LC_ALL, '') | 23:42 |
| barry | 'en_US.UTF-8' | 23:42 |
| barry | >>> locale.nl_langinfo(locale.CODESET) | 23:42 |
| barry | 'UTF-8' | 23:42 |
| barry | 23:42 | |
| barry | note that the above is python 2.7. python 3.2 behaves differently: | 23:43 |
| barry | >>> import sys | 23:43 |
| barry | >>> sys.getfilesystemencoding() | 23:43 |
| barry | 'utf-8' | 23:43 |
| barry | >>> import locale | 23:43 |
| barry | >>> locale.nl_langinfo(locale.CODESET) | 23:43 |
| barry | 'UTF-8' | 23:43 |
| barry | 23:43 | |
| barry | http://bugs.python.org/msg96095 | 23:43 |
| cjwatson | python 2.7 does an internal setlocale(LC_CTYPE) around setting Py_FileSystemDefaultEncoding | 23:43 |
| slangasek | SpamapS: do you have an opinion on whether the lvm2 merge from Debian is safe? Debian is now at 2.02.86; bug #726677 comments on 2.02.84 being "the safe" version, but I don't know if that's changed since. | 23:45 |
| ubottu | Launchpad bug 726677 in lvm2 (Ubuntu) "[Wishlist] Upgrade lvm2 to at least 2.02.73" [Wishlist,Confirmed] https://launchpad.net/bugs/726677 | 23:45 |
| slangasek | SpamapS: also, maybe you're better poised to test this merge than I am? I'm TIL on it, but it was for a minor build-system thing | 23:46 |
| SpamapS | slangasek: I can take a look.. I'm impressed LVM2 actually made a real release. ;) | 23:48 |
| SpamapS | IIRC it had been quite some time | 23:48 |
| slangasek | SpamapS: heh. they seem to have made several, upstream is at .88 now | 23:48 |
| SpamapS | RHEL6 probably propelling that | 23:49 |
| poolie | ok, thanks for the discussion | 23:49 |
| slangasek | SpamapS: should I assign the bug to you for tracking? | 23:49 |
| SpamapS | slangasek: please do, I plan to start working on merges tomorrow, will put that at the top of my list. | 23:51 |
| slangasek | SpamapS: done, thanks | 23:51 |
| SpamapS | slangasek: btw, did the mdadm situation in Debian ever get sorted? | 23:52 |
| SpamapS | I recall there was a call for help. | 23:52 |
| slangasek | SpamapS: I don't know | 23:52 |
| SpamapS | Been bogged down in other things.. fairly interested in making sure mdadm is solid for 12.04 | 23:52 |
| slangasek | yep | 23:52 |
| slangasek | we still have that un-worked spec proposing that we document the architecture :/ | 23:52 |
| SpamapS | if we cna justify it, I'd love to move that forward to P | 23:55 |
| cjwatson | slangasek: FYI, I have coreutils merged, but I'm going to wait for tomorrow to upload it so I can be around for a solid block of time afterwards, just in case it plays the buildd exploding game | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!