Re: Misc Developer News (#42)
On Mon, Oct 17, 2016 at 09:53:21AM +0800, Paul Wise wrote: > The news are collected on https://wiki.debian.org/DeveloperNews > Please contribute short news about your work/plans/subproject. > > In this issue: > + git-series: track changes to a patch series over time > + PHP licence applicability to the Debian archive > + New #packaging IRC channel > + SourceForge uscan redirector & subdirs > + LeaseWeb offers discounts to Debian Developers > > git-series: track changes to a patch series over time > - > > Josh Triplett announced[1] a new git tool, git-series[2], to manage patch > series with git, tracking the "history of history". git series tracks > changes to the patch series over time, including rebases and other > non-fast-forwarding changes. git series also tracks a cover letter for > the patch series, formats the series for email, and prepares pull requests. > > This makes it easier to collaborate on a patch series, distribution > package, backport, or any other development process that includes > rebasing or non-fast-forward development. > > Debian package maintenance tends to have this exact family of problems: > maintaining a set of patches to upstream code, rebasing those patches on > new upstream versions, reorganizing/refining/adding/dropping patches, > having individual patches merged upstream, and backporting changes *from* > upstream. > > If you're interested in developing workflows for package maintenance with > git-series, please follow up to debian-devel. More detail is available[3]. > > -- Josh Triplett > > [1] https://lists.debian.org/debian-devel/2016/07/msg00535.html > [2] https://github.com/git-series/git-series/ > [3] https://lists.debian.org/msgid-search/20160812035657.c72mu75x5bmygvva@x > > PHP licence applicability to the Debian archive > --- > > The FTPMasters have published specific guidance[4] to allow PHP 3.0+ > licensed works in the main archive. > This allows software published under the license to be included, but with > specific guidance to the wording in the copyright file. It also serves to > ensure compliance with the ''PHP'' trademark. > > -- Neil McGovern > > [4] https://ftp-master.debian.org/php-license.html > > New #packaging IRC channel > -- > > There have been some folks who aren't satisfied with the level of signal > to noise on the #debian-mentors IRC channel, mainly around people joining > who are not aiming at creating policy compliant packages for upload to > the Debian archive. People looking for help with private packaging, > packaging for derivatives, packaging for their external repos and so on. > As a result I've created the #packaging channel on OFTC to help such > folks and reduce the noise on #debian-mentors. If you don't mind helping > such folks out, please join us! If you have such questions, please join > #packaging instead. > > -- Paul Wise > > SourceForge uscan redirector & subdirs > -- > > Some upstreams have identically named tarballs in different > subdirectories in their SourceForge file area. The Debian uscan > redirector for SourceForge now emits extra links that include the full > path to upstream files. This means that you now can choose which > particular upstream subdirectories that you want to match files from. > Here is an example for the boost package: > > version=3 > opts="uversionmangle=s/_/./g,dversionmangle=s/\+dfsg$//" \ > http://sf.net/boost/ .*/[.\d]+/boost_([\d_]*)\.tar.bz2 > > -- Paul Wise > > LeaseWeb offers discounts to Debian Developers > -- > > One of the major sponsors behind snapshot.debian.org, LeaseWeb[5], is now > offering discounts on their services to Debian Developers. > > LeaseWeb provides dedicated servers, bare metal servers, private clouds, > virtual servers and content delivery networks. LeaseWeb offers discounts > to Debian Developers. > > DDs should send emails to sa...@us.leaseweb.com (for North America) or > sa...@nl.leaseweb.com (for Europe) from their @debian.org address > referencing "debian.org membership special offer". > > The specific amount of discount is dependent on the service requested and > the availability of resources (eg, number of dedicated servers available > at the time of the request). > > Other benefits[6] are also available to Debian members and contributors. > > [5] https://www.leaseweb.com > [6] https://wiki.debian.org/MemberBenefits > > -- > bye, > pabs > > https://wiki.debian.org/PaulWise -- cheers, Holger signature.asc Description: Digital signature
Re: Misc Developer News (#42)
Hi & sorry for the noise. Upon re-reading when replying I realized I didnt have anything to add/ask and then failed to cancel sending… To add some signal. I'll just say: Thanks for these developer news! -- cheers, Holger signature.asc Description: Digital signature
Bug#841047: ITP: r-hms-dbmi-spp -- GNU R package for processing ChIP-seq & other functional sequencing data
Package: wnpp Severity: wishlist Owner: Debian Med team * Package name: r-hms-dbmi-spp Version : 1.14 Upstream Author : peterK * URL : http://compbio.med.harvard.edu/Supplements/ChIP-seq/ * License : GPL-2 Programming Lang: R, C++ Description : GNU R package for processing ChIP-seq & other functional sequencing data A set of routines for reading short sequence alignments, calculating tag density, estimates of statistically significant enrichment/depletion along the chromosome, identifying point binding positions (peaks), and characterizing saturation properties related to sequencing depth. Dependency of phantompeakqualtools, a dependency of the new pRSEM feature in rsem. Will be group maintained by the Debian Med team.
Problem with dpkg-source -b outside of package source dir
Hello, according to the man page, dpkg-source -b takes an argument that is "the name of the directory containing the debianized source tree". But that does not work for me if the current directory is not the package's source directory. When I execute dpkg-source in the package's source directory, i.e. /tmp/test/pkg$ dpkg-source -b . everything works fine. But if I execute dpkg-source from a different directory with the source directory as the argument to -b, e.g. /tmp$ dpkg-source -b /tmp/test/pkg dpkg-source complains that it can't find the original tarball at ../pkg_vers.orig.tar.*. Shouldn't it look into /tmp/test/pkg/..? The problem does not occur with native packages as they do not require an original tarball. I'm using dpkg-source 1.17.27 in Debian jessie Malte
Bug#841069: ITP: node-extend-shallow -- Extend an object with the properties of additional objects
Package: wnpp Severity: wishlist Owner: Pirate Praveen X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-extend-shallow Version : 2.0.1 Upstream Author : Jon Schlinkert (https://github.com/jonschlinkert) * URL : https://github.com/jonschlinkert/extend-shallow * License : Expat Programming Lang: JavaScript Description : Extend an object with the properties of additional objects. node.js/javascript util. signature.asc Description: OpenPGP digital signature
Bug#841075: ITP: node-collection-visit -- Visit a method over the items in an object, or map visit over the objects in an array
Package: wnpp Severity: wishlist Owner: Sruthi Chandran X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-collection-visit Version : 0.2.3 Upstream Author : Jon Schlinkert (https://github.com/jonschlinkert) * URL : https://github.com/jonschlinkert/collection-visit * License : Expat Programming Lang: JavaScript Description : Visit a method over the items in an object, or map visit over the objects in an array
Re: non-Debian software on ftp*.*.debian.org mirrors
> Lars Wirzenius writes: > On Sun, Oct 16, 2016 at 11:50:46AM +, Ivan Shmakov wrote: >> Doesn’t the presence of the ‘non-free’ section in the official >> Debian Release (InRelease) files /already/ mislead inexperienced >> people into thinking that such software is either part of Debian or >> endorsed by the project (or both)? > https://www.debian.org/social_contract point 5. > We're not exactly unclear about non-free and contrib. I'd say that those who can discern Debian non-free from Debian proper are at low risk of confusing, say, [1] with the "software [...] endorsed or even produced by Debian." [1] http://ftp.se.debian.org/mirror/opensolaris.com/ -- FSF associate member #7257 58F8 0F47 53F5 2EB2 F6A5 8916 3013 B6A0 230E 334A
Re: [buildd] unexpected FTBFS on amd64 buildd «binet»
On Mon, Oct 17, 2016 at 03:10:57AM +0100, Ben Hutchings wrote: > On Sun, 2016-10-16 at 18:57 +0300, Adrian Bunk wrote: > [...] > > You should fix your package so that it works on the lowest supported > > hardware of each port. > > Right. > > > Autobuilding is only a small part of the problem, your package would > > also not run on many computers that Debian does support. > > > > That means nothing higher than SSE2 on amd64, and no SSE at all on i386. > [...] > > On i386 we cannot even assume MMX, as the earliest 686 models don't > have it. That is true, but what is supported and what is not is more complicated and depends on what exactly gcc/binutils define as "i686". The root of the problem is that the "earliest 686 model" is the Pentium Pro. The Pentium Pro does not support MMX, even though many 586 CPUs do. And much worse, what is supported by the Pentium Pro is not a subset of what is supported by all other 686 CPUs. MMX is supported by many 586 CPUs like the AMD K6 and the Pentium MMX, but it is not part of i686. Optional in 686 but emitted by the gcc i686 is CMOV, and that is the reason why even some desktop and laptop CPUs released as late as 2002 [1] will no longer be supported in stretch. Several 686 CPUs, including all VIA C3s (even the ones with CMOV) and all Geodes, do not support NOPL. Due to the OLPC laptop using Geode, binutils were upstream-patched in 2010 (sic) to no longer emit NOPL for i686. So what exactly gcc/binutils define as "i686" (and what will therefore be supported by the i386 port in stretch) does not only depend on what the earliest 686 CPUs supported back in 1995 - it does also depends on politics in 2010. > Ben. cu Adrian [1] Via C3 1.0T -- "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
Re: non-Debian software on ftp*.*.debian.org mirrors
On Mon, Oct 17, 2016 at 12:55:39PM +, Ivan Shmakov wrote: > I'd say that those who can discern Debian non-free from Debian > proper are at low risk of confusing, say, [1] with the "software > [...] endorsed or even produced by Debian." http://ftp.se.debian.org/ and http://ftp.se.debian.org/mirror/ both declare that it is a server run by an organisation called ACC at the Umeå University. I think the risk of confusion here is highly overstated. Remember that all mirror sites are donated to Debian: the hardware, the bandwidth, the hosting, and the sysadmin work to keep it running. We don't want to make it difficult to donate this kind of stuff to Debian. Requiring the donators to set up their servers in particular ways makes it harder to do that. I'd rather risk the tiny chance of people being confused than people not running Debian mirrors for us. Besides, if someone is confused, that's an excellent opportunity to talk to them about what Debian actually is. -- I want to build worthwhile things that might last. --joeyh signature.asc Description: PGP signature
Re: Is missing SysV-init support a bug?
I just want to respond after all this time because I ignored this debate as I hadn't had time for it. Russ you state in the email of 30-08 that you wish people would realize the nuances between a system that can do one thing and a system that can do another thing and both have advantages, and Simon Richter stated the same and wrote a long blog post that I've also read. When I voiced my problem with the idea that SystemD would be by definition superior, it was along the same idea. I have no issue whatsoever with claiming that SystemD is better at some things. (And I write SystemD with caps because that makes it easier to read, people invented capitals for a reason). I only had an issue with unequivocally claiming that SystemD would be better at "everything" and hence be the "superior" project. I like to say that superiority is something you can only claim based on a goal; the goal is a subjective thing, once you have the subjective thing (the goal) you can make objective assessments with regards to that goal. But you cannot make universal statements as to the superiority of anything. A broken pot is superior at watering the ground. It may not be superior for holding and watering the plants held within it, but surely it will do a better job at spilling water on the ground. That's why I wrote, as has been responded to, "But that's not the relevance. The idea that systemd is clearly superior to sysvinit is just something you concoct up because you don't know how to write a service file or script and you want to let systemd do the hard work.", and for no other reason really. I mean, Mac lovers love Apple, and apple provides very high level functionality that has very low flexibility. If its model is not suitable to you, you cannot use the software. At the same time these people might claim "What's your problem? It's just easier!". I never claimed SysV was superior. I just had a problem with the unequivocal "superiority" of SystemD being used as a brandishing stick to burn SysV scripts with. So Nikolaus Rath's response that: "How is that concoted? Yes, systemd is clearly superior to sysvinit because it doesn't require me to know how to write a service file or script but does the hard work for me." -- was unwarranted. I was not arguing for the superiority of SysV. I was arguing against the superiority of SystemD. I was basically arguing against superiority, not for it. I just thought that the reasons for saying that "SystemV-init was outdated, and we're in 2016 now, and any sensible developer will know that SystemD is superior" -- and all of that --- were populist in nature and not rational; as if we have a Robber's Cave experiment where we have to prove which is the best team -- but there can only be one winner.
Bug#841083: ITP: node-fill-range -- Fill in a range of numbers or letters
Package: wnpp Severity: wishlist Owner: Pirate Praveen X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-fill-range Version : 3.0.3 Upstream Author : Jon Schlinkert (https://github.com/jonschlinkert) * URL : https://github.com/jonschlinkert/fill-range * License : Expat Programming Lang: JavaScript Description : Fill in a range of numbers or letters, optionally passing an increment or `step` to use, or create a regex-compatible range with `options.toRegex` signature.asc Description: OpenPGP digital signature
Bug#841084: ITP: node-arr-union -- Combines a list of arrays, returning a single array with unique values, using strict equality for comparisons
Package: wnpp Severity: wishlist Owner: Sruthi Chandran X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-arr-union Version : 3.1.0 Upstream Author : Jon Schlinkert (https://github.com/jonschlinkert) * URL : https://github.com/jonschlinkert/arr-union * License : Expat Programming Lang: JavaScript Description : Combines a list of arrays, returning a single array with unique values, using strict equality for comparisons
lamenting current developments [was: Re: Is missing SysV-init support a bug?]
I also want to just quickly summarize my position here, since some very long posts were written on this and linked into the thread by someone. I have only three issues with SystemD in order of diminishing importance: 1) it is very hard to get up to speed with systemd, you run up against walls where you don't know how to proceed 2) the lack of flexibility mentioned by Russ and Simon. It is very hard to schedule something for shutdown alone, for instance. 3) the bad command environment; journalctl, systemctl, all of the -ctl names are hard to use. It is not user friendly, you get confused, you type the wrong things; apt (and its verbs) is like the opposite of that; easy, fast, quick to learn, quick to remember. For me all of that points to a bad design and I haven't read the criticism that was also linked in this thread (by Jonathan de Boyne Pollard, on 01-09 (september)). Personally I would not have made the choice to go with SystemD (site wide, so to speak) because I think SysV init can be improved and I disagree with the notion that it could not be used as the basis for something that would provide more standardized services, but of course I never went there as a person. Precisely because it is based on scripts (while also having descriptive elements) it can be evolved into something into something that does a better job than it does now until it would get to the point where you started replacing scripts with something more solid after you got the model for that right, but of course I never did any of that. The main issue I have with it personally is that once you have a higher level functionality built on a bad model it will be impossible to change it. As long as you stick to the lesser-high level functionality based on a good model, you are still free to go in whatever you like. The SystemD integration has cut off development paths and trackts and makes it virtually impossible to go back after the fact and take another path still. It's a consolidation but it means the interest for an alternative path will become less and less while all the while having a system built on a very bad model with deep issues relating to the many failure cases SystemD can have and that I witness quite often. Just today someone ran into the problem of trying to mount some local filesystems on top of NFS but it couldn't be done because SystemD orders remote mounts after local mounts. The unaware person will not have a single clue as to why it is not working. There are more directives that get conveniently broken by SystemD when it messes or interferes with its ordering mechanics. People continually run into things that do not work as expected and this "breach of contract" is the biggest issue. Most of the time you will simply not know how to do something until you ask the developers or someone with experience. And then they will mention caveat #2311. But it was impossible to know beforehand and that turns it into an oblique system. And troubleshooting boot failures is rather expensive... So for me personally it is a very independable system with a high risk of breaking the moment you change something, anything, whteher it is custom encryption, or some mount, or anything else. Shutdown can take very long for reasons you don't know and have almost no way to troubleshoot. And this is just my personal impression, my personal experience that I have to deal with, nothing else. Just stating what it is for me without any comparison to any other system. I mean the things I run into with Systemd. These things stand on their own and are just true, for me, they have happened, all of them. That's all, I just think I am worse off because a /bad/ high level feature had closed off development paths to alternatives since pretty much no one is going to be interested in it, or that there would be developers interested in it, nor that it becomes easier to run these systems, and have them available for yourself to work with. So if I am at any time vehemently arguing for the non-throwing-away of some script, it is also because I see opportunities for myself grow dimmer by the minute... That's all. And I can't fight that because I'm not "there" and I am not in that position to actually do something with it. But the chances of /getting/ to that position become worse. So personally, for me, not only as a user, but also as a developer, I see conditions worsen. I like SysV-init better because it has more potential, you can do more with it, you can go directions with it. It is an open-ended story, but SystemD is not. I can't take SystemD and turn it into something else. That's practically impossible. I could have taken SysV and turned it into something else, easily. I wasn't there yet, but I could have gotten there in time. But the chances of that ever taking place (within reasonable time) are now probably 20% of what they were before. I like systems in their early
Re: When should we https our mirrors?
TL;DR: Would we now recommend deb.d.o over httpredir.d.o for production use e.g. in base images (including for Jessie)? On Sun, 2016-10-16 at 09:11 +0800, Paul Wise wrote: > httpredir.d.o is not well maintained There still seems to be general grumbling (including a persistent drip of CI failures and the odd end user bug report) at $dayjob about failures which are ultimately down to the use of httpredir in the base container images. > deb.d.o is backed by two commercial CDNs, Have we gotten to the point where we consider deb.d.o suitable for production use? The web page still says Experimental (so I would assume "not production yet") and I'm not really sure if there will be a distinction between >=Stretch and <=Jessie in this regards. It looks like Jessie and earlier get a fallback mode of operation, but is that mode of operation suitable to be recommended for production? If not deb.d.o then what would people recommend these days? Ian.
Re: When should we https our mirrors?
On Mon, 17 Oct 2016, Ian Campbell wrote: > TL;DR: Would we now recommend deb.d.o over httpredir.d.o for production > use e.g. in base images (including for Jessie)? Yes. > On Sun, 2016-10-16 at 09:11 +0800, Paul Wise wrote: > > httpredir.d.o is not well maintained > > There still seems to be general grumbling (including a persistent drip > of CI failures and the odd end user bug report) at $dayjob about > failures which are ultimately down to the use of httpredir in the base > container images. We get a few mails about the redirector failing at the mirrors@ address every week. Very few get answered. :( > > deb.d.o is backed by two commercial CDNs, > > Have we gotten to the point where we consider deb.d.o suitable for > production use? The web page still says Experimental (so I would assume > "not production yet") and I'm not really sure if there will be a > distinction between >=Stretch and <=Jessie in this regards. It looks > like Jessie and earlier get a fallback mode of operation, but is that > mode of operation suitable to be recommended for production? The fallback is not only needed for old apt versions but also for clients behind webproxies that don't do SRV record lookups. (Which, at a guess, would be all of them). > If not deb.d.o then what would people recommend these days? If you don't have a good local mirror (or you don't have a specific local), I would recommend deb.debian.org these days. -- | .''`. ** Debian ** Peter Palfrader | : :' : The universal https://www.palfrader.org/ | `. `' Operating System | `-https://www.debian.org/
Re: lamenting current developments [was: Re: Is missing SysV-init support a bug?]
On 2016-10-17 16:04, Bart Schouten wrote: I also want to just quickly summarize my position here, since some very long posts were written on this and linked into the thread by someone. And you then wrote another very long post. We really don't need another one. Regards, Adam
Re: When should we https our mirrors?
(Please Cc me if you want me to notice any response.) Paul Tagliamonte (2016-10-15): > I find most of these arguments pretty boring, and I don't think the > "costs" outweigh the benefits. > > > I see no reason why the argument that the mirror server may be > compromised means we have to open ourselves up to trivial MITM and > installed packages / versions disclosure to everyone between me and > the server. > > I see no reason why just because we check signatures later that I put > random data from the internet into memory and on disk, and run a > program over it without making sure it's at least the server I think > I'm talking to. > > I see no reason why exotic pet arches that already take huge cycles to > process data are a reason to keep back the vast majority of our install > base. > > > So, the real question: > > So, when are we going to push this? If not now, what criteria need to be > met? Why can't we https-ify the default CDN mirror today? > > (Sadly this means my trick to MITM the debian mirrors with my LAN mirror > breaks, but this strikes me as a feature not a bug) AFAICT from a recent https deployment, apt will perform a TLS handshake for each and every file it downloads from the mirror; including indices, translations, pdiffs, and finally debian packages. Either I've blatantly failed at noting what happened there (which is entirely possible since I was limited in time), or this HTTPS everywhere suggestion would lead to huge wastes in resources if apt doesn't get fixed. (Cc-ing deity@ for fact-checking purposes.) KiBi. signature.asc Description: Digital signature
Re: When should we https our mirrors?
On Mon, Oct 17, 2016 at 15:24:42 +, Peter Palfrader wrote: > On Mon, 17 Oct 2016, Ian Campbell wrote: > > > Have we gotten to the point where we consider deb.d.o suitable for > > production use? The web page still says Experimental (so I would assume > > "not production yet") and I'm not really sure if there will be a > > distinction between >=Stretch and <=Jessie in this regards. It looks > > like Jessie and earlier get a fallback mode of operation, but is that > > mode of operation suitable to be recommended for production? > > The fallback is not only needed for old apt versions but also for > clients behind webproxies that don't do SRV record lookups. (Which, at > a guess, would be all of them). > Also, the fallback is "just" a http redirect, so it's the same cost you'd pay when using httpredir.d.o. Cheers, Julien
Re: When should we https our mirrors?
❦ 17 octobre 2016 17:39 +0200, Cyril Brulebois : > AFAICT from a recent https deployment, apt will perform a TLS handshake > for each and every file it downloads from the mirror; including indices, > translations, pdiffs, and finally debian packages. > > Either I've blatantly failed at noting what happened there (which is > entirely possible since I was limited in time), or this HTTPS everywhere > suggestion would lead to huge wastes in resources if apt doesn't get > fixed. There are tickets (RFC 5077) to avoid this. It's easy to implement as long as the same process is used for all requests. This is automatic with OpenSSL. With GNU TLS, I don't think this is automatic but this is just a matter of calling gnutls_session_ticket_enable_client() on the session. Most servers will support that out of the box. I have tools to check that here (but they may not work with the API change in OpenSSL): https://github.com/vincentbernat/rfc5077 -- Let the machine do the dirty work. - The Elements of Programming Style (Kernighan & Plauger) signature.asc Description: PGP signature
Bug#841091: ITP: node-get-value -- Use property paths to get a nested value from an object
Package: wnpp Severity: wishlist Owner: Sruthi Chandran X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-get-value Version : 2.0.6 Upstream Author : Jon Schlinkert (https://github.com/jonschlinkert) * URL : https://github.com/jonschlinkert/get-value * License : Expat Programming Lang: JavaScript Description : Use property paths (`a.b.c`) to get a nested value from an object
Re: When should we https our mirrors?
On Sun, Oct 16, 2016 at 09:11:42AM +0800, Paul Wise wrote: > Exactly what actions do you mean by this? > > Debian does not control what mirror operators do, they are free to add > https or not. Some do but most don't. We do control the CDN. We can also start to move systems with a new apt to a HTTP redirect-based mirror network using HTTPS only. This could become the default, and new mirrors can add themselves when they're ready, and as stable ages out, so does our use of HTTP. Or whatever. > httpredir.d.o is not well maintained, but it could theoretically > support https if someone cared about it. > > deb.d.o is backed by two commercial CDNs, see Tollef's mail about that. Sounds like a great starting point :) Cheers, Paul
Re: Is missing SysV-init support a bug?
On Oct 17 2016, Bart Schouten wrote: > (And I write SystemD with caps because that makes it > easier to read, people invented capitals for a reason). What would you think some people consistently spelled your name as Bart SchouteN with the same justification? And if that set of people also happened to coincide exactly with your most vocal critics? How you write your emails is up to you, but you're not making it likely for them to be well received. Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.«
Bug#841097: ITP: node-repeat-element -- Create an array by repeating the given value n times
Package: wnpp Severity: wishlist Owner: Pirate Praveen X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-repeat-element Version : 1.1.2 Upstream Author : Jon Schlinkert (https://github.com/jonschlinkert) * URL : https://github.com/jonschlinkert/repeat-element * License : Expat Programming Lang: JavaScript Description : Create an array by repeating the given value n times. signature.asc Description: OpenPGP digital signature
Bug#841099: ITP: node-has-values -- Returns true if any values exist, false if empty
Package: wnpp Severity: wishlist Owner: Sruthi Chandran X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-has-values Version : 0.1.4 Upstream Author : Jon Schlinkert (https://github.com/jonschlinkert) * URL : https://github.com/jonschlinkert/has-values * License : Expat Programming Lang: JavaScript Description : Returns true if any values exist, false if empty
Bug#841104: ITP: cspice -- C implementation of The SPICE Toolkit
Package: wnpp Severity: wishlist Owner: Rock Storm * Package name: cspice Version : 0065 Upstream Author : NASA's Navigation and Ancillary Information Facility (NAIF) * URL : http://naif.jpl.nasa.gov/naif/index.html * License : public-domain Programming Lang: C Description : C implementation of The SPICE Toolkit SPICE (Spacecraft Planet Instrument C-matrix Events) is a NASA ancillary information system used to compute geometric and event information in analyzing and planning science observations obtained from spacecraft. It is also used in planning missions and conducting numerous engineering functions needed to carry out those missions. SPICE has become the de facto standard for handling much of the so-called observation geometry information on NASA's planetary missions, and it is now widely used in support of science data analysis on planetary missions of other space agencies as well. Some SPICE capabilities are used on a variety of astrophysics and solar physics missions, such as JAXA's Hayabusa project, ESA's Rosetta or NASA's Steins. I would like this package to be maintained either by the Debian Astro team or, if it were outside its scope, the Debian Science team. Regards, Rock
Bug#841105: ITP: node-copy-descriptor -- Copy a descriptor from object A to object B
Package: wnpp Severity: wishlist Owner: Sruthi Chandran X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-copy-descriptor Version : 0.1.1 Upstream Author : Jon Schlinkert (https://github.com/jonschlinkert) * URL : https://github.com/jonschlinkert/copy-descriptor * License : Expat Programming Lang: JavaScript Description : Copy a descriptor from object A to object B
Re: When should we https our mirrors?
On Mon, 2016-10-17 at 15:24 +, Peter Palfrader wrote: > On Mon, 17 Oct 2016, Ian Campbell wrote: > > > TL;DR: Would we now recommend deb.d.o over httpredir.d.o for production > > use e.g. in base images (including for Jessie)? > > Yes. Thanks!
Bug#841113: ITP: extremetools -- tools for running processes under extreme uid and gid
Package: wnpp Severity: wishlist Owner: Jan Mojzis * Package name: extremetools Version : 20161017 Upstream Author : Jan Mojžíš * URL : https://github.com/janmojzis/extremetools * License : public-domain Programming Lang: C Description : tools for running processes under extreme uid and gid Extremetools consists of 2 simple tools extremesetuidgid and extremeenvuidgid. - extremesetuidgid runs program under unique (extreme) uid and gid - extremeenvuidgid runs program with environment variables indicating unique (extreme) uid and gid This is useful for running processes in the system under unique (extreme) uids/gids. So processes can't ptrace each other, can't send signal each other, etc ... --- I'm going to maintain the package using collab-maint. I need sponsor. Debian package: - has autotest - is using debhelper - is using git-dpm https://anonscm.debian.org/cgit/collab-maint/extremetools.git - lintian clean (no warnings)
Re: When should we https our mirrors?
On 10/17/2016 05:39 PM, Cyril Brulebois wrote: > AFAICT from a recent https deployment, apt will perform a TLS handshake > for each and every file it downloads from the mirror; including indices, > translations, pdiffs, and finally debian packages. Last I checked it pipelined within a single TLS connection (well, one per host). A casual Wireshark seems to confirm that. Kind regards Philipp Kern
Re: When should we https our mirrors?
❦ 17 octobre 2016 16:21 +0100, Ian Campbell : > TL;DR: Would we now recommend deb.d.o over httpredir.d.o for production > use e.g. in base images (including for Jessie)? I get a 404 from time to time. Doing a second apt full-upgrade fixes the issue. This works far better than httpredir.d.o. However, this works less reliably than a fixed classic mirror. The speed varies a lot during the day and I never achieve the speed I get with a country mirror (I am in Switzerland with a 100M connection). We also saw that in some part of the world, this is slow as hell (in South Africa for example). No perfect solution yet. -- Make sure all variables are initialised before use. - The Elements of Programming Style (Kernighan & Plauger) signature.asc Description: PGP signature
Re: When should we https our mirrors?
Philipp Kern (2016-10-17): > On 10/17/2016 05:39 PM, Cyril Brulebois wrote: > > AFAICT from a recent https deployment, apt will perform a TLS handshake > > for each and every file it downloads from the mirror; including indices, > > translations, pdiffs, and finally debian packages. > > Last I checked it pipelined within a single TLS connection (well, one > per host). A casual Wireshark seems to confirm that. Ah. What I saw might have been due to client cert auth then? I guess I should revisit this setup when I find more time. There's also Pipeline- Depth option's being advertised as not supported for https, too. KiBi. signature.asc Description: Digital signature
Debian and the node-js eco system
On Mon, Oct 17, 2016 at 08:23:19PM +0200, Andrew Shadura wrote: > Hi, > > On 17 October 2016 at 18:57, Sruthi Chandran wrote: > > Package: wnpp > > Severity: wishlist > > Owner: Sruthi Chandran > > X-Debbugs-CC: debian-devel@lists.debian.org > > > > * Package name: node-has-values > > Version : 0.1.4 > > Upstream Author : Jon Schlinkert (https://github.com/jonschlinkert) > > * URL : https://github.com/jonschlinkert/has-values > > * License : Expat > > Programming Lang: JavaScript > > Description : Returns true if any values exist, false if empty > > Honestly, I???d like to object to packaging a 31 line script in a > separate package. I???d rather see a package named > node-jonschlinkert-modules with all modules bundled, which would > Provides: node-has-values, node-copy-descriptor, ??? +1 Thing I would like to see, is that all those "node js package" get their own component. ( 'main', 'contrib' and 'non-free' are components ) Groeten Geert Stappers -- Leven en laten leven
Bug#841122: ITP: libgeo-constants-perl -- standard constants used by Geo perl packages
Package: wnpp Owner: Florian Schlichting Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libgeo-constants-perl Version : 0.06 Upstream Author : Michael R. Davis * URL : https://metacpan.org/release/Geo-Constants * License : Artistic or GPL-1+ Programming Lang: Perl Description : standard constants used by Geo perl packages Geo::Constant provides a number of standard constants used by the Geo:: family of modules, such as Pi, conversion from degrees to radians or nautical miles to meters per second, and vice versa. The package will be maintained under the umbrella of the Debian Perl Group.
Bug#841125: ITP: libgeo-functions-perl -- standard functions for Geo perl modules
Package: wnpp Owner: Florian Schlichting Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libgeo-functions-perl Version : 0.07 Upstream Author : Michael R. Davis * URL : https://metacpan.org/release/Geo-Functions * License : Artistic or GPL-1+ Programming Lang: Perl Description : standard functions for Geo perl modules The Geo::Functions module provides some standard functions for conversions, for example between degrees, radians and degrees minutes seconds, or between knots and meters per second. The package will be maintained under the umbrella of the Debian Perl Group.
Re: Bug#841099: ITP: node-has-values -- Returns true if any values exist, false if empty
Andrew Shadura wrote: > Honestly, I’d like to object to packaging a 31 line script in a separate > package. These are distinct packages, with distinct version numbers, and packages will need to declare (potentially versioned) dependencies on them. Packaging numerous libraries in a single source package has downsides as well, such as larger uploads any time *any* component of the package changes, or any time a new component gets added. I would, in general, object to packages like this *if they're not being packaged as part of the dependency/build-dependency tree of some other intended package*, but in general, I think we need to be prepared to deal with upstreams that have small single-purpose packages. I don't think we should package the entire node ecosystem, but packaging the subset of it needed for end-user-targeted packages seems fine. Also, consider the ongoing issue of packaging high-level JavaScript libraries and frameworks correctly, whose build-dependency toolchains for processes like minimization/"browserification" have numerous packages like these in them. If we're going to require the packaging of all the tools needed to build such libraries, which I absolutely think we should, then let's not simultaneously put up roadblocks every time someone tries to do so.
Re: Bug#841099: ITP: node-has-values -- Returns true if any values exist, false if empty
Hallo, * Andrew Shadura [Mon, Oct 17 2016, 08:23:19PM]: > Hi, > > On 17 October 2016 at 18:57, Sruthi Chandran wrote: > > Package: wnpp > > Severity: wishlist > > Owner: Sruthi Chandran > > X-Debbugs-CC: debian-devel@lists.debian.org > > > > * Package name: node-has-values > > Version : 0.1.4 > > Upstream Author : Jon Schlinkert (https://github.com/jonschlinkert) > > * URL : https://github.com/jonschlinkert/has-values > > * License : Expat > > Programming Lang: JavaScript > > Description : Returns true if any values exist, false if empty > > Honestly, I’d like to object to packaging a 31 line script in a > separate package. I’d rather see a package named > node-jonschlinkert-modules with all modules bundled, which would > Provides: node-has-values, node-copy-descriptor, … +1 Seriously, can we please keep this nodejs stuff out of the main repository? It's not like I don't trust APT guys in finding the right bullet to deal with thousands of trivial packages but do we really have to care about the costs of all that spam littering up our namespace? Regards, Eduard.
Bug#841127: ITP: libgeo-ellipsoids-perl -- standard Geo:: ellipsoid a, b, f and 1/f values
Package: wnpp Owner: Florian Schlichting Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libgeo-ellipsoids-perl Version : 0.16 Upstream Author : Michael R. Davis * URL : https://metacpan.org/release/Geo-Ellipsoids * License : Artistic or GPL-1+ Programming Lang: Perl Description : standard Geo:: ellipsoid a, b, f and 1/f values Geo::Ellipsoids provides a large number of standard ellipsoid values useful for calculations such as when determining the distance between two points on a planet. The package will be maintained under the umbrella of the Debian Perl Group.
Bug#841130: ITP: libgeo-inverse-perl -- module to calculate geographic distance from a lat & lon pair
Package: wnpp Owner: Florian Schlichting Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libgeo-inverse-perl Version : 0.05 Upstream Author : Michael R. Davis * URL : https://metacpan.org/release/Geo-Inverse * License : Artistic or GPL-1+ Programming Lang: Perl Description : module to calculate geographic distance from a lat & lon pair Geo::Inverse is a pure Perl port of the NGS program in the public domain "inverse" by Robert (Sid) Safford and Stephen J. Frakes. It can be used to calculate the distance, forward and back azimuth from a latitude and longitude pair. The package will be maintained under the umbrella of the Debian Perl Group.
Re: Bug#841099: ITP: node-has-values -- Returns true if any values exist, false if empty
On Mon, Oct 17, 2016 at 10:28:53PM +0200, Eduard Bloch wrote: > Hallo, > * Andrew Shadura [Mon, Oct 17 2016, 08:23:19PM]: > > Hi, > > > > On 17 October 2016 at 18:57, Sruthi Chandran wrote: > > > Package: wnpp > > > Severity: wishlist > > > Owner: Sruthi Chandran > > > X-Debbugs-CC: debian-devel@lists.debian.org > > > > > > * Package name: node-has-values > > > Version : 0.1.4 > > > Upstream Author : Jon Schlinkert (https://github.com/jonschlinkert) > > > * URL : https://github.com/jonschlinkert/has-values > > > * License : Expat > > > Programming Lang: JavaScript > > > Description : Returns true if any values exist, false if empty > > > > Honestly, I’d like to object to packaging a 31 line script in a > > separate package. I’d rather see a package named > > node-jonschlinkert-modules with all modules bundled, which would > > Provides: node-has-values, node-copy-descriptor, … > > +1 > > Seriously, can we please keep this nodejs stuff out of the main repository? > > It's not like I don't trust APT guys in finding the right bullet to deal > with thousands of trivial packages but do we really have to care about > the costs of all that spam littering up our namespace? I do not think insulting language like "spam" is helpful here. In unstable there are around 3500 packages for perl modules, and even more for python modules. The whole JS ecosystem still being a bit immature is a real problem, but the number of packages itself is not a problem. I am not a fan of all that JS stuff, but I do not see any valid basis for rejecting such packages in general. > Regards, > Eduard. 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
Re: Is missing SysV-init support a bug?
Nikolaus Rath schreef op 17-10-2016 18:26: On Oct 17 2016, Bart Schouten wrote: (And I write SystemD with caps because that makes it easier to read, people invented capitals for a reason). What would you think some people consistently spelled your name as Bart SchouteN with the same justification? I would consider that bigotry as SystemD is short pretty much for System Daemon. Also, I do not consider or remember that you are systemd employees. I am glad you are spending your time on things that are important though. And if that set of people also happened to coincide exactly with your most vocal critics? How you write your emails is up to you, but you're not making it likely for them to be well received. Because I write the name of a project in the most reasonable capitalized form. You really have your priorities right, sir. Best, -Nikolaus
Re: lamenting current developments [was: Re: Is missing SysV-init support a bug?]
Adam D. Barratt schreef op 17-10-2016 17:38: On 2016-10-17 16:04, Bart Schouten wrote: I also want to just quickly summarize my position here, since some very long posts were written on this and linked into the thread by someone. And you then wrote another very long post. We really don't need another one. Well, I'm glad you're never hostile to anyone else either, Adam. I did not say those posts were written here (they were blog posts linked in and people were urged to read it) and I do also not intend to start debating, I was just cleaning up old email and I ran across this, and just felt I needed to finish that. Alright? I am also unsubscribing because the bug reports (are they part of debian-devel?) are too much of a distraction. It is also pretty remarkable that by their own actions the ones who want to stifle a debate or cut short a chain of messages often act in such a way as to further a new chain of messages to arrive, or arise. By their rudeness and hostility they often prompt more responses when that was never the intent of the original poster. Bug reports made out of a bug report system fall into that category, where they give rise to heated debate when such was never the intent of the reporter; he or she merely wanted to pass something along. A report of something that's not working is then met by hostile responses that question everything that has been said, when the intent was clearly to provide support, not defamation. Maybe you should stop thinking the entire world is against you, you know. You could also respond with "Well thank you for your opinion, I hope it is closed that way for now." Or anything of the kind. But no, you choose hostility. In any case, regards, and cya<-- go ahead and prove me right, right now. *Shakes head*.
Bug#841136: ITP: sagemath -- Sage: Open Source Mathematical Software
Package: wnpp Severity: wishlist Owner: Ximin Luo * Package name: sagemath Version : 7.4 Upstream Author : SageMath developers * URL : https://www.sagemath.org/ * License : GPL-2+ Programming Lang: Python Description : Sage: Open Source Mathematical Software SageMath is a free open-source mathematics software system licensed under the GPL. It builds on top of many existing open-source packages: NumPy, SciPy, matplotlib, Sympy, Maxima, GAP, FLINT, R and many more. Access their combined power through a common, Python-based language or directly via interfaces or wrappers. Mission: Creating a viable free open source alternative to Magma, Maple, Mathematica and Matlab.
Bug#841139: ITP: gajim-triggers -- configure Gajim's behaviour for each contact
Package: wnpp Severity: wishlist Owner: "W. Martin Borgert" * Package name: gajim-triggers Version : 0.1 Upstream Author : Yann Leboulanger * URL : http://trac-plugins.gajim.org/wiki/TriggersPlugin * License : GPL3 Programming Lang: Python Description : configure Gajim's behaviour for each contact With this plugin you will be able to configure precisely Gajim's behaviour when you receive a message or a presence from a given contact.
Re: Bug#841099: ITP: node-has-values -- Returns true if any values exist, false if empty
On Tue, Oct 18, 2016 at 4:21 AM, Josh Triplett wrote: > These are distinct packages, with distinct version numbers, and packages > will need to declare (potentially versioned) dependencies on them. Has anyone involved in the node ecosystem tried to talk the respective upstreams into creating a standard library that contains all these basic functions? -- bye, pabs https://wiki.debian.org/PaulWise
Bug#820036: No bug mentioning a Debian KEK and booting use it.
Yes it one thing to get shim signed by Microsoft. Do remember Microsoft is free to push out updates to the The Forbidden Signatures Database(dbx). Sign a new shim in case of current one being black listed for some reason could take weeks/months from Microsoft. The process to replace PK(platform key) and replace the KEK can be done faster than getting a new shim. Its also a safe guard against Microsoft changing the rules how shims are constructions. Please be aware when Microsoft signing shims they do not use the KEK that is used to sign the windows boot loader. So windows bootloaders are signed with Microsoft Windows Production PCA 2011 and debian shim will be signed with Microsoft Corporation UEFI CA 2011. https://technet.microsoft.com/en-au/library/dn747883.aspx Now there is a line to OEM that should worry the heck out of us. ---On non-Windows RT PCs the OEM should consider including the Microsoft Corporation UEFI CA 2011--- Key words "should consider" so making the "Microsoft Corporation UEFI CA" key and everything signed by optional if it works or not. Microsoft does not mandate OEM install "Microsoft Corporation UEFI CA" only the "Microsoft Windows Production PCA" the one the debian shim will not be signed with .So getting the shim signed by Microsoft does not promise it works on every motherboard. Manually installing Microsoft Corporation UEFI CA if OEM did not include is replace PK(platform key) and upload new KEK set. At this point might has well have the set of processes to install own KEK and will require to provide users with the complete instructions to replace the PK anyhow. Also there appears to be no bug saying to put a system in place to check that the shim had not been added revocation list as Microsoft publishes it here http://www.uefi.org/revocationlistfile to allow early response in case for some reason shim gets blacklist. Secureboot is a mess. A single plan is not going to work.2 plans are required. 1) A signed shim by Microsoft to reduce the number of people who have to replace PK at first. 2) A plan to replace PK and use own KEK set containing the KEKs debian needs. The interesting point from Microsoft OEM documentation is the PK(platform key) rules. Yes this is again https://technet.microsoft.com/en-au/library/dn747883.aspx 1.3.3.3 PK generation Two entries of very big interest. --One per product line. If a key is compromised a whole product line would be vulnerable-- And --One per OEM. While this may be the simplest to set up, if the key is compromised, every PC you manufacture would be vulnerable. To speed up operation on the factory floor, the PK and potentially other keys could be pre-generated and stored in a safe location. -- Debian is a product line or a OEM right so Debian install images can ship with it own premade PK and KEK set/sets so user if required can delete the PK and attempt an alternate functional set particularly if the motherboard lacks the KEK the shim needs .Of course this does not stop users making their own PK and KEK set latter and it not against the rules to-do this. Peter Dolding
Re: Bug#841099: ITP: node-has-values -- Returns true if any values exist, false if empty
On Tue, Oct 18, 2016 at 09:08:04AM +0800, Paul Wise wrote: > Has anyone involved in the node ecosystem tried to talk the respective > upstreams into creating a standard library that contains all these > basic functions? From speaking to someone I know who works with node, they'd be philosophically opposed to this -- the community is rather attached to the micro-dependency model. -- Sean Whitton signature.asc Description: PGP signature
Re: [pkg-gnupg-maint] Bug#840669: Bug#840669: Beware of leftover gpg-agent processes
On Sat 2016-10-15 11:21:29 -0400, Ian Jackson wrote: > 1. gnupg1-compatible authorisation lifetime: I believe this is a deliberate change in semantics from the upstream GnuPG project. In particular, authorization for the use of secret key material is now the responsibility of the gpg-agent. This is an overall win, because it means that no process ever gets access to the secret key in memory *except* for the gpg-agent. The gpg-agent is where these decisions are made. If you want an agent that never caches any passphrase (and therefore has a one-use-per-authorization), this is an easy thing to do by adjusting max-cache-ttl in gpg-agent.conf. you can also set this dynamically with gpgconf (see the --runtime option in gpgconf(1)). > 2. Explicit programmatic control of authorisation lifetime: This is also present in some form with the current gpg, but there are a couple different ways to do it -- you can still set up and tear down a separate gpg-agent (though managing that independently from other sessions can be tricky); you can set authorization cache times that are bounded to the times you prefer; or you can explicitly tear down the agent after a given run. btw, upstream now has fixes to the inotify teardown approach, which i hope to land in debian unstable in the next day or two. Thanks for your engagement on this issue, Ian. --dkg signature.asc Description: PGP signature
Re: Bug#841099: ITP: node-has-values -- Returns true if any values exist, false if empty
On Tuesday 18 October 2016 01:51 AM, Josh Triplett wrote: > Andrew Shadura wrote: >> Honestly, I’d like to object to packaging a 31 line script in a separate >> package. > > These are distinct packages, with distinct version numbers, and packages > will need to declare (potentially versioned) dependencies on them. > Packaging numerous libraries in a single source package has downsides as > well, such as larger uploads any time *any* component of the package > changes, or any time a new component gets added. Yes, it is more effort to package them together and it becomes impossible to declare version-ed dependencies. I tried doing this for ruby-jquery-rails and ruby-rails-assets-jquery (ruby-jquery-rails was providing ruby-rails-assets-jquery), but stopped doing it because I could not declare version-ed dependency on ruby-rails-assets-jquery. > I would, in general, object to packages like this *if they're not being > packaged as part of the dependency/build-dependency tree of some > other intended package*, but in general, I think we need to be prepared > to deal with upstreams that have small single-purpose packages. I don't > think we should package the entire node ecosystem, but packaging the > subset of it needed for end-user-targeted packages seems fine. These are dependencies for grunt. https://wiki.debian.org/Javascript/Nodejs/Tasks/grunt > Also, consider the ongoing issue of packaging high-level JavaScript > libraries and frameworks correctly, whose build-dependency toolchains > for processes like minimization/"browserification" have numerous > packages like these in them. If we're going to require the packaging of > all the tools needed to build such libraries, which I absolutely think > we should, then let's not simultaneously put up roadblocks every time > someone tries to do so. > We are crowd funding grunt/browserify packaging http://igg.me/at/debian-browserify signature.asc Description: OpenPGP digital signature
Bug#841151: ITP: node-isexe -- Minimal module to check if a file is executable
Package: wnpp Severity: wishlist Owner: Pirate Praveen X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-isexe Version : 1.1.2 Upstream Author : Isaac Z. Schlueter (http://blog.izs.me/) * URL : https://github.com/isaacs/isexe#readme * License : ISC Programming Lang: JavaScript Description : Minimal module to check if a file is executable. Dependency for updating which to 1.2.11, which is in turn a dependency of grunt-legacy-util and grunt. signature.asc Description: OpenPGP digital signature
Bug#841152: ITP: node-pascalcase -- Convert a string to pascal-case
Package: wnpp Severity: wishlist Owner: Sruthi Chandran X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-pascalcase Version : 0.1.1 Upstream Author : Jon Schlinkert (https://github.com/jonschlinkert) * URL : https://github.com/jonschlinkert/pascalcase * License : Expat Programming Lang: JavaScript Description : Convert a string to pascal-case
Re: Bug#841099: ITP: node-has-values -- Returns true if any values exist, false if empty
On Tue, Oct 18, 2016 at 10:36:57AM +0530, Pirate Praveen wrote: > Yes, it is more effort to package them together and it becomes > impossible to declare version-ed dependencies. I tried doing this for > ruby-jquery-rails and ruby-rails-assets-jquery (ruby-jquery-rails was > providing ruby-rails-assets-jquery), but stopped doing it because I > could not declare version-ed dependency on ruby-rails-assets-jquery. We have versioned Provides now. -- WBR, wRAR signature.asc Description: PGP signature
Bug#841154: ITP: node-map-cache -- Basic cache object for storing key-value pairs
Package: wnpp Severity: wishlist Owner: Sruthi Chandran X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-map-cache Version : 0.2.2 Upstream Author : Jon Schlinkert (https://github.com/jonschlinkert) * URL : https://github.com/jonschlinkert/map-cache * License : Expat Programming Lang: JavaScript Description : Basic cache object for storing key-value pairs Dependency for Grunt
Re: Bug#840915: ITP: python-github3.py -- comprehensive, actively developed and extraordinarily stable wrapper around the GitHub API (v3)
[2016-10-16 13:15] ChangZhuo Chen (陳昌倬) > > part 1 text/plain 762 > Package: wnpp > Severity: wishlist > Owner: "ChangZhuo Chen (陳昌倬)" > > * Package name: python-github3.py > Version : 0.9.3 > Upstream Author : Ian Cordasco (sigmavirus24) > * URL : https://github.com/sigmavirus24/github3.py > * License : BSD-3-clause > Programming Lang: Python > Description : Python stable wrapper around the GitHub API (v3) > > github3.py is a comprehensive, actively developed and extraordinarily > stable wrapper around the GitHub API (v3). How is it releated to python-github and python3-github already in archives? -- X-Web-Site: https://sinsekvu.github.io | Note that I process my email in batch, Accept-Languages: eo,ru,en | at most once every 24 hours. If matter Accept: text/plain, text/x-diff| is urgent, you have my phone number.
