Bug#928073: unblock: beancount/2.2.0-3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package beancount
Santiago Villa has discovered an unpredictability in the cleanup of a gnupg
socket file, which might randomly make the package FTBFS. The version I've just
uploaded to unstable includes a patch by Santiago that fixes this. It would be
nice to have this fix in testing, to make rebuilding the next stable release
more predicatble.
debdiff attached.
unblock beancount/2.2.0-3
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru beancount-2.2.0/debian/changelog beancount-2.2.0/debian/changelog
--- beancount-2.2.0/debian/changelog2019-01-14 10:01:37.0 +0100
+++ beancount-2.2.0/debian/changelog2019-04-21 17:00:36.0 +0200
@@ -1,3 +1,11 @@
+beancount (2.2.0-3) unstable; urgency=medium
+
+ [ Santiago Vila ]
+ * patches/0003: Ignore FileNotFoundError from self.tmpdir.cleanup().
+Fixes a FTBFS problem which happens randomly (Closes: #923606)
+
+ -- Stefano Zacchiroli Sun, 21 Apr 2019 17:00:36 +0200
+
beancount (2.2.0-2) unstable; urgency=medium
* rules: do not ship *.picklecache files with Python examples (fixes
diff -Nru
beancount-2.2.0/debian/patches/0003-Ignore-FileNotFoundError-from-self.tmpdir.cleanup.patch
beancount-2.2.0/debian/patches/0003-Ignore-FileNotFoundError-from-self.tmpdir.cleanup.patch
---
beancount-2.2.0/debian/patches/0003-Ignore-FileNotFoundError-from-self.tmpdir.cleanup.patch
1970-01-01 01:00:00.0 +0100
+++
beancount-2.2.0/debian/patches/0003-Ignore-FileNotFoundError-from-self.tmpdir.cleanup.patch
2019-04-21 17:00:36.0 +0200
@@ -0,0 +1,18 @@
+From: Santiago Vila
+Date: Sun, 21 Apr 2019 16:48:40 +0200
+Subject: Ignore FileNotFoundError from self.tmpdir.cleanup()
+
+--- a/beancount/utils/encryption_test.py
b/beancount/utils/encryption_test.py
+@@ -98,7 +98,10 @@
+ self.run_gpg('--import', stdin=TEST_SECRET_KEY.encode('ascii'))
+
+ def tearDown(self):
+-self.tmpdir.cleanup()
++try:
++self.tmpdir.cleanup()
++except FileNotFoundError:
++pass
+
+ def run_gpg(self, *args, **kw):
+ command = ('gpg',
diff -Nru beancount-2.2.0/debian/patches/series
beancount-2.2.0/debian/patches/series
--- beancount-2.2.0/debian/patches/series 2019-01-14 10:01:37.0
+0100
+++ beancount-2.2.0/debian/patches/series 2019-04-21 17:00:36.0
+0200
@@ -1,2 +1,3 @@
0001-Remove-fonts.googleapis.com-links-for-the-bean-web-t.patch
0002-make-test_version-more-lax-to-accept-non-git-hg-vers.patch
+0003-Ignore-FileNotFoundError-from-self.tmpdir.cleanup.patch
Bug#772968: unblock: dose3/3.3~beta1-3
On Sun, Dec 14, 2014 at 10:17:37AM +0100, Mehdi Dogguy wrote: Did you also request binNMUs for reverse dependencies? I didn't, because I was under the impression that dose3 didn't have any reverse dependencies. I see now that there is at least ceve. My bad. If you have handy a full list of reverse deps, can you submit the binNMU requests directly? Otherwise I'll look them up. Thanks for spotting this! Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Bug#772968: unblock: dose3/3.3~beta1-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package dose3 The upload fixes #772875, by demoting a trigger from (implicit) await to noawait; there was no real reason for blocking in the first place. The upload also include a oneline change to debian/watch, to include a uversionmangle (tentatively ACK-ed on #debian-release). Here is a debdiff: - diff -Nru dose3-3.3~beta1/debian/apt-cudf.triggers dose3-3.3~beta1/debian/apt-cudf.triggers --- dose3-3.3~beta1/debian/apt-cudf.triggers2014-10-21 20:53:10.0 +0200 +++ dose3-3.3~beta1/debian/apt-cudf.triggers2014-12-12 16:41:11.0 +0100 @@ -1 +1 @@ -interest /usr/share/cudf/solvers +interest-noawait /usr/share/cudf/solvers diff -Nru dose3-3.3~beta1/debian/changelog dose3-3.3~beta1/debian/changelog --- dose3-3.3~beta1/debian/changelog2014-10-21 20:53:10.0 +0200 +++ dose3-3.3~beta1/debian/changelog2014-12-12 16:41:11.0 +0100 @@ -1,3 +1,16 @@ +dose3 (3.3~beta1-3) unstable; urgency=medium + + [ Stefano Zacchiroli ] + * demote trigger on /usr/share/cudf/solvers from interest to +interest-noawait: there is no real need to block, and doing so avoid +trigger cycles. Thanks Guillem Jover for the heads-up. +(Closes: #772875) + + [ Johannes Schauer ] + * fix debian/watch (add uversionmangle) + + -- Stefano Zacchiroli z...@debian.org Fri, 12 Dec 2014 16:39:24 +0100 + dose3 (3.3~beta1-1) unstable; urgency=low [ Ralf Treinen ] diff -Nru dose3-3.3~beta1/debian/watch dose3-3.3~beta1/debian/watch --- dose3-3.3~beta1/debian/watch2014-10-21 20:53:10.0 +0200 +++ dose3-3.3~beta1/debian/watch2014-12-12 16:41:11.0 +0100 @@ -1,2 +1,3 @@ version=3 -https://gforge.inria.fr/frs/?group_id=4395 .*/dose3-(.*)\.tar\.gz \ No newline at end of file +opts=uversionmangle=s/-/~/ \ +https://gforge.inria.fr/frs/?group_id=4395 .*/dose3-(.*)\.tar\.gz - unblock dose3/3.3~beta1-3 -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141212155256.12284.46147.reportbug@timira.takhisis.invalid
Re: Aw: Re: Adding cloud-init in the next Wheezy point release
On Tue, May 07, 2013 at 09:24:00PM +0800, James Bromberger wrote: 1) Use backports by default in apt.source in cloud images, and we bless this as still being Debian Personally, I am happy with #1, so long as the rest of the community is. Given that backports are not installed by default, I don't think the matter of whether backports is *present* in sources.list alone is enough to define the problem. It's rather how many packages we have to install from it, and how relevant they are. Considering that, AFAICT, we're talking only about cloud-init, and considering its relevance for the cloud images, I think installing it from backports in the cloud images would be acceptable. (And, as we discussed earlier on, at that point you really want to have backports in sources.list, to avoid missing updates for the backported package.) What we should certainly do is have some Debian documentation specific for the cloud images, which include a list of differences from regular images. (But before talking about this, we should probably look into having a get Debian page for Debian cloud images :-)) Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: CD sizes again (and BoF reminder!)
On Sun, Jul 08, 2012 at 12:03:44AM +0200, Cyril Brulebois wrote:
Ansgar Burchardt ans...@debian.org (07/07/2012):
Another question is if the release team would consider unblocking
updated packages (with just the switch to xz for binaries). I think
it would be nice to be able to get a useful desktop system using just
the first CD, but I'm not sure if they would make an exception for
this.
You may want to actually ask the release team at some point, if you want
to know. Just saying…
Thanks for the brilliant idea! :-)
Oh all mighty release team,
Ansgar has been experimenting with .deb sizes to make the packages
needed for a minimal desktop installation fit in the first CD. It looks
like that's doable by switching to xz compression for the involved
binaries. Would you grant freeze exceptions for packages that only
changes that?
See attached email and the corresponding thread on -devel for more info.
Thanks!
Cheers.
--
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences .. http://upsilon.cc/zack .. . . o
Debian Project Leader... @zack on identi.ca ...o o o
« the first rule of tautology club is the first rule of tautology club »
---BeginMessage---
Steve McIntyre st...@einval.com writes:
On Fri, Jul 06, 2012 at 09:00:32PM -0600, Ansgar Burchardt wrote:
I tried recompressing all packages in wheezy with xz. The total size
for all amd64+all packages was reduced from 42GB to 33 GB (about 20%).
A per-package listing is available from [1]
[1] http://people.debian.org/~ansgar/wheezy-20120706-with-xz.txt.gz
Would this be enough to make GNOME and/or KDE installable from a single
CD image?
Using rough calculation:
* For GNOME, it takes about 185MB out of the space used to get up to
task-gnome-desktop. Instead of being ~90MB into CD#2, that's ~100MB
inside CD#1.
* For KDE, it takes about 170MB out of the space used to get up to
task-kde-desktop. Instead of being ~70MB into CD#2, that's ~100MB
inside CD#1.
So, yes - looks like xz will make a difference here for the wheezy
release, for amd64 at least. It's enough that we'd probably even have
space for the installation manual and release notes to fit \o/.
i386 is still worse off (2 kernels instead of 1), but I don't have the
exact figures to hand.
We need a safety margin as the base system must continue to use gzip
compression. But my feelings say that 100 MB should be enough for that.
Another question is if the release team would consider unblocking
updated packages (with just the switch to xz for binaries). I think it
would be nice to be able to get a useful desktop system using just the
first CD, but I'm not sure if they would make an exception for this.
Ansgar
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87r4snohc6@marvin.43-1.org
---End Message---
signature.asc
Description: Digital signature
Re: 5... 4... 3... 2... 1...
On Sat, Jun 30, 2012 at 09:20:55PM +0100, Adam D. Barratt wrote:
As previously announced[1], testing is now frozen.
Kudos!
Thanks a lot (to the release team) for your release coordination work.
I love it when a --- time-based freeze --- plan comes together!
... let's now see if it also quicken the release ;-)
Zack, leaving for Debcamp, and happy.
--
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences .. http://upsilon.cc/zack .. . . o
Debian Project Leader... @zack on identi.ca ...o o o
« the first rule of tautology club is the first rule of tautology club »
signature.asc
Description: Digital signature
Re: Bug#678746: desktop-base: Joy theme is a mix of incompatibly-licensed works
On Sun, Jun 24, 2012 at 06:57:03PM +0200, Adrien Aubourg wrote:
As I've been asked to write Debian on the installer picture, could
be there any license trouble to do so ?
Adrien, if it's not too much work, could you please prepare two
different versions of the installer picture, one with the official
(currently) non-free typeface of the with debian logo at
http://www.debian.org/logos/ and one with a DFSG-free typeface.
I'm still positive we can do the relicensing of the currently non-free
typeface in time for Wheezy. But clearly not in time for the freeze. So
if there could be two versions of it, we can choose between either:
1) ship now the non-free version and have an RC bug against it for the
non-freeness
2) ship now the free version and ask for a freeze exception to include
the official typeface later on. *If* the only difference is in a
difference typeface in an otherwise identical image, then hopefully
the risks of inducing regressions will be minimized.
Choosing among these two options is probably better left to the
desktop-base maintainers + the release team. I guess that (2) is a more
conservative choice anyhow, that leaves us a releasable desktop-base
package even if the relicensing fails.
Cheers.
PS I just came back after 5 days of (Debian-related) traveling and I
still have to catch up with -desktop traffic
--
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences .. http://upsilon.cc/zack .. . . o
Debian Project Leader... @zack on identi.ca ...o o o
« the first rule of tautology club is the first rule of tautology club »
signature.asc
Description: Digital signature
Re: Debian artwork for Wheezy
On Tue, Dec 13, 2011 at 09:17:39PM -0200, Valessio Brito wrote:
I think the attempt to tender / call for proposal has already happened
more than once and did not work very well.
Well, it is also true we could have done more to advertise the call for
proposals. For instance, it seems to me that we did not send out a press
release asking for them for Squeeze. Nor we did advertise in similar
ways a user poll to choose one (in case the -desktop people actually
want to do so).
If you people want to give up on the idea of proposals, that's fine, of
course. But please consider that, starting ahead of time, we can do way
more publicity to the call for proposals than what we did for Squeeze.
Would not the construction of several themes, all parties could work
on a concept or theme predefined by the developers.
example:
The concept of sustainability and clean energy.
Or a topic related against planned obsolescence or free technologies.
If you do so, please be aware that it might be a slippery slope. In
particular, please keep in mind that Debian has an ethical position on
Free Software, but has no ethical position on topics like ecology,
economy, world peace, religion, etc.
Cheers.
--
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences .. http://upsilon.cc/zack .. . . o
Debian Project Leader... @zack on identi.ca ...o o o
« the first rule of tautology club is the first rule of tautology club »
signature.asc
Description: Digital signature
Re: Multiarch support in dpkg — really in time for wheezy?
On Sat, Oct 22, 2011 at 12:25:31PM +0200, Guillem Jover wrote:
On Fri, 2011-10-21 at 11:23:27 +0200, Raphael Hertzog wrote:
Given this, and if Guillem hasn't responded with a review requiring
further work on the branch by sunday, I will upload dpkg 1.16.2 to
experimental on sunday (October 23th).
snip
I will also ensure that this second upload happens.
NACK on both unreviewed uploads.
Guillem, I'm very much worried about this attitude.
[ Disclaimer: my only data points come from people who have been trying
to get m-a in the archive in the past several months, including the
Release Team and Raphael. I might hence be biased or misinformed. I've
been trying to get your POV in the past weeks without much success,
mainly due to our different availability periods on IRC, so let's have
this discussion here. ]
What worries me is that there is multi-arch work in dpkg, work that has
its origins in Debian. That work is ready enough to be deployed in
popular Debian derivatives such as Ubuntu, but is not in Debian proper
yet. That is bad for Debian morale and should be avoided. Moreover, that
work is also considered ready enough by other dpkg co-maintainers, by
the Release Team, and by various porters, which have all asked multiple
times to have that work in the Debian archive.
Looking from the outside, the only blockers for that to happen are your
NACK-s. Those NACKs have been posted repeatedly, together with (largely
disattended) promises of timely review, uploads, and git push-es of
yours.
Accepting this attitude would be very bad for Debian, because it is at
stake with the way we usually do things (AKA do-ocracy). Accepting
this attitude would indeed mean acknowledging that people who have
earned respect in the past as maintainers can stall work done by others
by simply saying NACK, without having to contribute alternative
solutions and/or show progress. We cannot allow that to happen in
Debian.
I'm very happy to see that some git push -es of yours are now flowing
into dpkg.git. I thank you for that. But it also seems that is happening
way slower than what is needed. (And TBH the thought of you hurrying up
now in doing such a work is worrisome in its own right.)
Please be a team player. If you can make it, that's great, we will all
benefit from extra eyes on the code, especially if they are experienced
eyes as yours. But if you cannot make it, please step back and allow for
uploads to happen. In case you are not willing to do that, I'd be in
favor of having other dpkg co-maintainers doing the uploads the Release
Team is asking for. After all, there is nothing that cannot be fixed
later in subsequent uploads.
Cheers.
--
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences .. http://upsilon.cc/zack .. . . o
Debian Project Leader... @zack on identi.ca ...o o o
« the first rule of tautology club is the first rule of tautology club »
signature.asc
Description: Digital signature
Re: SAT based britney
Stefano Zacchiroli
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams
signature.asc
Description: Digital signature
Re: time based freezes
[ M-F-T to -devel ]
On Thu, Apr 07, 2011 at 06:00:09PM +0200, Stefano Zacchiroli wrote:
Another thread, another thread summary! Here is a summary about where we
are on this discussion, at least as far as I can tell.
Lather, rinse, repeat.
snip
I would love if we can summarize the above part by saying that we have
consensus on: 1) announcing at the beginning of a release cycle a target
freeze month, 2) refining it later on.
This seems to be uncontroversial; modulo the fact that *if* the freeze
month is not absolute but relative (to the start of the cycle), people
might want to have a round of consultations with the release team before
a proposal is made. [1]
- On the other hand, a wide open front of the discussion is *when* to
freeze, with various people arguing in favor of having a specific
period, such as we freeze on $month every even/odd year.
Also considering the potential problems discussed, no objections have
been raised to such a scheme either. It seems this is something we might
want to try out.
Independently of the above, I've also received a few comments in private
mails on the risks that announcing a precise freeze day in advance
(i.e. close to the freeze month, according to the discussed scheme)
might be prone to last-minute uploads issues. While I understand the
problem, it seems to me that the alternative option of impromptu freeze
announces has its own set of problems (reducing the ability to plan in
advance and upsetting developers) which I believe outweighs the
advantages. All in all, this specific choice seems to be independent of
the general scheme of deciding a freeze month and stick to it.
Dear Release Team ... good luck in proposing a freeze month now :-)
Cheers.
[1] In my opinion, this is another argument in favor of absolute freeze
months, as it would make the whole cycle more resilient to
communication inertia (something we are trying to fight in general,
in several project areas), but I cannot claim this is part of
consensus as I'm introducing it only now.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams
signature.asc
Description: Digital signature
Re: Bits from the Release Team - Kicking off Wheezy
On Thu, Mar 31, 2011 at 01:28:01PM +0200, Stefano Zacchiroli wrote:
I propose the following additions:
1) No uninstallable packages, according to their dependencies, are
snip
2) No packages with (detectable) conflicts are shipped as part of a
snip
After Ralf's ack to document them for Wheezy, I've added the above two
to http://wiki.debian.org/ReleaseGoals/PackagesQuality
3) All packages with priority required and important have test suites
run at build time (of course it's hard to define test suite coverage,
so let's start with just saying that there should be a test suite in
the first place).
I've turned this one into
http://wiki.debian.org/ReleaseGoals/BuildTimeTestSuites (and linked it
from the ReleaseGoals page). At present, that would essentially mean
start to report bug against packages which have upstream build-time test
suites which are not run during Debian package build.
4) All packages with priority required and important have automatic
as-installed package test suites (cfr. DEP8); those test suite are
run before release and must not report any failure. (Same disclaimer
on coverage as per previous point applies.)
I've done the same as above for this one, which has become
http://wiki.debian.org/ReleaseGoals/RunTimeTestSuites. At present,
that is essentially blocked by the standardization of DEP8 / bit rot
review for autopkgtest (see recent discussion on the matter on this
list).
Comments are welcome, especially by the release team, as I've took the
liberty of fiddling with the release goals wiki page directly. Feel free
to list me as (one of) the shepherd/advocate for (3) and (4).
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams
signature.asc
Description: Digital signature
Re: Bits from the Release Team - Kicking off Wheezy
[ Bcc: -release to keep track of the actual proposals ]
On Wed, Mar 30, 2011 at 07:21:08PM +0200, Luk Claes wrote:
# package quality
Advocate: Holger Levsen and Luk Claes
State: confirmed
Wiki: http://wiki.debian.org/ReleaseGoals/PackagesQuality
This is a never ending goal of sustaining our packages quality by
improving our tests and following up closely... so needless to say that
I would still advocate this one.
Agreed ... although in that page there is essentially only the current
status rather than proposals for improvement in the Wheezy time frame,
or am I missing something?
I propose the following additions:
1) No uninstallable packages, according to their dependencies, are
shipped as part of a release. AFAIK this is already monitored
pre-release, and daily monitored at
http://edos.debian.net/uninstallable.php. If this is actually the
case, it should be added to the current status, otherwise mentioned
as a future improvement (and commit it to check it for releases).
2) No packages with (detectable) conflicts are shipped as part of a
release. This is not daily monitored, but periodically checked with
an initiative by Ralf Treinen described at
http://edos.debian.net/file-overwrites/. As above: we should
mention it, either as current status or as future improvement.
3) All packages with priority required and important have test suites
run at build time (of course it's hard to define test suite coverage,
so let's start with just saying that there should be a test suite in
the first place).
4) All packages with priority required and important have automatic
as-installed package test suites (cfr. DEP8); those test suite are
run before release and must not report any failure. (Same disclaimer
on coverage as per previous point applies.)
Both (3) and (4) are rather ambitious, but it's not by non proposing
them that we're going to advance on those topics. I'll be happy to be
listed as advocate for these goals, although I know I'll need help to be
able to push for them.
Regarding (4), it has an obvious dependency on DEP8 and on the
infrastructure needed to run the tests. We're still looking for help
willing to do both secretarial and infrastructure work to make that a
reality.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams
signature.asc
Description: Digital signature
Bug#607191: document that non-free Linux firmware has been moved to non-free
Package: release-notes Severity: important Starting from Squeeze, non-free Linux firmware has been moved to non-free. This is a great achievement for Debian! Still, we should take care that the poor users that are forced to use non-free firmware, as they own hardware for which no DFSG-free firmware exists, know how to install Debian on their machines. To that end, the release notes should probably document this change, especially in the part concerning installation from scratch (documenting where images with firmware can be found), but also for upgrades, as people might be forced to change their APT configuraiton to get the firmware they need. In doing so, we should take care of reminding what is part of Debian and what is not, as it has consequences on support. I'd be happy to comment/review on draft text, although I don't have time right now to draft a text from scratch right now (sorry about that). Many thanks for maintaining the release notes! Cheers. -- System Information: Debian Release: 6.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101215141123.17461.18836.report...@usha.takhisis.invalid
Bug#607193: document various download options/locations for Squeeze CD images
Package: www.debian.org Severity: important Starting with Debian Squeeze, there will be (more) download options/locations for CD images, be them netinst/complete/etc. In particular, users of specific pieces of hardware will be affected by the choice of images containing (or not) non-free firmware for the Linux kernel. We should document that on the website before the Squeeze release, obviously the prominent links should point to Debian images; links to non-free firmware images should be provided under big fat warnings that they are not part of Debian and supported only to the extent that not having their source code permits. Maybe, a link to the announcement text of today (http://www.debian.org/News/2010/20101215) can be provided too? I report this bug as important, as IMHO it should be fixed by the day Squeeze gets released. Many thanks in advance! Cheers. -- System Information: Debian Release: 6.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101215143250.17913.56657.report...@usha.takhisis.invalid
call for upgrade testing - debian news?
[ Mail-Followup-To: -publicity ]
Dear -publicity, you have surely already noticed the release update just
sent out by the release team.
I believe the call for upgrade testing and the matching call for
upgrade report triaging are worth a wider public than d-d-a. In
particular, the first one is suitable material for a call to *users*.
I propose to have a news item sent out with a call for upgrades,
mentioning also how people can help out with triaging. Any volunteer for
giving a first stab at a draft for it? (sorry for not doing one myself
yet, unfortunately I'm a bit on a hurry ATM ...)
Many thanks in advance,
Cheers.
- Forwarded message from Neil McGovern ne...@debian.org -
Date: Sun, 14 Nov 2010 19:25:42 +
From: Neil McGovern ne...@debian.org
To: debian-devel-annou...@lists.debian.org
Subject: Release Update - Upgrades, deep freeze info, BSPs
Hello!
It's time for another release update as we move, like a glacier,
inevitably and unstoppingly towards the release.
Release notes and upgrade/installation reports
==
Help is needed in this area. On one hand:
* since Squeeze is almost in its final form, it is a good time for the
brave to upgrade their systems, and inform of any troubles by filing a
bug against the upgrade-reports package.
* if you have new systems to install, testing of the Debian Installer
would be most welcome. As usual, please report any problems by filing
bugs against the installation-reports package.
On the other hand, we also need help in processing those bug reports,
particularly those filed against upgrade-reports. If you think you could
help with this, please do! Work involves figuring out what went wrong
with the upgrade, filing bug against the involved packages if
appropriate, and/or documenting the issue or workarounds in the Release
Notes.
We would also like help with letting everyone know what a great release
Squeeze will be, via the New In Squeeze page.
http://wiki.debian.org/NewInSqueeze
http://bugs.debian.org/release-notes
http://www.debian.org/releases/testing/releasenotes
http://www.debian.org/releases/testing/installmanual
snip
- End forwarded message -
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams
signature.asc
Description: Digital signature
Re: chromium not in Squeeze: a bit of communication needed?
On Wed, Sep 08, 2010 at 07:08:29PM +0200, Moritz Muehlenhoff wrote:
The plan for Chromium is to update it with the Chromium stable releases, i.e.
the same way Xulrunner has been updated during the supported life time of
xulrunner 1.9.0. Once these updates have stopped, the plan is apply
backported patches (again, like xulrunner is handled for lenny).
Thanks for this data point Moritz! I guess this settles the part about
security team support, which can be counted upon. Of course that alone
does not mean that we should have Chromium back: the package is not in
testing at present and will need to enter back, if ever, according to
usual release team policies. At least, we now have one doubt less :-).
Cheers.
PS regarding the other part of this thread about how to support, via
backports, what I would call rapidly evolving end-user apps, it is
surely a worthwhile discussion, more general than Chromium. I believe
it would be worth to have it elsewhere (e.g. -devel), possibly once
the needed feature requests (e.g. on APT) have been implemented. Note
that unless there is a chance to get those features into Squeeze,
it's probably a too-late-coming discussion.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Caposella ...| ..: |.. -- C. Adams
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100909100056.ga9...@upsilon.cc
chromium not in Squeeze: a bit of communication needed?
I've been following the chromium-browser saga a bit, who has ended up
with the removal of the package from testing [1,2]. While I'm a
chromium-browser user myself, and hence I'm saddened of seeing it go,
I'm not here to question the choice as I'm sure it's been made as the
right one and that it hasn't been an easy one to make.
[1] http://lists.debian.org/debian-release/2010/09/msg00582.html
[2]
http://www.iuculano.it/en/linux/debian/chromium-browser-removed-from-testing/
Still I think we need, as Debian, to communicate about that choice. As
you can imagine, I particularly care about that as sooner or later
someone will ask me « why Debian doesn't ship Chromium? », and I'd like
to know the right answer to that question, so that I can provide it,
rather than offering my personal view only :-)
That's all I care about. [3]
From the exchange on -release, I *guess* that the reason is that
Chromium 5 is not meant to be supportable security-wise and at the same
time that it's too late to get Chromium 6 into Squeeze. If this is the
case, I welcome explicit comments in that direction by the security and
release teams. If there are other reasons, please let me know.
Such an answer will be even more useful as, say, a kind of public
statement toward upstream, explaining why their practices are not
something that suite the quality requirements we have in Debian.
Many thanks in advance to all involved teams, and in particular to
Giuseppe who put a shitload of work in the packaging.
Please help me out in answering tricky questions like this one!
Cheers.
[3] A question you might have at this point is: why you bother about
Chromium and not other packages?. Well, I do bother about all
packages and I'm just trying to anticipate questions I'll might be
asked as soon as Squeeze get released. For instance and for the same
reason, I've proposed just yesterday to mention the removal of Plone
from Squeeze, and the maintainer has kindly agreed to explain the
reasons in the Squeeze release notes. So, I'm not special casing
anything here, and I encourage you to point me to other similar
cases.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Caposella ...| ..: |.. -- C. Adams
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100908114849.ga7...@upsilon.cc
Re: Meeting Minutes for the IRC Release Team Meeting on August 23, 2010
On Tue, Aug 24, 2010 at 12:28:15AM +0200, Philipp Kern wrote:
- upgrade-reports to be prepared and solicited [assignee: vorlon]
I'm very happy to read that you're on this. I've briefly discussed the
matter with Philipp at DebConf10 and I agree that we need to send out a
call for user upgrades ASAP.
To avoid burning out the remaining cycles of the release team :-), I
suggest to both send out a call for upgrades via debian-news
(-publicity is great for coordinating that) and to mention how to help
reviewing the upgrade reports on d-d-a, maybe as part of the next bits
from the release team.
For instance, I'm sure that a lot of people doesn't know about the
upgrade-reports pseudo package and, more importantly, they do not
necessarily know that the release team is actively using it.
If I can help in any way, just let me know.
Keep up the good work!
Cheers
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Caposella ...| ..: |.. -- C. Adams
signature.asc
Description: Digital signature
Re: User-testing of testing?
On Tue, Aug 10, 2010 at 11:40:29AM +0100, Enrico Zini wrote:
So I was wondering if we shouldn't have a list of user-centered
stable release goals, such as open a PDF attachment in icedove,
open an OpenDocument attachment in icedove, watch youtube videos,
copy a file to a USB key, which people trying a fresh testing
install could test.
snip
I however do not see an obvious way of collecting feedback for such user
tasks, or for having fights over which user tasks are the most
significant, without having people submit tasks to the release managers
and the release managers deciding which ones are worth making official,
which would be quite a burden to them.
Are there ways to set up such a thing so that it mostly manages itself?
I don't know a specific answer on your questions, but I do have some
lateral thinking/discussion to report. At DebConf10, I've spoken with
Philipp Kern about how to invite our users to test Squeeze before we
release it. We have agreed on the fact that we can do better than past
releases on that and the rough idea was to send out a press release
inviting willing users to do upgrades from Lenny to frozen Squeeze and
report the issues they find. We discussed how the best moment to do that
would have been post-freeze and it turns out that this is exactly *that*
moment.
The TODO list to go forward with this is:
- Decide where user feedback will have to go; the obvious answer is the
BTS, but we need to decide whether reuse some existing (pseudo)
package or create a new one for the occasion. IMHO it should be
something quite obvious for the users such as squeeze or
squeeze-upgrades or something like that.
- Draft a text to send out as press release, the title should probably
be something like User testing sought to improve the quality of the
forthcoming Debian Squeeze. The debian-public...@lists.d.o is
wonderful for reviewing this kind of stuff, but we need first to
decide the content of the press release. I propose the following main
points:
- please test upgrades from lenny to (frozen) squeeze
- please test ISOs/d-i
- please report issues THIS WAY
I believe that what you are looking for can later on be extracted from
user reports ... but of course we will need to find out a group of
Debian volunteers to do that triaging. The latter can probably be found
easily if the release team agrees on sending (later on) a specific call
for help via d-d-a (I'm kind of reluctant to add such duty to the
release team, given that they will be super-busy in the near future with
unblock requests and in getting the RC bug count down).
How does this plan sound?
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: User-testing of testing?
On Tue, Aug 10, 2010 at 11:09:04PM +0200, Luk Claes wrote:
- Decide where user feedback will have to go; the obvious answer is the
BTS, but we need to decide whether reuse some existing (pseudo)
package or create a new one for the occasion. IMHO it should be
something quite obvious for the users such as squeeze or
squeeze-upgrades or something like that.
There is upgrade-reports just for that reason...
Oh, right, I apologize for my ignorance of that package. What is the
appropriate way to tag upgrade reports so that we can easily filter on
lenny-squeeze upgrades or alternatively filter out past unrelated
reports?
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: User-testing of testing?
On Tue, Aug 10, 2010 at 11:59:03PM +0200, Luk Claes wrote:
I guess it would be best if they get a tag lenny or get closed when
they are not about upgrades to squeeze.
Any volunteer to do that (i.e. review + tagging) with the current
reports, before calling for other upgrades? If someone can volunteer
for that, I'll then draft the text that will call for upgrade testing.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: Eucalyptus Cloud infrastructure and kernels/initrds
On Sat, May 29, 2010 at 01:13:45AM +0200, Steffen Möller wrote:
since today, we have Eucalyptus in the archive, which
is a Free clone of the Amazon Web Services for computing
and storage. Stefano wants to tag Squeeze as cloud
ready, and, frankly, for the very exact moment nobody
really knows what this is supposed to mean.
Eh, let's not exaggerate with the buzz words :) I just want that users
interesting in run Debian on some cloud infrastructure (be it Amazon or
Eucalyptus-based) are aware of the fact that they can and that they are
supported by Debian in doing so (assuming we can make the needed
arrangements with the various involved teams).
So Debian is cloud ready already with
the advent of Eucalyptus in sid. But there is more to
it, like the synchronisation of releases with cloud
images. We are preparing for such an automated
synchronisation, but how much of that is automated
and how that is triggered, we don't really know for
the moment. Also we don't know if we need to plan
for any mirroring or if we can start with a single
site to offer immediately cloudifiable images.
I believe this is the most relevant part for -release. AFAIK the
pkg-eucalyptus team already has all the software to create on the fly
the needed images and kernel/initrds. The point is then which work-flow
do you want to synchronize with pkg-eucalyptus so that when a release is
updated, their images get updated too (assuming that the extra
coordination is not too much of an extra burden for -release). Similar
concerns exist for kernel alone and Steffen is getting in touch with the
kernel team about that.
Thanks to Steffen for raising the topic!
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: Eucalyptus Cloud infrastructure and kernels/initrds
On Sat, May 29, 2010 at 10:19:09AM +0200, Lucas Nussbaum wrote:
I think that enabling users to build their own customized images is
more in the spirit of doing things the Debian way, and also has the
advantage of not adding more work for any core debian team.
I've been told by the pkg-eucalyptus people that such a possibility is
already there. Still, the advantage of having pre-built images is that,
well, they're pre-built. You can for instance cook-up your own d-i
image, but you prefer to use one which is already built, right?
Upstream is very open towards Debian, actually an
official partnership is considered by both sides,
all postponed a bit until the situation at Eucalyptus
becomes less stressful again.
What does official partnership mean? How will it be binding for
Debian?
http://www.debian.org/partners/
But as reported that is still being evaluated on both sides, and is
really off-topic here.
I'm not sure I understand why it is so important to have upstream
developers involved directly with Debian, instead of using a DD (you) as
a proxy, as we do with 99.9% of our packages. Are we going to add all
our upstreams as DM? It seems to me that getting upstreams directly in
touch with core teams might result in a big loss of time on both sides
due to upstreams' lack of Debian knowledge.
I don't understand why this general discussion is relevant here. In
Debian we welcome anyone which has the technical qualities we ask for to
be contributors of any kind, up to DD. If some upstream are also
willing to do that, in addition to their upstream work, that's
good. Let's focus on the packages and their quality rather than on the
people, shall we?
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: Eucalyptus Cloud infrastructure and kernels/initrds
On Sat, May 29, 2010 at 01:29:13PM +0200, Steffen Möller wrote:
This Debian-like self-building is what is happening today and yes,
we can continue like that. My mail was just thought as an invitation
to think along, not as a request for anything. If the perfect answer is
VMbuilder I don't know yet. For some it definitely is and the others
may just use someone else's image.
Do you have daily build images (of some default profile) yet? If so,
maybe those can be advertised a bit more to seek for more testing,
feedback, etc. Also, having a pseudo-package or the like in the BTS
users can report bugs against would be useful (and needed anyhow if
we'll eventually have some releases of that).
Thanks for your info,
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100529115036.ga20...@upsilon.cc
Re: Parallellizing the boot in Debian Squeeze - ready for wider testing
On Sat, May 08, 2010 at 07:07:44PM +0200, Petter Reinholdtsen wrote:
Perhaps you are right. Perhaps we should do a poll to collect
information on how testers experience their boot with
CONCURRENCY=makefile, to make it easier to switch with some confidence
that it would work for most users. :)
Now you're talking! :)
Well, it has not really been discussed with the release team, and the
decision depend a lot of when Squeeze freezes, so it is hard to know
what to decide. :)
Perhaps we should switch the default in unstable to
CONCURRENCY=makefile for a while, and if it causes a lot of problems
we can switch it back to sequential boot. At the moment I believe we
need to increase the amount of testing a lot to get the remaining bugs
located and fixed, and that is hard to do without actually doing the
switch.
If you are ready to monitor the issue closely, I don't see any problem
in switching the default now in unstable, see how it goes, and then
decide later on if revert back to the current default in Squeeze
time. Ideally, you should probably communicate a on the matter when/if
it arrives in testing to raise the awareness for testing users (and
probably we should work on the doc, as reported by Vincent). AFAICT the
change of the default change is relatively self-contained and will only
help in showing other problems which has been difficult to spot thus
far. [ I'm Cc-ing the release team, in case they see extra problems that
I don't in doing that change in the interim. ]
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Bug#577073: RM: blootbot/1.2.0-6.3 ; RC-buggy, low popcon, no upload in long time
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm User: release.debian@packages.debian.org Usertags: rm As investigated by Robert Lemmen (Cc:-ed) in #502753, blootbot is a good candidate for removal from testing. Here is a summary of the reasons: rc-buggy: #502753 other bugs low popcon (10 ATM, with recent 0) no upload in long time (last upload in 2008) low bug reaction (#502753 has been reported Oct 2008) In fact, given the popcon, it seems to me that blootbot would also be a good candidate for removal from the archive tout court, but I leave that to the judgement of the maintainer (Cc:-ed). If needed, I'll be happy to take care of requesting removal from the archive too. Hope this helps, Cheers. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-3-amd64 (SMP w/2 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100409111856.23603.30566.report...@usha.takhisis.invalid
Bug#575260: RM: bash-completion-lib/1.3.1-2 -- RoQA; not in stable, RC buggy, not currently in development
On Fri, Mar 26, 2010 at 10:30:56AM +, Arnaud Cornet wrote:
If you're willing to do it, it's greatly appreciated. Otherwise I'll
do it when I get a bit more time.
I've just filed the RM request, you are Cc-ed in the request.
Thanks for your feedback,
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100326111349.ga6...@usha.takhisis.invalid
Bug#575260: RM: bash-completion-lib/1.3.1-2 -- RoQA; not in stable, RC buggy, not currently in development
On Thu, Mar 25, 2010 at 02:48:26PM +, Arnaud Cornet wrote:
In fact, I think it should be even removed from the archive completely, but
I'd
like the maintainer (Cc-ed as well) to voice his opinion on that more drastic
measure.
Agreed.
Heya, thanks for your feedback.
Are you going to submit the RM request by yourself or should I?
TIA,
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100325150015.ga1...@usha.takhisis.invalid
Bug#575260: RM: bash-completion-lib/1.3.1-2 -- RoQA; not in stable, RC buggy, not currently in development
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: rm
Severity: normal
Dear release team,
I've been investigating the status of bash-completion-lib, which is currently
RC buggy and, more generally, not suitable for a release (e.g. total
lack of any documentation).
Additionally, and thanks to David Paleino (Cc-ed), I've checked with upstream
that bash-completion-lib, while not yet abandoned, is currently not being
developed and his upstream is contributing all his work on the more mainstream
bash-completion package. Upstream plans to drop bash-completion-lib anyhow in
the future once the load by need feature will be part of
bash-completion. Considering that bash-completion-lib has never been part of a
stable release, that the maintainer has not replied to its RC bugs, and
comparing the popcon of bash-completion{,-lib}, I hereby request it to be
removed from testing.
In fact, I think it should be even removed from the archive completely, but I'd
like the maintainer (Cc-ed as well) to voice his opinion on that more drastic
measure.
Cheers.
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100324153456.ga10...@fettunta.org
Bug#575260: RM: bash-completion-lib/1.3.1-2 -- RoQA; not in stable, RC buggy, not currently in development
- Original message -
comparing the popcon of bash-completion{,-lib}, I hereby request it to be
removed from testing.
Removal hint added.
Thanks!
Cheers.
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1269456964.1401.2.ca...@nokia-n900-42-11
Re: Bits from the Release Team: What should go into squeeze?
On Sun, Mar 14, 2010 at 09:42:58PM +0100, Philipp Kern wrote:
It would be great if every team on track could send us a short mail to
debian-release@lists.debian.org and if every team that still faces work
could write up a corresponding bug report filed against release.debian.org,
preferably with proper blocked by[1] annotations if bugs are filed for the
issues at hand.
Dear -release-rs, thanks for this poll, it is much appreciated to seek
status report from teams which have worked to have their work in
Squeeze!
Regarding the OCaml team, we just went through the OCaml 3.11.2
transition, which has contributed to double-check our new dependency
scheme where linking failures get translated to non co-installable
packages. We do not foresee further OCaml transition before the Debian
Squeeze freeze (assuming, as we hope, it will happen soon-ish :-)).
We still have some small package sub-systems which we would like to get
in Squeeze (most notably some packages related to the Ocsigen web
framework). Assuming the freeze announcement will be posted somewhat in
advance (e.g. 2 weeks), we believe we won't have problems in reaching
the freeze deadline without needing significant unblock requests
afterward.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Bug#569163: Bug#555325: gq: version 1.3.4 completely unusable
[ reporting relevant info to the appropriate release.d.o bug report,
sorry for the not-so-handy cloning ]
After a few crashes the first minutes I threw away all ~/.gq* files and
directories. I tried to add a new server. Impossible to enter the bind
dn. It simply forgets it. On the first search it crashes. I have seen
about 10 crashes in the very few first 10 minutes. This is completely
unusable. This version should never have been transferred to testing
IMHO. In this state it is better to remove gq completely.
Agreed. This package is in quite a bad shape, mostly because latest
upstream release (albeit recent) is fubar. The last package maintainer
gave up for this reason, and because he was not willing to fix all
outstanding issues on the Debian side. As long as either a maintainer
step in (which is willing to do that) or upstream releases a decent
version, the package is quite useless.
The most reasonable course of action from the Debian POV is to remove
the package from testing.
Can you please do so?
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: On cadence and collaboration
On Thu, Aug 06, 2009 at 02:08:26AM +0200, Cyril Brulebois wrote:
Or is some incremental freeze still supposed to happen?
During the talk/discussion at DebConf, IIRC Luk stated that
incremental freezes had a negative effect because for many developers
it was not clear what/when was going to be frozen. The logical
consequence drawn there (again, IIRC) has been that the release team
would prefer releasing all at once.
Note, however, that we have always used to have unblocks during
freezes; the policy on how unblocks are handled is completely
orthogonal to how sharply you freeze.
(Putting -release in Cc to catch their attention.)
Keeping that to ensure I'm not on crack with my memories :-)
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: Webkit build issues
On Tue, Apr 28, 2009 at 09:45:41PM +0200, Adeodato Simó wrote:
Anyway, the exact list of Bin-NMUs is rather uninteresting. More
interesting can be, I think, the current list of known transitions
against which the Release Team works, which you were pointed at on
IRC later:
https://buildd.debian.org/transitions/summary.html
Is that page linked from anywhere? I've looked into the most obvious
(to me) places (e.g., {buildd,release}.d.o), but I failed to find it.
As a bonus, Google found this for me:
http://wiki.debian.org/OngoingTransitions which looks a bit
outdated.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: Bug#524120: transitions.yaml handling: the PTS needs to grok finished transitions
On Wed, Apr 15, 2009 at 10:25:40AM +0200, Adeodato Simó wrote:
I see the PTS as the consumer of the YAML file. There can be,
theoretically, other consumers and basically you are implicitly
proposing that all consumers implement the cleanup upon
migration logics.
FWIW, Adam Barrat (thanks!) just prodded me on IRC about this,
remembering me that devscripts contains another consumer of that
YAML file (/usr/bin/transition-check), which is affected by the very
same problem. In a sense, that strengthen my feeling that the solution
should be FTP master side, let's gather some more comments ...
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
OCaml 3.11 is in testing!
On Mon, Apr 06, 2009 at 12:33:29PM +0200, Adeodato Simó wrote:
I guess migrating ocaml to testing can now be considered...
This is now done:
ocaml | 3.11.0-5 | testing
ocaml | 3.11.0-5 | unstable
Congratulations for making of this transition one of the less painful
I’ve ever had to deal with
YAY \o/
Thanks to you -release-rs, I suggest adding the above lines to the CV
of all Debian OCaml-ers which contributed to this transition ;-)
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
transition to OCaml 3.11
[ please keep the Cc to d-o-m, for the sake of other OCaml maintainers ]
Hi release-rs,
many thanks and congratulations for the Lenny release!
As a lot of teams I guess :), we---Debian OCaml Maintainers---are
eager to push our (r)evolutions to unstable, starting in the few
days. The first of such evolution is the long overdue transition of
OCaml 3.11, which are users are waiting for for a while now.
We plan to go ahead and uploading ocaml 3.11 itself (the package)
during next week, then slowly uploading all the other packages. This
time, given the unstable freeze, quite a lot of packages will need
sourceful uploads, and we plan to take care of the appropriate delay
to avoid unnecessary build failures. Then, as usual, we will request
the usual round of binNMUs and dep-wait as with the old ocaml
transitions.
Please let us know if you have any problem with such plan.
JFYI, we also plan to implement proper dependencies which enforce the
lack of ABI incompatibility, as discussed back in
DebConf7. Nevertheless, we want to separate concerns and we will not
entangle this with the current 3.11 transition (also because not all
needed tools are ready yet).
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: RFC: how to push the fix for #503616
On Thu, Oct 30, 2008 at 12:18:14AM +0100, Luk Claes wrote: If not please let me know if I'd go for t-p-u with ocamlnet 2.2.9-4. Please upload it with a lower version to tpu, TIA. Done: ocamlnet/2.2.9-3+lenny1, uploaded to t-p-u, urgency: low. Override as needed. Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7 [EMAIL PROTECTED],pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/ Dietro un grande uomo c'è sempre /oo\ All one has to do is hit the right uno zaino-- A.Bergonzoni \__/ keys at the right time -- J.S.Bach signature.asc Description: Digital signature
RFC: how to push the fix for #503616
On Wed, Oct 29, 2008 at 10:57:54PM +0100, Stéphane Glondu wrote: Luk Claes wrote: t-p-u is a workaround so should only be used if unstable is no option. So if posssible, please use use unstable. Actually, there might be a problem because of libpcre3... Erm, I was in fact fearing some entanglement, that's why I asked for t-p-u (even though I didn't check to discover libpcre3 in advance). ocamlnet 2.2.9-4 is now in unstable, with urgency high, built on all arch waiting for an unblock *and* for pcre3 to transition. Is pcre3 going to be transitioned? If yes please unblock ocamlnet 2.2.9-4 as well. If not please let me know if I'd go for t-p-u with ocamlnet 2.2.9-4. TIA, Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7 [EMAIL PROTECTED],pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/ Dietro un grande uomo c'è sempre /oo\ All one has to do is hit the right uno zaino-- A.Bergonzoni \__/ keys at the right time -- J.S.Bach signature.asc Description: Digital signature
RFC: how to push the fix for #503616 (and on the fix itself)
tags 503616 + patch thanks Dear -release-rs, how should I push the fix for #503616? Via t-p-u or unstable + unblock request? Long story: only recently it has been brought to my attention #503616 which affects an Apache module currently in testing. I do have a fix already, but it involves using an -rpath. Still, I do believe it is possible one of the few proper usages of -rpath, my reasoning is in the bug log, and is agreed upon by other Debian OCaml members. Also, this solution permits to fix only ocamlnet in Lenny, while the other (rpath-free) solution I envisaged would require fixing both ocamlnet and ocaml in the Lenny timeframe. (... and we do not think it is the right solution.) Now, my question is how should I push the fix: via t-p-u or via unstable + unblock request? The diff to the latest ocamlnet version in Lenny is attached for review. Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7 [EMAIL PROTECTED],pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/ Dietro un grande uomo c'è sempre /oo\ All one has to do is hit the right uno zaino-- A.Bergonzoni \__/ keys at the right time -- J.S.Bach diff --git a/debian/changelog b/debian/changelog index 0cbcf4d..d969761 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,14 @@ +ocamlnet (2.2.9-3+lenny1) testing-proposed-updates; urgency=low + + * add rpath pointing at `ocamlc -where` to the Apache module shipped by +libapache2-mod-ocamlnet, so that libcamlrun_shared.so can be found +(Closes: #503616) + * fix wrong path in /etc/apache2/mods-available/netcgi_apache.load, which +inhibited proper loading of netcgi .cma library +(also needed to fix #503616) + + -- Stefano Zacchiroli [EMAIL PROTECTED] Wed, 29 Oct 2008 00:09:07 +0100 + ocamlnet (2.2.9-3) unstable; urgency=medium [ Stephane Glondu ] diff --git a/debian/etc/netcgi_apache.load b/debian/etc/netcgi_apache.load index a4b51fb..a105813 100644 --- a/debian/etc/netcgi_apache.load +++ b/debian/etc/netcgi_apache.load @@ -4,4 +4,4 @@ NetcgiLoad netsys/netsys.cma NetcgiLoad netstring/netstring.cma NetcgiLoad str.cma NetcgiLoad netcgi2/netcgi.cma -NetcgiLoad netcgi2-apache/netcgi_apache.cma +NetcgiLoad netcgi_apache/netcgi_apache.cma diff --git a/debian/patches/00list b/debian/patches/00list index b899fa0..09ac5b0 100644 --- a/debian/patches/00list +++ b/debian/patches/00list @@ -1,5 +1,6 @@ camlp5_5_alias_pat.dpatch camlrun_shared.dpatch +rpath-apache.dpatch dont_install_gpl.dpatch mkdir_destdir.dpatch missing_shebangs.dpatch diff --git a/debian/patches/rpath-apache.dpatch b/debian/patches/rpath-apache.dpatch new file mode 100755 index 000..ebe6a0a --- /dev/null +++ b/debian/patches/rpath-apache.dpatch @@ -0,0 +1,20 @@ +#! /bin/sh /usr/share/dpatch/dpatch-run +## rpath-apache.dpatch by Stefano Zacchiroli [EMAIL PROTECTED] +## +## All lines beginning with `## DP:' are a description of the patch. +## DP: add rpath to Apache module, pointing to `ocamlc -where` +## DP: rationale: ensure libcamlrun_shared.so can be found + [EMAIL PROTECTED]@ +diff -urNad ocamlnet~/src/netcgi2-apache/Makefile.def ocamlnet/src/netcgi2-apache/Makefile.def +--- ocamlnet~/src/netcgi2-apache/Makefile.def 2008-10-29 00:19:10.175784001 +0100 ocamlnet/src/netcgi2-apache/Makefile.def 2008-10-29 00:19:56.095780612 +0100 +@@ -46,7 +46,7 @@ + ### Embed Caml code into the C code. + ### Requires `caml_startup' instead of `caml_main' in handler.c + mod_netcgi_apache.so: $(MOD_OBJECTS) +- $(APXS) -c -o $@ $^ -L$(APACHE_OCAMLLIBDIR) $(patsubst -lcamlrun,-lcamlrun_shared,$(APACHE_OCAMLLIBS)) ++ $(APXS) -c -o $@ $^ -L$(APACHE_OCAMLLIBDIR) -Wl,--rpath,$(APACHE_OCAMLLIBDIR) $(patsubst -lcamlrun,-lcamlrun_shared,$(APACHE_OCAMLLIBS)) + test -f .libs/$@ cp .libs/$@ . + + netcgi_apache_mod.lo: netcgi_apache_mod.o
Re: please unblock loudmouth 1.4.2-2
On Sun, Oct 26, 2008 at 12:18:22AM +0200, Stefano Zacchiroli wrote: Can you please unblock loudmouth 1.4.2-2, so that build-deps of gossip get satisfied in lenny, and then reschedule building in testing of gossip/1:0.31-1? Checking twice, only the unblock of loudmouth/1.4.2-2 is needed, as gossip/1:0.31-1 has already been rebuilt against the same version of loudmouth I'm requesting to unblock. Hence, I restrict my request to just: please unblock loudmouth/1.4.2-2. Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7 [EMAIL PROTECTED],pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/ Dietro un grande uomo c'è sempre /oo\ All one has to do is hit the right uno zaino-- A.Bergonzoni \__/ keys at the right time -- J.S.Bach -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
please unblock loudmouth 1.4.2-2 / reschedule gossip 1:0.31-1
Hi, loudmouth 1.4.2-2 is needed in testing to let gossip (which is in testing already) have all its needed build-deps. See #501423. There was an additional bug blocking loudmouth, #494940, which has been fixed by Löic 5 days ago. Since then loudmouth has been rebuilt everywhere and is apparently read to transition. Can you please unblock loudmouth 1.4.2-2, so that build-deps of gossip get satisfied in lenny, and then reschedule building in testing of gossip/1:0.31-1? FWIW, I do have tried building gossip in lenny against loudmouth 1.4.2-2 and it worked fine. TIA, Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7 [EMAIL PROTECTED],pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/ Dietro un grande uomo c'è sempre /oo\ All one has to do is hit the right uno zaino-- A.Bergonzoni \__/ keys at the right time -- J.S.Bach -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
what about nautilus 2.22 [ Was: Perl 5.10 transition: Done ]
On Sun, May 18, 2008 at 12:44:28AM +0200, Marc 'HE' Brockschmidt wrote: The Perl5.10 transition has now been completed, with about 400 source packages in testing getting updates (either by new source versions or binNMUs). I have removed the upload block for the involved packages and would like to thank all involved maintainers, bug reporters and the Perl maintainer team for their help. In the course of the perl5.10 transition, new versions of heimdal, clamav and sendmail/libmilter have moved to testing. The release team has planned several other, considerably less complex updates for xulrunner, ocaml, ffmpeg, poppler and nautilus over the next weeks. Given that the freeze is now on the doorstep, can I conclude that we are going to release with GNOME 2.22, with the exception of nautilus which will be version 2.20? There seems to be quite active work in the packaging, but all is still in experimental ... Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7 [EMAIL PROTECTED],pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/ I'm still an SGML person,this newfangled /\ All one has to do is hit the XML stuff is so ... simplistic -- Manoj \/ right keys at the right time signature.asc Description: Digital signature
Re: BinNMU for ocsigen
On Sun, Jun 15, 2008 at 02:04:05PM -0700, Steve Langasek wrote: Stefano Zacchiroli was working on the design for an shlibs-style mechanism for ocaml. Has this not made it to the implementation stages yet? No it has not, the last ocaml step we did for lenny was the recent 3.10.2 transition and we won't be going to push for the mechanism you mention now for lenny, since it is too near to the release. It is an objective for lenny+1 though. -- Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7 [EMAIL PROTECTED],pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/ I'm still an SGML person,this newfangled /\ All one has to do is hit the XML stuff is so ... simplistic -- Manoj \/ right keys at the right time signature.asc Description: Digital signature
please add a link to transitions.yaml from http://release.d.o
... I think such a link would fit perfectly under Useful Links. TIA, Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],cs.unibo.it,debian.org} -%- http://upsilon.cc/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Freeze exception for dpkg 1.14.18
On Sat, Apr 26, 2008 at 07:42:46PM +0200, Marc Haber wrote: On Sat, Apr 26, 2008 at 04:18:29PM +0200, Raphael Hertzog wrote: I would have liked to upload all this sooner, but Guillem absolutely wanted to merge the triggers in dpkg 1.14.17 and with the hijack story, it delayed the whole for several weeks. Please explain how Ian's upload (which was promptly unaccepted) delayed Guillem's work. No, please don't. We don't want the whole issue to be re-raised again in a new sub-thread. Let's move on. FWIW, in my view Raphael's claim is not such a strong claim that needs the motivation you are asking for. I think we can all imagine how a fight like those between Guillem and Ian can delay work on one side: you have emotionally to deal with the fight, and you have technically to work with the FTP guys to deal with the issue (for example to explain the motivation so that they lift the upload restriction). All these things take time away. Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],cs.unibo.it,debian.org} -%- http://upsilon.cc/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
authorization request for an ocaml 3.10.2 transition
Hi release-rs, the current OCaml version in testing is 3.10.1, the latest upstream release is 3.10.2 and comes with a handful, though important bug fixes (most about violate type safety). For this reason, the Debian OCaml Maintainers team would be really happy to release Lenny with 3.10.2. The transition would first require a few uploads of new usptream versions (for example of camlp5) to ensure compatibility with OCaml 3.10.2. Then we will need the usual round of binNMUs of all libraries (about 90 source packages). Of course we won't go ahead without release manager permissions at this point in time of the Lenny release. We hereby ask your permission to go ahead and any other comments/suggestions you might have on the subject. TIA, Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],cs.unibo.it,debian.org} -%- http://upsilon.cc/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Re: Bug#455135: NMU uploaded
On Sun, Mar 16, 2008 at 11:55:17PM +0100, Andreas Barth wrote: I uploaded an NMU of your package. Please see this as help to get the package into a releaseable condition again. No, argh, no! gdome2-xslt was involved in the OCaml 3.10.1 transition which is currently involving 99 source packages and is waiting for 40 days now to get in, due to buildd slowness. Your upload now resets the counter, luckily by just 5 days. But you can't upload like that, at least use a delayed queue by 1 or 2 days. I have nothing against NMU of my packages in general and actually you can even directly commit in the Subversion repository of most of my packages, since they are in repositories writable by all DDs. But uploading a package involved in such a transition is just reckless. You could have at least pinged me, in mail or even on IRC as yesterday I was well online. Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],cs.unibo.it,debian.org} -%- http://upsilon.cc/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Re: Bug#455135: NMU uploaded
[ the problem is already solved, as aba kindly offered to take care of the needed urgency bumps, replying just to make it clearer my position ] On Mon, Mar 17, 2008 at 10:26:22AM +0100, Petter Reinholdtsen wrote: [Stefano Zacchiroli] But you can't upload like that, at least use a delayed queue by 1 or 2 days. Sure he can. It is stated policy for release goals. Did you read the particular problem I've pointed out in my mail or are you just replying in the usual mood of people complain about NMU? Yes, anybody can and should upload a package for fixing a RC bug with 0-day NMU policy. And I have nothing against that. Nevertheless, in this particular case, the NMU-ed package was involved in a big transition (circa 100 source packages) which is waiting to enter testing since more than a month now. So, sure, feel free to do the 0-day NMU, but anybody doing that should be aware of the potential consequences: delays in testing transitions and possible tying together of unrelated transitions due to extra dependencies which can be brought in by buildd rebuilds. But I repeat: this problem is already solved for gdome2-xslt thanks to aba, if it is just for that please let this thread die. If it is for a more general point about 0-day NMUs, I personally think that we all make mistakes, and we all can do that when doing NMUs. So, what do you loose in uploading to delayed-2 when doing an NMUs? I think nothing, just 2 tiny teeny days which can give the benefit of avoiding big masses, for example in case of overlooked large transitions. And I'm not even saying to change the default policy of 0-day NMUs, I'm find with that, I only think it is wiser to use delayed-2 and I personally do that. Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],cs.unibo.it,debian.org} -%- http://upsilon.cc/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Re: Bug#455135: NMU uploaded
On Mon, Mar 17, 2008 at 09:54:43AM +0100, Andreas Barth wrote: * Stefano Zacchiroli ([EMAIL PROTECTED]) [080317 09:31]: But you can't upload like that, at least use a delayed queue by 1 or 2 days. I'll make sure it resets it only by 1 or 2 days, thanks for the notice. Thanks a lot. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],cs.unibo.it,debian.org} -%- http://upsilon.cc/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: binNMU requests for the OCaml 3.10.1 transition
On Fri, Feb 15, 2008 at 03:42:19PM +0100, Stefano Zacchiroli wrote: Can someone please schedule them? Any news? -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],cs.unibo.it,debian.org} -%- http://upsilon.cc/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
binNMU requests for the OCaml 3.10.1 transition
m68k mips mipsel powerpc s390 sparc pxp dep-wait libocamlnet-ssl-ocaml-dev (= 2.2.9-1+b1) pxp dep-wait libcryptgps-ocaml-dev (= 0.2.1-4+b1) why_2.10.dfsg.2-1, Rebuild with ocaml 3.10.1, 1, alpha amd64 arm armel hppa i386 ia64 m68k mips mipsel powerpc s390 sparc why dep-wait coqide (= 8.1.pl3+dfsg-1+b1) why dep-wait liblablgtksourceview-ocaml-dev (= 2.10.0-4+b1) why dep-wait liblablgl-ocaml-dev (= 1.03-1+b1) xmlrpc-light_0.6-3, Rebuild with ocaml 3.10.1, 1, alpha amd64 arm i386 ia64 powerpc s390 sparc xmlrpc-light dep-wait libocamlnet-ssl-ocaml-dev (= 2.2.9-1+b1) xmlrpc-light dep-wait libcryptgps-ocaml-dev (= 0.2.1-4+b1) matita_0.4.98-5, Rebuild with ocaml 3.10.1, 1, alpha amd64 arm armel hppa i386 ia64 m68k mips mipsel powerpc s390 sparc matita dep-wait libhttp-ocaml-dev (= 0.1.4-2+b1) matita dep-wait libocamlnet-ssl-ocaml-dev (= 2.2.9-1+b1) matita dep-wait libcryptgps-ocaml-dev (= 0.2.1-4+b1) -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],cs.unibo.it,debian.org} -%- http://upsilon.cc/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Re: binNMU request for camlp5
On Sun, Dec 09, 2007 at 12:12:01AM -0800, Steve Langasek wrote: Scheduled now. Is anything being done about the fact that the runtime dependencies on otags are wrong (satisfied by versions of camlp5 that you say it's incompatible with)? Yes, it is being done (remember the ocaml dependency hell we were discussing at last DebConf?), but unfortunately it is proceeding slower than expected ... Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Re: binNMU request for camlp5
On Fri, Nov 30, 2007 at 10:24:47PM +0100, Stefano Zacchiroli wrote: ocaml-ulex08_0.8-4, rebuild against latest camlp5, 1, alpha amd64 arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc otags_3.09.3-2, rebuild against latest camlp5, 1, alpha amd64 arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc As per Dato suggestion: please add a dep-wait on the architectures on which camlp5 hasn't yet been built, namely: arm hppa m68k mipsel sparc. On Tue, Dec 04, 2007 at 05:15:08PM +0100, Enrico Tassi wrote: ocaml-ulex08_0.8-4, rebuild against latest camlp5, 1, alpha amd64 arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc I did a new upload by hand since it was blocking me... Ok, but the binNMU for otags is still needed, can someone please schedule it? In the meantime camlp5 have been rebuilt everywhere except m68k. Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
binNMU request for camlp5
package]_[source-version], [reason], [binNMU number], [list of archs] The reverse build-deps of camlp5 need binNMU to be able to link properly with the latest camlp5 (version 5.04). Unfortunately that version haven't yet been rebuilt on all arch, is it appropriate to ask the binNMUs in advance? (i.e. do you have any way to schedule them in advance or something such?) ocaml-ulex08_0.8-4, rebuild against latest camlp5, 1, alpha amd64 arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc otags_3.09.3-2, rebuild against latest camlp5, 1, alpha amd64 arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc As per Dato suggestion: please add a dep-wait on the architectures on which camlp5 hasn't yet been built, namely: arm hppa m68k mipsel sparc. TIA, Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Re: binNMU request for gtkmathview on amd64 [Was: Re: Bug#441198: Crash on amd64]
On Mon, Oct 15, 2007 at 02:48:16AM -0700, Steve Langasek wrote: ... also, after manually installing libxpm-dev for the build and installing the resulting packages, I still get a segfault on amd64. So binNMUs don't seem to be the answer here. Thanks for this investigation, I've just reported #446864 for the t1lib issue. Since upstream has just released 0.8.0 I'll wait for the above bug to be solved and then give again a try to the latest upstream. Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
binNMU request for gtkmathview on amd64 [Was: Re: Bug#441198: Crash on amd64]
Hi -releasers, can you please schedule a binNMU for the source package gtkmathview on amd64? Unfortunately I'm not entirely sure that it is the proper solution, since I did not (also after talking with upstream et al) about what was the cause of the crash, but we are quite convinced it was some toolchain breakage. Nevertheless, ATM rebuilding the package on amd64 fixes the problem, that's why I'm asking for the binNMU. Hints on what to do on other archs (i.e. binNMU also there?) are appreciated. On i386 the package works just fine, but I don't know what to expect elsewhere ... TIA, Cheers. On Fri, Sep 07, 2007 at 02:25:10PM +0100, Enrico Tassi wrote: Package: libgtkmathview-bin Version: 0.7.8-2 Severity: normal --- Please enter the report below this line. --- It crashes in a deterministic way, gdb bt and valgrind log follow. I also attach the document I used to generate the crash. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Re: [binNMU] facile
On Wed, Sep 12, 2007 at 11:21:36PM +, Sylvain Le Gall wrote:
I'm not sure what problem you're trying to solve here. The problem at hand
is what other packages need to be rebuilt first because they also depend on
the same {library/runtime} package as the present package. That should be
solvable without adding any new fields at all.
Sven is talking of one of the issue that i only have half explained...
OCaml dependency between packages is an open problem. I am not sure that
anyone has a good solution (tm) for now.
Yep, and this has nothing to do with what me and Steve were initially
discussing.
Besides, Steve is well aware of the OCaml dependency issue due to
discussions on that with me and Julien at the past DebConf. And yes, we
have what we believe is the LSS (Least Sucking Solution) for that but we
haven't yet had time to discuss it nor to port our current tools to
that.
But please drop this, it's getting more and more off-topic :)
--
Stefano Zacchiroli -*- PhD in Computer Science ... now what?
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
(15:56:48) Zack: e la demo dema ?/\All one has to do is hit the
(15:57:15) Bac: no, la demo scema\/right keys at the right time
signature.asc
Description: Digital signature
Re: [binNMU] facile
On Tue, Sep 11, 2007 at 02:02:29PM -0700, Steve Langasek wrote: Anyway, this is certainly no worse than what happened with the maintainer upload of ulex, which was uploaded before findlib was available on all archs and had to be given back after a FTBFS. Well, sorry, but I consider this as a shortcoming in our buildd infrastructure and I'm not always willing to dilute my workflow because of that. When I upload something like ulex I provide all the information to discover that the build won't be possible. Why can't this be automatically detected and need manual work? I understand that this way I've cause additional work to someone else and I'm sorry for that, but having to dilute work on a set of related packages is sub-optimal for me. Maybe I can upload to delayed or something next time, but I'm convinced something about that can be fixed on the buildd side (but no, I'm not volunteering, I'm just replying to your complain). Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Re: [binNMU] facile
On Wed, Sep 12, 2007 at 02:31:32AM -0700, Steve Langasek wrote: Dude, I wasn't complaining, I was pointing out that the binNMUs I scheduled are no different than the maintainer uploads. Yep, got it, I wasn't bothered at all by your mail (sorry if it seemed so), I was just wondering if anything can be improved on the handling of that give backs (on which I'm sure you know more than me). Knowing that with non timely upload I can induce some troubles to others is not exactly something I like :) But maybe this is not the right thread to discuss this stuff ... Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Re: [binNMU] facile
On Mon, Sep 10, 2007 at 04:16:06AM -0700, Steve Langasek wrote: On Mon, Sep 10, 2007 at 10:32:36AM +0200, Lucas Nussbaum wrote: ocaml-sqlite needs a binNMU. libsqlite-ocaml-dev: Depends: libsqlite-ocaml (= 0.3.5.arch.4-9) but it is not going to be installed Depends: ocaml-nox-3.09.2 but it is not installable This causes ocamldbi to FTBFS. Scheduled, along with binNMUs of 50 other packages... You mean, I guess, that all that other 50 packages are ocaml-related and can't be installed for the same reason above, right? If you have the list at hand can you please let me (or [EMAIL PROTECTED]) nows which packages you have scheduled? Many thanks in advance, Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Re: transition to ocaml 3.10
On Mon, Aug 20, 2007 at 08:27:55AM +0200, Stefano Zacchiroli wrote: I'm hereby asking for your permission to go forward with this transition. No answers so far. In a few days we will go ahead and start uploading to unstable (assuming in good faith it's not a big deal for the release team), please speak ASAP if you have reasons to prevent this to happen. Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
transition to ocaml 3.10
Hi releasers, we, members of the OCaml team, feel ready to start transitioning packages from OCaml 3.09.2 to OCaml 3.10 in unstable. A list of the involved packages is available at [1]. I'm hereby asking for your permission to go forward with this transition. Many thanks in advance. Cheers. [1] http://pkg-ocaml-maint.alioth.debian.org/debian-ocaml-status.html -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Re: transition to ocaml 3.10
On Mon, Aug 20, 2007 at 10:23:29PM +0900, Junichi Uekawa wrote: I use 'advi' and care about it, and I noticed that it's not in the list[1]. Is the list comprehensive? It is up to bug / strangeness in the interested packages :-) In particular I just noticed that advi does not declare a direct build-dep on ocaml, but relies on the transitivity of ocaml-best-compilers. Hence it is missing from the list. I'll fix the package (or the script generating the page). Anyhow, advi is one of the packages which are not particularly problematic for the transition, since they do not depend at runtime on any ocaml package, they just need to be rebuilt and only to ensure they won't FTBFS (which is a rare happening). Thanks for your observation, Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: proposed release goal: DEBIAN/md5sums for all packages
[ fully quoting my original request, for the sake of context preservation ] On Fri, Aug 17, 2007 at 09:04:13AM +0200, Luk Claes wrote: Stefano Zacchiroli wrote: [ Assuming is not too late to propose release goals of course ] Hi, a long time ago we were wondering to have DEBIAN/md5sums generated for all packages in the archive ... and we are still wondering! Can we make it a release goal for lenny? Cheers PS thanks to Romain Francoise which reminded me of this with his blog entry (http://blog.orebokech.com/2007/08/debian-packages-without-md5sums.html) With more than 600 issues, it's a bit early to make it a release goal IMHO. Though making maintainers aware by upgrading the lintian check to a warning and discussion on debian-devel about which exceptions are warranted (and possible mass bug filing) will probably be a good idea to get the amount reduced rather fast... Ok, moving the discussion to -devel then. Please reply there, people. In an attempt to prevent drift to a well-known counter argument: DEBIAN/md5sums (used by debsums) are *not* intended as a mean to counter security attacks, since they can be easily altered. Rather, they are useful as a general mechanism to check if something got corrupted due to hardware/software failures and can be used to spot which packages need to be reinstalled. Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Re: Gnome plans for the lenny cycle
On Thu, Apr 19, 2007 at 10:10:33PM +0200, Loïc Minier wrote: Perhaps we need more intermediate milestones, which is something which seems to be lacking in some areas (no goals for each milestone, no I fully agree on this. As a member of few teams in which no strong leadership is de facto established (and this is generally good), I think all those teams will benefit of knowing that they have to test-drive their next release skills with some intermediate milestone; something like: ``X months before the release you have to be ready on .. something ..''. Given that the X and the something need to be internally defined by the team I have no idea on how the RMs can enforce that, though. Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Re: binNMUs request for ocamlnet
On Sun, Apr 15, 2007 at 01:02:58PM +0200, Steve Langasek wrote: cduce_0.4.1-1, rebuild against newer ocamlnet, 1, alpha amd64 hppa i386 ia64 m68k mips mipsel powerpc s390 sparc Scheduled. FWIW, the package names wanted here are the source package names, not the binary package names. Right, sorry, I was aware of that but nevertheless I overlooked it when writing the request. Many thanks, Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
binNMUs request for ocamlnet
With the upload of ocamlnet 2.2.7 to unstable all ocaml libraries depending on it are now broken, I kindly ask the following binNMUs to fix that: cduce_0.4.1-1, rebuild against newer ocamlnet, 1, alpha amd64 hppa i386 ia64 m68k mips mipsel powerpc s390 sparc libhttp-ocaml-dev_0.1.3-2, rebuild against newer ocamlnet, 1, alpha amd64 hppa i386 ia64 m68k mips mipsel powerpc s390 sparc libldap-ocaml-dev_2.1.8-2, rebuild against newer ocamlnet, 1, alpha amd64 hppa i386 ia64 m68k mips mipsel powerpc s390 sparc libpxp-ocaml-dev_1.1.96-8, rebuild against newer ocamlnet, 1, alpha amd64 hppa i386 ia64 m68k mips mipsel powerpc s390 sparc I haven't checked if the packages have previously been binNMUed, so 1 as the NMU number in the list above is a guess of mine (I do have checked source version and archs though). Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Re: Please allow xbmbrowser 5.1-10 to enter unstable
On Tue, Apr 10, 2007 at 05:49:03PM +0200, Michelle Konzack wrote: Since it was orphaned last year I have pushed it back into Debian and like to see Etch be released with it. Quite hard to achieve without a time-machine: http://www.debian.org/News/2007/20070408 :-) -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Re: (Bad) results of running piuparts over the whole archive
On Wed, Jan 17, 2007 at 10:03:35PM +0100, Lucas Nussbaum wrote: All logs are available on http://people.debian.org/~lucas/logs/2007/01/16/ I love these automated QA tests, thanks for that! What do we do with that ? In another piuparts campaign at the end of last year, I filed quite a lot of bugs, but voluntarily ignored I have no particular opinion about whether to fill bugs or not, but still I wouldn't be bothered if bug reports starts flowing for that to packages of mine: if they are issues they need to be fixed or at least known. In the meantime, could you please produce a list of packages classified by maintainer using dd-list? I guess it would be easier for you than for anyone else digging your logs. Many thanks! Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Re: libexiv2-0.10 issues
On Fri, Dec 15, 2006 at 01:22:33PM +, Mark Purcell wrote:
I would suggest that we need to backport the fixes from exiv2-0.12 into
exiv2-0.10, or justify the upgrade to exiv2-0.12 as this effects all rdepends
packages for libexiv2-0.10 in etch.
Just for the records, I'm maintaining gpscorrelate{,-gui} and I'm
following this discussion. I haven't done anything yet since I'm waiting
for a comment of the release managers if anything has to be done from my
side. If it's only a matter of rebuilding against a new exiv2 version a
binNMU is enough and my help AFAICT is not needed.
Let me (and the other exiv2 rdependent packages) know.
--
Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
(15:56:48) Zack: e la demo dema ?/\All one has to do is hit the
(15:57:15) Bac: no, la demo scema\/right keys at the right time
signature.asc
Description: Digital signature
let vim 1:7.0-164+1 enter testing
Vim 1:7.0-164+1 is in unstable since more than 2 weeks, but it is not transiting to testing given that base is frozen. The version of vim in testing now is 1:7.0-122+1. Is it possible to hint vim -164 in testing? - upstream patches from -122 to -164 include several fix for various possible crashes which are solved in -164 (no major changes otherwise) - 10 bugs in the debian BTS have been closed since -122 Many thanks in advance, Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
ocaml 3.09.3 released
On Wed, Aug 30, 2006 at 05:21:23PM -0700, Steve Langasek wrote: It looks like we'll have a new ocaml transition soon. Have discussed this a bit with Sven on IRC already. The two main considerations are: 1) please wait for the python 2.4 transition to complete first, 2) please try to check whether this new upstream version includes any regressions in the set of architectures supported for native compiling. The latter has happened before in the past, and it would be unpleasant to have to deal with such a transition at this point in the release cycle. OCaml 3.09.3 has been released on September 15th. We, debian ocamlers, feel ready for the new transitions. Regarding your points: (1) should be done by now (I see the same version of python in both testing and unstable), (2) should not be a problem for this release of ocaml which is only a bug fix release. Regarding the possible issue of more strict toolchains, a problem we encountered in the past, we uploaded ocaml 3.09.3rc1 to unstable and it has been successfully built on i386, amd64, sparc and kfreebds-i386 by the experimental building network. I hereby ask for permission to go ahead with the 3.09.3 transition, starting to upload the ocaml package to unstable. TIA, Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Re: [Fwd: [Caml-list] 3.09.3 release candidate 1]
On Wed, Aug 30, 2006 at 05:21:23PM -0700, Steve Langasek wrote: 2) please try to check whether this new upstream version includes any regressions in the set of architectures supported for native compiling. The latter has happened before in the past, and it would be unpleasant to have to deal with such a transition at this point in the release cycle. Thanks for the feedback. Just to move in advance: what do you suggest to do in case (2) is actually the case? Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Re: bits from the release team: release goals, python, X.org, amd64, timeline
On Tue, May 30, 2006 at 07:40:40PM -0700, Steve Langasek wrote: No, because no one had proposed it as a pet release goal, and it also I missed this, probably my fault. Is there an official, or at least standardized way, for proposing pet release goals? TIA, Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
transition to ocaml 3.09.2: go!
On Sat, May 13, 2006 at 05:21:22PM -0500, Stefano Zacchiroli wrote: Pinging again on this topic. Can we go ahead with the ocaml 3.09.2 transition? I just talked in person with Vorlon here at the debconf. We can go ahead with the transition to ocaml 3.09.2 in unstable. Samuel, could you please go ahead and start with the upload of ocaml itself? Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Re: Starting a transition to ocaml 3.09.2
On Wed, Apr 26, 2006 at 01:36:40PM +0200, Samuel Mimram wrote: BTW, do you have any ETA of when we'll be able to upload the new caml? Pinging again on this topic. Can we go ahead with the ocaml 3.09.2 transition? Thanks in advance, Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Starting a transition to ocaml 3.09.2
On Mon, Apr 17, 2006 at 10:21:49PM -0700, Steve Langasek wrote: It's not clear to me whether there would be problems. Please hold off on starting this transition until we have a handle on which packages need to be updated to go into etch for the X11R7 transition; I don't *think* any ocaml-using packages are affected, but better safe than sorry. Thanks Steve, tell us if we can do something to help in this respect. Samuel, could you please upload to experimental then? Now it is (BES-ly) built, it would be a good test drive for ocaml 3.09.2 and interested people can start the transition there ... Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Re: gtkmathview 0.6.5, is it possible to accept it in sarge?
On Wed, May 04, 2005 at 11:41:53PM -0700, Steve Langasek wrote: Is it possible to accept gtkmathview 0.6.5 in testing? snip Very much a border case, but approved. Many thanks. Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
gtkmathview 0.6.5, is it possible to accept it in sarge?
[ this is a low priority mail, nothing vital for testing, just an attempt to see non-disruptive changes propoage into sarge ] Hi all, gtkmathview (a GTK widget to render MathML) has versions 0.6.5 in unstable and 0.6.4 in testing. The freeze happened 1 day before it transition in testing :-( As a package it is a good guy: no bugs at all, responsive upstream, and only one package on which he is depending on (lablgtkmathview: ocaml bindings for gtkmathview). Is it possible to accept gtkmathview 0.6.5 in testing? The reason why I'm asking is that starting from this version support for rendering MathML tables has been added. API/ABI haven't changed and as a consequence lablgtkmathview does not need to be rebuilt with the new version. Many thanks in advance. Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
