Bug#544894: libtk-filedialog-perl: Unusable in Lenny

[Ansgar Burchardt]

clone 544894 -1
reassign -1 release.debian.org
retitle  -1 pu: libtk-filedialog-perl/1.3-2+lenny1
severity -1 normal
reopen   -1
tags -1 =
notforwarded -1
user release.debian@packages.debian.org
usertag  -1 + pu
thanks

Hi,

libtk-filedialog-perl is unusable in Lenny [1]: even the example dies in
the constructor.  There is a simple one-line patch from CPAN [2] that
has already been applied in unstable for some while.

I prepared an update for Lenny as well (see attached patch).  Is the
release team okay with uploading this to stable?

Regards,
Ansgar

[1] 
[2] 
diff -u libtk-filedialog-perl-1.3/FileDialog.pm libtk-filedialog-perl-1.3/FileDialog.pm
--- libtk-filedialog-perl-1.3/FileDialog.pm
+++ libtk-filedialog-perl-1.3/FileDialog.pm
@@ -467,7 +467,7 @@
 	$FDialog->{'Can'}->invoke;
 	}
 });
-$FDialog->transient($FDialog->toplevel);
+$FDialog->transient($FDialog->parent->toplevel);
 
 foreach (@TabOrder) {
 	$FDialog->{'TabSel'}->{$_} = 1;
diff -u libtk-filedialog-perl-1.3/debian/changelog libtk-filedialog-perl-1.3/debian/changelog
--- libtk-filedialog-perl-1.3/debian/changelog
+++ libtk-filedialog-perl-1.3/debian/changelog
@@ -1,3 +1,10 @@
+libtk-filedialog-perl (1.3-2+lenny1) UNRELEASED; urgency=low
+
+  * Patch to fix error about making ".filedialog" its own master.
+(Closes: #544894)
+
+ -- Ansgar Burchardt   Thu, 05 Aug 2010 13:07:38 +0900
+
 libtk-filedialog-perl (1.3-2) unstable; urgency=low
 
   * Adds debian/watch so uscan will actually work

Processed: libtk-filedialog-perl: Unusable in Lenny

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> clone 544894 -1
Bug#544894: libtk-filedialog-perl: examples/example.pl fails with message 
...can't make ".filedialog" its own master...
Bug 544894 cloned as bug 591738.

> reassign -1 release.debian.org
Bug #591738 {Done: Tim Retout } [libtk-filedialog-perl] 
libtk-filedialog-perl: examples/example.pl fails with message ...can't make 
".filedialog" its own master...
Bug reassigned from package 'libtk-filedialog-perl' to 'release.debian.org'.
Bug No longer marked as found in versions libtk-filedialog-perl/1.3-2.
Bug No longer marked as fixed in versions libtk-filedialog-perl/1.3-3.
> retitle  -1 pu: libtk-filedialog-perl/1.3-2+lenny1
Bug #591738 {Done: Tim Retout } [release.debian.org] 
libtk-filedialog-perl: examples/example.pl fails with message ...can't make 
".filedialog" its own master...
Changed Bug title to 'pu: libtk-filedialog-perl/1.3-2+lenny1' from 
'libtk-filedialog-perl: examples/example.pl fails with message ...can't make 
".filedialog" its own master...'
> severity -1 normal
Bug #591738 {Done: Tim Retout } [release.debian.org] pu: 
libtk-filedialog-perl/1.3-2+lenny1
Severity set to 'normal' from 'grave'

> reopen   -1
Bug #591738 {Done: Tim Retout } [release.debian.org] pu: 
libtk-filedialog-perl/1.3-2+lenny1
> tags -1 =
Bug #591738 [release.debian.org] pu: libtk-filedialog-perl/1.3-2+lenny1
Ignoring request to alter tags of bug #591738 to the same tags previously set
> notforwarded -1
Bug #591738 [release.debian.org] pu: libtk-filedialog-perl/1.3-2+lenny1
Unset Bug forwarded-to-address
> user release.debian@packages.debian.org
Setting user to release.debian@packages.debian.org (was ans...@43-1.org).
> usertag  -1 + pu
Bug#591738: pu: libtk-filedialog-perl/1.3-2+lenny1
There were no usertags set.
Usertags are now: pu.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
591738: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=591738
544894: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=544894
-1: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=-1
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


-- 
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/handler.s.c.128098240414230.transcr...@bugs.debian.org

Re: Releasability of the kFreeBSD ports

[Aurelien Jarno]

On Wed, Aug 04, 2010 at 07:52:52PM +0200, Axel Beckert wrote:
> Hi,
> 
> * ALSA: Many ALSA dependent packages not working/building/available.
>   (There is a limited emulation layer called SALSA, but either many
>   packages don't work with it or nobody tried to get them working with
>   it. Not sure how many unfixed bugs because of this are still open.)
> 

A lot of the packages have OSS support (with BTW is a lot better on
FreeBSD than it uses to be on Linux). We definitely shoudl try to avoid
this emulation layer when possible, as it is limited and often introduce
bugs.

[...]
 
> Some smaller issues I noticed only happening on kfreebsd, but haven't
> tracked them down (probably no bug report yet either, partially also
> affects servers):
> 
> * Emacs 23 via remote X doesn't work. No idea why yet.
> 
> * aptitude segfaults approximately every second or third call. (That's
>   much better than months ago where I was used to start aptitude with
>   "until aptitude; do sleep 0.1; done")

The problem with this kind of issues is that we are now aware of it.
Personally I don't use emacs and aptitude works perfectly on my machine
since the crash issue has been fixed.

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net


-- 
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/20100804183534.gs4...@hall.aurel32.net

Re: Releasability of the kFreeBSD ports

[Axel Beckert]

Hi,

Tuco wrote:
> I think as a desktop it's still inmature but as a server it's very
> usable and has wonderful capabilities in storage area thanks to ZFS
> (for example http://www.ypass.net/solaris/zfsbackup/).

Yeah, thanks to Tuco we made big advances with usable ZFS support
recently. Thanks! :-)

But I also have to agree that there are still many more or less small
but often very annoying issues, especially on the desktop, like:

* gdm[1] and kdm[2] not getting a working keyboard with default X
  config, but restarting them later (e.g. via ssh or by calling the
  XDMCP chooser) makes the keyboard work (Yet another nasty HAL issue?
  Race condition somewhere?)

  [1] http://bugs.debian.org/586539
  [2] http://bugs.debian.org/586540

* konsole no more working with newer kfreebsd kernels:
  http://lists.debian.org/debian-bsd/2010/08/msg00024.html and
  http://bugs.debian.org/573063

* No bluetooth.

* ALSA: Many ALSA dependent packages not working/building/available.
  (There is a limited emulation layer called SALSA, but either many
  packages don't work with it or nobody tried to get them working with
  it. Not sure how many unfixed bugs because of this are still open.)

* FUSE: fuse4bsd[3] hasn't been packaged yet, therefore most fuse based
  packages are uninstallable. (For luck the upstream website
  is back again, was replaced by some advertising portal or so for
  some weeks.) Last commit[4] 17 months ago, last release June 2007.

  [3] http://fuse4bsd.creo.hu/
  [4] http://mercurial.creo.hu/repos/fuse4bsd-hg/
  http://fuse4bsd.creo.hu/darcsweb/darcsweb.cgi?r=fuse4bsd

  More on that in a seperate mail to debian-...@l.d.o.

Some smaller issues I noticed only happening on kfreebsd, but haven't
tracked them down (probably no bug report yet either, partially also
affects servers):

* Emacs 23 via remote X doesn't work. No idea why yet.

* aptitude segfaults approximately every second or third call. (That's
  much better than months ago where I was used to start aptitude with
  "until aptitude; do sleep 0.1; done")

* IPv6 support and some other stuff[4] in the /sbin/route wrapper is
  missing. I do have that on my todo list, but not with top priority.

  [4] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=567939

There are probably more of that kind, but those are the ones I
remember at the moment.

> > If it's not entirely up to our standards, would a separate suite, like it
> > has been done in the past for sarge-amd64 and etch-m68k, help having some
> > sort of release that can be updated independently from the main stable
> > release?  Such a suite could also be useful to land larger changes than
> > normally allowed for stable.

Sounds like an fallback in case we don't get close to a releasable
state. At least I do have good memories(*) about using sarge-amd64, so
that's IMHO an option which should both, not affect the "normal"
release, but is still very close to the normal release. I.e. we do
have a more or less fixed state, so nobody who likes to try kfreebsd
does have to use rolling releases (i.e. testing/unstable). And being
close to the release even if not officially part of the release will
get us far more kfreebsd users than just kicking it out short before
the release.

(*) I'm writing this mail on a machine which started out as
sarge-amd64 and never needed a reinstallation since then, just
dist-upgrades as I'm used from Debian. :-)

> > Or do you think we should skip this release?  (But keep it in testing, of
> > course.)

If we don't release it normal with Squeeze, I'd at least release it
like sarge-amd64, but definitely not do nothing (i.e. skip the
release).

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
  `-|  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5


-- 
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/20100804175252.gn11...@sym.noone.org

Re: Hypre transition

[Adam C Powell IV]

On Wed, 2010-08-04 at 17:38 +0200, Philipp Kern wrote:
> Adam,
> 
> On Wed, Aug 04, 2010 at 11:23:36AM -0400, Adam C Powell IV wrote:
> > I'd like to move the hypre package from version 2.4.0b to 2.6.0b.  Its
> > shared libs are used directly by petsc and elmerfem, and indirectly by a
> > handful of petsc's reverse-depends (deal.ii, dolfyn, life, slepc).
> 
> you didn't mention why you need this transition.

More advanced features in the new library, and the alioth repository has
an RC bug fix and other changes mixed in with the new version changes,
so it would take a bit of time to untangle them.

> Furthermore it seems unlikely to accept any further transitions at this
> point.

I understand.  I'll proceed with the untangling in the next few days,
unless I hear from you or others on the list first.

Thanks,
Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Engineering consulting with open source tools
http://www.opennovation.com/


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

Re: Releasability of the kFreeBSD ports

[Aurelien Jarno]

On Wed, Aug 04, 2010 at 02:38:42AM +0200, Philipp Kern wrote:
> Dear kFreeBSD porters, dear kFreeBSD users,

Hi,

> the Release Team is currently wondering if it makes sense to release with
> kFreeBSD as a regular stable architecture with squeeze.  It might be that
> it is not yet up to the standards of a regular Debian release as it might
> not contain everything that's expected by users.
> 
> So, what do you think is still missing?  What would we need to communicate
> as a disclaimer to the users if releasing kFreeBSD in this state?  

>From the server point of view, I think we reached something close to
other debian-ports, with even some added features like ZFS. On the other 
hand I have to agree that on the desktop point of view, there are still
problems, which may break the expectations users have from a stable
release. The desktop is usable though.

> If it's not entirely up to our standards, would a separate suite, like it
> has been done in the past for sarge-amd64 and etch-m68k, help having some
> sort of release that can be updated independently from the main stable
> release?  Such a suite could also be useful to land larger changes than
> normally allowed for stable.
> 
> Or do you think we should skip this release?  (But keep it in testing, of
> course.)
> 

Doing a release, a "technology preview" or something that offer a
consistent port with security updates to the users will definitely help
the port by attracting more users and possible developers. I am open to
any form of "release".

Cheers,
Aurelien

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net


-- 
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/20100804171529.ga3...@hall.aurel32.net

Re: GNOME 2.32 plans

[Emilio Pozuelo Monfort]

On 04/08/10 18:14, Josselin Mouette wrote:
> Le mercredi 04 août 2010 à 17:21 +0200, Emilio Pozuelo Monfort a écrit :
>> I'd say it depends on when the RT plans to freeze the archive. If soon (e.g.
>> this month) maybe we should just release with 2.30? But if they don't plan to
>> release anytime soon, updating GLib and GTK+ doesn't bad to me, although I 
>> don't
>> see much benefits in updating GLib.
> 
> The benefit of updating Glib is to be able to upload GTK+ 2.22 - which
> in turn is necessary if we want GTK+ 3.0 backports to work.

Oh right. It's probably that GTK+ 3.0 will depend on GLib 2.28, and maybe a new
libgdk-pixbuf, although it would be easier to upload a newer libgdk-pixbuf to
backports if the split is already in stable.

I'm fine with updating them.

Is there an approximated freeze date?

Regards,
Emilio


-- 
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/4c5995ae.6070...@debian.org

Re: Releasability of the kFreeBSD ports

[Tuco]

I intend to deploy Debian GNU/kFreeBSD as a backup / NAS server. I
think as a desktop it's still inmature but as a server it's very
usable and has wonderful capabilities in storage
area thanks to ZFS (for example http://www.ypass.net/solaris/zfsbackup/).

I also think it can be a good firewall with PF. It would be very
useful to me if there was a stable release with security support.
Running an unreleased system in production is a bit
impractical :-(

On 8/3/10, Philipp Kern  wrote:
> Dear kFreeBSD porters, dear kFreeBSD users,
>
> the Release Team is currently wondering if it makes sense to release with
> kFreeBSD as a regular stable architecture with squeeze.  It might be that
> it is not yet up to the standards of a regular Debian release as it might
> not contain everything that's expected by users.
>
> So, what do you think is still missing?  What would we need to communicate
> as a disclaimer to the users if releasing kFreeBSD in this state?
>
> If it's not entirely up to our standards, would a separate suite, like it
> has been done in the past for sarge-amd64 and etch-m68k, help having some
> sort of release that can be updated independently from the main stable
> release?  Such a suite could also be useful to land larger changes than
> normally allowed for stable.
>
> Or do you think we should skip this release?  (But keep it in testing, of
> course.)
>
> Kind regards,
> Philipp Kern
>


-- 
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/aanlktinvjqsncprkr4a6vc6gknku9aj7w=qdt=vd=...@mail.gmail.com

Re: Releasability of the kFreeBSD ports

[Brian Gupta]

Ok my suggestions below may be stating the obvious, if so my apologies.

I would suggest, making a list of criteria, that we believe would
constitute a stable release. (I personally don't know enough to say
what that criteria is, and this email thread may be the first step in
creating that list).

Then, at the after the stable change-freeze, I would look and see
where we are. I think the options, in my preferred order of
preference, would be:
1) Fix all the release critical bugs and release as planned. (If this
slightly delays things, and the overall Debian release team is ok with
the delay, I'd say this should be a preference).
2) Go "stable", with a caveat that "stable" for this port differs from
standard debian stable, which has assumptions based on the development
of an OS built on a Linux kernel. Much of what you are doing is
unprecedented, so that some degree of flexibility on creating new
policy as you go should be awarded. e.g. - changing the FreeBSD kernel
during the life of a stable release *MAY* be desirable. Another caveat
to announce would be that this is "first stable" and that as such this
is the first time the port will be introduced to a widespread audience
so there *MAY* be more issues than other stable "ports".
3) See if we can remain in some sort of "stable-candidate" state after
the overall squeeze goes stable, and declare it stable when we are
ready. (I don't know if this is possible under current Debian policy,
but again I would argue that unprecedented efforts, deserve the
opportunity to create new policy). I suspect that if we can assure
that we are either only touching kfreebsd packages, and/or the files
that affect kfreebsd we could find support for this option.
4) Do as you have done in the past effectively skipping squeeze. I
don't think this is a good idea. (If you need me to expound, I can,
but I suspect my opinion here matches the majority).

Cheers,
Brian

On Wed, Aug 4, 2010 at 11:33 AM, Julien BLACHE  wrote:
> Petr Salinger  wrote:
>
> Hi,
>
>> * openjdk on both kfreebsd-i386/kfreebsd-amd64
>>   man-power is missing, we use gcj similarly as hppa
>
> gcj 4.4 is currently broken on kfreebsd-amd64 per #576335.
>
> JB.
>
> --
>  Julien BLACHE - Debian & GNU/Linux Developer - 
>
>  Public key available on  - KeyID: F5D6 5169
>  GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169
>
>
> --
> To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
> Archive: http://lists.debian.org/871vae75q0@sonic.technologeek.org
>
>


--
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/aanlktiøk49wyuayxlnfzfyj39hganefsp_e31y2...@mail.gmail.com

Re: GNOME 2.32 plans

[Josselin Mouette]

Le mercredi 04 août 2010 à 17:21 +0200, Emilio Pozuelo Monfort a écrit :
> I'd say it depends on when the RT plans to freeze the archive. If soon (e.g.
> this month) maybe we should just release with 2.30? But if they don't plan to
> release anytime soon, updating GLib and GTK+ doesn't bad to me, although I 
> don't
> see much benefits in updating GLib.

The benefit of updating Glib is to be able to upload GTK+ 2.22 - which
in turn is necessary if we want GTK+ 3.0 backports to work.

-- 
 .''`.
: :' : “You would need to ask a lawyer if you don't know
`. `'   that a handshake of course makes a valid contract.”
  `---  J???rg Schilling


--
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/1280938451.449.34.ca...@meh

Re: Releasability of the kFreeBSD ports

[Tuco]

On 8/4/10, Petr Salinger  wrote:
> * openjdk on both kfreebsd-i386/kfreebsd-amd64
>man-power is missing, we use gcj similarly as hppa

I'm working on openjdk. But progress is slow because it takes
a lot of time to build after each fix.


-- 
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/aanlktik2gfboe=ngu8gtgxnuc--byu4hmpynbfwqq...@mail.gmail.com

Re: GNOME 2.32 plans

[Emilio Pozuelo Monfort]

Hi,

On 04/08/10 10:24, Josselin Mouette wrote:
> as some of you might have heard, there is going to be a GNOME 2.32
> release in September, GNOME 3.0 being delayed to next spring.
> 
> For a large number of modules, 2.32 is going to be a pure bugfix release
> based on 2.30. Therefore I propose the following approach:
>   * For bugfix releases, we upload them to unstable and try to put
> them in squeeze.

This sounds a little error-prone, but I don't have a better idea than "let's
just release with 2.30", so I'm fine with it. (If we upload something that
shouldn't have been uploaded, we can always reupload the 2.30 package).

>   * For modules requiring GSettings, we keep the 2.30 version, maybe
> with some backported bugfixes. GSettings is simply too fresh, we
> don’t have enough hindsight and we don’t want to have to direct
> users through 2 different configuration mechanisms.

Agreed.

>   * For modules not requiring GSettings but requiring other new
> features in Glib or GTK+ 2.x, see later. I doubt we will have
> many such modules.

> Then there’s the case of Glib. Glib 2.26 will be backwards compatible,
> but the introduction of GSettings causes some packaging changes. I’m not
> too fond of risking to break reverse dependencies. Having this version
> in squeeze will depend on the calendar, but I’m not too fond of risking
> to break thousands of reverse dependencies. I guess we’ll have to see
> how the freeze is coming when it’s out.

What packaging changes are you afraid of? The new triggers and the new -bin
package? What problems could they cause to reverse dependencies? Are there
packages calling gio-querymodules themselves?

> For GTK+ 2.22, things are in a similar state. Even larger packaging
> changes are being introduced because gdk-pixbuf was split in a separate
> module. However I’d prefer to see it in squeeze, otherwise backporting
> GTK+ 3.0 will be very hard. Of course I’m only proposing it since it
> doesn’t use GSettings. 
> 
> For GTK+ 3.0, the plan is to rely on backports since we don’t even have
> a release date.

I've heard about the release being on Christmas, but that's probably not set in
stone yet.

> If we ever happen to see it available during early
> freeze time, we can try to squeeze it in. But in any case, direct or
> indirect dependencies of meta-gnome2 must not depend on it. It would be
> just so that GTK+ 3 applications can be built on squeeze without
> backports.
> 
> Do you think this is realistic?

I'd say it depends on when the RT plans to freeze the archive. If soon (e.g.
this month) maybe we should just release with 2.30? But if they don't plan to
release anytime soon, updating GLib and GTK+ doesn't bad to me, although I don't
see much benefits in updating GLib.

Cheers,
Emilio


-- 
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/4c598567.2050...@debian.org

Re: Hypre transition

[Philipp Kern]

Adam,

On Wed, Aug 04, 2010 at 11:23:36AM -0400, Adam C Powell IV wrote:
> I'd like to move the hypre package from version 2.4.0b to 2.6.0b.  Its
> shared libs are used directly by petsc and elmerfem, and indirectly by a
> handful of petsc's reverse-depends (deal.ii, dolfyn, life, slepc).

you didn't mention why you need this transition.

Furthermore it seems unlikely to accept any further transitions at this
point.

Kind regards,
Philipp Kern



signature.asc
Description: Digital signature

Re: Releasability of the kFreeBSD ports

[Julien BLACHE]

Petr Salinger  wrote:

Hi,

> * openjdk on both kfreebsd-i386/kfreebsd-amd64
>   man-power is missing, we use gcj similarly as hppa

gcj 4.4 is currently broken on kfreebsd-amd64 per #576335.

JB.

-- 
 Julien BLACHE - Debian & GNU/Linux Developer -  
 
 Public key available on  - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 


-- 
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/871vae75q0@sonic.technologeek.org

Hypre transition

[Adam C Powell IV]

Greetings,

I'd like to move the hypre package from version 2.4.0b to 2.6.0b.  Its
shared libs are used directly by petsc and elmerfem, and indirectly by a
handful of petsc's reverse-depends (deal.ii, dolfyn, life, slepc).  The
interface has changed only slightly (though enough for a soname bump),
so for the most part only bin-NMUs should be required.  And I maintain
petsc, elmerfem and deal.ii, so I can handle most of the non-binNMU
changes.

Is this something I can go ahead with?  Is there any preparation I
should do, e.g. porting petsc, elmerfem and deal.ii in alioth before
uploading anything?

[Please CC me in replies.]

Thanks,
Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Engineering consulting with open source tools
http://www.opennovation.com/


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

Bug#589689: Bug#590948: Bug#589689: transition to libjack-jackd2-0 breaks many packages

[Felipe Sateler]

On 03/08/10 17:50, Julien Cristau wrote:
> On Tue, Aug  3, 2010 at 17:31:05 -0400, Felipe Sateler wrote:
> 
>> This doesn't seem to help (I called dpkg-buildpackage -B and doxygen was
>> called). How will dh_listpackages know if we called dpkg-buildpackage -B?
>>
> In 'build', it doesn't.  If you want to do something only if arch-indep
> packages are built, do it in binary-indep or binary.

Jonas,

How do we do this in CDBS?

-- 
Saludos,
Felipe Sateler



-- 
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/4c597e60.3040...@debian.org

NEW changes in proposedupdates

[Archive Administrator]

Processing changes file: lftp_3.7.3-1+lenny1_i386.changes
  ACCEPT
Processing changes file: lftp_3.7.3-1+lenny1_alpha.changes
  ACCEPT
Processing changes file: lftp_3.7.3-1+lenny1_amd64.changes
  ACCEPT
Processing changes file: lftp_3.7.3-1+lenny1_arm.changes
  ACCEPT
Processing changes file: lftp_3.7.3-1+lenny1_armel.changes
  ACCEPT
Processing changes file: lftp_3.7.3-1+lenny1_hppa.changes
  ACCEPT
Processing changes file: lftp_3.7.3-1+lenny1_ia64.changes
  ACCEPT
Processing changes file: lftp_3.7.3-1+lenny1_mips.changes
  ACCEPT
Processing changes file: lftp_3.7.3-1+lenny1_mipsel.changes
  ACCEPT
Processing changes file: lftp_3.7.3-1+lenny1_powerpc.changes
  ACCEPT
Processing changes file: lftp_3.7.3-1+lenny1_s390.changes
  ACCEPT
Processing changes file: lftp_3.7.3-1+lenny1_sparc.changes
  ACCEPT


-- 
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/e1ogeza-0005sx...@franck.debian.org

GNOME 2.32 plans

[Josselin Mouette]

Hi,

as some of you might have heard, there is going to be a GNOME 2.32
release in September, GNOME 3.0 being delayed to next spring.

For a large number of modules, 2.32 is going to be a pure bugfix release
based on 2.30. Therefore I propose the following approach:
  * For bugfix releases, we upload them to unstable and try to put
them in squeeze.
  * For modules requiring GSettings, we keep the 2.30 version, maybe
with some backported bugfixes. GSettings is simply too fresh, we
don’t have enough hindsight and we don’t want to have to direct
users through 2 different configuration mechanisms.
  * For modules not requiring GSettings but requiring other new
features in Glib or GTK+ 2.x, see later. I doubt we will have
many such modules.

Then there’s the case of Glib. Glib 2.26 will be backwards compatible,
but the introduction of GSettings causes some packaging changes. I’m not
too fond of risking to break reverse dependencies. Having this version
in squeeze will depend on the calendar, but I’m not too fond of risking
to break thousands of reverse dependencies. I guess we’ll have to see
how the freeze is coming when it’s out.

For GTK+ 2.22, things are in a similar state. Even larger packaging
changes are being introduced because gdk-pixbuf was split in a separate
module. However I’d prefer to see it in squeeze, otherwise backporting
GTK+ 3.0 will be very hard. Of course I’m only proposing it since it
doesn’t use GSettings. 

For GTK+ 3.0, the plan is to rely on backports since we don’t even have
a release date. If we ever happen to see it available during early
freeze time, we can try to squeeze it in. But in any case, direct or
indirect dependencies of meta-gnome2 must not depend on it. It would be
just so that GTK+ 3 applications can be built on squeeze without
backports.

Do you think this is realistic?
-- 
 .''`.
: :' :  “Fuck you sir, don’t be suprised when you die if
`. `'   you burn in Hell, because I am a solid Christian
  `-and I am praying for you.”   --  Mike


--
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/1280910279.449.21.ca...@meh

Re: Releasability of the kFreeBSD ports

[Petr Salinger]

Hi,


the Release Team is currently wondering if it makes sense to release with
kFreeBSD as a regular stable architecture with squeeze.  It might be that
it is not yet up to the standards of a regular Debian release as it might
not contain everything that's expected by users.

So, what do you think is still missing?  What would we need to communicate
as a disclaimer to the users if releasing kFreeBSD in this state?


Call it "technology preview" ?


If it's not entirely up to our standards, would a separate suite, like it
has been done in the past for sarge-amd64 and etch-m68k, help having some
sort of release that can be updated independently from the main stable
release?  Such a suite could also be useful to land larger changes than
normally allowed for stable.



Or do you think we should skip this release?  (But keep it in testing, of
course.)


Please do not skip squeeze release.

The GNU/kFreeBSD architectures cover majority of packages,
see [1] for missing packages ordered by popcon count.


From TOP 500, most packages have their counter part

already available, like
  net-tools -> freebsd-net-tools
  module-init-tools -> kldutils
  linux-2.6 -> kfreebsd-8
  strace -> ktrace in freebsd-utils
  iptables -> pfctl in freebsd-net-tools
  grub -> grub2

The uninstallable packages in testing are currently
related mainly to fuse/iptables/udev.

Update of [2]:

* decide version of kernel and related utilities.
  8.1 have been released in July 2010, currently in sid
  Also zfsutils have been packaged.

* port of Debian Installer for GNU/kFreeBSD
  it is being built daily with local udebs, based on 7.2 kernel,
  switch to 8.1 kernel is being prepared

* gnat availability on kfreebsd-amd64
  finished

* ghc6 availability on kfreebsd-amd64
  finished

* openjdk on both kfreebsd-i386/kfreebsd-amd64
  man-power is missing, we use gcj similarly as hppa

* cleanup after eglibc 2.10 upload (drop of libfreebsd)
  finished

* specific FTBFS on GNU/kFreeBSD, many with patches in BTS, see [3]
  continuously updated ...

* infrastructure (DSAed build daemons, DSAed porter machines)
  state not known to me

* general usability of the port
  continuously tested ;-)


The implementation of #27 (support [only out-of-date] on buildd status 
pages) would be very helpfull for prioritizing porters work.


Cheers

Petr

[1] http://glibc-bsd.alioth.debian.org/NOTES.archive
[2] http://lists.debian.org/debian-release/2009/09/msg00094.html
[3] 
http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=kfreebsd;users=debian-...@lists.debian.org;pri0=pending:pending,forwarded,pending-fixed,fixed,done,absent;ttl0=Outstanding,Forwarded,Pending%20Upload,Fixed%20in%20NMU,Resolved;pri1=pending%3dpending%2btag%3dwontfix,pending%3dpending%2btag%3dmoreinfo,pending%3dpending%2btag%3dpatch,pending%3dpending%2btag%3dconfirmed,pending%3dpending;ttl1=Will%20Not%20Fix,More%20information%20needed,Patch%20Available,Confirmed,Unclassified;ord1=2,3,4,1,0,5


--
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/pine.lnx.4.62.1008041034220.3...@sci.felk.cvut.cz