Wouter Verhelst writes:
> On Sun, Jan 27, 2013 at 07:16:44PM +0100, Jakub Wilk wrote:
>> Dmitrijs Ledkovs wrote on his blog[0]:
>>
>> >Generally if software is useful in Debian Project it can be useful
>> >for other debian-like and unlike projects. In particular native
>> >packages do not offer
On 27 January 2013 18:32, Gergely Nagy wrote:
> Jakub Wilk writes:
>
>> Dmitrijs Ledkovs wrote on his blog[0]:
>>
>>> Generally if software is useful in Debian Project it can be useful
>>> for other debian-like and unlike projects. In particular native
>>> packages do not offer the same patching
Dear Developers,
How this package, named pidstat works on Debian? or i'm
looking for ghosts?
http://linuxaria.com/howto/linux-terminal-pidstat-know-everything-about-your-processes?lang=en
Thanks in advance
gnugr
--
Le 28/01/2013 10:47, vangelis mouhtsis a écrit :
> Dear Developers,
> How this package, named _pidstat _works on Debian? or i'm looking for
> ghosts?
>
> http://linuxaria.com/howto/linux-terminal-pidstat-know-everything-about-your-processes?lang=en
>
> Thanks in advance
> gnugr
> --
Hi,
this i
So, is it ok?
Index: screen/tty.sh
===
--- screen.orig/tty.sh 2013-01-27 02:16:57.916935245 +
+++ screen/tty.sh 2013-01-27 02:33:12.831241123 +
@@ -1506,11 +1506,21 @@
char *tty;
{
struct stat st;
+ char * real;
+
Package: wnpp
Severity: wishlist
Owner: Jon Dowland
* Package name: squishyball
Version : 0.1~svn18785
Upstream Author : Monty
* URL : http://svn.xiph.org/trunk/squishyball/
* License : GPL
Programming Lang: C
Description : audio sample comparison test
Gergely Nagy writes:
...
> We have tools that make it easy to create upstream tarballs from an SCM
> repo. Git has git archive, gitpkg and possibly other tools make it very
> easy to create upstream tarballs: so much so, that it means nothing more
> than tagging the repo properly.
>
> I've been us
Hi,
I have a package (closure-compiler[1]) with files copyrighted by six different
parties unsystematically distributed over a large source tree.
Has anybody already written a tool to automatically create the files section
of the debian/copyright file? The tool should try to keep the files list
On 01/28/2013 12:58 PM, Thomas Koch wrote:
I have a package (closure-compiler[1]) with files copyrighted by six different
parties unsystematically distributed over a large source tree.
Has anybody already written a tool to automatically create the files section
of the debian/copyright file? The
On Mon, Jan 28, 2013 at 7:58 PM, Thomas Koch wrote:
> I have a package (closure-compiler[1]) with files copyrighted by six different
> parties unsystematically distributed over a large source tree.
>
> Has anybody already written a tool to automatically create the files section
> of the debian/cop
John Paul Adrian Glaubitz writes:
>> Has anybody already written a tool to automatically create the files section
>> of the debian/copyright file? The tool should try to keep the files list
>> short
>> by using wildcards.
http://lindi.iki.fi/lindi/git/git-copyright-scan.git/
Normal invocation:
On the other side of the fence are folks who believe in the separation
between upstream and Debian so much that they refuse to package
software they are upstream for (I'm not among them, but I know they
exist).
--
bye,
pabs
http://wiki.debian.org/PaulWise
--
To UNSUBSCRIBE, email to debian-de
On 28/01/2013 13:04, Paul Wise wrote:
> licensecheck is obviously not as complete as something like fossology
Fossology seems to have been removed because it was un-maintained,
(ITP #483297 then RoQA #656591 at version 1.1.0).
But upstream looks (very) active and released version 2.1.0 three month
On Mon, 2013-01-28 at 13:28 +0100, Jérémy Lal wrote:
> Fossology seems to have been removed because it was un-maintained,
> (ITP #483297 then RoQA #656591 at version 1.1.0).
> But upstream looks (very) active and released version 2.1.0 three months ago.
> Paul, do you think it is worth bringing it
Let's start to collect examples of package which we might should rather not be
native. This might make the discussion easier.
- maven-repo-helper, maven-debian-helper
both packages contain a lot of logic that would also be usefull for other
distributions, e.g. fedora. However the code needs a
On Mon, 2013-01-28 at 14:17 +0200, Timo Juhani Lindfors wrote:
> John Paul Adrian Glaubitz writes:
> >> Has anybody already written a tool to automatically create the files
> >> section
> >> of the debian/copyright file? The tool should try to keep the files list
> >> short
> >> by using wildcar
Philip Hands writes:
> Gergely Nagy writes:
> ...
>> We have tools that make it easy to create upstream tarballs from an SCM
>> repo. Git has git archive, gitpkg and possibly other tools make it very
>> easy to create upstream tarballs: so much so, that it means nothing more
>> than tagging the
Thomas Koch, 2013-01-28 12:58:43 +0100 :
> Hi,
>
> I have a package (closure-compiler[1]) with files copyrighted by six
> different
> parties unsystematically distributed over a large source tree.
>
> Has anybody already written a tool to automatically create the files section
> of the debian/c
On Mon, 2013-01-28 at 14:17:13 +0400, Игорь Пашев wrote:
> So, is it ok?
>
> Index: screen/tty.sh
> ===
> --- screen.orig/tty.sh2013-01-27 02:16:57.916935245 +
> +++ screen/tty.sh 2013-01-27 02:33:12.831241123 +
>
On 28/01/2013 20:04, Paul Wise wrote:
> licensecheck --copyright -r `find -type f` |
> /usr/lib/cdbs/licensecheck2dep5 > debian/copyright
You don't need the the `find...` bit in there. "-r" is recursive, so just
specifying "." is good enough.
licensecheck2dep5 is actually pretty good. I use it to
Package: wnpp
Severity: wishlist
Owner: Colin Watson
* Package name: gdb-heap
Version : 0.5
Upstream Author : David Malcolm
* URL : https://fedorahosted.org/gdb-heap/
* License : LGPLv2.1, Python
Programming Lang: Python
Description : gdb extension to
]] Gergely Nagy
> No, not really. I don't really care what tools one uses, as long as the
> result is reasonably easy *and* reliable to work with. Since VCS can be
> stale, and quite often does not include neither NMUs, nor backports,
> that fails the reliable requirement.
It sounds like you are
Gergely Nagy balabit.hu> writes:
> There's also the case where upstream and debian maintainer are the same
> *now*, but that can change anytime. Case in point: there's a package[1]
That’s actually (one of) the reasons why I’m not using native packages
for the software I’m upstream of, or working
Tollef Fog Heen writes:
> ]] Gergely Nagy
>> No, not really. I don't really care what tools one uses, as long as the
>> result is reasonably easy *and* reliable to work with. Since VCS can be
>> stale, and quite often does not include neither NMUs, nor backports,
>> that fails the reliable requi
On Mon, Jan 28, 2013 at 09:36:45AM -0800, Russ Allbery wrote:
> Tollef Fog Heen writes:
> > ]] Gergely Nagy
>
> >> No, not really. I don't really care what tools one uses, as long as the
> >> result is reasonably easy *and* reliable to work with. Since VCS can be
> >> stale, and quite often does
On 28 January 2013 18:17, Roger Leigh wrote:
> On Mon, Jan 28, 2013 at 09:36:45AM -0800, Russ Allbery wrote:
>> Tollef Fog Heen writes:
>> > ]] Gergely Nagy
>>
>> >> No, not really. I don't really care what tools one uses, as long as the
>> >> result is reasonably easy *and* reliable to work with
Roger Leigh writes:
> Maybe I forgot the answer, but at least in terms of git and the dpkg 3.0
> (git) format, why can't we simply make use of shallow cloning? We only
> distribute a single revision, the one we're building, and if the history
> is polluted for whatever reason, it has no impact--
On Mon, Jan 28, 2013 at 18:17:20 +, Roger Leigh wrote:
> On Mon, Jan 28, 2013 at 09:36:45AM -0800, Russ Allbery wrote:
> > Tollef Fog Heen writes:
> > > ]] Gergely Nagy
> >
> > >> No, not really. I don't really care what tools one uses, as long as the
> > >> result is reasonably easy *and*
Hi,
On Montag, 28. Januar 2013, Ben Hutchings wrote:
> Do not assume that authors are copyright holders.
this(!), and you also don't have to repeat detailed copyright ownership
information in debian/copyright - it's fine if that information is scattered
along these files itself, as long as thes
On Sun, Jan 27, 2013 at 07:16:44PM +0100, Jakub Wilk wrote:
> I am guilty myself of maintaining a native package (and another one
> is waiting in NEW). However, I will be happy to switch to a
> non-native format once I figure out a releasing work-flow that is
> convenient for me.
Changing from nati
I demand that Adam Borowski may or may not have written...
[snip]
> No, it's something in the middle. Those who dislike systemd say it
> exaggerates systemd's claimed benefits, while Joss considers it an attack
> as well. Let's no go there for now.
>
> What makes this article worth reading is t
Am Dienstag, den 29.01.2013, 08:49 +1100 schrieb Craig Small:
> On Sun, Jan 27, 2013 at 07:16:44PM +0100, Jakub Wilk wrote:
> > I am guilty myself of maintaining a native package (and another one
> > is waiting in NEW). However, I will be happy to switch to a
> > non-native format once I figure out
* Michael Stapelberg:
> Go libraries (not binaries!) should be present in Debian _only_ for
> the purpose of building Debian binary packages. They should not be
> used directly for Go development¹.
This is a pity for those of us who don't really subscribe to "get
everything from github as needed"
Benjamin Drung (28/01/2013):
> Other distributions gain from your extra work. Image the
> opposite. You want to package a software that is only available in a
> downstream distribution (e.g. Ubuntu or Linux Mint). Do you prefer
> to have a non-native format or a native format?
“upstream first” an
On Fri, Jan 18, 2013 at 10:11:50AM -0600, Paul Johnson wrote:
>
> $ dpkg -l | grep libc6
> ii libc6:amd64 2.13-37 amd64
> ii libc6:i3862.13-37 i386
> ii libc6-amd64 2.13-37 i386
> ii libc6-i3862.13-37 amd64
So you basicly have libc6 installed 4 times, twice for i386 and
twice
On Mon, Jan 28, 2013 at 11:59:56PM +0100, Benjamin Drung wrote:
> Other distributions gain from your extra work. Image the opposite. You
> want to package a software that is only available in a downstream
> distribution (e.g. Ubuntu or Linux Mint). Do you prefer to have a
> non-native format or a n
Benjamin Drung writes:
> Other distributions gain from your extra work. Image the opposite. You
> want to package a software that is only available in a downstream
> distribution (e.g. Ubuntu or Linux Mint). Do you prefer to have a
> non-native format or a native format?
I'm not sure I see how i
On Mon, Jan 28, 2013 at 09:44:18AM +0100, Gergely Nagy wrote:
> Wouter Verhelst writes:
>
> > On Sun, Jan 27, 2013 at 07:16:44PM +0100, Jakub Wilk wrote:
> >> Dmitrijs Ledkovs wrote on his blog[0]:
> >>
> >> >Generally if software is useful in Debian Project it can be useful
> >> >for other debi
Package: wnpp
Severity: wishlist
Owner: Theppitak Karoonboonyanan
* Package name: ibus-libthai
Version : (to be released from
http://linux.thai.net/svn/software/ibus-libthai/trunk)
Upstream Author : Theppitak Karoonboonyanan
* URL : http://linux.thai.net/projects/lib
[Benjamin Drung]
> Image the opposite. You want to package a software that is only
> available in a downstream distribution (e.g. Ubuntu or Linux
> Mint). Do you prefer to have a non-native format or a native format?
If their native format is an archive in gzipped tar file format, like
ours is, I
]] Russ Allbery
> Tollef Fog Heen writes:
> > ]] Gergely Nagy
>
> >> No, not really. I don't really care what tools one uses, as long as the
> >> result is reasonably easy *and* reliable to work with. Since VCS can be
> >> stale, and quite often does not include neither NMUs, nor backports,
>
Hi Hilko,
Hilko Bengen writes:
> This is a pity for those of us who don't really subscribe to "get
> everything from github as needed" model of distributing software.
Yes, but at the same time, it makes Go much more consistent across
multiple platforms. We should tackle one issue at a time. I sup
Hello.
I have the next error:
~# update-grub
Searching for GRUB installation directory ... found: /boot/grub
Searching for default file ... Generating /boot/grub/default file and setting
the default boot entry to 0
entry not specified.
Usage: grub-set-default [OPTION] entry
Set the default
43 matches
Mail list logo
