Re: more current iproute

Ce jour Wed, 10 Nov 2004, Andreas Barth a dit: > Dear all, > > I uploaded the current version of iproute (that also works with current > 2.6-kernels) to experimental. As this is a major change, any test > reports are appreciated. Also, a review of the source whether I managed > to keep all securi

Re: spamassassin3 - is memory usage ok now?

Ce jour Thu, 11 Nov 2004, Andreas Barth a dit: > Hi, > > I can remember some people complained that spamassassin3 had increased > ressource usage. For the people who had problems: Are they fixed now > with the new release that appeared in unstable? > > Cheers, > Andi not sure what upload you sp

Re: Nagios Packages

Ce jour Sun, 14 Nov 2004, Joerg Jaspert a dit: > Hi > > A while ago the old Nagios Maintainer filed an O: for nagios. A group of > people, including myself, started an Alioth-Project for it and did some > work with the packaging. > Now we are at a point where we can consider an upload into the ar

Re: Nagios Packages

Ce jour Sun, 14 Nov 2004, Joerg Jaspert a dit: > Hi > built, installed, and ran fine on PPC. it's now happily running as before. -- ,''`. http://www.debian.org/ http://www.nuit.ca/ : :' : Debian GNU/Linux http://simonraven.nuit.ca/ '

Re: please test new quik with initrd-support (was: Re: getting quik into sarge?

Ce jour Sun, 28 Nov 2004, Christian Leimer a dit: > Hi! > > Can someone please post a sample quik.conf? > > Do you use the ramdisk option or the append string one, any other settings? > > I have an Umax S900 and it does not work here. > Says something about can not find the root device. > > I

Re: please test new quik with initrd-support

Ce jour Sun, 28 Nov 2004, Simon Vallet a dit: > On Fri, 26 Nov 2004 10:58:48 +0100 > Holger Levsen <[EMAIL PROTECTED]> wrote: > > kernel-image-2.6.9-powerpc and initrd : I get stuck at > VFS : Unable to mount root fs on unknown-block (1,0), > which is what I experi

Re: please test new quik with initrd-support

Ce jour Tue, 30 Nov 2004, Simon Vallet a dit: > On Mon, 29 Nov 2004 23:05:03 +0100 > Peter 'p2' De Schrijver <[EMAIL PROTECTED]> wrote: > > > The quik.conf should be : > > > > image=/boot/vmlinux-2.6.9-powerpc > > append="root=/dev/

Re: please test new quik with initrd-support (was: Re: getting quik into sarge?

Ce jour Sun, 28 Nov 2004, Colin Watson a dit: > On Fri, Nov 26, 2004 at 10:58:48AM +0100, Holger Levsen wrote: > > and, better not to forget, the new quik.deb is available at > > http://www.ulyssis.org/~p2/debjes/ > > Could the quik.conf(5) man page also be modified to include > documentation of

Re: Summary / new quik available (was Re: please test new quik with initrd-support (was: Re: getting quik into sarge?

Ce jour Fri, 03 Dec 2004, Holger Levsen a dit: i'd appreciate not having it hijacked from under me. i don't mind getting help, and i do appreciate that, but i get the feeling it's being hijacked from me. you could at least tell me WTF is going on. eric (the current quik maintainer) -- Microsoft

new quik in sid

hello, the new quik is now in sid, as per discussed earlier i was to email [EMAIL PROTECTED] to notify them about it. well, it's there (finally! :). you have been warned eric -- "I believe that part of what propels science is the thirst for wonder. It's a very powerful emotion. All childr

条码应用合作

debian-devel 你好： 　　　我们是毕思条码网（WWW.BSEAY.COM)，我们致力于条码资讯平台的建设以关注条码应用和发展，欢迎各位来毕思条码网看看 　　　，欢迎链接，欢迎加入毕思条码论坛。 　 　　　毕思条码论坛(www.bseay.com/forum.asp)提供给大家一个条码交流的场所，大家可以在论坛中互相交流。毕思条码论坛目标是打造网上最热最火的条码专业论坛 　　　如此邮件给你带来不便，我们在此向您道歉！ 毕思条码网 　

Bug#157710: bug in compiler (cpp) internal error code 323 in main.cpp:174

Package: general Version: N/A; reported 2002-08-21 Severity: important -- System Information Debian Release: testing/unstable Architecture: powerpc Kernel: Linux pentangle.dyndns.org 2.4.18-xfs-1.1 #1 Tue Aug 13 03:58:02 EDT 2002 ppc Locale: LANG=C, LC_CTYPE=fr_CA more specifically, received t

Re: Mandatory LC_ALL=C.UTF-8 during package building

d require disabling this check, and thus hide an entire class of bugs from detection. Simon

Re: Mandatory LC_ALL=C.UTF-8 during package building

e package that are known to affect reproducibility -- that would be declarative, so the reproducible-builds project can disable the test and get meaningful results for the remaining typical problems, and could be checked and handled by dpkg-buildpackage as well. Simon

Re: Locale sanitizer (Was: Mandatory LC_ALL=C.UTF-8 during package building)

On Thu, 06 Jun 2024 at 14:40:23 +0200, Daniel Gröber wrote: > On Thu, Jun 06, 2024 at 11:32:33AM +0200, Simon Richter wrote: > > If your package is not reproducible without it, then your package is > > broken. > > At build-time, if a program doesn't call setlocale befor

Re: Mandatory LC_ALL=C.UTF-8 during package building

On Thu, 06 Jun 2024 at 13:32:27 +0300, Hakan Bayındır wrote: > C, or C.UTF-8 is not a universal locale which works > for all. Sure, and I don't think anyone is arguing that you or anyone else should set the locale for your interactive terminal session, your GUI desktop environment, or even your se

Re: File descriptor hard limit is now bumped to the kernel max

On Thu, 06 Jun 2024 at 15:21:22 +0200, Marco d'Itri wrote: > On Jun 06, Luca Boccassi wrote: > > The last time this was tried some packages were still not ready, so it > > was patched out to let them be fixed. > > I missed the venerable inn 1.x at the time, and I never noticed that it > allocates

Re: Mandatory LC_ALL=C.UTF-8 during package building

On Thu, 06 Jun 2024 at 12:56:10 +0200, Johannes Schauer Marin Rodrigues wrote: > If we imagine a hypothetical switch to LC_ALL=C.UTF-8 for all source > packages by default, then there will be bugs. Do you mean: there will be bugs that break the build of certain packages, which previously built suc

Re: File descriptor hard limit is now bumped to the kernel max

On Thu, 06 Jun 2024 at 18:39:15 +0200, Marco d'Itri wrote: > On Jun 06, Simon McVittie wrote: > > I believe the change Luca describes is increasing rlim_max (hard limit) > > but not rlim_cur (soft limit), and the code touched by that patch is > > looking at rlim_cur,

Re: Mandatory LC_ALL=C.UTF-8 during package building

need incremental builds and a graphical debugger, and both of these are a major hassle in containers. Simon OpenPGP_0xEBF67A846AABE354.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature

Re: Mandatory LC_ALL=C.UTF-8 during package building

On Fri, 07 Jun 2024 at 23:22:46 +0900, Simon Richter wrote: > On 6/7/24 22:40, Alexandre Detiste wrote: > > Maybe a compromise would be to at least mandate some UTF-8 locale. > > Having an UTF-8 locale available would be a good thing, but allowing > packages to rely on the activ

Re: Mandatory LC_ALL=C.UTF-8 during package building

On Fri, 07 Jun 2024 at 14:32:14 +0200, Guillem Jover wrote: > I'm a non-native speaker, who has been involved > in l10n for a long time, while at the same time I've pretty much > always run my systems with either LANG=C.UTF-8 or before that LANG=C, > LC_CTYPE=ca_ES.UTF-8 and LC_COLLATE=ca_ES.UTF-8.

Re: Mandatory LC_ALL=C.UTF-8 during package building

Hi, On 6/8/24 00:42, Simon McVittie wrote: Having an UTF-8 locale available would be a good thing, but allowing packages to rely on the active locale to be UTF-8 based reduces our testing scope. I'm not sure I follow. Are you suggesting that we should build each package *n* times (in

Re: Suggestions about i386 support

On Mon, 10 Jun 2024 at 12:43:27 +, Stefano Rivera wrote: > The point here is that the Debian project is not intending to support > new hardware on the i386 architecture. The architecture is being kept > around primarily to support running old i386 binaries. ... and the most appropriate answers

Re: Enabling some -Werror=format* by default?

On Mon, 10 Jun 2024 at 16:24:54 +0200, Guillem Jover wrote: > In general I think it's good (in principle) to enable -Werror flags > that detect actual bugs in code, the problem is always going to be > the amount of fallout and work that creates Yes. The difficult thing here is balancing "detect ac

Re: Mandatory LC_ALL=C.UTF-8 during package building

On Sat, 08 Jun 2024 at 02:14:36 +0900, Simon Richter wrote: > Reproducibility outside of sterile environments is however a problem for us > as a distribution, because it affects how well people are able to contribute > to packages they are not directly maintaining If our package-build

Re: Suggestions about i386 support

On Mon, 10 Jun 2024 at 20:17:27 +0500, Andrey Rakhmatullin wrote: > On Mon, Jun 10, 2024 at 04:02:54PM +0100, Simon McVittie wrote: > > several important upstreams no longer consider i386 to be useful (and > > especially i386-without-SSE2), so so the burden of supporting 32-bit >

Re: Mandatory LC_ALL=C.UTF-8 during package building

Hi, On 6/11/24 00:26, Simon McVittie wrote: Reproducibility outside of sterile environments is however a problem for us as a distribution, because it affects how well people are able to contribute to packages they are not directly maintaining If our package-building entry point sets up

Re: Seeking consensus on file conflict between python3-proto-plus and nanopb

explain why the module is not up to current conventions. Simon [1] https://github.com/nanopb/nanopb/blob/master/extra/FindNanopb.cmake

Re: Reviving schroot as used by sbuild

On Tue, 25 Jun 2024 at 10:16:20 +0200, Helmut Grohne wrote: > In this work, limitations with --chroot-mode=unshare became apparent and > that lead to Johannes, Jochen and me sitting down in Berlin pondering > ideas on how to improve the situation. That is a longer story, but > eventually Timo Röhli

Re: Reviving schroot as used by sbuild

On Tue, 25 Jun 2024 at 09:32:21 -0700, Russ Allbery wrote: > Simon McVittie writes: > > I think the > > only model that should be used in new systems is to have some concept of > > a session (like schroot type=file, but unlike schroot type=directory) > > I'm not

Re: Reviving schroot as used by sbuild

On Tue, 25 Jun 2024 at 18:47:49 +0200, Guillem Jover wrote: > I manage my chroots with schroot (but not via sbuild, for dog fooding > purposes :), and use type=directory and union-type=overlay so that I > get a fast and persistent base, independent of the underlying filesystem, > with fresh instanc

Re: Reviving schroot as used by sbuild

On Tue, 25 Jun 2024 at 18:55:45 +0200, Helmut Grohne wrote: > At least for me, building container images locally is a requirement. I > have no interest in using a container registry. I expected you'd say that. podman --rootfs is one way to use it without a registry; a trivially short Dockerfile li

Re: Reviving schroot as used by sbuild

On Thu, 27 Jun 2024 at 11:46:51 +0200, Helmut Grohne wrote: > I am concerned about behavioural differences due to the reimplementation > from first principles aspect though. Jochen and Aurelien will know more > here, but I think we had a fair number of ftbfs due to such differences. > None of them

Re: Reviving schroot as used by sbuild

On Thu, 27 Jun 2024 at 17:26:20 +0200, Johannes Schauer Marin Rodrigues wrote: > But, if everybody is so excited about this, where are the sbuild contributors > implementing this? I'm sorry, consider it added it to my list. As usual, there's no guarantee that I will get there within my lifetime, b

Re: Reviving schroot as used by sbuild

On Wed, 26 Jun 2024 at 18:05:15 -0400, Reinhard Tartler wrote: > I imagine that one could whip up some kind of wrapper > that is building a container either from a tarball created via mmboostrap or > similar > using buildah, have it install all necessary build dependencies, and then use > podman to

Re: Builds that pass locally but fail on sbuild? (Re: Reviving schroot as used by sbuild)

On Thu, 27 Jun 2024 at 19:56:43 -0700, Otto Kekäläinen wrote: > Could you point me to some Debian Bug # or otherwise share examples of > cases when a build succeeded locally but failed on official Debian > builders due to something that is specific for sbuild/schroot? I can't easily point you to a

Re: Reviving schroot as used by sbuild

On Mon, 01 Jul 2024 at 09:18:19 +0200, Philipp Kern wrote: > Specifically I'm concerned about what [advocating use of podman] > means for tests and if they > should be able to use unprivileged containers themselves to test things. tl;dr: There's no regression here, because you already can't run th

Re: Mandatory LC_ALL=C.UTF-8 during package building

On Tue, 02 Jul 2024 at 03:47:29 +0200, Guillem Jover wrote: > On Fri, 2024-06-07 at 15:40:07 +0200, Alexandre Detiste wrote: > > Maybe a compromise would be to at least mandate some UTF-8 locale. > > dpkg-buildpackage: Require an UTF-8 (or ASCII) locale when > building packages Allowing ASCII seem

Bug#1075715: ITP: cppi/1.18 -- adjusts or checks indentation of C and C++ preprocessor directives

Package: wnpp Severity: wishlist Owner: Simon Josefsson X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: cppi Version : 1.18-1 Upstream Author : Jim Meyering, FSF, et al * URL : https://www.gnu.org/software/cppi/ * License : GPL-3+ Programming

Re: Bug#1074175: netkit-rwho: remove for trixie?

h tnftp(d) maintainers when we have joint bugs). I haven't analyzed what rwho(d) implementations are out there. I see NetBSD/FreeBSD has one still in -current, but OpenBSD removed it during 5.x. Are people aware of any other implementations worth considering? What do you think? /Simon Gür

Re: default network management tools (was: ifupdown maintenance)

On Tue, 09 Jul 2024 at 10:57:39 +0200, Matthias Urlichs wrote: > Agreed: either it's drop-in compatible or we may as well switch the > default to NM and/or systemd-networkd. > > Well, here's a heretical thought: why don't we do that anyway, at least for > new > installations? To some ext

Re: ifupdown maintenance

On Tue, 09 Jul 2024 at 12:27:58 +0200, Bjørn Mork wrote: > Matthias Urlichs writes: > > Somebody could even write a converter. Shouldn't be that difficult, > > AFAIK there's nothing ifupdown can do that systemd[-networkd] can't. > > Run user scripts on up/down events. That's a huge blank spot in

Re: ifupdown maintenance

cept the UX regression of having to configure the network again on the first graphical login, when per-user credential stores are available through the appropriate services. Simon [1] there should really be documentation in Policy what dependencies are allowed.

Re: ifupdown maintenance

On Tue, 09 Jul 2024 at 16:21:16 +0200, Ansgar 🙀 wrote: > On Tue, 2024-07-09 at 22:44 +0900, Simon Richter wrote: > > I believe NM does not have a fixed configuration format, but only a dbus > > API. > > It's perfectly fine to edit configuration files for NM manua

Re: ifupdown maintenance

backports of core system packages installed. I fully expect some breaking changes, as we are storing the WiFi credentials into a configuration file, when they should be stored in some secrets manager -- so this is already "legacy", and I'm not sure if it is a "legacy interface" or a "legacy implementation detail." Simon

Re: ifupdown maintenance

ificantly reduce the effort required for this process. Simon OpenPGP_0xEBF67A846AABE354.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature

Re: ifupdown maintenance

more resources we need to keep on hand to catch up. This is not a technical problem, but a project management one. The technical aspects of this are the easy part, although it is also possible to bungle them if they are left to overconfident people. Simon

Re: what about Netplan?

On Sun, 14 Jul 2024 at 17:09:48 +0100, Steve McIntyre wrote: > Luca Boccassi wrote: > >Networking is not static, it constantly changes in the kernel, > >sometimes in dramatic and incompatible ways. > > Sorry, but no. Networking clearly is *not* changing that fast, in > software terms. Many old too

Re: OpenPGP digital signature

On Tue, 30 Jul 2024 at 10:35:18 +0400, Yadd wrote: > On 7/30/24 09:53, imtoas...@mail.com wrote: > > On behalf of the Release Team, > > Paul Please note that imtoas...@mail.com is (presumably) not Paul, the PGP signature does not validate, the subject line is not what the release team would use, a

Re: Produce extra build artifacts during package builds

On Fri, 02 Aug 2024 at 16:40:15 +0900, Mattia Rizzolo wrote: > Lastly I think https://lists.debian.org/debian-devel/2022/02/msg00216.html > to which Simon had a quite nice answer. I also did some more concrete design and wrote a prototype - <https://lists.debian.org/debian-devel/2022/02

Re: Produce extra build artifacts during package builds

On Fri, 02 Aug 2024 at 18:17:52 +0200, Niels Thykier wrote: > Simon McVittie: > > In the design that I prototyped, it's declarative, loosely inspired by > > the equivalent Gitlab-CI feature: > > > > - the maintainer can write patterns into debian/build-artifacts fo

Re: Produce extra build artifacts during package builds

On Sat, 03 Aug 2024 at 15:15:10 +0900, Mattia Rizzolo wrote: > Consider that in my mind, most packages wouldn't have needed to write > any imperative code. > I was considering it for example within dh_auto_configure and > dh_auto_test, etc, those tools would be responsible for copying the > relevan

Re: Produce extra build artifacts during package builds

On Fri, 02 Aug 2024 at 21:03:05 +0200, Niels Thykier wrote: > I think it is more of a question whether [artifacts in /tmp] will be supported > initially (might require a per-source TMPDIR too for buildd support, so > artifacts does not get tainted because the buildd was running two builds at > the

Re: Mandatory LC_ALL=C.UTF-8 during package building

On Sat, 03 Aug 2024 at 19:16:30 +0200, Guillem Jover wrote: > I'm not sure the current state is ideal, because we are back to > packages being able to rely on some stuff on build daemons, that are > not guaranteed by default for our supported build entry points This was already true, though: the o

Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages

, attempts (and then eventually feel that it would be better to "improve" your contributions using other methods). This information should be in debian/README.source. Simon

Re: Machine readable contributor information

e development workflow just so we could reuse some of their shiny tools. Simon

Re: Bug#1077974: ITP: gr-framework -- Universal framework for cross-platform visualization applications

d be fairly involved. Simon

Re: salt removed from mirror

On Fri, 09 Aug 2024 at 13:31:02 +, Johannes Drexl wrote: > I was under the impression that the software stack of a > stable/oldstable release does not change anymore (safe for security > updates and suchlike), so I'm pretty flabberghasted by this. More so as > I cannot find a mention about this

Re: RFC: Sensible-editor sensible-utils alternative and update

On Mon, 12 Aug 2024 at 12:36:37 +0100, Richard Lewis wrote: > Bastien Roucariès writes: > > Sensible-editor could now use EDITOR="emacsclient -n -c" and accept > > that sh -c accept > > > > My goal is to create a sensible-editor.desktop that will lauch by > > default the sensible-editor of choice

Re: RFC: Sensible-editor sensible-utils alternative and update

On Mon, 12 Aug 2024 at 14:23:51 +, Bastien Roucariès wrote: > Yes I want sensible-editor to open kate on kde and gnome-editor on gnome. > > Thinks about running latex and typing e for editing, it should run the > desktop editor of choice. > > I do not want to change desktop user choice This

Re: RFC: Sensible-editor sensible-utils alternative and update

On Mon, 12 Aug 2024 at 08:44:51 -0700, Russ Allbery wrote: > What this is telling me is that ideally someone should tighten the > definition of EDITOR in Policy 11.4, which is the specification satisfied > by sensible-editor, to make it clear that GUI editors with these sorts of > properties are no

Re: Porterbox - impossible efficient debugging?

On Tue, 13 Aug 2024 at 13:01:45 +0200, Stéphane Glondu wrote: > BTW, IIUC, it is be possible with namespaces to give root privileges (or > enough to install packages) to anybody inside a container. [1] could be a > way, but it needs unprivileged user namespaces. See also https://salsa.debian.org/d

Re: Accepting DEP14?

s where we want to be at. Simon

Re: Accepting DEP14?

ose, since the 1)-style uploads are not uncommon for me. I think the core problem is that there really is no reasonable concept of "latest" branch for a Debian package. There are just many different versions targetted at different suites or vendors, each of them having their own meaning of what is latest. /Simon signature.asc Description: PGP signature

Re: Accepting DEP14?

It would also strengthen the integrity of the resulting archive, since then there is some way to look at a *.debian.tar.* and git debian/ sub-directory and understand what the intended source code it applies to are. Manually curating the release artifact checksums is what many other packaging system

Re: Request for IkiWiki NMU (FTBFS #1074727)

On Sat, 17 Aug 2024 at 13:13:51 +0100, Jonathan Dowland wrote: > intrigeri's patch at > > looks good to me (eyeball test only) > > I would be very grateful if someone would be prepared to Debian-ize > it and NMU IkiWiki (due to be remo

Re: Re: Accepting DEP14?

On Sat, 17 Aug 2024 at 22:45:59 +0200, Chris Hofstaedtler wrote: > "latest" is illnamed. What do you expect to find in a branch thats > called debian/latest? > > Packaging for unstable? For experimental? For experimental if there's currently a version in experimental (or if there is about to be o

Re: Removing more packages from unstable

hierarchy violations would be good to have. obs-websocket Websocket support was merged into the main program a while ago. Simon

Representing Debian Metadata in Git

ve to be very generic on this side to not block future development -- and it would require a lot of design effort on the Debian side as well to hammer out the details. Any feelings/objections/missed requirements? Simon

Re: debian/gbp.cnf analytics? (Re: Re: Accepting DEP14?)

On Mon, 19 Aug 2024 at 22:42:53 -0700, Otto Kekäläinen wrote: > ## How many packages have a 'upstream-vcs-tag' and what is it typically? Unlike most of the other questions you asked and answered (thanks!) we should never expect this to be consistent, because it isn't Debian's decision: it's upstre

Re: Removing more packages from unstable

which packages should go on the first installation CDs, but it cannot ever produce an accurate picture of which packages are actually used (and that was communicated clearly back then, but seems to have been lost to the sands of time). Simon

Re: Removing more packages from unstable

ture for determining which CD image a package should go to, because desktop users are most likely to install from CD/USB, and popcon directly impacts the installation experience here, but it is a bad metric for determining how many users are affected by a change. Simon

Re: The end of 32-bit PostgreSQL support in Debian

else being broken. Simon

Status of OpenMAX IL

a bit behind here) Simon

Bug#1079669: ITP: libntruprime -- Streamlined NTRU Prime (sntrup) microlibrary

Package: wnpp Severity: wishlist Owner: Simon Josefsson X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: libntruprime Version : 20240825 Upstream Authort: Daniel J. Bernstein * URL : https://libntruprime.cr.yp.to/ * License : LicenseRef-PD-hp OR CC0

Re: Should OpenSSL/ libssl3 depend on brotli?

On Sat, 07 Sep 2024 at 11:41:34 +0200, Sebastian Andrzej Siewior wrote: > What is the benefit of reducing the pseudo-essential size? I have > libssl installed on all of my systems since it is pulled in at least by > openssh. chroots/containers, mainly. I'm sure you have openssh installed on all y

Re: DEP5 and spdx shortname of license

On Sun, 08 Sep 2024 at 09:49:39 +0200, Niels Thykier wrote: > Is it really that valuable for us to have a delta here compared to what > upstream projects would use? IMO: no. If (some) upstream projects are now taking copyright/license tracking in general (and machine-readable copyright/license spe

Re: Reviving schroot as used by sbuild

On Fri, 13 Sep 2024 at 11:15:55 +0200, Helmut Grohne wrote: > My initial experiments indicate that we're in > for a factor two [slowdown] whereas we could get this down significantly > by using an overlayfs approach that we cannot shoehorn into podman. Er, podman does use overlayfs, in at least so

Re: Several X applications refuse to start

ais je suis nulle...mais )-- --( je suis très tetue alors ça compense :)' )-- Simon ( #parinux ) Nomis Htag.pl 0.0.22

Bug#279494: ITP: apache2-redirtoservname -- Apache module to redirect browsers to the canonical server name

Package: wnpp Severity: wishlist * Package name: apache2-redirtoservname Version : 0.1 Upstream Author : Simon Richter <[EMAIL PROTECTED]> * URL : http://www.hogyros.de/misc * License : GPL + exception to allow linking against Apache Description :

Bug#281786: ITP: xplc -- Light weight component system

Package: wnpp Version: N/A; reported 2004-11-17 Severity: wishlist * Package name: xplc Version : 0.9.10 Upstream Author : Pierre Phaneuf <[EMAIL PROTECTED]> * URL : http://xplc.sourceforge.net * License : LGPL Description : Light weight component system

Re: ldap - a completely new method for fetching lists of packages?

fast. But, your idea is not an unreasonable one. Simon

Re: ldap - a completely new method for fetching lists of packages?

d this is by writing a sumb HTTP proxy which translates information queried from LDAP into Packages.gz, Release.gz, and Sources.gz. Granted, APT would have to parse those files over again. But you wouldn't be grabbing needless data off the network. Simon

Re: Bug#285518: misdn-utils includes a firmware loader

of any firmware that may be loaded with it once the mISDN stack reaches a non-beta state. Simon signature.asc Description: OpenPGP digital signature

Re: Bug#285518: misdn-utils includes a firmware loader

a single utility just to move it into contrib. The case was clearly different IMO if core functionality was affected, but in fact we are discussing about 100 lines of code within an ISDN stack. :-) Simon (who never thought he'd be on the "pragmatic" side) signature.asc Description: OpenPGP digital signature

Re: dselect survey

uld be deinstalled (i.e. until another package depending on it is installed or a decision is made). (I'd also like to be able to search for these packages in order to clean up after my fellow sysadmins) Simon

Re: Bug#285768: dselect survey

tween automatically installed new packages and new packages. In total, we get four new categories. Simon signature.asc Description: OpenPGP digital signature

Buildds automatically dep-waiting on build-depends

ith a solution to this yet. But yes, one day I'll try and have a look if someone more familiar with wanna-build hasn't fixed it by then. Simon. -- Just another wannabie | "Bet ya five dollars I get | Just another fool --+ off" - Pusher to Mulder (3x17

Re: Bits (Nybbles?) from the Vancouver release team meeting

n furthers promotion into testing. Port patches are, at least to a non-insignificant percentage, likely to break other architectures. Why would I do that to my package, perhaps only five days after I uploaded it (= five days before it would enter testing)? Simon signature.asc Description: OpenP

Re: Building windows versions of debian packages

ian packages, submit wishlist bugs. 6. Repeat steps 4 and 5. Simon [1] Incidentally, this is one of the things that are going to happen soonish, as the Amiga needs a new bootloader badly, and it should be possible to build that from source from within Debian. signature.asc Description: OpenPGP digital signature

Re: master's mail backlog and upgrade time

unning an email server accepting broken emails). Forwarding email unconditionally makes my debian.org address receive by far the largest amount of spam of all addresses I have. Please, think about the kittens. Simon signature.asc Description: OpenPGP digital signature

Re: master's mail backlog and upgrade time

ell dialup systems from other systems? There is a database where ISPs can register the ranges they assign for dialup users. Simon signature.asc Description: OpenPGP digital signature

Re: Spliting packages between pkg and pkg-data

foo. If it is providing the functionality "working program foo", then of course, it need to depend on foo. No, it needs to Recommend foo, not Depend on it. Otherwise you end up with a dependency loop. Simon signature.asc Description: OpenPGP digital signature

Re: master's mail backlog and upgrade time

r the addresses are dynamically assigned, not whether the network connection is intermittent (mail servers are supposed to handle that as a temporary error, while talking to the wrong server will lead to a 5xx and the mail bouncing). Simon signature.asc Description: OpenPGP digital signature

Re: Remove

I hope this helps, Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dpkg-sig support wanted?

any signed .deb just because a developer signed it, that would be bad(tm). Simon signature.asc Description: OpenPGP digital signature

Re: dpkg-sig support wanted?

release") and if the idea of adding description/template translations later on catches on, also some from the translators/translation system. Simon signature.asc Description: OpenPGP digital signature

Re: Secret changes for binNMUs

Hi, Henrique de Moraes Holschuh schrieb: > We really need another substvar with different semantics. http://lists.debian.org/debian-devel/2002/09/msg01251.html Simon signature.asc Description: OpenPGP digital signature

Re: Alternate proposal for Declassification of debian-private archives

- the list of posts to be declassified will be made available to developers two weeks before publication, so that the decisions Two weeks is too short to review, IMO. I didn't read that as a hard time limit between announcement and publication, but rather as the minimum wait t

  1   2   3   4   5   6   7   8   9   10   >