Bug#712219: ITP: libjs-forge -- a native implementation of TLS in JavaScript
Package: wnpp Severity: wishlist Owner: Dominik George -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 ** Prerequisite for geierlein, ITP #695204 ** * Package name: libjs-forge Version : Upstream Author : Digital Bazaar, Inc. * URL : https://github.com/digitalbazaar/forge * License : GPL or BSD Programming Lang: JavaScript Description : a native implementation of TLS in JavaScript The Forge software is a fully native implementation of the TLS protocol in JavaScript as well as a set of tools for developing Web Apps that utilize many network resources. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQJOBAEBCAA4BQJRusTSMRpodHRwczovL3d3dy5kb21pbmlrLWdlb3JnZS5kZS9n cGctcG9saWN5LnR4dC5hc2MACgkQt5o8FqDE8pZPlA/+OfRqhDCFA7a0kWUldgDy iobdrYUqMGnmCTtmcQXJLR9NaZlDbqdgFGOILbpvGnw4c+xFGq+dUc9hSgSABudG gETIDUcbpjB97eDFIrzuX9TsIxgSVDqhB0FlWqy749f3ur3nsWLWPVbMK0vechze HTuKRGEoL42Vp7wN1Zv5yH23nOIrXD2vm6No1845//FEI9PEvw+3bIa6E3iy6zGn a4qVDSwoavJP+Gv7KzjYUOA5D9NOZMdJXCFw7vBA+x2841xbcnaNKuw8zsrSQO6+ vpYhE0fp/AuJiuynimcaPcHsWPdfxlCDovkLls7BQ2NoB40+thZlooJ7f1WZBGQy kAWfd3Bd4sfDHRtaTbNtAMuTkNktu7qfsKRSnSzCOw1NazGMVB9LNjVo4QYqtbwH aUZ7kwadCQfv4lAa/pDmsUK89YMTDJ5xuxBSja0XNzzwrwzRm3XLNdAGp6pIK0xS TNvcqcb3T/7ncwGYzFB9SpWAcgEWUC9jGO55dK44gjGmX5xWCAQO9o9wo4wvvfza s3Uwj4wkUyy8DRq/uT7hF6g4F2bnNzl71p5XmPeFM6qPzD0K+HXt7zT1TJuZ0VNZ OYDLJJ+rOJm9UqcsPbKMzFtlUqfHPuaOU2EkhXkgLnRZXJJiQO7AFkNcq7hb+cw3 fuSdHCkwUnkunouSZJh0Rp4= =z7ey -END PGP SIGNATURE- -- 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/20130614072302.18464.58286.report...@keks.lan.naturalnet.de
Bug#712215: ITP: libjs-gzip -- a pure JavaScript implementation of the GZIP file format
Package: wnpp Severity: wishlist Owner: Dominik George -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 ** Prerequisite for geierlein, ITP #695204 ** * Package name: libjs-gzip Version : 0.3.1 Upstream Author : T. Jameson Little * URL : htts://github.com/beatgammit/gzip-js * License : MIT Programming Lang: JavaScript Description : a pure JavaScript implementation of the GZIP file format gzip-js is a pure JavaScript implementation of the GZIP file format. It uses the DEFLATE algorithm for compressing data. Please note that since this is a pure JavaScript implementation, it should NOT be used on the server for production code. It also does not comply 100% with the standard, yet. The main goal of this project is to bring GZIP compression to the browser. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQJOBAEBCAA4BQJRusa/MRpodHRwczovL3d3dy5kb21pbmlrLWdlb3JnZS5kZS9n cGctcG9saWN5LnR4dC5hc2MACgkQt5o8FqDE8pYuYw//R+i/turNPYPl2ULmawsl GZuU3EGMZ5UQk6zdsUqnpaBqXSO/ZtcoqcaZzysrjEu5oAwa0cml+bW8IeKroLHg 7bCdl1AhYlz3Sr14ce+VFmt0OG5Y06b/DAjEKH0G3MFwfPWupdk5VeeiAyEpQ3+L wTvsCVZVQ2TRwQ7OYlLLAV5C1zqpU+ShxLZA+qDuzWaQVoHgDcxjTG+0+Yi8gdKP Y1KVf9NbEisrKIEVG7wQ7amamWyxxdk8efJwE/oRW1EiUuuDf6LQcJt74sLXAnVu o5KlrwbqT35x57N/qXrgSuiwOy9RcrzcDUA3RZJ980qZRsa7svmVuVW4b0wdyylx 529O5YaXDdizUF+t5CO0Qz5O3oUjCq1yVaKuez7TUg6MiyUDEE0yU83wgDlJlUQi Ycjcia0qQ9UNHw7BaIBn6dYBpzNGGBCv32lbu2NMIXnXRskfv7L8JUQzLbC/aynT NDPNbcrGEoxD0Lvk6Kq6Bpi28sK+mtHAse7oMdbXYm0r6vgMlyuJ8WK+0myJAvpw BlsvjCpIwQVougu8ISUikK6oUsIcRTAmPvjT104iUqataoJtt8ZEx0hMhRp1pX2i fsJKMZMxyEGS6O5U/EGwcElGfJKViH/xugkYgtrpfmkXPqiqye+NP2kMjuS0348y gEtMVla66EbYUmEiafHJiLo= =Xjky -END PGP SIGNATURE- -- 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/20130614073111.19180.89391.report...@keks.lan.naturalnet.de
Bug#712220: ITP: libjs-jsxml -- XML/XSLT to DOM parser in JavaScript
Package: wnpp Severity: wishlist Owner: Dominik George -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 ** Prerequisite for geierlein, ITP #695204 ** * Package name: libjs-jsxml Version : Upstream Author : Anton Zorko * URL : http://jsxml.net * License : BSD Programming Lang: JavaScript Description : XML/XSLT to DOM parser in JavaScript -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQJOBAEBCAA4BQJRusunMRpodHRwczovL3d3dy5kb21pbmlrLWdlb3JnZS5kZS9n cGctcG9saWN5LnR4dC5hc2MACgkQt5o8FqDE8pYAyRAAtaMhz0ghbyEUKWgdNkDn RRr2Zp6ZyzDhHVdb2gRIAPwK/VULIQ9P0C9AbJuwDr6tuPTMFmecIvfMQQjLbedj vxNf4xHMHYleZkgwo/QfV/kOnRBrg9Lc/nEud9cnU+fttYC56bz9voEbqlRCNMQ2 H+sOlhx5z4KAEIpmeGGOVKtPNvyWM3V/lugON9qw+4u0uAK7C4smUg7G4LuKEjHw m3z29g2cktPgxLOLn6gWjeHIqDw/OOgCgik1wF2ITs39mIwFhffmkfl371yKss9q 2vju2nc5B2SejBPJYyFCnnW3tcg4WzZm8DmATa7w5DgSco89U/7f5gVuw9MKEdup vW1kRletWtmM3AA5+yfXriFhIknQDOZFW7C6QAWnUtpPp4iyJvKrWmZYJGRDWvg/ /TxGGnRbUtYa+1uVFEeKi8W5Vgh3b+Rh/VKHGjzKUFyYJY1YPyWCkNkHB9wTZ8Vo 8spAXlswNafqRVS6GV6xC3+wJ5a74GWQx+fJas9sQh6onEwODtiLyUZ7mjuaUWa9 Q4BZeriw85PZy3ND5K0xrY3pd2geP1wQcgBh4ThxV25tQqhsRqyQjq6/82BClHgK y4TXCJLrwsJGQKSEOM8Mygb1JDypO7C8xuV7NvQ7+t6Z01paVDmIasKATNSm0vJk U8/fclVWrVgBWurdLa3WLhE= =5Jbo -END PGP SIGNATURE- -- 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/20130614075207.20383.20727.report...@keks.lan.naturalnet.de
Bug#712233: ITP: adcli -- Tool for performing actions on an Active Directory domain
Package: wnpp Severity: wishlist Owner: Laurent Bigonville * Package name: adcli Version : 0.7.1 Upstream Author : Stef Walter * URL : http://www.freedesktop.org/software/realmd/adcli/ * License : LGPL Programming Lang: C Description : Tool for performing actions on an Active Directory domain A helper library and tools for Active Directory client operations. -- 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/20130614094127.9720.30328.report...@soldur.bigon.be
Aw: KickStarter for Debian packages - crowdfunding/donations for development
I am less critical about it - it just should remain outside Debian. We would gain a deb-store, I presume. The ties should be more with the respective program's developers than with us the Debian community. After all, the money would flow because of the functionality, not because of the availability for the disitribution. Any particular support from the Debian community would be nice, but if the concept works, then this would not be required. Cheers, Steffen -- 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/trinity-c368a183-4a11-4e9f-99cb-47bfa8f8e923-1371207111589@3capp-gmx-bs28
Re: Current and upcoming toolchain changes for jessie
Am 13.06.2013 21:47, schrieb Thorsten Glaser: > Matthias Klose dixit: > >> The Java and D frontends now default to 4.8 on all architectures, the Go >> frontend stays at 4.7 until 4.8 get the complete Go 1.1 support. > > I’d like to have gcj at 4.6 in gcc-defaults for m68k please, > until the 4.8 one stops FTBFSing. please send a patch. > From me nothing against switching C/C++ to 4.8 for m68k at > this point, but I’d like to hear at least Wouter’s opinion > on that, and possibly Mikael since he’s not just doing work > upstream on gcc but also using it (for ColdFire) heavily. same as well, please send a patch. > For Ada, I’d like to see a successful build of gnat-4.8 > (from src:gcc-4.8, if I understand the recent changes right) > first; gnat-4.6 mostly works at the moment, but I’m not sure > about the upstream situation wrt. patches from Mikael. try it and send a patch please. thanks for your cooperation, Matthias -- 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/51baf88c.3080...@debian.org
Re: Current and upcoming toolchain changes for jessie
Am 13.06.2013 16:46, schrieb Steven Chamberlain: > Hi, > > On 13/06/13 13:51, Matthias Klose wrote: >> GCC 4.8 is now the default on all x86 architectures, and on all ARM >> architectures (the latter confirmed by the Debian ARM porters). I did not >> get >> any feedback from other port maintainers, so unless this does change and port >> maintainers get involved with toolchain maintenance, the architectures >> staying >> at 4.6 or 4.7 shouldn't be considered for a successful release >> (re-)qualification. > > I trust these are the architectures that are okay so far: > | gcc48_archs = amd64 armel armhf arm64 i386 x32 kfreebsd-amd64 > kfreebsd-i386 hurd-i386 no, they are probably not ok, and there surely are yet undiscovered regressions, but at least the ARM porters did agree to address these. Same seems to be true for the kfreebsd and hurd porters. They did change GCC defaults usually at the same time as this was done for the x86 linux archs. > So the following would be the architectures for which some response is > requested urgently from port maintainers, to confirm they are ready for > GCC 4.8 as default: > > Release arches: ia64 mips mipsel powerpc s390 s390x sparc > > All the above have built gcc-4.8.1-2 or higher. and nobody committing to scan the bts for architecture specific issues, nobody to prepare test cases, nobody to forward these. > Other ports: alpha hppa* m68k powerpcspe ppc64 sh4* sparc64* > > * these ports don't appear to have successfully built GCC 4.8 yet. afaics, alpha, powerpcspe and ppc64 did build. Note that you cannot trust the hppa status, this port is still denied access to ports.debian.org and is kept in another place. So yes, some of these ports are in better shape than the ports released with wheezy. Matthias -- 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/51bafa9e.5080...@debian.org
jessie release goal: verbose build logs
Much more often than I do like it, I see bug reports for the toolchain just pointing to a build log. Then looking at the build log, you often just see CC ... CCLD ... (sometimes even colorized) This doesn't really help when trying to diagnose things, and even for successful builds it's valuable to have the complete build log, including the parts how the upstream build system is called from the Debian packaging. Verbose build logs allow to analyse package builds and give hints to more issues regarding the build, especially for the hardening flags. The lintian hardening checks are incomplete, because they rely on the inspection of the generated binaries, which may be incomplete especially for many plugins or dynamically loadable extensions. So I'm proposing for jessie: - File and track issues for packages not enabling verbose builds. https://buildd.debian.org/~brlink/bytag/W-compiler-flags-hidden.html - Fix debhelper not passing --disable-silent-rules by default. #680686 I think cdbs already does this. - Fix debhelper to show how the upstream build system is called. #680687 As an alternative buildds could run with DEB_BUILD_OPTIONS=verbose - Change Debian policy to recommend or require verbose build logs. #628515 This is not rocket science, but allows for almost free additional QA. Size of the build logs shouldn't be an issue, but if it is, I'm considering to disable compiler warning and errors messages by default, unless DEB_BUILD_OPTIONS=verbose is set. Matthias -- 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/51bb0006.4080...@debian.org
Re: jessie release goal: verbose build logs
+++ Matthias Klose [2013-06-14 13:35 +0200]: > Much more often than I do like it, I see bug reports for the toolchain just > pointing to a build log. Then looking at the build log, you often just see > > CC ... > CCLD ... (sometimes even colorized) > > This doesn't really help when trying to diagnose things, and even for > successful > builds it's valuable to have the complete build log, including the parts how > the > upstream build system is called from the Debian packaging. > So I'm proposing for jessie: > > - File and track issues for packages not enabling verbose builds. >https://buildd.debian.org/~brlink/bytag/W-compiler-flags-hidden.html > > - Fix debhelper not passing --disable-silent-rules by default. >#680686 >I think cdbs already does this. > > - Fix debhelper to show how the upstream build system is called. >#680687 >As an alternative buildds could run with DEB_BUILD_OPTIONS=verbose > > - Change Debian policy to recommend or require verbose build logs. >#628515 I'll second this. Like Doko, I've spent way too much time recently(ish) staring at build-logs. The short-form build logs are often useless for working out why something isn't working, or comparing successful native builds with failed cross builds, for example. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- 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/20130614114927.gx14...@stoneboat.aleph1.co.uk
Re: jessie release goal: verbose build logs
Hi, On 14/06/13 13:35, Matthias Klose wrote: > Much more often than I do like it, I see bug reports for the toolchain just > pointing to a build log. Then looking at the build log, you often just see > > CC ... > CCLD ... (sometimes even colorized) > > This doesn't really help when trying to diagnose things, and even for > successful > builds it's valuable to have the complete build log, including the parts how > the > upstream build system is called from the Debian packaging. > > Verbose build logs allow to analyse package builds and give hints to more > issues > regarding the build, especially for the hardening flags. The lintian > hardening > checks are incomplete, because they rely on the inspection of the generated > binaries, which may be incomplete especially for many plugins or dynamically > loadable extensions. > > So I'm proposing for jessie: > > - File and track issues for packages not enabling verbose builds. >https://buildd.debian.org/~brlink/bytag/W-compiler-flags-hidden.html > > - Fix debhelper not passing --disable-silent-rules by default. >#680686 >I think cdbs already does this. It has done so since version 0.4.62 from 2009. > - Fix debhelper to show how the upstream build system is called. >#680687 >As an alternative buildds could run with DEB_BUILD_OPTIONS=verbose > > - Change Debian policy to recommend or require verbose build logs. >#628515 Completely agreed on everything. I thought this was already a requirement. > This is not rocket science, but allows for almost free additional QA. Size of > the build logs shouldn't be an issue, but if it is, I'm considering to disable > compiler warning and errors messages by default, unless > DEB_BUILD_OPTIONS=verbose is set. If size is an issue, xz-compression could probably help a lot. Cheers, Emilio -- 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/51bb0535.1080...@debian.org
Re: jessie release goal: verbose build logs
On 14/06/2013 13:49, Wookey wrote: > +++ Matthias Klose [2013-06-14 13:35 +0200]: >> Much more often than I do like it, I see bug reports for the toolchain just >> pointing to a build log. Then looking at the build log, you often just see >> >> CC ... >> CCLD ... (sometimes even colorized) >> [...] > I'll second this. Like Doko, I've spent way too much time recently(ish) > staring at build-logs. The short-form build logs are often useless for > working out why something isn't working, or comparing successful > native builds with failed cross builds, for example. Same as Wookey. This would save me some time working on the analysis of rebuilds with clang. Thanks Sylvestre -- 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/51bb0507.5070...@debian.org
Re: jessie release goal: verbose build logs
On 2013-06-14, Jakub Wilk wrote: > I attached a dd-list for the lazy. But note that "false positives are > possible, especially when building in parallel". I've just sample-checked 4 packages I'm involved in and 100% of those four I checked was false positives. We need a better detection. But beside that, I agree with wanting verbose build logs. /Sune -- 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/slrnkrm2nj.j8.nos...@sshway.ssh.pusling.com
Re: jessie release goal: verbose build logs
Matthias Klose writes: > This doesn't really help when trying to diagnose things, and even for > successful > builds it's valuable to have the complete build log, including the parts how > the > upstream build system is called from the Debian packaging. This is a useful goal. However, since fixing many different source packages is a lot of work I recently explored some alternative approaches. For example, with systemtap we can simply log all execve() invocations complete with timing information and end up with fully structured build logs. Here's example output from the proof of concept from a few years ago: http://lindi.iki.fi/lindi/structured-buildlogs/logs/hello-2.6-1_amd64.build Don't take me wrong, I don't intend to replace any of the existing infrastructure, I'm simply exploring new ways to (ab)use systemtap :-) -- 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/84y5aczv7c@sauna.l.org
Re: jessie release goal: verbose build logs
Hi, I completely agree on the goal and disable silent rules where I notice them, but: On Fri, Jun 14, 2013 at 01:35:34PM +0200, Matthias Klose wrote: > - Change Debian policy to recommend or require verbose build logs. >#628515 Change buildds. Do we have autosiging now for all buildds? TTBOMK one ia64 buildd maintainer doesn't want it, so buildd log size restrictions "block" bigger logs (and that will happen e.g. for LO, bddt). That's why LO does verbose on "normal" build and not-verbose on the buildds. Regards, Rene -- 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/20130614140840.ga26...@rene-engelhard.de
Re: default MTA
On 06/13/2013 04:03 AM, Jakub Wilk wrote: > * Daniel Pocock , 2013-06-12, 21:41: >> #4: Our priorities are our users and free software > > In any Debian discussion, given enough time, someone inevitably mentions > SC§4. Once this occurs, the thread is over, and the person who mentioned > it has automatically lost the argument. I agree. SC§4 is the godwin of Debian. Thomas -- 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/51bb2d50.7010...@debian.org
Re: jessie release goal: verbose build logs
Hi I agree we need good build logs. On 14-06-13 14:14, Jakub Wilk wrote: > * Matthias Klose , 2013-06-14, 13:35: >> So I'm proposing for jessie: >> >> - File and track issues for packages not enabling verbose builds. >> https://buildd.debian.org/~brlink/bytag/W-compiler-flags-hidden.html > > I attached a dd-list for the lazy. But note that "false positives are > possible, especially when building in parallel". False positives also happen for other compilers, at least for Free Pascal. AIUI, that is why I show up in that list. Paul signature.asc Description: OpenPGP digital signature
Re: Current and upcoming toolchain changes for jessie
Matthias Klose dixit: >> I’d like to have gcj at 4.6 in gcc-defaults for m68k please, >> until the 4.8 one stops FTBFSing. > >please send a patch. For gcc-defaults? I think that one is trivial… For gcj? I did not take Compiler Design in what two semesters of Uni I managed until I ran out of money. I will, however, forward #711558 to upstream. I can’t do everything, but I don’t think anyone can accuse me of not trying either… >> From me nothing against switching C/C++ to 4.8 for m68k at >> this point, but I’d like to hear at least Wouter’s opinion >> on that, and possibly Mikael since he’s not just doing work >> upstream on gcc but also using it (for ColdFire) heavily. > >same as well, please send a patch. Wouter, Mikael: input on switching C/C++ to 4.8? [ Ada ] >try it and send a patch please. Would be useful to get it compiled first, for which #711558 is currently the blocker AFAICT. But I guess I’ll try eventually. Note to myself: do not “temporarily help out” in any more Debian projects, you’ll never leave them… bye, //mirabilos, sponsoring for a week of Linuxhotel would be nice… (I’m seriously short of hacking time, in general, recently, and could use some switching of paper hangings for a while) -- Support mksh as /bin/sh and RoQA dash NOW! ‣ src:bash (259 (278) bugs: 0 RC, 182 (196) I&N, 77 (82) M&W, 0 (0) F&P) ‣ src:dash (86 (102) bugs: 3 RC, 41 (46) I&N, 42 (53) M&W, 0 F&P) ‣ src:mksh (2 bugs: 0 RC, 0 I&N, 2 M&W, 0 F&P, 1 gift) http://qa.debian.org/data/bts/graphs/d/dash.png is pretty red, innit? -- 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/pine.bsm.4.64l.1306141907290.27...@herc.mirbsd.org
Re: Aw: KickStarter for Debian packages - crowdfunding/donations for development
On 06/14/2013 06:51 AM, "Steffen Möller" wrote: > I am less critical about it - it just should remain outside Debian. I don't quite understand what you mean by "outside Debian"? > We would gain a deb-store, I presume. I also don't understand what you mean by "deb-store". > The ties should be more with the respective program's developers than > with us the Debian community. After all, the money would flow because > of the functionality, not because of the availability for the > disitribution. I agree with you about functionality, but isn't part of that functionality provided by ensuring that the software is packaged nicely, tested thoroughly, and maintained? That certainly adds value, doesn't it? > Any particular support from the Debian community would be nice, but > if the concept works, then this would not be required. I don't understand what you mean by "this". What wouldn't be required, support from the Debian community? If so, in what way? -- manu -- Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) Founder/CEO - Digital Bazaar, Inc. blog: Meritora - Web payments commercial launch http://blog.meritora.com/launch/ -- 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/51bb8454.60...@digitalbazaar.com
Re: jessie release goal: verbose build logs
* Matthias Klose [130614 13:36]: > Verbose build logs allow to analyse package builds and give hints to more > issues > regarding the build, especially for the hardening flags. The lintian > hardening > checks are incomplete, because they rely on the inspection of the generated > binaries, which may be incomplete especially for many plugins or dynamically > loadable extensions. While I agree that a build log without compiler arguments is essentially worthless, could we please not call something that is not too silent "verbose"? Verbose is something that uses more words as necessary, while compiler options are neccessary, without them users of the software cannot get help in forums or channels when they have problems compiling the software and with build logs porters can often hardly help if the old buildd log contains no information. Bernhard R. Link -- 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/20130614223601.gb3...@client.brlink.eu
Re: default MTA
On Friday, June 14, 2013 02:31:45, Marc Haber wrote: > On Thu, 13 Jun 2013 16:42:15 -0400, Chris Knadle > > wrote: > >So right now I think that I probably just didn't know that this had been > >fixed, because I haven't been using the "split file" configuration for > >along time. I clearly remember having _upgrade_ problems in 2003 with > >Exim on Debian Testing, but I might be confusing the root cause of those > >problems at that time; there are occasional required configuration > >changes, and that's another possible cause. I should explain the above a bit further; when using the "split file" configuration and choosing "N" to certain config file updates, that leaves behind several .dpkg-dist config files. If the upgrade goes badly because of required configuration changes, the first thing that catches one's eye are the .dpkg-dist files, making it _seem_ as though they could have been the root cause, even if they're not. ;-) > In 2003 the exim4 packages were in a kind of steady flux, everything > was new back than. The old exim 3 packages worked totally different. I > fully understand that exim4 2003 might have had serious and bad bugs, > but I think that most of them have been ironed out by now. Yes I ran Exim3 for a while also, so I know what you mean. With Exim4 I think it was the "in flux" part that got me at the time concerning upgrades, which was exaserbated by my running Testing on the server. > That doesn't mean that I am not going to break exim during the jessie > release cycle, but Andreas is there to fix it ;-) If that happens, it's fixable. ;-) -- Chris -- Chris Knadle chris.kna...@coredump.us GPG Key: 4096R/0x1E759A726A9FDD74 -- 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/201306142149.59458.chris.kna...@coredump.us
Re: Current and upcoming toolchain changes for jessie
GCC-4.8 should become the default on ia64 soon; some other changes are desirable: - The transition of gcc-4.8/libgcc1 to libunwind8. - A removal of the libunwind7 dependency of around 4600 packages on ia64 - when they are updated next time after the transition. The libc6.1 should (likely) depend on libunwind8 after that in order to guarantee that libunwind8 is installed. Stephan -- 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/20130615032245.horde.t7xtwhrox0q8ei0bj2c0...@webmail.df.eu
Re: default MTA
On 31/05/13 08:41, Jean-Christophe Dubacq wrote: > A utility to scan syslog and convey important information to the user > would be much more useful than configuring all mailers in Debian to read > root's local mail by default. I know how to redirect root's mail > elsewhere, thank you for not making another mail account to check. This utility already exists on Debian: is called logcheck. Unfortunately (from your point of view) it requires that the user is able to configure the mailer. So maybe instead of trying to reinvent the wheel [1] we could fix the current one, and make sure that the default configuration of the mailer ensures that local mails are read by root or by the default system user. [1] http://tr.im/44jc8 signature.asc Description: OpenPGP digital signature
Re: default MTA
On Fri, 14 Jun 2013 21:49:59 -0400, Chris Knadle wrote: >On Friday, June 14, 2013 02:31:45, Marc Haber wrote: >> On Thu, 13 Jun 2013 16:42:15 -0400, Chris Knadle >> wrote: >> >So right now I think that I probably just didn't know that this had been >> >fixed, because I haven't been using the "split file" configuration for >> >along time. I clearly remember having _upgrade_ problems in 2003 with >> >Exim on Debian Testing, but I might be confusing the root cause of those >> >problems at that time; there are occasional required configuration >> >changes, and that's another possible cause. > >I should explain the above a bit further; when using the "split file" >configuration and choosing "N" to certain config file updates, that leaves >behind several .dpkg-dist config files. And if you choose "Y", .dpkg-old config files are left. That's basic dpkg functionality, and it has always been the case that files that don't match the [-a-z0-9] rule are ignored. .dpkg-foo files have a period and get ignored. See run-parts(8) Grüße Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834 -- 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/e1unk3x-0001da...@swivel.zugschlus.de
Re: default MTA
On 30/05/13 12:15, Bjørn Mork wrote: > Ben Hutchings writes: >> On Wed, May 29, 2013 at 09:06:59PM +0200, Adam Borowski wrote: >>> On Wed, May 29, 2013 at 05:11:35PM +0200, Josselin Mouette wrote: Le mercredi 29 mai 2013 à 16:31 +0200, Javier Fernandez-Sanguino a écrit : > Take for example, smartmoontools [1]. Currently, if an end-user > installs smartmoontools and a hard-disk fails (i.e. smartd detects a > problem with one HD) he will *not* see any notification: the failure > is sent through local e-mail. He will see a notification on his desktop. Clear, understandable and translated in his configured language: https://git.gnome.org/browse/gnome-disk-utility/tree/src/notify/gdusdmonitor.c (The code is different but already here in squeeze and wheezy.) >>> >>> What you propose requires: >>> * adding desktop environment specific code to every facility that may need >>> to send notifications >>> * adding such notifications to every other desktop environment >> >> Wrong, we already have org.freedesktop.Notifications in GNOME, >> KDE and Xfce. >> >> So those two points become: >> >> * adding cross-desktop code to every facility that may need to send >> notifications >> * adding a notification daemon to task-lxde >> >> There are libraries to help with the first point, of course. > > Wouldn't a daemon watching /var/mail/root and turning any mail into > desktop notifications solve most of this, while still allowing the same > notifications to reach a sysadmin on non-desktop systems? > I really think this is the way to go: By default install some application on the debian-desktop tasksel that displays on the desktop unread mails sent to root. Installing logcheck by default also would be nice. > The issue that worries me most about these desktop notification plans is > the possibility that some package may decide to unnecessarily drop > support for non-desktop systems, adding dependencies on the desktop > notification system. I believe we already have had a few examples of > such unnecessary dependencies on services which are "nice to have", like > GNOME depending on NetworkManager for example. > This issue is easily solved by ensuring that programs sending notifications do it by mail to root@localhost and not to some fancy new dbus thing. signature.asc Description: OpenPGP digital signature
