[00:04] * sistpoty keeps on stepping people on the foot [00:29] we could switch MC applications to answers.launchpad.net which expires unanswered tickets after 15 days :P [00:32] Hello [00:32] Will Virtualbox 1.6 have a package for hardy? [00:34] bug 240856 [00:34] Launchpad bug 240856 in hardy-backports "Please backport virtualbox-ose 1.6.2 from Intrepid to hardy" [Undecided,New] https://launchpad.net/bugs/240856 [00:34] daskreech: ^ if that is approved, then yes (in the backports). So if you test it and give some feedback there, that would be appreciated [00:35] pochu: Oh you ^_^ [00:35] gracias [00:35] de nada :) [00:41] * sistpoty is off to bed... gn8 everyone [00:41] NIght [00:59] night. [01:06] emgent: have a beer in my name! [01:30] How does python library naming work? [01:30] there are lots of packages that are called python-pysomething [01:30] but then pycrypto is just called python-crypto [01:30] instead of python-pycrypto [01:33] "Public modules should be packaged with a name of python-foo, where foo is the name of the module." [01:33] So the module name of pycrypto is mere crypto [01:34] Did I get it right? [01:36] cyberix: right [01:36] if you do 'import crypto', then it should be python-crypto [02:29] Does anyone else here use cowbuilder and run into problems building multiple packages concurrently, it would appear that /var/lib/dpkg is shared amoung all running chroots, any ideas what I'm doing wrong? [03:01] hi stdin [03:01] Have you ever used quote ? [03:01] hey [03:01] don't think so, what is it? [03:01] Dunno just noticed it gets installed by default [03:02] on intrepid? (I have Hardy here) [03:02] On hardy [03:02] i think i have use it [03:03] it's just eastern egg [03:03] or something [03:03] nxvl: What is it for? [03:03] "which quote" shows nothing, probably a bash built-in [03:03] it's kind of fun [03:03] DaskreecH: tipe quote on the terminal [03:03] I know :) [03:03] type* [03:03] stdin: it's a function [03:04] ahh, I know what that is [03:04] is just to put quotes to a string [03:04] it's from bash_completion [03:04] ah ok makes sense now [03:05] (i was confusing it with other tool which just prints famus quotes on the terminal) [03:05] ok well what I was really here to ask about was a bug :) [03:05] https://bugs.launchpad.net/hardy-backports/+bug/240856 [03:05] Launchpad bug 240856 in hardy-backports "Please backport virtualbox-ose 1.6.2 from Intrepid to hardy" [Undecided,New] [03:06] What's the likelihood of that happening? [03:49] is there license issues with backporting 1.6.2 to hardy? === Gralco is now known as foo_ === foo_ is now known as Gralco_ [05:04] ScottK: I hope I did this right: I reset https://bugs.edge.launchpad.net/hardy-backports/+bug/240755 to confirmed to request a slightly newer version of the Intrepid package to replace the Wine backport [05:04] Launchpad bug 240755 in hardy-backports "Please backport Wine 1.0 from Intrepid to Hardy" [Medium,Confirmed] [05:49] I'm getting a "native-package-with-dash-version" error from Lintian [05:50] it was suggested that my package be named pyrocket-0.5-0ubuntu1 [05:50] Will this help?: http://lintian.debian.org/tags/native-package-with-dash-version.html [05:51] I've seen the error explanation, but I don't understand how to fix it [05:51] kostmo: You need an orig.tar.gz in the parent directory when you build the package. [05:52] e.g. pyrocket_0.5.orig.tar.gz [05:52] s/e.g./i.e./ (Oops) [05:52] so starting from a clean package build, should I actually run debuild twice? [05:52] Not usually, although it can help detect certain classes of bugs. [05:53] Typically, one just renames the upstream tarball. [05:53] I'm not sure how to generate the orig.tar.gz file, actually [05:53] I'm packaging up my own program, btw [05:53] kostmo: Download the tar.gz file from upstream. Rename it. [05:53] Ah. Therein lies the confusion :) [05:53] You'll want to wear two different hats, and think about the program two different ways. [05:54] Firstly, make a perfect version with no debian/ [05:54] Bundle that up into a tar.gz file and put it on the internet. [05:54] Next, rename the tarfile to orig.tar.gz, and add all the packaging information. [05:55] does it matter where (or at all) I put it on the internet? [05:55] Then, when you run debuild -S, you'll get a diff.gz with the packaging, and a .dsc. [05:55] It doesn't matter where you put it. People tend to put them on the project homepage, and host them on the same service that hosts the code. [05:56] You want to have an internet-accesible archive of releases so you can construct a working watch file, to provide notification when the version in the distribution differs from the version upstream. [05:56] ok, so the orig.tar.gz doesn't have to have any kind of installer (i.e. more like a fend-for-yourself piece of code)? [05:56] As your project grows, you probably won't have time to focus on both packaging for each distribution and doing all the upstream work: creating this separation of concerns early makes that transition easy later. [05:57] Well, your life will be easier if your setup.py takes an install argument for a raw install. [05:57] ok [05:57] But no, no nice packaged installer to integrate with the distribution. [05:58] You'll likely want a slightly different set of packaging information to be able to integrate into each of Debian, Ubuntu, Fedora, SuSE, slackware, etc. [05:59] under what circumstances would the distribution's version differ from my upstream version? [05:59] i.e. why do I need a 'watch' file? [06:00] kostmo: Well, firstly getting new upstream versions into released stable distributions is hard, so most distributors aren't likely to do that. [06:00] Secondly, as the number of distributions that packages pyrocket grows, you may not be watching them all, so it helps to have automated notification when there is a new upstream, for those packaging the updates for the given distribution. [06:01] YokoZar: Generally one files a new bug, but I think that will work. Is it really worth another backport? [06:03] so the effectiveness of this watch file depends on having a stable URL for the upstream code? [06:03] ScottK: Well if the backported one is going to be SRUed, then I think so. The changes to the .desktop file to make it say "Wine Windows Program Loader" instead of "Wine Windows Emulator", but more importantly it also adds an association for .msi files. If we also update shared-mime-info, then users will be able to double click msi files. [06:03] OK. Sounds reasonable. [06:04] I hadn't considered starting a sourceforge project, but I guess I could [06:04] * cody-somerville disturbingly just realizes he missed the MOTU-SRU meeting. [06:08] cody-somerville: It's important to stay on top of these things :) [06:09] ScottK, how did it go? [06:10] IIRC it went fine. [06:10] It's very late here and I'm not entirely awake. [06:10] Ask me again tomorrow. [09:50] hey, how is it possible that in REVU several packages have an empty Lintian file, while running Lintian gives lots of errors/warnings? I uploaded a package, and its Lintian file was correctly generated, but in other cases (e.g: http://revu.ubuntuwire.com/details.py?package=playonlinux, http://revu.ubuntuwire.com/details.py?package=gedit-regex-plugin), it didn't happen [09:53] tooba1: my guess would be different versions of lintian [09:54] there are HUGE differences! [09:54] but, principally, the point is: [09:54] isn't the file automatically generated on server? So where would be the different Lintian versions? [09:56] the file is generated on the server, but I don't know which lintian version is there installed [09:56] if you run lintian on your system you might use a different version [09:57] and it also depends if you run lintian on the source package or on the binaries (debs) [09:57] revu checks only the source package [09:57] ok, I get it. Anyway, this is very strange, since there are a lot of things missing, so I think it's more probable that it's run with lots of "exclude" arguments (on the server) [09:58] the server doesn't have the binaries, as I see [09:58] I think it checks the ".changes", as I do [09:59] geser: I installed the latest backported lintian about a week ago - it definitely supports 3.8.0. [09:59] tooba1: then playonlinux and gedit-regex-plugin are lintian clean (at least the source packages) [09:59] tooba1: We can't risk building the packages, so we don't run it on binaries. Just sources. [10:00] wgrant: right. But running "lintian xyz.changes" means checking sources, right? [10:00] If it's a source-only changes, yes. [10:01] morning [10:01] well... I thing that looking at http://revu.ubuntuwire.com/details.py?package=gedit-regex-plugin, you'll get the point. The "lintian" is empty, I attached a lintian report [10:01] Hi emgent [10:01] they're all source changes, obviously [10:01] geser :) [10:01] (right?) [10:01] And it indeed runs on the .changes. [10:02] wait [10:02] All of those are binary issues. [10:02] here's a more interesting example [10:02] Except for the lack of intrepid. [10:02] exactly that [10:03] Your lintian is broken and/or out of date. [10:03] tooba1: you can also run lintian just on the .deb or the .dsc [10:04] I get it [10:06] It would be optimal to automatically build each upload, but that would imply development of a virtualised building infrastructure. [10:06] ok [10:07] wgrant: doesn't revu run on a sparc machine? so it isn't the fastest either for building packages [10:08] but it's awful that lintian is not able to spot changes that ARE in the source files... [10:08] It's a 5 year old UltraSparc III, right. [10:08] anyway, [OT] [10:08] tooba1: It is... [10:08] thanks for the clarifications [10:08] tooba1: What didn't it pick up? [10:11] package-contains-empty-directory, readme-debian-contains-debmake-template, copyright-lists-upstream-authors-with-dh_make-boilerplate, copyright-without-copyright-notice, extended-description-is-empty, section-is-dh_make-template, script-not-executable, binary-without-manpage, extra-license-file, extended-description-line-too-long, unknown-section, python-script-but-no-python-dep [10:11] (in just 2 packages :-) [10:11] The second, third and fourth could be picked up, but the rest are binary issues. [10:12] yep [10:13] no wait, why not "extended-description-is-empty"? [10:13] Because that's a binary attribute. [10:13] Though you should in general be able to check that in debian/control. [10:14] I don't believe it's required by policy, though. [10:14] aha [10:29] hi all. [10:30] I'm trying fix some issues in my package. What's binary-arch-rules-but-pkg-is-arch-indep ? can I make a package for 'all' arch? [10:32] k0p: That is a report that it appears debian/rules is calling the binary-arch target even when the package is architecture-independent. You likely want to check the rules structure carefully. `make -p -f debian/rules` may help, although it may confuse. [10:34] persia, really nice. thanks for the help. [10:34] :) [10:35] k0p: You may find that running lintian -iIv is more informative than lintian alone, for these expansions to be automated. [10:36] persia, gh. I don't know the lintian command [10:36] thanks :D [10:37] persia, one more question [10:37] the package on revu only have comment when does it have errors? [10:39] I considered packaging Astro Chicken, but then I changed my mind -> http://cs.helsinki.fi/u/twruottu/ss/astro_chicken.png [10:40] And no, I don't have a written permission to publish this screen shot [10:44] k0p; the package has comments when someone commented it :-) [10:44] it may have errors nobody noticed [10:44] it may have comments not regarding errors [10:45] tipically, the only systematic method of finding (many) errors if lintian [10:45] you build your package, then run "lintian nameofthepackage.changes" [10:45] hmm yeap.. now I understand. I don't need upload to see the lintian file [10:45] lol [10:48] right... [10:48] moreover, the lintian file you see when you upload shows a very small part of the potential errors, because it runs on the package not compiled [10:48] bye [10:49] k0p: Congrats. You are one step closer to being a perfect packager. [10:49] lol [10:49] cyberix, so far... [10:50] k0p: Not that far. It seems you found revu. Now you are getting one step closer every day. [10:52] I would like that my package should be able in 8.10 [10:52] may be it not possible, right? [10:52] is it late? === doko_ is now known as doko [10:53] k0p: It is still possible [10:53] https://wiki.ubuntu.com/IntrepidReleaseSchedule [10:53] k0p: k0p You should get it in before FeatureFreeze [10:54] (sorry for two nicks) [10:54] :-P [10:54] hehe [10:54] :) [10:54] 28 th august right? [10:54] getting it in means that you must get two sponsors in revu and get someone to upload it before the FeatureFreeze [10:54] yes [10:55] yeah ... but I don't have sponsors .. not yet :) [10:55] i'm fixing issues on my package [10:55] Of course the package may be sent back to revu, if there is some big problem with it [10:55] But revu is trying to make sure there is nothing wrong with it before it gets uploaded [10:55] hmm of course [10:56] There is one revuday each week [10:56] cyberix, but in revu nobody make package.. only make sources [10:56] really? [10:56] That is the day when you are supposed to ask sponsors [10:56] I don't understand so much . .revu is compiling ? [10:56] build packages? or what's that? [10:56] no [10:56] reviewing [10:57] so, if you want to be efficient you should fix all reported issuesduring the week between revu days, so you can ask for sponsors on each revu day [10:57] you can only ask for sponsors, if you have fixede all reported problems [10:58] hmm [10:58] yeah [10:58] then it is likely that someone looks at your package and reports more problems [10:58] what the day of revu? [10:59] so may be in next week my package found a sponsor? [11:00] In theory yes, but if you are very new at packaging you'll probably get error reports instead [11:00] :-) [11:00] revu day is announced in the topic of this channel [11:01] I'm not sure which weekday it currently is [11:02] cyberix, well .. I have 4 Errors and 2 Warnings... [11:03] humans can usually find more errors than lintian :-) [11:03] cyberix: There isn't one at this time. [11:03] but ofcourse it makes no sense to ask humans before you have fixed the easy ones [11:04] wgrant: How is that? [11:04] cyberix, of course. [11:04] cyberix: Nobody is running REVU days. [11:04] wgrant: Each day is a "revu day" then? [11:05] I guess that each day is equally REVU-friendly, perhaps. [11:05] cyberix, in changelog.. intrepid is a versiong right? [11:05] I suppose revu days appear closer to release when people are busy [11:05] k0p: interpid is the codename for Ubuntu 8.10 [11:06] k0p: So, you are working with the Umit package? [11:06] yeap [11:06] how you guess? [11:06] packager email address sounded similar to your (nick)name [11:07] is intrepid or interpid? [11:07] yeah [11:07] :) [11:07] intrepid [11:07] hmm [11:07] http://en.wiktionary.org/wiki/intrepid [11:08] Does Umit depend on nmap or is it standalone? [11:08] depend of nmap [11:09] may be the error about bad-distro-name is because I don't have 8.10 installed.. I have 8.04 [11:10] I think my 8.04 didn't complain about intrepid [11:11] hmm [11:12] cyberix, umit (0.9.5-ubuntu1) intrepid; urgency=low [11:12] looks like fine? [11:15] I think the version number should be 0.9.5-0ubuntu1 [11:16] but ofcourse you have to make that change to each place where you specify the version number [11:17] right [11:18] k0p: Ok. I get the bad distro name error too [11:18] so it should be ok [11:18] is n't 0.9.5-0ubuntu1? [11:19] cyberix: One only specifies the version number in a single place unless one is doing strange things that shouldn't be done. [11:20] wgrant, but the trouble is in intrepid :/ [11:20] Oh I forgot [11:20] k0p: Install lintian from hardy-backports. [11:20] wow [11:20] Online it don't appear [11:20] Hm? [11:20] I don't have one error and one warning [11:21] Because they have a newer version of lintian there [11:21] Online where? [11:21] wgrant, revu [11:21] revu of course [11:21] On REVU? I upgraded lintian there last week. [11:21] wgrant, yeah.. I'll update lintian from backport [11:21] thanks for the help [11:21] :) [11:21] np [11:21] k0p: You should till change the version number to 0.9.5-0ubuntu1 [11:22] That is something lintian won't warn about [11:22] It should, though. [11:22] Well, lintian doesn't report Ubuntu specific stuff, right? [11:23] cyberix: It doesn't, but it might be nice if it did. [11:27] k0p: I'm happy to see that someone is trying to package umit for Ubuntu. [11:28] k0p: I recall I wanted to try it out sometime, but didn't because there was no package. [11:28] cyberix, I already make one package [11:28] well.. We're working hard to release stable version [11:28] before august [11:29] after that we need to merge lot of features that was develpmenting in other branches. [11:29] You just have to figure out which version of nmap will ship with intrepid [11:29] cyberix, it isn't a problem [11:29] >=4.50 [11:29] right? [11:30] sure [11:30] :) [11:30] btw specify the version requirement only, if umit really doesn't work well with older versions of nmap [11:31] I have a working about native-package-with-dash-version [11:31] hmm ok [11:31] give me a second [11:32] umit working nice with older version. . 4.20 it's nice. but I don't have totally sure about that [11:32] i'll verify it [11:32] You can just say nmap in dependencies, without a version requirement [11:32] If upstream tells you not to use versions older than x, then that is valid reason for setting the requirement. [11:32] cyberix, I do it [11:33] ok [11:33] Now I have to do some household hacking [11:33] :-D [11:33] hehe :) [11:33] See you later, and good luck with the project [11:33] good luck [11:33] thanks a lot for your help [11:34] no problem === fta_ is now known as fta === LucidFox is now known as LuciusFox === LuciusFox is now known as LucidFox === clifford is now known as yrjokin [13:52] Hello. could some review those: http://revu.tauware.de/details.py?package=ubuntume-gdm-themes , | [13:52] http://revu.tauware.de/details.py?package=usplash-theme-ubuntume [13:54] AnAnt: I'm going to discourage the use of REVU for package updates (like those), as they have an even greater chance of being ignored than other things on REVU. [13:54] That said, looking now. [13:54] persia: errm, I don't understand [13:54] persia: I mean, how would package updates be reviewed then ? [13:55] AnAnt: REVU is for new packages, not already in the archives. For updates to packages already present, submitting a diff as a bug is preferred. [13:56] ok [13:56] Mind you, for native packages, this doesn't always work, and you'll have to submit the entire tar.gz (which is part of why I don't like native packages). [13:57] AnAnt: Anyway, I know you, and know you maintain these packages, and know that they likely ought get updated, so unless I can find something extra wrong, I'll upload them this time: just please use a bug to update them in the future. [13:57] sure thing [13:57] thanks [13:58] persia: btw, regarding webstrict, the maintainer is trying to get it in Debian [13:59] persia: anyways, he'll need to make changes, seems that debian don't have openjdk yet [14:00] persia: oh, for java based software, should the package build-depend on openjdk or on default-jdk [14:00] AnAnt: Ah. Right. I think there was an effort to do that. You might ask on #debian-java on OFTC to check the current status. [14:00] That said, if it can build on gcj, that would be far preferable. [14:02] persia: how about default-jdk ? [14:03] persia: btw, thanks for the link ! === effie is now known as effie_jayx [14:38] cyberix, are you there? [14:42] k0p: It's generally best to ask your questions and look for whoever is about to answer: you may need a specific person, but even then, telling them what you seek can help them form an answer when they return, in case you are not watching at that moment. [14:43] k0p: I'm here [14:44] k0p: I'm having a coffee break from household hacking [14:46] is DBus part of Gnome? [14:48] bliZZardz: I think it's idenpentant of the DE: http://www.freedesktop.org/wiki/Software/dbus [14:48] bliZZardz: GNOME relies on DBUS, but other things do as well. Why? [14:50] persia : bon jour! well, i was just exploring DBUS, hence curious to understand it - was not sure whether it is 'still' being used [14:50] bliZZardz: It is very much in use. [14:50] persia : any good place/link to understand GNOME better(except for the code:P ) [14:51] bliZZardz: gnome.org? [14:51] That said, I think the code is better: I'd recommend looking at session, panel, and menus primarily. [14:53] persia : any specific reasons for that rationale? [14:57] bliZZardz: I found it more useful? [14:59] persia : useful as in??? gtk code that can be used in other ways? [14:59] persia, ok. [14:59] sorry [15:01] i'm trying to solve native-package-with-dash-version warning. it's cause is set as debian native package? I would like know how solve this [15:01] bliZZardz: Useful in understanding how GNOME works. For GTK code, look at your favorite GTK application. [15:01] k0p: You need an orig.tar.gz file. Then rebuild. That's it. [15:02] persia, just make a rename? [15:03] Right. rename the upstream tar.gz file to match the naming convention for orig.tar.gz, and you should be good. [15:06] persia, thanks. silented this warning [15:07] persia : you know of any channels/forums wherein i can application deisgn questions/queries? [15:10] bliZZardz: I don't. Sorry. === greeneggsnospam is now known as jsgotangco [16:12] Could someone review my package? http://revu.tauware.de/details.py?package=monkeystudio Thanks ;) [16:16] hi folks [16:16] huhu sistpoty [16:16] hi sebner [16:19] * sistpoty reboots again, and hopes to be right back *g* [16:20] reboot? what does this word mean? [16:28] * sistpoty grumbles a little bit about being forced to use the nv driver instead of the blob [16:29] sistpoty: you too? ^^ [16:29] yep [16:29] sistpoty: kernöl? [16:30] sebner: 2.6.26-2-generic [16:30] (lrm doesn't seem to contain nvidia blob any longer... /me wonders where it went) [16:30] sistpoty: kay. though also compiling and using that thing on the old 2.6.24 kernel isn't working :( [16:30] sistpoty: Which version of libdrm do you have? [16:30] * DRebellion gumbles a little bit about never getting a review :P [16:31] persia: 2.3.0-4ubuntu1 [16:31] Oh well. No nouveau either then [16:31] DRebellion: Yeah. This cycle has been weak on reviews. Sorry about that. [16:32] persia, by cycle, do you mean up to alpha1? [16:34] DRebellion: I mean intrepid [16:34] oh, right [16:34] = [16:34] =( === LucidFox__ is now known as LucidFox [17:04] <\sh> sebner: do you want to work on an SRU? [17:05] hey all, I have uploaded my package to REVU, am I supposed to get an e-mail with login information? Package is here: http://revu.ubuntuwire.com/details.py?upid=2611 [17:10] \sh: depending on how urgent it is since today I haven't got really time to work on it but tomorrow [17:10] kostmo: just try to log in with your email address and give no password, then there'll be a "recover password" link [17:11] <\sh> sebner: bug #241587 check the debdiff [17:11] Launchpad bug 241587 in claws-mail "bugfix batch for Hardy's Claws Mail" [Undecided,New] https://launchpad.net/bugs/241587 [17:11] <\sh> sebner: check if it works on hardy etc :) [17:14] \sh: so many patches to test O_o . I never used claws mail so I have to waste time for setting it up correctly and test then every patch? [17:15] <\sh> sebner: no..the patches are coming from upstream.... [17:16] <\sh> sebner: just make a "run test" the more in-deep testing we are doing via -proposed [17:16] \sh: ah ^^ kk. ok if tomorrow? [17:16] <\sh> sebner: I trust upstream in this..colin was very helpful... [17:16] <\sh> sebner: sure :) [17:17] \sh: np, Will do and ping you tomorrow about it then [17:17] <\sh> sebner: I'm busy with leonov release tomorrow and in the evening I'm watching EM finals ;) [17:18] \sh: bah! but me too. except the leonov thing xD === asac_ is now known as asac === asac__ is now known as asac [18:48] doko: ok if I grab crystalspace merge from you? [18:51] johanbr: looking at the empathy buildlog would have shown you that it failed because some packages it relies on were broken at the time it was built [18:57] Lutin: Right. Do you know if those packages have been fixed? [18:57] sistpoty, devfil was looking at it, he should have a debdiff ready [18:58] DktrKranz: ah, thanks... didn't find a bug on lp, so I assumed it wasn't taken yet [18:58] johanbr: I gave it back on i386, built fine, waiting for it to go through NEW [18:59] DktrKranz: and just in time... as at this moment dl of the source packages finished *g* [18:59] heh [18:59] Lutin: Alright. Thanks. [18:59] sistpoty, FYI bug 242961 [18:59] Launchpad bug 242961 in crystalspace "Please update crystalspace to 1.2.1" [Undecided,Confirmed] https://launchpad.net/bugs/242961 [19:00] DktrKranz: ah... I guess I was confused that the title didn't contain "merge" *g* [19:01] Can someone please help with an (apparently) difficult question on the appropriate version number to assign to a package to be uploaded as a stable release update? [19:01] sistpoty, probably because he was trying to get package in shape again, since it requires much love [19:01] and I guess merge is not enough :P [19:01] sistpoty: in Debian package fails to build, I've merged it and updated it to the latest version [19:06] There's a significant bug in the package which is currently in hardy (version 0.25-0ubuntu1) which has been fixed by a new upstream release which is now in intrepid as 0.26-0ubuntu1. What should the version number be for the hardy release of 0.26, since 0.26-0ubuntu1 is already taken by the intrepid release, and 0.26-0ubuntu2 incorrectly implies that it follows the intrepid release? [19:07] guest22, 0.26-0ubuntu1.1 [19:07] mh... no, I misread [19:08] 0.25-0ubuntu1.1 should fit [19:09] DktrKranz: But the new release for hardy would be based on 0.26 upstream, so surely 0.25-xxx is incorrect? [19:10] guest22: 0.26-0ubuntu0.1 [19:10] guest22, if new upstream release is a bugfix release, you can use 0.26-0ubuntu1~hardy1 [19:11] devfil and DktrKranz: any suggestions on which is preferred, 0.26-0ubuntu0.1 or 0.26-0ubuntu1~hardy1 (yes, it is a bugfix release)? [19:12] guest22: ~hardy1 [19:13] devfil and DktrKranz: OK, thanks to both of you for the advice. One additional question: the wiki at https://wiki.ubuntu.com/StableReleaseUpdates mentions uploading to release-proposed, but doesn't give any more details. Do I just do dput to hardy-proposed? If so, where do I find the dput config for this upload target? [19:13] guest22: in changelog use hardy-proposed [19:14] guest22, just attach a debdiff for hardy-proposed to a bug report, subscribe motu-sru for approval and wait for sponsors to upload package for you. [19:15] DktrKranz: Ah, so I just ignore the additional instructions at the StableReleaseUpdates wiki, eg. "4. Upload the fixed package to release-proposed with the patch in the bug report ..."? [19:15] guest22, yes. This is managed by developers who have upload rights. [19:16] as much as following steps [19:17] DktrKranz: OK, thanks. It really would be useful to have better documentation for package maintainers so that one doesn't have to clarify everything on IRC. [19:19] Apologies for the heresy, but the Fedora people really are ahead in this respect. [19:19] guest22, it's a work in progress, We hope to have something better soon. [19:20] DktrKranz: Sure, I understand. [19:20] thanks for bringing us bugfix releases :) [19:26]