Re: xulrunner 1.9.2 into sid?

[Mike Hommey]

On Sun, Jun 27, 2010 at 08:25:59AM -0600, Aaron Toponce wrote:
> Seeing as though upstream Firefox 3.6 released December 1, 2008, and
> upstream Thunderbird 3.1 released just a couple days ago, it might be
> high time to get xulrunner 1.9.2 into Sid, as both Iceweasel 3.6 and
> Icedove 3.1 will depend on it. However, I hear there will be lots of
> breakage if xulrunner 1.9.2 comes into Sid. If so, what will break?
> Further, what can I do to help?

Short answer: not much.

Long answer:
The target for squeeze was decided to be 3.5/1.9.1 a long time ago, when
testing freeze was expected much earlier. Until Thunderbird 3.1, the
incentive to keep it that way still made sense. Now, things may have
changed, but it's more complicated than it seems.

We currently only have one version of xulrunner in the archive for a
given suite. Technically speaking, the xulrunner source package provides
the xulrunner-1.9.x packages, and obviously a given source package only
provides on xulrunner-1.9.x package. At the moment, stable (lenny) has
xulrunner-1.9, squeeze and unstable have xulrunner-1.9.1 and
experimental has xulrunner-1.9.2. With the upcoming release of the
Firefox 4.0 first beta, there might be a xulrunner-2.0 coming in a third
party repository.

Therea are mainly two reasons for that state of affairs with xulrunner:
- it avoids having a part of the suite using a version of xulrunner
  while another part uses a different one, which would most probably
  create a big mess.
- there is not enough hand power to maintain several versions of
  xulrunner in the same suite (especially stable)

The latter also applies for iceape and icedove, and is why 3.5/1.9.1 is
still considered as the release target: iceape 2.0, icedove 3.0, and
iceweasel 3.5 are all based on xulrunner/gecko 1.9.1. Security support
for stable will be easier if there is only one branch to support for the
whole gecko ecosystem. Sure, upstream support for it will be dropped
soon, but we can't expect 3.6 to be supported the whole squeeze lifetime
either.

That being said, there are reasons why 3.6 would be nice to have in
squeeze, and the main one is the out of process plugin feature.

BUT, there are technical reasons that make that goal difficult to attain.

First, TB 3.1 has just been released, and as such hasn't been widely
tested in Debian. It usually isn't very wise, that close to the expected
freeze time, to upload a new major release of a not exactly small and
trivial software.

Second, for the reasons given earlier, releasing with iceweasel 3.6 and
icedove 3.1 would mean to avoid releasing with iceape 2.0. This may not
be a huge problem, as we already didn't release lenny with iceape, but
see below.

Switching to xulrunner 1.9.2 means making sure all the packages
currently built against xulrunner-dev and libmozjs-dev build fine, get
the proper dependencies, and then run fine with xulrunner 1.9.2.
Unfortunately, as xpcom is guaranteed forward compatible but not
backwards compatible, some plugins and extensions, once built against
xulrunner 1.9.2, are likely to not work in iceape 2.0 anymore. This
would leave iceape users with a bitter aftertaste. Alternatively,
iceape-dev could be filled again with the relevant header and library
files, such that those plugins and extensions can build against it which
would solve the compatibility issue, but then iceape would need to
either be released or be left in the same state as in lenny, i.e. only
providing the -dev package. That means a lot of work in identifying
those plugins and extensions, modifying them, etc.
FWIW, as iceape-dev is not used anymore and is a transitional package, I
was about to remove it.

Switching to xulrunner 1.9.2 would also mean to make sure it works
properly on all the target architectures, while currently there are
various test suite failures on some architectures. xulrunner 1.9.1 is in
a better shape, from that perspective.

All in all, I still think releasing squeeze with iceape 2.0, iceweasel
3.5 and icedove 3.0 is the best course of action.

Cheers,

Mike


-- 
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/20100628083406.gd5...@glandium.org

Re: xulrunner 1.9.2 into sid?

[Steffen Möller]

Hello,

On 06/27/2010 04:25 PM, Aaron Toponce wrote:
> Seeing as though upstream Firefox 3.6 released December 1, 2008, and
> upstream Thunderbird 3.1 released just a couple days ago, it might be
> high time to get xulrunner 1.9.2 into Sid, as both Iceweasel 3.6 and
> Icedove 3.1 will depend on it. However, I hear there will be lots of
> breakage if xulrunner 1.9.2 comes into Sid. If so, what will break?
> Further, what can I do to help?
>   
It cannot be that bad, I am running it on my desktop with Maverick.
ii  xulrunner-1.9.2 1.9.2.4+build7+nobinonly-0u XUL + XPCOM
application runner

It is already in experimental
http://packages.debian.org/search?searchon=sourcenames&keywords=xulrunner
maybe you can just install it and report back to the maintainers?

Thanks and regards

Steffen


-- 
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/4c285f84.7030...@gmx.de

Re: [DRAFT] Policy for Linux kernel, initramfs, boot loader update process

[maximilian attems]

On Mon, 28 Jun 2010, Ben Hutchings wrote:

> 2. Packages for boot loaders that need to be updated whenever the files
> they load are modified must also install hook scripts in
> /etc/mkinitramfs/post-update.d.  Initramfs builders must call these
> scripts using run-parts after they create, update or delete an
> initramfs.  The arguments given to these hook scripts are the kernel ABI
> version and the absolute path to the initramfs image.

Please rename to more generic /etc/initramfs path.
mkinitramfs is initramfs-tools specific.
otherwise ack.
 
> 3. Initramfs builders must complete their work before returning from the
> kernel postinst hook script.  [initramfs-tools currently uses a trigger
> to defer this because it can also be invoked twice, but this means it
> also has to know how to update specific boot loaders.]

not twice but multiple times, if you upgrade together for example
udev, lvm2, cryptsetup, mdadm and linux-2.6.
 
> 4. During a kernel package installation, upgrade or removal, various
> boot loader hooks may be invoked (in this order):
> 
> a. A postinst_hook or postrm_hook command set by the user or the
>installer in /etc/kernel-img.conf
> b. A hook script in /etc/mkinitramfs/post-update.d
> c. A hook script in /etc/kernel/postinst.d or .../postrm.d
> 
> To avoid unnecessary updates, the hooks invoked at step a and b may
> check whether $DPKG_MAINTSCRIPT_PACKAGE begins with 'linux-image-' and
> do nothing in this case.  [Is this sensible or is it too 'clever'?]

what is the intent of that point?
sorry you lost me here.
 
> 5. Kernel and initramfs builder packages must not invoke boot loaders
> except via hooks.  If /etc/kernel-img.conf contains an explicit
> 'do_bootloader = yes', kernel package maintainer scripts should warn
> that this is now ignored.

for backward compat and upgrade purpose from lenny,
I think the must is wrong.
 
> 6. The installer must not define do_bootloader, postinst_hook or
> postrm_hook in /etc/kernel-img.conf.
> ---

thanks

-- 
maks


-- 
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/20100628084532.ga23...@stro.at

Re: xulrunner 1.9.2 into sid?

[Marco d'Itri]

On Jun 28, Mike Hommey  wrote:

> Unfortunately, as xpcom is guaranteed forward compatible but not
> backwards compatible, some plugins and extensions, once built against
> xulrunner 1.9.2, are likely to not work in iceape 2.0 anymore. This
> would leave iceape users with a bitter aftertaste. Alternatively,
And how would this be worse than shipping a version of iceweasel which
is already obsolete? Who actually cares about iceape?
If there is no manpower to do better than this then I feel that it would
be more honest to just use volatile.

FWIW, I have been using iceweasel 3.6 since it has been uploaded and it
works *much* better than 3.5 did, which was slow and crashed a lot.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: xulrunner 1.9.2 into sid?

[Philipp Kern]

On 2010-06-28, Marco d'Itri  wrote:
> If there is no manpower to do better than this then I feel that it would
> be more honest to just use volatile.

The catch-all for "I can't maintain this stuff properly"[1] is not volatile,
but backports.  Thanks.

Kind regards,
Philipp Kern

[1] No offence meant for the awesome mozilla maintainers.


-- 
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/slrni2gsca.jp9.tr...@kelgar.0x539.de

Re: xulrunner 1.9.2 into sid?

[Mike Hommey]

On Mon, Jun 28, 2010 at 11:35:17AM +0200, Marco d'Itri wrote:
> On Jun 28, Mike Hommey  wrote:
> 
> > Unfortunately, as xpcom is guaranteed forward compatible but not
> > backwards compatible, some plugins and extensions, once built against
> > xulrunner 1.9.2, are likely to not work in iceape 2.0 anymore. This
> > would leave iceape users with a bitter aftertaste. Alternatively,
> And how would this be worse than shipping a version of iceweasel which
> is already obsolete? Who actually cares about iceape?
> If there is no manpower to do better than this then I feel that it would
> be more honest to just use volatile.

apt-cache rdepends xulrunner-1.9.1 libmozjs2d

What are you suggesting for these packages? volatile, too?

Mike


-- 
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/20100628101703.ga12...@glandium.org

Re: xulrunner 1.9.2 into sid?

[Mike Hommey]

On Mon, Jun 28, 2010 at 09:55:22AM +, Philipp Kern wrote:
> On 2010-06-28, Marco d'Itri  wrote:
> > If there is no manpower to do better than this then I feel that it would
> > be more honest to just use volatile.
> 
> The catch-all for "I can't maintain this stuff properly"[1] is not volatile,
> but backports.  Thanks.

Speaking of backports, a way to streamline packages from testing to
backports would be very much helpful for packages like iceweasel, where
basically the package from testing can be installed on a lenny system
provided you already use backports for some other libraries. If that's
not the case anymore, some of its dependencies should be switched to
using symbols files.

Mike


-- 
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/20100628101928.gb12...@glandium.org

Re: xulrunner 1.9.2 into sid?

[Marco d'Itri]

On Jun 28, Mike Hommey  wrote:

> Speaking of backports, a way to streamline packages from testing to
> backports would be very much helpful for packages like iceweasel, where
> basically the package from testing can be installed on a lenny system
> provided you already use backports for some other libraries. If that's
> not the case anymore, some of its dependencies should be switched to
> using symbols files.
Please open bugs on all your dependencies which are still not shipping
symbol files!
I did it (with patches) for some key dependencies of my packages and it
helped a lot.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: xulrunner 1.9.2 into sid?

[Aaron Toponce]

On 06/28/2010 02:34 AM, Mike Hommey wrote:
> The latter also applies for iceape and icedove, and is why 3.5/1.9.1 is
> still considered as the release target: iceape 2.0, icedove 3.0, and
> iceweasel 3.5 are all based on xulrunner/gecko 1.9.1. Security support
> for stable will be easier if there is only one branch to support for the
> whole gecko ecosystem. Sure, upstream support for it will be dropped
> soon, but we can't expect 3.6 to be supported the whole squeeze lifetime
> either.

Ah yes, Iceape. Their releases are so few and far between, this could
possibly mean that we won't see Iceweasel 3.6 or Icedove 3.1 for some
time, correct? Upstream Seamonkey 2.1 will be build against gecko 1.9.3,
but its release date is TBD. Upstream Firefox 4 is due the end of the
year, based on 1.9.3, and will likely be ahead of Seamonkey. So where
does that put us? Seems trying to keep the two projects aligned is some
task. :)

Will Iceweasel 4 go into Sid when Iceape 2.1 goes into Sid?

> First, TB 3.1 has just been released, and as such hasn't been widely
> tested in Debian. It usually isn't very wise, that close to the expected
> freeze time, to upload a new major release of a not exactly small and
> trivial software.

I can understand this, but I would imagine the release of Squeeze is at
least 8-10 months out. We still have a good deal of RC bugs to get
through. Of course, packages this size will add to the count.

> Second, for the reasons given earlier, releasing with iceweasel 3.6 and
> icedove 3.1 would mean to avoid releasing with iceape 2.0. This may not
> be a huge problem, as we already didn't release lenny with iceape, but
> see below.

Iceape is a beautiful piece of software, and I have run it in the past.
But market share shows that Seamonkey/Iceape users are the minority,
with Firefox/Iceweasel and Thunderbird/Icedove the vast majority.
Releasing Lenny without Iceape was the best move, IMO.

> All in all, I still think releasing squeeze with iceape 2.0, iceweasel
> 3.5 and icedove 3.0 is the best course of action.

Is this really the best move? With Firefox 4 due the end of the year,
and 3.6 will be a year old already, the security team will be supporting
3.5 after Mozilla stops it's support. Same might be the case with
Icedove 3.0.

I can see this is a delicate dance, and I can see the problem of two
xulrunner releases in a single archive. I wasn't aware of the technical
complexities, so it was good to learn. Thanks for taking the time.

-- 
. O .   O . O   . . O   O . .   . O .
. . O   . O O   O . O   . O O   . . O
O O O   . O .   . O O   O O .   O O O



signature.asc
Description: OpenPGP digital signature

RE : xulrunner 1.9.2 into sid?

[PICCA Frédéric-Emmanuel]

Do you have an entry explaining how to create from scratch a symbol file for a 
given library ?

I could not find this information on the debian wiki.

thanks

Frederic


 Message d'origine
De: Marco d'Itri [mailto:m...@linux.it]
Date: lun. 28/06/2010 12:37
À: debian-devel@lists.debian.org
Cc: pkg-mozilla-maintain...@lists.alioth.debian.org
Objet : Re: xulrunner 1.9.2 into sid?
 
On Jun 28, Mike Hommey  wrote:

> Speaking of backports, a way to streamline packages from testing to
> backports would be very much helpful for packages like iceweasel, where
> basically the package from testing can be installed on a lenny system
> provided you already use backports for some other libraries. If that's
> not the case anymore, some of its dependencies should be switched to
> using symbols files.
Please open bugs on all your dependencies which are still not shipping
symbol files!
I did it (with patches) for some key dependencies of my packages and it
helped a lot.

-- 
ciao,
Marco


--
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/606cc410b038e34cb97646a32d0ec0bf03888...@venusbis.synchrotron-soleil.fr

Re: xulrunner 1.9.2 into sid?

[Mike Hommey]

On Mon, Jun 28, 2010 at 05:36:11AM -0600, Aaron Toponce wrote:
> Ah yes, Iceape. Their releases are so few and far between, this could
> possibly mean that we won't see Iceweasel 3.6 or Icedove 3.1 for some
> time, correct? Upstream Seamonkey 2.1 will be build against gecko 1.9.3,
> but its release date is TBD. Upstream Firefox 4 is due the end of the
> year, based on 1.9.3, and will likely be ahead of Seamonkey. So where
> does that put us? Seems trying to keep the two projects aligned is some
> task. :)

(note 1.9.3 is apparently going to be reversioned to 2.0)

> Will Iceweasel 4 go into Sid when Iceape 2.1 goes into Sid?

3.6 will go into sid when squeeze is released. It will remain in
experimental until then, except if the plans change.
4.0 betas will go into experimental then. In the meanwhile, they will
probably be provided somewhere on mozilla.debian.net.
4.0 will go into sid when it is released.

> > First, TB 3.1 has just been released, and as such hasn't been widely
> > tested in Debian. It usually isn't very wise, that close to the expected
> > freeze time, to upload a new major release of a not exactly small and
> > trivial software.
> 
> I can understand this, but I would imagine the release of Squeeze is at
> least 8-10 months out. We still have a good deal of RC bugs to get
> through. Of course, packages this size will add to the count.

Supposedly, the freeze is somewhen in august. After that, getting a new
major version in the archive is a no-go.

> > Second, for the reasons given earlier, releasing with iceweasel 3.6 and
> > icedove 3.1 would mean to avoid releasing with iceape 2.0. This may not
> > be a huge problem, as we already didn't release lenny with iceape, but
> > see below.
> 
> Iceape is a beautiful piece of software, and I have run it in the past.
> But market share shows that Seamonkey/Iceape users are the minority,
> with Firefox/Iceweasel and Thunderbird/Icedove the vast majority.
> Releasing Lenny without Iceape was the best move, IMO.

If Debian accounted for market share, it would dump a whole lot of
packages. There are a lot of packages with less users than iceape.

> > All in all, I still think releasing squeeze with iceape 2.0, iceweasel
> > 3.5 and icedove 3.0 is the best course of action.
> 
> Is this really the best move? With Firefox 4 due the end of the year,
> and 3.6 will be a year old already, the security team will be supporting
> 3.5 after Mozilla stops it's support. Same might be the case with
> Icedove 3.0.

Choosing between 3.5 and 3.6 on that alone is not enough.
As I said, Mozilla will also stop supporting 3.6 way before squeeze
security support ends.

Mike


-- 
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/20100628115428.ga18...@glandium.org

Re: Improve support for installing 32-bit libraries on 64-bit systems

[David Kalnischkies]

2010/6/26 Luca Bruno :
> David Kalnischkies scrisse:
>> The biggest showstoppers are as far as i know that
>> a) dpkg doesn't support it
>> b) APT doesn't support it
>> c) (not many) packages use it (last time i check ~24)
>>
>> c) is likely caused by a) and b) which in fact decreases the
>> motivation for a) and b) to implement it as nobody use it… ***
>> dependency loop detected ***
>
> Goswin recently offered some help to improve the situation regarding a)
> and c) points, but I've seen no (public) answer from you:
> http://lists.debian.org/debian-devel/2010/04/msg00493.html

What should i have answered? That i like that he wants to work
on a) and c)? I knew that as we exchanged a few mails already
as he is also present on deity@ and the associated bugreports,
so my only semi-public move as response to this mail was to join
the recommend list and proceed in doing "stuff" rather than writing
the obvious… especially as i was not a (direct) addressee of the mail
and got it a bit later than usual.

I can't comment on a) as dpkg is magic (for me at least) and the problem
for dpkg is more about reference counting for /usr/share/doc files than
dependency solving as far as i understand and should as it is promised be
done by someone who know his stuff. It might need to do something similar
to what i did in APT with creating pseudo-archdepending packages for
arch:all packages to "simplify" dependency solving, for their dependency
checking but that depends on their liking, isn't limited by compatibility
requirements like it is in APT - and the theory is documented in
README.MultiArch and code in case i am hit by a bus,
so as long as nobody has (further) questions - nothing to comment…
c) is also not my cup of tea so far as i never touched a library by now,
starting to tell libary maintainers they should do this and that is at least
in my understanding a bit awkward then. (This avoids also a bit pre-seeding
everyone with my understanding.) ;)


> Given that you say apt in experimental is semi-working, it would be
> interesting to join forces and see if something almost test-able can
> be provided.

Semi working as (obviously) nothing can be really installed as dpkg
will jump at you if you try. Semi working also as i focused mostly
on the case until now that you have e.g. i386 and amd64 packages
available but have only packages from one arch installed
(fun-fact: It is i386 for me as i have no amd64 system currently).
Requesting to install one or two packages from the other arch will be
the most seen use case and this works so far, but only with simple
constructed cases as in real world you will be hit by c) - i see that
positive as this at least guarantees that APT isn't too relaxed about
the dependencies. ;)
The ABI changes for it are quite stable and i am especially happy that
they are API compatible to the SingleArch-epoch.
The APT part left is beside bughunting really the (important) MultiArch
"auxiliary" stuff i described in the proposal.


> If so, it would also be useful to advertise it a bit more and hoping to
> gain some momentum...

While many would certainly love it, i don't feel like rushing into a mess.
We already saw some tries to implement a semi-multiarch behavior
and personally i don't want to see them again. Do it once, clean and
for real - and at best not before squeeze freeze or even release:

It requires a lot of changes to work correctly in a lot of packages and
mindsets and would be currently a waste of time which could better be
spent in (rc-)bugs and ongoing or waiting transitions.

(At least in the eyes of my mentor and myself. Big bangs after releases
generally generate more (positive) noise than near freeze time)

And most of the auxiliary stuff has the advantage to be not only "needed"
for MultiArch, but fixes a lot of bugs in drive-by mode.
Thankfully APT has still so many of them to choose from. ;)


Best regards,

David Kalnischkies


--
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/aanlktiklo0ach_m9lqo0ekxxxfnudepm6vdk_cyrc...@mail.gmail.com

Re: xulrunner 1.9.2 into sid?

[Ron Johnson]

On 06/28/2010 06:54 AM, Mike Hommey wrote:

On Mon, Jun 28, 2010 at 05:36:11AM -0600, Aaron Toponce wrote:

[snip]

Second, for the reasons given earlier, releasing with iceweasel 3.6 and
icedove 3.1 would mean to avoid releasing with iceape 2.0. This may not
be a huge problem, as we already didn't release lenny with iceape, but
see below.


Iceape is a beautiful piece of software, and I have run it in the past.
But market share shows that Seamonkey/Iceape users are the minority,
with Firefox/Iceweasel and Thunderbird/Icedove the vast majority.
Releasing Lenny without Iceape was the best move, IMO.


If Debian accounted for market share, it would dump a whole lot of
packages. There are a lot of packages with less users than iceape.



When you've got limited resources, you must make hard decisions.

One of those decisions is whether to help a lot of people at the 
expense of a few, or the few at the expense of the lot.


Quoting Aristotle: "Even supposing the chief good to be eventually 
the aim for the individual as for the state, that of the state is 
evidently of greater and more fundamental importance both to attain 
and to preserve. The securing of one individual's good is cause for 
rejoicing, but to secure the good of a nation or of a city-state is 
nobler and more divine."


Quoting Spock: "Were I to invoke logic, however, logic clearly 
dictates that the needs of the many outweigh the needs of the few."


--
Seek truth from facts.


--
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/4c289659.60...@cox.net

Re: xulrunner 1.9.2 into sid?

[Marco d'Itri]

On Jun 28, PICCA Frédéric-Emmanuel 
 wrote:

> Do you have an entry explaining how to create from scratch a symbol file for 
> a given library ?

You add "dh_makeshlibs -- -c4" to debian/rules and then edit the diff in
the error message.
Do not forget to remove the old .shlibs file.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: xulrunner 1.9.2 into sid?

[Vincent Danjean]

On 28/06/2010 14:29, Marco d'Itri wrote:
> On Jun 28, PICCA Frédéric-Emmanuel 
>  wrote:
> 
>> Do you have an entry explaining how to create from scratch a symbol file for 
>> a given library ?
> 
> You add "dh_makeshlibs -- -c4" to debian/rules and then edit the diff in
> the error message.

You can also create an empty symbol file and look at/apply the "diff"
in the build log. This is what I do.

> Do not forget to remove the old .shlibs file.

  Regards,
Vincent

-- 
Vincent Danjean   GPG key ID 0x9D025E87 vdanj...@debian.org
GPG key fingerprint: FC95 08A6 854D DB48 4B9A  8A94 0BF7 7867 9D02 5E87
Unofficial packages: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://perso.debian.org/~vdanjean/debian unstable main


-- 
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/4c28a8f1.8080...@free.fr

Re: RE : xulrunner 1.9.2 into sid?

[Didier 'OdyX' Raboud]

PICCA Frédéric-Emmanuel wrote:

> Do you have an entry explaining how to create from scratch a symbol file
> for a given library ?
> 
> I could not find this information on the debian wiki.
> 
> thanks
> 
> Frederic

Hi, 

$ man dpkg-gensymbols

aka

$ dpkg-gensymbols -plibfoo -v0.1.2 -Odebian/libfoo.symbols.$arch 

Then, for a c++ library, some sed, c++filt, etc. can give you a "multi-arch" 
symbols file.

Cheers,
OdyX


-- 
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/i0aa9n$ct...@dough.gmane.org

Re: xulrunner 1.9.2 into sid?

[Micah Gersten]

On 06/28/2010 03:38 AM, Steffen Möller wrote:
> Hello,
> 
> On 06/27/2010 04:25 PM, Aaron Toponce wrote:
>> Seeing as though upstream Firefox 3.6 released December 1, 2008, and
>> upstream Thunderbird 3.1 released just a couple days ago, it might be
>> high time to get xulrunner 1.9.2 into Sid, as both Iceweasel 3.6 and
>> Icedove 3.1 will depend on it. However, I hear there will be lots of
>> breakage if xulrunner 1.9.2 comes into Sid. If so, what will break?
>> Further, what can I do to help?
>>   
> It cannot be that bad, I am running it on my desktop with Maverick.
> ii  xulrunner-1.9.2 1.9.2.4+build7+nobinonly-0u XUL + XPCOM
> application runner
> 
> It is already in experimental
> http://packages.debian.org/search?searchon=sourcenames&keywords=xulrunner
> maybe you can just install it and report back to the maintainers?
> 
> Thanks and regards
> 
> Steffen
>

Well, Ubuntu started the transition in Lucid and it's not entirely
completed yet.  We still have a handful of sources that we cannot
rebuild due to the transition.  There are also a few broken applications
that we still have to patch.  In addition, we had to drop most of the
extensions from the archive and a few less popular applications that
were built on xulrunner.  Also, Ubuntu does not have the resources to
backport security fixes for EOL gecko versions.  That was the main push
to have xulrunner-1.9.2 in Lucid (3 yr desktop support).  Since Debian
is committed to providing backported security fixes for EOL versions and
the greater number of packages involved, I think what Mike Hommey said
before is the way to go for Squeeze and sid.

Micah Gersten
Ubuntu Mozilla Team Member


-- 
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/4c28ae1c.3050...@ubuntu.com

Bug#587422: ITP: ferret-viz -- Interactive data visualization and analysis environment, for gridded and non-gridded climate data

[Alastair McKinstry]

Package: wnpp
Severity: wishlist
Owner: Alastair McKinstry 

* Package name: ferret-viz
  Version : 6.2
  Upstream Author : NOAA 
* URL : http://ferret.pmel.noaa.gov/Ferret/home
* License : Public Domain / 
  Programming Lang: Fortran
  Description : Interactive data visualization and analysis environment, 
for gridded and non-gridded climate data

Ferret is an interactive computer visualization and analysis environment 
designed to meet the needs of oceanographers and meteorologists analyzing 
large and complex gridded data sets. It runs on most Unix systems, and on 
Windows XP/NT/9x using X windows for display. It can transparently access 
extensive remote Internet data bases using OPeNDAP (formerly known as DODS); 
see http://www.unidata.ucar.edu/packages/dods/.

Ferret was developed by the Thermal Modeling and Analysis Project (TMAP) at 
PMEL in Seattle to analyze the outputs of its numerical ocean models and 
compare them with gridded, observational data. The model data sets are 
generally multi-gigabyte in size with mixed 3 and 4-dimensional variables 
defined on staggered grids. Ferret offers a Mathematica-like approach to 
analysis; new variables may be defined interactively as mathematical 
expressions involving data set variables. Calculations may be applied over 
arbitrarily shaped regions. Fully documented graphics are produced with a 
single command.

Many excellent software packages have been developed recently for scientific 
visualization. The features that make Ferret distinctive among these 
packages are Mathematica-like flexibility, geophysical formatting, 
"intelligent" connection to its data base, memory management for very large 
calculations, and symmetrical processing in 4 dimensions.

Ferret is widely used in the oceanographic community to analyze data and create 
publication quality graphics. We have compiled an (incomplete) list of 
publications where the authors felt that the contribution of Ferret was 
sufficient to warrant an acknowledgment. We appreciate your acknowledgment of 
Ferret in your publications.

-- System Information:
Debian Release: 5.0.4
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: powerpc (ppc)



-- 
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/20100628143745.27638.34979.report...@ailm.sceal.ie

Re: xulrunner 1.9.2 into sid?

[Mike Hommey]

On Mon, Jun 28, 2010 at 02:29:54PM +0200, Marco d'Itri wrote:
> On Jun 28, PICCA Frédéric-Emmanuel 
>  wrote:
> 
> > Do you have an entry explaining how to create from scratch a symbol file 
> > for a given library ?
> 
> You add "dh_makeshlibs -- -c4" to debian/rules and then edit the diff in
> the error message.
> Do not forget to remove the old .shlibs file.

While that's enough to be useful for next versions, it's certainly not
to be useful to relax current dependencies in unstable. Using the
various files from mole[1] should be used as a base template, though the
versioning given by mole is wrong (the symbols file it gives contain the
debian revisions while they shouldn't)

Mike

1. http://qa.debian.org/cgi-bin/mole/seedsymbols


-- 
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/20100628145812.gb29...@glandium.org

all twitter client should support OAuth before they will drop Basic Auth in August

[Hideki Yamane]

Hi,

 As I reported in Bug#587420, all twitter client should support OAuth since 
twitter
 will discard basic auth. If they not, we should drop them from Squeeze release.

 These lists are assumed to be affected packages (got with "apt-cache search 
twitter").


bisho: ? does it need?? (meego)
bti: not yet?
choqok: needs update. It should be newer than 0.9.80 (Bug#587420)
gtwitter: not yet?
gwibber: not yet, see https://bugs.launchpad.net/gwibber/+bug/381133
libmojito0: ? does it need?? (meego)
libnet-twitter-lite-perl: OK
libnet-twitter-perl: OK
libsocialweb0: ? does it need?? (meego)
libtwitter-glib-1.0-0: not yet?
libtwitter-ruby1.8: not yet?
libtwitter-ruby1.9.1: not yet?
pidgin-microblog: OK
python-twitter: not yet, see
http://code.google.com/p/python-twitter/issues/detail?id=65
python-twyt: not yet?
qwit: needs update. It should be newer than 1.1-beta.
tircd: OK, see http://code.google.com/p/tircd/issues/detail?id=72&can=1&q=oauth
twitux: not yet?
smuxi-engine-twitter: not yet, see http://projects.qnetp.net/issues/show/368


 Any comments are welcome. Thanks.


-- 
Regards,

 Hideki Yamane henrich @ debian.or.jp/org
 http://wiki.debian.org/HidekiYamane


-- 
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/20100628234007.3662897f.henr...@debian.or.jp

Re: [DRAFT] Policy for Linux kernel, initramfs, boot loader update process

[Stephen Powell]

I took the liberty of adding debian-boot and debian-s390 to the CC
list on this e-mail, since it affects the Debian installer and
the s390-tools package, which contains the zipl boot loader, which
has a design very similar to that of lilo.  If this results in some people
getting more than one copy of this e-mail, please accept my apologies; but
I figured it was better to err on the side of caution in this case.
I also added Joachim Wiedorn, the new lilo upstream maintainer (who
also happens to be the Debian package maintainer for backup2l).

On Sun, 27 Jun 2010 22:02:35 -0400 (EDT), Ben Hutchings wrote:
> 
> I propose the following policy for squeeze and later releases.  This
> affects all Linux kernel, initramfs builder and boot loader packages,
> and the installer.
> 
> I regret that this is happening so late in the release cycle, but
> currently a kernel update can easily leave the system unbootable and
> this does need to be addressed before release and I want to do so in a
> way that is reasonably clean and maintainable.
> 
> ---
> 1. Packages for boot loaders that need to be updated whenever the files
> they load are modified (i.e. those that store a block list) must install
> hook scripts in /etc/kernel/postinst.d and /etc/kernel/postrm.d, which
> will be called on installation/upgrade and removal of kernel packages,
> respectively.
> 
> The arguments given to all kernel hook scripts are the kernel ABI
> version (the string that uname -r reports) and the absolute path to the
> kernel image.

Currently, hook scripts invoked by a stock kernel maintainer script
or a maintainer script from a kernel image package created by make-kpkg
pass these exact same arguments.  But a maintainer script for a kernel
image package created by "make deb-pkg" passes only the first argument.
Existing hook scripts rely on that difference to determine whether or
not to take action.  For example, the initramfs hook script provided by
the initramfs-tools package tests the number of arguments and exits
without doing anything if more than one argument is supplied.  In other
words, this hook script is designed to create the initial RAM file system
for a kernel image created by "make deb-pkg", and only for a kernel
image created by "make deb-pkg".  It does nothing otherwise.  Are you
proposing to change this behavior?

> The environment variable DEB_MAINT_PARAMS will contain
> the arguments given to the kernel maintainer script, single-quoted.

Is this environment variable provided by the maintainer scripts
that come with kernel image packages created by "make deb-pkg"?
(I honestly don't know.  I've never used "make deb-pkg".)

> 
> Since these boot loaders should be updated as the last step during
> installation/upgrade and removal, hook scripts for boot loaders must be
> named using the prefix 'zz-' and no other packages may use this prefix
> or one that sorts later by the rules used by run-parts.  A postrm hook
> script should warn but exit with code 0 if the boot loader configuration
> file still refers to the kernel image that has been removed.
> 
> 2. Packages for boot loaders that need to be updated whenever the files
> they load are modified must also install hook scripts in
> /etc/mkinitramfs/post-update.d.  Initramfs builders must call these
> scripts using run-parts after they create, update or delete an
> initramfs.  The arguments given to these hook scripts are the kernel ABI
> version and the absolute path to the initramfs image.
> 
> 3. Initramfs builders must complete their work before returning from the
> kernel postinst hook script.  [initramfs-tools currently uses a trigger
> to defer this because it can also be invoked twice, but this means it
> also has to know how to update specific boot loaders.]
> 
> 4. During a kernel package installation, upgrade or removal, various
> boot loader hooks may be invoked (in this order):
> 
> a. A postinst_hook or postrm_hook command set by the user or the
>installer in /etc/kernel-img.conf
> b. A hook script in /etc/mkinitramfs/post-update.d
> c. A hook script in /etc/kernel/postinst.d or .../postrm.d
> 
> To avoid unnecessary updates, the hooks invoked at step a and b may
> check whether $DPKG_MAINTSCRIPT_PACKAGE begins with 'linux-image-' and
> do nothing in this case.  [Is this sensible or is it too 'clever'?]
> 
> 5. Kernel and initramfs builder packages must not invoke boot loaders
> except via hooks.  If /etc/kernel-img.conf contains an explicit
> 'do_bootloader = yes', kernel package maintainer scripts should warn
> that this is now ignored.

At the risk of flogging a dead horse, I would prefer to see
"do_bootloader = yes" supported until Squeeze+1, both by the
kernel maintainer scripts and by "update-initramfs -u", particularly
since we are so close to a freeze.  But if
you're going to drop support for it in Squeeze, then yes,
a warning message is necessary.  Both the kernel maintainer scripts
*and* "update-initramfs -u" *must* issue a warning message if they
fi

Re: all twitter client should support OAuth before they will drop Basic Auth in August

[Sune Vuorela]

On 2010-06-28, Hideki Yamane  wrote:
> Hi,
>
>  As I reported in Bug#587420, all twitter client should support OAuth since 
> twitter
>  will discard basic auth. If they not, we should drop them from Squeeze 
> release.
>
>  These lists are assumed to be affected packages (got with "apt-cache search 
> twitter").
>
> 
> bisho: ? does it need?? (meego)
> bti: not yet?
> choqok: needs update. It should be newer than 0.9.80 (Bug#587420)
> gtwitter: not yet?
> gwibber: not yet, see https://bugs.launchpad.net/gwibber/+bug/381133
> libmojito0: ? does it need?? (meego)
> libnet-twitter-lite-perl: OK
> libnet-twitter-perl: OK
> libsocialweb0: ? does it need?? (meego)
> libtwitter-glib-1.0-0: not yet?
> libtwitter-ruby1.8: not yet?
> libtwitter-ruby1.9.1: not yet?
> pidgin-microblog: OK
> python-twitter: not yet, see
> http://code.google.com/p/python-twitter/issues/detail?id=65
> python-twyt: not yet?
> qwit: needs update. It should be newer than 1.1-beta.
> tircd: OK, see 
> http://code.google.com/p/tircd/issues/detail?id=72&can=1&q=oauth
> twitux: not yet?
> smuxi-engine-twitter: not yet, see http://projects.qnetp.net/issues/show/368

plasma-widgets-addons (microblog widget)

/Sune


-- 
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/slrni2hfmm.rvp.nos...@sshway.ssh.pusling.com

Re: all twitter client should support OAuth before they will drop Basic Auth in August

[Carlos Galisteo]

On Mon, Jun 28, 2010 at 4:40 PM, Hideki Yamane  wrote:
> qwit: needs update. It should be newer than 1.1-beta.

 Waiting for qoauth [1].

> Any comments are welcome. Thanks.

Please, notice that oauth may imply some issues about distributing
application secret tokens [2]. Upstream and maintainers should be
aware of it and try to implement the better possible solution.


Thanks.

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=537247
[2] 
http://groups.google.com/group/twitter-development-talk/browse_thread/thread/c18ade9d86c8b239#




-- 
---
Carlos Galisteo 
GPG key :0x8E0076E9:
Fingerprint: 939E 3D10 EAA2 A972 3AF2  E25C 26B7 D8E3 8E00 76E9
---


-- 
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/aanlktikdeqz-rnfof7-dn7jddymn5j9ufta0n0w-g...@mail.gmail.com

Re: all twitter client should support OAuth before they will drop Basic Auth in August

[Joachim Breitner]

Hi,

Am Montag, den 28.06.2010, 23:40 +0900 schrieb Hideki Yamane:
>  As I reported in Bug#587420, all twitter client should support OAuth since 
> twitter
>  will discard basic auth. If they not, we should drop them from Squeeze 
> release.
> 
>  These lists are assumed to be affected packages (got with "apt-cache search 
> twitter").
> 
> 
> bisho: ? does it need?? (meego)
> bti: not yet?
> choqok: needs update. It should be newer than 0.9.80 (Bug#587420)
> gtwitter: not yet?
> gwibber: not yet, see https://bugs.launchpad.net/gwibber/+bug/381133
> libmojito0: ? does it need?? (meego)
> libnet-twitter-lite-perl: OK
> libnet-twitter-perl: OK
> libsocialweb0: ? does it need?? (meego)
> libtwitter-glib-1.0-0: not yet?
> libtwitter-ruby1.8: not yet?
> libtwitter-ruby1.9.1: not yet?
> pidgin-microblog: OK
> python-twitter: not yet, see
> http://code.google.com/p/python-twitter/issues/detail?id=65
> python-twyt: not yet?
> qwit: needs update. It should be newer than 1.1-beta.
> tircd: OK, see 
> http://code.google.com/p/tircd/issues/detail?id=72&can=1&q=oauth
> twitux: not yet?
> smuxi-engine-twitter: not yet, see http://projects.qnetp.net/issues/show/368

twidge: Probably OK (depends on haskell-hoauth)

Greetings,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


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

Re: xulrunner 1.9.2 into sid?

[Olivier Bonvalet]

Le 28/06/2010 11:35, Marco d'Itri a écrit :

On Jun 28, Mike Hommey  wrote:

   

Unfortunately, as xpcom is guaranteed forward compatible but not
backwards compatible, some plugins and extensions, once built against
xulrunner 1.9.2, are likely to not work in iceape 2.0 anymore. This
would leave iceape users with a bitter aftertaste. Alternatively,
 

And how would this be worse than shipping a version of iceweasel which
is already obsolete? Who actually cares about iceape?
If there is no manpower to do better than this then I feel that it would
be more honest to just use volatile.

FWIW, I have been using iceweasel 3.6 since it has been uploaded and it
works *much* better than 3.5 did, which was slow and crashed a lot.

   
I agree : on 64bit systems Iceweasel 3.5 is way too slow, and Iceweasel 
3.6 should be included in Squeeze.
For Icedove 3.0, it's a beta no ? I would prefer Icedove 2.0 or Icedove 
3.1 in Squeeze, but really not Icedove 3.0.


Have this packages in unstable or testing is not a huge problem, but do 
not release that in stable please !


Of course I'm ok to give some help to avoid that... if I can be usefull.

Olivier B.


--
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/4c28c5fc@daevel.fr

Re: [DRAFT] Policy for Linux kernel, initramfs, boot loader update process

[Joachim Wiedorn]

Hello William,

perhaps you have read the recent email from Ben (see below). It would be
important to update the lilo package to support these recent requirements
to prepare LILO for Squeeze before it will get stable.

Do you have the intention to update the lilo package to integrate some
scripts for these recent requirements?

Have a nice day,

Joachim (Germany)

---

Ben Hutchings  wrote on 2010-06-28 03:02:

> I propose the following policy for squeeze and later releases.  This
> affects all Linux kernel, initramfs builder and boot loader packages,
> and the installer.
> 
> I regret that this is happening so late in the release cycle, but
> currently a kernel update can easily leave the system unbootable and
> this does need to be addressed before release and I want to do so in a
> way that is reasonably clean and maintainable.
> 
> ---
> 1. Packages for boot loaders that need to be updated whenever the files
> they load are modified (i.e. those that store a block list) must install
> hook scripts in /etc/kernel/postinst.d and /etc/kernel/postrm.d, which
> will be called on installation/upgrade and removal of kernel packages,
> respectively.
> 
> The arguments given to all kernel hook scripts are the kernel ABI
> version (the string that uname -r reports) and the absolute path to the
> kernel image.  The environment variable DEB_MAINT_PARAMS will contain
> the arguments given to the kernel maintainer script, single-quoted.
> 
> Since these boot loaders should be updated as the last step during
> installation/upgrade and removal, hook scripts for boot loaders must be
> named using the prefix 'zz-' and no other packages may use this prefix
> or one that sorts later by the rules used by run-parts.  A postrm hook
> script should warn but exit with code 0 if the boot loader configuration
> file still refers to the kernel image that has been removed.
> 
> 2. Packages for boot loaders that need to be updated whenever the files
> they load are modified must also install hook scripts in
> /etc/mkinitramfs/post-update.d.  Initramfs builders must call these
> scripts using run-parts after they create, update or delete an
> initramfs.  The arguments given to these hook scripts are the kernel ABI
> version and the absolute path to the initramfs image.
> 
> 3. Initramfs builders must complete their work before returning from the
> kernel postinst hook script.  [initramfs-tools currently uses a trigger
> to defer this because it can also be invoked twice, but this means it
> also has to know how to update specific boot loaders.]
> 
> 4. During a kernel package installation, upgrade or removal, various
> boot loader hooks may be invoked (in this order):
> 
> a. A postinst_hook or postrm_hook command set by the user or the
>installer in /etc/kernel-img.conf
> b. A hook script in /etc/mkinitramfs/post-update.d
> c. A hook script in /etc/kernel/postinst.d or .../postrm.d
> 
> To avoid unnecessary updates, the hooks invoked at step a and b may
> check whether $DPKG_MAINTSCRIPT_PACKAGE begins with 'linux-image-' and
> do nothing in this case.  [Is this sensible or is it too 'clever'?]
> 
> 5. Kernel and initramfs builder packages must not invoke boot loaders
> except via hooks.  If /etc/kernel-img.conf contains an explicit
> 'do_bootloader = yes', kernel package maintainer scripts should warn
> that this is now ignored.
> 
> 6. The installer must not define do_bootloader, postinst_hook or
> postrm_hook in /etc/kernel-img.conf.
> ---
> 
> I'm particularly interested to hear whether there are any upgrade issues
> I have not addressed.
> 
> Ben.
> 


signature.asc
Description: PGP signature

Re: [DRAFT] Policy for Linux kernel, initramfs, boot loader update process

[maximilian attems]

On Mon, Jun 28, 2010 at 11:16:58AM -0400, Stephen Powell wrote:
> > ---
> > 1. Packages for boot loaders that need to be updated whenever the files
> > they load are modified (i.e. those that store a block list) must install
> > hook scripts in /etc/kernel/postinst.d and /etc/kernel/postrm.d, which
> > will be called on installation/upgrade and removal of kernel packages,
> > respectively.
> > 
> > The arguments given to all kernel hook scripts are the kernel ABI
> > version (the string that uname -r reports) and the absolute path to the
> > kernel image.
> 
> Currently, hook scripts invoked by a stock kernel maintainer script
> or a maintainer script from a kernel image package created by make-kpkg
> pass these exact same arguments.

no.

> But a maintainer script for a kernel
> image package created by "make deb-pkg" passes only the first argument.

no.

> Existing hook scripts rely on that difference to determine whether or
> not to take action.  For example, the initramfs hook script provided by
> the initramfs-tools package tests the number of arguments and exits
> without doing anything if more than one argument is supplied.  In other
> words, this hook script is designed to create the initial RAM file system
> for a kernel image created by "make deb-pkg", and only for a kernel
> image created by "make deb-pkg".  It does nothing otherwise.  Are you
> proposing to change this behavior?

please get your facts right before spamming the world.

kthxbye.


-- 
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/20100628164510.gb9...@baikonur.stro.at

Re: all twitter client should support OAuth before they will drop Basic Auth in August

[Luk Claes]

On 06/28/2010 04:40 PM, Hideki Yamane wrote:
> Hi,
> 
>  As I reported in Bug#587420, all twitter client should support OAuth since 
> twitter
>  will discard basic auth. If they not, we should drop them from Squeeze 
> release.

Will they also not be usable anymore with identi.ca and similar twitter
like services? If not, there is no reason to have them dropped AFAICS.
It would be better to have them support both authentication mechansisms
though.

Cheers

Luk

PS: I don't get why they abandon a proven standard that everyone knows.


-- 
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/4c28da30.6050...@debian.org

Bug#587446: RFP: cutycapt -- a small command-line utility to capture WebKit's rendering of a web page

[Riccardo Magliocchetti]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

--- Please fill out the fields below. ---

   Package name: cutycapt
Version: svn
Upstream Author: Bjoern Hoehrmann 
URL: http://cutycapt.sourceforge.net/
License: GPLv2+
Description: a small command-line utility to capture WebKit's 
rendering of a web page
 CutyCapt is a small cross-platform command-line utility to capture 
WebKit's rendering of a web page into a variety of vector and bitmap 
formats, including SVG, PDF, PS, PNG, JPEG, TIFF, GIF, and BMP.



Some work done in the past, last update more than one year ago here
http://oss.alea-soluciones.com/trac/browser/debian/cutycapt/

--
Riccardo Magliocchetti



--
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/4c28dc8c.4020...@gmail.com

Re: xulrunner 1.9.2 into sid?

[Kelly Clowers]

On Mon, Jun 28, 2010 at 02:35, Marco d'Itri  wrote:
> On Jun 28, Mike Hommey  wrote:
>
>> Unfortunately, as xpcom is guaranteed forward compatible but not
>> backwards compatible, some plugins and extensions, once built against
>> xulrunner 1.9.2, are likely to not work in iceape 2.0 anymore. This
>> would leave iceape users with a bitter aftertaste. Alternatively,
> And how would this be worse than shipping a version of iceweasel which
> is already obsolete? Who actually cares about iceape?

I would say I care, but I use Mozilla nightlies straight from ftp.mozilla.org...
But if current stable doesn't have iceape, anyone on stable that wants it
must be doing something else anyway, so I'm not sure it's that big a deal.


Cheers,
Kelly Clowers


-- 
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/aanlktili6xjjh5ckitbdcdj3hipmnvo8r37bjynto...@mail.gmail.com

Re: [DRAFT] Policy for Linux kernel, initramfs, boot loader update process

[Stephen Powell]

On Mon, 28 Jun 2010 12:45:10 -0400 (EDT), maximilian attems wrote:
> On Mon, 28 Jun 2010 03:02:35 +0100 Ben Hutchings wrote:
>> The arguments given to all kernel hook scripts are the kernel ABI
>> version (the string that uname -r reports) and the absolute path to the
>> kernel image.
> On Mon, Jun 28, 2010 at 11:16:58AM -0400, Stephen Powell wrote:
>> Currently, hook scripts invoked by a stock kernel maintainer script
>> or a maintainer script from a kernel image package created by make-kpkg
>> pass these exact same arguments.
> 
> no.

>From a Squeeze system running a custom kernel created by make-kpkg:

-

debian3:~# dpkg-reconfigure linux-image-2.6.32-custom5b-s390x
Running depmod.
Examining /etc/kernel/postinst.d.
run-parts: executing /etc/kernel/postinst.d/S30initramfs 2.6.32-custom5b-s390x 
/boot/vmlinuz-2.6.32-custom5b-s390x
 ^ ^
 +-- 1st argument  
+-- 2nd argument
  
-

>From a Squeeze system running a stock kernel image:

-

r...@testdebian:~# dpkg-reconfigure linux-image-2.6.32-3-686
Running depmod.
Running update-initramfs: Generating /boot/initrd.img-2.6.32-3-686
Examining /etc/kernel/postinst.d.
run-parts: executing /etc/kernel/postinst.d/S30initramfs 2.6.32-3-686 
/boot/vmlinuz-2.6.32-3-686
 ^^
 |+-- 2nd 
argument
 +-- 1st argument

-

Q.E.D.

> On Mon, Jun 28, 2010 at 11:16:58AM -0400, Stephen Powell wrote:
>> But a maintainer script for a kernel
>> image package created by "make deb-pkg" passes only the first argument.
> 
> no.

The actual text of /etc/kernel/postinst.d/initramfs-tools:

-

#!/bin/sh

version="$1"
bootopt=""

# passing the kernel version is required
[ -z "${version}" ] && exit 0

# kernel-package passes an extra arg
if [ -n "$2" ]; then
if [ -n "${KERNEL_PACKAGE_VERSION}" ]; then
bootdir=$(dirname "$2")
bootopt="-b ${bootdir}"
else
# official Debian linux-images take care themself
exit 0
fi
fi

# avoid running multiple times
if [ -n "$DEB_MAINT_PARAMS" ]; then
eval set -- "$DEB_MAINT_PARAMS"
if [ -z "$1" ] || [ "$1" != "configure" ]; then
exit 0
fi
fi

# we're good - create initramfs.  update runs do_bootloader
update-initramfs -c -t -k "${version}" ${bootopt}

-

I admit that I have never personally used "make deb-pkg", but
clearly the source code speaks for itself.  This hook script is
expecting only one argument when invoked by "make deb-pkg".

Q.E.D.

> On Mon, Jun 28, 2010 at 11:16:58AM -0400, Stephen Powell wrote: 
>> Existing hook scripts rely on that difference to determine whether or
>> not to take action.  For example, the initramfs hook script provided by
>> the initramfs-tools package tests the number of arguments and exits
>> without doing anything if more than one argument is supplied.  In other
>> words, this hook script is designed to create the initial RAM file system
>> for a kernel image created by "make deb-pkg", and only for a kernel
>> image created by "make deb-pkg".  It does nothing otherwise.  Are you
>> proposing to change this behavior?
> 
> please get your facts right before spamming the world.

OK, you're partly right on this one.  Execution tracing shows that it
does nothing when invoked by a stock kernel maintainer script but
does create an initial RAM file system when invoked by a maintainer
script from a kernel image package created by make-kpkg.  (By the way,
since this script is running under debconf, output from update-initramfs
should be redirected to standard error via ">&2".)  I don't remember the
kernel-package logic being present in this script the last time I looked
at it.

(1) As far as I am able to determine, my original statements are correct,
with the exception of the correction made in the above paragraph.
If you can prove me wrong, please do so.
(2) This was not spam.  Spam is unsolicited advertising.
This was a response to an RFC, to which I was explicitly
included as an adressee.
(3) All the addressees of my e-mail were legitimate stake-holders
in this process.  This is not "the world".

-- 
  .''`. Stephen Powell
 : :'  :
 `. `'`
   `-


-- 
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/1137353821.16101.1277752206454.javamail.r...@md01.wow.synacor.com

Re: Policy 3.9.0.0 released

[Carl Fürstenberg]

On Mon, Jun 28, 2010 at 19:20, Russ Allbery  wrote:
>     perl
>          `perl-base' now provides `perlapi-' instead of a package
>          based solely on the Perl version.  Perl packages must now depend
>          on `perlapi-$Config{debian_abi}', falling back on
>          `$Config{version}' if `$Config{debian_abi}' is not set.


Might be relevant to point out that dh_perl and ${perl:Depends} should
take care of this, so for most it shouldn't be an issue.

-- 
/Carl Fürstenberg 


--
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/aanlktimvph5mlz74xntsvnqmc4ld70fh0emikb5h2...@mail.gmail.com

Bug#587467: ITP: audacious-analog-vumeter-plugin_1.0.0~rc1-1_i386.deb -- VU meter plugin for xmms and audacious

[Antonino Arcudi]

Package: wnpp
Severity: wishlist
Owner: Antonino Arcudi 


* Package name: audacious-analog-vumeter-plugin_1.0.0~rc1-1_i386.deb
  Version : 1.0.0~rc1-1
  Upstream Author : Name Pekka Harjamäki, mcf...@users.sourceforge.net
* URL : http://sourceforge.net/projects/vumeterplugin/
* License : (GPL)
  Programming Lang: (C)
  Description : VU meter plugin for xmms and audacious



-- 
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/20100628212131.16301.99540.report...@njordr.lan

Bug#587468: ITP: audacious-analog-vumeter-plugin_1.0.0~rc1-1_i386.deb -- VU meter plugin for xmms and audacious

[Antonino Arcudi]

Package: wnpp
Severity: wishlist
Owner: Antonino Arcudi 


* Package name: audacious-analog-vumeter-plugin_1.0.0~rc1-1_i386.deb
  Version : 1.0.0-rc1
  Upstream Author : Pekka Harjamäki, mcf...@users.sourceforge.net
* URL : http://sourceforge.net/projects/vumeterplugin/
* License : (GPL)
  Programming Lang: (C)
  Description : VU meter plugin for xmms and audacious



-- 
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/20100628212732.17034.91342.report...@njordr.lan

Re: xulrunner 1.9.2 into sid?

[Yves-Alexis Perez]

On lun., 2010-06-28 at 17:55 +0200, Olivier Bonvalet wrote:
> I agree : on 64bit systems Iceweasel 3.5 is way too slow, and Iceweasel 
> 3.6 should be included in Squeeze. 

Thank you for volunteering, I'm sure Mike will take all the help you'll
give.
-- 
Yves-Alexis


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

Re: [DRAFT] Policy for Linux kernel, initramfs, boot loader update process

[Colin Watson]

On Mon, Jun 28, 2010 at 03:02:35AM +0100, Ben Hutchings wrote:
> 1. Packages for boot loaders that need to be updated whenever the files
> they load are modified (i.e. those that store a block list) must install
> hook scripts in /etc/kernel/postinst.d and /etc/kernel/postrm.d, which
> will be called on installation/upgrade and removal of kernel packages,
> respectively.

It seems to me (particularly from the fact that you upgraded a grub2 bug
report about this to important - GRUB 2 does not store block lists for
kernels) that this is not limited to boot loaders that store block lists
for the files they load: it also affects boot loaders that need to be
updated whenever the *list* of files they load is modified.  Can you
confirm that my understanding is correct?

> 2. Packages for boot loaders that need to be updated whenever the files
> they load are modified must also install hook scripts in
> /etc/mkinitramfs/post-update.d.  Initramfs builders must call these
> scripts using run-parts after they create, update or delete an
> initramfs.  The arguments given to these hook scripts are the kernel ABI
> version and the absolute path to the initramfs image.

Does the same apply here, or not?  This is going to be quite a lot of
calls to update-grub if so, although at least it's quite a bit faster
now than it used to be ...

> 3. Initramfs builders must complete their work before returning from the
> kernel postinst hook script.  [initramfs-tools currently uses a trigger
> to defer this because it can also be invoked twice, but this means it
> also has to know how to update specific boot loaders.]

Is an initramfs guaranteed to be built before any of the boot loader
hooks are executed?  It seems like a waste of time calling boot loader
hooks otherwise.  (This may be implied by your design, but it was a
little bit implicit if so.)

> 4. During a kernel package installation, upgrade or removal, various
> boot loader hooks may be invoked (in this order):
> 
> a. A postinst_hook or postrm_hook command set by the user or the
>installer in /etc/kernel-img.conf
> b. A hook script in /etc/mkinitramfs/post-update.d
> c. A hook script in /etc/kernel/postinst.d or .../postrm.d
> 
> To avoid unnecessary updates, the hooks invoked at step a and b may
> check whether $DPKG_MAINTSCRIPT_PACKAGE begins with 'linux-image-' and
> do nothing in this case.  [Is this sensible or is it too 'clever'?]

Sensible, I think.  There's no point running update-grub three times.

-- 
Colin Watson   [cjwat...@debian.org]


-- 
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/20100628221906.ga28...@master.debian.org

Re: [DRAFT] Policy for Linux kernel, initramfs, boot loader update process

[Ben Hutchings]

On Mon, 2010-06-28 at 22:19 +, Colin Watson wrote:
> On Mon, Jun 28, 2010 at 03:02:35AM +0100, Ben Hutchings wrote:
> > 1. Packages for boot loaders that need to be updated whenever the files
> > they load are modified (i.e. those that store a block list) must install
> > hook scripts in /etc/kernel/postinst.d and /etc/kernel/postrm.d, which
> > will be called on installation/upgrade and removal of kernel packages,
> > respectively.
> 
> It seems to me (particularly from the fact that you upgraded a grub2 bug
> report about this to important - GRUB 2 does not store block lists for
> kernels) that this is not limited to boot loaders that store block lists
> for the files they load: it also affects boot loaders that need to be
> updated whenever the *list* of files they load is modified.  Can you
> confirm that my understanding is correct?

Sorry, I managed to lose this sentence during editing:

'Packages for boot loaders that can provide a menu of kernel versions
should install kernel hook scripts in order to update that menu.'

> > 2. Packages for boot loaders that need to be updated whenever the files
> > they load are modified must also install hook scripts in
> > /etc/mkinitramfs/post-update.d.  Initramfs builders must call these
> > scripts using run-parts after they create, update or delete an
> > initramfs.  The arguments given to these hook scripts are the kernel ABI
> > version and the absolute path to the initramfs image.
> 
> Does the same apply here, or not?  This is going to be quite a lot of
> calls to update-grub if so, although at least it's quite a bit faster
> now than it used to be ...

No.

> > 3. Initramfs builders must complete their work before returning from the
> > kernel postinst hook script.  [initramfs-tools currently uses a trigger
> > to defer this because it can also be invoked twice, but this means it
> > also has to know how to update specific boot loaders.]
> 
> Is an initramfs guaranteed to be built before any of the boot loader
> hooks are executed?  It seems like a waste of time calling boot loader
> hooks otherwise.  (This may be implied by your design, but it was a
> little bit implicit if so.)
[...]

This requirement and the naming requirements on hook scripts are
intended to guarantee that.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


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

Re: Policy 3.9.0.0 released

[Russ Allbery]

Emil Langrock  writes:
> Russ Allbery wrote:

>> Debian Policy 3.9.0.0 has been released.  The next time you upload your
>> packages, please review them against the upgrading checklist in the
>> debian-policy package and see if they require changes for the new
>> version of Policy.
>> 
> [...]
>>  5.6.8, 7.1, 11.1.1
>>   Architecture wildcards may be used in addition to specific
>>   architectures in `debian/control' and `*.dsc' Architecture
>>   fields, and in architecture restrictions in build relationships.

> Why is this allowed and still all packages are send to all
> architectures? This creates a lot of false "failed ... build of ..."
> mails. In the log of these builds on those architectures only appears
> something like:

>  not in arch list or does not match any arch wildcards: linux-any all

It's a long-standing limitation of the way that the buildds work that if a
package builds any arch-independent package, that package is attempted on
all the buildds even if none of the arch-dependent packages will build
there.  It would be lovely to have that bug fixed, but it's not new nor is
it directly related to arch wildcards.  It's affected the openafs package
for years, which explicitly lists out the architectures it supports.

-- 
Russ Allbery (r...@debian.org)   


-- 
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/87wrtiahcu@windlord.stanford.edu

Re: [DRAFT] Policy for Linux kernel, initramfs, boot loader update process

[Ben Hutchings]

Please reply to debian-kernel only.

On Mon, 2010-06-28 at 11:16 -0400, Stephen Powell wrote:
> On Sun, 27 Jun 2010 22:02:35 -0400 (EDT), Ben Hutchings wrote:
[...]
> > The environment variable DEB_MAINT_PARAMS will contain
> > the arguments given to the kernel maintainer script, single-quoted.
> 
> Is this environment variable provided by the maintainer scripts
> that come with kernel image packages created by "make deb-pkg"?
> (I honestly don't know.  I've never used "make deb-pkg".)

It has done since 2.6.31, though without single-quotes.  I'll note that
they may or may not be quoted, and recommend how to use this variable.

[...]
> > 5. Kernel and initramfs builder packages must not invoke boot loaders
> > except via hooks.  If /etc/kernel-img.conf contains an explicit
> > 'do_bootloader = yes', kernel package maintainer scripts should warn
> > that this is now ignored.
> 
> At the risk of flogging a dead horse, I would prefer to see
> "do_bootloader = yes" supported until Squeeze+1, both by the
> kernel maintainer scripts and by "update-initramfs -u", particularly
> since we are so close to a freeze.

The release team has stated we are not close to a freeze.  So we have a
little time to sort this out.

> But if
> you're going to drop support for it in Squeeze, then yes,
> a warning message is necessary.  Both the kernel maintainer scripts
> *and* "update-initramfs -u" *must* issue a warning message if they
> find "do_bootloader = yes" specified in /etc/kernel-img.conf.
> In fact, since the default value is "yes", they should issue
> the warning message unless do_bootloader is *explicitly* set
> to no.

I can put a one-time warning into linux-base.  But the default for
squeeze must be 'no'.  It should not be necessary to create
/etc/kernel-img.conf at all in squeeze.

> > 6. The installer must not define do_bootloader, postinst_hook or
> > postrm_hook in /etc/kernel-img.conf.
> 
> Doesn't this conflict with point 4 (a)?

Not at all.  This means postinst_hook and postrm_hook are now strictly
for use by the user.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


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

Re: [DRAFT] Policy for Linux kernel, initramfs, boot loader update process

[Ben Hutchings]

On Mon, 2010-06-28 at 18:45 +0200, maximilian attems wrote:
[...]
> please get your facts right before spamming the world.

Max, this is rude and unjustified.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


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

Re: Policy 3.9.0.0 released

[Emil Langrock]

Russ Allbery wrote:
> Debian Policy 3.9.0.0 has been released.  The next time you upload your
> packages, please review them against the upgrading checklist in the
> debian-policy package and see if they require changes for the new version
> of Policy.
> 
[...]
>  5.6.8, 7.1, 11.1.1
>   Architecture wildcards may be used in addition to specific
>   architectures in `debian/control' and `*.dsc' Architecture
>   fields, and in architecture restrictions in build relationships.

Why is this allowed and still all packages are send to all architectures? This 
creates a lot of false "failed ... build of ..." mails. In the log of these 
builds on those architectures only appears something like:

 not in arch list or does not match any arch wildcards: linux-any all
-- 
Emil Langrock


-- 
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/201006290055.06113.emil.langr...@gmx.de

Bug#587483: ITP: threadscope -- a graphical thread profiler for Haskell programs

[USB]

Package: wnpp
Severity: wishlist
Owner: "Ernesto Hernández-Novich (USB)" 


* Package name: threadscope
  Version : 0.1.2
  Upstream Author : Simon Marlow ,
Donnie Jones ,
Satnam Singh 
* URL : http://hackage.haskell.org/package/threadscope
* License : Glasgow Haskell Compiler License (BSD3)
  Programming Lang: Haskell
  Description : a graphical thread profiler for Haskell programs

Threadscope is a graphical thread profiler for Haskell programs.
It parses and displays the content of .eventlog files emitted by the
GHC 6.12.1 and later runtimes, showing a timeline of spark creation,
spark-to-thread promotions and garbage collections.

This helps debugging the parallel performance of Haskell programs,
making easier to check that work is well balanced across the available
processors and spot performance issues relating to garbage collection
or poor load balancing.



--
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/20100628235029.851.99075.report...@deepthought.ius.cc

kapila chawhan has invited you to open a Google mail account

[kapila chawhan]

I've been using Gmail and thought you might like to try it out. Here's
an invitation to create an account.

---

kapila chawhan has invited you to open a free Gmail account.

To accept this invitation and register for your account, visit
http://mail.google.com/mail/a-dfb6db189b-f1e8c2e09c-hFA6MSnt0q46UXLfhxxcMpxNDGs

Once you create your account, kapila chawhan will be notified with
your new email address so you can stay in touch with Gmail!

If you haven't already heard about Gmail, it's a new search-based webmail
service that offers:

- Over 2,700 megabytes (two gigabytes) of free storage
- Built-in Google search that instantly finds any message you want
- Automatic arrangement of messages and related replies into
  "conversations"
- Powerful spam protection using innovative Google technology
- No large, annoying ads--just small text ads and related pages that are
  relevant to the content of your messages

To learn more about Gmail before registering, visit:
http://mail.google.com/mail/help/benefits.html

And, to see how easy it can be to switch to a new email service, check
out our new switch guide: http://mail.google.com/mail/help/switch/

We're still working every day to improve Gmail, so we might ask for your
comments and suggestions periodically.  We hope you'll like Gmail.  We
do.  And, it's only going to get better.

Thanks,

The Gmail Team

(If clicking the URLs in this message does not work, copy and paste them
into the address bar of your browser).


-- 
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/aanlktimm5h7hyvsv6pyvlopbpwcfssg-mwasqsl7o...@mail.gmail.com

broken upload

[Russell Coker]

Below are two messages I have received after attempts to upload a new 
refpolicy package.  I first tried via FTP but the 3G Internet connection I'm 
using gives me a 10.0.0.0/24 address with NAT that doesn't support FTP, so I 
ended up with a zero byte file on anonymous-ftp-master.  Then I got scp 
working with ftp-master which allows me to upload all the files but then 
doesn't process them.

Apart from doing another package build with version -2 what can I do to solve 
this?

refpolicy_0.2.20100524-1.diff.gz doesn't exist
selinux-policy-default_0.2.20100524-1_all.deb has incorrect size; deleting it
selinux-policy-mls_0.2.20100524-1_all.deb doesn't exist
selinux-policy-src_0.2.20100524-1_all.deb doesn't exist
selinux-policy-dev_0.2.20100524-1_all.deb doesn't exist
selinux-policy-doc_0.2.20100524-1_all.deb doesn't exist
Due to the errors above, the .changes file couldn't be processed.
Please fix the problems for the upload to happen.

Greetings,

Your Debian queue daemon (running on host ries.debian.org)



/refpolicy_0.2.20100524-1_amd64.changes is already present on target host:
-rw---S--- 1 1518 802 4032 Jun 29 03:29 refpolicy_0.2.20100524-1_amd64.changes
Either you already uploaded it, or someone else came first.
Job refpolicy_0.2.20100524-1_amd64.changes removed.

Greetings,

Your Debian queue daemon (running on host ravel.debian.org)

-- 
russ...@coker.com.au
http://etbe.coker.com.au/  My Main Blog
http://doc.coker.com.au/   My Documents Blog


-- 
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/201006291606.17876.russ...@coker.com.au

Bug#587488: ITP: qt-assistant-compat -- Qt Assistant compatibility binary (legacy)

[Fathi Boudra]

Package: wnpp
Severity: wishlist
Owner: Fathi Boudra 

* Package name: qt-assistant-compat
  Version : .4.6.3
  Upstream Author : Nokia Corporation and/or its subsidiary(-ies)
* URL : http://labs.trolltech.com/
* License : LGPL2 with exception or GPL3
  Programming Lang: C++
  Description : Qt Assistant compatibility binary (legacy)

 This package contains the Qt Assistant compatibility version, based on
 Assistant Document Profile (.adp) files, and the associated
 QtAssistantClient library, for compatibility with applications providing help 
in that
 format.

 New applications should use the new version of Qt Assistant introduced
 in Qt 4.4, based on the Qt Help Framework also introduced in Qt 4.4, instead.



-- 
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/20100629062248.5590.53597.report...@dc7700p

Re: xulrunner 1.9.2 into sid?

[Michael Gilbert]

On Mon, 28 Jun 2010 13:54:28 +0200 Mike Hommey wrote:

> On Mon, Jun 28, 2010 at 05:36:11AM -0600, Aaron Toponce wrote:
> > Ah yes, Iceape. Their releases are so few and far between, this could
> > possibly mean that we won't see Iceweasel 3.6 or Icedove 3.1 for some
> > time, correct? Upstream Seamonkey 2.1 will be build against gecko 1.9.3,
> > but its release date is TBD. Upstream Firefox 4 is due the end of the
> > year, based on 1.9.3, and will likely be ahead of Seamonkey. So where
> > does that put us? Seems trying to keep the two projects aligned is some
> > task. :)
> 
> (note 1.9.3 is apparently going to be reversioned to 2.0)
> 
> > Will Iceweasel 4 go into Sid when Iceape 2.1 goes into Sid?
> 
> 3.6 will go into sid when squeeze is released. It will remain in
> experimental until then, except if the plans change.
> 4.0 betas will go into experimental then. In the meanwhile, they will
> probably be provided somewhere on mozilla.debian.net.
> 4.0 will go into sid when it is released.
> 
> > > First, TB 3.1 has just been released, and as such hasn't been widely
> > > tested in Debian. It usually isn't very wise, that close to the expected
> > > freeze time, to upload a new major release of a not exactly small and
> > > trivial software.
> > 
> > I can understand this, but I would imagine the release of Squeeze is at
> > least 8-10 months out. We still have a good deal of RC bugs to get
> > through. Of course, packages this size will add to the count.
> 
> Supposedly, the freeze is somewhen in august. After that, getting a new
> major version in the archive is a no-go.
> 
> > > Second, for the reasons given earlier, releasing with iceweasel 3.6 and
> > > icedove 3.1 would mean to avoid releasing with iceape 2.0. This may not
> > > be a huge problem, as we already didn't release lenny with iceape, but
> > > see below.
> > 
> > Iceape is a beautiful piece of software, and I have run it in the past.
> > But market share shows that Seamonkey/Iceape users are the minority,
> > with Firefox/Iceweasel and Thunderbird/Icedove the vast majority.
> > Releasing Lenny without Iceape was the best move, IMO.
> 
> If Debian accounted for market share, it would dump a whole lot of
> packages. There are a lot of packages with less users than iceape.
> 
> > > All in all, I still think releasing squeeze with iceape 2.0, iceweasel
> > > 3.5 and icedove 3.0 is the best course of action.
> > 
> > Is this really the best move? With Firefox 4 due the end of the year,
> > and 3.6 will be a year old already, the security team will be supporting
> > 3.5 after Mozilla stops it's support. Same might be the case with
> > Icedove 3.0.
> 
> Choosing between 3.5 and 3.6 on that alone is not enough.
> As I said, Mozilla will also stop supporting 3.6 way before squeeze
> security support ends.

This discussion brings up an opportunity to debate the merrit of
continuing to suffer the chilling effects of a self-interested upstream
(i.e. mozilla no longer attempts to play well in the open source
ecosystem since it has no impact on 90% of their marketshare). Based on
their latest decision to go to a 6-month only support cycle, it will be
impossible to support their package for the 3+ year lifetime of a
stable release (especially since since they purposely leave out patch
information in their advisories, which is needed to independently solve
their problems). In fact, at the current rate, 3.5 will be end-of-lifed
before squeeze gets out the door. Chilling affects have already been
felt: etch had to drop support for iceweasel 6 months before its
end-of-life as well. Also since 3.0 is already end-of-lifed, support
for iceweasel in lenny will need to end soon (a year or more before the
end of that release).

There are a couple solutions to this problem.  In light of the new
upstream support timeframe, Ubuntu has decided to sacrifice stability
(opting to push new major upstream releases into their stable versions)
and engage in poor supportability/secuirity practices (using embedded
code copies instead of system libraries) [0]. This path is
unnacceptable for Debian.

In my personal opinion, the only viable option left is to drop all
mozilla and mozilla-depending packages from main, and provide them in
backports (as suggested already in another message in this thread).
Backports' rolling release model makes it the perfect avenue to adhere
to mozilla's dictated treadmill.  It may take quite a bit of work to
excise the offending packages, but there is still quite a bit of time
before the squeeze freeze; so it should be doable.  With respect to 
upgrades from lenny, perhaps the iceweasel packages could upgrade to
epiphany or chromium and provide a message about using backports
informing the user about how to continue using iceweasel if that's
really what they want.

Losing mozilla wouldn't be that significant of an loss since there
are plenty of other good options nowadays (webkit, konquerer, chromium,
etc.), which wasn't the case a year or so a