[00:06] if anyone has the time to review my package charm, http://revu.ubuntuwire.com/details.py?package=charm, I would be greatly appreciative. Thanks :) [00:31] is there a way to override dch -i putting 'jaunty' as the release? [00:31] with a text editor? [00:33] man dch, there is a parameter for that [00:33] dch -D foo [00:33] OK, found it. thanks === bddebian2 is now known as bddebian [00:59] So I have built the package, am I right in thinking that debsign goes out to a key repository because it gives me an error, and it never asks for my passphrase. [01:01] building it unsigned is fine for this pass, but I probably do need get the keys figured out so that I can build official packages for replicator :-) [01:01] it uses your local keyring [01:02] but it looks for a key with a UID which byte-for-byte matches what is in debian/changelog [01:02] you can tell it what key to use with the -k option, or make debian/changelog match a UID on the desired key [01:05] Are PPA packages signed with maintainer's key? [01:06] No. [01:20] Source is [01:20] Ok, I am almost positive that there is something wrong with pbuilder (or the related packages) for intrepid [01:22] nhandler: Then how come you're the only one with a problem? [01:22] That I know of anyway.... [01:22] ScottK: I have no clue. But I just did a fresh install (again) with the same problem. [01:22] Since I'm using the same pbuilderrc as some other people, I don't think that is the issue [01:22] nhandler: Want my pbuilder wrapper script? [01:23] ScottK: Let me see it. vorian already had me try one which failed [01:23] After I saw you discuss this last, I made a new one with it. [01:23] OK. [01:24] nhandler: http://pastebin.com/f659051c5 [01:27] * ScottK considers the very idea of php-gnupg as questionable. [01:41] ScottK: The wrapper script failed too. [01:42] nhandler: which debootstrap are you using? [01:42] backport? [01:42] vorian: Yeah, 1.0.10ubuntu1~intrepid1 [01:43] hmmm [01:43] I even tried the jaunty debootstrap a few days ago, but it didn't help [01:46] nhandler: What error? I've forgotten [01:51] wgrant: when you have a minute, please ping me re: MOTU Science team issues === _neversfelde is now known as neversfelde [02:02] ScottK: Err http://archive.ubuntu.com jaunty/main libcwidget3 0.5.12-3ubuntu1 Could not resolve 'archive.ubuntu.com' [02:02] (That comes up for all of the packages) [02:04] ie hte /etc/resolv.conf in the pbuilder is wrong. strange... [02:39] Hobbsee: Is there any way to fix that? Since the chroot isn't created, I can't do a pbuilder login [02:48] nhandler: You can run debootstrap by hand, and try and correct any problems it comes up with [02:50] I'll give that a try StevenK [02:52] nhandler: use pbuilder login --save-after-login? [02:56] vorian: would you mind checking out my changes to http://revu.ubuntuwire.com/details.py?package=wxbanker when you have a minute? [02:56] I dont think you can login until after its created. [02:56] oh, the problem is creating it in the first place. got it [02:56] vorian: I found a package using the same icon set as I am, so that was super helpful :) [02:58] nhandler: you're not running a local nameserver or anything, are you? === bluesmoke_ is now known as Amaranth [03:24] nhandler: You don't happen to have the resolveconf package installed do you? [03:24] Err resolvconf [03:26] that too [04:55] I am going to ask what may sound as a dumb question but please be patient. [04:56] Both the PackageUpdate and MOTU/TODO encourage us to be merging and syncing. [04:57] The sync page asks that we only request syncs that improve Ubuntu. [04:57] But the reaity is there are several packages that would improve Ubuntu through bug fixes and new features. It really is subjective. [04:57] What is the rule of thumb when making these requests? [04:57] This is correct. [04:57] It's a question of risk and benifit. [04:58] Assessment of these is subjective and requires experience. [04:58] Should I just go to town and request anything I think would benifit Ubuntu? [04:58] I'd suggest start small. [04:58] I'm only asking because it is a main todo and I want to be helpful. [04:58] Pick a few and suggest them. See how it goes. [04:59] You're main job when you're new is learning. [04:59] So don't go overboard with requests. [04:59] Okay, since I can't do the actual uploading and was scolded for doing debdiffs for syncs, should I at least upload a build log? [04:59] Focus on picking what you think are important things and see what's good. [05:00] You should definitely test build. No need to actually upload the log. The sponsor will test build it anyway. [05:02] ScottK, thanks. "You're main job when you're new is learning." I really am trying. [05:02] Good. Just keep at it. [05:09] if anyone has the time to review my package charm, http://revu.ubuntuwire.com/details.py?package=charm, I would be greatly appreciative. Thanks :) [05:15] Ok, time to fix us some dbus permissions on packagekit. [05:17] Is there a way to get a feed for packages with a particular tag, like patch? [05:28] jsmidt: I don't think so, but haven't dug into that particularly. [05:31] ScottK: has a freeze date been set for Jaunty yet? [05:32] * milli would like to get Rails 2.2.2 in soon, with fixed depends [05:33] milli: It'll be on wiki.ubuntu.com. [05:33] https://wiki.ubuntu.com/JauntyReleaseSchedule [05:35] raof: ty... guess I need to hassle the Debian maintainer first... there are security fixes beyond 2.1.0 that's in sid too... === ssweeny_ is now known as ssweeny === hggdh is now known as hggdh|away === bluesmoke is now known as Amaranth [06:27] bigon: Can you please include more information in your sync requests? Having to dig up two changelogs and then compare changes is very tiresome. [06:56] I'm trying to package my second package, but it relies on qmake so I'm not sure how to format the changes to the debian/rules file. Are there any good qt packaging guides around? [06:56] stochastic: your best bet is to find another package that uses qmake === freeflyi1g is now known as freeflying === freeflyi1g is now known as freeflying [07:27] good morning [07:31] G'morning dholbach. [07:31] hiya iulian === BugMaN1 is now known as BugMaN [08:33] soren: I got ~ubuntu-motu merged into ~motu. It's done now. [08:43] raof: could you merge/sync banshee 1.4.2, ipod-sharp 0.8.2 and podsleuth 0.6.4 from experimental? if you need to do any changes except changing libgnome2.0-cil to libgnome2.24-cil please tell me ;) [08:46] slomo_: If you update f-spot, sure! [09:14] I uploaded a fix to bug #211798 a few weeks ago but there's been no sign of activity since. Do I need to mark the bug as fixed before the debdiff is accepted into the repos? [09:14] Launchpad bug 211798 in jack-rack "jack-rack open file hangs" [Undecided,Confirmed] https://launchpad.net/bugs/211798 [09:16] thekorn, jpds: do you have any idea why the new grab-attachments (using lplib) do unzip zipped attachments (.diff.gz)? [09:17] stochastic: no, unless your bug is already fixed in jaunty. [09:17] DktrKranz, is there anything I can do other than wait now? [09:19] stochastic: waiting is the key here. I could have a look this evening, since I've no UI here. [09:19] *GUI [09:20] Okay, I'm just making sure its not going under the radar for jaunty [09:20] stochastic: if you're around this evening (europe timezone), please remind me :) [09:23] dholbach, hmm, really? let me check, I'm sure I did not change anything related to handling of zipped files in this tool === ara_ is now known as ara [09:26] dholbach, it looks like it's a 'feature' of launchpadlib, zipped content is automatically unzipped [09:30] narf :) [09:33] go, report a bug! [09:37] I always forget; if I upload a Banshee merge which build-depends on some new syncs, that's fine - it'll happily sit in dep-wait until the version is satisfied, yes? [09:38] RAOF, As long as you're using unsatisfied versioned build-depends, it ought. Worst case, it's just a rebuild for the build failure. [09:38] RAOF: yes, unless there are broken inner dependencies, in that case a give-back is enough to have things done. [09:38] (and we can do give-backs with the UI now :) ) [09:38] Oh, we can, can't we. Yay! [09:38] * DktrKranz hugs persia [09:39] "Yes, we can" (cit.) [09:46] RAOF: if you need a hand to clear those, count on me. I want to be able to upgrade banshee again ;) [10:10] DktrKranz: You're welcome to help. The relevant bug is bug #314516 [10:10] Launchpad bug 314516 in tomboy "gnome-sharp2 transition" [Medium,Confirmed] https://launchpad.net/bugs/314516 [10:17] The world has no right to be 30°C at 9pm. [10:18] RAOF: 1°C here :) [10:18] It's 3*C here. [10:18] yeah [10:18] dholbach: Trade you? :) [10:18] * ogra would love to be where RAOF is [10:18] Sydney. Sweet, sweaty, humid Sydney. [10:23] RAOF: I know, I filed it ;) [10:27] just I hadn't time to follow it [10:29] dholbach: I want to ask a question, it's related to yesterday's talk. Can I /msg you? === asac_ is now known as asac [10:37] Quintasan: sure [10:41] s the diffrence between Fix Commited and Fix Released? [10:41] crap :S [10:42] fix committed means the fix is published "somewhere". fix released means the fix is in a package in the archive in the right place [10:42] fr'example it might be fixed in a package's bzr branch or svn repo, but not yet pushed to a new package [10:48] directhex: When's the mono packaging session tomorrow? [10:48] directhex: thanks [10:49] RAOF, it's at 8pm utc tonight [10:49] RAOF, you can translate that into foreign === azeem_ is now known as azeem [10:50] Ok, that's 7am at GMT+11. === shiyee_ is now known as shiyee [11:24] milli: It's mid feb. Let me know about Rails. I'd be glad to sponsor it. === ember_ is now known as ember === LucidFox_ is now known as LucidFox [13:31] Please remind me: I want to update a package to a new upstream version. What do I attach to the LP ticket: debdiff, or diff.gz? [13:32] morgs: diff.gz, the debdiff is not really helpful, as it contains all the new upstream changes as well :) [13:32] dholbach: and a pointer to the upstream tarball, right? [13:32] that'd help, if the package does not have a debian/watch file [13:33] dholbach: the upstream tarball is a tar.bz2 - I can put an orig.tar.gz somewhere, would that be better? [13:33] * dholbach hopes to do do some sponsoring during the Jam in Berlin later on [13:33] morgs: no need really, re-compressing a tarball is easy to do [13:33] OK, thanks [13:34] * dholbach nods towards james_w [13:34] I personally always check the contents of the new proposed tarballs anyway [13:34] one day... one fine glorious day - I know the sun will be shining brightly... we won't have the .orig.tar.gz limiation any more [13:39] morgs, Please do have a get-orig-source rule and a README.source if the tarball is being recompressed. [13:40] morgs, Also, if you're planning to push the same version also to Debian, and that orig.tar.gz has already been submitted, it's helpful to link to it to avoid any md5sum clashes. [13:40] OK [13:40] conversely, if you're submitting to Debian later, and it goes into Ubuntu first, it's helpful to link to the Ubuntu orig.tar.gz for the Debian sponsor. [13:40] OK, thanks [13:47] hyperair: ping [13:48] hyperair, did you see the comments why codelite was rejected? [13:48] mok0: rejected? [13:48] mok0: i didn't see anything about it [13:48] hyperair: ah, you didn't :-) [13:48] where? [13:48] I was rejected by archive-admin [13:49] s/I/It/ :-) [13:49] tsk tsk! [13:49] eh? but why? [13:50] hyperair: https://lists.ubuntu.com/archives/ubuntu-archive/2009-January/024103.html [13:50] i see [13:51] so i make a get-orig-source rule that removes all of that? [13:51] hyperair: you need to repackage the tar-ball, they don't want all that crud in the archive :-) [13:51] hyperair: yes [13:51] alrgiht [13:52] and then do i need another two advocates to get it in? [13:52] hyperair: no I'll just re-upload [13:52] okay [13:53] basically only the dlls right? [13:53] hyperair: yes, all the binary files that don't belong on Linux [13:53] hyperair: he mentions an .exe file too [13:53] eh? [13:53] there is? [13:54] yeah you're right [13:54] so there's just dlls and exes? [13:54] I think, yes [13:55] hyperair: but check the tree carefully for irrelevant stuff [13:59] mok0: there's a .a somewhere [13:59] do i remove that too? [13:59] yes [14:00] hyperair: If the app doesn't build without it we're in trouble [14:00] then i start bugging upstream [14:00] hyperair: :-) good boy [14:01] heh [14:02] mok0: are .ico files acceptable? [14:02] hyperair: Are they needed for the Linux version of the app? [14:03] i'm not sure [14:03] can linux even use .ico files? [14:04] hyperair: Aren't they desktop icon things for Windows? [14:04] hyperair: try getting rid of them & check if it hurts [14:06] i'll check if they're in the debs [14:06] hyperair, .ico files can be read by several applications, but can't be used in .desktop files natively. [14:07] yeah i thought so [14:07] but if it's in the source but not the debs is it really required to remove them? [14:07] Not usually. .ico files are sometimes the preferred source for modification. We certainly have .ico editors in the archive. [14:08] hm [14:08] i see [14:12] mok0: do i need to remove .bat files? [14:12] hyperair: yep [14:12] and Makefile.win? [14:12] hyperair: everything related to windows [14:12] *groan* [14:13] there are so damn many things [14:13] hyperair: Bug upstream ;-) [14:13] to release a separate source tarball for linux and windows? [14:13] hyperair: yes [14:13] hyperair: many projects do [14:13] i think that'll require quite a lot of work on his part [14:13] ._. [14:14] the last time i tried getting him to do something on that scale, he took ages, and in the end i settled for using symlinks [14:14] hyperair: yeah, probably a bad idea [14:14] hyperair: note down the paths of all the files you remove in a file and make a script to do it [14:15] hyperair: or "find . -name \*.bat -exec rm {}\; [14:15] "find . -name \*.exec -exec rm {}\; [14:15] mok0: yeah i'll do that, but right now, i'm still trying to get all the files [14:15] there are dlls, exes, bats, Makefile.win [14:15] among other things [14:16] hyperair: spread all over the source tree? [14:16] geez, even pidgin's tarball has windows specific Makefiles in them, why didn't those get removed [14:16] yes [14:16] spread all over [14:16] hyperair: file a BTS bug about it :-) [14:18] Huh, isn't the problem just binaries without corresponding source? [14:18] mok0: what's a BTS? [14:18] There's no need to remove any trace of the windows build [14:18] oh [14:18] hyperair: Debians Bug Tracking System [14:19] if it's just binaries without corresponding source, then .exe and .dll and .a should be enough [14:19] right [14:20] and then what do i call the repackaged tarball? [14:20] if they're needed for the build then they should be created as part of it [14:20] hoo boy [14:20] looks like i'm going to ahve to bug upstream [14:20] he's got a libcurl.a [14:20] but no libcurl sources [14:20] can it use the system libcurl? [14:21] lemme grep and see [14:22] it seems the readme says to install the libcurl dev [14:22] but ./configure doesn't seem to detect it [14:22] no wait i found a function inside configure which detects it [14:23] but it isn't called [14:24] ah it seems it's a CURL for Windows [14:24] i think i'll just rm -rf the whole folder than [14:24] then* [14:25] ..come to think of it i'm going to try and build without the whole sdk/ folder [14:29] hyperair: yikes that's a miss. You have to call the system curl [14:29] mok0: no the curl folder seems to belong to windows [14:30] hyperair: ah ok [14:30] mok0: in the first placei d on't think it uses curl === quadrispr1 is now known as quadrispro [14:31] hyperair: just add '~dfsg' to tarball name, after the version no. (That's tilde-dfsg) [14:31] tilde eh? [14:32] strange, i thought it was "." [14:32] No, please, not tilde. [14:32] heh [14:32] .dfsg then? [14:32] hyphen is much preferred, or even better, minus-sign. [14:32] erm [14:32] is there a difference between minus and hyphen? [14:32] persia: tilde will let any other version override it [14:32] Yes. [14:32] mok0, Yes, but do we want that? [14:32] For dfsg, usually we don't. [14:33] I thought it was +dfsg usually [14:33] * hyperair sighs [14:33] persia: if upstream packages a tarball that confirms to dfsg without altering the version no [14:33] that's very rare isn't it? [14:33] Laney, That's common too. [14:33] persia: than you want to be able to override the package and still use the same version [14:33] mok0, If upstream does that, they should have versions explained to them. [14:34] mok0: and in the first place, i don't think he's about to package a dfsg tarball minus version change [14:34] mok0: his version contains the svn revision stuck on it [14:34] mok0: that's the 4-digit version after 1.0. [14:34] hyperair: kk [14:35] persia: heh you know, the author of sigx released a tarball sigx-2.0.tar.bz2 twice, second time, setting a SONAME after i requested him to do so [14:35] * mok0 screams in pain [14:35] lol [14:36] well considering nobody actually does use sigx yet (i haven't seen any application which uses it, or any distro which packages it), i think that as long as he doesn't do it again it'll be fine [14:36] hyperair, I do hope you asked the author to never repeat that, given the nature of web archives. It breaks namespacing. [14:36] persia: web archives? [14:36] The old tarball may have been archived elsewhere [14:37] oh [14:37] i see [14:37] persia: TBH, that's a problem with Debian's archive structure [14:37] hyperair, archive.org for one. There are others. Also, there are uncountable caches, both visible and transparent. [14:37] persia: it really OUGHT to be able to handle name-space clashes [14:37] mok0: Not accepting substitute tarballs with the same version name, but a different md5sum is a feature, even though it's painful. [14:37] mok0, It's not archive-specific: it's related to the fact that if two binary blobs have the same name, it causes confusion. [14:40] mok0, Yes, the real solution is to rearchitect browserspace to have persistent URNs for all binary blobs, and use URLs as redirectors for URNs, but that idea failed to catch on before the web left CERN years ago, and doesn't show any signs of getting better. [14:41] with persistent links between URNs and blobs, adding a cryptographic check doesn't matter, and the archive could just have arbitrary version codes used to reference URNs for packages [14:41] (and yes, a text file is also a binary blob, much as a square is also a rectangle) [14:48] mok0: "primadonnas" :-) [14:48] * dholbach sniggers [14:50] Good morning, dholbach. [14:51] hiya tritium [14:54] dholbach: I'm considering packaging http://ngspice.sourceforge.net/index.html for jaunty, as it has not been in an ubuntu repository since hoary, but I need to check on licensing issues. [14:56] Ik heb de vraag gekregen in welke mate details moeten gekend zijn van de verschillende entiteiten die kunnen voorkomen in het GRB en in de GRB-skeletbestekken. [14:56] GRB-producten: 1. Datamodellering: slide 10 tem 30 --> Is het hier de [14:56] bedoeling dat alle afkortingen en types van elk element gekend zijn? [14:56] En in hoeverre moet dit gedetailleerd gekend zijn? Of is het enkel [14:56] voldoende dat je kort kan zeggen wat alles is? [14:56] De verschillende soorten entiteiten die voorkomen in het GRB dienen gekend te zijn, maar de bijhorende afkortingen en alle mogelijke voorkomende types van een entiteit dienen niet in detail gekend te zijn. [14:56] Van elke entiteit dient er kort toegelicht te kunnen worden om welk object op het terrein het gaat of waar dit kan voorkomen. Daarom moeten niet alle geometrische eigenschappen, uitzonderingen, kenmerken... ten gronde gekend zijn. [14:56] GRB-producten : 4. GRB-GIS: slide 7 tem 29 --> Ook hier, in hoeverre [14:56] moet dit gekend zijn? Is het de bedoeling dat je weet hoe alles in GIS [14:56] tritium: alright [14:56] voorgesteld wordt? [14:56] Deze slides hoeven niet in detail gekend te zijn. Ze dienen vooral ter illustratie van het GIS-product en tonen een mogelijke voorstelling van de verschillende entiteiten die reeds eerder uitgelegd werden. Qua te kennen leerstof, houden deze slides geen nieuwe elementen in. [14:56] GRB-skeletbestekken : 3. Opbouw: slide 41 tem 141 --> Hoe [14:56] gedetailleerd moet dit gekend zijn? Is het voldoende als je van elk [14:56] element weet wat het juist is en hoe het in een foto wordt [14:56] erm [14:56] voorgesteld? Of moet elk detail gekend zijn? [14:58] dholbach: is there any specific guidance on licenses? ngspice has a heterogenous license, as it draws from different projects with different licenses, including LGPL, Old BSD, Public Domain, and New BSD. [14:59] tritium: https://wiki.ubuntu.com/PackagingGuide has a chapter about licenses and debian/copyright [14:59] dholbach: thank you [14:59] anytime [15:05] persia, ScottK, sorry I had to go AFK for a while [15:06] mok0, No problems. Happens to everyone [15:06] persia: I agree that publishing tarballs with different content but the same name is ... erhh... stupid [15:07] persia: but it happens [15:07] Yes, but it shouldn't :) [15:07] Anyway, there are lots of ways around it, just not aesthetically pleasing ones. [15:07] persia: I've just reviewed software, where the newest tarball has version 0.6, and an older one 1.0 [15:08] persia: the uploader had quite a task writing a watch file :-) [15:08] heh, I bet. [15:09] perl regular expressions are *very* powerful, but man uscan doesn't provide much of a guide. [15:09] persia: yes, you sometimes have to work to get it to do what you want [15:10] persia: I think we ended up mangling 1.0 to 0.1 or something like that [15:11] persia: us packagers hate upstreams even more than developers hate users ;-) [15:12] heh [15:12] I'd probably have tried to somehow find the URL near the most recent date, but it might have taken me a week to get it right. [15:13] persia: we considered it, but the date was not systematically written on the web page. [15:13] Ugh, even worse. [15:13] Some things should just not be. [15:13] persia: and unfortunately, uscan can't get a tarball directly from the URL [15:13] persia: if it contains http:// [15:13] Needs to scrape a web page? [15:14] Yes it can, as long as directory indexing is enabled, and there's no index page. [15:14] persia: I think so, I haven't been able to get the other thing to work [15:14] persia: it ought to be able to work like wget [15:14] Uh, no. [15:15] I needs a list of versions to compare. [15:15] With a single URL, one can only get a single thing. [15:15] With a regular expression, one needs to have a set of matching things as a filter. [15:15] persia: of course, d'Oh! [15:15] Otherwise, one needs to iterate over the entire matched set, which takes until well after the heat death of the universe. [15:15] :) === hggdh|away is now known as hggdh [15:20] Still faster than Debian releases. [15:21] Heya gang [15:23] hi bddebian [15:23] Hi mok0 [15:24] Hi bddebian. [15:27] Heya tritium! [15:27] :) [15:29] Heya bddebian. [15:29] Hi ScottK [15:32] I'm a bit puzzled by bug 246506. The debian bug status is "Fix Committed", but only because someone has privately packaged it, as far as I can tell. It's not yet in Debian. [15:32] Launchpad bug 246506 in ubuntu "[needs-packaging] ngspice" [Wishlist,Confirmed] https://launchpad.net/bugs/246506 [15:33] tritium: It may be in Debian New too. [15:33] ScottK: I'm not familiar with Debian New. [15:34] Ah, found it. [15:34] tritium: When packages are uploaded to the archive they are initially reviewed for legal problems. [15:34] While that happens they're not downloadable. [15:34] tritium: After a package is uploaded for the first time it goes into the New package queue (as broonie says) [15:34] broonie: oh, I see. This one, having multiple licenses, would need that legal review. [15:34] The Debian Import Freeze has passed, correct? [15:34] http://ftp-master.debian.org/new.html [15:35] tritium: All new packages get this review, you can't tell if the maintainer noticed everything without review. [15:35] tritium: For auto sync, yes. They can still be requested manually. [15:35] OK. I don't find it in http://ftp-master.debian.org/new.html [15:36] I'd like to apologise for my paste earlier; I wasn't aware of the fact that Putty associated the middlemousebutton with paste. Sorry. [15:37] Thanks, broonie and ScottK. How would you advise I proceed? [15:38] tritium: You could email the owner of the ITP bug and ask them how soon the plan to upload it. You might also look on mentors.debian.net. [15:38] It seems that "Fix Committed" isn't appropriate for it, if it's not even in Debian New. [15:39] ScottK: will do. Can his package be brought into ubuntu directly, or should it come straight from Debian? Should it be repackaged (by me)? [15:40] In the mean time, I'll contact the bug owner. [15:40] If it doesn't come through Debian (and given the length of the New queue that's getting unlikely) then it'd have to go through REVU. You could do that. [15:40] Ideally they will give you access to the draft package and you don't have to change much. [15:41] ScottK: ok, thanks again. [15:41] https://wiki.ubuntu.com/UbuntuDeveloperWeek - Day 4 to kick off in #ubuntu-classroom in 19m. :-) [15:42] tritium: check with motu science team if they are interested in helping you with ngspice. [15:43] slytherin: I'm technically still the administrator of that team, but I'm no longer MOTU. I'm not sure the team is still active. [15:43] I've pinged wgrant about it, though. Thanks. [15:46] * ScottK notes mok0 is interestedin science stuff too. [15:46] I am [15:46] tritium: ^^ [15:46] * tritium notes above ;) [15:50] * mok0 notes his name is no isotope [15:50] s/name/nick [15:51] tritium: the science team is sadly inactive [15:52] mok0: yes, if I pursue reinstatement as an MOTU again, I'd hope to focus on that team. [15:52] tritium: cool [15:52] tritium: the Debian science team is much more active [15:52] mok0: are you part of that? [15:53] tritium: yes [15:53] mok0: excellent [15:53] Have you seen anything about ngspice in particular on your mailing list or otherwise? It's licensing is peculiar. [15:53] tritium: No, I haven [15:54] t [15:54] ah [15:54] tritium: you may want to contact tuxmaniac. Although he is not MOTU, he is very enthusiastic about electronic related softwares. [15:54] tritium: can I see it somewhere? URL? [15:54] slytherin: oh, thanks for the tip. [15:55] tritium: and norsetto [15:55] mok0: debian bug here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=489768 [15:55] Debian bug 489768 in wnpp "ITP: ngspice -- A Spice circuit simulator" [Wishlist,Open] [15:56] project page here: http://ngspice.sourceforge.net/ [15:59] "The group developing ngspice has written to Berkeley's copyright holders asking to change the license to the new BSD, which has the incompatibility removed, but without success. " [15:59] I wonder if that means they refused, or that they didn't answer the request [16:01] Not sure. Here's the COPYING file from the new ng-spice-rework-18 package that talks about the "heterogenous [16:01] " license: http://paste.ubuntu.com/108277/ [16:03] tritium: OMG [16:04] mok0: pretty crazy, eh? [16:05] tritium: yeah [16:06] It seems I always pick the crazy stuff to try to package. [16:07] tritium: If UC decided to remove the advertising clause from their license, why wouldn't they accept that the old BSD license be changed in this case? It doesn't make sense [16:08]