Re: Debian should not modify the kernels!

[Sebastian]

I have been following the discussion and just want to add some things
from a user's point of view:

1.
I appreciate the additional functionality and included bug fixes of the
Debian kernels, but in the end I often have to use the vanilla kernel,
because most patches - like grsecurity - don't apply otherwise.

2.
In the past, there was a problem with security fixes regarding the linux
kernel and stable distribution (woody). Only recently the security team
started to backport security fixes for the kernel versions included in
stable. Additionally, for most modern hardware a more recent kernel
release is needed. Thus I need to fetch newer kernel releases from
unstable or from kernel.org (and hope that they will work with woody),
and I have to look for security issues by myself.

Thus, while I really like the "stability" of woody, I frequently need
kernel updates. This means that the kernel packages don't really fit
into Debian's concept of "stable" and "unstable".


As a user, I really would prefer a second set of current kernel-sources
and kernel-images that can be used to update a woody system and that
promises the same level of stability as woody does in general. These
kernels should thus be tested with woody and only include the vanilla
kernels plus important bugfixes, but no additional features.

Sebastian

Bug#645189: ITP: qasconfig -- ALSA configuration browser

[Sebastian]

Package: wnpp
Severity: wishlist
Owner: Sebastian 

Dear Maintainer,

* Package name: qasconfig
  Version : 0.2.0
  Upstream Author : Sebastian Holtermann 
* URL : http://xwmw.org/qasconfig
* License : GPL-3
  Programming Lang: C++
  Description : ALSA configuration browser

The configuration of the linux sound system ALSA 
resides in a tree structure which is built by reading several 
configuration files like /etc/asound.conf and ~/.asoundrc.
QasConfig is a simple browser for this configuration tree
and can help to analyze and debug an ALSA setup.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111013114436.17785.18061.reportbug@blauwal

Bug#647448: ITP: qasmixer-l10n -- Localization package for QasMixer

[Sebastian]

Package: wnpp
Severity: wishlist
Owner: Sebastian 

* Package name: qasmixer-l10n
  Version : 0.15.0
  Upstream Author : Sebastian Holtermann 
* URL : http://xwmw.org/qasmixer
* License : GPL-3
  Programming Lang: C++
  Description : Localization package for QasMixer

QasMixer is a volume mixer application for the Linux sound 
architecture ALSA.

This is the localization(l10n) package for QasMixer.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2002194852.27352.58759.reportbug@blauwal

Bug#647450: ITP: qasconfig-l10n -- Localization package for QasConfig

[Sebastian]

Package: wnpp
Severity: wishlist
Owner: Sebastian 

* Package name: qasconfig-l10n
  Version : 0.3.0
  Upstream Author : Sebastian Holtermann 
* URL : http://xwmw.org/qasconfig
* License : GPL-3
  Programming Lang: C++
  Description : Localization package for QasConfig

The configuration of the Linux sound system ALSA 
resides in a tree structure which is built by reading several 
configuration files like /etc/asound.conf and ~/.asoundrc.
QasConfig is a simple browser for this configuration tree
and can help to analyze and debug an ALSA setup.

This is the localization(l10n) package for QasConfig.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2002200137.27576.48892.reportbug@blauwal

Bug#651943: ITP: qastools -- collection of desktop tools for ALSA

[Sebastian]

Package: wnpp
Severity: wishlist
Owner: Sebastian H. 

* Package name: qastools
  Version : 0.16.0
  Upstream Author : Sebastian Holtermann 
* URL : http://xwmw.org/qastools
* License : GPL-3
  Programming Lang: C++
  Description : collection of desktop tools for ALSA

 QasTool is a collection of desktop tools for the 
 Linux sound system ALSA.
 .
 The tools included are:
  - QasConfig - browser for the ALSA configuration tree
  - QasHctl - mixer for ALSA's High level Control Interface
  - QasMixer - simple mixer with features similar to alsamixer

 QasTools replaces the separate QasMixer and QasConfig packages
 for easier maintenance.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111213134827.3288.87940.reportbug@blauwal

Re: autoconf 2.72 to unstable?

[Sebastian Ramacher]

Hi

On 2024-06-13 15:25:04 +0200, Gürkan Myczko wrote:
> is the t64 transition over?

It is.

> here's the test results http://qa-logs.debian.net/2024/03/20/

I only randomly checked some of the packages, but didn't find any bug
reports based on these results. Please report them.

Cheers
-- 
Sebastian Ramacher

Bug#1074072: ITP: python-libpulse -- asyncio interface to the Pulseaudio and Pipewire pulse library

[Sebastian Ramacher]

Package: wnpp
Severity: wishlist
Owner: Sebastian Ramacher 
X-Debbugs-Cc: debian-devel@lists.debian.org, sramac...@debian.org

* Package name: python-libpulse
  Version : 0.2
  Upstream Contact: Xavier de Gaye
* URL : https://gitlab.com/xdegaye/libpulse
* License : MIT
  Programming Lang: Python
  Description : asyncio interface to the Pulseaudio and Pipewire pulse 
library

libpulse is a Python project based on asyncio, that uses ctypes to
interface with the pulse library of the PulseAudio and PipeWire sound
servers. The interface is meant to be complete. That is, all the
constants, structures, plain functions and async functions are made
available by importing the libpulse module of the libpulse package.


Cheers
-- 
Sebastian Ramacher

Bug#1074075: ITP: pa-dlna -- pa-dlna forwards audio streams to DLNA devices

[Sebastian Ramacher]

Package: wnpp
Severity: wishlist
Owner: Sebastian Ramacher 
X-Debbugs-Cc: debian-devel@lists.debian.org, sramac...@debian.org

* Package name: pa-dlna
  Version : 0.11
  Upstream Contact: Xavier de Gaye
* URL : https://gitlab.com/xdegaye/pa-dlna
* License : MIT
  Programming Lang: Python
  Description : pa-dlna forwards audio streams to DLNA devices

A Python project based on asyncio, that uses ctypes to interface with
the libpulse library and supports the PulseAudio and PipeWire sound
servers.

pa-dlna is composed of the following components:

* The pa-dlna program forwards PulseAudio streams to DLNA devices.
* The upnp-cmd is an interactive command line tool for introspection and 
control of UPnP devices.
* The UPnP Python sub-package is used by both commands.


Cheers
-- 
Sebastian Ramacher

Re: Bug#278075: ITP: libical0 -- An implementation of basic iCal protocols

[Sebastian Ley]

* Ricardo Mones wrote:

> * Package name: libical0

Are you aware that libical is currently pretty unmaintained upstream and has a 
lot of nasty bugs? In fact all projects who needed an ical parser (e.g. KDE 
PIM, evolution, OpenGroupware.org...) all dropped libical, forked it or wrote 
something new from scratch.

Libical has been in Debian until some months ago, when it was removed from 
unstable due to buggyness and unmaintaindness.

Regards,
Sebastian

-- 
PGP-Key: http://www.mmweg.rwth-aachen.de/~sebastian.ley/public.key
Fingerprint: A46A 753F AEDC 2C01 BE6E  F6DB 97E0 3309 9FD6 E3E6

Re: Bug#278255: ITP: rdflib -- A python library for working with RDF

[Sebastian Ley]

* Alberto Rodriguez Galdo wrote:

> * Package name: rdflib
>   Description : A python library for working with RDF

Please consider naming the package according to the python policy, prefixing 
it with "python-".

Regards,
Sebastian

-- 
PGP-Key: http://www.mmweg.rwth-aachen.de/~sebastian.ley/public.key
Fingerprint: A46A 753F AEDC 2C01 BE6E  F6DB 97E0 3309 9FD6 E3E6

Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor

[Sebastian Ley]

* Jonas Meurer wrote:

> can you give further information about this 'Godwin law'?

http://en.wikipedia.org/wiki/Godwins_law

Sebastian

-- 
PGP-Key: http://www.mmweg.rwth-aachen.de/~sebastian.ley/public.key
Fingerprint: A46A 753F AEDC 2C01 BE6E  F6DB 97E0 3309 9FD6 E3E6

Re: Duelling banjos or how a sane community goes crazy

[Sebastian Ley]

* Andreas Tille wrote:

> This stupid thread made its way even in a German Linux news feed ...
>
>http://www.pro-linux.de/news/2004/7569.html

...and on the frontmatter of this week's LWN issue...

> even if you do not understand German: I would love if Debian would
> become famous for releasing Sarge instead of discussing about
> hot-babes.

Amen.

Sebastian

-- 
PGP-Key: http://www.mmweg.rwth-aachen.de/~sebastian.ley/public.key
Fingerprint: A46A 753F AEDC 2C01 BE6E  F6DB 97E0 3309 9FD6 E3E6

Re: Always run dpkg --dry-run -i before running dpkg -i!

[Sebastian Ley]

* William Ballard wrote:

[...crap...]

Do you need the -utils apckage to build the -source package? No. So no Depends 
and no Recommends for you. Period. Depends and Recommends have a certain 
well-defined meaning and I am greatful that we are not arbitarily misusing 
them.

The resulting -modules package has a depends on the -utils package, which is 
everything that is needed.

Sebastian

-- 
PGP-Key: http://www.mmweg.rwth-aachen.de/~sebastian.ley/public.key
Fingerprint: A46A 753F AEDC 2C01 BE6E  F6DB 97E0 3309 9FD6 E3E6

Re: Always run dpkg --dry-run -i before running dpkg -i!

[Sebastian Ley]

* Adam Heath wrote:

> It *may* require a versioned depends on a newer version, but that's just a
> normal bug.

...and no reason to introduce this dependency in the -source package.

Btw: Leaving old packages build from -source packages around would quite well 
do the trick. But I suppose W.B. wants to call more people assholes before 
invoking brain functions...

*sigh*

Sebastian
-- 
PGP-Key: http://www.mmweg.rwth-aachen.de/~sebastian.ley/public.key
Fingerprint: A46A 753F AEDC 2C01 BE6E  F6DB 97E0 3309 9FD6 E3E6

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

[Sebastian Ley]

* Steve Langasek wrote:

> The much larger consequence of this meeting, however, has been the
> crafting of a prospective release plan for etch.

Thanks to the team for your work on that. I support the direction of the 
proposal itself (modulo minor issues) and I hope that Debian reckognizes that 
it is not a shame if such things are worked out in a small team. 

It is plainly impossible to work out such a plan in a reasonable time when 
each and every of our thousand developers wants a say in it. I happily 
delegate my voice to a small team for quick and high quality decisions.

While I believe that Debians distributed packaging model with the packagers 
being the more or less ultimate authority over decisions regarding the 
package, I like to see a more structured approach when it comes to making 
overall decisions.

Regards,
Sebastian
-- 
PGP-Key: http://www.mmweg.rwth-aachen.de/~sebastian.ley/public.key
Fingerprint: A46A 753F AEDC 2C01 BE6E  F6DB 97E0 3309 9FD6 E3E6


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

Here are lions

[Sebastian Tennant]

Hi all, happy new year and all that.

Just rolled my own 2.6.12 on a 700 MHz Pentium III, with everything I
need built-in, and very little that I don't.  Boot time from button
press to text console, via a grub default confirm, 72 secs :-)

So now that I'm up to speed, I'm trying to grok the
d-bus/udev/hald/gvm conspiracy, which is fantastic by the way.  Gnome
is damn close to achieving it's stated aim in recent months, namely;
"hardware that just works".

Anyhow, I just came across this file; /etc/udev/links.conf

  # This file does not exist. Please do not ask the debian maintainer about it.
  # You may use it to do strange and wonderful things, at your risk.

  L fd  /proc/self/fd
  L stdin   /proc/self/fd/0
  L stdout  /proc/self/fd/1
  L stderr  /proc/self/fd/2
  L core/proc/kcore
  L sndstat /proc/asound/oss/sndstat
  L MAKEDEV /sbin/MAKEDEV

  D pts
  D shm

  M nullc   1 3
  M console c   5 1

  # Hic sunt leones.
  M ppp c 108 0
  D loop
  M loop/0  b   7 0
  D net
  M net/tun c  10 200

Is this someone's idea of a joke, because it's very funny indeed :-)

I've no idea what it does, but I never thought the Latin we had to
learn at school would ever have a use.  How wrong I was!

On a more serious note, the aforementioned hardware conspiracy is
actually working a little _too_ well for me at the moment.  I have an
external firewire drive with several partitions on it, only one of
which I need on a daily basis.  As soon as I switch it on gvm mounts
all (five) partitions.  Is there any way I can prevent gvm from
mounting four of them?

sdt


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

Re: [Listmaster] Seeking petsupermarket

[Sebastian Tennant]

Cord Beermann <[EMAIL PROTECTED]> wrote:

> Hallo! Du (Linas Zvirblis) hast geschrieben:
>
>>>BTW, Who da hell is some AntiSpam UOL? Everytime that I send an email to
>>>debian-devel that stupid machine sends me an email. Is there a way to 
>>>block?
>>
>>Yes, the [EMAIL PROTECTED] is back. You will just have to 
>>block this address on your side until listmaster takes care of this.
>
> You might have seen the probes we send out in the last year.
>
> Sadly it didn't work out as hoped, so i (and ${all_subscribers}-1 here)
> would be thankful if anyone can provide more information about 
> petsupermarket (you don't have to point out the website, i already
> tried to contact all address i could find there).
>
> Someone who is subscribed to d-devel forwards the mails to
> petsupermarket. petsupermarket itself is not subscribed to any of our
> mailinglists.
>
> If you have seen those c-r-responses outside of the debian-lists, or
> in the last days on other lists than debian-devel, then this
> information is maybe helpful to identify the address.
>
> We already put many hours in trying to identify this annoying member,
> and this really sucks, as this time is lost for other activities or
> enhancements we could do inside or outside of the Project.

Could they be coming through gmane somehow?  I received one a few
hours ago when I posted an article on gmane.comp.debian.general (which should 
have gone
on g.c.d.user - Here are Lions), but now I've just recieved one having
sent *mail* to the fetchmail-friends mailing list, which I'm reading as a
newsgroup on gmane...

gawd knows...

sdt


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

Re: Bug#352303: ITP: gsynaptics -- configuration tool for Synaptics touchpad driver of X

[Sebastian Ley]

* Christian Perrier wrote:

> Let's nitpick a little: 

Well, especially when nitpicking, you should be sure of what you are 
writing ;-)

> This allow for modifications of the driver

s/allow/allows/

Regards,
Sebastian

-- 
PGP-Key: http://www.withouthat.org/~sebastian/public.key
Fingerprint: A46A 753F AEDC 2C01 BE6E  F6DB 97E0 3309 9FD6 E3E6

Re: Required firewall support

[Sebastian Ley]

* Wouter Verhelst wrote:

> Note that some packages, directly or indirectly, build-depend on
> packages containing daemons that will be started by default if
> installed. In that light, a firewall really is required to keep things
> safe.

IMO most notably, because many users will hit that:
KDE -> famd -> portmapper

While I would not judge on portmappers security, it is certainly not a service 
which most users need to have exposed to the internet, and so it shouldn't be 
by default.

Of course, the proper solution would be to a) do not make fam depend on 
portmapper or b) alter portmapper to listen for local connections only, 
neither of both has been implemented for some time now...

Sebastian

-- 
PGP-Key: http://www.mmweg.rwth-aachen.de/~sebastian.ley/public.key
Fingerprint: A46A 753F AEDC 2C01 BE6E  F6DB 97E0 3309 9FD6 E3E6


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

Re: Detecting the installed MTA

[Sebastian Ley]

* Søren Boll Overgaard wrote:

> During packaging, that is, during the installation of a package, I need to
> determine which MTA is currently installed, since I need to set certain
> permissions specific to my package, so that they match with those of the
> currently running MTA.

Might be hackish, but seems to work:

dpkg -S /usr/sbin/sendmail | awk -F ':' '{print $1}'

Regards,
Sebastian

-- 
PGP-Key: http://www.withouthat.org/~sebastian/public.key
Fingerprint: A46A 753F AEDC 2C01 BE6E  F6DB 97E0 3309 9FD6 E3E6

Re: problem creating pbuilder environment

[Sebastian Kuzminsky]

Andreas Fester <[EMAIL PROTECTED]> wrote:
] # pbuilder create --mirror http://ftp.de.debian.org/debian


I had the same error when making a pbuilder Sid environment, but Sarge
works for me.  Add "--distribution sarge" to that command line.




--
Sebastian


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

debian package of cogito-0.9 available

[Sebastian Kuzminsky]

Hi folks, I'm a wanna-be new maintainer.  With the helpful guidance
of Anibal, I've been working on a Debian package of Cogito.  Cogito is
Pasky's distributed revision control system on top of Linus Torvalds'
GIT directory tracker.


I know there's an ITP for Cogito (#304602), I've tried to contact the
people involved but I have not heard back from them yet.  I hope I'm
not stepping on anyone's toes here!


I think the package is ready for a wider audience.  I just updated it
to the just-released upstream version 0.9, it's available here:

http://highlab.com/~seb/debian


It's lintian & linda clean, _except_ for missing manpages.  There are
no manpages in the upstream, I'll be working to write them over the next
week or two and I'll offer them to the upstream maintainer.


What do you think?




--
Sebastian


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

Re: debian package of cogito-0.9 available

[Sebastian Kuzminsky]

Martin Waitz <[EMAIL PROTECTED]> wrote:
] On Sat, May 07, 2005 at 09:42:39PM -0600, Sebastian Kuzminsky wrote:
] > I think the package is ready for a wider audience.  I just updated it
] > to the just-released upstream version 0.9, it's available here:
] 
] why do you patch the Makefile?
] does 'make prefix=3D/usr' not work?


Sure that works.  Is it prefered to do that over patching the upstream?
I guess it's more maintainable...  Ok, I'll do it that way instead.




--
Sebastian


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

cogito_0.10-1 available

[Sebastian Kuzminsky]

Get it here:

http://highlab.com/~seb/debian


Before 0.10, the upstream installed both the binaries (actually shell
scripts) and the shell libraries in /usr/bin.  Starting with 0.10, the
shell libraries are moved to /usr/lib/cogito.  This seems to me like a
fine thing to do, any reason Debian doesnt want them there?


The only lintian/linda complaints are from missing manpages.  Some
upstream folks are working on translating the existing docs from .txt
to manpages (actually asciidoc), so it'll hopefully get cleaner soon
without me lifting a finger.  :)




--
Sebastian


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

Re: cogito_0.10-1 available

[Sebastian Kuzminsky]

Peter Samuelson <[EMAIL PROTECTED]> wrote:
] [Sebastian Kuzminsky]
] > Before 0.10, the upstream installed both the binaries (actually shell
] > scripts) and the shell libraries in /usr/bin.  Starting with 0.10,
] > the shell libraries are moved to /usr/lib/cogito.
] 
] Correct, except that it should be /usr/share/cogito/.


The FHS describes /usr/share as "architecture-independent data", and gives
examples like sound files and icons; this conflicts with executable code
in my mind.


However, packages like quilt and lintian put a bunch of executable code
there (internal scripts and script libraries).


Putting the internal scripts and shell libraries in /usr/lib/cogito
would mirror packages like base-config and pbuilder.


Seems like a somewhat fuzzy distinction to me.  I'll be happy to move
it to /usr/share if that's The Thing To Do(tm).




--
Sebastian


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

Re: cogito_0.10-1 available

[Sebastian Kuzminsky]

Ben Finney <[EMAIL PROTECTED]> wrote:
] It could be better described, yes. My understanding of /usr/share as
] "architecture-independent" (and read-only, as the description
] continues) is that /usr/share/can potentially be mounted read-only
] for multiple machines of different architectures.


Ok, I can deal with that.  Thanks for the explanation.


I'll move the Cogito shell fragments from /usr/lib/cogito to
/usr/share/cogito.  There is talk (of course) of reimplementing Cogito,
possibly in C -- if that happens I'll put the C libraries and binary
helper programs back in /usr/lib/cogito.  


I'll put up cogito_0.10-2 later today with this fix.




--
Sebastian


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

cogito_0.10-2 available, and request for Sponsor

[Sebastian Kuzminsky]

cogito_0.10-2 is up, it now puts the internal scripts and the shell
library in /usr/share/cogito instead of /usr/lib/cogito.  Thanks to Ben
Finney and Peter Samuelson for cluing me in.


You can get the package here:

http://highlab.com/~seb/debian


The only problem I know of with the package now is the missing manpages.
The upstream people are working feverishly on this, so I want to wait
a week or so and see what they come up with.


I'm a wanna-be new maintainer starting out the New Maintainer process.
I'm looking for a Debian Sponsor to upload this package to the archive.
I'm also looking to have my GPG key signed (I live in Colorado, USA),
and for an Advocate.




--
Sebastian


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

Re: cogito_0.10-2 available, and request for Sponsor

[Sebastian Kuzminsky]

Anibal Monsalve Salazar <[EMAIL PROTECTED]> wrote:
] On Tue, May 10, 2005 at 11:22:17AM -0600, Sebastian Kuzminsky wrote:
] >I'm also looking to have my GPG key signed (I live in Colorado, USA),
] >and for an Advocate.
] 
] What city in Colorado. Maybe there is a DD in the same city as yours.
] You really need a DD to sign your gpg key to start the NM process.


I'm in Boulder.  Anyone nearby?




--
Sebastian


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

Re: cogito_0.10-2 available, and request for Sponsor

[Sebastian Kuzminsky]

Anibal Monsalve Salazar <[EMAIL PROTECTED]> wrote:
] On Tue, May 10, 2005 at 11:22:17AM -0600, Sebastian Kuzminsky wrote:
] >I'm looking for a Debian Sponsor to upload this package to the archive.
] 
] I'll upload it. However, we'll have to wait until the license issue
] raised by Florian Weimer is resolved. If the package is uploaded is
] very likely to be rejected by the ftpmaster team.


Thanks for offering to upload the package!


What license issue do you mean?  The fact that it's "GPLv2 exactly,
unless Linus wants a later GPL"?  I'm not lawyerly enough to see why
that's a problem.




--
Sebastian


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

Re: cogito_0.10-2 available, and request for Sponsor

[Sebastian Kuzminsky]

Anibal Monsalve Salazar <[EMAIL PROTECTED]> wrote:
] On Tue, May 10, 2005 at 08:57:56PM +0200, Florian Weimer wrote:
] >The package is GPLed, but depends on OpenSSL, whose license is not
] >GPL-compatible.  Please ask upstream for a linking exception, or use
] >some other SHA-1 implementation.


Ah, that.  Thanks.




--
Sebastian


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

updated cogito package - now with docs!

[Sebastian Kuzminsky]

The upstream now includes docs for the GIT core, though still not for
Cogito.  The docs are available in .txt and .html, and they _would_
be available as manpages except for a bug in asciidoc.  The asciidoc
maintainer has been offered a patch.


You can grab the new cogito package here:

http://highlab.com/~seb/debian


You can look at the docs here (or in /usr/share/doc/cogito if you install
the package):

http://highlab.com/~seb/git-docs/git.html




--
Sebastian


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

Re: updated cogito package - now with docs!

[Sebastian Kuzminsky]

Andres Salomon <[EMAIL PROTECTED]> wrote:
> On Wed, 11 May 2005 14:05:28 -0600, Sebastian Kuzminsky wrote:
> > You can grab the new cogito package here:
> >
> > http://highlab.com/~seb/debian
> 
> FYI, you can make the packages and source apt-get'able w/ a script like
> http://www.acm.rpi.edu/~dilinger/libmusicbrainz-ruby/mkarchive.sh


Cool. 


Ok all you crazy gits, add this to your sources.list and get apt-getting:

# Seb's Cogito packages
deb http://highlab.com/~seb/debian /
deb-src http://highlab.com/~seb/debian /


Only i386 binary packages for now, get the sources if you want to
try compiling it on your architecture (and send me bugreports when
it breaks!).




--
Sebastian


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

new cogito package, OpenSSL license issue resolved

[Sebastian Kuzminsky]

I've updated the Cogito package to compile against the upstream-included
GPL SHA1 implementation lifted from Mozilla, instead of the (possibly)
GPL-incompatible OpenSSL code.  Thanks to Florian Weimer and Anibal
Monsalve Salazar for bringing this issue to my attention.  I have a
terrible head for this kind of legal stuff, "can't we all just get
the code?"


This is the last issue I know of keeping this package out of the Debian
archives.  Yay!  There's still the manpage issue, but I expect it will
be resolved upstream in the next few days.


The latest version (0.10+20050513-2) can be downloaded from here:

http://highlab.com/~seb/debian


Or apt-getted from here:

# Seb's packages from highlab.com
deb http://highlab.com/~seb/debian /
deb-src http://highlab.com/~seb/debian /




--
Sebastian


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

Re: new cogito package, OpenSSL license issue resolved

[Sebastian Kuzminsky]

Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> On Fri, May 13, 2005 at 11:44:05PM -0600, Sebastian Kuzminsky wrote:
> > I've updated the Cogito package to compile against the upstream-included
> > GPL SHA1 implementation lifted from Mozilla, instead of the (possibly)
> > GPL-incompatible OpenSSL code.  Thanks to Florian Weimer and Anibal
> > Monsalve Salazar for bringing this issue to my attention.  I have a
> > terrible head for this kind of legal stuff, "can't we all just get
> > the code?"
> > 
> > 
> > This is the last issue I know of keeping this package out of the Debian
> > archives.  Yay!  There's still the manpage issue, but I expect it will
> > be resolved upstream in the next few days.
> 
> Any chance you can make the package use the included assemly sha1
> implementation on powerpc?  It's a notable difference and with that
> change I could switch from self-compiled cognito to the package.


I've updated my Cogito source package (0.10+20050513-3) to use the
ppc-sha1 on powerpc, but I dont have a powerpc machine to compile on,
so I haven't tested it.  It still uses mozilla-sha1 on all the other
architectures.


Please pull the sources via http or apt and let me know if it works!


http://highlab.com/~seb/debian

-or-

# Seb's packages from highlab.com
deb http://highlab.com/~seb/debian /
deb-src http://highlab.com/~seb/debian /




--
Sebastian


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

Re: updated cogito package - now with docs!

[Sebastian Kuzminsky]

Adrian von Bidder <[EMAIL PROTECTED]> wrote:
> Sebastian, can I humbly request that you don't announce cogito package
> updates on (at least the -devel) mailing list?


Yeah that was a little excessive, sorry.  I'm a noob and I got excited,
I'll pipe down.  :-}




-- 
Sebastian Kuzminsky


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

Re: new cogito package, OpenSSL license issue resolved

[Sebastian Kuzminsky]

Andres Salomon <[EMAIL PROTECTED]> wrote:
> For people trying this out, Zach Brown wrote some excellent
> documentation [1].  It would be nice to see this end up in the debian
> packages.


I'm hoping the upstream maintainer (Pasky) will pick up that patch.
If he doesnt in the next several days, I'll consider adding Zack Brown's
updated README alongside the official upstream README.




> If you need a sponsor for this, let me know; I'd like to see it in
> debian sooner rather than later.


I appreciate the offer, but it's already in Sid!  Anibal Monsalve Salazar
is sponsoring it.


Sid currently has version 0.10+20050513-2, but there's a newer version
in the queue (0.10+20050515-2).




-- 
Sebastian Kuzminsky

"Marie will know I'm headed south, so's to meet me by and by"
Townes Van Zandt


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

namespace conflict != package Conflict?

[Sebastian Kuzminsky]

Hi folks, I have a noob question for you.  I maintain the Cogito package
(my first), and it wants to install an executable as /usr/bin/git.  The
GNU Interactive Tools package (git) also wants to install an executable
as /usr/bin/git.  To avoid this conflict I made cogito Conflict with git.

I have been told by Jurij Smakov that this is "seriously wrong", and
I'm asking for help here.  What's the proper way to handle this situation?

The cogito /usr/bin/git is a tiny little helper script hardly worth its
inode, but it's in the upstream package and I dont want to remove it or
rename it.


-- 
Sebastian Kuzminsky


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

Re: namespace conflict != package Conflict?

[Sebastian Kuzminsky]

[EMAIL PROTECTED] (Aaron M. Ucko) wrote:
> > The cogito /usr/bin/git is a tiny little helper script hardly worth its
> > inode, but it's in the upstream package and I dont want to remove it or
> > rename it.
> 
> As others have asked, why not?  Does anything actually rely on the
> script existing by that name?

I believe the nature of cogito's "git" command is such that renaming it
would make less sense than removing it.  And just removing it from the
upstream package seems pretty lame, but maybe that's the thing to do.

cogito currently includes & extends an upstream package called 'git'
(they may split in the future, let's hope they rename git-as-in-cogito
before then).  Cogito's git includes many commands with names of
the form "git-$FUNCTION-script", with the idea that it's easier to
command-line-complete them if the $FUNCTION is part of the command-name
(as opposed to "svn commit", etc).  The loyal opposition was placated
with the "git" command, which runs "git-$1-script" with the remaining
arguments.

Renaming git to something longer & more complicated seems to contradict
this goal; users would be better off calling the original commands that
git wraps.


That was my thinking.


Aaron Ucko's suggestion of trying to tell, from the command-line
arguments, wether the user wants git-from-cogito or git-from-git seems
incredibly brittle.  git-from-git can take a directory as the first
argument, so if you try to use git-from-git to look at a directory with
a name like "log" or "tag", it'll run git-from-cogito instead (because
git-log-script and git-tag-script exist).


Hm, given that git-from-cogito seems to have a fatal flaw (it doesnt
shift the script name out of the arguments list), I'm guessing it's
not widely used.  I'll request that the upstream people remove it from
the distribution.

If they agree, the issue will be solved I think.  (cogito wants to install
a git(7) manpage, which will not conflict with GNU Interactive Tools'
git(1) page.)

If they dont agree (and they're a cantankerous bunch, hi to all my
friends on the git list) we'll have to come up with something else...


-- 
Sebastian Kuzminsky


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

Re: namespace conflict != package Conflict?

[Sebastian Kuzminsky]

Sebastian Kuzminsky <[EMAIL PROTECTED]> wrote:
> Hm, given that git-from-cogito seems to have a fatal flaw (it doesnt
> shift the script name out of the arguments list), I'm guessing it's
> not widely used.  I'll request that the upstream people remove it from
> the distribution.

Oops, my fingers are faster than my brain.  The git script now shifts
out the first argument, as it ought.  But I still think they should just
remove it.


-- 
Sebastian Kuzminsky


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

cogito no longer conflicts with git or cgvg

[Sebastian Kuzminsky]

The new cogito package (0.11.3+20050610-1) is on its way into sid.
It does not install /usr/bin/git or /usr/bin/cg, and so it does not
conflict with git or with cgvg.

I made a note about this in /usr/share/doc/cogito/README.Debian, and I
updated the git docs to remove all the mentions of those programs.

I guess I just prefer getting flamed by the git/cogito people rather
than the Debian people.  :-/


-- 
Sebastian Kuzminsky


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

Re: namespace conflict != package Conflict?

[Sebastian Kuzminsky]

Kevin Mark <[EMAIL PROTECTED]> wrote:
> On Thu, Jun 09, 2005 at 07:50:58PM -0600, Sebastian Kuzminsky wrote:
> > Hi folks, I have a noob question for you.  I maintain the Cogito package
> > (my first), and it wants to install an executable as /usr/bin/git.  The
> > GNU Interactive Tools package (git) also wants to install an executable
> > as /usr/bin/git.  To avoid this conflict I made cogito Conflict with git.
>
> if its not a user-executed script, doesn't it go in /usr/lib?

It _is_ designed to be run by humans though, so it needs to go in
/usr/bin.


-- 
Sebastian Kuzminsky


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

Re: namespace conflict != package Conflict?

[Sebastian Kuzminsky]

Adam Majer <[EMAIL PROTECTED]> wrote:
> Sebastian Kuzminsky wrote:
> >Hi folks, I have a noob question for you.  I maintain the Cogito package
> >(my first), and it wants to install an executable as /usr/bin/git.  The
> >GNU Interactive Tools package (git) also wants to install an executable
> >as /usr/bin/git.  To avoid this conflict I made cogito Conflict with git.
> >
> >  
> >
> Of course this is *seriously* wrong. Why are you preventing people from
> using git and cogito together?

As I see it, it's not _me_ preventing them from being used together,
it's Linus Torvalds, the upstream developer of git-as-in-cogito, who
chose a conflicting name for his project.  The problem has been pointed
out to him and he doesnt care:

http://marc.theaimsgroup.com/?l=git&m=111350397024057&w=2


> >I have been told by Jurij Smakov that this is "seriously wrong", and
> >I'm asking for help here.  What's the proper way to handle this situation?
>
> rename /usr/bin/git to /usr/bin/cogito-git or whatever. It is not that hard.

That's true Adam: renaming a file is not hard...  But in this case it
has terrible consequences.

Naming it "cogito-git" makes no sense at all.  Cogito uses git, but
git doesnt know or care about cogito.  That'd be like naming glibc
"mozilla-glibc", because mozilla uses glibc.

Renaming it something else, like "git.scm" or "git.debian" or
"git.not-gnu-interactive-tools" or something, _might_ make sense, except
then we'd have an incompatible debian-specific fork of git/cogito.

People coming from other systems will correctly percieve this as
debian-induced breakage.  Users downloading helper scripts and finding
cookbook recipies on mailing list etc will discover that they are
incompatible with the rest of the universe.

That seems like too high a price to pay.


-- 
Sebastian Kuzminsky


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

Re: cogito no longer conflicts with git or cgvg

[Sebastian Kuzminsky]

Michelle Konzack <[EMAIL PROTECTED]> wrote:
> Am 2005-06-10 23:21:54, schrieb Sebastian Kuzminsky:
> > The new cogito package (0.11.3+20050610-1) is on its way into sid.
> > It does not install /usr/bin/git or /usr/bin/cg, and so it does not
> > conflict with git or with cgvg.
> 
> I think, this is a realy bad idea.
> You should rename "git" to "cogito" which is 100 times better.

Now _that's_ crazy.  Cogito uses git, but git doesnt know or care about
cogito.  Cogito is logically a separate package, it's a high-level UI
on top of git's low-level tools.

The upstream folks are planning to split cogito and git into two separate
packages.  I requested (and they seemed to agree) that they change the
package name from git to something else before then.  Hopefully they'll
see the light and try to play nice with the rest of the world.


-- 
Sebastian Kuzminsky


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

Re: cogito no longer conflicts with git or cgvg

[Sebastian Kuzminsky]

"Joe Smith" <[EMAIL PROTECTED]> wrote:
> > The upstream folks are planning to split cogito and git into two separate
> > packages.  I requested (and they seemed to agree) that they change the
> > package name from git to something else before then.  Hopefully they'll
> > see the light and try to play nice with the rest of the world.
> > 
> Hmm... It looks to me like git is already a seperate package.
> http://www.kernel.org/pub/software/scm/

It does look like that, and in a way you're right.  Linus maintains the
"mainline" git, and Pasky maintains cogito.  Two separate packages.
However, cogito includes its own version of git.  Usually these days,
cogito's git is a recent copy of Linus' git.

Sometimes, development of cogito exposes bugs or shortcomings in git,
and the cogito people patch cogito's git, and the patches later make it
in to Linus' git (or they dont).  This was an especially convenient setup
when both git and cogito were evolving very rapidly, in April and May.
Things are starting to stabilize now (they're talking about git 1.0),
so version skew is becoming less of an issue.  It is expected that
Pasky will quit distributing his own version of git with cogito soon,
and then I'll need to package Linus' git for Debian.

Make sense?


-- 
Sebastian Kuzminsky


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

Re: namespace conflict != package Conflict?

[Sebastian Kuzminsky]

Steve Greenland <[EMAIL PROTECTED]> wrote:
> On 12-Jun-05, 02:27 (CDT), Hamish Moffatt <[EMAIL PROTECTED]> wrote: 
> > >From my reading of your package description for cogito,
> > the name GIT (the version control system) doesn't seem to
> > mean anything in particular. So renaming it would not be a big loss.
> 
> The upstream name isn't going to change. There are probably already
> more users of GIT-the-VCS than GIT-the-tools. So if you rename git for
> Debian, we are very likely going to to be incompatible.
> 
> Just Conflict with the git package. The overlapping user base is likely
> to be nil.

There is at least one user that wants both...  I got a bug report about
this before I made cogito.deb Conflict with git.deb.  (Then of course
I was told that that was the wrong approach, so I _removed_ cogito's
/usr/bin/git and removed the Conflict with git.deb.)

But I agree totally with you.  I'd much rather conflict with GNU
Interactive Tools and have git-the-vcs be compatible with non-debian
universe.  That seems like the lesser of two evils.  But everyone else
on debian-devel seems to want it the other way so I gave in for now.


-- 
Sebastian Kuzminsky


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

Re: Ongoing Firefox (and Thunderbird) Trademark problems

[Sebastian Ley]

Am Dienstag, 14. Juni 2005 13:04 schrieb Julien BLACHE:

> We drop their products from Debian, they lose market share. We drop
> their trademarks, and *we* lose market share: "eh, wtf, Debian hasn't
> got firefox? mozilla? thunderbird? sunbird? omgwtf $DISTRO has them!"

Uh? If we ship their products under a different name, people will complain, 
but if we drop them they won't? Strange argumentation...

Sebastian

-- 
PGP-Key: http://www.mmweg.rwth-aachen.de/~sebastian.ley/public.key
Fingerprint: A46A 753F AEDC 2C01 BE6E  F6DB 97E0 3309 9FD6 E3E6


pgpSAOyvuWIOw.pgp
Description: PGP signature

Re: Ongoing Firefox (and Thunderbird) Trademark problems

[Sebastian Ley]

Am Dienstag, 14. Juni 2005 16:20 schrieb Humberto Massa Guimarães:

> > Does calling it "firefox" or "thunderbird" hurt "free software"?
>
> At first, no. But it *does* hurt our users. Why? Because they are
> confident that getting something from the Debian mirror, modifying
> it and re-distributing under the same terms is allowed. And they can
> be burned after some time. And they *will* blame it on Debian.

Modifying and redistributing stuff from the Debian archive does not release 
you from checking redistribution licenses. Just make 
sure /usr/share/doc/$MOZILLA-PRODUCT/copyright clarifies the trademark issue, 
and let's justify the inclusion with §4 of the DFSG.

Regards,
Sebastian

-- 
PGP-Key: http://www.mmweg.rwth-aachen.de/~sebastian.ley/public.key
Fingerprint: A46A 753F AEDC 2C01 BE6E  F6DB 97E0 3309 9FD6 E3E6

Re: debian security archive/updates b0rken???

[Sebastian Ley]

Am Sonntag, 19. Juni 2005 08:45 schrieb Steve Langasek:
> On Sun, Jun 19, 2005 at 12:31:23AM -0400, sean finney wrote:
> > please excuse this blatant cross-posting, i wouldn't do it if i didn't
> > think it were critical that i do so...
> >
> > http://www.infodrom.org/~joey/log/?200506142140
> >
> > say it isn't so!
>
> It isn't so.

... one of the largest German IT News Sites today claims otherwise:
http://www.heise.de/newsticker/meldung/61076

Headline translates to "Debian without security updates for several weeks 
now". I did not follow up on the current status of stable security, but in 
any case we should send them a response. I volunteer to translate an answer 
from English to German and send it to Heise.

Regards,
Sebastian

-- 
PGP-Key: http://www.mmweg.rwth-aachen.de/~sebastian.ley/public.key
Fingerprint: A46A 753F AEDC 2C01 BE6E  F6DB 97E0 3309 9FD6 E3E6


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

Re: dak now supports ~ in version numbers

[Sebastian Harl]

Hi,

> Adeodato>   Depends: foo (>= 0.8), foo (<< 0.9~)
> 
> Can I assume that the first one will accept version 0.9~rc1, but the
> second one wont?

You're right. The empty string at the end of '0.9~' counts as zero in
lexical comparison. Thus 0.8 < 0.9~ < 0.9~rc1.

Cheers,
Sebastian

-- 
Sebastian "tokkee" Harl
GnuPG-ID: 0x8501C7FC
http://tokkee.org/



signature.asc
Description: Digital signature

Re: VMware packaging

[Sebastian Harl]

Hi,

> > vmware
> 
> QEMU:

I really don't get this (type of) discussion...

Some people prefer qemu, some others vmware, still others prefer foo.

There is vim available from Debian repositories as well as emacs. You can
install KDE as well as Gnome, fvwm, ... why not provide qemu as well as bochs
as well as vmware (if the licence permits it). Just because vmware is
non-free? That does not make sense imho.

Just my 2 cents...

Cheers,
Sebastian

-- 
Sebastian "tokkee" Harl
GnuPG-ID: 0x8501C7FC
http://tokkee.org/



signature.asc
Description: Digital signature

ITP: fusedav -- userspace file system driver for mounting WebDAV shares

[Sebastian Harl]

retitle 379147 ITP: fusedav -- userspace file system driver for mounting WebDAV 
shares
owner 379147 !
thanks

> * Package name: fusedav
>   Version : 0.2
>   Upstream Author : Lennart Poettering
> * URL : http://0pointer.de/lennart/projects/fusedav/
> * License : GPL
>   Programming Lang: C
>   Description : fusedav is a Linux userspace file system driver for 
> mounting WebDAV shares.

I'm going to package this software.

Cheers,
Sebastian

--
Sebastian "tokkee" Harl
GnuPG-ID: 0x8501C7FC
http://tokkee.org/



signature.asc
Description: Digital signature

Re: ITP: fusedav -- userspace file system driver for mounting WebDAV shares

[Sebastian Harl]

Hi,

>  Did you consult with Lennart Poettering before you take over? 

I'm not taking over this package. Lennart Poettering filed an RFP.

> Anyway, the neon dependency is OK just by now. The neon26 package is
> accepted today to the archive, so you can build depend on it.

I know. That's why I am going for the package now ;-)

Cheers,
Sebastian

-- 
Sebastian "tokkee" Harl
GnuPG-ID: 0x8501C7FC
http://tokkee.org/



signature.asc
Description: Digital signature

Bug#389926: ITP: tig -- content addressable filesystem (CLI repository browser)

[Sebastian Harl]

Package: wnpp
Severity: wishlist
Owner: Sebastian Harl <[EMAIL PROTECTED]>


* Package name: tig
  Upstream Author : Jonas Fonseca <[EMAIL PROTECTED]>
* URL : http://jonas.nitro.dk/tig/
* License : GPL
  Description : content addressable filesystem (CLI repository browser)

tig is a command line repository browser capable of displaying a summerized 
revision log and showing commit log messages, diffstats and diffs. It may also
be used as a pager. It reads input from stdin and colorizes it.


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

Bug#390655: ITP: enblend -- image blending with multiresolution splines

[Sebastian Harl]

Package: wnpp
Severity: wishlist
Owner: Sebastian Harl <[EMAIL PROTECTED]>


* Package name: enblend
  Upstream Author : Andrew Mihal
* URL : http://enblend.sourceforge.net/
* License : GPL
  Description : image blending with multiresolution splines

enblend is a tool for compositing images. Given a set of images that overlap
in some irregular way, enblend overlays them in such a way that the seam
between the images is invisible, or at least very difficult to see. enblend
does not line up the images for you. Use a tool like hugin to do that.


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

Re: Dropping GStreamer 0.8 for etch

[Sebastian Dröge]

Am Mittwoch, den 06.12.2006, 22:47 +0100 schrieb Josselin Mouette:
> Le mercredi 06 décembre 2006 à 21:48 +0100, Loïc Minier a écrit :
> > On Wed, Dec 06, 2006, Josselin Mouette wrote:
> > > Maybe it is also not too late to rework the gstreamer0.10-ffmpeg package
> > > to link against the Debian libavcodec/libavformat packages. This would
> > > save a lot of trouble to the security team.
> > 
> >  This is a separate issue, and the short status on the subject is that
> >  upstream thinks this is not possible, but they would accept help on
> >  this topic:
> > 
> 
> The attached patch should be at least enough for Debian. Finally working
> h264 videos with totem-gstreamer, hear hear!

You can also get working h.264 decoding by taking latest gst-ffmpeg CVS
which will be released as 0.10.2 in a few days. As upstream does very
extensive tests that their current ffmpeg snapshot works as expected
with the gstreamer plugin I think it's far safer to stay with their
version unless we want bugs that are not reproducible with upstream's
gstreamer plugin and ffmpeg combination.

Also using a different ffmpeg version than upstream could lead to our
bugreports being rejected or at least being seen as less valid than
other bugreports with default builds...

Bye


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: Dropping GStreamer 0.8 for etch

[Sebastian Dröge]

Am Mittwoch, den 06.12.2006, 21:27 +0100 schrieb Loïc Minier:
> Hi,
> 
>  This is to discuss dropping the 0.8 series of GStreamer for etch.
> 
>  Recently, a security bug affected gst-ffmpeg and needed an upload for
>  both the 0.8 and 0.10.  The security team wonders whether it will have
>  to support both sources for the etch lifetime.
>The number of packages which are still using the 0.8 series of
>  GStreamer has dropped significantly.  Remain as libgstreamer0.8-0
>  rdeps:
>  - teatime: Sebastian Dröge sent a patch for GStreamer 0.10 support in
>#401897

A new version of teatime including this patch (2.6.0-5) was already
uploaded today.


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: FSG Packaging Summit in Berlin

[Sebastian Feltel]

Hello,

Ottavio Caruso schrieb am 03.01.2007 15:35:
> http://www.freestandards.org/en/LSB_face-to-face_%28December_2006%29
> 
> Quote:"The goal of the Summit is to bring together the key people in
> the Linux packaging world and ISVs to discuss the future of Linux
> packaging. Topics will include RPM, the role of other packaging
> technologies (dpkg, APT, yum, etc.), and the needs of ISVs in
> packaging solutions".
> 
> Has this ever been discussed on Debian ML's?
> 
> Joey Hess was there. I can't recall any mention of it on the DWN.

If you are aware of currently unmentioned events, news or whatever
please report [1] them. We (meaning the regular contributors to DWN)
cannot read every single Debian/Linux/FOSS-related mailing list or
website so we need your support.

Bye
Sebastian

[1] http://www.debian.org/News/weekly/contributing

-- 
debianforum.de - die deutschsprachige Supportwebseite rund
um das Debian-Projekt  <http://www.debianforum.de>



signature.asc
Description: OpenPGP digital signature

Re: What library to use for manipulation iCal data from C

[Sebastian Ley]

* Alexander Sack wrote:

> Any idea why libical has been removed from the archive? e.g. sunbird
> uses/includes it too, so maybe it makes sense to have it back in the
> archive.

At that time, libical was upstream-dead, had bugs and almost every project 
that neede it used a customized and modified version of it.

Maybe it comes back to live here:
http://www.aurore.net/projects/libical/

Regards,
Sebastian

-- 
Blog: http://www.withouthat.org/~sebastian/blog
PGP-Key: http://www.withouthat.org/~sebastian/public.key
Fingerprint: A46A 753F AEDC 2C01 BE6E  F6DB 97E0 3309 9FD6 E3E6


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

Re: unstable? nah. :-)

[Sebastian Harl]

> http://www.crackerjack.net/adserton3.png

On that picture it says the box is up for 378 days. How does that go with 875
days idle time?

Cheers,
Sebastian
-- 
Sebastian "tokkee" Harl
GnuPG-ID: 0x8501C7FC
http://tokkee.org/



signature.asc
Description: Digital signature

Bug#373008: ITP: collectd -- statistics collection daemon

[Sebastian Harl]

Package: wnpp
Severity: wishlist
Owner: Sebastian Harl <[EMAIL PROTECTED]>


* Package name: collectd
  Version : 3.9.3
  Upstream Author : Florian Forster <[EMAIL PROTECTED]>
* URL : http://collectd.org/
* License : GPL
  Description : statistics collection daemon

collectd is a small daemon written in C for performance. It reads various
system statistics and updates RRD files, creating them if necessary. Since
the daemon doesn't need to startup every time it wants to update the files
it's very fast and easy on the system. Also, the statistics are very fine
grained since the files are updated every 10 seconds.

-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.14.3-vs2.0.1
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)


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

Bug#375548: ITP: openvcp -- Linux-VServer Control Panel

[Sebastian Harl]

Package: wnpp
Severity: wishlist
Owner: Sebastian Harl <[EMAIL PROTECTED]>


* Package name: openvcp
  Version : 0.1-beta
  Upstream Author : Gerrit Wyen <[EMAIL PROTECTED]>
* URL : http://openvcp.org/
* License : GPL
  Description : Linux-VServer Control Panel

OpenVCP allows you to manage Linux-VServers (http://linux-vserver.org/) on
several machines using a single webinterface.


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

Re: code cpustat.c

[Sebastian Harl]

> This code is written to
> take CPU loading statistics. cpustat; shows the usage load statistic of
> your CPU.

top(1) gives the exact same information. What's the advantage of your program?

Cheers,
Sebastian

-- 
Sebastian "tokkee" Harl
GnuPG-ID: 0x8501C7FC
http://tokkee.org/



signature.asc
Description: Digital signature

Re: code cpustat.c

[Sebastian Harl]

> ps and top command gives the ram state. i am doing this to see cpu's load
> and usage.

As far as I can see it, you're reading the exact same information as top(1)...

-- 
Sebastian "tokkee" Harl
GnuPG-ID: 0x8501C7FC
http://tokkee.org/



signature.asc
Description: Digital signature

Re: ITP: openwatcom -- C/C++ compiler and IDE that produce efficient, portable code

[Sebastian Harl]

> > What does it mean for a compiler to produce portable code?
> >
> Good question. I do not have personal experience with this, but I am
> told you can write your code once and then recompile it for a wide
> variety of platforms

On the website it says it's a cross compiler, that is to say you can produce
code for different target platforms on one host platform.

Maybe you should change the description to something like "C/C++ cross
compilers and IDE". Saying that a compiler produces portable code is wrong
imho (Even the Java compiler does not really produce portable code - the Java
binary code only runs on the Java VM. The Java VM itself is portable though.).

Cheers,
Sebastian

-- 
Sebastian "tokkee" Harl
GnuPG-ID: 0x8501C7FC
http://tokkee.org/



signature.asc
Description: Digital signature

Bug#377220: ITP: liblingua-de-ascii -- convert german umlauts to and from ascii

[Sebastian Harl]

Package: wnpp
Severity: wishlist
Owner: Sebastian Harl <[EMAIL PROTECTED]>


* Package name: liblingua-de-ascii
  Version : 0.11
  Upstream Author : Janek Schleicher <[EMAIL PROTECTED]>
* URL : http://cpan.org/modules/by-module/Lingua/
* License : GPL / Artistic
  Description : convert german umlauts to and from ascii

This module enables conversion from and to the ASCII format of german texts.
It has two methods: to_ascii and to_latin1 which each do exactly what they 
say.


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

Re: Bug#377220: ITP: liblingua-de-ascii -- convert german umlauts to and from ascii

[Sebastian Harl]

> > * Package name: liblingua-de-ascii
> >   Version : 0.11
> >   Upstream Author : Janek Schleicher <[EMAIL PROTECTED]>
> > * URL : http://cpan.org/modules/by-module/Lingua/
> > * License : GPL / Artistic
> >   Description : convert german umlauts to and from ascii
> 
> According to the Debian Perl Policy, your package should be called
> liblingua-de-ascii-perl (see
> http://www.debian.org/doc/packaging-manuals/perl-policy/ch-module_packages.html)

Yes... thx - that was just a typo.

Cheers,
Sebastian

-- 
Sebastian "tokkee" Harl
GnuPG-ID: 0x8501C7FC
http://tokkee.org/



signature.asc
Description: Digital signature

Bug#377527: ITP: liboping -- C library to generate ICMP_ECHO requests

[Sebastian Harl]

Package: wnpp
Severity: wishlist
Owner: Sebastian Harl <[EMAIL PROTECTED]>


* Package name: liboping
  Version : 0.3
  Upstream Author : Florian Forster <[EMAIL PROTECTED]>
* URL : http://verplant.org/liboping/
* License : GPLv2
  Description : C library to generate ICMP_ECHO requests

liboping is a C library to generate ICMP_ECHO requests (better known as "ping
packets"). It features pinging multiple hosts in parallel using IPv4 or IPv6
transparently. The interface is object oriented.


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

Re: orphaning gitweb

[Sebastian Harl]

Hi Andres,

> I'm going to orphan gitweb; I haven't used it in a long time, and I've
> been doing a poor job of keeping it up-to-date.  It doesn't have any
> bugs open on it; it just needs the occasional update (and the one patch
> I've done for it should be fed upstream if they're willing to take it).

I'm interested. However, it might make more sense to build gitweb from the 
git-core source package.

Cheers,
Sebastian

-- 
Sebastian "tokkee" Harl
GnuPG-ID: 0x8501C7FC
http://tokkee.org/



signature.asc
Description: Digital signature

Bug#379857: ITP: git-completion -- content addressable filesystem (bash completion)

[Sebastian Harl]

Package: wnpp
Severity: wishlist
Owner: Sebastian Harl <[EMAIL PROTECTED]>


* Package name: git-completion
  Version : 0+20060722
  Upstream Author : Ben Clifford <[EMAIL PROTECTED]>
* URL : http://www.hawaga.org.uk/ben/tech/gitcompletion/
* License : GPL
  Description : content addressable filesystem (bash completion)

git is a stupid (but extremely fast) directory content manager. It doesn't do 
a whole lot, but what it 'does' do is track directory contents efficiently.
.
This package contains the bash completion for git, cogito and stg.


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

Re: Bug#379857: ITP: git-completion -- content addressable filesystem (bash completion)

[Sebastian Harl]

Hi,

> > * Package name: git-completion
> >   Version : 0+20060722
> >   Upstream Author : Ben Clifford <[EMAIL PROTECTED]>
> > * URL : http://www.hawaga.org.uk/ben/tech/gitcompletion/
> > * License : GPL
> >   Description : content addressable filesystem (bash completion)
> >
> > git is a stupid (but extremely fast) directory content manager. It doesn't 
> > do 
> > a whole lot, but what it 'does' do is track directory contents efficiently.
> > .
> > This package contains the bash completion for git, cogito and stg.
> 
> Why should this be a separate package? Either include it in the bash package
> or into the /etc/bash_completion.d of git, cogito and stg.

Well, why shouldn't it be a separate package? It _is_ a separate source
package that's developed independently of anything git or bash related. Imho
it just would not make much sense to include it in any other package.

Cheers,
Sebastian

-- 
Sebastian "tokkee" Harl
GnuPG-ID: 0x8501C7FC
http://tokkee.org/



signature.asc
Description: Digital signature

Bug#4060: Update: 4060 - Kernel decompression failure.

[Sebastian Benoit]

On Mon, 12 Aug 1996, Christopher R. Hertel wrote:

> Package: boot (boot1440.bin, install)
> Version: 1.1  (kernel is 2.0.0)
> 
> Updated information...
> 
> Problem: On some systems, the compressed kernel image provided on the
> installation floppy (boot1440.bin) is not decompressed properly when
> read from floppy.  One solution that seems to work for most users is to
> *disable the internal cache*.  If this does not work for you, try
> disabling both the internal and external cache.  This is done via the
> bios setup.
> 

It is possible that your system has timing problems ... Try to increase 
the IO-Waitstates in the BIOS-Setup (if there is an option like that), 
and leave both internal and external cache on.
   
- Sebastian Benoit  Save the planet !
- [EMAIL PROTECTED]
- [EMAIL PROTECTED]
- http://www.mathematik.uni-marburg.de/~benoit  less is more !

Re: apt-get and proxy

[Sebastian Rittau]

On Wed, Sep 13, 2000 at 07:55:11AM +0200, Andreas Tille wrote:

> I'm in real trouble with apt-get and a squid proxy.

We've got the same problem when using apt via Squid via a broken
IBM proxy. (Apt connects to the Squid proxy, which has the proxies
of the German provider T-Online as its only and mandatory parent.[1]
I thought it was the result of some strange interaction between the
two proxies and didn't care. I just changed all apt methods from ftp
to their http equivalents, which works.

Before, most packages were rejected due to a "size mismatch". Just
moving these packages from /var/cache/apt/archives/partial to
/var/cache/apt/archives and re-running apt worked.

 - Sebastian

[1] The IBM proxy is quite buggy. It returns an HTTP status of 200 (Ok)
on several occasions, where an error code would be appropriate.
This also showed a bug in Squid: Squid tries to request a
document called something like /squid-internal-db from
neightbor caches. Of course the IBM proxy does not find this
document and returns status code 200 with an HTML body, saying
"404 Document Not Found". Squid, on the other hand, handles the
returned document as binary data and tries to parse it,
resulting in undefined behaviour. (In our case it hung while
consuming all CPU power.)


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

Re: tar -I incompatibility

[Sebastian Rittau]

On Sat, Jan 06, 2001 at 02:53:06PM +, Colin Watson wrote:
> "Scott Ellis" <[EMAIL PROTECTED]> wrote:

> >Of course the -I option to tar was completely non-standard.  The
> >changelog explains why it changed, to be consistant with Solaris tar.
> 
> I don't see the reasoning in the changelog, but I may just have missed
> it.

It's actually in the NEWS file:

| * The short name of the --bzip option has been changed to -j,
|   and -I is now an alias for -T, for compatibility with Solaris tar.

 - Sebastian

Re: Bug#195426: O: multi-gnome-terminal -- Enhanced the GNOME Terminal

[Sebastian Rittau]

On Sat, May 31, 2003 at 12:00:13AM +0900, Akira TAGOH wrote:

> I'm orphaning multi-gnome-terminal package now, because I
> don't use it at this point, and I have no enough time to
> maintain such package. presumably there might be the
> appropriate DD than me to maintain this package.

Is there anything that multi-gnome-terminal can do that the current
(GNOME 2) gnome-terminal cannot? Is there any point in keeping this
obsolete GNOME 1 package? If not, I would suggest to file a bug against
ftp.gnome.org, requesting its removal.

 - Sebastian

Re: Bug#195426: O: multi-gnome-terminal -- Enhanced the GNOME Terminal

[Sebastian Rittau]

On Sat, May 31, 2003 at 03:34:50AM +0900, Akira TAGOH wrote:
> >>>>> On Fri, 30 May 2003 17:25:15 +0200,
> >>>>> "SR" == Sebastian Rittau <[EMAIL PROTECTED]> wrote:

> SR> Is there anything that multi-gnome-terminal can do that the current
> SR> (GNOME 2) gnome-terminal cannot? Is there any point in keeping this
> SR> obsolete GNOME 1 package? If not, I would suggest to file a bug against
> SR> ftp.gnome.org, requesting its removal.
> 
> It's not in ftp.gnome.org. the upstream is
> multignometerm.sf.net.

Oops, I meant ftp.debian.org, of course. So, my suggestion basically
was: Are you sure you want to orphan this package? Wouldn't it be better
to remove it from the archive, instead? But since people have already
spoken up, who astill use this package, this question has become
meaningless.

 - Sebastian

Re: Bug#198158: architecture i386 isn't i386 anymore

[Sebastian Kapfer]

On Fri, 20 Jun 2003 17:20:13 +0200, Mathieu Roy wrote:

> If so, are you kidding? The Pentium classic (i586) was still available
> in 1997.

It is still available even today. Not sure where to get a mainboard for
this beast, but just a week ago I saw it on a price list.

> I know a lot of person who use a Pentium classic as mini-server, with is
> really enough to run a local network.
> 
> Also P MMX seems meaningless to me. MMX was, I think, introduced in
> Pentium Pro (which is still a i586 according to uname)

Really? Seems wrong to me.

> and nowadays computers still got MMX (so what is the meaning of P MMX?
> PPro? PII? PIII? PIV?).

MMX was introduced with the Pentium/MMX (P55C) processor. That's a Pentium
(i586) with MMX bolted on. PPro (P6, i686) doesn't have MMX (being
introduced before the Pentium MMX). PII united the two designs. It
features a PPro core _and_ MMX. So I guess the meaning of P MMX is pretty
clear. It refers to the classic Pentium with MMX.

> Skipping 386 for 486 seems acceptable because nowadays, a distro
> requires more HD space and RAM than it's possible to add with usual 386
> motherboards,

You could always burn a CD-ROM for /usr :-)

> but dropping all Pentiums until Pentium II generation
> seems completely foolish. I hope I misunderstood your message.

I'd drop the sub-pentiums (i.e. 386 and 486) entirely. Not that my vote
would count...

-- 
Best Regards,   |   Hi! I'm a .signature virus. Copy me into
 Sebastian  |   your ~/.signature to help me spread!

Re: Bug#198158: architecture i386 isn't i386 anymore

[Sebastian Kapfer]

On Fri, 20 Jun 2003 23:40:13 +0200, Cyrille Chepelov wrote:

>> I'd drop the sub-pentiums (i.e. 386 and 486) entirely. Not that my vote
>> would count...
> 
> Hmmm. Until all of glibc, the kernel and gcc deprecate and discard
> support for 386 and 486,

One of them is enough to be a showstopper.

> I'd love if I could keep my home edgge router running the way it is
> thank you very much (and I'm happy with the great job the Security Team
> is doing). Not that the flea market value of a Pentium Classic is that
> high nowadays, but why fix what works? I thought Free Software was above
> planned obsolescence...

Sure it's nice when you can use old hardware until it breaks, not until
company XYZ wants to charge for new licenses.

> (note that if there is a compelling technical reason for forking i386
> into i386-proper and i686, I'm happy with it. Have you seen it? I
> haven't so far.)

IANAIAP (I am not an i386 assembler programmer), but if the illegal
instruction workaround which was proposed in this thread _does_ work, it
would probably turn out to be the best solution. Makes your old box run
Quake 3 ;-) and the guys running a 486+ kernel won't need to pay for it.
Would it hurt the i386's performance too hard?

A general solution to the problem would be nice. I don't know about other
arch's, but Intel and AMD are inventing new instructions faster than new
processor designs. Makes me wonder how a multi-architecture distro like
Debian is supposed to handle that. Is there something like automatic
detection of the "best" codepath given the limitations of the current CPU?
Not sure what effect something like that would have on binary sizes and
build times though...

(And no, I'm not demanding P4-optimized word processors here! Optimization
has to be restricted to packages where it really speeds up things.)

-- 
Best Regards,   |   Hi! I'm a .signature virus. Copy me into
 Sebastian  |   your ~/.signature to help me spread!

Re: Debconf or not debconf

[Sebastian Rittau]

On Wed, Jul 02, 2003 at 01:41:13PM +0200, Julien LEMOINE wrote:

> Not exactly, there is a variable ENABLED which is set to 0 at installation. 
> So 
> the service will not start while variable is not set to 1.

So, just set the variable to 1 if upgrading from a version earlier than
that in which you introduced that feature.

 - Sebastian

Re: Please remove RFCs from the documentation in Debian packages

[Sebastian Rittau]

On Thu, Jul 03, 2003 at 01:00:47PM +0200, Petter Reinholdtsen wrote:

> There seem to be someone believing that standard documents should be
> treated as software.  Standards are not software.  Standards do not
> improve if everyone is allowed to modify them and publish the modified
> version as an updated version of the standard.

There's no need to. But I want to have the right to change a standard
slightly, and hand it around, telling people that this is how I would
have liked the standard. I also want to have the right to enhance or
even change a standard, and use it e.g. for some internal project. I
want to quote parts of the standard in other documents or my software
(maybe even outside the "fair use" constraints). I might not be allowed
to do that. There might be other restrictions as well.

I don't want to have the right to call these modified documents "RFCs"
or "standards", though. Please don't confuse these two issues. This is
something that we already allow - see some software licenses that we
consider free that require derived versions of the software to change
the name of the software.

 - Sebastian

Re: Debconf or not debconf : Conclusion

[Sebastian Rittau]

On Thu, Jul 03, 2003 at 04:17:50PM +0200, Julien LEMOINE wrote:
>   Finally, since there is not really a policy about when to use debconf, 
> I will respect the DFSG [1] and add a debconf warning [2] in the 
> stunnel package.

[...]

> [1] "4. Our Priorities are Our Users and Free Software "

As a user: You are doing me a disservice. That's one more useless
debconf warning, especially, since an automatic update is easy to
implement.

 - Sebastian

Re: Please remove RFCs from the documentation in Debian packages

[Sebastian Rittau]

On Fri, Jul 04, 2003 at 02:04:51PM +0200, Florian Weimer wrote:

> But how far goes clause 4?  Obviously not that far that Debian
> includes Java (for rather complete values of "Java", which seems to
> imply a certain proprietary implementation at the moment).

Which non-free Java implementations are part of Debian? I know of none.

 - Sebastian

Re: Debian 10th birthday gear

[Sebastian Rittau]

On Tue, Jul 08, 2003 at 05:36:22PM +1000, Anand Kumria wrote:

> General
>   Debian
> 1 project
>10 architectures
>   100 countries
>  1000 maintainers
> 1 packages
>10 bug fixed
>   100 million users
>  1000 installations

I would recommend to exchange these last two lines. More installations
than users?

 - Sebastian

Re: Debian 10th birthday gear

[Sebastian Rittau]

On Tue, Jul 08, 2003 at 11:57:40AM +0200, Federico Di Gregorio wrote:
> Il mar, 2003-07-08 alle 11:11, Sebastian Rittau ha scritto:
> > On Tue, Jul 08, 2003 at 05:36:22PM +1000, Anand Kumria wrote:

> > >   100 million users
> > >  1000 installations
> > 
> > I would recommend to exchange these last two lines. More installations
> > than users?
> 
> sure. i am 1 user (mm.. if i continue eating like i do i'll account for
> 1.5) but i installed at least 10 debians on my boxes only, much more for
> work. :)

Well, I've got an installation with about 20 hosts and about 700 users.
And that's not counting all the users of web sites which are running
Debian ... I think that multiple users per host is much more common than
vice versa (except in the geek case).

 - Sebastian

Re: Qt3 still broken (compat-headers), what to do?

[Sebastian Rittau]

On Sun, Jul 13, 2003 at 12:14:52AM -0500, Branden Robinson wrote:

> Bah, the Technical Committee takes months, sometimes over a year, to do
> something even as seemingly uncontroversial as voting in opposition to
> whichever solution Branden Robinson proposes.

So? This is more than enough time. This problem is to be fixed in sarge ...

 - Sebastian

Re: Qt3 still broken (compat-headers), what to do?

[Sebastian Rittau]

On Sun, Jul 13, 2003 at 01:51:07PM +1000, Ben Burton wrote:

> It seems then that our options are as follows.
> 
> (i) Wait for the Qt maintainers to upload a fix.
> (ii) Do an NMU for Qt, despite the fact that this bug is not release-critical.
> (iii) Resort to the technical committee.
> (iv) Keep the package split and release sarge with a broken Qt development 
> environment.

Option (iii) is certainly the way to go. Problems like this are exactly
what the TC is for.

My suggestion: Add a "Recommends: libqt3-compat-headers" to libqt3-dev.
A dependency is too strong, since libqt3-dev is perfectly usable without
the compatibility headers, but a recommendation ensures that the compat
headers are installed along libqt3-dev in most cases.

 - Sebastian

Re: default MTA for sarge

[Sebastian Kapfer]

On Sun, 13 Jul 2003 11:50:07 +0200, Sean 'Shaleh' Perry wrote:

> Enough of a Linux system assumes that a MTA is present that not
> installing any would be wrong.  Asking an user which MTA they want is
> equally wrong because many users have no clue what one is.

I strongly support this. A week or two ago, I had to fix a Debian box
which was "painfully slow". The cause was (you guess it) - exim. The user
installed it (probably dependencies), but didn't configure it correctly.
Now combine that with a cronjob that runs every five minutes and cron's
send-mail-when-complete feature. The machine accumulated a mail queue of
several hundred megabytes; every 10 minutes or so, exim was run and tried
in vain to send out those mails. Because none of these mails was ever
delivered, the user didn't know what the problem was.

In short, please make "local delivery" the default; don't even run
exim-config on installation.[1] Those who need the feature will know how
to activate it. The others shouldn't need to care.


[1] The question where root's mail goes to comes to mind. I think this
question has to be asked.

-- 
Best Regards,   |   Hi! I'm a .signature virus. Copy me into
 Sebastian  |   your ~/.signature to help me spread!

Re: default MTA for sarge

[Sebastian Kapfer]

On Sun, 13 Jul 2003 12:30:08 +0200, ZHAO Wei wrote:

>> So do we want there to be a MTA by default?
> 
> I, for one, don't want there be a MTA by default. At least not a running
> daemon there.

What about inetd (which is IMHO the current default)?

-- 
Best Regards,   |   Hi! I'm a .signature virus. Copy me into
 Sebastian  |   your ~/.signature to help me spread!

Re: default MTA for sarge

[Sebastian Kapfer]

On Sun, 13 Jul 2003 15:00:10 +0200, Andreas Metzler wrote:

> If you installed exim4 and used frontend=noninteractive or just press
>  on every debconf-question you should end up exactly with this:
> local delivery only.

In this case, it was the exim3 package, which had a non-debconf
configuration program last I looked. This program was probably confusing
the user (he didn't intend to install an MTA after all). Good to hear that
exim4 has improved this.

> OTOH if you upgraded from an exim with broken config you /might/ end up
> with an exim4 inheriting the broken config, as it tries to "parse"
> exim.conf to preanswer the debconf-questions.

Of course one can't rely on updates to fix misconfigurations. So that's
probably OK.

>> [1] The question where root's mail goes to comes to mind. I think this
>> question has to be asked.
> 
> If you don't specify another user when configuring /etc/alises it will
> be delivered to /var/mail/root

I know, but that location (/var/mail/root) is discouraged, isn't it? The
admin shouldn't read his/her mail under uid 0. That's why I think that
exim should ask this question when it is configured for local delivery (or
in "newbie" mode ;-)

The best solution (at least for the average user which doesn't care about
his MTA) would IMHO be a question along the lines of "Which user account
should receive messages for the system administrator?" I.e. not even
mentioning the technical details. The word "mail" might be misleading
here.

Just thinking aloud... I have not installed any exim4 yet, and I know how
to get exim3 to do local delivery. But Debian should become a more
user-friendly OS after all, right?

-- 
Best Regards,   |   Hi! I'm a .signature virus. Copy me into
 Sebastian  |   your ~/.signature to help me spread!

Re: unicode

[Sebastian Rittau]

On Wed, Oct 30, 2002 at 02:11:46PM +0100, Sergey V. Spiridonov wrote:

> Is Debian aims to be unicode compatible system?

Not officially, although I think that this is a worthwhile goal and
there are various efforts that try to bring Debian a little bit closer
to ubiquitous Unicode support.

> If yes, then should I mail a bug report against packages which are not 
> able to handle unicode?
> 
> If yes, should it be "Minor", "Normal" or "Important"?

wishlist

> For example, grep is not able to search unicode strings.

Is it not?

  [EMAIL PROTECTED]:~$ cat foo
  This is
  a test
  with Umlauts: äöü
  [EMAIL PROTECTED]:~$ grep ä foo
  with Umlauts: äöü
  [EMAIL PROTECTED]:~$ locale
  LANG=de_DE.UTF-8
  LC_CTYPE="de_DE.UTF-8"
  LC_NUMERIC="de_DE.UTF-8"
  LC_TIME="de_DE.UTF-8"
  LC_COLLATE="de_DE.UTF-8"
  LC_MONETARY="de_DE.UTF-8"
  LC_MESSAGES="de_DE.UTF-8"
  LC_PAPER="de_DE.UTF-8"
  LC_NAME="de_DE.UTF-8"
  LC_ADDRESS="de_DE.UTF-8"
  LC_TELEPHONE="de_DE.UTF-8"
  LC_MEASUREMENT="de_DE.UTF-8"
  LC_IDENTIFICATION="de_DE.UTF-8"
  LC_ALL=
  [EMAIL PROTECTED]:~$

 - Sebastian

Re: Bits from the RM

[Sebastian Ley]

* GOTO Masanori wrote:

> AFAIK, the unresolved difficult bugs are: (1) hppa build (2) dpkg
> (setjmp/longjmp) on sparc (3) NIS (will be fixed?)  (4) misterious
> apache on ia64 bug.  Note that (3) becomes ok to revert patches, (4)
> may be non-glibc bug.  Well, they are still something hard work. :-)

(5) Breakage of all d-i boot images created in an environment with new
libc. Seems to be related to libc6-pic and mklibs, bug will be filed
against libc6-pic.

Sebastian

-- 
PGP-Key: http://www.mmweg.rwth-aachen.de/~sebastian.ley/public.key
Fingerprint: A46A 753F AEDC 2C01 BE6E  F6DB 97E0 3309 9FD6 E3E6

Re: packages mucking in /usr/local/?

[Sebastian Kapfer]

On Sun, 24 Aug 2003 05:50:07 +0200, Colin Watson wrote:

>> /usr/local/lib/texmf/ls-R
> 
> Those aren't bugs (well, possibly apart from the TeX one, dunno about
> that).

ls-R is an index generated by texhash, so that Debian's teTeX can use TeX
packages installed under /usr/local.

-- 
Best Regards,   |   Hi! I'm a .signature virus. Copy me into
 Sebastian  |   your ~/.signature to help me spread!

Re: galeon in Debian stable

[Sebastian Kapfer]

On Wed, 27 Aug 2003 10:10:11 +0200, Mark Howard wrote:

> Sorry for cross-posting. There are many interested people who only read
> one of the lists I'm posting to.
> 
> Hello again,
>   It's great to see so many positive comments about galeon. Hopefully
> 1.3.8 will go into stable.

It would be really sad to release Sarge without a Galeon. I use your 1.3
debs every day, and while they crash sometimes, they aren't totally
unusable. 1.3.5 was even better - it proved rock-stable for me. What about
a slight regression to 1.3.5 if we can't stabilize 1.3.[78] in time for
the release?

-- 
Best Regards,   |   Hi! I'm a .signature virus. Copy me into
 Sebastian  |   your ~/.signature to help me spread!

Re: Where are we now? (Was: Bits from the RM)

[Sebastian Ley]

Am Do, den 02.10.2003 schrieb Martin Michlmayr um 07:42:

>  * Debian-Installer HOWTO Sebastian Ley
> http://lists.debian.org/debian-devel-announce/2003/debian-devel-announce-200309/msg7.html

During the last debcamp we took the opportunity to introduce some last
major changes which leaves us presently again with unusable images. But
a fix for all the problems is underway, and agter that we will ensure
that there is always a version which has been known to work I'll post
the status on the present showstoppers on debian-boot.

Sebastian

-- 
PGP-Key: http://www.mmweg.rwth-aachen.de/~sebastian.ley/public.key
Fingerprint: A46A 753F AEDC 2C01 BE6E  F6DB 97E0 3309 9FD6 E3E6

Re: Annoyances of aptitude

[Sebastian Kapfer]

On Fri, 03 Oct 2003 05:20:10 +0200, Daniel Burrows wrote:

>   As I indicated in a recent message, I don't currently have time to
> get aptitude working the way I'd like.  Please consider this a public
> call for a codeveloper -- you can "interview" by submitting working
> patches for one of the issues below, particularly the ones I've outlined
> a fix for.  (aptitude is maintained as an Alioth project, so if you have
> an Alioth account, I can just add you to the project)

aptitude is actually in a rather good state IMHO, it gets the job done
very well. I've never grocked dselect, but once I had found out about
aptitude, I was converted to the Debian side :-)

A minor issue that plagues me as a Sid user is the "broken packages"
display. When I install foo that breaks package bar by conflicts of
dependencies of dependencies (you get the idea), aptitude tells me that
there are broken packages. That's nice to know, but it would be even
better if aptitude could display a _list_ of these packages in the "g"
view (I mean the summary that appears just before committing the changes).
With the current release, I have to browse through the packages and hope
to stumble on the broken ones.

This is probably not directly relevant for the Sarge release, but it would
be very helpful.

-- 
Best Regards,  | Wer Windows-Rechner ins Internet lässt,
 Sebastian | braucht nicht über SWEN stänkern!
   |
   | mailbox in "From" silently drops any mail > 20k

Re: Annoyances of aptitude (Was: Where are we now?) (Was: Bits from the RM)

[Sebastian Kapfer]

On Fri, 03 Oct 2003 17:20:11 +0200, Steve Greenland wrote:

> On 02-Oct-03, 21:59 (CDT), Daniel Burrows <[EMAIL PROTECTED]> wrote:
>> It will never be off by default while I am a maintainer of the package,
>> unless someone gets me to change my mind (which I don't think is
>> likely; I already thought for a while about this before changing the
>> default to be "on")
> 
> You might consider including a default filter so that the only
> candidates for automatic removal begin with 'lib' and don't end with
> '-dev'.

Huh? Don't fix things that aren't broken. For example, I don't care about
cpio, though I have that package installed because dpkg-dev depends on it.
Should I remove dpkg-dev one day, then I'd want cpio to leave, too. That's
why cpio has the auto flag on my system. It's simple, straightforward. We
don't need to discriminate against lib* packages.

-- 
Best Regards,  | Wer Windows-Rechner ins Internet lässt,
 Sebastian | braucht nicht über SWEN stänkern!
   |
   | mailbox in "From" silently drops any mail > 20k

Re: Annoyances of aptitude

[Sebastian Kapfer]

On Fri, 03 Oct 2003 21:40:06 +0200, MichaÅ Politowski wrote:

[locating broken packages]
> Usually I just press l~b

Cool, thanks. I didn't know that trick. (The German translation of the "l"
feature is misleading, no it's actually totally wrong... It never occurred
to me that this keybinding could be useful. Bug report filed.)

> Limited views are (together with GC, and command-line search) probably
> the three features of aptitude I couldn't live without.

Does my feature request still make some sense?

-- 
Best Regards,  | Wer Windows-Rechner ins Internet lÃsst,
 Sebastian | braucht nicht Ãber SWEN stÃnkern!
   |
   | mailbox in "From" silently drops any mail > 20k

Re: Firefox:I get redirected to microsoft website when entering http//kernel.org or http//debian.org

[Sebastian Bober]

On Mon, Aug 08, 2005 at 11:58:58AM +0300, Török Edvin wrote:
> 
> I shouldn't get redirected because I misstyped a URL (not only the
> http://, other parts can be misstyped too). Maybe the site I am trying
> to access is down temporarly, that doesn't mean I have to get
> redirected to some other site.

Just for the record: you wont be redirected if the site is down. Just
try http://dfadsfasdfasd.org in Firefox.

cheers,
  Sebastian


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

shouldn't I use update-alternatives for this?

[Sebastian Kuzminsky]

Yet another thread about cogito-vs-git, sorry folks.  Just killfile me
if I've worn out your patience.


Still there?  Great!


Background: I'm the guy who maintains the cogito package.  I had a problem
a while back because my upstream package wanted to install a program with
the same name as a program installed by GNU Interactive Tools (git.deb).
I asked on this list and was told that Conflicting with GNU Interactive
Tools was wrong, I should rename my upstream's program to avoid the
collision.  I didn't like this suggestion, but I complied with it.


Now, after bumbling around the Debian developer docs a little more,
I found this.  Section 3.10 of the Policy Manual states:

<http://www.debian.org/doc/debian-policy/ch-binary.html#s-maintscripts>

All packages which supply an instance of a common command name (or, in
general, filename) should generally use update-alternatives, so that
they may be installed together. If update-alternatives is not used,
then each package must use Conflicts to ensure that other packages
are de-installed.


Seems like a match to me.  git.deb and cogito.deb both supply an
instance of a common command name (/usr/bin/git).  So shouldn't I use
update-alternatives?


The only other mention I found of update-alternatives was in Appendix
F of the Policy Manual, here:

<http://www.debian.org/doc/debian-policy/ap-pkg-alternatives.html>

Appendix F is marked as being "from old Packaging Manual".  The wording
here suggests that in order to use update-alternatives, the alternatives
need to "do the same thing" (like nvi and vim, for example).  This seems
to be in mild conflict with section 3.10: 3.10 talks about filename
conflicts without mentioning "interfaces" (which I take to mean the
"purpose" of the program or file).


So, I'm proposing this:

GNU Interactive Tools installs /usr/bin/git.shell (or something)

Cogito installs /usr/bin/git.scm (or something)

update-alternatives is used to make one of those appear as
/usr/bin/git


The same thing could be done for /usr/bin/cg, which is a name used by
cogito's upstream and the cgvg.deb package.


People who just want GNU Interactive Tools get what they want.  People who
just want Cogito get what they want.  People who want both have to learn
a new name for one of them.  Seems good to me.  Am I missing anything?


Calling Ian Beckwith (git maintainer) and Sergio Talens-Oliag (cgvg
maintainer): what do you think of this proposal?


-- 
Sebastian Kuzminsky


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

Re: shouldn't I use update-alternatives for this?

[Sebastian Kuzminsky]

Petter Reinholdtsen <[EMAIL PROTECTED]> wrote:
> [Marco d'Itri]
> > Reality? git is the kernel SCM and GNU Interactive Tools is an
> > obscure package, and you should just install /usr/bin/git.
> > If the GNU Interactive Tools maintainer refuses to rename the other
> > program then just conflict with it.
> 
> Ah, conflict resolution by the use of force.  The method seem to gain
> popularity in the world today, but I do not recommend it.
> 
> It is is not obvious which tool is more obscure, as this will differ
> from user group to user group.  It is a better idea for the
> maintainers to try to reach an agreement, and perhaps to discuss the
> choice of name with upstream as well, to try to make the choosen name
> used in other distros.

The "just conflict" idea is what I naively did first, and got flamed
right here on debian-devel. [1]

I've pushed the "rename it upstream" idea on the upstream maintainers
twice now and it gets shut down by both Linus (the original author)
and Junio (the current maintainer). [2]

update-alternatives seems like it would work but it's apparently not
supposed to used unless the programs that share a name also do the
same thing.

Qingning Huo suggested using diversions to make /usr/bin/git a little
selector script that lets the admin & user choose between git-the-shell
and git-the-scm.  This sounds good to me, who objects?


[1]: http://lists.debian.org/debian-devel/2005/06/msg00909.html

[2]: http://marc.theaimsgroup.com/?l=git&m=112371729330066&w=2


-- 
Sebastian Kuzminsky


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

Re: shouldn't I use update-alternatives for this?

[Sebastian Kuzminsky]

Qingning Huo <[EMAIL PROTECTED]> wrote:
> I suggest dpkg-divert /usr/bin/git, and install a shell script as
> /usr/bin/git, which will invoke either program depending on a certain
> environment variable[1] or a configuration file.  It is possible to achieve
> the following objectives.
> 
> (1) Installing cogito will not change the meaning of /usr/bin/git by
> default;
> 
> (2) System admin can decide a default preference of /usr/bin/git,
> through e.g. /etc/git.rc;
> 
> (3) Each user can choose her/his own preference by e.g. ~/.gitrc;
> 
> (4) cogito on Debian works the same as on other systems.

This sounds like a great suggestion, thank you very much.

In this thought experiment, the cogito package would do this:

1.  Install its git as /usr/bin/git.scm (or something).

2.  Divert GNU Interactive Tools' /usr/bin/git to /usr/bin/git.shell
(or something).

3.  Install something like this as /usr/bin/git (written in the
mailer, not tested):
#!/bin/sh
GIT=/usr/bin/git.scm
[ -f /etc/git-selector   ] && source /etc/git-selector
[ -f $HOME/.git-selector ] && source $HOME/.git-selector
exec $GIT

4.  Typical /etc/git-selector, set via debconf on install of cogito:
#GIT=/usr/bin/git.scm
GIT=/usr/bin/git.shell

5.  Typical $HOME/.git-selector, set by user:
GIT=/usr/bin/git.scm
#GIT=/usr/bin/git.shell


Wow, this seems like a really nice save -- I especially like objective 4.

I changed the names git.rc and .gitrc, as those might reasonably be
taken by the upstream package(s).

Does this solution seem acceptable to everyone?


-- 
Sebastian Kuzminsky


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