approx (was Re: apt-proxy)
On Mon, Nov 14, 2005 at 08:40:04AM +0100, Brian May wrote: > Is a back port available for sarge? If not, how feasible would it be > to create on? Does it depend on anything not in sarge? Approx needs the current version of libocamlnet-ocaml-dev, but otherwise should compile and work OK in sarge. On Mon, Nov 14, 2005 at 08:40:04AM +0100, Eduard Bloch wrote: > Update your package description please. Current apt-cacher does not > require Apache. Yes, I noticed that when I saw the recent thread about apt-cacher's path_map option. It should be fixed in the next upload. As far as I can see, the primary difference is that approx supports FTP to remote repositories (which apt-cacher is likely to do too in the future), and is compiled to native code (which may not matter in practice). A secondary difference is that approx doesn't keep any meta information (HTTP headers) in the cache, just the downloaded files themselves. Apt-cacher has more flexibility in name mapping, and can integrate (or not) with an existing webserver. Is that a fair comparison? -- 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]
when and why did python(-minimal) become essential?
I saw today that the python-minimal package in unstable is tagged as Essential (and currently pulls in python2.3). According to policy, this is supposed to happen only after discussion on debian-devel and consensus is reached, but I couldn't find that discussion in the list archives. -- 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: question on hurd-i386 Debian architecture
On Mon, Mar 13, 2006 at 01:05:38AM +0100, Pjotr Kourzanov wrote: > Dpkg maintainer(s), what do you think is the correct procedure for > additing these things i.e., extra -vendor and -libc fields? I already > have a patch for dpkg package which adds-in uclibc variants... I hope toolchain-source maintainer(s) will also join the party. -- 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]
advice needed on handling network port conflicts
I've written a proxy server (approx) that is intended to be a drop-in replacement for apt-proxy. Sites that use apt-proxy are likely to have lots of http://foo:/... lines in the /etc/apt/sources.list files on multiple client machines. To avoid having to edit all those files, approx also listens to port by default. But if apt-proxy is still installed and running when apt-proxy starts up, it will fail because the port is in use. Should I make the approx package conflict with apt-proxy? Both packages allow the port to be changed to something else, so it's not impossible for them to coexist (just difficult in their default configurations). Any suggestions or policy pointers here would be appreciated. -- 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: dummy packages and "Replaces:" field
On Fri, Jun 24, 2005 at 09:52:34AM -0300, Margarita Manterola wrote: > So, if we had a new header to indicate that this is the > "drop-in" replacement of the old program, it could work, right? [...] > Which should this new header be? > "Substitutes:", "Supersedes:", "Takes-Over:", "Drop-In Replaces:", > "Follows:" ? Since there should be a unique replacement that old and new package maintainer(s) agree on, I think the old package (the one being replaced) should have the header. (Perhaps "Replaced-By:" ?) -- 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: tpkg-debarch should support "arm-linux-gnu" target (was Re: small quirks setting up a cross-compile toolchain)
This thread suggests that it's time for toolchain-source to be retired: http://lists.debian.org/debian-embedded/2006/07/msg00068.html If not, perhaps some documentation pointing to this alternative method of building cross tools should be added to the toolchain-source package. -- 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]
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]
Bug#378938: ITP: ocaml-sha1 -- SHA1 binding for OCaml
Package: wnpp Severity: wishlist Owner: Eric Cooper <[EMAIL PROTECTED]> * Package name: ocaml-sha1 Version : 0.4 Upstream Author : Vincent Hanquez <[EMAIL PROTECTED]> * URL : http://tab.snarc.org/download/ocaml/ocaml_sha1-0.4.tar.bz2 * License : GPL Programming Lang: OCaml Description : SHA1 binding for OCaml SHA1 is a 160-bit cryptographic hash function. This library provides an interface for OCaml programs to use SHA1 functions. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-strat 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: Bug#320067: ITP: vamps -- Vamps evaporates DVD compliant MPEG2 program streams by selectively copying audio and subpicture tracks and by re-quantizing the embedded elementary video stream.
On Wed, Jul 27, 2005 at 12:09:18AM +0300, Lars Wirzenius wrote: > ti, 2005-07-26 kello 21:36 +0200, Moratti Claudio kirjoitti: > > Description : Vamps evaporates DVD compliant MPEG2 program streams > > by selectively copying audio and subpicture tracks and by re-quantizing > > the embedded elementary video stream. > > This short description is a bit long and it also leaves it unclear to me > what the program actually does. The verb evaporate means, according the > WordNet dictionary: > [...] > At a guess, does vamps make MPEG2 streams smaller? Perhaps a confusion of "evaporate" with "condense"? (Maybe the thermodynamic equivalent of an "off by 1" error? :-) -- 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: Bug#315945: seyon does not work when gnome-terminal is installed
On Sun, Jul 31, 2005 at 11:59:18PM +0100, Steve McIntyre wrote: > c) write a wrapper script for the terminal emulator, and cope with > finding the right options for each possible emulator (potentially > huge amount of work) This is how it's done already in the case of gnome-terminal (see /usr/bin/gnome-terminal.wrapper). So it's reasonable to file a bug against it for better option-munging to handle this case. -- 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: apt-proxy
On Mon, Nov 07, 2005 at 11:51:55AM +1100, Brian May wrote: > Simple question: is apt-proxy still being maintained? > > Based on the growing list of bugs, I suspect not. > > A quick glance of some of the reports shows no sign of response from > the maintainer. > > Some users in fact have completely given up. > > A recent bug I have discovered makes it unusable. > > However, I prefer the approach over apt-cacher, as the apt-sources > entries remain independent of the server that will be used to retrieve > the files. > > Is there a good alternative? I wrote approx for exactly this purpose. It's now in testing. -- 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]
bug closing etiquette
Suppose someone has reported a bug that the maintainer can't reproduce, but the reporter can. Is it reasonable for the maintainer to email the reporter and ask whether a new version fixes the problem, or is that considered obnoxious? -- 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]
Bug#462602: ITP: eeepc-acpi-source -- source for Eee PC ACPI module
Package: wnpp Severity: wishlist Owner: Eric Cooper <[EMAIL PROTECTED]> * Package name: eeepc-acpi-source Version : 1.0-1 Upstream Author : Eric Cooper <[EMAIL PROTECTED]> * URL : http://www.cs.cmu.edu/~ecc/eeepc-acpi_1.0.tar.gz * License : GPL Programming Lang: C Description : source for Eee PC ACPI module The eeepc_acpi module supports the hotkeys found on the Asus Eee PC. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable'), (400, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.22-3-686 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#462602: ITP: eeepc-acpi-source -- source for Eee PC ACPI module
On Sat, Jan 26, 2008 at 10:15:50PM +0100, Bastian Blank wrote: > What is the Linux upstream status of this module? At Riku Voipio's suggestion, I emailed the linux-acpi email list this morning about it. -- 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: Bug#463584: ITP: rubyripper -- an open-source secure ripper for Linux
On Fri, Feb 01, 2008 at 08:15:04PM +0100, Christian Perrier wrote: > "open source" is not really relevant here > > "secure audio ripper" seems to better fit the recommended writing > style (DevRef 6.2.2) "secure" connotes "safe from exploits", but I think what is intended is "extremely careful about obtaining an accurate copy of the audio data". -- 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: [OT] Need old Packages.gz and Release Files
On Fri, Apr 25, 2008 at 04:07:51PM +0800, Stefano Zacchiroli wrote: > You are asking generically Packages without specifying a mirror. Are > they granted to be identically replicated among all mirrors? Of course > they *probably* are due to how mirroring works, but is it *granted* that > there are no differences among mirrors? > > Would such difference inhibit proper installation due to the apt-secure > stuff? The Release file contains strong checksums of the Packages files, and it is signed with the Debian Archive key. Both of these are checked when apt does updates and installs. So as long as there are no keys from rogue repositories in apt's keyring, it should be fine. -- 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]
menu policy & use of doc-base for programming documentation
The Debian OCaml maintenance team is looking at how to organize the
HTML documentation provided by the various OCaml packages. Our first
thought was to use doc-base, but according to the doc-base
documentation, the hierarchy is determined by the Debian menu
sub-policy (http://www.debian.org/doc/packaging-manuals/menu-policy/).
The current hierarchy is only 2 levels deep, and places all
programming language libraries and tools in the same "bucket":
Apps/Programming. This makes the dhelp browser front-end to doc-base
almost useless as a programmer's documentation browser.
So, should we propose (on debian-policy) that the hierarchy be
deepened to 3 levels (Apps/Programming/{OCaml,C,Python,Perl,...})?
Or should the doc-base policy be cut loose from the menu policy?
The advantage of either of these is that we don't have to reinvent the
wheel for our documentation browser.
Another approach might be to add some more advanced filtering or
narrowing to dhelp, etc. but that requires duplicated effort in all
the clients of doc-base; and rolling our own tool, like perldoc, is
the least attractive.
--
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: menu policy & use of doc-base for programming documentation
On Tue, Sep 04, 2007 at 07:59:44PM +, Frank Küster wrote: > We have a similar problem with TeX documentation. In my opinion, > using menu categories for doc-base might have been a good start, but > we should definitely extend that now. Perhaps we should piggyback on the debtags work and have some kind of tag-based document registration and browsing, rather than trying to define the One True Hierarchy. -- 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: debian archive integrity check tool?
On Wed, Nov 14, 2007 at 01:13:39PM +0100, Václav Ovsík wrote: > So, is there some utility, that can verify checksums from archive index > files (integrity of archive)? The approx archive proxy that I wrote includes the utility "gc_approx", which garbage-collects its cache by verifying sizes and checksums agaiings Packages/Sources files, and also removes .debs that are unreachable from those files. It would require only a little modification to run on a real archive, rather than approx's cache. I can help with that if you'd like. -- 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]
how should a daemon drop privileges in a PAM-compatible way?
I wrote a daemon that is started from an init-script as root, and then uses setuid and setgid to drop to a less-privileged system user and group. A user discovered that the program breaks when he uses the libpam-tmpdir module, because TMPDIR doesn't get changed to the /tmp/user/NNN directory, so the daemon tries, unsuccessfully, to create files in /tmp. What is the correct way to handle this? I'm not very familiar with PAM, but I presume there might be other PAM modules out there that would cause similar breakage; I don't want my program to have to know about them all. I can't use an su wrapper, because the daemon needs to do some privileged things initially. Is there a high level function to "change userid, groupid and do the related PAM things" that I can use, or example code I can use? Thanks for any pointers. -- 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: Draft new policy document format
On Sun, Dec 02, 2007 at 12:34:28PM +0100, Stefano Zacchiroli wrote: > In addition to that, just some tiny nitpicking below. > [...] I had the same initial reaction, but when I re-read Manoj's introduction, I think he suggests that this docbook format should be the *output* of an XSLT tool; the various policies would be encoded as individual XML entities with a more semantically appropriate schema (TBD, I guess). -- 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]
Bug#597228: ITP: minidlna -- server for DLNA/UPnP-AV clients
Package: wnpp Severity: wishlist Owner: Eric Cooper * Package name: minidlna Version : 1.0.18-1 Upstream Author : Justin Maggard * URL : http://sourceforge.net/projects/minidlna * License : GPL and BSD Programming Lang: C Description : server for DLNA/UPnP-AV clients MiniDLNA (aka ReadyDLNA) is server software with the aim of being fully compliant with DLNA/UPnP-AV clients. The minidlna daemon serves media files (music, pictures, and video) to clients on your network. Example clients include applications such as totem and xbmc, and devices such as portable media players, smartphones, televisions, and Blu-Ray players. MiniDLNA is a simple, lightweight alternative to mediatomb, but has fewer features. It does not have a web interface for administration and must be configured by editing a text file. -- 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/20100917200824.5363.69144.report...@stratocaster.home
Re: best practice for updating inetd.conf with a user-chosen port?
On Thu, Mar 12, 2009 at 02:13:12PM +0100, Holger Levsen wrote: > On Donnerstag, 12. März 2009, Giacomo A. Catenazzi wrote: > > But now I'm not sure about: > > - if it is a good thing to have admin choosed ports > > I dont think so and I guess I'm not alone and thats why there is no best > practice to do that. The only (typo of) package where I can think off where > this is sensible as default, is one which sets up a hidden service. > > What kind of daemon are you packaging? I'm packaging approx, which for compatibility with apt-proxy defaults to port (not in /etc/services). That was fine when approx, like apt-proxy, was run as a standalone daemon from an initscript. But I just changed it to run (only) from inetd, hence this thread. Regarding the other thread in -devel about the future of inetd: in my case I found it very sensible to jettison all the code for opening sockets, binding ports, handling IPv6, handling tcp-wrappers, daemonizing processes, etc. and punt it to inetd. Since apt clients keep their connections open for many multiple, the performance hit is negligible. -- Eric Cooper e c c @ c m u . e d u -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Proposal to avoid executable naming conflicts (was: Bug#753704: ITP: amap -- Next-generation scanning tool for pentesters)
Since Debian package names must already be unique, we ought to be able to leverage that to avoid having to fight over which package gets to claim which binary name. What about making it into a user's install-time decision, rather than a developer's packaging-time decision? As a proof of concept, I copied each package's binaries on my machine into /opt//bin/. Then I union-mounted all these /opt/*/bin directories into a single /ubin (for "unified /bin"), and set my PATH to just that. I've been using it (lightly) for a couple of days without problems. I just union-mounted them in alphabetical order, but in the case of conflicts it would be easy to use a site-specific prioritization, analagous to mailcap.order, to control the shadowing. My apologies if this has already been proposed and rejected before. Cheers, Eric -- Eric Cooper e c c @ c m u . e d u -- 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/20140708153112.gb30...@google.com
Re: Proposal to avoid executable naming conflicts (was: Bug#753704: ITP: amap -- Next-generation scanning tool for pentesters)
On Wed, Jul 09, 2014 at 06:57:02AM +1200, Chris Bannister wrote: > On Tue, Jul 08, 2014 at 11:31:12AM -0400, Eric Cooper wrote: > > Since Debian package names must already be unique, we ought to be able > > to leverage that to avoid having to fight over which package gets to > > claim which binary name. > > > > What about making it into a user's install-time decision, > > rather than a developer's packaging-time decision? > > Wouldn't you get sick of 'that name has already been taken, please > try another.' message? Given how infrequently this issue has cropped up over the years, no. And a prioritization (like mailcap.order) would limit it to once per conflict. -- Eric Cooper e c c @ c m u . e d u -- 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/20140708195720.ga8...@google.com
Re: Golang >= 1.12 in Buster?
On Sat, Apr 13, 2019 at 09:54:18PM +0800, Shengjing Zhu wrote:
> FWIW, golang-1.12 was removed from buster, because the RT think
> there're too many golang for buster[1].
> At first we have golang-1.{10,11,12} in testing.
>
> [1] https://tracker.debian.org/news/1024215/golang-112-removed-from-testing/
Go has a very strong commitment to backward compatibility.
Please remove the older versions, not the new one.
--
Eric Cooper e c c @ c m u . e d u
Re: Debian distribution
On Tue, Jul 16, 2019 at 9:44 AM Kyle Edwards wrote: > > On Tue, 2019-07-16 at 10:22 +, Javeed Ahmed wrote: > > sir/madam > > can i make my own os using debian as a base and distribute it? > > Absolutely! Debian is free software, and you are free to use, modify, > and distribute it for any purpose. Please make sure to follow the rules > of each package's license (GPL, BSD, etc.), but in general, yes, all of > these licenses allow modification and redistribution. See: > > https://www.debian.org/social_contract#guidelines > > for a description of the Debian philosophy of what consitutes "free > software". See also https://www.debian.org/derivatives/
Re: Lots and lots of tiny node.js packages
I see that a similarly large number of smallish libraries are getting
packaged for golang. When I first looked into it, and maybe it's
still the case, these were only to allow other Debian packages written
in Go to be compiled; developers were still encouraged to use the Go
package ecosystem ("go get ..."). And whenever I've built node
programs, I also just use "npm install ..." rather than looking for a
Debian package.
If that's the primary use case, then perhaps there could be a simpler
way to deal with the dependencies of node and Go projects than
packaging each of them for a mostly nonexistent developer audience.
We could just make snapshots of the versions (obtained via "go get" or
"npm install") used to build the end-user packages, for
auditing/security/reproducibility purposes. These could be stored in a
well-defined place in the Debian archives, without "exporting" them
via .deb files, Packages entries, etc.
--
Eric Cooper e c c @ c m u . e d u
Re: apt-get upgrade removing ifupdown on jessie→stretch upgrade
On Thu, Feb 23, 2017 at 11:22:17AM +1300, martin f krafft wrote: > [...] I've been using APT since one of its first > versions, and I think "upgrade" has existed from the early days with > precisely the promise that, unlike "dist-upgrade", it would not > modify the set of installed packages, either way. Indeed, from apt-get(8), under "upgrade": "under no circumstances are currently installed packages removed, or packages not already installed retrieved and installed." -- Eric Cooper e c c @ c m u . e d u
Re: Running tests with xvfb
On Fri, Jul 28, 2017 at 10:46:57PM +0200, Jeff wrote: > I have a package whose tests crash X on my machine, which uses nouveau. > This makes testing rather inconvenient. > > Running the tests in a chroot with xvfb works, but takes an age (i.e. a > couple of minutes) to set up the chroot. This is also not conducive to > rapid testing of small changes. > > Running the test outside the chroot with xvfb still crashes X, because > xvfb seems to grab the "real" X if it is there. > > Is there a way of getting xvfb to ignore the system X? Can you use an xorg.conf with the "dummy" driver instead of xvfb? I use a "with-dummy-xserver" wrapper script for situations like that. -- Eric Cooper e c c @ c m u . e d u
