Bug#576881: ITP: fsmap -- Graphical description in a concept map of the free software world
Package: wnpp Severity: wishlist Owner: René Mérou Owner: René Mérou * Package name: fsmap Version : 3 Upstream Author : René Mérou * URL : http://es.gnu.org/~reneme/fsmap/ * License : GFDL Description : Graphical description in a concept map of the free software world fsmap, Free Software Concept Map, is a visual document to understand free software in a view. It expresses the its meaning by drawing relations with source code, distribution, free software freedoms, human values, developers, and other relaterd terms. -- 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/20100407233251.12133.50083.report...@privateso.localdomain
Inconsistent naming of ethernet interfaces...
I have a computer system with 3 ethernet ports, one on the motherboard and two on a dual NIC PCI card. Typically, the onboard port is aliased as eth0 while the ports on the NIC get assigned eth1 and eth2. Lately, eth1 gets assigned to the onboard port, which is very annoying since that messes up my connections to the internet and LAN subnets. I know this is a problem that many people have complained about when upgrading their kernel from 2.4.x to 2.5.x or 2.6.x. For some people this problem happens when they upgrade their hardware (as it did for me). I understand that one way to fix the naming of the interfaces is to use the nameif utility and store the static interface-to-mac mappings for my system in /etc/mactab. I've gotten this to work with trivial effort. So far so good. In the future, if I swap out my dual NIC with a newer one, I'd like a way to be able to produce the new mappings automatically. Perhaps I could do it like this for a port I want to call "eth1": 1- Connect ethernet loopback plug to port 2- Run my script, which does this: a. determine that I am trying to configure eth1 b. probe all ports to see which has loopback activity. c. store the mac addr of that port in mactab (along with eth1 tag) 3- Done. This is a simple self-calibration procedure. But I'm guessing somebody has some thoughts on how to better implement this. This will be especially useful to someone who is trying to ship a large number of computers pre-configured with Debian, and they want to ensure that eth0 is always the onboard port, eth1 is the left port on the dual nic, and eth2 is the right port on the dual nic, and so on. Any thoughts will be appreciated. Thanks, Salman __ Do you Yahoo!? Yahoo! Mail - now with 250MB free storage. Learn more. http://info.mail.yahoo.com/mail_250 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Large ramdisks, kernel memory space issue
Hi All, I'm using a slightly modified Debian kernel along with PXELinux to boot a machine over the network. My kernel's memory footprint is quite large (400 megs) because it pre-allocates memory for some processes (in the interest of speedier process execution). My ramdisk size is about 500 megs. Now, the ramdisk has to fit in the lower 1 Gig of memory which the kernel can access. So a ramdisk bigger than 500 megs cannot be loaded by the kernel, since the ramdisk would exceed the 1 Gig kernel memory space bound. My question: Is there an easy way make the Linux kernel be able to access the entire memory space? This way I can easily load larger ramdisks on my target machines which have 2 Gigs of physical memory. Thanks, Salman __ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Large ramdisks, kernel memory space issue
--- Goswin von Brederlow <[EMAIL PROTECTED]> wrote: > salman h <[EMAIL PROTECTED]> writes: > > > Hi All, > > > > I'm using a slightly modified Debian kernel along > with > > PXELinux to boot a machine over the network. > > > > My kernel's memory footprint is quite large (400 > megs) > > because it pre-allocates memory for some processes > (in > > the interest of speedier process execution). > > > > My ramdisk size is about 500 megs. > > > > Now, the ramdisk has to fit in the lower 1 Gig of > > memory which the kernel can access. So a ramdisk > > bigger than 500 megs cannot be loaded by the > kernel, > > since the ramdisk would exceed the 1 Gig kernel > memory > > space bound. > > > > My question: Is there an easy way make the Linux > > kernel be able to access the entire memory space? > This > > way I can easily load larger ramdisks on my target > > machines which have 2 Gigs of physical memory. > > > > Thanks, > > > > Salman > > Just a thought but why not load the ramdisk > yourself. > > Write a small initrd that sets up large ramdisk and > downloads an image > from the network. > > MfG > Goswin There's no reason why that would not work. Except the constraints of my problem are such that I may not always have the network available for downloading a second ramdisk. I realize I mentioned PXELinux and network booting earlier. But let us say I was using ISOLinux for CD booting without network connectivity. I suppose I could store the second ramdisk on the CD and mount it from there during init. So that would work as well. It looks like the best solution right now. Thanks for you help. Salman __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Large ramdisks, kernel memory space issue
--- "J.A. Bezemer" <[EMAIL PROTECTED]> wrote: > > On Fri, 15 Apr 2005, salman h wrote: > > > Hi All, > > > > I'm using a slightly modified Debian kernel along > with > > PXELinux to boot a machine over the network. > > > > My kernel's memory footprint is quite large (400 > megs) > > because it pre-allocates memory for some processes > (in > > the interest of speedier process execution). > > > > My ramdisk size is about 500 megs. > > > > Now, the ramdisk has to fit in the lower 1 Gig of > > memory which the kernel can access. So a ramdisk > > bigger than 500 megs cannot be loaded by the > kernel, > > since the ramdisk would exceed the 1 Gig kernel > memory > > space bound. > > This 1GB boundary makes me think of the High Memory > support (CONFIG_NOHIGHMEM) > kernel config option. You might want to try > different values for that option, > even though they might not be intuitively applicable > to your case. > > Regards, > Anne Bezemer What you said makes sense. I spent some time reading up on the memory organization structure of linux. It lead me to believe that if I enable CONFIG_HIMEM in the kernel the it would be able to access the entire 4GB memory address space. I tried that, but no success. Googling around, I found a simple write-up on kernel memory organization which had a link to a patch to split kernel/user memory allocation. Here is the link to the article: http://kerneltrap.org/node/2450 That didn't work either though. So I'm still fairly confused about how the kernel manages higher memory. Perhaps there's a hard upper-limit on the size of the initial ramdisk? I don't know... Anyway, another user suggested a feasible sounding solution: Make the initrd small enough to fit in low mem. Mount more ramdisks later during the init process (either by downloading from the server, or from the CD if using ISOLinux, etc). I hope that makes sense. Thanks for your help. Salman __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Great find!!!
Check this out! I've found this great site! The girls are hot and the pics are even hotter! And man can they talk the talk. Great Buzz! A definite must see. www.seemetextme.com/girls -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Great find!!!
Check this out! I've found this great site! The girls are hot and the pics are even hotter! And man can they talk the talk. Great Buzz! A definite must see. www.seemetextme.com/girls -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#4012: xbase: `window-managers' was un-correctly generated
Package: xbase Version: 3.1.2-9 I believe that the 3 first extra explanatory lines in file `xbase.postinst' of this package should be removed as they trigger unexpected result in some cases (can go into an infinite loop as Xsession will call itself if you start X from /etc/X11 for instance). I'm including the offending portions of the corresponding files here after. Thanks for the efforts of all Debian's developers and keep the good work guys. == /etc/X11/Xsession = if [ -e /etc/X11/window-managers ] then for i in cat `/etc/X11/window-managers` do if [ -x $i ] then exec $i fi done fi == == xbase.postinst cat >/etc/X11/window-managers <
Re: Fwd: /etc/hosts and resolving of the local host/domainname - 127.0.0.1 vs. 127.0.1.1
On Mon, 5 Aug 2013 13:08:28 -0400, Thomas Hood wrote: (I had an exchange of emails with Thomas off-list and he suggested that I reply on-list.) > With the nsswitch configuration > > hosts: files ... dns ... myhostname > > myhostname resolves the system hostname if nothing else does so > first. So it can be overridden either by DNS or by /etc/hosts. If > the system hostname changes, no file has to be edited. Nice. > > Also nice is the fact that myhostname resolves the system hostname > to an external address if there is one, increasing the chances that > the result is similar to what would be obtained from DNS. The output below is from Debian Sid with libnss-myhostname installed and Fedora 19. On Debian, getent outputs the system's IP address for 127.0.1.1, whereas on Fedora, getent outputs 127.0.0.2 for 127.0.0.2. Debian Sid [root@debdeb:/etc]# cat hostname debdeb [root@debdeb:/etc]# cat hosts 127.0.0.1 localhost [root@debdeb:/etc]# getent hosts 127.0.1.1 192.168.1.250 debdeb Fedora 19 [root@fedfed:/etc]# cat hostname fedfed.defdef [root@fedfed:/etc]# cat hosts 127.0.0.1 localhost [root@fedfed:/etc]# getent hosts 127.0.0.2 127.0.0.2 fedfed.defdef -- 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/5204124c.7030...@gmail.com
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Wed, 30 Oct 2013 21:50:53 -0400, Theodore Ts'o wrote: > > It's not necessarily the init script author who might want the degrees > of freedom, but the local system administrator. > > The most basic is the idea that whether you can control (via shell > scrpit fragments) whether or not a service should start at all, and > what options or environments should be enabled by pasing some file. > The fact that we can put that sort of thing in configuration files > such as /etc/default/*, for example. > > Yes, yes, you can do this via if you use system V init scripts scripts > in backwards compatibility mode, but you've argued that we should be > moving briskly away from that. In which case system administrators > will need to hand-edit the services files by hand, which will no doubt > increase the chances of conflicts at package upgrade time, compared to > if the configuration options were isolated away in files such as > /etc/default/rsync (for example). Both upstart and systemd allow you to source any file and run any script from their .conf/.service files. In Fedora 19: You can source anything with "EnvironmentFile=" and run anything from "ExecStartPre=", "ExecStart=", "ExecStartPost=". "/usr/lib/systemd/system/iptables.service" has "ExecStart=/usr/libexec/iptables/iptables.init start" where "/usr/libexec/iptables/iptables.init" is the "/etc/rc.d/init.d/iptables" sysvinit script of Fedora 15. iptables also has "/usr/libexec/initscripts/legacy-actions/iptables/save" and it runs "exec /usr/libexec/iptables/iptables.init save". Also, "/usr/lib/systemd/system/nfs-server.service" sources "/etc/sysconfig/nfs" with "EnvironmentFile=/etc/sysconfig/nfs" and runs scripts in "/usr/lib/nfs-utils/scripts/". (It's surprising that there isn't a canonical location for custom systemd scripts. I don't have an Arch instance on which to check, but AFAIK its iptables.service calls a script that's in "/usr/lib/systemd/scripts/".) In Ubuntu 13.10: I would've liked to compare like for like but neither iptables-persistent and nfs-kernel-server have upstart jobs. Let's assume that "/etc/init/nfs-kernel-server.conf" exists and that you want to override it. # vi /etc/init/nfs-kernel-server.override ... script [ -r /home/ted/ted-nfs-kernel-server ] \ && . /home/ted/ted-nfs-kernel-server end script -- 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/5272144a.3000...@gmail.com
Bug#729535: general: mouse sometimes slow upon boot. must reboot to fix.
Package: general Severity: important Dear Maintainer, *** Please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these lines *** Rebooted system after work (cold boot), and logged into my user name, started up X and my mouse was very slow and unresponsive. Sometimes freezing. If frozen I have to switch to another virtual terminal, and then switch back to X to un- freeze it. When it's slow, switching between the terminal and X does nothing. I have to reboot the entire system and log back in, fire up X and the mouse is then responsive again. I do this a few times a day and it's quite a pest. -- System Information: Debian Release: 7.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- 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/20131114002118.4388.72814.reportbug@debian
default init on non-Linux platforms
On Thu, 20 Feb 2014 14:19:30 +0900, hero...@gentoo.org wrote: > Tollef Fog Heen writes: >> >> It's probably better to just contribute your changes to the sysv-rc >> version and so make that one able to manage openrc in addition to the >> others it already knows how to. No point in forking it. > > Forking was a decision made by me in the early phase of packaging > OpenRC. At that time I referred to the way file-rc handled update-rc.d > as in > > sysvinit: /usr/share/sysvinit/update-rc.d > > A central package providing update-rc.d and invoke-rc.d is nice. > Though it should not be sysv-rc, which OpenRC is intending to replace. What features does sysvinit+openrc have that sysvinit+sysv-rc+insserv doesn't have? https://wiki.debian.org/Debate/initsystem/openrc doesn't make that case and none of the members of the CTTE explained their "openrc > sysvinit" votes (unless I missed that point in the 100s/1000s of #727708 posts). -- 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/5305fcf8.90...@gmail.com
default init on non-Linux platforms
On Thu, 20 Feb 2014 22:28:56 +0800, Thomas Goirand wrote: > On 02/20/2014 09:02 PM, Tom H wrote: Thanks for your answer and apologies for the delay in responding but my $dayjob's been keeping me very busy. >> What features does sysvinit+openrc have that sysvinit+sysv-rc+insserv >> doesn't have? You're being unfair to sysvinit+sysv-rc+insserv, although I have to admit that openrc is better and more cleanly designed from a user perspective because the combination of rc-update, rc-service, and rc-status is better than using service except to enable/disable a service where you have to use update-rc.d - and, if you want an output that's more human-friendly than "insserv -s", you have to install and use chkconfig. > Just to name a few: > - getting rid of the ugly LSB headers Beauty is in the eye of the beholder. The "Short-Description" and "Description" LSB fields are useless, but I don't find Debian's LSB headers and Gentoo's squiggle-delimited stanzas any more beautiful or uglier than the other. What's important is that they do the job of allowing their respective rc routines order the startup - and they both do so. As a sysadmin who works with different distributions, I find it quite frustrating that sysv-rc uses "Required-Start" and Should-Start", openrc "need" and "use", and systemd "Requires" and "Wants" to mean the same thing. Although it's not difficult to keep track of what's what, why should we have to? > - cgroup supports to kill processes IIRC, Patrick Lauer claimed to have written openrc's cgroup support in one afternoon. And IIUC that support'll have to rewritten once the kernel's cgroup maintainer makes the changes that he's announced and non-systemd sysinits have to use Ubuntu's in-development cgroup manager (since systemd's cgroup manager's integrated into its pid 1). > - rc_hotplug (a hotplugged service is one started by a dynamic dev > manager when a matching hardware device is found). AIUI openrc simply leverages udev to hotplug devices; but I'm only an occasional Gentoo user so I might have misundertood the process. > - Checks if a daemon is really started by start-stop-daemon > - Dependency loop breaking system What does this mean? That there are bugs in the dependency headers in the 1000-odd initscripts in Debian where openrc can work through the problem and insserv send you to the BTS? > - Named runlevels (I already talked about that) I don't see this as a must-have feature. The default runlevels of sysinit, boot, default, single, reboot, shutdown where "sysinit" groups the services that are started in single-user mode and "boot" groups the services that are started by "default" and any user-defined runlevel but aren't started in single-user mode. However, the only one that you can switch to by name is "default" (with "rc default"). For the others, you have to use "init " just like sysv-rc. In Gentoo, it makes sense to use named runlevels because if you install rsyslog, for example, you have to run "rc-update add rsyslog default" to ensure that rsyslog is started at boot. I guess that it makes more sense that running "rc-update add rsyslog 3" but in Debian, the maintainer scripts take care of this. If a Debian user wants to create a custom runlevel, calling it "4" or "thomasg" isn't that big a deal. There's also a weird relationship between named levels, possibly because "default" is special-cased. I don't have a Gentoo box at hand to retest this but I did do this in the past. When you boot to the "default" runlevel, "who -r" return "3". If you run "init 5", the runlevel switches to "5" instantaneously, and "rc-status --all" lists all the same services as "started". If you boot to the "default" runlevel, rename "/etc/runlevels/default" to "/etc/runlevels/thomasg", and run "init 5", the runlevel switches to "5" by shutting down the daemons in "thomasg", and "rc-status --all" lists the sysinit and boot services as "started" and the thomasg services as "stopped". Perhaps you'd have to run "rc thomasg" before "init 5" for the "thomasg" daemons not to be stopped but it's non-intuitive. I know that it's a contrived, artificial (mis)manipulation that's unlikely in a real-world situation but there does seem to be a disconnect somewhere. > - Stateful system (see rc-status) see insserv > - Dependency caching system (so you wont have to wait for its &
Re: Request for testing: /run and initscripts
Roger, I could not find any references to debootstrap installations with the new /run setup. How is debootstrap - and any other program installing Debian - supposed to handle /run, esp. with the initscripts postinst detecting chroots and it not bringing in the preferred setup? Thanks, -ch (Please keep me CC'ed.) signature.asc Description: Digital signature
Re: Anonymous read-only access and Vcs-* [Re: Alioth status update, take 3]
On Thu, Jun 9, 2011 at 6:43 AM, Tollef Fog Heen wrote: > [various URLs have been fixed] http://pkg-java.alioth.debian.org/ has a link to http://git.debian.org/?s=pkg-java . This doesn't give a flat 404, but an index page that's rather useless. I suppose a flat redirect from http://git.debian.org to http://anonscm.debian.org/gitweb isn't possible? Thanks, -ch -- 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/banlktik-myjptejbvwiy17+hyh9d98s...@mail.gmail.com
Bug#632642: ITP: qasmixer -- mixer for the sound system ALSA powered by a QT GUI
Package: wnpp Severity: wishlist Owner: "Sebastian H." * Package name: qasmixer Version : 0.12.1 Upstream Author : Sebastian Holtermann * URL : http://www.xwmw.org/qasmixer/ * License : GPL-3 Programming Lang: C++ Description : mixer for the sound system ALSA powered by a QT GUI QasMixer is a graphical mixer application for the Linux sound architexture ALSA. It is powered by a QT4 GUI with customized slider and checkbox widgets that dynamically adjust their size to use the available window space optimally. By using the ALSA mixer interface QasMixer aims to stay close to the sound hardware without any intermediate abstraction layers. This also means that it shows the same sliders and switches as the console alsamixer. Closes: #n -- 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/2011070438.6629.45630.reportbug@blauwal
Re: Q: why binary-log by systemd-journald is not enabled by default?
On Tue, May 12, 2015 at 7:10 AM, Piotr Ożarowski wrote: > [Hideki Yamane, 2015-05-10] >> On Sun, 10 May 2015 00:56:43 -0300 >> Henrique de Moraes Holschuh wrote: >>> >>> And I wish it would keep /var/log/dmesg (and its rotation). That thing is >>> really useful for user support when dealing with kernel and boot issues. >> >> Is it enough to ask users to exec "sudo journalctl"? > > IMO a better idea is to add them to systemd-journal group Shouldn't "systemd-*" groups be reserved for systemd system accounts? th@localhost:~$ grep systemd /etc/passwd systemd-timesync:x:100:104:systemd Time Synchronization,,,:/run/systemd:/bin/false systemd-network:x:101:105:systemd Network Management,,,:/run/systemd/netif:/bin/false systemd-resolve:x:102:106:systemd Resolver,,,:/run/systemd/resolve:/bin/false systemd-bus-proxy:x:103:107:systemd Bus Proxy,,,:/run/systemd:/bin/false th@localhost:~$ grep systemd /etc/group systemd-journal:x:102: systemd-journal-remote:x:103: systemd-timesync:x:104: systemd-network:x:105: systemd-resolve:x:106: systemd-bus-proxy:x:107: I can run "journalctl" as non-root because I'm a member of "adm". th@localhost:~$ id uid=1000(th) gid=1000(th) groups=1000(th),4(adm),27(sudo),46(plugdev),115(lpadmin) th@localhost:~$ journalctl -- Logs begin at Tue 2015-05-12 08:19:51 EDT, end at Tue 2015-05-12 08:34:59 EDT. -- May 12 08:19:51 localhost.localdomain systemd-journal[232]: Runtime journal is using 8.0M (max allowed 78.9M, trying to leave 118.4M free of 781.2M available → current limit 78.9M). May 12 08:19:51 localhost.localdomain systemd-journal[232]: Runtime journal is using 8.0M (max allowed 78.9M, trying to leave 118.4M free of 781.2M available → current limit 78.9M). May 12 08:19:51 localhost.localdomain kernel: Initializing cgroup subsys cpuset May 12 08:19:51 localhost.localdomain kernel: Initializing cgroup subsys cpu May 12 08:19:51 localhost.localdomain kernel: Initializing cgroup subsys cpuacct It's set up by "systemd-tmpfiles-setup.service". th@localhost:~$ grep '/run/log/journal' /usr/lib/tmpfiles.d/* /usr/lib/tmpfiles.d/systemd.conf:z /run/log/journal 2755 root systemd-journal - - /usr/lib/tmpfiles.d/systemd.conf:Z /run/log/journal/%m ~2750 root systemd-journal - - /usr/lib/tmpfiles.d/systemd.conf:a+ /run/log/journal/%m - - - - d:group:adm:r-x /usr/lib/tmpfiles.d/systemd.conf:A+ /run/log/journal/%m - - - - group:adm:r-x th@localhost:~$ grep '/var/log/journal' /usr/lib/tmpfiles.d/* /usr/lib/tmpfiles.d/systemd.conf:z /var/log/journal 2755 root systemd-journal - - /usr/lib/tmpfiles.d/systemd.conf:z /var/log/journal/%m 2755 root systemd-journal - - /usr/lib/tmpfiles.d/systemd.conf:a+ /var/log/journal/%m - - - - d:group:adm:r-x /usr/lib/tmpfiles.d/systemd.conf:A+ /var/log/journal/%m - - - - group:adm:r-x -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAOdo=sye7ppyqc_gcu2afaft_-anvkp6vuq-vxh2tgaaoaz...@mail.gmail.com
A little "research" on nvi given the vim-tiny issue
Russ A said [1] that nvi "is orphaned both upstream and in Debian". I wanted to emphasize that fact by pointing out that Gentoo's removing nvi for similar reasons, and trying to install it just now resulted in this "package.mask" message: $ sudo emerge -p nvi # Michał Górny (2020-02-17) # Based on very old code needing a lot of patches. Minimal upstream # activity since early 2011, last patches accepted in 2016. Multiple # unresolved bugs. app-editors/vim[minimal] is the recommended # replacement. # Removal in 30 days. Bug #690102. Arch uses "the traditional vi" [2], AFAICT, it was last released in 2005 and Arch has three patches for it. Arch's AUR has nvi from [3] version 1.79 and nvi-multibyte-upstream from [4] version 1.81. The three BSDs use nvi as "/usr/bin/vi". The READMEs indicate that FreeBSD has version 2.1.3, NetBSD has version 1.80, and OpenBSD has version 1.79. Version 1.81 has multibyte support and Debian and Gentoo use it. FreeBSD's version 2.1.3 is the result of a GSoC to add multibyte-encoding support [5]. That's when it jumped from 1.79 to 2.1.1. [1] https://lists.debian.org/debian-devel/2020/03/msg00243.html [2] http://ex-vi.sourceforge.net/ [3] https://sites.google.com/a/bostic.com/keithbostic/vi/ [4] https://repo.or.cz/nvi.git [5] https://github.com/lichray/nvi2 PS: Fedora's vim-minimal is vim configured using "--with-features=small". PPS: Gentoo's vim[minimal] is vim configured using "--with-features=tiny" like Debian's vim-tiny.
Re: A little "research" on nvi given the vim-tiny issue
On Thu, Mar 19, 2020 at 12:35 AM James McCoy wrote: > On Wed, Mar 18, 2020, 17:29 Tom H wrote: >> >> PPS: Gentoo's vim[minimal] is vim configured using >> "--with-features=tiny" like Debian's vim-tiny. > > Debian's vim-tiny actual uses "--with-features=small". We used to, > back in 2007, build a hybrid between small and tiny, by configuring > the tiny feature set and then enabling extra features. However, that > became too brittle to maintain and now most, if not all, of the > features we were enabling are enabled by default upstream. Sorry and many thanks. I assumed that "tiny" meant "tiny" :(
Re: Can we kill net-tools, please?
On Fri, Dec 30, 2016 at 2:32 AM, Andrey Rahmatullin wrote: > > Do you really think that > > wlp3s0: flags=4163 mtu 1500 > inet 192.168.** netmask 255.255.255.0 broadcast 192.168.** > inet6 fe80::** prefixlen 64 scopeid 0x20 > ether e4:**:ca txqueuelen 1000 (Ethernet) > RX packets 66323088 bytes 90518262611 (84.3 GiB) > RX errors 0 dropped 0 overruns 0 frame 0 > TX packets 18425793 bytes 2920636610 (2.7 GiB) > TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 > > is clearer than > > 3: wlp3s0: mtu 1500 qdisc mq state UP group > default qlen 1000 > link/ether e4:***:ca brd ff:ff:ff:ff:ff:ff > inet 192.168**/24 brd 192.168.** scope global dynamic wlp3s0 >valid_lft 70216sec preferred_lft 70216sec > inet6 fe80:**/64 scope link >valid_lft forever preferred_lft forever > > ? > > To me they are the same. Note that ifconfig too has cryptic uppercase > jumble and cryptic lowercase jumble and doesn't have any separators > between field names and values. Those used to ifconfig's old output might dislike its new output too: JESSIE # ifconfig en0 en0 Link encap:Ethernet HWaddr 08:00:27:31:6a:8c inet addr:192.168.43.242 Bcast:192.168.43.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 # ip a sh en0 2: en0: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 08:00:27:31:6a:8c brd ff:ff:ff:ff:ff:ff inet 192.168.43.242/24 brd 192.168.43.255 scope global en0 valid_lft forever preferred_lft forever STRETCH # ifconfig en0 en0: flags=4163 mtu 1500 inet 192.168.43.242 netmask 255.255.255.0 broadcast 192.168.43.255 ether 08:00:27:31:6a:8c txqueuelen 1000 (Ethernet) # ip a sh en0 2: en0: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 08:00:27:31:6a:8c brd ff:ff:ff:ff:ff:ff inet 192.168.43.242/24 brd 192.168.43.255 scope global en0 valid_lft forever preferred_lft forever The stretch output's similar to the output on the BSDs and Solaris...
Re: Can we kill net-tools, please?
On Fri, Jan 6, 2017 at 7:58 PM, Toni Mueller wrote: > On Thu, Dec 29, 2016 at 09:01:51PM +0500, Andrey Rahmatullin wrote: >> On Thu, Dec 29, 2016 at 10:30:26AM -0500, Theodore Ts'o wrote: >>> Ifconfig has been deprecated; you should probably use "ip a show >>> dev lo" instad of the shorter and more convenient "ifconfig lo" >> >> ... and often wrong > > The BSD ifconfig can do this with ease, and since ages, too. Why is > the Linux ifconfig _so_ different? Forking for the sake of it? Is there any relationship between current ifconfig on Linux and the BSDs, other than the name? I don't think so. The BSDs have continued to develop ifconfig, adding many features and options. > Eg adding an IPv6 address: > # ifconfig em0 inet6 address alias > > and removing it: > # ifconfig em0 inet6 address -alias On Linux, you can do the same with ipv6 ifconfig eth0 inet6 add ipv6_address but for ipv4 you have to label the NIC as an alias ifconfig eth0:0 ipv4_address You can use ip a sh lo (if you have bash-completion installed, "a" will complete to "addr" and "sh" will complete to "show") instead of "ip a show dev lo" above (still longer than "ifc though).
Re: Can we kill net-tools, please?
On Sun, Jan 8, 2017 at 10:55 AM, Andrey Rahmatullin wrote: > On Sun, Jan 08, 2017 at 10:49:23AM -0500, Tom H wrote: >> >> You can use >> >> ip a sh lo (if you have bash-completion installed, "a" will >> complete to "addr" and "sh" will complete to "show") >> >> instead of "ip a show dev lo" above (still longer than "ifc >> though). > > OTOH "ip a" is not longer than that. Sure. But I was replying to displaying "ip a" for a specific NIC.
Re: concerns about Salsa
On Tue, Jun 5, 2018 at 2:37 PM, Pierre-Elliott Bécue wrote: > Le lundi 04 juin 2018 à 12:54:32+0100, Ian Jackson a écrit : >> >> In practice, I have found that it is much easier to deploy a >> production service directly from its git tree. This makes it much >> easier to make changes. > > I've always found otherwise, ie that packaged stuff makes the > administrator of a service spare a lot of time. > > I wonder then, if a lot of people prefer deploy a service from > upstream's git repo/cookbooks, what is the purpose of packaging? Who > would benefit from it and who should use package-distros? In this case, isn't it because the service is being installed as and run by user "git"?
Re: policy for shipping sysctl.d snippets in packages?
On Sun, Apr 23, 2017 at 3:00 PM, Wouter Verhelst wrote:
>
> The "packages drop files in /usr/*, sysadmins override in /etc" way of
> doing things is prevalent in the RPM world; in Debian, however, we
> traditionally have packages drop files in /etc, and let the maintainer
> change them in place. This is possible, because our package management
> system deals better with changed files than does RPM (which must work
> silently, rather than confirming things with the user).
s/package management system deals better/package management system
deals differently/
rpm doesn't have a problem with config file handling and deals with
config files in a similar way that dpkg uses the "conffile" attribute
to deal with them. rpm spec files use two (one-and-a-half?) macros:
- "%config": "foo.conf" is replaced in an upgrade and saved as
"foo.conf.rpmsave";
- "%config(noreplace)": "foo.conf" isn't replaced in an upgrade and
the new "foo.conf" is installed as "foo.conf.rpmnew".
So rpm isn't a factor; upstreams drop files into "/usr/lib" because
Red Hat is pushing the concept of all/almost-all distro-provided files
in "/usr".
[OT: If I've *had* a complaint about
"/usr/lib/{modules-load.d,sysctl.d,tmpfiles.d}", it's that, when I
first looked for them on Debian, I expected them to be under "/lib"
and not "/usr/lib" given that systemd installs its boot-time files
under "/lib/systemd".]
Re: policy for shipping sysctl.d snippets in packages?
On Mon, Apr 24, 2017 at 9:10 AM, Adam Borowski wrote: > > All of this is caused by Red Hat having no support for upgrades: > > https://access.redhat.com/solutions/21964 > > # Red Hat does not support in-place upgrades between major versions 4, 5 and > # 6 of Red Hat Enterprise Linux. (A major version is denoted by a whole > # number version change. For example, Red Hat Enterprise Linux 5 and Red > # Hat Enterprise Linux 6 are both major versions of Red Hat Enterprise > # Linux). > # > # In-place upgrades across major releases do not preserve all system > # settings, services or custom configurations. Consequently, Red Hat > # strongly recommends fresh installations when upgrading from one major > # version to another. > > # Red Hat currently supports only upgrades from Red Hat Enterprise Linux 6 > # to Red Hat Enterprise Linux 7 for specific/targeted use cases only. > > On the other hand, being able to effortlessly dist-upgrade is one of biggest > reasons many of us have chosen Debian. The reason that you can't dist-upgrade RHEL is that there's too large a gap between releases. Let's look at the release dates and compare like with like. RHEL 6: November 2010 RHEL 7: June 2014 Debian 6 (squeeze): February 2011 Debian 7 (wheezy): May 2013 Debian 8 (jessie): April 2015 You can't dist-upgrade RHEL from 6 to 7 and you can't dist-upgrade Debian from 6 to 8 in one leap.
Re: policy for shipping sysctl.d snippets in packages?
On Wed, Apr 26, 2017 at 2:55 PM, Ben Hutchings wrote: > On Wed, 2017-04-26 at 07:53 -0400, Tom H wrote: >>> On Sun, Apr 23, 2017 at 3:00 PM, Wouter Verhelst wrote: >>> The "packages drop files in /usr/*, sysadmins override in /etc" way of >>> doing things is prevalent in the RPM world; in Debian, however, we >>> traditionally have packages drop files in /etc, and let the maintainer >>> change them in place. This is possible, because our package management >>> system deals better with changed files than does RPM (which must work >>> silently, rather than confirming things with the user). >> >> s/package management system deals better/package management system >> deals differently/ >> >> rpm doesn't have a problem with config file handling and deals with >> config files in a similar way that dpkg uses the "conffile" attribute >> to deal with them. rpm spec files use two (one-and-a-half?) macros: >> >> - "%config": "foo.conf" is replaced in an upgrade and saved as >> "foo.conf.rpmsave"; >> >> - "%config(noreplace)": "foo.conf" isn't replaced in an upgrade and >> the new "foo.conf" is installed as "foo.conf.rpmnew". > > I didn't know about this, and I'm pleased to see that this is (now) > possible. Is this documented somewhere? (I've never been able to find > documentation of RPM macros that isn't very old and incomplete.) I first used it with RHEL 3 for some company-developed apps but it might predate that. But Google says that it was available since at least RHL 9: http://people.ds.cam.ac.uk/jw35/docs/rpm_config.html Fedora has an rpm draft doc: https://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/RPM_Guide/index.html >> So rpm isn't a factor; > > It is, because rpm is non-interactive and the above choice has to be > made by the packager and not the adminsitrator. It must've slipped my mind because I disable the interactivity. Indeed, dpkg has the advantage that an administrator can change the behavior at run-time, for the current transaction or for all, but that flexibility doesn't give dpkg an advantage over rpm for dropping config files in "/etc" rather than in "/usr/lib". >> upstreams drop files into "/usr/lib" because >> Red Hat is pushing the concept of all/almost-all distro-provided files >> in "/usr".
Re: policy for shipping sysctl.d snippets in packages?
On Wed, Apr 26, 2017 at 8:12 PM, Luca Capello wrote: > On Wed, 26 Apr 2017 08:05:10 -0400, Tom H wrote: >> >> You can't dist-upgrade RHEL from 6 to 7 and you can't dist-upgrade >> Debian from 6 to 8 in one leap. > > Debian *does* support dist-upgrading between *following* releases only, > which is what we are talking about. > > And, in any case, for your example on Debian you will do 6 -> 7 -> 8. "in one leap"
Re: policy for shipping sysctl.d snippets in packages?
On Thu, Apr 27, 2017 at 2:34 AM, Brian May wrote: > On 2017-04-27 16:19, Andrey Rahmatullin wrote: >> >> It seems you've missed the point (which was about 4 years between RHEL >> releases). > > There was almost three years between Woody (July 19th 2002) and Sarge (June > 6th 2005), yet we still allowed upgrades from Woody to Sarge. > > The time duration is irrelevant. It is the policy we have that we support > and test upgrades that matters. It is much easier to ignore upgrades and > recommend to reinstall from scratch, that means we don't need to test and > debug why upgrades break under various corner cases. Not so good for our > users however. Did Linux development move as quickly as it does now? Did users experience more problems or failures when running those dist-upgrades? Of course duration matters. It's not the same use-case as a Debian dist-upgrade but feel free to look up gentoo-user@ threads where a user kicks them off with "I haven't upgraded for 6 months, 1 year, 3 years." The longer the period, the more problems. Simply because Debian supports dist-upgrades doesn't make them easy or doesn't make the duration between them irrelevant. We're on a more or less two-year cycle and it makes dist-upgrades easier that if we were on a 4-year cycle; I don't see what can possibly be debatable about this.
Re: policy for shipping sysctl.d snippets in packages?
On Thu, Apr 27, 2017 at 3:18 AM, Wouter Verhelst wrote: > On Wed, Apr 26, 2017 at 07:53:57AM -0400, Tom H wrote: >> On Sun, Apr 23, 2017 at 3:00 PM, Wouter Verhelst wrote: >>> >>> The "packages drop files in /usr/*, sysadmins override in /etc" way of >>> doing things is prevalent in the RPM world; in Debian, however, we >>> traditionally have packages drop files in /etc, and let the maintainer >>> change them in place. This is possible, because our package management >>> system deals better with changed files than does RPM (which must work >>> silently, rather than confirming things with the user). >> >> s/package management system deals better/package management system >> deals differently/ >> >> rpm doesn't have a problem with config file handling and deals with >> config files in a similar way that dpkg uses the "conffile" attribute >> to deal with them. rpm spec files use two (one-and-a-half?) macros: >> >> - "%config": "foo.conf" is replaced in an upgrade and saved as >> "foo.conf.rpmsave"; >> >> - "%config(noreplace)": "foo.conf" isn't replaced in an upgrade and >> the new "foo.conf" is installed as "foo.conf.rpmnew". > > Yes, I am aware of that (many of my customers use RedHat systems). > However, you will notice the complete absense of a "merge" option in the > above. This means that new configuration files are dropped on the > system, *without* any active notification to the user, so it's up to you > to figure out that this has happened and that you may have work to do. > > I didn't say RPM *doesn't* deal with changed files; I said ours deals > with it better. I stand by that. Sure; and an rpm or emerge user'll tell you that dpkg is inferior because an interactive upgrade's a crazy thing to do.
Re: policy for shipping sysctl.d snippets in packages?
On Fri, Apr 28, 2017 at 12:08 PM, Wouter Verhelst wrote: > On Fri, Apr 28, 2017 at 04:21:17AM -0400, Tom H wrote: >> >> Did Linux development move as quickly as it does now? >> Did users experience more problems or failures when running those >> dist-upgrades? > > RedHat also did not support upgrades back when they did not wait four > years to do finish a new release. They do not support them, because > they *choose* not to support them, instead telling people to reinstall. > > Yes, that makes it easier for them to wait four years between releases. > But I think you have cause and effect swapped around. I've never even tried to dist-upgrade RHEL but I have dist-upgraded RHL and Fedora. It was/is perfectly do-able but they both had/have shorter release cycles. IF Red Hat had felt that there was a market for dist-upgrade support, it could have offered it for a extra fee, just like it offers an extended support subscription for companies that want to stick to want to stick to a release beyond the standard EOL or to a minor release. It does offer an *unsupported* upgrade via anaconda.
Re: policy for shipping sysctl.d snippets in packages?
On Sun, Apr 30, 2017 at 2:22 PM, Wouter Verhelst wrote: > On Sat, Apr 29, 2017 at 03:48:09PM -0400, Tom H wrote: >> On Thu, Apr 27, 2017 at 3:18 AM, Wouter Verhelst wrote: >>> >>> I didn't say RPM *doesn't* deal with changed files; I said ours >>> deals with it better. I stand by that. >> >> Sure; and an rpm or emerge user'll tell you that dpkg is inferior >> because an interactive upgrade's a crazy thing to do. > > Yes, sure. This discussion is getting increasingly side-tracked though. > > The original question was "should I install defaults in /etc or /usr?" > to which I replied that in Debian, we've traditionally done the former > rather than the latter, and that the latter feels like a result of an > ecosystem (other than ours) where dealing with conflicting changes to > configuration files is frowned upon. I think our way is better, but > I'm sure others disagree. If Debian decides to drop into "/etc" files that are dropped into "/usr/lib" (or "/lib") upstream because rpm and others can't handle config file upgrades, it would be a decision not based on facts.
Re: Too many Recommends (in particular on mail-transport-agent)
On Thu, Jun 1, 2017 at 1:00 PM, Henrique de Moraes Holschuh wrote: > > The initramfs-tools does not depend or recommend mdadm. However, > initramfs-tools is modular and its mdadm support is supplied by the > mdadm package. > > Dracut isn't modular, and its mdadm support is built-in. This is a key > difference. > > One needs to actually read dracut's source code to know how it would > behave in all boundary conditions related to mdadm support, in which > case it might only suggest or not even mention mdadm. It probably is > safe, but the point is that someone has to check it first. If mdadm isn't available, dracut'll print a warning along the lines of "mdadm will not be installed".
Re: Too many Recommends (in particular on mail-transport-agent)
On Tue, Jun 6, 2017 at 9:55 AM, Adam Borowski wrote: > > dnsmasq-base: lxc > * BAD: how often are you on a network without a DNS server? The dnsmasq-base "recommends" is about providing a dhcp server for containers not a dns server. libvirt-daemon-system has the same "recommends" for its VMs.
Re: P.S. Re: Debian 9 in a VM with Proxmox 5 system
On Wed, Jul 12, 2017 at 2:40 PM, Roger Lynn wrote:
> On 10/07/17 19:40, Marvin Renich wrote:
>>
>> There is an easy fix to revert the default behavior while still allowing
>> knowledgeable sysadmins to get the new behavior. On the other hand,
>> those who need to administer systems but are not sysadmins by trade (and
>> thus will have to do significantly more research to even know that the
>> older behavior is possible) are the ones who need the older behavior as
>> the default.
>
> This caught me out on a recent new installation, which gave me these new
> names which are too complicated to be usable. I wasted hours working out
> what had happened, how to fix it and how to write a udev rules file from
> scratch. And having just read this thread, I've discovered that the rules
> I've written are themselves apparently unreliable, for example:
> SUBSYSTEM=="net", ATTR{address}=="1c:1b:0d:9a:34:98", NAME="eth0"
> SUBSYSTEM=="net", ATTR{address}=="1c:1b:0d:9a:34:9a", NAME="eth1"
It's simpler to use (for example)
# cat /etc/systemd/network/77-en0.link
[Match]
MACAddress=1c:1b:0d:9a:34:98
[Link]
Name=en0
# cat /etc/systemd/network/77-en1.link
[Match]
MACAddress=1c:1b:0d:9a:34:9a
[Link]
Name=en1
This rule works even if you use sysvinit as pid 1.
Renaming NICs within the kernel's "eth*" namespace is discouraged upstream.
Suppose that the kernel names "1c:1b:0d:9a:34:9a" "eth0" and
"1c:1b:0d:9a:34:98" "eth1". You'll have a renaming clash when udev
tries to apply your rules.
Re: Naming of network devices - how to improve it in buster
On Thu, Jul 13, 2017 at 12:22 AM, Russell Stuart wrote: > > I still don't understand what use case the current scheme is aimed at. Stateless "/etc". Systems with multiple NICs where the order in which they're recognized by the kernel can vary.
Re: Naming of network devices - how to improve it in buster
On Thu, Jul 13, 2017 at 6:14 AM, Russell Stuart wrote: > On Thu, 2017-07-13 at 05:20 -0400, Tom H wrote: >> >> Stateless "/etc". >> >> Systems with multiple NICs where the order in which they're >> recognized by the kernel can vary. > > I asked for a person. You raised more than one point. I was replying to "I still don't understand what use case the current scheme is aimed at." I don't know of a person who types the weird new names. I rename all my NICs "enX". But I don't think that many people end up with the "en48e244f61c1b" that you mentioned (it would anyway be "enx48e244f61c1b" not "en48e244f61c1b"). I'd expect the more common variants to be "enoX", "ensX", and "enpXsY". > I guess I really asking for a use case. > "Stateless /etc" isn't either. Why isn't "stateless /etc" a use-case?! Red Hat controls udev development. It or its customers might want to have such systems. > I've never seen the kernel vary the order it enumerates a PCI bus. It's happened to me. It's happened to ex-colleagues. When there isn't a file under "/etc" to map NIC name to NIC MAC address. > This isn't an accident. Quoting "According to: "PCI Express System > Architecture" R. Budruk, D. Anderson, T. Shanley, ADDISON-WESLEY > DEVELOPER´S PRESS, 2003. ISBN: 0-321-15630-7, page 743": > > The specification states that the enumeration software must > perform a depth-first search, so before proceeding to discover > additional functions/ devices on bus 0, it must proceed to search > bus 1. For PCI Express; for all I know, other technologies might enumerate differently or change the enumeration method with different driver versions. and Per driver. There's no guarantee that the kernel will load the drivers in the same order at boot. There was even a (specific) note in one of the RHEL 5 release notes about systems with NICs using both e1000 and e1000e being enumerated in a different order. >From >https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ : The classic naming scheme for network interfaces applied by the kernel is to simply assign names beginning with "eth0", "eth1", ... to all interfaces as they are probed by the drivers. As the driver probing is generally not predictable for modern technology this means that as soon as multiple network interfaces are available the assignment of the names "eth0", "eth1" and so on is generally not fixed anymore and it might very well happen that "eth0" on one boot ends up being "eth1" on the next.
Re: Naming of network devices - how to improve it in buster
On Fri, Jul 14, 2017 at 10:20 AM, Henrique de Moraes Holschuh wrote: > On Fri, 14 Jul 2017, Tom H wrote: >> The classic naming scheme for network interfaces applied by the kernel >> is to simply assign names beginning with "eth0", "eth1", ... to all >> interfaces as they are probed by the drivers. As the driver probing is > > Unfortunately, this is incorrect. It's most likely written by Lennart so you should take it up with him. > MOST PCI/PCIe NICs indeed use "ethX", etc. But the naming scheme really > is device driver-specific, and the "default" name used by a driver is > considered part of the kernel stable ABI, and cannot be changed on the > kernel side unless it is done opt-in at kernel config time (kconfig) or > at boot time (kernel command line, device tree, etc). > > That said, most consumer devices nowadays are handled by drivers that > will use either ethX or wlanX by default. > >> generally not predictable for modern technology this means that as soon >> as multiple network interfaces are available the assignment of the names >> "eth0", "eth1" and so on is generally not fixed anymore and it might >> very well happen that "eth0" on one boot ends up being "eth1" on the >> next. > > Correct, in the general case.
Bug#885583: ITP: node-json-parse-better-errors -- Node.js library for context errors on JSON.parse()
Package: wnpp Severity: wishlist Owner: Hari Govind S X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-json-parse-better-errors Version : 1.0.1 Upstream Author : Kat Marchán * URL : https://github.com/zkat/json-parse-better-errors#readme * License : Expat Programming Lang: JavaScript Description : JSON.parse() with context information on errors This is a Node.js library for getting nicer errors out of JSON.parse(), including context and position of parse errors. . It servers similar purpose as the JSON.parse() method but returns more useful errors when exceptions happen. . This Node.js module is an improvement to the buitin JavaScript method JSON.parse(). This module is useful for Node.js developers using Debian. . I want to maintain it as part of JavaScript packaging team.
Re: Putting default config files in /usr [was; (newbie) Disruptive LIRC package update.]
On Wed, Nov 11, 2015 at 10:37 AM, Marc Haber wrote: > > I violently disagree. We have always done it the other way, and had > the advantage that our conffile handling (which used to be and IMO > still is far superior to everything else other distributions have) > could notice if _both_ local changes and distribution changes happened > and ask the use what to do in this case. > > Adopting the systemd way here deprives our users of this advantage, > reducing Debian's operation safety. > > Just imagine Tom Smith having copied /lib/systemd/foo.service to > /etc/systemd/foo.service, and changed the /etc copy to better fit his > needs. Debian later finds that a bug in /lib/systemd/foo introduces a > security hole and ships a new version of that file. Tom installs the > security update, feels safe but isn't since noone warned him that the > security fix is not even looked at by his systems since his local copy > of the (old, insecure) file in /etc overrides the fix. > > Jane Jones, being smarter than her colleague Tom, uses the > /etc/systemd/foo.service.d approach to add her local changes. If we > ship a security update to /lib/systemd/foo.service, it depends on our > change whether Jane gets either the fix, or her local addition > overrides the fix as it was the case with Tom, or she gets > "interesting" local breakage due to a security update if our change > does not fit her change since she now inadvertently gets a mixture of > her and our changes. > > In my humble opinion, it is really bad if a package _this_ central and > important to Debian deviates from the Debian way this severely. It is, > IMO, a very good example about how badly systemd integrates in the > Debian ecosystem and that it was a bad decision to blindly follow how > systemd upstream handles configuration. The packaging should instead > follow how _Debian_ handles configuration. This is Debian in the first > place. If systemd-delta could be enhanced to apply to one unit (its current output can only be limited to a specific unit type), it could be integrated into the installation of packages providing systemd units. systemd isn't the first package to allow/promote shipping distro settings in "/lib" or "/usr/lib" and overriding them via "/etc"; udev and polkit/policykit have behaved like this for a long time. There's also "/usr/lib/sysctl.d/" where a distro ship settings that can be overridden via "/etc/sysctl.d/". I don't know how extensively it's used on Debian - it's empty on my systems - but systemd used to modify, at least, kernel.sysrq in older systemd versions in this way.
Re: Putting default config files in /usr [was; (newbie) Disruptive LIRC package update.]
On Wed, Nov 11, 2015 at 4:16 PM, Bjørn Mork wrote: > Tom H writes: >> >> systemd isn't the first package to allow/promote shipping distro >> settings in "/lib" or "/usr/lib" and overriding them via "/etc"; udev >> and polkit/policykit have behaved like this for a long time. There's >> also "/usr/lib/sysctl.d/" where a distro ship settings that can be >> overridden via "/etc/sysctl.d/". > > "/usr/lib/sysctl.d/" is systemd specific. Dropping files there won't do > anything unless you run the systemd-sysctl service. > > "/etc/sysctl.d/" used to be owned by procps, and will still be used by > /etc/init.d/procps whether or not you run systemd-sysctl. Perhaps a few years ago: # strings $(which sysctl) | grep 'sysctl.d' /run/sysctl.d /etc/sysctl.d /usr/local/lib/sysctl.d /usr/lib/sysctl.d # dpkg -S $(which sysctl) procps: /sbin/sysctl # Also codesearch.debian.net shows more than systemd as a user of "/usr/lib/sysctl.d/".
Re: Putting default config files in /usr [was; (newbie) Disruptive LIRC package update.]
On Wed, Nov 11, 2015 at 4:23 PM, Bjørn Mork wrote: > Bjørn Mork writes: >> >> "/usr/lib/sysctl.d/" is systemd specific. Dropping files there won't do >> anything unless you run the systemd-sysctl service. > > Sorry, should have researched this better first. sysctl WILL use > "/usr/lib/sysctl.d/" if it exists. procps won't create it, but it is > supported. No prob. I didn't look closely enough at codesearch.debian.net but I suspect that the "/usr/lib/sysctl.d/" hits are for binaries than scan it rather than packages that drop a file into it. I remember dracut, libvirt, and procps.
Re: support for merged /usr in Debian
On Sat, Jan 2, 2016 at 6:42 PM, Geert Stappers wrote:
> On Fri, Jan 01, 2016 at 03:53:03PM +0100, Marco d'Itri wrote:
>> On Jan 01, Ian Jackson wrote:
>> With a merged /usr you would be able to serve the whole OS over NFS (and
>> even share it among multiple systems without the constant threat of
>> having / and /usr diverge) and only configuration + data from the local
>> disk, which makes this kind of setup much more useful.
>
> "whole OS over NFS" is the same as "whole OS on /usr"
>
> A design with "whole OS over NFS" breaks the good pratice of having
> A design with "whole OS on /usr" breaks the good pratice of having
> tools like /bin/mount and /sbin/ifconfig available when /usr is unavailable.
I don't like usr-merge because it goes against my historical
expectation that "/{,s}bin" be separate from their /usr namesakes and
contain binaries required for boot.
On RHEL and RHEL clone systems that I manage, I reconcile this
expectation with RHEL's usr-merge by thinking of the initramfs as the
new "/" (it's easier in RHEL than in Debian because the initramfs has
"real" binaries rather than their busybox equivalents).
> To me is this "TheUsrMerge" something like among
> * "it is hard too to explain to have /sbin/fsck and not /usr/sbin/fsck"
> * "there was a question about /bin/kill and /usr/bin/killall being
> inconsequent"
Your mentioning of "kill" reminds me of a samba-devel@ thread where
three RH samba developers insisted that the upstream-supplied systemd
units should use "/usr/bin/kill" in spite of the fact that a fellow
samba developer pointed out that the "/bin" symlink obviated the need
for "/usr" in "ExecStart" and that this change voided the systemd
intent to have distros use upstream units as-is.
So, even though Marco's proposing a non-compulsory usr-merge, I expect
that it'll become at some point the unique and default Debian setup,
if only to reduce the delta with the various RH-dominated upstreams.
> * "we could not agree if p{erl,ython,hp} should in /bin or in /usr/bin"
> * "when calling `foo` we rely on $PATH. To avoid $PATH we call `/bin/foo`,
> to have a reason to rant it should be /usr/bin/foo"
> * "reverting a historic decission is much better then accepting a historic
> decission"
> * "just because we can"
> * "others doing also"
>
> In other words: I don't yet see a _good_ reason for "TheUsrMerge".
>
> And I think that it is ill-named,
> it should be named "PutAllExecutablesInRootFS" :-)
>
> And the "PutAllExecutablesInRootFS" is
> in fact "put all executables in a single file system".
"put all executables in a single file system" is the main/only benefit
of usr-merge.
To Simon Richter:
You mentioned earlier in the thread that you had resource-constrained
systems possibly incompatible with an initramfs.
Gentoo mandated at least two years ago that systems with a separate
"/usr" have an initramfs. A (I suspect unhappy) developer created a
busybox-based binary called "ginit" to mount "/usr" early without an
initramfs. IIRC, you have to set "init=/ginit" at the kernel cmdline
to use it - and it hands over boot to "/sbin/init" once it's done its
job.
Should you be interested, the source must be
"sys-apps/busybox/files/ginit.c" in the Gentoo distfiles tree.
Re: support for merged /usr in Debian
On Sun, Jan 3, 2016 at 11:04 AM, Daniel Reurich wrote: > On 03/01/16 22:33, Philip Hands wrote: >> Daniel Reurich writes: >>> Because systemd doesn't work without /usr on the root partition isn't a >>> good reason either. >> >> You are right ... it is a poor reason, because it is pure fantasy. > > Then why is it that since the introduction of systemd is having /usr on > a separate partition suddenly considered evil and systemd complains > loudly about it. It always has worked and does work fine for me with > sysvinit It's udev (already pre-systemd) that needs "/usr" early, with sysvinit or any other init. Whether this need breaks split-usr can be a matter of opinion because there'll always be some people saying "it's OK for me." But does this mean that it's OK for all? It also doesn't mean that udev doesn't have to go through some workarounds in order to make it work. >>> That just means systemd is broken by design and needs to be fixed. >> >> If what you claimed were true, then I'd agree with you, but since all >> the systems I've upgraded to systemd have a separate /usr, and are >> working without any issue whatsoever, this drivel can be safely ignored. > > Then what's the problem and why are we even having this conversation > about merged /usr??? usr-merge isn't correcting the broken-ness of split-usr. Mounting a separate "/usr" via the initramfs is the fix to that problem.
Re: support for merged /usr in Debian
On Sun, Jan 3, 2016 at 6:17 PM, Iustin Pop wrote:
> On 2016-01-03 12:59:01, Tom H wrote:
>>
>> I don't like usr-merge because it goes against my historical
>> expectation that "/{,s}bin" be separate from their /usr namesakes and
>> contain binaries required for boot.
>
> OK, so adjust your historical expectation. It's not a technical issue,
> it's simply a matter of expectations, which have no reason to stay the
> same for ever.
Did you read the next para of my email?!
Re: support for merged /usr in Debian
On Wed, Jan 6, 2016 at 12:03 AM, Philipp Kern wrote: > On 2016-01-04 11:30, Marc Haber wrote: >> >> Please also notice that this is the only option for ExecStart in >> systemd units. Well played, Lennart. > > Similarly skeleton-based init scripts use the full path as well. It helps if > you can stat() it. Which, I guess, you could by extension by using "which" > and the like. On the other hand init scripts are supposed to be runable in > "env -i". Now, what would the PATH be for systemd to use? My skeleton-based > init scripts ship their own PATH (yay, duplication and decentral > configuration). I can see how you would want to use EnvironmentFile for > that. But then, why not simply override ExecStart? And even then I don't see > the point. (One reply would be "to reuse the distro-provided commandline > arguments", which is fair, but you are already redirecting the path to the > binary from the default anyway and are not using the distro one.) > > You can continue to childishly blame Lennart for everything, but that might > cause others to stop taking you seriously. Which isn't really what you > deserve. Lennart didn't even say that he wanted to get rid of "EnvironmentFile=". >From the same-named thread on systemd-devel@: --- 8< --- 1) I probably should never have added EnvironmentFile= in the first place. 2) I think EnvironmentFile= was a mistake, and I explained why. But then again, I am not planning to remove it, and I never suggested that. --- >8 --- He advocated the use of drop-ins, as you (Philipp) do. There's one daemon (that I use) where this is a PitA; nfsd and its associated executables. It would mean having to edit multiple units rather than two files on Debian/Ubuntu and one file on Gentoo/RHEL.
Re: support for merged /usr in Debian
Off-list. On Wed, Jan 6, 2016 at 1:38 PM, Ansgar Burchardt wrote: > > What is the advantage of having a optional-merged-/usr? Imagine the opposition if this had been proposed as a non-optional change! (BTW, I'll take this opportunity to thank you for two of your recent proposals, the re-work of the list of packages to be installed by default and the re-naming of the security suite. Thanks!)
Re: support for merged /usr in Debian
Sorry. Not meant for list. :( On Sun, Jan 10, 2016 at 9:59 AM, Tom H wrote: > Off-list. > > On Wed, Jan 6, 2016 at 1:38 PM, Ansgar Burchardt wrote: >> >> What is the advantage of having a optional-merged-/usr? > > Imagine the opposition if this had been proposed as a non-optional change! > > (BTW, I'll take this opportunity to thank you for two of your recent > proposals, the re-work of the list of packages to be installed by > default and the re-naming of the security suite. Thanks!)
Re: support for merged /usr in Debian
On Sun, Jan 10, 2016 at 12:09 PM, Marc Haber wrote: > On Sun, 10 Jan 2016 09:53:52 +0100, Tom H wrote: >> >> Lennart didn't even say that he wanted to get rid of "EnvironmentFile=". >> >>> From the same-named thread on systemd-devel@: >> >> --- 8< --- >> 1) >> I probably should never have added EnvironmentFile= in the first place. >> >> 2) >> I think EnvironmentFile= was a mistake, and I explained why. But then >> again, I am not planning to remove it, and I never suggested that. >> --- > 8 --- >> >> He advocated the use of drop-ins, as you (Philipp) do. > > Yes. But two of his militant fanbois suggested in the following that > the option should be removed because of Lennarts reasoning. In the > following, one of them said that if the option will be removed in the > future, it would be "our" because "we" had been using the option > "wrong" and have thus "forced lennart" to remove it since we refused > to be "educated" about "proper" use of systemd. Johann (I can't think of the other "fanboi" to whom you're referring) has argued in the past for the removal of rc.local and sysvinit compatibility. Let's assume that Lennart removes support for them as well as for "EnvironmentFile=", will it really be something that'll be worth getting upset about? I'm not trying to provoke you, I'm just thinking it through. For EnvironmentFile, does it really matter whether you edit a file under "/etc/default/" or under "/etc/systemd/system/"? As I said up-thread, I'm wouldn't like setting up nfs without "EnvironmentFile=" but it's something that'll just take a little longer initially, whether I'm using config management or not. And then it'll be the same, since I only change these files at setup. For rc.local, does it really matter whether you edit "/etc/rc.local" or a file under "/etc/systemd/system/"? Personally, even if I've used rc.local when in a hurry, I've always made a point of creating a sysvinit script, upstart job, or systemd service unit later. If the rc.local support's removed, I might even create my own "/etc/systemd/system/rc-local.service" to parse "/etc/rc.local" for cases when I don't have the time to think through the dependencies of a proper unit. There's residual anger at systemd because it more or less snookered distros and users into adopting it, but being angry at every little change seems OTT, no matter how Lennart expresses his musts and must-nots and his likes and dislikes.
Re: Drop testing
On Sat, Oct 23, 2004 at 12:56:36PM +0200, Eduard Bloch wrote: > It may sound a bit radical, but core points have been mentioned in the > thread already. I suggest to do it in a more radical way: > > - unstable lockdown in the freeze > - drop Testing and concentrate on work instead of wasting time on >synching stuff. This eliminates the need for testing-security. See >the last part of the paper for details. You _are_ aware that this is approximately how it was done before woody, no? /* Steinar */ -- Homepage: http://www.sesse.net/
Re: Release-critical Bugreport for May 14, 2004
On Sun, Oct 24, 2004 at 11:08:32AM +0100, Colin Watson wrote: > As far as I can tell, the reports are still being mailed as normal. > Perhaps a listmaster could investigate why they're not reaching the > debian-devel-announce readership. Perhaps they hit the maximum message size or something? /* Steinar */ -- Homepage: http://www.sesse.net/
Location of Type 1 fonts
I'm confused as to where to place Type 1 fonts. Should they go into /usr/X11R6/lib/X11/fonts/Type1 or /usr/share/fonts/type1? Why do some TeX packages have their fonts under /usr/share/texmf/fonts/type1? -- Jaldhar H. Vyas <[EMAIL PROTECTED]> La Salle Debain - http://www.braincells.com/debian/
Re: Location of Type 1 fonts
Jaldhar H. Vyas asks, > I'm confused as to where to place Type 1 fonts. Should they go into > /usr/X11R6/lib/X11/fonts/Type1 or /usr/share/fonts/type1? Why do some > TeX packages have their fonts under /usr/share/texmf/fonts/type1? I do not pretend to have the full answer to the question, but I see no full answer yet on the list, and this may interest you. The listed Debian packages appear to deal in Type 1 fonts yet seem to have nothing particularly to do with X. Source: debram, ramification [1718 Fonts], standing separately from [1823 X Fonts] for precisely the kind of issue your question raises. Further info at [http://debtags.alioth.debian.org]. 1718 FONTS (39) CM Connelly opt mminstance Multiple-master font utilities for creating AFM or PFB files CM Connelly opt t1utils A collection of simple Type 1 font manipulation programs AR Czechowski opt libt1-5 Type 1 font rasterizer library - runtime AR Czechowski opt libt1-dev Type 1 font rasterizer library - development AR Czechowski opt libt1-doc Type 1 font rasterizer library - developers documentation AR Czechowski opt t1lib-bin Type 1 font rasterizer library - user binaries AR Czechowski opt t1lib-dev Type 1 font rasterizer library - development AR Czechowski opt t1lib1 Type 1 font rasterizer library - runtime A. Fokopt ttf2pt1 A TrueType to PostScript Type 1 Font Converter A. Lees opt defoma Debian Font Manager -- automatic font configuration framework A. Lees opt defoma-doc Debian Font Manager documentation A. Lees opt psfontmgr PostScript font manager -- part of Defoma, Debian Font Manager J. Mouetteopt fontconfig generic font configuration library J. Mouetteopt libfontconfig1 generic font configuration library (shared library) J. Mouetteext libfontconfig1-dbg generic font configuration library (debugging symbols) J. Mouetteopt libfontconfig1-dev generic font configuration library (development headers) C. Silpa-Anan opt fontforge Font Editor for PS, TrueType and OpenType fonts C. Silpa-Anan opt fontforge-doc Font Editor for PS, TrueType and OpenType fonts C. Silpa-Anan opt pfaedit A migration package for FontForge C. Silpa-Anan opt type1inst Install Adobe Type 1 fonts into X11 and Ghostscript -- Thaddeus H. Black 508 Nellie's Cave Road Blacksburg, Virginia 24060, USA +1 540 961 0920, [EMAIL PROTECTED] pgpvYzi6VUFfp.pgp Description: PGP signature
Re: Release-critical Bugreport for October 29, 2004
On Fri, Oct 29, 2004 at 04:13:48PM +0100, Jochen Voss wrote: >> 269366 [] [U] screen: ftbfs [sparc] no tgetent - no screen > Where does the [U] come from? I do not see the upstream bug tag > set on It is for "sid" in this case. /* Steinar */ -- Homepage: http://www.sesse.net/
Re: Apt-Torrent project
On Sat, Oct 30, 2004 at 12:42:32PM -0400, Mike Furr wrote: > However, I do feel that having a p2p backend to apt is a very > interesting and feasible distribution method. There is a lot of > structure in the way Debian lays out its archive, from the Package files > to the .deb's themselves, which can be exploited to make this very > efficient. An interesting experiment would be simply cat-ing all the .debs together and extend BT in some way to just fetch the parts (ie. the .debs) that it needs (and likewise, only mirror hotspots). I don't know enough about the BT protocol to know if this is feasible or not, but it does at least sound interesting :-) /* Steinar */ -- Homepage: http://www.sesse.net/
Re: GPL and command-line libraries
On Tue, Nov 02, 2004 at 09:53:21PM +0100, Wesley W. Terpstra wrote:
> If someone writes a program that does: popen('my-api');
> does the GPL require that program to also be GPL?
> From the short answer I got on IRC it seemed the answer was: No!
See http://www.gnu.org/licenses/gpl-faq.html#GPLPluginsInNF, which (among
other things) says:
If the program uses fork and exec to invoke plug-ins, then the plug-ins are
separate programs, so the license for the main program makes no requirements
for them. So you can use the GPL for a plug-in, and there are no special
requirements.
> 4. Writing to debian-legal and asking for advice.
debian-legal is the right mailing list; please repost there.
/* Steinar */
--
Homepage: http://www.sesse.net/
Re: YaST2 for Debian (aka nYaST)
On Sun, 7 Nov 2004, Mario Fux wrote: > Good morning > > Abstract: > I search a person (or more than one) who is interested to port Yast2 from > Novell/SuSE to Debian. I'd like to spend some money and/or hardware for this > task (I can't spend that much because I'm a student who lives from grants) > and perhaps some organizational help. > Dear Mario, I was until recently the Debian maintainer of webmin/usermin. I have filed an ITP (Intent to Package) for Yast2. And I intend to look into it, the hold up at the moment is I am expecting the birth of a baby boy almost any day now. Certainly financial help would speed things up a little but thats the main block. The first time I brought this up there were concerns about the license iirc but according to a Novell rep I talked to once, they do intend it to be used by other distros so we can hopefully count on them to help resolve any problems. I doubt if they would contribute any money though but asking is worth a try. It's going to take a _lot_ of work to adapt yast2 to Debian, more than just tweaking a few config files. > > This (or a similar) email goes to the following mailinglists (I'm subscribed > to all of them): > - debian-desktop [3] > - debian-devel [4] > - kalyxo and kalyxo-devel [5] & [6] > - debian-cdd [7] > We should probably consolidate discussion on, say, debian-desktop. -- Jaldhar H. Vyas <[EMAIL PROTECTED]>
Re: YaST2 for Debian (aka nYaST)
On Sun, 7 Nov 2004, Ron Johnson wrote: > On Sun, 2004-11-07 at 09:32 -0500, Jaldhar H. Vyas wrote: > > On Sun, 7 Nov 2004, Mario Fux wrote: > > > [snip] > > > > It's going to take a _lot_ of work to adapt yast2 to Debian, more than > > just tweaking a few config files. > > Questions: > 1. Then does that indicate that Yast2 might not be suitable for >Debian? No I think it can be made to work. There are just a lot of Suse-isms to remove. > 2. Does Yast2 also keep configuration data in some sort of separ- >ate database, meaning that people who switch between Yast2 and >direct conf editing might screw up their systems? > No it works on the regular conf files and allows round-tripping. -- Jaldhar H. Vyas <[EMAIL PROTECTED]> La Salle Debain - http://www.braincells.com/debian/
Re: YaST2 for Debian (aka nYaST)
On Sun, 7 Nov 2004, Ron Johnson wrote: > Would you integrate it with dpkg-reconfigure? > Could there be a yast frontend to debconf? Yes. That would probably not be the first priority though. -- Jaldhar H. Vyas <[EMAIL PROTECTED]> La Salle Debain - http://www.braincells.com/debian/
Re: possible mass bug filing: spamassassin 3
On Tue, Nov 16, 2004 at 10:54:44AM +0100, Andreas Barth wrote: > Given that SA3 is a major change, and we had massive memory issues with > the previous upload, the transfer to sarge is a bit delayed. I expect > that SA3 will go in one of these days, and it is _definitly_ on my > direct watch list. FWIW, we've run SA3 here (with a couple thousand users) in a woody backport for almost a week now, with no problems. This is of course not to say there is no bugs... :-) /* Steinar */ -- Homepage: http://www.sesse.net/
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor
On Thu, 2 Dec 2004, William Ballard wrote: > > Krishna is Jesus, dumbass. > No He isn't. dumbass. (And in case you were going to bring up that list of supposed correspondences that's floating around the net, don't bother, it's worthless.) -- Jaldhar H. Vyas <[EMAIL PROTECTED]> La Salle Debain - http://www.braincells.com/debian/
Re: Bug#283976: ITP: simnazi -- historical city simulation game, clone of Sim City
On Thu, 2 Dec 2004, Josselin Mouette wrote: > * Package name: simnazi This is the most creative invocation of Godwins law I've seen. Well done. -- Jaldhar H. Vyas <[EMAIL PROTECTED]> La Salle Debain - http://www.braincells.com/debian/
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor
On Thu, 2 Dec 2004, Manoj Srivastava wrote: > I would be surprised if ftp-masters let personal feeling about > content interfere with their official duties -- I am not aware of > this being the case. I have heard cases where packages were refused > on license grounds. > FWIW, when I packaged the Acme::Brainfuck perl module (which I also wrote) the ftpmasters suggested I censor the visible name of the package. I agreed and the matter ended there. I don't know what would have happened if I had refused. I prefer to think they would not have used coercion. -- Jaldhar H. Vyas <[EMAIL PROTECTED]> La Salle Debain - http://www.braincells.com/debian/
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor
On Thu, 2 Dec 2004, William Ballard wrote: Well sorry I was assuming you meant from some historical or theological perspective but even then... > Krishna is an advocation of false gods, exactly as is Jesus and should > be equally offensive to Manoj for the exact same reasons. Except Debian contains no Vaishnava texts nor is anyone trying to introduce them. So Krishna as far as Debian is concerned is not at all like Jesus who if you were the kind of oversensitive type Manoj was lampooning is being forced upon non-believers. -- Jaldhar H. Vyas <[EMAIL PROTECTED]> La Salle Debain - http://www.braincells.com/debian/
Re: fonts section?
Nathanael asks, > Or at least their own tag in debtags (do they > have one?) They do. Relevant facet::tags include data::font media::font role::font x11::font pgpaQIFXVPUdR.pgp Description: PGP signature
Re: charsets in debian/control
On Sun, Dec 05, 2004 at 01:01:16PM +0100, Josselin Mouette wrote: > Many of us have names that can't be written using ASCII. Well, they usually can be transliterated, can't they? Transliterating is somewhat of a kludge (and I think in most cases UTF-8 is a much better solution); OTOH I'd rapidly get confused in the list of Japanese maintainers if their names weren't transliterated. /* Steinar */ -- Homepage: http://www.sesse.net/
Re: charsets in debian/control
Peter Samuelson writes, > We seem to be moving to a de facto standard of UTF-8 for non-ASCII > characters in debian/control files. This is not specified in Policy > [1], but for hopefully obvious reasons, consistency is a Good Thing, > and UTF-8 seems to be the best solution for this sort of thing. Would Peter permit me a mild dissent? I prefer Latin-1. Reason: I can recognize and distinguish Latin-1 characters, even when I do not always understand the words they spell. Recognizing and distinguishing the characters is important to me. And not just to me. Imagine the dismay of a Korean user trying to read Arabic script in a control file. Well, the Korean user can speak for himself. Speaking for myself, ASCII is a little too limited. There is a proper balance to strike, and to me Latin-1 though imperfect is about right. Latin-1 is wrong if you speak Polish, of course, and even if you don't speak Polish, Latin-1's lack of a euro sign is slightly annoying; but, well, I admit that I do not really mind precisely where the line is drawn, so long as the general simple Latin concept of writing is preserved and the number of distinct characters represented is kept within reasonable bounds. Regarding only Latin, Unicode recognizes over eight hundred Latin characters: far too many for me. This is not considering Cyrillic or Greek; nor even beginning to think of the numerous very different writing systems of a wider non-Western world---worthy writing systems which I cannot even transcribe much less read---beautiful writing systems in which the basic Western left-to-right, character-based, diacritically marked semantics are not preserved. For the Debian Project, madness lies that way. If Latin-1 is established and used if not universally loved, then probably we should limit our usage to it. I do not deny that Latin-1 represents all the languages I can read, and that this fact may color my view. Nevertheless to me a source written in Chinese is effectively non-free. It might as well be a compiled binary blob. Actually, UTF-8 encoding as such is fine. It uses a few extra 0xC0 and 0xC1 bytes for the Latin-1 characters (see utf-8(7)), but this does not matter much. The full UTF-8 domain has numerous subtle semantics which I should like to be able to avoid, however. UTF-8 is for Unicode, which is to allow the representation of the languages of the world in their own scripts. While highly useful in its own domain, this has little to do with Debian control files, where we probably do not want the languages of the world represented in any event. I would tend to recommend that untranslated Debian work, especially control files, be limited to Latin-1. If the Japanese maintainers uncomplainingly transliterate their names to Latin-1 for our benefit, then probably the rest of us should do likewise. Whether the Latin-1 is C0/C1-encoded as UTF-8, however, is a matter of indifference to me. -- Thaddeus H. Black 508 Nellie's Cave Road Blacksburg, Virginia 24060, USA +1 540 961 0920, [EMAIL PROTECTED] pgpZfqqlenkJK.pgp Description: PGP signature
Re: charsets in debian/control
I would not disagree with Peter or Daniel. They are right in my view. However, consider the following Unicode characters: 025A LATIN SMALL LETTER SCHWA WITH HOOK 025E LATIN SMALL LETTER CLOSED REVERSED OPEN E 0261 LATIN SMALL LETTER SCRIPT G 0264 LATIN SMALL LETTER RAMS HORN 0267 LATIN SMALL LETTER HENG WITH HOOK 027A LATIN SMALL LETTER TURNED R WITH LONG LEG 027F LATIN SMALL LETTER REVERSED R WITH FISHHOOK 0285 LATIN SMALL LETTER SQUAT REVERSED ESH 0295 LATIN LETTER PHARYNGEAL VOICED FRICATIVE 02A2 LATIN LETTER REVERSED GLOTTAL STOP WITH STROKE FF21 FULLWIDTH LATIN CAPITAL LETTER A We are not speaking of a stricken Polish L, a double-accented Magyar O, or a euro sign. We are speaking of... well, to tell the truth I have no idea what these letters are. Have you? More to the point, should you and I learn to recognize such letters? Should we expect basic Latin terminal fonts to cover them? Is it reasonable to marginalize the á's and ü's of Latin-1 by lumping them with the "squat reversed esh"? Now, the "squat reversed esh" as such does not bother me. If you show me a picture of it and tell me what language it is for and what sound it makes, then I will know it. What is important to me is to preserve the simple Roman conception of the general-use alphabet in a reasonable way---not for communication in a particular language, but rather for clear, compact terminal representation and for general international use. Inherent in the concept are the relative fewness of the available characters and the predictable way they are arrayed across a page from left to right. In my view, a terminal which cannot correctly display the "á" is somewhat broken, and a user who does not recognize the "á" probably should learn. I would not say the same with respect to the "squat reversed esh". However, this is just my view. -- Thaddeus H. Black 508 Nellie's Cave Road Blacksburg, Virginia 24060, USA +1 540 961 0920, [EMAIL PROTECTED] pgpC3wA9A3ASF.pgp Description: PGP signature
Re: charsets in debian/control
Steve Langasek writes, > ... most of the letters you listed here are specific > to the IPA, which would have no use at all in a > control file as they're not part of the writing system > of any natural language. Ok. > Encodings and charsets are distinct concepts. Just > because the file is specified in UTF-8 *encoding* does > not mean we suddenly have to start coping with the > entire Unicode character set. Right. > Why, what a lovely straw man you have there. No comment. > But yes, non-ASCII Latin-1 chars should not be given > special status over the national chars found in other > languages spoken by project members. Debian should be > using either ASCII, or Unicode; standardizing on > Latin-1 makes no sense in a global project. True. Look, Steve: mild abuse aside, I agree with you in every particular. Nevertheless, I would respectfully suggest that your criticism underscores my point, which regards the monstrous increase in complexity which the full Unicode standard represents. Consider. Is it a bug if Readline cannot echo full bidirectional input? If Dselect does not appreciate all the non-spacing characters? If Less does not regard Tibetan subjoined letters? (This is my Tibetan straw man.) Undoubtedly one might observe that the Tibetan problem were not really a problem with Less but rather with some underlying library, but this misses the point---or rather again it underscores the point. Unicode solves what for many of us was not a problem by creating an entirely new class of problems. For example, it requires us to be particular about how we tag our e-mail attachments... > ... to properly declare the character set on the > non-ASCII mails you send. We can perhaps be pardoned for feeling a little grumpy about this. Am I arguing to jettison Unicode? No; to the partial extent that I had been arguing it earlier in the thread, you, Peter, Daniel and Matthew have changed my mind. However, the typical roster of skills one masters in contributing broadly to Debian development is already awesome: C, C++, CPP, Make, Perl, Python, Autoconf, CVS, Shell, Glibc, System calls, /proc, IPC, sockets, Sed, Awk, Vi, Emacs, locales, Libdb, GnuPG, Readline, Ncurses, TeX, Postscript, Groff, XML, assembly, Flex, Bison, ORB, Lisp, Dpkg, PAM, Xlibs, Tk, GTK, SysVInit, Debconf, ELF, etc.---not to mention the use of the English language at a sophisticated technical level. UTF-8 is neat, but I do not really like Unicode (you may have noticed this). Seeking essential simplicity, I would prefer to keep the full hairy overgrown Unicode standard from the typical Debian roster of development skills. Wouldn't you? -- Thaddeus H. Black 508 Nellie's Cave Road Blacksburg, Virginia 24060, USA +1 540 961 0920, [EMAIL PROTECTED] pgpoTit3xtAci.pgp Description: PGP signature
Re: charsets in debian/control
It is one thing spiritedly to argue a point against friends and allies. It is another to be obstinate. I do not wish the latter, and I admit that I am both outnumbered and outreasoned today. Please permit me without malice to conform my position, which now might be stated as follows. Unicode is a reasonable solution to a difficult yet important problem. Broadly accepted even among Debian Developers from the Latin-1 countries, Unicode is also recognized outside Debian around a wider world. Unicode is recommended for general Debian application. For non-localized purposes in which a restricted, byte-based character set is wanted, plain seven-bit ASCII is normally the logical choice. As for Latin-1, although it served some needs in an earlier day, it must today be regarded as a local, incompatible encoding, not recommended for general international use. I trust that you will inform me if the conformed position yet lacks in any significant way! Besides expressing my own revised view, the statement also means to summarize the subthread's key points. Since I happen to have the attention of interested people at the moment, I should say that I could use some help in conforming debram's [7800 Non-English Natural Language] division sensibly to the Unicode consensus. I lack the right knowledge to do it myself. At present, only the Latin-1 languages are sensibly differentiated there. The aid of a Russian (for group 7890) and a Japanese (for group 7880) might be particularly suitable, for instance. (If you don't know what this is about, it regards debtags [1].) Turning to another matter, the responses to my impromptu roster of Debian development skills indicate that the roster has been taken in slightly a different manner than I had meant it. > ... the typical roster of skills one masters in > contributing broadly to Debian development is ... > awesome: C, C++, CPP, Make, Perl, Python, Autoconf, > CVS, Shell, Glibc, System calls, /proc, IPC, sockets, > Sed, Awk, Vi, Emacs, locales, Libdb, GnuPG, Readline, > Ncurses, TeX, Postscript, Groff, XML, assembly, Flex, > Bison, ORB, Lisp, Dpkg, PAM, Xlibs, Tk, GTK, SysVInit, > Debconf, ELF, etc.---not to mention the use of the > English language at a sophisticated technical level. Although the roster may be interesting, it was meant neither as a canonical proposal nor as a challenge. In fact it was just what I had happened to think of informally at the moment. For the record, I happen to have a working familiarity with nineteen of the items on my own roster, plus a limited familiarity with seven more. Were the roster a challenge, it would be a foolish one, because Steve Langasek would beat me in a Debian development contest and I know it. As for the other fifteen roster items, as Steve said, > "contributing broadly to Debian" usually means > mastering some of these skills, and knowing where to > find answers for the rest. -- Thaddeus H. Black 508 Nellie's Cave Road Blacksburg, Virginia 24060, USA +1 540 961 0920, [EMAIL PROTECTED] 1. http://debtags.alioth.debian.org pgpWJ19KUmZqo.pgp Description: PGP signature
Re: Linux Core Consortium
On Thu, Dec 09, 2004 at 04:42:29PM -0500, Ian Murdock wrote: > Second, the common core will have a release schedule corresponding to > the release schedule of the LSB standard (roughly every 12-18 months), > and the members' release schedules will be synchronized to match that. So given that Debian's release schedule once again slips past 18 months, do we have to wait another 18 months to get etch out? /* Steinar */ -- Homepage: http://www.sesse.net/
Re: Linux Core Consortium
On Thu, Dec 09, 2004 at 02:25:28PM -0800, Bruce Perens wrote: >> So given that Debian's release schedule once again slips past 18 months, do >> we have to wait another 18 months to get etch out? > I don't see why, we don't do that for X or GNOME or anything else. Then I don't see what you mean by "synchronization". > But some of us don't want to see Debian's release schedule slip again. I doubt anybody wants to see Debian's release schedule slip, but it still happens. :-) /* Steinar */ -- Homepage: http://www.sesse.net/
Re: dselect survey
Steve Greenland writes, > Which, of course, isn't to say that it should be > removed. I was surprised by how many people still use > it; I hope some one will pick [dselect] up. Dselect is sufficiently important to me that, as time permits, I mean to pick it up. Another competent person with more time immediately available may pick dselect up first, of course, which would be fine. Otherwise expect dselect action from me within the four months following sarge's release. pgpOBgHkQactc.pgp Description: PGP signature
Re: Bug#293771: ITP: gr-ssrp -- GNU Radio interface to SSRP
On Sat, Feb 05, 2005 at 11:16:54PM +0530, Ramakrishnan Muthukrishnan wrote: > The package interfaces the GNU Radio libraries to SSRP > hardware interface. Just so people know; there will be a gr-usrp as well (for the http://comsec.com/wiki?UniversalSoftwareRadioPeripheral), but as I haven't received mine yet, I haven't gotten around to writing a proper ITP yet. :-) /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debug packages cluttering the archive
On Sun, Feb 06, 2005 at 08:52:28AM -0500, Joey Hess wrote: > My feeling for some time has been that we should introduce a separate > section in the archive, or a separate archive and come up with the > infrastructure to upload -dbg packages to there, with separated > debugging symbols in them (see dh_strip). This could be done for nearly > all binary packages, not just libraries. Then people who want all the > -dbg packages available can just add an apt line and install them at > will. We'll have to do a load of changes to the library packages when we introduce multiarch in etch anyhow; can't we do this at the same time? (Ie.: "New policy says you must follow multiarch, and make -dbg packages in libdevel-dbg"). I fail to see the big point of -dbg for non-libraries, though. Archive bloat is still a problem, though. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#293688: ITP: ttf-tibetan -- A Unicode OpenType font for Tibetan, Dzongkha and Ladakhi
On Sat, 5 Feb 2005 [EMAIL PROTECTED] wrote: > A freely available Tibetan Machine Uni font from the THDL project > (http://www.thdl.org/). The font contains almost 4,000 glyphs and can generate > over 20,000 different combinations with full support for the Sanskrit > combinations found in chos skad texts. > Do you need a sponsor? -- Jaldhar H. Vyas <[EMAIL PROTECTED]> La Salle Debain - http://www.braincells.com/debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#293930: ITP: aefirion -- A Class5 SoftSwitch.
On Sun, Feb 06, 2005 at 10:49:14PM +0100, Kilian Krause wrote: > Description : A Class5 SoftSwitch. > > The Aefirion project aims to develop a > telecommunications switch that can be classified > as Class5, which means that it should eventually > be nearly NEBS compliant. It is intended to be a > rock solid gateway rather than a super PBX, and > focuses on stability and interoperability. After reading your description, I still have zero idea what this package really is or does. Could it be reworded so people not into telecommunications would have an idea of what it does? /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#293986: ITP: rubilicious -- the Delicious (http://del.icio.us/) bindings for Ruby
On Mon, Feb 07, 2005 at 08:02:10PM +0900, Nobuhiro IMAI wrote: > Description : the Delicious (http://del.icio.us/) bindings for Ruby > > This package contains the delicious (http://del.icio.us/) bindings for > Ruby language. Wouldn't it be better to say something like (taken from the website) Description : social bookmarks manager, Ruby bindings Delicious is a social bookmarks manager. It allows you to easily add sites you like to your personal collection of links, to categorize those sites with keywords, and to share your collection not only between your own browsers and machines, but also with others. This package contains the Ruby bindings. You can add URLs with comments and tags, fetch what you or others posted filtered by tags or date, rename tags and delete URLs you posted. Upstream homepage: http://pablotron.org/software/rubilicious/ That way, it would actually be possible to see what the package is about. :-) /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#294084: ITP: life -- Linux Instrumentation for Enterprise - a set of WBEM management providers from Novell
On Tue, Feb 08, 2005 at 08:43:32PM -0500, Glenn Maynard wrote: > Call it cim-life, or wbem-life, or novell-life, or life-wbem, or something, > then. (The description was of the buzzword variety--if you don't already > know what CIM or WBEM mean, the description doesn't tell you anything--so > I don't know which is most appropriate.) You must realize the humor in being able to tell people to "apt-get a life", though. ;-) /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITP: hotplug-ng
On Fri, Feb 11, 2005 at 11:02:59AM +0100, Marco d'Itri wrote: > (I haven't seen this reaching the list, I tought that wnpp bugs were > automatically forwarded.) Just for the record: They aren't automatically forwarded by the BTS, but reportbug by default forwards them (or more correctly, sets a header so the BTS does it). /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: #284724: Interpretation of NON-BREAK SPACE
On Sat, Feb 12, 2005 at 01:18:06PM +0100, Frederic Peters wrote: > [EMAIL PROTECTED]:~$ perl -e 'printÂ"hello world\n";' > Unrecognized character \xC2 at -e line 1. 0xc2 is LATIN CAPITAL LETTER A WITH CIRCUMFLEX... Sounds like you tried to give UTF-8 to Perl without the "use utf-8" pragma to tell it your script is in UTF-8 (the non-breaking space is encoded in UTF-8 as 0xc2 0xa0). However, on my system it breaks out with the same error even with "use utf8;" on top, so I guess it's broken anyhow (and a bug against perl?). With "use utf8;" I can have all sorts of odd national characters in variable names etc., though, but I don't really know how useful that is ;-) /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: #284724: Interpretation of NON-BREAK SPACE
> ... should all characters in the class [:space:] be > treated as a token seperator in shells/languages, or > just the ASCII SPACE? If it seems pertinent to you, the C language standard sets this precedent [1]: "The source file is decomposed into preprocessing tokens and sequences of white-space characters (including comments)." Although the verbiage in the standard annoyingly leaps a few extra gymnastics to support some obsolete anti-ascii character sets, basically, all six of the traditional [:space:] characters [\t\n\v\f\r ] are treated the same---except that the two-character sequence "\\\n" (backslash followed by newline) serves to join two lines of text before preprocessing. However, the NO-BREAK SPACE is not one of the six characters, nor is it a member of [:space:], nor is it acknowledged by the iswspace(3) function. Personally, if I were using your interpreter, I would not want it quietly to accept a NO-BREAK SPACE as a token separator. I would prefer it to warn me that I had some weird character lurking in my script. -- Thaddeus H. Black 508 Nellie's Cave Road Blacksburg, Virginia 24060, USA +1 540 961 0920, [EMAIL PROTECTED] [1] ISO/IEC 9899:1999 5.1.1.2.3. pgp6Q8zJZOlml.pgp Description: PGP signature
First line in /etc/hosts
Current d-i writes the following line to the beginning of /etc/hosts: 127.0.0.1localhost.localdomain localhost Traditionally, this confuses some programs; at least pvm used to have problems with this, and I'm fairly sure cfengine2 doesn't like it either, so we've changed to 127.0.0.1. localhost However, now we've suddenly discovered that _other_ programs get confused by this! In particular, if you use an NFSv4-patched mount, it does a gethostname() and resolves that, which returns 127.0.0.1, which in turn makes it happily use that as a client identifier to the remote server. (This breaks when two or more such clients connect, obviously.) So, one program has to be buggy here, but which? :-) /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian-policy: Virtual package: change mp3-encoder with music-encoder
On Mon, Feb 14, 2005 at 11:43:41AM +, Colin Watson wrote: > Well, if any program were to actually depend on this virtual package, > they'd need to know which encoder was being used in order to correctly > support the differing argument conventions. In which case, why not just > depend on the encoders they know how to support, which is presumably a > finite list? One could of course make a standardized shell wrapper for all the packages. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#295328: general: Help messages to stderr should be banned
On Mon, Feb 14, 2005 at 11:06:30PM -0500, Justin Pryzby wrote: [...] > I occasionally install a program and need to know how to use it as > quickly as possible; for example, while reading through bug reports. > So, I run foo --help. Sometimes, the help screen is more than 25 > lines long, and it scrolls on past. So, I run foo --help |less. > Occasionally, though, foo writes its help output to stderr, and I'm > left with an empty less buffer. So, I try again: foo --help 2>&1 > |less. This is a pretty obnoxious command to have to type just to > see what the required commands are, and in what order they are taken > (and, I guess csh doesn't even allow it). [...] Actually, in csh/tcsh it's very un-obnoxious: foo --help |& less This is one of the things I wish bash supports, so that I can switch to bash. (I use csh/tcsh as my primary shell.) FWIW. T -- Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian W. Kernighan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Take APT 0.6 discussion public!
martin f krafft asks, > Obviously, for reasons unknown to the mere mortals, > the above only applies to topics of the mere mortals > of Debian, not to certain members of the cabal. Some > vital components of the Debian project are better kept > away from the public, or they could be flooded with > opinions or suggestions for improvement, or even > help (ftpmasters, are you listening?). AJ Towns replies, > Yes. If we weren't we might wake up one day and > mistakenly think it might be possible to have > discussions on Debian lists that didn't involve > gratuitous insults. AJ, having respect for and deference to your inestimable Debian work, nevertheless I object. When have you ever seen Martin F. Krafft gratuitously insult anyone? Has he not earned the benefit of the doubt? It is hard to imagine someone so passionate about Debian who habitually tries so hard to avoid insult, as Martin F. Krafft. Martin's valid question stands. Someone has advised Martin to plan his APT work in the full glare of the lists. Whether this is good advice to Martin, I do not know; but all Martin wants to know is, if the advice is good for the APT team, then why not for ftpmaster? It is a fair question, asked by many others on this list in various ways, and never really answered in my opinion. I have never asked the question but respectfully I do so now. Why can so many DDs apparently not determine to their satisfaction why and how ftpmaster works, or what they can do to help when ftpmaster seems broken? Are these DDs somehow delinquent? Do they need to RTFM? Are they as children, who just do not understand? But how can they understand what has so long been hidden? Are they unreasonable to expect gentle illumination, moderate collegiality, and some ongoing public engagement? Are they actually getting these things, only they don't realize it? On the other hand, does ftpmaster feel besieged? Is the problem that Debian development is too open, too undisciplined for practical collegiality? Yet the release team answer questions publicly: not everyone agrees with everything they do, but few seem to wonder what dark secrets they keep. And when you, AJ, served as release manager, did you ever raise a tangled hedge to keep information in and eyes and voices out? I do not think that you did. The same can be said of the dpkg and installer teams: at least they converse. What is this shroud which hides ftpmaster? It may be observed that there has recently been good progress on the DAM front, and this is true. However, the question was about ftpmaster not the DAM. Either the two are separate roles or they are not. The matter can be debated under either premise, but either way, similar questions arise. It is doubtful whether anyone can do much useful work in the continuous, full glare of general public scrutiny. This is admitted. It is also admitted that anything ftpmaster publishes about its internal works invites unsettling, perhaps even unwarranted criticism, costing ftpmaster patience and time---and even opening the possibility of a direct challenge: "I can do ftpmaster's job better. Watch." However, the body of DDs are not the general public, and Martin has never asked for hot spotlights to focus on every tiny ftpmaster move. He has asked: if gentle illumination and moderate transparency matter in APT work, then how much more so in ftpmaster work? If the question in any of its several forms is found insulting by some, I hope that they will pardon Martin, me, and the several others who have asked it. (Certainly it would be extremely easy to punish me, who after nearly three years of Debian development am soon to go for final DAM review.) I intend no more insult than Martin does. Not a DD, I have earned no right to demand an answer; but it were cowardice to leave Martin standing alone today, and I would respectfully request an answer nevertheless. -- Thaddeus H. Black 508 Nellie's Cave Road Blacksburg, Virginia 24060, USA +1 540 961 0920, [EMAIL PROTECTED] (I would quietly ask that this post not be referenced in the Weekly News. The Weekly News is great and has the honorable right to reference anything it sees fit. Personally I do not mind either way. However, if mention in the Weekly News tempted a certain non-Debian forum to open a clueless thread on the topic, then I am not sure what good purpose it would serve. Anyone who is really interested can read about it here. This is all.) pgpWjjjTVsuAc.pgp Description: PGP signature
Re: Take APT 0.6 discussion public!
Rats. Posted to the wrong list. Please do not reply to parent on -devel, but on -project. Sorry. pgpmFt12eWFCQ.pgp Description: PGP signature
Re: Bug#295785: ITP: 2pong -- It's a pong clone, but a one difference-It's played with two balls.
On Fri, Feb 18, 2005 at 03:00:26AM +0100, alionka wrote: > Description : It's a pong clone, but a one difference-It's played with > two balls. More like "pong clone played with two balls" (it is common practice to to have descriptions that fit well into "PACKAGENAME is a DESCRIPTION" or somesuch). > As the name might indicate, It's a pong clone. However, there is one "As the name might indicate, 2pong is a pong clone", probably? /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: FW: A Call to Action in OASIS
On Tue, 22 Feb 2005, John Goerzen wrote: > A Call to Action in OASIS > Debian has a representative in OASIS doesn't it? -- Jaldhar H. Vyas <[EMAIL PROTECTED]> La Salle Debain - http://www.braincells.com/debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Tips wanted for debugging and testing Debian
On Fri, Feb 25, 2005 at 02:41:48PM +0100, Michael Tautschnig wrote: >> If a bug is serious, and not a trivial thing, and if a patch has >> been filed then a NMU could be applied. > But only a Debian developer can do so, right? You can have a sponsored NMU -- I did such a thing once. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: self-depending packages
On Mon, Feb 28, 2005 at 11:58:14AM +0100, Marc Haber wrote: > Does it? The last time I was faced with that issue, the starting point > chosen was random and unpredictable. It does. (I've hacked the code.) /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Problems with - and ' in some man-pages
Eric Lavarde writes, > in some man pages ... the dashes and single quotes are > not really what they look like, but some other unicode > letter. This has two major drawbacks: > - search for options become nearly impossible > ... You illustrate well the fundamental problem with indiscriminate use of a very large character set like Unicode. If people want to use Unicode, this is fine; Unicode and utf-8 exist to be used, after all. However, restricted character sets (mainly ascii and Latin-1) offer several real practical benefits that Unicode can never provide. One such benefit is that dashes and single quotes are usually what they appear to be. Comprehensiveness is important, and Unicode is nothing if not comprehensive. On the other hand, simplicity is a prime aesthetic, which Unicode lacks. -- Thaddeus H. Black 508 Nellie's Cave Road Blacksburg, Virginia 24060, USA +1 540 961 0920, [EMAIL PROTECTED] pgpFO11tXVMjX.pgp Description: PGP signature
Re: ITP: debsync -- synchronise the installed packages lists on several machines
On Fri, Mar 04, 2005 at 12:12:48PM +0100, Florian Ragwitz wrote: >debsync is a Python command line tool which helps to synchronise the >installed packages lists on several existing Debian GNU/Linux >machines. > >debsync gets a list of installed packages from a master host, and >installs or removes packages on several hosts to match the master's >package list. > >debsync can do its work either over ssh (default) or rsh. What separates this in practice from pkgsync, already in main? /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Switchconf: Orphaning or removing?
On Mon, Mar 07, 2005 at 10:44:25AM +0200, Shaul Karl wrote: > 60 PCs with Debian and there exist 4 different configurations? > In case each PC has a nic, it sounds like the fai package suits your > situation. Or cfengine2 (optionally coupled with pkgsync). /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ports.debian.org (Re: Bits (Nybbles?) from the Vancouver release team meeting)
On Mon, Mar 14, 2005 at 03:31:30PM +0100, Christoph Berg wrote: > I'd propose to use a less "discriminating" name for the scc archive. > What about ports.debian.org (which coincidentally already exists and > http-wise points to http://www.debian.org/ports/)? You are probably risking confusion with BSD's ports system. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Mon, Mar 14, 2005 at 08:02:49PM +0100, Goswin von Brederlow wrote: > On that note I think amd64 fails the 5 DDs crtiteria. When we asked > for inclusion we had 1 DD working on amd64 and several NMs I think. I > think when we hit the 98% mark there were 2 DDs involved. Tada, you have my vote if you need it. I really don't think getting the last two ones will really be hard. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: master's mail backlog and upgrade time
On Fri, Nov 18, 2005 at 02:11:43PM -0500, Stephen Frost wrote: > I expect you could do it though I havn't tried myself because I'm not a > big fan of smtp-level rejects exactly for these reasons. I just accept > and then discard (at least for known userids, but I don't expect many > people to be setting up forwards for non-existant userids). What do you do when you encounter a false positive? Not everybody has the luxury of affording to have their legitimate mail eaten silently. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: g++/stl -frepo problem? (was: library renaming due to changed libstdc++ configuration)
On Sat, Nov 19, 2005 at 04:08:12PM +0900, Miles Bader wrote: > Summary of problem: compilation with g++ gives "undefined reference" > for references to some STL template function instantiations, despite > using -frepo (which AFAIK should automatically recompile something to > instantiate all missing functions). [See previous message for some > error output.] -frepo is an optimization switch, designed to avoid multiple instantiations of the same template (reducing its size). You should be able to compile just fine without it, but your binaries will be bigger. BTW, you are _linking_ with -frepo as well, right? /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: too long to build 2.6.14.2 kernel
On Tue, Nov 22, 2005 at 10:54:26AM +, Andreas Orfanos wrote: > My question is: Is this build time acceptable for the new kernels? > Is something wrong with the tool chain? Distribution? My question is: Is it a real problem? How often do you really compile your kernels yourself with all the modules turned on, such as Debian does? > I remember kernel builds where ultra fast, couldn't watch on > screen what it was compiled. 2.4 used to spit out the entire command line while compiling. Try making with V=1 to get the same effect on 2.6. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
On Sat, Nov 26, 2005 at 09:13:02AM +1000, Anthony Towns wrote: >> Moving away from MD5 is certainly not a bad idea, but it's not clear >> whether the alternatives are any better. Sure, everyone recommends >> SHA-256 at this stage, but nobody can give a rationale. > MD5 is broken; SHA-1 is where MD5 was a couple of years ago, SHA256 (or > higher) are significantly harder to break in practice, and there's > nothing better yet. Just a comment here for those who are not used to hash functions: "Broken" here means that you can generate collisions faster than using the birthday attack (2^64 for MD5, 2^80 for SHA-1). It does not have to mean that you can do _really_ evil stuff, like generate a second file with the same MD5 hash as a given file (so-called "second preimage", IIRC) and to the best of my knowledge, nobody has done so yet). However, there's a long way from "you can't generate a valid .deb with a given md5sum easily" to "SHA-256 is no better than MD5". You can generate an MD5 collision in four hours on a standard desktop computer today; you're nowhere near that for SHA-1, and SHA-256 is still AFAIK not broken (although it relies on the same basic structure as MD5 and SHA-1). All three might eventually be truly broken, but you can bet that MD5 will be the first to go. If you use SHA-256 today instead of MD5, you probably buy yourself a few extra years, which you can use to smooth out the transition to the next hash function when the world advances. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
On Sat, Nov 26, 2005 at 10:47:57AM +1100, Brian May wrote: >>> Well, even if I know naught about it, it looks to me that having >>> something signed is better than having the same something not signed. >> Sorry, but that's a snake oil rationale. > A: Why do you lock your car up[1]? Because it makes it harder to steal the car. I think the point was that signing a .deb did not automatically make it harder to do whatever the scenario asked for. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
