Bug#306226: ITP: avinfo -- Audio/Video information automatic extractor / file list generator
Package: wnpp Severity: wishlist Owner: Stanislav Maslovski <[EMAIL PROTECTED]> * Package name: avinfo Version : 1.0.a15 Upstream Author : George Shuklin <[EMAIL PROTECTED]> * URL : http://shounen.ru/soft/avinfo/ * License : GPL Description : Audio/Video information automatic extractor / file list generator AVInfo is a powerful tool for extracting practically any useful information from a collection of your multimedia files. It works with many different file formats including most popular ones as AVI, OGG, OGM, MPEG, and MKV. All the file scanning code has been implemented from scratch. AVInfo does not rely on any external libraries to do this job and has been written in pure C. Due to that it is fast and efficient. It has a built-in scripting language called A.S.S. (AVInfo Simple Script) that is used in templates which control the output of the program. It is a "must have" tool for anyone with a huge number of multimedia files on her/his hard drives. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.4.29 Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Is there a need for /usr/lib64/ on a pure i386?
Hello d-dev, I noticed yesterday that after an upgrade I got a /usr/lib64 dir with some (not neded) stuff in it. I am not running any 64 bit arch. $ dpkg -S /usr/lib64 # says: libg2c0-dev, fakeroot, libgfortran1-dev: /usr/lib64 I have found that there is a bug [1] on fakeroot reporting the same. The question is: will it become a common practice that packages for i386 will include 64-bit libraries? After reading the reply of Clint Adams on [1] I have got such an impression. Please correct me if I am wrong. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=344104 -- Станислав
Re: On including 64-bit libs in 32-bit packages (see #344104)
On Sat, Oct 21, 2006 at 03:18:45PM -0600, Bruce Sass wrote: > On Sat October 21 2006 13:35, Darren Salt wrote: > > I demand that Hendrik Sattler may or may not have written... > > > 64bit kernels are not available in the i386 archive. That makes the > > > 64bit libs rather useless, doesn't it? > > > > No - you could be using a locally-built 64-bit kernel. > > Perhaps i386 needs something along the lines of localepurge for 64bit > stuff. Yup, I had a similar idea. -- Станислав
Re: Debian desktop -situation, proposals for discussion and change. Users point of view.
On Thu, May 17, 2007 at 08:20:50AM +0200, Mgr. Peter Tuharsky wrote: > Steve, > > >And as others have pointed out, the purpose of stable is to minimize > >disruptions. For many users, living with known bugs with known workarounds > >is a *lot* better than identifying new bugs. > > Yeas. Let the choice to the user. Don't dictate him. Well, I really cannot see your point. If you do not like how stable is done at the moment in Debian, but do like how it is done in whatever other distro - use that distro. Nobody forces anything on you. This is all about choice. > Whoever wants to > use the old software w/o change, let be it. Whoever wants the new one, > noticed about the risks, let's give him an official and supported way to > do it. Fist of all, there is such a way: use testing, most of the time it is fairly safe to use. Learn how to put packages on hold and how to get back if something goes wrong. [ skipped ] > Let the users choose, whether they want to upgrade. =) OMG, I do not think that somebody really forces me when to run apt-get upgrade and what packages to install and from what repository. > Repeat, let there be easy downgrade option for the case things don't > work as expected. man sources.list man apt_preferences http://snapshot.debian.net/ If you maintain more than one machine - setup a local repository and fill it with the versions of the packages you like. Including backported ones, learn how to backport. -- Stanislav -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian desktop -situation, proposals for discussion and change. Users point of view.
On Thu, May 17, 2007 at 09:12:18AM +0200, Mgr. Peter Tuharsky wrote: > Steve, > > > I see main problem with testing that broad platform changes are going > there. That's why things break sometimes there. > > That's why I think, that the Stable platform with new desktop software > might be the choice -the new software versions with no platform > dependecies breakage risk. > > This is closest to "backports" and "volatile" idea. I wouldn't call it > "backports" however, because that reminds porting some very new software > to some very old platform, and this is not the case. The stable's basic > platform should stay LSB-compliant and "moderately-aged" (supported by > all main software vendors) for the whole length of release cycle. Thus > the new versions of desktop software wouldn't be "backported"; just > compiled against ordinary, stable platform. This sounds more rational. Yes, the megafreeze model that Debian uses at the moment has certain drawbacks. However, my experience shows that currently it is the best one can get out of the free distros at the moment (with regard to stability), IMO. And I choose for stability. A base system (required utils + services + libs, 0 RC bugs) + script based automatic building/backporting system, similar to that used in "testing", could be an option. This was discussed, i believe, many times in the past. -- Stanislav -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian desktop -situation, proposals for discussion and change. Users point of view.
On Thu, May 17, 2007 at 09:20:48AM +0200, Mgr. Peter Tuharsky wrote: > Stanislav, > > > I see Your point, however this is far from "user-friendliness". > > First solution -use other distro. Wow, what a great idea. Looking at > statistics and Linux users in neighborhood, You can be _sure_ they > discovered that way already :-) Well, I think this is for the best. > Be also sure, that unwilling to do more for desktop users, Debian will > not be less, but increasingly more server-oriented distro (I like Debian > on server!). I like Debian either. Debian will remain Debian ;) I really hope for it. Please, do not go for the stupid race over the so-called average (read not willing to learn) user. -- Stanislav -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#492548: ITP: avinfo -- Audio/Video information automatic extractor/file list generator
Package: wnpp Severity: wishlist Owner: Stanislav Maslovski <[EMAIL PROTECTED]> * Package name: avinfo Version : 1.0.a16 Upstream Author : George Shuklin <[EMAIL PROTECTED]> * URL : http://shounen.ru/soft/avinfo/ * License : GPL Programming Lang: C Description : Audio/Video information automatic extractor/file list generator AVInfo is a powerful tool for extracting practically any useful information from a collection of your multimedia files. It works with many different file formats including most popular ones as AVI, OGG, OGM, MPEG, and MKV. All the file scanning code has been implemented from scratch. AVInfo does not rely on any external libraries to do this job and has been written in pure C. Due to that it is fast and efficient. It has a built-in scripting language called A.S.S. (AVInfo Simple Script) that is used in templates which control the output of the program. It is a "must have" tool for anyone with a huge number of multimedia files on her/his hard drives. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#493593: ITP: cdde -- CD Detect & Execute utility
Package: wnpp Severity: wishlist Owner: Stanislav Maslovski <[EMAIL PROTECTED]> * Package name: cdde Version : 0.2.0 Upstream Author : Eric Lathrop <[EMAIL PROTECTED]> * URL : http://ericlathrop.com/cdde/ * License : GPL Programming Lang: C Description : CD Detect & Execute utility CDDE is a program that detects when a CD/DVD-ROM drive has a disc inserted. When it finds a disc inserted in the drive it will attempt to determine the type of the disc, and execute a specified command. This means a DVD can be inserted and your favorite DVD software will start, or a data CD can be automatically mounted, etc. The commands are defined in a configuration file that has simple XML syntax. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#503991 closed by Michael Biebl (Re: Bug#503991: debian policy requires the configurable files be under /etc)
package powersaved reopen 503991 thanks On Thu, Oct 30, 2008 at 10:28:36AM +, Debian Bug Tracking System wrote: > Stanislav Maslovski wrote: > > Package: powersaved > > Version: 0.15.20-3 > > Severity: serious > > > > This severity is totally exagerrated. wishlist would have been much more > appropriate > > > Any non-trivial configuration of powersaved requires writing event scripts. > > At the moment these scripts must be placed under /usr/lib/powersave/scripts > > which violates Debian Policy (see below). Please respect the policy. > > I don't agree. You do not agree with the Debian Policy? > Event scripts are not configuration files and shouldn't > be edited. Wrong. In the case of powersaved they are. You can find many examples of such scripts placed under /etc in other packages (acpid, pm-utils, etc). The system administrator must have a possibility to add his own scripts and they must be placed under /etc, not to some random place in the filesystem. *At least* you have to provide a mean to do that for locally created scripts, but it would be better if all powersaved scripts where treated the same. > If you want to create locally modified scripts, feel free to > put them under /etc and symlink them. That is exactly what policy requires from _you_ as the package maintainer to do. I am reopening this bug and also CC-ing this message to debian-devel. -- Stanislav -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
On Tue, Aug 07, 2007 at 11:38:33AM +0200, Julien BLACHE wrote: > "David Lopez Zajara (Er_Maqui)" <[EMAIL PROTECTED]> wrote: > > Hi, > > > Personally i'm an xmms user, and now, with this, i have tested other > > options. Audacious isn't an option at all. Yes, we have the same > > I've recently tried to switch to Audacious, and man it's buggy. Way > more buggy than xmms. > > Random segfaults during playback, random segfaults while scrolling the > playlist; can't have it running for more than 2 minutes. If you are using the version from Etch I would recommend upgrading/backporting to the version from unstable. It is quite usable. -- Stanislav -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
On Tue, Aug 07, 2007 at 09:28:05PM +0200, Julien BLACHE wrote: > Stanislav Maslovski <[EMAIL PROTECTED]> wrote: > > >> Random segfaults during playback, random segfaults while scrolling the > >> playlist; can't have it running for more than 2 minutes. > > > > If you are using the version from Etch I would recommend > > upgrading/backporting > > to the version from unstable. It is quite usable. > > I'm running unstable on all my desktops. Hm. I am running backported audacious on etch. I admit that I have seen audacious segfaulting but not as often as you describe. Moreover, with this new version I have yet to see it... Well, anyway, reportbug is our friend ;) -- Stanislav -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian on the Desktop - plans for Lenny?
On Wed, Aug 08, 2007 at 01:38:18PM -0400, Tim Hull wrote: > > I just reported an ITP Bug for restricted-manager [1] > > [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=436722 > > Just making sure you know this... You do not have to do this, and I think you have already realized why. -- Stanislav -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why no Opera?
On Tue, Aug 28, 2007 at 10:49:21AM +0200, Bernd Zeimetz wrote: > Michael Banck wrote: > > On Tue, Aug 28, 2007 at 02:57:07AM +0300, Lars Wirzenius wrote: > >> It is not free software. I had a quick peek at the license in the .deb > >> available from Opera's website, and it would not seem that they allow > >> other parties to distribute the software, therefore Debian cannot do so. > > > > That shouldn't stop us from having a discussion about it anyway! > > true. If somebody could convince the opera guys to open their source - > that would be a great thing. Opera is a very well working browser and it > is a shame, that it is not under an open source license. ^^ [flame on] I do not understand why that is "a shame". I think that the real shame is too many broken or never finished programs under open source licenses. [flame off] -- Stanislav -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#445105: ITP: fuse-convmvfs -- mirrors a whole filesystem tree from one charset to another
Package: wnpp Severity: wishlist Owner: Stanislav Maslovski <[EMAIL PROTECTED]> * Package name: fuse-convmvfs Version : 0.2.4 Upstream Author : Z.C. Miao <[EMAIL PROTECTED]> * URL : http://fuse-convmvfs.sourceforge.net/ * License : GPL Programming Lang: C++ Description : mirrors a whole filesystem tree from one charset to another convmvfs is a FUSE (File System in Userspace) utility that transparently mirrors a whole filesystem tree from one charset to another. Only the names of files and directories are converted, the file content remains intact. The mirrored tree is mounted at the given mountpoint. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#445377: ITP: awesome -- tiling window manager based on dwm
Package: wnpp Severity: wishlist Owner: Stanislav Maslovski <[EMAIL PROTECTED]> * Package name: awesome Version : 1.2 Upstream Author : Julien Danjou <[EMAIL PROTECTED]> * URL : http://awesome.naquadah.org/ * License : GPL (original dwm code is under MIT/X) Programming Lang: C Description : tiling window manager based on dwm awesome is a tiling window manager initially based on dwm (Dynamic Window Manager) code. It's extremely fast, small, dynamic and awesome. Like in dwm, windows in awesome can be managed in tiled and floating layouts. Each layout can be applied on the fly, optimizing the environment for the application in use and the task performed. With tiled layout, windows are managed in a master and a stacking area. The master area contains the windows which currently need most attention, whereas the stacking area contains all other windows. In floating layout, windows can be resized and moved freely, just like in a usual window manager. Dialog windows are always managed floating, regardless of the layout selected. In contrast to dwm which is configured by editing its source files and recompiling, every aspect of awesome is configurable via a configuration file: awesomerc. Awesome also does not impose a strict limit on its SLOC (Source Lines Of Code) count and therefore is more open for new features than dwm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Sourcing init-functions
On Sat, Jan 16, 2010 at 10:57:48AM +0100, Michael Welle wrote: > Hello, > > several init scripts use such a fragment for sourcing init-functions: > > if ! [ -x "/lib/lsb/init-functions" ]; then > . /lib/lsb/init-functions > else > echo "E: /lib/lsb/init-functions not found, lsb-base (>= 3.0-6) needed" > exit 1 > fi > > What is the reason to bail out if the execute bit is set? Or should I > bug report these packages? Looks like a bug. -x checks for existence _and_ the exec bit set, so if the file does not exist the next line will try to source it. The error message suggests that the author wanted a completely different behaviour... -- Stanislav -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Removing the manpage requirement for GUI programs?
On Wed, Mar 03, 2010 at 07:17:14PM +0100, Yves-Alexis Perez wrote: > On 28/02/2010 01:32, Ben Finney wrote: > > Josselin Mouette writes: > > > >> > Yes, I overall agree with your arguments. However having it in the > >> > policy means we get bug reports about manual pages and have to deal > >> > with them, while they are not the primary source of documentation for > >> > command-line options. > > If manpages were useful only for documenting command-line options, this > > would be a valid point. As has been pointed out, though, manpages for > > programs are useful for much more than that. > > > > But that's why he doesn't propose to forbid manpages for GUI programs, > just to not have them mandatory (well, agreed, it's a “should”). For > programs where there's no point in having a manpage (and only them) he > proposes to drop the “should” requirement, that's all. > > That doesn't prevent motivated people/upstream to provide manpages, it > just spares some time for maintainers. I have few cases in Xfce of such > programs (like all the xfce4-*-settings). My two cents: I have seen manpages in Debian that basically claim that "This program does not have a useful manpage, for the information look into bla-bla-bla..." I think that even having such a man page is better than not having one at all. Just because it clearly indicates where to look for additional information. In fact, a group of related programs that have information about them shared in a common place or have the same means to get this information (like --help command line option) could symlink to a single man file. -- Stanislav -- 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/20100304004148.ga22...@kaiba.homelan
Re: Removing the manpage requirement for GUI programs?
On Thu, Mar 04, 2010 at 04:32:45PM +0100, Josselin Mouette wrote: > Le jeudi 04 mars 2010 à 15:20 +0100, Bill Allombert a écrit : > > On Thu, Mar 04, 2010 at 10:26:06AM +0100, Josselin Mouette wrote: > > > No. It’s just that they ship with HTML documentation, which is much more > > > suitable for documenting a GUI. A manual page cannot contain things as > > > trivial as screenshots, which are mandatory. > > > > But a manual page can at least provide a link to the HTML documentation. > > > > This is far better than letting the user guess how to access the > > documentation. > > Because, of course, the user is too stupid to click the “Help” menu > inside the application. BTW, do you get bug reports about missing man pages in such cases? If you do, then probably those who submit the bugs explain why they still want a man page. And, of course, not every GUI app has a "Help" menu. -- Stanislav -- 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/20100305202751.ga2...@kaiba.homelan
Re: Invite to join the Release Team
On Sun, Mar 14, 2010 at 10:45:26PM +1030, Karl Goetz wrote: > On Sun, 14 Mar 2010 12:58:48 +0100 > Frank Lin PIAT wrote: > > > Hi dear Teams, > > At the risk of getting involved... > Where was the criticism that started this thread posted to? I didn't > notice it pass on -devel. I think it was the reaction on Clint's recent post on debian.planet.org. You can easily find it there. -- Stanislav -- 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/20100314125911.ga1...@kaiba.homelan
Re: Bits from the Release Team: What should go into squeeze?
On Mon, Mar 15, 2010 at 07:31:42PM +0100, Sylvestre Ledru wrote: > > We would like to know what needs attention, what bugs still need to be > > fixed in your package before squeeze is released, which features or new > > upstream versions you want to see in squeeze which are not ready yet. > > Furthermore we would like to get an overview of the remaining transitions > > that need to be done. > It is not a classical transition but the Debian Science team would like > to upload of BLAS / LAPACK and ATLAS this week. > This is described here: > http://wiki.debian.org/DebianScience/LinearAlgebraLibraries > I sent an email to debian-release to double check my proposal: > http://lists.debian.org/debian-release/2010/03/msg00051.html > but I haven't received an answer yet. > Updated packages are available in experimental. My tests show it is > working smoothly and I am going to do more tests in the next few days. > > These are common libraries in the numerical computing world. ATLAS (an > high performance BLAS implementation) has 4 RCs in testing/unstable > which are going to be fixed with this upload (with many others) > I can provide more information if needed. Good news! Does it fix libatlas3gf-sse2 bug #536686? -- Stanislav -- 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/20100320112357.ga22...@kaiba.homelan
Re: migration to testing
On Sat, Mar 27, 2010 at 01:38:56PM +0100, Mike Hommey wrote: > On Sat, Mar 27, 2010 at 01:05:37PM +0100, Simon Paillard wrote: > > On Sat, Mar 27, 2010 at 02:16:58PM +0300, Stanislav Maslovski wrote: > > > One of my packages, fuse-convmvfs (uploaded by a sponsor), cannot > > > migrate to testing. The migration is blocked by kfreebsd: > > > > > > * fuse-convmvfs/kfreebsd-amd64 unsatisfiable Depends: fuse-utils > > > * fuse-convmvfs/kfreebsd-i386 unsatisfiable Depends: fuse-utils > > > > > > What is the recommended way of solving this? > > > > fuse-utils is not build on kfreebsd-(amd64|i386) since it's > > Linux-specific, see #528537: [snip] > Anyways, on kfreebsd, fusemount is provided by another package (fusebsd, > iirc), which means that except if the freebsd kernel allows the mount > syscall for users, all packages currently depending on fuse-utils should > now depend on fuse-utils | fusebsd. I could not find this fusebsd package in Debian :( However, a related project indeed exists [1]. As the original poster of that question on debian-mentors, I would like to ask anyone who has access to a Debian/kFreeBSD installation to test if fuse-convmvfs from sid works there (provided that fuse4bsd is installed). My package builds on that architecture just fine, but unfortunately I cannot test myself if it works there. > This just sounds plain wrong, and IMHO, libfuse itself should do the > depend, though arguably, some libfuse rdepends don't need them. Well, if that would be possible I would simply prefer to add a dependence to my package and forget about it for a while. [1] http://fuse4bsd.creo.hu/ -- Stanislav -- 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/20100405210552.ga6...@kaiba.homelan
Re: Default value of net.ipv6.bindv6only should revert to 0
On Wed, Apr 07, 2010 at 05:04:58PM +0900, Kazuo Oishi wrote: > Vincent Danjean writes: > >>> Anyone, could you teach me why net.ipv6.bindv6only need to be set > >>> to 1 globally, and why other good programs need to be changed? > >>> I think it should revert. > > > > I've no strong opinion about the default value for net.ipv6.bindv6only. > > However, I think that any application that breaks if the default value > > is 0 or 1 is broken and a bug must be filled.. > > I think that an application which depends on net.ipv6.bindv6only=1 is > broken (at least as Linux application). I am not sure that there are such applications. Can you give us an example? > And I think that an application which depends on bindv6only=0 might have > a problem on portability and it might be a bug, but it should work with > Debian as ever. Setting bindv6only=1 and breaking these programs, > including outside of Debian packages, would not be a good choice. Well, nothing forbids you from changing that option on your own system, if you really need it. BTW, a related question to everyone: from reading /etc/init.d./procps I see that files in /etc/sysctl.d/ take a precedence over /etc/sysctl.conf. Should not it be the other way around? -- Stanislav -- 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/20100407090837.ga13...@kaiba.homelan
is BTS down?
Hi, Debian BTS seems to be on vacation. For how long? -- Stanislav -- 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/20100429080919.ga17...@kaiba.homelan
Re: is BTS down?
On Thu, Apr 29, 2010 at 10:11:01AM +0200, Sandro Tosi wrote: > On Thu, Apr 29, 2010 at 10:09, Stanislav Maslovski > wrote: > > Hi, > > > > Debian BTS seems to be on vacation. For how long? > > http://downforeveryoneorjustme.com/bugs.debian.org I can ping it: PING bugs.debian.org (86.59.118.149) 56(84) bytes of data. 64 bytes from lindberg.debian.org (86.59.118.149): icmp_seq=1 ttl=52 time=81.2 ms 64 bytes from lindberg.debian.org (86.59.118.149): icmp_seq=2 ttl=52 time=83.8 ms 64 bytes from lindberg.debian.org (86.59.118.149): icmp_seq=3 ttl=52 time=79.2 ms 64 bytes from lindberg.debian.org (86.59.118.149): icmp_seq=4 ttl=52 time=79.7 ms but the HTTP requests simply hang forever: % wget bugs.debian.org --2010-04-29 12:45:18-- http://bugs.debian.org/ Resolving bugs.debian.org... 86.59.118.149, 140.211.15.34, 206.12.19.114, ... Connecting to bugs.debian.org|86.59.118.149|:80... connected. HTTP request sent, awaiting response... -- Stanislav -- 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/20100429084655.ga20...@kaiba.homelan
Re: bindv6only again
On Tue, Apr 27, 2010 at 01:40:53PM +0200, Marco d'Itri wrote: > On Apr 27, Juliusz Chroboczek wrote: > > > reasonable commenter), and now you're saying that Julien Cristau is "the > > peanut gallery". > No, I am not. > > > But you're breaking peoples' systems *now*. And breaking systems > Which ones? There is only one bug open (gdm) and it has patches. >From what I noticed: xvnc4viewer (in the reverse connection mode) listens just on ::1 with this new default, so that I had to change some of my scripts (have not reported this as a bug yet, sorry). And there is no command line option to manually define the listening address, only for the port. freeciv (server) has the same problem by default, but at least in this case the address is configurable on the command line. Still, the automatic start of the game server from within the client is broken now (also not reported yet). -- Stanislav -- 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/20100429091438.ga21...@kaiba.homelan
Re: UPG and the default umask
On Mon, May 17, 2010 at 04:00:57AM +0200, Thomas Hochstein wrote:
> Felipe Sateler schrieb:
>
> > I mean, is there a reason for why I would want a non-UPG system?
>
> What about a hosting environment where you need to have user files
> world-readable (HTML documents or (PHP) scripts readable by www-data),
> but don't want them readable by other customers? You could achieve
> that by putting all customers in a common group ("users") and setting
> the files 604 or the like.
I think that in a UPG environment you could achieve the same (at least
in the case when there is a certain directory in which all those users
create their files, like /var/www/ or something) with a combination of
a common group, umask 072, and a setgid bit (and most likely a sticky
bit too to prevent deletions) on the shared directory.
--
Stanislav
--
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/20100519232410.ga32...@kaiba.homelan
Re: lilo removal in squeeze (or, "please test grub2")
On Mon, May 24, 2010 at 12:11:30AM +0400, William Pitcock wrote: > Hi, > > - "Stephen Powell" wrote: > > > (blah blah blah blah) > > Nobody cares if you are opposed to it. Unless you are offering to become > lilo upstream, it's going away. That is why I love reading d-dev. Some debian developers are so good at argumentation! -- Stanislav -- 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/20100523215431.ga6...@kaiba.homelan
Re: lilo removal in squeeze (or, "please test grub2")
On Sat, May 29, 2010 at 04:43:32PM -0400, Stephen Powell wrote: > On Sat, 29 May 2010 14:40:41 -0400 (EDT), Andreas Barth wrote: > > Stephen Powell wrote: > >> On Sat, 22 May 2010 23:39:52 -0400 (EDT), William Pitcock wrote: > >>> After some discussion about lilo on #debian-devel in IRC, it has pretty > >>> much been determined that kernel sizes have crossed the line past where > >>> lilo can reliably determine the payload size. > >> > > > > We're speaking about #505609 I assume? > > I hope not. Strictly speaking, 505609 is not a lilo bug. The key is > that he was still able to boot his old kernel that had been de-installed. > That's a sure sign that lilo's map installer did not get run during the > kernel upgrade process. [skipped] > If there's a bug here, it's somewhere else in the kernel installation > process, not in lilo itself. If this so-called bug in lilo is what > prompted the decision to drop lilo, then the decision was based on bad data. > lilo, at least in this case, is working as designed. The problem is that > the lilo map installer did not get run during the kernel installation > process. I've helped a number of people on debian-user with problems > like this, and in every case so far running lilo at the command line > fixed the problem. I guess your analysis was based on the follow-up by Tomas Pospisek? Christian Hammers from the same bug thread also stated that the problem disappeared after executing lilo from the command line. If that is really the case, then I would advise William to simply orphan lilo, if for some reason he does not want to work on it anymore. Removing, IMO, is not justified in this case. BTW, Stephen, you could also post your analysis on the BTS. -- Stanislav -- 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/20100530081726.ga31...@kaiba.homelan
Bug#583749: ITP: xkbind -- X Keyboard Extension Indicator
Package: wnpp Severity: wishlist Owner: Stanislav Maslovski * Package name: xkbind Version : 2010.05.20 Upstream Author : CHG * URL : http://xkbind.sourceforge.net/ * License : GPL2 Programming Lang: C Description : X Keyboard Extension Indicator The XkbInd program (X Keyboard Extension Indicator) is a minimal indicator of keyboard layout (XKB group) for the X Window System; it indicates current keyboard layout in the title of top-level windows via prefix to the original string. It also allows to simulate independent keyboard layout for each handled window and it works with most of the window managers, including twm, mwm and fvwm. Main Features = 1. XkbInd simulates independent keyboard layout for each handled top-level window. 2. XkbInd is very light-weight and uses less than 150 kb of virtual memory (excluding "shared", of course). 3. XkbInd doesn't grab entries in the default color pallet, doesn't perform any drawing operations on the X display itself, but relies wholly on the window manager. 4. XkbInd doesn't occupy any area on the screen, and outputs all relevant information to the window title. 5. XkbInd can be configured to ignore (or accept) particular windows or applications. This feature is based on examination of WM_CLASS property. It is possible to use wildcards in the "ignore" and "accept" lists. 6. XkbInd is a "true" XKB program, i.e. all interactions with the X-server are carried out through XKB extension protocol. 7. XkbInd keeps current layout of window at the server side as window property, unlike the most other similar programs which keep this data in the internal storage. 8. And the last, XkbInd does only what it says -- it is an indicator. Nothing more. -- 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/20100530115610.10041.68103.report...@kaiba.homelan
Re: finally: packages to optionally create default collaboration dirs
On Tue, Jun 01, 2010 at 08:23:00PM +0200, C. Gatzemeier wrote: > > If collaboration among users should work nicely out of the box, we will > finally need three small things. I am not sure in which package some of > them should go, though. > > 1) An install? option to populate /etc/skel/ with the special permission > directories private/(rwx--) and incoming/ (rwsrws-wt) > > > 2) An option for addgroup to automatically create groupdirs for > each created group: > > root: (rwxrwsr-x) /home/group/ > root: (rwxrws---) /home/group//private > root: (rwsrws-wt) /home/group//incoming > http://bugs.debian.org/248130 > > 3) A groupdir (like in 2) set up for the "users" system group. > > But where/how should those things be created best? Should not be created at all on default installs, thanks. If you care so much about this write a how-to and distribute it with any of the related documentation packages. Those things should be under control of a local administrator. They do not belong in Debian. -- Stanislav -- 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/20100601212000.ga4...@kaiba.homelan
Re: finally: packages to optionally create default collaboration dirs
On Wed, Jun 02, 2010 at 10:27:35AM +0200, C. Gatzemeier wrote: > Am Wed, 2 Jun 2010 01:20:00 +0400 schrieb Stanislav Maslovski > : > > Do not worry. They are not to be created by default. > If you read the subject it even explicitly reads "optionally > create". > > > Those things should be under control > > of a local administrator. > > And the functionality should be handled by a configurable option in > Debian. But why Debian should care about the precise details of local admistration policies? IMO, what is required from a distribution is just a set of sane defaults. One could argue that we could have a configurable set of defaults in this case, but in reality such unnessesary options will only confuse inexperieced users and irritate administrators. -- Stanislav -- 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/20100602085303.ga28...@kaiba.homelan
Re: finally: packages to optionally create default collaboration dirs
On Wed, Jun 02, 2010 at 10:27:35AM +0200, C. Gatzemeier wrote: [skipped] BTW, mutt seems to incorrectly fill the References: header when I reply to your mail. Just a second test. Please ignore... -- Stanislav -- 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/20100602090023.ga29...@kaiba.homelan
Re: finally: packages to optionally create default collaboration dirs
On Wed, Jun 02, 2010 at 11:59:18AM +0200, C. Gatzemeier wrote: > Am Wed, 2 Jun 2010 12:53:03 +0400 > schrieb Stanislav Maslovski: > > > But why Debian should care about the precise details of local > > admistration policies? > > If you have read #248130 Yes, I have. > and know debian, I am with Debian for more than 10 years, so, yes, I know something about it. > you probably know local details are usually nicely configurable. In 99.9% of cases the details you are writing about are package-related details. They define the behaviour of the software. The administration policies instead define the behaviour of the _users_ of software. My point is that this latter part does not belong in Debian. > You probably also know about debconf, preseeding and priorities > I.e. for addgroup a configuration analogy to adduser's homedirs would > be: > > GROUPDIRS=no > DGROUPDIR=/home/group > QUOTAGROUP= > GROUP_DIR_MODE=2775 > > > > what is required from a distribution is > > just a set of sane defaults. > > Before we can actually choose any defaults, we need > functionality that is able to optionally set up collaboration > directories. > > To set up the directories that are bound to groups, addgroup is the > obvious place for this. I don't know the right place yet though, for > the option to set up the groupdir for the "users" system group, and > ~/private and ~/incoming for each user. What may seem good to you, may be as well unacceptable to others for mirriads of reasons. > > in reality such unnessesary options will only confuse inexperieced > > users and irritate administrators. > > Ready to go and easy collaboration among the users of a system may not > be necessary and welcomed by everyone. Just stay with those things > disabled then, you shouldn't even notice. I'd like quote Petter here, > "You should not really allow your lack of imagination to limit what > computer systems can handle. :)" You said. But I think that the lack of imagination is actually on the other side. > The great thing about Debian is that it can mean and handle so many > different things for so many people. Yes, that is why we should not limit it to a fixed number of predefined choices. -- Stanislav -- 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/20100602204320.ga7...@kaiba.homelan
Re: finally: packages to optionally create default collaboration dirs
On Thu, Jun 03, 2010 at 10:36:09AM +0200, C. Gatzemeier wrote: > Am Thu, 3 Jun 2010 00:43:20 +0400 > schrieb Stanislav Maslovski : > > > > The great thing about Debian is that it can mean and handle so many > > > different things for so many people. > > > > Yes, that is why we should not limit it to a fixed number of > > predefined choices. > > Configurable defaults should implement full choice, unlike missing > functionality. Well, and how does _your_ proposal implement _full_ choice? > One can miss some configuration options about the optional setup of > collaboration directories (think $HOMEs for groups), but sorry, Debian's > mirriads of functionalities or packages that one can perfectly keep > disabled (or not installed) can hardly be unacceptable. Simply missing those "optional options" that are intended to be disabled or not installed can also hardly be unacceptable. But well, if you want to spend your time on this, it is up to you, of course. Just make it sure that it will not show up in places where it should not (like in debian installer). -- Stanislav -- 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/20100604082156.ga25...@kaiba.homelan
Re: How to make Debian more attractive for users
On Thu, Jul 22, 2010 at 05:39:19PM +0200, Benjamin Drung wrote: > Am Donnerstag, den 22.07.2010, 23:14 +0800 schrieb Paul Wise: > > On Thu, Jul 22, 2010 at 4:28 PM, Giacomo A. Catenazzi > > wrote: > Debian contributors don't have to be Debian users at the beginning. They > can come from Debian-derived distributions and contribute directly to > Debian to avoid work duplication. Sure. First they sell their souls to a daemon and then seek for an indulgence. Just kidding. -- Stanislav -- 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/20100725114242.ga4...@kaiba.homelan
libcairo2 in squeeze & subpixel rendering
Hi debian-devel, As we all know, squeeze is frozen now. This was a long awaited event, although for some importans software that we have in the distro it would be beneficial if this moment could happen later. One of such examples is libcairo2. The last release by ustream [1] is 1.8.10. At the moment we have this version in both testing and unstable. We also have 1.9.14 in experimental, one of the very important features of which is a proper support of fontconfig's attribute "lcdfilter" [2]. To those who are not familiar with this: this setting allows to tune the final stage of subpixel rendering [3] that is a filtering stage, the purpose of which is to reduce the visual color fringes around a character. Unfortunately, there is no filter that could perform equaly well with all available fonts. Fonts that have bytecode and are full-hinted with the native hinter usually look better (i.e., give less strain to the eyes) with the so-called "intrapixel" filters, while the autohinted fonts with hintstyle = hintslight look better with the so-called "interpixel" filters (or FIR lilters) [4, 5]. I am writing this to make it clear that it is important to have this filtering configurable. The lcdfilter setting with possible values of lcdnone, lcddefault, lcdlight (FIR filters), and lcdlegacy (itrapixel) has been supported by fontconfig since version 2.6.0. Freetype has provided respective filters since 2.3.0 (i.e., both were already available in lenny). Qt-based applcations respected these settings since Qt 4.5 [6]. The current situation with GTK applications in squeeze is the following. GTK aplications use cairo to render fonts. Cairo 1.8.10 has its own intrapixel filter (which is equivalent to freetype's lcdlegacy filter). It is impossible to redefine or tune this filter besides setting subpixel order. This significantly reduces the set of fonts that one can daily use with this filter without putting too much strain on her eyes. Even worse: one is usually forced to use only non-free fonts with this filter because the glyphs must be very well hinted in order for this filter to be efficient. For a long time there have been patches [7] that make cairo lcdfilter-aware and let it use freetype's internal filters. Untill recently (the commit [2] is dated June, 17th) the upstream was reluctant to accept them, therefore many distributions applied these patches on their own (so did Ubuntu; in the internet one may find many guides of how to build and install these Ubuntu packages on Debian to get "decent fonts"; we have also bugreports like [8]). Thus, getting to the main point of this long e-mail: what are we going to do with libcairo2 in squeeze? If we keep it at 1.8.10, I think it makes sense to apply the above mentioned patch, because it has been accepted by upstream and tested for quite a long time by other distributions. Or are we going to wait for the next release of cairo that might happen any time before squeeze releases, and then push it into testig? This sounds less probable, knowing the usual Debian practices. References == [1] http://cairographics.org/releases/ [2] http://cgit.freedesktop.org/cairo/commit/?id=7a023a62f7517ad0d54f4d59c99909fadcc05e82 [3] http://en.wikipedia.org/wiki/Subpixel_rendering [4] http://en.wikipedia.org/wiki/Intrapixel_and_Interpixel_processing [5] http://freddie.witherden.org/pages/font-rasterisation/ [6] http://labs.trolltech.com/blogs/2008/09/01/subpixel-antialiasing-on-x11/ [7] http://bugs.freedesktop.org/show_bug.cgi?id=10301 [8] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=555722 -- Stanislav -- 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/20100809142701.ga8...@kaiba.homelan
Re: libcairo2 in squeeze & subpixel rendering
On Mon, Aug 09, 2010 at 05:22:27PM +0200, Sebastian Dröge wrote: > On Mon, 2010-08-09 at 18:27 +0400, Stanislav Maslovski wrote: > > Thus, getting to the main point of this long e-mail: what are we going > > to do with libcairo2 in squeeze? If we keep it at 1.8.10, I think it > > makes sense to apply the above mentioned patch, because it has been > > accepted by upstream and tested for quite a long time by other > > distributions. Or are we going to wait for the next release of cairo > > that might happen any time before squeeze releases, and then push it > > into testig? This sounds less probable, knowing the usual Debian > > practices. > > Hi, > although cairo 1.10 is going to be released in a few days I don't think > we should get this into squeeze now as there are many changes that might > introduce regressions everywhere and I don't have the time to track them > all right now. Also, people reported problems with some video drivers > and in iceweasel recently. > > (OTOH I personally have no problems with cairo 1.9.14 and for me there > are only improvements and I can't reproduce the bugs reported by others) > > Backporting the lcdfilter patch to 1.8.10 might be a solution for > squeeze though. If someone wants to provide a patch that doesn't add any > new public API I'd be fine with applying it to the unstable package... > at least if the release team agrees. I am pretty sure porting is doable and I think I can volunteer to do this. But before it, let us collect more opinions. It would be nice to know what does the release team think about it. BTW, suboptimal subpixel rendering of fonts in Debian is one of the reasons why many desktop users switch to other distros. -- Stanislav -- 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/20100809171305.ga14...@kaiba.homelan
Re: libcairo2 in squeeze & subpixel rendering
On Mon, Aug 09, 2010 at 08:31:53PM +0200, Bernd Zeimetz wrote: > On 08/09/2010 07:13 PM, Stanislav Maslovski wrote: > > I am pretty sure porting is doable and I think I can volunteer to do > > this. But before it, let us collect more opinions. It would be nice to > > know what does the release team think about it. BTW, suboptimal > > subpixel rendering of fonts in Debian is one of the reasons why many > > desktop users switch to other distros. > > Interesting, I've never run into any trouble with subpixel rendering... Your opinion is subjective. If you want to be objective please invest some time into studying this issue, like I did. You may start with references I gave in my first post. -- Stanislav -- 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/20100809185338.ga22...@kaiba.homelan
Re: libcairo2 in squeeze & subpixel rendering
On Mon, Aug 09, 2010 at 08:54:16PM +0200, Sebastian Krause wrote: > Stanislav Maslovski wrote: > > I am pretty sure porting is doable and I think I can volunteer to do > > this. But before it, let us collect more opinions. It would be nice to > > know what does the release team think about it. BTW, suboptimal > > subpixel rendering of fonts in Debian is one of the reasons why many > > desktop users switch to other distros. > > I actually switched back *to* Debian from Ubuntu because I found the > font rendering in Ubuntu totally horrible. Especially in Firefox > fonts were really blurry and last time I checked they still haven't > fixed it. > > By choosing the "Autohinter" option in "dpkg-reconfigure > fontconfig-config" (which is also broken in Ubuntu) and enabling > full hinting I actually like the rendering very much in Debian. At > least using the DejaVu fonts which I basically have everywhere. This is not surprising, as the legacy filter which was first introduced in xft and then appeared in cairo was fine-tuned specifically for the fonts with which you use full hinting, such as DejaVu fonts or msttcorefonts. My point is that rather let the user decide which fonts and which settings are better for her. With the present cairo in squeeze this is impossible (in cairo-based applications), while if we apply the change I propose, you will still get your sharp and crispy DejaVu fonts with hintstyle=hintfull and lcdfilter=lcdlegacy. From the other hand, another user, who prefers slightly hinted fonts with better outlines, will be also happy, as she will set hintstyle=hintslight and lcdfilter=lcddefault. You did not like Ubuntu's font rendering because, I guess, you had the default lcdfilter. As I wrote in my initial post (have you read it?) it was not the best choice for strongly hinted fonts. Thus I repeat: the subpixel rendering of fonts in current squeeze is suboptimal, because instead of providing flexibility and full control it virtually limits the choice of fonts by roughly two families, one of which is non-free. -- Stanislav -- 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/20100809194000.ga23...@kaiba.homelan
Re: why are there /bin and /usr/bin...
On Tue, Aug 10, 2010 at 03:15:35AM -0600, Bruce Sass wrote: > /sbin and /usr/sbin, /lib and /usr/lib directories? > > AFAICT, the reason is so that a minimal but functional system is > guaranteed to exist so long as a local HDD with a root filesystem is > available (which doesn't necessarily include /usr); and that is a good > thing to have because it gives developers a core set of software tools > they can count on to always exist and facilitates troubleshooting or > repairs if something breaks (e.g., bug# 592361, where I've worked > around the problem by using /bin/nano to reconfigure the box with a > static IP address). Not just to repair. First of all, / must have enough tools to bring the system up to the point where the other file systems can be mounted (i.g., over the network). > If that is a good reason, perhaps even The reason, for having both /bin > and /usr/bin, etc., then doesn't it follow that all files required by > executables residing in /bin and /sbin should also be available so long > as a local HDD with a root filesystem is available (otherwise those > executables are either broken or crippled)? All files that a tool requires to operate must be there, for sure. > I suppose there could be cases where the broken or crippled > functionality is not useful or required when a properly populated /usr > doesn't exist, but I expect those would be "special" cases, because, > generally, crippled or broken programs are a bad thing. ya? Can you give examples of such special cases? > I'm trying to understand the logic behind it not being an automatic bug > (i.e., something which is a good candidate to check for at build-time) > for stuff in /bin and /sbin to require stuff in /usr; and I've gotten > onto this because of bugs like #592361 and #589123, and the observation > that over the last couple/few years I seem to be running up against > problems related to this issue more and more frequently. This is an unfortunate consequence of the fact that less and less developers separate /, /usr, /var, etc. partitions on their machines. In the past I always did it on my workstations, however, stopped doing it around the time of lenny's release. > With bugs in scripts (e.g., #589123) it should be good enough that a > text editor is available, but with broken binaries (e.g., #592361) the > potential to be put in a not-so-easy-to-fix situation is pretty high > (remember, dpkg is not around when /usr is missing and the fix is going > to arrive in a .deb)--so maybe that one should generate a warning of > some sort. Well, just the other day I was helping a user on #debian to repare his Debian installation, using mostly sed to edit the config files. Nano was not functional without /usr and it seemed he did not have any other editor. -- Stanislav -- 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/20100810101810.ga11...@kaiba.homelan
Re: libcairo2 in squeeze & subpixel rendering
On Mon, Aug 16, 2010 at 12:06:48PM +0200, Josselin Mouette wrote: > Le lundi 09 août 2010 à 23:40 +0400, Stanislav Maslovski a écrit : > > Thus I repeat: the subpixel rendering of fonts in current squeeze is > > suboptimal, because instead of providing flexibility and full control > > it virtually limits the choice of fonts by roughly two families, one > > of which is non-free. > > And the other one being the default. > > I’ll let you come back with accurate figures of the number of users who > change the default fonts. Well, many users of non-latin alphabets do. I do not have an accurate figure, however. Anyone interested should speak up (there was a discussion of this in debian-russian, for example). Actually, whatever figure it could be, my point you quoted above remains valid. I'm currently travelling; I will be back home next week, then I will look into porting the patch. -- Stanislav -- 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/20100817134107.ga4...@kaiba.homelan
Re: 38
On Fri, Aug 27, 2010 at 12:22:08AM +0200, posion bit wrote: > I've just started my love history again with squeeze. > > There are 38 unquoted $i in /etc in i386 installing base+laptop+standar > > There are 172 "$i" (maching without spaces around) 38 of them matches > whit spaces around (unquoted). > > Some are iteration numbers, some are directory, files, etc... > > I've not time neither humor, to fill such bugs or not bugs depending > on the situation. > > That has been my first command after login: > > grep -R ' $i ' /etc/ | grep -viE '(binary|no such)' > > Just in case that some good person as time and humor (what I lack > today) to review it and file the bug if may be convenient. So, what is the problem with this? Both usages are legitimate (if one understands what she is doing, of course). -- Stanislav -- 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/20100827063007.ga3...@kaiba.homelan
Re: 38
On Fri, Aug 27, 2010 at 09:58:22AM +0200, Adam Borowski wrote: > On Fri, Aug 27, 2010 at 10:30:07AM +0400, Stanislav Maslovski wrote: > > On Fri, Aug 27, 2010 at 12:22:08AM +0200, posion bit wrote: > > > There are 38 unquoted $i in /etc in i386 installing base+laptop+standar > > > > > > There are 172 "$i" (maching without spaces around) 38 of them matches > > > whit spaces around (unquoted). > > > > > > Some are iteration numbers, some are directory, files, etc... > > > > > > > grep -R ' $i ' /etc/ | grep -viE '(binary|no such)' > > > So, what is the problem with this? Both usages are legitimate (if one > > understands what she is doing, of course). > > touch "o rly?" > > While many of these are false alarms (numbers, fixed names, ...), the > problem is real. [skipped] Have you noticed what I have written above in brackets? The obvious things you mentioned are bugs and must be fixed, of course. It does not invalidate the use of unquoted $var, however, when one needs it for an effect. -- Stanislav -- 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/20100827084101.ga5...@kaiba.homelan
does aptitude really need to lock the status database when downloading?
Hi debian-devel, I wanted to ask this for quite a long time: Does aptitude (I think apt-get does the same) really have to lock "the status database area" when _downloading_ packages? For example, I am running an update on a slow connection and want to uninstall or install with dpkg a few packages while the others are being downloaded. Should not this be possible? I understand that there can be a situation that a dependency could be affected by such an action, but is not it easy to check for this right before unpacking? -- Stanislav -- 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/20110204001054.GA31724@kaiba.homelan
Re: does aptitude really need to lock the status database when downloading?
On Fri, Feb 04, 2011 at 01:21:07AM +0100, Eduard Bloch wrote: > #include > * Stanislav Maslovski [Fri, Feb 04 2011, 03:10:54AM]: > > Hi debian-devel, > > > > I wanted to ask this for quite a long time: Does aptitude (I think > > apt-get does the same) really have to lock "the status database area" > > when _downloading_ packages? > > > > For example, I am running an update on a slow connection and want to > > uninstall or install with dpkg a few packages while the others are > > being downloaded. Should not this be possible? I understand that there > > can be a situation that a dependency could be affected by such an > > action, but is not it easy to check for this right before unpacking? > > If you want to have that level of control, why don't you just check it > manually? Use --download-only with apt-get (no dpkg locking this way) > and when it's done, use apt-get without it to install the packages after > making sure that there is no dpkg active anymore. This is possible, however, it is an extra busy work for a user. In any case, I think that holding a lock only for downloading is an overkill and this can be relaxed. As Julian Taylor mentioned, there is also another side of the same problem: aptitude itself can be improved so that it is able to download and unpack in parallel. If it were doing this then the lock would be justified. -- Stanislav -- 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/20110204085722.GA6573@kaiba.homelan
Re: does aptitude really need to lock the status database when downloading?
On Fri, Feb 04, 2011 at 10:00:40AM +0100, Olaf van der Spek wrote: > On Fri, Feb 4, 2011 at 9:57 AM, Stanislav Maslovski > wrote: > > This is possible, however, it is an extra busy work for a user. In any > > case, I think that holding a lock only for downloading is an overkill > > and this can be relaxed. > > What if you would launch two download-only ops at the same time? > Isn't a lock needed in that case as well? That should a different lock. Currently, when _dowloading_ aptitude holds a lock that prevents _installing_. -- Stanislav -- 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/20110204092307.GA10851@kaiba.homelan
Re: does aptitude really need to lock the status database when downloading?
On Fri, Feb 04, 2011 at 09:47:21AM -0200, Fernando Lemos wrote: > On Fri, Feb 4, 2011 at 6:57 AM, Stanislav Maslovski > wrote: > [...] > >> If you want to have that level of control, why don't you just check it > >> manually? Use --download-only with apt-get (no dpkg locking this way) > >> and when it's done, use apt-get without it to install the packages after > >> making sure that there is no dpkg active anymore. > > > > This is possible, however, it is an extra busy work for a user. In any > > case, I think that holding a lock only for downloading is an overkill > > and this can be relaxed. > > As far as I can tell (and please correct me if I'm wrong), when you > do, say, an "apt-get upgrade", apt prepares an upgrade "plan" that > uses a given set of packages. If apt wouldn't lock and parallel to > that you do an "apt-get install", for example, the original "plan" > might not be valid anymore (e.g., new "Breaks" or "Conflicts" were > introduced). This I understand, as I mentioned in my original mail. > So a new plan would have to be created, the user would > have to be asked for confirmation again. Doesn't sound that great. Actually, it is the opposite. It sounds actually very great _for_the_target_user_. Because the user who wants this feature will be aware of what he is doing. For that user the _current_ situation with the global lock does not seem very great. Other users will not be affected at all if such a check is indroduced, because they do not use dpkg when doing an apt-get upgrade. Unfortunately, I do not know anything about the internal architecture of apt and friends, therefore I cannot promise any help with it and may only ask for other people that may be interested in implementing this. Maybe in a competing software (was there something called cupt?) > > As Julian Taylor mentioned, there is also another side of the same > > problem: aptitude itself can be improved so that it is able to > > download and unpack in parallel. If it were doing this then the lock > > would be justified. > > As far as I know, apt-get already downloads in parallel. Not sure > about aptitude. A parallel download is not the same as a download superimposed with unpacking. -- Stanislav -- 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/20110204160931.GA13423@kaiba.homelan
Bug#725712: ITP: tarix -- Indexing utility for tar archives
Package: wnpp Severity: wishlist Owner: Stanislav Maslovski * Package name: tarix Version : 1.0.7 Upstream Author : Matthew "Cheetah" Gabeler-Lee * URL : https://github.com/fastcat/tarix; http://sourceforge.net/projects/xtar/ * License : GPL Programming Lang: C Description : Indexing utility for tar archives tarix is a program for indexing tar archives so that selective extraction can be done rapidly, especially on slow devices like tape drives, providing that you can seek to arbitrary locations (at least on 512 byte boundaries) within the tar archive. . Tarix is designed to work as a compression filter for tar with the --use-compress-program option. Tarix can either pass the tar archive straight through, or it can compress the archive using zlib on the way through. Note that tarix does special things when using zlib to enable random access when extracting. . Tarix's index file format is geared for simplicity and ease of use in a recovery situation. For those reasons, it is a simple text format. Using tarix's indexes requires only grep, sed, dd, and tar for basic usage. tarix itself can use the index for fast extraction without convoluted usage of grep, sed, and dd. -- 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/20131007161918.20593.18916.reportbug@kaiba.homelan
Re: oops I sent a courtesy copy in violation of the code of conduct
Hello, On Sun, Mar 13, 2011 at 10:44:07AM +0200, Shachar Shemesh wrote: > On 13/03/11 08:19, Ben Finney wrote: > >Shachar Shemesh writes: > >>I am subscribed to lots and lots of mailing lists. All mail from those > >>lists gets automatically delivered to dedicated folders automatically. > >>This means I'm highly likely to miss a reply to my own emails to the > >>list unless I get another, direct, copy (which doesn't have the list > >>hidden headers, and therefor stays in my inbox). I *like* to get two > >>copies, as it increases the chance that I actually get to see the > >>replies to my own emails. > >If you like to get two copies, why can't you arrange to generate the > >extra copies you want without involving anyone else's configuration? > Any suggestions on how to do it? I have a similar configuration with many separate folders for mailing lists. I receive mail with fetchmail and employ procmail for sorting mail out (probably, not a common setup nowadays). My trick to get extra copies of direct replies to my own mails in mailing lists (I place such copies into a dedicated folder) is to keep a local cache of Message-IDs of my own sent messages and then check In-Reply-To: header in the received mails against this cache. It is done with a couple of relatively simple rules in ~/.procmailrc that make use of formail and grep. -- Stanislav -- 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/20110402232947.GA13619@kaiba.homelan
Re: /run support for wheezy?
On Wed, Mar 30, 2011 at 05:29:55PM +0200, Julien Cristau wrote: > On Wed, Mar 30, 2011 at 16:20:10 +0100, Roger Leigh wrote: > > > Given that Fedora are adopting /run, and it has been something > > we have wanted in the past, is anyone working on implementing > > /run in Debian? > > > > http://thread.gmane.org/gmane.linux.redhat.fedora.devel/146976 > > That seems to say "on Debian /lib/init/rw was introduced for the same > thing, but I'm using a different name just because I can". What am I > missing? Exactly, I got the same impression. Especially, when I saw that it was listed under a summary of "exsting broken solutions". -- Stanislav -- 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/20110403095905.GA20318@kaiba.homelan
Re: network-manager as default? No! (was: Bits from the Release Team - Kicking off Wheezy)
On Sun, Apr 03, 2011 at 10:11:03AM +0200, martin f krafft wrote: > But if network-manager would become default and ifupdown an optional > replacement, I would question Debian's capacity to make technically > excellent decisions and wonder, how much we have been dragged along > by "user-friendly distros" and slid off the track. I agree. If that happens I will seriously think about moving to another distro (I have been using Debian since around 1999). Or maybe to a *BSD. Just for a record: on this _laptop_ the network is configured from /etc/network/interfaces with extensively used mapping and self-written scripts; also with wpa_supplicant for wireless and ifplugd to bring up eth0 and openvpn tunnels when required. Never felt a need to switch to something like wicd or network-manager. -- Stanislav -- 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/20110403103726.GA25742@kaiba.homelan
Re: network-manager as default? No! (was: Bits from the Release Team - Kicking off Wheezy)
On Sun, Apr 03, 2011 at 12:56:40PM +0200, Stefano Zacchiroli wrote: > On Sun, Apr 03, 2011 at 02:37:26PM +0400, Stanislav Maslovski wrote: > > If that happens I will seriously think about moving to another distro > > (I have been using Debian since around 1999). Or maybe to a *BSD. > > You're entitled to choose your own distro. Still, please do not assume > that this sort of threatening is something useful to drive technical > decisions in Debian. Where do you see treatening there? I am just expressing my opinion, as others do on the very same thread. > In fact, I believe it just adds noise to technical discussions, just > imagine would happen if all users out there will start using -devel > to implement polls. Since when we have debian-devel moderated? And please do not summarize other's people mails to your own liking. -- Stanislav -- 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/20110403123439.GA665@kaiba.homelan
Re: network-manager as default? No! (was: Bits from the Release Team - Kicking off Wheezy)
On Sun, Apr 03, 2011 at 02:09:09PM +0200, Stefano Zacchiroli wrote: > On Sun, Apr 03, 2011 at 01:07:12PM +0200, Bernhard R. Link wrote: > > Debian is not about market-share, so losing users is no thread. It is > > only an information for us that we no longer helpful to some of our > > users. > > The problem is that such a message only conveys the information that > *one* specific user will find our distro no long useful. In turn, that > might induce other users to post ack/nack to -devel and that would > hardly help driving technical discussions to conclusion. I understand that you are in a position that forces you to think about public relations and such, but if I were a DD I would be more happy if DPL was a bit more focused on real problems. > Ultimately, my point is that user feedback is very useful, but we should > find better way to seek it (e.g. explicit polls) than encouraging users > to post their feedback to -devel. I manage packages in Debian. If you want me to stop doing that please exress it more clearly. -- Stanislav -- 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/20110403124211.GA895@kaiba.homelan
Re: network-manager as default? No! (was: Bits from the Release Team - Kicking off Wheezy)
On Sun, Apr 03, 2011 at 03:50:36PM +0200, Stefano Zacchiroli wrote: > On Sun, Apr 03, 2011 at 04:42:11PM +0400, Stanislav Maslovski wrote: > > I understand that you are in a position that forces you to think about > > public relations and such, but if I were a DD I would be more happy if > > DPL was a bit more focused on real problems. > > Non sequitur: the fact that I'm participating into this sub-thread does > not imply I'm not focusing on (other) "real problems". Then it means that my and your understanding of which problems are real and which are not differs very much, as, for instance, I would not advise users to refrain from expressing their opinions on various "technical suggestions" on d-d list just in a fear of flood. > > I manage packages in Debian. If you want me to stop doing that please > > exress it more clearly. > > Non sequitur again: I've said nothing about the packages you're > managing. You stressed too much on my role as a mere user, that is why I brought this point to your attention. I thought it was obvious from the context. > You're right when you say -devel is not moderated, but that also > gives the liberty to all the list participants, including myself, to > comment when they see usage patterns that they do not think will > further the goals of the list. Of course. Nobody even tried to take this liberty away from you or to disrespect it. > And I'm sorry, but when I read comments like "if you do $foo I'll > stop using Debian", I can't help thinking (and sometime commenting) > that those comments are not helping pursuing a technical discussion. Analogously, when I see such "great" technical suggestions as replacing ifupdown on default installs with network-manager, I can't help thinking (and sometimes commenting) that if this trend continues, then at some point in future I may face a painful decision to abandon the distribution that I continuously used for more than a decade and to which I contributed. PS: And there was a technical part in that my post you replied first. You just skipped it. -- Stanislav -- 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/20110403173213.GA6770@kaiba.homelan
Re: network-manager as default? No! (was: Bits from the Release Team - Kicking off Wheezy)
On Sun, Apr 03, 2011 at 11:26:20PM +0530, Josselin Mouette wrote: > Le dimanche 03 avril 2011 à 21:32 +0400, Stanislav Maslovski a écrit : > > Analogously, when I see such "great" technical suggestions as > > replacing ifupdown on default installs with network-manager, I can't > > help thinking (and sometimes commenting) that if this trend continues, > > then at some point in future I may face a painful decision to abandon > > the distribution that I continuously used for more than a decade and > > to which I contributed. > > May I suggest that you install a squeeze system with the desktop task, > with a simple DHCP network configuration? Why on earth would I do that? It does not match my needs at all. For instance, this laptop sometimes connects to a couple of remote LANs through VPNs, so that I have to set up routing in a not completely trivial manner. On another site where I sometimes work, there is an IPX network to which I have to connect to access the fileserver. Occasionaly, I have to run another OS in a virtual machine on this laptop for which I set up a bridge, etc. I am not even mentioning any servers, as it is obvious that network-manager is a "no-no" for them. > You will see that your network is no longer managed by ifupdown. So > we’re talking about something that has partly already happened, and > AFAICT the world hasn’t fallen apart. Well, I can only feel pity for the users who fell into this trap. Do you know what is the first advise that is given to those users when they eventually run into a problem with their network? Right, deinstal network-manager! > So far your only contribution to the discussion has been “If this > happens, I will use another distribution.” Fine. That is not exactly true, while I understand that certain people prefer to see it like this. > But could you explain why we would care? I should probably remind you > that Debian is, at first, a do-o-cracy, so if you’re not interested > into fixing things yourself Yes, I usually fix bugs myself when I need it, if you mean this. Try googling "Stanislav Maslovski +patch". > or at least giving constructive criticism If you read my mails without a prejudice you will notice it. > please let other people dream of other technical solutions that they > might actually end up improving the state of our network stack (which > is, in case you haven’t noticed, absolutely disastrous). If you mean the ifupdown-based configuration, then I cannot agree that it is "really disastrous" (I would agree that the network-manager approach is really disastrous, however) as at least in my cases (which are not so trivial) ifupdown works okay (and if not then at least I would know ways how to workaround problems). -- Stanislav -- 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/20110403201856.GA14280@kaiba.homelan
Re: network-manager as default? No! (was: Bits from the Release Team - Kicking off Wheezy)
Hello, This reply went to debian-russian@ due to a mistake. Next doing a bounce to d-d was another mistake, so if you receive this message twice, I am sorry for that! Still I feel that I cannot leave it unanswered, so here it goes. On Sun, Apr 03, 2011 at 11:26:20PM +0530, Josselin Mouette wrote: > Le dimanche 03 avril 2011 à 21:32 +0400, Stanislav Maslovski a écrit : > > Analogously, when I see such "great" technical suggestions as > > replacing ifupdown on default installs with network-manager, I can't > > help thinking (and sometimes commenting) that if this trend continues, > > then at some point in future I may face a painful decision to abandon > > the distribution that I continuously used for more than a decade and > > to which I contributed. > > May I suggest that you install a squeeze system with the desktop task, > with a simple DHCP network configuration? Why on earth would I do that? It does not match my needs at all. For instance, this laptop sometimes connects to a couple of remote LANs through VPNs, so that I have to set up routing in a not completely trivial manner. On another site where I sometimes work, there is an IPX network to which I have to connect to access the fileserver. Occasionaly, I have to run another OS in a virtual machine on this laptop for which I set up a bridge, etc. I am not even mentioning any servers, as it is obvious that network-manager is a "no-no" for them. > You will see that your network is no longer managed by ifupdown. So > we’re talking about something that has partly already happened, and > AFAICT the world hasn’t fallen apart. Well, I can only feel pity for the users who fell into this trap. Do you know what is the first advise that is given to those users when they eventually run into a problem with their network? Right, deinstal network-manager! > So far your only contribution to the discussion has been “If this > happens, I will use another distribution.” Fine. That is not exactly true, while I understand that certain people prefer to see it like this. > But could you explain why we would care? I should probably remind you > that Debian is, at first, a do-o-cracy, so if you’re not interested > into fixing things yourself Yes, I usually fix bugs myself when I need it, if you mean this. Try googling "Stanislav Maslovski +patch". > or at least giving constructive criticism If you read my mails without a prejudice you will notice it. > please let other people dream of other technical solutions that they > might actually end up improving the state of our network stack (which > is, in case you haven’t noticed, absolutely disastrous). If you mean the ifupdown-based configuration, then I cannot agree that it is "really disastrous" (I would agree that the network-manager approach is really disastrous, however) as at least in my cases (which are not so trivial) ifupdown works okay (and if not then at least I would know ways how to workaround problems). -- Stanislav -- 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/2011040325.GA22184@kaiba.homelan
Re: Flaming as a way to reach technical quality? No! (was: network-manager as default? No! (was: Bits from the Release Team - Kicking off Wheezy))
On Sun, Apr 03, 2011 at 10:28:42PM +0100, Lars Wirzenius wrote: > I have read all e-mails in this thread, and what constructive criticism > you may have given is buried under uncompromising prejudice. For > example: > > > If you mean the ifupdown-based configuration, then I cannot agree that > > it is "really disastrous" (I would agree that the network-manager > > approach is really disastrous, however) as at least in my cases (which > > are not so trivial) ifupdown works okay (and if not then at least I > > would know ways how to workaround problems). > > You say Network Manager is disastrous, when it manifestly works quite > well for quite a number of people. It is hard to take you seriously, > when you say things that are so clearly wrong. Be it clearly wrong or not, I strongly disbelieve that a tool with a hard-wired logic such a network-manager may seem a reasonable replacement for such a configurable tool as ifupdown. These two tools have been designed with absolutely different goals in mind. And I think it is quite clear that even with the current limitations of ifupdown (some were mentioned in this thread) its intended use case is wider than the use case of network-manager. -- Stanislav -- 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/20110403234229.GA27504@kaiba.homelan
Back to technical discussion? Yes! (was: network-manager as default? No!)
On Mon, Apr 04, 2011 at 12:00:01AM -0700, Steve Langasek wrote: > On Mon, Apr 04, 2011 at 10:52:33AM +0400, Dmitry E. Oboukhov wrote: > Yes, a user can do anything with ifconfig if his time has no value. I am > happily using network manager on my laptop, because unlike ifconfig it's > easy to configure for use on new wireless networks. Well, actually configuring a wireless network with wpa_supplicant and ifupdown is not hard at all and does not require too much time, _if_ a user has developed a good habbit of reading documentation first. It is also preferable in that sense that you configure it once and it works for years, surviving upgrades, etc. So in the end you conserve your time, and not loose your time. There is also a basic GUI if one needs it (wpa_gui). > I am not happy that network manager bypasses ifconfig to do this; I > would have much preferred a daemon that could properly integrate with > the existing infrastructure we had. Exactly. There is ifplugd that implements some of the functionality that is required to support dynamically appearing and disappearing connections. It is a simple daemon that calls ifupdown when needed, so that the old and good way of network configuration is respected. But ifplugd needs some love, because it was mostly intended to be used with ethernet cable connections (I managed to use it also with dynamic tap interfaces, though). -- Stanislav -- 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/20110404075506.GA636@kaiba.homelan
Re: Back to technical discussion? Yes! (was: network-manager as default? No!)
On Mon, Apr 04, 2011 at 05:35:10PM +0530, Josselin Mouette wrote: > Le lundi 04 avril 2011 à 11:55 +0400, Stanislav Maslovski a écrit : > > Well, actually configuring a wireless network with wpa_supplicant and > > ifupdown is not hard at all and does not require too much time, _if_ a > > user has developed a good habbit of reading documentation first. > > It seems to be a common belief between some developers that users should > have to read dozens of pages of documentation before attempting to do > anything. > > I’m happy that not all of us share this elitist view of software. I > thought we were building the Universal Operating System, not the > Operating System for bearded gurus. I do not think that reading documentation before trying to achieve something is that elitist. And in the case of wpa_supplicant, it is definitely not dozens of pages. Basically, it is just man interfaces man wpa_supplicant.conf zless /usr/share/doc/wpasupplicant/README.Debian.gz (and for most cases just reading that README.Debian should be enough) > > It is also preferable in that sense that you configure it once and it > > works for years, surviving upgrades, etc. So in the end you conserve > > your time, and not loose your time. > > Do you even know in what kind of contexts a laptop with wireless > connection is actually used? Because from your sentence it looks like > you live in a different world. Perhaps, I do. I travel quite a lot, so I use my laptop in airports, libraries, hotels, etc. The wireless networks in public locations are usually open and do not require any specific configuration; the most of them are catched with a simple roaming setup outlined in that README from above, supplanted with a default /e/n/interfaces stanza for DHCP-based networks. If one instead prefers using a GUI, then there is wpa_gui with which one may scan for networks, select the needed one, change parameters, etc. I also use wireless at home and at the sites where I work. For these locations I have several fixed stanzas in /e/n/interfaces and in wpa_supplicant.conf that I do not need to touch at all. -- Stanislav -- 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/20110404133118.GA17213@kaiba.homelan
Re: Back to technical discussion? Yes! (was: network-manager as default? No!)
On Mon, Apr 04, 2011 at 07:33:31PM +0530, Josselin Mouette wrote: > Le lundi 04 avril 2011 à 10:39 -0300, Ben Armstrong a écrit : > > But the average laptop user really does have a hard time with the > > status quo. Something needs to change in the next release. > > I think squeeze already does a lot better, but there is still work to > do, especially with the installation process. > > On my personal wishlist for wheezy is d-i actually calling NM behind the > scenes to configure the network, instead of ifupdown. I’ll definitely > try to find time to hack on this. Do you plan also to hack on network-manager itself so that it might become at least remotely reasonable alternative to ifupdown, or do you simply plan to follow the way redhat went, i.e., network manager as it is, even on server installations? Sould not there be an option to select between the old network configuration and NM? -- Stanislav -- 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/20110404145205.GA21595@kaiba.homelan
Re: Back to technical discussion? Yes! (was: network-manager as default? No!)
On Mon, Apr 04, 2011 at 06:06:28PM +0530, Josselin Mouette wrote: > Le lundi 04 avril 2011 à 16:19 +0400, Dmitry E. Oboukhov a écrit : > > User MUST study each OS he uses. > > No, he must not. The OS must adapt to the user’s needs, not the > opposite. > > > If he doesn't want he will be > > forced to pay the other people who will tune his (user's) system. > > A lot of users actually pay for that indeed. I don’t see this as a > problem, especially since it gets me to eat every day. By the way, I am glad that you spoke your mind so clearly. IMO, this agrees very much with the trends in free software development that solidified in the last decade: the development of popular free software is now concentrated within big corporations and is done in groups of well paid fulltimers. Those who still believe in the openness of this process must disillusion themselves: nowadays most of the development is driven by marketing. It is not surprising that marketing places an emphasis on simplicity to the detriment of configurability. Such marketing goals also explain why these groups usually agressively fight for domination. Nevertheless, I honestly hope that Debian, with its huge collection of free software, will contunue to provide freedom of choice to all types of its users, including those who disagree with marketing goals of big corporations. -- Stanislav -- 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/20110404171858.GA25705@kaiba.homelan
Re: Back to technical discussion? Yes! (was: network-manager as default? No!)
On Mon, Apr 04, 2011 at 06:35:19PM +0100, Jon Dowland wrote: > On Mon, Apr 04, 2011 at 06:52:05PM +0400, Stanislav Maslovski wrote: > > Sould not there be an option to select between the old network configuration > > and NM? > > Nowhere have I seen it argued that NM will be the *only* networking solution > for Debian going forward, merely the *default* one. In other words, yes, > there > should be an option: just like there is now. I mean that such an option should be available from within the installer (at least in the expert mode) at the stage of the initial network configuration, if network-manager is going to replace ifupdown in this stage. -- Stanislav -- 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/20110404181000.GA29744@kaiba.homelan
Re: Back to technical discussion? Yes! (was: network-manager as default? No!)
On Mon, Apr 04, 2011 at 01:57:10PM -0500, Romain Beauxis wrote: > 2011/4/4 Stanislav Maslovski : > >> I am not happy that network manager bypasses ifconfig to do this; I > >> would have much preferred a daemon that could properly integrate with > >> the existing infrastructure we had. > > > > Exactly. There is ifplugd that implements some of the functionality > > that is required to support dynamically appearing and disappearing > > connections. It is a simple daemon that calls ifupdown when needed, so > > that the old and good way of network configuration is respected. > > wicd has the same functionalities than network-manager and is > compatible with ifconfig and the like. I considered using wicd some time ago, but gave up after reading information from its FAQ: http://wicd.sourceforge.net/moinmoin/FAQ -- Stanislav -- 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/20110404193420.GA2344@kaiba.homelan
Re: Back to technical discussion? Yes!
On Mon, Apr 04, 2011 at 12:30:24PM -0700, Russ Allbery wrote: [skipped] > "It is a profoundly erroneous truism, repeated by all copy-books and by > eminent people when they are making speeches, that we should cultivate the > habit of thinking of what we are doing. The precise opposite is the case. > Civilisation advances by extending the number of operations we can perform > without thinking about them." -- Alfred North Whitehead This turns backward immediately as you face a need to do something less trivial than that is supported by the ready-to-use tool of your choice. > That said, for simple server network configuration patterns, ifupdown just > works. Sure. But it also works in complicated configuration patterns that are not supported by any of the available click-n-go solutions. [skipped] > That said, of course for a server build one can just remove Network > Manager and install ifupdown and go on with life. Removing NM after a _successful_ installation is not a problem, of course. But are you sure that, for instance, an unattended network install will complete successfuly with NM in the background if the network connection blinks for a moment? Or if the system dbus service is restarted at a certain stage of installation? I would expect NM in such situations to begin reconfiguring network interfaces (or just go crazy) with all possible (and generally unpredictable) consequences (disclaimer: those are my random guesses). I very much dislike the idea of making NM the default, but if we decide to go this way, then there must be an option in the installer to disable the use of NM altogether in the very early stages of the installation. -- Stanislav -- 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/20110404204644.GA3233@kaiba.homelan
Re: Back to technical discussion? Yes!
On Mon, Apr 04, 2011 at 10:03:12PM +0200, Michelle Konzack wrote: > What I do not understand is WHY the Debian Project can not do an install > in two steps. I mean installing the bare base using "ifupdown" and if > the user choose the Desktop-Task replace it with NM. AFAICT, the main concerns with the current ifupdown-based installation process is that its suport of wireless networks is very limited: only WEP is supported, and there are problems with lost connections. I am pretty sure that these problems may be addressed without replacing all the infrastructure and switching to NM, though. -- Stanislav -- 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/20110404205554.GA5668@kaiba.homelan
Re: network-manager as default? No! (was: Bits from the Release Team - Kicking off Wheezy)
On Mon, Apr 04, 2011 at 11:17:59PM +0200, Michelle Konzack wrote: > Hello Stanislav Maslovski, > > Am 2011-04-04 01:11:15, hacktest Du folgendes herunter: > > On Sun, Apr 03, 2011 at 11:26:20PM +0530, Josselin Mouette wrote: > > > May I suggest that you install a squeeze system with the desktop task, > > > with a simple DHCP network configuration? > > Why on earth would I do that? It does not match my needs at all. For > > instance, this laptop sometimes connects to a couple of remote LANs > > through VPNs, so that I have to set up routing in a not completely > > trivial manner. On another site where I sometimes work, there is an > > IPX network to which I have to connect to access the fileserver. > > Occasionaly, I have to run another OS in a virtual machine on this > > laptop for which I set up a bridge, etc. > > And HOW MANY users have such special case? I have in Strasburg and its > Region 37 customers and do not need such killer config. Well, that is not the question of how many, that is the question of can you do a given task or not with a given tool. NM is limited in all possible ways I can imagine, and also buggy. On the contrary, with ifupdown, one for sure can do things that I even cannot imagine due to my limited knowledge. Feel the difference ;) -- Stanislav -- 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/20110404220829.GA9539@kaiba.homelan
Re: Back to technical discussion? Yes! (was: network-manager as default? No!)
On Mon, Apr 04, 2011 at 07:39:23PM -0300, Fernando Lemos wrote: > On Mon, Apr 4, 2011 at 6:23 PM, Mathieu Trudel-Lapierre > wrote: > [...] > > This said, I don't think NM can be the magic bullet to fix everything. > > Even RedHat while shipping NetworkManager on servers last I checked, > > still relies on their simpler command-line setup for interfaces. So > > should we. Defaulting to using NM probably takes care of the widest > > audience who would use DHCP and such, and others can fall back to > > ifupdown or a successor to do the more complicated things like > > bridging. > > Also note that there are NM plugins that enable NM to understand > /etc/network/interfaces and the Fedora/RHEL counterparts. This means > that if a server has NM enabled and an administrator wants to > configure networking manually, he can do it just fine even if NM is > installed. NM will gracefully understand that and won't try to do > anything stupid (see /etc/NetworkManager/NetworkManager.conf). The mentioned plugin is nothing more than just a rather primitive parser intended to read a limited set of common interface settings such as ip addresses, netmasks, dns servers, etc., from the existing /e/n/interfaces file for the ease of transition. The plugin simply translates these settings into the internal representation of NM. It is not intended to interoperate with the ifupdown infrastructure in any other way. Therefore, it is generally useless for an administrator that wants to configure network interfaces manually. > For servers using DHCP, you don't even have to create a connection. > Wired interfaces are already automatically configured to use DHCP in > NM. For the other cases, just use the legacy tools or configure > /etc/network/interfaces and set managed=true Accordingly to docs here http://live.gnome.org/NetworkManager/SystemSettings that should be actually "managed=false" if you want an interface to be completely ignored by NM. > in /etc/NetworkManager/NetworkManager.conf (not sure if the latter > works, never tested it). -- Stanislav -- 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/20110405002005.GA11761@kaiba.homelan
Re: Back to technical discussion? Yes!
On Tue, Apr 05, 2011 at 07:08:19AM +0100, Brett Parker wrote: > On 05 Apr 00:55, Stanislav Maslovski wrote: > > On Mon, Apr 04, 2011 at 10:03:12PM +0200, Michelle Konzack wrote: > > > What I do not understand is WHY the Debian Project can not do an install > > > in two steps. I mean installing the bare base using "ifupdown" and if > > > the user choose the Desktop-Task replace it with NM. > > > > AFAICT, the main concerns with the current ifupdown-based installation > > process is that its suport of wireless networks is very limited: only > > WEP is supported, and there are problems with lost connections. I am > > pretty sure that these problems may be addressed without replacing all > > the infrastructure and switching to NM, though. > > It is?! I better tell my /etc/network/interfaces that those wpa keys in > there shouldn't work... Well, I guess you did not read the text you replied to. That was about the problems with Debian installer, not with ifupdown-based setups in general. As you may have noticed, I have been trying to convince people that ifupdown and wpa may work perfectly when properly configured since yesterday. Therefore I believe that the known problems with installer can be actually solved without switching to NM. > (I use ifupdown on my laptop *lots*, it has *several* wireless > configurations in /etc/network/interfaces, and a magical mapping script > that uses iwlist scan to check where we are... it all "just works" > including the WPA configuration...) So do I, and it just works. -- Stanislav -- 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/20110405065935.GA3684@kaiba.homelan
Re: Back to technical discussion? Yes!
On Tue, Apr 05, 2011 at 09:10:47AM +0200, Tollef Fog Heen wrote: > ]] Stanislav Maslovski > > | AFAICT, the main concerns with the current ifupdown-based installation > | process is that its suport of wireless networks is very limited: only > | WEP is supported, and there are problems with lost connections. I am > | pretty sure that these problems may be addressed without replacing all > | the infrastructure and switching to NM, though. > > d-i doesn't use ifupdown, it uses netcfg. Hm, okay, I was pretty sure J.M. at some point mentioned replacing ifupdown _in the installer_ with network manager… Then, the current limitations of the installer are not even related to ifupdown at all. That is a good news. -- Stanislav -- 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/20110405080942.GA6830@kaiba.homelan
Re: Back to technical discussion? Yes!
On Tue, Apr 05, 2011 at 12:09:42PM +0400, Stanislav Maslovski wrote: > On Tue, Apr 05, 2011 at 09:10:47AM +0200, Tollef Fog Heen wrote: > > ]] Stanislav Maslovski > > > > | AFAICT, the main concerns with the current ifupdown-based installation > > | process is that its suport of wireless networks is very limited: only > > | WEP is supported, and there are problems with lost connections. I am > > | pretty sure that these problems may be addressed without replacing all > > | the infrastructure and switching to NM, though. > > > > d-i doesn't use ifupdown, it uses netcfg. > > Hm, okay, I was pretty sure J.M. at some point mentioned replacing > ifupdown _in the installer_ with network manager… Then, the current > limitations of the installer are not even related to ifupdown at all. > That is a good news. Yes, he did. Here: "On my personal wishlist for wheezy is d-i actually calling NM behind the scenes to configure the network, instead of ifupdown. I'll definitely try to find time to hack on this. -- .''.Josselin Mouette" -- Stanislav -- 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/20110405082156.GA7988@kaiba.homelan
Re: network-manager as default? No! (was: Bits from the Release Team - Kicking off Wheezy)
On Wed, Apr 06, 2011 at 07:29:05AM +0200, Josselin Mouette wrote: > Le mardi 05 avril 2011 à 02:08 +0400, Stanislav Maslovski a écrit : > > Well, that is not the question of how many, that is the question of > > can you do a given task or not with a given tool. NM is limited in all > > possible ways I can imagine, and also buggy. On the contrary, with > > ifupdown, one for sure can do things that I even cannot imagine due to > > my limited knowledge. > > Your limited knowledge is like jam. The less you have, the more you > spread it. Thanks, I also love how you show your bitching side on this mailing list when you have no better arguments. > What you actually like about ifupdown is that it cannot do anything but > extremely trivial setups. No, you are wrong. > Then you can stack all soft of stuff on top of it, and get them to > work manually for your specific setup, and since it’s not event-based > you have to hard-code the way your network is set up. I am just following the best practices that are currently available. -- Stanislav -- 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/20110406165218.GA5910@kaiba.homelan
Re: network-manager as default? No! (was: Bits from the Release Team - Kicking off Wheezy)
> On Wed, Apr 06, 2011 at 07:29:05AM +0200, Josselin Mouette wrote: > > Then you can stack all soft of stuff on top of it, and get them to > > work manually for your specific setup, and since it’s not event-based > > you have to hard-code the way your network is set up. ^^ The underlined claims, btw, are also false. -- Stanislav -- 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/20110406170511.GA7397@kaiba.homelan
Re: network-manager as default? No! (was: Bits from the Release Team - Kicking off Wheezy)
On Wed, Apr 06, 2011 at 10:51:08PM +0200, Hendrik Sattler wrote: > Am Mittwoch 06 April 2011, 19:05:11 schrieb Stanislav Maslovski: > > > On Wed, Apr 06, 2011 at 07:29:05AM +0200, Josselin Mouette wrote: > > > > Then you can stack all soft of stuff on top of it, and get them to > > > > work manually for your specific setup, and since it’s not event-based > > > > > > > > > > you have to hard-code the way your network is set up. > > > > ^^ > > The underlined claims, btw, are also false. > > You made clear that you think of yourself as the ultimate master of ifupdown. > So what? That tells us _nothing_ about the rest of the world... First of all, that is only your interpretation which is wrong. Second, there is no point in turning a discussion about ifupdown vs. NM into a discussion of my abilities/disabilities. -- Stanislav -- 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/20110407040959.GA16611@kaiba.homelan
Re: A few observations about systemd
On Mon, Jul 25, 2011 at 11:26:23AM +0100, Roger Leigh wrote:
> Do we actually have a standardised interface that can disable a service
> and then reenable it so that it is in exactly the same state as before
> it was disabled, without requiring black magic and/or prior knowledge
> of the correct runlevels? update-rc.d certainly isn't it.
Hm. But what exactly is wrong with update-rc.d enable | disable ?
It seems to do what you want (in the case there is no black magick in
/etc/default, of course, or simply when {ENABLE|RUN|WHATEVER}=yes by
default).
--
Stanislav
--
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/2011073946.GA21330@kaiba.homelan
Bug#636262: ITP: kbdd -- Per-window keyboard layout switching daemon for X
Package: wnpp Severity: wishlist Owner: Stanislav Maslovski * Package name: kbdd Version : 0.6 Upstream Author : Alexander V. Vershilov * URL : https://github.com/qnikst/kbdd * License : GPL Programming Lang: C Description : Per-window keyboard layout switching daemon for X KBDD stands for keyboard daemon. It is a simple keyboard layout switching program, which is designed to run in an X11 session and remember keyboard layouts on a per-window basis. That can be very handy for a user of a non-US keyboard who does not want to jump through layouts back and forth while typing in terminals (mostly in latin) and some kind of chat in her native language. Another useful thing about KBDD is its D-Bus notification support — it can emit signals on layout change, thus, making it possible to create layout indicator widgets in such window managers as awesome, for example. -- Stanislav -- 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/20110801203229.18008.56708.reportbug@kaiba.homelan
Re: Bug#636262: ITP: kbdd -- Per-window keyboard layout switching daemon for X
On Mon, Aug 01, 2011 at 11:48:29PM +0300, Timo Juhani Lindfors wrote: > Hi, > > Stanislav Maslovski writes: > > Description : Per-window keyboard layout switching daemon for X > > How does this relate to the Gnome System->Keyboard->Layouts dialog that > already in squeeze has the option to have separate layout for each > window: > > "[ ] Separate layout for each window" Not everyone uses gnome/kde/etc. > Is kbdd mainly targeted for non-GNOME users? Yes. The target group of users of this software are those who are aware of xxkb and friends, but want a tool that also works with nonreparenting window managers. -- Stanislav -- 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/20110801213204.GA23537@kaiba.homelan
Re: Bug#636262: ITP: kbdd -- Per-window keyboard layout switching daemon for X
On Mon, Aug 01, 2011 at 11:16:22PM +0200, Samuel Thibault wrote: > Stanislav Maslovski, le Tue 02 Aug 2011 00:32:29 +0400, a écrit : > > KBDD stands for keyboard daemon. It is a simple keyboard layout > > switching program, which is designed to run in an X11 session and > > remember keyboard layouts on a per-window basis. > > Err, I guess it watches for the currently active window, and on switch, > switches the whole X server keyboard layout? That's a costly approach, > when you can much more efficiently redirect the keymap updates, to send > the appropriate keymap update to the appropriate windows just once and > be done with it without having to watch window switch. Tell me when you have it programmed and ready for use, I will be happy to package it for Debian. -- Stanislav -- 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/20110801213649.GB23537@kaiba.homelan
