Re: Change default PATH for Jessie / wheezy+1
On 08/09/2012 11:43 PM, Carlos Alberto Lopez Perez wrote: """ As of DebianSqueeze, if you ask for the Desktop task during the installation, that pulls in sudo with a default configuration that automatically grants sudo-ing rights to any member of the sudo group. Depending on what user accounts you set up during the install, it's still possible that you may not have been added to that group - you can check by running groups. """http://wiki.debian.org/sudo So, how can be the we add the first user of the system to sudoers and we don't add sbin to his default paths? For the record and at least up to squeeze, you do have a sudo group but you are *not* added to that group. Second thing I do in a new installation after adding sbin to path is adding myself to sudo group... but that being a default is more debatable ;) -- 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/5024b020.6070...@qindel.com
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
On 08/09/2012 09:54 PM, Marco d'Itri wrote: > openrc was recently discussed on debian-devel@ and there was a large > consensus that it is not a credible alternative to upstart and systemd. > That's clearly *not* truth. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5024904a.5080...@debian.org
Bug#684442: ITP: pax-britannica -- one-button real-time multi-player strategy game
Package: wnpp Severity: wishlist Owner: Joseph Nahmias * Package name: pax-britannica Version : 1.0.0 Upstream Author : nofunga...@gmail.com * URL : http://paxbritannica.henk.ca/ * License : MIT Programming Lang: Lua Description : one-button real-time multi-player strategy game Pax-Britannica is a real-time strategy game that uses only one button. You fight your opponnents by spawning various ships and upgrading your factory ship. The player who keeps their factory ship alive wins! -- 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/20120810025556.20476.7934.report...@brain.nahmias.net
Bug#684440: ITP: horst -- small, lightweight IEEE802.11 wireless LAN analyzer with a text interface
Package: wnpp
Severity: wishlist
Owner: "Antoine Beaupré"
* Package name: horst
Version : 3.0
Upstream Author : Bruno Randolf
* URL : http://br1.einfach.org/tech/horst/
* License : GPL-2
Programming Lang: C
Description : small, lightweight IEEE802.11 wireless LAN analyzer with a
text interface
horst is a small, lightweight IEEE802.11 wireless LAN analyzer with a
text interface. Its basic function is similar to tcpdump, Wireshark
or Kismet, but it's much smaller and shows different, aggregated
information which is not easily available from other tools. It is
mainly targeted at debugging wireless LANs with a focus on ad-hoc
(IBSS) mode in larger mesh networks. It can be useful to get a quick
overview of what's going on on all wireless LAN channels and to
identify problems.
.
* Shows signal/noise values per station
* Calculates channel utilization ("usage") by adding up the amount
of time the packets actually occupy the medium
* "Spectrum Analyzer" shows signal levels and usage per channel
Graphical packet history, with signal/noise, packet type and physical
rate
* Shows all stations per ESSID and the live TSF per node as it is
counting
* Detects IBSS "splits" (same ESSID but different BSSID \u2013 this
is a common driver problem)
* Statistics of packets/bytes per physical rate and per packet type
* Has some support for mesh protocols (OLSR and batman)
* Can filter specific packet types source addresses or BSSIDs
* Client/server support for monitoring on remote nodes
--
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/20120810024551.29365.45117.report...@marcos.anarcat.ath.cx
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
On Aug 10, Roger Leigh wrote: > In the case of OpenRC, it has the potential to be a drop-in replacement > for sysv-rc (note that it uses base sysvinit still underneath that). So do the other init systems. The point is what they can do which sysvinit (and openrc) cannot. -- ciao, Marco signature.asc Description: Digital signature
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
On 10/08/2012 08:04, Steve Langasek wrote: > On Fri, Aug 10, 2012 at 01:16:17AM +0200, Adam Borowski wrote: >> Wasn't the idea of porting to non-Linux rejected by upstart's upstream? > > Porting upstart to non-Linux kernels has never been rejected by upstream. > It just requires porters to do the porting; no one involved in upstart > upstream has any applicable BSD or Hurd porting experience. > If I recall correctly, non-Linux ports were required by upstream to be maintained in a separate bzr branch, because upstart's upstream did not want compatibility code inside the main code-base. This sounds very much like "if you want to port it, fork it." -- Kind regards, Loong Jin signature.asc Description: OpenPGP digital signature
Bug#684439: ITP: libguac-client-rdp -- RDP client plugin for Guacamole
Package: wnpp Severity: wishlist Owner: Mike Jumper * Package name: libguac-client-rdp Version : 0.6.0 Upstream Author : Michael Jumper * URL : http://guac-dev.org/ * License : MPL-1.1 or GPL-2.0 or LGPL-2.1 Programming Lang: C Description : RDP client plugin for Guacamole A plugin for the Guacamole proxy daemon (guacd) that provides support for the RDP protocol (Windows Remote Desktop). -- 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/20120601023432.14335.46471.report...@test1.guac-dev.org
Work-needing packages report for Aug 10, 2012
The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 457 (new: 0) Total number of packages offered up for adoption: 144 (new: 0) Total number of packages requested help for: 65 (new: 0) Please refer to http://www.debian.org/devel/wnpp/ for more information. No new packages have been orphaned, but a total of 457 packages are orphaned. See http://www.debian.org/devel/wnpp/orphaned for a complete list. No new packages have been given up for adoption, but a total of 144 packages are awaiting adoption. See http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list. For the following packages help is requested: apt-xapian-index (#567955), requested 920 days ago Description: maintenance tools for a Xapian index of Debian packages Installations reported by Popcon: 54174 asymptote (#517342), requested 1259 days ago Description: script-based vector graphics language inspired by MetaPost Installations reported by Popcon: 3005 athcool (#278442), requested 2844 days ago Description: Enable powersaving mode for Athlon/Duron processors Installations reported by Popcon: 78 balsa (#642906), requested 319 days ago Description: An e-mail client for GNOME Installations reported by Popcon: 249 bastille (#592137), requested 733 days ago Description: Security hardening tool Installations reported by Popcon: 208 boinc (#511243), requested 1309 days ago Description: BOINC distributed computing Installations reported by Popcon: 1598 cardstories (#624100), requested 472 days ago Description: Find out a card using a sentence made up by another player Installations reported by Popcon: 4 chromium-browser (#583826), requested 802 days ago Description: Chromium browser Installations reported by Popcon: 10050 debtags (#567954), requested 920 days ago Description: Enables support for package tags Installations reported by Popcon: 2494 doc-central (#566364), requested 929 days ago Description: web-based documentation browser Installations reported by Popcon: 201 elvis (#432298), requested 1858 days ago Description: powerful clone of the vi/ex text editor (with X11 support) Installations reported by Popcon: 297 fbcat (#565156), requested 939 days ago Description: framebuffer grabber Installations reported by Popcon: 143 flightgear (#487388), requested 1510 days ago Description: Flight Gear Flight Simulator Installations reported by Popcon: 761 freeipmi (#628062), requested 441 days ago Description: GNU implementation of the IPMI protocol Installations reported by Popcon: 1749 gnat-4.4 (#539633), requested 1577 days ago Description: backport bug fixes from trunk (GCC 4.5) Installations reported by Popcon: 1600 gnat-gps (#496905), requested 1442 days ago Description: co-maintainer needed Installations reported by Popcon: 407 gnokii (#677750), requested 54 days ago Description: Datasuite for mobile phone management Installations reported by Popcon: 2387 gnupg (#660685), requested 171 days ago Description: GNU privacy guard - a free PGP replacement Installations reported by Popcon: 121151 golang (#668870), requested 116 days ago Description: Go programming language compiler - metapackage Installations reported by Popcon: 246 gpa (#663405), requested 152 days ago Description: GNU Privacy Assistant (GPA) Installations reported by Popcon: 501 gradle (#683666), requested 7 days ago Description: Groovy based build system Installations reported by Popcon: 31 grub2 (#248397), requested 3013 days ago Description: GRand Unified Bootloader Installations reported by Popcon: 111938 hfsprogs (#557892), requested 988 days ago Description: mkfs and fsck for HFS and HFS+ file systems Installations reported by Popcon: 1129 hotkey-setup (#483107), requested 1535 days ago Description: auto-configures laptop hotkeys Installations reported by Popcon: 3458 irssi-scripts (#663577), requested 150 days ago Description: collection of scripts for irssi Installations reported by Popcon: 995 isdnutils (#661110), requested 167 days ago Description: ISDN utilities Installations reported by Popcon: 9519 jove (#470185), requested 1614 days ago Description: Jonathan's Own Version of Emacs - a compact, powerful editor Installations reported by Popcon: 1097 lesstif2 (#551853), requested 1023 days ago Descri
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
On Fri, Aug 10, 2012 at 01:16:17AM +0200, Adam Borowski wrote: > Wasn't the idea of porting to non-Linux rejected by upstart's upstream? Porting upstart to non-Linux kernels has never been rejected by upstream. It just requires porters to do the porting; no one involved in upstart upstream has any applicable BSD or Hurd porting experience. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
Hi! systemd's upstream is not hostile at all - systemd just relies on many Linux-specific technologies, not just cgroups, and therefore it is not easily possible to port it. Upstream suggested to fork systemd and maintain patches for other OSes there, because they don't want a construct with lots of #ifdefs which is hard to debug and doesn't work as expected on all platforms. (supporting multiple platforms is a huge effort) So far nobody has created a non-Linux fork of systemd, and the reason is mainly that it is too much work. Cheers, Matthias 2012/8/10 Roger Leigh : > On Fri, Aug 10, 2012 at 12:50:43AM +0200, Josselin Mouette wrote: >> Le jeudi 09 août 2012 à 23:53 +0200, Carlos Alberto Lopez Perez a >> écrit : >> > What about Debian kFreeBSD and Hurd? AFAIK systemd needs a linux kernel to >> > work. >> >> Please explain again why we should cripple the Linux port for the sake >> of toy ports? > > I'm not sure that this is true. > > OpenRC can (on Linux) use cgroups and hence do some of the more > advanced stuff that systemd does. Yet it still runs on other > platforms. This is in part due to the fact that OpenRC is > written to be portable, while the systemd developers have an > asoundingly bad attitude with respect to this. It would be > perfectly possible for systemd to support other platforms if > they really wanted to; it probably wouldn't even be that hard. > > > Roger > > -- > .''`. Roger Leigh > : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ > `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools >`-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 > > > -- > 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/20120809231631.gc25...@codelibre.net > -- 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/caknhny-a_7vqnxva+mzcmz3vofvdn4iczthf2bpyhesrvna...@mail.gmail.com
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
On Fri, Aug 10, 2012 at 12:50:43AM +0200, Josselin Mouette wrote: > Le jeudi 09 août 2012 à 23:53 +0200, Carlos Alberto Lopez Perez a > écrit : > > What about Debian kFreeBSD and Hurd? AFAIK systemd needs a linux kernel to > > work. > > Please explain again why we should cripple the Linux port for the sake > of toy ports? I'm not sure that this is true. OpenRC can (on Linux) use cgroups and hence do some of the more advanced stuff that systemd does. Yet it still runs on other platforms. This is in part due to the fact that OpenRC is written to be portable, while the systemd developers have an asoundingly bad attitude with respect to this. It would be perfectly possible for systemd to support other platforms if they really wanted to; it probably wouldn't even be that hard. Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120809231631.gc25...@codelibre.net
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
On Thu, Aug 09, 2012 at 02:51:49PM -0700, Steve Langasek wrote: > On Thu, Aug 09, 2012 at 10:40:44PM +0200, Adam Borowski wrote: > > On Thu, Aug 09, 2012 at 03:54:05PM +0200, Marco d'Itri wrote: > > > Please do not bother. > > > openrc was recently discussed on debian-devel@ and there was a large > > > consensus that it is not a credible alternative to upstart and systemd. > > > openrc is not acceptable from the very start, as it lacks a key part: > > a hostile upstream. That seems to be the main requirement for Debian. > > Ah, that must be why the community hasn't rallied around upstart yet... we > aren't being hostile enough! Thanks for helping me understand, I'll do what > I can to make sure Canonical is being appropriately hostile wrt upstart from > now on. ;) Wasn't the idea of porting to non-Linux rejected by upstart's upstream? With nowhere as much hostility as systemd's, though -- if I recall correctly, it was something like "do all the work yourself, we won't help you even with merging patches", as opposed to systemd "no because no, over my dead body". With people like you around, this is something that's solvable. -- Copyright and patents were never about promoting culture and innovations; from the very start they were legalized bribes to give the king some income and to let businesses get rid of competition. For some history, please read https://en.wikipedia.org/wiki/Statute_of_Monopolies_1623 -- 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/20120809231617.ga25...@angband.pl
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
On Thu, Aug 09, 2012 at 05:37:57PM +0200, Marco d'Itri wrote: > On Aug 09, The Fungi wrote: > > > So I would assume this ITP is merely an outcome of that debian-devel > > discussion, > I think that the outcome of that discussion was that openrc would be too > little too late for Debian, and that it is proven that trying to support > well multiple init implementations does not work. In the case of OpenRC, it has the potential to be a drop-in replacement for sysv-rc (note that it uses base sysvinit still underneath that). With the work that Benda Xu has done to make OpenRC work with LSB init scripts, it can now run standard Debian init scripts. There's work going on in openrc upstream to allow introspection of OpenRC dependencies dynamically (it's possible now, but without a standard interface). This will potentially let insserv and other tools (systemd etc.) add support for integrating OpenRC dependencies into their normal operation. The first allows a migration path to using OpenRC; the latter allows a migration path from LSB to OpenRC scripts. Working on getting OpenRC to work on Debian is not without value. For me, the entire point of the exercise is to explore the feasability to port it and evaluate it as an alternative/replacement for sysv-rc; this is almost completely orthogonal to work on systemd/upstart, which will for the most part be unaffected by this. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120809230132.gb25...@codelibre.net
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
Le jeudi 09 août 2012 à 23:53 +0200, Carlos Alberto Lopez Perez a écrit : > What about Debian kFreeBSD and Hurd? AFAIK systemd needs a linux kernel to > work. Please explain again why we should cripple the Linux port for the sake of toy ports? -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1344552643.4958.7.camel@tomoyo
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
On Thu, Aug 09, 2012 at 10:40:44PM +0200, Adam Borowski wrote: > On Thu, Aug 09, 2012 at 03:54:05PM +0200, Marco d'Itri wrote: > > Please do not bother. > > openrc was recently discussed on debian-devel@ and there was a large > > consensus that it is not a credible alternative to upstart and systemd. > openrc is not acceptable from the very start, as it lacks a key part: > a hostile upstream. That seems to be the main requirement for Debian. Ah, that must be why the community hasn't rallied around upstart yet... we aren't being hostile enough! Thanks for helping me understand, I'll do what I can to make sure Canonical is being appropriately hostile wrt upstart from now on. ;) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
On 09/08/12 15:54, Marco d'Itri wrote: > Please do not bother. > openrc was recently discussed on debian-devel@ and there was a large > consensus that it is not a credible alternative to upstart and systemd. > We do not need to be able to choose among multiple init implementations. > What about Debian kFreeBSD and Hurd? AFAIK systemd needs a linux kernel to work. signature.asc Description: OpenPGP digital signature
Bug#684430: ITP: nagios-plugins-ldap-ltb -- LDAP Tool Box (ltb) nagios plugins
Package: wnpp Severity: wishlist Owner: "Adam Cécile (Le_Vert)" * Package name: nagios-plugins-ldap-ltb Version : 0.3 Upstream Author : Clement OUDOT, LTB-project.org * URL : http://tools.ltb-project.org/projects/ltb * License : GPL-2.0+ Programming Lang: Perl Description : LDAP Tool Box (ltb) nagios plugins This package contains Nagios plugins from the LDAP tool box project. It features a syncrepl plugin to check synchronisation between two servers among other nice plugins. -- 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/20120809215817.26192.27847.reportbug@thrall.courc.levert
Re: Change default PATH for Jessie / wheezy+1
On 09/08/12 22:05, Thomas Goirand wrote: > What you are proposing here is a hack based on dangerous assumptions. Why you say this is a dangerous assumption? I am not proposing adding this to already installed machines via upgrades, but to add this feature to d-i, so it automatically adds sbin dirs to the path of the first user on new installs. I believe that many newbie users could be confused when they type on the console "random-sbin-command" and get "command not found" or they aren't able to use tab completion to discover that this commands are available on their system. > Why can't you customize your own computer $PATH for your user, if > you feel this way? > Already did long time ago. Just trying to improve the defaults :) > Also, I quite not understand why ifconfig is so important in the eyes > of many participant to this thread, when there's an alternative, when > other tools without other implementation would deserve much more > attention. Others have already listed few tools, but here's my own > list too: > - tc (to be used with /sbin/tc qdisc show for example) > - All partitioning / formatting utilities (mkfs, resize2fs, etc.) > > But that's about it. Why not trying to fix those instead? These are two different things. Of course I agree with fixing the sbin files that should be in bin. But at the same time I think that adding sbin to the path of the first user on d-i is a good idea. I bet that the first user of the 90% of the systems (uid 1000) is also the admin of that machine. Either because is a single-user machine (laptop/pc) or because he is the one which installed the server and therefore is the sysadmin. Furthermore I believe that also this first user is added to sudoers by d-i when installing a new Debian system """ As of DebianSqueeze, if you ask for the Desktop task during the installation, that pulls in sudo with a default configuration that automatically grants sudo-ing rights to any member of the sudo group. Depending on what user accounts you set up during the install, it's still possible that you may not have been added to that group - you can check by running groups. """ http://wiki.debian.org/sudo So, how can be the we add the first user of the system to sudoers and we don't add sbin to his default paths? signature.asc Description: OpenPGP digital signature
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
Le jeudi 09 août 2012 à 18:42 +0200, Martin Wuertele a écrit : > > We do not need to be able to choose among multiple init implementations. > > According to my latest information only the DPL may speak on behalf of > the project which can by overridden by way of a GR. I therefore conclude > that YOU don't want to be able to chose among multiple init > implementatioins. It’s not a question of wanting it or not. It is a stupid thing to do, which brings us more work with no added value for our users. And no, choice between multiple broken implementation is NOT added value. Linux is not about choice. -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1344545887.4958.6.camel@tomoyo
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
On Thu, Aug 09, 2012 at 03:54:05PM +0200, Marco d'Itri wrote: > Please do not bother. > openrc was recently discussed on debian-devel@ and there was a large > consensus that it is not a credible alternative to upstart and systemd. openrc is not acceptable from the very start, as it lacks a key part: a hostile upstream. That seems to be the main requirement for Debian. (Not going into actual technical reasons, I took part in too many flamewars recently already.) -- Copyright and patents were never about promoting culture and innovations; from the very start they were legalized bribes to give the king some income and to let businesses get rid of competition. For some history, please read https://en.wikipedia.org/wiki/Statute_of_Monopolies_1623 -- 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/20120809204044.ga16...@angband.pl
Re: Change default PATH for Jessie / wheezy+1
On 09/08/12 04:05 PM, Thomas Goirand wrote: When we are talking about IPv4, then it's probably right to tell that having multiple IPs on a single interface isn't a very common setup. But for IPv6, that's another story! It's very common to setup more than one IP per iface with IPv6. And yes, we should consider IPv6 as important. Just for the record, ifconfig seems to display multiple IPv6 addresses just fine: $ ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:30:48:87:0d:fa inet addr:64.15.147.134 Bcast:64.15.147.159 Mask:255.255.255.224 inet6 addr: 2607:f748:1200:f9::4:1/64 Scope:Global inet6 addr: 2607:f748:1200:f9::5:f/64 Scope:Global inet6 addr: 2607:f748:1200:f9::2:f/64 Scope:Global inet6 addr: 2607:f748:1200:f9::a:1/64 Scope:Global ... etc. This ifconfig hiding of extra addresses appears to be an IPv4-only problem. Jason Rhinelander -- 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/50241cef.4040...@jagerman.com
Re: Change default PATH for Jessie / wheezy+1
On 08/09/2012 06:14 PM, Carlos Alberto Lopez Perez wrote: > I am aware of the shortcomings of ifconfig. However it is still a nice > and valid tool to just show the ip address the DHCP server assigned to a > machine (AFAIK DHCP servers only assign one IP address per interface) > With all the due respect, only considering this one use case (eg: when using dhcp and you need to know the IP address) is a quite short sighted view. > Also ip is only available for Linux kernels, but ifconfig is available > on any *nix. ifconfig has a different output depending on the *nix (eg: formatting is different IIRC). Saying it's the same thing isn't fully right. > Furthermore the output formatting of ifconfig is more user > friendly than the one of ip. > A tool which potentially hides part of the information (eg: other IPs that may have been assigned to an interface, link status, type of scheduling, etc.) can't be called more user friendly. At the maximum, you can tell that you like it better and know it better, but that's probably it. When we are talking about IPv4, then it's probably right to tell that having multiple IPs on a single interface isn't a very common setup. But for IPv6, that's another story! It's very common to setup more than one IP per iface with IPv6. And yes, we should consider IPv6 as important. > After reading the thread, I think that probably the better idea is to: > > * Fix #312669 > Yes. But we shouldn't mix #312669 with the title of the thread, both issues should be addressed totally separately, and #312669 shouldn't be used as an excuse to mess everything. Same for all other utilities that might have been wrongly put in sbin. > * Add /sbin:/usr/sbin to the PATH of the first user (uid 1000) >Since on single-user machines (laptops/PCs) I think is a valid >assumption to think that the (probably) unique user of the machine >is also the administrator of that machine. So he will probably >find useful to have the administrative commands on his path. >Also on multi-user machines (servers) the first user installed is >probably the user the sysadmin will use for himself. > What you are proposing here is a hack based on dangerous assumptions. Why can't you customize your own computer $PATH for your user, if you feel this way? Also, I quite not understand why ifconfig is so important in the eyes of many participant to this thread, when there's an alternative, when other tools without other implementation would deserve much more attention. Others have already listed few tools, but here's my own list too: - tc (to be used with /sbin/tc qdisc show for example) - All partitioning / formatting utilities (mkfs, resize2fs, etc.) But that's about it. Why not trying to fix those instead? Cheers, Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50241818.5040...@debian.org
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
* Marco d'Itri [2012-08-09 16:12]: > Please do not bother. > openrc was recently discussed on debian-devel@ and there was a large > consensus that it is not a credible alternative to upstart and systemd. It was a very long discussion that did not end in a major consensus the way I read it. Consensus was only between those favoring an event driven system but the advantages or requirements for an event driven system have not yet fully been disclosed in such a way that all questions raised are answered. > We do not need to be able to choose among multiple init implementations. According to my latest information only the DPL may speak on behalf of the project which can by overridden by way of a GR. I therefore conclude that YOU don't want to be able to chose among multiple init implementatioins. Yours Martin -- 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/20120809164229.gb10...@anguilla.debian.or.at
Bug#684403: ITP: python-librcsb-core-wrapper -- library that exports C++ mmCIF accessors to Python
Package: wnpp Severity: wishlist Owner: Laszlo Kajan -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: python-librcsb-core-wrapper Version : 1.000 Upstream Author : Vladimir Guranovic * URL : http://sw-tools.rcsb.org/apps/CORE-WRAPPER/index.html * License : RCSB PDB SOFTWARE LICENSE AGREEMENT, Henry Spencer's regex license Programming Lang: C++ Description : library that exports C++ mmCIF accessors to Python This package provides RCSB Core Wrapper, a library that exports C++ mmCIF accessors to Python. . This library is built on top of RCSB CIFPARSE-OBJ, a library that provides an object-oriented interface to information in mmCIF format. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJQI+EgAAoJEJvS1kCaDFL6PTYP+QHjI4Uuhn1MzAGCuFEaEnBm lufhWz/ulfHXpl0Z/oH7w/zPoE+oXGAFY7Cl5nAVvGGR1FqIdWwT5Rc3TGb+XU2b 4KhR4+Q9WjcLddX/x9NjUF3vM9fBk7dULFmYCyvCdVWsvESV1lh5l/GTNDaAJTIM 7zjnBIOMY9DVnUiWf4pibCNMGA7kBcqhDW+ohljcHK1W8FOQTQTWzgeWgNj7V8i+ 7yjnj9kHKj89TUgkcPtnazibhMYI2TZJuCMUsiZiHuGz7mHT22/ni3KdA5qVzb9k K+edy/HxkCz8B8iqPKjFtY1P/r/FNID68GEy05iRQ1O9fZpq3ABQza/EYqryfXxb vWV0S5ojcXD/b8Dy/jTuTI3kD1yS1aXaiVf7FzIdkYFMZCIhLuNGcmPUSJ4z2yel qEKYbytd+O+ttgGarhdQPR7Z9SXywMMU2mlo090ByPrJ5SVphijfyt/Pjv+5WzI2 /Bh6+XobVOH8qgz8mXCwvpqKfRW8bUhO4GGF3oO7bZTJDlhM/ooaPPybEpU8MTDX FHsrfLwqud74vST6apJNa6m1s6YUY/tqZbbFH60CEjAmkRhszSmlaXDZFr7zSEDz B0atqqBldIvSqQNfaWjcNdEHkZq6U+Fmjb52NCBOnBRVOd84rOQM6O45bVlA2sMB XdfmofkA8OxP7tA6tIYl =pxBx -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120809161116.28467.97898.reportbug@debian-unstable.rostclust
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
On Aug 09, The Fungi wrote: > So I would assume this ITP is merely an outcome of that debian-devel > discussion, I think that the outcome of that discussion was that openrc would be too little too late for Debian, and that it is proven that trying to support well multiple init implementations does not work. -- ciao, Marco signature.asc Description: Digital signature
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
On 2012-08-09 15:54:05 +0200 (+0200), Marco d'Itri wrote:
> Please do not bother.
[...]
Last I recall from that thread, Roger Leigh was coordinating with
Gentoo upstream to incorporate/wrap the necessary functionality to
parse LSB header comments already present in Debian's init scripts.
He also seems to be involved in this ITP as the submitter's mentor,
judging from:
http://wiki.debian.org/OpenRC
So I would assume this ITP is merely an outcome of that debian-devel
discussion, based on work which has been taking place behind the
scenes since the thread died down.
--
{ IRL(Jeremy_Stanley); WWW(http://fungi.yuggoth.org/); PGP(43495829);
WHOIS(STANL3-ARIN); SMTP(fu...@yuggoth.org); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); IRC(fu...@irc.yuggoth.org#ccl); }
--
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/20120809150317.gl3...@yuggoth.org
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
Please do not bother. openrc was recently discussed on debian-devel@ and there was a large consensus that it is not a credible alternative to upstart and systemd. We do not need to be able to choose among multiple init implementations. -- ciao, Marco signature.asc Description: Digital signature
Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
Package: wnpp Severity: wishlist Owner: XU Benda * Package name: openrc Version : 0.10.5 Upstream Author : Gentoo OpenRC Team * URL : http://www.gentoo.org/proj/en/base/openrc/ * License : 2 clause BSD Programming Lang: C, shell script Description : alternative boot mechanism that manages the services, startup and shutdown of a host OpenRC is a dependency based init system that works with the system provided init program, normally /sbin/init. It is not a replacement for /sbin/init, but an alternative to /etc/init.d/rc from sysv-rc. OpenRC understands LSB headers, providing a smooth way to switch back and forth with sysv-rc. -- 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/20120809130307.7498.64495.reportbug@localhost
Re: Change default PATH for Jessie / wheezy+1
On Wed, Aug 08, 2012 at 09:58:51PM +0200, Philipp Kern wrote: > On Wed, Aug 08, 2012 at 07:54:59PM +0200, Andrew Shadura wrote: > > On Wed, 08 Aug 2012 19:44:25 +0200 > > Vincent Bernat wrote: > > > "arp" can be replaced by "ip neigh", "ifconfig" by "ip addr" or "ip > > > link", "route" by "ip route", "ipmaddr" by "ip maddr", "mii-tool" by > > > "ethtool", "netstat" by "ss", "nameif" by "ip link", "iptunnel" by > > > "ip tunnel". "iproute" and "ethtool" packages are kept in sync with > > > kernels and allow the user to use the latest features. > > ...And completely lack full documentation on all of them, yeah? > > Hm? There are manual pages[1]. Also ip is able to support IPv6 with the same > syntax (like arp → neigh for both) by just passing "-6". Actually, like most good tools, "ip" supports IPv4 and IPv6 together. You can filter for one or the other with "-4" and "-6" respectively. signature.asc Description: Digital signature
Re: Change default PATH for Jessie / wheezy+1
On Thu, 2012-08-09 at 12:14, Carlos Alberto Lopez Perez wrote: > On 08/08/12 12:11, Thomas Goirand wrote: > > On 08/08/2012 10:32 AM, Carlos Alberto Lopez Perez wrote: [...] > on any *nix. Furthermore the output formatting of ifconfig is more user > friendly than the one of ip. It depends of that who is the 'friend'. -- Kind regards, Milan -- 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/20120809110711.gc21...@arvanta.net
Re: Change default PATH for Jessie / wheezy+1
On Thu, 9 Aug 2012 08:16:46 +, Tzafrir Cohen wrote: [...] > While I'm in rant mode, note that there's no programmable bash > completion for the subcommands of ip. I wasn't aware of ip neigh. For a brief shell size war interlude, note that there is zsh completion for the subcommands of ip. -- Michał Politowski Talking has been known to lead to communication if practiced carelessly. -- 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/20120809094026.ga13...@meep.pl
Re: Change default PATH for Jessie / wheezy+1
On 08/08/12 12:11, Thomas Goirand wrote: > On 08/08/2012 10:32 AM, Carlos Alberto Lopez Perez wrote: >> I think this is a great idea :) >> >> You can't imagine how much I blame Debian each time I have to type the >> full path "/sbin/ifconfig" as a non-root user on virtual servers to just >> know the IP address the DHCP server assigned to the machine. >> > Start using the right tool for the job (I mean: "ip addr show"), > and stop blaming Debian. Using ifconfig by the way will show > you only part of the information (eg: if there's more than one > IP assign, ifconfig will not show it). > I am aware of the shortcomings of ifconfig. However it is still a nice and valid tool to just show the ip address the DHCP server assigned to a machine (AFAIK DHCP servers only assign one IP address per interface) Also ip is only available for Linux kernels, but ifconfig is available on any *nix. Furthermore the output formatting of ifconfig is more user friendly than the one of ip. > If ifconfig is the only reason why we should move everything, > change $PATH and so on, please find a better excuse, because > I'm not at all buying into that one! > After reading the thread, I think that probably the better idea is to: * Fix #312669 * Add /sbin:/usr/sbin to the PATH of the first user (uid 1000) Since on single-user machines (laptops/PCs) I think is a valid assumption to think that the (probably) unique user of the machine is also the administrator of that machine. So he will probably find useful to have the administrative commands on his path. Also on multi-user machines (servers) the first user installed is probably the user the sysadmin will use for himself. signature.asc Description: OpenPGP digital signature
Re: Change default PATH for Jessie / wheezy+1
On Wed, Aug 08, 2012 at 07:44:25PM +0200, Vincent Bernat wrote: > ❦ 8 août 2012 12:21 CEST, David Given : > > > ifconfig (before this discussion I'd never even *heard* of ip) > > All what is inside "net-tools" package is old and hardly maintained. > > "arp" can be replaced by "ip neigh", "ifconfig" by "ip addr" or "ip link", > "route" by > "ip route", "ipmaddr" by "ip maddr", "mii-tool" by "ethtool", "netstat" > by "ss", "nameif" by "ip link", "iptunnel" by "ip tunnel". "iproute" and > "ethtool" packages are kept in sync with kernels and allow the user to > use the latest features. Apologies for the rant mode: # mii-tool eth0: negotiated 100baseTx-FD flow-control, link ok # ethtool ethtool: bad command line argument(s) For more information run ethtool -h # ethtool -h | grep ' ethtool' | grep -v DEVNAME ethtool -h|--help Show this help ethtool --version Show version number So no, it's not a simple replacement. While I'm in rant mode, note that there's no programmable bash completion for the subcommands of ip. I wasn't aware of ip neigh. -- Tzafrir Cohen | tzaf...@jabber.org | VIM is http://tzafrir.org.il || a Mutt's tzaf...@cohens.org.il || best tzaf...@debian.org|| friend -- 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/20120809081646.gj12...@pear.tzafrir.org.il
