Indicator applets and related packages

[Raphael Hertzog]

[ Bcc debian-mentors as some prospective DD might be interested in
 packaging those ]

Hello,

I would like to be able to use ubuntu's indicator applets in Debian but
very few of the required packages are in Debian (only libindicator is
available).

Here are some of the design pages if you don't know what this is all
about:
https://wiki.ubuntu.com/DesktopExperienceTeam/ApplicationIndicators
https://wiki.ubuntu.com/MessagingMenu
https://wiki.ubuntu.com/MeMenu

The missing source packages are AFAIK:
- libdbusmenu https://launchpad.net/ubuntu/+source/libdbusmenu
  (no RFP/ITP known)
- libindicate https://launchpad.net/ubuntu/+source/libindicate
  RFP: http://bugs.debian.org/560122
- indicator-applet https://launchpad.net/ubuntu/+source/indicator-applet
  RFP: http://bugs.debian.org/534556
- indicator-messages https://launchpad.net/ubuntu/+source/indicator-messages
  (no RFP/ITP known)
- indicator-application 
https://launchpad.net/ubuntu/+source/indicator-application
  (no RFP/ITP known)
- indicator-session https://launchpad.net/ubuntu/+source/indicator-session
  (no RFP/ITP known)
- indicator-me https://launchpad.net/ubuntu/+source/indicator-me
  (no RFP/ITP known)
- indicator-sound https://launchpad.net/ubuntu/+source/indicator-sound
  (no RFP/ITP known)
- in the near future: indicator-network
  https://launchpad.net/indicator-network

And also several plugins/extensions to various piece of software:
- evolution-indicator
  https://launchpad.net/ubuntu/+source/evolution-indicator

And some of those in Qt/KDE variants:
- libindicate-qt https://launchpad.net/ubuntu/+source/libindicate-qt
- https://launchpad.net/plasma-widget-message-indicator

I contacted Ted Gould of Ubuntu/Canonical to ask him whether he would like
to maintain some of those packages within Debian. If yes, I'll sponsor
him (if you want to be the sponsor instead of me, please say so).

I hope we can find maintainers for all those. Should they be maintained
within the Debian Gnome team ?

Cheers,
-- 
Raphaël Hertzog

Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/
My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/


-- 
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/20100614073602.ga25...@rivendell

Re: Xen for Squeeze, 3.4 or 4.0

[Pasi Kärkkäinen]

On Fri, Jun 11, 2010 at 11:47:49PM -0500, Gunnar Wolf wrote:
> Bastian Blank dijo [Thu, Jun 10, 2010 at 05:54:28PM +0200]:
> > Hi folks
> > 
> > I'm currently thinking about which version of Xen supporting in Squeeze.
> > There are two possibilities: 3.4 and 4.0. 3.4 is currently in testing
> > and unstable, 4.0 is in experimental.
> 
> Are both releases supporting running as Dom0 and DomU? I understood
> there were still integration problems with upstream (Linux).
> 

Xen here refers to the *hypervisor* itself (xen.gz). In addition to the 
hypervisor
you also need a separate dom0 Linux kernel for the host, and domU kernels for 
PV guests.

Xen dom0 Linux kernel for Squeeze will be based on (afaik) upstream long-term 
maintained 
xen/stable-2.6.32.x branch from xen.git kernel repository.

-- Pasi


-- 
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/20100614075716.ga17...@reaktio.net

Processed: Re: Bug#585826: general: gnome trash is full

[Debian Bug Tracking System]

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

> reassign 585826 gnome
Bug #585826 [general] general: gnome trash is full
Bug reassigned from package 'general' to 'gnome'.
> thanks
Stopping processing here.

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


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

Re: Indicator applets and related packages

[Emilio Pozuelo Monfort]

On 14/06/10 09:36, Raphael Hertzog wrote:
> I hope we can find maintainers for all those. Should they be maintained
> within the Debian Gnome team ?

No. They are not GNOME modules and we're already quite loaded.

Cheers,
Emilio


-- 
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/4c15e72b.8010...@debian.org

Re: Indicator applets and related packages

[Evgeni Golov]

Hi,

On Mon, Jun 14, 2010 at 09:36:02AM +0200, Raphael Hertzog wrote:
> I would like to be able to use ubuntu's indicator applets in Debian but
> very few of the required packages are in Debian (only libindicator is
> available).

I'd like too, thus I packaged libindicator (sid) and 
xfce4-indicator-plugin (NEW) :)

> The missing source packages are AFAIK:
> - libdbusmenu https://launchpad.net/ubuntu/+source/libdbusmenu
>   (no RFP/ITP known)
> - libindicate https://launchpad.net/ubuntu/+source/libindicate
>   RFP: http://bugs.debian.org/560122

Interested in those, planing to package, will contact ITP-author.

> - indicator-applet https://launchpad.net/ubuntu/+source/indicator-applet
>   RFP: http://bugs.debian.org/534556

No GNOME here, no way to test, sorry.

> - indicator-messages https://launchpad.net/ubuntu/+source/indicator-messages
>   (no RFP/ITP known)
> - indicator-application 
> https://launchpad.net/ubuntu/+source/indicator-application
>   (no RFP/ITP known)
> - indicator-session https://launchpad.net/ubuntu/+source/indicator-session
>   (no RFP/ITP known)
> - indicator-me https://launchpad.net/ubuntu/+source/indicator-me
>   (no RFP/ITP known)
> - indicator-sound https://launchpad.net/ubuntu/+source/indicator-sound
>   (no RFP/ITP known)
> - in the near future: indicator-network
>   https://launchpad.net/indicator-network

Interested.

> And also several plugins/extensions to various piece of software:
> - evolution-indicator
>   https://launchpad.net/ubuntu/+source/evolution-indicator
> 
> And some of those in Qt/KDE variants:
> - libindicate-qt https://launchpad.net/ubuntu/+source/libindicate-qt
> - https://launchpad.net/plasma-widget-message-indicator
> 
> I contacted Ted Gould of Ubuntu/Canonical to ask him whether he would like
> to maintain some of those packages within Debian. If yes, I'll sponsor
> him (if you want to be the sponsor instead of me, please say so).
> 
> I hope we can find maintainers for all those. Should they be maintained
> within the Debian Gnome team ?

libindicator is currently collab-maint with kar...@d.o (CCed) and me, if 
others want to join, we could start a "pkg-indicators" or something :)

Regards
Evgeni

-- 
Bruce Schneier can read and understand Perl programs.


-- 
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/20100614093259.ga9...@dorei.kerker.die-welt.net

Re: Indicator applets and related packages

[Raphael Hertzog]

On Mon, 14 Jun 2010, Evgeni Golov wrote:
> I'd like too, thus I packaged libindicator (sid) and 
> xfce4-indicator-plugin (NEW) :)

I saw libindicator and wondered why indicator-applet was not in the same
batch and investigated and found your RFP and this led me to this mail.
:)

> > The missing source packages are AFAIK:
> > - libdbusmenu https://launchpad.net/ubuntu/+source/libdbusmenu
> >   (no RFP/ITP known)
> > - libindicate https://launchpad.net/ubuntu/+source/libindicate
> >   RFP: http://bugs.debian.org/560122
> 
> Interested in those, planing to package, will contact ITP-author.

They are build-dependencies of several other source packages, so when do
you expect to have a first version ready to test ? :-)

> > - indicator-applet https://launchpad.net/ubuntu/+source/indicator-applet
> >   RFP: http://bugs.debian.org/534556
> 
> No GNOME here, no way to test, sorry.

Is that really the only component depending on Gnome?

> > I hope we can find maintainers for all those. Should they be maintained
> > within the Debian Gnome team ?
> 
> libindicator is currently collab-maint with kar...@d.o (CCed) and me, if 
> others want to join, we could start a "pkg-indicators" or something :)

Or it could be "pkg-ayatana" that takes care of packaging the software
that Ubuntu's Ayatana team releases:
https://launchpad.net/ayatana

I think this could be a good idea indeed. A team that would be very open
to the upstream Ubuntu/Canonical maintainers.

I saw that you used Git for the packaging, while I also use git for all
my own projects, I wonder if it would not make sense to use bzr for those
Canonical projects since they are all maintained in bzr, and it would make
it more likely to have upstream directly involved in the team.

What do you think?

Maybe James Westby could write an HOWTO for DD that are used to git on how
to best maintain Ubuntu's software within Debian with bzr-builddeb.

Cheers,
-- 
Raphaël Hertzog

Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/
My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/


-- 
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/20100614101437.gb26...@rivendell

vim transition to python 2.6

[Oren Held]

Hi,

Currently vim packages (vim-nox, vim-gtk) on sid are still linked to the 
old python2.5.
(Even though it seems possible to compile with python 2.6, according to 
the debian-vim changelog changelog and bug #566842)


Being linked with an old Python version, vim python plugins tend to fail 
when they encounter new 2.6 syntax.


Why is this transition delaying? Is there any task left which I can help 
with?



Thanks

Oren


--
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/4c1601ff.3050...@held.org.il

Re: Bindv6only once again

[Brian May]

On 14 June 2010 16:35, Marco d'Itri  wrote:
> I believe that now we fixed ~everything which can be fixed, so this
> leaves us with the proprietary Java implementation which apparently Sun
> is unwilling to fix.

Is there software that still requires this proprietary Java
implementation? I hear openjdk is getting better all the time.

Is proprietary Java the only reason we should keep having bindv6only=0?

Why not just set bindv6only=0 if this is installed on a system? e.g.
you could make it part of the installer deb.

> Unless the maintainer believes that we can get a fixed version before
> the release then I propose to stop setting bindv6only=1 by default.
> While it was a useful experiment, since it allowed to expose and fix a
> fair number of bugs, it should not compromise the general usability of
> Debian systems.
>
> I do not consider the POSIX-related arguments interesting.

I would be disappointed to think Debian has decided not to "do the
right thing" for all of Debian because it might break a proprietary
application that some people might use.

For me, bindv6only=0 seems like an ugly hack designed to make existing
applications work without change. Although all these arguments have
been hashed out before, no point to repeat them.
-- 
Brian May 


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

Re: Indicator applets and related packages

[Evgeni Golov]

Hi,

On Mon, Jun 14, 2010 at 12:14:37PM +0200, Raphael Hertzog wrote:
> On Mon, 14 Jun 2010, Evgeni Golov wrote:
> > I'd like too, thus I packaged libindicator (sid) and 
> > xfce4-indicator-plugin (NEW) :)
> 
> I saw libindicator and wondered why indicator-applet was not in the same
> batch and investigated and found your RFP and this led me to this mail.
> :)
> 
> > > The missing source packages are AFAIK:
> > > - libdbusmenu https://launchpad.net/ubuntu/+source/libdbusmenu
> > >   (no RFP/ITP known)
> > > - libindicate https://launchpad.net/ubuntu/+source/libindicate
> > >   RFP: http://bugs.debian.org/560122
> > 
> > Interested in those, planing to package, will contact ITP-author.
> 
> They are build-dependencies of several other source packages, so when do
> you expect to have a first version ready to test ? :-)

I have working versions of the ubuntu packages on my Laptop, so 
theretically not tooo far in the future.

> > > - indicator-applet https://launchpad.net/ubuntu/+source/indicator-applet
> > >   RFP: http://bugs.debian.org/534556
> > 
> > No GNOME here, no way to test, sorry.
> 
> Is that really the only component depending on Gnome?

Gnome-testing, yes. The others may need some gnome (or gtk, or both) 
libs, but work fine in every environment.

> > > I hope we can find maintainers for all those. Should they be maintained
> > > within the Debian Gnome team ?
> > 
> > libindicator is currently collab-maint with kar...@d.o (CCed) and me, if 
> > others want to join, we could start a "pkg-indicators" or something :)
> 
> Or it could be "pkg-ayatana" that takes care of packaging the software
> that Ubuntu's Ayatana team releases:
> https://launchpad.net/ayatana

*nod*

I don't care for a name or being a part of another team instead of 
creating a new one, just having helpers is great :)

> I saw that you used Git for the packaging, while I also use git for all
> my own projects, I wonder if it would not make sense to use bzr for those
> Canonical projects since they are all maintained in bzr, and it would make
> it more likely to have upstream directly involved in the team.
> 
> What do you think?
> 
> Maybe James Westby could write an HOWTO for DD that are used to git on how
> to best maintain Ubuntu's software within Debian with bzr-builddeb.

Never tried bzr, so no idea how complicated it is (I guess not too 
different to git anyways). If there is a simple howto, I'll happily move 
:)

Regards
Evgeni

-- 
Bruce Schneier can read and understand Perl programs.


-- 
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/20100614105430.ge9...@dorei.kerker.die-welt.net

Re: Bindv6only once again

[Sylvestre Ledru]

Le lundi 14 juin 2010 à 20:45 +1000, Brian May a écrit :
> On 14 June 2010 16:35, Marco d'Itri  wrote:
> > I believe that now we fixed ~everything which can be fixed, so this
> > leaves us with the proprietary Java implementation which apparently Sun
> > is unwilling to fix.
> 
> Is there software that still requires this proprietary Java
> implementation? I hear openjdk is getting better all the time.
It is not the case. The OpenJDK has some problems with font management, 
slower with Swing and a few other problems.
However, I am not aware of software not working with the OpenJDK (ie
requiring the proprietary Java).

Sylvestre



-- 
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/1276512754.21869.18898.ca...@korcula.inria.fr

Re: Indicator applets and related packages

[Sebastien Bacher]

Le lundi 14 juin 2010 à 11:32 +0200, Evgeni Golov a écrit :
> I'd like too, thus I packaged libindicator (sid)

Hi,

Could you avoid changing the packaging system when you take things to
Debian? We do use cdbs for those because it makes easier some of the
things we are doing, we could need to add a diff back for langpacks
translations for example over your version rather than being able to
sync the source. That's something we should solve by porting our tools
to dh7 but right now it's not done so meanwhile if we want to work
together on those directly in Debian it would be nice to let the rules
use cdbs if you can...

Sebastien Bacher


--
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/1276511250.4912.18.ca...@seb128-laptop

Re: Indicator applets and related packages

[Evgeni Golov]

On Mon, Jun 14, 2010 at 12:27:30PM +0200, Sebastien Bacher wrote:
> Le lundi 14 juin 2010 à 11:32 +0200, Evgeni Golov a écrit :
> > I'd like too, thus I packaged libindicator (sid)
> 
> Hi,
> 
> Could you avoid changing the packaging system when you take things to
> Debian? We do use cdbs for those because it makes easier some of the
> things we are doing, we could need to add a diff back for langpacks
> translations for example over your version rather than being able to
> sync the source. That's something we should solve by porting our tools
> to dh7 but right now it's not done so meanwhile if we want to work
> together on those directly in Debian it would be nice to let the rules
> use cdbs if you can...

Hi,

I could, sure. But I had the "same problem" the other way: I have no 
idea how cdbs works, thus I tried to avoid it :)
If we can put a team together where we have some cdbs cracks, it's fine 
to have cdbs again I think ;)

regards

-- 
Bruce Schneier can read and understand Perl programs.


-- 
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/20100614110814.gf9...@dorei.kerker.die-welt.net

Re: Bindv6only once again

[Jarek Kamiński]

Na grupie linux.debian.devel napisałe(a)ś:
> I believe that now we fixed ~everything which can be fixed, so this
> leaves us with the proprietary Java implementation which apparently Sun
> is unwilling to fix.
> Unless the maintainer believes that we can get a fixed version before
> the release then I propose to stop setting bindv6only=3D1 by default.
> While it was a useful experiment, since it allowed to expose and fix a
> fair number of bugs, it should not compromise the general usability of
> Debian systems.

I see only two ways of fixing proprietary Java (apart from fixing it
upstream or ignoring the problem):
* wrap java and java_vm binaries in some scripts setting LD_PRELOAD (in
  Debian package)
or
* allow sun-java6-* packages to override bindv6only sysctl.

I can't say I like any of these approaches (although I currently do the
first on my systems).

I hope Oracle will eventually fix the bug in Java allowing the change in
(some) stable Debian release (or OpenJDK will replace Sun's Java
completely).

Jarek.


-- 
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/20100614112511.ga10...@vilo.eu.org

Re: Bindv6only once again

[Sylvestre Ledru]

Le lundi 14 juin 2010 à 13:25 +0200, Jarek Kamiński a écrit :
> Na grupie linux.debian.devel napisałe(a)ś:
> > I believe that now we fixed ~everything which can be fixed, so this
> > leaves us with the proprietary Java implementation which apparently Sun
> > is unwilling to fix.
> > Unless the maintainer believes that we can get a fixed version before
> > the release then I propose to stop setting bindv6only=3D1 by default.
> > While it was a useful experiment, since it allowed to expose and fix a
> > fair number of bugs, it should not compromise the general usability of
> > Debian systems.
> 
> I see only two ways of fixing proprietary Java (apart from fixing it
> upstream or ignoring the problem):
> * wrap java and java_vm binaries in some scripts setting LD_PRELOAD (in
>   Debian package)
This won't work in some cases. Some native programs instantiate a JVM
from C/C++. 

> or
> * allow sun-java6-* packages to override bindv6only sysctl.
Is it allowed by the Debian policy ?

> I can't say I like any of these approaches (although I currently do the
> first on my systems).
> 
> I hope Oracle will eventually fix the bug in Java allowing the change in
> (some) stable Debian release 
There is no interest from Oracle on this issue:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6342561

> (or OpenJDK will replace Sun's Java completely).
Last time I heard, Java 7 was expected for September 2010 but I am not
counting on it.

Sylvestre



-- 
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/1276516044.21869.19032.ca...@korcula.inria.fr

Re: Bindv6only once again

[Mike Hommey]

On Mon, Jun 14, 2010 at 01:25:11PM +0200, Jarek Kamiński wrote:
> Na grupie linux.debian.devel napisałe(a)ś:
> > I believe that now we fixed ~everything which can be fixed, so this
> > leaves us with the proprietary Java implementation which apparently Sun
> > is unwilling to fix.
> > Unless the maintainer believes that we can get a fixed version before
> > the release then I propose to stop setting bindv6only=3D1 by default.
> > While it was a useful experiment, since it allowed to expose and fix a
> > fair number of bugs, it should not compromise the general usability of
> > Debian systems.
> 
> I see only two ways of fixing proprietary Java (apart from fixing it
> upstream or ignoring the problem):
> * wrap java and java_vm binaries in some scripts setting LD_PRELOAD (in
>   Debian package)
> or
> * allow sun-java6-* packages to override bindv6only sysctl.

* allow bindv6only to be overridden by process instead of system-wide.

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/20100614114750.ga9...@glandium.org

Re: vim transition to python 2.6

[James Vega]

On Mon, Jun 14, 2010 at 01:18:39PM +0300, Oren Held wrote:
> Currently vim packages (vim-nox, vim-gtk) on sid are still linked to
> the old python2.5.
> (Even though it seems possible to compile with python 2.6, according
> to the debian-vim changelog changelog and bug #566842)
> 
> Being linked with an old Python version, vim python plugins tend to
> fail when they encounter new 2.6 syntax.
> 
> Why is this transition delaying? Is there any task left which I can
> help with?

Vim will be built against Python 2.6 when Python 2.6 becomes the default
Python version.  If you want to help achieve that, take a look at the
bug list for that transition:

http://tinyurl.com/Py26Transition

-- 
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega 


signature.asc
Description: Digital signature

Re: Bindv6only once again

[Adam Borowski]

On Mon, Jun 14, 2010 at 08:45:58PM +1000, Brian May wrote:
> On 14 June 2010 16:35, Marco d'Itri  wrote:
> > I believe that now we fixed ~everything which can be fixed, so this
> > leaves us with the proprietary Java implementation which apparently Sun
> > is unwilling to fix.

There's no bug, so there is nothing to fix there.

Non-proprietary packages are more prone to bikeshedding -- if you want to
introduce a workaround to a problem elsewhere, you can do that.  This is
usually good -- but you can't blame Sun for refusing to pander to
regressions in outside software.

Both values of bindv6only have their upsides and downsides.  In my opinion,
=0 is vastly superior for anything but a few improperly ported programs, in
Marco's opinion =1 is better -- but they are still different colours of
paint you can cover your bikeshed with.  And proprietary software is harder
to repaint.

> For me, bindv6only=0 seems like an ugly hack designed to make existing
> applications work without change.

"without change"?  Except, you know, the whole conversion from gethostname()
and friends to getaddrinfo()?  V4-mapped addresses won't show for you if you
do nothing -- they're a part of the package for the new API.

It's not an ugly hack, it is careful design aimed to make software protocol
agnostic.  Without having to deal separately with every protocol, you get
forward-compatibility to any other future protocol, be it IPv17, IPX (if
someone bothers extending it), or any other private use development --
without having to modify or even recompile any existing software.

It also lets programs to bind a socket in one go without having to
separately handle IPv4 and v6.

It is bindv6only=1 what is an ugly hack, since it tries to hide errors 
that result from partially botched conversions from IPv4-only to
multiprotocolness.

-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


-- 
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/20100614121353.ga9...@angband.pl

Re: libnss-myhostname instead of mangling /etc/hosts

[Joachim Breitner]

Hi joey,

Am Sonntag, den 13.06.2010, 10:59 -0400 schrieb Joey Hess:
> Joachim Breitner wrote:
> > Would this be something that could be used by default in Debian, maybe
> > for squeeze+1? 
> 
> You're suggesting making the package standard priority. This is not a
> decision within the purvue of the d-i team, really.

that’s of course a valid point. I’ll therefore move the suggestion to
d-devel. Here is my original mail again:

> at the moment, the Debian installer creates a /etc/hosts file
> containing the local host name¹, so that this name is resolvable even
> if not registered in the DNS. Unfortunately, this is a possible cause
> of problems when the user wants to change the hostname – he has to
> change it in /etc/hosts two.
> 
> Lennart Poetting’s libnss-myhostname² works around this issue. Instead
> of hard-coding the hostname in /etc/hosts, this nss module resolves
> the current local host to 127.0.1.1. It also works with ipv6.
> 
> Would this be something that could be used by default in Debian, maybe
> for squeeze+1? 
> 
> Pros:
>  * Renaming a host does not affect /etc/hosts.
>  * /etc/hosts is the same on all installation and can be made a
> regular static conffile shipped by some base package, instead of being
> created by netcfg during installation.
> 
> Cons:
>  * Another nss module that has to be loaded.
>  * More code involed in a very common procedure that might contain
> bugs (but these will eventually all be fixed, I assume).
> 
> 
> What do you think?


OTOH, maybe libnss-myshostname does not have to be priority standard.
Instead, /etc/hosts could be shipped without the local hostname and
packages that are known to require the hostname to be resolvable can
just depend on it. Advantage is that only installations that really
require the feature need to install the package. Disadvantage is that
the admin can not easily remove it and do the /etc/hosts setting
manually. Maybe a case for a Recommends?

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: Bindv6only once again

[Russ Allbery]

m...@linux.it (Marco d'Itri) writes:

> I believe that now we fixed ~everything which can be fixed, so this
> leaves us with the proprietary Java implementation which apparently Sun
> is unwilling to fix.

I think there are probably other proprietary applications that people just
haven't tried using with testing yet.  I suspect most uses of proprietary
applications are in environments where it's rare to use something other
than stable.

> Unless the maintainer believes that we can get a fixed version before
> the release then I propose to stop setting bindv6only=1 by default.
> While it was a useful experiment, since it allowed to expose and fix a
> fair number of bugs, it should not compromise the general usability of
> Debian systems.

I agree with this decision.

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

3.0 (quilt) format and patches applied to "component" source

[David Paleino]

Hello people,
I'm trying to merge josm and josm-plugins in a single source package, so that
it's easier to maintain them both.
I succeeded in changing the buildsystem and doing the necessary patching to
make it work; however I'm having an issue now. My layout consists in
josm_X.Y.orig.tar.gz, and josm_X.Y.orig-plugins-ZZZ.tar.gz:

  $ ls -1 *.gz
  josm_0.0.svn3329.orig-plugins-0.0.svn21666.tar.gz
  josm_0.0.svn3329.orig.tar.gz
  $

The -plugins- tarball is unpacked in unpacked in josm/plugins/.

The problem is, when launching "dpkg-source -b" on that directory, it tries to
apply the patches _before_ unpacking the component, thus failing. Is this a
genuine bug, or am I missing something?
I'm running:

  $ dpkg-source -i.git -I.git -b josm/

See the log here: http://paste.debian.net/77398/ ("deboprep" is a local script
that also runs dpkg-genchanges and other things).

Passing --no-preparation, as seen in the above log, doesn't do any better:
http://paste.debian.net/77399/ .

Ideas?

Thank you,
David

-- 
 . ''`.   Debian developer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 | http://deb.li/dapal
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174


signature.asc
Description: PGP signature

Re: 3.0 (quilt) format and patches applied to "component" source

[David Paleino]

On Mon, 14 Jun 2010 20:00:28 +0200, David Paleino wrote:

> Hello people,
> [..]

Ahah! I got it.

> [..]
>   $ ls -1 *.gz
>   josm_0.0.svn3329.orig-plugins-0.0.svn21666.tar.gz
>   josm_0.0.svn3329.orig.tar.gz
>   $

 doesn't accept dots. So, I changed that to *-plugins-svn21666, but
it obviously unpacked it into josm/plugins-svn21666/. While this could be an
acceptable solution (but would need some overhead to refresh the patches at
each release, and to commit useless changes to $VCS), I don't really fancy it.

Only using "*-plugins.tar.gz" works fine :)

/me beats himself hard.

-- 
 . ''`.   Debian developer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 | http://deb.li/dapal
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174


signature.asc
Description: PGP signature

Bug#585899: ITP: libclhm-java -- high performance Map implementation useful for caching

[Eric Evans]

Package: wnpp
Severity: wishlist
Owner: Eric Evans 

* Package name: libclhm-java
  Version : 1.0
  Upstream Author : Ben Manes
* URL : http://code.google.com/p/concurrentlinkedhashmap/
* License : Apache License 2.0
  Programming Lang: Java
  Description : high performance java Map implementation useful for caching

A Java hash table supporting full concurrency of retrievals, adjustable
expected concurrency for updates, and a maximum capacity to bound the map
by. This implementation differs from ConcurrentHashMap in that it
maintains a page replacement algorithm that is used to evict an entry when
the map has exceeded its capacity.


The long description above is copypasta from the upstream site and will
need some work prior to upload. Suggestions are welcome.

-- 
Eric Evans
eev...@debian.org


signature.asc
Description: Digital signature

Bug#585902: ITP: libhighscale-java -- high performance java collection alternatives

[Eric Evans]

Package: wnpp
Severity: wishlist
Owner: Eric Evans 

* Package name: libhighscale-java
  Version : 1.1.2
  Upstream Author : Cliff Click
* URL : http://sourceforge.net/projects/high-scale-lib
* License : Public Domain 
  Programming Lang: Java
  Description : high performance java collection alternatives

A collection of concurrent and highly scalable utilities. These are
intended as direct replacements for the java.util.* or
java.util.concurrent.* collections but with better performance when many
CPUs are using the collection concurrently. Single-threaded performance
may be slightly lower.

The above long description is copypasta from upstream will need some work
prior to upload. Suggestions welcome.

-- 
Eric Evans
eev...@debian.org


signature.asc
Description: Digital signature

Bug#585903: ITP: libyaml-snake-java -- YAML parser and emitter for Java

[Eric Evans]

Package: wnpp
Severity: wishlist
Owner: Eric Evans 

* Package name: libyaml-snake-java
  Version : 1.6
  Upstream Author : Andrey Somov 
* URL : http://code.google.com/p/snakeyaml
* License : Apache License 2.0
  Programming Lang: Java
  Description : YAML parser and emitter for Java

YAML is a data serialization format designed for human readability and
interaction with scripting languages. SnakeYAML is a YAML parser and
emitter for the Java programming language. It has a high-level API for
serializing and deserializing native Java objects, and conforms to the
YAML 1.1 specification.


The above description is pieced together from the upstream site will
need some work prior to upload. Suggestions for better wording welcome.

-- 
Eric Evans
eev...@debian.org


signature.asc
Description: Digital signature

Bug#585905: ITP: cassandra -- highly scalable distributed datastore (database)

[Eric Evans]

Package: wnpp
Severity: wishlist
Owner: Eric Evans 

* Package name: cassandra
  Version : 0.7.0
  Upstream Author : Apache Cassandra Team
* URL : http://cassandra.apache.org
* License : Apache License 2.0
  Programming Lang: Java
  Description : highly scalable distributed datastore (database)

Apache Cassandra is a distributed, schema-free, sparse-table database. Its
shared-nothing design and client tunable eventual consistency result in
both linear scalability, and a high level of fault tolerance. Cassandra is
ideally suited to very large datasets, high write throughput, and for
distributing redundant copies of data across racks and data-centers.


-- 
Eric Evans
eev...@debian.org


signature.asc
Description: Digital signature

Re: A lot of pending packages

[Vincent Danjean]

On 11/06/2010 09:54, Thomas Goirand wrote:
> Right, I was being silly. Also, the word "experimental" adds more fear
> to the user than just "devel", which is good. Let me rephrase then. How
> about we accept MORE packages with LESS checks in Experimental, and have
> new maintainers forced in that repository, then if they are seen as
> responsive, we upload to SID? Could that be a sponsor's decision already
> right now, and be considered a good practice?

I disagree with this new proposed used of experimental. If you do this,
you will end up with newbies using experimental to get new stuff and
breaking their system to us a big on-going transition in experimental.

  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/4c169925.8040...@free.fr

Bug#585935: ITP: googlecl -- command-line access to (some) Google services

[jholt]

Package: wnpp
Severity: wishlist
Owner: jholt 


* Package name: googlecl
  Version : 0.9
  Upstream Author : Tom H. Miller 
* URL : http://code.google.com/p/googlecl/
* License : Apache 2.0
  Programming Lang: Python
  Description : command-line access to (some) Google services

 This package provides a user-friendly command-line interface to
 some of the Google gdata APIs.  It lets you do things like:
 .
 google blogger post --title "Test Post" "I'm posting from the command line"
 google calendar list --date 2010-06-01
 google contacts list
 google youtube post killer_robots.avi



-- 
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/20100614233505.1947.23447.report...@tonne

Re: Debian Installer string freeze: translations to complete (deadline July 4th)

[Christian PERRIER]

Quoting Christian PERRIER (bubu...@debian.org):

Sorry for the followup in an -announce mailing list, but my announce
(which was written offline) includes an error:

> [1] http://d-i.alioth.debian.org/doc/l10n

The right link is http://d-i.alioth.debian.org/doc/i18n




signature.asc
Description: Digital signature

Re: Indicator applets and related packages

[Ted Gould]

On Mon, 2010-06-14 at 12:14 +0200, Raphael Hertzog wrote:
> On Mon, 14 Jun 2010, Evgeni Golov wrote:
> > > - indicator-applet https://launchpad.net/ubuntu/+source/indicator-applet
> > >   RFP: http://bugs.debian.org/534556
> > 
> > No GNOME here, no way to test, sorry.
> 
> Is that really the only component depending on Gnome?

That is the goal.  Some others depend on GTK like libdbusmenu-gtk, but
the goal is to make each piece need as little as possible to make it
easier for platforms like XFCE to adopt.

> > > I hope we can find maintainers for all those. Should they be maintained
> > > within the Debian Gnome team ?
> > 
> > libindicator is currently collab-maint with kar...@d.o (CCed) and me, if 
> > others want to join, we could start a "pkg-indicators" or something :)
> 
> Or it could be "pkg-ayatana" that takes care of packaging the software
> that Ubuntu's Ayatana team releases:
> https://launchpad.net/ayatana
> 
> I think this could be a good idea indeed. A team that would be very open
> to the upstream Ubuntu/Canonical maintainers.

I'm unfamiliar with Debian processes so I can't comment on whether a
team is appropriate.  But, I'd be happy to join a mailing list or answer
questions and provide help how ever I can.  I will need some guidance on
that though as things get setup.

--Ted



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

Re: Bindv6only once again

[Julien BLACHE]

Sylvestre Ledru  wrote:

Hi,

> It is not the case. The OpenJDK has some problems with font management, 
> slower with Swing and a few other problems.
> However, I am not aware of software not working with the OpenJDK (ie
> requiring the proprietary Java).

ISTR OpenJDK and JDBC4 do not exactly work well together (read: not at
all). Do you know anything about that? I've run into this myself and am
forced to use Sun's JDK in this case.

In case you'd like to check it out, this is with OpenBravo POS using
PostgreSQL. The database code just doesn't work at all with OpenJDK 6.

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-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87iq5ku7iz@sonic.technologeek.org

Bug#585952: ITP: gnome-paint - simple, easy to use paint program for GNOME

[Aron Xu]

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

Package name: gnome-paint
Version: 0.3
Upstream Author: Rogério Ferro do Nascimento 
URL: http://code.google.com/p/gnome-paint/
License: GPL-3
Description: simple, easy to use paint program for GNOME



--
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/aanlktil7-e-rmncacrkixs-fmumrp85wgbezbi_4y...@mail.gmail.com