[RFC] [PATCH] 32-bit pointers in x86-64

[Luca]

This proof of concept patch modifies GCC to have 32-bit pointers and
longs on x86-64.

This allows to create an "x86-32" architecture that takes advantage of
the higher number of registers and support for 64-bit computation in
x86-64 long mode while avoiding the disadvantage of increased memory
usage due to 64-bit pointers and longs in structures.
Thus, such a GCC version could be used to produce a GNU/Linux
distribution with the performance of x86-64 and the reduced memory
usage of i386. Furthermore, programs requiring "large data" could use
special "64-bit pointer" attributes to only use 64-bit pointers to
reference the relevant large arrays/structures, using 32-bit pointers
for everything else.

The current patch is just an hack and should obviously be made
configurable and reimplemented properly.
Just setting POINTER_SIZE to 32 mostly works but more hacks are
necessary to get PIC compilation working (note that the hacks are
probably at least partially wrong, since I'm not an experienced GCC
hacker).
A patch to binutils is also required to stop it from complaining about
32-bit relocations in shared objects.

Currently a simple "Hello world!" program will work using a standard
x86-64 dynamic loader and libc.
This is because the function call ABI is unchanged and thus anything
that doesn't use structures containing pointers or longs should be
binary compatible.

I do not really intend to work on this personally: I did this initial
work for fun and I'm posting these patches to possibly stimulate
broader interest on this concept.

A possible roadmap for this would be:
1. Make it configurable
2. Fix the LEA hacks and allow proper PIC compilation
3. Fix everything else that may not work properly (e.g. PIC,
relocations, exception handling, TLS, debug info)
4. Add a "32-bit object" flag to x86-64 objects
5. Modify libc so that allocations are made in the lower 4GB space for
x86-32 shared objects and modify x86-64 assembly code to work with
32-bit pointers
6. Compile a native x86-32 libc and compile and test a full Debian or
Ubuntu distribution
7. Add support for loading x86-32 and x86-64 objects in the same
address space, using a single modified 64-bit libc (that for
compatibility actually generate pointers in the low 4GB)
7.1. Add __attribute__((pointer_size(XXX))) and #pragma pointer_size
to allow 64-bit pointers in 32-bit mode and viceversa
7.2. Surround glibc headers with #pragma pointer_size 64
7.3. Modify the dynamic loader to support different namespaces and
directories for x86-32 and x86-64. Symbols starting with "__64_" or
"__32_" or similar could be mapped to the other namespace. Also
support "multiarchitecture" objects that would be added to both.
7.4. Split malloc/mmap in __32_malloc, __32_mmap and similar in glibc.
glibc itself would use 32-bit allocations and be loaded in the low
4GB.
7.5. Compile the result and use a modified libc/dynamic loader
compiled in x86-64 mode flagged as multiarchitecture to load both
x86-32 and x86-64 objects
8. Modify popular programs to explicitly use 64-bit allocations and
pointers for potentially huge allocations (e.g. database caches,
compression program data structures, P2P software file mappings)

Patches are against GCC 4.2.2 and Binutils HEAD.
Index: bfd/elf64-x86-64.c
===
RCS file: /cvs/src/src/bfd/elf64-x86-64.c,v
retrieving revision 1.144
diff -u -r1.144 elf64-x86-64.c
--- bfd/elf64-x86-64.c	18 Oct 2007 09:13:51 -	1.144
+++ bfd/elf64-x86-64.c	25 Nov 2007 14:19:17 -
@@ -1038,6 +1038,8 @@
 	case R_X86_64_TPOFF32:
 	  if (info->shared)
 	{
+	if(0)
+	{
 	  (*_bfd_error_handler)
 		(_("%B: relocation %s against `%s' can not be used when making a shared object; recompile with -fPIC"),
 		 abfd,
@@ -1045,6 +1047,7 @@
 		 (h) ? h->root.root.string : "a local symbol");
 	  bfd_set_error (bfd_error_bad_value);
 	  return FALSE;
+	  }
 	}
 	  break;
 
@@ -1198,6 +1201,8 @@
 	  && (sec->flags & SEC_ALLOC) != 0
 	  && (sec->flags & SEC_READONLY) != 0)
 	{
+	if(0)
+	{
 	  (*_bfd_error_handler)
 		(_("%B: relocation %s against `%s' can not be used when making a shared object; recompile with -fPIC"),
 		 abfd,
@@ -1205,6 +1210,7 @@
 		 (h) ? h->root.root.string : "a local symbol");
 	  bfd_set_error (bfd_error_bad_value);
 	  return FALSE;
+	  }
 	}
 	  /* Fall through.  */
 
@@ -2599,6 +2605,8 @@
 		  || !is_32bit_relative_branch (contents,
 		rel->r_offset)))
 	{
+	if(0)
+	{
 	  if (h->def_regular
 		  && r_type == R_X86_64_PC32
 		  && h->type == STT_FUNC
@@ -2613,6 +2621,7 @@
 		   h->root.root.string);
 	  bfd_set_error (bfd_error_bad_value);
 	  return FALSE;
+	  }
 	}
 	  /* Fall through.  */
 
diff -ur g_orig/gcc-4.2.2/gcc/config/i386/i386.c gcc-4.2.2/gcc/config/i386/i386.c
--- g_orig/gcc-4.2.2/gcc/config/i386/i386.c	2007-09-01 17:28:30.0 +0200
+++ gcc-4.2.2/gcc/config/i386/i386.c	

Bug#816604: ITP: tycho -- Tool for building Eclipse plug-ins with Maven

[luca]

Package: wnpp
Severity: wishlist
Owner: luca 

* Package name: tycho
  Version : 0.24.0
  Upstream Author : Eclipse Foundation 
* URL : http://www.eclipse.org/tycho/
* License : Eclipse Public License
  Programming Lang: Java
  Description : Tool for building Eclipse plug-ins with Maven

Tycho is focused on a Maven-centric, manifest-first approach to building
Eclipse plug-ins, features, update sites, RCP applications and OSGi bundles.
Tycho is a set of Maven plugins and extensions for building Eclipse plugins and
OSGi bundles with Maven.

This package is a dependency for Eclipse.

I hope to maintain this package jointly with the Java Team.

Bug#826643: ITP: tn5250j -- A 5250 terminal emulator for the AS/400

[luca]

Package: wnpp
Severity: wishlist
Owner: luca 

* Package name: tn5250j
  Version : 0.7.6
* URL : https://tn5250j.github.io/
* License : GPL
  Programming Lang: Java
  Description : A 5250 terminal emulator for the AS/400

The tn5250j is a 5250 terminal emulator for the AS/400 written in Java.

This is currently the only one terminal emulator for Linux with features like
continued edit fields, gui windows, cursor progression fields etc

Re: DEP17 /usr-move: debootstrap set uploaded

[Luca Boccassi]

On Thu, 6 Jun 2024 at 10:02, Johannes Schauer Marin Rodrigues
 wrote:
>
> Hi Helmut,
>
> Quoting Helmut Grohne (2024-06-06 09:28:52)
> > I have just uploaded
> >  * base-files
> >  * bash
> >  * dash
> >  * glibc
> >  * util-linux
> > to unstable. These were the last remaining packages shipping aliased
> > files inside the package set relevant to debootstrap.
>
> thank you (and freexian for funding you) so much for finally reaching this
> milestone!! Thank you also for doing all your work with incredible diligence
> and attention to detail. This is really outstanding and what I consider to be 
> a
> model for how changes in Debian should be performed.
>
> Your upload timing seems to have been great: the buildds seem to already have
> gone through most of what you uploaded.
>
> I cannot wait for the next dinstall in ~5 hours to test what you uploaded with
> the mmdebstrap test suite (which is also testing debootstrap).
>
> Too bad that it is just these days that snapshot.d.o is moving to the new
> infrastructure (a big thanks to the team who is working on that) which means
> that this crucial transition in unstable will not be part of
> snapshot.debian.org. There are no timestamps recorded for June yet.

+1 thank you Helmut, excellent work!

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

[Luca Boccassi]

On Thu, 6 Jun 2024 at 09:07, Gioele Barabucci  wrote:
>
> Hi,
>
> setting LC_ALL=C.UTF-8 in d/rules is a common way to fix many
> reproducibility problems. It is also, in general, a more sane way to
> build packages, in comparison to using whatever locale settings happen
> to be set during a build. However, sprinkling a variant of `export
> LC_ALL=C.UTF-8` in every d/rules is error-prone and a waste of
> maintainers' time.
>
> Would it be possible to set in stone that packages are supposed to
> always be built in an environment where LC_ALL=C.UTF-8, or, in other
> words, that builders must set LC_ALL=C.UTF-8?
>
> In which document should this rule be stated? Policy?

This makes sense to me, seems similar enough to SOURCE_DATE_EPOCH

File descriptor hard limit is now bumped to the kernel max

[Luca Boccassi]

Hi,

PSA: as of systemd/256~rc3-3 the open file descriptors hard limit is
bumped early at boot from 1048576 to the max value that the kernel
allows, which on amd64 is currently 1073741816.

(I meant to send this last week but it fell off the wagon and
languished in the draft folder, sorry!)

This allows modern applications to use as many file descriptors as they
want, since they are an extremely cheap resource nowadays, and it's
more important than ever given that, for example, process tracking is
switching over to PID FDs for security reasons. Please note that the
soft limit still is 1024, as that's what legacy syscalls like select()
can handle.

The last time this was tried some packages were still not ready, so it
was patched out to let them be fixed. Enough time has passed now, and
it's time to let any unknown leftover just break and be fixed. In all
known cases, the buggy pattern was to manually iterate over the hard
limit and close every FD one by one, which is completely unnecessary
since kernel 5.9 (bullseye/oldstable) since the close_range() syscall
is available, that can do it in one fell swoop. Any packages still
doing the iteration manually need to switch to close_range, which is
very simple to use and documented at:

https://man7.org/linux/man-pages/man2/close_range.2.html

Please enjoy your extra file descriptors responsibly.

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Re: Re: About i386 support

[Luca Boccassi]

> I've tried reproducing the daemon-reload bug report, unless I missed
> something
> obvious, daemon-reload works on my T2300, the TM Efficeon, and the
> pre-SSE2
> Pentium 3 (mobile) that I have. I could try running it on an original
> Pentium, but I doubt that debian will run on it at all, even when
> ignoring the fact that the thing also only has 96M of ram, which is
> to small to load a ramdisk and debian only targets i686. So the bug
> might only apply to a very specific processor, unless there is a
> patch
> in the debian package.

There are no relevant patches in the Debian package. This is exactly
the problem with supporting old and obsolete architectures, that are
very difficult to find in the wild: things break in weird and
incomprehensible ways, and nobody is able to fix them. This is one of
the main jobs of porters: if you can't triage and fix this issue, then
it's likely you won't be able to triage and fix other architecture-
specific issues either, as this is very very likely a hidden compiler
toolchain issue. The effort required to have a release architecture
officially supported in Debian goes way beyond "I have an old machine
under the desk and can build some trivial packages", I am afraid.

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Re: Re: About i386 support

[Luca Boccassi]

On Fri, 14 Jun 2024 at 11:54,  wrote:
>
> Then it's not a problem in the first place. If you can't reproduce a bug with 
> a reasonable effort, then it is unconfirmed and you can stop worrying about 
> it. A bug that can't be reproduced, effectively doesn't exist.
>
> That's not a reason to stop supporting an entire architecture. That's a 
> troubleshooting decision that you would make on any architecture.

Of course it is a reason to drop an architecture. Not the mere
existence of an individual bug of course, but the fact that there is
nobody who is able or willing to successfully triage and debug and fix
such toolchain issues. As per RT's requirements, a release
architecture requires multiple porters as one of the basic
requirements to be considered, and the fact that nobody can fix issues
like these means there are effectively 0 porters. Once again,
maintaining a release architecture does not just mean having a machine
under your desk and building trivial packages, it means maintaining a
functioning toolchain, which involves triaging and fixing complex
bugs.

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

[Luca Boccassi]

On Fri, 14 Jun 2024 at 13:21, Mourad De Clerck  wrote:
>
> > PSA: as of systemd/256~rc3-3 the open file descriptors hard limit is
> > bumped early at boot from 1048576 to the max value that the kernel
> > allows, which on amd64 is currently 1073741816.
>
> Hi,
>
> It seems some proprietary software (the JetBrains IDEs) has some
> problems with this change.
>
> See for instance: https://youtrack.jetbrains.com/issue/IJPL-156522
>
> While I wait for them to fix this on their end, what's the best way to
> revert this to the original behaviour on my machine?
>
> I would think:
>
> echo "fs.nr_open = 1048576" > /etc/sysctl.d/99-max-fds.conf
>
> … would do the trick, but "ulimit -Hn" reports 524288.
>
> Something to do with DefaultLimitNOFILE=1024:524288 maybe? But
> overriding that didn't work.

For user instances the link you shared has a workaround, it has to do
with PAM limits, that should work.
Please keep the pressure on the upstream project to fix that bug as
well. Thanks.

Re: ifupdown maintenance

[Luca Boccassi]

On Tue, 9 Jul 2024 at 14:44, Simon Richter  wrote:
>
> Hi,
>
> On 7/9/24 17:57, 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?
>
> Both are overly complex for a static-IP-only server installation, where
> there is no requirement for an unprivileged user to modify the network
> configuration, or any background process at all, really. At least in
> expert mode I would expect a way to generate a static,
> unmanaged-by-anything configuration.

As per smcv's point, if you need to manually write a static
configuration then you can also install your favourite tool to use it.
This is not the default case - the default case is "I have ethernet
and/or wifi and I want DHCP v4+v6 on anything that can talk to a
router kkthxbye"

> What would be needed for new installations is d-i support, mainly, and
> the difficulty there is saving the configuration.
>
> I believe NM does not have a fixed configuration format, but only a dbus
> API. Our best bet there would be a firstboot unit, but I have no idea
> whether accessing NM from a unit attached to firstboot is safe or leads
> to a dependency loop[1].
>
> I'm not sure if systemd-networkd is much happier long-term if we write
> its configuration from a shell script, we'd need to get some commitment
> from upstream that this is an interface, not an implementation detail,
> at least.

I'm not sure what this means, you can write networkd configuration
files from wherever you like, the tool doesn't care, it wouldn't even
be able to tell the difference anyway, just drop them in the
appropriate location in /etc/ and off you go.

Re: ifupdown maintenance

[Luca Boccassi]

On Tue, 9 Jul 2024 at 18:02, Simon McVittie  wrote:
>
> 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 manually, see
> > man:nm-settings-keyfile(5).
>
> ... and debian-installer already knows how to write out these files,
> and has done so for more than a decade if I'm reading correctly. This is
> not a recent innovation, and anyone who has installed our default desktop
> environment in the last few years - especially if they used wifi during
> installation - has been relying on this code path.
>
>  is responsible
> for converting the network configuration that was used temporarily in
> the d-i environment into a NM configuration file if NM is installed,
> or an ifupdown configuration otherwise. Writing the equivalents into
> /etc/systemd/network for systemd-networkd would presumably not be rocket
> science, it's a simple .ini-like syntax similar to the one NM uses.

It is indeed quite simple:

https://salsa.debian.org/installer-team/netcfg/-/merge_requests/11

And I think you are perfectly right: for the simple, default use case,
we want something that is not downstream-only and dependent on a
single overworked maintainer, and that is modern enough to know that
Netlink exists and cannot be ignored. It's not 1998 anymore, even the
simplest systems need to take it into account, and there are
distro-agnostic solutions that everyone can rely on with minimal
integration efforts.

I think it's fine to add support for netplan, in fact it should be
merged first in the installer and my MR builds on top of it, and there
are many cases where it is a good idea to use it, but it should not be
the default, for the same reason as above - only Ubuntu really uses
it, and it does happen that Canonical's priorities shift.

The default logic in the above MR, absent specific choices, is: if
netplan is installed it will be used (needs to be preseeded or
installed manually, so it works for the cloud case), if
network-manager is installed it will be used (perfect for the
desktop/GUI case), if the interface is wired and it's on Linux and
systemd is init networkd will be used (perfect for minimal
installations/servers), else it goes back to the current ifupdown.

The main obvious advantage of networkd is that it is already installed
and will always be already installed in the default case, it's just
disabled, so the extra cost is one ini file and a couple of symlinks,
so the footprint of the minimal working install goes down. When
ifupdown loses prio: important then the footprint will actually
decrease.

Those who want complex cases can manually pick netplan. Those who want
to relive the thrills of the late 90s can pick ifupdown and write all
the crappy scripts they like, and spend their own time wondering why
eth0 became eth1 or viceversa and everything stopped working. The
default is the smallest and most sensible option. Everybody wins.

Re: what about Netplan?

[Luca Boccassi]

On Thu, 11 Jul 2024 at 12:12, Lukas Märdian  wrote:
>
> On 11.07.24 11:13, Marco d'Itri wrote:
> > On Jul 11, Philip Hands  wrote:
> >
> >> I've only seen netplan mentioned in passing in this thread so far.
> > Because I believe that Netplan is the answer to a question that nobody
> > asked here.
> >
> > It has all the disadvantages of switching to a new configuration format,
> > but then it limits you to the features that it actually implements from
> > each backend and you have an indirection layer that must be used when
> > interacting with the backend daemon.
>
> Yes, it brings a new configuration format. So do systemd-networkd and 
> NetworkManager.
>
> Netplan's feature set is pretty comprehensive and certainly enough for a 
> default installation,
> see its reference: https://netplan.readthedocs.io/en/stable/netplan-yaml/
>
> But it's not an indirection layer that MUST be used. Should the features of 
> Netplan not be enough
> for an advanced usecase, everybody is free to write configuration for the 
> underlying backend directly.
>
> Netplan will not interfere with that and go out of the way. Just don't write 
> Netplan configuration
> for a specific interface (or all of them) that you want to handle differently.

I appreciate the work you've done on Netplan and I am quite sure your
D-I MR should be merged, it looks ready to me. It's good to have this
support in the installer.

However, I do not think it should be the default. First of all, only
Ubuntu uses it, nobody else - as Simon says, we don't want the
defaults to be super-special things that nobody else uses. And then
again, not your fault in the slightest, but Canonical is known for
shifting its priorities every now and then - perfectly normal for a
for-profit company, but a bit worrying when one wants to pull all eggs
in that basket. And also for the minimal case, an additional layer of
indirection and set of dependencies, when there's an alternative that
requires none of that, is not the ideal solution.

So I am quite sure that yes netplan should be supported in the
installer and your MR should be merged, but the new default for the
default, simple, wired case should be networkd, and for the
GUi/desktop case the default should continue to be NetworkManager.

Re: what about Netplan?

[Luca Boccassi]

On Sun, 14 Jul 2024 at 11:41, Andrey Rakhmatullin  wrote:
>
> On Sat, Jul 13, 2024 at 09:44:03PM +0200, Lukas Märdian wrote:
> > > However, I do not think it should be the default. First of all, only
> > > Ubuntu uses it, nobody else - as Simon says, we don't want the
> > > defaults to be super-special things that nobody else uses. And then
> >
> > Actually, I think this is an agrument FOR Netplan, not against it. Netplan 
> > is being used
> > by millions of users for 7+ years. Plenty of usecases have been tried and 
> > documented. It's
> > clearly not a "super-special thing that nodbody uses".
> >
> > Whereas I'm not aware of a major Linux distro using systemd-networkd 
> > directly, Debian would be
> > singeling out itself. I see some of networkd's strengths with advanced 
> > users who want to dig deep
> > and have full control at minimal resource usage (e.g. Arch Linux). Also 
> > with lightweight container
> > usecases, where network config only needs minimal manipulation after 
> > deployment (if at all).

It largely depends on the configuration and flavours, in some cases
networkd is used for headless installs, in some other cases
network-manager is used, like in Fedora. Up until some time ago SUSE
used to use wicked, but they also switched to network-manager by
default somewhat recently, and wicked is deprecated. But nobody apart
from Ubuntu uses anything but network-manager on GUI installations at
this point. Debian is actually following the rest of the ecosystem on
this for once, and that is a good thing. I am quite convinced we
should stop being outliers, there are way more interesting things to
do with our limited time. It's fine to have other less popular options
available, even in the installer, but the default is something
different.

> > The RedHat ecosystem is all-in on NetworkManager. Debian and Ubuntu have 
> > (natually) been very close
> > to each other (e.g. package management) and together with its derivatives 
> > create the Debian ecosystem.
>
> Then it looks like a chance for netplan to go the way of upstart?

Or MIR or Unity or...

It's perfectly normal and expected for companies to follow their own
strategy and do what's best to pursue it. When things are aligned with
the rest of the ecosystem, it's not a problem. But when it goes in
opposite directions, then it's quite a different story. Recently there
was also the LXD case, where after many years a CLA and a license
change were introduced last year by Canonical, creating de-facto a
split, with the community choosing to fork to Incus - I do not know
the background details, as I am not involved in the slightest, and I'm
sure there must have been some reason for those decisions, but from an
outsider's perspective I'm afraid the optics were not quite good. What
guarantees do we have that what happened to LXD won't happen to
netplan.io at some point in the future?

Networking is not static, it constantly changes in the kernel,
sometimes in dramatic and incompatible ways. A widely used, well
maintained stack with large amounts of contributors is fundamental for
the default choice, because we have to keep up, as the rest of the
world will not sit and wait for us.

Here's some stats from 'git shortlog --after="2021-12-31" -sn --all'.
In the last ~2.5 years, in netplan.io's github repo, there are only 2
contributors with more than 100 commits, and 2 with more than 10, and
2 of them are Canonical employees:

   569  Lukas Märdian
   310  Danilo Egea Gondolfo
39  Simon Chopin
38  Danilo Egêa Gondolfo
11  Robert Krátký

Same stat, for the same period, for systemd:

  6650  Yu Watanabe
  5415  Lennart Poettering
  2884  Luca Boccassi
  2772  Zbigniew Jędrzejewski-Szmek
  2437  Daan De Meyer
  1793  Frantisek Sumsal
  1364  Mike Yuan
   483  Jan Janssen
   400  David Tardon
   245  Franck Bui
   215  dependabot[bot]
   211  Antonio Alvarez Feijoo
   165  Ronan Pigott
   152  Dan Streetman
   146  Ludwig Nussel
   126  hulkoba
   119  Nick Rosbrook
   114  Dmitry V. Levin
   107  Sam Leonard
   102  Evgeny Vereshchagin
78  msizanoen
74  Richard Maw
73  Adrian Vovk
72  Maanya Goenka
63  Michal Sekletár
60  Cristian Rodríguez
49  Michal Koutný
40  Jan Macku
40  Krzesimir Nowak
37  Mariano Giménez
37  Michael Biebl
37  Topi Miettinen
36  наб
35  Susant Sahani
33  Peter Morrow
32  Benjamin Franzke
32  Christian Brauner
32  Richard Phibel
31  Christian Göttsche
29  Anita Zhang
29  Khem Raj
26  James Hilliard
25  Abderrahim Kitouni
23  Arthur Zamarin
23  Florian Schmaus
22  Bastien Nocera
22  Daniel P. Berrangé
22  James Coglan
20  Arseny Maslennikov
20  G

Re: what about Netplan?

[Luca Boccassi]

On Sun, 14 Jul 2024 at 21:26, Philip Hands  wrote:
>
> Luca Boccassi  writes:
>
> > Here's some stats from 'git shortlog --after="2021-12-31" -sn --all'.
> > In the last ~2.5 years, in netplan.io's github repo, there are only 2
> > contributors with more than 100 commits, and 2 with more than 10, and
> > 2 of them are Canonical employees:
> >
> >569  Lukas Märdian
> >310  Danilo Egea Gondolfo
> > 39  Simon Chopin
> > 38  Danilo Egêa Gondolfo
> > 11  Robert Krátký
> >
> > Same stat, for the same period, for systemd:
>
> If you're going to make such a comparison, wouldn't it make sense to
> limit it to the bits that might have some sort of relation to networkd?
>
> I suspect this is a bit nearer to a fair comparison:
>
>   git shortlog --after="2021-12-31" -sn --all src/network/ network/
>771  Yu Watanabe
>107  Luca Boccassi
> 86  Zbigniew Jędrzejewski-Szmek
> 42  Lennart Poettering
> 32  Mike Yuan
> 24  Susant Sahani
> 18  Frantisek Sumsal
> 16  Daan De Meyer
> 13  Ronan Pigott
> 10  Jan Janssen
> 10  Michael Biebl
>
> which looks like its in the same ballpark, and presumably still includes
> quite a lot of stuff that would fall outside netplan's scope, so one
> could perhaps argue should be whittled down further.

Not at all: the way we structure systemd's repository, most of the
code that ends up in the network (or any other) binary are actually in
the shared areas. So if you really wanted to catch only the code that
ends up in the specific binaries:

$ git shortlog --after="2021-12-31" -sn --all src/network/ network/
src/libsystemd/ src/basic/ src/shared/ src/fundamental/

  2858  Yu Watanabe
  2195  Lennart Poettering
   882  Zbigniew Jędrzejewski-Szmek
   772  Luca Boccassi
   724  Daan De Meyer
   409  Mike Yuan
   196  Frantisek Sumsal
   128  Dan Streetman
87  David Tardon
76  Jan Janssen
64  Franck Bui
36  Nick Rosbrook
34  Cristian Rodríguez
31  Dmitry V. Levin
30  Adrian Vovk
25  Antonio Alvarez Feijoo
24  Susant Sahani
21  Topi Miettinen
20  msizanoen
19  Arseny Maslennikov
19  Ronan Pigott
17  Khem Raj
16  Ludwig Nussel
15  Maanya Goenka
13  Heinrich Schuchardt
12  Curtis Klein
12  Sam Leonard
11  Alberto Planas
11  David Rheinsberg
11  Florian Schmaus
11  rhellstrom
11  наб
10  Rafaël Kooi
10  jcg

and even that is not an accurate or good metric: the actual sources
that end up in a binary are not the only thing that matters in a
project. Documentation, manpages, unit tests, integration tests, CI,
build system, release tools, dev tools and more are just as important
to the health of a project, and are just as necessary (if not more) to
maintain it, and need active contributors. So the project-wide metric
is really the best metric to use for these kind of comparisons, for
these reasons, and for what Simon said too, of course.

Re: what about Netplan?

[Luca Boccassi]

On Sun, 14 Jul 2024 at 19:21, Simon McVittie  wrote:
>
> 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 tools still continue to work just fine after
> > a decade or more.
>
> Yes, I think I agree with Luca's conclusion, but not so much with this
> argument: the parts of networking that are relevant for a default choice
> that lets users get started (approximately the subset supported by d-i)
> don't move that fast.

Eh, ish. The kind of bugs and weirdness that regularly come through
because of what changes in the kernel paint a different picture to me,
even for the really basic stuff. Just to take two of the most recent
ones:

https://github.com/systemd/systemd/issues/33104
https://github.com/systemd/systemd/issues/29701

"laptop with ethernet port attached to a dock with another ethernet
port" and "ipv6 enabled with privacy extension" do not look like
abstruse corner cases to me, they look pretty basic. And yet...

This is not an argument against netplan of course, given it's a
configuration layer on top of networkd/network-manager. It is an
argument against ifupdown though.

And then once you start adding more complex things like bonding this
just goes out of the window. Yes the installer doesn't allow
configuring bonding (thank ), but the default choice goes beyond
what the installer allows to configure in the installation phase.

Re: what about Netplan?

[Luca Boccassi]

On Sun, 14 Jul 2024 at 19:21, Simon McVittie  wrote:
> Dependency size and maintenance
> ---
>
> I also notice that the netplan.io package would bring GLib, Python,
> python3-dbus and python3-yaml into the dependencies of the base system,
> among others. As an upstream and downstream maintainer of GLib, and in
> practice the only upstream and downstream unmaintainer[1] of python3-dbus,
> I'm not comfortable with that, both for size reasons (GLib and Python
> are not small) and for quality and maintainedness reasons (python3-dbus).
>
> GLib and Python are relatively large in both on-disk size and attack
> surface, but they're essential to our desktop installations anyway,
> reinventing them in parallel would be worse than reusing them, and
> their maintainers have already accepted the responsibility of them
> being an important system component. So those two are actually not my
> main concern here, and if we had no good alternative, I'd be saying:
> yes they're relatively bulky for a container/embedded use-case, but on
> a typical server installation they're fine.

Let's put some hard numbers on the table given this is an important
detail. The following is all starting from a default debootstrapped
unstable.

With networkd only we can drop ifupdown, net changes:

REMOVING:
  ifupdown

Summary:
  Upgrading: 0, Installing: 0, Removing: 1, Not Upgrading: 0
  Freed space: 207 kB


Using network-manager in headless mode (no GUI) brings in:

Installing:
  network-manager

Installing dependencies:
  ca-certificates  libgudev-1.0-0libnl-genl-3-200
 libssh2-1t64
  dbus libicu72  libnl-route-3-200
 libteamdctl0
  dbus-bin libjim0.82t64 libnm0
 libusb-1.0-0
  dbus-daemon  libldap-2.5-0 libpam-systemd
 libxml2
  dbus-session-bus-common  libldap-commonlibpcap0.8t64
 modemmanager
  dbus-system-bus-common   libmbim-glib4 libpcsclite1
 openssl
  dbus-user-sessionlibmbim-proxy
libpolkit-agent-1-0polkitd
  dns-root-datalibmbim-utils libpolkit-gobject-1-0  ppp
  dnsmasq-base libmm-glib0   libpsl5t64
 publicsuffix
  libbluetooth3libndp0   libqmi-glib5
 sgml-base
  libbrotli1   libnetfilter-conntrack3   libqmi-proxy
 shared-mime-info
  libcurl3t64-gnutls   libnfnetlink0 libqmi-utils
 usb-modeswitch
  libdbus-1-3  libnghttp2-14 libqrtr-glib0
 usb-modeswitch-data
  libduktape207libnghttp3-9  librtmp1
 wireless-regdb
  libexpat1libngtcp2-16  libsasl2-2
 wpasupplicant
  libglib2.0-0t64  libngtcp2-crypto-gnutls8  libsasl2-modules
 xdg-user-dirs
  libglib2.0-data  libnl-3-200
libsasl2-modules-dbxml-core

Suggested packages:
  low-memory-monitor  libsasl2-modules-gssapi-mit
libsasl2-modules-sql  comgt debhelper
  libcryptsetup12 | libsasl2-modules-gssapi-heimdal  libteam-utils
wvdial
  libtss2-rc0t64  libsasl2-modules-ldap  iptables
wpagui
  pcscd   libsasl2-modules-otp   sgml-base-doc
libengine-pkcs11-openssl

Summary:
  Upgrading: 0, Installing: 69, Removing: 0, Not Upgrading: 0
  Download size: 28.2 MB
  Space needed: 110 MB / 8295 MB available


Installing netplan.io instead brings in:

Installing:
  netplan.io

Installing dependencies:
  ca-certificates  libexpat1  libsqlite3-0
 python3-gi python3-yaml
  dbus libgirepository-1.0-1  libxml2
 python3-markdown-itpython3.12
  dbus-bin libglib2.0-0t64libyaml-0-2
 python3-mdurl  python3.12-minimal
  dbus-daemon  libglib2.0-datamedia-types
 python3-minimalshared-mime-info
  dbus-session-bus-common  libicu72   netplan-generator
 python3-netifaces  xdg-user-dirs
  dbus-system-bus-common   libnetplan1openssl
 python3-netplan
  gir1.2-girepository-2.0  libpython3-stdlib  python3
 python3-pkg-resources
  gir1.2-glib-2.0  libpython3.12-minimal  python3-cffi-backend
 python3-pygments
  libdbus-1-3  libpython3.12-stdlib   python3-dbus
 python3-rich

Suggested packages:
  default-dbus-session-bus  | wpasupplicant python3-tk
python-pygments-doc  binutils
  | dbus-session-busopenvswitch-switch  python3-venv
ttf-bitstream-vera   binfmt-support
  low-memory-monitoriw  python-dbus-doc
python3.12-venv
  network-manager   python3-doc python3-setuptools
python3.12-doc

Summary:
  Upgrading: 0, Installing: 42, Removing: 0, Not Upgrading: 0
  Download size: 25.2 MB
  Space needed: 101 MB / 8340 MB available


So we have a net gain of ~200K when using networkd, a net loss of
~110M whe

Re: what about Netplan?

[Luca Boccassi]

On Mon, 15 Jul 2024 at 14:36, Lukas Märdian  wrote:
> = "How to do networking on Debian?" =
>
> If we have to tell our users and sysadmins to do "X" on Debian server systems
> (using ifupdown or potentially sd-networkd), while doing "Y" on Debian desktop
> systems (using NetworkManager), while doing "Z" on Debian cloud systems (using
> Netplan), while doing something totally different on RaspberryPi (or alike) 
> boards
> that run a Debian server setup, but using WiFi as their primary network 
> interface,
> that's just a really bad user experience.
>
> Using Debian should NOT feel like using different distros. And we really need 
> a
> common way to do network configuration. With Netplan we can tell people to 
> just use
> use the "dhcp4: true" setting (for example), which will work on all Debian 
> systems
> and is automatically translated to the corresponding backend for
> server/desktop/cloud/embedded usecases.
>
> All while giving sysadmins the flexibilty to fully utilize the underlying 
> network
> daemon directly, if they feel like writing native configuration for it (or 
> don't
> like Netplan).

Assuming that's really needed, and it's far from clear that different
use cases should really use the exact same things, using
network-manager everywhere would achieve the exact same result,
without pulling in additional dependencies, and without being tied to
the internal decisions made in Canonical that we cannot do anything to
influence. Again, not your fault, but existing examples don't exactly
inspire a lot of confidence in that regard: mir, upstart, unity,
lxd...

Re: what about Netplan?

[Luca Boccassi]

On Tue, 16 Jul 2024 at 00:26, Steve Langasek  wrote:
>
> On Mon, Jul 15, 2024 at 03:47:16PM +0100, Luca Boccassi wrote:
> > Assuming that's really needed, and it's far from clear that different
> > use cases should really use the exact same things, using
> > network-manager everywhere would achieve the exact same result,
> > without pulling in additional dependencies, and without being tied to
> > the internal decisions made in Canonical that we cannot do anything to
> > influence. Again, not your fault, but existing examples don't exactly
> > inspire a lot of confidence in that regard: mir, upstart, unity,
> > lxd...
>
> You could compile a similar list of software projects that were abandoned
> when Red Hat stopped funding them.  Or of entirely community-backed free
> software projects that are moribund.  I think it's prejudicial to argue that
> a piece of free software should not be adopted because its development is
> funded by a company which, over the course of 20 years, has made strategic
> decisions to discontinue investments in other, unrelated projects.

Yes, you could compile those lists, and those items would be
problematic too. That's the point made in
https://lists.debian.org/debian-devel/2024/07/msg00137.html and I
think it's spot-on.

> Either netplan is technically sound, providing a sensible configuration
> language that meets the needs of Debian users and has a high-quality code
> base, in which case it should not actually be a problem for Debian to
> maintain it in the event that Canonical discontinues work on it; or it
> isn't, and we can stop the discussion there.

Again, yes, in that case it would most definitely be a problem, as
explained in https://lists.debian.org/debian-devel/2024/07/msg00137.html
being saddled with having to maintain a discontinued product would
absolutely be an issue, which is enough to make it a less prefereable
solution, independently of whatever specific technical merits it might
or might not have. In the end all these projects largely just work, in
the sense of allowing to successfully achieve the goal of configuring
network interfaces, so in this case other individual metrics are less
important than other factors such as, how many other distributions are
using it and how resilient is maintenance against shift in priorities
of a single entity, which translates to, how many active maintainers
and from which backgrounds are working on the project.

Re: what about Netplan?

[Luca Boccassi]

On Tue, 16 Jul 2024 at 14:05, gregor herrmann  wrote:
>
> On Tue, 16 Jul 2024 13:13:16 +0200, Philip Hands wrote:
>
> > I suspect having something that's agnostic about the underlying
> > implementation as our default would be rather better for the non-systemd
> > options that people care about, …
> > Also, networkd doesn't support non-Linux and non-systemd systems AFAIK,
>
> AFAICS, the netplan packages (netplan.io, netplan-generator) currently
> have a hard dependency on systemd.

And that is fine - it's entirely appropriate for any optional or
default to do so. One wishing to "experiment with other systems" can
simply build an image that only contains ifupdown, and that will work
as expected, regardless of what the default is. Such a workflow is
needed for ports like Hurd, for example.

Re: Size measuring contest (Was: what about Netplan?)

[Luca Boccassi]

On Tue, 16 Jul 2024 at 14:46, Daniel Gröber  wrote:
>
> Hi Luca,
>
> On Mon, Jul 15, 2024 at 02:50:17PM +0100, Luca Boccassi wrote:
> > Let's put some hard numbers on the table given this is an important
> > detail. The following is all starting from a default debootstrapped
> > unstable.
> >
> > With networkd only we can drop ifupdown, net changes:
> >
> > REMOVING:
> >   ifupdown
> >
> > Summary:
> >   Upgrading: 0, Installing: 0, Removing: 1, Not Upgrading: 0
> >   Freed space: 207 kB
> >
> >
> > Using network-manager in headless mode (no GUI) brings in:
> > [...]
> >
> > Summary:
> >   Upgrading: 0, Installing: 69, Removing: 0, Not Upgrading: 0
> >   Download size: 28.2 MB
> >   Space needed: 110 MB / 8295 MB available
> >
> >
> > Installing netplan.io instead brings in:
> > [...]
> >
> > Summary:
> >   Upgrading: 0, Installing: 42, Removing: 0, Not Upgrading: 0
> >   Download size: 25.2 MB
> >   Space needed: 101 MB / 8340 MB available
> >
> >
> > So we have a net gain of ~200K when using networkd, a net loss of
> > ~110M when using network-manager, and a net loss of ~101M when using
> > netplan.
>
> For completeness let me turn that arguemnt around on you as systemd
> maintainer. Why is systemd-networkd, a component currently disabled by
> default mind you bloating our base system? :)

Because it is used commonly enough in servers/containers, and doesn't
bring in any additional dependencies

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

[Luca Boccassi]

On Thu, 1 Aug 2024 at 10:36, Johannes Schauer Marin Rodrigues
 wrote:
>
> Hi Otto,
>
> Quoting Otto Kekäläinen (2024-07-28 00:38:40)
> > I have drafted a new DEP at
> > https://salsa.debian.org/dep-team/deps/-/merge_requests/8 titled "DEP-18:
> > Enable true open collaboration on all Debian packages".
> >
> > Direct link to raw text:
> > https://salsa.debian.org/dep-team/deps/-/raw/798bfa5a1e1609afd4e48ee20aff80a82bcd4a2f/web/deps/dep18.mdwn
> >
> > This would have been a great topic to discuss in person at DebConf, but
> > unfortunately I can't attend this year, so I'll just kick this off on the
> > mailing list.
>
> thank you for working on this.
>
> > This is continuation to the 'single maintainership' discussions earlier this
> > year. I also think that more unified and open collaboration processes could
> > help decrease maintainer burnout, lower barrier for existing and new
> > maintainers to help with multiple packages, and overall perhaps also improve
> > quality of uploads by having more attention on the source code prior to
> > upload.
>
> A slightly related topic: what is everybody's opinion on maybe starting with
> some of the basic items of DEP-18, lets say items 1-3, and prescribe them to
> only a very small set of packages in Debian. And which set of packages in
> Debian should *especially* have easy open collaboration enabled if not the set
> of source packages producing our Essential:yes packages? So why not start with
> the source packages in the Essential:yes set, have them adhere to better
> collaboration standards like packaging in git on salsa and with salsa CI
> enabled?

This is a great idea, as it would provide a real testing ground while
having a clearly delineated and well defined scope, and with the
greatest potential return of investment.

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

[Luca Boccassi]

On Thu, 1 Aug 2024 at 09:49, Jonas Smedegaard  wrote:
> Quoting Otto Kekäläinen (2024-08-01 07:30:18)
> > You have for sure developed an optimal workflow for yourself.
>
> Then I have failed: I have strived towards a collaborative workflow.
>
> Just not a web-centered collaborative workflow, but an email- and chat-
> based one.

Emails are actually a barrier against collaboration, and actively
hinder it by preventing new people from joining in. Please understand
that, outside of the demographic group of people who started using
computers in the 70s and 80s, the vast majority of opinions on the
topic of email as a collaborative tool range from "barely tolerated"
to "deeply hated". Emails sucks, it's horrible and outdated stuff
based on horrible and outdated procolos and ideas, and today it is by
and large a system to deliver spam, phishing and malware, with
occasional barely useful things like confirming registration on a new
website or resetting a lost password. The vast majority of people who
are forced to use emails do so for work via a
work-mediated/administered interface that tries to make it somewhat
tolerable, like Outlook or Gmail. By and large people born this side
of the millennium look at people running their own email workflows as
you would look at someone programming with punchcards - an interesting
curiosity if found in a museum re-enactment or a history book
photograph, and a strong reason to get the heck out of there
otherwise. And outside of the tech bubble it's even worse. Some
projects like the kernel can afford to let the curmudgeons continue to
dictate its use because it's a de-facto monopoly and if one wants to
get things merged in Linux there is no alternative, and even then
there are continuous grumblings and attempts by the IT infra managers
to build bridges with the 21st century with custom and bespoke
kernel-specific kludges, to the point where some subtree maintainers
have just gone "fuck this" and set up their own Gitlab repos for their
own subtrees. We don't have that luxury: there are plenty of
alternatives to Debian that work just as well for the same use cases.

The number of people involved in programming, software engineering, IT
and any other related field has absolutely exploded since the 90s. The
number of Debian project members has remained pretty much flat at
~1000 people, and we just about manage to backfill retirements/MIAs.
To pick a random example, a less well known, less used, less popular
distribution like Nixos has 7000+ contributors listed on Github. It
would be wise to stop and reflect on why this is the case every now
and then. The passage of time and demographics are cruel and
merciless.

And the fact that, two decades or so after it became standard practice
in the industry, there is _still_ resistance against having CI runs
_before_ pushing things out simply boggles my mind. This is a no
brainer: run a CI before uploading, even a very basic one is just
fine, better than nothing. It's 2024, "but but but the Gitlab UI
doesn't display nicely on my 80x24 green phosphor monochrome monitor"
just doesn't cut it anymore, sorry.

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

[Luca Boccassi]

On Thu, 1 Aug 2024 at 13:43, Charles Plessy  wrote:
>
> Le Thu, Aug 01, 2024 at 12:23:43PM +0100, Luca Boccassi a écrit :
> >
> > run a CI before uploading, even a very basic one is just fine, better
> > than nothing.
>
> Thanks for the remider !  I will have a closer look at Salsa CI instead
> of trying to understand how to run autopkgtests locally.
>
> Would there be a way to get Salsa upload and tag the package if the CI
> tests pass and the changelog signals a release?  Or does somebody has a
> script which can screen a Salsa group for ready uploads, and run clone
> && buildpackage && dput automatically ?

See https://www.debian.org/vote/2024/vote_002 and the associated email
threads on debian-vote

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

[Luca Boccassi]

On Thu, 1 Aug 2024 at 18:16, Marc Haber  wrote:
>
> On Thu, 1 Aug 2024 12:23:43 +0100, Luca Boccassi 
> wrote:
> >The vast majority of people who
> >are forced to use emails do so for work via a
> >work-mediated/administered interface that tries to make it somewhat
> >tolerable, like Outlook or Gmail.
>
> This must be the least accurate statement about Outlook that I have
> ever read. Outlook does not have a single feature that makes email
> more tolerable in any way. Au contraire. The feature called threading
> is incompatible with the rest of the world and not even very useful in
> an outlook-only environment, the search function finds everything but
> the mail you're looking for, and Outlook's disability to quote
> decently is notorious for having led to the whole world generating
> only top-posting replies.
>
> Outlook is essentially responsible for making email so much worse
> today than it was in the 1990s.
>
> Even Salsa's and github's praised way to communitate in an MR is
> VASTLY inferior to a decently threading mail client like mutt or even
> Thunderbird.
>
> I violently disagree with the rest of the message as well and am not
> willing to spoil the rest of my day by replying in detail. I'd prefer
> learning a bit more Slowfoxtrot later tonight.

Again, please understand that outside of the bubble of tech nerds of
the 70s/80s, saying out loud phrases such as "The only right way to
collaborate is reading and writing emails is in my terminal" means
getting looked at like being a dinosaur just escaped from a museum.
The rest of the universe just doesn't work like that, sorry. There's
nothing wrong with being a dinosaur for an individual of course, we
will all become one at some point, but optimizing for making dinosaurs
happy from the simple perspective of demographics is a sure way for a
project to slowly slide into irrelevance. The fact that the project
membership has just about managed to remain flat while the tech sector
absolutely exploded in size should send shivers down everyone's
spines.

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

[Luca Boccassi]

On Thu, 1 Aug 2024 at 21:57, Marc Haber  wrote:
>
> On Thu, 1 Aug 2024 18:36:29 +0100, Luca Boccassi 
> wrote:
> >On Thu, 1 Aug 2024 at 18:16, Marc Haber  wrote:
> >>
> >> On Thu, 1 Aug 2024 12:23:43 +0100, Luca Boccassi 
> >> wrote:
> >> >The vast majority of people who
> >> >are forced to use emails do so for work via a
> >> >work-mediated/administered interface that tries to make it somewhat
> >> >tolerable, like Outlook or Gmail.
> >>
> >> This must be the least accurate statement about Outlook that I have
> >> ever read. Outlook does not have a single feature that makes email
> >> more tolerable in any way. Au contraire. The feature called threading
> >> is incompatible with the rest of the world and not even very useful in
> >> an outlook-only environment, the search function finds everything but
> >> the mail you're looking for, and Outlook's disability to quote
> >> decently is notorious for having led to the whole world generating
> >> only top-posting replies.
> >>
> >> Outlook is essentially responsible for making email so much worse
> >> today than it was in the 1990s.
> >>
> >> Even Salsa's and github's praised way to communitate in an MR is
> >> VASTLY inferior to a decently threading mail client like mutt or even
> >> Thunderbird.
> >>
> >> I violently disagree with the rest of the message as well and am not
> >> willing to spoil the rest of my day by replying in detail. I'd prefer
> >> learning a bit more Slowfoxtrot later tonight.
> >
> >Again, please understand that outside of the bubble of tech nerds of
> >the 70s/80s, saying out loud phrases such as "The only right way to
> >collaborate is reading and writing emails is in my terminal" means
> >getting looked at like being a dinosaur just escaped from a museum.
> >The rest of the universe just doesn't work like that, sorry. There's
> >nothing wrong with being a dinosaur for an individual of course, we
> >will all become one at some point, but optimizing for making dinosaurs
> >happy from the simple perspective of demographics is a sure way for a
> >project to slowly slide into irrelevance. The fact that the project
> >membership has just about managed to remain flat while the tech sector
> >absolutely exploded in size should send shivers down everyone's
> >spines.
>
> Now that you have added personal insult while not adding anything for
> the cause, I recuse myself from continuing this situation. I am happy
> that I don't need to collaborate with you in my Debian efforts.

What are you on about? What personal insult?

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

[Luca Boccassi]

On Thu, 1 Aug 2024 at 18:23, Jeremy Stanley  wrote:
>
> On 2024-08-01 12:23:43 +0100 (+0100), Luca Boccassi wrote:
> [...]
> > To pick a random example, a less well known, less used, less
> > popular distribution like Nixos has 7000+ contributors listed on
> > Github.
> [...]
>
> Just to pick on this particular point, because I see this metric
> used all the time by projects trying to inflate public impressions
> of their size: you're aware that GitHub counts someone as a
> "contributor" even if all the do is leave a comment on a bug report,
> right? By that gauge, Debian is probably orders of magnitude larger.

I'm not, no, I thought it was committers/authors? But I haven't really
looked it up so you might very well be right. Where did you find that
defined?

Re: too long to build 2.6.14.2 kernel

[Luca Capello]

Hello!

On Tue, 22 Nov 2005 23:49:34 +0100, Andreas Orfanos wrote:
> I try to produce some statistical data with different kernels. The
> latest 2.4.32 takes an average 6 minutes to build (~500
> objects). But 2.6.0 takes more than half an hour for (~3000objects
> and more). The latest 2.6.14.2<http://2.6.14.2>one hour and more,
> and again we are talking for thousands of object files. I was using
> a 2GHz Pentium for the builds.

FYI, with the linux-source-2.6.14 and the linux-image-2.6.14-2-686
.config (so, all drivers as module) I got:
=
[EMAIL PROTECTED]:~/src/linux-2.6.15-rc3$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
 --enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr
 --enable-shared --with-system-zlib --libexecdir=/usr/lib
 --without-included-gettext --enable-threads=posix --enable-nls
 --program-suffix=-4.0 --enable-__cxa_atexit --enable-clocale=gnu
 --enable-libstdcxx-debug --enable-java-awt=gtk --enable-gtk-cairo
 --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre
 --enable-mpfr --disable-werror --enable-checking=release
i486-linux-gnu
Thread model: posix
gcc version 4.0.3 2005 (prerelease) (Debian 4.0.2-4)

[EMAIL PROTECTED]:~/src/linux-source-2.6.14$ time fakeroot make-kpkg
real34m9.394s
user30m30.182s
sys 2m19.645s

[EMAIL PROTECTED]:~/src/linux-source-2.6.14$ fakeroot make-kpkg clean

[EMAIL PROTECTED]:~/src/linux-source-2.6.14$ time fakeroot make-kpkg \
 kernel_image
real35m34.851s
user31m26.494s
sys 2m25.501s

[EMAIL PROTECTED]:~/src/linux-source-2.6.14$
=

This is on a IBM ThinkPad T42p: Pentium-M 745 (1.80GHz) and 512MB RAM.

Thx, bye,
Gismo / Luca


pgpb9uNq1nDSQ.pgp
Description: PGP signature

Re: Size matters. Debian binary package stats

[Luca Brivio]

On Sun, 18 Dec 2005 15:02:55 +0100
"Steinar H. Gunderson" <[EMAIL PROTECTED]> wrote:

> Not to mention that a DVD-R can fit about three million times as much
> data as a floppy disk, which was the dominant way of distributing
> software at the time. We can continue keep playing these number
> games, but I don't really see the point :-)

Anyway, ~ 3 000 times, not ~ 3 000 000 times, sadly!

-- 
Luca Brivio


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

Bug#349607: ITP: cl-parenscript -- JavaScript embedded in a Common Lisp host

[Luca Capello]

Package: wnpp
Severity: wishlist

* Package name: cl-parenscript
  Version : 1:20060122-1
  Upstream Author : Manuel Odendahl <[EMAIL PROTECTED]>
Edward Marco Baringer <[EMAIL PROTECTED]>
* URL or Web page : http://common-lisp.net/project/ucw/repos/parenscript
* License : BSD
  Description : JavaScript embedded in a Common Lisp host

 Parenscript is a small lispy language that can be compiled to
 JavaScript.
 .
 It also comes with an embedded CSS representation in Common Lisp.
 This simplifies the development of web applications in Common Lisp
 by allowing the Common Lisp programmer to write all the documents
 in Common Lisp syntax.
 .
 HTML pages, CSS files and JavaScript code can be generated with
 the full power of Common Lisp and its macros.

=

This is necessary as dependency for UCW [1].

The package will be sit in the CL-Debian repository [2] and will
follow the "Common Lisp in Debian Manual" [3].  I'm resolving some
minor problems concerning the documentation, so it'll be ready in a
couple of days.

Thx, bye,
Gismo / Luca

[1] http://common-lisp.net/project/ucw/
[2] http://cl-debian.alioth.debian.org/cgi-bin/darcsweb.cgi
[3] http://cl-debian.alioth.debian.org/clid/clid.html/


pgp2gn1qJmKX7.pgp
Description: PGP signature

Re: Bug#350909: ITP: ekiga -- A VoIP softphone

[Luca Capello]

Hello!

On Wed, 01 Feb 2006 16:59:08 +0100, Santiago José Ruano Rincón wrote:
>
> * Package name: ekiga
>   Version : 1.99.0
>   Upstream Author : Damien Sandras  <[EMAIL PROTECTED]>
> * URL : http://www.ekiga.org/
> * License : GPL
>   Description : A VoIP softphone
>
>  Ekiga is a softphone with full support for SIP and H.323.

Some questions:

1) this is Gnomemeeting renamed, so have you asked to the Gnomemeeting
   maintainer (Jose Carlos Garcia Sogo <[EMAIL PROTECTED]>) if he would
   like to package it?

2) will the package be based on the unofficial Debian (but official
   Ekiga) snapshot available at [1]?

Thx, bye,
Gismo / Luca

[1] http://snapshots.gnomemeeting.net


pgpTlZ1JGJkT3.pgp
Description: PGP signature

Re: Bug#352064: ITP: wormux -- A clone of the Worms game

[Luca Capello]

Hello!

On Thu, 09 Feb 2006 15:39:29 +0100, Moritz Muehlenhoff wrote:
> Previous versions of Wormux depended on a development version of clanlib,
> that's why a previous ITP never made it into a real package and was later
> closed due to inactivity.

So, simple question: why not re-open the ancient ITP, instead of a new
one? ;-)

Thx, bye,
Gismo / Luca


pgpdKfR0V0fHZ.pgp
Description: PGP signature

Bug#292643: ITP: cl-s-xml -- simple Common Lisp XML parser

[Luca Capello]

Package: wnpp
Severity: wishlist
Owner: Luca Capello <[EMAIL PROTECTED]>

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: cl-s-xml
  Version : 3+cvs.2005.01.27
  Upstream Author : Sven Van Caekenberghe <[EMAIL PROTECTED]>
* URL : http://common-lisp.net/project/s-xml/
* License : Lisp LGPL
  Description : simple Common Lisp XML parser

 S-XML is a Common Lisp implementation of a simple XML parser, with
 a SAX-like and DOM interface.
 .
 This XML parser implementation has the following features:
  * It works (handling many common XML usages).
  * It is very small (the core is about 400 lines of code, including
comments and whitespace).
  * It has a core API that is simple, efficient and pure functional, much
like that from SSAX (see also http://ssax.sourceforge.net).
  * It supports different DOM models: an XSML-based one, an LXML-based one
and a classic xml-element struct based one.
  * It is reasonably time and space efficient (internally avoiding garbage
generatation as much as possible).
 .
 This XML parser implementation has the following limitations:
  * It does not support CDATA.
  * Only supports simple character sets.
  * It does not support name spaces
  * It does not support any special tags (like processing instructions).
  * It is not validating, even skips DTD's all together.

=

I already packaged it, it's available on my unofficial Debian repository:
http://luca.pca.it/debian/

My GPG key is 6D742669, http://keyserver.linux.it or http://luca.pca.it,
key fingerprint 10CD 0397 6DBE 1E36 DEA3  72CC 540A 7B5E 6D74 2669

The package is based on other cl-* packages, I followed the "Debian
New Maintainers' Guide" and it's lintian checked.

This is my first *official* Debian package, it will be follow ASAP by
cl-gtk (which needs to be checked for some little Debian things). I
haven't wrote to the sponsor list yet, because AFAIK most of the cl-*
packages are updated by Kevin M. Rosenberg <[EMAIL PROTECTED]>, so maybe
he'd be direct interested in sponsoring me (or whatever the best for
this and the other cl-* packages I'm going to ITP).

I'm here for any other questions, suggestions, etc.

Thx, bye,
Gismo / Luca

- -- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.10-mh2
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFB+kc7VAp7Xm10JmkRAtHnAJ4vHRNkq2ExV4u2spvXcIVHUV/brwCeNKeV
RHJ+E2xCFULUjEt6kP1QHxg=
=Kr35
-END PGP SIGNATURE-


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

Re: ITP: cl-rfc2388 -- an implementation of RFC 2388 in Common Lisp

[Luca Capello]

Hello!

On Wed 25 May 2005 07:17 +0200, Peter Van Eynde wrote:
> * Package name: cl-rfc2388
>   Version : x.y.z

0.9

>   Upstream Author : Name <[EMAIL PROTECTED]>

Janis Dzerins <[EMAIL PROTECTED]>

> * URL : http://www.example.org/

http://common-lisp.net/project/rfc2388/

> * License : (GPL, LGPL, BSD, MIT/X, etc.)

BSD

The only problem with this package is that the source contains the
rfc2388 text, which cannot be included in a free package. As the
rfc2388 text is already included in the doc-rfc-std-proposed package
(which is in not-free), IMO the cl-rfc2388 should suggest the
doc-rfc-std-proposed package.

BTW, the CVS source already contains a debian/ folder, as the author
accepted to let rfc2388 become a Debian native package :-)

Thx, bye,
Gismo / Luca


pgpKIbHx2mrcJ.pgp
Description: PGP signature

Re: Upcoming removal of orphaned packages

[Luca Bruno]

Joey Hess <[EMAIL PROTECTED]> scrisse:

> Martin Michlmayr wrote:
> > gkdial -- PPP dial-up configuration and dialing tool [#287992]
> >   * Orphaned 164 days ago
> >   * 1 RC bugs.
> 
> Does any graphical ppp frontend exist that can be used instead of
> this?

Under gnome you can find gpppkill and gpppon, but they can't manage
provider setting.
However you can find the modem-light applet for the gnome panel.

Gkdial is a great tool, but ATM is really buggy :(

Ciao, Luca

-- 
 .''`.  ** Debian GNU/Linux **  | Luca Bruno
: :'  :   The Universal O.S.| luca.br(AT)uno.it
`. `'`  | GPG Key ID: 0x3BFB9FB3
  `- http://www.debian.org  | Proud Debian GNU/Linux User


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

Bug#316503: ITP: istanbul -- Desktop session recorder

[Luca Bruno]

Package: wnpp
Severity: wishlist
Owner: Luca Bruno <[EMAIL PROTECTED]>

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: istanbul
  Version : 0.1.0
  Upstream Author : Zaheer Abbas Merali <[EMAIL PROTECTED]>
* URL : http://live.gnome.org/istanbul
* License : GPL
  Description : Desktop session recorder

Istanbul is a desktop session recorder for the Free Desktop.
It records your session into an Ogg Theora video file.
To start the recording, you click on its icon in the 
notification area. To stop you click its icon again.
..
It works on Gnome, KDE, XFCE and others.

- -- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/dash
Kernel: Linux 2.6.9
Locale: LANG=it_IT, LC_CTYPE=it_IT (charmap=ISO-8859-1)

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCxTJeRqobajv7n7MRAlj2AJ4wIcCvz19JdVMsFXyHkKy8HqdeEQCfWBCO
ZoDyPoVBDfGa9DjEHfv7p2g=
=iyY8
-END PGP SIGNATURE-


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

Re: Centralized darcs

[Luca Capello]

Hello!

On Tue, 01 Aug 2006 22:34:41 +0200, John Goerzen wrote:
> On Tue, Aug 01, 2006 at 09:06:19PM +0100, martin f krafft wrote:
>> John, are you actually using the workflow you describe for
>> maintenance of Debian packages? Single or team maintenance? Could
>> you elaborate a bit?
>
> I do use darcs for almost all of my Debian packages.  You can find
> my darcs repositories at http://darcs.complete.org/debian/
>
> In darcs, every working copy is a repository, and a branch is just a
> "get", and a commit to the canonical location is just a merge (darcs
> push).

FWIW, the Common Lisp in Debian group [1] (Peter Van Eynde, René Van
Bevern and me) uses Darcs to manage its packages [2].  From the
"private presentation" Peter sent me a long time ago...

The tree is

  upstream -> -upstream
   |
   branch + debian patches -> 

You update -upstream, then pull the changes into .
The debian parts are only in .  darcs-build.sh [3] or
darcs-buildpackage will automaticly create the upstream .orig.tar.gz
file from the -upstream repository.

> I've been using "darcs push", which sends the patch over ssh,
> instead of the e-mail thing since I am the only committer to my
> repos.  But sending a GPG-signed patch bundle can be as easy as
> "darcs send" and David Roundy has posted recipes for processing
> those on the server.

I don't know how Peter and René work, but in my case as I'm the only
one working on my packages I just rsync to Alioth my local
repositories.  In case I've patches for other (i.e. not mine)
repositories, I send them to the corresponding bug [4] or the
CL-Debian mailing list.

Just my 0.02€...

Thx, bye,
Gismo / Luca

[1] http://cl-debian.alioth.debian.org/
[2] http://cl-debian.alioth.debian.org/repository
[3] http://cl-debian.alioth.debian.org/repository/pvaneynd/darcs-build.sh
[4] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=335489


pgprsjWBVF1SU.pgp
Description: PGP signature

Re: Centralized darcs

[Luca Capello]

Hello!

On Wed, 02 Aug 2006 10:17:57 +0200, Christoph Haas wrote:
> On Tuesday 01 August 2006 23:47, John Goerzen wrote:
>> I do use darcs to track patches against upstream.  I really don't
>> understand the whole cdbs/dpatch/whatever thing -- why use a hack
>> to manage your patches when you could use a real VC tool that does
>> it better?
>
> Is there a common "best practice" procedure on how to deal with new
> upstream releases then?

You may check the darcs-buildpackage manual, if you've
darcs-buildpackage installed is at [1].

BTW, John's announcement is at [2].

HTH!

Thx, bye,
Gismo / Luca

[1] http://localhost/doc/darcs-buildpackage/html/
[2] http://www.abridgegame.org/pipermail/darcs-users/2005-April/007072.html


pgp9U74BPA27R.pgp
Description: PGP signature

Re: Centralized darcs

[Luca Capello]

Hello!

On Wed, 02 Aug 2006 15:32:13 +0200, John Goerzen wrote:
> If upstream uses darcs or git, you could use their repo directly.
> If they use CVS or SVN, you could use tailor to track it.  If they
> use Arch, you can use arch2darcs to track it.

For a tailor mini-HowTo, please give a look at [1].

Actually, I use a different approach for the three upstream that uses
CVS.

The first time I generated the darcs -upstream repository, I didn't
include the CVS folders (because anyway it's a lintian error if
they're present in the .orig.tar.gz).  Thus, every time I want to
"import" a CVS version into the darcs -upstream, I do:

  $ cd /path/to/package-upstream
  $ cvs update -d
  $ darcs add [any new files]
  $ darcs record -m "Import upstream $PACKAGE version $DATE
  $ darcs tag -m "UPSTREAM_$PACKAGE_$DATE

Until now it worked without any problem.

Thx, bye,
Gismo / Luca

[1] http://wiki.debian.org/PackagingWithDarcsAndTailor


pgpKWxkvHaODb.pgp
Description: PGP signature

Re: Centralized darcs

[Luca Capello]

Hello!

On Wed, 02 Aug 2006 16:49:06 +0200, Luca Capello wrote:
> The first time I generated the darcs -upstream repository, I didn't
 
> include the CVS folders (because anyway it's a lintian error if
  ^^^
> they're present in the .orig.tar.gz).

The underlined above should be read as "I didn't `darcs add` the CVS
folder", obviously the CVS folder is present into the
$PACKAGE-upstream folder (otherwise `cvs update -d` couldn't work).

Thx, bye,
Gismo / Luca


pgpoDLDCViCDu.pgp
Description: PGP signature

Re: Stuff the installer does which isn't done on upgrade....

[Luca Capello]

Hello!

On Sat, 05 Aug 2006 15:05:10 +0200, Adrian von Bidder wrote:
> On Thursday 03 August 2006 06:24, Nathanael Nerode wrote:
>> So upgraded systems don't get the benefits of certain changes to the
>> installer's defaults, or defaults in programs used by the installer.
>
> <http://wiki.debian.org/Sarge2EtchUpgrade>

I added a link to a blog entry by Erich Schuberts [1], whose
instructions I followed to turn on dir_index on my Debian.  Maybe a
more structured HowTo will be better, but in the meantime I think it
could be useful.

Thx, bye,
Gismo / Luca

Footnotes: 
[1] http://blog.drinsama.de/erich/en/linux/2006060401-optimize-your-ext23-fs


pgpVaXkG8TLJS.pgp
Description: PGP signature

Bug#383645: ITP: nta -- network traffic analyzer, generate static html reports from /proc/net/dev

[Luca Bigliardi]

Package: wnpp
Severity: wishlist
Owner: Luca Bigliardi <[EMAIL PROTECTED]>


* Package name: nta
  Version : 1.1
  Upstream Author : C. McCohy <[EMAIL PROTECTED]>
* URL : http://nta.kyberdigi.cz/
* License : GPL
  Programming Lang: Perl
  Description : network traffic analyzer, generate static html reports from 
/proc/net/dev

NTA is a perl script intended to run under cron that generates static
html reports of traffic passed through network interfaces.


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

Re: glibc and UNACCEPTs

[Luca Capello]

Hello!

On Tue, 22 Aug 2006 20:51:56 +0200, David Nusinow wrote:
> On Tue, Aug 22, 2006 at 03:30:07PM -0400, Joey Hess wrote:
>> Drew Parsons wrote:
>>> Unfortunately it's happened against, this time with the upload of
>>> xorg-server (xserver-xorg-core) 1:1.1.1-3, accidentally uploaded
>>> to unstable instead of experimental.  An easy enough mistake, it's
>>> only one little field in a changelog file.
>> 
>> '2:' is not any worse than '1:', so I don't see why this is any
>> worse than any other bug that upload could have introduced. Upload
>> again with a new epoch, problem solved.
>
> This is what I'd consider the appropriate fix. Just do another
> upload straight away and you don't even need to bother an
> ftpmaster. It's what I would have done if I'd been awake.

Well, the problem is that with my daily `apt-get update && apt-get
upgrade` I got (again) the xserver-xorg from unstable, ending up with
some X.Org packages from unstable and some from experimental, which
AFAIK isn't a good thing :-(

=
[EMAIL PROTECTED]:~$ apt-cache policy xserver-xorg xserver-xorg:
  Installed: 1:7.0.23
  Candidate: 1:7.0.23
  Version table:
 *** 1:7.0.23 0
990 http://ftp.ch.debian.org unstable/main Packages
100 /var/lib/dpkg/status
 1:7.0.22 0
500 http://ftp.ch.debian.org testing/main Packages

[EMAIL PROTECTED]:~$ apt-cache policy xserver-xorg-core xserver-xorg-core:
  Installed: 2:1.0.2-10
  Candidate: 2:1.0.2-10
  Version table:
 *** 2:1.0.2-10 0
990 http://ftp.ch.debian.org unstable/main Packages
100 /var/lib/dpkg/status
 1:1.1.1-2 0
  1 http://ftp.ch.debian.org experimental/main Packages
 1:1.0.2-9 0
500 http://ftp.ch.debian.org testing/main Packages

[EMAIL PROTECTED]:~$ apt-cache policy xserver-xorg-input-mouse 
xserver-xorg-input-mouse:
  Installed: 1:1.1.1-2
  Candidate: 1:1.1.1-2
  Version table:
 *** 1:1.1.1-2 0
  1 http://ftp.ch.debian.org experimental/main Packages
100 /var/lib/dpkg/status
 1:1.0.4-3 0
500 http://ftp.ch.debian.org testing/main Packages
990 http://ftp.ch.debian.org unstable/main Packages

[EMAIL PROTECTED]:~$ apt-cache policy xserver-xorg-video-v4l 
xserver-xorg-video-v4l:
  Installed: 0.1.1-1
  Candidate: 0.1.1-1
  Version table:
 *** 0.1.1-1 0
  1 http://ftp.ch.debian.org experimental/main Packages
100 /var/lib/dpkg/status
 0.0.1.5-1 0
500 http://ftp.ch.debian.org testing/main Packages
990 http://ftp.ch.debian.org unstable/main Packages

[EMAIL PROTECTED]:~$
=

I don't think it's my fault (not having preserved xserver-xorg-core
From an upgrade), but in case of just disregard this post.  If it's
not my fault, however, I think we need a new package in
experimental...

Thx, bye,
Gismo / Luca


pgpsSVCYsxZT2.pgp
Description: PGP signature

Need for darcs.debian.org?

[Luca Capello]

Hello!

Croos-posting to d-d and the CL-Debian mailing list to let it know
about my post, but please answer only on d-d (I set M-F-T and R-T
accordingly).

After having read zack's blog entry [2] about the new XS-X-VCS-xxx
field for debian/control files, I was adding it to my packages [3]
(all related to Common Lisp).

Now, most of the CL-Debian packages are Darcs-maintained, with
repositories like the following:

  http://cl-debian.alioth.debian.org/repository/$MAINT/$PACKAGE

While I'm fine with the string above, I'm wondering if a more general
one would be better, similar to the SVN one:

  http://darcs.debian.org/$GROUP/$PACKAGE

Now, the questions:

1) could it be useful and will it be adopted by the Darcs-maintained
   packages?

2) has someone already proposed it?  The only reference I could found
   is from a post to d-d by George Danchev [4].

Thx, bye,
Gismo / Luca

Footnotes: 
[1] http://cl-debian.alioth.debian.org
[2] http://www.bononia.it/~zack/blog//posts/xs-x-vcs-XXX.html
[3] http://qa.debian.org/[EMAIL PROTECTED]
[4] http://lists.debian.org/debian-devel/2006/07/msg00853.html


pgpEFieLKwCMy.pgp
Description: PGP signature

Re: new mplayer

[Luca Capello]

Hello!

Cc:ing directly Andrea and Dariush (the Debian maintainer) to be sure
they read my post, hope you don't mind.

On Thu, 21 Sep 2006 15:36:16 +0200, A Mennucc wrote:
> I prepared a new mplayer (with help from  Diego Biurrun of the
> mplayer team)

From the package description:

Mplayer is a movie player for LINUX.
.
NOTE: the .tar.gz distributed with Debian does not contain all of the upstream
code. Read README.Debian and copyright for details.
.
MPlayer plays most MPEG, VOB, AVI, OGG/OGM, VIVO,
ASF/WMA/WMV, QT/MOV/MP4, FLI, RM, NuppelVideo, yuv4mpeg, FILM, RoQ, PVA files,
supported by many native, XAnim, RealPlayer, and Win32 DLL codecs. You can
watch VideoCD, SVCD, DVD, 3ivx, RealMedia, and DivX movies too.
.
Another big feature of MPlayer is the wide range of supported output
drivers.  It works with X11, Xv, DGA, OpenGL, SVGAlib, fbdev,
AAlib(*), DirectFB, but you can also use SDL and GGI(*) (and this way
all their drivers) and some lowlevel card-specific drivers (for
Matrox, 3Dfx and Radeon, Mach64, Permedia3) too!  Most of them
supports software or hardware scaling, so you can enjoy movies in
fullscreen.  MPlayer supports also displaying through some hardware MPEG
decoder boards, such as the DVB and DXR3/Hollywood+.
(*) GGI and  AAlib are not currently compiled by default.
=

Some hints:

1) please add the upstream homepage at the end, as per the Developer
   Reference paragraph 6.2.4 [1], like
   =
   [...]
   (*) GGI and  AAlib are not currently compiled by default.
   .
Homepage: http://www.mplayerhq.hu
   =

2) the second paragraph could be better wrapped, especially compared
   to the third one
   =
   .
   MPlayer plays most MPEG, VOB, AVI, OGG/OGM, VIVO, ASF/WMA/WMV,
   QT/MOV/MP4, FLI, RM, NuppelVideo, yuv4mpeg, FILM, RoQ, PVA files,
   supported by many native, XAnim, RealPlayer, and Win32 DLL codecs.
   You can watch VideoCD, SVCD, DVD, 3ivx, RealMedia, and DivX movies too.
   =

3) I'd put the NOTE paragraph at the end of the description, but AFAIK
   there's no consensus on this as I could see from the output of
   `grep-aptavail -FDescription NOTE`

Thx, bye,
Gismo / Luca

Footnotes: 
[1] 
http://www.debian.org/doc/developers-reference/ch-best-pkging-practices.en.html#s-bpp-upstream-info


pgpFEZ9BM2kUg.pgp
Description: PGP signature

Re: Need for darcs.debian.org?

[Luca Capello]

Hello!

On Fri, 22 Sep 2006 18:17:56 +0200, John Goerzen wrote:
> On Fri, Sep 22, 2006 at 03:14:02PM +0200, Luca Capello wrote:
>> one would be better, similar to the SVN one:
>> 
>>   http://darcs.debian.org/$GROUP/$PACKAGE
>> 
>> Now, the questions:
>> 
>> 1) could it be useful and will it be adopted by the
>>Darcs-maintained packages?
>
> It could be useful, I think.  How would one push to it -- over ssh
> or with darcs send?

ATM, for what is the CL-Debian packages I'm rsyncing my local
repositories to the Alioth ones, because there's only one maintainer,
me :-D

IMHO the simplest solution I can see is a push over SSH, which is what
I successfully use for the BESE software [1] [2].

`darcs send` could be useful if we want to keep track of the various
commits on a mailing list.

Moreover, we could have darcs-server or darcsweb :-)

Thx, bye,
Gismo / Luca

Footnotes: 
[1] http://common-lisp.net/project/bese
[2] http://common-lisp.net/project/ucw


pgp2D5Yt10FZy.pgp
Description: PGP signature

Re: Bug#389053: apache2-common: API module structure `perl_module' in file /usr/lib/apache2/modules/mod_perl.so is garbled

[Luca Capello]

Hello!

Cc:ing to d-d to get a wider audience.

On Mon, 25 Sep 2006 12:27:42 +0200, Thom May wrote:
> reassign 389053 libapache2-mod-perl2
> retitle 389053 Please upload mod_perl2 to experimental built against apache 
> 2.2
> severity 389053 wishlist 
> thanks
>
> Mod Perl2 needs to be rebuilt in experimental to work with the new
> apache2.

Well, I thought the same but then I did a little test (which I'm sorry
I forgot to mention before):
=
[EMAIL PROTECTED]:~$ sudo dpkg -P libapache2-mod-perl2
(Reading database ... 105871 files and directories currently installed.)
Removing libapache2-mod-perl2 ...
Module perl disabled; run /etc/init.d/apache2 force-reload to fully disable.
Purging configuration files for libapache2-mod-perl2 ...

[EMAIL PROTECTED]:~$ sudo invoke-rc.d apache2 start
Starting web server (apache2)...apache2: Syntax error on line 185 of \
 /etc/apache2/apache2.conf: Syntax error on line 1 of \
 /etc/apache2/mods-enabled/php5.load: API module structure
 `php5_module' in file /usr/lib/apache2/modules/libphp5.so is garbled - \
 perhaps this is not an Apache module DSO? \
 failed!
invoke-rc.d: initscript apache2, action "start" failed.
[EMAIL PROTECTED]:~$
=

So, I submitted it to the apache2-common package because it involves
more than the single libapache2-mod-perl2 package (and again, sorry
not to have mentioned it before).

Thx, bye,
Gismo / Luca


pgplA5AKFSnDT.pgp
Description: PGP signature

Re: new mplayer

[Luca Capello]

Hello!

On Fri, 22 Sep 2006 16:35:27 +0200, Luca Capello wrote:
> Cc:ing directly Andrea and Dariush (the Debian maintainer) to be
> sure they read my post, hope you don't mind.

Doing it again :-)

> On Thu, 21 Sep 2006 15:36:16 +0200, A Mennucc wrote:
>> I prepared a new mplayer (with help from  Diego Biurrun of the
>> mplayer team)

FWIW, I cannot build it in a clean and updated-to-latest-sid pbuilder
(complete script available on request, 10K gzipped):
=
Script started on Tue 26 Sep 2006 01:38:35 AM CEST
[EMAIL PROTECTED]:~/test$ sudo pbuilder build mplayer_1.0~rc1~svn19921.dsc
I: using fakeroot in build.
pbuilder-buildpackage/i386 $Id: pbuilder-buildpackage-funcs,v 1.31 2006/05/30 
23:45:45 dancer Exp $
$Id: pbuilder-buildpackage,v 1.127 2006/08/15 13:14:25 dancer Exp $

Current time: Tue Sep 26 01:38:45 CEST 2006
pbuilder-time-stamp: 1159227525
Building the build Environment
[...]

Checking for s3fb ... no 
Checking for tdfxvid ... yes 
Checking for tga ... yes 
Checking for DirectFB ... /tmp/mplayer-conf-24598-4424.c:1:30: error: 
directfb_version.h: No such file or directory
no (failed to get version)
Checking for X11 headers presence ... yes (using /usr/include)
Checking for X11 ... yes 
Checking for DPMS ... yes (using Xdpms 4)
[...]

#
if test "19921" ; then echo  "#define VERSION 
\"dev-SVN-r19921-4.1.2-DFSG-free\""  > version.h ; else sh version.sh 
4.1.2-DFSG-free ; fi
touch configure-stamp
dh_testdir
[ -r DOCS/.upstream_ships_docs ] || /usr/bin/make -C DOCS/xml html-chunked
make[1]: Entering directory `/tmp/buildd/mplayer-1.0~rc1~svn19921/DOCS/xml'
mkdir ../HTML
(mkdir ../HTML/en)
/usr/bin/make HTMLDIR=../../HTML/en -C en html-chunked
make[2]: Entering directory `/tmp/buildd/mplayer-1.0~rc1~svn19921/DOCS/xml/en'
rm -f ../../HTML/en/*
../xmllint.sh main.xml
cp -f ../default.css ../../HTML/en/
../xsltproc.sh ../../HTML/en/ ../html-chunk.xsl main.xml
main.xml:25: warning: failed to load external entity 
"/usr/share/sgml/docbook/dtd/xml/4.1.2/docbookx.dtd"
]>
  ^
encoding-guide.xml:1437: parser error : Entity 'mdash' not defined
  boost encoding speed — by about 40-60% in typical cases —
  ^
encoding-guide.xml:1437: parser error : Entity 'mdash' not defined
  boost encoding speed — by about 40-60% in typical cases —
   ^
encoding-guide.xml:1447: parser error : Entity 'nbsp' not defined
  hung on to DivX 3 for years when newer codecs were already doing wonders,
[...]

unable to parse main.xml
make[2]: *** [../../HTML/en/index.html] Error 6
make[2]: Leaving directory `/tmp/buildd/mplayer-1.0~rc1~svn19921/DOCS/xml/en'
make[1]: *** [html-chunked-en] Error 2
make[1]: Leaving directory `/tmp/buildd/mplayer-1.0~rc1~svn19921/DOCS/xml'
make: *** [build-indep] Error 2
pbuilder: Failed autobuilding of package
 -> Aborting with an error
 -> unmounting dev/pts filesystem
 -> unmounting proc filesystem
 -> cleaning the build env 
-> removing directory /var/cache/pbuilder/build//31045 and its 
subdirectories
[EMAIL PROTECTED]:~/test$ exit

Script done on Tue 26 Sep 2006 01:40:21 AM CEST
=

Thx, bye,
Gismo / Luca


pgpwsMvbSeCIb.pgp
Description: PGP signature

Bug#390578: ITP: webcam-server -- a tool to share webcam streaming in www-browser

[Luca Bedogni]

Package: wnpp
Severity: wishlist
Owner: Luca Bedogni <[EMAIL PROTECTED]>

* Package name: webcam-server
  Version : x.y.z
  Upstream Author : Donn Morrison <[EMAIL PROTECTED]>
* URL : http://sourceforge.net/projects/webcamserver
* License : (GPL)
  Programming Lang: (C)
  Description : a tool to share webcam streaming in www-browser

 webcam_server is a server daemon that can stream frames from any
 video4linux device to  remote clients running the provided applet
 or single frame snapshots running a web browser, you simply have
 to point it to localhost:

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17.13
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)


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

Re: apt-findremovable v0.1 (initial release)

[Luca Capello]

Hello!

On Wed, 04 Oct 2006 13:08:50 +0200, Alexey Feldgendler wrote:
> On Wed, 04 Oct 2006 18:07:02 +0700, Raphael Hertzog <[EMAIL PROTECTED]> wrote:
>
>>> Some of us are partial to apt-get and would appreciate
>>> apt-findremovable.
>
>> I would rather appreciate that apt-get and aptitude share the
>> information of which packages have been explicitely installed and
>> which have been automatically installed.
>
> Why not just stop using apt-get? aptitude can do everything the same
> as apt-get and even supports the same command line parameters.

I reordered the dependencies, to be simpler to compare:
=
[EMAIL PROTECTED]:~$ dpkg -s aptitude | grep Installed
Installed-Size: 8424
[EMAIL PROTECTED]:~$ dpkg -s aptitude | grep Depends
 Depends: libc6 (>= 2.3.6-6), libgcc1 (>= 1:4.1.1-12), \
  libstdc++6 (>= 4.1.1-12), \
  libapt-pkg-libc6.3-6-3.11, libncursesw5 (>= 5.4-5), \
  libsigc++-2.0-0c2a (>= 2.0.2)

[EMAIL PROTECTED]:~$ dpkg -s apt | grep Installed
Installed-Size: 4296
[EMAIL PROTECTED]:~$ dpkg -s apt | grep Depends
 Depends: libc6 (>= 2.3.6-6), libgcc1 (>= 1:4.1.1-12), \
  libstdc++6 (>= 4.1.1-12)

[EMAIL PROTECTED]:~$
=

Except from the difference in size between aptitude and apt, we have:

- libapt-pkg-libc6.3-6-3-11 is provided by apt, so with aptitude we
  *have* apt

- libncursesw5 adds 584K

- libsigc++-2.0-0c2a adds 88K

Even if it's only about 5M more, sometimes matter (not in my specific
case, however).

Thx, bye,
Gismo / Luca


pgp7iuBS7UlJs.pgp
Description: PGP signature

Removing obexserver (Re: RFA: obexserver -- Receive files with OBEX protocol)

[Luca Capello]

Hello!

Taking this out of bug [1] and to d-d to have a more advice on the
correct action to be taken (as per DevRef §5.9.2 [2]).

On Wed, 11 Oct 2006 16:47:08 +0200, Michael Holzt wrote:
>> Good idea, I talked with Eugeniy about that. Though, I guess the
>> final decision is to the obexserver maintainer.
>
> Totally fine with me. Go ahead and remove obexserver from the
> distribution.
>
>> Since my NMU on affix, when it propagates to testing, obexserver
>> will be the last user of the old libopenobex-1.0-0 package:
>
> This is nice as well.

As the maintainer agrees, we should ask for remotion of obexserver
(and successively libopenobex-1.0-0, cc:ing its maintainer).  While
the latter has no opened bugs, the former has 4 bugs: how should we
deal with them?  Just close them with remotion of the package?

Another question: is it worth to remove the package from etch, too?

Thx, bye,
Gismo / Luca

Footnotes: 
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=363689
[2] 
http://www.debian.org/doc/developers-reference/ch-pkgs.en.html#s-removing-pkgs


pgpzLEgjCs2cT.pgp
Description: PGP signature

Re: Removing obexserver (Re: RFA: obexserver -- Receive files with OBEX protocol)

[Luca Capello]

Hello!

On Thu, 12 Oct 2006 00:21:03 +0200, Hendrik Sattler wrote:
> Am Donnerstag 12 Oktober 2006 00:06 schrieb Luca Capello:
>> As the maintainer agrees, we should ask for remotion of obexserver
>
> The bug for removal is already filed: #392447

Oh, that's very good, I thought that a note would have been posted on
the RFA bug, too ;-)

>> While the latter has no opened bugs, the former has 4 bugs: how
>> should we deal with them?  Just close them with remotion of the
>> package?
>
> All should be solved with the replacement:
> #300908, #278609: I don't see why it shouldn't just work
^^
I've a SE K700i and can confirm that obexpushd works nicely with it
(tested today).

>> Another question: is it worth to remove the package from etch, too?
>
> AFAIK, etch will follow sid automatically.

I know this, but I was wondering about the time needed to remove both
packages.  Anyway, just a question, nothing more.

Thx, bye,
Gismo / Luca


pgpD8DS6ILBB0.pgp
Description: PGP signature

Re: Bug#392122: ITP: php-suhosin -- Suhosin is an advanced protection system for PHP installations.

[Luca Capello]

Hello!

On Tue, 10 Oct 2006 14:57:38 +0200, Jan Wagner wrote:
> * Package name: php-suhosin
>   Version : 0.9.6

There's already ITP #392119 [1] (cc:ing its submitter), I guess the
two should be merged.

Thx, bye,
Gismo / Luca

Footnotes: 
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=392119


pgpmAKlhCXgvG.pgp
Description: PGP signature

Re: release critical bug in apache2.2?

[Luca Capello]

Hello!

On Sun, 05 Nov 2006 21:13:14 +0100, Bastian Venthur wrote:
> But the DirectoryIndex problem should be fixed nevertheless.

FWIW, I've the following for apache2.2 on my sid:
=
[EMAIL PROTECTED]:~$ grep -r index.html /etc/apache2/*
/etc/apache2/mods-available/dir.conf: \
 DirectoryIndex index.html index.cgi index.pl index.php index.xhtml
[EMAIL PROTECTED]:~$
=

BTW, I didn't manually touch any configuration files and I tried also
to purge apache2.2-common: the result is always the same,
/etc/apache2/mods-available/dir.conf contains that line [1].

Thx, bye,
Gismo / Luca

Footnotes: 
[1] 
http://svn.debian.org/wsvn/pkg-apache/trunk/apache2/config-dir/mods-available/dir.conf?op=file&rev=0&sc=0


pgpEEqUrM7N0e.pgp
Description: PGP signature

Bug#399398: ITP: screenkast -- Record your activities on the screen

[Luca Bedogni]

Package: wnpp
Severity: wishlist
Owner: Luca Bedogni <[EMAIL PROTECTED]>


* Package name: screenkast
  Version : 0.1.3
  Upstream Author : Bram Biesbrouck <[EMAIL PROTECTED]>
* URL : http://sourceforge.net/projects/screenkast
* License : GPL
  Programming Lang: C++
  Description : Record your activities on the screen

Screen capturing program that records your screen-activities, supports
commentboxes and exports to all video formats. It also acts as a client
for the captorials.com website that enables you to share your captured
tutorial with users around the world.

-- System Information:
Debian Release: 4.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18.2
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]

Bug#399402: ITP: libinstrudeo -- library for capturing screen recordings

[Luca Bedogni]

Package: wnpp
Severity: wishlist
Owner: Luca Bedogni <[EMAIL PROTECTED]>


* Package name: libinstrudeo
  Version : 0.1.3
  Upstream Author : Bram Biesbrouck <[EMAIL PROTECTED]>
* URL : http://sourceforge.net/projects/libinstrudeo/
* License : GPL
  Programming Lang: C++
  Description : library for capturing screen recordings

Library, initially written for the ScreenKast program. Provides the
necessary logic to capture screen recordings and to process them.
Includes a soap-client for the webservice at captorials.com that enables
you to share your recordings.

-- System Information:
Debian Release: 4.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18.2
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: Debian Archive Automatic Signing Key (4.0/etch)?

[Luca Capello]

Hello!

On Wed, 22 Nov 2006 12:09:58 +0100, Hendrik Sattler wrote:
> Noone answered, yet, why this key is not in debian-archive-keyring
> package.

It's there since the last update:
=
debian-archive-keyring (2006.11.22) unstable; urgency=low

  * Non-maintainer upload.
  * Add Etch release key
  * Bump priority to important (Closes: Bug#397698)
  * Update FSF address in copyright.

 -- Anthony Towns   Wed, 22 Nov 2006 01:30:50 +1000
=

> I thought that the whole idea was to make it available before it
> gets used. 
> That would be the easiest (install it at installation time) and
> "apt-key update" could be used.

Full ACK.

Thx, bye,
Gismo / Luca


pgp7nG6u7Yo8m.pgp
Description: PGP signature

Re: Automatically collect hardware information from users?

[Luca Capello]

Hello!

On Mon, 27 Nov 2006 13:56:53 +0100, Petter Reinholdtsen wrote:
> [Goswin von Brederlow]
>> Shouldn't that be included in popularity-contest?
>
> Well, I have had the same idea, but never found time to implement
> it.  It could be added as an option to popularity-contest, but not
> as part of the normal popcon submission as it would require approval
> from each individual sysadmin with popcon installed before reporting
> hardware information.  On the other hand, the hardware content in a
> machine changes very rarely, while the package list change fairly
> regularly.

Another solution could be to add the feature to popularity-contest,
but only for the first submission and controlled by a debconf question
when the package is installed (thus the sysadmin can approve it).

> I suspect it is a good idea to set up the collector as part of
> popcon.debian.org, but let the hardware reporting system be a
> standalone package reporting when the machine is installed or
> something like that, instead of weekly.

Well, doesn't the debian-installer report [1] [2] already fulfill the
latter case, i.e. when the machine gets installed the first time?

Just my 0.02€...

Thx, bye,
Gismo / Luca

Footnotes: 
[1] /var/log/debian-installer/*
[2] http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=installation-reports


pgpwltd4j6YjD.pgp
Description: PGP signature

Re: Hal issues with RB

[Luca Capello]

Hello!

On Mon, 11 Dec 2006 17:50:02 +0100, Loïc Minier wrote:
> On Mon, Dec 11, 2006, Sven Arvidsson wrote:
>> If you're not running a complete GNOME environment, it's possible
>> that hal is missing. Rhythmbox seems to need it for audio CD
>> playback. At least that's what bug 380503 indicates.
>
> RB recommends gnome-volume-manager which depends on hal, but it
> might make sense to Recommend or even depend on hal, I didn't check
> whether it helps.

I'm the submitter of the bug mentioned above: as I reported,
installing hal solved the issue.

I think the problem has two points:

1) rhythmbox *should* at least recommends hal, because this (and not
   gnome-volume-manager) is what lets rhythmbox plays AudioCD.
   Moreover, the g-v-m recommendation has been added in version
   0.9.6-2 for iPod-autodetection support, after I reported the bug
   (discovered in version 0.9.5-2).  Obviously, I didn't and still
   don't have g-v-m installed.

2) no note about playing AudioCD is present in the README.Debian, thus
   the user cannot discover the problem source on a normal GNOME
   session, where I guess rhythmbox isn't started with terminal output
   (I didn't check, sorry).

Thx, bye,
Gismo / Luca


pgpVSmtoVx79y.pgp
Description: PGP signature

Re: Some emacs modes only depends on *emacs21, mass bug filing?

[Luca Capello]

Hello!

On Thu, 14 Dec 2006 00:23:56 +0100, Arnaud Fontaine wrote:
> Here is the list of the affected packages (this kind of problem may
> already have been reported for some packages in this list):
[...]
> Fumitoshi UKAI <[EMAIL PROTECTED]>
>w3m-el

This is bug #321995 [1], quite old, I'm cc:ing the maintainer in case
he doesn't read d-d.

Thx, bye,
Gismo / Luca

Footnotes: 
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=321995


pgpPssNX6dz0k.pgp
Description: PGP signature

Re: Bug#403506: ITP: fdisk -- linux fdisk replacement based on libparted

[Luca Capello]

Hello!

On Mon, 18 Dec 2006 09:50:10 +0100, Michael Banck wrote:
> On Sun, Dec 17, 2006 at 10:58:29PM +0100, Julien Louis wrote:
>> I'll rename the package to gnu-fdisk reflect binary name changes.
>
> The usual naming scheme seems to be to prepend the name with a `g',
> see glibc, gcc, gawk, etc.

I think the main problem here is that the GNU fdisk page [1] already
refers to another gfdisk, which AFAIK should be the GNOME fdisk,
lately renamed to gnome-fdisk [2].

Thx, bye,
Gismo / Luca

Footnotes: 
[1] http://www.gnu.org/software/fdisk/
[2] http://live.gnome.org/ListOfCVSModulesArchive


pgpeZOqBNFrAE.pgp
Description: PGP signature

Re: possible grave bug in debian-installer or ifupdown?

[Luca Capello]

Hello!

On Mon, 18 Dec 2006 07:36:01 +0100, Anthony Towns wrote:
> On Sun, Dec 17, 2006 at 09:58:48PM +0100, Bastian Venthur wrote:
>> I issued:
>>  # ifup eth0
>> manually on both boxes but nothing happened. 
>
> This probably means that ifup thought the interface was already up
> -- ie there was an "eth0" entry in /etc/network/ifstate.

Shouldn't ifup show a message anyway?  On my sid:
=
[EMAIL PROTECTED]:~$ cat /etc/network/run/ifstate
lo=lo
wired=wired-unige-sciii
[EMAIL PROTECTED]:~$ sudo ifup wired
Password:
ifup: interface wired already configured
[EMAIL PROTECTED]:~$
=

Thx, bye,
Gismo / Luca


pgpfOGUJQ7a8e.pgp
Description: PGP signature

Re: BTS package to report bugs in "Debian New Maintainers' Guide"

[Luca Capello]

HellO!

On Sun, 07 Jan 2007 18:02:34 +0100, Jari Aalto wrote:
> Where should the bugs found in "Debian New Maintainers' Guide" be
> reported? BTS package name?

=
[EMAIL PROTECTED]:~$ dpkg -s maint-guide | grep Description
Description: Debian New Maintainers' Guide
[EMAIL PROTECTED]:~$ 
=====

Thx, bye,
Gismo / Luca


pgp5LYfI4z316.pgp
Description: PGP signature

Bug#359339: ITP: cl-trivial-sockets -- a Common Lisp socket interface

[Luca Capello]

Package: wnpp
Severity: wishlist

* Package name: cl-trivial-sockets
  Version : 0.3
  Upstream Author : Daniel Barlow <[EMAIL PROTECTED]>
* URL or Web page : http://www.cliki.net/trivial-sockets
* License : see below
  Description : a Common Lisp socket interface
 trivial-sockets is a portable socket interface that allows Common
 Lisp programs to open connected (client) stream sockets to network
 service (for example HTTP, FTP or SMTP servers) and communicate with
 them.  It's intended mostly for "scripting" and interactive use.
 .  
 Note that in the interests of simplicity and ease of porting, the
 functionality available through TRIVIAL-SOCKETS has been deliberately
 restricted.



Here is the license:
 Copyright (c) 2004 Daniel Barlow and contributors

 Permission is hereby granted, free of charge, to any person obtaining
 a copy of this software and associated documentation files (the
 ``Software''), to deal in the Software without restriction, including
 without limitation the rights to use, copy, modify, merge, publish,
 distribute, sublicense, and/or sell copies of the Software, and to
 permit persons to whom the Software is furnished to do so, subject to
 the following conditions:

 The above copyright notice and this permission notice shall be
 included in all copies or substantial portions of the Software.

 THE SOFTWARE IS PROVIDED ``AS IS'', WITHOUT WARRANTY OF ANY KIND,
 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
 MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
 NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
 BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
 ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
 CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
 SOFTWARE.

=

As the upstream author is a Debian maintainer, I've tried to contact
him before this ITP, but without any success.  I cc:ed him and I'll
wait a month before asking for my sponsor to uploading the package.

This is necessary as dependency for UCW [1].  The package will be
included in the CL-Debian repository [2] and will follow the "Common
Lisp in Debian Manual" [3].

Thx, bye,
Gismo / Luca

[1] http://common-lisp.net/project/ucw/
[2] http://cl-debian.alioth.debian.org/cgi-bin/darcsweb.cgi
[3] http://cl-debian.alioth.debian.org/clid/clid.html/


pgp8cR9bFFY2Z.pgp
Description: PGP signature

Re: How (not) to write copyright files - take two

[Luca Capello]

Hello!

On Sun, 26 Mar 2006 20:29:48 +0200, Joerg Jaspert wrote:
> Some extra hints:
>
> - Its not enough to have the following two-liner:
>   | On Debian systems, the complete text of the GNU General Public
>   | License can be found in the `/usr/share/common-licenses/GPL'
>   | file.
>
>   There are license headers, like the one used for GPL in the
>   example below, you should use those.

Just to be sure, is the following enough for the BSD license?

 This software is licensed under the terms of the BSD license,
 which can be found on Debian systems in the file
 /usr/share/common-licenses/BSD or from
 http://www.opensource.org/licenses/bsd-license.php

 The license was modified to reflect that $AUTHOR, not the Regents
 of the University of California, is the author. 

Thx, bye,
Gismo / Luca


pgp55EstzuGBG.pgp
Description: PGP signature

Bug#359348: ITP: cl-rfc2109 -- a cookie library for Common Lisp based on RFC 2109

[Luca Capello]

Package: wnpp
Severity: wishlist

* Package name: cl-rfc2109
  Version : 0.3
  Upstream Author : Alan Shields <[EMAIL PROTECTED]>
* URL or Web page : http://common-lisp.net/project/rfc2109/
* License : BSD
  Description : a cookie library for Common Lisp based on RFC 2109
 rfc2109 implements the original cookie specification as defined by
 the RFC 2109 document.
 .
 It can be used to generate (and eventually parse) cookies in an
 RFC-compliant way.
 .
 The recommended package adds extra features: test suite with
 cl-fiveam.

=

This is necessary as dependency for UCW [1].  The package will be
included in the CL-Debian repository [2] and will follow the "Common
Lisp in Debian Manual" [3].

A darcs repository with minor changes not yet included upstream is
available at [4].

Thx, bye,
Gismo / Luca

[1] http://common-lisp.net/project/ucw/
[2] http://cl-debian.alioth.debian.org/cgi-bin/darcsweb.cgi
[3] http://cl-debian.alioth.debian.org/clid/clid.html/
[4] http://cl-debian.alioth.debian.org/repository/lcapello/rfc2109-gismo


pgpP4kpxZ7sor.pgp
Description: PGP signature

Re: How (not) to write copyright files - take two

[Luca Capello]

Hello!

On Tue, 28 Mar 2006 17:06:05 +0200, Christoph Berg wrote:
> Re: Luca Capello 2006-03-28 <[EMAIL PROTECTED]>
>> Just to be sure, is the following enough for the BSD license?
[...]
>>  The license was modified to reflect that $AUTHOR, not the Regents
>>  of the University of California, is the author. 
>
> It feels wrong to do that, I'd copy the whole text. IMHO having the
> (C) Regents line in /usr/share/common-licenses/BSD makes that file
> practically useless, except for using the text as a cut-and-paste
> template.
>
> The fact that every (L)GPL packages' copyright points to
> /usr/share/common-licenses/ is misleading. Packagers are required to
> put the *full* license in debian/copyright (be it a 'short' license
> like BSD-style, be it a long text as the GPL uses).

I'm not an English native speaker, but I think this is not what it's
reported in the Debian New Maintainer's Guide [1] or in the Debian
Policy Manual [2].


[Debian New Maintainer's Guide]

 4.2 `copyright' file

 [...]

 The important things to add to this file are the place you got the
 package from and the actual copyright notice and license. You must
 include the complete license, unless it's one of the common free
 software licenses such as GNU GPL or LGPL, BSD or the Artistic
 license, when you can just refer to the appropriate file in
 /usr/share/common-licenses/ directory that exists on every Debian
 system.

-
[Debian Policy Manual]

 12.5 Copyright information

 Every package must be accompanied by a verbatim copy of its copyright
 and distribution license in the file
 /usr/share/doc/package/copyright. This file must neither be compressed
 nor be a symbolic link.

 [...]

 Packages distributed under the UCB BSD license, the Artistic license,
 the GNU GPL, and the GNU LGPL should refer to the files
 /usr/share/common-licenses/BSD, /usr/share/common-licenses/Artistic,
 /usr/share/common-licenses/GPL, and /usr/share/common-licenses/LGPL
 respectively, rather than quoting them in the copyright file.
=

Please correct me if I'm wrong :-)

Thx, bye,
Gismo / Luca

[1] http://www.debian.org/doc/maint-guide/ch-dreq.en.html#s-copyright
[2] http://www.debian.org/doc/debian-policy/ch-docs.html#s-copyrightfile


pgpdnEVWLDDkb.pgp
Description: PGP signature

Re: Reforming the NM process

[Luca Capello]

Hello!

As someone in the NM queue...

On Tue, 11 Apr 2006 18:59:44 +0200, Pierre Habouzit wrote:
> For 2.2, I'd recommend that NM's maintain a page about them on
> wiki.d.org (my current applicant did that, and I found that rather
> useful). In a glance you can see applicants that are not comited
> enough.

I wouldn't measure an NM commitment WRT a wiki page, at least if
she/he doesn't want to deal mainly with web pages.

I stopped putting too much effort in maintaining my website [1], while
I increased the time involved in Debian (or F/LOSS in general).

Just my 0.02€...

Thx, bye,
Gismo / Luca

[1] http://luca.pca.it


pgpnpqudS2Lrn.pgp
Description: PGP signature

Re: Reforming the NM process

[Luca Capello]

Hello!

On Wed, 12 Apr 2006 19:48:36 +0200, Raphael Hertzog wrote:
> On Wed, 12 Apr 2006, Luca Capello wrote:
>> I wouldn't measure an NM commitment WRT a wiki page, at least if
>> she/he doesn't want to deal mainly with web pages.
>
> Writing a wiki page is like writing a mail... you can cut & paste
> raw text in the wiki page and it will be ok. It's really not a big
> requirement...

I fear of the fact that my wiki page will be outdated, while my
involvement in Debian not.  Probably it's a specific problem of mine,
as I try to be the most perfectionist I can and... without success.

Obviously, as soon as the wiki page will be a requirement for an NM or
a DD, I'll put my best in it.

> you should be able to manage that if you're going to manage more
> complicated things like maintaining a package.

I already maintain some packages and I really prefer to work on
them than on web pages...

> We're not asking you to maintain a debian-dedicated website... :-)

I hope so, because my web-programming skills are not my bests ATM ;-)

Thx, bye,
Gismo / Luca


pgpkYWHBqf5x8.pgp
Description: PGP signature

Re: Reforming the NM process

[Luca Capello]

Hello!

On Thu, 13 Apr 2006 10:19:41 +0200, Raphael Hertzog wrote:
> Well, the wiki page has a "last change" date. The AM (or FD) will
> notice that it's not up-to-date and they can ask you to update it.

Thank you for the explanation.

Last questions:

- is there something like a template for an NM page?

- am I correct if I create my page at w.d.o/LucaCapello?

Thx, bye,
Gismo / Luca


pgpEK7MQVT7n4.pgp
Description: PGP signature

Re: alternatives and priorities

[Luca Capello]

Hello!

On Fri, 19 May 2006 08:46:28 -0500, Wouter Verhelst wrote:
> On Fri, May 19, 2006 at 02:28:30PM +0100, Jon Dowland wrote:
>> At 1148052328 past the epoch, Wouter Verhelst wrote:
>> >  Using popcon would ensure that the applications which most
>> >  people prefer would be the default; this is a fair and objective
>> >  criterion.
>> > 
>> > Thoughts?
>> 
>> Interesting idea, but by my reckoning that would make "ed" the
>> default editor for most people, which I don't think is a good idea:
>>  <http://popcon.debian.org/main/editors/by_inst>
>
> That's not an issue. First, ed doesn't install an alternatives for
> "editor". Second, there's also 'by_vote', which puts vim on top.

ed is installed as an alternative "editor":
=
[EMAIL PROTECTED]:~$ su
Password:
gismo:/home/luca# update-alternatives --list editor
/bin/ed
/usr/bin/emacs21
/usr/bin/mcedit-debian
/usr/bin/emacs-snapshot
/usr/bin/vim.tiny
gismo:/home/luca#
=

And the postinst script says so, too:
=
[EMAIL PROTECTED]:~$ grep alternatives /var/lib/dpkg/info/ed.postinst
 update-alternatives --quiet --install /usr/bin/editor editor /bin/ed -100 \
[EMAIL PROTECTED]:~$
=

Thx, bye,
Gismo / Luca


pgpfsxFY6kze9.pgp
Description: PGP signature

Re: [Debconf-discuss] Re: Please revoke your signatures from Martin Kraff's keys

[Luca Capello]

Hello!

On Thu, 25 May 2006 15:39:44 +0200, Henrique de Moraes Holschuh wrote:
> On Thu, 25 May 2006, Manoj Srivastava wrote:
>> It has come to my attention that Martin Kraff used an
>>  unofficial, and easily forge-able, identity device at a large key
> [...]
>
> Should you not have *signed* a message of this sort?  I certainly
> won't do anything until I know for sure it came from you.  And
> preferably, we need to hear Martin's side as well, before doing
> anything hasty (like either signing keys, or revoking signatures of
> keys).

FYI, Martin's explanation is at [1], which passed on Planet Debian.

Thx, bye,
Gismo / Luca

[1] http://blog.madduck.net/geek/2006.05.24-tr-id-at-keysigning


pgpa1W56G5ktc.pgp
Description: PGP signature

Re: [Debconf-discuss] Please revoke your signatures from Martin Kraff's keys

[Luca Capello]

Hello!

/me playing the devil's advocate instead of Enrico...

On Fri, 26 May 2006 08:32:43 +0200, David Moreno Garza wrote:
> As an additional bit of security, I asked some people to show their
> visa, issued by the Mexican government, or check the Mexican seal
> they got on their point of entrance to Mexico. After all, I trust a
> bit more some of my federal authorities.

As a side note, while my passport was valid (re-newed the day before
leaving for Mexico because I forgot it was expired after 5 years and
not 10), I didn't get any Mexican seal when I arrived at Mexico City
airport.  As 2 others DDs with me (Aurelien Jarno and Matthias Klose)
got a seal, I went back to the customs officer asking for the seal and
he answered me I didn't need it.

Thx, bye,
Gismo / Luca


pgpvxtl70NDFF.pgp
Description: PGP signature

Re: stumpwm: Clarify README.Debian - can't understand a thing how to start this wm

[Luca Capello]

tags 356948 + help
retitle 356948 stumpwm: clarify how to start this WM in the README.Debian
thanks

Hello!

For d-d: I'd like a more general advice about the user request, which
I'm quite reluctant to accomplish.

For all: please honor the R-T and M-F-T headers (no need to cc: me).

On Fri, 02 Jun 2006 19:05:01 +0200, Jari Aalto wrote:
> The debian/control::Description reads:
[...]
> From "StumpWM is a window manager written entirely in Common Lisp"
> it suggests, that is is just another window manager only that the
> host language is common lisp.

Well, as I already explained in my previous reply [1], you need a
specific background in Common Lisp to use this WM.  Moreover, the
package section is specifically set to "devel" and not "x11" as most
of the other WMs.

> Something is not connecting here. 
>
> - Aa per you explanation, the the sescription string should
>   differentiate stumpwm from the other regular "window managers"
>   by saing that this one is for only people that understand
>   how to use it with common lisp.
[...]
> Currently
>
> - Description does not suggest anything to be different from
>   standard WM
> - README* lacks information for anyone else but CL-knowledgeable.

I think that this is a problem not only for stumpwm, but for all the
Common Lisp software.

> Please don't go away, before we can improve this :-)

I'm still here, just asking more help from the fellow developers ;-)

Thx, bye,
Gismo / Luca

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=356948;msg=10


pgp92CItNVzxq.pgp
Description: PGP signature

Re: Bug#378876: Bug#378872: ITP: libsvm0 -- LibSVM is a machine-learning library providing Support Vector Machines in C++

[Luca Capello]

Hello!

On Fri, 21 Jul 2006 00:29:46 +0200, martin f krafft wrote:
> Also, about the -dev package name, please read the Debian Library
> Packaging Guide (I can't get at the URL right now, search for it)

http://www.debian.org/doc/developers-reference/ch-best-pkging-practices.en.html#s-bpp-libraries

and then

http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html

Thx, bye,
Gismo / Luca


pgprJSJ6OIvwj.pgp
Description: PGP signature

Re: ITP mgeupsd

[Luca Filipozzi]

On Wed, Mar 15, 2000 at 11:21:14PM -0800, Robert Stone wrote:
> Package: mgeupsd
> Architecture: any
> Conflicts: powstatd, bpowerd, genpower

Provides: ups-monitor
Conflicts: ups-monitor

This will catch all the other ups daemons.

I am packaging Network UPS Tools (NUT). I have finished and am just waiting
for my sponsor to upload the package. NUT will soon be a woody package.

NUT provides a pretty decent client/server architecture for supporting
multiple boxen on one UPS. The project provides interfaces to wide variety of
UPS's.

I am not the author of NUT. However, if you are the author of mbgeupsd, you
may wish to contribute to NUT.

NUT can be found at http://www.exploits.org/nut/

Just an idea,

Luca

-- 
Luca Filipozzi, EMYRnet

Re: Bug#60753: mutt: /etc/Muttrc should not use colors

[Luca Filipozzi]

On Mon, Mar 20, 2000 at 02:30:55AM -0600, Zed Pobre wrote:
> From my experiments with the above, only two things behave in a
> way that I would expect an unfamiliar user to find strange: asymmetry
> in PgUp/PgDown behaviour, and maybe UpArrow and DownArrow moving
> between messages instead of up and down single lines in a viewed
> message.  That can be fixed with three lines:
> 
> set pager_stop
> bind pager  previous-line
> bind pager  next-line

These lines are great for a new mutt user. They really should be in the
/etc/Muttrc file... at least commented out and documented. postinst could
even mention that such sane bindings exist.

LeftArrow goes to previous message when in paged view... so why does
UpArrow? It's very intuitive to use UpArrow to scroll up the current
screen.  ditto for RightArrow/DownArrow.

> On the other hand, maybe the project really would find those three
> lines more convenient to have as defaults.  How about it, folks,
> anyone in favor of adding the three lines above to the default
> /etc/Muttrc?

Yes!

-- 
Luca Filipozzi


pgpbKfDHff2M7.pgp
Description: PGP signature

Re: ITP: Netrek Vanilla server and COW (Client of Windows)

[Luca Filipozzi]

On Tue, Mar 21, 2000 at 10:13:49AM +0800, Neil Hunt wrote:
> I intend to package the Netrek vanilla server, and the COW client.

Cool. Are you also going to include instructions on how to play it from
behind a masquerading firewall? That would be the kind thing to do.

-- 
Luca Filipozzi


pgpHzJ7sGAaeI.pgp
Description: PGP signature

Re: Seems potato's now 'stable'! 2.2's out, then?

[Mircea Luca]

Ben Gertzfield wrote:
> 
> I guess nobody's actually announced it on the list, but the FTP sites
> seem to have moved the link for stable to potato! 2.2 must, logically,
> be released!
> 
> Shocking. :) Congrats to everyone! (How come it wasn't announced
> on the list?)
> 
> Ben
> 

 I just received the mail from debian-announce.It is official.


-- 
The best way to escape from a problem is to solve it. 
 Alan Saporta 
My waste of cyberspace=
http://deepblue.dyndns.org :-)

Re: Implementing "testing" (was: Re: Potato now stable)

[Mircea Luca]

 On Fri, Aug 18, 2000 at 10:34:35AM +0100, Jules Bean wrote:
I'd just like to bring up the only point which really worries me about
all this... what is the incentive for people to run their machines on
 'unstable'?

In my case curiosity to test new stuff without having to deal with
the other side(rpm based distros) and the assurance that all new
packages even if they're buggy fall into the Debian's way of
putting together a distro.Don't forget that most people don't have the
time/incentive to learn a new distro and Debian stable is pretty
outdated
for a desktop most of the time (see slink).I also find that testing new
stuff make you learn and research things that otherwise you really
wouldn't care about.Learning new stuff is good.:-)
 And btw at HDD prices this days it's quite easy to keep a stable
install
just in case you need the computer when unstable won't even boot.
 I for myself will install unstable next week now that I have a working
Stormix install(really just Debian+some extra stuff I don't use).

-- 
The best way to escape from a problem is to solve it. 
 Alan Saporta 
My waste of cyberspace=
http://deepblue.dyndns.org :-)

Re: ITP or rather upload... KDE

[Mircea Luca]

Hi

Will it be a kde2 for potato or only for woody?
Ofcourse assuming that KDE2 will be out before woody.:-)

-- 
The best way to escape from a problem is to solve it. 
 Alan Saporta 
My waste of cyberspace=
http://deepblue.dyndns.org :-)


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

Re: Need to clone machines efficiently - help?

[Mircea Luca]

Erik Winn wrote:
> 
> Hi Folks,
> 
>  I have just started working with a group here in Portland that is taking in
> old machines and recycling them - putting linux on as the OS (of course ;}).
> See http://www.freegeek.org for more. Its a non-profit all volunteer thing;
> and actually one of the people has posted to one of these lists before ...
> but, apparently things kinda (lamely, IMO) drifted toward a mandrake system
> -- I think I can turn that around with a little help; I am putting in some
> good time there and I think that when the realities of maintaining and
> upgrading rpm systems hits they may change their minds.
> 
>  Here is the first obstacle - not really a big one, but I spent all day
> digging around and couldn't really find any tools for this one: we want to be
> able to clone the machines easily over the local net. Mandrake has a tricky
> boot floppy that asks only for the eth0 config and then runs a bunch of perl
> to do the rest of the install non-interactively. I haven't started reading
> the scripts yet (that's plan B), instead I was hoping that someone had come
> up with something similar for debian. We are looking at hundreds of boxes
> already and its really just begun.
> 
>  This is really not a huge task - it would just make a nice splash over here
> if we could come up with something ...
> 
>  I would greatly appreciate recieving help/ideas/advice on this - Note
> however that I am not actually subscribed to the list at present (sorry, just
> too much at the moment ) so you can reply to me personally if you like.
> 
>  Thanks very much in advance! I hope we can get this to happen.
> 
> Erik Winn
> 
> --
This is what you want I guess.Made for Debian

http://www.informatik.uni-koeln.de/fai/

-- 
The best way to escape from a problem is to solve it. 
 Alan Saporta

ITP: TCM -- Toolkit for Conceptual Modelling

[Luca De_Vitis]

Package: wnpp
Severity: wishlist

The Toolkit for Conceptual Modeling is a collection of software tools to 
present conceptual models of software systems in the form of diagrams, 
tables, trees, and the like. (See the README file included in sources)
license: GPL
homepage: http://www.cs.utwente.nl/~tcm
sources: ftp://ftp.cs.utwente.nl/pub/tcm
Since I'm in NM, Cosimo Alfarano will sponsor me.
-- 
Luca - De Whiskey's - De Vitis
Undergraduate Student of Computer Science at Bologna University.
aliases: Luca ^De [A-Z][A-Za-z\-]*[iy]'\?s$
e-mail: devitis at (students dot )?cs dot unibo dot it
anti SPAM: s/\ dot\ /./ && (solve_regex(e-mail)
homepage: http://www.Students.CS.UniBO.IT/~devitis/

Re: Postgres 7?

[Luca Filipozzi]

On Fri, Jan 05, 2001 at 10:31:43PM +0100, Jiri Klouda wrote:
> Hi,
> why postgres 7 is inaccessible even in Woody?

Recently, the Debian package management system has undergone two major changes:
1) the introduction of package pools
2) the introdcution of the 'testing' distribution

The current state of the distributions is:
stable:   potato
testing:  woody
unstable: sid

The creation of 'testing' has meant that all the packages in woody have
reverted to the versions from potato. Packages from unstable will migrate
to testing once all their dependencies are also in testing.

This means, for now, that packages in 'woody' are at about the same version
as 'potato'. Once the system has had time to settle, most packages in 'sid'
will also be in 'woody' with about a two week lag.

Please be patient.

Luca

-- 
Luca Filipozzi
[dpkg] We are the apt. Resistance is futile. You will be packaged.

Re: lilo.conf

[Luca Filipozzi]

On Sat, Jan 06, 2001 at 01:52:17PM +1100, Russell Coker wrote:
> I am working on the Debian package of lilo and am writing code for
> auto-generating lilo.conf files.

> image=/vmlinuz.old
> label=old

the 'old' image should be optional... i.e., add the optional keyword

> other=/dev/ide/host0/bus0/target0/lun0/part1
> label=part1

allow the user to specify the label

> table=/dev/ide/host0/bus0/target0/lun0/disc

-- 
Luca Filipozzi
[dpkg] We are the apt. Resistance is futile. You will be packaged.

ITP: phpGroupWare -- Web based GroupWare application

[Luca De_Vitis]

 Package: wnpp
 Severity: wishlist

phpGroupWare is a web based GroupWare system. It comes with serveral core apps
for email, calendar, todo list, address book, file manager, and a notepad. 

It also provides a framework for add-on applications to integrate seamlessly
in phpGroupWare. Some samples are a bookmark manager, a trouble ticket system,
a weather reporter, a phone log, a chat program, and a forum system. There are
many more in development, and you can develop your own as well. 

homepage: http://www.phpgroupware.org
licence: GNU GPL
-- 
Luca - De Whiskey's - De Vitis
Undergraduate Student of Computer Science at Bologna University.
aliases: Luca ^De [A-Z][A-Za-z\-]*[iy]'\?s$
e-mail: devitis at (students dot )?cs dot unibo dot it
homepage: http://www.Students.CS.UniBO.IT/~devitis
anti SPAM: s/\ dot\ /./ , s/ at /@/  && solve_regex(e-mail)

Re: NUT packages status checkpoint

[Luca Filipozzi]

On Sun, Aug 24, 2003 at 03:40:01PM +0200, Arnaud Quette wrote:
> To conclude, our collaboration (Karl and myself) on
> NUT bug squashing was really productive! I think he
> also should be listed as NUT Co Maintainer to
> officialise it, as Karl is also one of the most active
> people in the NUT Community!

I am very comfortable with this.  Karl's bug reports have been some of
the most useful that I have received, and they nearly always include
patches!

Anaud, please list Shaul Karl as comaintainer if he agrees.

Thanks very much for your efforts... life has take me out of the picture
for quite a number of months and I appreciate you two stepping in to
ensure that nut doesn't languish.

Luca

-- 
Luca Filipozzi
"Linux gives us the power to crush those that oppose us." - switchlinux
gpgkey 5A827A2D - A149 97BD 188C 7F29 779E  09C1 3573 32C4 5A82 7A2D

Re: How coldplug works

[Luca Capello]

Hi Marco!

On Tue 23 Aug 2005 09:57 +0200, Marco d'Itri wrote:
> On Aug 23, Isaac Clerencia <[EMAIL PROTECTED]> wrote:
>
>> I've just tried it and it has worked really great, except it has not loaded 
>> mousedev module. Everything else has worked, and it's incredible fast (at 
> It's supposed to, do you mind investigating? Do not delete the
> generated events, etc. Try manually running the init script a second
> time too.
> I noticed that on my system the first time it's run the ehci_hcd is not
> loaded, but I have not yet found why.

I just gave coldplug a try.

First of all, my Debian:

- unstable, just upgraded (not dist-upgrade, but a simple upgrade)

- vanilla 2.6.13-rc6 + ACPI patch dated 20050729 (compiled with
  make-kpkg), external modules are ALSA, cdfs, ieee80211, ipw2100,
  pwc, qc-usb and thinkpad

- udev 0.068-1 (and `dpkg --purge --force-all hotplug` ;-) )

- IBM ThinkPad T42p + docking station


And here the results (differences versus hotplug):

- mousedev is correctly loaded, but this is not the case for psmouse
  (so, it automatically starts xdm, but I need to manually load
  psmouse)

- no sound at all (the ALSA modules are not loaded)

- no wired network (I use the e1000 driver), while the ipw2100 module
  is automatically loaded

- otherwise, it seems to work correctly (I tried plugging in an
  external USB drive and scsi_mod, usb_storage and sd_mod are
  correctly and automatically loaded, but not uloaded)


BTW, as you suggested, I tried to manully run the init script
two/three times, but nothing changed.

I'm available for others test if you need (and I'm on Freenode as
gismo).

Thx, bye,
Gismo / Luca


pgpEviYSyNVfd.pgp
Description: PGP signature

Re: Effort to change IETF's copying conditions for RFCs

[Luca Capello]

Hello!

On Fri 07 Oct 2005 10:30 +0200, Simon Josefsson wrote:
> Russ Allbery <[EMAIL PROTECTED]> writes:
>
>> Wesley J Landaker <[EMAIL PROTECTED]> writes:
>>> On Thursday 06 October 2005 06:57, Simon Josefsson wrote:
>>
>>>> I know the copying conditions of IETF RFC's has been a concern
>>>> for Debian in the past, and that the RFCs has been removed from
>>>> the official archive (?),
>>
>> If they haven't been yet, they will have to be for etch, at least
>> all of the RFCs that are under the standard IETF IPR policy.  They
>> don't allow modification and redistribution of modified versions,
>> and therefore do not meet DFSG#3.
>
> Yes.  I couldn't find them when I did a 'apt-cache search' so I
> assume they were gone.  I recall a series of packages, rfc1-499,
> rfc500-999 or similar before.

`apt-cache search doc-rfc`, they are in unstable/non-free.

Thx, bye,
Gismo / Luca


pgpNL72k7mlO2.pgp
Description: PGP signature

Re: A thought about killing two bird with one stone

[Luca Capello]

Hello!

On Thu 27 Oct 2005 00:57 +0200, Brian May wrote:
> (I have seen a system that appears to run ntpdate on startup before
> the network is configured - but it hasn't bothered me enough to
> investigate why yet.)

If you're using ifplugd, this is a known (and wontfix) issue:

   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=204499

Thx, bye,
Gismo / Luca


pgp88ij34RKOx.pgp
Description: PGP signature

Re: Bug#328423: must be moved from recommeds to suggests

[Luca Capello]

Hello!

I posted to debian-devel because I think it's a general question and I
cannot figure out the answer with the manuals. Sorry if I was wrong.

I'm in the process of debianize some CL software [1] and I've the same
problem as bug #328423: some extra features of the package needs other
packages to be installed, so I don't know if the package should use
Suggests or Recommends.

On Sun 02 Oct 2005 13:11 +0200, Steve Langasek wrote:
> On Fri, Sep 30, 2005 at 12:11:22PM +0200, Wolfram Quester wrote:
>
>> as long as your attention rests at inkscape, may I ask you a question
>> about Bug #328423?
>
>> Olleg asked to move the stuff in Recommends: to Suggests: and argues:
>
>> On Mon, Sep 26, 2005 at 10:49:16AM +0400, Olleg Samoylov wrote:
>> > >So I'm not totally sure what would be the best way to follow here.
>
>> > Let's see 
>> > http://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps

>
>> > As I undestand the definition all modules and plugins must be declared 
>> > as suggests. Without it inscape give warning message "One or more 
>> > extensions failed to load". This is not very bad, but for newbie debian 
>> > user looked like something go wrong. But debian user expirienced enough 
>> > to uncheck "unstall suggests by default" will be not confused by this 
>> > warning. But I may mistake. May be better ask some of Debian Guru?
>
>> I think that he is right, but in the beginning I had it in Suggests and
>> got a bug report to move it to Recommends. So I think the solution would
>> be to put all this into Suggests and add a README.Debian explaining
>> which packages are needed for which effect. What do you think?

Wolfram was referring to bug #317767.

> I really have no strong opinion on the question; the best guides to
> Recommends vs. Suggests are the wording in policy, and user feedback. :)  It
> sounds to me like these would be better as Suggests than Recommends, but I
> don't know the package, so I don't have much to base that judgement on...

The "The Debian GNU/Linux FAQ" [2] says:

* Package A recommends Package B, if the package maintainer judges
  that most users would not want A without also having the
  functionality provided by B.

* Package A suggests Package B if B contains files that are
  related to (and usually enhance) the functionality of A.

So, I'd use Recommends in inkscape (and in the CL packages), but I'd
like to have a wider help ;-)

Thx, bye,
Gismo / Luca

[1] http://common-lisp.net/pipermail/bese-devel/2005-October/001176.html
[2] http://www.debian.org/doc/FAQ/ch-pkg_basics.en.html#s-depends


pgpUQ02lF33Vk.pgp
Description: PGP signature

Bug#337646: ITP: cl-arnesi -- small Common Lisp utilities

[Luca Capello]

Package: wnpp
Severity: wishlist

* Package name: cl-arnesi
  Version : 1:20051105-1
  Upstream Author : Edward Marco Baringer <[EMAIL PROTECTED]>
* URL or Web page : http://common-lisp.net/project/bese/arnesi.html
* License : BSD
  Description : small Common Lisp utilities

 arnesi is a Common Lisp utility suite. It contains various "bits 'n
 pieces" of code.
 .
 Features:
  * Flow control macros - while, whichever, if-bind, etc.
  * A simple logging facility - kind-of/sort-of/maybe like log4j.
  * HTTP/HTML utilities - URL and HTML escaping
  * Pattern matching - fare-matcher style pattern matcher and "regular"
list matcher
  * Accumulation - collecting and reducing macros
  * Cps transformer - an ad-hoc, bug ridden implementation of half of
call/cc.
  * Decimal arithmetic - convert floats to exact rationals and vice
versa with a given precision; standard rounding functions.
  * MOP compatibility package - The MOPP package provides the MOP's
symbols on various implementations. Currently OpenMCL, CMUCL, SBCL,
Lispworks and CLISP are supported.
 .
 The recommended packages add extra features: documentation via
 cl-qbook, test suite with cl-fiveam and add-ons for cl-ppcre.
 .
 This is the development version.

=

This is the first of a series of ITPs for Common Lisp software that is
necessary as dependency for UCW [1].

As soon as this bug will get a number by the BTS, I'll add the package
to the CL-Debian repository [2]. The package is linda and lintian
free and it follows the "Common Lisp in Debian Manual" [3].

Thx, bye,
Gismo / Luca

[1] http://common-lisp.net/project/ucw/
[2] http://cl-debian.alioth.debian.org/cgi-bin/darcsweb.cgi
[3] http://cl-debian.alioth.debian.org/clid/clid.html/


pgpNpXzGK1ASa.pgp
Description: PGP signature

Bug#337657: ITP: cl-fiveam -- simple regression testing framework

[Luca Capello]

Package: wnpp
Severity: wishlist

* Package name: cl-fiveam
  Version : 1:20051105-1
  Upstream Author : Edward Marco Baringer <[EMAIL PROTECTED]>
* URL or Web page : http://common-lisp.net/project/bese/FiveAM.html
* License : BSD
  Description : simple regression testing framework

 FiveAM is a simple (as far as writing and running tests goes)
 regression testing framework. It has been designed with Common
 Lisp's interactive development model in mind.
 .
 Features:
  * Test and test suite hierarchies allow test to be organized into
hierarchies to ease running
  * Functions for re-running recently run tests.
  * Inter-test dependencies.
 .
 The documentation is provided via the cl-qbook package.

=

Continuation of the series of CL software started with bug #337646.

As soon as this bug will get a number by the BTS, I'll add the package
to the CL-Debian repository [1]. The package is linda and lintian
free and it follows the "Common Lisp in Debian Manual" [2].

Thx, bye,
Gismo / Luca

[1] http://cl-debian.alioth.debian.org/cgi-bin/darcsweb.cgi
[2] http://cl-debian.alioth.debian.org/clid/clid.html/


pgphOxf3h7t0f.pgp
Description: PGP signature

Bug#337662: ITP: cl-yaclml -- Yet Another Common Lisp Markup Language

[Luca Capello]

Package: wnpp
Severity: wishlist

* Package name: cl-yaclml
  Version : 1:20051105-1
  Upstream Author : Edward Marco Baringer <[EMAIL PROTECTED]>
* URL or Web page : http://common-lisp.net/project/bese/yaclml.html
* License : BSD
  Description : Yet Another Common Lisp Markup Language

 YACLML is a collection of macros and utilities for generating
 XML/HTML like markup from lisp code.
 .
 Features:
  * Constant folds as much as possible.
  * Macros for generating HTML from within lisp code.
  * Templating system for generating HTML from designer templates.
 .
 The recommended packages add documentation via cl-qbook or a test
 suite with cl-fiveam.

=

Continuation of the series of CL software started with bug #337646.

As soon as this bug will get a number by the BTS, I'll add the package
to the CL-Debian repository [1]. The package is linda and lintian
free and it follows the "Common Lisp in Debian Manual" [2].

Thx, bye,
Gismo / Luca

[1] http://cl-debian.alioth.debian.org/cgi-bin/darcsweb.cgi
[2] http://cl-debian.alioth.debian.org/clid/clid.html/


pgperXExUzCx8.pgp
Description: PGP signature

Bug#337666: ITP: cl-qbook -- create HTML/LaTeX versions of Common Lisp source code

[Luca Capello]

Package: wnpp
Severity: wishlist

* Package name: cl-qbook
  Version : 1:20051105-1
  Upstream Author : Edward Marco Baringer <[EMAIL PROTECTED]>
* URL or Web page : http://common-lisp.net/project/bese/qbook.html
* License : BSD
  Description : create HTML/LaTeX versions of Common Lisp source code

 qbook is a Common Lisp tool to create HTML/LaTeX versions of
 source code.
 .
 Features:
  * Very simple (easy to learn and use).
  * It can produce HTML or LaTeX.

=

Continuation of the series of CL software started with bug #337646.

As soon as this bug will get a number by the BTS, I'll add the package
to the CL-Debian repository [1]. The package is linda and lintian
free and it follows the "Common Lisp in Debian Manual" [2].

Thx, bye,
Gismo / Luca

[1] http://cl-debian.alioth.debian.org/cgi-bin/darcsweb.cgi
[2] http://cl-debian.alioth.debian.org/clid/clid.html/


pgpQSiwLB9YMT.pgp
Description: PGP signature

Re: Standard to indicate repacking in version numbers?

[Luca Capello]

Hi all!

On Mon, 28 Jan 2008 21:22:43 +0100, Russ Allbery wrote:
> Bill Allombert <[EMAIL PROTECTED]> writes:
>> On Mon, Jan 28, 2008 at 10:13:51AM -0800, Russ Allbery wrote:
>>> We went back and forth on this several times on debian-mentors and I
>>> think everyone finally agreed that debian/copyright is the correct
>>> place to explain any repackaging of the upstream source.  Since
>>> debian/copyright is the standard place to explain where the upstream
>>> source came from, it's the logical place for that information to go.
>>> Please let's not add a new documentation file that isn't automatically
>>> collected by the PTS, packages.d.o, etc.
>>
>> Personnally I put it in debian/README.sources with instruction on how
>> to generate the tarball from the upstream one.
>>
>> debian/README.sources is mentionned in another policy proposal.
>
> Which I am similarly opposed to.  I think Policy 12.5 is reasonably clear
> here:
>
> In addition, the copyright file must say where the upstream sources
> (if any) were obtained.
>
> To me at least, that includes information about how a custom pack of the
> upstream sources is generated, if that's necessary.

I think there's a problem here, according to the facts below...


- debian-policy_3.7.3.0, § 12.5, reported above by Russ, doesn't sound
  so clear to me (but I'm not an English native speaker).

  Let's say that I grab foo from foo.alioth.d.o, then I remove some
  non-DFSG-free material and I repackage the orig.tar.gz: the upstream
  sources are still obtained from foo.alioth.d.o.


- developers-reference_3.3.8 (11 November, 2006, the version available
  on sid...), § 6.7.8.2:

A repackaged .orig.tar.gz

1. must contain detailed information how the repackaged source was
   obtained, and how this can be reproduced, in README.Debian-source
   or a similar file.


- developers-reference_3.3.9 (04 August, 2007, available *only* on
  www.d.o), § 6.7.8.2:

A repackaged .orig.tar.gz

1. must contain detailed information how the repackaged source was
   obtained, and how this can be reproduced in the debian/copyright.


- on 04 December, 2007, I asked on #debian-devel about where I should
  have explained how I repackaged thinkinger and the answer was duplex:
  debian/copyright if the explanation was simple or debian/README.Source
  if more complex (which I chose, since I prefer to be more verbose)


Thx, bye,
Gismo / Luca


pgpyngW1p997I.pgp
Description: PGP signature

Re: Bug#465660: ITP: extreme-tuxracer -- Arcade game featuring tux the penguin, snow ice and fishes

[Luca Brivio]

Alle 11:34, gio 14 febbraio 2008, Alexander Schmehl ha scritto:
> * Christian Perrier <[EMAIL PROTECTED]> [080214 06:54]:
> > >   Description : Arcade game featuring tux the penguin, snow ice and
> > > fishes
> >
> > At least uncapitalize "Arcade".
>
> "At least"?  You have further improvements?  Sounds "3D racing game
> featuring Tux, the Linux penguin" better for you?

Maybe e.g. "make Tux the penguin slide down mountains and collect fishes"?
(Tags: game::arcade, interface::3d, and perhaps game::sport:racing should 
apply, among others.)

-- 
Luca


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

(user)tagging wnpp bugs

[Luca Brivio]

Hello folks,
following a short discussion with Erich Schubert on the debtags-devel list[1], 
I decided to come with a simple proposal (are DEPs already active and 
useful?).

In order to have wnpp bugs better categorized (and, as such, searched, shown, 
and managed), it seems a viable option to use (abuse?) faceted usertags, like 
somebody from the Debian Science subproject already does[2][3]. These tags 
could be collected using wiki pages, and should IMHO mostly match debtags' 
ones (that would enable using them when entering debtags).

Of course, using just one ‘login’ for categorizing wnpp tags looks way more 
useful than having several teams each using a different one.

Any comments? What ‘user’ should we use?

If nothing against comes up, I'm going to use such usertags as 
<[EMAIL PROTECTED]> and report (lots of) RFPs (and possibly some ITP!) for 
fields I am interested in.

[1] 
http://lists.alioth.debian.org/pipermail/debtags-devel/2008-February/001764.html
[2] http://wiki.debian.org/DebianScience/Usertags
[3] 
http://bugs.debian.org/cgi-bin/[EMAIL PROTECTED]

Cheers,
-- 
Luca

Re: (user)tagging wnpp bugs

[Luca Brivio]

Thank you for your feedback...

Alle 21:41, sab 1 marzo 2008, Don Armstrong ha scritto:
> > If nothing against comes up, I'm going to use such usertags as
> > <[EMAIL PROTECTED]> and report (lots of) RFPs (and possibly some ITP!)
> > for fields I am interested in.
>
> I'd suggest just picking a reasonable subset of the tags

I shall see, didn't even quickly screened for applicable tags, anyway I guess 
they will be a subset of debtags + a few wnpp-specific tags. We haven't yet 
created a wiki page.

> and using the [EMAIL PROTECTED] user so the tags are visible by 
> default. 

I wasn't aware of this. It's fine to me.

> [Well, after testing using your own user, of course.]

or maybe using [EMAIL PROTECTED] again. ;-)

Cheers,
-- 
Luca


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

Re: mass ITPs

[Luca Brivio]

Alle 19:48, sab 1 marzo 2008, Christian Perrier ha scritto:
> If someone cares to listen: when you think about ITPing each and every
> piece of FLOSS that pops around: think about *helping* people who
> maintain existing packages instead of adding even more noise to our
> noisy bunch of various crap^W software.

Just some thoughts:
- ITPing doesn't of course mean being packaging. One can have low priority on 
an ITP, and even when, once started, one finds that software isn't worth it, 
she can decide not to package it anymore...
- Helping with packages almost always requires more skills than packaging 
simple new ones, which OTOH is good for learning.
- Yeah, at least one should package use- and featureful stuff! Anyway I don't 
see *that* much ITPs for actually “unuseful” software, relative to how much 
software enters Debian...
- There's no big evidence about where exactly help is needed!

-- 
Luca

Re: actively notifying users of removed packages

[Luca Brivio]

Alle 14:57, mar 11 marzo 2008, Andreas Bombe ha scritto:
> It's no active notification, but aptitude lists all installed packages
> that aren't in any distribution included in sources.list under "Obsolete
> and Locally Created Packages".  Verifying that this doesn't include any
> packages that I expect there (like locally compiled kernel module
> packages) is my way of checking for removed packages.

aptitude should perhaps list packages that became (that is, are and weren't 
before) obsolete (= not being in any archive? removed?) every time actions 
are performed through its CLI? Seems like an efficient way...

-- 
Luca


signature.asc
Description: This is a digitally signed message part.