Bug#653894: ITP: mediainfo -- MediaInfo supplies information about a video or audio file

[Chow Loong Jin]

Package: wnpp
Severity: wishlist
Owner: Chow Loong Jin 


* Package name: mediainfo
  Version : 0.7.52
  Upstream Author : i...@mediaarea.net
* URL : http://mediainfo.sf.net
* License : LGPL
  Programming Lang: C++
  Description : MediaInfo supplies information about a video or audio file

MediaInfo supplies technical and tag information about a video or audio file
.
What information can I get from MediaInfo?
General: title, author, director, album, track number, date, duration...
Video: codec, aspect, fps, bitrate...
Audio: codec, sample rate, channels, language, bitrate...
Text: language of subtitle
Chapters: number of chapters, list of chapters
.
What format (container) does MediaInfo support?
Video: MKV, OGM, AVI, DivX, WMV, QuickTime, Real, MPEG-1, MPEG-2,
MPEG-4, DVD (VOB)...
(Codecs: DivX, XviD, MSMPEG4, ASP, H.264, AVC...)
Audio: OGG, MP3, WAV, RA, AC3, DTS, AAC, M4A, AU, AIFF...
Subtitles: SRT, SSA, ASS, SAMI...
.
This package includes the command line interface



-- 
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/20120101082109.27646.85113.reportbug@localhost6.localdomain6

Re: from / to /usr/: a summary

[Thomas Goirand]

On 01/01/2012 03:11 PM, Russ Allbery wrote:
> Thomas Goirand  writes:
>   
>> On 01/01/2012 01:49 AM, brian m. carlson wrote:
>> 
>   
>>> So the only sane thing to do is not change the default, ever.
>>>   
>   
>> The other sane way is to mark files not in /etc as conffiles.  It
>> semantically sux a bit, but if we have no choice because of upstream
>> decisions (which we don't have enough time to fix), then that might be a
>> way...
>> 
> That doesn't help unless you expect sysadmins to change them (unchanged
> conffiles are quietly updated just like any other package file), at which
> point it becomes an FHS violation.
>   
Which is why I wrote "semantically sux a bit" (it's another way to say
there's
a FHS violation ...). But my understanding is that we have no choice
considering the path upstream took.

I'd like to know: is it a normal thing to edit these files in
/usr/lib/udev/rules.d
(or, any other file that udev will use and which will be stored in /usr)?
Or should we expect that *never* anyone will touch them (eg: there's never
a real valid reason to edit them)?

Thomas


-- 
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/4f002401.1050...@debian.org

Re: from / to /usr/: a summary

[Bernhard R. Link]

* Russ Allbery  [111231 18:41]:
> "Bernhard R. Link"  writes:
>
> > My experience is rather that people usually stick to their core packages
> > as personal property and won't except patches to make them more well
> > behaved.
>
> That experience aside, we're not talking about patches here, assuming
> Marco's description of the situation is correct.  We're talking about a
> full-blown fork and a need for a new udev upstream.  You don't need to
> send patches to anyone for that; you need to set up a Git repository, a
> web page, a development mailing list, some infrastructure around how
> you're going to maintain the software, and start doing regular releases,
> and then see about getting Debian to switch upstreams.
>
> > If people maintain some core piece of software and want to decide what
> > the package looks like, listen to what other people want.
>
> This isn't about the package.  It's about the *software*, the part that we
> generally use from upstream as much as possible because asking people to
> be both upstream and the Debian package maintainer is generally too much
> work for one person or even a small packaging team.

If the maintainer refuses patches and only wants to fix brokeness if
someone does a full blown upstream fork then this is a maintainer issue.

Bernhard R. Link


-- 
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/20120101115756.gb3...@server.brlink.eu

Re: from / to /usr/: a summary

[Bernhard R. Link]

* Josselin Mouette  [111231 10:54]:
> Le samedi 31 décembre 2011 à 10:23 +0100, Bernhard R. Link a écrit : 
> > If people maintain some core piece of software and want to decide what
> > the package looks like, listen to what other people want.
> > If you want to use "too much work" as excuse, then file a RFA.
>
> Because it’s well-known that filing RFAs will magically generate
> competent maintainers with a lot of time in their hands.

Spare your sarcasm, please.

While a RFA will not magically make people appear magically, one at
least makes clear that one would accept help.

Even there it is of course possible to refuse help as "incompotent",
just as refusing patches by requiring a full upstream fork.

But you cannot combine a "I'm the only one knowing how to handle the
package" with "There is not enough manpower for your request, so do not
dare to say that the current situation is broken".

Bernhard R. Link


-- 
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/20120101120229.gc3...@server.brlink.eu

Re: from / to /usr/: a summary

[Toni Mueller]

On 12/21/2011 11:55 AM, Russell Coker wrote:
> Nowadays 100G disks are small by laptop standards and for desktops 1TB is 
> about the smallest that anyone would buy.

Focussing on the desktop is the core of this - imho - misguided idea.
I'd still like to be able have a small, self-contained, Debian that I
can run on about anything. /usr is where all the real bloat (Gnome etc.)
lies, which may or may not be available, and if you eg. consider your
favourite phone storage, that's 512MB internally, or similar, with /home
presumably on an external storage (SD card).

> Things have changed a lot since the FSSTD first came out.

Indeed. Nowadays, we should support a much wider range of devices, not
just computers the size of refrigerators.


-- 
Kind regards,
--Toni++


-- 
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/4f004b35.2040...@debian.org

Re: from / to /usr/: a summary

[Russell Coker]

On Sun, 1 Jan 2012, Toni Mueller  wrote:
> On 12/21/2011 11:55 AM, Russell Coker wrote:
> > Nowadays 100G disks are small by laptop standards and for desktops 1TB is
> > about the smallest that anyone would buy.
> 
> Focussing on the desktop is the core of this - imho - misguided idea.
> I'd still like to be able have a small, self-contained, Debian that I
> can run on about anything. /usr is where all the real bloat (Gnome etc.)
> lies, which may or may not be available, and if you eg. consider your
> favourite phone storage, that's 512MB internally, or similar, with /home
> presumably on an external storage (SD card).

Do we have Debian running on phones with a configuration such that the root 
filesystem is small but /usr can be bigger?

Note that we shouldn't be planning for future phones here because they will 
have more internal storage.  Phone storage is rapidly getting bigger.

> > Things have changed a lot since the FSSTD first came out.
> 
> Indeed. Nowadays, we should support a much wider range of devices, not
> just computers the size of refrigerators.

Yes, modern phones have more RAM and storage than the fridge size servers of 
the early 90's.

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


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

Re: from / to /usr/: a summary

[Josselin Mouette]

Le dimanche 01 janvier 2012 à 13:02 +0100, Bernhard R. Link a écrit : 
> > Because it’s well-known that filing RFAs will magically generate
> > competent maintainers with a lot of time in their hands.
> 
> Spare your sarcasm, please.

No. I’m sick of these repeated allusions, really. If you are not ready
to help, please stop telling maintainers that they should treat your
personal nitpicks as the most important matters.

> While a RFA will not magically make people appear magically, one at
> least makes clear that one would accept help.

Most maintainers in core teams have been repeatedly explaining they are
PERMANENTLY looking for help. So far, neither RFHs, RFAs nor calls for
help have changed much.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


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

Re: from / to /usr/: a summary

[Timo Juhani Lindfors]

Russell Coker  writes:
> Do we have Debian running on phones with a configuration such that the root 
> filesystem is small but /usr can be bigger?

My openmoko has just

$ df -h
Filesystem  Size  Used Avail Use% Mounted on
rootfs  3.8G  3.0G  626M  83% /
tmpfs   5.0M 0  5.0M   0% /lib/init/rw
tmpfs13M  224K   13M   2% /run
tmpfs25M   24K   25M   1% /tmp
udev 62M 0   62M   0% /dev
tmpfs25M  4.0K   25M   1% /run/shm
tmpfs13M  224K   13M   2% /var/lock
tmpfs13M  224K   13M   2% /var/run


-- 
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/84wr9bxzac@sauna.l.org

Re: from / to /usr/: a summary

[Nick Leverton]

On Sun, Jan 01, 2012 at 05:14:41PM +0800, Thomas Goirand wrote:
> On 01/01/2012 03:11 PM, Russ Allbery wrote:
> > Thomas Goirand  writes:
> >> The other sane way is to mark files not in /etc as conffiles.  It
> >> semantically sux a bit, but if we have no choice because of upstream
> >> decisions (which we don't have enough time to fix), then that might be a
> >> way...
> >> 
> > That doesn't help unless you expect sysadmins to change them (unchanged
> > conffiles are quietly updated just like any other package file), at which
> > point it becomes an FHS violation.
> >   
> I'd like to know: is it a normal thing to edit these files in
> /usr/lib/udev/rules.d
> (or, any other file that udev will use and which will be stored in /usr)?
> Or should we expect that *never* anyone will touch them (eg: there's never
> a real valid reason to edit them)?

The latter.  If you wish to override them, place the new file in
/etc/udev/rules.d and the one in /usr/lib/udev won't be used.

Nick


-- 
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/20120101144201.ga5...@leverton.org

Re: from / to /usr/: a summary

[Milan P. Stanic]

On Sun, 2012-01-01 at 14:42, Nick Leverton wrote:
> On Sun, Jan 01, 2012 at 05:14:41PM +0800, Thomas Goirand wrote:
> > On 01/01/2012 03:11 PM, Russ Allbery wrote:
> > > Thomas Goirand  writes:
> > >> The other sane way is to mark files not in /etc as conffiles.  It
> > >> semantically sux a bit, but if we have no choice because of upstream
> > >> decisions (which we don't have enough time to fix), then that might be a
> > >> way...
> > > That doesn't help unless you expect sysadmins to change them (unchanged
> > > conffiles are quietly updated just like any other package file), at which
> > > point it becomes an FHS violation.
> > I'd like to know: is it a normal thing to edit these files in
> > /usr/lib/udev/rules.d
> > (or, any other file that udev will use and which will be stored in /usr)?
> > Or should we expect that *never* anyone will touch them (eg: there's never
> > a real valid reason to edit them)?
> The latter.  If you wish to override them, place the new file in
> /etc/udev/rules.d and the one in /usr/lib/udev won't be used.
   ^
You mean:
/lib/udev/rules.d

-- 
Kind regards,  Milan


-- 
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/20120101172513.gb29...@arvanta.net

Re: from / to /usr/: a summary

[Russ Allbery]

"Bernhard R. Link"  writes:
> * Russ Allbery  [111231 18:41]:

>> This isn't about the package.  It's about the *software*, the part that
>> we generally use from upstream as much as possible because asking
>> people to be both upstream and the Debian package maintainer is
>> generally too much work for one person or even a small packaging team.

> If the maintainer refuses patches and only wants to fix brokeness if
> someone does a full blown upstream fork then this is a maintainer issue.

I think this discussion is getting hopelessly muddled by excessive use of
sweeping statements like this.  I can't tell from this response whether
you just disagree with Marco that the changes required will be substantial
and ongoing, or whether you think that Marco should be maintaining
substantial and ongoing patches himself as part of some obligation to the
project for having the title of udev maintainer, or something else.  And
that lack of clarity just makes for more pointless arguments.

Semantically, *any* patch is a fork of a sort.  Practically, small patches
involve small amounts of ongoing work and therefore become a different
sort of thing than a real fork.  A real fork is required if the patches
become substantial, impact core functionality, and pose significant merge
issues.  But there's no clear distinction.

My understanding of Marco's position is that the changes to udev that
people are objecting to (undermining the ability to mount only / and not
/usr at early boot, and using configuration overlays or replacements in
/etc with package files in /lib) are the sort of changes that cannot be
reversed with a simple patch that Marco can easily maintain on an ongoing
basis.  That even if the current complexity is low, he believes it will
grow.

This is an ENTIRELY REASONABLE thing for a maintainer to say, and an
entirely reasonable thing for a maintainer to not want to get involved
in.  I daresay it's likely you've done the same yourself for some wontfix
divergence from upstream with one of your packages.  I know I certainly
have with mine.  Packaging resources are limited, and maintaining
permanent divergence from upstream is a lot of hard work.

Please, don't try to paint this position as some sort of dereliction of
duty in order to score rhetorical points.  It doesn't get us anywhere.

If you think Marco is wrong in his estimation of the level of effort
required, *that* is useful information, particularly if it's backed up
with a concrete analysis (which would involve research into what the
changes entail and what the udev upstream has said).  That's a good
discussion to have.  But just hammering on Marco because you don't like
the upstream direction of the package (at least as he understands it) and
you want him to single-handedly stop it is pointless and needlessly
antagonistic.

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/871urjb8bw@windlord.stanford.edu

Re: Bug#653894: ITP: mediainfo -- MediaInfo supplies information about a video or audio file

[Milan P. Stanic]

On Sun, 2012-01-01 at 16:21, Chow Loong Jin wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Chow Loong Jin 
> 
> 
> * Package name: mediainfo
>   Version : 0.7.52
>   Upstream Author : i...@mediaarea.net
> * URL : http://mediainfo.sf.net
> * License : LGPL
>   Programming Lang: C++
>   Description : MediaInfo supplies information about a video or audio file
> 
> MediaInfo supplies technical and tag information about a video or audio file
> .
> What information can I get from MediaInfo?
> General: title, author, director, album, track number, date, duration...
> Video: codec, aspect, fps, bitrate...
> Audio: codec, sample rate, channels, language, bitrate...
> Text: language of subtitle
> Chapters: number of chapters, list of chapters
> .
> What format (container) does MediaInfo support?
> Video: MKV, OGM, AVI, DivX, WMV, QuickTime, Real, MPEG-1, MPEG-2,
> MPEG-4, DVD (VOB)...
> (Codecs: DivX, XviD, MSMPEG4, ASP, H.264, AVC...)
> Audio: OGG, MP3, WAV, RA, AC3, DTS, AAC, M4A, AU, AIFF...
> Subtitles: SRT, SSA, ASS, SAMI...
> .
> This package includes the command line interface

Mediainfo is already in Debian multimedia.

-- 
Kind regards,  Milan


-- 
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/20120101172017.ga29...@arvanta.net

Re: Bug#653894: ITP: mediainfo -- MediaInfo supplies information about a video or audio file

[Alessio Treglia]

Hi,

On Sun, Jan 1, 2012 at 6:20 PM, Milan P. Stanic  wrote:
> Mediainfo is already in Debian multimedia.

if your "Debian multimedia" above means "debian-multimedia.org",
please keep in mind that *IS NOT* Debian.
Mediainfo looks a good candidate to me, so hyperair please go ahead.
And if you need help, you could consider taking it under the umbrella
of the Debian Multimedia Maintainers team [1] - the *real* Debian
Multimedia ;)

Have a great 2012, cheers!

[1] http://wiki.debian.org/DebianMultimedia

-- 
Alessio Treglia          | www.alessiotreglia.com
Debian Developer         | ales...@debian.org
Ubuntu Core Developer    | quadris...@ubuntu.com
0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A


--
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/CAMHuwowfMsktQcVp=-qcg3bqdebvjow3sj4vthkchxetots...@mail.gmail.com

Re: from / to /usr/: a summary

[Riku Voipio]

On Sat, Dec 24, 2011 at 11:48:42AM +, Philip Hands wrote:
> That might allow us to come up with solutions that are not just:
> 
>   Everyone must have initramfs, like it or not.

Would we really need that? If I understand correctly, the / to /usr will
merely mean that

  People who want to have /usr on separate partition will need initramfs.

There might be other reasons why initramfs will get mandatory in near future
thou.

Riku


-- 
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/20120101190856.ga30...@afflict.kos.to

Re: Bug#653894: ITP: mediainfo -- MediaInfo supplies information about a video or audio file

[Chow Loong Jin]

On 02/01/2012 02:39, Alessio Treglia wrote:
> Hi,
> 
> On Sun, Jan 1, 2012 at 6:20 PM, Milan P. Stanic  wrote:
>> Mediainfo is already in Debian multimedia.
> 
> if your "Debian multimedia" above means "debian-multimedia.org",
> please keep in mind that *IS NOT* Debian.
> Mediainfo looks a good candidate to me, so hyperair please go ahead.
> And if you need help, you could consider taking it under the umbrella
> of the Debian Multimedia Maintainers team [1] - the *real* Debian
> Multimedia ;)
> 
> Have a great 2012, cheers!
> 
> [1] http://wiki.debian.org/DebianMultimedia
> 

Thanks for the suggestion. I'll do just that.

-- 
Kind regards,
Loong Jin



signature.asc
Description: OpenPGP digital signature

Bug#653943: ITP: zanshin -- to-do list manager

[Fathi Boudra]

Package: wnpp
Severity: wishlist
Owner: Fathi Boudra 

* Package name: zanshin
  Version : 0.2.0
  Upstream Author : Kevin Ottens
* URL : http://zanshin.kde.org/
* License : GPL2+
  Programming Lang: C++
  Description : to-do list manager

 Zanshin is a powerful yet simple application for managing your day today
 actions and notes. It helps you organize and reduce the cognitive pressure of
 what one has to do in his job and personal life. You'll never forget anything
 anymore, getting your mind like water.



-- 
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/20120101201738.15695.44865.reportbug@dc7700p

Re: from / to /usr/: a summary

[Tanguy Ortolo]

Enrico Weigelt, 2011-12-31 03:55+0100:
> IMHO this is completely wrong, those files should be under
> /usr/lib/... or maybe even /usr/share/... as they're not
> dynamic data.

Well, when people install new plugins or new themes, they get installed
on the same directory, so I decided that it was less surprising to have
packaged files that people will not touch under /var than to have user
files under /usr.

> I'd split off package install and instance deployment
> (as soon as you want several dokuwiki instances on one
> host, that will be needed anyways).

Multisite support is a feature that has been asked for quite a long
time, but I implemented it some months ago, without copying anything.

-- 
 ,--.
: /` )   Tanguy Ortolo  
| `-'Debian Maintainer
 \_


-- 
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/jdqf6p$99b$1...@dough.gmane.org

Bug#653949: ITP: nxt-python -- a pure-python driver/interface/wrapper for the Lego Mindstorms NXT robot

[Scott Kitterman]

Package: wnpp
Owner: Scott Kitterman 


* Package name: nxt-python
  Version : 2.2.1
  Upstream Author : Marcus Wanner 
* URL : http://code.google.com/p/nxt-python/
* License : GPL v3
  Programming Lang: Python
  Description : a pure-python driver/interface/wrapper for the Lego 
Mindstorms NXT robot

 NXT-Python is a package for controlling a LEGO NXT robot using the
 Python programming language. It can communicate using either USB or
 Bluetooth.

Note: Binary name will be python-nxt per Python policy



-- 
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/20120101212035.3692.35527.reportbug@Scott-Latitude-E6320

Re: from / to /usr/: a summary

[Josh Triplett]

Toni Mueller wrote:
> On 12/21/2011 11:55 AM, Russell Coker wrote:
> > Nowadays 100G disks are small by laptop standards and for desktops 1TB is 
> > about the smallest that anyone would buy.
> 
> Focussing on the desktop is the core of this - imho - misguided idea.
> I'd still like to be able have a small, self-contained, Debian that I
> can run on about anything. /usr is where all the real bloat (Gnome etc.)
> lies, which may or may not be available, and if you eg. consider your
> favourite phone storage, that's 512MB internally, or similar, with /home
> presumably on an external storage (SD card).

If you want to run Debian on a phone with incredibly small internal
storage, then either put / on external storage, or don't install large
packages like GNOME if you only have 512MB available.  And in any case,
nothing discussed in this thread would stop you from splitting out /usr
if you want to, as long as the initramfs mounts it.

(Also, my favorite phone has 32GB of storage. :) )

- Josh Triplett


-- 
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/20120101214217.GA27644@leaf

Re: from / to /usr/: a summary

[Marco d'Itri]

On Dec 31, Russ Allbery  wrote:

> >> ACK. Sometimes upstreams doing really stange things (maybe because they
> >> dont have any package management in mind), that should be fixed.  If
> >> upstream doesnt do those fixes, distros have to catch in.
> Sometimes, I think Red Hat makes some of these design decisions because
> RPM's handling of configuration files sucks.  If it had always behaved
> like dpkg, I wonder if they wouldn't use designs that honor configuration
> files somewhat more.
This has been my conclusion as well.
And an ever bigger problem is that Red Hat just does not support
upgrading to the next major release and so they choose to not care about
lots of issues which are important to us.

> This, however, is a really good point, and is the thing that keeps running
> through the back of my head reading this thread.  There seems to be a lot
> of sentiment that people wish udev (in particular) would work differently
A few people have been wishing for udev to work differently since it was 
introduced in 2004. The major problem with these people is that they 
usually do not understand how udev works, so they cannot propose 
plausible alternative solutions, nor they have ever followed upstream
development, so they are unaware of the design choices and requirements 
which lead to the current implementation.
I think it is obvious that so far I was right and they were wrong, since 
they never actually proposed valid alternative solutions and my design
choices about how udev is integrated in Debian have been validated by
time and by adoption by other distributions.
(At least, before upstream drank the systemd kool aid.)

So we could waste a lot less time arguing over the inevitable if people
would accept that I tend to be right. :-)

> Note that Steve's point, namely that he (if I'm reading him right) thinks
> that the upstream changes are being overstated and that upstream's
> direction isn't actually going to cause problems for us, is an entirely
> separate one and not something I'm addressing in the above.  And is
> certainly something to explore before we start arguing over who's going to
> fork something that may not be an issue at all.
Unsurprisingly, this is not a black or white issue: there are many
different issues in different parts of the stack and with different
levels of complexity.
In some cases I have been able to keep old code around (e.g. to support
older kernels than upstream did), but in others it is intrinsecally
impossible (e.g. when udev needs to IMPORT{} data from something which
lives in /usr).

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation

[Axel Beckert]

Package: wnpp
Severity: normal

Hi,

Debian's screen package needs help with bug triaging, wheezy migration
and upstream lobbying.

Jan took over Debian's screen package in 2007 and was a very active and
talented screen package maintainer. Unfortunately he no more has enough
time[1] to maintain GNU Screen in Debian.

  [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=641867#20

Because I still prefer screen over tmux, I jumped in as co-maintainer a
few months ago and with the help of Brian P Kroth I managed to upload[2]
an upstream git snapshot to Debian Experimental which fixed especially
the tons of bugs already fixed by upstream. I also created a git
repository for Debian's screen packaging at [3].

  [2] http://packages.qa.debian.org/s/screen/news/20111009T025041Z.html
  [3] http://anonscm.debian.org/gitweb/?p=collab-maint/screen.git

Nevertheless I know I won't be able to maintain screen alone until Jan
has time for screen again. So screen definitely needs more (co-)
maintainers.

Additionally there are a few issues where I'd be happy to have other
people to dig into, too, especially:

* http://bugs.debian.org/644788 -- screen 4.1.0 can't attach to a
  running or detached screen 4.0.3 session
* http://bugs.debian.org/649240 -- release-notes: Upcoming upgrade
  issues with GNU Screen for Wheezy

Both these bug reports are defacto about the same issue, the first is
the technical issue itself while the second is about how to handle the
implications for screen's wheezy migration.

And both bug reports are somehow also about lobbying at upstream to fix
this issue upstream instead just for Debian and derivate distributions
like Ubuntu. Unfortunately a first reply[4] from upstream was a "won't
fix".

  [4] https://lists.gnu.org/archive/html/screen-devel/2011-11/msg00020.html

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



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87hb0eq4iq@nemo.deuxchevaux.org

Re: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation

[Yaroslav Halchenko]

pardon my blunt question:
but is there really possibility to have them 'fixed'?  I am reading
upstream response just as a statement that it can't be achieved due to a
chance in protocol...

On Mon, 02 Jan 2012, Axel Beckert wrote:
> Additionally there are a few issues where I'd be happy to have other
> people to dig into, too, especially:

> * http://bugs.debian.org/644788 -- screen 4.1.0 can't attach to a
>   running or detached screen 4.0.3 session
> * http://bugs.debian.org/649240 -- release-notes: Upcoming upgrade
>   issues with GNU Screen for Wheezy

> Both these bug reports are defacto about the same issue, the first is
> the technical issue itself while the second is about how to handle the
> implications for screen's wheezy migration.

> And both bug reports are somehow also about lobbying at upstream to fix
> this issue upstream instead just for Debian and derivate distributions
> like Ubuntu. Unfortunately a first reply[4] from upstream was a "won't
> fix".

>   [4] https://lists.gnu.org/archive/html/screen-devel/2011-11/msg00020.html

> Regards, Axel
-- 
=--=
Keep in touch www.onerussian.com
Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic


-- 
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/20120102014123.gi16...@onerussian.com

Re: from / to /usr/: a summary

[Marco d'Itri]

On Jan 01, Riku Voipio  wrote:

> Would we really need that? If I understand correctly, the / to /usr will
> merely mean that
> 
>   People who want to have /usr on separate partition will need initramfs.
Correct.
It does not even mean that they would need to use initramfs-tools, there 
are a few possible alternative solutions if anybody cared enough to 
implement them.
I believe that creating a generic initramfs with busybox-static which
can mount /usr defined on the kernel command line would take a couple of 
hours at most (and it could even be embedded in a custom kernel!).

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation

[Axel Beckert]

Hi Yaroslav,

Yaroslav Halchenko wrote:
> pardon my blunt question:

No, this question is completely valid and understandable and came up
already in the two mentioned bug reports (#644788 and #649240).

> but is there really possibility to have them 'fixed'?

Well, there are several ways to "fix" this, some are surely less
perfect and less favourable solutions, but then again -- as you
correctly state -- the perfect ones may not be possible.

But we have to choose at least one solution because otherwise the
dist-upgrade to Wheezy will be very ugly (and therefor not
debian-like) for those who run it inside a screen session remotely and
the network connections dies after screen has been dist-upgraded. (So
IMHO there is no option to do nothing at all. ;-)

> I am reading upstream response just as a statement that it can't be
> achieved due to a chance in protocol...

Yep.

I see the following options:

A) Add an option to screen so the screen client speaks the old
   protocol to the running server protocol. This IMHO would be best
   solution and one without a big impact. It's also something which
   could be Debian-only, i.e. a patch. (It of course would be better
   if upstream could be convinced to add such an option. :-)

B) Take care that nobody upgrades the screen package while running
   inside a screen without being aware of the possible problems. There
   are few ideas how to implement this:

   1) Mention it in the release notes that screen has to be upgraded
  to the very end of the dist-upgrade process if the dist-upgrade
  is running inside screen.

  Disadvantage: Many admins don't read the release notes.

   2) Fail in the preinst maintainer script if screen server processes
  are running like udev did from Etch to Lenny if not upgraded
  together with the kernel.

  Disadvantage: According to Steve Langasek this could be very
  ugly, so I suggest to inform via debconf about the issue and let
  the user decide if he wants to continue, abort (or maybe get a
  shell to connect to that screen session and close it)

   3) Tell people via the release notes that they should not run the
  dist-upgrade inside screen, but inside tmux instead.

  Disadvantage: Many admins don't read the release notes. People
  may still distrust tmux for such an crucial task or just may not
  be comfortable with the parts where tmux's behaviour differs
  from screen's behaviour.

C) Provide both, screen 4.0.3 and screen 4.1.0 binaries. Again, here
   are more than one option to do so:

   1) Let the preinst maintainer script make a copy of the old screen
  binary, provide a script to clean up this mess afterwards,
  inform the user via debconf about the issue and his
  possibilities (where the copy of the old screen is, etc.).

  Disadvantage: It's a non-dpkg-managed mess.

   2) Make screen 4.0.3 and screen 4.1.0 installable at the same time,
  i.e. give them different source and binary package names.

  Disadvantage: Dependencies between those packages needed for
  proper Wheezy migration not obvious. We'd need something like
  "if screen sessions are running, pull in screen-4.0.3 and
  screen-4.1.0, but just pull in screen-4.1.0 if no screen session
  is running", but of course this is impossible just with
  dependencies.

Additionally, I'm not 100% (but let's say 90% :-) convinced that these
changes necessarily had to be incompatible. But changing them back (if
possible) would surely have some impact the other way round for those
already running git snapshots running with the current protocol
version. So there may be also an option "D":

D) Convince upstream to make the new protocol (which includes password
   protected screen sessions even after reattaching) compatible to the
   old protocol.

IMHO option A would be the most preferable one, D seems less
realistic, C2 is realistic but quite some work, B1, B3 and C1 are
ugly, and B2 is said to possibly become ugly, too.

So my current plan is that if nobody manages A, I'd have a closer look
at C2 and if that's not possible or too complicated, I'd go with B2
and the mentioned Debconf questions as the last resort.

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120102021834.gh20...@sym.noone.org

Packaging best practice when upstream git contains more directory levels than the upstream tarball?

[Axel Beckert]

Hi,

for quite some while now I'm wondering what's the best practice to
maintain a package in a git repo if upstream uses a git repo, too, but
that has at least one directory level more than the official upstream
tarball.

I prefer to base my packages on official upstream tarballs for several
reasons (see below), but having the upstream git repo as remote in
your packaging git repo also has some advantages.

Unfortunately git has not yet a narrow clone like Subversion does
(i.e. with git you are not able to just clone a subdirectory instead
of the full repo), so things seem to get really complicated if the
upstream git repo contain more directory levels than the upstream
tarball.

So far the problem. Now to the advantages of both ways:

Upstream tarballs are preferable because:

* It's use is recommended in the Developer Reference
* It's clear how the tarball was generated -- built by upstream and
  downloaded
* Distributions which build the software on package/port installation
  time (like e.g. FreeBSD and Gentoo) rely a lot on the Debian
  mirrors -- but only if we use the original upstream tarball.(*)

(*) Even if some may argue that's somebody else's problem, I think
it's a not so unimportant argument.

Tarballs built from a git repo which includes the upstream git repo as
a remote git repo are preferable because:

* They may include more files you possibly need for using
  automake/autoconf foo or to rebuild other stuff which is prebuilt in
  the official upstream tarball.(**)
* You can use git bisect to see where upstream introduced a bug.
* You can easily produce packages of upstream snapshots.

(**) From my current point of view this is the only really problematic
 issue and if such an issue is not present, using upstream
 tarballs is preferable.

In ran into this dilemma when I packaged a git snapshot of screen for
experimental. Nevertheless I noticed the fact that it really can be a
problem only when looking closer at the packaging of zsh -- which
currently has issues similar to the one marked with (**), but without
the "one more directory level" component. (I though believe that we
can do the balance between both worlds with zsh. :-)

My current "solution" (well, more a workaround than a solution) for
packaging screen is to use upstream tarballs and keep a clone of the
upstream git repo in a separate git working copy. (A separate branch
would also do it, but that would be like having clones of two
completely different git repos in two branches of one git repo.)

Another idea which I had was using git submodules for whatever is in
the upstream tar ball, but I ran into non-obvious problems already
while just imagining with it.

Anyone else ran into this problem? Anyone has found a better solution
-- or a better workaround? :-)

Maybe also the git-buildpackage-alike workflow in my head
(git-import-orig, debuild -uc -us, pdebuild, git-builtpackage
--git-tag-only) keeps me away from seeing the wood for the trees...

P.S.: If anyone is interested in helping to maintain screen in Debian,
have a look at this RFH: http://bugs.debian.org/654116 -- TIA :-)

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120102023248.gj20...@sym.noone.org

Re: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation

[Marco d'Itri]

On Jan 02, Axel Beckert  wrote:

> A) Add an option to screen so the screen client speaks the old
>protocol to the running server protocol. This IMHO would be best
>solution and one without a big impact. It's also something which
As long as the needed patch is simple. But if it were, this would 
probably already have been solved.

>2) Fail in the preinst maintainer script if screen server processes
>   are running like udev did from Etch to Lenny if not upgraded
>   together with the kernel.
The abort notice should be provided by debconf before the upgrade 
process is started, indeed.

>1) Let the preinst maintainer script make a copy of the old screen
>   binary, provide a script to clean up this mess afterwards,
>   inform the user via debconf about the issue and his
>   possibilities (where the copy of the old screen is, etc.).
> 
>   Disadvantage: It's a non-dpkg-managed mess.
I strongly recommend this solution, along with a proper debconf notice.
If screen is running, the admin will be able to choose between:
- abort the upgrade, upgrade screen and its dependencies and then 
  start again the full upgrade
- continue the upgrade while knowing that the old binary will still be
  available in /tmp/old-screen.$RANDOM/ or something

/tmp is a good choice because the next reboot will automatically clean 
up everything (and obviously the old binary will not be needed after 
a reboot).

>2) Make screen 4.0.3 and screen 4.1.0 installable at the same time,
>   i.e. give them different source and binary package names.
This would require a great amount of work to fix a tiny problem which 
presents itself just for the length of the upgrade process, if at all.

I believe that this is a textbook example which shows how trying to 
implement the perfect solution which will beautifully cover all corner 
cases has indefinitly stalled development on the package.
Do not try to fix everything, you should aim to provide a reasonable 
solution which will solve the most common cases.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Bug#644788: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation

[Axel Beckert]

Hi Marco,

Marco d'Itri wrote:
> >1) Let the preinst maintainer script make a copy of the old screen
> >   binary, provide a script to clean up this mess afterwards,
> >   inform the user via debconf about the issue and his
> >   possibilities (where the copy of the old screen is, etc.).
> > 
> >   Disadvantage: It's a non-dpkg-managed mess.
> I strongly recommend this solution, along with a proper debconf notice.
[...]
> /tmp is a good choice because the next reboot will automatically clean 
> up everything (and obviously the old binary will not be needed after 
> a reboot).

Thanks for that hint. This sounds better (and especially less messy)
than I thought! :-)

> >2) Make screen 4.0.3 and screen 4.1.0 installable at the same time,
> >   i.e. give them different source and binary package names.
> This would require a great amount of work

I fear so, yes.

> to fix a tiny problem which presents itself just for the length of
> the upgrade process, if at all.

Correct. It's an option nevertheless, so I mentioned it.

Thanks for your insight!

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120102031344.gl20...@sym.noone.org

Re: Bug#644788: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation

[Ben Finney]

Axel Beckert  writes:

> A) Add an option to screen so the screen client speaks the old
>protocol to the running server protocol. This IMHO would be best
>solution and one without a big impact. It's also something which
>could be Debian-only, i.e. a patch. (It of course would be better
>if upstream could be convinced to add such an option. :-)

That does sound like the best option. Reading upstream's latest
response, they don't seem to have expressed a position on accepting such
a change if someone does the work to implement it.

> B) Take care that nobody upgrades the screen package while running
>inside a screen without being aware of the possible problems. There
>are few ideas how to implement this:
>
>1) Mention it in the release notes that screen has to be upgraded
>   to the very end of the dist-upgrade process if the dist-upgrade
>   is running inside screen.
>
>   Disadvantage: Many admins don't read the release notes.
[…]
>3) Tell people via the release notes that they should not run the
>   dist-upgrade inside screen, but inside tmux instead.
>
>   Disadvantage: Many admins don't read the release notes.

The release notes (by which I assume you mean ‘changelog’ and
‘changelog.Debian’) are not displayed by default, but I think the
‘NEWS.Debian’ file is intended for this sort of “you need to know this
before upgrading the package to this version” information. See the
Developer's Reference §6.3.4.

-- 
 \   “I am as agnostic about God as I am about fairies and the |
  `\   Flying Spaghetti Monster.” —Richard Dawkins, 2006-10-13 |
_o__)  |
Ben Finney 


--
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/87ty4e20xo@benfinney.id.au

Re: Bug#644788: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation

[Axel Beckert]

Hi Ben,

Ben Finney wrote:
> > B) Take care that nobody upgrades the screen package while running
> >inside a screen without being aware of the possible problems. There
> >are few ideas how to implement this:
> >
> >1) Mention it in the release notes that screen has to be upgraded
> >   to the very end of the dist-upgrade process if the dist-upgrade
> >   is running inside screen.
> >
> >   Disadvantage: Many admins don't read the release notes.
> […]
> >3) Tell people via the release notes that they should not run the
> >   dist-upgrade inside screen, but inside tmux instead.
> >
> >   Disadvantage: Many admins don't read the release notes.
> 
> The release notes (by which I assume you mean ‘changelog’ and
> ‘changelog.Debian’)

Nope. I mean the release notes as published by Debian when releasing a
new stable release, i.e.
http://www.debian.org/releases/stable/releasenotes tracked at
http://bugs.debian.org/release-notes

> but I think the ‘NEWS.Debian’ file is intended for this sort of “you
> need to know this before upgrading the package to this version”
> information.

It's already in there since the last upload to experimental.

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120102042948.gn20...@sym.noone.org

Re: Bug#644788: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation

[Karl Goetz]

On Mon, 2 Jan 2012 04:13:44 +0100
Axel Beckert  wrote:

> Hi Marco,
> 
> Marco d'Itri wrote:

> > >2) Make screen 4.0.3 and screen 4.1.0 installable at the same
> > > time, i.e. give them different source and binary package names.
> > This would require a great amount of work
> 
> I fear so, yes.
> 
> > to fix a tiny problem which presents itself just for the length of
> > the upgrade process, if at all.
> 
> Correct. It's an option nevertheless, so I mentioned it.

Sorry if I've misunderstood, but doesn't this problem manifest for
*anyone* trying to ssh from a wheezy system to a squeeze system?
thanks,
kk

-- 
Karl Goetz, (Kamping_Kaiser / VK7FOSS)
http://www.kgoetz.id.au
No, I won't join your social networking group


signature.asc
Description: PGP signature