Re: Debian development and release: always releasable (essay)
Hi, On Samstag, 25. Mai 2013, Petter Reinholdtsen wrote: > Actually, I believe there is. The Debian Edu blend contain the > education-main-server task and metapackage, which include a Kerberos > KDC. It also contain the LDAP server as KDC backend storage and > user/group/etc lookup. there is also the Debian-LAN which is described as "The goal of Debian-LAN is to make setting up a local network with centralized user and machine management, intranet, etc. as easy as possible in Debian." see ://lists.debian.org/20120408083121.GB9680@flashgordon cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: using upstart in Debian
Hi,
On Samstag, 25. Mai 2013, Nikolaus Rath wrote:
> For example: after some intense studying, I now fully understand why
> declaring a new upstart job C that depends on existing jobs A and B
> ("start on job-a-did-its-thing AND job-b-did-its-thing") may prevent the
> start of job A (cf
> https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/964207). However, I
> still consider it confusing and at least questionable design that adding a
> new job can prevent an existing job from starting even though they do not
> conflict in any way.
WHAT?!? if that's true then I for sure know what I won't let near my systems!
That's rather horrible. Thanks for the info!
cheers,
Holger (writing this offline...)
signature.asc
Description: This is a digitally signed message part.
Bug#709907: ITP: libmath-convexhull-monotonechain-perl -- Perl module to calculate a convex hull using Andrew's monotone chain algorithm
Package: wnpp Severity: wishlist Owner: Nicolas Dandrimont * Package name: libmath-convexhull-monotonechain-perl Version : 0.01 Upstream Author : Steffen Mueller, * URL : https://metacpan.org/release/Math-ConvexHull-MonotoneChain * License : GPL-1+ or Artistic (same as Perl) Programming Lang: Perl/C Description : Perl module to calculate a convex hull using Andrew's monotone chain algorithm This (XS) module optionally exports a single function convex_hull which calculates the convex hull of the input points and returns it. Andrew's monotone chain convex hull algorithm constructs the convex hull of a set of 2-dimensional points in O(n*log(n)) time. It does so by first sorting the points lexicographically (first by x-coordinate, and in case of a tie, by y-coordinate), and then constructing upper and lower hulls of the points in O(n) time. It should be somewhat faster than a plain Graham's scan (also O(n*log(n))) in practice since it avoids polar coordinates. This package is a dependency for Slic3r (ITP #689636) and will be maintained under the umbrella of the Debian Perl Group. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130526154644.ga27...@hilbert.home.olasd.eu
optimizing PNGs
Hi folks! A while ago, someone raised the possibility of recompressing PNG files. Unlike xz, this would save space not only on mirrors but also on live installed systems. PNGs are nearly incompressible so this is mostly independent from xz. At least by number, there's a lot of PNG images: zgrep -i '\.png ' Contents-*gz|wc -l 577815 zcat Contents-*gz|wc -l 4296965 (including 3*35 lines of header) This massive number of files seems to be concentrated mostly in a limited number of packages: 35276 widelands-data 28827 libjs-mathjax 5 ns3-doc 19968 jsmath-fonts 13395 openclipart2-png 13296 freefoam-dev-doc 10271 w3-recs 9877 uqm-content 9643 wesnoth-1.11-data 9015 wesnoth-1.10-data 8120 openclipart-png 6773 oxygen-icon-theme 6546 lxde-icon-theme 6272 mixxx-data 5890 gnome-icon-theme 5068 triplea 4641 tuxfootball 4505 gnome-themes-extras 4180 gnome-colors-common 3780 lilypond-doc Some time ago, I tested a number of png optimizers, and the best results, by far, come from using "optipng -o4 -i0 -fix" then "advpng -z4". The former attacks the payload well, then advpng (package advancecomp) has good deflate. -o4 is there because higher optipng levels mess only with zlib arguments, -i0 because advpng is afraid of interlaced files (why?), -fix because advpng refuses to touch files with certain errors like cruft after the end, as Adobe tools like to leave. I did test the alternatives quite thoroughly, but the corpus I needed that for was quite specific. It's possible some other set of tools might be better in general; these settings are the highest for optipng+advpng that make sense, though. So here are the results: size(MB) oo+a widelands-data 105 95.1% 93.4% libjs-mathjax 29 99.0% 98.5% openclipart2-png 476 99.6% 99.4% w3-recs 16 88.4% 84.2% wesnoth-1.11-data 89 98.3% 98.1% fonts-mathjax-extra 4 94.6% 90.0% (sizes include .png images only, o is optipng, o+a optipng+advpng) Nothing stunning, I'm not sure if savings of this kind are worth a lot of heed. I'd probably be good to have a common tool somewhere, to not reinvent the wheel for every package. -- ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130526155606.gb2...@angband.pl
Re: optimizing PNGs
I think it's worth approaching upstream and recompressing the images in upstream. Ondřej Surý On 26. 5. 2013, at 17:56, Adam Borowski wrote: > Hi folks! > > A while ago, someone raised the possibility of recompressing PNG files. > Unlike xz, this would save space not only on mirrors but also on live > installed systems. PNGs are nearly incompressible so this is mostly > independent from xz. > > At least by number, there's a lot of PNG images: > > zgrep -i '\.png ' Contents-*gz|wc -l > 577815 > zcat Contents-*gz|wc -l > 4296965 (including 3*35 lines of header) > > This massive number of files seems to be concentrated mostly in a limited > number of packages: > > 35276 widelands-data > 28827 libjs-mathjax > 5 ns3-doc > 19968 jsmath-fonts > 13395 openclipart2-png > 13296 freefoam-dev-doc > 10271 w3-recs > 9877 uqm-content > 9643 wesnoth-1.11-data > 9015 wesnoth-1.10-data > 8120 openclipart-png > 6773 oxygen-icon-theme > 6546 lxde-icon-theme > 6272 mixxx-data > 5890 gnome-icon-theme > 5068 triplea > 4641 tuxfootball > 4505 gnome-themes-extras > 4180 gnome-colors-common > 3780 lilypond-doc > > Some time ago, I tested a number of png optimizers, and the best results, by > far, come from using "optipng -o4 -i0 -fix" then "advpng -z4". The former > attacks the payload well, then advpng (package advancecomp) has good deflate. > -o4 is there because higher optipng levels mess only with zlib arguments, > -i0 because advpng is afraid of interlaced files (why?), -fix because advpng > refuses to touch files with certain errors like cruft after the end, as > Adobe tools like to leave. > > I did test the alternatives quite thoroughly, but the corpus I needed that > for was quite specific. It's possible some other set of tools might be > better in general; these settings are the highest for optipng+advpng that > make sense, though. > > > So here are the results: > > size(MB) oo+a > widelands-data 105 95.1% 93.4% > libjs-mathjax 29 99.0% 98.5% > openclipart2-png 476 99.6% 99.4% > w3-recs 16 88.4% 84.2% > wesnoth-1.11-data 89 98.3% 98.1% > fonts-mathjax-extra 4 94.6% 90.0% > (sizes include .png images only, o is optipng, o+a optipng+advpng) > > Nothing stunning, I'm not sure if savings of this kind are worth a lot of > heed. I'd probably be good to have a common tool somewhere, to not reinvent > the wheel for every package. > > -- > ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ > > > -- > To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: http://lists.debian.org/20130526155606.gb2...@angband.pl > -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/04a89d77-8284-49c3-9c82-0ec2afbba...@sury.org
Re: optimizing PNGs
On Sun, May 26, 2013 at 5:56 PM, Adam Borowski wrote: > A while ago, someone raised the possibility of recompressing PNG files. > Unlike xz, this would save space not only on mirrors but also on live > installed systems. PNGs are nearly incompressible so this is mostly > independent from xz. > > At least by number, there's a lot of PNG images: [...] > 5 ns3-doc This one is slightly different and should be treated differently IMHO. See `Subject: Ridiculously large packages`[1] on debian-cd, which got solved using SVG output when generating doxygen documentation. See for example: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=557238 2cts [1] https://lists.debian.org/debian-cd/2009/11/msg00039.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ca+7wusxnzjkznt0pye3c39evefhapbhiikaq6sgmorykac5...@mail.gmail.com
Re: optimizing PNGs
On Mon, May 27, 2013 at 1:42 AM, Mathieu Malaterre wrote: > On Sun, May 26, 2013 at 5:56 PM, Adam Borowski wrote: >> A while ago, someone raised the possibility of recompressing PNG files. >> Unlike xz, this would save space not only on mirrors but also on live >> installed systems. PNGs are nearly incompressible so this is mostly >> independent from xz. >> >> At least by number, there's a lot of PNG images: > [...] >> 5 ns3-doc > > This one is slightly different and should be treated differently IMHO. > See `Subject: Ridiculously large packages`[1] on debian-cd, which got > solved using SVG output when generating doxygen documentation. See for > example: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=557238 > > 2cts > [1] https://lists.debian.org/debian-cd/2009/11/msg00039.html > Can you give a more detailed pointer to `got solved using SVG output when generating doxygen documentation`? ns3-doc currently runs optipng against all generated PNG files during the arch:all package generation, which costs quite some time to finish even on a quite fast server but reduces the size for about 300MiB. -- Regards, Aron Xu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAMr=8w5aH9E2RTPMTL=rxce1fjk9fbxo6krjugjzy6gpadb...@mail.gmail.com
Re: X.509 and CA certificates for other purposes (i.e. the IGTF)
On Sat, May 25, 2013 at 2:27 PM, Charles Plessy wrote: > Le Fri, May 24, 2013 at 12:32:29PM +0200, Dennis van Dok a écrit : >> >> I've seen the Debconf '12 discussion on X.509 certificate stores[1] >> and the Wiki page that came out of that discussion[2]. >> >> 1. >> http://www.irill.org/videos/debconf-12/895_X.509_Cert_Store_Discussion.mp4 >> 2. http://wiki.debian.org/X.509 >> >> As far as I'm aware there aren't many mentions of [2] in the public >> mailing lists, but I'm very interested to discuss where this is going. >> >> My main interest is the use case for certificates from the science >> grid community. The IGTF[3] has a distribution of accredited CAs that >> are used world-wide to authenticate both services and users. These are >> typically not the kind of CAs you'd trust for on-line banking, but >> services like: >> >> - compute clusters >> - grid storage pools >> - science clouds >> - science workflow portals >> - etc. > > Hi Dennis and everybody, > > somewhat related to this, I would like to know if there is a package that > could > host Amazon's EC2 public certificate ? In Ubuntu it is added to the euca2ools > package, because a program of this package can use it, but it is not part of > the upstream source (which is not Amazon), so I really would prefer to ship > the certificate somewhere else. > > I proposed ca-certificates earlier, but the result was inconclusive. > > http://bugs.debian.org/573857 > > Would there be a volunteer to maintain new package from scratch if needed ? Maybe crypto consolidation arround libnss will greatly help here. jessie release goal ? > Cheers, > > -- > Charles Plessy > Tsurumi, Kanagawa, Japan > > > -- > To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: http://lists.debian.org/20130525122708.ga29...@falafel.plessy.net > -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cae2spazav0px6csdyp1czxhes0qjzbm+mebgztafh6+vc9b...@mail.gmail.com
Re: optimizing PNGs
On Sun, May 26, 2013 at 07:42:49PM +0200, Mathieu Malaterre wrote: > On Sun, May 26, 2013 at 5:56 PM, Adam Borowski wrote: > > A while ago, someone raised the possibility of recompressing PNG files. > > Unlike xz, this would save space not only on mirrors but also on live > > installed systems. PNGs are nearly incompressible so this is mostly > > independent from xz. > > > > At least by number, there's a lot of PNG images: > [...] > > 5 ns3-doc > > This one is slightly different and should be treated differently IMHO. > See `Subject: Ridiculously large packages`[1] on debian-cd, which got > solved using SVG output when generating doxygen documentation. Formats other than PNG might be more appropriate, yes. > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=557238 This one (vtk-doc) doesn't compress PNGs, but reduces their quality in a lossy way to 256 colours. And in this case, using optipng+advpng would reduce the files by more than a half (comparing sizes of .tar.xz). -- ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130526182021.gc2...@angband.pl
Bug#709924: ITP: node-active-x-obfuscator -- Safely obfuscate the string 'ActiveX' inside of JavaScript code
Package: wnpp Severity: wishlist Owner: Mike Gabriel * Package name: node-active-x-obfuscator Version : 0.0.1 Upstream Author : Felix Geisendörfer * URL : https://github.com/felixge/node-active-x-obfuscator * License : Expat Programming Lang: Javascript Description : Safely obfuscate the string 'ActiveX' inside of JavaScript code This Node.js module (safely) obfuscates all occurrences of the string 'ActiveX' inside any JavaScript code. . Some corporate firewalls/proxies such as Blue Coat block JavaScript files to be downloaded if they contain the word 'ActiveX'. That of course is very annoying for libraries such as socket.io that need to use ActiveXObject for supporting IE8 and older. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130526192225.19334.56948.report...@minobo.das-netzwerkteam.de
Bug#709930: ITP: zeparser.js -- Javascript library / Node.js module for parsing Javascript code
Package: wnpp Severity: wishlist Owner: Mike Gabriel * Package name: zeparser.js Version : 0.0.6 Upstream Author : Peter van der Zee (http://qfox.nl/) * URL : https://github.com/qfox/ZeParser * License : Expat Programming Lang: Javascript Description : Javascript library / Node.js module for parsing Javascript code Parse Javascript code elements with client-side Javascript (browser) / Node.js. The parser has two modes for parsing: simple and extended. . The simple mode is mainly for just parsing and returning the streams and a simple parse tree. There's not so much meta information here and this mode is mainly built for speed. . The extended mode has everything required for Zeon to do its job. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130526203549.12665.19669.report...@minobo.das-netzwerkteam.de
Re: systemd .service file conversion
On Sat, May 25, 2013 at 10:42:09PM +0800, Thomas Goirand wrote: > On 05/23/2013 03:14 PM, Helmut Grohne wrote: > > I partly disagree here. A good reason to reimplement part of systemd is > > to have a portable subset of its functionality. This could be part of > > the answer to the question of what to do about kfreebsd. > > If I'm not mistaking, the design you are describing is called OpenRC! :) If that is the way to go, so be it. Just be aware that OpenRC adds yet another incompatible interface to init systems. I find it depressing to see four init/rc systems, of which three are mutually incompatible in every single possible aspect. Dependency annotation: * sysv: LSB headers * openrc: a shell function * systemd: ini-file / not needed due to socket activation * upstart: another syntax Socket activation: * sysv: inetd can pass one accepting socket as stdin * openrc: no clue * systemd: sockets passed as fd 3 and higher + environment variables LISTEN_FDS and LISTEN_PID * upstart: socket passed as fd specified in environment variable UPSTART_FDS Daemon startup signalling: * sysv: shell script flexibility^Whell * openrc: no clue, guess like sysv * systemd: signalling via dbus, systemd-specific notification mechanism or just assume it to be ready * upstart: tracking via ptrace, tell number of expected forks ahead Resource limits: * sysv: shell has ulimit * openrc: I guess like sysv * systemd: declarative, ini-file * upstart: declarative syntax How is anyone supposed to write a service that runs with all of them? Disabling service: * sysv: /etc/default/$service is frowned upon, update-rc.d $service disable (or chkconfig if you are on redhat) * openrc: rc-update something * systemd: "three levels of off", systemctl disable $service.service, but this gets more complex with lsb init script compatibility * upstart: echo manual > /etc/init/$service.override Some remote resemblance of uniformity in interface might help as well. Some of these differences are rooted in technical differences (especially the signalling). It would still help a lot if interfaces were less of a surface for differentiation than implementation. Given the above I do not believe supporting even two of the above in a native way (i.e. without lsb compatibility) is possible for a distribution like Debian. Is there any chance in pushing upstreams to consolidate interfaces in any way to make this easier? Helmut -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130526202925.ga1...@alf.mars
Re: optimizing PNGs
On 26-05-13 17:56, Adam Borowski wrote: > -i0 because advpng is afraid of interlaced files (why?), Interlaced files were a good idea in the 56k modem days, because they would allow images to be shown at a coarser resolution first, and then at a less coarse resolution as more of the file gets loaded. However, because the frame is essentially split in two (or more?) subframes that are compressed independently one after the other, compression results for interlaced files are typically somewhat worse off. With the advantage not being relevant anymore in this day and age, they have gone the way of the dinosaur (and good riddance). -- This end should point toward the ground if you want to go to space. If it starts pointing toward space you are having a bad problem and you will not go to space today. -- http://xkcd.com/1133/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51a28873.5040...@debian.org
Re: using upstart in Debian
On 26-05-13 15:11, Holger Levsen wrote:
> Hi,
>
> On Samstag, 25. Mai 2013, Nikolaus Rath wrote:
>> For example: after some intense studying, I now fully understand why
>> declaring a new upstart job C that depends on existing jobs A and B
>> ("start on job-a-did-its-thing AND job-b-did-its-thing") may prevent the
>> start of job A (cf
>> https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/964207). However, I
>> still consider it confusing and at least questionable design that adding a
>> new job can prevent an existing job from starting even though they do not
>> conflict in any way.
>
> WHAT?!? if that's true then I for sure know what I won't let near my systems!
> That's rather horrible. Thanks for the info!
Reading the bug, what Nikolaus fails to mention is that the way the
event handling happens, this really becomes a _circular_ dependency
unless the --no-wait option is specified (IIUC)
--
This end should point toward the ground if you want to go to space.
If it starts pointing toward space you are having a bad problem and you
will not go to space today.
-- http://xkcd.com/1133/
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51a28946.9090...@debian.org
Bug#709940: ITP: node-async-stacktrace -- Improve Node.js stacktraces and make it easier to handle errors
Package: wnpp Severity: wishlist Owner: Mike Gabriel * Package name: node-async-stacktrace Version : 0.0.2 Upstream Author : Peter 'Pita' Martischka * URL : https://github.com/Pita/async-stacktrace * License : Apache-2.0 Programming Lang: Javascript Description : Improve Node.js stacktraces and make it easier to handle errors The "Async Stacktrace" module eases debugging of Node.js applications. With the default stacktraces, the problem is that they do not tell you exactly where a problematic subroutine has been called from. . The "Async Stacktrace" module shows you where an error was caught and passed to the next callback. This allows you to see from where problematic code was called. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130526222845.26396.16017.report...@minobo.das-netzwerkteam.de
Re: systemd .service file conversion
On Sun, May 26, 2013 at 10:29:25PM +0200, Helmut Grohne wrote: > I find it depressing to see four init/rc systems, of which three are > mutually incompatible in every single possible aspect. At the risk of adding another level of indirection, we could add a meta-init format that can generate an appropriate file for any of these. > Dependency annotation: > * sysv: LSB headers > * openrc: a shell function > * systemd: ini-file / not needed due to socket activation > * upstart: another syntax This should be fairly easy to generate from a meta-init format. > Socket activation: > * sysv: inetd can pass one accepting socket as stdin > * openrc: no clue > * systemd: sockets passed as fd 3 and higher + environment variables >LISTEN_FDS and LISTEN_PID > * upstart: socket passed as fd specified in environment variable >UPSTART_FDS If the services support socket activation, a sysvinit script could probably pass the FDs using an environment variable and some shell redirection. Alternately a small C wrapper could be used, or this could be pushed into start-stop-daemon. > Daemon startup signalling: > * sysv: shell script flexibility^Whell > * openrc: no clue, guess like sysv > * systemd: signalling via dbus, systemd-specific notification mechanism >or just assume it to be ready > * upstart: tracking via ptrace, tell number of expected forks ahead This would be harder to abstract. > Resource limits: > * sysv: shell has ulimit > * openrc: I guess like sysv > * systemd: declarative, ini-file > * upstart: declarative syntax We can generate ulimit commands for sysv and openrc and appropriate entries in the systemd and upstart files. > How is anyone supposed to write a service that runs with all of them? > > Disabling service: > * sysv: /etc/default/$service is frowned upon, update-rc.d $service >disable (or chkconfig if you are on redhat) > * openrc: rc-update something > * systemd: "three levels of off", systemctl disable $service.service, >but this gets more complex with lsb init script compatibility > * upstart: echo manual > /etc/init/$service.override We already have update-rc.d, so we can make it DTRT depending on the actual init system in use. > Given the above I do not believe supporting even two of the above in a > native way (i.e. without lsb compatibility) is possible for a > distribution like Debian. Is there any chance in pushing upstreams to > consolidate interfaces in any way to make this easier? A meta-init format would make everyone equally happy (or miserable, depending on your point of view), which may be the best way to solve the problem. I fear that consolidation of interfaces is unlikely to occur. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Bug#709948: ITP: node-graceful-fs -- Graceful drop-in replacement for Node.js's default fs module
Package: wnpp Severity: wishlist Owner: Mike Gabriel * Package name: node-graceful-fs Version : 1.2.1 Upstream Author : Isaac Z. Schlueter * URL : https://github.com/isaacs/node-graceful-fs * License : Expat Programming Lang: Javascript Description : Graceful drop-in replacement for Node.js's default fs module This Node.js module works as a drop-in replacement for the fs module, bringing various improvements. . The improvements are meant to normalize behavior across different platforms and environments, and to make filesystem access more resilient to errors. . The Improvements over default fs module are: . - Keep track of how many file descriptors are open, and by default limit them to 1024. Any further requests to open a file are put into a queue until new slots become available. If 1024 turns out to be too much, it decreases the limit further. - Fix lchmod for Node.js versions prior to 0.6.2. - Implement fs.lutimes if possible. Otherwise it becomes a noop. - Ignore EINVAL and EPERM errors in chown, fchown or lchown if the user isn't root. - Make lchmod and lchown become noops, if not available. - Retry reading a file if read results in EAGAIN error. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130526230214.10730.44996.report...@minobo.das-netzwerkteam.de
Proposed mass bug filing: Removal of automake1.4, automake1.9, automake1.10 and automake1.11
Hello folks, We've accumulated a lot of automake packages in main and since we're at the very beginning of the jessie release cycle I'd like to propose a mass bug filing to remove all the current automake packages in unstable (automake1.13 is in the NEW queue). Automake 1.4 in particular is very old at this point and is unsupported. Automake is moving to a more rational versioning scheme so new, non-backwards compatible automake packages should be far less common now. See "New versioning scheme for Automake." here: http://gnu-automake.7480.n7.nabble.com/GNU-Automake-1-13-2-released-td20448.html. So hopefully we can release jessie with one (or maybe two) automake package. Attached are the package list generated from the command below (and that list run through dd-list): grep-dctrl -n -s Package \( -F Build-Depends,Build-Depends-Indep -w 'automake1.4|automake1.9|automake1.10|automake1.11' \) --and \( --not -F Build-Depends,Build-Depends-Indep -w 'automake' \) /var/lib/apt/lists/ftp.us.debian.org_debian_dists_unstable_main_source_Sources -- Eric Dorland ICQ: #61138586, Jabber: ho...@jabber.com agg am-utils amule-emc anon-proxy audit aumix autoproject avr-libc baycomusb black-box boinc boinc-app-seti cairo-ocaml ccd2iso cciss-vol-status cddlib cegui-mk2 centerim clang compiz compiz-fusion-bcop compiz-fusion-plugins-extra compiz-fusion-plugins-main compiz-fusion-plugins-unsupported compizconfig-backend-gconf compizconfig-python console-data cpqarrayd cstream curl cwiid dapl diagnostics easypg ecl enigma enna enscript ethtool fam fenix-plugins ffrenzy freefem3d freesci freetalk freqtweak g15daemon g15mpd garden-of-coloured-lights gcc-3.3 gcc-4.4 gcc-avr gcc-h8300-hms gdc-4.4 gesftpserver gettext-lint gmerlin gmerlin-avdecoder gnat-4.4 gnuift google-perftools gpsdrive grub gsmc guile-gnome-platform gwaterfall gwhere hercules hfsplus hodie httrack hunspell ical2html icecast2 ices2 ijs iml iulib jack-audio-connection-kit jack-tools jamin jbig2dec kannel-sqlbox katoob lam libavg libcompizconfig libcsoap libg15render libgadu libgpelaunch libgpeschedule libgpevtype libibcm libiodbc2 liblrdf libm4ri libmodplug libnfsidmap libnss-ldap libpam-ccreds libshout libsieve libsigc++-2.0 libtododb liece linbox linphone llvm-2.9 llvm-3.0 llvm-3.2 llvm-toolchain-3.2 ltris lustre madplay mailsync maxima ming mousetrap mp4h multiget muttprint necpp net-snmp netdiscover nufw nullmailer nyquist ocropus openbox openhpi openmpi openocd par2cmdline pd-iemmatrix poker-engine qonk qwo read-edid refdb riece rtpproxy sawfish scli shadow siege simplelist sipwitch source-highlight sparsehash subtitleeditor syrep t-code tcpstat tidy torcs ucommon uim unicap urlview util-vserver viking webdruid whitedune wmforkplop wmxmms2 xosd xpilot-ng zabbix Adrian Knoth jack-audio-connection-kit (U) liblrdf (U) Alastair McKinstry console-data Alessandro Ghedini curl Alessio Treglia gmerlin (U) gmerlin-avdecoder (U) Andrea Veri agg Andreas Putzo gpsdrive (U) Andreas Rottmann guile-gnome-platform Anibal Avelar centerim mousetrap Anibal Monsalve Salazar ethtool libnfsidmap Anton Zinoviev console-data (U) Arnout Engelen jack-tools (U) Arthur Loiret clang (U) gcc-4.4 (U) gdc-4.4 (U) llvm-2.9 (U) llvm-3.0 (U) Asheesh Laroia ccd2iso Athena Capital Research sparsehash Aurélien GÉRÔME hfsplus Axel Beckert mp4h (U) Barry deFreese fenix-plugins (U) qonk (U) Bart Martens gwhere par2cmdline Bas Zoetekouw freesci Ben Armstrong xpilot-ng Ben Hutchings ethtool (U) Benoit Mortier dapl (U) libibcm (U) Bernd Zeimetz viking Bhavani Shankar freqtweak Bryan Sutula openhpi Camm Maguire lam maxima Chris Halls hunspell (U) Christian Hofstaedtler cciss-vol-status Christian Perrier console-data (U) shadow (U) Christian T. Steigies hodie Christoph Egger ecl (U) Christoph Haas zabbix Christophe Prud'homme freefem3d (U) Chuan-kai Lin fam Clément Stenac madplay (U) Colin Tuckley ltris Colin Watson grub (U) Cyril Brulebois compiz (U) Daigo Moriwaki google-perftools Daniel Burrows libsigc++-2.0 Daniel Hahler boinc (U) David Nusinow compiz (U) David Spreen anon-proxy Davide Cavalca enna Debian BOINC Maintainers boinc boinc-app-seti Debian Common Lisp Team ecl Debian Games Team fenix-plugins garden-of-coloured-lights qonk Debian GCC Maintainers gcc-4.4 gdc-4.4 gnat-4.4 Debian GIS Project gpsdrive Debian GPE team libgpelaunch (U) libgpeschedule (U) libgpevtype (U) libtododb (U) Debian Hamradio Maintainers baycomusb gsmc Debian LibreOffice Maintainers hunspell Debian Lustre Packaging team lustre Debian Multimedia Maintainers gmerlin gmerlin-avdecoder icecast2 ices2 jack-audio-connection-kit jack-tools jamin liblrdf libshout p
Re: "Blacklists" in BTS (stopping the trolls and bug machines)
On Sat, May 25, 2013 at 7:10 PM, Michael Gilbert wrote: > > Yes, I think we can do without his bug reports. > > I think it would be wrong to discriminate against particular bug > reporters. I've found it often helpful to make specific suggestions > about the bug reports that I've received that aren't of sufficient > quality. Sure, that takes some time, but it also reduces repeat poor > submissions because eventually those specific suggestions improve the > quality of those reporters over time. That probably sounds naive and > too kind, but in my opinion, it's just the right thing to do. You are free to receive whatever garbage bug reports in your package. However my time is too valuable to deal with people who don't listen and just repeat their opinion endlessly (yes, speaking about Filipus here). That's why I have asked for per-package blacklist. O. -- Ondřej Surý
Re: systemd .service file conversion
On Sun, May 26, 2013 at 10:27:53PM +, brian m. carlson wrote: > At the risk of adding another level of indirection, we could add a > meta-init format that can generate an appropriate file for any of these. Are you aware of http://wiki.debian.org/MetaInit (packages metainit and dh-metainit)? That work was started like eight years ago. Unfortunately it didn't take off yet. The only package using it is infon. [snipping constructive options for each issue] > A meta-init format would make everyone equally happy (or miserable, > depending on your point of view), which may be the best way to solve the > problem. I fear that consolidation of interfaces is unlikely to occur. As far as I can tell Debian simply lacks the resources to do that. Maybe Joachim Breitner can shed some light on this? Unless some consolidation of interfaces is going to happen, Debian will simply be unable to support multiple init systems natively. Helmut -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130527063844.ga11...@alf.mars
