Re: adding desktop files to misc packages

[Josselin Mouette]

Le lundi 16 juillet 2007 à 19:08 -0500, Steve Greenland a écrit :
> > Some of the users we target don't even know what a window manager is,
> > and they don't want to know it.
> 
> Some of the users we target don't use any desktop environment, running
> headless servers. So let's remove KDE and GNOME.

If you have nothing to say apart proving that you don't want to
understand what people write, what's the point of contributing to a
mailing list?

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.

Re: adding desktop files to misc packages

[Thijs Kinkhorst]

On Tuesday 17 July 2007 02:08, Steve Greenland wrote:
> Some of the users we target don't use any desktop environment, running
> headless servers. So let's remove KDE and GNOME.

This problem is about defaults, not about removing things entirely. 
Appearently every user gets menu items for all installed window managers. 

Fine with me if it's easy to add an installed window manager to the menu, but 
I do agree with the general point here that it's quite useless to build a 
menu with those options for every user by default.


Thijs


pgpfuL704q7lj.pgp
Description: PGP signature

Re: Any problems with mips/mipsel?

[Oleksandr Moskalenko]

* Frank Lichtenheld <[EMAIL PROTECTED]> [2007-07-05 13:01:36 +0200]:

> You should check http://buildd.debian.org/ which will tell you that
> both attempted to build your package but failed. Looks like a toolchain
> issue to me. You could ask on @buildd.debian.org to retry the
> package. Or you could try to find out first if the issue is fixed,
> that might be easily possible or not.

So, what can a developer do when builds for a package consistently fail on
mips/mipsel? Buildd logs are not very helpful in this case since they just
show uninformative assembler failure messages. I also made several unanswered
requests to [EMAIL PROTECTED] for build-depends installation on
any developer accessible mips/mipsel machine to try looking at the build to
figure out the problem.

I'm not sure what the next step to take would be.

Alex.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Bastian Venthur]

Frank Küster wrote:
> Michael Biebl <[EMAIL PROTECTED]> wrote:

>> for all the reason already given:
>> - It duplicates entries (so it's potentially confusing for novice users)
> 
> That's a point.

That's *the* point in my opinion. Duplicated entries are confusing and
therefore not user-friendly.

>> - Has no i18n
> 
> That isn't an argument to remove it, but for adding i18n support to it.

But why re-invent the wheel when .desktop files already provide this and
other features?

>> - ugly (although I agree that's subjective). No png icons for
>> applications, no icons for subdirectories, which imho makes it harder to
>> recognize the categories quickly.
> 
> Having no icons is probably a feature - someone else said in this thread
> that the icons are the reason for slow menus.

It is not a feature of the menu, it is a bug of the DE beeing unable to
hide icons if the user wants it.

This isn't usually a problem for users of the mainstream DEs. And
honestly, I think the vast majority of users (including those with
exotic DEs) actually likes icons in the menu since that's what menus
usually have. I don't want to waste my time and energy to please *every*
user out there (that's virtually impossible), so I'd draw the line right
here: If you don't want icons, fine but please don't elevate this bug to
a feature.


Cheers,

Bastian

-- 
Bastian Venthur  http://venthur.de
Debian Developer venthur at debian org


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Andreas Tille]

On Tue, 17 Jul 2007, Thijs Kinkhorst wrote:


Fine with me if it's easy to add an installed window manager to the menu, but
I do agree with the general point here that it's quite useless to build a
menu with those options for every user by default.


... which speaks for a role based user concept.

Kind regards

   Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Josselin Mouette]

Le lundi 16 juillet 2007 à 20:44 +0200, Javier Fernández-Sanguino Peña a
écrit :
> It looks to me like they are properly categorised and its the GNOME menu
> which is misbehaving

I have indeed to back out my previous claim. I'm going to work on fixing
this issue in gnome-menus.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.

Re: adding desktop files to misc packages

[Josselin Mouette]

Le mardi 17 juillet 2007 à 08:52 +0200, Frank Küster a écrit :
> > I actually do like Don's idea.
> > The first thing I usually do, after installing KDE or Gnome is to
> > disable the Debian menu in /etc/xdg/menus/(gnome,kde)-applications.menu,
> 
> Okay, as long as it can easily be configured, I see no problem in
> disabling it by default.  But there should be either a prominent menu
> entry which is easy to find, or a README.Debian in an obvious package.

If disabled with NoDisplay=true, you can easily re-enable the Debian
menu in alacarte (accessible with a right click and "edit menus"). Would
that suit you?

> Having no icons is probably a feature - someone else said in this thread
> that the icons are the reason for slow menus.

Ideally, slow features should be optimised, not disabled. See my
proposal on -release for generalising icon caches, and upstream
proposals to optimise icon caches further by sorting icons the same way
they are accessed.

Cheers,
-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.

Re: Co-Maintainer for libdbi-perl wanted

[Raphael Hertzog]

Hi,

On Tue, 17 Jul 2007, Christian Hammers wrote:
> I'm looking for a co-maintainer of libdbi-perl. It's a very low-work package
> that just sometimes fails to build on some architecture.

You could integrate the package in the pkg-perl repository and you'd have
lots of co-maintainers for free. :-)

http://pkg-perl.alioth.debian.org

Other interested co-maintainers which are not yet part of the pkg-perl team
are also welcome to join of course.

If you're interested, just tell us and we'll add you to the team.

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Upgrade kernel loses DVB devices

[Brendon Higgins]

Hi list,

I have here a problem that I solved. I have no idea who I should report it to, 
so I'm posting it here in the hope that, eventually, someone relevent might 
see it.

I'm running testing. After upgrading to kernel 2.6.21-2 my DVB device files 
disappeared. It turns out that a required module cx88-dvb was no longer 
getting pulled in with the other cx88 modules during boot. I've no idea why. 
I've no idea how it's supposed to work.

I've solved my problem by adding cx88-dvb to /etc/modules. I doubt this is the 
real solution, which is why I post here, but it works.

Peace,
Brendon


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Any problems with mips/mipsel?

[Mark Brown]

On Tue, Jul 17, 2007 at 12:53:05AM -0600, Oleksandr Moskalenko wrote:

> show uninformative assembler failure messages. I also made several unanswered
> requests to [EMAIL PROTECTED] for build-depends installation on
> any developer accessible mips/mipsel machine to try looking at the build to
> figure out the problem.

Did you do this by mailing debian-admin or by using the request
tracker[1]?  Requests sent via RT should have less chance of being
missed.

[1] http://lists.debian.org/debian-devel-announce/2007/03/msg00018.html

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."


signature.asc
Description: Digital signature

Re: patch for versioned symbols in Heimdal shared library

[Guillem Jover]

Hi,

On Wed, 2007-07-11 at 21:28:17 -0700, Russ Allbery wrote:
> I do this in configure.ac:
> 
> dnl If and only if we're on Linux, use a mapfile to do symbol versioning.
> dnl We'd like to do this on all platforms, but the syntax is different
> dnl everywhere and I don't feel like dealing with the differences.
> case "$host" in
> *-linux*)

This should probably be “*-gnu*)”, as this is dependent on ld and
should be fine on any GNU based system.

> VERSION_LDFLAGS="-Wl,--version-script=mapfile"
> ;;
> *)
> VERSION_LDFLAGS=""
> ;;
> esac
> AC_SUBST([VERSION_LDFLAGS])

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

debdelta service back on track

[A Mennucc]

hi all,

about two weeks ago  'debdelta-upgrade' started failing. Unfortunately I
was away with (almost) no Internet access. Today I could finally fix the
problem.

The problem was due to a subtle change in zlib1g: in newer versions, the
compressed output has 0x02 instead of 0x00 at the 10th byte (that is in
the header). This change occurred somewhere between version 1.2.3-13 and
1.2.3.3.dfsg-5 .
(I am sending a CC to the upstream authors and to the Debian Mantainer,
in case they are not aware of this change).
 Since dpkg-deb uses zlib1g, this changed the .deb files. So a file
reconstructed by "debpatch" would be different with the original in 2
bytes.

I have added a workaround for that problem in 'debdelta' version 0.21 ,
and I have installed it in the server that prepares deltas for
'debdelta-upgrade' . Now it should work again as expected. (If it does
not, mail me, or send a bug in the BTS).

Note that endusers that only use 'debpatch' and 'debdelta-upgrade' do
not need to upgrade: the workaround is in the delta-ing code.

a.

 --- Info

debdelta is a program suite designed to compute changes between Debian
packages.
It contains various utilities, including 'debdelta-upgrade' that can be
used by people with slow access to Internet to speed up their "apt-get
upgrade". The debian package is
http://packages.debian.org/unstable/devel/debdelta
More info are available at
http://tonelli.sns.it/pub/mennucc1/debdelta/README



signature.asc
Description: OpenPGP digital signature

Re: Bug#229357: Can we require build-arch/indep targets for lenny?

[Goswin von Brederlow]

Wouter Verhelst <[EMAIL PROTECTED]> writes:

> On Fri, Jun 29, 2007 at 11:11:04PM +0200, Bill Allombert wrote:
>> One of the issue is that tools like sbuild and pbuilder which want to
>> take advantage of the Build-Depends-Indep split needs to know whether
>> dpkg-buildpackage will call debian/rules build or build-arch.
>
> It needs to know no such thing. It just needs to know that if it runs
> "dpkg-buildpackage -b", only .debs will be generated, and if it runs
> "dpkg-buildpackage -B", all debs apart from the _all.debs will be
> generated. How exactly this happens is of no concern to sbuild.

It does when "Build-Depends" is used as specified in policy and not
like it is (brokenly) used now:

Policy 7.6:

| Build-Depends, Build-Conflicts
|
|The Build-Depends and Build-Conflicts fields must be satisfied
|when any of the following targets is invoked: build, clean,
|binary, binary-arch, build-arch, build-indep and binary-indep. 
|
| Build-Depends-Indep, Build-Conflicts-Indep
| 
| The Build-Depends-Indep and Build-Conflicts-Indep fields must be
| satisfied when any of the following targets is invoked: build,
| build-indep, binary and binary-indep.

That means that is -b is used or if the package does NOT support
build-arch then sbuild must install Build-Depends-Indep as well.

If build-arch remains optional and policy for Build-Depends remains
unchanged then sbuild must now. Making build-arch required or changing
the meaning of Build-Depends to the broken use we have now resolves
this. I favor making build-arch required.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Can we require build-arch/indep targets for lenny?

[Goswin von Brederlow]

Russ Allbery <[EMAIL PROTECTED]> writes:

>> I'm tempted to suggest _just_ going by the package's Standards-Version.
>
> Based on the arguments I've seen so far, I'm opposed to using the
> package's Standards-Version for this purpose.  I think it conflates
> different meanings of that field and will get us into serious trouble when
> it comes to the distinctions between must, should, and recommended.

| Policy 5.6.11 Standards-Version
|
| The most recent version of the standards (the policy manual and
| associated texts) with which the package complies.

This field has exactly this meaning. It says the package followes a
certain version of policy, e.g. the one where now there is a MUST
instead of the previous RECOMMENDS.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Frank Küster]

Josselin Mouette <[EMAIL PROTECTED]> wrote:

> Le mardi 17 juillet 2007 à 08:52 +0200, Frank Küster a écrit :
>> > I actually do like Don's idea.
>> > The first thing I usually do, after installing KDE or Gnome is to
>> > disable the Debian menu in /etc/xdg/menus/(gnome,kde)-applications.menu,
>> 
>> Okay, as long as it can easily be configured, I see no problem in
>> disabling it by default.  But there should be either a prominent menu
>> entry which is easy to find, or a README.Debian in an obvious package.
>
> If disabled with NoDisplay=true, you can easily re-enable the Debian
> menu in alacarte (accessible with a right click and "edit menus"). Would
> that suit you?

You mean, right click anywhere in the menu and choose edit?  That would
be very accessible, yes.  And user-friendly ;-)

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: adding desktop files to misc packages

[Frank Küster]

Bastian Venthur <[EMAIL PROTECTED]> wrote:

> Frank Küster wrote:
>> Michael Biebl <[EMAIL PROTECTED]> wrote:
>
>>> for all the reason already given:
>>> - It duplicates entries (so it's potentially confusing for novice users)
>> 
>> That's a point.
>
> That's *the* point in my opinion. Duplicated entries are confusing and
> therefore not user-friendly.

I agree - but for me that's one more argument for not using a DE with
it's limited set of menu entries, except for those in the Debian
menu... 

>>> - Has no i18n
>> 
>> That isn't an argument to remove it, but for adding i18n support to it.
>
> But why re-invent the wheel when .desktop files already provide this and
> other features?

I didn't say anything about the implementation, it might well be a good
approach to base it on desktop files.  

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: FTBFS if built twice in a row

[Goswin von Brederlow]

Russ Allbery <[EMAIL PROTECTED]> writes:

> Goswin von Brederlow <[EMAIL PROTECTED]> writes:
>> Russ Allbery <[EMAIL PROTECTED]> writes:
>
>>> This check would fail many packages that can still be built twice in a
>>> row (any package that runs autotools during the build process without
>>> doing a complicated dance to preserve the upstream-shipped files, for
>>> example), and it's not clear to me that there's a consensus that those
>>> packages are really broken.
>
>> But exceedingly anoying when doing a patch and debdiff.
>
> Not if you use pdebuild or similarly build in a chroot, which IMO everyone
> should be doing.

I use xen instances and that changes nothing at all.

1. My ~/src is mounted inside the build environment so I don't have to
copy the source around all the time

2. building generates the diff.gz and dsc file

Note: you can't generally even build source outside the build
environment as any Build-Depends could be required

Note 2: Building source can already add huge amount of spam to the
diff.gz.

So when you "debdiff debian.dsc local.dsc" you get all the changes
even the autogenerated stuff. Real pain to have 100k line diff for a 5
line change.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: FTBFS if built twice in a row

[Goswin von Brederlow]

Peter Samuelson <[EMAIL PROTECTED]> writes:

> [Lucas Nussbaum]
>> The problem is that it isn't required to have exactly the same source
>> tree after "./configure ; make ; make clean". It's just required that
>> "./configure ; make ; make clean ; ./configure ; make" works. It is
>> possible that the first build modifies some files, but that the package
>> can still be built, without being differerent from the one from the
>> first build.
>
> How about this then: if you debuild without -b, -B, or -nc, it builds a
> source package before building the binary packages.  What if it were to
> build another source package afterwards, and compare the two .diff.gz
> files?  Timestamps in the diff would be ignored.  But if the actual
> file contents of the diff were different, that would IMO be a bug.
> -- 
> Peter Samuelson | org-tld!p12n!peter | http://p12n.org/

debuild; debuild -S; debdiff  should give zero changes. Often enough
that isn't true though.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RFC: declaritive diversions

[Goswin von Brederlow]

Robert Collins <[EMAIL PROTECTED]> writes:

> Ian and I have chatted a few times about diversions in packages. It
> seems like it would be easier to look for packages that should divert
> (and don't), or do (and perhaps shouldn't :)) if the diversions were
> declared in the package rather than being done by turing complete
> code :).
>
> This is a long-promised email to kick start discussion about this.
>
> I don't have a proposed syntax at this point, but I was thinking a
> control file in the source such as debian/PACKAGENAME.diversions would
> be a good starting point - if thats able to record everything thats
> needed, even if the binaries stay as they are (doing diversions in the
> maintainer scripts) for now for compatibility this would improve things.
>
> -Rob

Did you see my earlier mail about the very same thing?

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: file mounted after debootstrap + udev

[Goswin von Brederlow]

[EMAIL PROTECTED] writes:

> Hi,
>
> I've been using debootstrap to produce my  live linux based on debian
> 2.6.18 .
> At first, my system was built with devfs and everything was fine .
> Recently, i moved to udev (i added kernel support + udev package) and
> although the live linux works just fine , after the "build process" -
> there are mounted files that i cannot remove from my development
> machine.
>
> If i try to delete my "working directory", i got the following error:
>
>   /bin/rm: cannot remove directory `working_dir/dev/.static/dev':
> Device or resource busy
>
> I've found out the following facts:
> 1. my build process installs an apache server
> 2. before running the build process , i had NO apache running
> 3. after running the build process , i an apache process is running
> 4. if i kill the apache process, umount the file , i can remove the
> directory
>
> My questions:
> - How come the build process starts an apache ? i thought it should
> just install it...
> - where should i look for the mount or apache installation scripts ?
>   (it's not my scripts...so i have no idea... i'm kinda a newbie in
> this
>   area...)
> - am i doing something wrong ? how can i prevent this behaviour ?
> - what's the "standard procedure" for building/installing a live
> linux   with apache ?
>
> tnx,
> zferentz

For this specific case see the other mails. But generally you need to
do the following (or at least check them unneccessary):

1. check for any processes left running in the chroot. Check the
/proc/root link of each pid and hope you have to fork bomb like
process in the chroot.

2. check for any filesystems left mounted below the chroot. Use
/proc/mounts and not /etc/mtab (or mount output) as that may be
incorrect.

3. remove working_dir

If any step fails you have to abort.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Any problems with mips/mipsel?

[Goswin von Brederlow]

Oleksandr Moskalenko <[EMAIL PROTECTED]> writes:

> * Frank Lichtenheld <[EMAIL PROTECTED]> [2007-07-05 13:01:36 +0200]:
>
>> You should check http://buildd.debian.org/ which will tell you that
>> both attempted to build your package but failed. Looks like a toolchain
>> issue to me. You could ask on @buildd.debian.org to retry the
>> package. Or you could try to find out first if the issue is fixed,
>> that might be easily possible or not.
>
> So, what can a developer do when builds for a package consistently fail on
> mips/mipsel? Buildd logs are not very helpful in this case since they just
> show uninformative assembler failure messages. I also made several unanswered
> requests to [EMAIL PROTECTED] for build-depends installation on
> any developer accessible mips/mipsel machine to try looking at the build to
> figure out the problem.
>
> I'm not sure what the next step to take would be.
>
> Alex.

Buy a Linksys router and use a chroot on nbd or nfs to build.

Have you asked on debian-mips for anyone to trace the problem? Most
maintainers won't be able to track gcc/binutils bugs.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Jon Dowland]

On Sun, Jul 15, 2007 at 10:57:10PM +0200, Daniel Leidert wrote:
> Maybe the Debian menu file format should follow the freedesktop.org
> specification too and contain something like:

> NoDisplay=true
> X-Debian_only=true

> to show, that the item should only appear in the Debian menu.

Argh. I really dislike the way that the debian menu is a sub-menu
shoe-horned into the gnome and KDE menus. I'd like whatever eventual
solution we come up with to present one root node.


-- 
Jon Dowland


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RFC: declaritive diversions

[Robert Collins]

On Tue, 2007-07-17 at 11:55 +0200, Goswin von Brederlow wrote:

> Did you see my earlier mail about the very same thing?

No I didn't, sorry.

I'm glad the concept seems to have positive reactions regardless.

-Rob
-- 
GPG key available at: .


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

Re: Bug#433143: ITP: bzr-rebase -- Rebase plugin for Bazaar

[Robert Collins]

On Mon, 2007-07-16 at 00:28 +0200, Stefano Zacchiroli wrote:


> I don't want to see a bzr-foo package in the archive for each .py module
> available on the internet which provides yet another sub-command for
> bzr. I asked under the (wrong) assumption that bzrtools was a Debian
> package shipping in a single Debian package several bzr addons. Under
> that assumption it seemed reasonable to avoid creating a new package,
> bug including your new addons as part of it.
> 
> Since my assumption was wrong: what about creating a "bzr-addons" Debian
> package containing the most used bzr addons out there instead of filing
> an ITP for just one?

I'd like to do the following:

 * rename the 'bazaar' package to 'baz' - both source and binary, though
binary is the key one. This is because it is no longer the recommended
tool from the 'Bazaar VCS Project' rather it is deprecated. Its useful
for conversions to bzr though, so keeping it as 'baz' is good.

 * Create a 'bazaar' package which is a metapackage depending on bzr,
recommending key plugins, and suggesting others.

-Rob
-- 
GPG key available at: .


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

Re: Upstream-only version dependency in debian/control

[Goswin von Brederlow]

Julian Andres Klode <[EMAIL PROTECTED]> writes:

> How about:
>  Depends: foo (>= 1.2.3), foo (<< 1.2.4~)
> or
>  Depends: foo (>= 1.2.3), foo (<< 1.2.3.0~)
>
> Julian 

% dpkg --compare-versions 1.2.3.0 ">>" 1.2.3a && echo yes
yes

Upstream might go crazy and add a text string to the verion. Or not so
crazy if you compare it to 1.2-3etch1.


A version ending in a digit can be extended by 'a~' while a version
ending in a letter should use '1~'.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Any problems with mips/mipsel?

[Petter Reinholdtsen]

[Mark Brown]
> Did you do this by mailing debian-admin or by using the request
> tracker[1]?  Requests sent via RT should have less chance of being
> missed.

Perhaps the link https://rt.debian.org/?user=guest&pass=readonly >
should be made more easily available on the Debian pages?

Happy hacking,
-- 
Petter Reinholdtsen


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Any problems with mips/mipsel?

[Mark Brown]

On Tue, Jul 17, 2007 at 01:03:09PM +0200, Petter Reinholdtsen wrote:
> [Mark Brown]
> > Did you do this by mailing debian-admin or by using the request
> > tracker[1]?  Requests sent via RT should have less chance of being
> > missed.

> Perhaps the link https://rt.debian.org/?user=guest&pass=readonly >
> should be made more easily available on the Debian pages?

Personally I expect half the problem is people just knowing that what
you need to do is mail debian-admin and not checking the web site at
all.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."


signature.asc
Description: Digital signature

Re: nepenthes_0.2.0-1(hppa/experimental): FTBFS: tries to use static library compiled without -fPIC

[Jan Wagner]

Hi Luciano,

On Wednesday 20 June 2007 19:15, Luciano Bello wrote:
>   I need your opinion and comments about: http://bugs.debian.org/399892
>   Nepenthes has a module (modulehoneytrap.so) linked with libipq (IPQ
> library for userspace), which is part of iptables-dev. Libipq looks like it
> only comes in a static form, and hence isn't built PIC.
>   Frank Lichtenheld <[EMAIL PROTECTED]> proposed to ask here.
>
> Please CC to the bug if you think is proper.

Any process with the issue?

Thanks and with kind regards, Jan.
-- 
Never write mail to <[EMAIL PROTECTED]>, you have been warned!
-BEGIN GEEK CODE BLOCK-
Version: 3.1
GIT d-- s+: a- C+++ UL P+ L+++ E- W+++ N+++ o++ K++ w--- O M V- PS PE
Y++ PGP++ t-- 5 X R tv- b+ DI- D++ G++ e++ h-- r+++ y+++
--END GEEK CODE BLOCK--


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

NMU's for non RC bugs

[Neil Williams]

In the process of fixing one RC bug (#359299) in order to fix another
(#289668) I am testing a possible fix for two other related bugs in the
first package (g-wrap) : 428800 and 383049 (just merged).

The related bug is currently only normal severity:
"g-wrap binary package depends on libgwrap-runtime0-dev instead
libgwrap-runtime0"
"Please drop guile-1.6-dev dependency for Gnucash"

guile-1.6-dev becomes part of the GnuCash dependency chain due to
g-wrap depending on libgwrap-runtime0-dev.

I have permission from the GnuCash maintainer for that NMU and I have
waited for a reply from the g-wrap maintainer without a response on my
NMU for 359299.

Neither 428800 nor 383049 have any response from the g-wrap maintainer
(Andreas Rottmann) in the bug reports although he is active (entry in
debian-devel-changes for 7/7/07).

So I'm asking here - Andreas, if you are around, do you agree that
g-wrap should not depend on libgwrap-runtime0-dev but
libgwrap-runetime0 instead? Are you in a position to upload a fix or can
I include it in my existing NMU?

Everyone else: If Andreas does not respond, is there any way of fixing
428800 and 383049? Are the issues worth an RC bug anyway?

I don't mind making two NMU's, if that helps clarify the different
issues.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/



pgpUOfaJhX5wE.pgp
Description: PGP signature

Re: NMU's for non RC bugs

[Steinar H. Gunderson]

On Tue, Jul 17, 2007 at 12:27:18PM +0100, Neil Williams wrote:
> Everyone else: If Andreas does not respond, is there any way of fixing
> 428800 and 383049? Are the issues worth an RC bug anyway?

For non-RC bugs, the normal (ie. non-0-day) NMU policy applies, as outlined
in the Developer's reference. There's nothing saying you can't NMU for non-RC
bugs -- in fact, Debian would probably be a better place if we were better at
NMUing for other bugs as well.

/* Steinar */
-- 
Homepage: http://www.sesse.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Javier Fernández-Sanguino Peña]

On Tue, Jul 17, 2007 at 09:42:48AM +0200, Josselin Mouette wrote:
> > Okay, as long as it can easily be configured, I see no problem in
> > disabling it by default.  But there should be either a prominent menu
> > entry which is easy to find, or a README.Debian in an obvious package.
> 
> If disabled with NoDisplay=true, you can easily re-enable the Debian
> menu in alacarte (accessible with a right click and "edit menus"). Would
> that suit you?

Please note that 'alacarte' is not part of gnome-core. I'm not very into
GNOME but a *different* application seems to get executed for editing menus
if you don't have the 'gnome-desktop-environment' meta-package (which pulls
in alacarte) but just have gnome-core.

If alacarte should be a core tool (as you seem to imply) maybe it should be
pulled in by gnome-core. Otherwise users will get different behaviours
depending on their package selection (full GNOME desktop vs. minimalistic
GNOME desktop). Don't you think?

Regards

Javier


signature.asc
Description: Digital signature

Re: NMU's for non RC bugs

[Luk Claes]

Neil Williams wrote:
> In the process of fixing one RC bug (#359299) in order to fix another
> (#289668) I am testing a possible fix for two other related bugs in the
> first package (g-wrap) : 428800 and 383049 (just merged).
> 
> The related bug is currently only normal severity:
> "g-wrap binary package depends on libgwrap-runtime0-dev instead
> libgwrap-runtime0"
> "Please drop guile-1.6-dev dependency for Gnucash"
[...]
> Everyone else: If Andreas does not respond, is there any way of fixing
> 428800 and 383049? Are the issues worth an RC bug anyway?

I don't see any reason why you wouldn't include it in the NMU you are doing
anyway.

> I don't mind making two NMU's, if that helps clarify the different
> issues.

The bugs are filed as seperate issues, you could send different patches,
though I think one patch for all the bugs will probably be clear enough anyway
for these kind of bugs.

Cheers

Luk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Josselin Mouette]

Le mardi 17 juillet 2007 à 14:35 +0200, Javier Fernández-Sanguino Peña a
écrit :
> Please note that 'alacarte' is not part of gnome-core. I'm not very into
> GNOME but a *different* application seems to get executed for editing menus
> if you don't have the 'gnome-desktop-environment' meta-package (which pulls
> in alacarte) but just have gnome-core.
> 
> If alacarte should be a core tool (as you seem to imply) maybe it should be
> pulled in by gnome-core. Otherwise users will get different behaviours
> depending on their package selection (full GNOME desktop vs. minimalistic
> GNOME desktop). Don't you think?

Well, I don't think the ability to edit menus, be it for adding the
Debian menu or something else, is a core feature. We're talking about
the default behaviour here and the default GNOME installation is
gnome-desktop-environment.

Anyway, maybe we could add alacarte to gnome-panel's Recommends: to
avoid that.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.

Re: adding desktop files to misc packages

[Javier Fernández-Sanguino Peña]

On Tue, Jul 17, 2007 at 09:36:53AM +0200, Josselin Mouette wrote:
> Le lundi 16 juillet 2007 à 20:44 +0200, Javier Fernández-Sanguino Peña a
> écrit :
> > It looks to me like they are properly categorised and its the GNOME menu
> > which is misbehaving
> 
> I have indeed to back out my previous claim. I'm going to work on fixing
> this issue in gnome-menus.

Thanks for looking into this. Surprisingly, this thread seems to have sparked
some good things :)

Regards

Javier


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#433467: ITP: xorp -- eXtensible Open Router Platform

[Jose Calhariz]

Package: wnpp
Severity: wishlist
Owner: Jose Calhariz <[EMAIL PROTECTED]>

* Package name: xorp
  Version : 1.4
  Upstream Author : International Computer Science Institute in Berkeley
* URL : http://www.xorp.org
* License : BSD Like
  Programming Lang: C++
  Description : eXtensible Open Router Platform

 The goal is to develop an open source software router platform that
 is stable and fully featured enough for production use, and flexible
 and extensible enough to enable network research. Currently XORP
 implements routing protocols for IPv4 and IPv6 and a unified means to
 configure them. In future, we would also like to support custom
 hardware and software forwarding architectures.
 
 XORP is free. It is covered by a BSD-style license and is publicly
 available for research, development, and use.
 
 The core team is based at the International Computer Science
 Institute in Berkeley, California, but contributors come from around
 the world.


-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-amd64
Locale: LANG=C, LC_CTYPE=pt_PT.UTF-8 (charmap=UTF-8)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#433472: ITP: dirbuster -- Directory & file brute forcing, with a twist

[Tim Brown]

Package: wnpp
Severity: wishlist
Owner: Tim Brown <[EMAIL PROTECTED]>

* Package name: dirbuster
  Version : 0.9.7
  Upstream Author : James Fisher <[EMAIL PROTECTED]>
* URL : http://sourceforge.net/projects/dirbuster/
* License : LGPL
  Programming Lang: Java
  Description : Directory & file brute forcing, with a twist

DirBuster is a multi threaded java application designed to brute force
directories and files names on web/application servers. Often is the case
now of what looks like a web server in a state of default installation is
actually not, and has pages and applications hidden within. DirBuster
attempts to find these

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.18 (SMP w/1 CPU core)
Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Steve Greenland]

On 17-Jul-07, 02:05 (CDT), Josselin Mouette <[EMAIL PROTECTED]> wrote: 
> Le lundi 16 juillet 2007 ? 19:08 -0500, Steve Greenland a ?crit :
> > > Some of the users we target don't even know what a window manager is,
> > > and they don't want to know it.
> > 
> > Some of the users we target don't use any desktop environment, running
> > headless servers. So let's remove KDE and GNOME.
> 
> If you have nothing to say apart proving that you don't want to
> understand what people write, what's the point of contributing to a
> mailing list?

You keep saying that because you don't use particular menu entries, and
because you don't understand why anyone would use those menu entries,
they should be removed. When others say that they *do* find those
entries useful, you say that well, we're not the important users, and
our use of those menu entries is irrelevant, and we can work around the
inconvenience.

My point, which I tried to make through what I thought was obvious
humorous exageration, was that NOBODY uses all of Debian. There are
huge chunks that I'll never use. To *me* they are useless clutter -
they make Package file downloads larger, they make finding things via
aptitude and apt-cache search more inconvenient, they fill up my disk
with useless translations. But because I agree with the "Debian is the
universal operating system" sentiment, I don't spend time trying to get
that "useless clutter" removed. I accept that many people find that
functionality useful, and get on with it.

If you and the other GNOME maintainers thing your primary users would
be better served by removing the Debian menu entries by default, that's
fine. No one would have batted an eye, so long as it was easy to
re-enable (and yes, I'd consider "edit this file in /etc" sufficiently
easy to qualify). But that's not what you wrote. You wanted to eliminate
big chunks of the Debian menu system[1] that you didn't think were
useful,

Regards,
Steve

[1] That may not be what you *intended*. But I'm not the only one who
read it that way.

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#433143: ITP: bzr-rebase -- Rebase plugin for Bazaar

[Steve Greenland]

On 17-Jul-07, 05:19 (CDT), Robert Collins <[EMAIL PROTECTED]> wrote: 
> 
> I'd like to do the following:
> 
>  * rename the 'bazaar' package to 'baz' - both source and binary, though
> binary is the key one. This is because it is no longer the recommended
> tool from the 'Bazaar VCS Project' rather it is deprecated. Its useful
> for conversions to bzr though, so keeping it as 'baz' is good.
> 
>  * Create a 'bazaar' package which is a metapackage depending on bzr,
> recommending key plugins, and suggesting others.

Wouldn't that cause people who currently have "bazaar" (the package)
installed to suddenly change from 'baz' (aka "bazaar the old SCM tool")
to 'bzr' (the new SCM tool)? That seems like a bad idea.

Steve

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Manoj Srivastava]

On Tue, 17 Jul 2007 15:01:19 +0200, Josselin Mouette <[EMAIL PROTECTED]> said: 

> Le mardi 17 juillet 2007 à 14:35 +0200, Javier Fernández-Sanguino Peña
> a écrit :
>> Please note that 'alacarte' is not part of gnome-core. I'm not very
>> into GNOME but a *different* application seems to get executed for
>> editing menus if you don't have the 'gnome-desktop-environment'
>> meta-package (which pulls in alacarte) but just have gnome-core.
>> 
>> If alacarte should be a core tool (as you seem to imply) maybe it
>> should be pulled in by gnome-core. Otherwise users will get different
>> behaviours depending on their package selection (full GNOME desktop
>> vs. minimalistic GNOME desktop). Don't you think?

> Well, I don't think the ability to edit menus, be it for adding the
> Debian menu or something else, is a core feature. We're talking about
> the default behaviour here and the default GNOME installation is
> gnome-desktop-environment.

How easy is it for users to add/remove the debian menu hierarchy
 to their GNOME menus?  Can different users on the same machine have
 different customized menus easily?

manoj
-- 
The more things change, the more they stay insane.
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#433143: ITP: bzr-rebase -- Rebase plugin for Bazaar

[Manoj Srivastava]

On Tue, 17 Jul 2007 20:19:59 +1000, Robert Collins
<[EMAIL PROTECTED]> said:  

>  * rename the 'bazaar' package to 'baz' - both source and binary,
>though binary is the key one. This is because it is no longer the
>recommended  tool from the 'Bazaar VCS Project' rather it is
>deprecated. Its useful  for conversions to bzr though, so keeping
>it as 'baz' is good. 

That is not the only use for it. bzr is an inplementation of
 Arch, and there are people who have not bought the 'Bazaar VCS Project'
 koolaid, and still prefer Arch to the new VCS.

>  * Create a 'bazaar' package which is a metapackage depending on bzr,
> recommending key plugins, and suggesting others.

This would be a bug.  While I understand you prefer the bzr VCS
 over Arch, I see no justification for imposing your likes and dislikes
 over users happily using baz as their version control system.  I would
 be most annoyed if baz would have been replaced by bzr on my systems if
 the sysadmin dude did not notice the change.

A note in NEWS.Debian about your preferred VCS would be OK, I
 suppose, but please come up with a bewtter upgrade plan for current
 users of baz.

manoj
-- 
The goal of Computer Science is to build something that will last at
least until we've finished building it.
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: debdelta service back on track

[Mark Brown]

On Tue, Jul 17, 2007 at 11:23:53AM +0200, A Mennucc wrote:

> The problem was due to a subtle change in zlib1g: in newer versions, the
> compressed output has 0x02 instead of 0x00 at the 10th byte (that is in
> the header). This change occurred somewhere between version 1.2.3-13 and
> 1.2.3.3.dfsg-5 .

Byte 10 is the XFL field which contains compression method specific
flags.  For deflate a value of two indicates that the compressor was
aiming for maximum compression and a value of zero indicates nothing in
particular.  The code was previously not bothering to provide any
information about how hard it was trying to compress things.

> (I am sending a CC to the upstream authors and to the Debian Mantainer,
> in case they are not aware of this change).

Not that it's likely to be important but you've only CCed me, not
upstream.

>  Since dpkg-deb uses zlib1g, this changed the .deb files. So a file
> reconstructed by "debpatch" would be different with the original in 2
> bytes.

Two bytes?

> I have added a workaround for that problem in 'debdelta' version 0.21 ,
> and I have installed it in the server that prepares deltas for
> 'debdelta-upgrade' . Now it should work again as expected. (If it does
> not, mail me, or send a bug in the BTS).

I'm not sure exactly what debdelta is doing here but it sounds like
it ought to have specific code for handing the reconstruction of this
header in order to be robust against reasonable upstream changes.  There
are several fields in there which are informational and could be varied
by the compressor pretty much at will.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."


signature.asc
Description: Digital signature

Re: adding desktop files to misc packages

[Josselin Mouette]

Le mardi 17 juillet 2007 à 08:50 -0500, Steve Greenland a écrit :
> > If you have nothing to say apart proving that you don't want to
> > understand what people write, what's the point of contributing to a
> > mailing list?
> 
> You keep saying that because you don't use particular menu entries, and
> because you don't understand why anyone would use those menu entries,
> they should be removed.

They should be removed *by default*.

> When others say that they *do* find those
> entries useful, you say that well, we're not the important users, and
> our use of those menu entries is irrelevant, and we can work around the
> inconvenience.

Well, if the maintainers have the extra burden to support two distinct
menu systems, I'd understand their will to only support the one that
works best.

> My point, which I tried to make through what I thought was obvious
> humorous exageration, was that NOBODY uses all of Debian.

Apart from sarcasm being different from humour, that is obvious.

> There are
> huge chunks that I'll never use. To *me* they are useless clutter -
> they make Package file downloads larger, they make finding things via
> aptitude and apt-cache search more inconvenient, they fill up my disk
> with useless translations. But because I agree with the "Debian is the
> universal operating system" sentiment, I don't spend time trying to get
> that "useless clutter" removed. I accept that many people find that
> functionality useful, and get on with it.

Good for you. I think that we would be able to better serve our users if
we removed useless and/or unmaintained and/or buggy software from our
archive. I'm not saying any software which isn't used by 90% of them
should be removed, as you seem to imply, but we should reduce the
functionality we are providing so that we can keep our quality level.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.

Re: FTBFS if built twice in a row

[Russ Allbery]

Goswin von Brederlow <[EMAIL PROTECTED]> writes:
> Russ Allbery <[EMAIL PROTECTED]> writes:

>> Not if you use pdebuild or similarly build in a chroot, which IMO
>> everyone should be doing.

> I use xen instances and that changes nothing at all.

> 1. My ~/src is mounted inside the build environment so I don't have to
> copy the source around all the time

So don't do that and then everything works.

I'm not saying it's ideal, but this really isn't that difficult to work
around in practice, and the alternative is a lot more package maintenance
work to track down the autogenerated files that's both finnicky and
fragile.  Right now, it's my opinion that we're optimizing for the common
case.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Josselin Mouette]

Le mardi 17 juillet 2007 à 09:02 -0500, Manoj Srivastava a écrit :
> How easy is it for users to add/remove the debian menu hierarchy
>  to their GNOME menus?  Can different users on the same machine have
>  different customized menus easily?

  * Right-click on the main menu
  * Click on "Edit menus..."
  * Check or uncheck the box near "Debian"
  * Close the window

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.

Re: Can we require build-arch/indep targets for lenny?

[Russ Allbery]

Goswin von Brederlow <[EMAIL PROTECTED]> writes:
> Russ Allbery <[EMAIL PROTECTED]> writes:

>> Based on the arguments I've seen so far, I'm opposed to using the
>> package's Standards-Version for this purpose.  I think it conflates
>> different meanings of that field and will get us into serious trouble
>> when it comes to the distinctions between must, should, and
>> recommended.

> | Policy 5.6.11 Standards-Version
> |
> | The most recent version of the standards (the policy manual and
> | associated texts) with which the package complies.

> This field has exactly this meaning. It says the package followes a
> certain version of policy, e.g. the one where now there is a MUST
> instead of the previous RECOMMENDS.

You seem to be ignoring the end of second sentence of my paragraph above,
which I wrote precisely because I anticipated this argument.  Could you
respond to it as well?  Not every feature we care about is going to be a
must.

I would much prefer to see a new control field that explicitly lists the
supported features.  We're going to need that *anyway* for any feature
that's only a should or recommended and not a must (such as supporting
noopt or nostrip), and making every should into a must just so that we can
use this interpretation of Standards-Version is not a solution.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Co-Maintainer for libdbi-perl wanted

[Gunnar Wolf]

Raphael Hertzog dijo [Tue, Jul 17, 2007 at 10:37:47AM +0200]:
> You could integrate the package in the pkg-perl repository and you'd have
> lots of co-maintainers for free. :-)
> 
> http://pkg-perl.alioth.debian.org
> 
> Other interested co-maintainers which are not yet part of the pkg-perl team
> are also welcome to join of course.
> 
> If you're interested, just tell us and we'll add you to the team.

Not only that, several of us owe our life to DBI, so will be more than
glad to work on it ;-)

Anyway, you can co-maintain it with the team even without joining, if
you prefer it that way... Although it would be awkward
(i.e. coordinating SVN work and such) - I do recommend you to join. We
won't load your back with unrelated bugs ;-)

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Frank Küster]

Josselin Mouette <[EMAIL PROTECTED]> wrote:

>> When others say that they *do* find those
>> entries useful, you say that well, we're not the important users, and
>> our use of those menu entries is irrelevant, and we can work around the
>> inconvenience.
>
> Well, if the maintainers have the extra burden to support two distinct
> menu systems, I'd understand their will to only support the one that
> works best.

That's obviously a criterion which won't help, since people have
different opinions about which works best.

But it's actually an argument for better interoperability between both,
i.e. better creation of .desktop files from menu and vice versa.

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: adding desktop files to misc packages

[Javier Fernández-Sanguino Peña]

On Tue, Jul 17, 2007 at 09:02:33AM -0500, Manoj Srivastava wrote:
> How easy is it for users to add/remove the debian menu hierarchy
>  to their GNOME menus?  

Very easy (if using alacarte). Not possible if using the barebones menu
editor (the one you get with gnome-core, don't know the application's name)

> Can different users on the same machine have
>  different customized menus easily?

Ditto.

I think the following question is also relevant:

"Can the system administrator edit system-wide menus for all users?"
(add/remove Debian menu hierarchy)

A: AFAIK not (in GNOME) currently, even when using alacarte
(see http://bugzilla.gnome.org/show_bug.cgi?id=372861). I believe the only
way currently is editing /etc/xdg/menus/ manually.

Regards

Javier


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#433143: ITP: bzr-rebase -- Rebase plugin for Bazaar

[Adeodato Simó]

* Manoj Srivastava [Tue, 17 Jul 2007 09:11:45 -0500]:

> >  * Create a 'bazaar' package which is a metapackage depending on bzr,
> > recommending key plugins, and suggesting others.

> This would be a bug.  While I understand you prefer the bzr VCS
>  over Arch, I see no justification for imposing your likes and dislikes
>  over users happily using baz as their version control system.  I would
>  be most annoyed if baz would have been replaced by bzr on my systems if
>  the sysadmin dude did not notice the change.

Well, the issue at hand is that the upstream authors of Bazaar 1.x have
renamed it to "baz", and given away their name to some other project
(bzr). Sooner or latter the packages will have to reflect *that*.

Cheers,

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
Debugging is twice as hard as writing the code in the first place. Therefore,
if you write the code as cleverly as possible, you are, by definition, not
smart enough to debug it.
-- Brian W. Kernighan


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#433535: ITP: libset-nestedgroups-perl -- Simple implementation of nested groups

[Gunnar Wolf]

Package: wnpp
Severity: wishlist
Owner: Gunnar Wolf <[EMAIL PROTECTED]>


* Package name: libset-nestedgroups-perl
  Version : 0.01
  Upstream Author : Alan Barclay <[EMAIL PROTECTED]>
* URL : http://www.cpan.org/modules/by-module/Set
* License : Artistic + GPL
  Programming Lang: Perl
  Description : Simple implementation of nested groups

 Set::NestedGroups gives an implementation of nested groups,
 access control lists (ACLs) would be one example of
 nested groups.

 For example, if Joe is a Manager, and Managers have access to payroll,
 you can create an ACL which implements these rules, then ask the ACL
 if Joe has access to payroll.

 Another example, you may wish to track which city, state and country
 people are in, by adding people to cities, cities to states, and states
 to countries.

 This module includes some facilities to integrate its data structures
 with either files in the local filesystem and with tables in a RDBMS.

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.21-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Steve Greenland]

On 17-Jul-07, 10:33 (CDT), Josselin Mouette <[EMAIL PROTECTED]> wrote:
> I think that we would be able to better serve our users if we removed
> useless and/or unmaintained and/or buggy software from our archive.

Those three things are not comparable. "Unmaintained" and "buggy" are,
to at least some extent, objective criterion. "Useless" is a matter of
opinion. Is 'nvi' useless? Not to me, but I'd guess that a great many of
our users would think so. Who decides?

And to comment on another of your points: yes, requiring two menu
formats is silly. If the FDo format is a complete superset of the debian
menu format, then transitioning to FDo format is a fine proposal.
Someone (Bruce Sass?) proposed a straightforward transition plan. 

Steve
-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Any problems with mips/mipsel?

[Oleksandr Moskalenko]

* Goswin von Brederlow <[EMAIL PROTECTED]> [2007-07-17 12:06:19 +0200]:

> Oleksandr Moskalenko <[EMAIL PROTECTED]> writes:
> 
> > * Frank Lichtenheld <[EMAIL PROTECTED]> [2007-07-05 13:01:36 +0200]:
> >
> >> You should check http://buildd.debian.org/ which will tell you that
> >> both attempted to build your package but failed. Looks like a toolchain
> >> issue to me. You could ask on @buildd.debian.org to retry the
> >> package. Or you could try to find out first if the issue is fixed,
> >> that might be easily possible or not.
> >
> > So, what can a developer do when builds for a package consistently fail on
> > mips/mipsel? Buildd logs are not very helpful in this case since they just
> > show uninformative assembler failure messages. I also made several 
> > unanswered
> > requests to [EMAIL PROTECTED] for build-depends installation on
> > any developer accessible mips/mipsel machine to try looking at the build to
> > figure out the problem.
> >
> > I'm not sure what the next step to take would be.
> >
> > Alex.
> 
> Buy a Linksys router and use a chroot on nbd or nfs to build.
> 
> Have you asked on debian-mips for anyone to trace the problem? Most
> maintainers won't be able to track gcc/binutils bugs.
> 
> MfG
> Goswin

Goswin,

Thanks for the answer. I was going to follow mrvn's suggestion on #d-d to try
breaking some of the routines in the offending source file into smaller chunks
and going through the loops to make sure there is nothing really big there
that will be out of assembler opcode storage size. In the meanwhile, I'm
subscribing to the debian-mips list to ask people there to trace the problem.
Thanks for the suggestion.

Regards,

Alex.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Josselin Mouette]

Le mardi 17 juillet 2007 à 09:36 +0200, Josselin Mouette a écrit :
> Le lundi 16 juillet 2007 à 20:44 +0200, Javier Fernández-Sanguino Peña a
> écrit :
> > It looks to me like they are properly categorised and its the GNOME menu
> > which is misbehaving
> 
> I have indeed to back out my previous claim. I'm going to work on fixing
> this issue in gnome-menus.

This is now done in the pkg-gnome SVN. I'm waiting for translations for
the submenus names before uploading.

(BTW, anyone can remind me of the procedure to ask for a supplementary
po/ directory to be translated?)

If some people find other menus to be too large on their desktop, just
tell me or file a bug; this procedure can be extended.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: Bug#433143: ITP: bzr-rebase -- Rebase plugin for Bazaar

[Steve Greenland]

On 17-Jul-07, 12:56 (CDT), Adeodato Sim?? <[EMAIL PROTECTED]> wrote: 
> * Manoj Srivastava [Tue, 17 Jul 2007 09:11:45 -0500]:
> 
> > >  * Create a 'bazaar' package which is a metapackage depending on bzr,
> > > recommending key plugins, and suggesting others.
> 
> > This would be a bug.  While I understand you prefer the bzr VCS
> >  over Arch, I see no justification for imposing your likes and dislikes
> >  over users happily using baz as their version control system.  I would
> >  be most annoyed if baz would have been replaced by bzr on my systems if
> >  the sysadmin dude did not notice the change.
> 
> Well, the issue at hand is that the upstream authors of Bazaar 1.x have
> renamed it to "baz", and given away their name to some other project
> (bzr). Sooner or latter the packages will have to reflect *that*.

Fine. Figure out a way to transition that doesn't involve automatically
replacing baz with bzr.

Or, just include in the bazaar package long description "This is baz,
not bzr. You probably want the bzr package, instead."

Or, just have 'bazaar' depend on *both* baz and bzr. 

Steve

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#433555: ITP: cnijfilter -- Canon inkjet printer drivers for CUPS

[Nikolaus Schulz]

Package: wnpp
Severity: wishlist
Owner: Nikolaus Schulz <[EMAIL PROTECTED]>

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: cnijfilter
  Version : 2.70
  Upstream Author : Canon Inc. 
* URL : http://cweb.canon.jp/drv-upd/bj/other.html
* License : partly GPL, partly non-free
  Description : Canon inkjet printer drivers for CUPS

 This driver provides printing functions for Canon inkjet printers
 operating under the CUPS (Common UNIX Printing System) environment.
 This includes setting printer-specific options like printing quality,
 quiet operation mode, maintenance functions like cleaning the print
 heads, and monitoring printer status like ink level, paper jam, cover
 opened, and so on.


NOTES
- -

I am not sure if the wnpp bug is the right place for such annotations,
but there are *so* many peculiarities with this package, which makes me
feel the most important should be mentioned here.

This is actually about several packages, and it is a *very* messy thing.
For a start, there is no canonical english web site for these packages,
the URL in the package description is japanese only.  (Ugh!)  If you are
like me and don't speak japanese, you may want to proxy the site with a
translation service like [1].  There is also an ftp address for most
packages, but it doesn't work for everyone:
ftp://download.canon.jp/pub/driver/bj/linux.

Since the licence is partly non-free, I will post it to debian-legal in
the next days for advice.  (I am optimistic that it allows distribution.)

If all goes well, there will be several Debian packages for each
supported printer.  I have not yet determined how these are best
organized, both as source and binary packages; unfortunately the
upstream tarballs are non-standard (in lots of ways), for example 
their organization varies (!, *argh*) from split tarballs to big,
combined source rpm's (oh boy!).

The non-free material from Canon is a couple of binary-only libraries,
covered by a special licence.  (Ouch!)  All other programs are GPL,
plus, where needed, a special exception allowing to link against the
said libraries. 

The packages are actively developed upstream (good!), but not maintained
(what?!): each released version supports the then-current printer models
only, and is not maintained after release. (Oh ${DEITY}!)  

So, I plan to make versioned source packages like cnijfilter2.7, and try
to backport some stuff to older versions that support older printers.
The mapping between driver versions and supported printer models is
here (but see the note below). 

v2.0: BJ S500.
v2.1: BJ F900/BJ F9000/BJ S300.
v2.2: Pixus 550i/Pixus 850i/Pixus 950i.
v2.3: i250/i255.
v2.4: Pixus 560i/Pixus 860i/Pixus 990i.
v2.5: Pixma iP1000/Pixma iP1500/Pixus iP3100/Pixus iP4100/Pixus iP8600.
v2.6: iP2200/iP4200/iP7500/iP6600D/MP500.
v2.7: iP3300/MP510/iP4300/MP600/MP160/iP2500 series/iP1800 series/iP90.

Depending on the country, at least some of the model names varied.  E.g.
the "Pixus 550i" was sold as such in Japan, but in Europe (and I think
in USA, too) it was called "Canon i550". 

Since I have such a i550 printer, I've started with v2.2 of the driver.
When these packages are ready and tested, I'll continue the way up to
v2.7.  Testers with printers listed above are welcome!  (Oh, you say you
want to co-maintain this evil thing?  Even better!  But you have been
warned. :-)

Finally note that, as of v2.6, the upstream packages were renamed from
"bjfilter" to "cnijfilter".  So much for the broad overview; I hope I
didn't forget anything essential.  I'll probably turn up soon with some
more dirty details on debian-mentors. :-) 

Cheers, 
Nikolaus


[1] http://babelfish.altavista.com/babelfish

- -- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.4.27-deb.171206
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFGnTUw6A8tMErBwasRAtjBAJ9Oh/StgtjGpBQFdIPXFgcSRaMZkQCg3w5l
A16Kf69wllnxZchqUiPp6Dc=
=Yy3/
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#433555: ITP: cnijfilter -- Canon inkjet printer drivers for CUPS

[Evgeni Golov]

Hi Nikolaus,

On Tue, 17 Jul 2007 23:31:29 +0200 Nikolaus Schulz wrote:

> * Package name: cnijfilter
>   Version : 2.70
>   Upstream Author : Canon Inc. 
> * URL : http://cweb.canon.jp/drv-upd/bj/other.html
> * License : partly GPL, partly non-free
>   Description : Canon inkjet printer drivers for CUPS

Are you aware of these packages:
http://mambo.kuhp.kyoto-u.ac.jp/~takushi/#canon ?
I think they do contain the same tools ;)

Regards
Evgeni


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#433143: ITP: bzr-rebase -- Rebase plugin for Bazaar

[Manoj Srivastava]

On Tue, 17 Jul 2007 19:56:05 +0200, Adeodato Simó <[EMAIL PROTECTED]> said: 

> * Manoj Srivastava [Tue, 17 Jul 2007 09:11:45 -0500]:
>> >  * Create a 'bazaar' package which is a metapackage depending on
>> >bzr,
>> > recommending key plugins, and suggesting others.

>> This would be a bug.  While I understand you prefer the bzr VCS over
>> Arch, I see no justification for imposing your likes and dislikes
>> over users happily using baz as their version control system.  I
>> would be most annoyed if baz would have been replaced by bzr on my
>> systems if the sysadmin dude did not notice the change.

> Well, the issue at hand is that the upstream authors of Bazaar 1.x
> have renamed it to "baz", and given away their name to some other
> project (bzr). Sooner or latter the packages will have to reflect
> *that*.

Oh, certainly. Renaming a package, and providing an upgrade
 path, are simple procedures we have tonnes of examples of, and should
 be relatively straight forward to implement.

So, in lenny, the name can change from bazaar to baz; leaving
 the package name bazaar vacant in lenny + 1.

The fact that bzr now wants the name bazaar can be treated like
 any other name conflict -- bzr wants a name that is currently used by
 baz; and the process I outlined above would allow baz to let go of the
 name; and bzr gain it, in time for  lenny + 1.

Prior to that, I don't think there is a sane way for bzr to take
 over the name currently used by baz -- but I am willing to listen to
 any working transition plan.

manoj
-- 
"We learn from history that we learn nothing from history." George
Bernard Shaw
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#433566: ITP: cryptkeeper -- encfs system tray applet for GNOME

[Francesco Namuri]

Package: wnpp
Severity: wishlist
Owner: Francesco Namuri <[EMAIL PROTECTED]>


* Package name: cryptkeeper
  Version : 0.7.666
  Upstream Author : Tom Morton <[EMAIL PROTECTED]>
* URL : http://www.tomatarium.pwp.blueyonder.co.uk/cryptkeeper.html
* License : GPL
  Programming Lang: C++
  Description : EncFS system tray applet for GNOME

An encrypted folders manager, it allows to mount and umount, to create
new folders, to change the password of each mount. It integrates with
your preferred file manager.

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (850, 'unstable'), (200, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.22-rc5-custom.1 (SMP w/1 CPU core)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#433143: ITP: bzr-rebase -- Rebase plugin for Bazaar

[Ben Finney]

Manoj Srivastava <[EMAIL PROTECTED]> writes:

>  bzr is an inplementation of Arch, and there are people who have not
>  bought the 'Bazaar VCS Project' koolaid, and still prefer Arch to
>  the new VCS.

'bzr' is not an implementation of Arch. At best, it is strongly
inspired by work the developers did on 'baz', which *was* an
implementation of Arch.

With the 'bzrtools' package installed, it's (sometimes) possible to do
a one-way import of existing 'baz' branches or repositories. That's
useful for those who know they're transitioning to an entirely new
VCS, and want to do so.

> Robert Collins wrote:
> >  * Create a 'bazaar' package which is a metapackage depending on bzr,
> > recommending key plugins, and suggesting others.
>
> This would be a bug.  While I understand you prefer the bzr VCS
>  over Arch, I see no justification for imposing your likes and dislikes
>  over users happily using baz as their version control system.

I agree; the older 'baz' VCS is what currently gets installed with the
'bazaar' package, and the 'bzr' VCS is not a compatible replacement.

-- 
 \"Members of the general public commonly find copyright rules |
  `\ implausible, and simply disbelieve them."  -- Jessica Litman, |
_o__)  _Digital Copyright_ |
Ben Finney


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#433472: ITP: dirbuster -- Directory & file brute forcing, with a twist

[David Nusinow]

On Tue, Jul 17, 2007 at 01:46:03PM +0100, Tim Brown wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Tim Brown <[EMAIL PROTECTED]>
> 
> * Package name: dirbuster
>   Version : 0.9.7
>   Upstream Author : James Fisher <[EMAIL PROTECTED]>
> * URL : http://sourceforge.net/projects/dirbuster/
> * License : LGPL
>   Programming Lang: Java
>   Description : Directory & file brute forcing, with a twist
> 
> DirBuster is a multi threaded java application designed to brute force
> directories and files names on web/application servers. Often is the case
> now of what looks like a web server in a state of default installation is
> actually not, and has pages and applications hidden within. DirBuster
> attempts to find these

This is a pretty poor description. I don't really know what it means to
"brute force directories and files names". Starting the description with
something like "DirBuster is an application designed for finding hidden
files and applications on a server" might be a better way to go.

 - David Nusinow


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#433143: ITP: bzr-rebase -- Rebase plugin for Bazaar

[Robert Collins]

On Tue, 2007-07-17 at 19:56 +0200, Adeodato Simó wrote:
> * Manoj Srivastava [Tue, 17 Jul 2007 09:11:45 -0500]:
> 
> > >  * Create a 'bazaar' package which is a metapackage depending on bzr,
> > > recommending key plugins, and suggesting others.
> 
> > This would be a bug.  While I understand you prefer the bzr VCS
> >  over Arch, I see no justification for imposing your likes and dislikes
> >  over users happily using baz as their version control system.  I would
> >  be most annoyed if baz would have been replaced by bzr on my systems if
> >  the sysadmin dude did not notice the change.
> 
> Well, the issue at hand is that the upstream authors of Bazaar 1.x have
> renamed it to "baz", and given away their name to some other project
> (bzr). Sooner or latter the packages will have to reflect *that*.

A small data point : its always been 'baz' as the command, we just were
not as clear about the difference between the individual command and the
overall system as we are now.

-Rob
-- 
GPG key available at: .


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

Re: Bug#433143: ITP: bzr-rebase -- Rebase plugin for Bazaar

[Robert Collins]

On Tue, 2007-07-17 at 09:11 -0500, Manoj Srivastava wrote:
> On Tue, 17 Jul 2007 20:19:59 +1000, Robert Collins
> <[EMAIL PROTECTED]> said:  
> 
> >  * rename the 'bazaar' package to 'baz' - both source and binary,
> >though binary is the key one. This is because it is no longer the
> >recommended  tool from the 'Bazaar VCS Project' rather it is
> >deprecated. Its useful  for conversions to bzr though, so keeping
> >it as 'baz' is good. 
> 
> That is not the only use for it. bzr is an inplementation of
>  Arch, and there are people who have not bought the 'Bazaar VCS Project'
>  koolaid, and still prefer Arch to the new VCS.

Thats fine, they are welcome to keep using Arch. 'baz' itself is
unmaintained, though many of the patches in it relative to 'tla' have
been incorporated upstream.

> >  * Create a 'bazaar' package which is a metapackage depending on bzr,
> > recommending key plugins, and suggesting others.
> 
> This would be a bug.  While I understand you prefer the bzr VCS
>  over Arch, I see no justification for imposing your likes and dislikes
>  over users happily using baz as their version control system.  I would
>  be most annoyed if baz would have been replaced by bzr on my systems if
>  the sysadmin dude did not notice the change.

Curiosity: I take it then that you are still using baz, rather than
tla? 

> A note in NEWS.Debian about your preferred VCS would be OK, I
>  suppose, but please come up with a bewtter upgrade plan for current
>  users of baz.

A starting point is to do the package rename with upgrades and not
introduce a bazaar metapackage for a release. Or at least for some
arbitrary timeframe, as that can be more precisely defined.

-Rob

-- 
GPG key available at: .


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

Re: adding desktop files to misc packages

[Joe Smith]

"Don Armstrong" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

So it seems like we should do the following:

1. Make changes to the menu system to use .desktop files in preference
to .menu files when they exist

2. Generate .desktop files from .menu files using the menu system when
.desktop files don't exist.

3. Continue using the menu system for window managers which don't
natively understand .desktop files; drop the Debian menu for those
that do.

The other issue that was brought up was improving the hierarchical
organization of the menus, but how to do that hasn't been made clear
in this thread.



That is exactly the correct thing to do. It has the advantage of basically 
converting Debian to the stardard FDO .desktop format.
It also effectively adds limited support for the FDO format to the other 
window managers (the menu system would be converting the .desktop files of 
any installed package automatically).


Of course one of the keys to this transition would be to eventually 
depreciate the .menu files. If the menu system can read the .desktop files 
then there would be no reason to keep the .menu format around long term, but 
it would need to stay temporally as part of the transition.




--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#433143: ITP: bzr-rebase -- Rebase plugin for Bazaar

[Manoj Srivastava]

On Wed, 18 Jul 2007 09:38:43 +1000, Ben Finney <[EMAIL PROTECTED]> said: 

> Manoj Srivastava <[EMAIL PROTECTED]> writes:
>> bzr is an inplementation of Arch, and there are people who have not
>> bought the 'Bazaar VCS Project' koolaid, and still prefer Arch to the
>> new VCS.

> 'bzr' is not an implementation of Arch. At best, it is strongly
> inspired by work the developers did on 'baz', which *was* an
> implementation of Arch.

That was a typo.  Of course I meant baz is an implementation of
 arch. 

> With the 'bzrtools' package installed, it's (sometimes) possible to do
> a one-way import of existing 'baz' branches or repositories. That's
> useful for those who know they're transitioning to an entirely new
> VCS, and want to do so.

Err, OK.  Not something I am likely to do, but I can see people
 finding 'bzrtools' useful.

>> Robert Collins wrote:
>> >  * Create a 'bazaar' package which is a metapackage depending on
>> >bzr,
>> > recommending key plugins, and suggesting others.
>> 
>> This would be a bug.  While I understand you prefer the bzr VCS over
>> Arch, I see no justification for imposing your likes and dislikes
>> over users happily using baz as their version control system.

> I agree; the older 'baz' VCS is what currently gets installed with the
> 'bazaar' package, and the 'bzr' VCS is not a compatible replacement.

I think if there is no bazaar packaged shipped with lenny (apart
 from being a dummy package to enable the package rename; then in
 lenny + 1 we could use bazaar as the container for bzr, if people so
 desire.

manoj
-- 
"Come on over here, baby, I want to do a thing with you." A Cop,
arresting a non-groovy person after the revolution, Firesign Theater
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#433143: ITP: bzr-rebase -- Rebase plugin for Bazaar

[Manoj Srivastava]

On Wed, 18 Jul 2007 10:14:06 +1000, Robert Collins <[EMAIL PROTECTED]> said: 

> On Tue, 2007-07-17 at 09:11 -0500, Manoj Srivastava wrote:
>> On Tue, 17 Jul 2007 20:19:59 +1000, Robert Collins
>> <[EMAIL PROTECTED]> said:
>> 
>> >  * rename the 'bazaar' package to 'baz' - both source and binary,
>> >though binary is the key one. This is because it is no longer
>> >the recommended tool from the 'Bazaar VCS Project' rather it is
>> >deprecated. Its useful for conversions to bzr though, so keeping
>> >it as 'baz' is good.
>> 
>> That is not the only use for it. bzr is an inplementation of Arch,
>> and there are people who have not bought the 'Bazaar VCS Project'
>> koolaid, and still prefer Arch to the new VCS.

> Thats fine, they are welcome to keep using Arch. 'baz' itself is
> unmaintained, though many of the patches in it relative to 'tla' have
> been incorporated upstream.

If baz ever bit rots, I might pick it up. At the  moment, it
works just fine.

>> >  * Create a 'bazaar' package which is a metapackage depending on
>> >bzr,
>> > recommending key plugins, and suggesting others.
>> 
>> This would be a bug.  While I understand you prefer the bzr VCS over
>> Arch, I see no justification for imposing your likes and dislikes
>> over users happily using baz as their version control system.  I
>> would be most annoyed if baz would have been replaced by bzr on my
>> systems if the sysadmin dude did not notice the change.

> Curiosity: I take it then that you are still using baz, rather than
> tla?

I use either interchangeably.  My finger have acquired a weird
 selection of one or the other over time.

>> A note in NEWS.Debian about your preferred VCS would be OK, I
>> suppose, but please come up with a bewtter upgrade plan for current
>> users of baz.

> A starting point is to do the package rename with upgrades and not
> introduce a bazaar metapackage for a release. Or at least for some
> arbitrary timeframe, as that can be more precisely defined.

As long as I don't find baz replaced by bzr, I'm happy with this.

manoj
-- 
The light of a hundred stars does not equal the light of the moon.
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]