On Sat, Oct 07, 2017 at 01:00:41AM +0100, James Clarke wrote:
> >
> > Doesn't happen here. The _source and _arch changes files only differ by
> > the generate binaries:
>
> I assume this is because in Andreas's case, debsign is automatically run
> on one of the .changes files after the build,
On Fri, Oct 06, 2017 at 10:04:00AM +0200, Guido Günther wrote:
> Hi,
> On Thu, Oct 05, 2017 at 09:26:04PM +0200, IOhannes m zmölnig (Debian/GNU)
> wrote:
> > On 10/05/2017 06:53 PM, Andreas Tille wrote:
> > > Bad checksums on loki_2.4.7.4-7_source.changes: Checksum mismatch for
> > > file
Hi,
On Thu, Oct 05, 2017 at 09:26:04PM +0200, IOhannes m zmölnig (Debian/GNU) wrote:
> On 10/05/2017 06:53 PM, Andreas Tille wrote:
> > Bad checksums on loki_2.4.7.4-7_source.changes: Checksum mismatch for file
> > loki_2.4.7.4-7.dsc: b4d2841416822842e6e6b85c44e3f4f3 !=
> >
On 10/05/2017 06:53 PM, Andreas Tille wrote:
> Bad checksums on loki_2.4.7.4-7_source.changes: Checksum mismatch for file
> loki_2.4.7.4-7.dsc: b4d2841416822842e6e6b85c44e3f4f3 !=
> 7acc0c03ab3a269d117decd6dd692967
>
> What to try next?
following this conversation with interest, i also tried
On Tue, Oct 03, 2017 at 06:55:38PM +0200, Andreas Tille wrote:
> On Tue, Oct 03, 2017 at 12:17:05AM -0500, Michael Lustfield wrote:
> > > I tried both but with no success. :-(
> >
> > Then you obviously need a third option!
> > I use `SOURCE_ONLY_CHANGES=yes` in `~/.pbuilderrc`.
>
> Works!
>
>
On Tue, Oct 03, 2017 at 12:17:05AM -0500, Michael Lustfield wrote:
> > I tried both but with no success. :-(
>
> Then you obviously need a third option!
> I use `SOURCE_ONLY_CHANGES=yes` in `~/.pbuilderrc`.
Works!
Thanks for the hint,
Andreas.
--
http://fam-tille.de
Hi,
On Mon, Oct 02, 2017 at 09:49:35AM +0200, Andreas Tille wrote:
> Hi Carsten,
>
> On Sun, Oct 01, 2017 at 06:00:05PM +0200, Carsten Schoenert wrote:
> > Guido pointed me some times ago to the following additions to my local
> > setup in ~/.gbp.conf. That do the trick always create a
Hi,
On Sun, Oct 01, 2017 at 06:00:05PM +0200, Carsten Schoenert wrote:
> Hi Andreas,
>
> Am 01.10.2017 um 17:37 schrieb Andreas Tille:
>
> > I confirm that I remember times when I had the same _source.chanegs
> > alongside the _.changes but for some reason the source changes are
> > missing now
On Mon, Oct 2, 2017 at 2:49 AM, Andreas Tille wrote:
> Hi Carsten,
>
> On Sun, Oct 01, 2017 at 06:00:05PM +0200, Carsten Schoenert wrote:
>> Guido pointed me some times ago to the following additions to my local
>> setup in ~/.gbp.conf. That do the trick always create a
On Mon, Oct 02, 2017 at 01:03:42PM +0200, Adam Borowski wrote:
> On Mon, Oct 02, 2017 at 12:35:42PM +0200, Marc Haber wrote:
>> Or, are the logs available somewhere an ordinary DD can see?
No.
> Non-DDs/DMs have no reason to check upload problems. On the other hand, a
> DD/DM is likely to hit
On Mon, Oct 02, 2017 at 12:35:42PM +0200, Marc Haber wrote:
> On Mon, 02 Oct 2017 09:08:05 +0200, Joerg Jaspert
> wrote:
> >Thats not the most userfriendly one, if you have trouble with your key,
> >but its the safest option to not make us spam random people for some
> >forged
On Mon, 02 Oct 2017 09:08:05 +0200, Joerg Jaspert
wrote:
>Thats not the most userfriendly one, if you have trouble with your key,
>but its the safest option to not make us spam random people for some
>forged .changes.
Is there a web page where we can look whether our upload
Hi Carsten,
On Sun, Oct 01, 2017 at 06:00:05PM +0200, Carsten Schoenert wrote:
> Guido pointed me some times ago to the following additions to my local
> setup in ~/.gbp.conf. That do the trick always create a *source.changes
> file too.
>
> > $ cat ~/.gbp.conf
> > ...
> > [buildpackage]
> > ...
On 14812 March 1977, Attila Szalay wrote:
> For me, the uploaded package was disappeared when I accidentally used a
> wrong gpg kez to sign it. It was also mine, just an old, 1024 bit long one.
> In that case I received nothing back about the upload.
That works as designed.
As the upload queue
For me, the uploaded package was disappeared when I accidentally used a
wrong gpg kez to sign it. It was also mine, just an old, 1024 bit long one.
In that case I received nothing back about the upload.
And about the source-only upload I found another page where there are some
cases, when the
Hi Andreas,
Am 01.10.2017 um 17:37 schrieb Andreas Tille:
> I confirm that I remember times when I had the same _source.chanegs
> alongside the _.changes but for some reason the source changes are
> missing now when I call pbuilder (--cowbuilder) from git-buildpackage.
> Do I need to add some
On Thu, Sep 28, 2017 at 09:03:26PM +0200, Guido Günther wrote:
> > Nice hint in general. However, in the statsmodels case it was an upload
> > to new (due to additional binary packages) - it does not permit source
> > only uploads.
>
> Pbuilder generates a _source.chanegs alongside the _.changes
Hi,
On Wed, Sep 27, 2017 at 10:08:13PM +0200, Andreas Tille wrote:
> Hi,
>
> On Wed, Sep 27, 2017 at 07:38:22PM +0200, Andreas Metzler wrote:
> > Andreas Tille wrote:
> > [...]
> > > To answer Mattias question why not using source uploads all the time:
> > > Once I have build
Quoting Andreas Metzler (2017-09-27 19:38:22)
> Andreas Tille wrote:
> [...]
> > To answer Mattias question why not using source uploads all the time:
> > Once I have build the package to see whether all those lintian issues
> > are fixed I want to fix I have a sensible package
Hi,
On Wed, Sep 27, 2017 at 07:38:22PM +0200, Andreas Metzler wrote:
> Andreas Tille wrote:
> [...]
> > To answer Mattias question why not using source uploads all the time:
> > Once I have build the package to see whether all those lintian issues
> > are fixed I want to fix I
Andreas Tille wrote:
[...]
> To answer Mattias question why not using source uploads all the time:
> Once I have build the package to see whether all those lintian issues
> are fixed I want to fix I have a sensible package to upload and somehow
> this workflow to upload what is
I need to correct myself
On Wed, Sep 27, 2017 at 02:46:00PM +0200, Andreas Tille wrote:
> BTW, I did several uploads today and a single one of statsmodels did
> not arrived somewhere - seems the same case as OP had.
The according mails arrived right after I wrote this in my inbox -
may be only
Hi,
On Tue, Sep 26, 2017 at 07:21:51PM +0200, Adam Borowski wrote:
> > > Indeed, dupload worked right ahead. Thanks.
> >
> > How odd. Is there a bug filed against dput ?
>
> Also note there's also dput-ng.
I like dput-ng a lot and I'm using it. However, I'm *frequently*
observing failed
On Tue, Sep 26, 2017 at 07:21:51PM +0200, Adam Borowski wrote:
> > > > I now use dupload which does not have that kind of issues.
> > > Indeed, dupload worked right ahead. Thanks.
> > How odd. Is there a bug filed against dput ?
> Also note there's also dput-ng.
Look! Squirrels!
--
cheers,
Hi,
Norbert Preining writes:
>> I now use dupload which does not have that kind of issues.
>
> Indeed, dupload worked right ahead. Thanks.
dput should also allow uploads via rsync-over-ssh (or scp or sftp) which
also allows resuming uploads. The default dput.cf doesn't include it,
but I have
On Tue, Sep 26, 2017 at 06:03:24PM +0100, Ian Jackson wrote:
> Norbert Preining writes ("Re: ftp master uploads disappearing?"):
> > Dominique Dumont:
> > > I now use dupload which does not have that kind of issues.
> >
> > Indeed, dupload worked right ahea
Norbert Preining writes ("Re: ftp master uploads disappearing?"):
> Dominique Dumont:
> > I now use dupload which does not have that kind of issues.
>
> Indeed, dupload worked right ahead. Thanks.
How odd. Is there a bug filed against dput ?
Ian.
On Tue, Sep 26, 2017 at 08:46:42AM +0900, Norbert Preining wrote:
> > I now use dupload which does not have that kind of issues.
>
> Indeed, dupload worked right ahead. Thanks.
And btw, why do you keep uploading binaries now that source only uploads
are finally available?
> I now use dupload which does not have that kind of issues.
Indeed, dupload worked right ahead. Thanks.
Norbert
--
PREINING Norbert http://www.preining.info
Accelia Inc. +JAIST +TeX Live +Debian Developer
GPG: 0x860CDC13 fp: F7D8 A928
On Monday, 25 September 2017 22:28:35 CEST Norbert Preining wrote:
> Umpf, interesting. dput was quite happy with the upload, but somehow
> actually it didn't work out.
>
> Seems to be a serious bug in dput!
I had a lot of trouble with dput on a slow connection: a too long upload was
aborted.
> Sep 25 01:28:21 processing /calibre_3.8.0+dfsg-1_amd64.changes
> Sep 25 01:28:21 calibre_3.8.0+dfsg-1_all.deb is too small (ignored for now)
Umpf, interesting. dput was quite happy with the upload, but somehow
actually it didn't work out.
Seems to be a serious bug in dput!
Norbert
--
On 09/25/2017 09:01 AM, Norbert Preining wrote:
> Hi Dominique,
>
> (please Cc)
>
>> There was an outage on Debian server that happened Friday and Saturday. This
>> isssue was announced on debian-infrastruture-announce.
>
> Ah, ok, thanks. Dropped, all of them.
>
>> I guess that your packages
Hi Dominique,
(please Cc)
> There was an outage on Debian server that happened Friday and Saturday. This
> isssue was announced on debian-infrastruture-announce.
Ah, ok, thanks. Dropped, all of them.
> I guess that your packages were either silently processed (check the PTS) or
> dropped.
On Monday, 25 September 2017 16:01:18 CEST Norbert Preining wrote:
> The same happened today, I uploaded calibre 3.8.0 and didn't get any
> response whatsoever from the upload server.
>
> Are the servers back up running?
I don't know the exact status. All I can say is that I uploaded libconfig-
On Monday, 25 September 2017 08:51:49 CEST Norbert Preining wrote:
> is there anything known about the status of ftp-master?
There was an outage on Debian server that happened Friday and Saturday. This
isssue was announced on debian-infrastruture-announce.
I guess that your packages were either
Hi all,
(please CC)
is there anything known about the status of ftp-master? I couldn't
find any warning or announcement, but I did upload three packages,
one was rejected and re-uploaded with a fix (for a stupidity in
lintian), but these three packages *never* got processed. Not
even an answer
36 matches
Mail list logo