| ScottK | webtech_m33: clamav doesn't support external scanners like used the --unrar option any more. Because of the licensing of the unrar code in clamav, we can't ship clamav with unrar. | 00:01 |
|---|---|---|
| tdomhan | should mentors.debian.net uploads and/or ITP bugs be linked in the launchpad needs-packaging bug? | 00:02 |
| sistpoty | tdomhan: right about autotools-dev :) | 00:05 |
| sistpoty | tdomhan: and yes, there's no problem with debhelper/dh_compat for bot-sentry ;) | 00:05 |
| tdomhan | sistpoty: ok thank you for reviewing | 00:07 |
| sistpoty | tdomhan: thanks for your interest in improving ubuntu ;) | 00:07 |
| sistpoty | tdomhan: and sorry, I meant to advocate bot-sentry, but must have clicked wrongly ;) | 00:08 |
| tdomhan | sistpoty: the icon here says that you advocated | 00:09 |
| === asac_ is now known as asac | ||
| sistpoty | tdomhan: well, I just added the advocation actually ;) | 00:09 |
| tdomhan | sistpoty: ah I see, ok ty ;) | 00:10 |
| * sistpoty is off again... cya | 00:19 | |
| handschuh | it is still friday somewhere, right? Could anyone check the get-orig-source rule of http://revu.ubuntuwire.com/details.py?package=libballoontip-java ? | 01:00 |
| dmoerner | hi, i just got an email from launchpad that this has happened to an autobuild of my package: http://launchpadlibrarian.net/19641953/buildlog_ubuntu-hardy-amd64.pekwm_0.1.8-1ubuntu1_CHROOTWAIT.txt.gz | 01:57 |
| dmoerner | isn't this a problem on launchpad's end? | 01:57 |
| wgrant | dmoerner: Yes - chroot problems are never the package's fault. | 02:01 |
| wgrant | Well, they are never *that build's* fault. | 02:01 |
| wgrant | I'll retry that build, as it got caught in the archive sync race. | 02:01 |
| dmoerner | i thought it was for a package i maintain in debian that was being built in jaunty, which would be a real bug | 02:02 |
| wgrant | Oh, it's in a PPA? | 02:02 |
| dmoerner | it's actually for my ppa so i don't really care | 02:02 |
| dmoerner | yeah | 02:02 |
| wgrant | Right. | 02:02 |
| wgrant | If you retry it, it will work fine. | 02:02 |
| dmoerner | yes i will do that later tonight. thanks. | 02:02 |
| wgrant | (you just have to click 'Retry build', not reupload) | 02:03 |
| === gouki_ is now known as gouki | ||
| === kc8tad is now known as rrittenhous | ||
| AnAnt | Hello, I have prepared a new package that adds support for DKMS, what should I do ? I understand that I will file a bug against sl-modem, and attach the debdiff, but is there something else to do? subscribe someone or add some tags ? | 04:03 |
| cody-somerville | I'm pretty sure we already have support for DKMS. Thanks anyhow. | 04:05 |
| AnAnt | cody-somerville: in sl-modem ? | 04:05 |
| ScottK | cody-somerville: In sl-modem? | 04:05 |
| ScottK | ;-) | 04:05 |
| === kc8tad is now known as rrittenhouse | ||
| AnAnt | cody-somerville: no, it doesn't I know that ! | 04:06 |
| cody-somerville | Lies. | 04:06 |
| AnAnt | cody-somerville: sl-modem was just sync'ed from Debian, the Debian package doesn't support DKMS | 04:06 |
| AnAnt | so, can someone answer my question ? | 04:07 |
| cody-somerville | https://wiki.ubuntu.com/SponsorshipProcess | 04:08 |
| jdong | ooh I see we got shiny new fglrx in intrepid. | 04:11 |
| AnAnt | ok, here it is: bug 298273 | 04:21 |
| ubottu | Launchpad bug 298273 in sl-modem "Add DKMS support to sl-modem" [Undecided,New] https://launchpad.net/bugs/298273 | 04:21 |
| ethana2 | It seems the debian maintainer for the package that I built for 8.10.. well | 04:44 |
| ethana2 | I hope he's not dead, but I have no way to tell | 04:44 |
| ethana2 | in any case, I'd like to move the package from my PPA to REVU, do I need to re-upload, or is this something that can be done mainly just on launchpad? | 04:46 |
| Hobbsee | i think there is an importer, but don't know the details. ncommander would, though | 04:46 |
| hyperair | ethana2: so you managed to get it uploaded after all? | 04:47 |
| ethana2 | hyperair: yep | 04:48 |
| hyperair | ethana2: dput revu something | 04:48 |
| hyperair | revu isnt connected with the ppas | 04:48 |
| ethana2 | ah, ok | 04:48 |
| hyperair | you'll need to add stuff to .dput.cf though | 04:48 |
| ethana2 | k | 04:48 |
| * ethana2 opens ~/.dput.cf | 04:48 | |
| wgrant | And you'll need to log into REVU first. | 04:48 |
| ethana2 | uh | 04:48 |
| ethana2 | do I have to have another account? | 04:48 |
| hyperair | no | 04:48 |
| wgrant | Go and see. | 04:49 |
| hyperair | it's the same as your launchpad account | 04:49 |
| hyperair | you log in with your launchpad openid | 04:49 |
| jdong | ha! Firefox, I WIN. | 04:50 |
| * jdong disabled fsync and sync. no more bookmark hangs. | 04:50 | |
| wgrant | jdong: Ooh, where'd you disable that? | 04:52 |
| ethana2 | ok, logged into REVU | 04:53 |
| hyperair | jdong: i want! | 04:53 |
| wgrant | ethana2: You can now upload. | 04:53 |
| ethana2 | wgrant: do I need to add something to .dput.cf ? | 04:53 |
| wgrant | ethana2: Yes. | 04:53 |
| wgrant | !revu | 04:53 |
| ubottu | REVU is a web-based tool to give people who have worked on Ubuntu packages a chance to "put their packages out there" for other people to look at and comment on in a structured manner. See https://wiki.ubuntu.com/MOTU/Packages/REVU | 04:53 |
| ethana2 | k | 04:53 |
| jdong | wgrant: a LD_PRELOAD library http://www.flamingspork.com/projects/libeatmydata/ | 04:54 |
| ethana2 | Since Ubuntu 6.06 LTS (Dapper Drake), dput is already configured for REVU uploads, with the [revu] entry. | 04:54 |
| jdong | basically you shove it to the process you want via LD_PRELOAD and it simply contains a empty sync and fsync call. | 04:54 |
| wgrant | jdong: Ah. I like that name. | 04:54 |
| jdong | I don't think it's entirely crackful to do as long as you don't, say, do it with your text editor :) | 04:54 |
| ethana2 | ethan@home:/var/cache/pbuilder/result$ dput revu *source.changes | 04:55 |
| ethana2 | Assuming i clear out that directory after every new build, is that command correct? | 04:56 |
| * ethana2 runs | 04:57 | |
| ethana2 | ah, right on that page there, sorry | 04:58 |
| ethana2 | oh, blehh, there I go again, that'-- *shuts up* | 05:01 |
| jmarsden | What is the package name in Intrepid that adds mod_security (for apache2) ? Used to be libapache2-mod-security ?? | 05:14 |
| wgrant | jmarsden: It's non-free. So it's not in Debian, nor Ubuntu. | 05:28 |
| ethana2 | medibuntu? | 05:28 |
| jmarsden | Even after http://blog.modsecurity.org/2008/06/modsecurity-lic.html | 05:28 |
| jmarsden | Looks like they changed the license specifically to try and make it sufficiently free? | 05:29 |
| wgrant | WTF | 05:30 |
| wgrant | That's non-free. | 05:30 |
| wgrant | You can't make derivatives with that same license. | 05:30 |
| wgrant | That is either deliberate or particularly impressive failure. | 05:32 |
| jmarsden | I'm no licence lawyer... sounds like they should run their ideas by debian-legal? | 05:33 |
| wgrant | Hmm. It's a very confusingly worded exception. | 05:34 |
| wgrant | Even for legalese... | 05:34 |
| jmarsden | Is there some way to get an "official" ruling on it? In reasonably finite time? | 05:36 |
| wgrant | debian-legal | 05:36 |
| jmarsden | OK. | 05:36 |
| wgrant | Ew. | 05:38 |
| jmarsden | Hmmm. Someone beat me to it... http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=487431 | 05:38 |
| wgrant | One has to distribute source on the same medium. | 05:38 |
| ubottu | Debian bug 487431 in wnpp "ITP: libapache-mod-security2 -- Tighten web applications security" [Wishlist,Open] | 05:38 |
| wgrant | How stupid. | 05:38 |
| wgrant | Source for everything linked to it. | 05:39 |
| persia | Not entirely stupid, just not in alignment with modern practices. | 05:39 |
| wgrant | It also seems you can't distribute a modified version of the Program under the exception. | 05:40 |
| wgrant | So AFAICT they have utterly failed. | 05:40 |
| wgrant | Oh. | 05:41 |
| wgrant | Hmmm. | 05:41 |
| jmarsden | The author seems to think they do allow that... per his 03 July comment to http://blog.modsecurity.org/2008/06/modsecurity-lic.html | 05:43 |
| wgrant | Given one of the comments, perhaps they mean that derivatives have to be available without the GL2. | 05:43 |
| wgrant | Er. | 05:43 |
| wgrant | With only the GPL2. | 05:43 |
| wgrant | As well as perhaps in a version with the exception. | 05:43 |
| wgrant | Yes. | 05:43 |
| wgrant | persia: What do you think about that bit? | 05:43 |
| * persia reads the relevant language more carefully | 05:45 | |
| persia | I think that the license exception would allow distribution in non-free or multiverse under a no-patch model. By my reading, it cannot both be patched and used with Apache. | 05:49 |
| persia | That said, the argument for inclusion isn't convincing enough to me that I'd want to ship it in multiverse, as ModSecurity is bound to get a CVE at one point, and we couldn't patch it. | 05:49 |
| wgrant | Right. | 05:50 |
| persia | On the other hand, if Breach Security were to come to Ubuntu and ask for inclusion, and promise the same sort of active response we have for e.g. Mozilla, I'd not object to them participating, with removal to be expected as soon as they stop. | 05:51 |
| persia | In this case, it doesn't really matter who acts as counterparty, as long as there is an actionable contract that such updates will be provided under a license that permits shipping them. | 05:53 |
| === kc8tad is now known as rrittenhouse | ||
| gouki | I have the following makefile (http://paste.ubuntu.com/72224) and pbuilder is falling because of permission denied (error output: http://paste.ubuntu.com/70859). I was told the problem is in the makefile, but I should not touch the makefile. | 05:55 |
| persia | To me the issue is that it's not possible to both ship under the Apache Software License and obey the GPLv2 in all respects for the Program and Derivative work. | 05:55 |
| gouki | Any ideas? (sorry for the double line). | 05:55 |
| wgrant | I think it's pretty impressive. | 05:55 |
| Hobbsee | persia: that would be a pain for stable releases and such | 05:56 |
| persia | gouki, patch the Makefile to use DESTDIR rather than /usr/bin in install: | 05:56 |
| persia | Hobbsee, which? | 05:56 |
| Hobbsee | persia: removals, if we were forbidden from patching it | 05:57 |
| Hobbsee | (and Breach Security wasn't active) | 05:57 |
| persia | Hobbsee, Right, which is why it would only be acceptable to me to put it in multiverse if there was an actionable contract under which updates were provided. | 05:57 |
| gouki | persia, thank you (/me never created a patch). Any pointers? | 05:57 |
| wgrant | I wonder if they did this deliberately, or if they managed to accidentally make their license broken in two ways. | 05:57 |
| persia | Yeah, well, as with all contracts, it assumes all parties will remain extant. | 05:58 |
| Hobbsee | persia: my thought was more "what happens if they break their contract, in the context of released releases?" | 05:58 |
| persia | Hobbsee, The counterparty approaches them regarding the breach of contract. Standard tort law applies. | 05:58 |
| * Hobbsee didn't think we did removals from stable releases, at all...unless the standard tort law says that we patch it, in that case? | 05:59 | |
| persia | It would be a fairly clear violation of DFSG 8, but that's why it would be in multiverse. | 05:59 |
| persia | Hobbsee, It only says to follow terms of the contract. That would be an important clause to add in the contract between Breach Security and whoever was the counterparty. | 06:00 |
| Hobbsee | persia: ah, right, i see. | 06:00 |
| persia | (well, there are other provisions to e.g. prevent indentured servitude, in most jurisdictions, but we can mostly ignore those) | 06:00 |
| wgrant | Anyway, we can probably assume that this license is a big mistake and that they really intend to make their software usable. | 06:00 |
| jmarsden | It seems the previous packager of mod_security thinks this is "coming soon": http://lists.debian.org/debian-security/2008/09/msg00071.html | 06:01 |
| persia | wgrant, Entirely :) The Intent section makes that very clear. | 06:01 |
| wgrant | Unfortunately the last thread on debian-legal didn't get any replies. | 06:01 |
| wgrant | So upstream probably doesn't know that their license is borked. | 06:01 |
| persia | Well, it's sufficient to provide one-off distribution. | 06:01 |
| persia | It's just not sufficiently flexible to provide for security support unless Breach is tracking specific distros. | 06:02 |
| persia | If their code has no bugs, it's fine. | 06:02 |
| * jmarsden just added a comment to that blog post, pointing at the Debian ITP bug and asking for status... | 06:02 | |
| persia | (well, fine doesn't mean DFSG-free, but acceptable for multiverse) | 06:03 |
| gouki | PackagingGuide doesn't seem to talk much about patching the makefile :S | 06:05 |
| persia | gouki, It's not any different than any other patch to upstream. | 06:05 |
| persia | Use the same methods you'd use to patch other source files. | 06:05 |
| gouki | I have no idea of how that is done. Do you have some URLs about it to share, persia? | 06:05 |
| persia | So, depending on how you're doing it, that might mean carrying the diff in a VCS branch, in a patch system, or similar. | 06:06 |
| persia | https://wiki.ubuntu.com/PackagingGuide/Complete#Patch%20Systems | 06:07 |
| gouki | Thanks | 06:07 |
| persia | gouki, Note that patching without a patch system is not recommended unless you are maintaining the packaging in a VCS, as it makes it hard to unwind things later. | 06:07 |
| gouki | persia, the need for me to read about bzr arrives :( | 06:08 |
| persia | gouki, Only if you wish. dpatch, quilt, and simple-patchsys remain popular as well. | 06:09 |
| gouki | Ohh, OK. Thank you persia. | 06:09 |
| hyperair | persia: besides those three, are there any more? | 06:09 |
| persia | hyperair, There's the example of calling patch manually in the patch system guide, but I personally don't like it very much. There's the flexibility to use any method of applying patches you like, and some experimentation, but those three are the primary patch systems in use. | 06:10 |
| hyperair | ah i see | 06:11 |
| hyperair | well i like quilt =p | 06:11 |
| persia | hyperair, Then you should use quilt. | 06:12 |
| hyperair | yeah i do, but sometimes i use simple-patchsys when there's just a single patch or so | 06:12 |
| nadalizadeh | I'm confused a bit in becoming a MOTU. Reading the wiki, I found that first I should upload packages by a supervisor (where can I find one ?) then I can contribute to universe (when ?). For my first work I want to package a dictionary for stardict. | 07:10 |
| persia | nadalizadeh, Basically, the path to MOTU involves having done a fair bit first. | 07:14 |
| persia | The criteria on which prospective MOTU are judged are (loosely speaking) technical ability, volume and continuity of contributions, and integration with the community. | 07:14 |
| nadalizadeh | persia, So finally whats the first step ? | 07:14 |
| persia | So, when getting started, don't worry about MOTU. | 07:15 |
| persia | The first steps to contributing to development are usually either new packages or patches for packages. | 07:15 |
| persia | I typically recommend working on patches first, simply because I think this provides a gentle introduction to understanding debian format packaging. | 07:16 |
| persia | That said, if you want to package a dictionary for stardict, that would be the place to start. | 07:16 |
| persia | !packages | 07:16 |
| ubottu | You can browse and search for Ubuntu packages using !Synaptic, !Adept, "apt-cache search <keywords or regex>", the "apt:/" URL in KDE, or online at http://packages.ubuntu.com - Ubuntu has about 20000 packages available, so please *search* for an official package before installing things in awkward ways! | 07:16 |
| persia | !new packages | 07:16 |
| ubottu | Sorry, I don't know anything about new packages | 07:16 |
| persia | !newpackages | 07:16 |
| ubottu | The packaging guide is at http://wiki.ubuntu.com/PackagingGuide - See https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages for information on getting a package integrated into Ubuntu - Other developer resources are at https://wiki.ubuntu.com/UbuntuDevelopment - See also !backports | 07:16 |
| persia | !revu | 07:16 |
| ubottu | REVU is a web-based tool to give people who have worked on Ubuntu packages a chance to "put their packages out there" for other people to look at and comment on in a structured manner. See https://wiki.ubuntu.com/MOTU/Packages/REVU | 07:16 |
| persia | So the links provided for newpackages and REVU probably describe things in detail. | 07:17 |
| persia | Bascially, just package something, get it on REVU, fix any comments raised, and then it will get pushed to universe. | 07:17 |
| nadalizadeh | who will push it into universe ? I mean I somehow know the ubuntu packaging tips and can create the deb files. | 07:18 |
| persia | Well, once you get it packaged, and put it on REVU for review, people will comment. | 07:18 |
| persia | You need two MOTU to advocate your package, at which point someone (usually the second advocate) will upload it to the repository. | 07:19 |
| nadalizadeh | And how and when I can get into the MOTU group ? | 07:21 |
| persia | Once you're engaged enough that you've become a peer to the MOTU, people will start prompting you to apply. | 07:22 |
| persia | At that point, you send an application to the MOTU Council, and the MOTU debate your application, and the MOTU Council will then vote. | 07:22 |
| persia | If the vote is positive, you'll be MOTU. | 07:23 |
| persia | This can take a whlie: it was two years for me between my first patch and being MOTU, so I don't recommend worrying about it for a while. | 07:23 |
| persia | Some people do it faster, but the key is not to worry about it. | 07:23 |
| nadalizadeh | sure, thanks persia | 07:25 |
| zebulon | Anyone to help me with some software testing, link: http://fisygradis.sourceforge.net | 10:14 |
| === hyperair1 is now known as Guest30639 | ||
| === Guest30639 is now known as hyperair | ||
| handschuh | Could someone check the get-orig-source rule of http://revu.ubuntuwire.com/details.py?package=libballoontip-java ? | 10:41 |
| persia | handschuh, setting variables inside rules is awkward. | 10:45 |
| persia | Consider LIBBALLOONTIP_XML ?= above get-orig-source, and the others defined with = | 10:46 |
| persia | That way they won't actually be pulled until they are used. | 10:46 |
| persia | The watch file URL looks *very* specific. Do you really expect it to work for the next upstream version? | 10:46 |
| persia | Why mv Balloontip balloontip; ? | 10:47 |
| persia | Also, why so many \'s. Better to have separate lines in the rule. | 10:47 |
| persia | (and then you don't need the :s | 10:47 |
| persia | Err.. ;s | 10:47 |
| persia | It also fails the works-from-any-directory test, but most people don't follow that: it's not a significant bug (and fixing it is hard) | 10:48 |
| handschuh | persia: thanks for you time. | 10:49 |
| handschuh | persia: setting the variables outside of the rule would cause them to be calles | 10:50 |
| handschuh | s/calles/called | 10:50 |
| persia | No. | 10:50 |
| persia | Only if you did := | 10:50 |
| persia | If you do ?= for the uscan call, and = for the other two, they won't get expanded until get-orig-source is called. | 10:50 |
| handschuh | so I can set the variables above the rule and they are only called if needed? | 10:50 |
| handschuh | great | 10:51 |
| handschuh | btw: look at https://wiki.ubuntu.com/PackagingGuide/Examples/ChangingTheOrigTarball | 10:51 |
| handschuh | they also define variables inside the get-orig-source-rule | 10:52 |
| persia | Which example? I was sure I fixed that, and I'm not seeing it now. | 10:53 |
| handschuh | eyxample 3, "version" | 10:53 |
| * persia fixes | 10:53 | |
| persia | handschuh, Thanks for pointing that out. | 10:54 |
| handschuh | no problem | 10:54 |
| handschuh | and I was told to add the \'s | 10:55 |
| handschuh | therefore the ;'s are needed, too | 10:55 |
| persia | Who told you that? It's abuse of a makefile. | 10:55 |
| persia | Make is *not* shell. | 10:55 |
| handschuh | I was told that every single line without \ gets a single process | 10:56 |
| persia | Yes. | 10:57 |
| * persia notices that example 3 shouldn't even work because $version isn't defined at the time it's called | 10:57 | |
| handschuh | so i have to delete the \ and ; (and the end of a line) | 10:59 |
| handschuh | I still don't get why i have to add the get orig source-rule while other packages don't | 11:01 |
| persia | Because you're modifying the original tarball. | 11:06 |
| handschuh | ok | 11:06 |
| handschuh | so what about the \ and ; .... should i delete them? | 11:06 |
| handschuh | and put every command in a separate line? | 11:07 |
| persia | That's the best way to use make. It helps with debugging if anything goes wrong, because it processes each command separately. Otherwise you end up with a notice that get-orig-source didn't work, and no explanation why. | 11:09 |
| handschuh | fixed: http://paste.ubuntu.com/72299/ | 11:10 |
| persia | instead of using ``, change to $(shell shell-command) | 11:11 |
| persia | That won't actually work (or if it does, it's certainly not by design) | 11:11 |
| persia | Remember that make variables belong in $() or ${}: the variable definitions youhave in your variable declarations won't work. | 11:12 |
| handschuh | $ or $$ ? | 11:12 |
| persia | $() or ${}/ $$ is for shell variables (which these aren't) | 11:13 |
| handschuh | http://paste.ubuntu.com/72301/ | 11:14 |
| persia | When you run it, does it work for you? | 11:17 |
| handschuh | how to run it? (I only tested is as a shell file) | 11:21 |
| handschuh | btw: looking at https://wiki.ubuntu.com/PackagingGuide/Examples/ChangingTheOrigTarball again ... there are also \ and ; ... | 11:21 |
| persia | Test by calling debian/rules get-orig-source. That you tested as a shell file is why you are encountering confusion. | 11:22 |
| handschuh | it does not rrrun because the variable were not set | 11:23 |
| persia | Because you didn't use $(shell shell-command) as suggested. | 11:24 |
| handschuh | LIBBALLOONTIP_XML?=$(uscan --force-download --dehs) | 11:24 |
| handschuh | is wrong? | 11:24 |
| persia | Yes it is. | 11:25 |
| handschuh | ah "shell" | 11:25 |
| persia | $(...) is the variable named ..., and there's no variable named "uscan --force-download --dehs) | 11:25 |
| persia | The special "shell" variable will call a shell with the provided arguments | 11:25 |
| persia | Anyway, examples updated to be less bad. | 11:25 |
| handschuh | this http://paste.ubuntu.com/72307/ also does not work | 11:27 |
| handschuh | it does not get the variables ... not even the first | 11:30 |
| handschuh | this http://paste.ubuntu.com/72307/ also does not work | 11:31 |
| handschuh | it does not get the variables ... not even the first | 11:31 |
| persia | Try commenting out all your lines in get-orig-source, and using echo $(varaiblename) until you get those working, and then add the other lines back. | 11:33 |
| mok0 | handschuh: line 21, mv needs 2 arguments | 11:41 |
| handschuh | mok0: thanks! | 11:42 |
| mbudde | Hey, I'm working on updating Meld to version 1.2 but from previous packaging there is both a control and a control.in with the only difference being: http://paste.ubuntu.com/72311/ Does this have any purpose? | 11:43 |
| persia | mbudde, control.in theoretically makes it easier to update control. Update control.in, and see if your changes propagate at source build time. | 11:45 |
| * Hobbsee twitches | 11:45 | |
| persia | Hobbsee? | 11:46 |
| mok0 | Isn't modification of control etc deprecated? | 11:46 |
| handschuh | persia, mok0: how is that http://paste.ubuntu.com/72318/ ? | 11:46 |
| Hobbsee | persia: sounds very much like yada. | 11:46 |
| Hobbsee | "theoretically making it easier to update" | 11:47 |
| handschuh | (it works) | 11:47 |
| mbudde | persia, ok, but wouldn't you then only have the control.in and control would be automatically created? | 11:47 |
| mok0 | handschuh: looks better. Does it work? | 11:47 |
| RainCT | mbudde: yep | 11:47 |
| RainCT | mbudde: but the last version of it can still be included in the diff.gz | 11:47 |
| handschuh | mok0: it works calling "debian/rules get-orig-source" | 11:48 |
| persia | mbudde, control is required by policy. | 11:48 |
| persia | handschuh, That's the only test that matters. | 11:48 |
| mok0 | handschuh: great, and you fetch the .zip file manually I guess | 11:48 |
| quadrispr0 | hi RainCT, did you see http://revu.ubuntuwire.com/details.py?package=installation-report-generator? | 11:49 |
| handschuh | mok0: uscan --force-download fetches it | 11:49 |
| === quadrispr0 is now known as quadrispro | ||
| mok0 | handschuh: Ah | 11:49 |
| mbudde | Ok, I get it now.. just tried making a change to control.in and I can see control is automatically updated.. Makes more sense now, thanks! :) | 11:50 |
| mok0 | handschuh: did upstream provide a new zip file in the proper place? | 11:50 |
| handschuh | mok0: yes they do | 11:50 |
| mok0 | handschuh: good for you! | 11:50 |
| persia | Hobbsee, Indeed. | 11:53 |
| RainCT | quadrispro: I'll check it later today :) | 11:53 |
| quadrispro | ok thank you | 11:54 |
| RainCT | quadrispro: you'll still need a second advocate beside mine, though, so better start looking for someone else too :) | 11:54 |
| quadrispro | ah ok :) | 11:55 |
| handschuh | I uploaded a new version at http://revu.ubuntuwire.com/details.py?package=libballoontip-java | 11:55 |
| NCommander | Morning world | 13:00 |
| NCommander | hey Hobbsee | 13:00 |
| Hobbsee | heya | 13:01 |
| NCommander | Hobbsee, how goes it? | 13:05 |
| Hobbsee | NCommander: to bed! | 13:07 |
| * Hobbsee has work in 8 hours | 13:07 | |
| NCommander | ouch | 13:07 |
| NCommander | Night :-) | 13:07 |
| geser | Hi * | 13:15 |
| slytherin | geser: hi | 13:15 |
| geser | Hi slytherin | 13:15 |
| slytherin | geser: pm? | 13:15 |
| geser | sure | 13:16 |
| handschuh | someone_with_som_free_time: ping | 13:16 |
| handschuh | mok0: if you are free, I would be glad if http://revu.ubuntuwire.com/details.py?package=libballoontip-java could get its (hopefully) final review | 13:19 |
| slytherin | handschuh: geser might help you if he is free. | 13:19 |
| handschuh | slytherin: great | 13:20 |
| handschuh | geser: are you free now? | 13:20 |
| iulian | Hey geser. | 13:23 |
| * NCommander is trying to get IPv6 going | 13:24 | |
| DktrKranz | hi NCommander | 13:31 |
| NCommander | hey DktrKranz | 13:31 |
| DktrKranz | I've got something for you | 13:31 |
| DktrKranz | probably libtool related | 13:32 |
| DktrKranz | NCommander, http://hattory.no-ip.info/jaunty/result/liblunar_1.0.1-1ubuntu1/liblunar_1.0.1-1ubuntu1.buildlog | 13:33 |
| NCommander | it looks like the install file is out of date | 13:34 |
| DktrKranz | not really | 13:35 |
| DktrKranz | When I sponsored first version (which failed too), I test-built it | 13:35 |
| DktrKranz | and it worked | 13:35 |
| DktrKranz | but when I uploaded it... *bang* | 13:35 |
| geser | Hi iulian | 13:35 |
| geser | handschuh: I'm not really free right now | 13:36 |
| DktrKranz | in the meantime, there was a libtool upload | 13:36 |
| NCommander | I see | 13:37 |
| slytherin | geser: persia: one of those 'ant does not pull in compiler' build failures - http://launchpadlibrarian.net/19636916/buildlog_ubuntu-jaunty-i386.jaranalyzer_1.2-3_FAILEDTOBUILD.txt.gz | 13:37 |
| persia | slytherin, Surely that's a bug that the package doesn't build-dep on a compiler. | 13:38 |
| slytherin | handschuh: by the way, I was wondering why you named the source as libbaloontip-java, you could have kept it as balloontip. | 13:38 |
| geser | NCommander: have you an idea what's causing this FBTFS? http://launchpadlibrarian.net/19637735/buildlog_ubuntu-jaunty-amd64.dieharder_2.28.1-2_FAILEDTOBUILD.txt.gz | 13:38 |
| geser | I've seen this in several FTBFS build logs | 13:38 |
| persia | slytherin, Remember that Java packages in Debian are *never* build on the buildds, so there's *lots* of Build-Depends and Build-Depends-Indep issues with many of them. | 13:39 |
| slytherin | persia: Actually Debian's ant depends on java-gcj-compat-dev. | 13:39 |
| geser | slytherin: I've it on my TODO list already | 13:39 |
| persia | Hrm. Should ours depend on default-jdk or something? | 13:39 |
| geser | persia: ant recommends default-jdk | 13:39 |
| geser | but that doesn't work on the buildds | 13:39 |
| slytherin | persia: that is what I and geser were discussing that few days ago. He has already fixed a similar FTBFS. | 13:39 |
| * persia is confused. | 13:40 | |
| persia | Do the buildds not use recommends-by-default? | 13:40 |
| slytherin | So instead of patching all such packages I guess it is better to move default-jdk to Depends | 13:40 |
| DktrKranz | persia, IIRC, no | 13:40 |
| DktrKranz | not for intrepid, at least | 13:40 |
| NCommander | geser, take a number :-) (your looks the most straight fowrad to fix so once I fix my access to ipv6 sites, I'll help you) | 13:41 |
| persia | In that case, then I'm in support of making ant Depend on default-jdk. | 13:41 |
| * directhex adds default-jdk to Provides: in ikvm, giggles evilly | 13:42 | |
| geser | NCommander: please tell me how to fix this, so I can fix similar ones and don't need to bother you every time | 13:42 |
| NCommander | geser, generally speaking, you need to relibtoolize the package and copy the macros someplace where autotools can find them. | 13:43 |
| slytherin | directhex: please don't. | 13:43 |
| directhex | slytherin, nah, just kidding. | 13:44 |
| handschuh | slytherin: it is just a library and to match the conventions of any other java-library, the name has to be libXXX-java | 13:44 |
| directhex | slytherin, other fish to fry at the moment | 13:44 |
| === cprov is now known as cprov-afk | ||
| slytherin | handschuh: actually the source does not have to be of the form libfoo-java. You can keep it foo and then name binary packages libfoo-java | 13:45 |
| handschuh | slytherin: you mean the orig.tar.gz | 13:48 |
| handschuh | ? | 13:48 |
| directhex | aye. source package name is generally whatever upstream calls it | 13:48 |
| slytherin | handschuh: yes, you will also have to modify the debicn/control file accordingly | 13:48 |
| handschuh | slytherin: that seems stronly unnecessary to me ... | 13:49 |
| handschuh | slytherin: s/stronly/strongly | 13:49 |
| persia | directhex, You like ikvm? Perhaps you'd like to bring it up to date? | 13:49 |
| handschuh | slytherin: if we continue like this, no package will never be accepted | 13:49 |
| slytherin | handschuh: I am not saying that is necessary. I am just saying it is what we usually follow. | 13:50 |
| directhex | persia, nah, only ever used it once to try out. according to the guy who orphaned it, packaging it is... a battle | 13:50 |
| persia | directhex, That's a nice way to put it. | 13:50 |
| slytherin | handschuh: By the way, I am not a MOTU, so you don't need my opinion to get package accepted. | 13:50 |
| directhex | persia, who knows who's listening! | 13:50 |
| directhex | persia, if i'm any more rude, then i'll be misquoted on boycottnovell as badmouthing CLR in general | 13:51 |
| handschuh | slytherin: but I think you know a lot about java packages, so I wanted to follow your recommondations | 13:51 |
| persia | ikvm is CLR-based? | 13:51 |
| mok0 | handschuh: it seems endless, but you well get there ;) | 13:52 |
| directhex | persia, ikvm: /usr/lib/mono/gac/IKVM.GNU.Classpath/0.34.0.4__5a82d6c31a2f8235/IKVM.GNU.Classpath.dll | 13:52 |
| persia | handschuh, slytherin is our most active Java packager, and a member of the Debian Java team. Ignore his modesty :) | 13:52 |
| directhex | man, our package really IS ancient | 13:52 |
| persia | Yeah! There's also a few bugs with patches out there. Needs someone who understands how to make it work (which isn't me). | 13:52 |
| directhex | rule #1 of packaging applies even more when dealing with things that are difficult | 13:53 |
| persia | It was the subject of my "polishing a package" session during DeveloperWeek, because I was hoping someone would get interested, but that didn't happen. | 13:53 |
| persia | Which is that? Only maintain that which you use? | 13:53 |
| directhex | yep | 13:54 |
| directhex | not that it applies in ubuntuland, of course ;) | 13:54 |
| persia | That's the advantage of updating it behind the cloak of MOTU :) As long as you improve it a little, nobody expects you to make it really work. | 13:54 |
| directhex | if anyone materializes & expresses an interest in it, please do send them our way | 13:55 |
| persia | After enough of us touch it, it's typically in fairly good shape. | 13:55 |
| slytherin | handschuh: In the past java packagers have made source packages as libfoo-java as well. While there is no set rule for or against it, there days we try to keep source package name same as upstream. So if there are no other problems with your package, you may want to take a MOTU's advice if what I am saying is compulsory. | 13:55 |
| soc | hi | 13:55 |
| mok0 | azeem: ping | 13:55 |
| persia | directhex, Sure, although I share your doubts :) | 13:55 |
| directhex | although ikvm is probably the closest thing to common ground between pkg-java and pkg-mono | 13:55 |
| persia | soc, Welcome | 13:55 |
| directhex | and as such, neither of us want it ;) | 13:55 |
| persia | soc, Err. Back :) | 13:55 |
| handschuh | slytherin: so I should change in debian/control so Source: balloontip ? | 13:56 |
| soc | i want to uploade some sourcecode to launchpad, provide the debian packaging files and want to have it built online ... | 13:56 |
| soc | how would i have to do that? | 13:56 |
| handschuh | slytherin: or to balloontip-java ? | 13:56 |
| persia | soc, In the repository, or separate? | 13:56 |
| persia | handschuh, I'd recommend "baloontip", personally. | 13:56 |
| persia | (but with two 'l's) | 13:57 |
| soc | persia: as a ppa at first ... | 13:57 |
| slytherin | handschuh: balloontip | 13:57 |
| soc | i found out that somehow gnome-font-viewer wasn't built for intrepid | 13:57 |
| handschuh | persia, slytherin, ok, thanks | 13:57 |
| soc | normally it belongs to gnome-control-center | 13:57 |
| mok0 | handschuh: it's a quick change | 13:57 |
| soc | so i want to provide a seperate package for it | 13:57 |
| handschuh | mok0: indeed it is ... :-) | 13:57 |
| joaopinto | soc, https://help.launchpad.net/Packaging/PPA | 13:57 |
| slytherin | soc: have you analyzed why it wasn't build? | 13:58 |
| directhex | persia, hm, not a good sign, seems dajobe abandoned collaborative maintenance. the version in pkg-cli-apps svn is neolithic | 13:59 |
| mok0 | OT: have you guys seen http://wikimapia.org/ ?? Pretty awesome | 13:59 |
| directhex | persia, actually, we have a new guy (an italian dentists of all things) who's been really attacking out TODO list like you wouldn't believe. once he's done with his current challenge, i might suggest ikvm to him | 14:00 |
| mok0 | directhex: ah, he's good at drilling into things | 14:01 |
| directhex | mok0, indeed | 14:01 |
| handschuh | slytherin: I changed the rules and the control but on debuild it tells me that no original source could be found | 14:01 |
| directhex | mok0, currently he's tasked with backporting monodoc from trunk, as upstream added a bunch of stuff we asked for to make life easier... except at the same time they also dissolved the monodoc svn module & scattered its ashes to other modules. so it's a big task | 14:02 |
| persia | mok0, Interesting. Luckly I don't live in a defined "place" :) | 14:02 |
| soc | slytherin: no, i didn't | 14:02 |
| soc | from the gnome-channel: "borschty: got removed, but maybe will come back in 2.26" | 14:02 |
| slytherin | handschuh: that is because your .orig.tar.gz still has old name. | 14:03 |
| soc | and i think that shouldn't happen, because we lost the ability to view a whole range of files in ubuntu | 14:03 |
| slytherin | handschuh: make sure (before uploading) that your get-orig-source target is also modified accordingly. | 14:03 |
| handschuh | slytherin: no its balloontip_VERSION.orig.tar.gz | 14:04 |
| handschuh | slytherin: but debuild searches for libballoontip-java ... | 14:04 |
| directhex | slytherin, so what are the java team's plans for jaunty? anything exciting? | 14:04 |
| slytherin | handschuh: what is the name of the folder where you are running debuild? | 14:04 |
| handschuh | balloontip | 14:04 |
| slytherin | directhex: 1. killall sun-java5-*. 2. add maven support. | 14:05 |
| slytherin | directhex: koon is working on 2. | 14:05 |
| directhex | what's maven? | 14:05 |
| slytherin | handschuh: please paste your control file on pastebin | 14:05 |
| nhandler | handschuh: Did you change your changelog file? I'm not sure, but it might be using that | 14:05 |
| handschuh | slytherin: http://paste.ubuntu.com/72361/ | 14:06 |
| slytherin | directhex: it's is a build tool. It let's you define build dependencies for your project in a xml file and will then download all the relevant jar's form it's repository. | 14:06 |
| handschuh | nhandler: no i did not. Isnt it wrong to do this? | 14:06 |
| nhandler | handschuh: Isn't it wrong to do what? | 14:07 |
| directhex | slytherin, downloading binaries at build time? the security team will love that :| | 14:07 |
| RainCT | actually, the buildd's ahve no connection | 14:07 |
| RainCT | *have | 14:07 |
| persia | (except Koon has a plan to make maven use our repository rather than a random one: see https://wiki.ubuntu.com/JavaTeam/Specs/MavenSupportSpec ) | 14:07 |
| handschuh | nhandler: to change the changelog from libballoontip to balloontip | 14:07 |
| slytherin | directhex: check the link persia has pasted. We will be modifying maven to use packages form our repository. | 14:08 |
| persia | handschuh, When doing initial packaging, almost no change is wrong if it helps get the right result. | 14:08 |
| Laibsch | Any kind soul to push my debdiffs from bug 227547? | 14:08 |
| ubottu | Launchpad bug 227547 in wordpress "ubuntu wordpress should suppress the "please update" warning" [Wishlist,In progress] https://launchpad.net/bugs/227547 | 14:08 |
| directhex | neato. auto-resolving jars to package names? | 14:08 |
| handschuh | nhandler: if I change the changelog, everything works fine | 14:08 |
| nhandler | handschuh: Glad to hear that | 14:08 |
| slytherin | directhex: something of that sort. | 14:08 |
| directhex | clever | 14:08 |
| directhex | good luck with it | 14:09 |
| handschuh | nhandler: thanks a lot | 14:09 |
| nhandler | You're welcome handschuh | 14:09 |
| nhandler | Keep up the good work | 14:09 |
| persia | directhex, Well, it's not that automated. it's mostly just symlink hacks to make maven think it already downloaded everything when the build-deps are installed. | 14:09 |
| persia | kaaloon was looking at building a proxy that would cause maven requests to turn into apt-get requests, but it was too complicated (for the reasons you mention) | 14:10 |
| directhex | persia, ah. good, i was mildly concerned by the idea of dynamically constructed build-deps | 14:10 |
| persia | No, it's not that bad. Check the "How to use maven in a debian package" part of the spec. | 14:10 |
| handschuh | nhandler: http://revu.ubuntuwire.com/details.py?package=balloontip - but now the name has changed ... | 14:11 |
| persia | The only issue is if people want versions we don't ship, but that's the same mess we've worked around in ezinstall for a while now. | 14:11 |
| directhex | persia, right. | 14:12 |
| persia | directhex, Is there a similar set of madness for mono yet? | 14:12 |
| handschuh | slytherin: http://revu.ubuntuwire.com/details.py?package=balloontip ... but now, the name has changed ... will it be presented in the non-src repositories as libballoontip ? | 14:13 |
| directhex | persia, nothing which uses online repos for building, no | 14:13 |
| directhex | persia, we're gearing up for a major transition which will shrink our footprint, though | 14:13 |
| persia | I know python is mostly tamed. We have a plan to tame java. Ruby still suffers, but there's a light at the end of the tunnel. | 14:13 |
| persia | footprint shrinking is lovely. I suppose you're waiting for squeeze? | 14:13 |
| directhex | persia, squeeze would be joyous, but for now we have experimental | 14:14 |
| slytherin | handschuh: let me check, make rue the bug you logged has updated link. | 14:14 |
| directhex | persia, our latest mono is stuck in NEW, and further splits the mono source package into over 90 (!) binary packages | 14:14 |
| directhex | persia, on the ubuntu side, mono is now syncable, and after the transition we can dump half the packages from main into universe | 14:14 |
| * persia scans http://bts.turmzimmer.net/ to see if sqeeze can be made to release faster | 14:14 | |
| persia | directhex, source packages or binary packages? | 14:15 |
| directhex | persia, binary packages | 14:15 |
| persia | Careful with that. Having binary and source in separate pockets can be a recipe for confusion. | 14:15 |
| directhex | persia, shouldn't be, in this instance (and mono is already split between the two) | 14:15 |
| persia | In that case it won't be more so :) | 14:16 |
| directhex | persia, you know how with mono, there are specific versions of the classlib, rather than versions being backward-compatible? | 14:16 |
| directhex | persia, well, in .net generally | 14:16 |
| * persia knows almost nothing about .net | 14:16 | |
| directhex | persia, we're deprecating the .net 1.0 classlib from our packages, and forcing all libs & apps to build against 2.0 - hence removing all 1.0 binary deps which currently inflate the tomboy/f-spot depends | 14:17 |
| handschuh | slytherin: ok I added a comment to the launchpad bug that the url has been chnaged | 14:17 |
| slytherin | handschuh: I am reviewing the package. | 14:18 |
| directhex | persia, we've also further split one package so an app using the Mono.Posix assembly no longer pulls in the dependencies of the other things in the same package, such as sqlite | 14:18 |
| nhandler | handschuh: When you are dealing with the binary packages (apt-get install XXX) it will use whatever names you have in your control file for the binary packages | 14:18 |
| directhex | persia, total savings should be ~10-20 meg on the jaunty cd image | 14:18 |
| handschuh | slytherin: great! thanks a lot | 14:18 |
| persia | directhex, Well, something will eat that. | 14:18 |
| handschuh | nhandler: ok nice to hear | 14:18 |
| persia | Be nifty if it could be a java plugin for the browser, but that would require the same sort of refactoring, which nobody has volunteered to do. | 14:19 |
| directhex | persia, sure, something will, but the point is, not us | 14:19 |
| persia | directhex, Which is commendable. | 14:19 |
| directhex | persia, so the "mono is bloat" argument is diminished ;) | 14:19 |
| persia | Well, depends on the viewpoint. I'm probably still not going to include Mono in MID, but it will be worth another look. | 14:20 |
| persia | As much as I like Java, I wish I didn't have to include Java in MID, because lots of people only have 4G storage, so space is at a premium. | 14:20 |
| directhex | persia, so right now, there are three parts of the "core" mono stack remaining to transition - mono-debugger, which has seen no love for ages; monodoc, which needs severe backporting from trunk to avoid messy reconstruction of the index .xml file all the time; mono-tools, which build-depends monodoc & contains various little bits & pieces | 14:21 |
| directhex | persia, only include mono in MID if there are specific apps to make it worthwhile. including stacks for the sake of it is pointless | 14:21 |
| handschuh | slytherin: i have to go now - thanks for you review | 14:25 |
| slytherin | persia: filed bug 298400. geser: please don't work on jaranalyzer. Let's get this bug fixed instead. | 14:25 |
| ubottu | Launchpad bug 298400 in ant "Please move default-jdk to 'Depends'" [Undecided,New] https://launchpad.net/bugs/298400 | 14:25 |
| slytherin | handschuh: see you later. | 14:25 |
| persia | directhex, We're currently using gthumb instead of f-spot for example. | 14:26 |
| directhex | persia, to avoid mono? | 14:26 |
| persia | Well, total impact of gthumb was less than total impact of f-spot. It wasn't mono-specific. | 14:27 |
| persia | With the refactoring, it's probably worth revisiting that decision. | 14:27 |
| directhex | numbers would help | 14:27 |
| persia | Of course, best would be for someone to write a hildonised photo management app and get it in the repos, but that's more complicated. | 14:27 |
| persia | directhex, I don't have them handy, but gthumb had no additional deps, and f-spot had several. Total size was larger. | 14:28 |
| directhex | iirc you should pull about 17 meg off your numbers for f-spot | 14:28 |
| directhex | or perhaps that was tomboy | 14:28 |
| persia | Which might well make a big difference. | 14:28 |
| geser | slytherin: too late, I already uploaded jaranalyzer a few minutes ago | 14:28 |
| persia | MID doesn't have tomboy (no desktop means no point to desktop notes) | 14:28 |
| slytherin | geser: :-) | 14:28 |
| geser | slytherin: I guess it needed to by touched anyway as I also needed to modify JAVA_HOME in debian/rules | 14:29 |
| directhex | persia, well, obviously in a small space, you need to make size a priority | 14:30 |
| slytherin | geser: right, forgot that part. It should have been /usr/lib/jvm/default-java | 14:30 |
| directhex | persia, which java are you shipping? | 14:30 |
| slytherin | NCommander: RainCT: can either of you please archive http://revu.ubuntuwire.com/details.py?package=libballoontip-java the source name has changed to balloontip. | 14:32 |
| persia | directhex, OpenJDK + extras. | 14:33 |
| directhex | christ, that's over a hundred meg on disk isn't it? | 14:33 |
| persia | Too many people complain when the Java applets don't work, and that's the least painful alternative. | 14:33 |
| RainCT | slytherin: done | 14:33 |
| persia | Yes. It's something like 15% of the image size. | 14:33 |
| directhex | persia, flash too, presumably? | 14:33 |
| persia | gnash for flash. | 14:34 |
| slytherin | geser: by the way, there was an old bug 243214 for moving freeguide to universe. I think it can be acked now. | 14:34 |
| ubottu | Launchpad bug 243214 in freeguide "freeguide should be in universe" [Unknown,Fix released] https://launchpad.net/bugs/243214 | 14:34 |
| directhex | persia, so... about moonlight then ^_^ | 14:34 |
| persia | Problem is that people expect MID to have first-class browsing, although given the state of ubiquitous networking, I think most MIDs are more mp3 players, ebooks, etc. | 14:34 |
| persia | directhex, Nobody complained loudly enough yet :) | 14:34 |
| directhex | WAAAAAAA | 14:34 |
| directhex | ;) | 14:34 |
| persia | directhex, Get a plugin working on the desktop. Make sure it works with ferret, and then file a bug. | 14:35 |
| directhex | persia, the packaging for SL 1.0 profile is more or less done, and should need no changes for the final release of moonlight 1.0 | 14:35 |
| directhex | persia, ferret? | 14:35 |
| persia | I think that's what it's calleed. | 14:35 |
| directhex | fennec? | 14:35 |
| persia | MIDbrowser is mostly dead upstream, so we're switching. | 14:35 |
| persia | RIght. Fennec | 14:36 |
| * persia doesn't do browser stuff much. | 14:36 | |
| directhex | ought to be fine. xulrunner 1.9 is xulrunner 1.9 | 14:36 |
| slytherin | whatever happened to midori? Why isn't that shipped on MID? | 14:36 |
| directhex | persia, MID includes things from universe, right? | 14:37 |
| persia | directhex, Yep. It's a universe flavour. | 14:38 |
| geser | slytherin: ACKed | 14:38 |
| directhex | just checking | 14:38 |
| slytherin | geser: thanks. | 14:38 |
| directhex | persia, does MID include libavcodec for anything? | 14:39 |
| persia | slytherin, Because MIDbrowser was hildonised. With MIDbrowser upstream less active, other candidates are welcome. fennec has some support, but if someone makes another hildonised browser, it's a strong contender. | 14:39 |
| slytherin | hmm | 14:39 |
| persia | directhex, http://cdimage.ubuntu.com/ubuntu-mid/intrepid/20081029/ubuntu-mid.manifest was the ship image for intrepid. | 14:40 |
| directhex | looks like, then | 14:40 |
| directhex | persia, FYI then, jaunty should contain moonlight 1.0, which is all c++ (no mono deps), and uses libavcodec for media support | 14:41 |
| slytherin | should revu host package updates? I am talking about http://revu.ubuntuwire.com/details.py?package=stellarium | 14:41 |
| persia | directhex, In that case, it just needs to work with the browser. Does it work with fennec? | 14:41 |
| persia | slytherin, No. I'll clean those up now. | 14:41 |
| directhex | persia, is there a ppa with a fennec package? it ought to work with any xul 1.9 browser | 14:41 |
| persia | fta, When is fennec hitting REVU? | 14:42 |
| fta | persia, i didn't receive much feedbacks so far, so i'm unsure. maybe 1.0 final | 14:44 |
| persia | fta, OK. I'd like to get some testing, but if you think it needs more time to be stable, that makes more sense. | 14:45 |
| fta | persia, in the meantime, i'm working with mozilla to upstream my patches | 14:45 |
| persia | Cool! | 14:45 |
| directhex | oh, what does "uname -a" report on MID, ooi? MID is the image that uses lpia isn't it - does it still show as i386? | 14:45 |
| fta | persia, imho, it's already usable as it is | 14:45 |
| persia | fta, Your opinion is the one that matters. Toss it on REVU, grab an ACK, and upload. | 14:46 |
| persia | directhex, I'm getting a kernel panic today for reasons I don't entirely understand. Try it yourself? | 14:47 |
| persia | I think it reports "lpia". | 14:48 |
| persia | Might report "i686". | 14:48 |
| persia | RainCT, Why is cinepaint under "Updated Packages" on REVU? The old gtk+1.2 package was removed, but the version on REVU is for GTK+2.0 | 14:49 |
| persia | RainCT, Same question goes for "supercollider". If someone repackages something that was removed, it would be nice to show it as a candidate for inclusion. | 14:50 |
| persia | (note that this likely means upstream died and was revived, or licensing changes or something) | 14:50 |
| directhex | persia, it appears my shitty old cpu has no kvm powers. how sucky. | 14:53 |
| persia | directhex, Hrm. Well, ask me in a few days then, as I'm not likely to fuss about the kernel panic until then. | 14:53 |
| directhex | persia, you could mail me a new CPU, that would also work | 14:55 |
| persia | directhex, Yeah, but that's more effort on my part :) | 14:55 |
| directhex | and money! | 14:56 |
| persia | money is largely imaginary. Human effort should be preserved at all costs. | 14:56 |
| directhex | perhaps one day there'll be a system that allows you to exchange money for effort. or vice versa! | 14:57 |
| persia | money is mostly valuable because you can exchange money for human effort, and vice-versa | 14:57 |
| persia | directhex, Like contract work? | 14:57 |
| directhex | yeah! neat idea! | 14:57 |
| persia | RainCT, conversely, why is "stellarium" *not* listed as an "Updated Package"? | 15:01 |
| * persia leaves that one for purposes of SQL query review. | 15:02 | |
| fta | persia, so far, my branch is tracking a snapshot between a1 and a2 => 1.0~a2~hg20081106r253-0ubuntu1, is it good enough for revu ? | 15:02 |
| fta | persia, no idea when a2 is due | 15:02 |
| persia | fta, The version isn't so important for REVU, although many people prefer actual releases. I'm certain you've a working get-orig-source, as I've seen your packaging scripts. | 15:03 |
| directhex | fta, a1+ | 15:03 |
| directhex | not a2~ | 15:03 |
| directhex | ;) | 15:03 |
| persia | fta, The important part is whether you think it's ready. I'm only asking for it because directhex wanted to test it with moonlight. | 15:03 |
| directhex | still booting the kvm image with regular qemu | 15:04 |
| persia | directhex, Why? As long as it's known the next version will be ...a2..., ~a2 is safe. | 15:04 |
| fta | directhex, nope, a1+ is not good. internally, it's referred to as 1.0a2pre | 15:04 |
| directhex | fta, well, that's okay then | 15:04 |
| RainCT | persia: I think REVU is currrently checking the Sources of the current system (ie, Hardy). I'll to change this once I rework all the scripts | 15:04 |
| directhex | persia, if it's based on a2, use a2~. if it's based on a1, use a1+! | 15:04 |
| persia | directhex, Well, you ought be able to test on a regular system. Nothing in moonlight or fennec should be arch-specific. | 15:05 |
| fta | directhex, trust me, i know how to name versions, especially for mozilla projects ;) | 15:05 |
| persia | directhex, Right. See note above about a2pre | 15:05 |
| directhex | okay, desktop is up. how to open a terminal from the funny mid desktop? | 15:05 |
| persia | RainCT, Except it's not, because neither supercollider nor cinepaint was in hardy, and stellarium is. | 15:06 |
| persia | directhex, Why do you need the funny mid desktop to test fennec? | 15:06 |
| persia | Or moonlight, for that matter? | 15:06 |
| persia | Oh. Wrong question. | 15:06 |
| persia | I think it's in Accessories. | 15:06 |
| RainCT | persia: uhm, weird.. I'll check, I'mm not familiar with that part of REVU yet | 15:07 |
| directhex | persia, i wanted to check the arch question. moonlight will, if it fails to render something using its compiled-in codecs (i.e. with libavcodec) offer to download a binary codec pack. i want to know whether than gets the i386 codec pack on MID | 15:07 |
| persia | RainCT, That's why I'm not touching those packages for now :) It's a bit confusing. | 15:07 |
| persia | directhex, Ah. That makes sense. You probably do want the i386 binary codec pack for lpia. | 15:08 |
| directhex | persia, well, exactly | 15:08 |
| persia | RainCT, genpo is another interesting package in that respect. | 15:08 |
| directhex | persia, and, it seems, uname -m says i686 | 15:08 |
| directhex | so it should be fine | 15:08 |
| directhex | that's what i wanted to check | 15:08 |
| === mcasadevall is now known as NCommander | ||
| persia | Err, except I'm looking at the archived packages when I see genpo. Ignore that. | 15:09 |
| * NCommander laughs evilly | 15:11 | |
| directhex | evil laughter? been working on mono again? | 15:11 |
| NCommander | directhex, better | 15:11 |
| NCommander | I'm now connected to Freenode over IPv6 | 15:11 |
| directhex | using a mono-based irc client? | 15:12 |
| NCommander | not yet | 15:12 |
| slytherin | directhex: Why are you asking so many questions? Is 'evil laughter' patented? :-P | 15:13 |
| === asac_ is now known as asac | ||
| directhex | slytherin, if the ubuntu forums are to be believed, only certain classes of developer are allowed to use it | 15:13 |
| directhex | slytherin, java devs have halos & harp choruses | 15:13 |
| hyperair | directhex: what brought that on | 15:13 |
| hyperair | halos and harp choruses? O_o | 15:14 |
| directhex | hyperair, java is teh freedoms! | 15:14 |
| hyperair | directhex: ...you can't be serious.what freedom? | 15:15 |
| directhex | hyperair, freedom from software patents, duh! | 15:15 |
| hyperair | directhex: but wasn't java tied to patents until very recently? | 15:16 |
| directhex | hyperair, no, only microsoft have patents. everyone else declared them null & void, and danced around a flower circle holding hands | 15:17 |
| fta | persia, now i remember. i didn't push fennec because it needs xulrunner-1.9.1, for which i'm waiting for 1.9.1b2 | 15:17 |
| directhex | hyperair, you haven't been keeping up to date on your software news, man! | 15:17 |
| slytherin | hyperair: I don't think problem with java was patent, it was license. Please correct me if I am wrong. | 15:18 |
| hyperair | oh er whoops? | 15:18 |
| directhex | slytherin, aye. infact, istr the java distribution license is what prevented java from becoming bite-sized & well, less than 100 meg to install | 15:19 |
| hyperair | directhex: miserable thing. the programming language is as bloated as the java vm | 15:20 |
| hyperair | directhex: you ever tried writing java on paper? it's hell. | 15:20 |
| directhex | hyperair, of course. my undergrad degree had a few "write an app to do foo" paper exams | 15:20 |
| slytherin | hyperair: Programming language is never bloated. Programs are. | 15:21 |
| hyperair | directhex: i just sat for one of those the other day. i disliked java from the beginning, but when i wrote it on paper, i loathed it | 15:21 |
| directhex | hyperair, java as a language is okay now (at the time, some things drove me nuts) | 15:21 |
| directhex | hyperair, but who would code without an API reference to hand? O_o | 15:21 |
| hyperair | slytherin: it's long winded. that's what i mean by bloated | 15:21 |
| hyperair | slytherin: so yes, i do mean that the language itself is bloated. two constructors to open a file. my word. ridiculous! | 15:22 |
| directhex | at least "int" and "Integer" do the same thing these days. manually boxing & unboxing = pain | 15:22 |
| hyperair | directhex: the exam's got no API reference. | 15:22 |
| slytherin | directhex: exactly, with api reference in hand, java is programming heaven. :-) | 15:22 |
| hyperair | directhex: it's closed-book | 15:22 |
| directhex | slytherin, i prefer the semantics of c#, but both are pretty close. my degree was all java | 15:22 |
| directhex | slytherin, the manual boxing of raw types is what drove me up the bloody wall | 15:23 |
| slytherin | hyperair: java saves you from shooting yourself in the foot. :-P | 15:23 |
| hyperair | slytherin: wth a keyboard to type on, it's not SO bad. but when you write at 1/3 the speed you type, and have a time constraint, you begin to loathe it. | 15:23 |
| hyperair | slytherin: java makes me want to shoot myself in the head | 15:23 |
| slytherin | hyperair: at least you die better. :-P | 15:24 |
| hyperair | slytherin: how about programming in something better and NOT dying | 15:24 |
| hyperair | slytherin: i like to be optimistic | 15:24 |
| directhex | what does hyperair like to program with? | 15:24 |
| hyperair | python | 15:24 |
| hyperair | or C++ | 15:25 |
| hyperair | and before you shoot me for liking C++, shoot slytherin for liking java | 15:25 |
| slytherin | hyperair: when I tried writing meaningful programs in exams, I got 40 out of 100. I then realised that the problem was at examiner's end. | 15:25 |
| directhex | C++ is all the rope in the world | 15:25 |
| directhex | good luck not hanging yourself with it | 15:25 |
| hyperair | directhex: i won't =) | 15:25 |
| hyperair | slytherin: what? | 15:26 |
| slytherin | hyperair: It is just that if examiner's don't like to think. They just want to read your program and move ahead. So if they fine something unfamiliar in your program you are likely to fail. | 15:27 |
| persia | hyperair, You will. It's unavoidable. When you do, code more defensively. | 15:27 |
| * slytherin moves to checking if balloontip actually builds. | 15:28 | |
| hyperair | persia: i still prefer it to java. java makes me want to go to the supermarket, buy some rope, and hang myself. at least C++ lets me hang myself without the effort of buying the rope | 15:28 |
| RainCT | lol | 15:29 |
| persia | hyperair, I can understand your unhappiness. My issues with C++ are mostly that I've never seen a C++ program that was safe. They either mix primitives and objects, or they try to do functional coding in an OO environment. | 15:30 |
| persia | It's not that the language is so bad as languages go, it's that I've never encountered a programmer capable of writing safe C++. | 15:31 |
| persia | Other environments may be less pleasant, but it's also easier to not shoot yourself. | 15:31 |
| hyperair | hmm yeah =\ | 15:32 |
| hyperair | well what constitutes as safe C++ anyway? | 15:32 |
| hyperair | i'm still rather new to C++ so to speak. i mean i've learnt it over 2 yaers ago, but never really got anything done with it yet | 15:32 |
| persia | Incapable of segfauting from user-accessible actions. | 15:32 |
| hyperair | wait, what? | 15:32 |
| hyperair | incapable of segfaulting? | 15:32 |
| persia | If you like the syntax and similar, I'd recommend writing in C. There are several object frameworks for C that are considerably safer than C++. | 15:33 |
| hyperair | i like OOP | 15:33 |
| hyperair | including the polymorphism and inheritance part | 15:33 |
| hyperair | which is why i picked C++ over C | 15:33 |
| directhex | i like spending more time with apps, and less time with memory manglement | 15:34 |
| hyperair | it's not like i don't know C though, i know it about as well as i know C++ =p | 15:34 |
| directhex | hence i like languages with full GC and no need to malloc | 15:34 |
| hyperair | i don't like that java has no destructors. | 15:34 |
| persia | hyperair, I'm not saying don't use OO in C. I'm saying that how it's implemented in C++ isn't type-safe. | 15:34 |
| * directhex demands OO fortran | 15:35 | |
| hyperair | persia: sorry if i seem ignorant, but what dyou mean by type-safe? | 15:35 |
| persia | ObjC or gobject-style stuff is cleaner. | 15:35 |
| persia | hyperair C++ allows you to set a variable to an object, add the integer 0x0001 and then use that as an object reference. | 15:35 |
| persia | Since that part of memory isn't an object reference, it bails. | 15:36 |
| persia | You can do the same thing with any language, but most other languages make it harder by type-checking the result, rather than bouncing blindly to the offset and executing the code. | 15:37 |
| persia | Well, C lets you do it just as unsafely, but C natively doesn't do objects, and the object frameworks do type-checking. | 15:37 |
| persia | (well, the better ones, at least) | 15:37 |
| directhex | tell you what, hyperair. you write in ironpython, slytherin writes in c#, and you can interop fine via the wonders of CLR! it's foolproof! | 15:38 |
| * directhex pretends jython doesn't exist | 15:38 | |
| * persia notes that it was the basis for the recently announced Java launchpad bindings | 15:39 | |
| * slytherin feels directhex is a M$ spy. | 15:39 | |
| hyperair | directhex: what's CLR? | 15:39 |
| directhex | really? neato | 15:39 |
| directhex | hyperair, common language runtime. like the java vm, but designed to actually support & interop multiple languages | 15:39 |
| NCommander | geser, did you solve your FTBFS issue? | 15:39 |
| hyperair | mm i see | 15:40 |
| directhex | slytherin, sure. they pay me billions in order to package free software | 15:41 |
| hyperair | directhex: really? | 15:41 |
| slytherin | directhex: I was just kidding. :-) | 15:41 |
| directhex | hyperair, nah, course not | 15:41 |
| hyperair | directhex: i TOTALLY want to work for microsoft now | 15:41 |
| hyperair | ;) | 15:41 |
| hyperair | directhex: you didn't really believe i fell for that did you D= | 15:41 |
| directhex | okay, just checked, autofoo thinks target_cpu='i686' on ubuntu-mid | 15:42 |
| directhex | meaning no problems for moon | 15:42 |
| geser | NCommander: didn't have time yet to look at it | 15:44 |
| === cedric__ is now known as cedricv | ||
| mok0 | Where do I find the debootstrap script for jaunty? | 15:53 |
| mok0 | is it in -backports? | 15:54 |
| === NCommander is now known as Guest15215 | ||
| === Guest15215 is now known as mcasadevall | ||
| === mcasadevall is now known as NCommander | ||
| jpds | mok0: cd /usr/share/debootstrap/scripts && sudo ln -s jaunty intrepid? | 15:56 |
| hyperair | jpds: not intrepid jaunty? | 15:57 |
| mok0 | jpds: I can try that. I just thought there was a version of debootstrap that had the jaunty script in it | 15:57 |
| jpds | What hyperair said. | 15:58 |
| jpds | mok0: All the other releases just appear to be links to gutsy anyway. | 15:59 |
| mok0 | jpds: ok, thanks | 15:59 |
| hyperair | mok0: it's already a link to gutsy on my system | 16:00 |
| hyperair | mok0: and yes it's in -backports | 16:01 |
| handschuh | has somebody time to review http://revu.ubuntuwire.com/details.py?package=balloontip ? | 16:01 |
| mok0 | hyperair, weird, I activated backports and I don't have it | 16:02 |
| hyperair | mok0: maybe your mirror doesn't have it yet. | 16:02 |
| mok0 | hyperair: good point | 16:03 |
| hyperair | 1.0.10ubuntu1~intrepid1 | 16:03 |
| hyperair | mok0: which mirror are you using? | 16:03 |
| slytherin | mok0: why not directly download it from https://packages.ubuntu.com | 16:03 |
| NCommander | geser, if you want, I'll handle your FTBFSing package | 16:04 |
| mok0 | hyperair: perhaps if I activate the main component.... d'Oh! | 16:05 |
| geser | NCommander: please do if you have time | 16:06 |
| NCommander | geser, which package was it again? | 16:06 |
| geser | NCommander: I've to look it up, but there are several FTBFS with a similar error. | 16:07 |
| hyperair | mok0: lol | 16:07 |
| NCommander | Never fails when we update libtool :-/ | 16:07 |
| * mok0 happily creating cowbuilders | 16:13 | |
| geser | NCommander: here is a small list: dieharder, gpsdrive, lib3ds, libm4ri, plib | 16:16 |
| NCommander | "dieharder" | 16:16 |
| NCommander | O_O; | 16:16 |
| slytherin | persia: Do you have some time to review balloontip? I am currently verifying that if package builds. Rest looks fine to me. | 16:18 |
| handschuh | slytherin: thanks ... so no objections from your side on creating similar java packages (with different content)? | 16:21 |
| slytherin | handschuh: that depends on packages. What are you working on currently? | 16:22 |
| handschuh | slytherin: h2database, jaxws, java-excel-api | 16:22 |
| slytherin | handschuh: do you plan to get any of those packages in Debian? | 16:22 |
| handschuh | slytherin: all of them | 16:23 |
| handschuh | slytherin: I just have to travel a bit to get my key signed | 16:23 |
| toobaz | is there any way to push a patch reported on a critical bug with importance still "Undecided"? It is already in the ubuntu-universe-sponsors list, but its importance puts it very low on the list, and I'm afraid it will take too much time before it is considered. Please feel free to insult me if this is a stupid fear or if I should address to someone else (but who?) questions about setting the importance of a bugs. | 16:23 |
| slytherin | handschuh: Ok. ping me when those are on revu. | 16:23 |
| persia | handschuh, I'll take a look at baloontip tomorrow (it's past my bedtime) | 16:23 |
| handschuh | slytherin: will do! Thanks | 16:23 |
| slytherin | handschuh: you don't need to get your key signed. You can seek sponsorship same way as you do in Ubuntu. | 16:24 |
| handschuh | persia: ok, no problem | 16:24 |
| persia | toobaz, Bugs in the UUS queue are usually processed as FIFO, rather than by importance. | 16:24 |
| toobaz | persia: that's a very good answer, thanks | 16:24 |
| persia | toobaz, If it's an SRU for a critical regression already fixed in Jaunty, give the bug number here, and ask for help. | 16:24 |
| handschuh | slytherin: oh - didnt know that. I will search for the corresponding page | 16:24 |
| slytherin | handschuh: you may want to join debian-java team and get access to pkg-java svn (which contains team managed packages). | 16:25 |
| persia | handschuh, mentors.debian.net has a fair bit of info, but you'll probably want to get stuff into pkg-java SVN. | 16:25 |
| handschuh | slytherin, persia: thanks for the info | 16:26 |
| handschuh | slytherin: java.debian.net is a good place to look at, right? | 16:27 |
| toobaz | persia: no, unfortunately it's not fixed in Jaunty, neither in Debian Sid. It's LP #257797, and it totally breaks its package | 16:27 |
| ubottu | Launchpad bug 257797 in drgeo "segment fault" [Undecided,Confirmed] https://launchpad.net/bugs/257797 | 16:27 |
| slytherin | handschuh: right | 16:28 |
| persia | toobaz, Hrm. I've no suggestions but to wait then, unless some kind soul grabs it from your poke. | 16:28 |
| persia | Generally that doesn't happen, to discourage people from poking about every bug. | 16:28 |
| toobaz | persia: thanks anyway, but just a doubt: I think Jaunty will just import the debugged package from Debian (I'm following the Debian side of the bug too); is it OK if my debdiff's changelog entry addresses Intrepid? | 16:29 |
| persia | toobaz, No. You'd want intrepid-proposed. | 16:30 |
| persia | And it won't get accepted into intrepid-proposed until it's fixed in Jaunty, which might wait on the Debian sync. | 16:30 |
| toobaz | persia: so you mean I must address it to Jaunty to get it in reasonable time... | 16:30 |
| toobaz | on Debian side everyone is thinking to Lenny, which isn't affected... | 16:31 |
| persia | toobaz, Lenny isn't affected, but Jaunty is? | 16:33 |
| toobaz | Intrepid and Jaunty are | 16:33 |
| persia | toobaz:: Is it just the rebuild required? | 16:34 |
| toobaz | it's a bug that is spotted only by newer versions of gcc, but it is a bug indeed. | 16:34 |
| toobaz | the patch is minimal but needed | 16:34 |
| persia | I didn't realise intrepid had a newer gcc than Jaunty. | 16:34 |
| persia | Yes, please fix Jaunty then. | 16:35 |
| NCommander | geser, dieharder fixed | 16:35 |
| persia | Err. that intrepid had a newer gcc than lenny. | 16:35 |
| toobaz | persia: ok, thank you for the clarification (I would never had guessed that I should file a patch for a distro which probably doesn't need it, and not for the one needing it...) | 16:38 |
| persia | toobaz, Why doesn't jaunty need it? | 16:38 |
| persia | Considering that it's the same binary for drgeo as intrepid, I can't understand why it might be fixed in Jaunty. | 16:38 |
| toobaz | not fixed, but certainly imported from Debian before anyone will ask about it | 16:39 |
| persia | But since it's not fixed in sid, that doesn't mean anything. | 16:39 |
| persia | The idea is to not have something in intrepid and not in jaunty, to avoid the chance of regression. | 16:39 |
| persia | What happens if sid isn't updated before DIF? | 16:39 |
| toobaz | persia: I'm following the Sid side... but still, if Sid is updated, is sync made only on explicit request?! | 16:40 |
| persia | There's ubuntu changes (drgeo | 1.1.0-1ubuntu2 | jaunty/universe | source, amd64, i386). merge is a manual action. | 16:41 |
| toobaz | persia: ok, thanks | 16:41 |
| persia | toobaz, For extra points, fix Jaunty, fix Intrepid, get the icon into sid along with your fix, and requset a sync. | 16:44 |
| persia | (this may take a couple months) | 16:44 |
| toobaz | persia: I will certainly do it. Still, it's sad for the time spent with an unusable package, and it makes me ask you the last question before stopping bothering. What is the base level to be accepted as a MOTU? https://wiki.ubuntu.com/MOTU/GettingStarted isn't really very clear about it. I provided some patches, am maintainer of a package (hopely 2 in Jaunty) from the Debian side... I do not really spend my life on Ubuntu, but from time to time I do help | 16:50 |
| persia | toobaz, There's no set criteria. The two areas considered are community integration and technical knowledge. | 16:52 |
| persia | It's rare that someone is approved with less than 10-15 packages, and some people reach 400 before applying. | 16:52 |
| persia | (that's package uploads, not maintained packages) | 16:52 |
| persia | It's rare that someone is approved if they haven't worked visibly in Ubuntu for a full release cycle, but some people have been approved in as little as six months (and some have been submitting patches since Warty and still aren't MOTU). | 16:53 |
| persia | Err. As little as three months. | 16:53 |
| persia | Most applicants have also contributed to Ubuntu development in some other ways, for example working on a QA script, or helping with REVU, or providing assistance to new people, or writing some documentation, or something. | 16:54 |
| === DrKranz is now known as DktrKranz | ||
| toobaz | persia: OK, get it. If I have enough time to spend on Jaunty, I will try. | 16:59 |
| === icf7_ is now known as icf7 | ||
| mok0 | Lots of packages in REVU have very useful non-MOTU comments, but unfortunately they still appear in the "Needs Review" queue | 17:35 |
| mok0 | I am just adding "Please address above comments" to those so they get moved to the "Needs work" queue. Please assist with this, so we can trim down the "Needs review" queue! | 17:39 |
| NCommander | mok0, good idea | 17:39 |
| * NCommander notes maybe we need a new REVU permission so people can mark things Needs Review, but not Add Advocation. | 17:40 | |
| mok0 | NCommander: We should allow contributors | 17:40 |
| mok0 | at least | 17:40 |
| * NCommander nods | 17:41 | |
| mok0 | Huh?? "libtuxcap" has a comment by persia, but still appears in "Needs Review"???? | 17:47 |
| DktrKranz | probably, comments on self-uploaded packages aren't considered | 17:49 |
| slytherin | mok0: +1. We need 'needs work' permission for UUC | 17:49 |
| mok0 | DktrKranz: Why would persia make comments on something to fix himself? | 17:49 |
| DktrKranz | mok0, I'd comment on my upload, just to state why I did changes. It's uncorrect to tag it "needs review" just because I didn't advocate my package | 17:51 |
| DktrKranz | I'll comment on my package, just to see what happens | 17:52 |
| mok0 | DktrKranz: I am confused. Look at the comments, they look like they're for someone else | 17:52 |
| DktrKranz | mh... | 17:54 |
| mok0 | Another weird entry is ccbuild. It has already been uploaded, it seems. If this is an update for a new version, it should go via LP | 17:55 |
| ScottK | NCommander and mok0: I disagree. UUC is based on community contribution, not technical proficiency. | 17:57 |
| NCommander | ScottK, to mark something Needs Work | 17:57 |
| NCommander | and that only? | 17:57 |
| mok0 | ScottK: We need to get a smoother workflow at REVU | 17:58 |
| mok0 | ScottK: It's clogging up with old entries that have useful comments from non-MOTUs that have not been addressed by uploaders | 17:58 |
| mok0 | ScottK: We are not talking about advocating | 17:59 |
| DktrKranz | anyway, if someone has some spare time: http://revu.ubuntuwire.com/details.py?package=amule-adunanza | 18:01 |
| mok0 | amule? That's illegal. Tsk tsk ;-) | 18:01 |
| DktrKranz | naah | 18:01 |
| DktrKranz | a knife is illegal | 18:02 |
| * persia emerges long enough to oppose mok0's suggestion, and recommend that MOTUs who find such comments ACK them to reject, that non-MOTU who leave such comments request ACK in-channel, before wandering off again. | 18:02 | |
| DktrKranz | but I use it to feed myself with some good meal | 18:02 |
| * mok0 attempts to parse persia's sentence | 18:02 | |
| mok0 | persia: many of these are from july-august | 18:03 |
| persia | mok0, Then the MOTU are slacking, and shouldn't do that. | 18:03 |
| mok0 | persia: REVU was neglected throughout the II cycle | 18:04 |
| persia | Further, the uploaders don't seem to be paying any attention to the comments, or they would have been reuploaded. | 18:04 |
| persia | It's a general failure by several parties, none of whom are those whose permission you are suggesting we change. | 18:04 |
| mok0 | persia: the uploaders might not have discovered that there is a comment | 18:04 |
| persia | Because they didn't look? | 18:04 |
| mok0 | persia: because they see their entry is still in the "needs review" queue | 18:05 |
| persia | We've enough upload & forget that encouraging more by making REVU go faster doesn't help. | 18:05 |
| persia | mok0, That's not dilligence, really. | 18:05 |
| mok0 | We've allowed non-MOTU to make comments, it does not make sense not to value that | 18:06 |
| persia | Especially because every comment went to a mailing list, and now it's further possible to subscribe on a per-package basis. | 18:06 |
| mok0 | It is also not exactly motivating for non-MOTUs to do a job reviewing | 18:06 |
| persia | They are valued. That's why they are permitted. They comments need review, which is why they don't do anything by default. | 18:07 |
| joaopinto | persia, you mean that mailing list constantly getting spammed :) ? | 18:07 |
| persia | joaopinto, perhaps. I only check the web archives, but I never noticed that much spam. | 18:07 |
| joaopinto | I only tried it a long time ago, during my first upload attempts, had to unsubscribe because of the spam | 18:08 |
| radix | isn't there some kind of notification of new comments? | 18:08 |
| persia | mok0, The motivation is supposed to be about helping others. Not about moving stuff around on a display. If helping others, or working to make packages better aren't motivations in their own right, I'm not sure those people should be reviewing. | 18:08 |
| joaopinto | comment should go to the uploaders, not to an ML | 18:08 |
| persia | radix, There is. | 18:08 |
| mok0 | MOTUs are pressed enough with things to do already. I don't see why we couldn't make use of the help we can get. We only ask uploaders to consider a comment | 18:08 |
| persia | joaopinto, It goes to both. | 18:08 |
| joaopinto | persia, just if it was implemented on the last monthes... | 18:09 |
| persia | mok0, How does rejecting a package from arbitrary commenter help? | 18:09 |
| siretart | doing review on REVU is only making me sad | 18:10 |
| mok0 | persia: it helps getting the packages fixed, plus filters out those where the uploader is inactive | 18:10 |
| persia | mok0, Given that I've seen plenty of non-MOTU comments on packages that were flat wrong, or based on cargo-culting, I'm really not excited about the prospect. | 18:10 |
| ScottK | mok0: It takes just a moment to review the comment and see if it's sensible. This is, IMO, better than allowing people with no particular technical background to push packages out of the review queue. | 18:10 |
| persia | No it doesn't help get packages fixed. It only does so if it's correct. | 18:10 |
| siretart | there are really people actually trying to submit packages that just install *.jar files without actually compiling them: http://revu.ubuntuwire.com/details.py?package=ted-tv :/ | 18:10 |
| persia | Many of the packages advocated by MOTU still have issues, so I'm *really* not convinced that non-MOTU won't make mistakes. | 18:10 |
| ScottK | mok0: The real answer is ignore the stuff from before October. Odds are they've been abandoned anyway. | 18:11 |
| mok0 | DktrKranz: do you remember the scoring system I proposed earlier this year? | 18:11 |
| persia | ScottK, Not necessarily. Best to go through it quickly. If it has a good comment, ACK the comment. | 18:11 |
| joaopinto | ScottK, wrong assumption, I have uploaded a package on August, addressed all the issues, and got no further reviews | 18:11 |
| persia | If it doesn't have a comment, check if it's against intrepid, and for other common issues, and leave a short note asking for update. | 18:11 |
| * RainCT is also against allowing UUC members to move stuff to "needs work" | 18:12 | |
| persia | 5 minutes max on each package. | 18:12 |
| ScottK | joaopinto: At the very least it needs updated for Jaunty. | 18:12 |
| DktrKranz | mok0, probably not, mind remember it to me? | 18:12 |
| mok0 | DktrKranz: I've forgotten it myself :-P I'll look it up in my old emails... | 18:12 |
| ScottK | joaopinto: I'm sure they aren't all abandoned, but given limited time, I'll focus on stuff someone obviously still cares about. | 18:12 |
| joaopinto | ScottK, so it's probably a good idea to notify uploaders about that | 18:12 |
| DktrKranz | heh | 18:12 |
| ScottK | joaopinto: I agree. RainCT wanted to do that and got shot down. | 18:13 |
| persia | joaopinto, How doesn't the email about Jaunty being open do that? | 18:13 |
| joaopinto | ScottK, same here, from an uploader perspective | 18:13 |
| persia | I agree that it's not appropriate to ignore old packages, but I don't agree it needs special notice. | 18:13 |
| joaopinto | persia, there is nothing on the REVU documentation describing that in case there are no reviewers available for my package I will need to resubmit on the next release | 18:14 |
| persia | joaopinto, Yes, but REVU doesn't exist in a vacuum. It's expected that anyone uploading to REVU is participating in wider Ubutnu development, which surely involves either subscription to ubuntu-devel-announce or casual checking of the archives on a regular basis. | 18:15 |
| siretart | joaopinto: no. that point is clear after reading the general ubuntu developer documentation. | 18:15 |
| joaopinto | siretart, not really, if that is clear, all the REVU queue should be archived during release change | 18:16 |
| persia | joaopinto, I don't like to do that because I think uploaders deserve a better comment than "please update" when the package is pointlessly broken. | 18:16 |
| ScottK | persia: But it | 18:17 |
| ScottK | ergh | 18:17 |
| ScottK | persia: But it's still better, IMO, than nothing, which is what they get now. | 18:17 |
| * slytherin leaves. will join later. | 18:17 | |
| persia | ScottK, The point is that they *shouldn't* get nothing. | 18:17 |
| NCommander | persia, CDBS packages are absolutely evil, but I think I got galculator properly split | 18:18 |
| persia | I'm still a bit burnt out on REVUing, and don't do more than a couple per REVU day, but there's no good reason for the gap between the top REVUer and the rest of you. | 18:18 |
| ScottK | persia: Yes. Good theory, but the practice appears to be either nothing or some semi-automatic "please update". | 18:18 |
| joaopinto | persia, that does not go with your previous statemente, if, as per your words, REVU uploads are subscribed to the lists, and are aware of the need to reupload, why should they need further communication about archiving on release cycle ? | 18:18 |
| persia | joaopinto, Because they deserve to have their packages reviewed. | 18:18 |
| * ScottK wonders where persia will find the additional reviewers? | 18:19 | |
| persia | ScottK, I don't really care. | 18:19 |
| joaopinto | persia, then, you still be reviewing without the changelog updated to jaunty ? | 18:19 |
| persia | If there aren't reviewers, automation doesn't help. | 18:19 |
| persia | joaopinto, Yes, but I won't advocate. | 18:19 |
| ScottK | Automation at least gives us some filter to decide what to focus on. | 18:20 |
| persia | Then again, I've advocated maybe 10 times, out of all my reviews. | 18:20 |
| persia | ScottK, How is a newer package better? | 18:20 |
| persia | ScottK, An older package may just need s/intrepid/jaunty/ | 18:20 |
| persia | A new package may have all sorts of problems. | 18:20 |
| ScottK | persia: The point is to be able to then ignore the ones that don't get updated and focus limited reviewing resourced where they will be useful. | 18:20 |
| siretart | given the amount of junk nowadays on REVU, I agree that we probably should allow any contributor to move packages to the 'needs review' section. | 18:20 |
| persia | ScottK, How is recent related to useful? | 18:21 |
| joaopinto | persia, it's just an indication that the reviewer is "alive", which seems to be a major issue right now, and causes "alive" users to not get their packages reviewed | 18:21 |
| persia | Sometimes when I review a package that is several months old, it gets updated in a couple days. | 18:21 |
| === nhandler_ is now known as nhandler | ||
| joaopinto | ops, i mean, the upload is alive | 18:21 |
| siretart | I imagine some kind of 'peer-review' dynamic which prioritizes good packages by itself | 18:21 |
| persia | Sometimes when I review a package that was uploaded today, it doesn't get updated for > 3 months. | 18:21 |
| persia | joaopinto, Not in my experince. | 18:22 |
| * jorgenpt coughs and shuffles his package under the table | 18:22 | |
| mok0 | A different priority algorithm on REVU's listings, that takes into account uploader activity and MOTU activity would definitely help. | 18:23 |
| persia | mok0, How does one define "activity"? | 18:23 |
| joaopinto | persia, I know at least 8 packages on the current queue from an uploader which is no longer available, I just have 2 to packages which need review, and I am sure I will be delayed by those 8 | 18:24 |
| persia | It can't be REVU-only, as most work has nothing to do with REVU. | 18:24 |
| mok0 | E.g. a package with high uploader activity and low MOTU activity gets a high priority | 18:24 |
| mok0 | persia: activity would be for example, delta time between uploads, quickness to respond to MOTU comments etc | 18:24 |
| RainCT | (this is https://blueprints.edge.launchpad.net/revu/+spec/activity-scores, btw) | 18:24 |
| mok0 | RainCT: Ah yes, there it is :-) | 18:25 |
| persia | Oh, I'm not opposed to ranking uploads based in part on responsiveness, although I worry that someone will game it by uploading a lot even when the package it patently broken. | 18:26 |
| mok0 | persia: that's no different from now | 18:26 |
| persia | There were a couple cases in the past where a package would get repushed without addressing core concerns, but with fixes for minor unrelated stuff, and it had to be re-rejected. | 18:26 |
| persia | mok0, Hrm? How can the current algorithm be gamed? | 18:27 |
| mok0 | persia: upload w/o fixing all problems | 18:27 |
| mok0 | persia: just to move into the review queue again | 18:27 |
| persia | mok0, That puts them at the bottom of the queue though, so it's not quite the same. | 18:27 |
| mok0 | Hm, my impression is that the queue is processed from the bottom | 18:28 |
| persia | Well, people should process it from the top then. | 18:28 |
| joaopinto | mok0, I hope not | 18:28 |
| persia | Processing from the bottom only makes the perceived problem worse | 18:28 |
| mok0 | Because many reviewers like the fast ping-pong with the uploader | 18:29 |
| handschuh | mok0: indeed! | 18:29 |
| persia | mok0, Well, you can't both have few old packages and not process FIFO. Anything else just means ignoring packages, which is bad. | 18:30 |
| * NCommander notes I had the queue ordering reversed so the newest went ontop | 18:30 | |
| mok0 | persia: the topmost entry is from May. It has not been reviewed | 18:30 |
| NCommander | that change was backed out | 18:30 |
| persia | In fact, reviewing new packages first encourages upload racing by uploaders, which exhausts REVU resources faster. | 18:30 |
| persia | mok0, Then review it. There's surely something wrong with it. | 18:31 |
| mok0 | persia: exactly why I propose another priority algorithm | 18:31 |
| persia | mok0, How does that help the age problem? | 18:32 |
| mok0 | persia: the most active uploaders should be rewarded. The priority could include a quality grading by MOTU | 18:32 |
| persia | No, the most active contributors to Ubuntu should be rewarded. | 18:32 |
| persia | Rewarding the most active uploaders encourages people to use REVU and not fix bugs. | 18:33 |
| persia | This encourages upload & forget. | 18:33 |
| persia | This is counterproductive. | 18:33 |
| mok0 | persia: Obviously I don't agree with that | 18:33 |
| persia | Which part, and precisely why? | 18:33 |
| ScottK | persia: With insufficient reviewers, packages will, by definition, get ignored. The question is not if, but which packages to ignore. | 18:33 |
| mok0 | persia: I am not advocating a system that I think is counterproductive | 18:34 |
| persia | ScottK, Yes, but I have yet to hear a convincing argument that new == good. | 18:34 |
| persia | mok0, Do you not agree that upload&forget is counterproductive? | 18:34 |
| mok0 | persia: I want reviewers to spend time on the best and most active uploaders | 18:34 |
| ScottK | persia: New == at least someone will likely be there to respond to the comments. | 18:34 |
| persia | ScottK, Is it your experience, from your work with REVU, that recent uploads are more likely to have repeat uploads sooner? | 18:35 |
| ScottK | So there is less chance of investing a bunch of time in a detailed review for someone who is no longer listening. | 18:35 |
| ScottK | persia: Yes. | 18:35 |
| mok0 | ScottK: exactly | 18:35 |
| persia | Have either of you reviewed significant numbers of older packages? | 18:35 |
| ScottK | persia: Not recently, but in previous cycles I have. | 18:36 |
| mok0 | Why has no one reviewed the first 3 REVU entries? | 18:36 |
| handschuh | maybe there should be an automated email to the author of the package if there was a comment added (there is a setting to do this, but it doesnt work) | 18:36 |
| RainCT | handschuh: it doesn't? have you activated this in the preferences? | 18:37 |
| handschuh | RainCT: "Yes, I want to receive email notifications about everything related to my uploads. | 18:37 |
| handschuh | " is checked | 18:37 |
| persia | ScottK, Well, it's not been my experience, but then again, I mostly got the queue down to about 1 month maximum, so maybe that made some of the difference. | 18:38 |
| handschuh | RainCT: and I never got an email from revu | 18:38 |
| RainCT | handschuh: is your preferred address correct? | 18:38 |
| joaopinto | what is the major bottleneck right now ? The lack of reviewing, or the lack of activity from uploaders ? | 18:38 |
| RainCT | (and have you just got a mail?) | 18:38 |
| mok0 | joaopinto: both | 18:39 |
| handschuh | RainCT: I assume so, at least I get mails from launchpad | 18:39 |
| RainCT | joaopinto: the "needs review" queue is significantly longer than "needs work" | 18:39 |
| persia | I think the only bottleneck is lack of reviewing. If it was lack of uploader activity, there wouldn't be a backlog. | 18:39 |
| RainCT | handschuh: no, I mean about jaolt (I've just commented on it after subscribing myself, and I got the notification) | 18:39 |
| ScottK | joaopinto: Lack of reviewers was the main problem for Intrepid. We seem to be doing much better so far in Jaunty, but there's always much more to review than we can look at. | 18:39 |
| mok0 | persia: if you look at the queue, there are instances of individuals having uploaded a series of packages within a few days | 18:40 |
| persia | mok0, Yes. | 18:40 |
| persia | mok0, How is this relevant? | 18:40 |
| mok0 | persia: none of those have gotten reviewed. | 18:40 |
| persia | mok0, Then review them. | 18:40 |
| mok0 | persia: Most likely because reviewers avoid then thinking "this guy's gone" | 18:41 |
| joaopinto | festor90@gmail.com is no longer available | 18:41 |
| handschuh | RainCT: you mean the address that is used for uploading it? It is also correct. | 18:41 |
| RainCT | handschuh: no, the address which is displayed in your preferences page | 18:41 |
| mok0 | persia: I have reviewed stuff here on IRC during REVU days | 18:41 |
| persia | mok0, OK. There's a few things here. Firstly, I don't like the idea of package ownership. If there's a good package, and it's aging, anyone can update it. | 18:41 |
| persia | Secondly, I think that packages that get repeatedly reviewed by a single reviewer tend to be poor quality. This makes me especially against any scoring system based on quick response. | 18:42 |
| joaopinto | I would limit the nr of pending review packages/user | 18:42 |
| mok0 | persia: the "needs work" queue does not list the year, but there are some that I think are more than one year old | 18:42 |
| handschuh | RainCT: <blank/> | 18:42 |
| mok0 | persia: e.g. "gcutils" | 18:43 |
| joaopinto | to avoid mass uploads | 18:43 |
| persia | mok0, I know that not to be true because the queue was cleared on new year's day last year. | 18:43 |
| RainCT | handschuh: OK. I need to write some code to get the e-mail address from LP, will do this now | 18:43 |
| persia | mok0, The reason the three odd dates are on the top is because they got an advocation before being rejected. | 18:44 |
| handschuh | RainCT: ok, thanks a lot :-) | 18:44 |
| mok0 | persia: I see | 18:44 |
| mok0 | persia: now you're here, what's up with libtuxcap? | 18:47 |
| persia | mok0, I failed to delete a comment, was convinced that an upload would work, and assign to the user in the changelog, discovered this was incorrect, and tried to reject the upload. | 18:48 |
| persia | If it didn't reject, please ACK the rejection to get it into needs-work. | 18:48 |
| mok0 | joaopinto: you suggest we archive festor's packages? | 18:48 |
| NCommander | persia, I can delete rejections if need be | 18:48 |
| persia | NCommander, Can you delete an upload? | 18:49 |
| NCommander | yes | 18:49 |
| NCommander | Which one? | 18:49 |
| persia | Can you delete my libtux upload and reassign my comment to the previous upload? | 18:49 |
| NCommander | oh | 18:49 |
| persia | libtuxcap | 18:49 |
| mok0 | persia: done | 18:49 |
| NCommander | I can only delete entire packages | 18:49 |
| NCommander | Not individual uploads | 18:49 |
| persia | That's different. | 18:49 |
| NCommander | Yeah :-P | 18:50 |
| persia | It doesn't deserve to be nuked (I can do that). But the upload would benefit from deletion. | 18:50 |
| persia | mok0, Thanks. | 18:50 |
| NCommander | Just reverse-apply the debdiff and reupload, I can reassign the original package owner if need be | 18:50 |
| * persia really goes away again | 18:50 | |
| joaopinto | mok0, yes, he is gone | 18:50 |
| persia | NCommander, Just reassign it then. It's a no-change upload. | 18:50 |
| RainCT | persia: I'll add a "Remove upload" option to details.py (the code for this should already be there) | 18:50 |
| * NCommander hugs RainCT | 18:50 | |
| mok0 | joaopinto: OK I will archive them | 18:50 |
| persia | RainCT, It's a rare enough use case it probably doesn't need a UI, but would be handy to have from the CLI. | 18:51 |
| * handschuh thanks RainCT for the delete-option | 18:51 | |
| mok0 | joaopinto: thanks festor's packs are now archived | 18:52 |
| ScottK | mok0: Did you mean to knock plasmoid-memusage down into needs work? | 18:53 |
| mok0 | ScottK: let me take a look... | 18:54 |
| mok0 | ScottK: It was not intentional, but how could I comment without it moving? | 18:54 |
| ScottK | mok0: You can't. | 18:55 |
| mok0 | ScottK: I would like the guy to work on the default colours though | 18:55 |
| ScottK | mok0: I agree, but I think that's an upstream issue. | 18:55 |
| mok0 | ScottK: Hmm, it could be fixed with a local patch | 18:55 |
| mok0 | ScottK: Upstream may not like the Kubuntu pallette | 18:56 |
| ScottK | mok0: I suppose. I guess I think it's be better to upload it and file a bug or some such, but up to you. | 18:56 |
| * RainCT hugs NCommander and handschuh back | 18:56 | |
| mok0 | ScottK: I can add advocation and it will pop right to the top :-) | 18:57 |
| RainCT | mok0: neutral comments are planned | 18:57 |
| RainCT | (neutral = don't move the package from where it is) | 18:57 |
| mok0 | ScottK: what about the font size issue? | 18:58 |
| ScottK | mok0: I think that may be a problem on my system. I've had some other issues and since it didn't affect you, I'm not thinking it should block. | 18:59 |
| ScottK | mok0: If you add advocation, then it's ready for upload. | 18:59 |
| mok0 | ScottK: I am OK with the packaging, the app works, the fact that it's ugly is not a blocker I guess. | 18:59 |
| mok0 | s/fact/my opinion/ | 19:00 |
| ScottK | mok0: I think not supporting Kubuntu style would block moving to Main in the default install, but not for getting in, I don't think. | 19:00 |
| mok0 | ScottK: ok | 19:00 |
| mok0 | ScottK: It's now at the top | 19:01 |
| ScottK | mok0: Just upload it then. | 19:01 |
| mok0 | ScottK: OK | 19:01 |
| RainCT | handschuh: can you try logging in again now, and check if it sets your email address? | 19:09 |
| * handschuh hugs RainCT for fixing the email issue this fast | 19:11 | |
| handschuh | RainCT: so yes, the coorect address is beeing displayed | 19:12 |
| RainCT | handschuh: you've got mail, then :) | 19:12 |
| handschuh | RainCT: thanks a lot | 19:15 |
| * handschuh has to go home now | 19:15 | |
| * mok0 < dinner | 19:18 | |
| binarymutant | if anyone has time to review and help with my package http://revu.ubuntuwire.com/details.py?package=charm, I would appreciate it a lot, thanks :) | 19:44 |
| nellery | Laney: are you still working on the Bug #233963 merge? | 19:55 |
| ubottu | Launchpad bug 233963 in gnome-chemistry-utils "Please merge gnome-chemistry-utils 0.8.7-2 from Debian/unstable" [Undecided,Confirmed] https://launchpad.net/bugs/233963 | 19:55 |
| stefanlsd | RainCT: u were telling me bout geany | 20:13 |
| binarymutant | the debian/compat # should be the same as the debhelper version? | 20:23 |
| NCommander | bigon, yeah | 20:24 |
| NCommander | er binarymutant | 20:24 |
| binarymutant | thank NCommander :) | 20:24 |
| NCommander | compat is a hint to debhelper to what version it needs to emulate | 20:24 |
| binarymutant | okay cool, I thought so but never paid any attention to it. thanks again NCommander :) | 20:25 |
| NCommander | binarymutant, its one of those set it and forget things | 20:25 |
| binarymutant | is there a way to get the same kind of reviews that REVU does at mentors.debian.net too? Besides the mentors mailing list? | 20:34 |
| nhandler | binarymutant: You could ask people in the Debian Mentors channel to look at it | 20:35 |
| RainCT | stefanlsd: so? | 20:35 |
| binarymutant | nhandler, great idea thanks :) | 20:36 |
| nhandler | You're welcome binarymutant. | 20:36 |
| NCommander | hey nhandler and RainCT | 20:37 |
| nhandler | Hi NCommander | 20:37 |
| RainCT | nhandler: hi again | 20:37 |
| NCommander | nhandler, I just uploaded package 100 :-) | 20:37 |
| * iulian looks around. | 20:38 | |
| nhandler | NCommander: Package 100 for jaunty? Or in general? | 20:40 |
| NCommander | in general | 20:40 |
| nhandler | and hi RainCT | 20:40 |
| handschuh | NCommander: want to upload pacakge 100? -> http://revu.ubuntuwire.com/details.py?package=balloontip :-) | 20:41 |
| NCommander | Already uploaded package 100 | 20:41 |
| NCommander | You'd be 101 | 20:41 |
| nhandler | NCommander: What are you using to get that number? UTU? | 20:41 |
| NCommander | nhandler, Launchpad | 20:42 |
| NCommander | nhandler, I've had 100 distinct uploads | 20:42 |
| nhandler | Well, last I heard, the LP number isn't always 100% correct. So you very well could have more uploads than that ;) | 20:42 |
| handschuh | s/100/101 (sry) | 20:43 |
| NCommander | handschuh, what does the patch do? | 20:43 |
| nhandler | I'm hoping to NCommander According to LP, I have 200 packages ;) I'm hoping that I will be able to get 300 during the Jaunty dev cycle. | 20:44 |
| NCommander | heh | 20:44 |
| NCommander | nice | 20:44 |
| NCommander | handschuh, I need you to add the rational and reason for the patch to the changelog | 20:44 |
| NCommander | Add something like this under Inital Release | 20:45 |
| NCommander | * debian/patches/build-xml.diff | 20:45 |
| NCommander | - This patch does X,Y,Z because of | 20:45 |
| NCommander | Or something to that affect | 20:45 |
| handschuh | NCommander: ok damn .. I will fix this | 20:45 |
| NCommander | (the - should be indented two spaces past *) | 20:45 |
| NCommander | There are no other issues, so once you do that, I'll advocate and upload | 20:45 |
| NCommander | mok0, ping | 20:45 |
| nhandler | handschuh: What patch system are you using? | 20:45 |
| NCommander | He's using simple-patch-sys | 20:46 |
| handschuh | nhandler: I think its from cdbs | 20:46 |
| nhandler | NCommander: I can't remember, does simple-patch-sys expect a description of the patch at the very top? | 20:46 |
| nhandler | I know dpatch does | 20:46 |
| NCommander | nhandler, only dpatch does | 20:46 |
| nhandler | Ok, I couldn't remember. Thanks | 20:46 |
| NCommander | nhandler, you can add it on quilt. I dunno about cdbs, but as a general rule of thumb, I require all patches to be noted in changelog | 20:47 |
| nhandler | Yeah, having them in the changelog is good. But I still feel having them in the patch makes it much easier to quickly check what a patch is meant to do. That way, you don't need to hunt through a changelog. | 20:48 |
| NCommander | nhandler, its helpful on a future merge should debian ever package this | 20:48 |
| nhandler | I never said having it in the changelog isn't useful ;) | 20:49 |
| handschuh | NCommander: how is that: http://paste.ubuntu.com/72529/ ? | 20:49 |
| NCommander | handschuh, looks good, but mind adding the reason why you do that? | 20:49 |
| handschuh | NCommander: otherwise the build fails because it tires to copy files into bin - I will add that, too | 20:50 |
| NCommander | The reason I ask for that is if someone else ever updates the package, they won't know why its there | 20:51 |
| nhandler | handschuh: Also, have you considered submitting these packages to Debian? | 20:51 |
| handschuh | nhandler: i will do that (submitting)! | 20:52 |
| nhandler | Great handschuh. | 20:52 |
| NCommander | nhandler, how are you not an MOTU? | 20:53 |
| nhandler | NCommander: I applied a few days ago | 20:53 |
| nhandler | I have 2 +1's. I am waiting for the third | 20:53 |
| handschuh | NCommander: http://paste.ubuntu.com/72532/ | 20:53 |
| NCommander | nhandler, you need the full six now | 20:53 |
| nhandler | Do y/ | 20:53 |
| nhandler | Do you really? | 20:53 |
| NCommander | nhandler, yeah :-/ | 20:54 |
| nhandler | When did they change that? | 20:54 |
| NCommander | August | 20:54 |
| NCommander | handschuh, better, but changelog entries can't be more than 80 characters per line | 20:54 |
| * nhandler goes to check the archives | 20:54 | |
| NCommander | You need to line wrap it or lintian will complain | 20:54 |
| stefanlsd | RainCT: yeah, i hadnt tried it, but i've been using for some python stuff, and i really like it | 20:54 |
| handschuh | NCommander: http://paste.ubuntu.com/72534/ :-) | 20:55 |
| NCommander | handschuh, tada! | 20:55 |
| NCommander | Upload the package with that to REVU, and I'll look it over one more time | 20:55 |
| * handschuh is happy | 20:55 | |
| NCommander | RainCT, ping | 20:56 |
| NCommander | handschuh, ping me once its uploaded and you can see it on REVU | 20:57 |
| handschuh | NCommander: it is uploaded | 20:58 |
| NCommander | ok, building | 21:00 |
| NCommander | handschuh, has anyone explained to you the NEW queue? | 21:00 |
| handschuh | NCommander: No | 21:01 |
| NCommander | handschuh, ok, when a NEW package is uploaded to Ubuntu, it doesn't automatically enter the archive | 21:01 |
| NCommander | It gets stuck in NEW | 21:01 |
| NCommander | As the name suggests, its for new and unreviewed packages | 21:01 |
| NCommander | the Archive Administrators will review your package, and assuming they don't find anything wrong, add an override to allow it to enter the archive | 21:01 |
| NCommander | This process can take up to a week (usually less however) | 21:02 |
| handschuh | NCommander: What if they find something they do not like? | 21:02 |
| NCommander | handschuh, the package is rejected, and both you and your sponsor will get an email on why | 21:03 |
| NCommander | It's pretty rare when a package goes through REVU, and then gets a REJECT | 21:03 |
| handschuh | NCommander: ok | 21:03 |
| nhandler | NCommander: I just looked at a few MOTU application results for August. They only needed 3 +1's | 21:04 |
| NCommander | nhandler, look at mine | 21:04 |
| * NCommander might have found another mistake | 21:04 | |
| nhandler | Yes, they might all have voted, but I don't think it is a requirement | 21:04 |
| NCommander | nhandler, I asked | 21:04 |
| NCommander | handschuh, Your package generates the binary balloontip-java, but the source package is balloon | 21:04 |
| NCommander | Is that by design? | 21:05 |
| handschuh | NCommander: I was told to do so | 21:05 |
| NCommander | I don't see anything in the comments | 21:05 |
| nhandler | NCommander: It was on IRC | 21:06 |
| NCommander | Ok | 21:06 |
| NCommander | This is a library, or an application | 21:06 |
| handschuh | NCommander library | 21:06 |
| NCommander | bah | 21:06 |
| * NCommander makes a note to talk to mok0 | 21:06 | |
| NCommander | People need to read the Java packaging manual | 21:07 |
| NCommander | YOu need to make a few more changes sadly | 21:07 |
| NCommander | oh wait | 21:07 |
| NCommander | nm | 21:07 |
| NCommander | Ok | 21:07 |
| NCommander | I'm trying to figure out why you need -java in the name | 21:08 |
| NCommander | And now I know | 21:08 |
| * NCommander has never packaged or reviewed a java library, so I'm doing a quick crash course w/ the manual | 21:08 | |
| handschuh | :-) | 21:08 |
| NCommander | handschuh, this is all bytecode, no JNI/native? | 21:08 |
| handschuh | NCommander: yes, no JNI | 21:09 |
| NCommander | ok | 21:09 |
| NCommander | handschuh, where do you document your classpath? | 21:10 |
| handschuh | NCommander: classpath? | 21:11 |
| * NCommander sighs | 21:11 | |
| NCommander | Sorry, I can't +1 this just yet | 21:11 |
| NCommander | Still needs some more tweaks, but its close | 21:11 |
| handschuh | NCommand: I know .. noone cans | 21:11 |
| handschuh | NCommander: which I cannot bevieve ;-) | 21:12 |
| NCommander | hrm | 21:12 |
| NCommander | Upstream hasn't versioned the library? | 21:12 |
| handschuh | NCommander: just the zip-file they offer for download | 21:12 |
| * NCommander sighs | 21:13 | |
| NCommander | I need a java packaging expert | 21:13 |
| NCommander | The policy states java librarys should be names lib*name*-*fullversion*-java | 21:13 |
| handschuh | as a package name? | 21:13 |
| handschuh | NCommander: well that doesn't apply to all java packages ... | 21:14 |
| nhandler | NCommander: I just looked at smarter's application (https://lists.ubuntu.com/archives/motu-council/2008-October/001693.html). That is from October. He only had 3. Somehow, I still think 3 +1's is still the policy | 21:14 |
| * NCommander takes a look | 21:14 | |
| NCommander | I asked geser and nxinternal | 21:15 |
| NCommander | ok | 21:15 |
| nhandler | Are you sure you understood them correctly? I also haven't seen any message sent to the mailing lists announcing the policy change | 21:15 |
| NCommander | Looking at the packages in the archive | 21:15 |
| NCommander | nhandler, Yes, I'm sure | 21:15 |
| NCommander | handschuh, ok ... hrm | 21:16 |
| handschuh | NCommander: if something is even slighly wrong, just tell :-) | 21:17 |
| handschuh | NCommander: I will use this package as a template, so any mistake will be in other packages, too | 21:19 |
| NCommander | I don't see anything wrong | 21:19 |
| NCommander | Lintian clear | 21:19 |
| NCommander | Rules look fine | 21:19 |
| sebner | nhandler for MOTU! :D | 21:21 |
| NCommander | handschuh, advocated | 21:21 |
| nhandler | sebner: Your application is still open too, isn't it? | 21:22 |
| * handschuh also wants nhandler to be a MOTU | 21:22 | |
| nhandler | :) | 21:22 |
| handschuh | NCommander: thanks a lot | 21:22 |
| handschuh | now I have to talk to mok0 again | 21:22 |
| sebner | nhandler: every application is open ;P | 21:23 |
| NCommander | handschuh, no, I think I can upload without a second advocation since I had you make such a minor change | 21:23 |
| handschuh | mok0: ping | 21:23 |
| * NCommander is a REVU admin, but this is the first time I've actually sponsored a REVU upload | 21:23 | |
| handschuh | NCommander: ah ok, great | 21:23 |
| * handschuh is honored | 21:23 | |
| handschuh | NCommander: thanks a lot! | 21:24 |
| NCommander | handschuh, ok, I can upload it, I just want to retest build it, and then I'll upload | 21:25 |
| nhandler | NCommander: Remember to send an email to the mailing list after you upload | 21:25 |
| NCommander | nhandler, ? | 21:25 |
| NCommander | what mailing list | 21:25 |
| nhandler | I believe you are meant to notify the ubuntu-motu mailing list when you upload a revu package | 21:26 |
| nhandler | Although it might be the dev mailing list | 21:26 |
| sebner | nhandler: both? | 21:26 |
| NCommander | nhandler, I don't remember that for codeblocks | 21:26 |
| nhandler | sebner: I don't know. I just remember hearing that somewhere. Let me try to find the wiki page | 21:26 |
| * sebner thinks he saw 2 mail for codeblocks | 21:27 | |
| sebner | *mails | 21:27 |
| NCommander | sebner, well yes, codeblocks got rejected :-) | 21:27 |
| sebner | heh | 21:27 |
| * NCommander reminds himself how most packages that get two advocations don't usually get rejected :-P | 21:28 | |
| NCommander | Yeah .... :-P | 21:28 |
| james_w | stefanlsd: hey. Could I ask that you include the new debian/changelog entries in sync requests? It speeds up easy ones a lot. requestsync will automate that. | 21:29 |
| NCommander | It doesn't say anything on the wiki | 21:29 |
| james_w | NCommander: it is preferred | 21:29 |
| NCommander | to motu or devel? | 21:30 |
| james_w | it's not always remembered though | 21:30 |
| james_w | motu, they are the maintainers | 21:30 |
| stefanlsd | james_w: will do | 21:30 |
| james_w | stefanlsd: thanks | 21:30 |
| nhandler | I thought so, thanks for confirming james_w | 21:30 |
| NCommander | handschuh, Your package has been uploaded to Ubuntu Jaunty and is now pending in the NEW queue. | 21:31 |
| NCommander | handschuh, Thank you for your contribution to Ubuntu. | 21:31 |
| james_w | NCommander: forward the NEW email to -motu prefixed with [REVU] please | 21:31 |
| handschuh | NCommander: thanks :-) more is comming tomorrow :-) | 21:31 |
| * NCommander archives the REVU upload | 21:32 | |
| NCommander | handschuh, you can see the NEW queue here | 21:32 |
| NCommander | NCommander: | 21:32 |
| NCommander | er | 21:32 |
| NCommander | https://edge.launchpad.net/ubuntu/jaunty/+queue?queue_state=0&queue_text= | 21:32 |
| handschuh | Nice! | 21:32 |
| * handschuh feels good now | 21:35 | |
| RainCT | stefanlsd: cool :) | 21:36 |
| RainCT | NCommander: pong | 21:36 |
| NCommander | RainCT, too late :-P | 21:36 |
| NCommander | handschuh, feel free to ping me if you need a sponsor for NEW or universe/multiverse | 21:36 |
| handschuh | NCommander: thanks ... the next package will has proper versioning, i think | 21:37 |
| NCommander | yay, more java | 21:37 |
| handschuh | NCommander: yes this is all i do :-) | 21:37 |
| NCommander | Try some native code instead :-P | 21:38 |
| nhandler | handschuh: Was that the only package holding up jaolt? | 21:38 |
| NCommander | http://launchpadlibrarian.net/19678214/buildlog_ubuntu-jaunty-armel.newt_0.52.2-11.3ubuntu1_FAILEDTOBUILD.txt.gz | 21:38 |
| handschuh | nhandler: unfortunatly not ... there are 4 more missing | 21:38 |
| jmarsden | NCommander: Looks good. I think https://edge.launchpad.net/ubuntu/jaunty/+queue?queue_state=0 has the same effect and is shorter... does the trailing &queue_text= have any real effect on what is displayed? | 21:38 |
| NCommander | Anyone beside me bugged that the armel builder pull libraries from Debian ATM? | 21:38 |
| NCommander | jmarsden, no idea | 21:38 |
| handschuh | NCommander: whats native code? ;-) | 21:39 |
| NCommander | jmarsden, I used to be an admin on FSF Savannah. I have high standards when I review stuff | 21:40 |
| jmarsden | OK... Did you just negatively review something I did?? | 21:40 |
| NCommander | jmarsden, ? | 21:41 |
| RainCT_ | bah.. hard freeze :/ | 21:41 |
| * NCommander hasn't reviewed anything aside from handschuh's package | 21:41 | |
| === RainCT_ is now known as RainCT | ||
| NCommander | RainCT, I thought we were in soft freeze main-onky | 21:42 |
| NCommander | *only | 21:42 |
| jmarsden | NCommander: OK... so why did you just say: [13:40:07] <NCommander> jmarsden, I used to be an admin on FSF Savannah. I have high standards when I review stuff | 21:42 |
| NCommander | jmarsden, Oh, I'm sorry if that came out wrong | 21:42 |
| jmarsden | I'm just not sure why it was addresed to me in particular? | 21:42 |
| RainCT | NCommander: what? XD No, my PC frozed :/ | 21:42 |
| NCommander | jmarsden, oh, you said "Looks good." | 21:42 |
| NCommander | jmarsden, I was responding to that | 21:42 |
| jmarsden | Ah, OK. | 21:43 |
| RainCT | somehow that's happening quite often lately (and I think I had never seen this before Intrepid) :S | 21:43 |
| coppro | my only issue is with fglrx (x won't start with it installed) | 21:43 |
| * RainCT waits for the last half hour of irc log to come up on irclogs.ubuntu.com | 21:44 | |
| NCommander | I find that things have been very stable for me | 21:44 |
| RainCT | well, if there wasn't this problem with the freezes and that I can't enter GNOME, this would have been the best release for me, too | 21:44 |
| NCommander | RainCT, do you want me to review bot-sentry? | 21:45 |
| RainCT | NCommander: sure :) | 21:45 |
| sebner | RainCT: GNOME! \o/ | 21:47 |
| NCommander | RainCT, anything I should look out for on this package specifically? | 21:47 |
| james_w | NCommander: I'm on it | 21:49 |
| NCommander | james_w, ? | 21:49 |
| james_w | NCommander: I'm halfway through a review | 21:49 |
| NCommander | oh | 21:50 |
| james_w | of bot-sentry | 21:50 |
| NCommander | the needs review list is extreme long :-/ | 21:50 |
| NCommander | handschuh, I recommend if your interested in Ubuntu development, you should also get a feel for triaging bugs, and working towards full MOTU | 21:51 |
| handschuh | NCommander: will do that! | 21:53 |
| james_w | NCommander: so's the sponsor queue | 21:54 |
| * NCommander has been putting a dent in the later | 21:54 | |
| james_w | tdomhan: uploaded, thanks for your contribution to Ubuntu. | 21:56 |
| NCommander | \o/ | 21:56 |
| tdomhan | james_w: great, thank you :D | 21:58 |
| james_w | tdomhan: https://edge.launchpad.net/ubuntu/+source/bot-sentry is available for you to subscribe | 21:58 |
| james_w | and good luck with your quest to find a sponsor in Debian | 21:59 |
| geser | NCommander, nhandler: re applications: you need a majority (3 +1 votes) but we (the MC) try to wait till all members had the opportunity to vote before announcing the result | 22:05 |
| nhandler | geser: Thanks for clearing that up. | 22:05 |
| ScottK | NCommander: Turns out I was totally out to lunch on the libspf2 glibc_private thing. Magnus Holmgrean (Debian maintainer) sent me a patch. | 22:16 |
| NCommander | yay lunch :-P | 22:17 |
| ScottK | Just uploaded it. Have a look. | 22:17 |
| NCommander | Another lpia specific evil magic package destoried | 22:18 |
| NCommander | wooo | 22:18 |
| RainCT | NCommander: what was your question? wheter you've to forward the mail to -motu@? | 22:21 |
| NCommander | RainCT, yeah, it was answered | 22:21 |
| NCommander | geser, ping | 22:38 |
| NCommander | nixternal, ping | 22:40 |
| nixternal | NCommander: pongalong | 22:41 |
| handschuh | Can I have a package that only has one source file? | 23:01 |
| === fta_ is now known as fta | ||
| ScottK | handschuh: Yes. | 23:02 |
| handschuh | ScottK: ok great, thanks | 23:03 |
| RainCT | gouki_: ""I don't want to spend time maintaining an Operating System." what are you doing here? *g* | 23:14 |
| RainCT | gouki_: your website is cool, btw :) | 23:15 |
| NCommander | apachelogger, ping? | 23:42 |
| binarymutant | if anyone has time to review and help with my package http://revu.ubuntuwire.com/details.py?package=charm, I would appreciate it a lot, thanks :) | 23:48 |
| persia | binarymutant, Are you sure you can use debhelper 5.0.0? I seem to remember some python changes during the 5.x cycle which might affect you: it's probably worth double-checking the debhelper changelog. | 23:49 |
| * persia processes some UUC applications | 23:50 | |
| binarymutant | persia, I didn't actually check it out, I was requested to change it by sistpoty for backports; but I'll check it out now | 23:51 |
| persia | binarymutant, Well, you're definitely using dh5 style packaging, but you might need something like 5.0.39 or something for the python_central stuff (version is made up, and may not actually reflect a meaningful milestone) | 23:53 |
| NCommander | hey persia | 23:54 |
| persia | NCommander, Good day. | 23:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!