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
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
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
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: 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
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: 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: 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
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: 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
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
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
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
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
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: 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: 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
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: 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#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: 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
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: 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: 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: [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: 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: 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: 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: 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 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: 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: 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: 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: 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: 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: 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: 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
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: 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
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: 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: 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: 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: [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
Re: Doing an anonymous git clone from bitbucket: is it possible?
Hello, On Sun, 10 Mar 2013 18:27:33 +0800 Thomas Goirand z...@debian.org wrote: Is it possible to do an *anonymous* clone of a bitbucket repository using git? I saw it is possible to do a clone over ssh, but that's not what I want to do (ssh client asks for confirming the remote ssh host key, which I don't want to, I just want upstream source code so that I can put that in ./debian/rules get-vcs-source...). I've searched, and searched the web again, and didn't find out. :( Question one: why can't you just use hg to clone it? Also, you can download a tarball directly from bitbucket, they do hg export on the server side. Question two: why not use https? -- WBR, Andrew signature.asc Description: PGP signature
Re: git-remote-hg/bzr (was: Doing an anonymous git clone from bitbucket: is it possible?)
Hello, On Sun, 10 Mar 2013 12:15:27 +0100 Axel Beckert a...@debian.org wrote: I think so. The used concept and architecture seems superior to any external tools of which we have a few in Debian already: git-bzr-ng - bi-directional git to bzr bridge: never fear bzr again tailor - migrate changesets between version control systems mercurial-git - Git plugin for Mercurial Hg-Git is also bidirectional. Yet it creates a local hg clone next to the git clone. -- WBR, Andrew signature.asc Description: PGP signature
Bug#702745: ITP: pkgconf -- a pkg-config replacement
Package: wnpp Severity: wishlist Owner: Andrew Shadura bugzi...@tut.by * Package name: pkgconf Version : 0.8.12 Upstream authors: Baptiste Daroussin b...@freebsd.org Jeff Horelick jdh...@gentoo.org Michał Górny mgo...@gentoo.org William Pitcock neno...@atheme.org * URL : https://github.com/pkgconf/pkgconf * License : ISC Programming Lang: C Description : a pkg-config replacement pkgconf is a replacement for pkg-config, a system for managing library compile and link flags that works with automake and autoconf. . As far as it's known to date, pkgconf is compatible with all known variations of this macro. pkgconf detects at runtime whether or not it was started as 'pkg-config', and if so, attempts to set program options such that its behaviour is similar. . pkgconf builds an acyclic directed dependency graph. This allows for the user to more conservatively link their binaries — which may be helpful in some environments, such as when prelink(1) is being used. As a result of building a directed dependency graph designed for the specific problem domain provided by the user, more accurate dependencies can be determined. pkg-config, on the other hand builds a database of all known pkg-config files on the system before attempting to resolve dependencies, which is a considerably slower and less efficient design. . pkgconf does not bundle any third-party libraries or depend on any third-party libraries. -- 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/20130310232056.31192.56777.reportbug@localhost.localdomain
Re: Public service announcement about dependencies on gawk
Hello, On Mon, 18 Mar 2013 23:23:45 + brian m. carlson sand...@crustytoothpaste.net wrote: I've seen a lot of cases over the years of packages depending on gawk that do not need it. If you only need a standard nawk (new awk), you do not need to depend on gawk. mawk is smaller and faster and sufficient for almost all needs, and the existence of some awk on the system is guaranteed by base-files. Well, as far as I know, mawk has some sort of terrible UTF-8 support, so it's a no way for many applications. -- WBR, Andrew signature.asc Description: PGP signature
Re: Public service announcement about dependencies on gawk
Hello,
On Tue, 19 Mar 2013 23:44:22 +
brian m. carlson sand...@crustytoothpaste.net wrote:
Well, as far as I know, mawk has some sort of terrible UTF-8
support, so it's a no way for many applications.
Could you please explain? And if you haven't filed a bug report,
could you please do so? Searching Google, the only UTF-8-related
bugs I found are bugs mandated by POSIX (and one that updating mawk
to 1.3.4 would fix).
$ echo привет | mawk '{ print length($0) }'
12
$ echo привет | gawk '{ print length($0) }'
6
$ echo привет | mawk '{ printf substr($0, 1, 1) }' | hd
d0|.|
0001
I don't think it's mandated by POSIX (or is it?). Anyway, it's obviously
not what most of the applications want.
Also, my original post was inspired by the fact that most packages
depending on gawk invoke awk as their binary. In that case, the
dependency is wrong and unnecessary.
I just always put #!/usr/bin/gawk -f in the beginning of the file and
declare an explicit dependency on gawk. And also, I don't support
running those scriptf on broken awk implementations.
--
WBR, Andrew
signature.asc
Description: PGP signature
Re: Bug#703507: ITP: re2 -- fast, safe C++ regular expression library
Hello, On 20 March 2013 13:38, Adam D. Barratt a...@adam-barratt.org.uk wrote: This appears to have been in the archive for a couple of years already - http://packages.qa.debian.org/r/re2.html I wonder why is it still in experimental. Maybe it's worth re-uploading it to unstable? -- 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-mayutf0kuasjybwdughdjlqhc0w3se6k3_rtj8c-jxb...@mail.gmail.com
Re: packaging PostBooks (business accounting/CRM/ERP)
Hello, On Thu, 21 Mar 2013 21:36:04 +0100 Daniel Pocock dan...@pocock.com.au wrote: On the technical side, I found the project quite confusing at first because although it is open source, it is not conveniently distributed as a single source tarball, I had to build from SVN - and there are a dozen different SVN repos[3] relating to the project, which is itself slightly confusing. Once you know which repos to check out, it actually builds and runs very smoothly using the qt and postgres dependencies in Debian squeeze - all the notes about my experience with it so far in the ITP bug[4] It would also be useful for me to know which other accounting packages are popular in the free software community and whether people would use PostBooks if it was packaged. I tried GnuCash, but it seems more like the most basic version of Quickbooks or Microsoft Money. PostBooks genuinely offers many of the `Pro' features of QuickBooks or Sage, but appears a lot less complicated than a fully customizable solution like Adempiere, so I definitely think this fills a gap. Daniel, I have almost finished packaging Postbooks. The packages aren't yet in good shape and need some clean-up and fixing, and I'm waiting for response from upstream to fix some of those issues. They seem to be very interested in doing that, so I hope we'll do some progress in that. -- WBR, Andrew signature.asc Description: PGP signature
Re: packaging PostBooks (business accounting/CRM/ERP)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello, On Fri, 22 Mar 2013 00:09:20 +0100 Daniel Pocock dan...@pocock.com.au wrote: Would you be able to take over the ITP bug I created? Then you will be the one closing it when you upload. I did a search for any ITP bug before I filed one myself, but I'm quite happy to test your packages instead of making my own. Are they tracked in git somewhere? The sources are hg-tracked actually, but not in public yet. 90%-ready is now package for openrpt, there are just minor issues with it; xtuple package has more of them, and it's not easy to resolve them without upstream, and somehow they're a bit slow. If I have time I will put what I have on-line very soon. - -- WBR, Andrew -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQIcBAEBCAAGBQJRS5UwAAoJEG6k0jEaLSaNaHcP/2/meUqP8haqzxkGbUNtqQUM TB8e31MlsWtWv1EZgKPOlBnL7t+4BSLDx+sXsq2lMzS1NHqKJD3jxHE+j01kZyAj hFZqH5KtwSHt2lLj/2d+8R12CVhFR58Ge5L+adPaB0rG9vi0DCk/IRXkfiQYH1JY xIcHLgdNfgf55y8PzdrX6r3Kt4rpiE8/nhqeu07IDFM0KrY/P6jf6l2my8HXXamW XKkcaBBW3rlCpDLIqlu9C36QYXt3cyJuBO/oMyvPf+2+6QTmXK3c/wqg3zpCq/G5 CtfsIvXMsGc0q3f94ZBzMAkmnY7UzQkMwnBa4BreTn9sqhyBtLePQqudH8T3EUU/ WF21+wM5/ZEuUXDYUUwjxaxWV4itHiL3JqXv63FaNuwosCvzngFFv877EScWFZUf WUbXwdwVAWxUqEqJQ+ot9fNXZJmEqr7SmNW1BTuwGkLBVa/z4fkLYgwEG44d3q9K xh1RRDdrXUzGZ/xlwgM7rbIWaWG1pN/lazXcykx4mIneSDbnOJ1esuSstOPI5RlZ csCaFOIo11AvhYyI2TajNYckcpKHS5JxxRd+bHMcjwiQu9J8GFUCPFL8PslhhnvO RQ8EEvn3FPl40mo0DHf5GyzTJkHyCYFwRHaRvxiu+JbRwS4eDOPD72jGe7M5sDXg QH9e1BmX39e0yZYqfkjC =4l58 -END PGP SIGNATURE-
Re: [PATCH] netplug - Allow to specify custom script file via param '-s'
Hello,
Brian, could you please clarify the state of the upstream development?
(See below.)
On Sat, 23 Mar 2013 08:58:20 +0100
Philipp Matthias Hahn pmh...@pmhahn.de wrote:
On Fri, Mar 22, 2013 at 07:55:56AM +0100, Raphael Hertzog wrote:
There is: you can use experimental to continue working on the
package until the wheezy release. Or you can accumulate stuff in
the VCS.
I know.
So your patch will just stay in the BTS until I find some time to
work the netplug again, which is very low on my current priority
list.
It's not a very rewarding answer to someone who invested time in
your package...
When I am in a similar situation, I tend to offer the person to
join as co-maintainer. The patch is not very long and it should not
be too hard to review. Or you can redirect him towards upstream if
that's better.
Upstream is dead: http://hg.serpentine.com/netplug 2010-06-26
So basically I would need to maintain that patch ad infinitum.
And currently I don't have the time to become a new upstream, so my
rather harsh reply.
--
WBR, Andrew
diff -r aaebd52fac19 lib.c
--- a/lib.c Sat Jun 26 09:36:45 2010 -0700
+++ b/lib.c Sat Mar 02 02:38:19 2013 +0100
@@ -29,6 +29,7 @@
#include netplug.h
+const char *script_file = NP_SCRIPT_DIR /netplug;
void
do_log(int pri, const char *fmt, ...)
@@ -109,11 +110,11 @@
setpgrp(); /* become group leader */
do_log(LOG_INFO, %s %s %s - pid %d,
- NP_SCRIPT, ifname, action, getpid());
+ script_file, ifname, action, getpid());
-execl(NP_SCRIPT, NP_SCRIPT, ifname, action, NULL);
+execl(script_file, script_file, ifname, action, NULL);
-do_log(LOG_ERR, NP_SCRIPT : %m);
+do_log(LOG_ERR, %s: %m, script_file);
exit(1);
}
diff -r aaebd52fac19 main.c
--- a/main.c Sat Jun 26 09:36:45 2010 -0700
+++ b/main.c Sat Mar 02 02:38:19 2013 +0100
@@ -91,7 +91,7 @@
static void
usage(char *progname, int exitcode)
{
-fprintf(stderr, Usage: %s [-DFP] [-c config-file] [-i interface] [-p pid-file]\n,
+fprintf(stderr, Usage: %s [-DFP] [-c config-file] [-s script-file] [-i interface] [-p pid-file]\n,
progname);
fprintf(stderr, \t-D\t\t
@@ -102,6 +102,8 @@
do not autoprobe for interfaces (use with care)\n);
fprintf(stderr, \t-c config_file\t
read interface patterns from this config file\n);
+fprintf(stderr, \t-s script_file\t
+script file for probing interfaces, bringing them up or down\n);
fprintf(stderr, \t-i interface\t
only handle interfaces matching this pattern\n);
fprintf(stderr, \t-p pid_file\t
@@ -219,7 +221,7 @@
int probe = 1;
int c;
-while ((c = getopt(argc, argv, DFPc:hi:p:)) != EOF) {
+while ((c = getopt(argc, argv, DFPc:s:hi:p:)) != EOF) {
switch (c) {
case 'D':
debug = 1;
@@ -234,6 +236,9 @@
read_config(optarg);
cfg_read = 1;
break;
+case 's':
+script_file = optarg;
+break;
case 'h':
fprintf(stderr, netplugd version %s\n, NP_VERSION);
usage(argv[0], 0);
diff -r aaebd52fac19 man/man8/netplugd.8
--- a/man/man8/netplugd.8 Sat Jun 26 09:36:45 2010 -0700
+++ b/man/man8/netplugd.8 Sat Mar 02 02:38:19 2013 +0100
@@ -19,6 +19,7 @@
.Nm netplugd
.Op Fl FP
.Op Fl c Ar config_file
+.Op Fl s Ar script_file
.Op Fl i Ar interface_pattern
.Op Fl p Ar pid_file
.\
@@ -117,6 +118,9 @@
.Pa /dev/null
as a config file.
.\
+.It Fl s Ar script_file
+Specify an alternative script file path, override /etc/netplug.d/netplug
+.\
.It Fl i Ar interface_pattern
Specify a pattern that will be used to match interface names that
.Nm
diff -r aaebd52fac19 netplug.h
--- a/netplug.h Sat Jun 26 09:36:45 2010 -0700
+++ b/netplug.h Sat Mar 02 02:38:19 2013 +0100
@@ -26,8 +26,6 @@
#include linux/netlink.h
#include linux/rtnetlink.h
-#define NP_SCRIPT NP_SCRIPT_DIR /netplug
-
/* configuration */
void read_config(char *filename);
@@ -37,6 +35,8 @@
void probe_interfaces(void);
void close_on_exec(int fd);
+extern const char *script_file;
+
extern int debug;
/* netlink interfacing */
signature.asc
Description: PGP signature
Re: [PATCH] netplug - Allow to specify custom script file via param '-s'
Hello, On Wed, 27 Mar 2013 12:08:20 +0100 Pali Rohár pali.ro...@gmail.com wrote: So is my patch totally ignored? I sent it to upstream maintainer, next to debian mailinglist, attached to debian bug tracking system, sent to ubuntu mailinglist and also to launchpad ubuntu bug tracker. And nobody reviewed it until now... So where should be patches sent for review and for inclusion to system? I contacted upstream few days ago on IRC; it seems he's rather busy now. I think you need to wait for a while :) -- WBR, Andrew signature.asc Description: PGP signature
Re: Bug#705015: ITP: ie7-js -- help Internet Explorer behave like a standards-compliant browser
Hello, On Mon, 08 Apr 2013 21:29:21 +0200 John Paul Adrian Glaubitz glaub...@physik.fu-berlin.de wrote: On 04/08/2013 09:23 PM, David Prévot wrote: The purpose would be to provide it, via a libjs-ie7, in order to be used as a third party in other packages like spip. As such, I intend to maintain it under the Debian Javascript umbrella. And how would I use it on Debian when there is no Internet Explorer 7 available for non-Windows platforms? Wine? It's a shim. You provide the support for the missing features right on your website. When a user loads a page in IE7, this JavaScript detects this and enables replacement implementations of those things. Same as jQuery gives you a $ function, but here it's about redefining or overlaying existing features. -- WBR, Andrew signature.asc Description: PGP signature
Bug#705324: ITP: alacarte -- tile renderer for OpenStreetMap using Cairo and MapCSS
Package: wnpp Severity: wishlist Owner: Andrew Shadura andre...@debian.org * Package name: alacarte Version : 0.2.1 Upstream Author : Institut für Theoretische Informatik et al. * URL : http://github.com/alacarte-maps/alacarte/ * License : AGPL-3+ Programming Lang: C++11 Description : tile renderer for OpenStreetMap using Cairo and MapCSS alaCarte is a tile renderer for OpenStreetMap data written in C++11, using Cairo for rendering and Boost-Spirit for MapCSS parsing. . The rendered tiles are served over HTTP using the Slippy map tilenames convention. To compute which data is needed for rendering a tile, alaCarte uses a variant of a kd-Tree. . alaCarte was designed with medium dataset size in mind. On a typical machine with at leat 8GB RAM, alaCarte can handle a unfiltered export from the federal state of Baden-Wuerttemberg (Germany). . Features: * easy to use * most MapCSS attributes are implemented * no need to filter OSM exports, you have full access to all attributes at runtime * stylesheets are updated at runtime (changes are detected automatically) * tiles can be rendered in groups (meta tile) to speed up rendering P.S. The package is ready and working, but I think to wait a little bit until the upstream does the next release — I'm packaging from Git currently. -- 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/20130413055654.4123.18914.reportbug@localhost.localdomain
Re: Bug#705324: ITP: alacarte -- tile renderer for OpenStreetMap using Cairo and MapCSS
Hello, On 15 April 2013 12:56, Simon McVittie s...@debian.org wrote: On 13/04/13 07:22, Cyril Brulebois wrote: * Package name: alacarte alacarte | 0.13.2-1 |stable | source, all ... which is the (unrelated) GNOME menu editor. Call this new thing alacarte-maps after its github username, perhaps? Well, I don't quite understand why third person comments on this; I've replied to Vincent right after he pointed out the name is already taken; when KiBi told me the same thing, I've retitled the bug. Meanwhile, still this post attracts people. Why? -- 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-may5g+wm06v+cgooxj2jql+fu8m-fjvv9pa8mzsnncy...@mail.gmail.com
Re: Bug#705324: ITP: alacarte -- tile renderer for OpenStreetMap using Cairo and MapCSS
Hello, On 15 April 2013 13:30, Andrew Shadura bugzi...@tut.by wrote: Well, I don't quite understand why third person comments on this; I've replied to Vincent right after he pointed out the name is already taken; when KiBi told me the same thing, I've retitled the bug. Meanwhile, still this post attracts people. Why? Ah, I see; that mail didn't go to the debian-devel@. It's here, however: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=705324 -- 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-mAy=ctwBWDCR9v40jRXVnEDQtLo57K=zesd_tdmamn+...@mail.gmail.com
Re: multiarch and interpreters/runtimes
Hello, On 18 April 2013 16:41, Matthias Klose d...@debian.org wrote: - Tcl/Tk: Wookey and Dimitrij did start on that in Ubuntu, patches are available in Debian bug reports. Currently the shared libraries are split out into separate packages, and are co-installable. Not yet tested if this enough to run an embedded interpreter. Could I please have more info? :) -- 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-mAxnn=_vPXzPL2qvsKqM4kDMUOEZukF=xjg6c5kmms_...@mail.gmail.com
Re: multiarch and interpreters/runtimes
Hello, On Thu, 18 Apr 2013 16:07:44 +0100 Dmitrijs Ledkovs x...@debian.org wrote: On 18 April 2013 16:41, Matthias Klose d...@debian.org wrote: - Tcl/Tk: Wookey and Dimitrij did start on that in Ubuntu, patches are available in Debian bug reports. Currently the shared libraries are split out into separate packages, and are co-installable. Not yet tested if this enough to run an embedded interpreter. Could I please have more info? :) Well there are patches to move .so libraries from /usr/lib/tk8.*/ to /usr/lib/$(MULTIARCH)/tk8.*, same for tcl and matching tcltk-defaults package to have similar symlinks everywhere. And basically mark that package with .so's as multiarch:same. The interpreter packages are still not marked multi-arch anything. And as doko said, there wasn't anything else done e.g. test embedded interpreter use-case. By the way, have you contacted Sergei on this? Personally, I'm not yet convinced about this interpreter multiarchification, but hey Debian is a Universal OS ;-) and I don't see any reason to not do this. Well, it may make sense, but really there will be not many people running foreign interpreters at all, in my opinion. Is there a wiki page on Tcl/Tk multiarchification? To Sergei (added to Cc): I'd like to join the effort in packaging Tcl/Tk and stuff, as I said before; but as you've been the most active person on the team for quite some time I'm a bit hesitant about interrupting the process by committing things :) I guess, we need some co-ordination; also, in my opinion, the mailing list needs revival. -- WBR, Andrew signature.asc Description: PGP signature
Re: multiarch and interpreters/runtimes
Hello, On Thu, 18 Apr 2013 22:13:04 +0400 Sergei Golovan sgolo...@debian.org wrote: To Sergei (added to Cc): I'd like to join the effort in packaging Tcl/Tk and stuff, as I said before; but as you've been the most active person on the team for quite some time I'm a bit hesitant about interrupting the process by committing things :) I guess, we need some co-ordination; also, in my opinion, the mailing list needs revival. There's pkg-tcltk-de...@lists.alioth.debian.org mailing list for that. I know that, which is exactly why I said the above. The list seems to be overspammed, and there's very little communication going on there, unfortunately. -- WBR, Andrew signature.asc Description: PGP signature
Re: Bug#709237: ITP: meta-suckless-tools -- meta-package installs simple commands for minimalistic window managers
Hello, On Wed, 22 May 2013 00:11:20 +0400 Dmitry Papchenkoff dmitry.papchenk...@gmail.com wrote: 10 packages, excluding metapackage. This work was originally done for test-packages for mentors.debian.net as an effort to update and clean up suckless-tools. But after posting packages to mentors I was requested to make ITP-bugs for it. So, I'll post ITP just for two packages and wait if maintainer or other users find it useful (if any) I strongly disagree with this proposed split. The package is already too small for that. This split just adds unnecessary complexity and bloats the package manager lists, and also confuses users. Please don't. -- WBR, Andrew signature.asc Description: PGP signature
Re: Bwaaaaah I will tell my daddy^W^Wthe CTTE^W^Wa GR
Hello, On Wed, 22 May 2013 23:05:01 +0200 Josselin Mouette j...@debian.org wrote: Subject: Bwah I will tell my daddy^W^Wthe CTTE^W^Wa GR Couldn't you please finally stop behaving like a five years old? -- WBR, Andrew signature.asc Description: PGP signature
Re: Bug#717785: ITP: python-termcolor -- ANSII Color formatting for output in terminal
Hello, On Thu, 25 Jul 2013 13:29:14 +0800 Thomas Goirand z...@debian.org wrote: Description : ANSII Color formatting for output in terminal So, ANSI or ASCII? :) -- WBR, Andrew signature.asc Description: PGP signature
Re: [Debian-uk] Mini-Debconf in Cambridge, UK - November 14-17 2013
Hi, On 16 August 2013 15:23, Paul Mellors prjmell...@gmail.com wrote: I'm organising a mini-conf in Cambridge for November this year. My employer ARM has graciously volunteered to host people for 4 days for a mix of sprint sessions and talks: For more details and to sign up to attend, please visit the wiki page at https://wiki.debconf.org/wiki/Miniconf-UK/2013 I look forwards to seeing lots of you in November! Should I book my flight already? :) -- 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/cacujmdpzced8jyw--iojdar6h_qwjf3ooehgq6az-zvrtbz...@mail.gmail.com
Re: Bug#720518: ITP: tdbcpostgres -- Postgresql driver for the TDBC datatabase connectivity
Hello, On 23 August 2013 00:30, Massimo Manghi mxman...@apache.org wrote: * Package name: tdbcpostgres Version : 1.0.0 Upstream Author : mxman...@apache.org * URL : http://tdbc.tcl.tk/ * License : BSD Programming Lang: (C,Tcl) Description : Postgresql driver for the TDBC datatabase connectivity I think you need to rename the package according to the Tcl packaging policy, just as you did with the SQLite backend. -- 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/cacujmdodb1trvjzzfvkcwd11pvkb4qc5xpva3tj20ggxczv...@mail.gmail.com
Re: Bug#720518: ITP: tdbcpostgres -- Postgresql driver for the TDBC datatabase connectivity
Hello, On 23 August 2013 13:01, Massimo Manghi mxman...@apache.org wrote: I decided to call the package after the source package name. This package is eventually generating tcl8.x binary packages that follow the policy. In future it might happen that multiple binary packages for binary incompatible Tcl versions have to be released. Yes, that's what I meant. -- 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/CACujMDMquUFJ0ME=+a3rcudyqfw+deadpjt_jupfftu8sja...@mail.gmail.com
Re: Upcoming changes in Tcl/Tk packaging
Hello, On Sep 25, 2013 11:40 AM, Matthias Klose d...@debian.org wrote: Am 25.09.2013 10:25, schrieb Sergei Golovan: removing alternatives a lot. But later I'd like to have another transition (switching to 8.6 as default Tcl/Tk version). Do you have numbers what will break with 8.6? Not many things. I'm aware of one package, but that's a bug in it, I just can't find enough time to patch it. In general Tcl/Tk upstream is very careful about changes, and it's very rare that compatibility breaks. Even ABI is kept very stable so usually you can use binary extensions from old Tcl versions with new ones.
Re: Upcoming changes in Tcl/Tk packaging
Hello, On 25 September 2013 14:52, Sergei Golovan sgolo...@nes.ru wrote: There are about 30 packages left which unconditionally depend on tcl8.4 or tk8.4. We have to do some research and find how to port them to 8.5 or 8.6. When I have some free time, I occasionally port this or that package. Actually, I've created this page: https://wiki.debian.org/ReleaseGoals/UpgradeTcl and propose it as a release goal. -- 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/cacujmdnqgyb+qa7yny6a-t98t-vxfzoccuhkbpotojvqyd9...@mail.gmail.com
Re: Removing old unmaintained X drivers
Hello, On Thu, 26 Sep 2013 23:26:22 +0200 Julien Cristau jcris...@debian.org wrote: xserver-xorg-video-s3 I'd vote for this one, but I can't maintain it, unfortunately. -- WBR, Andrew signature.asc Description: PGP signature
Re: how do deal with versionless mercurial software ?
Hi, On 2 October 2013 17:27, Dominique Dumont d...@debian.org wrote: If you deem it unlikely that two commits are made in the same day (which happens all the time), how likely is it that upstream switches VCSs and does an important commit on the same day? that's not the issue. Try that: dpkg --compare-versions 1.hg2012 '=' 1.git2013 || echo 'false' Weren't we talking about 0~20131002.hg2efc4fcd vs 0~20131002.git67ed491a? -- 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/cacujmdnhtmpsh7f3gcqnbc90vtab2zlholda5j-82f2gsez...@mail.gmail.com
Re: Proposal: s have a GR about the init system
Hello, On Oct 26, 2013 7:15 AM, Uoti Urpala uoti.urp...@pp1.inet.fi wrote: I am no longer willing to assume that Steve Langasek would act in good faith in evaluating init systems; he has posted false claims about systemd too many times for me to believe they would all be honest mistakes, and has posted what has clearly been deliberate FUD. This independently of and in addition to any conflict of interest. He hasn't done so, you lie. Therefore I think your arguments should be disregarded. -- WBR, Andrew
Re: [PATCH] netplug - Allow to specify custom script file via param '-s'
Hello, On Thu, 7 Nov 2013 22:37:01 +0100 Pali Rohár pali.ro...@gmail.com wrote: Ok, here is info: Months ago I sent patch for package netplug to ML. Someody wrote that I should send it to bugtracker. So I posted it to [1]. I also sent that patch also to upstream project, but no response. Even no response from Debian package maintainer. Also bug page is without comments. Every month I send email to ML to this thread, asking for state. But still nobody wrote me if patch can be accepted or is definitely rejected. I would like to know state and what happening and if I need to provide something more... Or just Debian ignoring developers? From my point of view it looks like. That happens sometimes. I never got a response from Anthony J. Town regarding ifupdown, while I was certain he's on-line quite often (he did even post something here few times). At the end, I took it over completely. -- WBR, Andrew signature.asc Description: PGP signature
Re: Cross-directory hard links in Debian packages
Hello, On Wed, 13 Nov 2013 10:19:17 +0100 Helmut Grohne hel...@subdivi.de wrote: The tar file format supports hard links. Thus technically Debian packages can contain hard links. A significant number of packages including key packages such as bzip2, gzip, and ifupdown use this technique. While same-directory hard links are an established practise, the same is not so true for cross-directory hard links. Isn't there a mistake? I can't remember having hard links in ifupdown. -- Cheers, Andrew signature.asc Description: PGP signature
Re: Cross-directory hard links in Debian packages
Hello, On Fri, 15 Nov 2013 13:42:18 +0100 Andrew Shadura and...@shadura.me wrote: The tar file format supports hard links. Thus technically Debian packages can contain hard links. A significant number of packages including key packages such as bzip2, gzip, and ifupdown use this technique. While same-directory hard links are an established practise, the same is not so true for cross-directory hard links. Isn't there a mistake? I can't remember having hard links in ifupdown. Huh, it seems you're right. Upon inspection, I've noticed ifdown is hardlinked with ifup, and I have not a slightest idea why, as it was supposed to be a symlink. -- Cheers, Andrew signature.asc Description: PGP signature
Bug#729736: ITP: inputplug -- XInput event monitor
Package: wnpp Severity: wishlist Owner: Andrew Shadura andre...@debian.org * Package name: inputplug Version : 0.0~hg Upstream Author : Andrew Shadura andre...@debian.org * URL : https://bitbucket.org/andrew_shadoura/inputplug/ * License : MIT/X11 Programming Lang: C Description : XInput event monitor inputplug is a daemon which connects to a running X server and monitors its XInput hierarchy change events. Such events arrive when a device being attached or removed, enabled or disabled etc. When a hierarchy change happens, inputplug parses the event notification structure, and calls some command. inputplug may be useful when input devices are being reconnected frequently and need frequent manual reconfiguration. For example, some laptops detach their keyboards when going to memory sleep, so if some keys need remapping, or a custom keyboard layout is used, running xkbcomp/xmodmap is required after returning from sleep. Same applies to some touchpads if non-standard configuration is used. P.S. The above isn't quite what is going to be in the long package description; however, as I suppose I'm not the only person to hit this sort of issues, this ITP may serve as some sort of notification that the solution exists :) P.P.S. Bug reports are welcomed. -- 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/20131116140803.8360.25541.reportbug@localhost.localdomain
Re: Better pdiff handling for apt
Hello, On Sat, 4 Jan 2014 20:40:34 +0800 Anthony Towns a...@erisian.com.au wrote: Salut tout le monde, Some time ago (*cough* 2009), I had a play with working out how to apply pdiffs more efficiently than apt currently does, and implemented a proof of concept in python [0]. There weren't any replies (even a ooo, cool) when I posted to the deity list, so I left it at that; though trolling google now, I see that it got mentioned on -devel [1] not all that long ago (*cough* 2012), so apparently it did get read after all. Not that it looks like it would've done much good, because it seems like the script I put on the web, and the one I was actually using are completely different to the extent that the one on the web even has syntax errors. WTF? ooo, cool :-) Having better pdiffs handling would really help! P.S. Wait, what? Real Anthony J Towns? :) -- Cheers, Andrew signature.asc Description: PGP signature
Bug#735917: ITP: stm32flash -- software for programming STM32 chips using serial bootloader
Package: wnpp Severity: wishlist Owner: Andrew Shadura andre...@debian.org * Package name: stm32flash Version : 0.3~beta2 Upstream Author : Geoffrey McRae, Tormod Volden and others * URL : https://code.google.com/p/stm32flash/ * License : GPL-2+ Programming Lang: C Description : software for programming STM32 chips using serial bootloader stm32flash is a flashing program for the STM32 ARM processors using the ST serial bootloader. Features: * device identification * write to flash/RAM * read from flash/RAM * auto-detect Intel hex or raw binary input format with option to force binary * flash from binary file * save flash to binary file * verify retry up to N times on failed writes * start execution at specified address * software reset the device when finished if -g not specified * resume already initialized connection (for when reset fails) -- 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/20140118154137.8330.21624.reportbug@localhost.localdomain
