Re: [Pkg-utopia-maintainers] Bug#699749: Incompatible change in the ifupdown hooks interface
Hello, On Wed, 06 Mar 2013 20:26:47 +0100 Michael Biebl bi...@debian.org wrote: On 6 March 2013 13:45, Michael Biebl bi...@debian.org wrote: A quick grep over all unpacked packages shipping ifupdown hooks show 60 hook scripts which don't have ADDRFAM set. I haven't checked them individually, though. They usually check for interface name to match eth* or something, Checking for hard-coded interface name sounds like a terrible idea. Especially in hindsight of tools like biosdevname or the new interface naming scheme in udev. Yes, but that's a different bug. which is supposed to work. Somehow it did happen I haven't noticed avahi-daemon to have this thing, so that's why it's not fixed. Other packages I expect to work flawlessly. When you say expect, does that mean you didn't actually check those hook scripts individually? When I say expect I mean I did actually check, but I could however miss something. I don't know why these --all calls are a useful thing for ifupdown to do, but I do think it's the responsibility of the avahi package to sensibly ignore values of $ADDRFAM that it doesn't understand. What I'm not happy about is, that such a change was made without notifiying the affected package maintainers *in advance* with clear instructions how to address this. Ideally via the BTS. Such documentation and instructions are still missing. By the way, quoting myself, “Network Manager already uses similar approach, so if anything can break, it's been broken for a long time already.” Not sure what this quote is supposed to mean and why you bring up NM in this context. NM has been feeding ifupdown hooks with such unusual values for ages. I guess what I'm missing is a section in the ifup or interfaces man page called ifupdown for package maintainters and how to integrate your service with ifupdown. With recommendations, examples, best practices, etc. As I plan a serious rewrite of the hooks system soon anyway, I think I will just write a new manual on that regard. -- WBR, Andrew signature.asc Description: PGP signature
Accepted ifupdown 0.7.40 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Mon, 04 Mar 2013 21:56:39 +0100 Source: ifupdown Binary: ifupdown Architecture: source amd64 Version: 0.7.40 Distribution: experimental Urgency: low Maintainer: Andrew Shadura bugzi...@tut.by Changed-By: Andrew Shadura bugzi...@tut.by Description: ifupdown - high level tools to configure network interfaces Closes: 694541 695906 696642 701884 Changes: ifupdown (0.7.40) experimental; urgency=low . [ Andrew Shadura ] * Don't configure bridge interfaces as tagged VLAN interfaces (Closes: #696642). * Add tryonce option to DHCP-enabled methods (Closes: #694541). * Implement inet6/auto for kFreeBSD, call DHCP release of ifdown on Linux (Closes: #701884). * Update manual pages. * Add tests for DHCP method. * Add ISC DHCP client to Build-Depends (the tests don't actually run the DHCP client, however). . [ Stéphane Graber ] * Patches for upstart support from Ubuntu: - Start the job on runlevel [2345]. This is a no-op during a normal boot since the network will be started *before* runlevel is emitted, but is needed to restart the network after a change from runlevel 1 (LP: #752481). - Don't bring 'lo' down (add it to --exclude). - Emit deconfiguring-networking (LP: #1061639). - Update network-interface-security job to stop when the parent job is stopped itself. This avoids leftover instances (LP: #1065684). * Set MTU of tunnel devices (LP: #1074048). * Actually set the new calculated value for duplicate entries (LP: #1086517). . [ Josselin Mouette ] * postinst: Do not create /etc/network/interfaces if it was removed manually (Closes: #695906) Checksums-Sha1: ec87737d6c81a3fd7e82132645277ecf3b4bd7b0 1606 ifupdown_0.7.40.dsc 00f4ab2eb17d511202c5c9135299f1433f5ce038 105634 ifupdown_0.7.40.tar.gz 143d7eb56523c2177c8899ca09dda326d6661230 65224 ifupdown_0.7.40_amd64.deb Checksums-Sha256: 231cbcabbaef7bc72c8f4422649e85bc04663c71d476a0cb8a5886ad46bad9d7 1606 ifupdown_0.7.40.dsc caee44c8751e756032052ea0baca795439457f298c3bef6025f9ed929a5cc771 105634 ifupdown_0.7.40.tar.gz 0c81d22fc89bf6456b1927090cd83257ecf6b79fd86b26437c43e14e4aa56e48 65224 ifupdown_0.7.40_amd64.deb Files: 3201e0b980cc633c57e23f49c26779ff 1606 admin important ifupdown_0.7.40.dsc e4a19213e617047475d7550dcc80aee1 105634 admin important ifupdown_0.7.40.tar.gz 770043f4d48d23bd53735981dc562b96 65224 admin important ifupdown_0.7.40_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCgAGBQJRNlfFAAoJEOJSSsUKn1xZb9oP/AqBaz6u39t0QvuBEKfQ3XUr 1B6VpC1vLaZPXJ6COQOZUIgU7PJ2MIZX4Js0Sy0Q3xxgZP19W61LhGvr54YFbm/o dwlBwImT817urjoJb6dRbYR1psIr9M3A8ovQ/jcuhCi6u+yKgYCXd0JVxNCzMpI1 wDoLAUidR0JzJN304XwFt5+BOjnMMy8WRV+a8zxrzXF2BMs1bPuH0oKlu9JYiQat LTTnoSJ5ZhDVzQgMbfjaA56oMlIgw5cecCt5EUKlvTp85/zwRXpjf46uIQT9VjM4 NeRNFu2oQnpAYz4x4q8W2odC2n1y9AAFQAb27fumjrgGI4sFguMWMm1M0Ff3Zq6u jbK71ZmNNgEMSo806ejQzJJ/G3KPE6U3TQrGWkZialIB3GALyJlj2wUqGe+7yy8r RQefkn86/xyAxMXnUJP+2PtOQTe6uAqvb9/uTz7+3ddevH7q7aNmPUDJy6+1vjBD h6yUFid4drp/FWgtomU13+I/WDeImuSkRE0Zy8k3HO4Z8l2HVnhjsCBPJP9/Zung 0FS3gD4RHdBVcbjre5xRC2iOQBdKbj3Y0rwwA1+ZHmHXEzXsJlRHUwgudcf05D4e rxOkoaSV4+MWnEYWeMm4j2i2P0R2vq1JsgG8upI9E9y2xeozekUlUeL3tTFJBU1O hnLfsgUT/XtdcZJML02+ =zjdJ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1ucztl-0003rw...@franck.debian.org
Accepted tayga 0.9.2-5 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sun, 03 Mar 2013 11:32:42 +0100 Source: tayga Binary: tayga Architecture: source amd64 Version: 0.9.2-5 Distribution: experimental Urgency: low Maintainer: Andrew O. Shadura bugzi...@tut.by Changed-By: Andrew Shadura bugzi...@tut.by Description: tayga - userspace stateless NAT64 Closes: 673491 700712 Changes: tayga (0.9.2-5) experimental; urgency=low . * Don't try to configure routes if options aren't set (LP: #1031772, also closes: #673491, #700712). * Bring more sanity to the init script. * Redirect TUN creation and removal messages to the system log. * Update Standards-Version to 3.9.4 (no changes required). Checksums-Sha1: 4ec796484b693b126c22e60a0edddc4b99d4a7a7 1211 tayga_0.9.2-5.dsc 46446d3870d990fc90bcfcda6a57214916899583 6940 tayga_0.9.2-5.debian.tar.gz 11a8e836d48ed39ccc679259e631f39c596d9e52 36668 tayga_0.9.2-5_amd64.deb Checksums-Sha256: cbe912446043773c9cc69897e75fe31848dd574e2e7ddc63e3450f6eb8589f6e 1211 tayga_0.9.2-5.dsc 95ee48ba7b617279d51430bca129f93d4dcea3932be4574fa0bead71ea2171a5 6940 tayga_0.9.2-5.debian.tar.gz bbe9bae3a69a7adedf8b5a442f2f90b0038fba71566770efca688bd32f786334 36668 tayga_0.9.2-5_amd64.deb Files: acda3d1eb56004f5ae44a5af8447db31 1211 net optional tayga_0.9.2-5.dsc 4f2991922f8300ab39d7ce1c8582da0e 6940 net optional tayga_0.9.2-5.debian.tar.gz 3f5dd11a27eff14d78698819bcf52631 36668 net optional tayga_0.9.2-5_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlEzdcIACgkQLz4Gnv7CP7Jb0QCfRQTeUEpiQLRVtEILzqRbN48H mKUAn1L31SmBKlzfgIOWNIwDWlVpymnZ =XxoG -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1ucbbz-0006el...@franck.debian.org
Re: git dangerous operations on alioth
Hello, On Fri, 01 Mar 2013 18:48:51 +0800 Thomas Goirand z...@debian.org wrote: On 02/28/2013 08:33 PM, Andrew Shadura wrote: we'd have both hg and git in one unified interface. That is a very nice feature. I saw few sites having that, for example bitbucket, unfortunatley, bitbucket doesn't allow git anonymous checkout over http (it's only available with hg, if I understood well). Or is there a hidden URL that I didn't find? Seriously, I've never tried bitbucket with git. Actually, what I usually do is exactly other way around: I use github with hg. -- WBR, Andrew signature.asc Description: PGP signature
Re: git dangerous operations on alioth
Hello. On 28 February 2013 12:51, Arno Töll a...@debian.org wrote: Having that said the risk is real and it may be time to reconsider some choices including the use of Alioth itself for those who do not believe in openness. Chances are #700630 is going to rescue us all on that. Maybe we could set-up our own gitorious instance once the stuff is packaged. I at least am very interested in such a Debian service and might even set one up. On this regard, I propose to wait till I finish packaging Rhodecode, and install it, as then we'd have both hg and git in one unified interface. -- WBR, Andrew -- 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/camb-mazovq1vgal1zpcujg4zsb_cvsmauaz-+u+sf7-xzf9...@mail.gmail.com
Re: Bug#700630: ITP: gitorious -- Git based tool for collaborating on distributed open source projects
Hello, On Tue, 19 Feb 2013 10:43:41 +0100 Piotr Ożarowski pi...@debian.org wrote: Just some info: I'm currently working on packaging Rhodecode and its dependencies; Rhodecode supports both Git and Mercurial, which is great. By the way, I mostly have finished it. great! Please update 689573 accordingly (and let me know if you need sponsored upload) Well, at this moment yes, I still need sponsorship. I asked Paul to review on of the deps a while ago, but it seems like he hasn't found time for that yet, so feel free to review it if Paul agrees :) http://alioth.debian.org/~andrewshadoura-guest/debian/unstable/waitress_0.8.1-1.dsc -- WBR, Andrew signature.asc Description: PGP signature
Re: Bug#700630: ITP: gitorious -- Git based tool for collaborating on distributed open source projects
Hello, On 15 February 2013 16:44, Stefano Zacchiroli z...@debian.org wrote: That's great, thanks for giving this a try. We definitely need more good packages of self-hosted replacements for popular centralized (and often proprietary) services out there. gitorious surely qualifies and is very seldomly seen installed in the wild, other than the main instance at gitorious.org. On a related matter, do you happen to have any news about gitlab packaging? I understand it's a concurrent of gitorious :-), but AFAICT from the RFP, it was expected to land under the hood of pkg-ruby-extras as well. Just some info: I'm currently working on packaging Rhodecode and its dependencies; Rhodecode supports both Git and Mercurial, which is great. By the way, I mostly have finished it. -- WBR, Andrew -- 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/camb-maycncpisc4q63jhsjb2r+xgbncz9gbhxm8bagymp4k...@mail.gmail.com
Re: Ifupdown, loopback interface, /etc/network/interfaces.d
Hello, On Mon, 07 Jan 2013 08:42:40 +0100 Tollef Fog Heen tfh...@err.no wrote: I'd like to hear opinions on this idea. I think you should just get a wheezy-ignore tag from the release team and solve this properly for jessie. Also, your fix doesn't actually solve the RC bug either: Well, it does. You Must Preserve All Admin Changes in /etc. Not just the ones you think is sensible or reasonable. Why not just report that the file is missing and leave it to the admin to fix (on upgrades, feel free to create it on the initial installation)? After all, if they have removed it, they probably know how to bring it back. My suggestion would be to, over the jessie cycle, deprecate (but still read) /etc/network/interfaces and for jessie+1 just drop the file and only use the .d directory. I don't think it's a good idea. -- WBR, Andrew signature.asc Description: PGP signature
Ifupdown, loopback interface, /etc/network/interfaces.d
Hello, Following the discussion to #695906, I propose the following solution to the problem. First of all, I'd like to remind that ifupdown supports source directive since very long ago (it was actually my very first patch to ifupdown to add that support), so anyone can split their network config into small chucks and place them under /etc/network/interfaces.d — it's not done by default, however, yet. The main problem mentioned by Tollef was, basically, that he couldn't disable lo interface configuration, which he needed for some reason, as ifupdown's postinst script was repairing the interfaces file. (Actually, creating an empty interfaces file would prevent it from doing so, as it only checks if the file exists, not if it's valid or not.) While there are various opinions on the question raised in that bug, I don't agree that this is a policy violation, but I propose to resolve this by enabling the usage of 'source' directive in the default configuration, and moving 'lo' interface description into /e/n/interfaces.d. Also, d-i would be now supposed to generate interfaces description in this directory as well, and the default interfaces file would consist of one line only from now: source /etc/network/interfaces.d/* (Please note that this 'source' doesn't recurse into subdirectories.) As /etc/network/interfaces.d/lo is now a conffile, it may be freely edited while being managed by dpkg. Of course, I could modify ifupdown to source these files automatically, but I'm not sure it's a very good idea to do that now. Same about making lo implicit and not requiring a declaration. Users upgrading the package from previous versions can have a warning reminding them that there's a new directory, so they may choose to change their configs; alternatively, we may try to migrate them automatically. I'd like to hear opinions on this idea. The current version of the patch is attached. -- WBR, Andrew From: Andrew Shadura bugzi...@tut.by Subject: Move loopback definition under /etc/network/interfaces.d, Date: Sun, 06 Jan 2013 20:27:13 +0100 Commit-Id: 534:9673a0084e119856fb5a0e81f9badfd69733c5e7 Move loopback definition under /etc/network/interfaces.d, which is now sourced from the default /etc/network/interfaces. Closes #695906. diff --git a/debian/dirs b/debian/dirs --- a/debian/dirs +++ b/debian/dirs @@ -8,3 +8,4 @@ etc/network/if-pre-up.d etc/network/if-up.d etc/network/if-down.d etc/network/if-post-down.d +etc/network/interfaces.d diff --git a/debian/ifupdown.interfaces.d.lo b/debian/ifupdown.interfaces.d.lo new file mode 100644 --- /dev/null +++ b/debian/ifupdown.interfaces.d.lo @@ -0,0 +1,4 @@ +# We should always have a loopback interface, or bad things may happen. + +auto lo +iface lo inet loopback diff --git a/debian/postinst b/debian/postinst --- a/debian/postinst +++ b/debian/postinst @@ -99,17 +99,26 @@ if [ $1 = configure ] ; then if [ -f /etc/network/interfaces ] ; then # TODO: This should be handled with debconf and the script # could introduce the line there directly -if ! grep -q ^[[:space:]]*iface[[:space:]]\+lo0\?[[:space:]]\+inet[[:space:]]\+loopback\ /etc/network/interfaces ; then - report_warn No 'iface lo' definition found in /etc/network/interfaces -fi -if ! grep -q ^[[:space:]]*\(allow-\|\)auto[[:space:]]\+\(.*[[:space:]]\+\|\)lo0\?\([[:space:]]\+\|$\) /etc/network/interfaces ; then - report_warn No 'auto lo' statement found in /etc/network/interfaces +if ! ifquery --list | grep -q ^lo[0-9]*$ ; then +report_warn No loopback interface definition is found, you may want to check you configuration, as it may break software badly. +if ! grep -q ^[[:space:]]*iface[[:space:]]\+lo0\?[[:space:]]\+inet[[:space:]]\+loopback\ /etc/network/interfaces ; then +report_warn No 'iface lo' definition found in /etc/network/interfaces. +fi +if ! grep -q ^[[:space:]]*\(allow-\|\)auto[[:space:]]\+\(.*[[:space:]]\+\|\)lo0\?\([[:space:]]\+\|$\) /etc/network/interfaces ; then +report_warn No 'auto lo' statement found in /etc/network/interfaces. +fi +if [ -d /etc/network/interfaces.d ] ; then +if grep -q ^[[:space:]]*iface[[:space:]]\+lo0\?[[:space:]]\+inet[[:space:]]\+loopback\ /etc/network/interfaces.d/* ; then +files=$(grep ^[[:space:]]*iface[[:space:]]\+lo0\?[[:space:]]\+inet[[:space:]]\+loopback\ /etc/network/interfaces.d/* | cut -d : -f 1) +report_warn Loopback interface definition is found in the following files: $files.\nYou may want to include one of them in your /etc/network/interfaces file using 'source' directive. Read more in interfaces(5). +fi +fi fi else # ! -f /etc/network/interfaces echo Creating /etc/network/interfaces. echo # interfaces(5) file used by ifup(8) and ifdown(8) /etc/network/interfaces -echo auto lo /etc/network/interfaces -echo iface lo inet loopback /etc/network/interfaces
Re: Ifupdown, loopback interface, /etc/network/interfaces.d
Hello, On Mon, 07 Jan 2013 00:12:29 +0100 Michael Biebl bi...@debian.org wrote: On 06.01.2013 23:48, Andrew Shadura wrote: First of all, I'd like to remind that ifupdown supports source directive since very long ago (it was actually my very first patch to I've checked the squeeze version of ifupdown, and it doesn't seem to support that directive. So calling it supported since very long is probably a bit far fetched. It was complete news to me tbh. Actually, it's supported for more than 1.5 years already, and the initial version of the patch has been available since 2.5 years ago. So yes, I call that very long ago — but I agree, it's not been in squeeze. And by the way, this has been annouced here. ifupdown to add that support), so anyone can split their network config into small chucks and place them under /etc/network/interfaces.d — it's not done by default, however, yet. Please keep in mind that such a setup will break existing tools and scripts, which rely on finding the interface definitions in /e/n/i. E.g. the ifupdown plugin in NetworkManager doesn't know anything about such a source directive. If you are going to use such a interfaces.d/ directory this will break the NM integration. Well, yes, I forgot about NM. Actually, as far as I know, it's the only tool affected, everything else either doesn't care to read /e/n/i, or is already fixed, or this difference is irrelevant and doesn't need to be urgently patched. Correct me if I'm wrong. I'd like to hear opinions on this idea. The current version of the patch is attached. Imho it is far too late in the release to consider such a change for wheezy as this has effects on d-i other tools in the archive (as shown above). Okay, maybe you're right, as we still have NM unpatched, and it's too little time to patch and test it. So, just sourcing the directory by default shouldn't be enabled either, should it? -- WBR, Andrew signature.asc Description: PGP signature
Re: Ifupdown, loopback interface, /etc/network/interfaces.d
Hello, On Mon, 07 Jan 2013 08:50:26 +0800 Chow Loong Jin hyper...@debian.org wrote: Please keep in mind that such a setup will break existing tools and scripts, which rely on finding the interface definitions in /e/n/i. E.g. the ifupdown plugin in NetworkManager doesn't know anything about such a source directive. If you are going to use such a interfaces.d/ directory this will break the NM integration. Besides NetworkManager, what other existing tools and scripts are there that parse /e/n/i manually? As far as I know, guessnet (already fixed) and ifupdown's postinst (irrelevant), maybe something else, but I remember none of them at the moment. -- WBR, Andrew signature.asc Description: PGP signature
Re: Ifupdown, loopback interface, /etc/network/interfaces.d
Hello,
On Mon, 07 Jan 2013 00:12:29 +0100
Michael Biebl bi...@debian.org wrote:
ifupdown to add that support), so anyone can split their network
config into small chucks and place them
under /etc/network/interfaces.d — it's not done by default,
however, yet.
Please keep in mind that such a setup will break existing tools and
scripts, which rely on finding the interface definitions in /e/n/i.
E.g. the ifupdown plugin in NetworkManager doesn't know anything about
such a source directive.
If you are going to use such a interfaces.d/ directory this will break
the NM integration.
If I understand the code correctly, the attached patch should do the
job. I haven't tried to compile it, however.
--
WBR, Andrew
--- a/src/settings/plugins/ifupdown/interface_parser.c
+++ b/src/settings/plugins/ifupdown/interface_parser.c
@@ -25,6 +25,7 @@
#include stdio.h
#include stdlib.h
#include string.h
+#include wordexp.h
#include nm-utils.h
if_block* first;
@@ -211,6 +212,25 @@
add_block(token[0], token[i]);
skip_to_block = 0;
}
+ else if (strcmp(token[0], source) == 0) {
+ wordexp_t p;
+ char ** w;
+ size_t i;
+ const char * rest = join_values_with_spaces(value, token + 1);
+ int fail = wordexp(rest, p, WRDE_NOCMD);
+ if (!fail)
+ {
+w = p.we_wordv;
+for (i = 0; i p.we_wordc; i++)
+{
+ ifparser_init(w[i], quiet);
+}
+wordfree(p);
+ } else {
+g_message (Error: failed to match files using %s\n,
+ rest);
+}
+ }
else {
if (skip_to_block) {
if (!quiet) {
signature.asc
Description: PGP signature
Re: Ifupdown, loopback interface, /etc/network/interfaces.d
Hello, On Mon, 07 Jan 2013 02:31:30 +0100 Michael Biebl bi...@debian.org wrote: There are probably more of them, but finding them all is left as an exercise for the reader. You can at least add network-admin from gnome-system-tools to the list, or external config tools like webmin. Not counting any local scripts written by sysadmins. For most of the cases direct parsing of /e/n/i isn't required, for the most of those cases when it's needed, there's now ifquery. So usually if some script parses /e/n/i or writes to it, something is already seriously wrong, with few exceptions. I'd be very cautious with such a change. We should be really certain that the benefits are worth the cost. They are. I agree that there may be not enough time. -- WBR, Andrew signature.asc Description: PGP signature
Re: Math Fonts for Iceweasel and MathJax
Hello, On Tue, 18 Dec 2012 14:50:05 +0100 Frédéric WANG fred.w...@free.fr wrote: Basically, Iceweasel must not depend on ttf-lyx, ttf-mathematica4.1, xfonts-mathml or any other font packages that would lead to the installation of Computer Modern fonts or Mathematica fonts. These old fonts were used a long time ago in Gecko's MathML engine but now they may give weird rendering bugs if they are still installed. However, the dependency on otf-stix should be preserved and possibly a dependency on fonts-oflb-asana-math should be added: http://packages.debian.org/sid/fonts-oflb-asana-math It would also be great to make Iceweasel depend on the MathJax fonts as they look more like the old Computer Modern fonts. And what's wrong with Computer Modern Unicode fonts? Don't they render properly? -- WBR, Andrew signature.asc Description: PGP signature
Re: Bug#695850: ITP: libteam -- library for controlling team network device
Hello, On Fri, 14 Dec 2012 00:21:43 +1100 Dmitry Smirnov only...@member.fsf.org wrote: Upstream Author: Jiri Pirko jpi...@redhat.com Jiří Pírko, please. He's Czech: https://www.ohloh.net/accounts/jiripirko -- WBR, Andrew signature.asc Description: PGP signature
Re: Do not CC me
Hello, On Mon, 26 Nov 2012 08:07:03 -0500 The Wanderer wande...@fastmail.fm wrote: Gmail does something similar, except not time-limited; it won't even re-send you a copy of a mail you send to a mailing list. This is apparently on the grounds that you already have a copy under Sent Items or equivalent, and of course Gmail's magical unified conversations view will show that message in the discussion's context no matter where it's actually stored. Not always true. I get both, every time, and the sent message sometimes I get twice :) -- WBR, Andrew signature.asc Description: PGP signature
Re: major linux problems summary 2012
Hello, On Mon, 12 Nov 2012 23:29:04 -0500 The Wanderer wande...@fastmail.fm wrote: Or you could try one of the laptops from ZaReason; they specialize in designing, building, and supporting laptops specifically intended to run Linux. I haven't used one myself, but they look like a good outfit from what I can see, and the laptops look decent within the somewhat limited selection available. What?! 'Glossy screen'? NVIDIA video card? Crappy keyboard? Thanks for pointing this out, I'm never going to buy anything they produce. My Dell D620 is *much* *much* better. -- WBR, Andrew signature.asc Description: PGP signature
Re: Bug#689207: ITP: rust -- a safe, concurrent, practical language
Hello, On Sun, 30 Sep 2012 13:22:01 +0200 Luca Bruno lu...@debian.org wrote: * URL : http://www.rust-lang.org/ * License : MIT Programming Lang: C/C++, Rust Description : a safe, concurrent, practical language Oh, please, please package it! It seems like it's very interesting language indeed! -- WBR, Andrew signature.asc Description: PGP signature
Re: O: ted -- lightweight .DOC editor
Hello, On Thu, 30 Aug 2012 01:28:39 -0500 Ztatik Light ztatik.li...@gmail.com wrote: The only valid .DOC editors in Debian are LibreOffice and AbiWord, which are both somewhat bloated (especially LibreOffice, as it's in Java) ... That's not true. LibreOffice isn't written in Java, it's written in C++. -- WBR, Andrew signature.asc Description: PGP signature
Re: RFC: usb-modeswitch 1.2.0 release embedding jimtcl
Hello, (As a Tcler I have to comment on this.) On Tue, 18 Oct 2011 13:36:43 +0200 Didier Raboud o...@debian.org wrote: 1) Forget about jimtcl, rely on existing tcl interpreters This is mostly repacking to avoid the embedded jimtcl copy, no packaging of it, go on as is done currently; by relying on existing tcl interpreters. Pros: easy, straightforward,avoids the binary embedding of jimtcl. Cons: does not solve the desktop install needs tcl interpreter. Jimsh is already available, and can be used separately. Also, libjim allows linking dynamically. And also, jim and tcl are a bit different, so it's not always jim-based script is able to run in plain tclsh without additional shims. 2) Allow interpretation using separate jimtcl This means packaging jimtcl and allow usb-modeswitch to depend on it (That, plus repacking to avoid the embedded jimtcl copy) Pros: relatively easy, avoids the binary embedding of jimtcl. Cons: replaces the need of the desktop install on a tcl interpreter to jimtcl. Although it's probably smaller. Already packaged, see above. 3) Embed jimtcl using the internal copy This means taking the upstream tarball as is. Pros: small standalone -dispatcher binary. Cons: code duplication, potential security issues with out-of-date jimtcl versions, … I see no problems with this, if there's just one or two packages linking against libjim statically. 4) Embed jimtcl using a standalone package This means packaging jimtcl and do some build-time trickery to include the jimtcl static library (if possible, only the needed parts) into usb- -modeswitch-dispatcher. Pros: small standalone -dispatcher binary, no code duplication. Cons: binNMU needed at each jimtcl upgrade, static linkeage. Same as above. 5) Rewrite the usb-modeswitch-dispatcher in C This work has already been done by Mathieu Trudel-Lapierre for the Ubuntu ackage. For now, the upstream developer hasn't included this rewrite into the upstream package (for his own set of reasons). My current strategy is to avoid as much as possible to diverge from upstream, hence why it's not in Debian's usb-modeswitch for now. Pros: No tcl interpreter needed. Cons: as it's not an upstream effort, it can become out-of-sync in terms of functionality and bugfixes (and indeed currently is as of 1.2.0~beta). Stupid and useless. Usb-modeswitch was originally written in C, and later rewritten in Tcl partially, as it was very hard to maintain it. What's wrong with having a minimalist tcl interpreter? It's no bigger than bash, and actually much smaller, and it's faster and doesn't rely on coreutils. What's your opinion ? Just link it against libjim, statically or dynamically. -- WBR, Andrew signature.asc Description: PGP signature
Re: RFC: usb-modeswitch 1.2.0 release embedding jimtcl
Hello, On Tue, 18 Oct 2011 10:59:36 -0400 Mathieu Trudel-Lapierre mathieu...@ubuntu.com wrote: It also doesn't solve a second case we're trying to cover: the fact that usb-modeswitch would be the only package in the boot path on *Ubuntu* that would rely on Tcl. That's another reason why a compiled language was chosen. Please get ready: there will be one more. 2) Allow interpretation using separate jimtcl Sounds like a good idea to ship jimtcl separately anyway. That said, the comments above apply again. There's jim already packaged, as a library and as an interpreter! For now, the upstream developer hasn't included this rewrite into the upstream package (for his own set of reasons). My current strategy is to avoid as much as possible to diverge from upstream, hence why it's not in Debian's usb-modeswitch for now. Yup, it's already out-of-sync, though I'll try to get this fixed in the next two weeks. I've also sent another email to upstream about including the rewrite. The end goal would be to have a tarball that provides both options: a tcl version and a C version of the -dispatcher code. The version to use could be chosen at build time. Why do you need this? What's wrong with having an ultrasmall interpreter in default Ubuntu, which provides more features than bash, which is much faster and much smaller? Also, you're redoing upstream's work in an absolutely opposite direction: they've moved away from C, and you're bringing it back! I'm obviously all for this option, but I agree it would be much better if it was included in the tarball. No. Just keep it as is. -- WBR, Andrew signature.asc Description: PGP signature
Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning
Hello, On Mon, 20 Aug 2012 14:51:27 +0100 Ben Hutchings b...@decadent.org.uk wrote: What I mean is that this still happens: # ifup eth0 ... # ifconfig eth0 down # ifup eth0 ifup: interface eth0 already configured Why should it happen otherwise? You did *NOT* deconfigure the interface. People talk about how ifupdown works well with other configuration tools, unlike Network Manager. But it doesn't, it only knows how to undo the configuration specified in /etc/network/interfaces. ...and NM can't do anything at all which it doesn't know about. How do you suppose it's possible to undo arbitrary network configuration done by arbitrary set of tools when there's no central place to hold such information (and can't possibly be)? -- WBR, Andrew signature.asc Description: PGP signature
Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning
Hello, On Mon, 20 Aug 2012 16:21:18 +0200 Mike Hommey m...@glandium.org wrote: People talk about how ifupdown works well with other configuration tools, unlike Network Manager. But it doesn't, it only knows how to undo the configuration specified in /etc/network/interfaces. ifupdown should be the only way to configure network interfaces. Debian should get rid of NM, ifconfig, ip, and all the other heretic programs that break ifupdown. Haha, how clever and funny. And now please go and write you own NetConfNG which handles all the possible situations, ever. Or maybe you know any which does that already? I'm not aware of it. -- WBR, Andrew signature.asc Description: PGP signature
Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning
Hello, On Fri, 24 Aug 2012 15:03:49 +0100 Ben Hutchings b...@decadent.org.uk wrote: There is, it's called the kernel. No, there isn't, and there can't possibly be, as interface's configuration isn't only what ifconfig/route/ip reports to you (which is what kernel knows about it). -- WBR, Andrew signature.asc Description: PGP signature
Re: Enabling uscan to simply remove files from upstream source
Hello, On Tue, 21 Aug 2012 12:21:21 +0200 Andreas Tille andr...@an3as.eu wrote: 2. If files matching are contained in the source tarball this will be repackaged except if the option --no-exclusion is given at uscan command line or if USCAN_NO_EXCLUSION is set in /etc/devscripts.conf or ~/.devscripts. 3. If the tarball did not contained any of the globs in debian/copyright::Files-Excluded it should be left untouched (except if the repackaging is needed because of compression method anyway if the user forces --repack). By the way, how about adding something under debian/source/... to allow automatic repacking regardless of Files-Excluded? (Or please tell me how to repack upstream's zipball to targz automatically without having to specify --repack every time.) -- WBR, Andrew signature.asc Description: PGP signature
Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning
Hello, On Sun, 19 Aug 2012 19:32:03 +0100 Ben Hutchings b...@decadent.org.uk wrote: 3) ifupdown integration is really bad ifupdown is really a good framework, it offers hooks and and is properly integrated in many packages. ifupdown *was* a good framework, but Linux moved on. ifupdown doesn't know anything about interface state. Why should it? It's a configuration tool, not a monitoring one. If monitoring is needed, a different tool can be developed which would perfectly integrate into ifupdown... but nobody has needed that yet? It doesn't know whether hooks succeeded and it can't check for failures because that would be an incompatible change (#547587). It can, and compatibility isn't a matter here, it's just a question of bringing other packages to a state they should have been in already. Also, as you don't know the stuff behind ifupdown development, please don't make such statements, okay? We're in the freeze now, so the work on ifupdown is limited to fixing RC bugs for a while, but this doesn't mean new stuff won't be developed to make ifupdown better. -- WBR, Andrew signature.asc Description: PGP signature
Re: Bug#684396: ITP: openrc -- alternative boot mechanism
Hello, On Fri, 10 Aug 2012 13:11:12 +0200 Josselin Mouette j...@debian.org wrote: Le vendredi 10 août 2012 à 17:04 +0900, hero...@gentoo.org a écrit : Debian is about the freedom to choose. No, it is not. No, it is. -- WBR, Andrew signature.asc Description: PGP signature
Re: Change default PATH for Jessie / wheezy+1
Hello, On Wed, 08 Aug 2012 19:26:27 +0800 Thomas Goirand z...@debian.org wrote: This kind of remark make be say that probably, it'd be nice to have ifconfig display a warning as this one: ifconfig is deprecated, please use ip instead It'd be terrible. Please don't even think of it, okay? Let people decide themselves what to use. -- WBR, Andrew signature.asc Description: PGP signature
Re: Change default PATH for Jessie / wheezy+1
Hello, On Wed, 8 Aug 2012 12:40:42 +0100 Roger Leigh rle...@codelibre.net wrote: As a distribution we have to decide on a default, and that is ip. We took the effort to remove all use of ifconfig from ifupdown and other related tools for wheezy precisely to make it removable and optional, so that it can eventually be removed. It's perfectly fine to make it optional so the system doesn't require it, but complete removal seriously affects usability. Ifconfig is much more human-oriented, and it's not Linux-only, as some people mentioned here. While it's fine for an end user to continue to use ifconfig, we should continue to remove its use by ourselves and in programs in Debian. Warning the user that they are using an obsolete tool is IMO entirely justified, particularly when there is a much better and more capable replacement. I don't think any warning is justified. I use ifconfig quite often, and seeing any warnings is very annoying. It's the same situation as with idn(1), which used to display information about it's LGPL license every time you run it, which for me as a user is just on-screen rubbish which prevents me from receiving the information effectively. Also, when it becomes an optional package, it's completely user's choice to install it, so we shall respect it and not to warn anyone. A kind of warning may be put as the last paragraph of the package description, however, so users know what they're doing when they install it. Ifconfig is perfectly fine for many tasks and I can't seen why it should be wiped or anything. Same applies to route(8), which produces more readable output for IPv4 (but not for IPv6). As for netstat(8), I don't know a better tool. P.S. There are complaints about net-tools that they use old APIs. Okay, complainers are free to port them to newer ones, probably adding support for multiple IPv4 addresses or anything, but please keep the interface as close as possible to what we have now. -- WBR, Andrew signature.asc Description: PGP signature
Re: Change default PATH for Jessie / wheezy+1
Hello, On Wed, 08 Aug 2012 19:44:25 +0200 Vincent Bernat ber...@debian.org wrote: arp can be replaced by ip neigh, ifconfig by ip addr or ip link, route by ip route, ipmaddr by ip maddr, mii-tool by ethtool, netstat by ss, nameif by ip link, iptunnel by ip tunnel. iproute and ethtool packages are kept in sync with kernels and allow the user to use the latest features. ...And completely lack full documentation on all of them, yeah? -- WBR, Andrew signature.asc Description: PGP signature
Re: [RFC] Add upstream VCS info to control file
Hello, On Thu, 14 Jun 2012 17:30:51 -0400 James McCoy james...@debian.org wrote: Since devscripts 2.11.7, you can do this: Vcs-Git: git://anonscm.debian.org/anonscm.debian.org/openstack/nova.git -b debian/unstable I thought the patch that added that also updated the documentation, but it looks like documentation still needs to be added. I wonder why not use #-syntax, just like hg does: Vcs-Qux: quux://host.org/path/to/repo#debian/unstable -- WBR, Andrew signature.asc Description: PGP signature
Re: duplicates in the archive
Hello, On Sun, 24 Jun 2012 20:36:13 +0100 Neil Williams codeh...@debian.org wrote: If it can be justified. That's what the objective comparison would need to demonstrate. That's an established pattern in Debian - if someone wants to add something which is the same as something else, there should be a good reason to introduce the new one in that it needs to be better than the existing ones in some way which isn't achievable just by patching one of the existing ones. It is definitely not the same and not duplicate. Different window managers look differently and feel a lot differently (I thought it should be obvious enough, isn't it?). More to say, I'd like to see this window manager in Debian, jugding by its documentation it seems to be really great, flexible yet tiny and easily configurable, so I support it's inclusion fully. -- WBR, Andrew signature.asc Description: PGP signature
Re: Bug#678920: ITP: libzapojit -- library for accessing SkyDrive and Hotmail
Hello, On Sun, 24 Jun 2012 21:36:20 -0400 Jeremy Bicha jbi...@ubuntu.com wrote: * Package name: libzapojit What a funny name, hehe :) -- WBR, Andrew signature.asc Description: PGP signature
Re: Build environment bug: 675125
Hello, On Tue, 19 Jun 2012 23:03:17 +0200 Bernd Zeimetz be...@bzed.de wrote: Try gcc/g++ 4.6 instead of 4.7. Maybe check if S-Lang load path (wherever that is stored) is initialized in a sane way. I had a similar issue where an integer was 0 all the time - although not being initialized with something useful - which changed with gcc 4.7, then it was just a random value :) By the way, it might be a good idea to fill .bss section with random values intentionally for debug builds to detect non-properly-initialised things more effectively :) -- WBR, Andrew signature.asc Description: PGP signature
Re: Build environment bug: 675125
Hello, On Tue, 19 Jun 2012 15:11:33 -0700 Josh Triplett j...@joshtriplett.org wrote: Variables in the .bss section will by definition get initialized to 0. For example, a C variable defined as static typename varname; must get initialized to 0, and the compiler and linker will stick it in the .bss section expecting that it will end up with a value of 0 at runtime. That represents a defined property of the standard, not an implementation quirk. So, the .bss section must get initialized to 0, not to random values, whether in a debug build or not. Oh, yes, indeed, though I see no such requirement to put initialise non-static variables in the standard, so static variables could just go to .data section, leaving .bss truly uninitialised. -- WBR, Andrew signature.asc Description: PGP signature
Re: ifupdown's changed hook handling breaks other packages.
Hello, On Mon, 18 Jun 2012 09:23:25 +0200 Josselin Mouette j...@debian.org wrote: Le samedi 16 juin 2012 à 19:38 +0200, Andrew Shadura a écrit : Also, it's network-manager who tries to be a replacement somehow compatible with ifupdown, not vice versa, so NM maintainers should take care of their package to do things are they're supposed to be done in a compatible way. NM is not compatible with ifupdown and does not try to be. This is *precisely* why the /e/n/i lines are commented out by nm.postinst. When I say 'compatible' I don't mean NM supports everything ifupdown does (which it certainly doesn't and doesn't try to), I mean it is compatible in that it at least doesn't break ifupdown. It sounds to me that you have broken this behavior on purpose, where you could instead have added an interface to make disabling an interface more convenient than sed hackery (as mandated by policy). No. Also I'd like to remind you that this sed hackery has already been done by NM maintainers without much discussions on how to make it better. -- WBR, Andrew signature.asc Description: PGP signature
ifupdown should provide a way to disable interfaces configuration
Package: ifupdown Hello, On Mon, 18 Jun 2012 09:53:49 +0200 Stefano Zacchiroli z...@debian.org wrote: Let's stop the mutual accusation part of this thread. To avoid similar issues to arise again in the future, I wonder, would it be feasible to implement something like Joss mentioned, i.e. some sort of ifupdown blessed mechanism to enable/disable interfaces? The need of doing so exists, NM is an example of that. Enabling people to do so without _having_ to rely on text file fiddling would be an improvement over the status quo. I guess that can be done. The question is what exactly would be cool to have: just ability to black-list some interfaces, or ability to skip calling ifup/ifdown at boot time at all? Or, probably, both? -- WBR, Andrew signature.asc Description: PGP signature
Re: ifupdown's changed hook handling breaks other packages.
Hello, On Mon, 18 Jun 2012 09:53:49 +0200 Stefano Zacchiroli z...@debian.org wrote: Let's stop the mutual accusation part of this thread. P.S. Didn't mean to make anybody upset; I was a little bit tired back then, and I'm sorry that affected the way of me communicating with people. -- WBR, Andrew signature.asc Description: PGP signature
Re: ifupdown's changed hook handling breaks other packages.
Hello, On Sat, 16 Jun 2012 19:05:06 +0200 Michael Biebl bi...@debian.org wrote: Reassigning it back as it really is a bug in NetworkManager. I've asked for further justification. Just saying really isn't. If it is a bug in NetworkManager, then please show me where. auto eth0 #NetworkManager#iface eth0 ... is not a valid syntax. So when we have interfaces 'defined' like this, initscripts' hook thinks we've got all 0 interfaces up so it can start. Of course, this needs to be fixed so it won't even try to do so. But the source of the problem is that NetworkManager was abusing a bug in ifupdown's parser. If you really wanted to 'hide' an interface, you should have commented out all the 'auto' and 'allow-' lines, not 'iface', leaving 'auto' intact, which apparently doesn't work. Also calling ifupdown's hooks at random moments isn't a good idea either. If you suddenly decide to change the behaviour of ifupdown, then please co-ordinate such a change and get affected packages fixed beforehand. And let packages know what they need to change. That wasn't suddenly. It's been documented always but didn't work a little bit as expected. Exploiting a bug in a parser is always bad, and there's no excuse for doing that. I can't possibly know every person who's tried to misuse this software, and that's really a problem of those persons. Or shouldn't bugs get fixed at all then if anyone exploits them all the time? I think that reassigning a bug to network-manager in a first place was a clear enough message that something needs to be changed, so reassigning it back multiple times isn't a good way of communication either. -- WBR, Andrew signature.asc Description: PGP signature
Re: ifupdown's changed hook handling breaks other packages.
Hello, On Sat, 16 Jun 2012 19:05:06 +0200 Michael Biebl bi...@debian.org wrote: If you suddenly decide to change the behaviour of ifupdown, then please co-ordinate such a change and get affected packages fixed beforehand. And let packages know what they need to change. Also, it's network-manager who tries to be a replacement somehow compatible with ifupdown, not vice versa, so NM maintainers should take care of their package to do things are they're supposed to be done in a compatible way. -- WBR, Andrew signature.asc Description: PGP signature
Bug#673832: ITP: critcl -- compiled runtime in Tcl
Package: wnpp Severity: wishlist Owner: Andrew Shadura bugzi...@tut.by * Package name: critcl Version : 3.0.3 Upstream authors: Andreas Kupries akupr...@shaw.ca Jean-Claude Wippler j...@wippler.nl * URL : http://jcw.github.com/critcl/ * License : BSD Programming Lang: C, Tcl Description : compiled runtime in Tcl Critcl takes a snippet of C, generates Tcl interface, sends it to the compiler, and then dynamically links the code. Checksums are used to only recompile when needed, so the build overhead really applies only once. -- 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/20120521170420.22434.65795.reportbug@localhost.localdomain
Re: why do people introduce stup^Wstrange changes to quilt 3.0 format
Hello, On Thu, 17 May 2012 16:52:02 +0200 Gergely Nagy alger...@balabit.hu wrote: Git does have a complete view. What the above does, is tell dpkg-source to fold any changes made to the upstream sources into a single patch. Since the git tree already has the patches applied (with upstream sources on a different branch, most probably), it has a full view. This basically folds whatever patches the git tree has over upstream, outside of debian/ into a single file. That's about it. Since that file is generated, it has no business staying in git. I find it a very bad idea, as then it's very hard to track what patches we have applied. And no, VCS history doesn't help at all as we see *all* the patches ever applied or not, and also upstream changes sometimes. For that reason I prefer keeping patches themselves tracked as well, or I even (mostly) unapply them so the source in the VCS is clean. -- WBR, Andrew signature.asc Description: PGP signature
Re: why do people introduce stup^Wstrange changes to quilt 3.0 format
Hello, On Fri, 18 May 2012 11:37:08 +0200 Adam Borowski kilob...@angband.pl wrote: Quilt is a kind of really primitive VCS. It does not make sense to use both it and a modern one, and when someone tries, this ends up with no end of woe. Quilt sprinkles its modifications around the source, breaks timestamps causing unnecessary rebuilds, breaks basic VCS abilities like bisection, makes it really hard to even review history, and so on. I'm sorry to disappoint you, but quilt isn't a VCS at all. It's a patch queue management system, and it does its job well. And, by the way, git can't do it better at the moment as guilt seems to be dead, and stgit is buggy (mq in mercurial is better than quilt, but we speak of git atm). Keeping patches in git makes thing less transparent and more complicated. You have to inspect all the history just to find out what changes did maintainer do to the original source. And, of course, you need to have a clone of the repo. You complain about forcing people to use git, while you push quilt onto everyone else. And while git can do every single thing quilt can do, the reverse is thoroughly untrue. No, it can't. Please check what git, and what quilt is. They are different tools for different purposes and they can't do each other's job well enough. -- WBR, Andrew signature.asc Description: PGP signature
Bug#672212: RFH: ifupdown: please help adding GNU/Hurd support
Package: wnpp Severity: normal While we still have some time before freeze, it may be not too late to add GNU/Hurd support to 0.7 branch of ifupdown. For people familiar with GNU/Hurd it shouldn't be too hard, I guess. Currently, I don't have enough time for this, and I don't really have where to test it, so if anyone is interested in having Hurd support, please help. I'd really like if ifupdown 0.7 didn't drop Hurd, but with the current state of things it's very likely to happen. -- WBR, Andrew -- 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/20120509065347.10742.49411.reportbug@localhost.localdomain
Re: Licenses not in /usr/share/common-licenses
Hello, On Mon, 07 May 2012 18:32:50 +0200 Gergely Nagy alger...@balabit.hu wrote: since executable debian/copyright is not supported If we forget for a second about dh-exec and how it's used, this sounds really crazy :) -- WBR, Andrew signature.asc Description: PGP signature
Re: Bug#648345: marked as done (FTBFS on kfreebsd-amd64)
Hello, On Fri, 4 May 2012 16:34:30 +0200 m...@linux.it (Marco d'Itri) wrote: That doesn't look cosmetic to me. That looks like an FTBFS fix for kfreeBSD, which he gave you 5 months to do yourself before NMUing it. Since the package did not work before and will not work after, I do not consider this strictly a FTBFS bug. Marco, please respond to at least one of my messages I sent you last month or so, and please do some action on netbase. -- WBR, Andrew signature.asc Description: PGP signature
Re: switching from exim to postfix
Hello, On Tue, 1 May 2012 23:03:38 +0200 Philipp Kern pk...@debian.org wrote: I wonder why many people in this thread still don't understand this. And also I can't see why some find this annoying behaviour or something wrong. There's absolutely nothing wrong with what it does now, as re-encoding will happen somewhere anyway as there are still many really non-8-bit-compliant MTAs, so why should Exim do this? Exim transmits 8bit mails to non-8bit-compliant MTAs, so what exactly are you arguing? No it doesn't if 8BITMIME annouces are turned off! -- WBR, Andrew signature.asc Description: PGP signature
Re: switching from exim to postfix
Hello, On Wed, 2 May 2012 10:06:31 +0100 Jon Dowland j...@debian.org wrote: On Wed, May 02, 2012 at 08:44:12AM +0200, Andrew Shadura wrote: No it doesn't if 8BITMIME annouces are turned off! If exim receives an 8 bit mail, even if it hadn't announced 8BITMIME in the EHLO response, it will relay that message verbatim to other hosts. But it won't receive it at all if the sender is standards-compliant. -- WBR, Andrew signature.asc Description: PGP signature
Re: switching from exim to postfix
Hello, On Tue, 1 May 2012 20:18:07 +0200 Philipp Kern pk...@debian.org wrote: So just stop Postfix doing the conversion? Or teach Exim to announce 8BITMIME by default. No, Exim should not announce 8BITMIME, or it will violate RFC, not otherwise. Now it doesn't announce it, but accepts, so RFC-compliant MUA or other MTA should do the conversion themselves and everything just works. If it announces the support, it effectively lies as it doesn't support conversion which is needed if it wants to send mail to non-compliant MTA. I wonder why many people in this thread still don't understand this. And also I can't see why some find this annoying behaviour or something wrong. There's absolutely nothing wrong with what it does now, as re-encoding will happen somewhere anyway as there are still many really non-8-bit-compliant MTAs, so why should Exim do this? -- WBR, Andrew signature.asc Description: PGP signature
ifupdown/hurd [was: hurd-cvsfs -- CVS virtual filesystem for the GNU Hurd]
Hello, On the other hand, I've spent the whole week-end fixing some bits in glibc/parted/grub, which we *DO* need for a release. By the way, how about helping a bit with making ifupdown work properly (and, since recently, build, of course) on Hurd? It'd be really helpful if anybody deeply involved into Hurd could do anything for this. -- WBR, Andrew signature.asc Description: PGP signature
ifupdown news
Hello, A new version of ifupdown has been uploaded to experimental yesterday, which brings some important changes. First of all, now it's possible to specify default values for various interface configuration options. This eliminates the need of hard coding of them in C source, as Ubuntu has been doing for some time. End users are not affected by this change at all, of course. Second, now ifup behaves differently when it's called with --all option. Previously, that was causing all interfaces marked as 'auto' to be brought up. Now, it does exactly the same if --allow option isn't used. Otherwise, it brings up the interfaces which are declared to belong to a specified class using allow-* directive. In other words, 'auto' directive indeed declares interface as belonging to a class 'auto', and the default class for ifupdown is also 'auto', so when user runs `ifup -a` only those interfaces are brought up. Also, when called with --all, both ifup and ifdown now also call hook scripts before doing anything and just after that. Specifically, before bringing interfaces up, it calls pre-up scripts with a special interface name and a special address family (which can't happen otherwise), and calls post-up scripts after doing everything it needs. Same happens with ifdown, but it calls different scripts, of course. This feature helps to avoid manual parsing of /etc/network/interfaces and /run/network/ifstate as mountnfs script did (and still does), for example. In theory, exactly none of the existing scripts should be broken by this change. At least, I couldn't find any of distribution-supplied scripts which could break. Also, Network Manager already uses similar approach, so if anything can break, it's been broken for a long time already. One more change is related to the initscript. /etc/init.d/ifupdown is no more. However, ifupdown now provides /etc/init.d/networking instead of netbase. This means, the next version of netbase needs to drop it, and also setting up Breaks relationship would be cool. The script itself has been changed a bit. Apart from other things, now it supports reload command properly, grabbing the current interfaces state and bringing those interfaces back up. Also, start command now tries to bring up interfaces which are specified with 'allow-hotplug' if they can be brought up. Cool news for Ubuntu maintainers and everyone else interested: now ifupdown supports ifquery interface previously available in Ubuntu only. It has some bugs fixed, and now seems to work properly with mappings and already-up interfaces. Finally, /run transition has almost finished, so please if you opened any related bugs, please test and report if they still need fixing. Also, this version (with one more bug discovered while preparing this post fixed) is going to be upload to unstable as soon as enough people test it to be sure it's not going to Break Everything At All. In that upload, I plan to temporarily unapply a controversial patch already discussed on debian-devel@ which changed the processing of hook scripts' return values. Please do test and report any bugs you find. And, of course, a short summary of the changes: * Prefer isc-dhcp-client to dhcp3-client (also closes: #422885). * Let dhclient fail when no lease can be acquired (Closes: #420784). * Raise command-line options priority over /etc/network/interfaces (Closes: #657743). * Prevent aliases and VLANs from putting the main interface down (Closes: #656270). * Make iproute2 calculate the broadcast address (LP: #924880). * Shut udhcpc down correctly (Closes: #338348). * Update the rules according to /run migration. * Pass hardening flags from dpkg-buildflags (Closes: #661243). * Implement ifquery interface (Closes: #568479). - Make ifquery process mappings (LP: #850166). - Ensure ifquery always has no_act turned on. * Change --all behaviour: - If ifup or ifquery is called with the --all option, if doesn't just bring up all interfaces marked as auto, but all interfaces of a specified class, auto by default. For the most uses, this doesn't change anything, but lets all the interfaces of a specific class to be brought up or queried. * Support cross-compilation, move Debian-specific things out of the Makefile (Closes: #666084). * Take networking init script over from netbase package. - Add reload action which reconfigures all interfaces currently configured. - Add LSB Description field. - Remove /usr from PATH. - Merge ifupdown initscript in. - Improve warning messages. - Don't use redirection hacks when parsing /proc/mounts and /proc/swap. - Document all supported subcommands. - On start, try to configure hotplug interfaces if they seem to be ready. Ignore errors if they fail to configure for some reason (for example, if the interface happens to be renamed by udev before it's fully configured). - Override Lintian's false
Re: Bug#668556: ITP: dparser -- a scannerless GLR parser generator
Hello, On Sat, 14 Apr 2012 12:37:00 +0900 Charles Plessy ple...@debian.org wrote: * Package name: dparser Description : a scannerless GLR parser generator DParser is a scannerless GLR parser generator based on the Tomita algorithm. It is self-hosted and very easy to use. Grammars are written in a natural style of EBNF and regular expressions and support both speculative and final actions. I would like to suggest to explicit the GLR, RPF, and perhaps EBNF acronyms in the long description. In my opinion, this isn't needed. Those (except for RFP which is request for packaging) are well-known abbreviations are need not be explained to potential users of the package. -- WBR, Andrew signature.asc Description: PGP signature
Re: Bug#668556: ITP: dparser -- a scannerless GLR parser generator
Hello, On Sat, 14 Apr 2012 13:12:48 +0200 Adam Borowski kilob...@angband.pl wrote: I can't really imagine someone writing a parser using such tools without having heard these acronyms first, though. And I'd risk saying they are actually more widely known than their expansions. During my university studies I had a course dedicated to compilers theory, but while I knew (and still know) the meaning of all those abbreviations I rarely tried to spell them out in full, but rather was always using their abbreviated forms. -- WBR, Andrew signature.asc Description: PGP signature
Re: Bug#667496: ITP: python-smmap -- pure git implementation of a sliding window memory map manager
Hello, On Wed, 04 Apr 2012 22:40:28 +0900 TANIGUCHI Takaki tak...@debian.org wrote: Description : pure git implementation of a sliding window Sorry? Pure git? -- WBR, Andrew signature.asc Description: PGP signature
Bug#666242: ITP: clearwaita-theme -- Clearwaita theme for GTK+
Package: wnpp Severity: wishlist Owner: Andrew Shadura bugzi...@tut.by * Package name: clearwaita-theme Upstream Author : Jean-Philippe Fleury * URL : http://www.jpfleury.net/en/software/clearwaita.php * License : GPL-3+ Description : Clearwaita theme for GTK+ Clearwaita is a GTK+ 2/GTK+ 3 theme. Files for GTK+ 3 are a modified version of Adwaita, the default GNOME 3 theme, to make it visually close to Clearlooks. Files for GTK+ 2 come from the unmodified Clearlooks theme. -- WBR, Andrew -- 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/20120329214755.8434.34200.reportbug@localhost.localdomain
Re: ITP: oqapy -- Photographic workflow application
Hello, On Thu, 01 Mar 2012 06:42:24 +0100 Vincent Vande Vyvre vincent.vandevy...@swing.be wrote: This application is designed to handle large collection of image files with full support of metadatas include geolocalisation. Sorry for this little pedantism, but data is already plural (singular form is datum), so no need to add 's' to the word to pluralise it. Please report this to upstream as I see they use 'datas' at least at their website. -- WBR, Andrew signature.asc Description: PGP signature
Re: Bug#661591: packages providing ifupdown scripts must have those scripts fixed if needed
Hello, On Tue, 28 Feb 2012 22:37:29 +0100 Holger Levsen hol...@layer-acht.org wrote: just from what I've read in those two replies to this bug yet, I think I agree that this change should be reverted. And if you really want/need/do this change which needs changes in 30 (or so) other packages, then please file 30 bugs against those package and then use these bugs as blockers against one bug for tracking. (And I'd prefer this bug to be one against ifupdown and not general, but YMMV.) But, definitly, filing a bug against general saying these and these package need to be fixed wont do it. It does NOT involve all of those packages directly. Most of them do things correctly, some don't. That's why I've asked all the maintainers to do checks needed, just to make it easier, so people review their packages only and don't go into deep of others' packages. -- WBR, Andrew signature.asc Description: PGP signature
Re: Bug#661591: packages providing ifupdown scripts must have those scripts fixed if needed
Hello, On Tue, 28 Feb 2012 22:37:29 +0100 Holger Levsen hol...@layer-acht.org wrote: (And I'd prefer this bug to be one against ifupdown and not general, but YMMV.) But, definitly, filing a bug against general saying these and these package need to be fixed wont do it. Also, I find it fits general perfectly, as it's not a bug in ifupdown, but rather a number of bugs in some of the packages in the list. -- WBR, Andrew signature.asc Description: PGP signature
Re: Bug#661591: packages providing ifupdown scripts must have those scripts fixed if needed
Hello, On Tue, 28 Feb 2012 14:27:15 -0800 Steve Langasek vor...@debian.org wrote: When failure to execute a hook leads to interface being non-operational. Yes, that's probably a reasonable threshold. What should packages like miredo and wide-dhcpv6-client do? Both of these hooks have to do with routing information; if an interface comes up but the hook fails, the interface may be operational but not actually routing traffic to the networks the user cares about reaching. Should these hooks exit non-zero on failure, or not? Probably they should. Could this guidance be included in the ifupdown documentation as a clue to maintainers? The problem is that it's entirely up to the maintainer of an appropriate package; ifupdown doesn't really care what the hook script is doing, so it's script maintainer who should decide if this particular failure can be ignored (probably, with a warning) or if it's critical. This isn't a change in behaviour at all. Er, it most certainly is. You may argue that the previous behavior was *wrong*, but it's just plain false to say that the behavior isn't changing. There was a bug in ifupdown, but scripts must have been written with this behaviour in mind. And the change is incompatible with at least some existing hook scripts, which means it's incumbent on you as the ifupdown maintainer to coordinate this behavior change with the maintainers of those other packages. *Not* just filing a bug on general, but actually following through on this transition to make sure things get fixed as needed. Obviously I want this process to happen, but as a start a bug must be filed, so discussion can start, no? I understand this exactly this way. It does NOT involve all of those packages directly. Most of them do things correctly, some don't. That's why I've asked all the maintainers to do checks needed, just to make it easier, so people review their packages only and don't go into deep of others' packages. A bug filed against general is not an appropriate means of notifying package maintainers of anything at all. general bugs are sent to debian-devel, which maintainers are not required to follow. The idea was to make an announcement and to have some kind of a central point where the status can be seen. Also, I don't feel it a good idea to file bugs against packages not having them, and I can't physically check all the packages on my own to decide if they have bugs or not. Debian-devel seems to be the best place for this, I think. I think Holger is right that this needs to be done as a mass bug filing or other coordinated effort to review all of the hooks. I'm open to suggestions how to perform this better; I tried to review the packages from that list, but it's no easy task for me as I do not maintain any of them, so I can easily miss some important detail. That's why I asked for help here. Also, I wasn't going to push that particular change until I'm sure that at least the most of the packages don't have any problems with this. -- WBR, Andrew signature.asc Description: PGP signature
Re: Bug#661591: packages providing ifupdown scripts must have those scripts fixed if needed
Hello, On Wed, 29 Feb 2012 00:47:57 +0100 m...@linux.it (Marco d'Itri) wrote: Yes, that's probably a reasonable threshold. What should packages like miredo and wide-dhcpv6-client do? Both of these hooks have to do with Maybe they could stop pretending that the ifupdown configuration model can properly support multiple address families. How's that? Explain, please. which means it's incumbent on you as the ifupdown maintainer to coordinate this behavior change with the maintainers of those other packages. *Not* This is going to be a problem, considering that for most practical purposes ifupdown lacks a maintainer. Somehow 'Maintainer' field of the control file doesn't agree with you. -- WBR, Andrew signature.asc Description: PGP signature
Re: Debian 5.0 support for VMware ESX 3.5/4.0/ESXi 4.1
Hello, On Wed, 15 Feb 2012 16:40:03 +0100 Piotrek P to.think.ab...@gmail.com wrote: Dear All, Please be aware that VMware ESX 3.5 is NOT supporting any of Debian as Guest OS. Please be aware that VMware ESXi 4.1 IS supporting Debian 4.0, 5.0 as Guest OS. Please be aware that VMware ESX 5.0 IS supporting Debian 4.0, 5.0, 6.0 as Guest OS. Piotrek, I wonder, what do you mean when you say 'support'? What kind of support do you personally need? VMware (afaik) does have some Linux-specific hacks, but they do work regardless of a distribution and Linux kernel version. Also, it's quite probable that there aren't any real hacks there but just some presets (correct me if I'm wrong). So, does it really matter? -- WBR, Andrew signature.asc Description: PGP signature
Re: DEP-5 and files with white spaces
Hello, On Thu, 09 Feb 2012 11:01:00 +0100 Goswin von Brederlow goswin-...@web.de wrote: Idea 2: Allow quotation marks. Not a solution on its own. What about a file named foo bar' baz? For a worst case what about files with newlines? You can double the delimiter to embed it into a string, like this: foo bar' baz or 'foo bar'' baz'. -- WBR, Andrew signature.asc Description: PGP signature
Migrating (finally?) from Tcl/Tk 8.4 to something newer.
Hello, Currently in unstable there are around 30 packages which depend on Tcl/Tk 8.4, which is quite old itself despite the fact that updates are still released for it. Tcl/Tk 8.5 is available for more than 4 years, Tcl/Tk 8.6 is coming soon, so I think it may be the time to deprecate Tcl/Tk 8.4 finally. I've filed bugs against some packages already, one of them already got fixed, and also I've prepared two QA uploads to orphaned packages (one of which is already uploaded, thanks, Paul!) So I'd like the maintainers of the packages which still depend on Tcl/Tk 8.4 to update their packages to build against/use newer Tcl/Tk versions. I'm going to post here a list with details on packages needing some work a bit later. -- WBR, Andrew signature.asc Description: PGP signature
Re: Migrating (finally?) from Tcl/Tk 8.4 to something newer.
Hello, On Fri, 30 Dec 2011 14:43:29 +0300 Andrew Shadura bugzi...@tut.by wrote: So I'd like the maintainers of the packages which still depend on Tcl/Tk 8.4 to update their packages to build against/use newer Tcl/Tk versions. Also, I'd like to ask, that if possible, try to fix change the packages so they don't need source changes to rebuild them against a specific version of Tcl or Tk. -- WBR, Andrew signature.asc Description: PGP signature
Re: Bug#653208: ITP: node-ain2 -- syslog logging for Node
Hello, On Sun, 25 Dec 2011 15:43:44 +0700 Jonas Smedegaard d...@jones.dk wrote: Ain can send messages by UDP to 127.0.0.1:514 or to the a unix socket; the latter however only for Node 0.4.x, as unix_dgram sockets support has been removed 0.5.x. What? And they say Node.js is a 'cool' software after that? -- WBR, Andrew signature.asc Description: PGP signature
Re: /tmp as tmpfs and consequence for imaging software
Hello, On Sun, 13 Nov 2011 15:39:51 +0100 Salvo Tomaselli tipos...@tiscali.it wrote: $HOME is not really nice but it could work. I have a tmp dir under my home directry and some script to clean up at every log on. $HOME seems like a very bad idea to me. At least if used by default... Many universities (and i guess other places too) keep the homes on a file server and the rest locally. In my university we had a local aufs(ro:nfs + rw:tmpfs) home plus nfs-backed ~/work which all the workstations shared. If you wanted to, you could use a subdirectory in ~/work, but given enough chmods anyone could easily remove your data. That didn't apply to Windows users which accessed the same nfs mount using a different user id :) -- WBR, Andrew signature.asc Description: PGP signature
Re: /tmp as tmpfs and consequence for imaging software
Hello, On Mon, 14 Nov 2011 00:14:18 +0100 Josselin Mouette j...@debian.org wrote: No it does not work like you said. We know the matrix structure, not the kernel. We map and unmap manually. Doing as you said is inneficient and trash a lot cache and so on. This is getting insane. Please learn how to use madvise and posix_fadvise and let the kernel deal with paging. The kernel knows everything about the underlying hardware; the application does not. And what about the software being cross-platform? What about other systems which don't have such system calls? Also, the application doesn't need to know anything about the hardware except that disk memory is usually larger and slower than RAM is. -- WBR, Andrew signature.asc Description: PGP signature
important changes in ifupdown 0.7~beta2
Hello, Few moments ago ifupdown 0.7~beta2 entered experimental. This release, amongst others, fixes this bug: http://bugs.debian.org/477650. The change makes ifupdown to put interfaces down in the reverse order that they were brought up. If your /e/n/interfaces file relies on the behaviour of ifupdown in this regard, please consider changing your configuration. Second change may be important for maintainers of other packages using /e/n/if-*.d hook system. Before 0.7~beta2, commands specified in /e/n/interfaces were always executed before the scripts placed in the directories in question. Now, on ifdown, scripts are called first, and then user-configured options from /e/n/interfaces are executed. Please consider this if you package or system depends on the order of execution. Third thing is that now it is possible for ifdown to detect a running instance of ifup for the same interface and terminate it; in fact, that's actually done. Also, any processes started by ifup will be killed as well. Please test and report any bugs you find. Thanks. -- WBR, Andrew signature.asc Description: PGP signature
