On Tue, Jun 15, 2010 at 06:49:10PM -0600, Lloyd Standish wrote:
> I looked at zenity. From the man page which describes the command line
> options, I don't think it is capable of a complex dialog with different types
> of input fields and action buttons, all available in the same multi-tabbed
>
Norbert,
Thanks very much for pointing out how lintian is used to check a source
package. I would have seen this if I had read the lintian man page carefully.
I looked at zenity. From the man page which describes the command line
options, I don't think it is capable of a complex dialog with
On Di, 15 Jun 2010, Lloyd Standish wrote:
> Of course I came to that idea by running lintian (Lintian v1.24.2.1+lenny1)
> against the binary deb. It reported nothing (clean). I think the problem is
> that I am running the Debian stable (Lenny) version of dpkg-dev, and you are
> probably runnin
On 2010-06-15, Lloyd Standish wrote:
> It did not occur to me to check for gtkdialog in Sid (it is available
> in Lenny http://packages.debian.org/lenny/gtkdialog). So, until
> there is a gtkdialog package in Sid, snap2 cannot run. This is a
> great disappointment - I put a lot of effort into
Dear Norbert,
Thank you for your help with my snap2 project.
The package appears to be lintian-clean.
How do you come to that idea?
Of course I came to that idea by running lintian (Lintian v1.24.2.1+lenny1)
against the binary deb. It reported nothing (clean). I think the problem is
tha
On Di, 15 Jun 2010, Lloyd Standish wrote:
> Debian source: http://files.lstandish.com/snap2-source
>
> The package appears to be lintian-clean.
How do you come to that idea?
I unpacked your package, built it with dpkg-buildpackage -us -uc -rfakeroot,
and run lintian on the resulting package:
$ ls
Hello All,
My previous RFS for this package was premature because I had not prepared the
Debian source files. Even though the package contains no compiled code, this
was a gross omission, for which I apologize. I have carefully built the Debian
source files according to the documentation.
H
On Fr, 11 Jun 2010, Russ Allbery wrote:
> I don't think this has the implication that it sounds like you believe it
> has. Suppose that you're packaging something where upstream includes a
Thanks Russ, I completely agree. In fact I ask upstream to not ship
debian.
I only wanted to make clear tha
On Sa, 12 Jun 2010, Bernhard R. Link wrote:
> No, it is exactly correct and one of the important improvements of v3
> that the .orig.tar.gz's debian/ dir is completely removed.
Contraticted, I agree that v3 has lots of improvements, that is not
one of it.
Wasn't there *one* point in the list of i
* Thomas Goirand [100612 07:54]:
> I am quite sure that I read it somewhere, however, I can't find it again.
It was more important in the past. Since there is the version 3 source
format, an debian/ directory in the upstream tarball is only unecessary
and no longer harmful. So no longer any need
* Norbert Preining [100612 06:49]:
> > One of the ways dpkg-source v3 differs from dpkg-source v1 is that any
> > debian/ directory in the orig.tar.gz is removed before the
> > debian.tar.gz is unpacked. So debian.tar.gz cannot be empty and the
> > upstream debian/ directory if any is irrelevant.
Norbert Preining wrote:
> On Sa, 12 Jun 2010, Thomas Goirand wrote:
>
>> Quite not!!! It is even written in many places that if the upstram ships a
>> debian folder in its tar.gz, we should get in touch and at least ask that it
>> is renamed as debian-upstream or something similar. If you do n
Norbert Preining writes:
> On Sa, 12 Jun 2010, Paul Wise wrote:
>> One of the ways dpkg-source v3 differs from dpkg-source v1 is that any
>> debian/ directory in the orig.tar.gz is removed before the
>> debian.tar.gz is unpacked. So debian.tar.gz cannot be empty and the
>> upstream debian/ direct
On Sat, Jun 12, 2010 at 12:49 PM, Norbert Preining wrote:
> That is not compliant with what it *SHOULD* do. If there is a debian
> dir in upstream (again, anyone showing me the policy point forbidding
> that) then files in their should be replaced or whatever, but
> it is not correct (IMHO) that
On Sa, 12 Jun 2010, Paul Wise wrote:
> > Of course upstream can ship all necessary debian files as is, where is
> > the problem? Then the diff would be empty, or the debian.tar.gz would
> > be empty, and that is fine.
>
> One of the ways dpkg-source v3 differs from dpkg-source v1 is that any
> deb
On Sa, 12 Jun 2010, Thomas Goirand wrote:
> Quite not!!! It is even written in many places that if the upstram ships a
> debian folder in its tar.gz, we should get in touch and at least ask that it
> is renamed as debian-upstream or something similar. If you do not trust what
> I say, go read th
Hi,
Since my snap2 source is debianized, I though maybe this could be a "Debian native
package," and avoid the diff.gz entirely. However, in the debian-mentors FAQ by
Matthew Palmer (http://people.debian.org/~mpalmer/debian-mentors_FAQ.html) I see the
following advice:
"When to use a native
- Original message -
> On Sa, 12 Jun 2010, Thomas Goirand wrote:
> > While it is ok to keep your debian folder in your VCS, remember that
> > your orig.tar.gz should NOT contain it. It's less of an issue if you
> > use source format 3.0 (Quilt) but this is still the policy in Debian.
>
>
On Sat, Jun 12, 2010 at 11:20 AM, Norbert Preining wrote:
> Of course upstream can ship all necessary debian files as is, where is
> the problem? Then the diff would be empty, or the debian.tar.gz would
> be empty, and that is fine.
One of the ways dpkg-source v3 differs from dpkg-source v1 is t
On Sa, 12 Jun 2010, Thomas Goirand wrote:
> While it is ok to keep your debian folder in your VCS, remember that
> your orig.tar.gz should NOT contain it. It's less of an issue if you use
> source format 3.0 (Quilt) but this is still the policy in Debian.
That is a recommendation, but by far not a
Lloyd Standish wrote:
> Johan, your suggestion of looking at at art package was very helpful.
> I get a (separate) source package together as soon as I can.
>
> It is ironic in this case that the "upstream source tree" that I
> develop from is (except for the changlog files and man page, which I
>
Hello Thomas,
Yes, I mean "arch independent" due to the fact that it is written in bash, an
interpreted language.
What I am pointing out is that anyone who downloads the "binary" deb package has all the
"source" that I do. But, again, I understand the rules for a separate source package,
and
I agree. That's one of the reasons I wrote snap2. Users do not have to know
what a hard link is to use the program, nor touch any configuration files, nor
use the command line. When accessing the snapshot backups on the backup media,
the fact that most of the files are hard-linked together w
Johan, your suggestion of looking at at art package was very helpful. I get a
(separate) source package together as soon as I can.
It is ironic in this case that the "upstream source tree" that I develop from
is (except for the changlog files and man page, which I keep elsewhere) an exact copy
Sorry if I express my maybe unrequested opinion, but my search of a
really usable backup software ([0]) lately made me think that maybe
(hopefully) writers of backup software would appreciate some more
feedback.
Il giorno ven, 11/06/2010 alle 01.18 -0600, Lloyd Standish ha scritto:
> You may alrea
@Thomas,
Thanks for your comments.
Screenshots of the snap2 GUI are here: http://linuxbackups.org/node/25.
I did not mention every feature of snap2 in my RFS (I did however link to the
program webpage where you could read more about it.) snap2 does *not* do
exactly the same thing as Dirvish.
Lloyd Standish wrote:
> Hello DD's:
>
> My name is Lloyd Standish. I am the author and upstream maintainer of
> snap2, a fast, easy-to-use rsync-based backup program with GUI. It is
> considered "tested/stable" after several months of testing. I first
> released it publicly in 2009, but I used a
Hello Lloyd,
* I see no source package. You really need one. Since you don't need
to compile anything, just specifying where files have to be copied in
the debian/install file should be sufficient. Perhaps search for
artwork packages to find examples.
Johan
On Fri, Jun 11, 2010 at 9:18 AM, Lloyd
Hello DD's:
My name is Lloyd Standish. I am the author and upstream maintainer of snap2, a fast,
easy-to-use rsync-based backup program with GUI. It is considered
"tested/stable" after several months of testing. I first released it publicly
in 2009, but I used a previous version of the scri
29 matches
Mail list logo