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
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
]] 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,
>
[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
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
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
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 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
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
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
* 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"
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
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
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
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 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*
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 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
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
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
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
]] 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
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
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
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 +
>
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
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
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
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 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
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 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
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 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
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
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
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
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
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;
+
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
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
--
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
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
43 matches
Mail list logo
