In several mails you claimed testing as broken. This is completely
orthognal to my experience. I'm using testing since its existence
on most of my boxes.
I use it on some boxes too, however, mostly the snapshots from the
half-year before-stable period of time. Attempts to use much sooner
s
On Wed, 16 May 2007, Mgr. Peter Tuharsky wrote:
Don't remember, not too much. However, if hundred of packages had broken
deps,
This statement is definitely wrong.
where would You report the bug? I'm not too experienced with apt and I
hate hacking around it.
There is no need to hack around
[Christine Spang]
> I'll maintain powertop if you're looking to get rid of it. I have a
> new package for 1.2 sitting on my machine right now, just waiting to
> get an "okay" before I upload.
Great to hear. I already got offers from Patrick Winnertz and Jose
Luis Rivas Contreras, who plan to co-m
On Wed, May 16, 2007 at 08:10:44AM +0200, Martin Zobel-Helas wrote:
> as a QA effort the whole archive was rebuilt yesterday to catch
> build-failures, whether a package can be build twice in a row (unpack,
> build, clean, build). We found about 400 packages not having a sane
> clean target.
Wow,
On Wednesday 16 May 2007 09:11, Mgr. Peter Tuharsky wrote:
> I'd say, half of problems with testing were connected to bugs in
> installer.
This statement really wants some qualifications...
The official releases (beta and RC) of the installer for testing have had
no really serious bugs, though t
Hi,
On Wed May 16, 2007 at 10:11:55 +0200, Stefano Zacchiroli wrote:
> On Wed, May 16, 2007 at 08:10:44AM +0200, Martin Zobel-Helas wrote:
> > as a QA effort the whole archive was rebuilt yesterday to catch
> > build-failures, whether a package can be build twice in a row (unpack,
> > build, clea
On Wed, 16 May 2007, Stefano Zacchiroli wrote:
> I mean, packages that fail to build the second time have for
> sure garbage left around after the former invocation of "clean".
Not always. In some cases (for example, two of my packages) the error
was to modify a .po file "in place" to update it.
On Wed, 16 May 2007, Stefano Zacchiroli wrote:
Wouldn't it be better to unpack a package twice in two different
directories, build and clean in one dir and then compare the obtained
tree with the tree available in the other dir?
I personally store the diff.gz from first build and compare with
* Santiago Vila [Wed, 16 May 2007 10:52:02 +0200]:
> Not always. In some cases (for example, two of my packages) the error
> was to modify a .po file "in place" to update it. The second time
> you build the package, dpkg-source complains about the .mo files,
> as they are binary files and they hav
On Wed, May 16, 2007 at 10:11:55AM +0200, Stefano Zacchiroli wrote:
> Wouldn't it be better to unpack a package twice in two different
> directories, build and clean in one dir and then compare the obtained
> tree with the tree available in the other dir?
IMHO, a good test would be to build the
On Wed, May 16, 2007 at 11:12:56AM +0200, Richard Atterer wrote:
> > Wouldn't it be better to unpack a package twice in two different
> > directories, build and clean in one dir and then compare the obtained
> > tree with the tree available in the other dir?
>
> IMHO, a good test would be to bu
On Wed, 16 May 2007 10:52:02 +0200 (CEST)
Santiago Vila <[EMAIL PROTECTED]> wrote:
> On Wed, 16 May 2007, Stefano Zacchiroli wrote:
>
> > I mean, packages that fail to build the second time have for
> > sure garbage left around after the former invocation of "clean".
>
> Not always. In some cases
On Tue, May 15, 2007 at 10:05:56PM -0400, Felipe Sateler wrote:
> Roberto C. Sánchez wrote:
>
> > Well, the ~ character is stated to be evaluated to be less than the
> > empty string. If a package is the target of a security upload in
> > stable, you can be certain that the testing/unstable versi
On Wed, May 16, 2007 at 11:21:51AM +0200, Guus Sliepen wrote:
> On Wed, May 16, 2007 at 11:12:56AM +0200, Richard Atterer wrote:
>
> > > Wouldn't it be better to unpack a package twice in two different
> > > directories, build and clean in one dir and then compare the obtained
> > > tree with th
Hi, Greg
You took it quite actively.
As many see, all of them are different in server and in desktop world,
and many times Debian chooses to dictate the users "we know the best
what You need" instead of listening to them.
Why then are there 28000+ packages in Debian? If Debian only dictates
I'm glad it works for You.
Peter
Greg Folkert wrote / napísal(a):
On Tue, 2007-05-15 at 21:43 +0200, Andreas Tille wrote:
On Tue, 15 May 2007, Mgr. Peter Tuharsky wrote:
We're going OT, however my experience based on last two Debian
releases:
testing becomes quite "stable in means of usab
I don't have enough knowledge to do that.
Peter
David Nusinow wrote / napísal(a):
On Tue, May 15, 2007 at 09:41:17AM +0200, Mgr. Peter Tuharsky wrote:
The kernel, the X.org
So are you volunteering to join the kernel and XSF teams to make this
happen?
- David Nusinow
--
To UNSUBSCRIBE
How long should bugs be tagged pending in advance of an upload?
Is it acceptable to tag a bug pending when fixed upstream and the
maintainer is confident of an upstream release in under a week? (This
is easy for me, I'm also upstream in many cases. :-))
Does it depend on the severity of the bug?
Haven't heard how libtruetype security upgrade caused OpenOffice.org,
Sorry, should be "libfreetype"
Peter
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
On Wednesday 16 May 2007, Mgr. Peter Tuharsky wrote:
> > Do you realize Debian's stable is classified as this:
> >
> > Stable means stable package list. No changes in API and ABI
> > names or versions. This means no newer versions will ever make
> > it into "stable". It is i
Hi all!
On Mit, 16 Mai 2007, Santiago Vila wrote:
> Not always. In some cases (for example, two of my packages) the error
> was to modify a .po file "in place" to update it. The second time
I agree. In texinfo I have the following problem
- upstream ships po/*.gmo
- debian patches patch the .po f
On Wed, May 16, 2007 at 01:12:30PM +0200, cobaco (aka Bart Cornelis) wrote:
> On Wednesday 16 May 2007, Mgr. Peter Tuharsky wrote:
> > > Do you realize Debian's stable is classified as this:
> > >
> > > Stable means stable package list. No changes in API and ABI
> > > names or versi
On Wednesday 16 May 2007 12:50, Neil Williams wrote:
> How long should bugs be tagged pending in advance of an upload?
For me "pending" is a signal to users saying "issue has been confirmed,
solution is available and will be included with the next upload".
It would IMO not be correct to mark a b
On Wednesday 16 May 2007, Neil Williams wrote:
> How long should bugs be tagged pending in advance of an upload?
To me pending means, a fix is applied and will be in the next upload/release
(hence no further triaging needed on this bug).
It says nothing about when the upload with the fix will ta
Hi, Andreas
Another hand, many problems were well-known by the time I met them,
there wasn't need to report them again.
So if there are really well-known "many problems" can you do me a favour
and list one or two here?
It's been in context, meant as "many of those problems" -a relative part
On Wed, 16 May 2007, Norbert Preining wrote:
Sounds like a hack. What do other say?
There are different opinions about orig.tar.gz should be equal
to upstream. I tend to the opinion that no precompiled stuff
that can be builded by the source has to be in orig.tar.gz and
in such cases I would
On Wed, 16 May 2007, Neil Williams wrote:
> How long should bugs be tagged pending in advance of an upload?
Time isn't the important metric, in my opinion. The question is
whether the maintainer has fixed the bug (or believes they have fixed
the bug) in their development environment and the fix wi
* Andreas Tille [Wed, 16 May 2007 13:27:54 +0200]:
> On Wed, 16 May 2007, Norbert Preining wrote:
> >Sounds like a hack. What do other say?
> There are different opinions about orig.tar.gz should be equal
> to upstream.
In case there is confusion, my original suggestion was to remove the
files
Hi, Daniel
When you talk about "desktop users", I think you really mean "novice
consumers". Is that a fair assessment? In my experience, Debian can
work just fine on the desktop in some situations, just not for novice
home users. (think, e.g., about desktops for office workers)
We have ha
On Wed, 16 May 2007, Adeodato [utf-8] Simó wrote:
There are different opinions about orig.tar.gz should be equal
to upstream.
In case there is confusion, my original suggestion was to remove the
files from debian/rules ('clean' target), not to remove them from the
orig tarball. I don't think t
Neil Williams <[EMAIL PROTECTED]> wrote:
> How long should bugs be tagged pending in advance of an upload?
>
> Is it acceptable to tag a bug pending when fixed upstream and the
> maintainer is confident of an upstream release in under a week? (This
> is easy for me, I'm also upstream in many cases
Le mercredi 16 mai 2007 à 13:15 +0200, Norbert Preining a écrit :
> On Mit, 16 Mai 2007, Adeodato Simó wrote:
> > Deleting the binary files in the clean target. dpkg-source will complain
> > that they're missing, but will build the package just fine.
>
> Sounds like a hack. What do other say?
Tha
I try to keep all changes to upstream as a number of patches in
debian/patches. I've heard that restricting the .diff.gz to ./debian is a
Good Thing. The drawback is that the .diff.gz becomes more difficult to read,
with the diff of diffs and all, but once the source package is unpacked it's
mu
Frank Küster escreveu:
Neil Williams <[EMAIL PROTECTED]> wrote:
How long should bugs be tagged pending in advance of an upload?
Is it acceptable to tag a bug pending when fixed upstream and the
maintainer is confident of an upstream release in under a week? (This
is easy for me, I'm also up
On Wed, 16 May 2007 13:24:07 +0200
Frans Pop <[EMAIL PROTECTED]> wrote:
> On Wednesday 16 May 2007 12:50, Neil Williams wrote:
> > How long should bugs be tagged pending in advance of an upload?
>
> For me "pending" is a signal to users saying "issue has been confirmed,
> solution is available and
On Wed, 16 May 2007, Don Armstrong wrote:
> On Wed, 16 May 2007, Neil Williams wrote:
> > How long should bugs be tagged pending in advance of an upload?
>
> Time isn't the important metric, in my opinion. The question is
> whether the maintainer has fixed the bug (or believes they have fixed
> t
On Wednesday 16 May 2007, Mgr. Peter Tuharsky wrote:
> Thus, I assume that not only novice consumers have the need for
> improving desktop software and bugs seen fixed.
>
> However, Debian dosen't officially support and embrace any way to do
> this. Watching for new version, You're on Your own.
>
Andreas Tille <[EMAIL PROTECTED]> wrote:
> On Wed, 16 May 2007, Adeodato [utf-8] Simó wrote:
>
>>> There are different opinions about orig.tar.gz should be equal
>>> to upstream.
>>
>> In case there is confusion, my original suggestion was to remove the
>> files from debian/rules ('clean' target),
Norbert Preining wrote:
> Now at a second build time we have changes in the binary .gmo files
> which cannot be represented.
>
> What is the preferred solution for such a case?
I usually save upstream's generated files somewhere in debian/rules during
build, and copy them back in the clean target
Hi
On Wed, 16 May 2007 13:52:28 +0200
Magnus Holmgren <[EMAIL PROTECTED]> wrote:
> Now, how do you combine these? Several people have thought: "The VCS
> can handle the changesets. Putting patches under VCS is silly!" Maybe it is.
> What's for certain is, that to someone who just does 'apt-get
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, May 16, 2007 at 01:24:07PM +0200, Frans Pop wrote:
> On Wednesday 16 May 2007 12:50, Neil Williams wrote:
> > How long should bugs be tagged pending in advance of an upload?
>
> For me "pending" is a signal to users saying "issue has been conf
Magnus Holmgren <[EMAIL PROTECTED]> wrote:
> Now, how do you combine these? Several people have thought: "The VCS
> can handle the changesets. Putting patches under VCS is silly!" Maybe it is.
I don't agree. With patches in debian/patches, you can give names to
those files. Names that explain
Magnus Holmgren wrote:
> Now, how do you combine these? Several people have thought: "The VCS
> can handle the changesets. Putting patches under VCS is silly!"
I fully agree. Unfortunately Subversion doesn't make it easy for you. You
can keep your "patches" in different "feature branches", but it
> > I am attaching the local.te file below for comment; some of
> > this should probably go into the refpolicy package, and, eventually,
> > upstream.
>
> Would be nice to actually append the file.
I have attached a patch that I'm using in my work on getting a strict unstable
sy
On Wed, 16 May 2007, Kevin Mark wrote:
> would it be useful for some process to periodically poll the bts for
> 'pending' tags that are unusually old [ say 1 or 2 months ] and ping
> the maintainer to remind them if they forget to 'release often'?
I can't imagine a maintainer not being aware of bu
On Wednesday 16 May 2007 14:29, Don Armstrong wrote:
> Indicates that the maintainer has fixed the bug (or believes they
> have fixed the bug) in their development tree and the next upload
> will include the fix for the bug.
Good, but to me the bit between parenthesis does not add anything u
Frank Küster wrote:
>> "The VCS can handle the changesets. Putting patches under VCS is silly!"
> I don't agree. With patches in debian/patches, you can give names to
> those files.
With a VCS you can also name branches, or changesets (stgit).
Marcus
--
To UNSUBSCRIBE, email to [EMAIL PRO
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, May 16, 2007 at 06:01:54AM -0700, Don Armstrong wrote:
> On Wed, 16 May 2007, Kevin Mark wrote:
> > would it be useful for some process to periodically poll the bts for
> > 'pending' tags that are unusually old [ say 1 or 2 months ] and ping
>
On Wednesday 16 May 2007 14:52, Marcus Better wrote:
> > However, he can read debian/copyright and
> > debian/README.Debian to find out where the maintainer keeps his
> > repository,
>
> Or check the PTS, if you use XS-Vcs-* control fields.
Yeah, I suppose I didn't know that when I started writing
On Wed, 16 May 2007, Kevin Mark wrote:
> The other idea was for a simple .../pending page on the bts so that
> folks could quickly see what is about to be fixed.
Just append ;pend-inc=pending-fixed; to your pkgreport.cgi url, like so:
http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=debbugs;dist=
Le Wed, May 16, 2007 at 01:26:30AM +0200, Frans Pop a écrit :
> On Wednesday 16 May 2007 01:11, Charles Plessy wrote:
> > Maybe at each point release, the release notes could be
> > updated on the basis of these messages. Things like "emacs21 does not
> > have full unicode support, but you can disp
Marcus Better <[EMAIL PROTECTED]> wrote:
> Frank Küster wrote:
>>> "The VCS can handle the changesets. Putting patches under VCS is silly!"
>
>> I don't agree. With patches in debian/patches, you can give names to
>> those files.
>
> With a VCS you can also name branches, or changesets (stgit).
Am 2007-05-15 09:29:46, schrieb Mgr. Peter Tuharsky:
> I think, any new stable version of the desktop software should be
> automaticaly added to security updates and distributed to end user.
> There's no need to test the tested and stabilise the stable software.
> Should the new stable version b
Am 2007-05-15 11:25:56, schrieb Mgr. Peter Tuharsky:
> Do You think, that
> -compiling new upstream version of software against stable platform,
> building a package and distributing it
Containing NEW bugs and the loop goes on... -- No Thanks!
> -needs more effort than
> -studying security fix
Am 2007-05-15 09:41:17, schrieb Mgr. Peter Tuharsky:
> The kernel, the X.org
>
> I realise, that the kernel and X.org are somewhat delicate things,
> because they affect both desktop and server. Changing them in the middle
> of release life, might not sound too well.
Sorry, thats not right!
I
I am not sure how would I survive without VCS (first CVS and now SVN).
And there are probably more efficient ways than I use, but I just wanted
to share.
I find mergeWithUpstream "mode" useful whenever the upstream package is
huge, and you don't want to "pollute" SVN with that much of irrelevant
f
On 16-May-07, 06:24 (CDT), "Mgr. Peter Tuharsky" <[EMAIL PROTECTED]> wrote:
>
> It's been in context, meant as "many of those problems" -a relative part
> of problems, not absolute number of them.
>
> No, it's not worth the time. It's a history.
The problem is that your "history" doesn't match
(Please don't CC me on list mail.)
On 16-May-07, 01:58 (CDT), "Mgr. Peter Tuharsky" <[EMAIL PROTECTED]> wrote:
> Steve Greenland wrote / nap?sal(a):
>
> As I illustreted, "rock solid" is not automatically guaranteed by
> oldness of software or by length of pre-release testing.
And as others h
On Wed, May 16, 2007 at 08:10:44AM +0200, Martin Zobel-Helas wrote:
> as a QA effort the whole archive was rebuilt yesterday to catch
> build-failures, whether a package can be build twice in a row (unpack,
> build, clean, build). We found about 400 packages not having a sane
> clean target.
>
>
Martin Zobel-Helas <[EMAIL PROTECTED]> writes:
> On Wed May 16, 2007 at 10:11:55 +0200, Stefano Zacchiroli wrote:
>> Wouldn't it be better to unpack a package twice in two different
>> directories, build and clean in one dir and then compare the obtained
>> tree with the tree available in the othe
Martin Zobel-Helas <[EMAIL PROTECTED]> writes:
>> Wouldn't it be better to unpack a package twice in two different
>> directories, build and clean in one dir and then compare the obtained
>> tree with the tree available in the other dir?
>
> That would surely be the better solution to catch this p
On Wed, 16 May 07 11:36, Lennart Sorensen wrote:
> What about packages that automatically pull in updated autoconf files as
> part of the build, or regenerate .po files which were already there, but
> due to a new version of the tools generates a different .po file from
> what was already there? T
Si no ves este newsletter, pincha aquí o pega esta ruta en tu navegador
http://mails.lasagra.com/envios/2007-05-16.html
On 16/05/07 at 10:11 +0200, Stefano Zacchiroli wrote:
> Isn't "twice building" too coarse grained to spot actual violation of
> this rule? I mean, packages that fail to build the second time have for
> sure garbage left around after the former invocation of "clean". But it
> is not granted that pa
On Tue, 15 May 2007 23:54:02 +0200
maximilian attems <[EMAIL PROTECTED]> wrote:
> i'd appreciate if you post such questions to the corresponding
> development mailing list which is debian-kernel for initramfs
> questions.
> thanks
>
> > Current pratice is to only call `update-initramfs -u', that
Magnus Holmgren wrote:
> I have now. IIUC, it lets you group and name diffs vs. a particular state
> of the source code, but the end result is a normal .diff.gz, meaning that
> everyone else has to use stgit too to get all the benefits, right?
Yes. People working on the same project team should us
Frank Küster wrote:
> Personally, I don't like branches very much. Nobody ever explained to
> me a good receipe to handle them in the case where development proceeds
> in both, and important fixes are copied from one to the other.
I believe git handles that, it should work nicely in most cases.
On Fri, 2007-05-11 at 01:44 +0100, Stephen Gran wrote:
> This one time, at band camp, Ludovic Rousseau said:
> > Le 10.05.2007, à 00:25:32, Stephen Gran a écrit:
> > >
> > > I have always just asked them on IRC on #debian-kernel.
> >
> > Have you done this time again?
> > If not, could you? (I do
On (16/05/07 13:52), Magnus Holmgren wrote:
> svn-buildpackage has a feature called "mergeWithUpstream mode", which means
> that only the files that are actually touched are put under version control
> (I thought most $TLA-buildpackage would have something similar, but it seems
> to be unique to
On Wed, May 16, 2007 at 07:57:33PM +0200, Armin Berres wrote:
> I may be wrong, but IIRC removing those generated files in the clean
> target is the solution if you want a clean .diff.gz.
But dpkg-buildpackage will then spit out lots of warnings about being
unable to store the deletion of a binary
I am currently trying to find a valid UTF8 encoded text file to check my
terminal settings and such to make sure I have it working right. So to
do this I figured I would just find some changelog file that claims to
be in UTF8 format and see if it views correctly. Well so far no luck.
Every single
Lennart Sorensen <[EMAIL PROTECTED]> writes:
> So should changelog files for debian packages be UTF8
Yes.
> and if so are there any that actually are
lintian's is, at least. Many others are these days as well. All of my
packages have UTF-8 changelog files, although not all actually have
non-A
On Wed, May 16, 2007 at 02:53:09PM -0700, Russ Allbery wrote:
> Lennart Sorensen <[EMAIL PROTECTED]> writes:
> Yes.
Hmm, well I haven't found one yet and I think I checked 10 so far, all
of which have non ascii characters but none of which appeared valid to
me.
> lintian's is, at least. Many oth
On Wed, May 16, 2007 at 06:01:40PM -0400, Lennart Sorensen wrote:
> I wonder how many packages are triggering that right now.
>
> So is this valid utf-8? I don't believe so. If it is I have to go
> reread the UTF-8 spec again. :)
>
> 4b c4 99 73 74 75 74 69 73 (K..stutis)
> (I found this on
* Lennart Sorensen [Wed, 16 May 2007 18:01:40 -0400]:
> I wonder how many packages are triggering that right now.
http://lintian.debian.org/reports/Tdebian-changelog-file-uses-obsolete-national-encoding.html
> So is this valid utf-8? I don't believe so. If it is I have to go
> reread the UTF-8
On Wed, May 16, 2007 at 06:01:40PM -0400, Lennart Sorensen wrote:
> On Wed, May 16, 2007 at 02:53:09PM -0700, Russ Allbery wrote:
> > Lennart Sorensen <[EMAIL PROTECTED]> writes:
> > Yes.
> Hmm, well I haven't found one yet and I think I checked 10 so far, all
> of which have non ascii characters
Lennart Sorensen <[EMAIL PROTECTED]> writes:
> On Wed, May 16, 2007 at 02:53:09PM -0700, Russ Allbery wrote:
>> debian-changelog-file-uses-obsolete-national-encoding is the tag.
> I wonder how many packages are triggering that right now.
96.
http://lintian.debian.org/reports/Tdebian-changelog-f
[EMAIL PROTECTED] (Lennart Sorensen) writes:
> So is this valid utf-8? I don't believe so. If it is I have to go
> reread the UTF-8 spec again. :)
>
> 4b c4 99 73 74 75 74 69 73 (K..stutis)
> (I found this one in base-config from sarge since I happened to have
> that one open in a hex editor
On ke, 2007-05-16 at 23:17 +0100, Dagfinn Ilmari Mannsåker wrote:
> That's trivial to check. Just feed it to recode and specify UTF-8
> Hexadecimal input:
You might also be interested in isutf8 from moreutils.
--
Never underestimate the power of a small tactical Lisp interpreter.
--
To UNSUBS
On Wed, May 16, 2007 at 10:00:57AM +, [EMAIL PROTECTED] wrote:
> On Wed, May 16, 2007 at 11:21:51AM +0200, Guus Sliepen wrote:
> > On Wed, May 16, 2007 at 11:12:56AM +0200, Richard Atterer wrote:
> > > > Wouldn't it be better to unpack a package twice in two different
> > > > directories, bui
Steve Langasek <[EMAIL PROTECTED]> wrote:
> > granted there are things like this, but reproducible builds would be
> > fantastic and well worth the effort.
> If you're talking about "byte-for-byte identical builds", then no, that
> would be a tremendous amount of effort for no practical gain. The
On ke, 2007-05-16 at 16:26 -0700, Tyler MacDonald wrote:
> We should expect that given the same source, headers, and libraries, we
> would get the same bytes out of a build every time. Any deviation from this
> would indicate something different, or erratic. If it doesn't cause
> problems, fine,
Lars Wirzenius <[EMAIL PROTECTED]> wrote:
> printf("This program was compiled on " __DATE__ "\n");
>
> An example like the above has already been given. Build dates and other
> variable information gets put into a lot of output files from
> compilations.
Sorry, I was speaking from an overly sel
Tyler MacDonald <[EMAIL PROTECTED]> writes:
> We should expect that given the same source, headers, and libraries, we
> would get the same bytes out of a build every time.
This just isn't how compilers work. Timestamps are encoded in binaries,
temporary build directories are encoded in debugging
Package: wnpp
Severity: wishlist
Owner: Bernd Zeimetz <[EMAIL PROTECTED]>
* Package name: wmi
Version : 20070516
Upstream Author : Zenoss / Andrzej Hajda / The Samba Team
* URL : http://dev.zenoss.org/svn/trunk/wmi/
* License : GPL/LGPL and others
Progr
Frank Küster wrote:
> Personally, I don't like branches very much. Nobody ever explained to
> me a good receipe to handle them in the case where development proceeds
> in both, and important fixes are copied from one to the other.
http://youtube.com/watch?v=4XpnKHJAok8
is good to view if you're
Package: wnpp
Severity: wishlist
Owner: Sebastien Delafond <[EMAIL PROTECTED]>
* Package name: jruby
Version : 1.0.0rc2
Upstream Author : The JRuby Team
* URL : http://jruby.codehaus.org/
* License : tri license CPL/GPL/LGPL
Programming Lang: Ruby, Java
Desc
Roberto C. Sánchez wrote:
> On Tue, May 15, 2007 at 10:05:56PM -0400, Felipe Sateler wrote:
>> Roberto C. Sánchez wrote:
>>
>> > Well, the ~ character is stated to be evaluated to be less than the
>> > empty string. If a package is the target of a security upload in
>> > stable, you can be certa
On Wed, May 16, 2007 at 10:54:09PM -0400, Felipe Sateler wrote:
> Roberto C. Sánchez wrote:
>
> > On Tue, May 15, 2007 at 10:05:56PM -0400, Felipe Sateler wrote:
> >> Roberto C. Sánchez wrote:
> >>
> >> > Well, the ~ character is stated to be evaluated to be less than the
> >> > empty string. If
"Mgr. Peter Tuharsky" <[EMAIL PROTECTED]> writes:
> I wrote "worse" because for Debian, this is worse. Not that it is
> damaging it somehow. Of course there naturally will be other
> distros, cooperating hopefully.
>
> It's "worse" because it implies, that Debian is not as good desktop
> as it oug
[Lennart Sorensen]
> But dpkg-buildpackage will then spit out lots of warnings about being
> unable to store the deletion of a binary file in the diff. So it
> will look ugly, but work I guess.
dpkg-buildpackage doesn't store _any_ deletions in the diff.gz - the
warning about deletions has nothi
Peter Samuelson wrote:
> I'd file a bug asking for this, but clearly the warning is intentional,
> so a bug is not likely to get much more attention than #12564, which is
> also related.
12564 should be fixable with wig and pen. If it does get fixed then
deleting files in clean will no longer be t
> I install regulary NEW kernels where Debian had only 2.4.27 I used
2.4.32/33 and thats NOT the same as pushing a NEW Xorg into stable.
The Kernels can be installed without any problems parallel, and if
one is not working, you boot the last working one.
Yes, I have written it there too. Kern
Steve,
The problem is that your "history" doesn't match the experience of any
one else participating in this thread. You keep making assertions about
testing being broken, sometimes with "hundreds of broken dependencies".
Since one of the key criterion of packages entering testing is
"dependenci
Steve,
And as others have pointed out, the purpose of stable is to minimize
disruptions. For many users, living with known bugs with known workarounds
is a *lot* better than identifying new bugs.
Yeas. Let the choice to the user. Don't dictate him. Whoever wants to
use the old software w/o
95 matches
Mail list logo
