Re: Debian Light Desktop - meta package
On Fri, 12 May 2006 01:10:17 +0200, Eugen Paiuc <[EMAIL PROTECTED]> wrote: >I'd add localepurge - witch save my >25 % disk space on 6-700 mb >installation. Localepurge is a bad hack which tries to compensate for a shortcoming in dpkg, one that I have been waiting to be fixed since I started using Debian nearly ten years ago. I begin to lose my hope. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: bits from the release team
On Fri, 5 May 2006 18:56:21 +0200, Pierre Habouzit <[EMAIL PROTECTED]> wrote: > that would obviously mean two signatures per package (but I don't > think that's that much work) Considered that we are currently waiting since months (half a year?) for a security feature that used to work and has been disabled on purpose to be allowed again, I don't think that it is adviseable to propose any changes that need ftpmaster approval. >IMHO, changing the key every year at any date is not problematic at all, >because there is plenty of solution to do smooth replacement of the >key. Provided that the infrastructure maintainers play along, which is too much to expect for the current holders of this job. Remember, they're volunteers, and you cannot force them to do their job. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Intent to hijack Bacula
Roberto Lumbreras wrote: Hey, again, don't be so rude... Being harsh is not the same as being rude. some of those serious policy violations are things like mistakes erasing logfiles and editing conffiles that couldn't be done in another way. Are you serious? There's no excuse, ever, for editing conffiles in maintainer scripts. I guess I'm a harsh mentor, but I tend to refuse sponsoring packages until I'm really happy with them, which includes trying to actively break the package, trying to find errors, finding minor nits, etc. For a new package, this usually works out to about ten iterations before I'm happy to upload a package. - tfheen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
Adam Borowski <[EMAIL PROTECTED]> writes: > On Thu, May 11, 2006 at 04:49:26PM -0400, Joe Smith wrote: >> On the other hand, if we continue that thought process we could end up >> with all headers and libraries in /usr/share/, which is absurd. > > Why? This is exactly what's beautiful, especially if EVERYTHING ends up in > /usr/share/ at one day, at which point /share/ will be redundant and the FHS > will change. > >> Indeed, the current proposal almost seems to be reversing this. >> >Non-target specific libraries and header files remain in $prefix/lib and >> >$prefix/include. >> It seems to me that libraries and headers that are not target specific are >> supposed to go in /usr/share. >> That is because if they are not target specific they are most certainly >> cross-platform. Maybe they should. The amount of software thatr assumes /usr/include is being used might be to big of a problem though to get that changed any time soon. > I remember a lab that consisted mostly of SGI Indy boxes, a SunOS server, > some O2 and a stray Linux or two. The common problem was incompatibility of > binaries: things compiled on an Indy worked on the Indies and O2, but things > compiled on O2 were incompatible with Indy. Exactly the same thing as > i386->i486->i586->i686->amd64. > > Now, imagine that /usr/bin is split this way: > /usr/bin (perl, bash) > /usr/bin/indy (binaries) > /usr/bin/o2 (binaries) > /usr/bin/sun (binaries) [1] > Can you see what I mean? By just having different PATHs, everything would > be completely transparent. And the multiarch would take care of all > libraries and headers. That would be total insanity. Just think about the number of scripts with "#!/usr/bin/python" in it that would have to be changed. And how would you even change them to pick the right architectures python? Same for sh, perl, javal, ocaml, . Also depending on PATH to be specific for each arch would be a violation of debian policy somewhere. >> Hm... This entire concept seems messy. It seems that processors that >> support multiple architectures, as well as cross compilition are begining >> to blur the line between /usr and /usr/share. > > It's not "messy", it's plain awesome. And if the line gets blurred into > oblivion, it will be a reason for joy. No solution for multiarch I've seen so far has changed anything for cross compiling though. That is quite a different story. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
"Olaf van der Spek" <[EMAIL PROTECTED]> writes: > On 5/10/06, Matt Taggart and others <[EMAIL PROTECTED]> wrote: >> For a couple years now a few of us have been talking about an idea called >> "multiarch". This is a way to seamlessly allow support for multiple different >> binary targets on the same system, for example running both i386-linux-gnu >> and >> amd64-linux-gnu binaries on the same system (many other working combinations >> exist as well). I have created a new page in the wiki to track info and >> status > > Does it also allow completely arbitrary combinations to be installed? There are 3 cases that concern multiarch: 1) no Multiarch line (all old packages) Only one architecture of this package can be installed and any depends on this package must match the ABI. This keeps all existing debs working as they work now. It is the only save assumption. 2) Multiarch: no This package does not need to have multiple architectures installed (and nearly always can't). That means any depends on it do not involve the ABI. No library is in this package and any architecture will fullfill the depends for any other. Basicaly this means this is a binary package with only a command line interface that is architecture independent. 3) Multiarch: yes This package can have multiple architectures installed and any depending package must have the matching ABI installed for it. Any library package has to set this if they want to support multiarch. All the essential, required and base libraries need to support this as a minimum. X, gnome and kde almost certainly need this too for the users benefit. More obscure libs can probably get away with sticking to option 1. >> * allow for seamless large ABI transitions >> * allow users to smoothly migrate from one arch to another >> * do things like "partial architectures" so that we can add weird >> processor variants without needing to add an entire new port to the >> pool/mirrors >> * better assimilate the *BSD kernels and userspaces >> * better support non-monopoly archs, since they may be able to run bits >> for other archs >> * maybe even to do stuff like use non-native archs (with support for >> other binary targets) to build native bits (m68k emulator on >> superfast amd64?). >> * other cool stuff > > Does it also allow multiple versions of the same package to be > installed at the same time? > For example, multiple minor versions or multiple major versions? Only if they also differ in the architecture/abi. This won't remove the need to rename libfoo1 to libfoo2 on ABI changes. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
"Joe Smith" <[EMAIL PROTECTED]> writes: > "Daniel Ruoso" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] >>Em Qui, 2006-05-11 às 09:56 +0200, Gabor Gombas escreveu: >>> On Wed, May 10, 2006 at 03:33:45PM +0200, Olaf van der Spek wrote: >>> > Why would that not fly? >>> > Both versions of the arch-independent package could be installed at >>> > the same time. >>> /usr/share/foo/bar can't point to two different files at the same time, >>> so you can't install multiple package versions containing >>> incompatible /usr/share/foo/bar files. >>> The only way to support your proposal would be to kill the concept of >>> arch-independent packages and make everything arch-dependent. >> >>And what if dpkg knows about it and handle arch-independant packages in >>a different way? >> >>In fact, if the system is multiarch, dpkg should have a centralized list >>of which packages are installed for each architecture and which packages >>are installed for arch: all... >> >>But there's still the problem of arch-independant files inside >>arch-dependant files (maybe an arch-dependant package should not include >>arch-indenpendant files at all)... > > The problem is when foo [i386] depends on bar [all] 1.0, > but foo [amd64] depends on bar [all] 2.0. > > There is simply no good way to have bar [all] 1.0 and bar [all] 2.0 > installed, > so foo [i386] and foo [amd64] cannot both be installed. That can not happen in a release. Only one bar can be in testing and then one of the foos would be uninstallable. Britney prevents that. MfG Goswin PS: I will (and does already anyway) happen all the time in sid depending on the speed of buildds. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
[EMAIL PROTECTED] writes:
> There is yet another issue with the $arch portion of the canonical system
> name: chips which are upgrades of other chips. For instance, Fedora will
> give you 'i686', while Debian will give you 'i486'. This will (and should)
> result in two different directories -- different multiarch variants.
> However, programs compiled for i486 will run on i686.
>
> This raises fairly complex program interpreter issues for the simplest case
> (intercompatibility between Debian and RedHat on x86).
> Software must expect to be able to install to the i486-linux-gnu directories
> and function immediately, even on a "natively" i686-linux-gnu system.
> Likewise software should be able to install to the i686-linux-gnu directories
> and function immediately if the chip is actually an i686, even on an
> i486-linux-gnu system.
A proposed solution to this is pretty simple:
dpkg/apt can check all archs compatible with the cpu (and enabled in
the config). That means on i686 it can check i486, i585 and i686.
When installing dpkg/apt look at the ABI of each package instead of
the architecture and i[456]86 are all ia32. Those package naturaly
conflict and only one of them can be installed in parallel.
Whether you use i486-linux-gnu or i686-linux-gnu for i686 optimized
packages remains open but it is a simple change for the ld to include
that dir. If i686-linux-gnu is consistently used for i686 optimized
packages then one could even allow installing i486 and i686 flavours
of a package and have any of them suffice for a depends.
> Now, this is in fact trivial with the current non-multiarch situation. We
> must be careful not to break it with multiarch! Perhaps an "x86 annexe" to
> the specifications would help?
>
> I *believe* that this can be handled as follows:
> (1) Specify a list of arch-os pairs which are ABI-compatible
> (i486-linux-gnu, i586-linux-gnu, i686-linux-gnu perhaps)
> (2) Rework the program interpreter to search through all three arch-os pairs,
> starting with the "highest" one which the actual chip supports.
>
> However, this all seems to duplicate the existing functionality with
> /usr/lib/tls/{i486, i586, i686}. But perhaps it should be considered
> to be replacing that functionality? That seems like a wise way to go,
> actually.
That support is arch specific and varies widely between archs. It also
goes into "minor" differences within one arch, e.g. i686 is available
with and without cmov instruction.
> If not, it may be simpler to just specify outright that all x86 machines
> should use i486-linux-gnu, NOT i686-linux-gnu, regardless of what
> config.guess thinks, and that libraries compiled for the higher chips
> should use the subdirectories.
>
> Please consider the x86 intercompatibility case before making any final
> proposals. It's very important. :-)
>
> --Nathanael Nerode
Given that ld already covers the subelties of different i*86
architectures many people feel it is best to leave it there and just
put all i*86 in i486. After all, they are all one ABI and that is what
we actualy sort for.
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
Thiemo Seufer <[EMAIL PROTECTED]> writes: > I think we need a canonical ABI-OS (or ABI-KERNEL-OS ?) table which > provides mappings for multiarch-sensitive programs. I have dpkg-multiarch for that and other things like cflags, ldflags, libdir and the like. dpkg-multiarch is used just like dpkg-architecture just that it has different variables and an extra parameter to specifiy the target ABI. E.g. asking for CFLAGS for target ABI i486-linux-gnu on x86_64 will give you "-m32". MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
On 5/13/06, Goswin von Brederlow <[EMAIL PROTECTED]> wrote: That would be total insanity. Just think about the number of scripts with "#!/usr/bin/python" in it that would have to be changed. And how Shouldn't such hard-coded paths be avoided in the long term (anyway)? would you even change them to pick the right architectures python? Same for sh, perl, javal, ocaml, . I think the dependency should be considered a configuration issue. Use #!python instead and have the 'environment' pick the right binary target.
Re: python 2.4?
On Fri, 12 May 2006, Andreas Barth wrote: > > How about, right now, just a statement "this is what the issues are". > > Or even, "this [URL here] is the mailing list post where the issues > > are outlined." > > I forgot about them. So, I need to collect them again. Even release > managers don't have a superhuman brain (though we sometimes pretend we > do :). The only issue is Matthias Klose who absolutely wants to push big packaging changes at the same time[1] whereas everybody else agree that we should take our time for those changes since we managed to live with the current python policy until now. Doko wants python-central but the python modules team uses mostly python-support: http://wiki.debian.org/DebianPythonTODO I certainly hope we can discuss that IRL at Debconf. I would welcome a Python BoF. Cheers, [1] Otherwise he could already have uploaded them since the packages are ready... cf http://lists.debian.org/debian-python/2006/01/msg00028.html -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Getting rid of circular dependencies, stage 4
Le Sam 13 Mai 2006 08:45, Adrian von Bidder a écrit : > On Wednesday 10 May 2006 16:21, Daniel Schepler wrote: > > Le Mardi 09 Mai 2006 22:49, Bill Allombert a écrit : > > > Debian Qt/KDE Maintainers > > > > ... > > > > > libkcal2b > > > libkdepim1a > > > > It looks like these two have circular dependencies because > > libkdepim depends on libkcal, while a couple of the standard > > libkcal plugins (namely kcal_kabc.so and kcal_remote.so) depend on > > libkdepim. I don't see any easy way to disentangle these. > > At least three possibilities: > > (*) most systems probably have both installed anyway, so why not > merge the packages? (Back to kdepim-libs...) those libs are used by user to develop plugins, and I'm rather not happy to see sonames disappear. The split was meant for them, that would IMHO be a significant step backward. > (*) have libkcal2b only recommend libkdepim1a > > (*) split libkcal2b into the lib and a separate libkcal-plugins > package. I do not work on kdepim directly, and I don't know really what the interdependancies between those are, and what happen if we don't have the plugins e.g. but I guess that's the direction to look at. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpyvjQet8fnY.pgp Description: PGP signature
Re: Bug#361418: [Proposal] new Debian menu structure
Hello Debian people, I am proposing a new version of the new Debian menu structure proposal incorporating changes that have been proposed. Here the change from the previous draft: - change 'HAM Radio' to 'Amateur Radio'. - revert change 'Educational' -> 'Education'. - add 'Electronics' in place of 'Technical/Electronics'. - add 'Engineering' in place of 'Technical/Engineering'. - change 'Mathematical' to 'Mathematics'. - revert change 'Scientific' -> 'Science'. - rename 'Games/Arcade' to 'Games/Action'. - 'Modules' splited in 'FVWM Modules' and 'Window Maker'. - Lot of typo fix, courtesy of debian-l10-english. The changes from the current menu structure are listed below. The full listing is in attachment. Background: -- The menu structure define the list of sections and subsections of the Debian menu system (which are displayed in window-managers menus). The official list is part of the Debian menu subpolicy. This list is a bit outdated, so we are proposing an update. Proposal: Following discussion on debian-policy I am formally proposing the new Debian menu structure devised by Linas Zvirblis to be included in the Debian menu subpolicy. For transitionning from the old structure, the translate_menus system will be reused. What should you do: -- --- As a packages maintainer: check whether your menu entry fit in the new structure. --- As a translator: check whether the new names are easier to understand and translate. --- As a Debian user: check whether the new structure improve the Debian menu system. Thanks in advance for all your suggestions for improvement. Please send them to this buglog so we find them. Please find in attachment: - 1) The proposed new menu structure 2) The translate_menus file. To experiment with the new menu structure, copy this file to /etc/menu-methods/ and rerun update-menus, the new menu structure will be in effect as far as renaming of section are concerned (this will not add/remove new sections by itself). Note that this is English only until menu is translated (which will happen as soon as the new structure is finalised and official). summary of changes: -- -- Removed Sections -- Apps/Tools (351 entry) Games/Sports(7 entries) Screen/Root-window (8 entries) -- Renamed Sections -- Applications [was:Apps] Amateur Radio [was:Hamradio] Data Management [was:Databases] Electronics [was:Technical] Mathematics [was:Math] Network [was:Net] System System/Administration [was:Admin] System/Language Environment [was:Language-Environment] Terminal Emulators [was:XShells] Games Action [was:Arcade] Blocks [was:Tetris-like] Screen Saving [was:Save] Locking [was:Lock] Window Managers [was:WindowManagers] FVWM Modules [was:WindowManagers/Modules] -- New Sections -- Applications Accessibility [new] Engineering [new] File Management [new] Mobile Devices [new] Network Network/Communication [new] Network/File Transfer [new] Network/Monitoring [new] Network/Web Browsing [new] Network/Web News [new] Office [new] Project Management [new] System System/Hardware [new] System/Monitoring [new] System/Package Management [new] System/Security [new] TV and Radio [new] Video [new] Web Development [new] Games Tools [new] Window Maker [new] Acknowledgement: --- This new structure was devised by Linas Zvirblis with input from the debian-policy mailing list. Cheers, -- Bill. <[EMAIL PROTECTED]> Imagine a large red swirl here. -- The Menu Structure -- Applications [was:Apps] Normal applications. This is a top-level section, do not put entries here. Accessibility [new] Tools to aid people with disabilities or for machines lacking usual input devices. gok, yasr, dasher Amateur Radio [was:Hamradio] Anything relating to HAM radio. baken, hamsoft, twlog Data Management [was:Databases] Interactive database programs, collection managers, address books, bibliography tools, etc. gaby, alexandria, mdbtools Editors Editors, other than office word processors, for text-based information. ksubtile, nano, hexedit Education Educational and training software. gtypist, gcompris, quiz Electronics [was:Technical] Circuit design tools, simulators and assemblers for microprocessors, etc. geda, gnucap, tkgate Emulators Software that allows you to run non-native software or more than one OS at a time. wine, dosemu, qemu Engineering [new] CAD, UML tools, and other technical software not directly related to electronics. tcm, qcad, pythoncad File Management [new] Tools for file management, archiving, searching, CD/DVD burning, backup, etc. file-roller, mc, baobab Graphics 2D and 3D graphics manipulation software. gimp, inkscape, imagemagick Mathematics [was:Math] Mathematics-related software. gcalctool, snapea,
Re: Testing security archive move
Neil McGovern wrote: > --- > Debian Testing Security Team May 12th, 2006 > secure-testing-team@lists.alioth.debian.org > http://secure-testing-master.debian.net/ > --- > > Testing security archive move > > The Debian testing security team is pleased to announce the integration of > the secure testing archive to http://security.debian.org > This message should probably also be sent to debian-user and debian-announce, and maybe even debian-security-announce. I know that there are many folks that participate in debian-user and watch the other lists that are not also subscribed to debian-devel or debian-devel-announce. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~roberto signature.asc Description: OpenPGP digital signature
Re: bits from the release team
On Wed, May 10, 2006 at 11:05:03AM +0200, Goswin von Brederlow wrote: > Pierre Habouzit <[EMAIL PROTECTED]> writes: > > Le Ven 5 Mai 2006 18:41, Florian Weimer a écrit : [..] > Except that apt-get fails if any of the signatures are unknown or > expired. So you still need both keys and not just one of them as you > intent. This was fixed in January IIRC. [..] > > IMHO, changing the key every year at any date is not problematic at all, > > because there is plenty of solution to do smooth replacement of the > > key. > > Do you see any drawbacks with my proposal of having Release.key next > to each Releas.gpg or do you have a better idea that will work for > every apt-getable archive? If we do this, we must make sure that Relesae.key is properly authenticated. The authentication of the debian-archive-keyring package is the same as for any other package, we have a signed Release file for it with valid md5sums. I like the general idea of this and would like to combine it with the idea of having a master-key. I think that the debian-archive-keyring solve the problem of key-rollover more or less. But it does not solve the problem of key-compromises. The archive key is then invalid and we can't sign a new debian-archive-keyring package with it. A possible solution for this problem is a master key that is only used to issue new signing keys and is otherwise stored offline/off-site (and maybe split). A "apt-key update" would download a new keyring from a fixed location (maybe next to the Release file as Goswin suggested) and check if the new keys are signed with the master key. If so, the key is considered trusted. What do the others think about this? It shouldn't be very hard to implement, we can just ship the new master public-key in the debian-archive-keyring package (or just put it straight into apt). The problem here is of course what to do if the master key is compromised :) But the trust chain has to start somewhere and the master key would only be used once a year to issue new signing keys and that will expose it much less than our current signing key. Cheers, Michael -- Linux is not The Answer. Yes is the answer. Linux is The Question. - Neo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
getifaddr
I wrote a network byte monitor in BSD, thinking that it would port directly to GNU with a few minor changes. However, I've found that the if_addr structure does not contain a link to the if_data struct on GNU stdlib. What function calls should I make to get this similar data in GNU land? -- Regards, Ed :: http://www.s5h.net proud bash person :%s/Open Source/Free Software/g :: Free DNS available -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gcc 4.1 or not
Em Qui, 2006-05-11 às 15:05 -0300, Gustavo Franco escreveu: > by mail, really ? Well, that's weird. Why we've usertags[0] too ? > > [0] = http://wiki.debian.org/bugs.debian.org/usertags Usertags are not simply for "blocking" relations tagging. Usertags are supposed to be a way for users to do whatever categorization they want without messing with "real data" in the BTS. A blocked bug makes more sense in this case, because this is not simply 'I would like to see these stuff together', but a real issue we have that depends on others. Hope that helps on your understanding =) See ya, -- Gustavo Noronha Silva <[EMAIL PROTECTED]> http://people.debian.org/~kov/ signature.asc Description: Esta é uma parte de mensagem assinada digitalmente
using /usr/bin/nologin instead of /bin/false in adduser?
Hi, in login 4.0.13, /usr/bin/nologin has appeared which seems to be a good default choice for accounts that do not allow shell login. I am now wondering whether (and when) I should change adduser to use /usr/bin/nologin instead of /bin/false in the default case of disabled login. Are we sufficiently secure if an account with that login shell is being logged in while /usr is not yet mounted? Is it desireable to have adduser depend on login >= 4.0.13? Any comments will be appreciated. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: using /usr/bin/nologin instead of /bin/false in adduser?
* Marc Haber <[EMAIL PROTECTED]> [060513 16:34]: > in login 4.0.13, /usr/bin/nologin has appeared which seems to be a > good default choice for accounts that do not allow shell login. /bin/false and /bin/true have the advantage of relatively well-defined meanings (no login vs. no shell login). So some absurd ftp server or something might compare it with /bin/false, but then of course the second defense line of an disabled password hash is still there. Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: using /usr/bin/nologin instead of /bin/false in adduser?
Bernhard R. Link wrote: > * Marc Haber <[EMAIL PROTECTED]> [060513 16:34]: > >>in login 4.0.13, /usr/bin/nologin has appeared which seems to be a >>good default choice for accounts that do not allow shell login. > > > /bin/false and /bin/true have the advantage of relatively well-defined > meanings (no login vs. no shell login). > So some absurd ftp server or something might compare it with /bin/false, > but then of course the second defense line of an disabled password hash > is still there. > Out of curiousity, what happens when someone tries to login and /usr is unavailable? If the shell is set to something in /bin, it will still be used. What is the default action when the user's shell is not available? -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~roberto signature.asc Description: OpenPGP digital signature
Re: multiarch status update
I just felt like interjecting after having been reading up on this tread. The whole multiarch situation is exactly why my workstation was re-installed with FC5's x86_64 from the old Debian amd64 distro. Someday when Debian has multiarch I'll switch it back but for now all my 64 bit machines are running FC5 because it works a hell of a lot better than Debian right now. While there are definitely differences between the packaging formats it would appear that a solution for this is out there and from reading the thread sounds like people want to make it more difficult than it possibly is. Or maybe I'm just seeing that and it's really that people think it's too difficult so it won't be worth the effort. Who knows! Looking through my FC5 I can easily tell the 32-bit libraries as they're the ones installed under paths like /usr/lib and /lib64 while the 64-bit libraries are the ones in /usr/lib64 and /lib64. If I run 'file *' while in /usr/bin I find binaries that are both 64- and 32-bit side-by-side. Granted most are 64-bit only and only a few are 32-bit only, but there are a couple that are both in which case most are support binaries and have a suffix of either -32 or -64 to their names. The ones that fall into this latter category are things like gdk-pixbuf-query-loaders, gtk-query-immodules and pango-querymodules. The nice thing is I have no problem grabbing a i386 package and installing it or even a 64-bit package that makes use of 32-bit libraries. The solution is out there and I think it's probably much simplier than it's being made out to be if it really becomes a high priority for Debian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: using /usr/bin/nologin instead of /bin/false in adduser?
On Sat, May 13, 2006 at 01:17:02PM -0400, Roberto C. Sanchez wrote: > Out of curiousity, what happens when someone tries to login and /usr is > unavailable? If the shell is set to something in /bin, it will still be > used. What is the default action when the user's shell is not available? foo:x:1002:1002:,,,:/home/foo:/bin/ Debian GNU/Linux testing/unstable umbar tty5 umbar login: foo Password: Linux umbar 2.6.16-1-686 #2 Thu May 4 18:22:23 UTC 2006 i686 Cannot execute /bin/: No such file or directory Debian GNU/Linux testing/unstable umbar tty5 umbar login: /* Note: the password below is correct every time */ [~]$ ssh -l foo ::1 foo@::1's password: Permission denied, please try again. foo@::1's password: Permission denied, please try again. foo@::1's password: Permission denied (publickey,password). [~]$ scp DEADJOE [EMAIL PROTECTED]::1]: foo@::1's password: Permission denied, please try again. foo@::1's password: Permission denied, please try again. foo@::1's password: Permission denied (publickey,password). lost connection [~]$ May 13 19:43:32 umbar sshd[7413]: User foo not allowed because shell /bin/ does not exist May 13 19:43:32 umbar sshd[7413]: Failed none for invalid user foo from ::1 port 47974 ssh2 May 13 19:43:34 umbar sshd[7413]: (pam_unix) authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=ip6-localhost user=foo May 13 19:43:36 umbar sshd[7413]: Failed password for invalid user foo from ::1 port 47974 ssh2 May 13 19:43:44 umbar last message repeated 2 times May 13 19:43:44 umbar sshd[7413]: (pam_unix) 2 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=ip6-localhost user=foo With /bin/true: [~]$ scp DEADJOE [EMAIL PROTECTED]::1]: foo@::1's password: lost connection [~]$ May 13 19:50:25 umbar sshd[7465]: Accepted password for foo from ::1 port 53466 ssh2 May 13 19:50:25 umbar sshd[7467]: (pam_unix) session opened for user foo by (uid=0) May 13 19:50:25 umbar sshd[7467]: (pam_unix) session closed for user foo -- 1KB // Rule #6: If violence wasn't your last resort, // you failed to resort to enough of it. // - The Seven Habits of Highly Effective Pirates -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
cleaning up lib*-dev packages?
I use deborphan to get rid of unneeded packages on my system. But I have various lib*-dev packages installed to satisfy the build-dependencies of packages that I maintain or otherwise build from source. Deborphan reports these as orphaned, but I (usually) still need them. (When the build-dependencies change, some of these might really be orphans, but I can't easily tell.) Is there a way to tell deborphan to follow the build-dependencies of a set of source packages? I know about deborphan's keep file, but that's too tedious to keep up-to-date by hand. Is there another tool I should be using? -- Eric Cooper e c c @ c m u . e d u -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: using /usr/bin/nologin instead of /bin/false in adduser?
* Roberto C. Sanchez: > Out of curiousity, what happens when someone tries to login and /usr is > unavailable? If the shell is set to something in /bin, it will still be > used. What is the default action when the user's shell is not available? It's also interesting how this interacts with non-shell SSH services (such as port forwarding or maybe even SFTP). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#367112: ITP: advancecomp -- collection of recompression utilities
Package: wnpp Severity: wishlist Owner: Piotr Ozarowski <[EMAIL PROTECTED]> * Package name: advancecomp Version : 1.15 Upstream Author : Andrea Mazzoleni <[EMAIL PROTECTED]> * URL : http://advancemame.sourceforge.net/ * License : GPL, LGPL Programming Lang: C, C++ Description : collection of recompression utilities AdvanceCOMP is mainly intended for recompressing your rom, snapshot and clip collection of emulated games. . The main features are: * Recompress ZIP, GZ, PNG and MNG files using the Deflate 7-Zip implementation * Recompress MNG files using Delta and Move optimization -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16.12-grsec Locale: LANG=pl_PL, LC_CTYPE=pl_PL (charmap=ISO-8859-2) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
Scripsit "Olaf van der Spek" <[EMAIL PROTECTED]> > Goswin von Brederlow <[EMAIL PROTECTED]> wrote: >> That would be total insanity. Just think about the number of scripts >> with "#!/usr/bin/python" in it that would have to be changed. And how > Shouldn't such hard-coded paths be avoided in the long term (anyway)? The Linux kernel requires a full path for #! scripts. This makes sense if one considers a #! program to be something that should have predictable behavior no matter what the user happens to have in his $PATH. In multiarch, the right approach to this particular problem is to arrange for /usr/bin/python to be a symlink to /usr/bin/$arch/python with $arch chosen (somehow) appropriately for a default python interpreter. -- Henning Makholm"Detta, sade de, vore rena sanningen; ty de kunde tala sanning lika väl som någon annan, när de bara visste vad det tjänade til." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#367116: ITP: airport-utils -- configuration and management utilities for the Apple AirPort wireless base stations
Package: wnpp Severity: wishlist Owner: Julien BLACHE <[EMAIL PROTECTED]> * Package name: airport-utils Version : undecided yet Upstream Author : Jon Sevy <[EMAIL PROTECTED]> * URL : http://edge.cs.drexel.edu/GICL/people/sevy/airport/index.html * License : GPL Programming Lang: Java Description : configuration and management utilities for the Apple AirPort wireless base stations This package regroups all the AirPort utilities written by Jon Sevy: - airport2config: configurator for the Snow and Extreme base stations - airportconfig: configurator for the Graphite base station (original AirPort base station / Lucent RG-1000) - hostmon: host monitor - ipinspector: IP inspector - linkmon: link monitor - modem: modem utility - portinspector: port inspector I am waiting for the gcj-4.1 transition to be over to finalize the packages, as the current classpath is buggy and the apps won't run (both native builds and jars fail, both work with the classpath from gcj-4.1). I am undecided on the jars vs. native builds issue as of yet. The bytecode runs incredibly slow with kaffe so I tend to favour native builds right now. JB. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16 Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
On Sat, May 13, 2006 at 10:54:57PM +0200, Henning Makholm wrote: > The Linux kernel requires a full path for #! scripts. This makes > sense if one considers a #! program to be something that should have > predictable behavior no matter what the user happens to have in his > $PATH. The standard idiom for this seems to be "#! /usr/bin/env python". /* Stienar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
Henning Makholm wrote: In multiarch, the right approach to this particular problem is to arrange for /usr/bin/python to be a symlink to /usr/bin/$arch/python with $arch chosen (somehow) appropriately for a default python interpreter. Apart from the fact that no multiarch proposals have tried to multiarchify /usr/bin and /bin, but are rather letting applications for which multiarch makes sense (think gcc) handle this themselves. I so far haven't seen any compelling arguments for multiarchifying the whole archive including all of */bin. - tfheen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
