Package: kate
Version: 4:16.08.2-1
Severity: normal
Dear Maintainer,
Currently Kate fails to build against libgit2 0.26.0 which has just been
uploaded to experimental. Please consider updating Kates dependencies to see if
it will sucessfuly build against this newer version.
>From what I can see,
Source: gnuastro
Severity: normal
Dear Maintainer,
Please consider investigating why gnuasto [1] won't build against libgit2
0.26.0 in experimental.
>From what I can see there are no newer versions with explicit support, but it
may build anyway if the dependencies are updated.
Thanks,
Russell
Package: ruby-rugged
Version: 0.24.0+ds1-3
Severity: normal
Dear Maintainer,
Please consider updating ruby-rugged to the latest version 0.26.0.
libgit2 0.26.0 has been uploaded to experimental.
Cheers,
Russell
-- System Information:
Debian Release: 9.0
APT prefers unstable
APT policy: (9
Package: libgit2-glib-1.0-0
Version: 0.24.4-1
Severity: normal
Dear Maintainer,
Please consider updating to the latest upstream stable release of libgit2-glib
v0.26.0 as soon as possible.
libgit2 0.26.0 has been uploaded to experimental.
Thanks,
Russell
-- System Information:
Debian Release:
Package: fritzing
Version: 0.9.3b+dfsg-4
Severity: normal
Dear Maintainer,
A new version of libgit2 0.26.0 has been added to Experimental. It appears
that the version of fritzing in unstable won't build against this version [1].
>From what I can see Debian has the latests version of Fritzing.
id you
> get this from?
>
> Did you pull into stable intermediate packages from unstable?
I run unstable so I must have installed it from unstable.
--
Cheers,
Russell Sim
On 20 August 2017 at 17:10, Abhijith PA wrote:
>
> > The latest version of libgit2 is 0.26 and it has been uploaded to
> > experimental. Is ruby-rugged 0.26 compatible with GitLab?
> >
> >
> > --
> > Cheers,
> > Russell Sim
>
> No, ruby-r
-rugged 0.26 compatible with GitLab?
--
Cheers,
Russell Sim
Package: texlive-science-doc
Version: 2017.20170809-1
Severity: normal
Dear Maintainer,
During the process of updating some texlive packages, I ended up in a situation
where a package was trying to overwrite a file from another texlive package.
I'm not sure what the correct process is here, but
On 1 August 2017 at 14:47, Ximin Luo wrote:
> Ximin Luo:
> > Russell Sim:
> >>> [..]
> >>>
> >>> $ echo $(aptitude search --disable-columns -F "%p" '~Dlibgit2-24
> ~rnative
> >>> !~e^libgit2$')
> >>> ees
On 27 July 2017 at 14:01, Ximin Luo wrote:
> Russell Sim:
> > [..]
> >
> > Thank you for the in depth description it was very helpful. I was
> thinking
> > the same, but just wanted to clarify.
> >
> > I have tried to upload a new version, but was
On 27 July 2017 at 02:40, Ximin Luo wrote:
> Russell Sim:
> > Hey,
> >
> > I'm about to do an upload and I was wondering if you thought it would
> make
> > sense to start shipping this package with a versioned -dev package. At
> the
> > moment the d
GB.utf8 (charmap=UTF-8),
> LANGUAGE=en_GB:en (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages libgit2-dev depends on:
> ii libcurl4-gnutls-dev7.52.1-5
> ii libgit2-25 0.25.1.0-1
> ii libhttp-parser-dev 2.1-2
> ii libssh2-1-dev 1.8.0-1
> ii zlib1g-dev [libz-dev] 1:1.2.8.dfsg-5
>
> libgit2-dev recommends no packages.
>
> libgit2-dev suggests no packages.
>
> -- no debconf information
>
--
Cheers,
Russell Sim
CVE-2016-10129, CVE-2016-10130)
+(Closes: #851406)
+
+ -- Russell Sim Sun, 21 May 2017 18:18:47 +0200
+
+libgit2 (0.25.1-2) unstable; urgency=medium
+
+ * Upload to unstable
+
+ -- Russell Sim Sat, 20 May 2017 19:27:39 +0200
+
+libgit2 (0.25.1-1) experimental; urgency=medium
+
+ * New upstream
(300, 'unstable'), (200, 'experimental'), (1,
> 'experimental-debug')
> Architecture: amd64
> (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=U
Hey Ximin,
Actually, if you have any advice on what I should do to change the ACL it
would be appreciated. I have a feeling that every time a new version is
released, this ACL will prevent upload.
Thanks,
Russell
On 1 May 2017 21:11, "Russell Sim" wrote:
> Hey Ximin,
>
&
efore the upload? I'm here
> to help, if you need.
>
> I've actually already built this tag locally, and have been using it to
> build cargo with. It works well from that perspective at least.
>
> Ximin
>
> Russell Sim:
> > Hi,
> >
> > Sure thing,
#x27;), (1, 'experimental-debug')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.9.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
--
Cheers,
Russell Sim
tch (Closes: #841532)
+ * Correcty address CVE-2016-8568
+
+ -- Russell Sim Mon, 02 Jan 2017 20:35:08 +1100
+
libgit2 (0.24.2-2) unstable; urgency=medium
* Upload to unstable.
diff -Nru libgit2-0.24.2/debian/patches/commit-always-initialize-commit-message.patch libgit2-0.24.5/debian/p
Hi,
Sorry, I messed this up.
The fix for CVE-2016-8569 was included in the 0.24.2-1 release but the
fix for CVE-2016-8568 wasn't.
Sorry about that, I have pushed a new version to unstable that includes
the fix, the version is 0.24.5-1. I realised the mistake when I was
reviewing some diffs befo
k that it would make it past
freeze. But it appears that my assumption was mistaken. Thanks for
prodding me
I'll wait until after the full freeze to package and push 0.25.0 to
experimental.
Thanks,
Russell
On 28 December 2016 at 00:27, Andreas Henriksson wrote:
> Hello Russell Sim.
>
amb writes:
> forwarded 841532 https://github.com/libgit2/libgit2/issues/3970
> thanks
>
> Russell Sim wrote:
>
>> I have forwarded this bug report upstream
>> https://github.com/libgit2/libgit2/issues/3970 in the mean time I'll add
>> a fix to the existing pa
Chris Lamb writes:
Hi Chris,
Thanks for reporting this,
I have forwarded this bug report upstream
https://github.com/libgit2/libgit2/issues/3970 in the mean time I'll add
a fix to the existing package to force tests to run in GMT timezone.
> Source: libgit2
> Version: 0.24.1-2
> Severity: seri
; https://github.com/andhe/pkg-libgit2
>
> ruby-rugged is ready.
>
>
--
Cheers,
Russell Sim
of GPLed projects?
>
Fair call, this should be pretty straight forward. I thought it was
required for threading, but this doesn't seem to be the case.
A new version will be released shortly, I can move to the gnutls version of
curl then.
Thanks for looking into this.
--
Cheers,
Russell Sim
l we create a new team
> for it? Anything which is ok to you will be ok for me, as long as we can
> work in a better way, as a team.
>
I'm happy to join the OpenStack packaging team, I work on OpenStack during
my day job.
--
Cheers,
Russell Sim
3942 86EC 74C3 5394 479D D352 4C51
>
>
--
Cheers,
Russell Sim
Dmitry Smirnov writes:
> Why not add both files to "debian/clean"? That would be the easiest.
Thanks, I was using a rm in the rules file. But the debian/clean method
is better. I didn't know about the clean files but I find it mentioned
in the dh_auto_clean man page. Doesn't seem to be covere
Hi Dmitry,
Dmitry Smirnov writes:
> Just uploaded libgit2 introduced serious regression due to loss of bindings
> with libssh2 which causes loss of symbols in dependent library "libgit2-glib"
> and then in turn FTBFS in "gitg".
>
> Quoting "CHANGELOG.md":
>
> * The search for libssh2 is no
Hi Dmitry,
Dmitry Smirnov writes:
> Libgit2 leaves its build directory dirty hence it FTBFS when built again:
>
> dpkg-source: info: local changes detected, the modified files are:
> libgit2-0.22.2/tests/.clarcache
> libgit2-0.22.2/tests/clar.suite
I've had a look at this and it
Shawn Landden writes:
> git2go, the libgit2 go bindings, only support v22+ Could you please
> package v22, thanks.
Sorry for the late reply, I'm building this now should be uploaded in
the next couple of days. I was waiting for Jessie release.
--
Cheers,
Russell
--
To UNSUBSCRIBE, email to
accepted
https://packages.qa.debian.org/libg/libgit2/news/20150222T113335Z.html
Thanks!
--
Cheers,
Russell Sim
On 11 February 2015 at 23:24, Russell Sim wrote:
> On 9 February 2015 at 09:36, Mehdi Dogguy wrote:
>
>> I'm afraid we cannot accept 0.21.3-1.1 in Jessie because the changes are
>> quite large. Can you please prepare an upload targetting jessie based on
>> 0.
port the
relevant changes to the 0.21.1-2.1
Mehdi. I'm so sorry for the noise :(
--
Cheers,
Russell Sim
diff -Nru libgit2-0.21.1/debian/changelog libgit2-0.21.1/debian/changelog
--- libgit2-0.21.1/debian/changelog 2015-01-09 09:51:34.0 +1100
+++ libgit2-0.21.1/debian/changelo
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package libgit2
The newer version of the libgit2 package fixes a security hole [0].
Sorry I realise that this is the second unblock request for this
package. But at the tim
My apologies this request should be to unblock the yet to be uploaded
libgit2/0.21.1-2 sorry for any confusion.
Russell Sim writes:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
>
> Please unblock packa
Moritz Muehlenhoff writes:
> Source: libgit2
> Severity: important
> Tags: security
>
> libgit2 is also affected by the recent git vulnerability:
> http://openwall.com/lists/oss-security/2014/12/18/21
Thanks for the heads up. The new release of libgit2 0.21.3 addresses
this issue but it will ha
13:13:06.0 +1000
+++ libgit2-0.21.1/debian/changelog 2015-01-04 13:37:53.0 +1100
@@ -1,3 +1,9 @@
+libgit2 (0.21.1-2) UNRELEASED; urgency=medium
+
+ * Fix buildd errors. (Closes: #761539)
+
+ -- Russell Sim Sun, 04 Jan 2015 13:13:57 +1100
+
libgit2 (0.21.1-1) unstable
Ivo De Decker writes:
> The failure that happens on the i386 buildd is this one:
>
> 1) Failure:
> clone::nonetwork::local_absolute_path
> [/«PKGBUILDDIR»/tests/clone/nonetwork.c:91]
> Function call failed: (git_clone(&g_repo, local_src, "./foo", &g_options))
> error -1 - git_path_direach
David Suárez writes:
> Source: libgit2
> Version: 0.21.1-1
> Severity: serious
> Tags: jessie sid
> User: debian...@lists.debian.org
> Usertags: qa-ftbfs-20140913 qa-ftbfs
> Justification: FTBFS on amd64
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build on
> amd64.
Ivo De Decker writes:
>> > The failure that happens on the i386 buildd is this one:
>> >
>> > 1) Failure:
>> > clone::nonetwork::local_absolute_path
>> > [/«PKGBUILDDIR»/tests/clone/nonetwork.c:91]
>> > Function call failed: (git_clone(&g_repo, local_src, "./foo",
>> > &g_options))
>> > e
Hi Ivo!
Ivo De Decker writes:
> On Tue, Nov 25, 2014 at 10:38:44PM +0100, Lucas Nussbaum wrote:
>> Note that the build now fails on i386 too.
>>
>> Trying to reproduce it locally, I run into yet another problem:
>>
>> 1) Failure:
>> repo::iterator::fs_preserves_error
>> [/tmp/libgit2-0.21.1
OK, I'm about to request an upload of 0.21.2. Seems that it's still
failing on kfreebsd.
1) Failure:
repo::init::extended_1 [/home/russell/libgit2-0.21.2/tests/repo/init.c:340]
Function call failed: (git_repository_init_ext(&_repo, "root/b/c.git", &opts))
error -1 - Failed to set permissi
Salvo Tomaselli writes:
> I have reported the bug upstream
> https://github.com/libgit2/libgit2/issues/2580
>
>
> It would be nice for me if this could be solved, because subsurface is stuck
> in sid otherwise.
Thanks for pushing this upstream, I was going to try and replicate this
before send
Laurent Bigonville writes:
> libgit2 is unfortunately FTBFS on multiple architectures in unstable due
> to test failures.
>
> Would be nice if the pkg was building on all the architectures.
Thanks for the report, from what I can see, 3 of the failing builds are
segfaulting in the test suite, and
Laurent Bigonville writes:
> I see. And moreover libgit is not using proper soname versioning either.
>
> I've opened https://github.com/libgit2/libgit2/issues/2398 about this.
Thanks for doing that! I didn't really understand the soname stuff, so
I didn't really know to ask.
I have also asked
Sorry for the delay getting back to you.
Laurent Bigonville writes:
> Any news about this?
>
> Other packages are depending against libgit2 (libgit2-glib-1.0-0
> directly and the latest version of gitg indirectly).
The primary reason for not uploading this to Debian Unstable is that the
ABI ch
Paul Tagliamonte writes:
> On Fri, Sep 06, 2013 at 10:35:07AM +1000, Russell Sim wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Paul Tagliamonte writes:
>>
>> > On Mon, Sep 02, 2013 at 11:32:09PM +1000, Russell Sim wrote:
>>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Paul Tagliamonte writes:
> On Mon, Sep 02, 2013 at 11:32:09PM +1000, Russell Sim wrote:
>> Paul Tagliamonte writes:
>>
>> > I notice there's a mix of GPLv2 and Apache2 code in the same binary.
>> > This comb
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Paul Tagliamonte writes:
> I notice there's a mix of GPLv2 and Apache2 code in the same binary.
> This combined work isn't distributable. It'd be super great to fix this
> by getting upstream to move to GPLv3 or dropping the apache2 code (or
> gettin
Hi Jan,
Thanks for the quick response.
Jan Wagner writes:
> this issue affects not wheezy, as libc-bin (which is essential) ships
> /usr/bin/rpcinfo. Since eglibc 2.16-0experimental0 libc-bin doesn't
> ship /usr/bin/rpcinfo anymore.
Wow, I had no idea that this was originally bundled with lib
Package: nagios-plugins
Version: 1.4.16-1
Severity: normal
Hi,
In the debian rules file it seems that the wrong path for rpcinfo is being
used. It produces messages like:
"Can't exec "/usr/bin/rpcinfo": No such file or directory
This problem appeared in Ubuntu [0] and was dealt with in svn [1]
Hey Jann,
Thanks for the report. Yes it's compiled without the THREADSAFE option
because from what I can gather it's still a work in progress. I'll see
if I can get some more clarification about it's actual state.
Regards,
Russell
Jann Horn writes:
> Package: libgit2-0
> Version: 0.17.0-1
>
ly be
confusing for anyone looking through the .h files seeing references to
nonexistent files.
Also there also reasonable safeties that prevent accidental including of
these headers in the wrong environment.
So I'm going to mark this as wontfix. Thanks for the feedback all the
same.
Regard
Package: python-doc
Version: 2.7.3~rc2-1
Severity: normal
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Dear Maintainer,
Search doesn't seem to be working in the Pytho
Alexander Wirt writes:
> Russell Sim schrieb am Wednesday, den 01. August 2012:
>
>>
>> Package: nagios3-common
>> Version: 3.4.1-2
>> Severity: normal
>>
>> Hi,
>>
>> Nagios fails to upgrade if /etc/nagios3/resources.cfg is missing,
Package: nagios3-common
Version: 3.4.1-2
Severity: normal
Hi,
Nagios fails to upgrade if /etc/nagios3/resources.cfg is missing, here is the
error from apt.
Cheers,
Russell
Setting up nagios3-common (3.4.1-2) ...
chown: cannot access `/etc/nagios3/resource.cfg': No such file or directory
dpkg:
Hey Bálint,
Bálint Réczey writes:
>>> Why does the absence of 1.0 version prevent the upload to unstable?
>>> There has been many 0.xx releases and the package can be blocked from
>>> migration to testing if it is really not ready for being released as
>>> part of Debian.
>>> I would like to uplo
Bálint Réczey writes:
> Do you plan resurrecting the package repository at GitHub?
The repository is now avaliable via alioth.debian.org [1].
1. http://anonscm.debian.org/gitweb/?p=users/arrsim-guest/libgit2.git;a=summary
pgp4ZThFk0vZX.pgp
Description: PGP signature
Bálint Réczey writes:
> Why does the absence of 1.0 version prevent the upload to unstable?
> There has been many 0.xx releases and the package can be blocked from
> migration to testing if it is really not ready for being released as
> part of Debian.
> I would like to upload a package dependin
Arg, I have been doing some rounds with the libgit2 mailing list to try
and get subscribed, until I can get further conformation, it seems that
there are plans for a 1.0 release some time after the Google summer of
code [1] (so probably late 2012). Until then the library should be considered
in dev
Hi Carlos,
I would like to start by saying thanks for all the help reviewing and
corresponding regarding the package libgit2. I have been presented with
a sponsorship opportunity by a DD. If your interested in co-maintaining
that would be fantastic, if your unable to, may I take over this ITP?
rely sure about
other 64 bit architectures. If you suspect this may cause a problem, I
can setup qemubuilder and test the builds on some of the other debian
architectures.
Thanks,
Russell
commit 5ec485dd3659a396558773990ceae7d2f06e21e2
Author: Russell Sim
Date: Fri Mar 30 17:57:00 2012 +
Hi Carlos,
Sorry to keep bugging you :) you are probably more time poor that I. I
thought I should mention that I am by no means a debian developer or
even a maintainer for that matter. So I will be unable to upload the
package my self. I don't know if you are a DD or DM so I'm not sure if
I sh
Just thought I would give an update, I have just imported the latest
revision and written a pretty raw script to automate the process. I
have added some checking to detect changes in the copyright file.
Cheers,
Russell
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with
Carlos Martín Nieto writes:
> On Thu, 2012-03-22 at 09:15 +1100, Russell Sim wrote:
>> Carlos Martín Nieto writes:
>> > Another reason is that I don't know how much sense it makes to package
>> > the released version, as we've made a lot of bugfixes an
Carlos Martín Nieto writes:
> Thanks for taking the time to do this. One reason I haven't advanced too
> much on this (other than a version I have locally) is the issue of the
> clay script, which I wasn't too sure was DFSG compatible (though
> re-reading the rules, it looks like I was mixing th
Hi,
I have been watching this bug for a while with interest. I have tried
and failed to find copies of the package referred to in a previous
email. Since then I have been maintaining my own version of libgit2 for
a library I develop. Recently I have had the time to enhance the
packages I have b
Hi,
The problem seems to be because of the change to linux 3.0.0
I have fixed the problem on my machine by running
ln -s /usr/lib/tiger/systems/Linux/2 /usr/lib/tiger/systems/Linux/3
This is obviously not a 'real' fix but it does hilight the problem.
Cheers,
Russell
--
Russell Sim
Package: libglobus-common-dev
Version: 10.2-6
Severity: normal
missing dependency of grid-packaging-tools that contains some perl
files globus-makefile-header depends on.
$ globus-makefile-header --flavor=gcc32pthr
Can't locate Grid/GPT/Dependencies.pm in @INC (@INC contains: /etc/perl
/usr/loca
70 matches
Mail list logo
