Bug#515793: RFP: cgit -- C-code Web Front-end to GIT
Hi, Without noticing this RFP [1], I made another ITP [2] and experimental cgit package [3][4] which contains full source of git of specific version. I know such a package is undesirable, but I wonder if it's completely unacceptable for the Debian distribution. Isn't it possible for collaborative developers to keep maintaining this with support from the security team? [5] (I'd like to ask for co-maintainers if my package happens to be accepted) Oxan, have you already worked on your own cgit package built with something like git-source binary package? Please let me know if you made any progress. I might be able to contribute to your package! Thanks, [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=515793 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=739231 [3] http://debian.keshi.org/cgit/ [4] http://git.keshi.org/debian/cgit.git [5] https://wiki.debian.org/EmbeddedCodeCopies -- YAEGASHI Takeshi yaega...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515793: RFP: cgit -- C-code Web Front-end to GIT
Hi Jonathan, 2014-02-19 8:58 GMT+09:00 Jonathan Nieder jrnie...@gmail.com: I can write a patch demonstrating what I mean making use of your packaging from http://git.keshi.org/debian/cgit.git if you like. What do you think? I appreciate your help and would like to see how it will go with the git package with cgit. I could contribute as a co-maintainer for cgit in that case. Basically I think it's a bad idea to add more complexity to the git package and cgit/git should be decoupled in some way as Oxan stated, but we might be able to overcome possible downsides with your (the git maintainer's) assurance. Regards, -- YAEGASHI Takeshi yaega...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739231: ITP: cgit -- A hyperfast web frontend for git repositories written in C
Package: wnpp Severity: wishlist Owner: YAEGASHI Takeshi yaega...@debian.org * Package name: cgit Version : 0.10 Upstream Author : cgit Development Team c...@lists.zx2c4.com * URL : http://git.zx2c4.com/cgit/about/ * License : GPL-2 Programming Lang: C Description : A hyperfast web frontend for git repositories written in C This is an attempt to create a fast web interface for the Git SCM, using a built-in cache to decrease server I/O pressure. . Features: * basic repository browsing (logs, diffs, trees...) * caching of generated HTML * cloneable URLs (implements dumb HTTP transport) * commit feeds (atom format) * discovery of Git repositories * on-the-fly archives for tags and commits * plugin support for e.g. syntax highlighting * side-by-side diffs * simple time/author statistics * simple virtual hosting support (macro expansion) * understands GitWeb project-lists * understands gitweb.owner in Git config files * has extensive filtering framework using scripts or a built-in lua interpreter -- YAEGASHI Takeshi yaega...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739231: ITP: cgit -- A hyperfast web frontend for git repositories written in C
2014-02-17 6:40 GMT+09:00 Don Armstrong d...@debian.org: Just FYI, there's an existing RFP which I've now merged with your ITP. Argh, thanks for your prompt response. I thought it's ok just because reportbug didn't give me any caution! [You should probably also be using libgit2-0 instead of cgit's embedded git codebase if at all possible.] I've simply made a source package which contains the whole git distribution of specific version. http://debian.keshi.org/sid/cgit/ I know it wouldn't be the best solution at all, but might be acceptable considering the upstream activity has been high enough. However it doesn't look like an option after reading the discussion in #515793. It would be better if we could rely on libit2 or something alike instead, but it still seems to be in experimental. Anyway I'm going to investigate possible ways... Regards, -- YAEGASHI Takeshi yaega...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608320: unblock: wiliki/0.5.3-1.1
Hello, Thanks for your attention to wiliki package. I'm sorry that I was unaware of this unblock request by Yamane-san and submitted another as #608462... I admit this package has been of very low activity and left untouched for quite a long time due to my laziness, but I believe a certain number of sites in Japan are loyally using it for a handy locally shared CMS, I hope wiliki remains a part of squeeze however old it might be. Recent versions of wiliki would surely be packaged for the next release. Regards, -- YAEGASHI Takeshi yaega...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608462: unblock: wiliki/0.5.3-1.1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock wiliki/0.5.3-1.1 for squeeze. Thanks to NMU by Yamane-san, a bug tagged squeeze-will-remove has been fixed. Indeed it's quite old but recent versions would be packaged for the next release. Changelog: wiliki (0.5.3-1.1) unstable; urgency=high * Non-maintainer upload with maintainer's ACK. * debian/control - set Build-Depends: gauche-dev, not gauche to fix configure works (Closes: #608210) -- Hideki Yamane henr...@debian.org Thu, 30 Dec 2010 00:10:12 +0900 Regards, -- YAEGASHI Takeshi yaega...@debian.org unblock: wiliki/0.5.3-1.1 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#493999: tpm-tools: pkcs11 tools require libopencryptoki.so
Package: tpm-tools Version: 1.3.1-3 Severity: normal Hi, I've encountered a problem when I tried to run tpmtoken_init on the system without libopencryptoki-dev: % tpmtoken_init The PKCS#11 library cannot be loaded: libopencryptoki.so: cannot open shared object file: No such file or directory libopencryptoki.so seems hardcoded in PKCS#11 related tools. It's not available in any dependent packages. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.25-2-686 (SMP w/1 CPU core) Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages tpm-tools depends on: ii libc6 2.7-13 GNU C Library: Shared libraries ii libssl0.9.8 0.9.8g-13SSL shared libraries ii libtspi10.3.1-7 open-source TCG Software Stack (li ii opencryptoki2.2.6+dfsg-3 PKCS#11 implementation for Linux ( ii trousers0.3.1-7 open-source TCG Software Stack (da tpm-tools recommends no packages. tpm-tools suggests no packages. -- no debconf information Regards, -- YAEGASHI Takeshi [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#458987: libgems-ruby1.8: Installs scripts to /usr/bin
severity 458987 serious thanks Hi, With this bug you can easily overwrite/remove files in /usr/bin which belong to other packages! (e.g. apt-get install rake; gem install rake) I don't think it's a desirable behavior. If it really does match the maintainer's intention, please update the explanation in /usr/share/doc/rubygems/README.Debian. Regards, -- YAEGASHI Takeshi [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#459779: live-helper: bug in lh_chroot_devpts
Hi,
On Jan 9, 2008 1:24 AM, Jens Thiele [EMAIL PROTECTED] wrote:
the test in lh_chroot_devpts:80 fails for me
77 # Unmounting /dev/pts
78 if [ ${LH_USE_FAKEROOT} != enabled ]
79 then
80 if [ -e chroot/dev/pts/0 ]
81 then
82 ${LH_ROOT_COMMAND} umount
chroot/dev/pts
83 fi
84 fi
I suggest either improving the test wether dev/pts is mounted or simply
remove the test?
Similarly, it fails to detect sysfs being mounted in my OpenVZ VE
where there's no /sys/kernel/
I've fixed it with stat(1) as follows, but using mountpoint(1) would
be sufficient as mentioned in debian-live-devel list.
diff --git a/helpers/lh_binary_chroot b/helpers/lh_binary_chroot
index ad578cc..fa7244c 100755
--- a/helpers/lh_binary_chroot
+++ b/helpers/lh_binary_chroot
@@ -59,7 +59,7 @@ then
fi
fi
-if [ -d chroot/sys/kernel ]
+if [ $(stat -fc %T chroot/sys) = sysfs ]
then
if [ ${LH_USE_FAKEROOT} != enabled ]
then
diff --git a/helpers/lh_chroot_sysfs b/helpers/lh_chroot_sysfs
index 04e67de..fa9d74f 100755
--- a/helpers/lh_chroot_sysfs
+++ b/helpers/lh_chroot_sysfs
@@ -81,7 +81,7 @@ case ${1} in
then
# Unmounting /sys
#fuser -km chroot/sys
- if [ -e chroot/sys/kernel ]
+ if [ $(stat -fc %T chroot/sys) = sysfs ]
then
${LH_ROOT_COMMAND} umount chroot/sys
fi
--
YAEGASHI Takeshi [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#414703: rubygems: gem ignores --http-proxy for dependencies
Package: rubygems Version: 0.9.0-5 Severity: normal gem ignores --http-proxy when it attempts to process dependencies. The problem may have been solved in the latest upstream release. % sudo gem install rails -y --http-proxy http://10.0.0.1:3128/ --backtrace --debug Exception `Errno::ENOENT' at /usr/lib/ruby/1.8/rubygems/config_file.rb:49 - No such file or directory - /home/yaegashi/.gemrc Exception `LoadError' at /usr/lib/ruby/1.8/rubygems/custom_require.rb:27 - no such file to load -- sources Exception `Errno::ENETUNREACH' at /usr/lib/ruby/1.8/net/http.rb:560 - Network is unreachable - connect(2) Exception `Errno::ENETUNREACH' at /usr/lib/ruby/1.8/rubygems/remote_installer.rb:133 - Network is unreachable - connect(2) ERROR: While executing gem ... (Errno::ENETUNREACH) Network is unreachable - connect(2) /usr/lib/ruby/1.8/net/http.rb:560:in `initialize' /usr/lib/ruby/1.8/net/http.rb:560:in `open' /usr/lib/ruby/1.8/net/http.rb:560:in `connect' /usr/lib/ruby/1.8/timeout.rb:48:in `timeout' /usr/lib/ruby/1.8/timeout.rb:76:in `timeout' /usr/lib/ruby/1.8/net/http.rb:560:in `connect' /usr/lib/ruby/1.8/net/http.rb:553:in `do_start' /usr/lib/ruby/1.8/net/http.rb:542:in `start' /usr/lib/ruby/1.8/rubygems/open-uri.rb:288:in `open_http' /usr/lib/ruby/1.8/rubygems/open-uri.rb:694:in `buffer_open' /usr/lib/ruby/1.8/rubygems/open-uri.rb:199:in `open_loop' /usr/lib/ruby/1.8/rubygems/open-uri.rb:197:in `catch' /usr/lib/ruby/1.8/rubygems/open-uri.rb:197:in `open_loop' /usr/lib/ruby/1.8/rubygems/open-uri.rb:143:in `open_uri' /usr/lib/ruby/1.8/rubygems/open-uri.rb:596:in `open' /usr/lib/ruby/1.8/rubygems/open-uri.rb:92:in `open' /usr/lib/ruby/1.8/rubygems/remote_installer.rb:150:in `open_uri_or_path' /usr/lib/ruby/1.8/rubygems/remote_installer.rb:126:in `read_data' /usr/lib/ruby/1.8/rubygems/remote_installer.rb:59:in `fetch_path' /usr/lib/ruby/1.8/rubygems/incremental_fetcher.rb:39:in `fetch_path' /usr/lib/ruby/1.8/rubygems/remote_installer.rb:349:in `fetch_path' /usr/lib/ruby/1.8/rubygems/remote_installer.rb:566:in `download_gem' /usr/lib/ruby/1.8/rubygems/remote_installer.rb:442:in `install' /usr/lib/ruby/1.8/rubygems/remote_installer.rb:551:in `install_dependencies' /usr/lib/ruby/1.8/rubygems/remote_installer.rb:547:in `each' /usr/lib/ruby/1.8/rubygems/remote_installer.rb:547:in `install_dependencies' /usr/lib/ruby/1.8/rubygems/remote_installer.rb:439:in `install' /usr/lib/ruby/1.8/rubygems/gem_commands.rb:263:in `execute' /usr/lib/ruby/1.8/rubygems/gem_commands.rb:225:in `each' /usr/lib/ruby/1.8/rubygems/gem_commands.rb:225:in `execute' /usr/lib/ruby/1.8/rubygems/command.rb:69:in `invoke' /usr/lib/ruby/1.8/rubygems/cmd_manager.rb:117:in `process_args' /usr/lib/ruby/1.8/rubygems/cmd_manager.rb:88:in `run' /usr/lib/ruby/1.8/rubygems/gem_runner.rb:28:in `run' -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16.27-xen Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8) Versions of packages rubygems depends on: ii libgems-ruby1.8 0.9.0-5libraries to use RubyGems, a packa ii ruby 1.8.2-1An interpreter of object-oriented rubygems recommends no packages. -- no debconf information -- YAEGASHI Takeshi [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400556: gauche: ..*** ERROR: unbound variable: slib:features
NIIBE Yutaka wrote: Arnt Karlsen wrote: Setting up gauche (0.8.8-1) ... *** ERROR: unbound variable: slib:features With newer slib, it uses slib:features. It used to be *features*. We need to change Gauche-0.8.8/lib/slib.scm.in. Thanks for your concise information. Besides, I think that the fix of Bug#388474 is wrong. Instead, we should require slib at build-time and produce slibcat at build-time (Not at installation time). There is a case where slib is not yet installed when gauche is installed. In this case, slibcat is not produced at all. Agreed. I've been wondering about the current slib handling in postinst and what it should be. Following is my proposed change. It works for me. I'll test and upload it with the newer package later. Regards, -- YAEGASHI Takeshi [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#368415: fails to install - missing library?
Hi, Thanks for your report. In the article [EMAIL PROTECTED], Paul Collins [EMAIL PROTECTED] wrote: Package: gauche Version: 0.8.7-1 Upgrade to this version is failing with the following: Setting up gauche (0.8.7-1) ... *** ERROR: Compile Error: Compile Error: can't find dlopen-able module gauche-collection-lib /usr/share/gauche/0.8.7/lib/gauche/uvector.scm:42:(define-module gauche.uvector (use g ... /usr/share/gauche/0.8.7/lib/slib.scm:8:(define-module slib (use srfi-0) (us ... Because some essential modules were packaged into gauche-dev, gauche's postinst failed when slib already installed. To workaround this, please also install gauche-dev for now. I'll upload fixed 0.8.7-2 later. Sorry for your inconvenience. Regards, -- YAEGASHI Takeshi [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#315069: Intention to NMU
Hi, In the article [EMAIL PROTECTED], Luk Claes [EMAIL PROTECTED] wrote: Attached the patch for the version I intend to upload. Please respond if you don't want this NMU to happen, if you are working yourself on a patch or if you think that the attached patch won't work. Please go ahead. Sorry for my laziness, unfortunately I cannot make time for maintaining the package for now. There's been a newer upstream release (0.8.5) which might address this problem and I hope to package it next week. I will need to arrange with the maintainer of dependent packages to upgrade gauche. This may take additional time. Thanks, -- YAEGASHI Takeshi [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#319275: libc6-dbg: unusable debug information files in /usr/lib/debug/lib
Package: libc6-dbg Version: 2.3.2.ds1-22 Severity: normal Because files in /usr/lib/debug/lib lack all debug sections other than .debug_frame, gdb fails to acquire debug information automatically (See 15.2 Debugging Information in Separate of gdb.info). IMHO, the package should have correct debug information files in all possible (for each variant like tls) directories in the global debug file directory. Libraries with debug information in /usr/lib/debug seem useless. -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.8-2-k7 Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8) Versions of packages libc6-dbg depends on: ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#315660: mount: Wrong hash generation for the loopback device.
Package: mount
Version: 2.12p-4
Severity: normal
Tags: patch
Hi,
I found a bug in the loopback device routine in lomount.c
xgetpass() can return more than 128 bytes when it reads a passphrase
from fd specified by -p. With such a long passphrase, current
lomount.c can generate different hash value every time, so user can
never correctly encrypt or decrypt files.
Following patch will fix the problem.
--- util-linux-2.12p.orig/mount/lomount.c 2005-06-24 20:39:36.073263112
+0900
+++ util-linux-2.12p/mount/lomount.c2005-06-24 21:12:33.783174438 +0900
@@ -397,18 +397,21 @@
case LO_CRYPT_RIJNDAEL:
{
#define HASHLENGTH 20
-#define PASSWDBUFFLEN 130 /* getpass returns only max. 128 bytes, see man
getpass */
char keybits[2*HASHLENGTH];
- char passwdbuff[PASSWDBUFFLEN];
+ char *passwdbuff;
+ int passwdlen;
int keylength;
int i;
pass = xgetpass(pfd, _(Password: ));
- strncpy(passwdbuff+1,pass,PASSWDBUFFLEN-1);
- passwdbuff[PASSWDBUFFLEN-1] = '\0';
+ passwdlen = strlen(pass);
+ passwdbuff = malloc(passwdlen+2);
+ strcpy(passwdbuff+1,pass);
passwdbuff[0] = 'A';
- rmd160_hash_buffer(keybits,pass,strlen(pass));
-
rmd160_hash_buffer(keybits+HASHLENGTH,passwdbuff,strlen(pass)+1);
+ rmd160_hash_buffer(keybits,pass,passwdlen);
+ rmd160_hash_buffer(keybits+HASHLENGTH,passwdbuff,passwdlen+1);
+ memset(pass, 0, passwdlen);
+ free(passwdbuff);
memcpy((char*)loopinfo64.lo_encrypt_key,keybits,2*HASHLENGTH);
keylength=0;
for(i=0; crypt_type_tbl[i].id != -1; i++){
@@ -423,15 +426,18 @@
default:
if (hash_password) {
char keybits[2*HASHLENGTH];
- char passwdbuff[PASSWDBUFFLEN];
+ char *passwdbuff;
+ int passwdlen;
pass = xgetpass(pfd, _(Password: ));
- strncpy(passwdbuff+1,pass,PASSWDBUFFLEN-1);
- passwdbuff[PASSWDBUFFLEN-1] = '\0';
+ passwdlen = strlen(pass);
+ passwdbuff = malloc(passwdlen+2);
+ strcpy(passwdbuff+1,pass);
passwdbuff[0] = 'A';
- rmd160_hash_buffer(keybits,pass,strlen(pass));
-
rmd160_hash_buffer(keybits+HASHLENGTH,passwdbuff,strlen(pass)+1);
- memset(pass, 0, strlen(pass));
+ rmd160_hash_buffer(keybits,pass,passwdlen);
+
rmd160_hash_buffer(keybits+HASHLENGTH,passwdbuff,passwdlen+1);
+ memset(pass, 0, passwdlen);
+ free(passwdbuff);
memcpy((char*)loopinfo64.lo_encrypt_key,keybits,keysz/8);
loopinfo64.lo_encrypt_key_size = keysz/8;
} else {
-- System Information:
Debian Release: 3.1
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.10-1-k7
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8)
Versions of packages mount depends on:
ii libblkid1 1.37-1 block device id library
ii libc6 2.3.2.ds1-21 GNU C Library: Shared libraries an
ii libuuid11.37-1 universally unique id library
-- no debconf information
--
YAEGASHI Takeshi [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#315660: mount: Wrong hash generation for the loopback device.
Hi, In the article [EMAIL PROTECTED], Max Vozeler [EMAIL PROTECTED] wrote: Hi YAEGASHI, On Fri, Jun 24, 2005 at 09:49:59PM +0900, YAEGASHI Takeshi wrote: --- util-linux-2.12p.orig/mount/lomount.c 2005-06-24 20:39:36.073263112 +0900 +++ util-linux-2.12p/mount/lomount.c2005-06-24 21:12:33.783174438 +0900 (...) + strcpy(passwdbuff+1,pass); passwdbuff[0] = 'A'; - rmd160_hash_buffer(keybits,pass,strlen(pass)); - rmd160_hash_buffer(keybits+HASHLENGTH,passwdbuff,strlen(pass)+1); + rmd160_hash_buffer(keybits,pass,passwdlen); + rmd160_hash_buffer(keybits+HASHLENGTH,passwdbuff,passwdlen+1); + memset(pass, 0, passwdlen); + free(passwdbuff); This looks like it leaves the passphrase as free'd memory on the heap. Maybe add a memset before freeing the buffer? Yes, that would be the best practice. We should clear passwdbuff also. However, such careful attention will be in vain unless it's thorough throughout the whole source code. I feel there're still some doubtful portions in lomount.c... Thanks, -- YAEGASHI Takeshi [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
