date:20100530

Re: lilo removal in squeeze (or, please test grub2)

2010-05-30 Thread Stefano Zacchiroli

On Sat, May 29, 2010 at 04:51:09PM +0200, Marc Haber wrote:
 Right, but also note that there's an open RFH on grub2 #248397
 (retitled/refreshed recently, despite the low bug number).
 
 As long as there are tested-and-ready-to-apply[1] patches rotting away
 in the BTS without any comments, I don't get the feeling that this
 kind of help is really wanted.

YMMV, to me it would seem an even more acute indication of the fact that
maintainer is so unavailable that he hasn't even found the time to apply
tested-and-ready-to-apply patches; I believe both yours and mine
interpretation make sense.  Anyhow, now Colin is on the matter, let's
leave him some time to breathe, and I'm confident the patches you
mention will get through.

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'?? ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu ?? tous ceux que j'aime


signature.asc
Description: Digital signature

Re: Meaning of the different “format” fields and files.

2010-05-30 Thread Raphael Hertzog

On Sat, 29 May 2010, Charles Plessy wrote:
 Thanks for the pointer. I sent a patch for the Policy to this bug report. I
 agree with the comment of Manoj in message #15 that the Format field of the
 Debian source control files would have better been called Src-Format or
 something similar. Do you think that there is a chance to correct this in the
 future?

It's unlikely, it's a complication with no clear benefit.

 The patch I sent indicates the meaning of the Format field for the Debian
 change files and source control files, and brings the Policy up to date with
 the format 1.8 for Debian changes files. I did not address the meaning of the
 Format field in source package control files, because I do not understand why
 the debian/source/format file was introduced to replace the use of that field.

It's not replaced... the field is still here in the .dsc, but its content
is generated by dpkg-source (and the source format specific part) based on
debian/source/format or the --format command-line option.

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/20100530080813.gc6...@rivendell

Re: lilo removal in squeeze (or, please test grub2)

2010-05-30 Thread Stanislav Maslovski

On Sat, May 29, 2010 at 04:43:32PM -0400, Stephen Powell wrote:
 On Sat, 29 May 2010 14:40:41 -0400 (EDT), Andreas Barth wrote:
  Stephen Powell wrote:
  On Sat, 22 May 2010 23:39:52 -0400 (EDT), William Pitcock wrote:
  After some discussion about lilo on #debian-devel in IRC, it has pretty
  much been determined that kernel sizes have crossed the line past where
  lilo can reliably determine the payload size.
 
 
  We're speaking about #505609 I assume?
 
 I hope not.  Strictly speaking, 505609 is not a lilo bug.  The key is
 that he was still able to boot his old kernel that had been de-installed.
 That's a sure sign that lilo's map installer did not get run during the
 kernel upgrade process.

[skipped]

 If there's a bug here, it's somewhere else in the kernel installation
 process, not in lilo itself.  If this so-called bug in lilo is what
 prompted the decision to drop lilo, then the decision was based on bad data.
 lilo, at least in this case, is working as designed.  The problem is that
 the lilo map installer did not get run during the kernel installation
 process.  I've helped a number of people on debian-user with problems
 like this, and in every case so far running lilo at the command line
 fixed the problem.

I guess your analysis was based on the follow-up by Tomas Pospisek?
Christian Hammers from the same bug thread also stated that the
problem disappeared after executing lilo from the command line.

If that is really the case, then I would advise William to simply
orphan lilo, if for some reason he does not want to work on it
anymore. Removing, IMO, is not justified in this case.

BTW, Stephen, you could also post your analysis on the BTS.

-- 
Stanislav


-- 
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/20100530081726.ga31...@kaiba.homelan

hashing username = UID

2010-05-30 Thread C. Gatzemeier

Am Sat, 29 May 2010 16:51:10 +0200
schrieb Marc Haber mh+debian-de...@zugschlus.de:

 hash the user name into the UID since this will - at least on systems
 with only a handful of users - enhance the chance that the same user
 name will get the same UID on different systems.

That could be quite nice, yes.


-- 
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/20100530115005.5f9e2786c.gatzeme...@tu-bs.de@tu-bs.de

Re: Archive area for clamz (Amazon MP3 downloader)

2010-05-30 Thread Ron Johnson


On 05/29/2010 09:47 PM, Ben Hutchings wrote:

On Sat, 2010-05-29 at 19:33 -0500, Ron Johnson wrote:

On 05/29/2010 03:28 PM, Ben Hutchings wrote:

On Sat, 2010-05-29 at 21:14 +0200, Felix Geyer wrote:

clamz [1] has been rejected from Debian NEW [2] some time ago.
The FTP assistent that processed the package was of the
opinion that it belongs to contrib instead of main because it's
only useful to download non-free content.

The purpose of clamz is to download MP3 files after buying them
from Amazon. You can download MP3s with every browser though
and Debian even has many MP3 decoders in main.
I don't see why this is a problem.

There is another package in main that is similar in this
respect: youtube-dl.


Some material on YouTube may be under a free licence, e.g.
http://www.youtube.com/fosdemtalks   (though this isn't explicitly
stated there).



So to get in main, an app isn't allowed to *touch* non-free data?


I think the policy being applied is that if a package is only useful in
conjunction with non-free data, it belongs in contrib (just as if it
depends on some non-free library).



Thanks for the clarification.

However, I just read http://www.debian.org/social_contract and it 
says nothing about the kind of *data* that programs can touch; only 
software, source code and the licensing of that source code is 
mentioned.


--
Dissent is patriotic, remember?


--
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/4c024662.9080...@cox.net

Re: Bug#529974: RFP: rtmpdump -- download media streamed with the RTMP/RTMPE protocol

2010-05-30 Thread Ron Johnson


On 05/29/2010 12:25 AM, Reinhard Tartler wrote:

On Fr, Mai 28, 2010 at 22:49:43 (CEST), Ron Johnson wrote:


On 05/28/2010 09:20 AM, Reinhard Tartler wrote:

On Fr, Mai 28, 2010 at 16:00:27 (CEST), Ron Johnson wrote:


On 05/28/2010 01:25 AM, Reinhard Tartler wrote:

I'm going to package rtmpdump next week.

On Fr, Mai 22, 2009 at 16:33:44 (CEST), Sam Morris wrote:


* Package name: rtmpdump
* URL : [hidden obsolete url]
* License : GPL
 Programming Lang: C++
 Description : download media streamed with the RTMP/RTMPE protocol

A small dumper for media content streamed over the RTMP/RTMPE protocol.


How will this be different from the rtmpdump (currently at v2.2d-0.0) in
d-m.o?


I didn't look inside the source package nor do I intend to do so. I note
that it doesn't provide an librtmp-dev package, so it's useless for me.


Even when you need to reinvent the wheel, it's usually useful to see how
others built their wheels, and maybe -- just maybe -- add to their
well-debugged wheel.


not in this case.


   Some rights-restricted libraries stripped out?


I didn't spot any restricted libraries included. What are you referring to?



Christian created d-m.o for useful packages that can't be the official
Debian repositories; mainly for licensing issues.


what licensing issues do you see in rtmpdump, ffmpeg or mplayer?! they
are all (L)GPL which is perfectly DFSG compatible. Before you come up
with FUD about patents, DMCA, etc. - pretty please don't. there is
already enough FUD floating around.


There must be a good *reason* why Christian still maintains ffmpeg 
and mplayer in d-m.o even though same-named packages are also in Debian.


Maybe he likes the extra work??


That's why, for example, mplayer and ffmpeg are in both Debian and
d-m.o.


please do your homework. you are evading my question, probably because
you have no idea what you are talking about.



--
Dissent is patriotic, remember?


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

Bug#583749: ITP: xkbind -- X Keyboard Extension Indicator

2010-05-30 Thread Stanislav Maslovski

Package: wnpp
Severity: wishlist
Owner: Stanislav Maslovski stanislav.maslov...@gmail.com

* Package name: xkbind
  Version : 2010.05.20
  Upstream Author : CHG sme...@by.ru
* URL : http://xkbind.sourceforge.net/
* License : GPL2
  Programming Lang: C
  Description : X Keyboard Extension Indicator

The XkbInd program (X Keyboard Extension Indicator) is a minimal
indicator of keyboard layout (XKB group) for the X Window System; it
indicates current keyboard layout in the title of top-level windows via
prefix to the original string.  It also allows to simulate independent
keyboard layout for each handled window and it works with most of the
window managers, including twm, mwm and fvwm.

Main Features
=

  1. XkbInd simulates independent keyboard layout for each handled
 top-level window.

  2. XkbInd is very light-weight and uses less than 150 kb of virtual memory
 (excluding shared, of course).

  3. XkbInd doesn't grab entries in the default color pallet, doesn't
 perform any drawing operations on the X display itself, but relies wholly
 on the window manager.

  4. XkbInd doesn't occupy any area on the screen, and outputs all relevant
 information to the window title.

  5. XkbInd can be configured to ignore (or accept) particular windows or
 applications.  This feature is based on examination of WM_CLASS property.
 It is possible to use wildcards in the ignore and accept lists.

  6. XkbInd is a true XKB program, i.e. all interactions with the X-server
 are carried out through XKB extension protocol.

  7. XkbInd keeps current layout of window at the server side as window
 property, unlike the most other similar programs which keep this data
 in the internal storage.

  8. And the last, XkbInd does only what it says -- it is an indicator.
 Nothing more.



-- 
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/20100530115610.10041.68103.report...@kaiba.homelan

Re: Archive area for clamz (Amazon MP3 downloader)

2010-05-30 Thread Luca Niccoli

On 30 May 2010 04:47, Ben Hutchings b...@decadent.org.uk wrote:

 I think the policy being applied is that if a package is only useful in
 conjunction with non-free data, it belongs in contrib (just as if it
 depends on some non-free library).

I see a potential problem with this policy:
say I write a DFSG-compliant media player, and I want to add the
ability to download songs from Amazon; I then depend on clamz.
But clamz is in contrib, so my media player must go into contrib, even
though it's free and depends only on free programs, and it's not
useful only in combination with non-free data.
I guess the example would work better with a library, but I think it's
clear enough.

Cheers,

Luca


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

Re: Bug#529974: RFP: rtmpdump -- download media streamed with the RTMP/RTMPE protocol

2010-05-30 Thread Josselin Mouette

Le vendredi 28 mai 2010 à 15:49 -0500, Ron Johnson a écrit :
  I didn't look inside the source package nor do I intend to do so. I note
  that it doesn't provide an librtmp-dev package, so it's useless for me.
 
 Even when you need to reinvent the wheel, it's usually useful to see 
 how others built their wheels, and maybe -- just maybe -- add to 
 their well-debugged wheel.

There are wheels you can look at and find design inspiration into. And
there are others you shouldn’t look at since all you get will be bad
ideas and broken patches. That includes Ubuntu universe, Fedora rawhide
and debian-multimedia.org.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'  “If you behave this way because you are blackmailed by someone,
  `-[…] I will see what I can do for you.”  -- Jörg Schilling


--
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/1275223258.28113.50.ca...@tomoyo

Re: Improving in-place upgrades of Ada packages from Lenny to Squeeze

2010-05-30 Thread David Kalnischkies

2010/5/29 Ludovic Brenta ludo...@ludovic-brenta.org:
 David Kalnischkies kalnischkies+deb...@gmail.com writes:
 No. Replaces is used to say to dpkg: It is okay that this package
 overrides files of the other package - otherwise dpkg would complain
 loudly for good reasons. It doesn't say something about the
 upgrade path.

 I disagree with this particular part of your analysis.  What you say is
 true of Conflicts, not of Replaces.  IMHO, Replaces really, clearly
 suggests an upgrade path.  Why else would the package renaming procedure
 require both Conflicts and Replaces?

Consider a package A which moved from a bad example-config file to
a full blown doc translated to 100 languages. The documentation is split
out into a new package A-doc which will Replaces the old A version
as it will override the old example-file. The A-doc package will end up as
a Recommends or Suggests for A as it is not strictly needed to work with A.

Should a package manager really follow the Replaces? This would mean
we could end up removing A because A-doc replaces it? Or get full
blown documentation - now that you have used the application for
years without looking at the (non existing) documentation so far…
You can construct for Conflicts a similar (and better) situation, 'extra'
packages for example can Conflicts/Replaces with each other without
any problems…

Both together doesn't indicate much as well:
Your installed mail-transport-agent conflicts+replaces all other MTAs.
Is installing exim4 instead of postfix really an upgrade path?


 Let me emphasize again that, for Ada, a new version of a -dev package
 (i.e. libX2-dev) is *not* a complete replacement for libX1-dev,
 therefore we must use neither a dummy transitional package nor a
 Provides relationship.

The question is why you want that people which have libX1-dev installed
need to upgrade to libX2-dev AND remove libX1-dev by describing that
only with dependencies in libX2-dev. It is simply not possible and
doesn't make much sense:
If libX1-dev can't be used anymore the package breaking it should
Breaks it. If it is not broken why removing it?
It will be autoremoved if it is not needed anymore…
libX2-dev will be installed then something depends on it - or if the user
needs it and requests it manually.
I also don't see why libX1-dev and libX2-dev have Conflicts and/or
Replaces on each other. Their naming _highly_ suggests
that they can be co-installed and used. If they can't be co-installed
and used why is the package not called libX-dev instead…


Best regards,

David Kalnischkies


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktimyqurbfoka7n_dye0tfiytnmjrkpue9fxi1...@mail.gmail.com

Re: The story behind UPG and umask.

2010-05-30 Thread Stephen Gran

This one time, at band camp, Marc Haber said:
 On Wed, 26 May 2010 23:43:12 +0100, Stephen Gran sg...@debian.org
 wrote:
 This one time, at band camp, Roger Leigh said:
  How will adduser cope with group addition; does it skip UIDs until
  it finds an unused unique UID/GID pair?
 
 That certainly is the only approach that makes sense - it has the
 benefit of simplicity, if not elegance.
 
 I am not a very good friend of just counting. I would try to somehow
 hash the user name into the UID since this will - at least on systems
 with only a handful of users - enhance the chance that the same user
 name will get the same UID on different systems.

There are already well understood mechanisms for ensuring that uids are
the same across multiple systems.  I don't think adduser is the place
for that.

Cheers,
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :sg...@debian.org |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

[SOLVED] Unbootable after kernel upgrade: Lilo can't load kernel

2010-05-30 Thread Stephen Powell

This is not a lilo bug. The problem is that lilo's map installer
did not get run during the kernel upgrade process. The fact that
the user was able to boot his old de-installed kernel is proof of
this. The /boot/map file still pointed to the blocks in the file
system which formerly contained the old kernel and its initial RAM
file system image. And since, fortunately, those blocks had not yet
been reused, the data was still there. Modules which were
loaded from the initial RAM file system image loaded OK. But once
the switch was made from the initial RAM file system to the
permanent root file system, further module loads could not be done,
since the modules had been erased. When the user manually ran lilo's
map installer at the command line, the problem disappeared.

The real question is, Why didn't the map installer get run during
the kernel upgrade? There is not sufficient data in the bug log
to determine the answer to that question, but I have observed that
do_bootloader = yes in /etc/kernel-img.conf no longer causes
lilo to be run when a new kernel is installed. I believe that this
change in behavior was caused by changes to the kernel maintainer
scripts made around the time of the switch to grub version 1 as
the default boot loader. do_bootloader = yes in /etc/kernel-img.conf
still causes zipl to be run on the s390 port, a port that neither
version of grub supports. do_bootloader = yes should still be
specified in /etc/kernel-img.conf, however, so that update-initramfs -u
will cause lilo's map installer to be run when an initial RAM file
system is updated (but not when it is initially created).

So is this a bug in the kernel maintainer scripts? Or is it a feature?
I don't know. I'll leave that up to the kernel maintainers to decide.
A full discussion of how to make sure that lilo's map installer gets
run during the installation of a new kernel, taking into account all
types of kernels (official stock Debian kernels, custom kernels created
by make-kpkg, custom kernels created by make deb-pkg, etc., is beyond
the scope of this bug log. Interested readers may wish to look at my
web page on kernel building, particularly step 10, for further
information. http://www.wowway.com/~zlinuxman/Kernel.htm The instructions
for customizing the Lenny environment will work in Squeeze or Sid also,
provided that you use only official stock Debian kernels. If you use
custom kernels in Squeeze or later, you *must* use hook scripts to ensure
that any post-installation activities, such as the creation of an initial
RAM file system, updating symlinks, or running a boot loader, take place.

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

--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/2000712474.159302.1275230137351.javamail.r...@md01.wow.synacor.com

1 2 >

1 - 100 of 159 matches

Mail list logo