Bug#872859: kate: fails to build against libgit2 0.26.0
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, support for libgit2 has been removed from Kates master branch because it was deemed to be too unstable, so you may be able to backport that patch if it's too troublesome getting it to build against 0.26.0. Thanks, Russell -- System Information: Debian Release: 9.0 APT prefers unstable APT policy: (990, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages kate depends on: ii kate5-data 4:16.08.3-1 ii ktexteditor-katepart 5.27.0-1 ii libc62.24-11 ii libgit2-24 0.25.1+really0.24.6-1 ii libkf5activities55.27.0-1 ii libkf5bookmarks5 5.27.0-1 ii libkf5completion55.27.0-1 ii libkf5configcore55.27.0-1 ii libkf5configgui5 5.27.0-1 ii libkf5configwidgets5 5.27.0-1 ii libkf5coreaddons55.27.0-1 ii libkf5crash5 5.27.0-1 ii libkf5dbusaddons55.27.0-1 ii libkf5guiaddons5 5.27.0-1 ii libkf5i18n5 5.27.0-2 ii libkf5iconthemes55.27.0-1 ii libkf5itemmodels55.27.0-1 ii libkf5jobwidgets55.27.0-1 ii libkf5kiocore5 5.27.0-2 ii libkf5kiofilewidgets55.27.0-2 ii libkf5kiowidgets55.27.0-2 ii libkf5newstuff5 5.28.0-1 ii libkf5parts5 5.28.0-1 ii libkf5plasma55.28.0-2 ii libkf5service-bin5.27.0-1 ii libkf5service5 5.27.0-1 ii libkf5texteditor55.28.0-2 ii libkf5textwidgets5 5.27.0-1 ii libkf5threadweaver5 5.27.0-1 ii libkf5wallet-bin 5.27.0-1 ii libkf5wallet55.27.0-1 ii libkf5widgetsaddons5 5.27.0-1 ii libkf5windowsystem5 5.27.0-1 ii libkf5xmlgui55.27.0-1 ii libqt5core5a 5.7.1+dfsg-3+b1 ii libqt5dbus5 5.7.1+dfsg-3+b1 ii libqt5gui5 5.7.1+dfsg-3+b1 ii libqt5sql5 5.7.1+dfsg-3+b1 ii libqt5widgets5 5.7.1+dfsg-3+b1 ii libqt5xml5 5.7.1+dfsg-3+b1 ii libstdc++6 6.3.0-18 ii plasma-framework 5.28.0-2 ii qml-module-org-kde-kquickcontrolsaddons 5.27.0-1 ii qml-module-qtquick-layouts 5.7.1-2+b2 ii qml-module-qtquick2 5.7.1-2+b2 kate recommends no packages. Versions of packages kate suggests: ii aspell 0.60.7~20110707-3+b2 ii ispell 3.4.00-5 pn khelpcenter pn konsole-kpart -- no debconf information
Bug#872857: gnuastro: fails to bulid against libgit 0.26.0
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 1. https://people.debian.org/~infinity0/libgit2/gnuastro_0.3.33-1_amd64-2017-08-01T12:02:23Z.build.xz -- System Information: Debian Release: 9.0 APT prefers unstable APT policy: (990, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#872853: ruby-rugged: New upstream version 0.26.0
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: (990, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages ruby-rugged depends on: ii libc6 2.24-11 ii libgit2-24 0.25.1+really0.24.6-1 ii libgmp102:6.1.2+dfsg-1 ii libruby2.3 2.3.3-1 ii ruby1:2.3.3 ruby-rugged recommends no packages. ruby-rugged suggests no packages. -- no debconf information
Bug#872850: libgit2-glib-1.0-0: New upstream release v0.26.0
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: 9.0 APT prefers unstable APT policy: (990, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libgit2-glib-1.0-0 depends on: ii libc6 2.24-11 ii libgirepository-1.0-1 1.50.0-1+b1 ii libgit2-24 0.25.1+really0.24.6-1 ii libglib2.0-0 2.50.3-2 libgit2-glib-1.0-0 recommends no packages. libgit2-glib-1.0-0 suggests no packages. -- no debconf information
Bug#872847: fritzing: fails to bulid against libgit2 0.26.0
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. So if this problem is due to upsteam not supporting 0.26.0 can you please follow up with them to get the version of libgit2 required updated to the latest version. Thanks, Russell 1. https://people.debian.org/~infinity0/libgit2/fritzing_0.9.3b+dfsg-4_amd64-2017-08-01T11:37:39Z.build.xz -- System Information: Debian Release: 9.0 APT prefers unstable APT policy: (990, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages fritzing depends on: ii fritzing-data 0.9.3b+dfsg-4 ii libc6 2.24-11 ii libgcc1 1:6.3.0-18 ii libgit2-240.25.1+really0.24.6-1 ii libgl1-mesa-glx [libgl1] 13.0.6-1+b2 ii libqt5concurrent5 5.7.1+dfsg-3+b1 ii libqt5core5a 5.7.1+dfsg-3+b1 ii libqt5gui55.7.1+dfsg-3+b1 ii libqt5network55.7.1+dfsg-3+b1 ii libqt5printsupport5 5.7.1+dfsg-3+b1 ii libqt5serialport5 5.7.1~20161021-2 ii libqt5sql55.7.1+dfsg-3+b1 ii libqt5sql5-sqlite 5.7.1+dfsg-3+b1 ii libqt5svg55.7.1~20161021-2+b2 ii libqt5widgets55.7.1+dfsg-3+b1 ii libqt5xml55.7.1+dfsg-3+b1 ii libstdc++66.3.0-18 ii zlib1g1:1.2.8.dfsg-5 fritzing recommends no packages. Versions of packages fritzing suggests: ii fritzing-parts 0.9.3b-1 -- no debconf information
Bug#872013: texlive-science-doc: Upgrading from texlive-math-extra causes conflict
Hey Norbert, On 15 August 2017 at 03:48, Norbert Preining wrote: > > > trying to overwrite '/usr/share/man/man1/amstex.1.gz', which is also in > > package texlive-math-extra 2016.20161008-1 > > I only realize it now, but what is this a package? And where did 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
Bug#869665: package libgit2-25
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-rugged need one to one matching with libgit2 version. Current > upstream version of ruby-rugged is 0.26, but there is a strong chance > packaging latest version will break the current gitlab version that we > are targeting. > > >From what i can see GitLab 9.5 uses 0.26. Is there any reason not to target this version instead? I realize this may not suite your original plans but it will be less work in the long term. Theoretically, if we did change the epoch and then release version 0.25 into experimental, we would then need to do a full library transition of all libgit2 dependent packages only to immediately afterwards, do another full library transition to 0.26 since it's the current version. So either way you'll end up having to package 9.5 or greater, after you package your choice of GitLab 9.1-9.4. There are also other dependent packages that have already started packaging for 0.26 such as pygit2. -- Cheers, Russell Sim
Bug#869665: package libgit2-25
Hey Abhijith, On 20 August 2017 at 16:24, Abhijith PA wrote: > > Can you package libgit2 version 0.25 . It is really needed for the > ruby-rugged_0.25, which is a dependency of GitLab. > 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
Bug#872013: texlive-science-doc: Upgrading from texlive-math-extra causes conflict
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 should texlive-science conflict with texlive-math-extra so that this can't happen? I did get into this situation by running an apt-get install command to try and only upgrade a few texlive packages without updating everything. So using apt- get upgrade may have avoided this situation? I don't really know. Cheers, Russell sudo apt --fix-broken install Reading package lists... Done Building dependency tree Reading state information... Done Correcting dependencies... Done The following packages were automatically installed and are no longer required: libavformat56 libexiv2-13 libgif4 libjson-c3:i386 libnm-gtk-common libnma- common libwebrtc-audio-processing-0 linux-image-3.10-3-amd64 linux- image-3.13-1-amd64 linux-image-3.16.0-4-amd64 linux-image-3.2.0-1-amd64 linux-image-3.2.0-2-amd64 linux-image-4.0.0-2-amd64 linux-image-4.3.0-1-amd64 texlive-math-extra tla tla-doc Use 'sudo apt autoremove' to remove them. The following additional packages will be installed: texlive-science texlive-science-doc The following NEW packages will be installed: texlive-science texlive-science-doc 0 upgraded, 2 newly installed, 0 to remove and 2114 not upgraded. 149 not fully installed or removed. Need to get 52.4 MB of archives. After this operation, 73.2 MB of additional disk space will be used. Do you want to continue? [Y/n] y Get:1 http://ftp.dk.debian.org/debian unstable/main amd64 texlive-science all 2017.20170809-1 [3,085 kB] Get:2 http://ftp.dk.debian.org/debian unstable/main amd64 texlive-science-doc all 2017.20170809-1 [49.3 MB] Fetched 52.4 MB in 4s (11.2 MB/s) (Reading database ... 756895 files and directories currently installed.) Preparing to unpack .../texlive-science_2017.20170809-1_all.deb ... Unpacking texlive-science (2017.20170809-1) ... dpkg: error processing archive /var/cache/apt/archives/texlive- science_2017.20170809-1_all.deb (--unpack): trying to overwrite '/usr/share/man/man1/amstex.1.gz', which is also in package texlive-math-extra 2016.20161008-1 dpkg-deb: error: subprocess paste was killed by signal (Broken pipe) Preparing to unpack .../texlive-science-doc_2017.20170809-1_all.deb ... Unpacking texlive-science-doc (2017.20170809-1) ... dpkg: error processing archive /var/cache/apt/archives/texlive-science- doc_2017.20170809-1_all.deb (--unpack): trying to overwrite '/usr/share/doc/texlive-doc/amstex/base/README.gz', which is also in package texlive-math-extra 2016.20161008-1 dpkg-deb: error: subprocess paste was killed by signal (Broken pipe) Errors were encountered while processing: /var/cache/apt/archives/texlive-science_2017.20170809-1_all.deb /var/cache/apt/archives/texlive-science-doc_2017.20170809-1_all.deb -- Package-specific info: IMPORTANT INFORMATION: We will only consider bug reports concerning the packaging of TeX Live as relevant. If you have problems with combination of packages in a LaTeX document, please consult your local TeX User Group, the comp.text.tex user group, the author of the original .sty file, or any other help resource. In particular, bugs that are related to up-upstream, i.e., neither Debian nor TeX Live (upstream), but the original package authors, will be closed immediately. *** The Debian TeX Team is *not* a LaTeX Help Desk *** If you report an error when running one of the TeX-related binaries (latex, pdftex, metafont,...), or if the bug is related to bad or wrong output, please include a MINIMAL example input file that produces the error in your report. Please run your example with (pdf)latex -recorder ... (or any other program that supports -recorder) and send us the generated file with the extension .fls, it lists all the files loaded during the run and can easily explain problems induced by outdated files in your home directory. Don't forget to also include minimal examples of other files that are needed, e.g. bibtex databases. Often it also helps to include the logfile. Please, never send included pictures! If your example file isn't short or produces more than one page of output (except when multiple pages are needed to show the problem), you can probably minimize it further. Instructions on how to do that can be found at http://www.minimalbeispiel.de/mini-en.html (english) or http://www.minimalbeispiel.de/mini.html (german) ## minimal input file ## other files ## List of ls-R files -rw-rw-r-- 1 root staff 80 Jul 28 2012 /usr/local/share/texmf/ls-R -rw-r--r-- 1 root root 1895 Aug 13 14:10 /var/lib/texmf/ls-R lrwxrwxrwx 1 root root 29 Jan 17 2017 /usr/share/texmf/ls-R -> /var/lib/texmf/ls-R-TEXMFMAIN lrwxrwxrwx 1 root
Bug#869665: libgit2-dev: please update version in Debian unstable and do a library transition
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$') > >>> eeshow fritzing geany-plugin-git-changebar gnome-builder gnuastro kate > >>> kup-backup libgit2-glib-1.0-0 libgnuastro1 libgnuastro2 > libkf5texteditor5 > >>> lua-gall python-pygit2 python3-pygit2 ruby-rugged > >>> > >>> [..] > >> > >> Thanks for the info, I'll follow the document as described. > >> > >> I think i may get some time on Monday to start building and testing the > >> rdepends. In the meantime could you please upload 0.26.0+dfsg.1-1 to > >> experimental, I've pushed it to the collab-maint git. > >> > > > > I've uploaded that to experimental. I made a minor tweak in git which > will take effect for the next version, you can revert it if you want, see > the commit message for details. > > > > I can help with the rebuilds [..] > > > > I've rebuilt the packages above (except eeshow which is only in > experimental, and libgnucastro1 since it was replaced by *2). The following > packages fail: > > fritzing_0.9.3b+dfsg-4.dsc > gnome-builder_3.22.4-1.dsc > gnuastro_0.3.33-1.dsc > kate_16.08.3-1.dsc > libgit2-glib_0.24.4-1.dsc > python-pygit2_0.24.2-2.dsc > ruby-rugged_0.24.0+ds1-3.dsc > > Build logs are here if you'd like to investigate: > https://people.debian.org/~infinity0/libgit2/ > > I'll file bugs to those packages in the next few days, or feel free to > jump in ahead. (I'll be travelling tomorrow to go to DebConf, so it might > be a while before I get around to it.) > > X > > -- > GPG: ed25519/56034877E1F87C35 > GPG: rsa4096/1318EFAC5FBBDBCE > https://github.com/infinity0/pubkeys.git > Thanks, for doing all that. I'm happy to lodge the bugs, I'll wait for the package to clear the new queue and then send out the emails. I have had a look over the package build logs you posted, it appears that most of them have failed because the package defines a hard dependency on the libgit2 dev version. Which makes sense. Enjoy DebConf :) -- Cheers, Russell Sim
Bug#869665: libgit2-dev: please update version in Debian unstable and do a library transition
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 blocked because of the same > > FTP ACL as before. I think I should probably look at beginning the DD > > process. In the meantime it would be great if you could sponsor my > upload > > I have pushed it to git [0]. > > > > 0. https://anonscm.debian.org/cgit/collab-maint/libgit2.git/ > > > > In d/changelog you said this is for unstable, but since other packages in > Debian still link against libgit2 0.24 I think we are supposed to do a > transition: > > https://wiki.debian.org/Teams/ReleaseTeam/Transitions > > which means I should upload this to experimental first. However I also > notice you already did that previously - did you also already check that > the reverse dependencies also build correctly against 0.25? i.e. these > packages: > > $ echo $(aptitude search --disable-columns -F "%p" '~Dlibgit2-24 ~rnative > !~e^libgit2$') > eeshow fritzing geany-plugin-git-changebar gnome-builder gnuastro kate > kup-backup libgit2-glib-1.0-0 libgnuastro1 libgnuastro2 libkf5texteditor5 > lua-gall python-pygit2 python3-pygit2 ruby-rugged > > If you did the check already, we might be able to upload directly to > unstable, otherwise I think we are supposed to upload to experimental first > and go through the process listed in the "Transitions" page I linked. > > This somewhat lengthy process, is also why I suggested to just package > 0.26 directly and skip 0.25. Sorry, perhaps I should have explained it > earlier. > > (I am fairly new to this process as well, despite me being a DD for > several years I have not maintained a library package myself, that needs > these sorts of rebuilds.) > > X > > -- > GPG: ed25519/56034877E1F87C35 > GPG: rsa4096/1318EFAC5FBBDBCE > https://github.com/infinity0/pubkeys.git > Thanks for the info, I'll follow the document as described. I think i may get some time on Monday to start building and testing the rdepends. In the meantime could you please upload 0.26.0+dfsg.1-1 to experimental, I've pushed it to the collab-maint git. -- Cheers, Russell Sim
Bug#869665: libgit2-dev: please update version in Debian unstable and do a library transition
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 dev package is un-versioned, and the upstream API can change > > quite significantly with each release. So I'm a bit worried that this > will > > cause package build failures if any rebuilds occur. Does that make sense > > to do this, or is that over complicating things? I couldn't find any > good > > documentation about when it is appropriate to version a dev package. > > > > I won't let this stop me uploading 0.25.1.0, but I'm curious about what > > your opinion is? > > > > Hey, I'd suggest *not* to have the -dev package be versioned. > > Despite the fact that the API changes quite a lot, I would guess that most > (say ballpark 80%) dependants would still build fine with both 0.25 and > 0.26. If you start renaming the -dev packages, you would have to edit the > source code of all of the dependant packages to say Build-Depends: > libgit2-26-dev etc. That is more work than doing binary-only NMU rebuilds, > using the latest version of libgit2-dev. > > Also there would be extra trips through the NEW queue. Also it does not > really help build failures - since you are maintaining 1 source package, if > you upload libgit2-26-dev then the older libgit2-25-dev would go away > anyways and be unavailable for future builds. > > Usually the only appropriate time to do versioned -dev packages is if you > are going to maintain both those versions separately for a long period of > time, and usually this would only be because of very major API changes > (like GTK 2 vs 3) rather than relatively minor changes from 0.25 to 0.26. > > If upstream keeps changing API very significantly then yes, one would have > to make a tradeoff on whether it's more-or-less effort to (a) upgrade > packages to use the newer API or (b) maintain multiple source packages of > these different versions. However, having reviewed the 0.26 release notes, > I think keeping 1 source package (and an unversioned -dev package) is the > better solution for this case. > > X > > -- > GPG: ed25519/56034877E1F87C35 > GPG: rsa4096/1318EFAC5FBBDBCE > https://github.com/infinity0/pubkeys.git > 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 blocked because of the same FTP ACL as before. I think I should probably look at beginning the DD process. In the meantime it would be great if you could sponsor my upload I have pushed it to git [0]. 0. https://anonscm.debian.org/cgit/collab-maint/libgit2.git/ -- Thanks again, Russell Sim
Bug#869665: libgit2-dev: please update version in Debian unstable and do a library transition
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 dev package is un-versioned, and the upstream API can change quite significantly with each release. So I'm a bit worried that this will cause package build failures if any rebuilds occur. Does that make sense to do this, or is that over complicating things? I couldn't find any good documentation about when it is appropriate to version a dev package. I won't let this stop me uploading 0.25.1.0, but I'm curious about what your opinion is? On 25 July 2017 at 15:13, Ximin Luo wrote: > Package: libgit2-dev > Version: 0.25.1.0-1 > Severity: normal > > Dear Maintainer, > > Now that the stretch freeze is over, please could you update libgit to > 0.25.1 > (or 0.26 even) and do a library transition? > > We'd like to update rustc and cargo soon, without the embedded libraries. I > took a brief look at the cargo source code and believe it ought to work > with > either 0.25.1 or 0.26, there is one breaking change [1] but cargo does not > use > that functionality. > > If you want to upload 0.25.1, I'd suggest the version "0.25.1.0" so that it > sorts ahead of the current version "0.25.1+really0.24.6-1". > > X > > [1] https://github.com/libgit2/libgit2/releases/tag/v0.26.0 > > *** Reporter, please consider answering these questions, where appropriate > *** > >* What led up to the situation? >* What exactly did you do (or not do) that was effective (or > ineffective)? >* What was the outcome of this action? >* What outcome did you expect instead? > > *** End of the template - remove these template lines *** > > > -- System Information: > Debian Release: buster/sid > APT prefers testing > APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, > 'testing-debug'), (500, 'buildd-unstable'), (300, 'unstable'), (100, > 'experimental'), (1, 'experimental-debug') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 4.11.0-1-amd64 (SMP w/4 CPU cores) > Locale: LANG=en_GB.utf8, LC_CTYPE=en_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
Bug#863486: unblock: libgit2/0.25.1+really0.24.6-1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package libgit2
This version is a minor update which contains some fixes for CVE-2016-10128
CVE-2016-10129 CVE-2016-10130 [0]
Sorry about the version number.
0. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851406
unblock libgit2/0.25.1+really0.24.6-1
-- System Information:
Debian Release: stretch/sid
APT prefers unstable
APT policy: (990, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
diff -Nru libgit2-0.24.5/debian/changelog libgit2-0.25.1+really0.24.6/debian/changelog
--- libgit2-0.24.5/debian/changelog 2017-01-02 10:35:08.0 +0100
+++ libgit2-0.25.1+really0.24.6/debian/changelog 2017-05-21 18:18:47.0 +0200
@@ -1,3 +1,25 @@
+libgit2 (0.25.1+really0.24.6-1) unstable; urgency=medium
+
+ * Revert 0.25.1 in unstable, 0.24.5 was already in unstable 0.25.1 was
+uploaded after the freeze.
+ * Release 0.24.6 (CVE-2016-10128, 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 release. (CVE-2016-10128, CVE-2016-10129, CVE-2016-10130)
+(Closes: #851406, #857068)
+
+ -- Russell Sim Tue, 25 Apr 2017 07:29:37 +0200
+
libgit2 (0.24.5-1) unstable; urgency=medium
* New upstream release.
diff -Nru libgit2-0.24.5/include/git2/version.h libgit2-0.25.1+really0.24.6/include/git2/version.h
--- libgit2-0.24.5/include/git2/version.h 2017-01-02 10:47:27.0 +0100
+++ libgit2-0.25.1+really0.24.6/include/git2/version.h 2017-01-09 21:26:28.0 +0100
@@ -7,10 +7,10 @@
#ifndef INCLUDE_git_version_h__
#define INCLUDE_git_version_h__
-#define LIBGIT2_VERSION "0.24.5"
+#define LIBGIT2_VERSION "0.24.6"
#define LIBGIT2_VER_MAJOR 0
#define LIBGIT2_VER_MINOR 24
-#define LIBGIT2_VER_REVISION 5
+#define LIBGIT2_VER_REVISION 6
#define LIBGIT2_VER_PATCH 0
#define LIBGIT2_SOVERSION 24
diff -Nru libgit2-0.24.5/src/transports/http.c libgit2-0.25.1+really0.24.6/src/transports/http.c
--- libgit2-0.24.5/src/transports/http.c 2017-01-02 10:47:27.0 +0100
+++ libgit2-0.25.1+really0.24.6/src/transports/http.c 2017-01-09 21:26:28.0 +0100
@@ -602,13 +602,12 @@
if ((!error || error == GIT_ECERTIFICATE) && t->owner->certificate_check_cb != NULL &&
git_stream_is_encrypted(t->io)) {
git_cert *cert;
- int is_valid;
+ int is_valid = (error == GIT_OK);
if ((error = git_stream_certificate(&cert, t->io)) < 0)
return error;
giterr_clear();
- is_valid = error != GIT_ECERTIFICATE;
error = t->owner->certificate_check_cb(cert, is_valid, t->connection_data.host, t->owner->message_cb_payload);
if (error < 0) {
diff -Nru libgit2-0.24.5/src/transports/smart_pkt.c libgit2-0.25.1+really0.24.6/src/transports/smart_pkt.c
--- libgit2-0.24.5/src/transports/smart_pkt.c 2017-01-02 10:47:27.0 +0100
+++ libgit2-0.25.1+really0.24.6/src/transports/smart_pkt.c 2017-01-09 21:26:28.0 +0100
@@ -427,15 +427,23 @@
if (bufflen > 0 && bufflen < (size_t)len)
return GIT_EBUFS;
+ /*
+ * The length has to be exactly 0 in case of a flush
+ * packet or greater than PKT_LEN_SIZE, as the decoded
+ * length includes its own encoded length of four bytes.
+ */
+ if (len != 0 && len < PKT_LEN_SIZE)
+ return GIT_ERROR;
+
line += PKT_LEN_SIZE;
/*
- * TODO: How do we deal with empty lines? Try again? with the next
- * line?
+ * The Git protocol does not specify empty lines as part
+ * of the protocol. Not knowing what to do with an empty
+ * line, we should return an error upon hitting one.
*/
if (len == PKT_LEN_SIZE) {
- *head = NULL;
- *out = line;
- return 0;
+ giterr_set_str(GITERR_NET, "Invalid empty packet");
+ return GIT_ERROR;
}
if (len == 0) { /* Flush pkt */
diff -Nru libgit2-0.24.5/src/transports/smart_protocol.c libgit2-0.25.1+really0.24.6/src/transports/smart_protocol.c
--- libgit2-0.24.5/src/transports/smart_protocol.c 2017-01-02 10:47:27.0 +0100
+++ libgit2-0.25.1+really0.24.6/src/transports/smart_protocol.c 2017-01-09 21:26:28.0 +0100
@@ -759,14 +759,6 @@
line_len -= (line_end - line);
line = line_end;
- /* When a valid packet with no content has been
- * read, git_pkt_parse_line does not report an
- * error, but the pkt pointer has not been set.
- * Handle this by skipping over empty packets.
- */
- if (pkt == NULL)
- continue;
-
error = add_push_report_pkt(push, pkt);
git_pkt_free(pkt);
@@ -821,9
Bug#861752: libgit2: embeds unnecessary 3rd-party source files in deps/
Source: libgit2 > Version: 0.24.5-1 > Severity: minor > > Dear Maintainer, > > The source package embeds third-party dependencies in deps/. This appears > not > to be necessary: I installed the Build-Depends, deleted deps/*, ran > `debian/rules build`, and it still worked. > > You can remove this in the next upstream release by adding some > Files-Excluded: > entries to d/copyright and adjusting d/watch accordingly; see `man uscan` > for > details and/or ask me for help. > > After this is done, one can also remove the corresponding entries in > d/copyright. > > At the moment the situation is a bit confusing because it looks like the > package requires these embebbed libraries, but they're not actually used. > > Ximin > > -- System Information: > Debian Release: 9.0 > APT prefers testing > APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, > 'testing-debug'), (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=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > -- Cheers, Russell Sim commit d5ae1e4ef34eca2decfdc4558c319cfd691ae43f Author: Russell Sim Date: Sat May 20 18:38:09 2017 +0200 Exclude unused deps diff --git a/debian/copyright b/debian/copyright index 3aaf1cec6..3038b5f82 100644 --- a/debian/copyright +++ b/debian/copyright @@ -14,22 +14,7 @@ Files: debian/* Copyright: 2011-2015, Russell Sim License: GPL-2+ -Files: deps/regex/* -Copyright: 1985,1989-93,1995-98,2000,2001,2002,2003,2005,2006,2008 Free Software Foundation, Inc. -License: LGPL-2.1+ - -Files: deps/zlib/* -Copyright: 1995-2010, Jean-loup Gailly - 1995-2010, Mark Adler -License: Zlib - -Files: deps/http-parser/* -Copyright: Igor Sysoev, Joyent, Inc. and other Node contributors -License: MIT+NGINX - -Files: deps/winhttp/winhttp.h -Copyright: 2007, Francois Gouget -License: LGPL-2.1+ +Files-Excluded: deps/* Files: examples/* Copyright: Public Domain diff --git a/debian/watch b/debian/watch index 614432a98..3109585e9 100644 --- a/debian/watch +++ b/debian/watch @@ -1,3 +1,3 @@ version=3 -opts=filenamemangle=s/.+\/v?(\d\S*)\.tar\.gz/libgit2-$1\.tar\.gz/ \ +opts=compression=xz,repack,filenamemangle=s/.+\/v?(\d\S*)\.tar\.gz/libgit2-$1\.tar\.gz/ \ https://github.com/libgit2/libgit2/releases .*/v?([\d.]*)\.tar\.gz
Bug#857068: Bump libgit2 version to upstream release 0.25.1
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, > > It was rejected because I didn't have enough permissions. I can't upload > new packages due to an ACL, if you want to do a non-maintainer uploaded to > push it along feel free. Otherwise I'll start sorting that out tomorrow. > > Regards, > Russell > > On 1 May 2017 21:05, "Ximin Luo" wrote: > >> Hey Russell, how's it going with this? >> >> I notice you've already tagged an upload in the git repo: >> >> https://anonscm.debian.org/cgit/collab-maint/libgit2.git/tag >> /?h=debian/0.25.1-1 >> >> Is there anything else that needs to be done before 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, I'll take a look tonight. Yeah, I agree it's been a bit too >> > long, and I apologise for that. >> > >> > On 20 April 2017 at 10:37, Ximin Luo wrote: >> > >> >> Source: libgit2 >> >> Version: 0.24.5-1 >> >> Followup-For: Bug #857068 >> >> >> >> Hey, this would be useful for the cargo package. (see #860116) >> >> >> >> At the moment we have to embed libgit2 0.25.1 in the cargo source >> package, >> >> this >> >> is not ideal for Debian especially given that there was already a CVE >> and >> >> it's >> >> not obvious to the security team that they would also need to patch >> cargo. >> >> >> >> X >> >> >> >> -- System Information: >> >> Debian Release: 9.0 >> >> APT prefers testing >> >> APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, >> >> 'testing-debug'), (500, 'buildd-unstable'), (300, 'unstable'), (100, >> >> 'experimental'), (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) >> >> >> > >> > >> > >> >> >> -- >> GPG: ed25519/56034877E1F87C35 >> GPG: rsa4096/1318EFAC5FBBDBCE >> https://github.com/infinity0/pubkeys.git >> >
Bug#857068: Bump libgit2 version to upstream release 0.25.1
Hey Ximin, It was rejected because I didn't have enough permissions. I can't upload new packages due to an ACL, if you want to do a non-maintainer uploaded to push it along feel free. Otherwise I'll start sorting that out tomorrow. Regards, Russell On 1 May 2017 21:05, "Ximin Luo" wrote: > Hey Russell, how's it going with this? > > I notice you've already tagged an upload in the git repo: > > https://anonscm.debian.org/cgit/collab-maint/libgit2.git/ > tag/?h=debian/0.25.1-1 > > Is there anything else that needs to be done before 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, I'll take a look tonight. Yeah, I agree it's been a bit too > > long, and I apologise for that. > > > > On 20 April 2017 at 10:37, Ximin Luo wrote: > > > >> Source: libgit2 > >> Version: 0.24.5-1 > >> Followup-For: Bug #857068 > >> > >> Hey, this would be useful for the cargo package. (see #860116) > >> > >> At the moment we have to embed libgit2 0.25.1 in the cargo source > package, > >> this > >> is not ideal for Debian especially given that there was already a CVE > and > >> it's > >> not obvious to the security team that they would also need to patch > cargo. > >> > >> X > >> > >> -- System Information: > >> Debian Release: 9.0 > >> APT prefers testing > >> APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, > >> 'testing-debug'), (500, 'buildd-unstable'), (300, 'unstable'), (100, > >> 'experimental'), (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) > >> > > > > > > > > > -- > GPG: ed25519/56034877E1F87C35 > GPG: rsa4096/1318EFAC5FBBDBCE > https://github.com/infinity0/pubkeys.git >
Bug#857068: Bump libgit2 version to upstream release 0.25.1
Hi, Sure thing, I'll take a look tonight. Yeah, I agree it's been a bit too long, and I apologise for that. On 20 April 2017 at 10:37, Ximin Luo wrote: > Source: libgit2 > Version: 0.24.5-1 > Followup-For: Bug #857068 > > Hey, this would be useful for the cargo package. (see #860116) > > At the moment we have to embed libgit2 0.25.1 in the cargo source package, > this > is not ideal for Debian especially given that there was already a CVE and > it's > not obvious to the security team that they would also need to patch cargo. > > X > > -- System Information: > Debian Release: 9.0 > APT prefers testing > APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, > 'testing-debug'), (500, 'buildd-unstable'), (300, 'unstable'), (100, > 'experimental'), (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
Bug#850014: unblock: libgit2/0.24.5-1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package libgit2
The main reasons is that i messed up the packaging of version 0.24.2-1, and
have flagged CVE-2016-8568 [0] as being fixed which is untrue. This package
both addresses this issue correctly and fixes the serious bug [1].
Thanks,
Russell
0. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=840227
1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841532
unblock libgit2/0.24.5-1
-- System Information:
Debian Release: stretch/sid
APT prefers unstable
APT policy: (990, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
diff -Nru libgit2-0.24.2/debian/changelog libgit2-0.24.5/debian/changelog
--- libgit2-0.24.2/debian/changelog 2016-11-04 18:36:41.0 +1100
+++ libgit2-0.24.5/debian/changelog 2017-01-02 20:35:08.0 +1100
@@ -1,3 +1,11 @@
+libgit2 (0.24.5-1) unstable; urgency=medium
+
+ * New upstream release.
+ * debian/patch/fix_gmt14_timzone_bug.patch (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/patches/commit-always-initialize-commit-message.patch
--- libgit2-0.24.2/debian/patches/commit-always-initialize-commit-message.patch 2016-11-04 18:36:41.0 +1100
+++ libgit2-0.24.5/debian/patches/commit-always-initialize-commit-message.patch 1970-01-01 10:00:00.0 +1000
@@ -1,43 +0,0 @@
-From a719ef5e6d4a1a8ec53469c7914032ed67922772 Mon Sep 17 00:00:00 2001
-From: Patrick Steinhardt
-Date: Fri, 7 Oct 2016 09:31:41 +0200
-Subject: [PATCH] commit: always initialize commit message
-
-When parsing a commit, we will treat all bytes left after parsing
-the headers as the commit message. When no bytes are left, we
-leave the commit's message uninitialized. While uncommon to have
-a commit without message, this is the right behavior as Git
-unfortunately allows for empty commit messages.
-
-Given that this scenario is so uncommon, most programs acting on
-the commit message will never check if the message is actually
-set, which may lead to errors. To work around the error and not
-lay the burden of checking for empty commit messages to the
-developer, initialize the commit message with an empty string
-when no commit message is given.
- src/commit.c | 7 ---
- 1 file changed, 4 insertions(+), 3 deletions(-)
-
-diff --git a/src/commit.c b/src/commit.c
-index 99a8085..76e6dcb 100644
a/src/commit.c
-+++ b/src/commit.c
-@@ -459,10 +459,11 @@ int git_commit__parse(void *_commit, git_odb_object *odb_obj)
- buffer = buffer_start + header_len + 1;
-
- /* extract commit message */
-- if (buffer <= buffer_end) {
-+ if (buffer <= buffer_end)
- commit->raw_message = git__strndup(buffer, buffer_end - buffer);
-- GITERR_CHECK_ALLOC(commit->raw_message);
-- }
-+ else
-+ commit->raw_message = git__strdup("");
-+ GITERR_CHECK_ALLOC(commit->raw_message);
-
- return 0;
-
---
-2.8.1
-
diff -Nru libgit2-0.24.2/debian/patches/fix_gmt14_timzone_bug.patch libgit2-0.24.5/debian/patches/fix_gmt14_timzone_bug.patch
--- libgit2-0.24.2/debian/patches/fix_gmt14_timzone_bug.patch 1970-01-01 10:00:00.0 +1000
+++ libgit2-0.24.5/debian/patches/fix_gmt14_timzone_bug.patch 2017-01-02 20:35:08.0 +1100
@@ -0,0 +1,29 @@
+From 23c9ff8632d8ae90d211601d3254ab7f4d35e853 Mon Sep 17 00:00:00 2001
+From: Andreas Henriksson
+Date: Sat, 17 Dec 2016 17:33:13 +0100
+Subject: [PATCH] Fix off-by-one problems in git_signature__parse
+
+Etc/GMT-14 aka UTC+14:00 is a thing
+https://en.wikipedia.org/wiki/UTC%2B14:00
+
+Also allow offsets on the last minute (59).
+
+Addresses: https://bugs.debian.org/841532
+Fixes: #3970
+---
+ src/signature.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/signature.c b/src/signature.c
+index dcc3797..22cba7e 100644
+--- a/src/signature.c
b/src/signature.c
+@@ -251,7 +251,7 @@ int git_signature__parse(git_signature *sig, const char **buffer_out,
+ * only store timezone if it's not overflowing;
+ * see http://www.worldtimezone.com/faq.html
+ */
+- if (hours < 14 && mins < 59) {
++ if (hours <= 14 && mins <= 59) {
+ sig->when.offset = (hours * 60) + mins;
+ if (tz_start[0] == '-')
+ sig->when.offset = -sig->when.offset;
diff -Nru libgit2-0.24.2/debian/patches/series libgit2-0.24.5/debian/patches/series
--- libgit2-0.24.2/debian/patches/series 2016-11-04 18:36:41.0 +1100
+++ libgit2-0.24.5/debian/patches/series 2017-01-02 20:35:08.0 +1100
@@ -1,2 +1,2 @@
Bug#840227: libgit2: CVE-2016-8568 CVE-2016-8569
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 before an upload yesterday. Salvatore Bonaccorso writes: > Source: libgit2 > Version: 0.24.1-2 > Severity: grave > Tags: security upstream > > Hi, > > the following vulnerabilities were published for libgit2. > > CVE-2016-8568[0, 3]: > Read out-of-bounds in git_oid_nfmt > > CVE-2016-8569[1, 4]: > DoS using a null pointer dereference in git_commit_message > > If you fix the vulnerabilities please also make sure to include the > CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. > > For further information see: > > [0] https://security-tracker.debian.org/tracker/CVE-2016-8568 > [1] https://security-tracker.debian.org/tracker/CVE-2016-8569 > [2] https://marc.info/?l=oss-security&m=147594097425642&w=2 > [3] https://github.com/libgit2/libgit2/issues/3936 > [4] https://github.com/libgit2/libgit2/issues/3937 > [5] https://github.com/libgit2/libgit2/pull/3956 > > Please adjust the affected versions in the BTS as needed. > > Regards, > Salvatore -- Cheers, Russell
Bug#841532: libgit2 update in debian fixing #841532
Hey Andreas, I should be fine to do it. I'm currently in a different city and didn't take my laptop with me. I'll be back on the 1st Jan and can push up 0.24.5 with your patch applied easily before the 5th. I originally was not considering that patch because I didn't think 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. > > Wanted to check with you if you have any plans to deal with > debian bug #841532 in the libgit2 package soon? > My (quite trivial) patch went in upstream and is sitting > in the master branch. > https://github.com/libgit2/libgit2/commit/23c9ff8632d8ae90d211601d3254ab > 7f4d35e853.patch > > Do you want some help? > > I was thinking I could help you out with updating to 0.24.5 (since 0.25.0 > release seems to have broken API/ABI and we're past transition freeze) > and also pull in the above mentioned patch to fix the GMT-14 issue. > > Just tell me if you want to work on this or if you want my help. > > Regards, > Andreas Henriksson >
Bug#841532: libgit2: FTBFS under some timezones (eg. GMT-14)
Yeah, I totally agree it's an upstream bug, the bug exists in not only this version but also the master branch so I can't backport a fix. I did have a quick look at the test code, and it's not obviously due to that, so it must be related to how they store or retrieve the offset in this case. I'll leave this bug open until we have an actual fix. But I think that preventing random failures from Debian build infrastructure is the best I can do for the time being. Thanks for adding the forwarded tag, I'm still learning and I forget these things sometimes. Chris Lamb 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 package to force tests to run in GMT timezone. > > Be careful; it could mean that you are masking underlying bugs by forcing > the timezone - the code (outside of the tests) itself could be buggy! > > > Regards, -- Cheers, Russell
Bug#841532: libgit2: FTBFS under some timezones (eg. GMT-14)
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: serious > Justification: fails to build from source > User: reproducible-bui...@lists.alioth.debian.org > Usertags: ftbfs timezone > X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org > > Dear Maintainer, > > libgit2 fails to build from source in unstable/amd64 under > some timezones (eg. TZ="/usr/share/zoneinfo/Etc/GMT-14"): > > […] > > 1) Failure: > refs::reflog::reflog::append_then_read > [/home/lamby/temp/cdt.20161021132009.xEm9eCsvCE.ags.libgit2/libgit2-0.24.1/tests/refs/reflog/reflog.c:21] > Expression is not true: expected->when.offset == actual->when.offset > > > 50% tests passed, 1 tests failed out of 2 > > Total Test time (real) = 16.30 sec > > The following tests FAILED: > 1 - libgit2_clar (Failed) > Errors while running CTest > > […] > > The full build log is attached. > > > Regards, -- Cheers, Russell
Bug#798338: update to 0.24.0
Hey, My apologies, I am still here, but yes I have totally fallen behind. I'll can take a look at updating it tomorrow night. Or if you like your welcome to move this package to collab and take it over. Either way I don't mind. Sorry my situation has changed and I don't have the time to commit like I did previously hence the delay. Anyway let me know what you would like me to do. On 4 April 2016 at 20:17, Pirate Praveen wrote: > On Sun, 3 Apr 2016 18:03:57 +0200 Andreas Henriksson > wrote: > > I've made my changes available /temporarily/ at > > https://github.com/andhe/pkg-libgit2 > > ruby-rugged is ready. > > -- Cheers, Russell Sim
Bug#798421: Please don't depend specifically on the OpenSSL variant of Curl
On 9 September 2015 at 12:37, Josh Triplett wrote: > I'd like to use libgit2 for projects under the GPL. Would you please > consider either building libgit2 against the gnutls version of Curl, or > otherwise making it possible to avoid building with OpenSSL, for the > benefit 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
Bug#798338: Please package 0.23.2 available upstream
On 8 September 2015 at 18:54, Thomas Goirand wrote: > Source: libgit2 > Version: 0.22.2-2 > Severity: important > > Version 0.23.2 is available upstream, and is needed to fix the FTBFS with > the latest version of python-pygit2, which I need to package in order to > fix the RC bug #796657. > Hey thanks for the heads up! > I saw that in your Git, you already prepared version 0.23.1. What was > preventing you from uploading? > 0.23.1 has been uploaded and I got an email from the FTP master 90 minutes ago telling me it has been accepted into unstable. > > If you can't upload, please let me know, and I'll help (with NMU or > sponsoring). > I can't upload, but I am working on that :) I'm about to apply for Debian Maintainer status, just have to get everything sorted. Apparently the DD who signed my key years ago has changed keys. > Also, since pygit2 and libgit2 are really related, it'd be nice to > maintain them both in a single team, so that we can coordinate the > upload of both at the same time. Would you like to join the OpenStack > packaging team and maintain libgit2 there? Or shall 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
Bug#786494: libgit2: diff for NMU version 0.22.2-1.1
Hey, I have been waiting for my maintainer to upload a new version since last week :( he must be busy doing other things at the moment. http://anonscm.debian.org/cgit/users/arrsim-guest/libgit2.git/commit/?id=1230d224b48069ba4e1b613694b94f9f6ce6b68b I would prefer that you upload my version if possible. Is that ok? Cheers, Russell On 31 May 2015 at 07:30, Jonathan Wiltshire wrote: > Control: tags 786494 + patch > Control: tags 786494 + pending > > Dear maintainer, > > I've prepared an NMU for libgit2 (versioned as 0.22.2-1.1) and > uploaded it to DELAYED/2. Please feel free to tell me if I > should delay it longer. > > Regards. > > -- > Jonathan Wiltshire j...@debian.org > Debian Developer http://people.debian.org/~jmw > > 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 > > -- Cheers, Russell Sim
Bug#786491: libgit2: Fails to build for the second time
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 covered in the new maintainers guide though. -- Cheers, Russell -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#786494: libgit2: loss of libssh2 functionality; please add "pkg-config" to Build-Depends
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 now done via pkg-config instead of a > custom search of a few directories. > > Because "libgit2" do not depend on "pkg-config" new upstream release fails to > detect libssh library and builds without SSH support. > > After adding "pkg-config" to Build-Depends the following should appear in > build log: > > -- checking for module 'libssh2' > -- found libssh2, version 1.5.0 > > and "libgit2-22" will Depend on "libssh2-1". > > Please add "pkg-config" to Build-Depends. Thanks for the thorougher details. :) -- Cheers, Russell -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#786491: libgit2: Fails to build for the second time
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 seems that the cmake file's clean function should remove the clar.suite file.. The other one is missed though. I'll put in a patch to remove them both for the short term. -- Cheers, Russell -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#780495: libgit2-dev: package new version
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 debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#776839: unblock: libgit2/0.21.3-1.1
On 17 February 2015 at 09:26, Mehdi Dogguy wrote: > Thanks for your work and sorry for not getting back to you sooner. The > patch > looks okay. Please go ahead and upload 0.21.1-3 to Jessie and notify us as > soon as it gets accepted. > Ok, it has been uploaded and accepted https://packages.qa.debian.org/libg/libgit2/news/20150222T113335Z.html Thanks! -- Cheers, Russell Sim
Bug#776839: unblock: libgit2/0.21.3-1.1
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.21.1-2.1?
>>
>
>
> Thanks for looking at this. I have created a patch that backport the
> relevant changes to the 0.21.1-2.1
I have reduced the patch removing any Win32 parts.
--
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/changelog 2015-02-12 20:06:00.0 +1100
@@ -1,3 +1,10 @@
+libgit2 (0.21.1-3) jessie; urgency=medium
+
+ * Backported fix for case insensitive filesystems (CVE-2014-9390).
+(Closes: #774048)
+
+ -- Russell Sim Tue, 10 Feb 2015 20:29:05 +1100
+
libgit2 (0.21.1-2.1) jessie; urgency=medium
* Non-maintainer upload.
diff -Nru libgit2-0.21.1/debian/patches/CVE-2014-9390.patch
libgit2-0.21.1/debian/patches/CVE-2014-9390.patch
--- libgit2-0.21.1/debian/patches/CVE-2014-9390.patch 1970-01-01
10:00:00.0 +1000
+++ libgit2-0.21.1/debian/patches/CVE-2014-9390.patch 2015-02-12
20:06:00.0 +1100
@@ -0,0 +1,1479 @@
+commit a86d224d78a3ac0f8a1901b0e9e2aee1e15d6f73
+Author: Edward Thomson
+Date: Thu Dec 18 12:41:59 2014 -0600
+
+index tests: test capitalization before mkdir
+
+commit 86b9eb3bf5dba342d0a5d805e6fe35c3e9c861cc
+Author: Carlos Martín Nieto
+Date: Thu Dec 18 02:11:06 2014 +0100
+
+Plug leaks
+
+commit 07164371d10109ba564835947a62fcedf288dce9
+Author: Carlos Martín Nieto
+Date: Thu Dec 18 02:07:36 2014 +0100
+
+Create miscapitialised dirs for case-sensitive filesystems
+
+We need these directories to exist so cl_git_mkfile() can create the
+files we ask it to.
+
+commit 5d5d6136aaeea22903ed5d30a858f8d106876771
+Author: Edward Thomson
+Date: Tue Dec 16 18:53:55 2014 -0600
+
+Introduce core.protectHFS and core.protectNTFS
+
+Validate HFS ignored char ".git" paths when `core.protectHFS` is
+specified. Validate NTFS invalid ".git" paths when `core.protectNTFS`
+is specified.
+
+commit 2698e209d895856df9900899948269e2e490abd3
+Author: Vicent Marti
+Date: Tue Dec 16 13:03:02 2014 +0100
+
+path: Use UTF8 iteration for HFS chars
+
+commit d7026dc574b79723008bba72989f74a801f4dfb5
+Author: Edward Thomson
+Date: Wed Dec 10 19:12:16 2014 -0500
+
+checkout: disallow bad paths on HFS
+
+HFS filesystems ignore some characters like U+200C. When these
+characters are included in a path, they will be ignored for the
+purposes of comparison with other paths. Thus, if you have a ".git"
+folder, a folder of ".git" will also match. Protect our
+".git" folder by ensuring that ".git" and friends do not match it.
+
+commit 37221f8cb02554297710f703047711a61e1169bb
+Author: Edward Thomson
+Date: Tue Nov 25 18:13:00 2014 -0500
+
+checkout: disallow bad paths on win32
+
+Disallow:
+ 1. paths with trailing dot
+ 2. paths with trailing space
+ 3. paths with trailing colon
+ 4. paths that are 8.3 short names of .git folders ("GIT~1")
+ 5. paths that are reserved path names (COM1, LPT1, etc).
+ 6. paths with reserved DOS characters (colons, asterisks, etc)
+
+These paths would (without \\?\ syntax) be elided to other paths - for
+example, ".git." would be written as ".git". As a result, writing these
+paths literally (using \\?\ syntax) makes them hard to operate with from
+the shell, Windows Explorer or other tools. Disallow these.
+
+commit cb6a309d8667310d3323f5b601a2f2fa893c37d0
+Author: Vicent Marti
+Date: Tue Nov 25 00:58:03 2014 +0100
+
+index: Check for valid paths before creating an index entry
+
+commit 928a41d189f068010a32c6dea4bf921baa81d21c
+Author: Vicent Marti
+Date: Tue Nov 25 00:14:52 2014 +0100
+
+tree: Check for `.git` with case insensitivy
+
+commit f45baf7a94a75cfb1855c9a750f38bbcfa22b199
+Author: Edward Thomson
+Date: Mon Dec 1 13:09:58 2014 -0500
+
+win32: use NT-prefixed "\\?\" paths
+
+When turning UTF-8 paths into UCS-2 paths for Windows, always use
+the \\?\-prefixed paths. Because this bypasses the system's
+path canonicalization, handle the canonicalization functions ourselves.
+
+We must:
+ 1. always use a backslash as a directory separator
+ 2. only use a single backslash between directories
+ 3. not rely on the system to translate "." and ".." in paths
+ 4. remove trailing backslashes, except at the drive root (C:\)
+
+commit 2e37e214e3d85da2a68476c7ae54051d525b05eb
+Author: Edward Thomson
+Date: Mon Dec 1 13:06:11 2014 -0500
+
+clar: wide characte
Bug#776839: unblock: libgit2/0.21.3-1.1
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.21.1-2.1?
>
Thanks for looking at this. I have created a patch that backport 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/changelog 2015-02-11 23:09:15.0 +1100
@@ -1,3 +1,10 @@
+libgit2 (0.21.1-3) jessie; urgency=medium
+
+ * Backported fix for case insensitive filesystems (CVE-2014-9390).
+(Closes: #774048)
+
+ -- Russell Sim Tue, 10 Feb 2015 20:29:05 +1100
+
libgit2 (0.21.1-2.1) jessie; urgency=medium
* Non-maintainer upload.
diff -Nru libgit2-0.21.1/debian/patches/CVE-2014-9390.patch
libgit2-0.21.1/debian/patches/CVE-2014-9390.patch
--- libgit2-0.21.1/debian/patches/CVE-2014-9390.patch 1970-01-01
10:00:00.0 +1000
+++ libgit2-0.21.1/debian/patches/CVE-2014-9390.patch 2015-02-11
23:09:15.0 +1100
@@ -0,0 +1,2483 @@
+commit a86d224d78a3ac0f8a1901b0e9e2aee1e15d6f73
+Author: Edward Thomson
+Date: Thu Dec 18 12:41:59 2014 -0600
+
+index tests: test capitalization before mkdir
+
+commit 86b9eb3bf5dba342d0a5d805e6fe35c3e9c861cc
+Author: Carlos Martín Nieto
+Date: Thu Dec 18 02:11:06 2014 +0100
+
+Plug leaks
+
+commit 07164371d10109ba564835947a62fcedf288dce9
+Author: Carlos Martín Nieto
+Date: Thu Dec 18 02:07:36 2014 +0100
+
+Create miscapitialised dirs for case-sensitive filesystems
+
+We need these directories to exist so cl_git_mkfile() can create the
+files we ask it to.
+
+commit 5d5d6136aaeea22903ed5d30a858f8d106876771
+Author: Edward Thomson
+Date: Tue Dec 16 18:53:55 2014 -0600
+
+Introduce core.protectHFS and core.protectNTFS
+
+Validate HFS ignored char ".git" paths when `core.protectHFS` is
+specified. Validate NTFS invalid ".git" paths when `core.protectNTFS`
+is specified.
+
+commit 2698e209d895856df9900899948269e2e490abd3
+Author: Vicent Marti
+Date: Tue Dec 16 13:03:02 2014 +0100
+
+path: Use UTF8 iteration for HFS chars
+
+commit d7026dc574b79723008bba72989f74a801f4dfb5
+Author: Edward Thomson
+Date: Wed Dec 10 19:12:16 2014 -0500
+
+checkout: disallow bad paths on HFS
+
+HFS filesystems ignore some characters like U+200C. When these
+characters are included in a path, they will be ignored for the
+purposes of comparison with other paths. Thus, if you have a ".git"
+folder, a folder of ".git" will also match. Protect our
+".git" folder by ensuring that ".git" and friends do not match it.
+
+commit 37221f8cb02554297710f703047711a61e1169bb
+Author: Edward Thomson
+Date: Tue Nov 25 18:13:00 2014 -0500
+
+checkout: disallow bad paths on win32
+
+Disallow:
+ 1. paths with trailing dot
+ 2. paths with trailing space
+ 3. paths with trailing colon
+ 4. paths that are 8.3 short names of .git folders ("GIT~1")
+ 5. paths that are reserved path names (COM1, LPT1, etc).
+ 6. paths with reserved DOS characters (colons, asterisks, etc)
+
+These paths would (without \\?\ syntax) be elided to other paths - for
+example, ".git." would be written as ".git". As a result, writing these
+paths literally (using \\?\ syntax) makes them hard to operate with from
+the shell, Windows Explorer or other tools. Disallow these.
+
+commit cb6a309d8667310d3323f5b601a2f2fa893c37d0
+Author: Vicent Marti
+Date: Tue Nov 25 00:58:03 2014 +0100
+
+index: Check for valid paths before creating an index entry
+
+commit 928a41d189f068010a32c6dea4bf921baa81d21c
+Author: Vicent Marti
+Date: Tue Nov 25 00:14:52 2014 +0100
+
+tree: Check for `.git` with case insensitivy
+
+commit f45baf7a94a75cfb1855c9a750f38bbcfa22b199
+Author: Edward Thomson
+Date: Mon Dec 1 13:09:58 2014 -0500
+
+win32: use NT-prefixed "\\?\" paths
+
+When turning UTF-8 paths into UCS-2 paths for Windows, always use
+the \\?\-prefixed paths. Because this bypasses the system's
+path canonicalization, handle the canonicalization functions ourselves.
+
+We must:
+ 1. always use a backslash as a directory separator
+ 2. only use a single backslash between directories
+ 3. not rely on the system to translate "." and ".." in paths
+ 4. remove trailing backslashes, except at the drive root (C:\)
+
+commit 2e37e214e3d85da2a68476c7ae54051d525b05eb
+Author: Edward Thomson
+Date: Mon Dec 1 13:06:11 2014 -0500
+
+clar: wide character comparisons
+
+commit f2e46110c9f72d5eca539c76972b87003c5922be
+Author: Edward Thomson
+Date
Bug#776839: unblock: libgit2/0.21.3-1.1
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 time of the previous request I did not think that the vulnerability met the requirements for an unblock request. I have since been contacted by the Debian security team and asked to submit an unblock request. I haven't split out the fix into a separate patch on the existing package in jessie as it's probably not super easy. But i can do it if it's required. I have not inculded a debdiff since it's 182K but I can attach it if needed. 0. https://security-tracker.debian.org/tracker/CVE-2014-9390 unblock libgit2/0.21.3-1.1 -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-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 Init: systemd (via /run/systemd/system) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#774569: unblock: libgit2/0.21.1-2
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 package libgit2 > > The package is failing to build on some buildd i386/amd64 hosts > because of a failing test. It has been reported that the same error > can be fixed by setting the TMPDIR to a directory withing the build > directory. The bug this fixes is 761539. > > > ± debdiff ../build-area/libgit2_0.21.1-1.dsc > ../build-area/libgit2_0.21.1-2.dsc > diff -Nru libgit2-0.21.1/debian/changelog libgit2-0.21.1/debian/changelog > --- libgit2-0.21.1/debian/changelog 2014-09-03 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; urgency=medium > >* New upstream release 0.21.1. > diff -Nru libgit2-0.21.1/debian/rules libgit2-0.21.1/debian/rules > --- libgit2-0.21.1/debian/rules 2014-09-03 13:13:06.0 +1000 > +++ libgit2-0.21.1/debian/rules 2015-01-04 13:37:53.0 +1100 > @@ -36,6 +36,12 @@ > dh_auto_install --builddirectory=build-debian-release > dh_auto_install --builddirectory=build-debian-devel > > +override_dh_auto_test: > + mkdir -p build-debian-release/tmp > + TMPDIR=$(PWD)/build-debian-release/tmp dh_auto_test > --builddirectory=build-debian-release > + mkdir -p build-debian-devel/tmp > + TMPDIR=$(PWD)/build-debian-devel/tmp dh_auto_test > --builddirectory=build-debian-devel > + > override_dh_strip: > dh_strip --dbg-package=libgit2-dbg > > > > unblock libgit2/0.21.1-1 > > -- System Information: > Debian Release: 8.0 > APT prefers unstable > APT policy: (990, 'unstable'), (500, 'testing'), (1, 'experimental') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 3.16.0-4-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 > Init: systemd (via /run/systemd/system) -- Cheers, Russell -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#774048: CVE-2014-9390
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 have to wait until after the unfreeze before I can upload it to unstable. -- Cheers, Russell -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#774569: unblock: libgit2/0.21.1-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package libgit2 The package is failing to build on some buildd i386/amd64 hosts because of a failing test. It has been reported that the same error can be fixed by setting the TMPDIR to a directory withing the build directory. The bug this fixes is 761539. ± debdiff ../build-area/libgit2_0.21.1-1.dsc ../build-area/libgit2_0.21.1-2.dsc diff -Nru libgit2-0.21.1/debian/changelog libgit2-0.21.1/debian/changelog --- libgit2-0.21.1/debian/changelog 2014-09-03 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; urgency=medium * New upstream release 0.21.1. diff -Nru libgit2-0.21.1/debian/rules libgit2-0.21.1/debian/rules --- libgit2-0.21.1/debian/rules 2014-09-03 13:13:06.0 +1000 +++ libgit2-0.21.1/debian/rules 2015-01-04 13:37:53.0 +1100 @@ -36,6 +36,12 @@ dh_auto_install --builddirectory=build-debian-release dh_auto_install --builddirectory=build-debian-devel +override_dh_auto_test: + mkdir -p build-debian-release/tmp + TMPDIR=$(PWD)/build-debian-release/tmp dh_auto_test --builddirectory=build-debian-release + mkdir -p build-debian-devel/tmp + TMPDIR=$(PWD)/build-debian-devel/tmp dh_auto_test --builddirectory=build-debian-devel + override_dh_strip: dh_strip --dbg-package=libgit2-dbg unblock libgit2/0.21.1-1 -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-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 Init: systemd (via /run/systemd/system) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#761170: upstream
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 callback returned -1 > > > I can reproduce this in my test environment on i386 and amd64. It only happens > when the builddir and /tmp are on different filesystems. It seems the local > clone tries to create a hard link, which fails across filesystems (the fact > that this happens without fallback is an error in itself, so the test actually > discovered a problem here). When setting the TMPDIR to a directory on the same > filesystem, the test doesn't hit this issue, and the build works fine. I've had a go at reproducing this locally, but it seems to be a pretty subtle bug. My TMP_DIR on one of my machines is on a different file system to my builddir but it seems to switch to copying instead of linking during the clone. I can see this with strace. They do stat /tmp and . before beginning the copy/link. I realise it's probably futile but could you please run stat and compare your device id's. That is how they are checking that they are the same FS in the clone code. -- Cheers, Russell -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#761539: libgit2: FTBFS: Tests failures
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. > > Relevant part (hopefully): >> submodule::add >> submodule::lookup.. >> submodule::modify... >> submodule::nosubs... >> submodule::status... >> threads::basic.. >> threads::diff.. >> threads::iterator. >> threads::refdb.. >> trace::trace.. >> >> 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 callback returned -1 It has been identified that this failure is caused by having the tmp dir exist on a different mount to the package source. This can be fixed by setting the TMP_DIR to the package build dir before running the tests. -- Cheers, Russell -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#761170: upstream
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 callback returned -1 >> > >> > >> > I can reproduce this in my test environment on i386 and amd64. It only >> > happens >> > when the builddir and /tmp are on different filesystems. It seems the local >> > clone tries to create a hard link, which fails across filesystems (the fact >> > that this happens without fallback is an error in itself, so the test >> > actually >> > discovered a problem here). When setting the TMPDIR to a directory on the >> > same >> > filesystem, the test doesn't hit this issue, and the build works fine. >> > >> > It's unclear to me why this only happens on i386, but I suspect that the >> > setup >> > of the buildd chroots isn't the same everywhere. >> >> Yeah it struck me as odd. This same problem effects kfreebsd too so the >> change of the tmp dir will fix those builds as well. I'll have go at the >> running the clone nonetwork test with TMPDIR set to a mounted file >> system and report a bug upstream. >> >> > In any case, adding this patch fixes it in my environment. I can do an NMU >> > if >> > necessary. >> >> Thanks heaps for the patch, I only yesterday did exactly the same >> thing. It's included in the yet to be uploaded 0.21.3-1 that will also >> address the recent CVE. >> >> 0. >> http://anonscm.debian.org/cgit/users/arrsim-guest/libgit2.git/commit/?id=bd3a1fc82c5af703fe061fb22022eb48fb89be50 > > Does the tmp-test dir get cleaned up in the clean target? So that is why to put the TMP_DIR in the target dir for each build. Cunning. I'll follow suite. > Also, please note that most of the changes in the latest uploads probably > don't comply with the freeze policy. If you think they do, you need to file an > unblock request explaining why (including a debdiff). > > https://release.debian.org/jessie/freeze_policy.html > > I guess #761170 and #761539 should be unmerged, as they are really different > issues. Bug #761170 should be downgraded back to important. Adding support for > new architectures isn't something that is allowed during the freeze. The only > real issue for the version in testing is #761539, which is about > clone::nonetwork::local_absolute_path, which can be fixed by setting the > tmp dir. Setting TMP_DIR will fix kfreebsd builds too. This can't be avoided unless we explicitly fail when building on those architectures. I'm happy to split the this into 2 bugs and 2 uploads. One revision to fix the TMP_DIR bug that is messing with the i386 build. And a new version that I'll get uploaded once we unfreeze. So is the best course of action: - Split bugs - Create new revision that only fixes the failing test on i386, it will also force and kfreebsd build to fail. -- Cheers, Russell -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#761170: upstream
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/tests/repo/iterator.c:952] >> Expected function call to fail: git_iterator_advance(&e, i) > > This problem is only occurs when running is root (the test chmods a file to > 000 and checks if accessing it fails). It would probably be a good idea to add > another test to check if the test is running as root, and fail in that case > (because the tests assume they aren't). Interesting I didn't know that the user running the tests was the problem. Is that a problem with the buildd deployments? Or is it not a requirement that they all run as the same user? I guess what I'm really asking is if I add a test who will fix it when it fails? > 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 callback returned -1 > > > I can reproduce this in my test environment on i386 and amd64. It only happens > when the builddir and /tmp are on different filesystems. It seems the local > clone tries to create a hard link, which fails across filesystems (the fact > that this happens without fallback is an error in itself, so the test actually > discovered a problem here). When setting the TMPDIR to a directory on the same > filesystem, the test doesn't hit this issue, and the build works fine. > > It's unclear to me why this only happens on i386, but I suspect that the setup > of the buildd chroots isn't the same everywhere. Yeah it struck me as odd. This same problem effects kfreebsd too so the change of the tmp dir will fix those builds as well. I'll have go at the running the clone nonetwork test with TMPDIR set to a mounted file system and report a bug upstream. > In any case, adding this patch fixes it in my environment. I can do an NMU if > necessary. Thanks heaps for the patch, I only yesterday did exactly the same thing. It's included in the yet to be uploaded 0.21.3-1 that will also address the recent CVE. 0. http://anonscm.debian.org/cgit/users/arrsim-guest/libgit2.git/commit/?id=bd3a1fc82c5af703fe061fb22022eb48fb89be50 -- Cheers, Russell -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#761170: upstream
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 permissions on 'root/b/c.git': Operation not permitted 2) Failure: repo::init::extended_with_template_and_shared_mode [/home/russell/libgit2-0.21.2/tests/repo/init.c:489] Function call failed: (git_repository_init_ext(&_repo, "init_shared_from_tpl", &opts)) error -1 - Failed to set permissions on 'init_shared_from_tpl/.git': Operation not permitted I can't test the sparc so I'm hoping that these problems have been fixed. But I can't confirm. I have been unable to replicate the rebuild issues with the package, so it's unlikely that they have been fixed. http://aws-logs.debian.net/ftbfs-logs/2014/09/13/libgit2_0.21.1-1_unstable.log http://aws-logs.debian.net/ftbfs-logs/2014/09/26/libgit2_0.21.1-1_unstable.log http://aws-logs.debian.net/ftbfs-logs/2014/10/12/libgit2_0.21.1-1_unstable.log 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 callback returned -1 -- Cheers, Russell -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#761170: upstream
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 sending it upstream. But upstream has been super receptive so I probably shouldn't have delayed. -- Thanks, Russell -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#761170: libgit2: FTBFS on multiple architectures
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 the other 2 are just failing tests in the test suite. I'll see if I can replicate these locally. Thanks for bringing these to my attention. Cheers, Russell -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#745960: libgit2: Please upload to unstable
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 that the new release 0.21.1 be uploaded by my mentor into unstable, that will happen soon. Thanks! Russell -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#745960: libgit2: Please upload to unstable
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 changes with every release. Parts of the library are still under heavy development, version 0.20.0 changed the diff and patch API significantly for example. The releases also happen quite regularly so that would require all dependent packages to also be upgraded regularly. Cheers, Russell signature.asc Description: PGP signature
Bug#721454: libgit2 contiains mix of LGPL2 and Apache2
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: >> >> Paul Tagliamonte writes: >> it's not a pure GPLv2 license, instead it's modified to make it more >> compatible[0]. >> >> "This is a custom license which in practical effects makes it more >> permissive than the LGPLv2, allowing redistribution of software linked >> against the library under all circumstances without having to disclose >> its source code." >> >> >> I have also found that I missed an update to the license that happened >> >> in 0.19.0. It was a new reference to the PHP 3.01 license. From my >> >> understanding it's also incompatible with the GPLv2 and GPLv3. >> >> >> >> Hehe, well I think this PHP license thing is probably the biggest >> problem now, perhaps we should wait until they actually figure out where >> the got it from. I have had another read over the PHP license and the reason it's incompatible. Seems that it's because of the restriction on using the name PHP in derived works. I believe that because of the of the linking preamble on this licence it will be compatible. I'm going to close this ticket, if you believe this not to be the case, feel free to contact me. Thanks, Russell signature.asc Description: PGP signature
Bug#721454: libgit2 contiains mix of LGPL2 and Apache2
-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 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 >> > getting the copyright holders of the apache2 code to move to Expat or >> > similar) So I think that I have an answer to the GPLv2 and Apache2 incompatibilities. They have added a linking exception preamble to the license, so it's not a pure GPLv2 license, instead it's modified to make it more compatible[0]. "This is a custom license which in practical effects makes it more permissive than the LGPLv2, allowing redistribution of software linked against the library under all circumstances without having to disclose its source code." >> I have also found that I missed an update to the license that happened >> in 0.19.0. It was a new reference to the PHP 3.01 license. From my >> understanding it's also incompatible with the GPLv2 and GPLv3. >> >> I'll send a message upstream regarding these issues. In the mean time >> is there an action I should take regarding the package, it's currently >> in experimental, will it need to be removed from the archive? I have raised this with the upstream developers, and they are trying to remove the PHP code and are also seeking legal advice[1]. It also seems that I was mistaken, the PHP license was added to the code in the master branch, it's not in the 0.19.0 release. But they are still trying to workout the origin of the code. So it may have been mistakenly identified as being from the PHP code base. The code in question appears in the 0.19.0 release but it's only used for windows compatibility. I can remove it with a patch, so as to be sure it's not included in the binary? > Yeah, if you wouldn't mind a RoM, we can introduce it after upstream > gives folks the ability to, well, distribute the binaries :) Hehe, well I think this PHP license thing is probably the biggest problem now, perhaps we should wait until they actually figure out where the got it from. Cheers, Russell 0. https://github.com/libgit2/libgit2/issues/567 1. https://github.com/libgit2/libgit2/pull/1789 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) iQEcBAEBAgAGBQJSKSM7AAoJEKPQMr0n6UoaK3oH/2WZkDdseoeSkIjyIyvQptgm 7u7Seg4gTPJnSsiUZNfe91Vht9pCzjtq6gU1WpChWvJde7/zSFTCd0H+gelsuJcC IPn0DNk8CpJG5Mqc/CzjfzYtxFZP6rlhTPKjsw2JWjHRYoNQwtkJHAogMRr10/om vJHiTe9gJz9IJDjE2RFazQwg5mUqJj+N7P5lqOsiquCKd6VXadaJnGQbE3m+nz12 80uOox5c/QYKt61bZqSxfr3ZU86+AeOUX2uYDe3ayM1e+O6ckmTM4jomuVSHEhWo xNoPFneFiiuA9VPWavFhVYHFCVaAXbZPRjYKsEafjNeVz3bJQ27rP705rsDw6T4= =xwO3 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#721454: libgit2 contiains mix of LGPL2 and Apache2
-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 > getting the copyright holders of the apache2 code to move to Expat or > similar) Hey Paul, Thanks for notifying me of this issue. I have also found that I missed an update to the license that happened in 0.19.0. It was a new reference to the PHP 3.01 license. From my understanding it's also incompatible with the GPLv2 and GPLv3. I'll send a message upstream regarding these issues. In the mean time is there an action I should take regarding the package, it's currently in experimental, will it need to be removed from the archive? Thanks again, Russell -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJSJJNZAAoJEKPQMr0n6Uoa1+QH/jcVzxe2NTHWW1ka5fxi2sut y9GDSIK4tUqSLhh/jkmLlFYt7OzzO8lqaESUzrwxI0JAtf5QK0mU9fI8BsdJ07Eq usjwuCtEfW3anYboqCjY4Lzs2JVXS0AYHNwUIfoTgDUQck70b3QMODPLFMpisDbs +TmHi6uQHfVuKVfJW+DdbOdVbfCELu6vyhA13PNqQY2zRVFUVAIUR4OjpPcJTeS4 iLMO92x98MzSSZr4gk3uGGmfTUQN5rKqBUscdgAMyW9F9yAvJRGHHB4PJ0vZ8IZJ fm+LwzOQ444luXR2YI1tXMuioGXVjrOTMFW3x1syvOCNToV2+KHGzUavYl5wHlA= =Exuw -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#713839: [Pkg-nagios-devel] Bug#713839: nagios-plugins: check-rpc is using the wrong rpcinfo path.
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 libc-bin. I don't think I would have made that connection. > This will get fixed by recommending "rpcbind" with further releases. You may also still need to change the path. I installed the latest rpcbind it installs rpcinfo into a different directory to what this package expects /usr/sbin/rpcinfo. I had to edit /usr/lib/nagios/plugins/utils.pm to force nagios to use the correct path after installing rpcbind. Thanks, Russell -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#713839: nagios-plugins: check-rpc is using the wrong rpcinfo path.
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] but it seems to affect the debian package too. Thanks, Russell 0. https://bugs.launchpad.net/ubuntu/+source/nagios-plugins/+bug/1086151 1. http://lists.alioth.debian.org/pipermail/pkg-nagios- changes/2012-December/003281.html Error details --- Error messages like this appear in the nagios debugging log and the service drops to an Unknown state in nagios. [1371969253.026788] [016.1] [pid=8625] Embedded Perl ran /usr/lib/nagios/plugins/check_rpc: return code=3, plugin output=**ePN /usr/lib/nagios/plugins/check_rpc: "Can't exec "/usr/bin/rpcinfo": No such file or directory at (eval 1) line 308,".\n [1371969253.030020] [016.1] [pid=8626] Embedded Perl ran /usr/lib/nagios/plugins/check_rpc: return code=3, plugin output=**ePN /usr/lib/nagios/plugins/check_rpc: "Can't exec "/usr/bin/rpcinfo": No such file or directory at (eval 1) line 308,".\n the syslog side of the errors look like which i'm including more for indexing Jun 23 16:34:13 marvin nagios3: Error: Unable to rename file '/var/lib/nagios3/spool/checkresults/check30ojRr' to '/var/lib/nagios3/spool/checkresults/caUUYXN': No such file or directory Jun 23 16:34:13 marvin nagios3: Warning: Unable to move file '/var/lib/nagios3/spool/checkresults/check30ojRr' to check results queue. # apt-cache policy rpcbind rpcbind: Installed: 0.2.0-8 Candidate: 0.2.0-8 Version table: *** 0.2.0-8 0 990 http://mirror.internode.on.net/pub/debian/ testing/main amd64 Packages 500 http://mirror.internode.on.net/pub/debian/ unstable/main amd64 Packages 100 /var/lib/dpkg/status # dpkg -L rpcbind /. /usr /usr/share /usr/share/man /usr/share/man/man8 /usr/share/man/man8/rpcbind.8.gz /usr/share/man/man7 /usr/share/man/man7/rpcinfo.7.gz /usr/share/doc /usr/share/doc/rpcbind /usr/share/doc/rpcbind/copyright /usr/share/doc/rpcbind/changelog.Debian.gz /usr/share/doc/rpcbind/changelog.gz /usr/sbin /usr/sbin/rpcinfo /sbin /sbin/rpcbind /etc /etc/insserv.conf.d /etc/insserv.conf.d/rpcbind /etc/init.d /etc/init.d/rpcbind -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages nagios-plugins depends on: ii nagios-plugins-basic 1.4.16-1 ii nagios-plugins-standard 1.4.16-1 Versions of packages nagios-plugins recommends: ii nagios-plugins-contrib 6.20130521 Versions of packages nagios-plugins suggests: ii nagios3 3.4.1-3+b1 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#700181: libgit2-0: is compiled without THREADSAFE
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 > Severity: normal > > As far as I can see, libgit2 is compiled without the THREADSAFE option, > forcing > applications that want to use it in multiple threads to include their own > copy. > > -- System Information: > Debian Release: 7.0 > APT prefers testing > APT policy: (500, 'testing'), (500, 'stable'), (1, 'experimental') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 3.6.7 (SMP w/2 CPU cores) > Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > > Versions of packages libgit2-0 depends on: > ii libc6 2.13-37 > ii zlib1g 1:1.2.7.dfsg-13 > > libgit2-0 recommends no packages. > > libgit2-0 suggests no packages. > > -- no debconf information pgpmNkLlFD3mF.pgp Description: PGP signature
Bug#680337: Installs windows-specific header files
Hey Josh, Thanks for the bug report, since 0.18.0 has just been released I have been looking at closing this bug. But I don't think that it would be wise to remove the files in the package because there are other .h files that conditionally include them namely common.h. This would probably 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. Regards, Russell Sim Josh Triplett writes: > Package: libgit2-dev > Version: 0.17.0-1 > Severity: normal > > libgit2-dev installs three header files that only work on Windows > systems: > > /usr/include/git2/inttypes.h > /usr/include/git2/stdint.h > /usr/include/git2/windows.h > > Please don't install these files in the Debian package. > > - Josh Triplett > > -- System Information: > Debian Release: wheezy/sid > APT prefers unstable > APT policy: (500, 'unstable'), (1, 'experimental') > Architecture: amd64 (x86_64) > > Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores) > Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > > Versions of packages libgit2-dev depends on: > ii libgit2-0 0.17.0-1 > > libgit2-dev recommends no packages. > > libgit2-dev suggests no packages. > > -- no debconf information > > pgpYLvq0Hwbzm.pgp Description: PGP signature
Bug#689454: python-doc: Search isn't working.
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 Python-doc package. This is because the underscore library is located at a different location to the one that is symlinked to in the rules. Thanks, Russell $ ls -l /usr/share/doc/python-doc/html/_static/underscore.js lrwxrwxrwx 1 root root43 Apr 23 06:33 underscore.js -> ../../../../javascript/underscore/jquery.js $ ls -l ../../../../javascript/underscore total 56 -rw-r--r-- 1 root root 37390 Apr 11 00:43 underscore.js -rw-r--r-- 1 root root 12741 Apr 14 02:49 underscore.min.js -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Foreign Architectures: i386 Versions of packages python-doc depends on: ii python2.7-doc 2.7.3~rc2-2.1 python-doc recommends no packages. Versions of packages python-doc suggests: ii python 2.7.3-2 pn python-examples -- no debconf information ± dpkg -l libjs-underscore Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ NameVersion Architecture Description +++-===--- ii libjs-underscore1.3.3-1 all JavaScript's functional programming helper library diff --git a/debian/rules b/debian/rules index 5d26195..9f82234 100755 --- a/debian/rules +++ b/debian/rules @@ -966,7 +966,7 @@ binary-indep: build-indep install stamps/stamp-control /usr/share/doc/$(p_doc)/html \ /usr/share/javascript/jquery/jquery.js \ /usr/share/doc/$(p_base)/html/_static/jquery.js \ - /usr/share/javascript/underscore/jquery.js \ + /usr/share/javascript/underscore/underscore.js \ /usr/share/doc/$(p_base)/html/_static/underscore.js : # devhelp docs Date: Wed, 03 Oct 2012 06:33:06 +1000 Message-ID: <87pq50pqbh@sparky.home>
Bug#683521: [Pkg-nagios-devel] Bug#683521: nagios3-common: install fails if /etc/nagios3/resource.cfg is missing
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, here is the >> error from apt. > And why is is missing? To be honest I can't remember (it was in Feb), I am using puppet to manage the config files so it was removed probably because it stores the config in a subdir. I could possibly have removed it to avoid confusion about which one was the definitive version. Cheers, Russell pgpaov0I4KKEn.pgp Description: PGP signature
Bug#683521: nagios3-common: install fails if /etc/nagios3/resource.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: error processing nagios3-common (--configure): subprocess installed post-installation script returned error exit status 1 dpkg: dependency problems prevent configuration of nagios3-cgi: nagios3-cgi depends on nagios3-common (= 3.4.1-2); however: Package nagios3-common is not configured yet. dpkg: error processing nagios3-cgi (--configure): dependency problems - leaving unconfigured dpkg: dependency problems prevent configuration of nagios3-core: nagios3-core depends on nagios3-common (= 3.4.1-2); however: Package nagios3-common is not configured yet. dpkg: error processing nagios3-core (--configure): dependency problems - leaving unconfigured dpkg: dependency problems prevent configuration of nagios3: nagios3 depends on nagios3-cgi (= 3.4.1-2); however: Package nagios3-cgi is not configured yet. nagios3 depends on nagios3-core (= 3.4.1-2); however: Package nagios3-core is not configured yet. dpkg: error processing nagios3 (--configure): dependency problems - leaving uncconfigured to not write apport reports configured to not write apport reports configured to not write apport reports configured to not write apport reports onfigured Errors were encountered while processing: nagios3-common nagios3-cgi nagios3-core nagios3 -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages nagios3-common depends on: ii adduser 3.113+nmu3 ii bsd-mailx [mailx] 8.1.2-0.2006cvs-1 ii coreutils 8.13-3.2 ii libjs-jquery 1.7.2+debian-2 ii lsb-base 4.1+Debian7 ii nagios-plugins-basic 1.4.15-5 ii ucf 3.0025+nmu3 Versions of packages nagios3-common recommends: ii nagios-plugins 1.4.15-5 nagios3-common suggests no packages. -- Configuration Files: /etc/nagios3/commands.cfg [Errno 2] No such file or directory: u'/etc/nagios3/commands.cfg' /etc/nagios3/conf.d/contacts_nagios2.cfg [Errno 13] Permission denied: u'/etc/nagios3/conf.d/contacts_nagios2.cfg' /etc/nagios3/conf.d/extinfo_nagios2.cfg [Errno 13] Permission denied: u'/etc/nagios3/conf.d/extinfo_nagios2.cfg' /etc/nagios3/conf.d/generic-host_nagios2.cfg [Errno 13] Permission denied: u'/etc/nagios3/conf.d/generic-host_nagios2.cfg' /etc/nagios3/conf.d/generic-service_nagios2.cfg [Errno 13] Permission denied: u'/etc/nagios3/conf.d/generic-service_nagios2.cfg' /etc/nagios3/conf.d/hostgroups_nagios2.cfg [Errno 13] Permission denied: u'/etc/nagios3/conf.d/hostgroups_nagios2.cfg' /etc/nagios3/conf.d/localhost_nagios2.cfg [Errno 13] Permission denied: u'/etc/nagios3/conf.d/localhost_nagios2.cfg' /etc/nagios3/conf.d/services_nagios2.cfg [Errno 13] Permission denied: u'/etc/nagios3/conf.d/services_nagios2.cfg' /etc/nagios3/conf.d/timeperiods_nagios2.cfg [Errno 13] Permission denied: u'/etc/nagios3/conf.d/timeperiods_nagios2.cfg' /etc/nagios3/nagios.cfg changed [not included] /etc/nagios3/resource.cfg [Errno 13] Permission denied: u'/etc/nagios3/resource.cfg' -- no debconf information pgpmHdYXBzv9m.pgp Description: PGP signature
Bug#614517: Info received (Bug#614517: Packaging of libgit2
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 upload a package depending on libgit2, thus i would >>> like to see libgit2 >>> in unstable. :-) >> I don't know too much about blocking things from testing but I believe >> this is not recommended practice. The problem is that the API is > Filing a blocker RC bug is widely used when the package is not considered > to be ready or useful as part of the stable distributuion: > http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=no&bug=414385 >> changing in backwards incompatible ways with every version change. So >> the reason it's in experimental is because it is a more appropriate >> place for a package that is undergoing these kinds of changes. You will >> still able to access the package from the experimental repository and >> any packages that depend will probably need to be uploaded to >> experimental. I would also recommend adding a dependency on the >> specific version i.e. 0.16 because there are already symbol renames in >> master that will break compatibility. > In case of young libraries it is normal, IMO it could be part of stable. I don't think using a blocker RC bug is really justified in this case. For a start this library is not actually in Debian yet, so it is not going to break any other packages. By putting it in unstable there is an implicit agreement that the package will progress to testing. By putting the library in experimental it's much clearer what the current state of the library is, which is that every version will likely break all client libraries and there will be no bug fix releases. The library is young, and I think putting the library into unstable it will be misrepresenting the actual state of the library. You will still be able to upload your package, but you will need to upload it to experimental. Cheers, Russell -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#614517: Info received (Bug#614517: Packaging of libgit2
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
Bug#614517: Info received (Bug#614517: Packaging of libgit2
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 depending on libgit2, thus i would > like to see libgit2 > in unstable. :-) I don't know too much about blocking things from testing but I believe this is not recommended practice. The problem is that the API is changing in backwards incompatible ways with every version change. So the reason it's in experimental is because it is a more appropriate place for a package that is undergoing these kinds of changes. You will still able to access the package from the experimental repository and any packages that depend will probably need to be uploaded to experimental. I would also recommend adding a dependency on the specific version i.e. 0.16 because there are already symbol renames in master that will break compatibility. > Could you please ship static library in libgit2-dev? > I used the attached slightly modified debian patch for generating it. Great Scott a patch, that's fantastic, I'll look into adding this and pushing it back upstream to the authors (if you haven't already done this). I'll have to check with my mentor regarding doing another upload. > Do you plan resurrecting the package repository at GitHub? Sorry for removing that without putting a forwarding url, I have a guest account on Alioth and I have uploaded it there, but I can't see it with gitweb so I'll have to investigate further. In the meantime there is a mirror on my adhoc personal hosting [1]. Regards, Russell 1. http://git.russellsim.org/?p=packages/libgit2.git;a=summary pgpSJxH9oaokv.pgp Description: PGP signature
Bug#614517: Info received (Bug#614517: Packaging of libgit2)
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 development and as a result will not be suitable for upload into unstable. Regards, Russell 1. http://librelist.com/browser//libgit2/2012/4/7/roadmap/#9a71e64a0683c5746220eaa6048d86b6 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#614517: Sponsorship request
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? Thanks, Russell pgplSXQcYFJF0.pgp Description: PGP signature
Bug#560966: CFFI test patch
Hi, I spotted this bug and thought I might be able to help. Attached is a patch that adds execution of the CFFI test suite to the package build. You may notice I have also separated out building of the test C libraries, they seem to be the main pain point during a failure. Unfortunately the tests swallow the GCC and Make stdio so without building them as a separate step it is difficult to debug. I have tested the build on i386 and amd64. The C libraries that built during testing seem to target both 64 & 32 bit architectures, so gcc-multilib is required for amd64 but I am not entirely 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 +1100 added initial testing code to rules diff --git a/debian/control b/debian/control index f4c2ae9..0f1b79b 100644 --- a/debian/control +++ b/debian/control @@ -2,7 +2,7 @@ Source: cffi Section: lisp Priority: optional Build-Depends: debhelper (>= 7) -Build-Depends-Indep: dh-lisp, texinfo, a2ps, sbcl, texlive-extra-utils, texlive, texlive-generic-recommended +Build-Depends-Indep: dh-lisp, texinfo, a2ps, sbcl, texlive-extra-utils, texlive, texlive-generic-recommended, cl-rt, cl-alexandria, cl-trivial-features, cl-babel, gcc-multilib [amd64] Maintainer: Debian Common Lisp Team Uploaders: Peter Van Eynde Standards-Version: 3.8.3 diff --git a/debian/rules b/debian/rules index 94b5229..d1b6f2d 100755 --- a/debian/rules +++ b/debian/rules @@ -36,6 +36,10 @@ binary-indep: build dh_installchangelogs dh_compress dh_fixperms + cd tests + make + cd .. + sbcl --disable-debugger --no-userinit --eval "(require 'asdf)" --eval "(asdf:oos 'asdf:test-op :cffi-tests)" --eval '(quit)' dh_installdeb dh_gencontrol dh_md5sums
Bug#614517: Packaging of libgit2
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 should be searching for a sponsor. If you are possess the power and are interested in sponsoring, that would be fantastic. Otherwise just let me know and I'll start looking for someone. Thanks, Russell -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#614517: Packaging of libgit2
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 a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#614517: Packaging of libgit2
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 and added >> > features since then, and during the pre-1.0 stage, there won't be any >> > bugfix releases, so it might make more sense to create snapshot >> > packages. >> Yes I think that snapshot releases are probably a better way, since the >> symbols are changing anyway it's probably better to imply it's an >> unstable API. Since the testing is improving in the library it should >> also be easier to determine a working version. I can look at enhancing >> my packaging to cover the execution of the clar tests and the write a >> script to automate updating from the master? > Sounds good. If the tests pass, package it, otherwise wait for the fixes > to arrive. No sense in packaging the library if it's broken. Ok I have added the clar test to the build and I have also turned on the normal test, even though they are on by default I thought it would be better to have something fail rather than risk packing a broken package. I have also tested inducing an error and to confirm that the build fails. >> > A thing I do take issue with is the short description, which claims >> > libgit2 implements the "Git DVCS", but that's not what it does. It's an >> > implementation of the core git functions and it doesn't try to replicate >> > everything git does, but provide the functionality so you can write your >> > own tools on top of it. >> How about, "library to access and manipulate Git repositories" or >> perhaps back to the original "Git core methods library"? I don't >> really like the "git core methods library" one because it kinda implies >> that git is currently using it. > Fair point. What "core methods" is trying to say it that its goal is to > implement the git plumbing functionality, rather than focus on the > porcelain commands. I have adjusted it to "low-level Git library" to try and reinforce the idea that the library implements the plumbing functionality. > BTW, I noticed that in debian/copyright you missed deps/zlib/* which is > under its own license. Yes I must admit that this was a lack of foresight, I naively removed it when I added zlib to the build-deps. I have added it back now, and I corrected some minor issues with the dep5 compatibility. I have pushed the package to my github account [1] in case need it. 1. https://github.com/russell/libgit2 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#614517: Packaging of libgit2
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 them with the GPL's > requirement that software be in its preferred editable form), though I > guess the FTP admin team would have the last say. Yes I can see how having the generated Clay/Clar executable is less that desirable if you wanted to extend Clar. But the source is included, as a compressed string in the clar executable so it's not really obfuscated, just hidden away. > 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 and added > features since then, and during the pre-1.0 stage, there won't be any > bugfix releases, so it might make more sense to create snapshot > packages. Yes I think that snapshot releases are probably a better way, since the symbols are changing anyway it's probably better to imply it's an unstable API. Since the testing is improving in the library it should also be easier to determine a working version. I can look at enhancing my packaging to cover the execution of the clar tests and the write a script to automate updating from the master? > A thing I do take issue with is the short description, which claims > libgit2 implements the "Git DVCS", but that's not what it does. It's an > implementation of the core git functions and it doesn't try to replicate > everything git does, but provide the functionality so you can write your > own tools on top of it. How about, "library to access and manipulate Git repositories" or perhaps back to the origional "Git core methods library"? I don't really like the "git core methods library" one because it kinda implies that git is currently using it. Cheers, Russell -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#614517: Packaging of libgit2
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 been using to make them more applicable to the Debian project. I have uploaded them to mentors.debian.net [1]. So at this point I am interested contributing to the packaging of this library in what ever way I can, I am happy to try and find a mentor if necessary unless someone on this list is interested?. Thanks! Russell 1. http://mentors.debian.net/package/libgit2 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#635450: tiger: erroneous behavior of -q option (.: 1: Can't open /config)
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 e: russell@gmail.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#552398: libglobus-common-dev: missing dependency
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/local/lib/perl/5.10.1 /usr/local/share/perl/5.10.1 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl . /usr/lib/perl) at /usr/bin/globus-makefile-header.gpt1 line 27. ERROR: Command failed -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing-proposed-updates'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.30-1-686-bigmem (SMP w/2 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libglobus-common-dev depends on: ii globus-core 5.15-9 Globus Toolkit - Globus Core ii libglobus-common0 10.2-6 Globus Toolkit - Common Library ii libglobus-libtool-dev 1.2-4 Globus Toolkit - Globus libtool pa ii perl 5.10.1-5 Larry Wall's Practical Extraction Versions of packages libglobus-common-dev recommends: ii libglobus-common-doc 10.2-6 Globus Toolkit - Common Library Do libglobus-common-dev suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
