Bug#840292: ITP: node-esutils -- utility box for ECMAScript language tools
Package: wnpp Severity: wishlist Owner: Pirate Praveen X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-esutils Version : 2.0.2 Upstream Author : Yusuke Suzuki * URL : https://github.com/estools/esutils * License : BSD Programming Lang: JavaScript Description : utility box for ECMAScript language tools signature.asc Description: OpenPGP digital signature
Bug#840297: ITP: node-estraverse -- ECMAScript JS AST traversal functions
Package: wnpp Severity: wishlist Owner: Pirate Praveen X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-estraverse Version : 4.2.0 Upstream Author : FIX_ME upstream author * URL : https://github.com/estools/estraverse * License : BSD-2-Clause Programming Lang: JavaScript Description : ECMAScript JS AST traversal functions signature.asc Description: OpenPGP digital signature
Re: Porter roll call for Debian Stretch
On Sun, Oct 09, 2016 at 11:13:21PM +0100, Adam D. Barratt wrote: > On Sun, 2016-10-09 at 21:12 +0300, Adrian Bunk wrote: > > [ adding debian-powerpc ] > > > > On Sun, Oct 09, 2016 at 06:54:44PM +0200, Moritz Mühlenhoff wrote: > > > Niels Thykier schrieb: > > > > If I am to support powerpc as a realease architecture for Stretch, I > > > > need to know that there are *active* porters behind it committed to > > > > keeping it in the working. People who would definitely catch such > > > > issues long before the release. People who file bugs / submit patches > > > > etc. > > > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832931 is about > > > a powerpc-specific build failure of mariadb in stable. The maintainer > > > said he can't work on it, so if anyone considers himself/herself a > > > powerpc porter, this is something to look it. > > > > Can you give a hint what exactly should be looked at? > > https://buildd.debian.org/status/fetch.php?pkg=mariadb-10.0&arch=powerpc&ver=10.0.27-0%2Bdeb8u1&stamp=1473621159 > > > The bug did not make it clear that there is any problem left at all when > > I looked at it recently. > > > > The last message was closing the bug. > > > > There was a control command reopening the bug without giving any > > rationale, but the last control command was > > fixed 832931 10.0.27-1 > > For unstable, yes. The stable package is still broken. Thanks. When skimming through that the bug I thought it was fixed in upstream 10.0.27, and no comment in the bug indicated otherwise. As (pretty passive) reader of debian-powerpc, I am also puzzled by the fact that I cannot recall #832931 ever being mentioned there. An email to the bug and the mailing list of the port stating that there is a problem, and what is known about it, can be really helpful for getting such a bug resolved. > > buildd.debian.org says that 10.0.27-0+deb8u1 was installed on jessie.[1] > > That's an artefact of how builds for suites with "overlays" (i.e. pu / > tpu) are displayed. If one actually looks at the archive: > > mariadb-client-10.0 | 10.0.25-0+deb8u1 | stable | powerpc > mariadb-client-10.0 | 10.0.27-0+deb8u1 | stable | amd64, arm64, armel, > armhf, i386, mips, mipsel, ppc64el, s390x Ouch. I thought the information in the version tracking was wrong when buildd.d.o showed green. > Regards, > > Adam cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#840301: ITP: node-deep-is -- node's assert.deepEqual algorithm except for NaN being equal to NaN
Package: wnpp Severity: wishlist Owner: Pirate Praveen X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-deep-is Version : 0.1.3 Upstream Author : Thorsten Lorenz (http://thlorenz.com) * URL : https://github.com/thlorenz/deep-is * License : Expat Programming Lang: JavaScript Description : node's assert.deepEqual algorithm except for NaN being equal to NaN signature.asc Description: OpenPGP digital signature
Re: "Browserified" stuff
On 09/10/16 23:56, Adam Borowski wrote: > Another issue is, as mentioned in the TC discussion, the inability to fix > any non-trivial security bugs in stable. I can't quite imagine the Security > Team hunting for a specific old version of grunt and all of its extensive > dependencies to rebuild the buggy package. Such state hits the definition > of "contrib" exactly, why not actually use it for this purpose? Demotion of > libjs-handlebars would require changing or demoting two more packages: > prometheus and kcov, which would be a hassle but not the end of the world. Prometheus being in contrib basically means the work I have done for the past year is worthless, as users could as well just grab unofficial packages from other places. I am not saying this to justify the mess with handlebars, I want to find a solution, but putting this in contrib or non-free is not an option for me. -- Martín Ferrari (Tincho)
Re: "Browserified" stuff
On Mon, Oct 10, 2016 at 03:08:17PM +0200, Martín Ferrari wrote: > Prometheus being in contrib basically means the work I have done for the > past year is worthless, as users could as well just grab unofficial > packages from other places. contrib packages are not "unofficial". -- WBR, wRAR signature.asc Description: PGP signature
Re: "Browserified" stuff
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, Oct 10, 2016 at 03:08:17PM +0200, Martín Ferrari wrote: > Prometheus being in contrib basically means the work I have done for the > past year is worthless, as users could as well just grab unofficial > packages from other places. I am not saying this to justify the mess > with handlebars, I want to find a solution, but putting this in contrib > or non-free is not an option for me. So the decision is that this code in its current form does not belong in main. If I understand your position correctly, you do not dispute this, but you seem to advocate that it should be allowed in main anyway, to avoid demoralizing the developers (in particular, yourself)? While I understand that sentiment, that is not how Debian works. And not working that way means that Debian is of higher quality. While it may be uncomfortable to tell people they need to work on their package to keep it in main, doing so means that the packages in main will follow our guidelines as much as possible. If things don't belong in main, there's a reason for it. If a packager wants to get their package into main, the solution is to fix the problem that's preventing it from being there. In this case, that's a non-packaged build tool. So now that the discussion about whether "browserified" files are source has been settled (they aren't), I see these options: 1. Package the tools that are required for building from source. 2. Accept that the package moves out of main. 3. Fight that decision (with a GR). If none of these sound good to you, what else do you suggest? Thanks, Bas -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJX+6dBAAoJEJzRfVgHwHE6UEEP/0FEuS6/Qxlrrqg0m158Qp2S FSRYe9U2F+xpMchlGkczzVTUVlcznctQ1dvziE9o+jAn0sg5Fd6l07w9TS4Czjx1 x6ZKurxhFv2oT5MGSV177VLPrXe3ivGvHE1LRdxlUvJ7jV1fWbWqx0wqIHQjcPNc JnQSVrNxdhmoytJVaKiI65o7A/YSpAzQDENDVrDQEDSvz1+wLPl6iWowjNipr7oG sbwH+l3SFrboatDFo+CgutiK0nSU2KLwB2bV0TUmoprPWKKQtROzNIcBJKKytDUG 0Cj71qsAidOVw18Uy2O/eBjgf6f0buDY30ubHou1+dwU9k+Ewc0ZEdpBt7b5yX0H NiJKn2URps4rSQfE7lFtFyxxLO+uNaUDHxtKX+azzES1+z5QaNoytkeIGcR+4poM dSgmIccl90MEU6JWpFGoK5q1uVnVujZ+kkmwnEn65+qF+D85312JhdwSCkgpHBv1 y0XEHDDckql+0IGikQzvOvfEaHCTTUIdHSzl2z7SWE3yy45zlBdKKXDguH5P4/73 /Vsu3Bd5az8Rxo7XVrQ9BTZ3rs6GnVMuxtVeIWGXVQTd9qliYu6MlUX5Zbc0S2Qz Dv8lnCgIbPBGIk+np73KtHLJf6meH3AgISznuLZBpNMaukRnCBPT4vfMm1ZENc19 6m5JVvL6I79lItT9mtfU =sXZk -END PGP SIGNATURE-
Bug#840319: ITP: mistral-dashboard -- OpenStack Workflow Service - dashboard plugin
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: mistral-dashboard Version : 3.0.1 Upstream Author : OpenStack Foundation * URL : https://github.com/openstack/mistral-dashboard * License : Apache-2.0 Programming Lang: Python Description : OpenStack Workflow Service - dashboard plugin Mistral is a workflow service. Most business processes consist of multiple distinct interconnected steps that need to be executed in a particular order in a distributed environment. One can describe such process as a set of tasks and task relations and upload such description to Mistral so that it takes care of state management, correct execution order, parallelism, synchronization and high availability. Mistral also provides flexible task scheduling so that it can run a process according to a specified schedule (i.e. every Sunday at 4.00pm) instead of running it immediately. Such set of tasks and relations between them is called a workflow. . This package contains the OpenStack dashboard plugin.
Re: "Browserified" stuff
On Mon, Oct 10, 2016 at 03:08:17PM +0200, Martín Ferrari wrote: > On 09/10/16 23:56, Adam Borowski wrote: > > Another issue is, as mentioned in the TC discussion, the inability to fix > > any non-trivial security bugs in stable. I can't quite imagine the Security > > Team hunting for a specific old version of grunt and all of its extensive > > dependencies to rebuild the buggy package. Such state hits the definition > > of "contrib" exactly, why not actually use it for this purpose? Demotion of > > libjs-handlebars would require changing or demoting two more packages: > > prometheus and kcov, which would be a hassle but not the end of the world. > > Prometheus being in contrib basically means the work I have done for the > past year is worthless, as users could as well just grab unofficial > packages from other places. I am not saying this to justify the mess > with handlebars, I want to find a solution, but putting this in contrib > or non-free is not an option for me. The preferred solution, of course, would be having all that js brouchacha beaten into shape and packaged. But, as this hasn't happened for years, I'm not holding my breath. But why are you so opposed to contrib? Packages there _can_ have security support, it's just not guaranteed[1]. You get almost all the convenience of being in Debian proper, users just need to enable contrib as it doesn't have the same level of support -- and usually it's already enabled because of needing non-free drivers[2]. Yes, it is a shame to be there but it accurately warns users about problems. I know they're not your fault, but the results are still the same -- most non-trivial bugs in libjs-handlebars will be prohibitely hard to fix during the lifetime of stretch. I believe it's nicer on users to not have prometheus in main in stretch than to ship it then remove in buster (assuming the promise of "not giving the RC exception twice" is held, in practice the "very last chance" is extended indefinitely). There are some pretty useful packages in contrib, like, say, virtualbox (handles GUI x86 VMs better than qemu). It is in contrib only due to a small part of it being prebuilt (regenerating requires an out-of-Debian compiler, much like grunt), and that part is not even strictly required! (It's 8086 BIOS for VMs, these days being EFI-only becomes more and more acceptable.) Meow! [1]. For packages in main users at the very least get a message about security support for that package ceasing. [2]. On any modern x86 CPU running without microcode updates means data corruption bugs. -- A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol, 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month. Filter out and throw away the fruits (can dump them into a cake, etc), let the drink age at least 3-6 months.
Re: "Browserified" stuff
Quoting Bas Wijnen : 1. Package the tools that are required for building from source. 1a: It might not even be necessary to package the tools used by upstream. In some cases, adhoc tools to perform similar tasks are sufficient. Antonio Terceiro did this with jQuery successfully (debian/build.js). Cheers
[MBF]: json_checker testsuite, likely licensed "Good not Evil"
Dear Developers, while packaging an updated version of one of my packages which included now rapidjson I became aware that this library includes the test suite date of http://json.org/JSON_checker/. While there is no license on the testsuite.zip, json_checker is licensed by json.org with the infamous clause "The Software shall be used for Good, not Evil." and I believe the testdata is covered under the same license "best case", (worst case not licensed at all. For rapidjson [1] I filed #840333, but afterwards I checked also codesearch.debian.net for one of the testcases [2] and found many packages including it verbatim. I'm not sure if my assessment is right and we have a DFSG problem here, but if so, I guess this should be handled by extending the existing lintian error. Thoughts? [1] (where upstream is aware of it and later versions recommend to remove the testsuite) [1] https://codesearch.debian.net/search?q=%22Extra+comma%22%3A+true%2C +path%3Afail9.json&perpkg=1 -- tobi signature.asc Description: This is a digitally signed message part
Re: problem with libc6 / iconv
On 2016-10-09 10:21:03 +0300, Lars Wirzenius wrote:
> On Sun, Oct 09, 2016 at 01:49:14AM +0200, Jérémy Lal wrote:
> > node-iconv used to be able to translit utf-8 chars (ça va) to ascii (ca va)
> > using setlocale("C.UTF-8") trick.
> >
> > However, several libc6 version ago, that behavior changed, to the point
> > node-iconv fails its tests now.
> >
> > I've failed to work around that, and i'm lacking libc6 knowledge to fix it,
> > or even properly report a bug about that. Please help me !
>
> Write a short script that reproduces the problem, and attach it to a
> mail that explains what you want to do, what you expect the script to
> output, and what the actual output is. Sen report the problem to
> one of:
>
> * upstream: https://www.gnu.org/software/libc/bugs.html
> * Debian: https://www.debian.org/Bugs/
>
> I would expect this to be an upstream bug, and that it would faster to
> get it fixed by reporting it upstream.
No, I doubt that this can be an upstream bug as upstream does not
support/provide C.UTF-8. It is an addition in Debian and some other
distributions.
--
Vincent Lefèvre - Web:
Re: "Browserified" stuff
On 14455 March 1977, Adam Borowski wrote: > On Sat, Oct 08, 2016 at 10:45:08PM +0200, Joerg Jaspert wrote: >> we had a discussion inside the FTP Team about the "browserified js" >> issue. We understand that "browserified" refers to various changes to >> the original source, from concatenating multiple (local and remotely >> fetched) files together, arbitary transformations (down to something >> akin to compilation), minifying and others. Not all "browserification" >> may necessarily use all of those ways. > [...] >> - We acknowledge that it appears to be a big task to provide a proper >> "browserification" environment within Debian. Due to the freeze coming >> up we would understand the Release Team granting an RC exception for >> stretch for such non-sources already in main, with the condition that >> this will not extend to another release. > Could you please suggest some stick to ensure that the condition you mention > is actually enforced? I've got an impression that once a RC exception is > granted, it stays forever, renewed around every freeze. First of they have to grant it. I have no idea if they do or not, not having asked them at all. Second - the enforcing will have to come from us ftpmasters - by removing the packages at some point, if they don't get fixed. > Another issue is, as mentioned in the TC discussion, the inability to fix > any non-trivial security bugs in stable. I can't quite imagine the Security > Team hunting for a specific old version of grunt and all of its extensive > dependencies to rebuild the buggy package. Such state hits the definition > of "contrib" exactly, why not actually use it for this purpose? Demotion of > libjs-handlebars would require changing or demoting two more packages: > prometheus and kcov, which would be a hassle but not the end of the world. I would understand the security team to define them as "not supported (unless the maintainer does all the work)", and yes, contrib is IMO the way better place for them. -- bye, Joerg <_DeadBull_> ohne speicher, tastatur, mouse, pladde, monitor, also nur die Hardware...
Re: "Browserified" stuff
On 14456 March 1977, Martín Ferrari wrote: > On 09/10/16 23:56, Adam Borowski wrote: > >> Another issue is, as mentioned in the TC discussion, the inability to fix >> any non-trivial security bugs in stable. I can't quite imagine the Security >> Team hunting for a specific old version of grunt and all of its extensive >> dependencies to rebuild the buggy package. Such state hits the definition >> of "contrib" exactly, why not actually use it for this purpose? Demotion of >> libjs-handlebars would require changing or demoting two more packages: >> prometheus and kcov, which would be a hassle but not the end of the world. > Prometheus being in contrib basically means the work I have done for the > past year is worthless, as users could as well just grab unofficial > packages from other places. I am not saying this to justify the mess > with handlebars, I want to find a solution, but putting this in contrib > or non-free is not an option for me. It is not useless, and contrib is way different than any random repository out there. The solution is to have the full build environment needed (for prometheus and all its dependencies) in main - or accept that it can't be done (or is too much work for the amount of people interested in doing it) and move to contrib. There isn't anything bad or de-valuing in that, thats simply how it is defined in our policies. -- bye, Joerg I’m not normally a praying man, but if you’re up there, please save me Superman!
Re: [MBF]: json_checker testsuite, likely licensed "Good not Evil"
On Mon, Oct 10, 2016 at 8:30 PM, Tobias Frost wrote: > Dear Developers, > > while packaging an updated version of one of my packages which included > now rapidjson I became aware that this library includes the test suite > date of http://json.org/JSON_checker/. While there is no license on the > testsuite.zip, json_checker is licensed by json.org with the infamous > clause "The Software shall be used for Good, not Evil." > and I believe the testdata is covered under the same license "best > case", (worst case not licensed at all. > > For rapidjson [1] I filed #840333, but afterwards I checked also > codesearch.debian.net for one of the testcases [2] and found many > packages including it verbatim. > > I'm not sure if my assessment is right and we have a DFSG problem here, > but if so, I guess this should be handled by extending the existing > lintian error. With my lintian maint hat, they are here two approach: - autoreject based on md5sum and sha1 - autoreject based on regexp Do you have better signature than this file ? > > Thoughts? > > > [1] (where upstream is aware of it and later versions recommend to > remove the testsuite) > [1] https://codesearch.debian.net/search?q=%22Extra+comma%22%3A+true%2C > +path%3Afail9.json&perpkg=1 > > > -- > tobi >
Re: [Artwork] Survey for the default artwork for Stretch
Hi, On 04/10/2016 00:02, Niels Thykier wrote: > https://surveys.larjona.net/index.php?r=survey/index&sid=926823&lang=en_us > * Please be nice and vote only once! I just vote. Thanks to the artists for all these propositions. I also noticed that the survey link have been posted on many media websites and social networks now. But is there any kind of limitations for voting submission? If not maybe many people will do some mass-voting tricks or vote without any concern of the Debian project… Kind regards, Thomas Pierson
Re: [MBF]: json_checker testsuite, likely licensed "Good not Evil"
Am Montag, den 10.10.2016, 21:48 +0200 schrieb Bastien ROUCARIES: > On Mon, Oct 10, 2016 at 8:30 PM, Tobias Frost > wrote: > > Dear Developers, > > > > while packaging an updated version of one of my packages which > > included > > now rapidjson I became aware that this library includes the test > > suite > > date of http://json.org/JSON_checker/. While there is no license on > > the > > testsuite.zip, json_checker is licensed by json.org with the > > infamous > > clause "The Software shall be used for Good, not Evil." > > and I believe the testdata is covered under the same license "best > > case", (worst case not licensed at all. > > > > For rapidjson [1] I filed #840333, but afterwards I checked also > > codesearch.debian.net for one of the testcases [2] and found many > > packages including it verbatim. > > > > I'm not sure if my assessment is right and we have a DFSG problem > > here, > > but if so, I guess this should be handled by extending the existing > > lintian error. > > > With my lintian maint hat, they are here two approach: > - autoreject based on md5sum and sha1 > - autoreject based on regexp > > Do you have better signature than this file ? The testsuite data are in total 36 (mostly) small files, so I guess the hashes would work, maybe with an additional indicator if more than one file in the set is found. The zip is here: http://json.org/JSON_checker/test.zip a git repo for convenient browsing them here: https://github.com/miloyip/rapidjson/tree/master/bin/jsonchecker > > > > Thoughts? > > > > > > [1] (where upstream is aware of it and later versions recommend to > > remove the testsuite) > > [1] https://codesearch.debian.net/search?q=%22Extra+comma%22%3A+tru > > e%2C > > +path%3Afail9.json&perpkg=1 > > > > > > -- > > tobi > > > -- tobi signature.asc Description: This is a digitally signed message part
Re: problem with libc6 / iconv
2016-10-10 21:29 GMT+02:00 Vincent Lefevre :
> On 2016-10-09 10:21:03 +0300, Lars Wirzenius wrote:
> > On Sun, Oct 09, 2016 at 01:49:14AM +0200, Jérémy Lal wrote:
> > > node-iconv used to be able to translit utf-8 chars (ça va) to ascii
> (ca va)
> > > using setlocale("C.UTF-8") trick.
> > >
> > > However, several libc6 version ago, that behavior changed, to the point
> > > node-iconv fails its tests now.
> > >
> > > I've failed to work around that, and i'm lacking libc6 knowledge to
> fix it,
> > > or even properly report a bug about that. Please help me !
> >
> > Write a short script that reproduces the problem, and attach it to a
> > mail that explains what you want to do, what you expect the script to
> > output, and what the actual output is. Sen report the problem to
> > one of:
> >
> > * upstream: https://www.gnu.org/software/libc/bugs.html
> > * Debian: https://www.debian.org/Bugs/
> >
> > I would expect this to be an upstream bug, and that it would faster to
> > get it fixed by reporting it upstream.
>
> No, I doubt that this can be an upstream bug as upstream does not
> support/provide C.UTF-8. It is an addition in Debian and some other
> distributions.
>
>
I suggest to continue the discussion in bug #840199.
Jérémy
Bug#840361: ITP: fonts-pt-astra -- metric-compatible Times New Roman and Arial alternatives
Package: wnpp Severity: wishlist Owner: Andrew Shadura * Package name: fonts-pt-astra Version : 20160928 Upstream Author : ParaType Inc * URL : http://astralinux.com/fonts.html http://www.paratype.ru/cinfo/news.asp?NewsId=3469 http://astralinux.com/ofl.html * License : OFL 1.1 Description : metric-compatible Times New Roman and Arial alternatives PT Astra Serif and PT Astra Sans are metric-compatible replacements for Times New Roman and Arial fonts. PT Astra family of fonts have been developed by ParaType Inc for AstraLinux distribution.
Bug#840366: RFP: libsignal-protocol-c -- ratcheting forward secrecy protocol for synchronous and asynchronous messaging
Package: wnpp Severity: wishlist Owner: "W. Martin Borgert" * Package name: libsignal-protocol-c Version : None, 2016-10-05 Upstream Author : Moxie Marlinspike and others * URL : https://github.com/WhisperSystems/libsignal-protocol-c * License : GPL3 Programming Lang: C Description : ratcheting forward secrecy protocol for synchronous and asynchronous messaging This is a ratcheting forward secrecy protocol that works in synchronous and asynchronous messaging environments. This will be needed for implementing OMEMO in C, e.g. in libpurple/pidgin.
Bug#840371: ITP: git-repo -- CLI utility to manage git services from your workspace
Package: wnpp Severity: wishlist Owner: "ChangZhuo Chen (陳昌倬)" * Package name: git-repo Version : 1.7.2 Upstream Author : Bernard `Guyzmo` Pratz * URL : https://github.com/guyzmo/git-repo * License : GPLv2+ Programming Lang: Python Description : CLI utility to manage git services from your workspace git-repo is a CLI tool to manage git services likes GitHub, GitLab, and Bitbucket. It provides several commands to handle clone, gist, pull request. -- ChangZhuo Chen (陳昌倬) Debian Developer (https://nm.debian.org/public/person/czchen) Key fingerprint = EC9F 905D 866D BE46 A896 C827 BE0C 9242 03F4 552D BA04 346D C2E1 FE63 C790 8793 CC65 B0CD EC27 5D5B signature.asc Description: PGP signature
Re: dedicated live CD for PGP master key management
This can now be used, command line only for the moment, as described in my blog[1] about it If anybody wants to help take this further please join the list[2] I set up for it Regards, Daniel 1. https://danielpocock.com/dvd-based-clean-room-for-pgp-and-pki 2. https://lists.alioth.debian.org/mailman/listinfo/pki-clean-room-devel
Re: [Artwork] Survey for the default artwork for Stretch
Thomas Pierson: > Hi, > > On 04/10/2016 00:02, Niels Thykier wrote: >> https://surveys.larjona.net/index.php?r=survey/index&sid=926823&lang=en_us >> * Please be nice and vote only once! > > I just vote. Thanks to the artists for all these propositions. > Thanks. :) > I also noticed that the survey link have been posted on many media > websites and social networks now. But is there any kind of limitations > for voting submission? The survey does not use any guaranteed method for avoiding cheating as I wanted to support anonymous voting (with minimal hassle). If you really wanted to cheat, you could. This is also the reason for the "Please be nice and vote only once!" remark. > If not maybe many people will do some mass-voting tricks or vote without > any concern of the Debian project… > > Kind regards, > Thomas Pierson > Of course, if it becomes a problem, we will have to revise the method and re-issue a new survey with stricter checking. Thanks, ~Niels
Bug#840386: ITP: osinfo-db -- Operating system database files
Package: wnpp Severity: wishlist Owner: "Guido Günther" * Package name: osinfo-db Version : 1.0.0 * URL : https://fedorahosted.org/releases/l/i/libosinfo/ * License : GPL Programming Lang: XML Description : Operating system database files for libosinfo This are the operating system descriptions formerly shipped by libosinfo split out to ease updating.
Bug#840387: ITP: osinfo-db-tools -- operating system database tools
Package: wnpp Severity: wishlist Owner: "Guido Günther" * Package name: osinfo-db-tools Version : 1.0.0 * URL : https://fedorahosted.org/releases/l/i/libosinfo/ * License : GPL Programming Lang: C Description : Operating system database tools These are the tools formerly shipped by libosinfo.
