date:20101011

On 7 October 2010 14:06, Joachim Reichel joachim.reic...@gmx.de wrote:
 I guess what Christoph meant is the following: if you upload 1.45 to unstable
 you block this way for fixes to 1.44 in testing (and the RM will most probably
 not allow 1.45 to migrate to testing).

 You could upload 1.45 to experimental for now. This allows you to upload
 1.44-2, -3, and so on which just fix RC bugs in 1.44-1, upload them to
 unstable and request a freeze exception.

I've never really understood why Debian works like this. I think
experimental should mean too unstable for unstable but during
freeze time it seems to mean unstable-2, because otherwise I can't
fix packages in testing. In this particular case, we *know* that the
so-called experimental package is going to be even more stable than
the testing package, because it's had many more bugfixes tested by
upstream than tested by Debian. It seems silly to have to label it
experimental.

Does it have to be this way? Why do fixes to testing have to go
through unstable, even during freeze time? Why does experimental
become the new unstable during freeze time?

- Jordi G. H.


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktimbzn8d2mekpxx6q1sa0hong21two0rhfkop...@mail.gmail.com

Re: shlibs and lintian

2010-10-11 Thread Johan Van de Wauw

On Mon, Oct 11, 2010 at 1:41 PM, Zvi Dubitzky d...@il.ibm.com wrote:
 I am having a package for libraries (several)
 The package is called libvae (libvae_1.3_amd64.deb)  and include the
 libraries (libvae.so.2.0 , libvaeUtil.so.2.0  ..)
soname major version: 2; minor version: 0; patch: ? (I assume 0 also)
 The shlibs is as follows :
 libvae 2 libvae  (= 1.3)
dependencies refer to the version number on the soname.
libvae 2 libvae
should work if you really want (0.0).

[BTW: better call your package libvae2_1.3-1]
And make sure that you understand library version numbers
http://sourceware.org/autobook/autobook/autobook_91.html


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktikr9dlixshp5lkfvmkaaoij49kmo7_+rz1d+...@mail.gmail.com

Re: shlibs and lintian

Zvi Dubitzky d...@il.ibm.com writes:

 I am having a package for libraries (several)
 The package is called libvae (libvae_1.3_amd64.deb)  and include the 
 libraries (libvae.so.2.0 , libvaeUtil.so.2.0  ..)

 The shlibs is as follows :
 libvae 2 libvae  (= 1.3)
 libvaeUtil 2 libvae (= 1.3)
 libvirtExt 2 libvae (= 1.3)
 libvhi 2 libvae  (= 1.3)
 libvanos 2 libvae (= 1.3)

 all the libraries and some sym links to them are positioned in /usr/lib.

 yet after generating the package and running lintian I get the following 
 warning :

 W: libvae: unused-shlib-entry-in-control-file libvae 2
[...]

 Also there are sym links like : /usr/lib/libvae.so - libvae.so.2.0 . they 
 are also included but the lintian seems to want an entry
 for them in the shlibs and issues the following  error:
 E: libvae: shlib-missing-in-control-file libvae.so for usr/lib/libvae.so.2.0
[...]

The above seems to indicate that the problem is the shared libraries are
broken.  The Lintian tags that you're getting imply that the SONAME of
this library is just libvae.so without any version, not libvae.so.2
like it should be.  Such libraries without SONAMEs can't be represented in
shlibs, which is causing both of the errors that you're getting.

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/871v7wyb9r@windlord.stanford.edu

Re: Uploading during freeze time

Jordi Gutiérrez Hermoso jord...@gmail.com writes:

 Does it have to be this way? Why do fixes to testing have to go
 through unstable, even during freeze time?

Because otherwise there isn't any good way to test them with a reasonably
large user base, which is even *more* important during the freeze.

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87wrpowwnt@windlord.stanford.edu

Re: Uploading during freeze time

2010-10-11 Thread PJ Weisberg

2010/10/11 Jordi Gutiérrez Hermoso jord...@gmail.com:
 Why do fixes to testing have to go through unstable, even during freeze time?

Because a lot more people use Unstable than use Testing, so
(ironically) Unstable is a better place to do testing.

 Why does experimental become the new unstable during freeze time?

Because Unstable is busy being the new Testing. ;-)

Also note that in this context, unstable means may change
frequently, not may crash randomly.


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktimwªrjrt_yd126nlrqqwueou6xogpmbhzl...@mail.gmail.com

Re: shlibs and lintian

2010-10-11 Thread Zvi Dubitzky

Hi
What do you mean the libraries are broken ?
I can install the package and everything runs ok . But I do not like these 
messages OR
something can cause a trouble I do not see

thanks

Zvi Dubitzky 
Email:d...@il.ibm.com





From:   Russ Allbery r...@debian.org
To: debian-mentors@lists.debian.org
Date:   11/10/2010 17:56
Subject:Re: shlibs and lintian



Zvi Dubitzky d...@il.ibm.com writes:

 I am having a package for libraries (several)
 The package is called libvae (libvae_1.3_amd64.deb)  and include the 
 libraries (libvae.so.2.0 , libvaeUtil.so.2.0  ..)

 The shlibs is as follows :
 libvae 2 libvae  (= 1.3)
 libvaeUtil 2 libvae (= 1.3)
 libvirtExt 2 libvae (= 1.3)
 libvhi 2 libvae  (= 1.3)
 libvanos 2 libvae (= 1.3)

 all the libraries and some sym links to them are positioned in /usr/lib.

 yet after generating the package and running lintian I get the following 

 warning :

 W: libvae: unused-shlib-entry-in-control-file libvae 2
[...]

 Also there are sym links like : /usr/lib/libvae.so - libvae.so.2.0 . 
they 
 are also included but the lintian seems to want an entry
 for them in the shlibs and issues the following  error:
 E: libvae: shlib-missing-in-control-file libvae.so for 
usr/lib/libvae.so.2.0
[...]

The above seems to indicate that the problem is the shared libraries are
broken.  The Lintian tags that you're getting imply that the SONAME of
this library is just libvae.so without any version, not libvae.so.2
like it should be.  Such libraries without SONAMEs can't be represented in
shlibs, which is causing both of the errors that you're getting.

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact 
listmas...@lists.debian.org
Archive: http://lists.debian.org/871v7wyb9r@windlord.stanford.edu




-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/of716b8838.3843e979-onc22577b9.005a6b4f-c22577b9.005a8...@il.ibm.com

Re: shlibs and lintian

Zvi Dubitzky d...@il.ibm.com writes:

 Hi
 What do you mean the libraries are broken ?

It might be helpful to read Policy chapter 8:

http://www.debian.org/doc/debian-policy/ch-sharedlibs.html

which explains the purpose of the library SONAME.  The problem here
appears to be that you have libraries without any version number in the
SONAME.  This both violates Policy 8.1 because there's no versioning in
the SONAME:

Every time the shared library ABI changes in a way that may break
binaries linked against older versions of the shared library, the
SONAME of the library and the corresponding name for the binary
package containing the runtime shared library should change. Normally,
this means the SONAME should change any time an interface is removed
from the shared library or the signature of an interface (the number
of parameters or the types of parameters that it takes, for example)
is changed. This practice is vital to allowing clean upgrades from
older versions of the package and clean transitions between the old
ABI and new ABI without having to upgrade every affected package
simultaneously.

and it makes it impossible to use the shlibs section because the shlibs
file syntax requires a version number in the SONAME (see Policy 8.6.3).

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87d3rgwuv8@windlord.stanford.edu

Re: Uploading during freeze time

2010-10-11 Thread Boyd Stephen Smith Jr.

In aanlktimbzn8d2mekpxx6q1sa0hong21two0rhfkop...@mail.gmail.com, Jordi 
Gutiérrez Hermoso wrote:
On 7 October 2010 14:06, Joachim Reichel joachim.reic...@gmx.de wrote:
 I guess what Christoph meant is the following: if you upload 1.45 to
 unstable you block this way for fixes to 1.44 in testing (and the RM will
 most probably not allow 1.45 to migrate to testing).
 
 You could upload 1.45 to experimental for now. This allows you to upload
 1.44-2, -3, and so on which just fix RC bugs in 1.44-1, upload them to
 unstable and request a freeze exception.

I've never really understood why Debian works like this.
In this particular case, we *know* that the
so-called experimental package is going to be even more stable than
the testing package, because it's had many more bugfixes tested by
upstream than tested by Debian. It seems silly to have to label it
experimental.

I disagree that *any* package based on a new upstream release is *known* to be 
less buggy than the existing package, even *before* it gets uploaded to 
unstable/experimental.  (Exception: packages that have already been in a 
Debian derivative for some period of time before entering 
unstable/experimental.)

Does it have to be this way? Why do fixes to testing have to go
through unstable, even during freeze time?

They don't.  t-p-u exists for when the version in testing needs a fix, but 
migrating the package from unstable is troublesome.  It is rather frowned upon 
though, since it means the update does not get the level of exposure that 
other updates receive.  That's a bad thing; even very small fixes can 
inadvertently break a package for an entire architecture.  (E.g. bug #595728, 
which isn't about t-p-u but rather the *stable* update process)

Why does experimental
become the new unstable during freeze time?

Remember that the unstable name was chosen to indicate how often it is 
updated, not how well-tested the upstream software is.  unstable is packages 
intended to be in the next release of Debian, as they are uploaded.  If your 
package isn't intended for the next release of Debian, it shouldn't be in 
unstable.  With the freeze on, you should be fairly sure you will get a 
freeze exception from the release team *before* you upload to unstable.

experimental is packages not yet intended for any release of Debian, for 
whatever reason.  It gets used as unstable+1 during the freeze, since 
there's no better place.  Having an unstable+1 might work, but probably not; 
in any case, it would only be useful during a freeze AND you'd likely have to 
re-upload to unstable after the thaw anyway.  (Continual automatic migration 
from unstable+1 to unstable is wrong semantically, and likely has some 
technical hurdles as well.)  If a re-upload is required anyway, we might as 
well just use experimental as unstable+1 during the freeze, IMHO.
-- 
Boyd Stephen Smith Jr.   ,= ,-_-. =.
b...@iguanasuicide.net   ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/\_/


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

Re: Uploading during freeze time

On 11 October 2010 12:11, Boyd Stephen Smith Jr. b...@iguanasuicide.net wrote:
 I disagree that *any* package based on a new upstream release is *known* to be
 less buggy than the existing package,

Good, so do I, but in this case, cppcheck is a very infrequently used
Debian package, and it's used widely by other people outside of
Debian.

 In aanlktimbzn8d2mekpxx6q1sa0hong21two0rhfkop...@mail.gmail.com, Jordi
Gutiérrez Hermoso wrote:
Does it have to be this way? Why do fixes to testing have to go
through unstable, even during freeze time?

 They don't.  t-p-u exists for when the version in testing needs a fix, but
 migrating the package from unstable is troublesome.  It is rather frowned upon
 though, since it means the update does not get the level of exposure that
 other updates receive.

That's what I really don't get. So testing isn't for testing, unstable
is for testing, and experimental is for unstable? So where do really
crazy ideas go? Why do all the distros get pushed back one during
freeze time?

 Remember that the unstable name was chosen to indicate how often it is
 updated, not how well-tested the upstream software is.

Is that true? I've never seen an official reaffirmation of this
oft-quoted idea, it merely seems to come from people who don't mind
debugging or living with the bugs in unstable and therefore it's
stable enough for me. The kid who breaks toys doesn't sound to me
like the kid who changes too much. Unstable is too buggy for me.
During freeze time, shouldn't bugs should be fixed in testing, not in
unstable? You freeze a distribution, you fix its bugs, and you release
it, and while the six-month freeze is in effect, you can also have
your broken toys playground if you want it.

  unstable is packages intended to be in the next release of Debian, as they 
 are
 uploaded.

Where next in this instance means current? What does
experimental mean, then?

 experimental is packages not yet intended for any release of Debian,

But that's now how it's used. It's used as not squeeze, but almost
certainly wheezy

 It gets used as unstable+1 during the freeze, since  there's no better 
 place.

So why not create a better place?


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktikwokffmtyfhi-yy7j=_fx8_44wbcbu3vcc6...@mail.gmail.com

RFS: roxterm (updated package) [highly configurable terminal emulator]

2010-10-11 Thread Tony Houghton

Dear mentors,

My first RFS for this version didn't result in an upload so I am still
looking for a sponsor for the new version 1.18.5-3 of my package roxterm.

It builds these binary packages:
roxterm- Multi-tabbed GTK/VTE terminal emulator

The package appears to be lintian clean.

The upload would fix these bugs: 598971

The bug can affect which environment variables roxterm decides to set or
change in its child shells. The specific problem experienced in Ubuntu
Maverick (not setting TERM correctly) is unlikely to affect Debian,
because Debian's older vte library sets TERM whereas Maverick's doesn't.
However, the bug still has potential to cause weird things to happen
with environment variables and the fix is very simple, so I think it
should be included in squeeze.

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/r/roxterm
- Source repository: deb-src http://mentors.debian.net/debian unstable
main contrib non-free
- dget
http://mentors.debian.net/debian/pool/main/r/roxterm/roxterm_1.18.5-3.dsc

I would be glad if someone uploaded this package for me.

Kind regards
 Tony Houghton

-- 
TH * http://www.realh.co.uk


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4cb34b6d.8050...@realh.co.uk

Re: Uploading during freeze time

Jordi Gutiérrez Hermoso jord...@gmail.com writes:
 Boyd Stephen Smith Jr. b...@iguanasuicide.net wrote:

 It gets used as unstable+1 during the freeze, since there's no better
 place.

 So why not create a better place?

What specifically is wrong with experimental?  In other words, what
problem are you trying to fix other than that you don't like the name?

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87wrpovcb9@windlord.stanford.edu

Re: shlibs and lintian

2010-10-11 Thread Zvi Dubitzky

Hi

The way I understand the Debian Plociy is that a SONAME is composed of 
library name + SONAME version
So for libvae.so.2.0  : libvae is the library name and 2.0 is the SONAME 
version (or it can be 2.0.0) .

The moment a SONAME version changes is described in 8.1 but it is 
immaterial to this case (I think) 
Also by comparison to other cases it seems that  my shlibs adhers the 
shlibs file format

Or maybe the SONAME should also be stamped inside the library file and the 
lintian scans the file content and looks for
SONAME inside that fits the SONAME in the library name  . That is 
something I am missing  because I had to compose the package after the 
libraries were built (not a pure fake root process) 

thanks

Zvi Dubitzky 
Email:d...@il.ibm.com





From:   Russ Allbery r...@debian.org
To: Zvi Dubitzky/Haifa/i...@ibmil
Cc: debian-mentors@lists.debian.org
Date:   11/10/2010 18:35
Subject:Re: shlibs and lintian



Zvi Dubitzky d...@il.ibm.com writes:

 Hi
 What do you mean the libraries are broken ?

It might be helpful to read Policy chapter 8:

http://www.debian.org/doc/debian-policy/ch-sharedlibs.html

which explains the purpose of the library SONAME.  The problem here
appears to be that you have libraries without any version number in the
SONAME.  This both violates Policy 8.1 because there's no versioning in
the SONAME:

Every time the shared library ABI changes in a way that may break
binaries linked against older versions of the shared library, the
SONAME of the library and the corresponding name for the binary
package containing the runtime shared library should change. Normally,
this means the SONAME should change any time an interface is removed
from the shared library or the signature of an interface (the number
of parameters or the types of parameters that it takes, for example)
is changed. This practice is vital to allowing clean upgrades from
older versions of the package and clean transitions between the old
ABI and new ABI without having to upgrade every affected package
simultaneously.

and it makes it impossible to use the shlibs section because the shlibs
file syntax requires a version number in the SONAME (see Policy 8.6.3).

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/



-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/of7342215f.6cb70db2-onc22577b9.0062a8c7-c22577b9.00638...@il.ibm.com

Re: shlibs and lintian

Zvi Dubitzky d...@il.ibm.com writes:

 Or maybe the SONAME should also be stamped inside the library file and
 the lintian scans the file content and looks for SONAME inside that fits
 the SONAME in the library name.

Right, the SONAME *has* to be inside the library, because that's what
everything actually looks at.  All the other things, like the symlinks and
the shlibs entries, then have to match the SONAME that's recorded in the
library.

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87k4lovbnt@windlord.stanford.edu

Re: Uploading during freeze time

2010-10-11 Thread Boyd Stephen Smith Jr.

In aanlktikwokffmtyfhi-yy7j=_fx8_44wbcbu3vcc6...@mail.gmail.com, Jordi 
Gutiérrez Hermoso wrote:
On 11 October 2010 12:11, Boyd Stephen Smith Jr. b...@iguanasuicide.net 
wrote:
 In aanlktimbzn8d2mekpxx6q1sa0hong21two0rhfkop...@mail.gmail.com, Jordi
 Gutiérrez Hermoso wrote:
Does it have to be this way? Why do fixes to testing have to go
through unstable, even during freeze time?

 They don't.  t-p-u exists for when the version in testing needs a fix, but
 migrating the package from unstable is troublesome.  It is rather frowned
 upon though, since it means the update does not get the level of exposure
 that other updates receive.

That's what I really don't get. So testing isn't for testing, unstable
is for testing, and experimental is for unstable? So where do really
crazy ideas go? Why do all the distros get pushed back one during
freeze time?

Testing *is* for testing.  However, testing is not as unstable as unstable.  
The reason for this is simple: You can't test the functionality of a package 
if you can't install it.  It is relatively easy for an upload to unstable to 
render at least one package uninstallable in unstable.  The automated 
migration process is responsible for keeping all packages in testing 
installable.

I hope that shows why testing and unstable have to be different versions.  
Since they need to be separated anyway, adding the 10-day (or so) grace period 
for major bugs to be identified before entering testing, allows testing be be 
much closer to the ideal.

Packages are installed into the `testing' directory after they have undergone 
some degree of testing in unstable.

They must be in sync on all architectures where they have been built and 
mustn't have dependencies that make them uninstallable; they also have to have 
fewer release-critical bugs than the versions currently in testing. This way, 
we hope that `testing' is always close to being a release candidate.  
http://www.debian.org/doc/FAQ/ch-ftparchives

 Remember that the unstable name was chosen to indicate how often it is
 updated, not how well-tested the upstream software is.

Is that true? I've never seen an official reaffirmation of this
oft-quoted idea, it merely seems to come from people who don't mind
debugging or living with the bugs in unstable and therefore it's
stable enough for me.

The `unstable' directory contains a snapshot of the current development 
system. Users are welcome to use and test these packages, but are warned about 
their state of readiness. The advantage of using the unstable distribution is 
that you are always up-to-date with the latest in GNU/Linux software industry, 
but if it breaks: you get to keep both parts :-)  
http://www.debian.org/doc/FAQ/ch-ftparchives

Some upstream projects do a lot of testing on their side and work closely with 
the Debian maintainer(s).  When that is true, the package that gets uploaded 
to unstable is often less buggy than the package in testing (or even stable).

The kid who breaks toys doesn't sound to me
like the kid who changes too much. Unstable is too buggy for me.

The sid name predates the current division of stable/testing/unstable.  
http://www.debian.org/doc/FAQ/footnotes.en.html#f2

During freeze time, shouldn't bugs should be fixed in testing, not in
unstable? You freeze a distribution, you fix its bugs, and you release
it, and while the six-month freeze is in effect, you can also have
your broken toys playground if you want it.

The freeze process is as you describe.  What you don't seem to get is: The 
preferred way to fix bugs in testing to via automatic migration from unstable.  
This is to ensure a minimum quality of testing, so that users there can focus 
on testing packages, rather than suffering through breakages that the 
automated process can prevent.  If a bug fix is high-quality, it won't have 
any issues passing the automated tests; if the bug fix is important, the 
urgency of the upload can be changed which reduces waiting time in unstable.

In fact, if there are more automated tests you can think of, it wouldn't be 
bad for the bar between testing and unstable to be higher.  I think CUT 
(constantly usable testing) is actually pretty close to reality once the 
system is installed; though, d-i and installer media are important, too.

  unstable is packages intended to be in the next release of Debian, as
 they are uploaded.

Where next in this instance means current? What does
experimental mean, then?

No.  The next release of Debian is codenamed squeeze.  No release date has 
been set, but we are in the pre-release freeze.  
http://www.debian.org/releases/

 experimental is packages not yet intended for any release of Debian,

But that's now how it's used. It's used as not squeeze, but almost
certainly wheezy

Experimental is used for packages which are still being developed, and with a 
high risk of breaking your system. It's used by developers who'd like to study 
and test bleeding edge software. Users shouldn't be using

Re: shlibs and lintian

2010-10-11 Thread Sune Vuorela

On 2010-10-11, Zvi Dubitzky d...@il.ibm.com wrote:
 I am having a package for libraries (several)

Speaking as a maintainer who has been having library packages that
contained several libraries (Qt, kdelibs, kde4libs, kdepimlibs,
kdebase-workspace and ) - we have ended up splitting everything so
that 1 library goes in one package. I can only recommend that to others
because:
 - users of your libraries might only use one of them, and thus gets
   fewer dependencies
 - if upstream changes ABI of one of the libraries, you can change that
   one packagename and create a smaller transition
 - make it easier to manage thinrgs with symbol files rather than shlibs
   files
 

(and as a side effect you end up without such issues as you are
describing)

/Sune


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnib6mam.rvp.nos...@sshway.ssh.pusling.com

RFS: c2html (updated package) [Highlight C sources for WWW presentation]

2010-10-11 Thread Mònica

Dear mentors,

I am looking for a sponsor for a new version 0.9.6-3 
of the package c2html.

It builds these binary packages:
c2html - Highlight C sources for WWW presentation

I am just learning (and trying to help) and have updated this orphaned package. 
This package had lintian warnings and didn't follow the last version of Debian 
Policy, 
so I have fixed it.

I don't want to adopt it, but helping a little fixing existing errors. 
I hope it's useful. If not, please tell me :-)

So, now, the package appears to be lintian clean.

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/c/c2html
- Source repository: deb-src http://mentors.debian.net/debian unstable main 
contrib non-free
- dget http://mentors.debian.net/debian/pool/main/c/c2html/c2html_0.9.6-3.dsc

I would be glad if someone uploaded this package for me.

Kind regards,
 Mònica

Re: RFS: disco

2010-10-11 Thread Niels Thykier

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2010-10-06 20:47, Janos Guljas wrote:
 Dear mentors,
 
 I am looking for a sponsor for my package disco.
 
 * Package name: disco
   Version : 0.3.1-1
   Upstream Author : Ville Tuulos tuu...@gmail.com
 * URL : http://github.com/tuulos/disco/downloads
 * License : GPL-2+
   Section : admin
 
 It builds these binary packages:
 disco-doc  - A distributed computing framework - documentation
 disco-master - A distributed computing framework - master
 disco-node - A distributed computing framework - node
 python-disco - A distributed computing framework - client python module
 python-discodb - An efficient, immutable, persistent mapping object Disco
 python-discodex - Distributed indices for Disco
 
 [...]
 
 Kind regards
  Janos Guljas
 
 

Hi

Thanks for considering to contribute to Debian, your help is much
appreciated. :)

While I am not a python/erlang/etc. packager, I did a small review of
your package. It is quite possible that I missed some issues that a
second reviewer will find (particularly if said review knows anything
about packaging python or erlang).

That aside, here is what I got:

You got two license files in
  contrib/discodex/lib/discodex/restapi/
  master/src/mochiweb/

which mentions a copyright holders and/or licenses not mentioned in
d/copyright. Their presence implies that the respective subdirectories
are copyrighted and licensed as described in those license files (unless
individual files in those directories state otherwise).

Why do disco-master Pre-Depends on python-disco? I see nothing in the
preinst script that suggests that python-disco must be present before
disco-master is unpacked.

There is a reference in preinst disco-master and disco-nodes to
  /etc/init.d/disco-node
but neither of them appears to install that script.

Is disco-master really an arch:any package? It appears to only contain
image files, javascript, python scripts and html files?

I am not much of a Python packager, but I suspect you should not be
getting this warning.
dpkg-deb: warning: 'debian/$pkg/DEBIAN/control' contains user-defined
field 'Python-Version'

Probably you want X-Python-Version or XS-Python-Version (check the
Debian Python documentation or with the Python Team).



It fails to build from source if Build-Depends-Indep are not satisfied
when dpkg-buildpackage is invoked with -B:
[...]
sphinx-build -b html -d .build/doctrees   . .build/html
make[2]: sphinx-build: Command not found
[...]

This is how auto-builders will build your package. As I recall the
debian-policy is disagreeing with reality here. I believe there is an
attempt to make these two agree, but for now your package must be able
to build without Build-Depends-Indep when dpkg-buildpackage is passed -B.

Have you contacted (or considered to contact) the python application
team about team maintaining the package? (See [1] for more info).

If you have any questions or comments about the things I mentioned (or
anything else regarding your package) then feel free to write back.
~Niels

[1] http://wiki.debian.org/Teams/PythonAppsPackagingTeam

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJMs2/1AAoJEAVLu599gGRCwoQP/ipOCKeee+5NOgmSE+DW051y
dYfYnAGYZ6coGVmNVwlz4+SGy+d9JeGRwhHbAhG9pclYo94r3SdD7arTH09BeS+3
as1ySVEjkxrNmNaz6F58hd9GBCNQQD6AJpn/i0VEHuxwmVr8R8sjfTJdbWiEpMpQ
2zwtR3l663C+DpcDwqkwswBrjeMf7RbMFTkx4qgZg/ZkiimpbjdRuuZnpKneuxzM
HONBMbdtsPOEve+kjNgBtI9qUjpQRW2Lu87GSUa4EtqfPDi5wuyL0zJk1Uc8vKCw
5dOR7Bx7zbAHw2PtSg+JncZnwOVXj8KUKjFEOQgflD0pNyDl8yD7zVLgocPkGNAY
4UddlmjorGOr0+74oTwuo7P14pR19NEkBiXG2NIwoBHMQHTg5sUqN4uRw9ig+Stw
76fJj1nxgXhyhZ0sdTNIYABUk4ArRCNIUA/pJO/0KSaZYbbDpBAL5LSP7d0ot5n8
AKZU0j59Yvw5P0+ZH00Gkp4hrfwg46DbXQpfUICNfVEoKabjvChCgpLKQw8jikNm
AQW8YjWRUzpRpTtqKpSTQhkm5yKCn9ekfYwIii9X641QC1torRjR/Ii2UIyDRxNh
pbzE7NNEr/BXcaBVJjhhQwEwXvn+VcZ37TSzXYZsnVscS5WR+MZiZ0dXQ2CyfRTS
D3Jg6gVYBkWVzILCfc3C
=rSvV
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4cb36ff7.2080...@thykier.net

Re: Uploading during freeze time

On 11 October 2010 20:28, Boyd Stephen Smith Jr. b...@iguanasuicide.net wrote:
 In aanlktikwokffmtyfhi-yy7j=_fx8_44wbcbu3vcc6...@mail.gmail.com, Jordi
 Gutiérrez Hermoso wrote:
On 11 October 2010 12:11, Boyd Stephen Smith Jr. b...@iguanasuicide.net
 wrote:
 It gets used as unstable+1 during the freeze, since  there's no better
 place.

So why not create a better place?

 Because of the limited utility, which I mentioned in the message to which you
 replied.  First, it only has any use during a freeze.

Only during a freeze ends up meaning six months or longer. You
think that's a short time? It's one full Ubuntu release cycle!

- Jordi G. H.


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktimuz1ob7pybjm6y6eur301o1oqy32u+soj3y...@mail.gmail.com

Re: Uploading during freeze time

On 11 October 2010 20:01, Russ Allbery r...@debian.org wrote:
 Jordi Gutiérrez Hermoso jord...@gmail.com writes:
 Boyd Stephen Smith Jr. b...@iguanasuicide.net wrote:

 It gets used as unstable+1 during the freeze, since there's no better
 place.

 So why not create a better place?

 What specifically is wrong with experimental?  In other words, what
 problem are you trying to fix other than that you don't like the name?

Look at Iceweasel for a concrete example. We have an embarrassing
situation where the latest *stable* release, which has been amply
tested by *millions* of users worldwide ends up in the experimental
branch. It's not there because we actually think it's experimental, or
bad enough that it could potentially incur data loss due to bugs. No,
Iceweasel is in experimental due to vagaries of our release cycle that
non-developers should not concern themselves with.

So the promises implied by the spectrum of answers to do you want it
new, xor do you want it stable? gets broken during freeze time
because the usual place to upload untested software is occupied by the
freeze cycle.

That is what I don't like. I think it could be done in a better way.


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktim2zczty0q1xuc+aocrl0lfyz4q6j1ieqf9w...@mail.gmail.com

Re: Rescue Plan for apt-listbugs

2010-10-11 Thread Francesco Poli

On Mon, 11 Oct 2010 14:30:27 +0800 Paul Wise wrote:

On Sun, Oct 10, 2010 at 1:22 AM, Francesco Poli f...@firenze.linux.it wrote:
[I wasn't Cc:ed, hence I see your message only now, and I am replying
after manually quoting the text from the web archive and manually
setting the In-Reply-To field: I hope this won't break the thread;
apologies if it does!]

CCed you.

Thanks!

What if I already have the cloned repository (I've used it so far to
prepare patches that I've sent to Ryan via e-mail...) and it was cloned
via the git protocol at the time?
[...]
I would delete the remote that clones over git:// and rename the other one.

git remote rm origin
git remote rename alioth origin

Thanks, I will consider this option, even though I must admit that
having two remotes (one over ssh to push to, and one origin over the
git protocol to pull from) does not sound so weird to me.
The origin remote was created when I initially cloned the repository
over the git protocol: I had no push permissions at the time, hence I
could not clone over ssh (right?).
Now that I got push permissions, I can add a special alioth remote
over ssh, in order to push...

$ git checkout -b $MY_COOL_BRANCH_NAME origin

You want origin/master here.

I thought that origin was a shortcut for origin/HEAD:
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#how-git-stores-references
and origin/HEAD seems to be equivalent to origin/master on my
cloned repository:

When I do your proposed command I get this:

$ git checkout -b test origin
fatal: git checkout: updating paths is incompatible with switching branches.
Did you intend to checkout 'origin' which can not be resolved as commit?

It has always worked for me...

$ git branch -r
origin/HEAD - origin/master
origin/compare-version-accelerator
origin/make_list_work
origin/master
origin/try-index-with-soap
origin/update-po
origin/vimbts

Anyway, if I understand correctly, your suggestion is to use
origin/master, since it is a more general strategy.
Right?

Hmm, I don't have origin/HEAD on the test repo I was using:

$ git branch -r
origin/master

This may perhaps explain why the above mentioned command does not work
for you.

$ git checkout $MY_COOL_BRANCH_NAME git rebase origin

Probably s/origin/master/

origin and master should be identical at this point, since I've
just pulled while on branch master.
Or am I wrong?

Anyway, since I am then going to pull the rebased branch on the
master branch, you're probably right that the most correct rebase is
a git rebase master.
Could you please confirm that this is what you meant?

Yep.

Good, thanks for confirming!

Paul, I would like to thank you for all the help you provided.
It's really appreciated.

--
http://www.inventati.org/frx/progs/scripts/pdebuild-hooks.html
Need some pdebuild hook scripts?
. Francesco Poli .
GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4

pgpr0DpFo6mNK.pgp
Description: PGP signature

Re: Uploading during freeze time


On Tue, 12 Oct 2010, Jordi Gutiérrez Hermoso wrote:


On 11 October 2010 20:28, Boyd Stephen Smith Jr. b...@iguanasuicide.net wrote:

In aanlktikwokffmtyfhi-yy7j=_fx8_44wbcbu3vcc6...@mail.gmail.com, Jordi
Gutiérrez Hermoso wrote:

On 11 October 2010 12:11, Boyd Stephen Smith Jr. b...@iguanasuicide.net

wrote:

It gets used as unstable+1 during the freeze, since  there's no better
place.


So why not create a better place?


Because of the limited utility, which I mentioned in the message to which you
replied.  First, it only has any use during a freeze.


Only during a freeze ends up meaning six months or longer. You
think that's a short time? It's one full Ubuntu release cycle!


With releases once every (about) two years, that's about/at-least 1/4 of 
the time.


I give that (rough) figure to indicate that I agree with Jordi that 
during-the-freeze is actually a pretty large amount of time.


I'm not currently offering any proposals, just sympathizing. Sometimes you 
really feel that a new upstream release is better (alpine 2.02 is just bug 
fixes, none of which are release critical though, so alpine 2.00 is what 
we'll release with). But of course I might be wrong... but if I got alpine 
2.02 into unstable despite the freeze, users would be able to test it and 
figure out that it's not any worse than alpine 2.00...


Oh, eek, actually, I did upload 2.02 into unstable, in violation of the 
freeze. I feel kind of bad about that.


Now I just feel kind of embarrassed and will go back to doing other 
things


-- Asheesh.

--
Tomorrow, you can be anywhere.

Re: Uploading during freeze time

Jordi Gutiérrez Hermoso jord...@gmail.com writes:

 So the promises implied by the spectrum of answers to do you want it
 new, xor do you want it stable? gets broken during freeze time because
 the usual place to upload untested software is occupied by the freeze
 cycle.

Oh, so the specific problem that you're trying to fix is that you, as an
unstable user, aren't getting software that you would like to be using
because unstable is being used for a different purpose during the freeze?

I assume you don't feel comfortable with just installing software from
experimental because you're concerned that it may really be broken and
non-functioning?

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87r5fws57m@windlord.stanford.edu

Re: RFS: c2html (updated package) [Highlight C sources for WWW presentation]


On Mon, 11 Oct 2010, Mònica wrote:


Dear mentors,

I am looking for a sponsor for a new version 0.9.6-3
of the package c2html.


Hi Mònica,

Thanks for doing this! The best place to find people who are interested in 
maintenance on orphaned packages is the QA Team.


http://wiki.debian.org/qa.debian.org is supposed to explain what they do, 
but really http://qa.debian.org/ explains better.


So I suggest you send the same note along to the debian-qa email list and 
see what they say. http://wiki.debian.org/qa.debian.org/Join explains how 
communicate with the team.


Thanks for your contribution, and I hope the QA team finds a good way to 
use it! For your own sanity's sake, you can apply the same Four days 
rule there -- if you don't hear back from that team within four days, ask 
again. If within another four days you don't hear back again, please come 
back to debian-mentors explaining that they were nonresponsive.


That might sound like a lot of communication, but communication is what 
the Debian project runs on. (-:


Again, good work -- quality work like this on orphaned packages is hugely 
important.


-- Asheesh.

--
You need more time; and you probably always will.

Re: RFS: disco

2010-10-11 Thread David Bremner

On Mon, 11 Oct 2010 22:13:43 +0200, Niels Thykier ni...@thykier.net wrote:
 -BEGIN PGP SIGNED MESSAGE-

 While I am not a python/erlang/etc. packager, I did a small review of
 your package. It is quite possible that I missed some issues that a
 second reviewer will find (particularly if said review knows anything
 about packaging python or erlang).

Please double check your package for embedded libraries. I saw what
looked like libjs-jquery. You should (almost always) ensure your binary
packages are not using the embedded version.  See

http://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles

for more information.

d


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87k4logvjw@rocinante.cs.unb.ca

Re: RFS: roxterm (updated package) [highly configurable terminal emulator]

2010-10-11 Thread Kumar Appaiah

Hi!

On Mon, Oct 11, 2010 at 06:37:49PM +0100, Tony Houghton wrote:
 The upload would fix these bugs: 598971
 
 The bug can affect which environment variables roxterm decides to set or
 change in its child shells. The specific problem experienced in Ubuntu
 Maverick (not setting TERM correctly) is unlikely to affect Debian,
 because Debian's older vte library sets TERM whereas Maverick's doesn't.
 However, the bug still has potential to cause weird things to happen
 with environment variables and the fix is very simple, so I think it
 should be included in squeeze.

I'll take this. The change seems minimal, so I'll sponsor it. Please
be sure to request the release team for a freeze exception.

Thanks for mailing the request again, and thank you for contributing
to Debian!

Kumar
-- 
Who is General Failure and why is he reading my hard disk ?
Microsoft spel chekar vor sail, worgs grate !!
(By leit...@inf.fu-berlin.de, Felix von Leitner)


signature.asc
Description: Digital signature

Re: Uploading during freeze time

.On 12 October 2010 01:02, Russ Allbery r...@debian.org wrote:

 Oh, so the specific problem that you're trying to fix is that you, as an
 unstable user, aren't getting software that you would like to be using
 because unstable is being used for a different purpose during the freeze?

I guess so, although I don't personally even use unstable myself for
the aforementioned reasons. However, unstable is used as the desktop
version of Debian by a large number of users, and the awkward
development it gets during freeze time is not really fixed by
experimental.

The *real* problem is that labelling Firefox 3.6 as experimental is
downright silly.

- Jordi G. H.


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlkti=b2g8e8vg5h87buppwc-4-oh0zcqzujswcn...@mail.gmail.com

Re: Uploading during freeze time

Jordi Gutiérrez Hermoso jord...@gmail.com writes:

 I guess so, although I don't personally even use unstable myself for the
 aforementioned reasons. However, unstable is used as the desktop
 version of Debian by a large number of users, and the awkward
 development it gets during freeze time is not really fixed by
 experimental.

 The *real* problem is that labelling Firefox 3.6 as experimental is
 downright silly.

Hm, okay.  I guess I'm not feeling particularly inspired to do any work
based on that reaction.  Names are pretty arbitrary, and having the name
be what you consider to be the most urgent problem makes me think this
isn't really an issue.  It's not Firefox 3.6 that's experimental,
regardless; it's at most the *Debian packaging* of it, which is a distinct
entity.

I can see the argument of people who'd like to have new software in
unstable during the freeze period since they're not very interested in the
stable release, and that's come up before (such as in the CUT
discussions), but as with your note above, this seems most often to be an
argument made theoretically by people who aren't personally having
significant issues.

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/877hhos2fs@windlord.stanford.edu

Re: RFS: disco

2010-10-11 Thread Janos Guljas

Hi David,

On Tue, Oct 12, 2010 at 1:26 AM, David Bremner brem...@unb.ca wrote:
 On Mon, 11 Oct 2010 22:13:43 +0200, Niels Thykier ni...@thykier.net wrote:
 -BEGIN PGP SIGNED MESSAGE-

 While I am not a python/erlang/etc. packager, I did a small review of
 your package. It is quite possible that I missed some issues that a
 second reviewer will find (particularly if said review knows anything
 about packaging python or erlang).

 Please double check your package for embedded libraries. I saw what
 looked like libjs-jquery. You should (almost always) ensure your binary
 packages are not using the embedded version.  See

    http://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles

 for more information.

 d



As I see, there is only one copy of jquery library
master/www/js/jquery-1.2.1.js which is removed and linked in
debian/rules. Another copy which in disco-doc package as a result of
python-sphinx work is also removed and linked. If there is another
copy that I missed, could you point it out?


Thanks for getting interested in this package,
Janoš Guljaš


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktinxt1yyffxif+p1mbe0ohn2rsnhzg29+hatq...@mail.gmail.com

Re: RFS: disco

2010-10-11 Thread Janos Guljas

Hi Niels,

Thank you for reviewing this package.

On Mon, Oct 11, 2010 at 10:13 PM, Niels Thykier ni...@thykier.net wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2010-10-06 20:47, Janos Guljas wrote:
Dear mentors,

I am looking for a sponsor for my package disco.

* Package name : disco
Version : 0.3.1-1
Upstream Author : Ville Tuulos tuu...@gmail.com
* URL : http://github.com/tuulos/disco/downloads
* License : GPL-2+
Section : admin

It builds these binary packages:
disco-doc - A distributed computing framework - documentation
disco-master - A distributed computing framework - master
disco-node - A distributed computing framework - node
python-disco - A distributed computing framework - client python module
python-discodb - An efficient, immutable, persistent mapping object Disco
python-discodex - Distributed indices for Disco

[...]

Kind regards
Janos Guljas

Thanks for considering to contribute to Debian, your help is much
appreciated. :)

While I am not a python/erlang/etc. packager, I did a small review of
your package. It is quite possible that I missed some issues that a
second reviewer will find (particularly if said review knows anything
about packaging python or erlang).

That aside, here is what I got:

You got two license files in
contrib/discodex/lib/discodex/restapi/
master/src/mochiweb/

which mentions a copyright holders and/or licenses not mentioned in
d/copyright. Their presence implies that the respective subdirectories
are copyrighted and licensed as described in those license files (unless
individual files in those directories state otherwise).

Hm, licensecheck did not pointed them out, and I didn't do manual
check for licences. Thanks, they are in debian/copyright file now.

Why do disco-master Pre-Depends on python-disco? I see nothing in the
preinst script that suggests that python-disco must be present before
disco-master is unpacked.

Python module disco is needed for starting python-master.
Python-setuptools on disco python module must be triggered before
running /etc/init.d/disco-master start, which is done after installing
python-disco. Trying to start disco-master before configuring
python-disco package will fail.

There is a reference in preinst disco-master and disco-nodes to
/etc/init.d/disco-node
but neither of them appears to install that script.

Yes, that was left because upstream packaging is using that. It seems
deprecated, and I'll remove references.

Is disco-master really an arch:any package? It appears to only contain
image files, javascript, python scripts and html files?

Hm, yes, you are right. My mistake.

I am not much of a Python packager, but I suspect you should not be
getting this warning.
dpkg-deb: warning: 'debian/$pkg/DEBIAN/control' contains user-defined
field 'Python-Version'

I believe that this filed is here because of XB-Python-Version under
debian/control. Debian Python Policy requires that filed
http://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html#s-specifying_versions.

Probably you want X-Python-Version or XS-Python-Version (check the
Debian Python documentation or with the Python Team).

I'll see with them about that.

It fails to build from source if Build-Depends-Indep are not satisfied
when dpkg-buildpackage is invoked with -B:
[...]
sphinx-build -b html -d .build/doctrees . .build/html
make[2]: sphinx-build: Command not found
[...]

This is how auto-builders will build your package. As I recall the
debian-policy is disagreeing with reality here. I believe there is an
attempt to make these two agree, but for now your package must be able
to build without Build-Depends-Indep when dpkg-buildpackage is passed -B.

Are you suggesting to move references from:
Build-Depends-Indep: python-sphinx, libjs-jquery
to Build-Depends?

With that set, cowbuilder --build disco_0.3.1-1.dsc --buildresult .
--binary-arch is building packages fine. But I do not understand the
reason for -B option in autobuild scripts. Do you have some references
that can clarify reason for it. Until now, I tested packages without
--binary-arch build. I see now that this is a requirement.

Have you contacted (or considered to contact) the python application
team about team maintaining the package? (See [1] for more info).

Yes, but I am not sure is this belongs to DMPT or PAPT. There are
modules and application packages...

If you have any questions or comments about the things I mentioned (or
anything else regarding your package) then feel free to write back.
~Niels

[1] http://wiki.debian.org/Teams/PythonAppsPackagingTeam

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJMs2/1AAoJEAVLu599gGRCwoQP/ipOCKeee+5NOgmSE+DW051y
dYfYnAGYZ6coGVmNVwlz4+SGy+d9JeGRwhHbAhG9pclYo94r3SdD7arTH09BeS+3

Re: RFS: emerald

2010-10-11 Thread Janos Guljas

Dear mentors,

I am kindly asking if there is someone who can sponsor emerald and
emerald-themes http://lists.debian.org/debian-mentors/2010/09/msg00246.html
packages?

Thanks in advance.

Best,
Janoš Guljaš


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktikb3ma_4veabgla6vxom98zafwgf0qhjefku...@mail.gmail.com

Re: Uploading during freeze time

2010-10-11 Thread Boyd Stephen Smith Jr.

On Monday, October 11, 2010 17:01:16 you wrote:
On 11 October 2010 20:28, Boyd Stephen Smith Jr. b...@iguanasuicide.net 
wrote:
 In aanlktikwokffmtyfhi-yy7j=_fx8_44wbcbu3vcc6...@mail.gmail.com, Jordi
 Gutiérrez Hermoso wrote:
On 11 October 2010 12:11, Boyd Stephen Smith Jr. b...@iguanasuicide.net
wrote:
 It gets used as unstable+1 during the freeze, since  there's no better
 place.

So why not create a better place?

 Because of the limited utility, which I mentioned in the message to which
 you replied.  First, it only has any use during a freeze.

Only during a freeze ends up meaning six months or longer. You
think that's a short time? It's one full Ubuntu release cycle!

There's no reason Debian freezes must last six months or longer.  Still, even 
at that rate, the Debian freeze time would be proportionally less than the 
time before a Ubuntu release where packages are not pulled from unstable.

Squeeze: Development started 2009-02-15, Freeze started 2010-08-06, Release 
approximately 2011-02-06.  Freeze as a percentage of cycle: ~25%.  (I actually 
expect an earlier release; that date is based on being frozen for 6 months.  
If we release for Christmas, it is closer to 20%.)

Maverick: Development started 2010-05-06, Freeze started 2010-06-24, Release 
2010-10-10.  Freeze as a percentage of cycle: ~80%.  (This is based on when 
the automatic import from Debian unstable stops. Using the freeze date where 
release managers get involved, you still get ~40%.  Using the last freeze 
date, you still get 20%.)
-- 
Boyd Stephen Smith Jr.   ,= ,-_-. =.
b...@iguanasuicide.net   ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/\_/


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

Re: Uploading during freeze time

On Mon, 11 Oct 2010, Russ Allbery wrote:

Jordi Gutiérrez Hermoso jord...@gmail.com writes:

I guess so, although I don't personally even use unstable myself for the
aforementioned reasons. However, unstable is used as the desktop
version of Debian by a large number of users, and the awkward
development it gets during freeze time is not really fixed by
experimental.

The *real* problem is that labelling Firefox 3.6 as experimental is
downright silly.

Hm, okay. I guess I'm not feeling particularly inspired to do any work
based on that reaction. Names are pretty arbitrary, and having the name
be what you consider to be the most urgent problem makes me think this
isn't really an issue. It's not Firefox 3.6 that's experimental,
regardless; it's at most the *Debian packaging* of it, which is a distinct
entity.

I can see the argument of people who'd like to have new software in
unstable during the freeze period since they're not very interested in the
stable release, and that's come up before (such as in the CUT
discussions), but as with your note above, this seems most often to be an
argument made theoretically by people who aren't personally having
significant issues.

I'm a Debian desktop user who runs Iceweasel from Debian, and I have an
issue which is that:

* Firefox 3.5-based browsers crash more often than 3.6.4 and above. See
also
http://blog.mozilla.com/blog/2010/06/22/firefox-3-6-4-with-crash-protection-now-available/

* Extensions get updated by upstream, and I can't install the most recent
versions because they're not compatible with my browser.

* Firefox 3.6 has faster JavaScript, which is the difference between this
page being usable, and it not: http://openhatch.org/people/. (Admittedly
that's a site under my control, so I can improve it; but there are surely
other such pages.)

And so on.

We're going to ship the crashier (since plugins are in-process) 3.5.x
Firefox code to the millions/thousands/whatevers of Debian users in
squeeze, even though we could have possibly shipped 3.6. That's because of
the freeze, and surely lots of complex issues relating to xulrunner
dependencies. But it would be less of a big deal if the freeze lasted less
time.

If I feel this strongly, I should probably join the Mozilla applications
packaging team. I may yet do that. Actually, I guess I should do that
right now.

http://wiki.debian.org/Teams/DebianMozAppsTeam?action=fullsearchcontext=180value=mozilla+teamtitlesearch=Titles
returns no results...

http://packages.debian.org/experimental/iceweasel indicates that (1) I can
have Fx 3.6 (sweet, I'll install that right now) and (2) that
http://lists.alioth.debian.org/mailman/listinfo/pkg-mozilla-maintainers is
the list to join.

I've now joined it. If anyone else wants to come there with me, I bet we
can make the Mozilla apps teams' lives better. (-:

Also, I realize I can help the freeze be shorter -- fix a release-critical
bug. I'll remember to keep that on the queue.

(This email is now just me rambling, not me having a point. I think.)

-- Asheesh.

--
Many pages make a thick book.

Re: Uploading during freeze time

2010-10-11 Thread Paul Wise

On Tue, Oct 12, 2010 at 12:06 PM, Asheesh Laroia ashe...@asheesh.org wrote:

 * Firefox 3.6 has faster JavaScript, which is the difference between this
 page being usable, and it not: http://openhatch.org/people/. (Admittedly
 that's a site under my control, so I can improve it; but there are surely
 other such pages.)

Since that is a site under your control, please consider switching it
to OpenStreetMap instead of Google Maps.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktinhngcqrf0umthknbzkzcr+povipwbvs7ph=...@mail.gmail.com

Re: Uploading during freeze time