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
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
* 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
* 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
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
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
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
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
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 (
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
"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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
> >
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
30 matches
Mail list logo
