Bug#1057884: ITP: golang-github-harenber-ptc-go -- A driver for SCS PACTOR modems for Pat
Package: wnpp Severity: wishlist Owner: tony mancill * Package name: golang-github-harenber-ptc-go Version : 2.2.3-1 Upstream Author : * URL : https://github.com/harenber/ptc-go * License : Expat Programming Lang: Go Description : A driver for SCS PACTOR modems for Pat ptc-go - SCS PACTOR modems driver for the Pat Winlink-client . Documentation has been moved to the Wiki (https://github.com/harenber/ptc-go/wiki). -- The rationale for packaging golang-github-harenber-ptc-go will permit enabling PACTOR modem support in pat - see: #1057276 [1] This package depends on wnpp bug #1057882 [2]. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057276 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057882
Bug#1057882: ITP: golang-github-howeyc-crc16 -- Implements the 16-bit cyclic redundancy check, or CRC-16, checksum
Package: wnpp
Severity: wishlist
Owner: tony mancill
* Package name: golang-github-howeyc-crc16
Version : 0.0~git20171223.2b2a61e-1
Upstream Author : Chris Howey
* URL : https://github.com/howeyc/crc16
* License : BSD-3-clause
Programming Lang: Go
Description : Implements the 16-bit cyclic redundancy check, or CRC-16,
checksum
GoDoc (https://godoc.org/github.com/howeyc/crc16) Build Status
(http://travis-ci.org/howeyc/crc16)
.
CRC16
.
A Go package implementing the 16-bit Cyclic Redundancy Check, or CRC-16,
checksum.
.
Usage
.
To generate the hash of a byte slice, use the crc16.Checksum()
(https://godoc.org/github.com/howeyc/crc16#Checksum) function:
.
import "github.com/howeyc/crc16"
.
data := byte("test")
checksum := crc16.Checksum(data, crc16.IBMTable)
.
The package provides the following
(https://godoc.org/github.com/howeyc/crc16#pkg-variables) hashing tables.
For each of these tables, a shorthand can be used.
.
// This is the same as crc16.Checksum(data, crc16.IBMTable)
checksum := crc16.ChecksumIBM(data)
.
Using the hash.Hash (https://godoc.org/hash#Hash) interface also works.
.
h := crc16.New(crc16.IBMTable)
data := byte("test")
data2 := byte("data")
h.Write(data)
h.Write(data2)
checksum := h.Sum(nil)
.
Changelog
.
* 2017.03.27 - Added MBus checksum
* 2017.05.27 - Added checksum function without XOR
* 2017.12.08 - Implement encoding.BinaryMarshaler and
encoding.BinaryUnmarshaler to allow saving and recreating their
internal state.
--
The rationale for packaging is github.com/howeyc/crc16 is that it is a
dependency of github.com/harenber/ptc-go, which will permit enabling
PACTOR modem support in pat (winlink), as discussed in #1057276:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057276
Bug#1017877: ITP: reload4j -- Drop-in replacement for Apache log4j 1.2 Java logging framework
Package: wnpp Severity: wishlist Owner: tony mancill X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: reload4j Version : 1.2.22 Upstream Author : Ceki Gülcü * URL : https://reload4j.qos.ch/ * License : Apache 2.0 Programming Lang: Java Description : Drop-in replacement for Apache log4j 1.2 Java logging framework The reload4j project is a fork of Apache log4j version 1.2.17 in order to fix most pressing security issues. It is intended as a drop-in replacement for log4j version 1.2.17. By drop-in, we mean the replacement of log4j.jar with reload4j.jar in your build without needing to make changes to source code, i.e., to your java files. With release 1.2.18.0 and later, the reload4j project offers a clear and easy migration path for the thousands of users who have an urgent need to fix vulnerabilities in log4j 1.2.17. This is being packaged because it is a dependency of slf4j [1] since version 1.7.33 (Debian currently ships version 1.7.32 [2]) and because a number of upstream projects have switched to reload4j. Having a separate reload4j source package will allow us to provide a clean transition from liblog4j1.2-java -> libreload4j-java and fully EOL Apache log4j 1.2. [1] https://www.slf4j.org/ [2] https://tracker.debian.org/pkg/libslf4j-java signature.asc Description: PGP signature
Bug#971823: ITP: simrisc -- simulation model for risk associated with breast cancer
Package: wnpp Severity: wishlist Owner: tony mancill X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: simrisc Version : 13.02.00 Upstream Author : Frank B. Brokken * URL : https://fbb-git.gitlab.io/simrisc/ * License : GPL-3+ Programming Lang: C++ Description : simulation model for breast cancer risk https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3668482/ I intend to maintain this package as part of the Debian-Med team. Regards, tony signature.asc Description: PGP signature
Bug#890222: ITP: jnacl -- Pure Java implementation of the NaCl: Networking and Cryptography library
Package: wnpp Severity: wishlist Owner: tony mancill * Package name: jnacl Version : 0.1.1 Upstream Author : Neil Alexander * URL : https://neilalexander.eu/jnacl * License : BSD-2-clause Programming Lang: Java Description : Pure Java implementation of the NaCl: Networking and Cryptography library jnacl is a library that implements some of Daniel J. Bernstein's NaCl encryption primitives. The functions are written in pure Java, and are therefore very straight-forward to make use of in a Java application without the use of native libraries and bindings. The following primitives are included: - curve25519: Elliptic curve key agreement - salsa20: Stream cipher - poly1305: Message authenticator (MAC) It is open-source and available on GitHub. Even though it has not been comprehensively benchmarked, jnacl performs exceptionally well, even on resource-constrained Android platforms. This package will be maintained by the Debian Java Team. This library is a new dependency required to update jeromq. Note that the upstream author hasn't tagged releases in [0], therefore the packaging will track the releases of this fork [1]. [0] https://github.com/neilalexander/jnacl [1] https://github.com/trevorbernard/jnacl signature.asc Description: PGP signature
Bug#863685: ITP: jbibtex -- Java BibTeX and LaTeX parser and formatter library
Package: wnpp Severity: wishlist Owner: tony mancill * Package name: jbibtex Version : 1.0.15 Upstream Author : Villu Ruusmann, University of Tartu * URL : https://github.com/jbibtex/jbibtex * License : BSD-3-clause Programming Lang: Java Description : Java BibTeX and LaTeX parser and formatter library jbibtex provides a BibTeX parser, writer, and methods to iterate over entries in a BibTex database. It additionally provides utility classes to parse LaTeX strings into plain text representations. This library is a dependency of citeproc-java [1], which is in turn a dependency for packaging of JabRef 4.x. The package will be maintained by the Java Team. It is unrelated to the "Japanized BibTeX" jbibtex-base package [2] (src:ptex-base). [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841020 [2] https://packages.debian.org/unstable/jbibtex-base signature.asc Description: PGP signature
Bug#847046: ITP: podcastparser -- Simple, fast and efficient podcast parser in Python
Package: wnpp Severity: wishlist Owner: tony mancill * Package name: podcastparser Version : 0.6.0 Upstream Author : Thomas Perl * URL : https://github.com/gpodder/podcastparser * License : Expat/MIT Programming Lang: Python Description : Simple, fast and efficient podcast parser in Python The podcast parser project is a library from the gPodder project to provide an easy and reliable way of parsing RSS- and Atom-based podcast feeds in Python. This is being packaged as a dependency of gPodder version 3.9.2. signature.asc Description: PGP signature
Re: Bug#845471: ITP: java-diff-utils -- library for computing diffs, applying patches, and generation of side-by-side view in Java
On Wed, Nov 23, 2016 at 10:19:06PM +0100, Emmanuel Bourg wrote: > This is probably a duplicate of #696165, i.e. an ITP for the same > library when it was hosted on Google Code. Unfortunately the original > code has a license issue. Bah! Thank you for the pointer - it is most definitely a duplicate. I was searching here [1] for other ITPs but didn't consider looking for archived ITPs. Cheers, tony [1] https://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=unstable;package=wnpp signature.asc Description: PGP signature
Bug#845471: ITP: java-diff-utils -- library for computing diffs, applying patches, and generation of side-by-side view in Java
Package: wnpp Severity: wishlist Owner: tony mancill * Package name: java-diff-utils Version : 2.1.1 Upstream Author : Dmitry Naumenko, Brendan Kromhout * URL : https://github.com/bkromhout/java-diff-utils * License : Apache 2.0 Programming Lang: Java Description : library for computing diffs, applying patches, and generation of side-by-side view in Java The java-diff-utils library is for computing diffs, applying patches, generation side-by-side view in Java. It is an open source library for performing comparison operations between chunks of text: computing diffs, applying patches, generating unified diffs or parsing them, generating diff output for easy future display (like a side-by-side view) and so on. The main reason for creating this library was the lack of easy-to-use libraries with all the usual features necessary for working with diff files. Originally it was inspired by the JRCS library and its nice diff module design. This package is required for the upgrade of JabRef to 3.x (#810725). It will be team-maintained by the Java Team. The code originates from Google Code and there are numerous extant forks available on GitHub. The "bkromhout" fork was chosen as the basis for packaging because it is being actively maintained with participation by the JabRef upstream maintainers.
Bug#838245: ITP: java-string-similarity -- A library implementing different string similarity and distance measures.
Package: wnpp Severity: wishlist Owner: tony mancill * Package name: java-string-similarity Version : 0.18 Upstream Author : Thibault Debatty * URL : https://github.com/tdebatty/java-string-similarity * License : MIT Programming Lang: Java Description : A library implementing different string similarity and distance measures. Implementation of various string similarity and distance algorithms: Levenshtein, Jaro-winkler, n-Gram, Q-Gram, Jaccard index, Longest Common Subsequence edit distance, cosine similarity, and others. This package is reverse-dependency of packaging JabRef 3.6. It will be team-maintained by the Java Team. signature.asc Description: PGP signature
Bug#806774: ITP: mchange-commons-java -- General-purpose Java utilities by Machinery For Change, Inc.
Package: wnpp Severity: wishlist Owner: tony mancill * Package name: mchange-commons-java Version : 0.2.10 Upstream Author : Steve Waldman * URL : https://github.com/swaldman/mchange-commons-java * License : LGPL 2.1 or EPL 1.0 Programming Lang: Java Description : General-purpose Java utilities by Machinery For Change, Inc. mchange-commons-java is a utility library, a place to put widely reusable code Machinery for Change has grown over the years. It is a prerequisite for updating the c3p0 package to a current version. This package will be maintained by the Debian Java team.
Bug#806286: ITP: libgoogle-truth-java -- Assertion/Proposition framework for Java unit tests
Package: wnpp Severity: wishlist Owner: tony mancill * Package name: libgoogle-truth-java Version : 0.27 Upstream Author : Christian Gruber, Kurt Kluever, David Saff, David B * URL : http://google.github.io/truth * License : Apache 2.0 Programming Lang: Java Description : Assertion/Proposition framework for Java unit tests Truth is a testing framework designed to make your tests and their error messages more readable and discoverable, while being extensible to new types of objects. . Truth adopts a fluent style for test propositions, is extensible in several ways, supports IDE completion/discovery of available propositions, and supports different responses to un-true propositions. Truth can be used to declare JUnit-style assumptions (which skip the test on failure), assertions (interrupt the test on failure), and expectations (continue the test, but collect errors and report failure at the end). This package is a pre-requisite for packaging the latest version of the closure-compiler.
Re: Bug#756172: ITP: ssh-cron -- cron-like job scheduler that handles ssh key passphrases
On 07/31/2014 02:59 PM, Jeroen Dekkers wrote: > At Wed, 30 Jul 2014 22:17:43 -0700, > tony mancill wrote: >> I contacted the upstream author (on the cc: - hi Frank), and his concern >> with the passphraseless key trigger mechanism is precisely that you >> don't have a passphrase. The key is unprotected and subject to >> theft/unauthorized use. This could potentially occur on the system that >> is (normally) the legitimate source of the trigger. > > But ssh-cron will need to have the passphrase to be able to use the > key, so someone who can steal the key from ssh-cron can also steal the > passphrase from ssh-cron. What is the added security benefit of > storing a key and passphrase instead of a passphraseless key? ssh-cron uses ssh-agent, as Clint Byrum suggested in his post. If you're curious to learn more, please refer to the upstream page: http://sshcron.sourceforge.net/ signature.asc Description: OpenPGP digital signature
Re: Bug#756172: ITP: ssh-cron -- cron-like job scheduler that handles ssh key passphrases
On 07/27/2014 08:40 AM, tony mancill wrote: > On 07/27/2014 01:54 AM, Marc Haber wrote: >> On Sat, 26 Jul 2014 21:05:37 -0700, tony mancill >> wrote: >>> * Package name : ssh-cron >>> Version : 0.91.01 >>> Upstream Author : Frank B. Brokken >>> * URL: http://sshcron.sourceforge.net/ >>> * License: GPL-2+ >>> Programming Lang: C++ >>> Description : cron-like job scheduler that handles ssh key passphrases >>> >>> ssh-cron acts like cron, but is provided with ssh passphrases allowing >>> its commands to access remote systems without requiring a passphrase >>> to be stored in a clear-text file or resorting to ssh keys without >>> passphrases. >> >> Why would one use such a tool? passphraseless keys exist, and can be >> configured to be secure. > > Hello Marc, > > Thank you, Ansgar and Paul for responses regarding other ways to perform > these tasks. Specifically: > >> It is possible to restrict keys in .ssh/authorized_keys so that they are >> only allowed to run specific commands, see the 'command="command"' bit in >> man:sshd(8). One probably wants to combine this with no-port-forwarding >> and similar options. > > and in more detail: > >> http://blog.ganneff.de/blog/2007/12/29/ssh-triggers.html > > The idea for ssh-cron is to be able to use the keys (one might currently > already have) without having to generate separate keys for triggers, and > while maintaining a passphrase. Whether or not that's advisable given > alternatives such as ssh triggers depends on your risk tolerance and the > specifics of your environment. > > It seems like with Ganneff's trigger mechanism, one attack vector is to > steal a backup of the passphraseless key and spoof the source IP - now > you can run the trigger at will. Having a passphrase on the key could > at least slow the attacker down. I could imagine using ssh-cron > together with "command=" for a higher level of security. > > In any event, thank you for the discussion. I'll confer with the > upstream author before proceeding with the package. I contacted the upstream author (on the cc: - hi Frank), and his concern with the passphraseless key trigger mechanism is precisely that you don't have a passphrase. The key is unprotected and subject to theft/unauthorized use. This could potentially occur on the system that is (normally) the legitimate source of the trigger. Therefore, I don't think there's feature parity between the trigger mechanism and ssh-cron. (And even if there were, TIMTOWTDI, etc...) Of course once there is a package, feature requests and bug reports are welcome. Thanks for reviewing and responding to the ITP. Cheers, tony p.s. Where else but in Debian can you get constructive feedback on grammar and secure system administration *in the same thread*? :) signature.asc Description: OpenPGP digital signature
Re: Bug#756172: ITP: ssh-cron -- cron-like job scheduler than handles ssh key passphrases
/me mutters something about being incompatible with reportbug... The upstream author and URL should have been in the original report (corrected below). On 07/27/2014 01:54 AM, Marc Haber wrote: > On Sat, 26 Jul 2014 21:05:37 -0700, tony mancill > wrote: >> * Package name : ssh-cron >> Version : 0.91.01 >> Upstream Author : Frank B. Brokken >> * URL: http://sshcron.sourceforge.net/ >> * License: GPL-2+ >> Programming Lang: C++ >> Description : cron-like job scheduler than handles ssh key passphrases >> >> ssh-cron acts like cron, but is provided with ssh passphrases allowing >> its commands to access remote systems without requiring a passphrase >> to be stored in a clear-text file or resorting to ssh keys without >> passphrases. > > Why would one use such a tool? passphraseless keys exist, and can be > configured to be secure. Hello Marc, Thank you, Ansgar and Paul for responses regarding other ways to perform these tasks. Specifically: > It is possible to restrict keys in .ssh/authorized_keys so that they are > only allowed to run specific commands, see the 'command="command"' bit in > man:sshd(8). One probably wants to combine this with no-port-forwarding > and similar options. and in more detail: > http://blog.ganneff.de/blog/2007/12/29/ssh-triggers.html The idea for ssh-cron is to be able to use the keys (one might currently already have) without having to generate separate keys for triggers, and while maintaining a passphrase. Whether or not that's advisable given alternatives such as ssh triggers depends on your risk tolerance and the specifics of your environment. It seems like with Ganneff's trigger mechanism, one attack vector is to steal a backup of the passphraseless key and spoof the source IP - now you can run the trigger at will. Having a passphrase on the key could at least slow the attacker down. I could imagine using ssh-cron together with "command=" for a higher level of security. In any event, thank you for the discussion. I'll confer with the upstream author before proceeding with the package. Regards, tony signature.asc Description: OpenPGP digital signature
Bug#756172: ITP: ssh-cron -- cron-like job scheduler than handles ssh key passphrases
Package: wnpp Severity: wishlist Owner: tony mancill * Package name: ssh-cron Version : 0.91.01 Upstream Author : * URL : * License : GPL-2+ Programming Lang: C++ Description : cron-like job scheduler than handles ssh key passphrases ssh-cron acts like cron, but is provided with ssh passphrases allowing its commands to access remote systems without requiring a passphrase to be stored in a clear-text file or resorting to ssh keys without passphrases. -- 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/20140727040536.GA17911@boson
Re: Where / what is the repo for netkit-telnetd source packages?
On 06/06/2014 06:05 PM, Ben Hutchings wrote: > On Fri, 2014-06-06 at 17:59 -0500, Pedro DeKeratry wrote: >> I wish to rebuild telnetd package with some slight mods for an >> embedded application, and I want to keep my changes on a branch off >> the maintainer line. >> >> Anyway, I can't seem to find where to clone from. help? > > There appears to be no repository for this package. Hi Pedro, You could create a suitable local repo with all of the version history with: git-import-dscs --debsnap netkit-telnet Or if you don't need any history and only want the latest copy: dget -x http://ftp.de.debian.org/debian/pool/main/n/netkit-telnet/netkit-telnet_0.17-36.dsc git-import-dsc netkit-telnet_0.17-36.dsc Maybe that helps? tony signature.asc Description: OpenPGP digital signature
Bug#749839: ITP: guncat -- cat variant that handles partial encrypted sections of text
Package: wnpp Severity: wishlist Owner: tony mancill * Package name: guncat Version : 0.92.00 Upstream Author : Frank B. Brokken * URL : http://guncat.sourceforge.net/ * License : GPLv3 Programming Lang: C++ Description : cat variant that handles mixed clear and encrypted text Guncat (Gpg UNencrypting CAT) was designed to tackle a problem encountered with (partially) PGP encrypted files (as encountered, e.g., in mailboxes): the encrypted sections of such files are relatively difficult to browse through. Guncat acts like unix's cat command, but handles (partially) encrypted sections of processed files. Sections of guncat's input files which are surrounded by -BEGIN PGP MESSAGE- and -END PGP MESSAGE- markers are decrypted before being concatenated to the standard output stream. Guncat's output (i.e., the standard output stream) may subsequently be processed by other programs, like grep or less. -- 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/20140530045452.GA20888@boson
Re: [dd-list] Please use Architecture: linux-any
On 04/12/2014 11:26 PM, Samuel Thibault wrote: > gregor herrmann, le Sun 13 Apr 2014 02:25:18 +0200, a écrit : >> On Sun, 13 Apr 2014 01:34:52 +0200, Samuel Thibault wrote: >> >>> Here is a refreshed list of the packages that should probably use >>> Architecture: linux-any, please consider using it. >> >>> Debian Perl Group >>>libvideo-ivtv-perl >> >> % grep Architecture debian/control >> Architecture: linux-any kfreebsd-any >> >> So hurd is excluded, should kfreebsd also go away? > > Well, kfreebsd currently gets > > ivtv.xs:5:25: fatal error: linux/types.h: No such file or directory > > but perhaps libvideo-ivtv-perl could be fixed so it can use kfreebsd's > v4l layer. Perhaps... For the time-being, I've uploaded a -8 with the arch set to linux-any. Thank you for identifying the issue. tony signature.asc Description: OpenPGP digital signature
Re: [mass bug] New license problem/sourceless fil/privacy problems detected by lintian
On 01/16/2014 03:58 AM, Emmanuel Bourg wrote: > Thank you for the new Java check, that will be really useful. > > Do you test if the jar files contain Java classes? Hi Emmanuel, Take a look at http://lintian.debian.org/tags/codeless-jar.html, or, better, the source for the check in java.pm in the lintian package. It may need some tweaking, but that's the check we've been using. tony signature.asc Description: OpenPGP digital signature
Re: Looking for ideas for merging a micro package...
On 09/03/2013 02:17 PM, Russ Allbery wrote: > Vincent Danjean writes: > >> The fact is that the FTP team comment was correct: it is really a small >> package. So, my question was really open (I do not know every package in >> Debian), in case someone has a useful suggestion (that does not involve >> to rewrite the script). > > moreutils is another possible home for such useful scripts, although I'm > not sure if Joey is interested in accepting Ruby scripts. I think > currently it's C and Perl. Thank you for pointing this out. I just recently uploaded a script, splitpatch, that I argued should be accepted as-is (i.e. as a "micro package") because of the dependency on ruby. Given that ruby is becoming more popular for scripting, what do folks think about a catch-all package for ruby scripts? I don't have a good feel for what the right trade-off is between: * reducing load on the archive by consolidating these tiny packages * making good use of maintainer's time, the implication being that coordinating multiple (otherwise unrelated?) ruby scripts is going to be more of a time commitment for the maintainer(s) and * making it easy (or even possible) for users to find these scripts when the package name doesn't match upstream Discuss... (and thanks in advance for constructive ideas) tony signature.asc Description: OpenPGP digital signature
Bug#709262: ITP: bpm-tools -- command-line tool to calculate beats per minute of audio
Package: wnpp Severity: wishlist Owner: tony mancill -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: bpm-tools Version : 0.3 Upstream Author : Mark Hills * URL : http://www.pogo.org.uk/~mark/bpm-tools/ * License : GPLv2 Programming Lang: C Description : command-line tool to calculate tempo of audio The bpm-tools commands are used to automatically calculate the tempo (in beats-per-minute) of music, optionally displaying an analysis and adding it to file 'tags'. The data from these tags can be especially useful for navigating a music library in DJ software such as xwax(1). The bpm command implements the algorithm on raw data, but the most commonly used command is bpm-tag to tag the file with the tempo in bpm. The bpm-graph command will produce a plot of the results of the autocorrelation. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJRnEd9AAoJECHSBYmXSz6WLA0P/R9NsuHW1rYcTZxS5/8ZtEcj yv+4RIOM35WL0JWc8o9iJFybdm7EPIOdiUyaQxpz6/KH9O4X9gc9TlffEMe//3Mu YOa0Lo17vNdHbgB2SW0NvtBGO/fAUlecW9tf2i3s6fK7pO7+B26Agf8nH7RIu73c 553f4CWWkLMSpnKnm/dJP7w/ZNXLdX7r+bxImLHlok1C1UjSdoakVUPtmPUXeRli NZFetS53QvfDreD1JhtUg7mfuej6pMmDkfuBd8cXZyX5nh0chbCGjv+Hz03zY6AY VbId5vxHlSjrAG9cydsASUmTFEbmg6iYR8M2evftIF56sVQRSQCjlfC/dxxRQg2x k926YlV71Nb5+QQduY0BEYyoFTRFrPFh3Jl8P+ilqIVcTXEElqJallhqLUgQ9gpU xIMnsOwMVMGE86qf0ZJGIKYXObvCcIsJLGJnNT1jRuLnhq5YVE1Au8Edib5RO5oR zEkFG1RddyBIuMM186nQo35WORiPhNXuGJZLqtOvqt7f5uGZimCPVrmTzTzv3fxc WsAZnrLsVCDaE7HwdpmFc55PLyqpI5n5Q9nFcKaR2f/jmD6U82AlyDkpCLkx8feh OGe+KlMY5w8Rp2yWMJNp7LVlRHhLOJIU4bU46xTrBSYlxNN5OfZTQo/NzKG9cjPp 4o5ZvkaUY9F8t0a/usGt =XpRE -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/20130522042013.14567.17317.reportbug@boson
Re: DM upload permission
>> Note, you can also use dput-ng (available in unstable) to manage DM >> permissions. The equivalent command would be: >> >> dcut dm --uid "Tobias Stefan Richter" --allow nexus >> >> I have had good luck with yodack to set DM permission as well: https://github.com/algernon/yodack Cheers, tony signature.asc Description: OpenPGP digital signature
Re: Bug#696006: ITP: tinyos -- operating system for sensor motes and embedded devices
On 12/15/2012 10:29 AM, Sebastian Reichel wrote: > On Sat, Dec 15, 2012 at 07:06:01PM +0100, John Paul Adrian Glaubitz wrote: >> On Sat, Dec 15, 2012 at 06:03:27PM +0100, Sebastian Reichel wrote: >>> The package will generate a tinyos-source binary >>> package. >> >> What exactly does the package do? Does it download the current >> upstream source and builds it for deployment? > > No. The source is included in the package. Similar to the > linux-source package. > >> What's the advantage of having this as a package in Debian? Can it be >> used for something on a running Debian system? > > In short: > > The package is needed for developing TinyOS based applications for > small embedded devices as found in sensor networks. > > A bit more descriptive: > > TinyOS is not like a normal operating system. As mentioned in the > description it's intended to be used on very small devices. > Since these have very little memory/processing power a normal > operating system kernel (e.g. Linux) cannot be used on them. > > The solution of TinyOS is having a very small operating system, > which is statically linked together with the user written software > into one big binary. This binary is then uploaded to the > microcontroller. I did some development TinyOS during my graduate work and I think packaging it for Debian is a great idea. Having the source and other tools packaged makes Debian more attractive as a development platform for TinyOS developers, researchers, and students. Or more to the point, the convenience of having it packaged makes organizations that support those users more likely to opt for Debian as a platform. (When I was working with it, it was relative chaos with some folks working under Wine and the rest of team spread across different distributions, everyone installing tinyos and the toolchain by hand.) Thank you for considering packaging this for Debian. tony signature.asc Description: OpenPGP digital signature
Bug#694278: ITP: gpg-remailer -- GnuPG-enabled remailer for mailing lists
Package: wnpp Severity: wishlist Owner: tony mancill * Package name: gpg-remailer Version : 2.53.0 Upstream Author : Frank Brokken * URL : https://www.icce.rug.nl/debian/remailer * License : GPLv3 Programming Lang: C++ Description : GnuPG-enabled remailer for mailing lists Encrypting and signing remailer for groups of users/mailing lists. The original message can be sent to the remailer encrypted and the remailer will handle decryption and re-encrypting for the list recipients. The remailed content bears the signature and/or encryption of the remailer's GPG key. For this reason, the remailer is intended to run from a dedicated user account on a secured system. The remailer supports a number of configure options related to operation, including support for: o Multi-part encrypted messages o Encrypted messages containing detached signatures o Various signature requirements for received messages o Conifgurable logging and debugging -- 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/20121124233946.20383.50809.reportbug@boson
Re: Packages removing alternatives on upgrade
On 09/23/2012 08:40 AM, Ivan Shmakov wrote: >> Jakub Wilk writes: > > [Cross-posting to packages@qa, for elvis is maintained by the QA > group.] > > > Many packages remove alternatives on upgrade, only to re-add them > > later, potentially discarding manual choices of the user. > > > See also bug #71621. > > […] > > > Debian QA Group > >elvis > >elvis-console > >elvis-tools > >ircii > > […] > > BTW, do I understand it correctly that it's just a matter of > dropping the ‘upgrade’ case from .prerm? (Possible patch > MIME'd.) > > TIA. > > > > > --- debian/elvis-console.prerm.~1~2012-09-23 13:34:49.0 + > +++ debian/elvis-console.prerm2012-09-23 15:24:02.0 + > @@ -3,7 +3,7 @@ > set -e > > case "$1" in > -upgrade|remove|deconfigure) > +remove|deconfigure) > for app in editor ex input vi view; do > update-alternatives --quiet --remove "$app" /usr/bin/elvis > done > --- debian/elvis.prerm.~1~2012-09-23 13:34:49.0 + > +++ debian/elvis.prerm2012-09-23 15:24:02.0 + > @@ -3,7 +3,7 @@ > set -e > > case "$1" in > -upgrade|remove|deconfigure) > +remove|deconfigure) > for app in editor ex input vi view; do > update-alternatives --quiet --remove "$app" /usr/bin/elvisnox > done > --- debian/elvis-tools.prerm.~1~ 2012-09-23 13:34:49.0 + > +++ debian/elvis-tools.prerm 2012-09-23 15:24:02.0 + > @@ -3,7 +3,7 @@ > set -e > > case "$1" in > -upgrade|remove|deconfigure) > +remove|deconfigure) > update-alternatives --quiet --remove ctags /usr/bin/elvtags > ;; > failed-upgrade) Can someone confirm that Ivan's proposed patch is the correct way to deal with this problem? I have the same issue in some of my packages. Thank you, tony signature.asc Description: OpenPGP digital signature
Re: ITP: ipmiutil -- Easy-to-use IPMI server management utilities
On 11/28/2011 02:33 PM, Raf Czlonka wrote: > On Mon, Nov 28, 2011 at 08:58:42PM GMT, Andy Cress wrote: >> It supports Windows servers, the others do not. So users who have mixed OS >> environments would prefer ipmiutil. > > If that's true it's enough of a reason for me for it to be packaged. I concur. The more Debian can do to ease its introduction into mixed and/or non-Debian environments, the more potentially attractive it is to users. Having impiutil part of Debian, provided that it is not buggy and is well-maintained, means one less headache for sysadmins out there. 0.02, tony signature.asc Description: OpenPGP digital signature
Re: Perl transition blockers: candidates for testing removal
On 11/18/2011 09:25 AM, Luk Claes wrote: > Hi > > The following packages block the perl transition and will become testing > removal candidates soon unless the bugs get fixed: > > ... > > * genders (#646286): patch ready, maybe NMU? Working on an upload of genders now. Sorry, for some reason I don't believe I received the initial bug report. Thanks, tony -- 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/4ec69c50.7050...@debian.org
Re: Too much disruptive NMUs
Hi Ana,
I'm happy to start the discussion.
I sponsored the upload of a number of Jari's fixes. You state that they
were disruptive, but I'm wondering to whom. The uploads were to delayed
queues and the maintainer notified via the BTS, and in all cases where
the maintainer actually ACK'd the bug report or NMU, we discussed the
matter with the maintainer and/or removed the NMU from the delayed queue.
In most cases (it may be all for the packages Jari and I worked on), the
maintainers never responded whatsoever to bug reports that were over a
year old, nor to the intent to NMU, so in a sense they could be
considered them QA uploads. I.e., if a developer can't be bothered to
even respond to a bug in the Debian BTS, then the package is essentially
orphaned. Freshening the packaging to generic best practices (or
perhaps a better term is "defacto standards") - e.g. going to the quilt
source format (which changes almost nothing), using a modern version of
debhelper, freshening a debian/watch file, or adding standard fields to
debian/control - makes things easier for everyone involved, whether it
be Debian QA or the maintainer (should he or she every opt to reengage).
I view the "absolute minimal changes" NMU process as designed for (and
more appropriate for) actively maintained packages. That is, the NMU
process assumes that there is a developer on the other end who actually
maintains the package. I do agree that the work, all of which were
either FTBFS or transition-related, could have been coordinated through
Debian QA. In hindsight that may have been a better approach. I am
interested to hear QA's perspective; is it QA that finds the uploads
disruptive?
Thank you,
tony
On 05/22/2010 06:07 AM, Ana Guerrero wrote:
>
> Hi,
>
> It is good to care for packages from people who are currently too busy and
> making NMUs to fix critical/very important bugs. However, lately I have been
> seeing a lot of NMUs that are being very disruptive [0], you have a couple of
> examples below [1]. (This is not against Jari or Nobihuro, they are just the
> latest examples I have seen today).
>
> I know this is done with the best intentions but if you think the package
> is in bad shape or neglected by the maintainer then it might better write
> to mia@, debian-qa@ or open a bug asking whether the package should be
> orphaned (or even removed). Both examples below are candidates to be orphaned.
>
> If you think this kind of changes are good, please start a discussion about
> changing this in the developers-reference.
>
> Ana
>
>
> [0] http://www.debian.org/doc/developers-reference/pkgs.html#nmu
>
> [1]
>
> This one is not even fixing a serious bug:
>
> Format: 1.8
> Date: Tue, 04 May 2010 21:39:32 +0300
> Source: xwrits
> Binary: xwrits
> Architecture: source i386
> Version: 2.21-6.1
> Distribution: unstable
> Urgency: low
> Maintainer: Helen Faulkner
> Changed-By: Jari Aalto
> Description:
> xwrits - reminds you to take a break from typing
> Closes: 579038
> Changes:
> xwrits (2.21-6.1) unstable; urgency=low
> .
>[ Jari Aalto ]
>* Non-maintainer upload.
> - Move to packaging format "3.0 (quilt)".
>* debian/clean
> - Mew file.
>* debian/compat
> - New file.
>* debian/control
> - (Build-Depends): update obsolete xutils to xutils-dev.
>(important; Closes: #579038). Remove *-1 version suffix
>from texinfo dependency. Update to debhelper 7.1.
> - (Depends): add ${misc:Depends}.
> - (Homepage): New field.
> - (Standards-Version): update to 3.8.4.
>* debian/copyright
> - Update layout and point to GPL-2.
>* debian/rules
> - Delete EOL whitespaces.
> - (DH_COMPAT): Remove.
> - (install): Update dh_clean to dh_prep.
> - (clean): Fix lintian debian-rules-ignores-make-clean-error.
>* debian/source/format
> - New file.
>* debian/watch
> - New file.
>* xwrits.1
> - Fix hyphens.
>
> ---
>
> Format: 1.8
> Date: Fri, 14 May 2010 11:28:10 +0900
> Source: a2ps
> Binary: a2ps
> Architecture: source i386
> Version: 1:4.14-1.1
> Distribution: unstable
> Urgency: low
> Maintainer: Masayuki Hatta (mhatta)
> Changed-By: Nobuhiro Iwamatsu
> Description:
> a2ps - GNU a2ps - 'Anything to PostScript' converter and pretty-printer
> Closes: 487183 507293 547907 557775 571571
> Changes:
> a2ps (1:4.14-1.1) unstable; urgency=low
> .
>* Non-maintainer upload.
>* Update debian/control.
> - Bump Standards-Version to 3.8.4
> - Update Build-Depends on debhelper 7
> - Update Depends on emacs23 instead of emacs22. (Closes: #571571)
> * Add debian/source/format.
> Set source format to "1.0".
> * Update debian/compat to 7
> * Update debian/copyright
> - Add year of Copyright.
> - Fix copyright-without-copyright-notice lintian warning.
> * Update debian/rules
> - Remove -k from dh_clean
> - Remove usr/share/info/di
Re: Request for virtual package ircd
Marco d'Itri wrote: > On Oct 12, Mario Iseli <[EMAIL PROTECTED]> wrote: > >> as described in >> http://www.debian.org/doc/packaging-manuals/virtual-package-names-list.txt >> I announce here my idea of the virtual package ircd. When I count >> correctly are at the moment 7 different IRC-daemons in Debian and they >> logically conflict with each other. So I would think an official virtual >> package would be a fine solution. There are also IRC services which work >> in general with all ircds, so it would be easier if those packages also >> could only depend on "ircd". I'm not sure that multiple IRC-daemons logically conflict with other, given that you can configure them to run on different ports. In fact, IIRC, I've had more than one ircd-like package installed on a single system in the past. Perhaps you could share more information about what the virtual package would allow? tony signature.asc Description: OpenPGP digital signature
Re: Status of BSD-like licences with advertisement clauses.
Steve Langasek wrote: > On Wed, Aug 23, 2006 at 09:20:02AM +0900, Charles Plessy wrote: > >> I have been told by two different developers that licences using the >> 4-clauses BSD licence as a template are free or non-free > > Sounds like some DD could use a licensing refresher course. 4-clause BSD has > always been considered free by Debian. Perhaps we should update our 3-clause BSD license information[0] with the 4-clause variant. That link is found here[1]. [0] http://www.debian.org/misc/bsd.license [1] http://www.debian.org/intro/free signature.asc Description: OpenPGP digital signature
Re: Why does Ubuntu have all the ideas?
Dear Ms. Jackson, I'm not certain that your post isn't purely a troll (i.e. specifically aimed to generate a negative response), so I will refrain from answering each of your points in detail. However, I think you may want learn more about the relationship between Ubuntu and Debian before you make such sweeping statements. For one, Debian and Ubuntu aren't in competition, they complement each other. Furthermore, Ubuntu wouldn't exist without Debian or hundreds of other projects. If the Debian distribution is a cake, then Ubuntu takes that cake, frosts it and decorates it, and makes it easy for everyone to get a free slice of ready-to-eat cake. One which you appear to enjoy. So instead of berating Debian, you should be celebrating it. along with the fact that you have a choice of what distribution you install on your laptop. Sincerely, tony mancill Katrina Jackson wrote: > To Whom It May Concern, > > I am concerned Debian isn't trying to meet people's needs enough. > You seem to have so many more people working for you, and you both use > the same format for things, so it doesn't make sense to me why you can't > keep up with Ubuntu. > > A. Ubuntu seems like it can get hardware support immeadiatly, but that > support never seems to quickly get to Debian. I have been using Ubuntu > since Debian doesn't wok on my laptop. Suspend doesn't work and my > wireless pro 3945ABG doesn't work. With Ubuntu everything works fine. > > B. Ubuntu members not only support mailing lists and IRC but suport > user forums which are so much more user friendly and don't fill up your > mailbox. > > C. You seem to worry only about packaging. You push people to > package. But you don't focus on making your OS better. Ubuntu has made > so many nice features for their OS that you don't seem to do. I really > don't know why. I think you need to emphsise less packaging and more > focus on making your current OS better for people. Why does Ubuntu have > to have all the great ideas for their users? One example: They have a > pop up telling you updates are ready. Now maybe you now have this > feature, I don't know, but I see great ideas like this every six months > with Ubuntu, and I see nothing from debian. Except apt, but man, one > nice thing a decade is pretty slow. > > D. Going back to C., doesn't is concern you you have so many > programmers but so few good new Ideas for your OS compared to Ubuntu > that will help your users? How do they have 10 times the good ideas you > seem to. And furthermore, when a good idea is presented to them they > say, "good idea, we should impliment that" not "there's plenty of > documantation, do it yourself". > > E. Going back to the last statement, I could write an entire email on > how people think you guys are so unapproachable and so down right mean > to users who make these suggestions. Users' concerns mean nothing to > you. ***If they did you would be spending as much time as Ubuntu coming > up with great ideas to revoultionize your OS to better meet people's > needs*** Why are you so mean? I know you will either ignore this > letter or rip my head off, but somebody needs to tell you. > > E. Mr. Hess has a nice supermarket argument but can't see that Debian > needs to steal a few things from Ubuntu, ie it goes both ways. > > There seems to be so many issues. It seems you guys just don't care > about your users. You don't go out of your way to make your users have > a better experience. I honestly think you only care about yourselves. > I doesn't seem you try to hard to care about your users. What is the > difference? Why are you guys so anti being there for your users. > > The reason why Ubuntu is more popular than you is they honestly focus > their attention on making their users happy. They actually seem to > care about people's needs. As was recently said, pretty and nice are > features too. I don't understand what the deal is. Any, good > programmers have good ideas they impliment, more then just the ability > to hack to debug. Is debian good for anything besides Debuuging, > Debugging, Debugging. Never and new great features or ideas. > > > I hope you guys will put some thought into this, but by the reputation > you have I am guessing you will say, "If a user wants something done do > it yourself, there's plenty of documentation. We don't need to change, > we are the best programmers there are. We are too good to take notes > from Ubuntu" Unfortunatly I think you just aren't smart enough to read > the writing on the wall that there is a reason Ubuntu has been for a > while now such a more popular distro then us. > > Katrina Jackson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Using the SSL snakeoil certificate
On Thu, Jul 20, 2006 at 11:24:34AM +0200, Martin Schulze wrote: > Hence, I propose to stay with virtual per-service certificates, but to > link them to the common snakeoil certificate from ssl-certificates > during configuration and only if there is no other setting. > > For example: > > Dovecot uses . > > This is a symbolic link to if > the above file or link does not exist during configuration of > dovecot. > > That way, the admin can easily replace the symlink with a real > certificate if they want per-service certificates. > > If, however, they want to have one real certificate for everything, > they can replace the snakeoil certificate like Martin Pitt proposed. This would be a great improvement. I'd suggest one more level of symlinks. Have the individual services symlink to /etc/ssl/certs/ssl-cert-site.pem, which is then symlinked to ssl-cert-snakeoil.pem. When/if the local admin installs an actual site-wide certificate, updating the one ssl-cert-site.pem symlink will update all of the individual services using the the site cert, and the snakeoil cert is still available if you ever need to fail back to it. tony -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: doc compilations: build-time or pre-built?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Steinar H. Gunderson wrote: > On Tue, Jul 04, 2006 at 07:25:16PM -0300, [EMAIL PROTECTED] wrote: >> 1) compile docs pre-build-time; or >> 2) compile docs in build-time > > Definitely the latter. We build stuff at build time for a reason, > architecture-specific or -independent alike. Is this the consensus/best-practice on this question? It seems like it would be quite taxing on the autobuilders to have to pull something like docbook (and its chain of dependencies) into a pbuilder just to recompile a manpage that doesn't change between architectures. I'm interested in this because I've typically done (2), but have recently started to think that (1) is more appropriate, particularly for packages where the documentation is a simple manpage. Thanks, tony -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEqv2QpdwBkPlyvgMRAkBmAJ9KcON1gjVHvxoxOmFyq1ZEDbIW7QCaAu6+ nhExtIr+1x+oQIR1ft7Ah38= =3/Ia -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: downgrading optimization for m68k [was: Bug#328453: pbzip2_0.9.4-1(m68k/unstable/zeus): FTBFS on m68k]
Stephen R Marenka wrote: > On Fri, Sep 16, 2005 at 10:40:50AM +1000, Anibal Monsalve Salazar wrote: > > >>>to bug #317475 on gcc-4.0. As a workaround, you might try compiling with >>>less optimization or gcc-3.3/gcc-3.4. > > >>+ifneq (,$(findstring m68k,$(DEB_HOST_ARCH))) >>+ CFLAGS = -Wall -O0 >>+endif > > > For the record, -O2 seems to work fine. The segfaults only seem to > apply to -O3 and better (at least in my experience). This seems to affect one of the packages I sponsor as well: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=325557 If gcc-4.0 is going to puke on lots of packages that use -O3, doesn't it make more sense to upload a patched gcc-4.0 for m68k that silently changes the optimization level back to 2 untile the problem with the compiler can be fixed rather than upload and recompile a large number of packages for every architecture? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#277175: upload in progress
Package: wnpp Followup-For: Bug #277175 Owner: tony mancill <[EMAIL PROTECTED]> I've packaged this CPAN module and will upload a package shortly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#293965: ITP: libvideo-ivtv-perl -- Perl extension for using V4l2 in the ivtv perl scripts
Package: wnpp Severity: wishlist Owner: tony mancill <[EMAIL PROTECTED]> * Package name: libvideo-ivtv-perl Version : 0.13 Upstream Author : James A. Pattie <[EMAIL PROTECTED]> * URL : http://sourceforge.net/project/showfiles.php?group_id=73219&package_id=83888 * License : GPL Description : Perl extension for using V4l2 in the ivtv perl scripts The Video::ivtv module will provide helper methods for working with videodev2.h structures and making ioctl calls that have proven to be too difficult to create pack strings for in perl itself. This is not supposed to be an equivalent of the Video::Capture::V4l module which was created for videodev.h. The package is necessary for running the utilities included with ivtv-0.2 and newer. - Information: Debian Release: 3.1 Architecture: amd64 (x86_64) Kernel: Linux 2.6.10 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The Debian Mentors Project
On Tue, 13 May 2003, Daniel K. Gebhart wrote: > Matthew Palmer <[EMAIL PROTECTED]> wrote Tue, May 13, 2003 at 08:36:12AM > +1000: > > *very* serious problem for anyone who starts relying on the binary packages > > uploaded to m.d.n. What sort of protections do you have in place or plan to > > put in place to protect against this sort of thing? > > The mentors project is not something like apt-get.org! Hosting stable > and safe packages is not our goal. We are responsible for the contact > between maintainers and sponsors. Not between maintainers and users. Appropos of this and Colin's statement, my suggestion is to make only a deb-src URL available on the site, and to only host source packages. For packages destined for the Debian archive, it's critical that they be reviewed as source, and that they build from source. I do a fair amount of sponsoring, and never have need for a binary of the package being sponsored. Cheers, tony <[EMAIL PROTECTED]
Re: Debian Animation ;)
On Sun, 14 Apr 2002, Darren Salt wrote: > xanim says that DIVX(44495658) is unsupported. :-\ FYI, aviplay (in the avifile-player package) plays the animation just fine. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gpm and X problem investigated
On Sat, 2 Sep 2000, Massimo Dal Zotto wrote: > I had the same problems when using the new defaults (-R ms3 and Intellimouse > on /dev/gpmdata). > 2)use the default gpm repeater type (msc). It is compatible with > the old behavior of slink and gpm, and works without problems. > The default gpm repeater type is `msc' an not `raw'. Setting it > to raw would force the user to configure it also in XF86config, > while with msc it could be configured automatically (see next > point). After probably a good hour of mucking about with this when I installed potato from scratch about 6 months ago, I concur with using msc as the default repeater. On my Thinkpad 600E, this is not only the only configuration that worked, but the Z-axis button worked automatically as a middle mouse button (which according to the Linux Laptops page documentation at the time wasn't supposed to work at all). Do we need to start collecting a database of what combinations of configurations work in which situations? Perhaps there are other configurations that simply won't work using msc (or ms3) repeater types. If we knew about them, we could make gpmconfig a bit smarter. [EMAIL PROTECTED] | She who says, does not know. http://www.debian.org | She who knows, does not say. |- Tao Te Ching -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Help
On Tue, 29 Aug 2000, Hamish Moffatt wrote: > On Mon, Aug 28, 2000 at 03:18:26PM +, Dale Scheetz wrote: > > I checked and all the permissions are like they are supposed to be. (BTW, > > what is the "t" in the permission string "drwxrwxrwt" anyway?) > > 't' is the sticky bit. On a directory, it means a user can only delete > their own files, despite having write access to the entire directory. Just a point of clarification - if the user owns the directory where the sticky bit is set, then the user can delete anybody's files, regardless of the sticky bit. If the user doesn't own the directory where the sticky bit is set then Hamish's statement is correct (and quite useful!), even if that user does have write permission to the directory. [EMAIL PROTECTED] | I am a concientious man. http://www.debian.org | When I throw rocks at seabirds, | I leave no tern unstoned. (Ogden Nash) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
OT: 64MB laptop DIMM for donation
Sorry to post this to -devel, but it wasn't clear where else to post, and I didn't have any luck on IRC. Plus, hopefully this will help somebody out. I have 64MB memory module from an IBM Thinkpad 385XD but it should fit in any model that takes 60ns 8Mx64 3.3v memory. (I don't know if it's buffered or not.) It's an IBM part, FRU: 42H2817, and also says "OPT: 76H0268" on the label. If you are sure that you can use this stick of memory and are a contributor to Debian, send me an email signed with your Debian key (or have your sponsor/mentor/"Debian person who can vouch for your contribution" send an email on your behalf), and I'll drop it in the mail to you. (In the case of multiple responses, I'll do something fair, or at least creative.) Cheers, tony [EMAIL PROTECTED] | Linux: because a PC is a terrible thing to waste http://www.debian.org |-- [EMAIL PROTECTED] put this on Tshirts in '93
Re: mkfs in /sbin, mkisofs in /usr/bin (was: Re: Intent To Split: netbase
On Thu, 17 Aug 2000, Marcus Brinkmann wrote: > On Thu, Aug 17, 2000 at 11:26:17AM -0500, Manoj Srivastava wrote: > > > > The things that we do put in /sbin, for the same reasons, we > > expect that the average user will not use them and might be confused > > by encountering them. For example, mkfs and fsck and so forth are in > > /sbin. Anyone can use these, on a file or on a device they have > > permissions for. It's not that we expect only root to use these, but > > that we expect anyone who wanted to use them to probably know enough > > about the system to be root (or at least enough more than the average > > user that they can handle putting /sbin in their path). > > There is some inconsistency here. > > ulysses:~# which mkisofs > /usr/bin/mkisofs > ulysses:~# which mke2fs > /sbin/mke2fs I disagree. You *NEED* to have a copy of mke2fs in the root filesystem in case /usr or any other mounted filesystem gets whacked. OTOH, you probably won't be mastering any CD images while your system is crippled, so having mkisofs in /usr is not inconsistent. The reason that mkisofs is not in /sbin is because /sbin should be reserved for things the core OS needs to have all of the time on the root partition. If you start putting mkisofs and the like in /sbin, then you have the problem of / growing over time. If you put mke2fs in /usr, then you're going to wish that you hadn't one day. I'm not sure that I understand this entire thread. Much of "where files go" is based on history/tradition, and like it or not, most of Linux/Debian's heritage is based on how the various Unices have solved certain problems over the past 25 years or so. Change is good, but only when folks understand why they're changing things, insted of being too lazy to add something to their PATH or learn where (and *why*) commands are where they are. (Sorry, this really isn't intended to flame anyone, but it seems that -devel gets off on the weirdest tangents sometimes.) tony [EMAIL PROTECTED] | Time after time we lose sight of the way. http://www.debian.org | Our causes can't see their effects. | (Neil Peart)
Re: Hosed system during package build
On Thu, 16 Sep 1999, Dale Scheetz wrote: > Upon rebooting the system, I got told that there was no console device, so > I rebooted to my "emergency" slink system. (My normal development system > is on hda1, with hda2 for swap, and hda3 for the slink system) > > /dev contained the empty directory /pty, and a |init* file. > Recovering /dev from hda3 just brought up further errors: > /etc/init.d and /etc/resolv.conf are gone, but most of /etc is still > there. > > /bin is completely gone, as is /boot, although the system will still boot > on either the hda3 kernel or the hda1 kernel (both of which reside in > /dev/hda1/boot), so although the file system doesn't seem to know about > these files, they are still there for LILO to use. Saving the possibility of filesystem corruption based on disk failure (you didn't mention a long complicated fsck, so I'll assume that there was not one), the first thing that comes to mind is to ask you: You don't run your build script as the root user, do you? In other words, you are using fakeroot to build your packages, right? My guess is that an errant "rm -fr *" started and ran until it whacked a library it (or the "find" or whatever invoked it) was using. [EMAIL PROTECTED] | I am a concientious man. http://www.debian.org | When I throw rocks at seabirds, | I leave no tern unstoned. (Ogden Nash)
Re: mass-installing Debian
On 19 May 1999, Dean Carpenter wrote: > I've been thinking a bit about the need for mass-installations. Having > done a few of them, it gets to be a tad tedious ... > > Currently, the preinst and postinst scripts ask the user questions, and > make changes according to the responses. Instead of that, we need a > general service script that processes a package-specific file containing > questions and answer-variables. The results of this get appended to > an installation response file that each package can source to retrieve > the answers it needs. Hrmm, got that ? Regarding mass-installations: For the admin: As a start, why couldn't you just 'expect' the first installation, make expect part of base, and use that session to control the entire thing (from selecting the correct package retrieval method on). For the developers: On a related note, couldn't we have an environment variable set at installation time, e.g. "NON_INTERACTIVE_DPKG=TRUE", and have the maintainer scripts check this to see if they should ask questions or not? If this variable were set to TRUE, I'd like to see packages which require configuration send mail to root with a message like: "To finish configuring bind, please run /usr/sbin/bindconfig" If you don't like the idea of sending mail (maybe mail is not yet setup), then have the maintainer scripts write their config commands to a single script, like so: echo "/usr/sbin/bindconfig" >> ~root/debian_postinstall_config.sh Then the sysadmin can run this single script to complete the install at her leisure. Perhaps some mechanism like those above can tide the user community over until we have a new tool(set). Comments? [EMAIL PROTECTED] | You won't get wise with the sleep still in http://www.mancill.com | your eyes - no matter what your dream might be. |(Peart)
Re: evan leibovitch and the LPI certification tests
sorry feel compelled to dive into the fray, but... On Tue, 18 May 1999, Mark Mealman wrote: > On Tue, May 18, 1999 at 03:16:38PM -0700, Craig Brozefsky wrote: > > > > "Debian, so far, has been very popular in academia, hobbyist and > > research circles, but doesn't appear to be a big player in the retail > > and commercial fields." > > Well damn, I work for one of the US's largest insurance brokerage firms > and we use Debian. > > Guess I should run out and pick up Red Hat, before the LPI police come > knocking. I'm guilty too! I guess I should just hand over my production frame-relay routers all over the US and in Sweden, Germany, Malaysia, and Brazil too. Let me just fill out a purchase order for 40 copies of RH at $50 apiece... > Sure would hate to give up Debian's top-notch security, stability, and > ease of maintenance though. Then again, we're commercial and not > educational so we really don't need those qualities in a Linux > distribution. Commercial people never need to worry about things like true "hassle-free" licensing, or being able to build a custom sendmail package in 10 minutes by grabbing the source package and adding their own configuration files (btw, thanks to Richard Nelson for a rock-stable package). And who wants to be able to upgrade with a single command line or without reboots? Oh yea, and who wants to use free software when you follow a single vendor down the yellow brick road until they have you right where they want you?!? [EMAIL PROTECTED] | You don't get something for nothing, http://www.mancill.com | You can't have freedom for free. |(Peart)
