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

2012-01-01 Thread 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, ye

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

2012-01-01 Thread 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 > >

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

2012-01-01 Thread 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

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

2012-01-01 Thread 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, e

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

2012-01-01 Thread 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 w

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

2012-01-01 Thread 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 reaso

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

2012-01-01 Thread 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" t

Re: from / to /usr/: a summary

2012-01-01 Thread 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 p

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

2012-01-01 Thread 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 oth

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

2012-01-01 Thread 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

Re: from / to /usr/: a summary

2012-01-01 Thread 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 des

Re: from / to /usr/: a summary

2012-01-01 Thread 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

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

2012-01-01 Thread 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/wrapp

Re: from / to /usr/: a summary

2012-01-01 Thread 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 les

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

2012-01-01 Thread 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

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

2012-01-01 Thread 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 can

Re: from / to /usr/: a summary

2012-01-01 Thread 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

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

2012-01-01 Thread 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

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

2012-01-01 Thread 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 > P

Re: from / to /usr/: a summary

2012-01-01 Thread 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 wor

Re: from / to /usr/: a summary

2012-01-01 Thread 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, b

Re: from / to /usr/: a summary

2012-01-01 Thread 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 (

Re: from / to /usr/: a summary

2012-01-01 Thread 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.0

Re: from / to /usr/: a summary

2012-01-01 Thread 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

Re: from / to /usr/: a summary

2012-01-01 Thread 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

Re: from / to /usr/: a summary

2012-01-01 Thread 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

Re: from / to /usr/: a summary

2012-01-01 Thread 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

Re: from / to /usr/: a summary

2012-01-01 Thread 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, assumin

Re: from / to /usr/: a summary

2012-01-01 Thread 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 >> semant

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

2012-01-01 Thread 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 a