| arand | How does cdbs simple patchsys handle patches normally, just take everything in debian/patches in alphabetical order? (So I can just cp a couple of patches there is they are otherwise in the right format?) | 00:08 |
|---|---|---|
| bdrung | arand: yes | 00:09 |
| arand | bdrung: cheers, that makes things simple enough :) | 00:10 |
| ScottK | bdrung: Is this icon the same one that had audacious upstream here a few days ago asking for audacious to be removed from Ubuntu? | 00:22 |
| doctormo | ScottK: please critique this diagram, it shows my current understanding: http://imagebin.ca/view/dswC-M0r.html and is very probably wrong. | 00:24 |
| bdrung | ScottK: you are missinformed. i asked upstream if the upstream icon should look really like this http://launchpadlibrarian.net/44152900/audacious2-on-black.png - i did not create a new icon nor any other change. | 00:24 |
| ScottK | bdrung: I was here in the channel when it happened. | 00:24 |
| bdrung | ScottK: i asked upstream if they like the new svg icon and if they will accept it. they said yes. | 00:26 |
| ScottK | bdrung: Get them to say that in the bug and I'll accept it. | 00:26 |
| bdrung | <nenolod> bdrung, it looks nice | 00:27 |
| bdrung | <bdrung> nenolod: will you accept it? | 00:27 |
| bdrung | <nenolod> bdrung, sure | 00:27 |
| nenolod | it's fine | 00:27 |
| nenolod | go for it | 00:27 |
| ScottK | nenolod: You're upstream audacious? | 00:28 |
| nenolod | yes. | 00:28 |
| ScottK | OK. Thanks. | 00:28 |
| bdrung | nenolod: what do you think about following change to the tray icon search logic: searching for audacious2-panel. if it fails search for audacious2 | 00:30 |
| nenolod | the audacious/audacious2 distinction is no longer really relevant | 00:31 |
| nenolod | audacious classic (XMMS based audacious) has been dead for 2 years now. | 00:31 |
| bdrung | nenolod: but the 2 is in the binary name and in the icon name. will you drop that? | 00:32 |
| nenolod | bdrung, at some point. | 00:33 |
| nenolod | bdrung, it was reworked to allow audacious and audacious2 to be installed alongside each other. audacious 1.5 and audacious 2.0 PAPI/PABI were identical | 00:33 |
| bdrung | nenolod: http://pastebin.com/S1a61Yhv | 00:37 |
| bdrung | nenolod: this makes the statusicon themeable in an easy way | 00:38 |
| nenolod | bdrung, i already added that | 00:39 |
| nenolod | bdrung, to upstream... | 00:39 |
| doctormo | So, does that diagram look reasonable guys? | 00:39 |
| nenolod | like 3 days ago | 00:39 |
| bdrung | nenolod: really? hg pull doesn't pull it. | 00:40 |
| nenolod | it's there | 00:41 |
| nenolod | hg pull -u | 00:41 |
| nenolod | the -u is important | 00:41 |
| Laney | I really didn't think that un(iverse|seeded) uploads were subject to AA review | 00:42 |
| bdrung | nenolod: still not there | 00:42 |
| nenolod | it is. | 00:44 |
| nenolod | i am looking at it. | 00:44 |
| nenolod | ---> http://hg.atheme.org/audacious-plugins/audacious-plugins/rev/822c842d471e <--- | 00:44 |
| bdrung | strange | 00:45 |
| bdrung | nenolod: hg update did the job | 00:46 |
| nenolod | bdrung, use hg pull --rebase | 00:46 |
| nenolod | in the future | 00:46 |
| nenolod | just noting!! | 00:46 |
| nenolod | :p | 00:46 |
| bdrung | nenolod: can you add the check for audacious2? | 00:47 |
| nenolod | no | 00:47 |
| bdrung | http://pastebin.com/aTs4u7iv | 00:47 |
| nenolod | i disagree with that check | 00:47 |
| nenolod | for the reasons outlined above | 00:47 |
| nenolod | audacious2 name is deprecated | 00:48 |
| bdrung | ok, then the icons should drop the 2 | 00:48 |
| nenolod | they will eventually. | 00:48 |
| nenolod | it's not a high priority thing | 00:48 |
| bdrung | then this will be a diff that we carry until it's renamed | 00:49 |
| nenolod | i guess i'm going to have to protest that diff | 00:49 |
| ScottK | doctormo: Looking now | 00:50 |
| bdrung | nenolod: just retitle the bug to "rename the icons back to audacious" ;) | 00:50 |
| nenolod | bdrung, i'll title it "ubuntu package maintainers are arrogant" | 00:50 |
| nenolod | but do what you want | 00:51 |
| nenolod | i just find it somewhat strange that someone who thinks having 9001 patches is dumb, wants to add 9001 patches | 00:51 |
| ScottK | nenolod: Please don't paint your brush too widely. | 00:51 |
| nenolod | oh well ScottK is ok | 00:52 |
| bdrung | nenolod: the problem is that the icon is not found in the current situation. the statusicon searches for audacious, but the icons are called audacious2. i see only two solutions: 1. search for audacious2 as tray icon or 2. rename the icons to audacious | 00:53 |
| nenolod | bdrung, rename the ubuntu specific icons then... the fallback icon uri should be changed | 00:54 |
| ScottK | bdrung: I think this is an upstream issue and not a packaging issue and you should take the discussion to an audacious forum. | 00:54 |
| nenolod | bdrung, that last part is not possible as the ubuntu-proposed replacement svg icon hasn't been committed to hg yet as it was just filed in a bug today | 00:54 |
| bdrung | nenolod: "ubuntu specific icons"? the upstream png icon was called audacious2.png. - renaming the svg icon from audacious2.svg to audacious.svg? | 00:56 |
| nenolod | yes. as far as 2.3 goes, the new icon is still ubuntu-specific obviously | 00:56 |
| nenolod | we didn't ship the svg icon in 2.3, as it did not exist... | 00:56 |
| bdrung | nenolod: k (2.3 has the same problem, because it ships audacious2.png with the 2 in it) | 00:58 |
| nenolod | as far as upstream goes, 2.4 will replace the icon with the new .svg icon installed as audacious.svg | 00:59 |
| nenolod | :p | 00:59 |
| bdrung | nenolod: i will rename the icon tomorrow and update the patch. then we can drop this patch http://pastebin.com/aTs4u7iv | 00:59 |
| bdrung | and everybody will be happy :) | 01:00 |
| nenolod | my point is | 01:00 |
| nenolod | having 9001 patches doesn't benefit ubuntu audacious users | 01:00 |
| nenolod | if that makes sense | 01:00 |
| bdrung | nenolod: having 9001 patches makes only sense, if they end up in the next upstream release | 01:01 |
| bdrung | good night | 01:01 |
| nenolod | heh annoying story on that: the fedora guy keeps patching audacious (the patches are good), but when offered push access, he declines it | 01:02 |
| nenolod | :p | 01:02 |
| doctormo | thanks ScottK | 01:12 |
| ScottK | doctormo: It's kind of right and kind of wrong in ways that I really like the time to explain today. Maybe tomorrow. Feel free to give me a ping. | 01:15 |
| doctormo | ScottK: I presume you meant to add a "don't" in there somewhere | 01:18 |
| ScottK | Actually the error was like/lack | 01:19 |
| ScottK | But in principle, yes. | 01:19 |
| doctormo | ScottK: A dedicated seriousness we rarely see these days. | 01:22 |
| arand | doctormo: That diagram looks really nice (my cargo-cult kind of packaging knowledge might not be the best point of critique, but...). You planning to make more accessible guide to packages? | 01:28 |
| doctormo | arand: Yea, someone asked for a vidual guide similar to the foss visual guide I made. | 01:29 |
| carstenh | doctormo: the arrow from the "debian source control (not signature)" file to pbuilder means that you upload the dsc file to pbuilder? | 01:40 |
| doctormo | carstenh: Ah right, it's the changes file right? | 01:52 |
| doctormo | One I missed | 01:52 |
| carstenh | doctormo: you don't seem to like answering questions ;) when you upload a package to debian you have to sign .changes and .dsc but i have no idea how ubuntu handles uploads | 02:06 |
| doctormo | carstenh: I don't? | 02:07 |
| persia | It's precisely the same. | 02:08 |
| persia | Well, kinda. | 02:08 |
| persia | The signed .changes file needs to be source.changes, but otherwise the same. | 02:09 |
| carstenh | doctormo: (unless ubuntu does weird things with uploading directly from launchpad) you have to feed dput with the .changes file, but that does not mean that this is the only file you upload. how would pbuilder extract the tar.gz when you don't upload ist? | 02:09 |
| carstenh | s/ist/it/ | 02:09 |
| doctormo | carstenh: Of course you have to upload the whole lot of them (or rather that's what the command does) but you specify the changes file on the cli | 02:10 |
| doctormo | I need to get away from what the computer does and focus on what the user does | 02:10 |
| carstenh | doctormo: this is why i asked whether "you upload the dsc file to pbuilder". it's fine if this is by intention | 02:11 |
| doctormo | carstenh: It's not, that's why I'm editing it, because I was wrong. | 02:13 |
| carstenh | doctormo: you missed the most important part of packaging, the packaging itself. dh_make only generates templates | 02:14 |
| carstenh | doctormo: this was done for debian from a different point of view but might be helpful to get some ideas: en.wikipedia.org/wiki/File:Debian-package-cycle.png | 02:16 |
| carstenh | persia: do you need to upload a build log to show that you tried to build it before uploading? | 02:19 |
| ScottK | carstenh: No. | 02:19 |
| ScottK | If you're a developer you just upload. If you need to be sponsored, the sponsor might ask for that. | 02:19 |
| persia | carstenh: No. We trust uploaders to check first. Part of how this is encouraged is that when sponsoring, the sponsors always test-build, and reject stuff that doesn't build, so folks are used to being sure before they are ready to be granted upload rights. | 02:20 |
| persia | ScottK: Hey. If you're a developer, you test-build for your own peace of mind, and upload, right? | 02:20 |
| carstenh | are there any statistics how often ftbfs happen in comparison with debian where a dd obviously needs to build the package? | 02:20 |
| ScottK | persia: Yes | 02:20 |
| * persia knows of exceptions, but very much hopes they remain exceptions. | 02:20 | |
| doctormo | http://imagebin.ca/view/sp2isyc.html | 02:20 |
| doctormo | I expect to go through 20 revisions of this before I get it right | 02:20 |
| ScottK | carstenh: Actually I think we probably do better. | 02:21 |
| persia | carstenh: There aren't, although we have had to fix a little over a thousand arch:all pacakges that could build on local DD machines but not build on the builders from source upload (thankfully nearly all of these patches are now integrated in Debian) | 02:21 |
| ScottK | carstenh: It's not uncommon for me to see arch all package FTBFS on Ubuntu because the DD the uploaded it to Debian had something that would build in his local environment, but not in the pristine environment of a buildd | 02:21 |
| ScottK | My favorite was the one I found where the username of the DD was hard coded into the maintainer scripts. | 02:22 |
| lfaraone | lol. | 02:22 |
| persia | doctormo: Please say "packaging files", rather than `dh_make -e`. In 90% of cases, using dh_make only makes it harder for the user. | 02:22 |
| doctormo | persia: packaging files isn't an action or command, if none are appropriate, I'll remove it. | 02:23 |
| persia | (and really, one just needs control, copyright, changelog, contrib, and rules: of these 2 are trivially machine generated, 1 is available as an exampe that works in 90% of cases ,and the other two require thought) | 02:23 |
| persia | doctormo: My contention is that none are appropriate. | 02:23 |
| carstenh | ok, arch:all are some kind of special. before ubuntu or lucas built the whole archive ftbfs could get missed | 02:23 |
| doctormo | persia: What makes a debian directory? manually created? | 02:24 |
| persia | carstenh: s/could/would/, but yeah :) Most are fixed now, between the various sources of rebuilds. | 02:24 |
| persia | doctormo: My recommendation is currently `mkdir debian` for the general case, but there are some efforts to automate stuff (python-stdeb is a good example). | 02:25 |
| ScottK | Well, it's an example | 02:26 |
| doctormo | persia: Do you think that the automatic generation would likely to be dependant of the type of code/package? | 02:26 |
| * ScottK is sure it's made it to good yet. | 02:26 | |
| ScottK | is/isn't | 02:26 |
| persia | For the true general solution, we lack 1) polishing liw's work to autogenerate DEP5 copyrights, and 2) cleanup of the build-deps detectors for a few more languages, and 3) some integration scripts. | 02:26 |
| persia | doctormo: The build-dep detector will always be language-dependent. Nothing else needs be. | 02:27 |
| persia | And there's no reason one can't write a generalised pluggable build-dep detector framework, but nobody has done this yet. | 02:27 |
| doctormo | I mean for making good general debian directories | 02:27 |
| persia | I don't think so. For most packages, the implementation details of the code are irrelevant to the packaging, except in 1) determining build dependencies, and 2) working around any imperfections of the upstream build system. | 02:28 |
| carstenh | persia: one thing you miss is that there is now a new dpkg format where a second tar.gz replaces the diff.gz and that is able to handle tar.bz2 as upstream source archive | 02:29 |
| persia | carstenh: Hrm? How do I miss that? | 02:29 |
| ScottK | carstenh: It's an option, but in most cases really doesn't provide benifit. | 02:30 |
| persia | carstenh: Or do you mean that I failed to list source/format as a required file? It's useful, and recomended, but I don7t think it's any more required than watch. | 02:30 |
| ScottK | Lintian whines about its lack, but that's one of it's sillier complaints. | 02:30 |
| carstenh | persia: sorry, not you, doctormo :) | 02:30 |
| persia | (and I usually recommend packaging by starting with the watch file) | 02:30 |
| ScottK | The absence of source/format clearly means v1. To pretend anything else is just insanity. | 02:31 |
| carstenh | ScottK: optional yes, but people will expect a diff.gz when they read this diagram | 02:31 |
| ScottK | Adding source/format for v1 packages is just busywork. | 02:31 |
| ScottK | carstenh: For the general case that's reasonable. | 02:32 |
| persia | adding source/format for v1 packages is against the lintian recommendation. | 02:32 |
| carstenh | doctormo: see above | 02:32 |
| persia | It says to only do that if filing a bug about how v3 fails. | 02:32 |
| ScottK | persia: The assumption is that there's no other reason you'd not want to switch. | 02:32 |
| * lfaraone thinks the idea of adding a new *directory* just to contain a single file is madness. | 02:32 | |
| persia | doctormo: Yeah, don7t break down how the source package works: it's .dsc + package files (identified in the .dsc) | 02:33 |
| ScottK | lfaraone: If can contain more than one file if you have binaries in your debian.tar.gz. | 02:33 |
| lfaraone | ScottK: debian/source/? | 02:33 |
| ScottK | lfaraone: Yes. | 02:33 |
| doctormo | persia: what do you mean? | 02:33 |
| * lfaraone admits being only cursorly familiar with v3 | 02:33 | |
| persia | doctormo: A .dsc contains some metainformation and a list of files (and checksums) that make up the source package. There are steadily decreasing requirements regading the specific files that are required. | 02:34 |
| carstenh | doctormo: if you substitute diff.gz with diff.gz or debian.tar.gz it should be more correct and less confusing for people rebuilding a package that produces a debian.tar.gz | 02:35 |
| persia | Anyway, back to trying to set up a system that can play torcs to test whether the new openAL offers useful benefits for lucid (and other adventures in yak shaving) | 02:36 |
| ScottK | carstenh: You can also have a debian.tar.bz2. | 02:40 |
| doctormo | Revision 03: http://imagebin.ca/view/UdvI1Y.html | 02:40 |
| carstenh | ScottK: do you have any idea how to write debian.tar.{gz,bz2} human readable and short? ;) | 02:43 |
| ScottK | Sorry, need to run out (not really) | 02:43 |
| doctormo | carstenh: I was thinking just tar or tar.xz | 02:45 |
| wgrant | xz isn't supported yet, though. | 02:45 |
| funkyHat | https://edge.launchpad.net/~ubuntu-dev points to a non-existant page on the wiki | 02:47 |
| doctormo | wgrant: funny guy | 02:47 |
| wgrant | doctormo: What? I'm serious. | 02:48 |
| doctormo | OK I'm going to stop at rev 04 and then come back, I think I'll tackle each collection of transactions in the picture as a chapter. | 02:56 |
| lucas_ | ScottK: looking at the number of failed builds, I don't think so. the number looks normal | 06:43 |
| ScottK | lucas_: OK, but a number of the universe package failures are for non-existant packages that clearly exist and at the time were in Universe | 06:44 |
| lucas_ | ScottK: I'll do another rebuild now that the archive is frozen | 06:47 |
| lucas_ | ScottK: I know there was a problem with updating the chroot at the beginning of the rebuild | 06:48 |
| ScottK | lucas_: OK. Thank you. Sounds great. | 06:48 |
| micahg | ScottK: some of the FTBFSs in the last rebuild were due to the deleted binary packages | 06:48 |
| ScottK | lucas_: BTW, I've been finding quite a number of good fixes thanks to your tests. | 06:49 |
| ScottK | micahg: Yes, but not relevant to the ones I was questioning. | 06:49 |
| persia | micahg: That's part of what is useful to discover, and the point of it all. | 06:49 |
| micahg | ScottK: k, seems I missed the beginning of teh conversation | 06:49 |
| ScottK | micahg: BTW, where you find such cases we should get them removed binaries restored by fixing the FTBFS or get the binaries that now fail removed too. | 06:50 |
| ScottK | That's useful work here in the end game. | 06:50 |
| micahg | ScottK: I did for the one I noticed | 06:50 |
| ScottK | micahg: Excellent. | 06:50 |
| ajmitch | ScottK: I did end up filing that pychecker bug | 06:50 |
| micahg | just needed a sync from Debian | 06:50 |
| ScottK | ajmitch: I just went through syncs tonight and I didn't see anything. | 06:51 |
| ajmitch | still waiting for ~ubuntu-release | 06:51 |
| ScottK | ajmitch: What bug? | 06:51 |
| * ScottK doesn't recall the bugmail. | 06:51 | |
| ajmitch | bug 563543 | 06:52 |
| ubottu | Launchpad bug 563543 in ubuntu "FFe: Sync pychecker 0.8.18-4 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/563543 | 06:52 |
| ajmitch | the main sync I'm caring about at the moment is bug 562178, if you had a look at that tonight | 06:52 |
| ubottu | Launchpad bug 562178 in php-apc "FFe: Sync php-apc 3.1.3p1-2 (universe) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/562178 | 06:52 |
| ScottK | ajmitch: The latter one I looked at and put in a stack I asked slangasek to do. It should go through. | 06:53 |
| ajmitch | thanks | 06:53 |
| ScottK | ajmitch: Approved. Please see the comment. | 06:56 |
| ajmitch | ScottK: alright, thanks | 07:02 |
| ajmitch | I believe the changes aren't necessary, as they were just to run it on python 2.5 | 07:03 |
| ajmitch | I'll put that in the bug in a minute | 07:04 |
| kaushal | hi | 07:37 |
| kaushal | is TB 3.04 available in jaunty-backports ? | 07:37 |
| kaushal | checking in again for my query ? | 08:14 |
| === Zhenech_ is now known as Zhenech | ||
| === Lutin_ is now known as Lutin | ||
| === lool- is now known as lool | ||
| === \vish is now known as vish | ||
| === lucas_ is now known as lucas | ||
| DktrKranz | kaushal: no, it isn't | 10:57 |
| sistpoty | haha, I just saw an epic merge + patch system fail | 13:43 |
| === |sistpoty| is now known as sistpoty | ||
| === azeem_ is now known as azeem | ||
| sistpoty | ScottK: haha, just saw that you commented on bug #565836 about the same thing as /me... and I was actually referring to YokoZar for input and just now realised that this might not be that clear ;) | 15:13 |
| ubottu | Launchpad bug 565836 in playonlinux "[FFe] Please sync playonlinux 3.7.3-1 (multiverse) from Debian unstable (contrib)" [Undecided,Incomplete] https://launchpad.net/bugs/565836 | 15:13 |
| === ShadowChild is now known as lukjad86 | ||
| nigelb | nhandler, is bug 564070 ready for sponsorship? | 17:41 |
| ubottu | Launchpad bug 564070 in libgtk2-perl "libgtk2-perl ftbfs" [Wishlist,Confirmed] https://launchpad.net/bugs/564070 | 17:41 |
| nhandler | nigelb: Don't worry about that bug | 17:42 |
| nigelb | nhandler, came to review queue today :) | 17:42 |
| lfaraone | Hm. If a file was included in a GPL-2+ project with the following header: "courtesy of velAr the meerkat, denizen of #mpeg3c,This file is in the Public Domain", can it be included in universe? (is it DFSG-free?) | 17:49 |
| jcfp | why not? public domain = copyright disclaimed | 17:53 |
| jcfp | lfaraone: there's such software in the archive already, btw; projects with gpl-2+ and public domain code. | 17:54 |
| === yofel_ is now known as yofel | ||
| persia | Anyone happen to know the timing of debian dinstall runs offhand? | 18:13 |
| * persia wants to pull a bugfix sync adding amd64+armel support, but it's not published yet :( | 18:14 | |
| pochu | 19:19 >>> Topic for #debian-ftp: Feel free to idle but this isn't a discussion channel || dinstall starts at 0152,0752,1352,1952 UTC || #debian-dak || git clone http://ftp-master.debian.org/git/dak.git | 18:19 |
| pochu | persia: ^ | 18:19 |
| persia | Thanks! | 18:19 |
| pochu | np :) | 18:20 |
| nhandler | Does anyone know the reasoning behind not merging Ubuntu support back into Debian's version of pbuilder? | 18:20 |
| persia | Now I'm confused. Package accepted at 12:33 UTC, dinstall at 1352 UTC, and now it's 1720 UTC. | 18:20 |
| persia | Ah, poor mirror choice. | 18:21 |
| jpds | ... | 18:22 |
| persia | nhandler: You might want to check with lool about that: he's been doing a lot of work on pbuilder in Debian (and was recently accepted into upstream), and uses it for Ubuntu. | 18:24 |
| ScottK | persia: An archive admin with shell access can sync from incoming. | 18:30 |
| persia | ScottK: I like to a avoid that if I can (and in this case, I just needed not to use the mirror I selected). | 18:34 |
| ScottK | OK | 18:34 |
| persia | Ugh. "Unsupported CPU". | 18:34 |
| * persia wishes folks would just trust porters, and not add special checks in their supposedly portable code to detect the environment and not run there. | 18:35 | |
| ScottK | persia: Could you find a javaish person to deal with http://people.canonical.com/~ubuntu-archive/NBS/libnb-platform10-java - It's not just a rebuild. | 18:42 |
| * persia grumbles faintly in the direction of Oracle | 18:43 | |
| persia | One would think that if a company sponsored two open-source projects, that company would have an interest in them working together... | 18:44 |
| ScottK | Interesting theory. | 18:44 |
| ScottK | bdrung: Looking at the audacious FFe bug I see someone is having problems with the lastfm plugin now that it's updated. Would you please look into that. | 18:59 |
| nhandler | ScottK: He commented | 19:00 |
| ScottK | I see now. Thanks. | 19:00 |
| ScottK | Thanks bdrung. | 19:00 |
| lool | nhandler: What Ubuntu support do you mean? | 19:01 |
| nhandler | lool: I just had a DD try and use Debian's pbuilder to create a lucid chroot, but he said it was not recognized as a valid dist. I'm seeing ubuntu support in pbuilder's git branch, is this in the repos? | 19:01 |
| lool | nhandler: The delta is really limited nowadays, it's only the default mirror and release which change; I'd like to default to lsb_release output at some point, but that's not trivial | 19:01 |
| lool | nhandler: I'd guess it's his debootstrap being out of date | 19:02 |
| nhandler | I passted that guess on to the DD (he is at dinner now) | 19:03 |
| lool | nhandler: If that doesn't help, details on how he runs pbuilder would be nice | 19:04 |
| nhandler | lool: Sure thing | 19:04 |
| * ScottK points lfaraone at http://people.canonical.com/~ubuntu-archive/NBS/sugar-0.86 and urges him to peddle harder. | 19:05 | |
| ScottK | persia: Any thoughts on 565836? | 19:06 |
| * persia takes back criticism of Oracle, and just wishes that the libraries weren't embedded in sources. | 19:08 | |
| persia | ScottK: I've never used playonlinux, nor do I expect to do so in the future, but the upstream changelog, though sadly brief, seems to be bugfixes | 19:11 |
| ScottK | OK. | 19:11 |
| persia | I'd really want to hear from YokoZar about it, though. | 19:11 |
| * ScottK looks at YokoZar. | 19:11 | |
| ScottK | Thanks. | 19:11 |
| * ScottK looks at the krb5-auth-dialog depwait and hopes someone will look at it and figure out what needs doing. | 19:23 | |
| YokoZar | ScottK: I don't use playonlinux but its regression potential is very low | 20:01 |
| ScottK | YokoZar: Thanks. Does that means it works well and is unlikely to break or it's so fubar it can't get worse? | 20:02 |
| YokoZar | ScottK: It's basically a collection of workarounds with Wine, so it's a good thing when it's kept in sync with the Wine version it was written to | 20:03 |
| ScottK | YokoZar: OK, so which version matches our Wine for Lucid? | 20:04 |
| YokoZar | ScottK: 3.7.3, judging from their changelogs. Which also happens to be the one in debian unstable multivers | 20:09 |
| ScottK | YokoZar: Thanks. | 20:10 |
| ScottK | YokoZar: If you'd don your MOTU hat and sponsor 565836, I'd appreciate it. | 20:14 |
| imbrandon | moins ( afternoon ) all | 20:15 |
| YokoZar | ScottK: It's a sync request...what exactly would I sponsor? | 20:15 |
| imbrandon | bdrung: whats your dm key email ( so i can add you to the uploaders ) | 20:16 |
| ScottK | YokoZar: Sync reqeuest for non-developers need developer approval. | 20:16 |
| YokoZar | ScottK: Ahh ok. I'll test it today then and post there. | 20:16 |
| ScottK | YokoZar: So if you approve it, say so in the bug and subscribe ubuntu-archive. | 20:16 |
| ScottK | Thanks | 20:16 |
| === foxmike is now known as jeanl | ||
| Laney | http://orangesquash.org.uk/~laney/haskell-installability/armel.png | 20:51 |
| Laney | I'd call that complete | 20:51 |
| Laney | those two packages have porting problems | 20:51 |
| Laney | yay :) | 20:51 |
| ScottK | StevenK: My non-Perl trained brain says that http://launchpadlibrarian.net/44724101/buildlog_ubuntu-lucid-i386.libpoe-component-client-dns-perl_1:1.051-1_FAILEDTOBUILD.txt.gz is FTBFS on the buildd's because the last two tests in that particular file need network access to succeed. I'd appreciate it if you would have a look and see if that's correct and render an opinion about the advisability of removing the tests so that the package will build | 21:12 |
| ScottK | . | 21:12 |
| ScottK | YokoZar: I see at least one package looking to build-dep on libwine-dev, which we don't provide. What's the solution? https://launchpad.net/ubuntu/+source/dssi-vst/0.8-2/+build/1497469 | 21:17 |
| ari-tczew | when maverick will be open? | 21:17 |
| YokoZar | ScottK: adding provides: libwine-dev to wine-dev I think | 21:18 |
| ScottK | YokoZar: Could you take care of that? | 21:18 |
| YokoZar | ScottK: Well it might be better to just change the build deps in the package. I'll look at it anyway. | 21:18 |
| siretart | ari-tczew: https://wiki.ubuntu.com/MaverickReleaseSchedule/ | 21:18 |
| ScottK | YokoZar: Whichever. Please fix. | 21:19 |
| gastons | am I allowed to add files under the DEBIAN directory? | 21:31 |
| gastons | (besides control, postinst etc.) | 21:32 |
| imbrandon | gastons: sure, but if its the right thing to do depends on the case | 21:32 |
| gastons | I want to add a xml file there. It will be copied to ~/.some_config_dir, but if Install my .deb it fails. | 21:39 |
| directhex | gastons, you never ever ever ever ever mess with DEBIAN/ manually | 21:43 |
| imbrandon | gastons: debs are installed system wide, they have no concept of ~/ , the program should create/copy the needed xml's to the ~/ if needed | 21:45 |
| gastons | isn't the postinst script meant to do that? or maybe from postinst should I call a config script? | 21:50 |
| imbrandon | gastons: not really, i guess postinst could modify skel , but ewww, and what about existing users | 21:52 |
| imbrandon | think about when like you install wine, it dosent make a ~/.wine in all users homes, but it does for each user that runs it ( on first run ) | 21:53 |
| imbrandon | based on some sane defaults | 21:53 |
| joaopinto | gastons, home dirs should never be touched by a package install | 21:53 |
| gastons | omg yeah I get it | 21:54 |
| gastons | kk thanks all for clarifying this | 21:54 |
| joaopinto | you can also create a wrapper script | 21:54 |
| joaopinto | which creates the default config, and then runs the real command | 21:55 |
| lfaraone | Free motu around to merge bug 301190? (SRU, acked by ~ubuntu-sru) | 21:58 |
| ubottu | Launchpad bug 301190 in etoys "etoys does not launch" [High,Fix released] https://launchpad.net/bugs/301190 | 21:58 |
| ajmitch | to do a merge, or just upload the SRU to -proposed? | 22:00 |
| ajmitch | ah, using bzr branches for it | 22:01 |
| imbrandon | i should look into a bzr workflow | 22:02 |
| imbrandon | i always end up using so many RCS's though, i guess bzr-* plugins will help with that | 22:02 |
| * imbrandon is still doing alot by hand | 22:02 | |
| lfaraone | ajmitch: yeah :) | 22:04 |
| ScottK | ajmitch: Would you please look at 565781 for sponsor review? | 22:05 |
| lfaraone | ajmitch: merge the branch into lp:ubuntu/{jaunty,karmic,intrepid}/etoys and it'll be taken care of, apparently. | 22:05 |
| ajmitch | bug 565781 | 22:05 |
| ubottu | Launchpad bug 565781 in ipplan "FFE: ipplan incompatible with php 5.3" [Undecided,Confirmed] https://launchpad.net/bugs/565781 | 22:05 |
| lfaraone | imbrandon: it's *really* nice, IMHO. and yes, those plugins make life so much easier. | 22:05 |
| ajmitch | ScottK: ok, already had that one open | 22:05 |
| ScottK | ajmitch: Perfect. | 22:06 |
| ajmitch | lfaraone: I'm not familiar enough yet with the right procedures for sponsoring branches, I need to read up on it | 22:06 |
| ajmitch | ScottK: ipplan 4.92a-1 isn't showing up yet on ftp.debian.org, you may want to ping me about it in a bit | 22:08 |
| ScottK | OK. | 22:08 |
| * ScottK will try to rememver | 22:08 | |
| ScottK | v/b | 22:08 |
| ajmitch | ok, I can see it in incoming.d.o | 22:08 |
| persia | spy6 just uploaded a couple hours back. | 22:09 |
| lfaraone | ajmitch: https://wiki.ubuntu.com/DistributedDevelopment/Documentation/UploadingAPackage is the relevant page. | 22:10 |
| Laney | oh whoops, I've just run bzr merge in the past | 22:11 |
| lfaraone | james_w: if I understand that page properly, you have to dput *and* merge the branches? | 22:12 |
| Laney | yes | 22:12 |
| ajmitch | lfaraone: I don't think branch merging will do the upload of a source package just yet | 22:12 |
| lfaraone | ajmitch: I assume that's planned, though, right? | 22:12 |
| ajmitch | I think so, depending on the issues around trust paths, etc | 22:13 |
| ajmitch | the NoMoreSourcePackages spec has been around for awhile | 22:13 |
| lfaraone | Just do tag signing, and you should be good, no? | 22:13 |
| ajmitch | a lot of the stuff around build recipes is in place now, I think | 22:14 |
| ajmitch | someone like wgrant would know far better than I :) | 22:14 |
| persia | Would need someone to write a job in LP that did the branch->SPR translation bit as well as fixing all the authentication bits. | 22:14 |
| ScottK | You still have to upload. If you don't push the bzr bits back to LP, it takes them from the archive, so at this point all you lose is some possible bits of history in the merge detail. | 22:16 |
| * ajmitch waits oh so patiently for pbuilder update | 22:17 | |
| lfaraone | Do we consider SSH keys as secure as GPG keys? | 22:17 |
| lfaraone | if so, there's no problem, unless the LP box is compromised. | 22:18 |
| ajmitch | ssh keys are a different sort of beast, you don't get digital signatures with them | 22:18 |
| jdong | indeed there's no chain of trust either | 22:18 |
| lfaraone | jdong, ajmitch, but by simply being on the server, you have to know the person who pushed up the changes had access to the SSH keys in the LP account, no? | 22:19 |
| jdong | not necessarily | 22:19 |
| ajmitch | each source package has a gpg-signed file with the md5/sha-1/sha-256sums of the various source package components | 22:19 |
| jdong | that can be faked. | 22:19 |
| jdong | the bzr upload protocol lets me put in changesets that have your name on them. | 22:20 |
| jdong | and I'm pretty sure I can rewrite history too | 22:20 |
| ajmitch | bzr-rebase? | 22:20 |
| jdong | what you need is the testament signing form. | 22:20 |
| jdong | which, again, uses a GPG key :) | 22:20 |
| ajmitch | were there plans to gpg-sign every bzr revision? | 22:20 |
| lfaraone | jdong: ah, to prevent other accessors of ~ubuntu-branches from spoofing another's upload. | 22:20 |
| lfaraone | *members | 22:21 |
| jdong | amongst other things. | 22:21 |
| jdong | ajmitch: I sure hope so. | 22:21 |
| ajmitch | jdong: found a blueprint for it :) | 22:21 |
| jdong | ajmitch: otherwise I don't know how we can trust the authenticity | 22:21 |
| Laney | can't you sign a tag? | 22:21 |
| lfaraone | Laney: you can "Sign all commits by a given committer. | 22:22 |
| jdong | Laney: well yes, signing one revision does guarantee the state of the branch at that point | 22:22 |
| jdong | Laney: but what happens between tags is my concern | 22:22 |
| jdong | i.e. a blind bzr merge untrusted-branch can have some not-so-awesome consequences | 22:22 |
| Laney | responsibility of the uploader isn't it? | 22:23 |
| lfaraone | jdong: even if signed, a blind merge may pull in changes in between reviewing-code-on-web and merging. | 22:23 |
| lfaraone | jdong: so the uploader should of course review the diff :) | 22:24 |
| jdong | yes, indeed | 22:24 |
| Laney | why can't you branch and then merge from that? | 22:27 |
| ajmitch | sigh, OO.o uploaded, that'll kill buildds for a day or so :) | 22:33 |
| * ajmitch didn't do it, fwiw | 22:33 | |
| lfaraone | Laney: huh? | 22:40 |
| ajmitch | ScottK: ok, ipplan ACked, and I finally got back to pychecker | 22:41 |
| ajmitch | it's sad that I've pretty much doubled my karma in 1 week | 22:42 |
| wgrant | persia, ajmitch, lfaraone, jdong: So, we have recipe building pretty much implemented. There's just one or two backend bugs, plus the UI to sort out. | 22:58 |
| wgrant | The backend was actually mostly implemented at a sprint in January, but the other stuff is taking a while :/ | 22:58 |
| persia | wgrant: Thanks for the update. So it's close, but not there yet? Are we expecting that apt-get source will work to pull the current source from a bzr pushed build? | 23:01 |
| wgrant | persia: We may have it deployed for PPAs in LP 10.04. | 23:02 |
| wgrant | And yes, it uploads a source package just about as normal, so apt-get source will work. | 23:02 |
| persia | Nifty. I like having flexible systems that work both ways (so upload commits, and commit uploads). | 23:03 |
| ajmitch | the rcbugs list is depressing | 23:07 |
| persia | Why? Because it's long, or something else? | 23:08 |
| ajmitch | because it's long | 23:08 |
| ajmitch | plus I can see a few flaws in the versions where bugs are found | 23:09 |
| * ajmitch is just adding a few comments, in case someone wants to look further at packages on the list | 23:12 | |
| ScottK | ajmitch: Thanks. | 23:14 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
