Re: Work done on the WNPP front

[Matej Vela]

David Moreno Garza <[EMAIL PROTECTED]> writes:

[...]
> A fourth shoot was intended a couple of minutes ago on the ITA bugs. The
> ITAs were a little bit different. Since they represent existing
> packages, the mechanism used here was intended to close bugs, but
> retitling into O. ITAs are a very sensitive part of the WNPP chunk. An
> automatic retitling for ITAs with an inactivity greater than 250 days
> was launched, but it didn't return any bug retitled, which is great
> since at least this shows there is some activity on the BTS regarding
> these bugs.

You can eliminate most of the noise by taking into account only messages
from the prospective adopter (i.e. the owner of the WNPP bug).  See
~vela/ita-age.pl on merkel for a sample implementation; as of today it
lists 20 ITAs older than 250 days.

However, there is an important gotcha with retitling ITAs: currently we
have no reliable way to determine whether the package was previously up
for adoption (RFA) or orphaned (O).

The natural solution is to migrate WNPP bugs to BTS tags.  If I'm
remembering correctly, Anthony Towns talked on IRC about using
orphaned/up-for-adoption tags combined with pending to mark ITAs.
The expiry script would then simply remove the pending tag.

This would also prevent merged bugs from getting into conflicting states
since (unlike titles) they share a single set of tags (see #310181 for
an example of the problem).

Thanks,

Matej


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

subscribe

[Javier E. Perez P.]

-- 
Javier E. Perez P. (aka dvst)
GPG KeyID: 441C47B4
fingerprint = AB52 DC66 A8A3 2E93 59E4  87E0 372D 91FD 441C 47B4
Maracay - Venezuela


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

Bug#331325: ITP: xfce4-cpufreq-plugin -- cpufreq information plugin for the Xfce4 panel

[Stefan Ott]

Package: wnpp
Severity: wishlist
Owner: Stefan Ott <[EMAIL PROTECTED]>


* Package name: xfce4-cpufreq-plugin
  Version : 0.1
  Upstream Author : Joshua Kwan <[EMAIL PROTECTED]>
* URL : http://triplehelix.org/blog/
* License : BSD
  Description : cpufreq information plugin for the Xfce4 panel

 This plugin displays the current frequency of the CPU, in GHz or MHz as
 necessary. It also displays the frequency relative to the maximum CPU
 frequency as an accordingly colored progress bar.
 .
 Homepage: http://triplehelix.org/blog/

-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (650, 'testing'), (600, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.13.1
Locale: LANG=C, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8)


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

Bug#331319: ITP: ksubtile -- subtitle editor for KDE

[Isaac Clerencia]

Package: wnpp
Severity: wishlist
Owner: Isaac Clerencia <[EMAIL PROTECTED]>


* Package name: ksubtile
  Version : 1.1
  Upstream Author : Tom Deblauwe <[EMAIL PROTECTED]>
* URL : http://ksubtile.sourceforge.net
* License : GPL
  Description : subtitle editor for KDE

 This editor is capable of moving, stretching, joining, editing and
 creating SRT subtitle files.  It is capable of using MPlayer to help
 you sync and edit the subtitles with a particular movie.

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


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

Re: Bug#331287: ITP: criawips -- full featured presentation tool

[Ben Pfaff]

David Moreno Garza <[EMAIL PROTECTED]> writes:

> Criawips aims to become a full featured presentation application 
> that offers the perfect platform both for small presentations 
> used to explain a few things to other people and for big 
> presentations used for commercial presentations.
>
> Thus it should become easy to use, provide a good integration
> with other applications to become a presentation platform that
> can compete with commercial applications like MS PowerPoint,
> OpenImpress and Apple's Keynote.

That's a good description of what the program plans to be in the
future.

What is it now?
-- 
"Then, I came to my senses, and slunk away, hoping no one overheard my
 thinking."
--Steve McAndrewSmith in the Monastery


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

Re: Everyone go test aptitude 0.3.4!

[Steve Langasek]

On Sun, Oct 02, 2005 at 03:37:53PM +0200, Bernd Schubert wrote:

> >>   I suppose so -- it'll probably take a while before the translations are
> >> ready anyway.  When do you think apt 0.6.41 and its related packages will
> >> go in?

> > Not until gcc-4.0 and perl are both updated in testing, which block much
> > of
> > the archive from being updated right now.  gcc-4.0 is blocked mainly by
> > kaffe at this point; perl is blocked by the yet-unresolved testsuite
> > failures on arm and m68k.


> May I kindly ask first to solve the critical bugs in apt-0.6.x

The what?

> I reported a bug several weeks ago and didn't get the slightest response.

You filed a single severity: important bug against apt.  Regardless of
whether you got an answer, this doesn't qualify as "critical".

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Bug#331287: ITP: criawips -- full featured presentation tool

[David Moreno Garza]

Package: wnpp
Severity: wishlist
Owner: David Moreno Garza <[EMAIL PROTECTED]>

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: criawips
  Version : 0.0.11
  Upstream Author : Sven Herzberg <[EMAIL PROTECTED]>
* URL : http://www.nongnu.org/criawips
* License : GPL
  Description : full featured presentation tool

Criawips aims to become a full featured presentation application 
that offers the perfect platform both for small presentations 
used to explain a few things to other people and for big 
presentations used for commercial presentations.

Thus it should become easy to use, provide a good integration
with other applications to become a presentation platform that
can compete with commercial applications like MS PowerPoint,
OpenImpress and Apple's Keynote.

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

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

iD8DBQFDQEAQmBxf18ZxJX0RAldjAKCR6THb+NLq8GCL/APUOhotGD7MogCeKsGE
0fZKGOn/Dwpc7S5ye1Gwq/k=
=Khii
-END PGP SIGNATURE-


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

Re: time seen at top of /var/log/boot

[Anthony DeRobertis]

Dan Jacobson wrote:

> No its not my BIOS time. It appears to be a timezone 4 timezones east
> of New Zealand, GMT+16, i.e., out of this world. How about on your machine?

[EMAIL PROTECTED]:anthony$ perl -nwe 'next unless /Setting the System
Clock/../System Clock set/; s/: S.*//;print' /var/log/boot
Sat Oct  1 09:45:42 2005
Sat Oct  1 09:45:43 2005
Sat Oct  1 09:46:11 2005
Sat Oct  1 09:46:11 2005


[EMAIL PROTECTED]:~$ perl -nwe 'next unless /Setting the System
Clock/../System Clock set/; s/: S.*//;print' /var/log/boot
Tue Sep 20 18:55:35 2005
Tue Sep 20 18:55:37 2005
Tue Sep 20 18:56:27 2005
Tue Sep 20 18:56:28 2005


Both of these, I think, are local time.


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

Bug#331268: ITP: loop-aes-modules -- auto-build loop-AES binary modules

[Max Vozeler]

Package: wnpp
Owner: Max Vozeler <[EMAIL PROTECTED]>
Severity: wishlist

* Package name: loop-aes-modules
  Version : 3.0d+3.0b+1
  Upstream Author : Max Vozeler <[EMAIL PROTECTED]>
* URL : http://svn.decl.org/public/loop-aes-modules
* License : GPL
  Description : auto-build loop-AES binary modules (deb and udeb)

This package auto-builds loop-AES binary module packages for a
configurable list of kernels and archs (currently 2.6.12).

The module packages are required to support installing onto
loop-AES encrypted partitions in debian-installer. This needs an 
udeb for the d-i kernel in first stage and a module package that
can be installed before booting into second stage.

I would appreciate feedback/review from people with experience
auto-building external modules.

cheers,
Max

--
(There was a promising discussion on debian-kernel recently about
a common framework for auto-building external modules. The need for
this package will likely go away once that framework can be used.)


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

ITP, RFH: pcsx -- Sony PlayStation emulator

[Ryan Schultz]

reopen 137355
retitle 137355 ITP: pcsx -- Sony PlayStation emulator
owner 137355 !
thanks bts, daisuki da yo

Package: wnpp
Owner: Ryan Schultz <[EMAIL PROTECTED]>
Severity: wishlist

* Package name: pcsx
  Version : 1.6f
  Upstream Authors : Ryan Schultz <[EMAIL PROTECTED]>
Linuzappz <[EMAIL PROTECTED]>
Shadow<[EMAIL PROTECTED]>
Pete Bernett  <[EMAIL PROTECTED]>
NoComp<[EMAIL PROTECTED]>
Nik3d
Akumax<[EMAIL PROTECTED]>

* URL : http://www.pcsx.net, http://rschultz.ath.cx/code.php
* License : GPL
  Description : Sony PlayStation emulator
 PCSX is an advanced PlayStation (PSX) emulator, which uses a plugin
 architecture to provide full support for all components of the PSX.
 It has full emulation support for gamepads, videos, sound, memory cards,
 and other important PSX components, and is able to play most games.
 .
 You will need to install packages providing psemu-plugin-video,
 psemu-plugin-sound, psemu-plugin-input, and psemu-plugin-drive
 in order to use PCSX.

-- Summary & Notes --

debian-legal:
   PCSX is a quagmire, legally -- many of the files are copyrighted to authors 
that are missing, etc. -- however, investigative work :- ) by Matthew Dempsky 
and Frederic Briere has helped to track down the owners of nearly all of the 
files and proper license info is available (see especially 
http://www.ngemu.com/forums/showthread.php?t=45525 as well as the earlier 
discussion in this bug). Please take a look and I'll try to clarify ownership 
on any of the files, if I can. Please CC me or the bug, as I'm not subscribed 
to -legal.

RFP and ITP (-devel and CCs):
   The program itself is also a nightmare. Upstream is busy with PCSX2, a 
PlayStation 2 emulator, and has left PCSX with just a beta release. The 
emulator code does not compile with GCC 4, due mostly to invalid lvalues -- 
which aren't easily fixed, as they're buried in uncommented #define macros. 
Most of the code is uncommented, in fact. 

   The GTK2 frontend works well, but makes bad assumptions about where it is 
running, dumps files in the directory it runs from, doesn't search any 
specific system directory for plugins, and is generally unkind. Much of this 
has been alleviated by some clever wrapper scripting by F. Briere in his 
packages, but this shouldn't be required. 

   I'm not a C or a GTK programmer (not a good one, at least), and I'm not 
familiar with system emulation. However, I'm trying to beat this program into 
shape for Debian. I've already got it to search a system directory for 
plugins (but it's a hardcoded hack at the moment) and I've made the GUI a bit 
nicer to use. I gave the lvalue problems a shot but I couldn't get them fixed 
without causing more errors, and I have a -2 to my pointer casting skills 
anyway (from being a Python programmer). The version I'm working on is called 
'pcsx-df' where 'df' is 'Debian fork' (fork is not a dirty word). I'm 
maintaining my own version until I get something less hackish to send back 
upstream. 

Enough about the code. The Debian package I'm working on is based 
primarily on the work done by F. Briere, and I've already gotten all of the 
lintian warnings squashed. You'll want to add his archive if you're using my 
package, since it still needs the psemu plugins, which I've not yet started 
working on. Additionally, they cannot be configured from the GTK2 GUI with 
the pcsx-df 1.6f codebase, because the routine that launches the 
configuration program makes location assumptions (grrr...), and I've not been 
able to find it to fix these. You'll also want to run pcsx.real, as the pcsx 
wrapper script is now partly redundant. mkdir -p ~/.pcsx/memcards before 
running pcsx.real or you'll have problems configuring.

---

   Now, some information about the where to get code and packages:

Upstream:
   http://www.pcsx.net

F. Briere's work, including the psemu plugins:
   deb http://www.fbriere.net/debian/dists/unstable psx-emu/
   deb-src http://www.fbriere.net/debian/dists/unstable psx-emu/

My (temporary) Darcs repository, better one coming soon, but you can 'get' the 
pcsx-df 1.6f source:
http://rschultz.ath.cx/cgi-bin/darcs.cgi/pcsx-df/?c=browse
darcs get http://rschultz.ath.cx/repos/pcsx-df

A snapshot of the darcs repo:
http://rschultz.ath.cx/files/pcsx-df.tar.gz

My (only marginally functional, at the moment) PCSX-df package (it is named 
pcsx, not pcsx-df)
deb http://rschultz.ath.cx/debian unstable/i386/
deb-src http://rschultz.ath.cx/debian unstable/source/

- Final Notes --

Anyone looking for a minor packaging/major programming challenge, here it 
is. I'm more than willing to start handing out darcs access to pcsx-df to 
anyone who wants to help, and I'd really like a co-maintainer (F. 

Re: Accepted aptitude 0.3.4-1 (source all i386)

[Steve Greenland]

On 02-Oct-05, 09:34 (CDT), "Bernhard R. Link" <[EMAIL PROTECTED]> wrote: 
> * Joey Hess <[EMAIL PROTECTED]> [051002 05:57]:
> > >  - The password database is used instead of $HOME to determine where
> > >aptitude's configuration file goes, so people using sudo don't end 
> > > up
> > >with root-owned mode 0700 files in their home directory.
> > >(Closes: #272429, #274216, #285334, #272409)
> > 
> > Well, aptitude and debconf both it seems. Which suggests to me this is a
> > larger problem. Also note that I got just as many bugs reports after I
> > made debconf do this as I was able to close by doing it. :-/
> 
> This is not really a larger problem, but just a problem in sudo.

Not really: sudo -H aptitude

Steve

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net


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

Re: bogus lintian warning

[Henning Makholm]

Scripsit Colin Watson <[EMAIL PROTECTED]>

> Sure you can. Lintian could (relatively) easily check whether the
> problem is in the .orig.tar.gz before application of the Debian diff,
> and suppress the message in that case.

Better yet: Warn if
  (there are CVS directories in the .diff.gz)
  OR ((there are CVS directories in the .orig.tar.gz)
  AND (the .orig.tar.gz unpacks into packagename-version.orig/))

If one has reason to repackage the source archive, one may as well get
rid of cruft such as CVS directories.

-- 
Henning Makholm   "You propose to avoid dying? I will be
 interested to hear the method you plan for this endeavour."


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

Re: bogus lintian warning

[Henrique de Moraes Holschuh]

On Sun, 02 Oct 2005, Thomas Bushnell BSG wrote:
> Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes:
> > On Sun, 02 Oct 2005, Thomas Bushnell BSG wrote:
> >> Easily caught: check to make sure the CVS files are not in the
> >> .orig.tz before complaining.
> >
> > You keep assuming the bogus stuff ends up in the diff. It once happened to
> > me that it ended up on the .orig.tar.gz, but I don't recall exactly what
> > kind of fuckup I did (but it was a realy weird one).
> 
> Presumably you didn't keep the unmodified source as the .orig.tar.gz.

Most probably. 

> I don't know how or why, since the correct way to generate the
> .orig.tar.gz file is to use the CP or MV commands (or the equivalent),
> which do not change tar archives in the process.

Yes.  As I said, it was an accidental *error* and not deliberate action due
to me not knowing any better (in which case I would certainly recall the
embarassing details :( ).

> It is a bad thing to generate warnings which must be ignored 99.9% of
> the time.

I believe in this particular case, many believe it is wrong to have CVS dirs
on distribution tarballs, and the warning also serves to remind them to talk
to upstream about it.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: Accepted aptitude 0.3.4-1 (source all i386)

[Henning Makholm]

Scripsit "Bernhard R. Link" <[EMAIL PROTECTED]>
> * Joey Hess <[EMAIL PROTECTED]> [051002 05:57]:

>> >  - The password database is used instead of $HOME to
>> >  determine where aptitude's configuration file goes, so
>> >  people using sudo don't end up with root-owned mode 0700
>> >  files in their home directory.  (Closes: #272429, #274216,
>> >  #285334, #272409)
 
>> Also note that I got just as many bugs reports after I made debconf
>> do this as I was able to close by doing it. :-/

> This is not really a larger problem, but just a problem in sudo.

I'm not even sure it is the right problem. On a machine where several
people share the administration workload, each may well have his own
preferences with respect to aptitude's UI. Storing the configuration
in $HOME rather than using getpwuid allows that nicely.

Yes, it is ugly to have a root-owned 700 directory in $HOME.
Perhaps a better fix would be to just chown $HOME/.aptitude and
$HOME/.aptitude/config to the owner of $HOME when they are created
(resp. written to).

-- 
Henning Makholm"Nej, hvor er vi altså heldige! Længe
  leve vor Buxgører Sansibar Bastelvel!"

Re: bogus lintian warning

[Henrique de Moraes Holschuh]

On Sun, 02 Oct 2005, Thomas Bushnell BSG wrote:
> Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes:
> >> No; it should not report uncorrectible warnings.
> > *IT* *IS* *NOT* *UNCORRECTIBLE*.   If you have a good reason to, you can and
> > should correct it.  You are just not supposed to do it just to shut lintian
> > up, use an override for that.
> 
> I'm sorry, how can I correct it?
> 
> Keep in mind here that it is not allowed to change the .orig.tar.gz
> for cosmetic issues.  This is a purely cosmetic issue if I ever did
> see one.

First, it is techinically possible to correct it, so it is not
"incorrectible" technically speaking.  If it were, the warning would still
not be useless, as one might decide to refrain from uploading the package,
or to add extra code in debian/rules to fix it.

Second, I wrote: "if you have a good reason to, you can and should correct
it.  You are just not supposed to do it just to shut lintian up, use an
override for that."  What part of it says one should do it for purely
cosmetic issues?  I have already tried to explain which issues would not be
purely cosmetic and would warrant a fix.

If your upstream always adds CVS dirs and the package builds fine and does
not leak those dirs to binary packages, then just override the warning, or
ignore it.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: Everyone go test aptitude 0.3.4!

[Guilherme de S. Pastore]

Em Sáb, 2005-10-01 às 21:43 -0400, Travis Crump escreveu:
> That's the stale 0.3.3 aptitude, looks like the new one won't hit the
> archives til tomorrow[or it needs to be autobuilt]...

The dinstall run will happen in approximately 4h30, according to
http://people.debian.org/~joerg/dinstall.html =D

Regards,

-- 
Guilherme de S. Pastore (fatalerror)
<[EMAIL PROTECTED]>


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

Re: Accepted aptitude 0.3.4-1 (source all i386)

[Bernhard R. Link]

* Joey Hess <[EMAIL PROTECTED]> [051002 05:57]:
> >  - The password database is used instead of $HOME to determine where
> >aptitude's configuration file goes, so people using sudo don't end up
> >with root-owned mode 0700 files in their home directory.
> >(Closes: #272429, #274216, #285334, #272409)
> 
> Well, aptitude and debconf both it seems. Which suggests to me this is a
> larger problem. Also note that I got just as many bugs reports after I
> made debconf do this as I was able to close by doing it. :-/

This is not really a larger problem, but just a problem in sudo.
Using getpwuid to get the home-directory is compareable to hard-coding
/root. (Hardcoding /root is even a bit cleaner, as it might not lure
people into using it when not working around bugs in sudo).

Hochachtungsvoll,
  Bernhard R. Link


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

Re: bogus lintian warning

[Thomas Bushnell BSG]

Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes:

> On Sun, 02 Oct 2005, Thomas Bushnell BSG wrote:
>> Easily caught: check to make sure the CVS files are not in the
>> .orig.tz before complaining.
>
> You keep assuming the bogus stuff ends up in the diff. It once happened to
> me that it ended up on the .orig.tar.gz, but I don't recall exactly what
> kind of fuckup I did (but it was a realy weird one).

Presumably you didn't keep the unmodified source as the .orig.tar.gz.

I don't know how or why, since the correct way to generate the
.orig.tar.gz file is to use the CP or MV commands (or the equivalent),
which do not change tar archives in the process.

It is a bad thing to generate warnings which must be ignored 99.9% of
the time.


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

Re: bogus lintian warning

[Thomas Bushnell BSG]

Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes:

>> No; it should not report uncorrectible warnings.
>
> *IT* *IS* *NOT* *UNCORRECTIBLE*.   If you have a good reason to, you can and
> should correct it.  You are just not supposed to do it just to shut lintian
> up, use an override for that.

I'm sorry, how can I correct it?

Keep in mind here that it is not allowed to change the .orig.tar.gz
for cosmetic issues.  This is a purely cosmetic issue if I ever did
see one.

Thomas


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

Re: bogus lintian warning

[Henrique de Moraes Holschuh]

On Sun, 02 Oct 2005, Thomas Bushnell BSG wrote:
> Easily caught: check to make sure the CVS files are not in the
> .orig.tz before complaining.

You keep assuming the bogus stuff ends up in the diff. It once happened to
me that it ended up on the .orig.tar.gz, but I don't recall exactly what
kind of fuckup I did (but it was a realy weird one).

> > And it also tells you when upstream screwed up their dist-clean target,
> > which is quite useful too.
> 
> No; it should not report uncorrectible warnings.

*IT* *IS* *NOT* *UNCORRECTIBLE*.   If you have a good reason to, you can and
should correct it.  You are just not supposed to do it just to shut lintian
up, use an override for that.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: please upload gal0.x-0.24-2

[Thomas Bushnell BSG]

Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:

> The build of gal0.x-0.24-2 is complete on alpha, i386, mips, and
> mipsel, but has not been uploaded to the archive.  Users are starting
> to notice and complain.  Can you please upload them ASAP?  Thanks.

Whoops, there's a dangling antecedent if I ever did see one!  Of
course, I meant to upload the packages, not the users. :)

Thomas


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

Re: Everyone go test aptitude 0.3.4!

[Bernd Schubert]

> 
>>   I suppose so -- it'll probably take a while before the translations are
>> ready anyway.  When do you think apt 0.6.41 and its related packages will
>> go in?
> 
> Not until gcc-4.0 and perl are both updated in testing, which block much
> of
> the archive from being updated right now.  gcc-4.0 is blocked mainly by
> kaffe at this point; perl is blocked by the yet-unresolved testsuite
> failures on arm and m68k.
> 

May I kindly ask first to solve the critical bugs in apt-0.6.x and then
upload it to Etch? I mean, I reported a bug several weeks ago and didn't
get the slightest response.

Thanks,
Bernd


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

please upload gal0.x-0.24-2

[Thomas Bushnell BSG]

The build of gal0.x-0.24-2 is complete on alpha, i386, mips, and
mipsel, but has not been uploaded to the archive.  Users are starting
to notice and complain.  Can you please upload them ASAP?  Thanks.

Thomas


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

Re: bogus lintian warning

[Thomas Bushnell BSG]

Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes:

> dpkg-buildpackage in a cvs-checkout directory with strange things in the
> parent dir, for example, because of test builds leaving weird shit on the
> parent directory + lack of coffee + typing dpkg-buildpackage instead of
> cvs-buildpackage.  

Easily caught: check to make sure the CVS files are not in the
.orig.tz before complaining.

> It gets "I was too sleepy to think straight" type of errors.
>
> And it also tells you when upstream screwed up their dist-clean target,
> which is quite useful too.

No; it should not report uncorrectible warnings.


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

Re: bogus lintian warning

[Colin Watson]

On Sun, Oct 02, 2005 at 03:07:51AM -0300, Henrique de Moraes Holschuh wrote:
> On Sat, 01 Oct 2005, Thomas Bushnell BSG wrote:
> > But lintian is not there to warn about unfixable problems with
> 
> You cannot reliably determine wether the maintainer is doing something
> stupid, or upstream is.

Sure you can. Lintian could (relatively) easily check whether the
problem is in the .orig.tar.gz before application of the Debian diff,
and suppress the message in that case.

Cheers,

-- 
Colin Watson   [EMAIL PROTECTED]


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

Re: bogus lintian warning

[Colin Watson]

On Sat, Oct 01, 2005 at 06:59:19PM +0100, Roger Leigh wrote:
> Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:
> > Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes:
> >> Or those who screw up and add it to a non-orig .orig.tar.gz (and by that I
> >> do NOT mean a modified upstream one, I mean a re-generated tarball during
> >> build because someone screwed up).
> >>
> >> 99.9% of the time, one just ignores these lintian warnings as one knows it
> >> comes from the upstream tarball.
> >
> > I'd rather not have warnings that must be ignored 99.9% of the time.
> 
> You could add a lintian override.

Lintian overrides should only be used when a package is an exception to
an otherwise-generally-applicable Lintian message, not when the Lintian
message is basically wrong and should be removed. In this case, I
completely agree that the warning is bogus; it might be less so if it
were modified to check that the CVS directories are in the .diff.gz
rather than just somewhere in the unpacked source.

Cheers,

-- 
Colin Watson   [EMAIL PROTECTED]


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

Re: renaming mysql++

[Henning Glawe]

On Sun, Oct 02, 2005 at 01:17:12PM +0200, Henning Makholm wrote:
> Scripsit Henning Glawe <[EMAIL PROTECTED]>
> 
> > one minor point would be "apt-get install" interpreting + and -
> > appended to package names for manual conflict resolution.so "apt-get
> > install ... libmysql++ ..." could have different meanings in
> > different context
> 
> It wouldn't matter for a library package, because the ++ would be
> followed by the soname, e.g. "libmysql++1".

yes, you're right.

-- 
c u
henning


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

Re: Circular testing excuses for swt-gtk and swingwt

[Steve Langasek]

On Wed, Sep 28, 2005 at 11:02:59AM -0600, Shaun Jackman wrote:
> I am trying to help move swt-gtk into testing. The excuses [1] for
> swingwt, which depends on swt-gtk, says...

> * swingwt is waiting for swt-gtk
>   * Updating swt-gtk makes 2 depending packages uninstallable on arm:
> libswingwt0, swingwt-demo

> These excuses seem to be circular between swingwt and swt-gtk. Why
> does updating swt-gtk make swingwt uninstallable on arm?

Because unless otherwise hinted by the release team, source packages are
considered for testing one at a time, and the binary package names for
swt-gtk changed from libswt-gtk3* to libswt-gtk-3.1*.  So updating swt-gtk
removes the library that swingwt depends on.

> To aggravate the matter, swingwt is failing to build on three architectures:
>   alpha: unmet dependencies: libswt-gtk-3.1 (= 3.0+3.1M4-5)
>   hppa: gcj 4.0.1 ICE (internal compiler error)
>   sparc: unmet dependencies: libswt-gtk-3.1 (= 3.1-1)

> Both alpha and sparc have now built libswt-gtk-3.1 (= 3.1-2), so those
> two unmet dependencies errors should go away I hope.

They probably will, but there's not much sense in having them retry the
build unless hppa is also fixed, since you would just need to make another
upload for hppa.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: renaming mysql++

[Henning Makholm]

Scripsit Henning Glawe <[EMAIL PROTECTED]>

> one minor point would be "apt-get install" interpreting + and -
> appended to package names for manual conflict resolution.so "apt-get
> install ... libmysql++ ..." could have different meanings in
> different context

It wouldn't matter for a library package, because the ++ would be
followed by the soname, e.g. "libmysql++1".

-- 
Henning Makholm"What a hideous colour khaki is."


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

Re: Advices needed for moving {add|remove}-shell from passwd to debianutils

[Peter Samuelson]

[Christian Perrier]
> Peter Samuelson mentioned passwd being Essential because it depends
> on passwd. This is actually right. However this dependency is just
> the consequence of bash needing the add-shell and remove-shell
> utilities...so, in the future, bash shouldn't depend on passwd
> anymore.

Right, but the point is, *right now* both passwd and debianutils are
Essential.  This should prevent either from being removed from a
running system - if debianutils Conflicts/Replaces an old passwd before
the new passwd is in the archive, dpkg should refuse to upgrade to it.

And, maybe I'm just dense, but your plan appears to have the same race
condition, for new installs.


signature.asc
Description: Digital signature

Re: renaming mysql++

[Henning Glawe]

On Tue, Sep 27, 2005 at 09:41:45AM -0400, Andres Salomon wrote:
> I intend to rename the binary packages for mysql++ with the upload of 2.0.5.
> They've been called libsqlplus* for a while now, which isn't overly
> intuitive (I've had multiple people not realize mysql++ was packaged for
> debian, due to the name).  My choices are either libmysqlpp* (to match
> the library name) or libmysql++*.  Does anyone have any preferences, or 
> any reasons why I shouldn't use ++ in the package name?  Given that g++
> does it, and policy explicitly allows '+', I can't think of any reasons
> not to name it libmysql++*.

one minor point would be "apt-get install" interpreting + and - appended to
package names for manual conflict resolution.so 
"apt-get install ... libmysql++ ..." could have different meanings in different
context

1. there is a package called libmysql++:
  install the package
2. there is no package with that name:
  prefer the package called 'libmysql+' (note the single plus in the end !)
  for resolving packages in the given command line...

this is not a _real_ technical problem, but it is a bit ugly (I have
implemented a package-availability checker using libapt-pkg-perl for FAI and
exactly this ambiguity caused headaches and/or unnecessairily complex code).

Basically, I can't understand the following thing:
- why it's not forbidden by policy to use these characters as the end of a 
  packagename when they have a special meaning on the apt commandline ?
- or why is apt's command line interpreter changed to a different syntax for
  these special operations if + and - are allowed as the last character of a
  package name ?

-- 
c u
henning


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

Re: Bug#331072: ITP: cinelerra-cvs -- non-linear video editor and compositor for Linux.

[Adrian von Bidder]

On Saturday 01 October 2005 17.07, Andreas Kuckartz wrote:
> But your reaction proves that the name "cinelerra-cvs" is misleading.

But IMHO that's not something the Debian packager can do anything other than 
write it in the description.  Renaming the package would only confuse users 
searching for "Cinelerra CVS".

cheers
-- vbi

-- 
Wenn ein Politiker stirbt, kommen viele zur Beerdigung nur deshalb, um
sicher zu sein, daß man ihn wirklich begräbt.
-- Georges Clemenceau


pgprxRG2GLev9.pgp
Description: PGP signature

Re: Everyone go test aptitude 0.3.4!

[Marc Haber]

On Sun, 2 Oct 2005 02:57:43 +0200, "Steinar H. Gunderson"
<[EMAIL PROTECTED]> wrote:
>Am I missing something here?
>
>baby:~> LANG=C sudo aptitude -t experimental install aptitude

The package is in incoming, you cannot apt it yet.

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: How to generate a patch?

[Lars Wirzenius]

su, 2005-10-02 kello 09:20 +0200, Petter Reinholdtsen kirjoitti:
> [Robert Epprecht]
> > I have a suggestion for a new feature of a program which I'd like to
> > sent to the author. What is the exact command to generate the patch
> > in the usual format?
> 
> This was answered on the list not too long ago.  Use for example
> 'diff -ur original yourver' to get the patch between the original and
> your version.

If you have added new files, add the -N option to diff. Before you do
the diff, clean out any files that can be built by make so that changes
to them are not included unnecessarily in the patch. The patch should be
minimal and as easily readable as possible as a plain text file.

If you use CVS, "cvs diff -u" should do the trick. Other version control
systems have a similar command.


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

Re: gal0.x not being added to archive?

[Loïc Minier]

Hi,

On Sat, Oct 01, 2005, Thomas Bushnell BSG wrote:
> 
> Why is gal0.x not being added to the archive on alpha, i386, mips, and
> mipsel?  According to the buildd logs, it compiled successfully on all
> those archs over ten days ago.
> 
> It was uploaded for all the other archs.

 I think this is the same problem as:


   Cheers,
-- 
Loïc Minier <[EMAIL PROTECTED]>


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

Re: How to generate a patch?

[Petter Reinholdtsen]

[Robert Epprecht]
> I have a suggestion for a new feature of a program which I'd like to
> sent to the author. What is the exact command to generate the patch
> in the usual format?

This was answered on the list not too long ago.  Use for example
'diff -ur original yourver' to get the patch between the original and
your version.


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

How to generate a patch?

[Robert Epprecht]

I have a suggestion for a new feature of a program which I'd like to
sent to the author. What is the exact command to generate the patch
in the usual format?

Sorry, for the very basic question ;-)
Robert


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