Bug#910654: We're still discussing this question
reopen 910654 thanks There is still discussion within the cloud team on how to handle this feature. Reopening this bug to reflect that. We can close again if we decide not to change the current situation. - Jimmy Kaplowitz ji...@debian.org
Bug#878945: Request from cloud team: please add a debconf option for PasswordAuthentication
Hi Colin, On Wed, Oct 18, 2017 at 08:17:49AM +0100, Colin Watson wrote: > On Tue, Oct 17, 2017 at 02:50:24PM -0700, Jimmy Kaplowitz wrote: > > Hello from the Debian cloud team sprint at Microsoft! We were just > > discussing the appropriate default value for the PasswordAuthentication > > option in sshd_config in Debian's cloud images. Most of these currently > > set it to 'no' by modifying the config file; we'd like a debconf option > > for this to be added, so that we make the change that way and offer a better > > user experience across package upgrades. > > Thanks for the suggestion. Does this patch look OK? It seems to do the > job in my local testing. Your reply was impressively fast, and mine was depressingly slow! I apologize for the latter. We reviewed it during the sprint and marveled at your quick response time, but I failed to send a follow-up email. The patch looks great. The description would make more sense to me without the "(for internal use)" caveat, but I'm not going to bikeshed over such a detail. Once this is applied to unstable and migrates to testing, we can update our image build scripts to use this debconf option in lieu of a manual sed command on buster, or alternatively, in general except for the one or two older releases (stretch and maybe jessie) we still care about. I note when reviewing our build scripts that we also add a ClientAliveInterval line (not using sed), as befits a cloud environment where a network-level firewall will drop connections after extended periods of inactivity. Would you like me to file a separate wishlist bug for a debconf option for that value, or do you think it should stay a manual modification? Thanks! - Jimmy Kaplowitz ji...@debian.org
Bug#878945: Request from cloud team: please add a debconf option for PasswordAuthentication
Package: openssh-server Version: 1:7.6p1-2 Severity: wishlist Hello from the Debian cloud team sprint at Microsoft! We were just discussing the appropriate default value for the PasswordAuthentication option in sshd_config in Debian's cloud images. Most of these currently set it to 'no' by modifying the config file; we'd like a debconf option for this to be added, so that we make the change that way and offer a better user experience across package upgrades. Justification for the different default on most clouds: While defaulting this to 'yes' makes sense in Debian's general case, most of the major public clouds center their best practices around SSH keys and support this with tooling and infratructure. Additionally, public cloud VM instances are frequently targeted by attackers testing passwords, who will of course not have any authorized SSH keys. Although this meets the Debian BTS's definition of wishlist severity, we on the cloud team view this as a reasonably important change by those standards, so that we stay secure without manually modifying sshd_config. Thanks for your consideration. -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.13.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages openssh-server depends on: ii adduser 3.116 ii debconf 1.5.63 ii dpkg 1.18.24 ii init-system-helpers 1.50 ii libaudit11:2.8-1 ii libc62.24-17 ii libcomerr2 1.43.6-1 ii libgssapi-krb5-2 1.15.1-2 ii libkrb5-31.15.1-2 ii libpam-modules 1.1.8-3.6 ii libpam-runtime 1.1.8-3.6 ii libpam0g 1.1.8-3.6 ii libselinux1 2.7-2 ii libssl1.0.2 1.0.2l-2 ii libsystemd0 235-2 ii libwrap0 7.6.q-26 ii lsb-base 9.20170808 ii openssh-client 1:7.6p1-2 ii openssh-sftp-server 1:7.6p1-2 ii procps 2:3.3.12-3 ii ucf 3.0036 ii zlib1g 1:1.2.8.dfsg-5 Versions of packages openssh-server recommends: ii libpam-systemd 235-2 ii ncurses-term6.0+20170902-1 ii xauth 1:1.0.9-1+b2 Versions of packages openssh-server suggests: ii ksshaskpass [ssh-askpass] 4:5.10.5-2 pn molly-guard pn monkeysphere pn rssh pn ufw -- debconf information excluded
Bug#773462: Second data point confirming the described issue
Hi, I experienced this issue as well, in the final jessie release. Same version 0.9.3.4-2 of plasma-nm that was in the original bug report, but network-manager is 0.9.10.0-7 rather than 0.9.10.0-3. Running jessie and jessie-updates on amd64 (with i386 known to dpkg). The mentioned workaround of setting the password in the Connection editor settings window succeeds for me, even though it was failing for the original submitter on December 18 after previously working. The difference in network-manager version numbers probably explain this. As in the original report, I have KDE configured not to use kwallet. Version sanity check: I've confirmed with apt-show-versions that all packages on my system match the up-to-date versions from jessie or jessie-updates, with a very few clearly irrelevant exceptions (e.g. google-chrome and a 3.18 kernel from pre-jessie Debian experimental). - Jimmy Kaplowitz ji...@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#772898: win32-loader testing and newer fails with TRANSLATE error
Package: win32-loader Version: 0.7.5 Hi, I just got a new laptop preinstalled with Windows 7 Pro, and naturally wanted to install Debian via win32-loader. I tried several times, with the testing and unstable versions of win32-loader, and picking either stable or daily d-i. Here is one of the paths I tried with both the testing and unstable versions, and the resulting error: 1. Launch win32-loader and approve Windows's UAC prompt. 2. Choose Expert mode 3. Choose KDE. 4. Choose daily d-i. 5. Deal with the check for known issues prompt somehow, I tried both yes and no. 6. Confirm keyboard layout (mine was us). 7. Proceed with install, not specifying any proxy server or other changes. I got this error: Error: http://d-i.debian.org/daily-images/amd64/daily//MD5SUMS/TRANSLATE; When I tried with stable win32-loader, this worked (and will shortly remove my ability to test until I get virtualized Windows in place). - Jimmy Kaplowitz ji...@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#762148: Fix intel_pstate kernel panic in wheezy, already done upstream
Package: linux-image-3.2.0-4-amd64 Version: 3.2.60-1+deb7u3 Severity: normal Tags: patch Hi kernel folks, The intel_pstate driver in wheezy fails to calculate its timer timeout correctly, which can cause the driver to race with itself. Google's kernel engineers identified this as the cause for an occasional kernel panic which our test infrastructure picked up. The fix is one-line and was accepted upstream in April of last year. Could you please apply the one-line fix to the next wheezy stable update? While we've only encountered this infrequently, this is the kind of patch that can only help things. kernel.org git commit ID: ec376a2ab97ec3be52ca282dc6ac102e805d1005 Link to the diff in kernel.org: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/cpufreq/intel_pstate.c?id=ec376a2ab97ec3be52ca282dc6ac102e805d1005 Thanks! - Jimmy
Bug#673652: Intent to adopt
owner 673652 ji...@debian.org owner 673654 ji...@debian.org owner 673655 ji...@debian.org retitle 673652 ITA: pwauth -- authenticator for mod_authnz_external and the Apache HTTP Daemon retitle 673654 ITA: libapache2-mod-authz-unixgroup -- access control based on on unix group membership for Apache retitle 673655 ITA: libapache2-mod-authnz-external -- authenticate Apache against external authentication services thanks I'm planning to adopt these soon. They aren't in horrible shape as is, and I am involved with a system that uses two of them right now. The post-wheezy transition to Apache 2.4 should be fine since upstream has already done it. - Jimmy Kaplowitz ji...@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#604391: Apper status for Debian?
Hi Matthias, As a Debian developer and KDE user who wants to convert his parents' laptop away from Windows, I found your ITP while investigating the current state of KDE package managers on Debian. You've already done packaging work for Apper in (K)Ubuntu, and in fact it seems to have released in oneiric universe, which is great. Thank you for doing this! However your Debian ITP was filed almost a year ago and the last update to this bug in the Debian BTS was in August. What are your plans for adapting your packaging to Debian? If you need a sponsor for the first few uploads and until you're a DM, I'm happy to review your work, and I'm sure that many other DDs would be too. You seem to already be the maintainer of most PackageKit packages in Debian and applied for DM status two months ago, so I imagine you are familiar enough with Debian Policy and the like. If I do collaborate with you on this, I will make sure to involve the Debian QT/KDE team so that we can pay attention to their policies and practices as well, where relevant. If you have decided that you don't want to maintain Apper in Debian proper, I can take over the ITP, but I'll defer to you first. It would be quite helpful to have a working and reasonably bug-free package manager for KDE in Wheezy, which is currently targeted for freeze in June 2012 and then for release as soon it is sufficiently high-quality. Thanks again for your efforts thus far, - Jimmy Kaplowitz ji...@debian.org (I'm Hydroxide on irc.debian.org - feel free to collaborate with me there, but still please do respond to the bug with your plans.) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#641240: closed by Damien Raude-Morvan draz...@debian.org (Bug#641240: fixed in openjdk-6 6b23~pre9-2)
reopen 641240 found 641240 6b23~pre9-2 thanks Hi Damien, I think you may have typed the wrong bug number when closing my bug: On Fri, Sep 23, 2011 at 11:06:12PM +, Debian Bug Tracking System wrote: which was filed against the openjdk-6-jre-lib package: #641240: Incomplete changelog if version is ahead of openjdk-6-jre-headless It has been closed by Damien Raude-Morvan draz...@debian.org. [...] openjdk-6 (6b23~pre9-2) unstable; urgency=low [...] [ Damien Raude-Morvan ] * d/patches/icc_loading_with_symlink.diff: Try to fix loading of ICC profile when jre/lib/cmm is a symlink. (Closes: #641530, #639883, #641240). Even though my bug is also related to symlinks, it's entirely different than the other two bugs you listed as closed, and is unrelated to ICC profiles. It's also still present in the current version; even though the dependencies have been tightened somewhat due to #640476, it's still entirely possible to have version 6b23~pre9-2 of openjdk-6-jre-lib point to an incomplete changelog.Debian.gz if openjdk-6-jre-headless is version 6b23~pre9-1. The new dependencies stil allow this. Either the dependency should require exactly the same package version or the /usr/share/doc subdirectories should not be symlinked to each other. There are probably other gotchas in relation to such a symlink, relating to copyright or README/README.Debian files or similar, but since the real-world use case where this bug was a problem and my RC severity justification were both about an incomplete changelog, I'll restrict the scope of this bug number to that issue. Thanks for your work, - Jimmy Kaplowitz ji...@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#641240: Incomplete changelog if version is behind openjdk-6-jre-headless
Package: openjdk-6-jre-lib Version: 6b23~pre9-1 Severity: serious Justification: wheezy RC policy: The package changelog must be included. -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, The /usr/share/doc/openjdk-6-jre-lib directory is a symbolic link to /usr/share/doc/openjdk-6-jre-headless even though the dependency allows for the two packages to have different versions. This is not merely theoretical or of minor importance. Due to the unsatisfiable version conflict mentioned in #640736 and #641075, aptitude on my system has not yet upgraded openjdk-6-jre-headless to 6b23~pre9-1, even though it has upgraded openjdk-6-jre-lib to 6b23~pre9-1. I do make use of icedtea-netx, so I have not simply uninstalled it to complete the upgrade, and I am hesitant to do so. This became an issue when I was trying to prepare the Eclipse 3.7 packaging for entry into sid, which I am currently working on in collaboration with Niels Thykier. An error arose which I suspect is related in some way to my recent partial OpenJDK upgrade, but I do not have the ~pre9-1 changelog anywhere on my system due to the use of the symlink shortcut, so this has been difficult to debug. Although I found the changelog online, I do not only work on Debian when I have Internet access, and the DFSG-freeness part of the wheezy RC policy rightly insists on the inclusion of the package changelog. The version included in the current OpenJDK packaging does not always correspond to what is installed, which is the reason I have used an RC severity. Thanks in advance, - - Jimmy Kaplowitz ji...@debian.org - -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.0.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages openjdk-6-jre-lib depends on: ii openjdk-6-jre-headless 6b23~pre8-1 openjdk-6-jre-lib recommends no packages. openjdk-6-jre-lib suggests no packages. - -- no debconf information -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCgAGBQJObVTCAAoJEGT+wHBUdj6bBbUQAIDdNOUvqkP1vPCJzJj2zmnH PDvvMj3nl5Wb5QuEWOHO4UCmHjHDu/OonWeO/DGbd1MdmuulPG+Vu7F1hXDpDsgf YdcCotsCDUAW/Wsc1H5Bsg11ikxFJIOUNfTeNtqfhhJHECREI76X0WCy0S3dgom3 QqkXjDQ+xH3o9kttJHdkEsqqb9VK45QZCEj45MG+9rqjv8TBKu/vWQh70LNcylw/ J8LcpS5qUecmeSm/3WqaVDfdyhGV2Ddfw8TZIkDETS5mMx1oabTgN6LjzkwNKbhJ fAlQCMKvZ/PGOlSjAG5S6rc7Pb8AOxG2a51uADsIshvcv4IbPFu3dG1TKy8CAZcX tOqP0XJHfm7u+zSTSjGbUTu5zn9jW4oIFdf73i+ttVYnSObQjL85HEqzeloKlGEy G53hmf9PW4GOiLAUgDtRIa9Qytzmln+rsTq8iSWu2/ZshpjCAWVcQwaMqIAeZKfO eHy2rwV/YOdg1tC/djzA06+0ELn623vCMkdKsw52DWPvJHsEcDk2g6NN9HcONv1+ 1qAhCny89MvAPG403zXH3wb26qK8PIfIX40E9wI7v4pVaRglMI5e0Fbdut/CTN/I qA2WvmFzUE5ytMsUQYYGZG8+5YvNO8f8mk7B/F6l7GG0xOC/Ghk+iLg+1+Af9fe9 SwFR8AaqrxTScVRK/oJq =Q2gw -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#641240: Mistake in bug title
retitle 641240 Incomplete changelog if version is ahead of openjdk-6-jre-headless thanks Hi again, As you probably guessed from the version numbers in the main body of my report, I said behind in my bug title when I meant ahead of. Apologies for the confusion. - Jimmy Kaplowitz ji...@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#594101: tolua:libdevel/source, tolua++:libdevel/source
Package: ftp.debian.org Severity: normal Hi, I'm the tolua maintainer, and my package formerly had multiple binary packages, some of which were library packages and some of which were development ones. Now the sole binary package (libtolua-dev) is correctly in section libdevel and the source package is still in section devel. Please update the source package section to match the binary, or alternatively, change the binary to match the source if devel is more appropriate than libdevel for a package that ships a static-only library plus a binary for use in building packages that use the library. I will update my control file to reflect whichever you decision you make as of my next upload. I'm including tolua++ in this bug report even though it is not my package, since it looks like the maintainer of that based his work on mine and he has the same override mismatch between source and binary. (His binary is libtolua++5.1-dev.) Thanks! - Jimmy Kaplowitz ji...@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#520324: Any news on this? :)
On Sun, Jan 17, 2010 at 02:14:13PM +0100, Alexander Sack wrote: Only blocking issues are that there are some subtrees licensed GPL or LGPL without any version info given; while those need to be GPLv2 or later in order to have a chance to be compatible with Apache 2.0. The GPL and LGPL when specified with no license version restriction explicitly allow the recipient to use any version ever published by the FSF. So this is not a problem. - Jimmy Kaplowitz ji...@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#520324: Any news on this? :)
On Fri, Jan 29, 2010 at 12:00:36AM +0100, Alexander Sack wrote: On Thu, Jan 28, 2010 at 04:40:48PM -0500, Jimmy Kaplowitz wrote: On Sun, Jan 17, 2010 at 02:14:13PM +0100, Alexander Sack wrote: Only blocking issues are that there are some subtrees licensed GPL or LGPL without any version info given; while those need to be GPLv2 or later in order to have a chance to be compatible with Apache 2.0. The GPL and LGPL when specified with no license version restriction explicitly allow the recipient to use any version ever published by the FSF. So this is not a problem. curious ... is that written in the GPL itself? Yes, it's in the (legally binding part of the) text of both the GPL and the LGPL, in the sections regarding revised versions of those licenses. - Jimmy Kaplowitz ji...@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#544581: libtolua-dev: tolua generated code doesn't anymore build for modules (like it did for To/Lua v4)
Hi Eero, On Tue, Sep 01, 2009 at 08:17:50PM +0300, Eero Tamminen wrote: Package: libtolua-dev Version: 5.1b-3 Severity: normal Can you try your test case with the current testing/unstable version 5.1.2-1? This involves a new minor upstream release. Also please be more explicit about the commands you're running. Thanks! Most likely it's either fixed or it's an upstream bug, which I'll certainly forward to the author in that case. - Jimmy Kaplowitz ji...@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#472272: tolua: Reported license isn't DFSG-compliant — but upstream relicensed under MIT/X license
Hi Cyril, On Sun, Mar 23, 2008 at 02:15:08AM +0100, Cyril Brulebois wrote: the license of tolua isn't DFSG-compliant, which caused the REJECT of boswars (which includes a modified copy of tolua++, under the same terms as tolua) — I didn't look into that license too much at that time, since the very same terms were used for a package in main. I took a look at the copyright file you listed, and I don't see what's DFSG-nonfree about the original tolua license. Certainly it doesn't grant permission to use the program, but then again neither does the GPL version 2: Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. (Quote from Section 0.) It goes on to say that the act of running the program is not restricted, but not only does it never grant permission to run the program, such permission would explicitly be outside the scope of the license according to that quote. Copyright law does NOT restrict running programs which you legally obtain, as evidenced e.g. by Section 117 of the US Copyight Act; EULAs that impose usage restrictions are going beyond copyright law and using contract law or the conditional nature of a distribution and modification license to add restrictions which would not otherwise exist. (If they're using a conditional distribution and modification license, then any consequent usage restrictions also don't apply to any end users who neither distribute nor modify the software, given that they've never needed to accept the license.) Can you provide more information on the REJECTion so that I can discuss it with the relevant ftpmaster? I'll certainly update the copyright file when Waldemar releases a new version with the new license, but it's bad if ftpmasters are using an erroneous basis to reject packages. - Jimmy Kaplowitz [EMAIL PROTECTED] P.S. - According to copyright law, permission from the copyright holder is necessary to publicly perform a work, but the DFSG seems to allow the GPLv2 even though it never explicitly grants public performance rights (which are not identical to use rights).
Bug#472272: tolua: Reported license isn't DFSG-compliant — but upstream relicensed under MIT/X license
Hi Cyril, On Sun, Mar 23, 2008 at 03:16:10AM +0100, Cyril Brulebois wrote: Thank you for your input (and I'm certainly no lawyer at all, nor highly experienced in that domain). Here's the relevant quote from Jörg's REJECTED mail (there were other problems as well): I should emphasize that I am not a lawyer either and can't be considered as giving legal advice. That said, I have made sure to become quite well-informed in copyright matters despite being a layman. Next point: ---+++ This code is free software; you can redistribute it and/or modify it. The software provided hereunder is on an as is basis, and the author has no obligation to provide maintenance, support, updates, enhancements, or modifications. ---+++ While we all know they mean the right thing - its still not free. You arent allowed to use it, and in (C) stuff that means you simply arent allowed to use it, as by default everything not granted is just not there... Joerg is approximately right here, but only approximately. Copyright law does requires permission to violate the exclusive rights of the copyright holder, and any permission not granted within that is indeed just not there, but the right to use a legally obtained program is not one of those exclusive rights. In addition to the example I gave in my previous mail of the GPLv2 not granting explicit use rights, I just read the Clarified Artistic License already in such Debian packages as ncftp, and beyond an indirect and non-binding remark of author intention in the preamble it doesn't explicitly grant use rights either. Likewise with the W3C Software Notice and License linked from http://www.debian.org/legal/licenses/ - it lists use as one of the conditions for the license to trigger, but its permission clause also doesn't grant permission to use it. Such permission is not needed. The Software Freedom Law Center's Legal Issues Primer for Free Software Projects does not mention use when they list the exclusive rights governed by copyright, and Wikipedia's Software license article (admittedly less reliable than the other sources I've listed) also asserts that mere end users are allowed to use an open-source program even if they do not accept the license, as long as they don't infringe any of the exclusive copyright rights. I will discuss with Joerg and see if he agrees with the reasoning I've used in this thread. Thanks for raising this issue. - Jimmy Kaplowitz [EMAIL PROTECTED]
Bug#288324: Finally returning to tolua in Debian
tags 288324 + pending thanks (I'm directly emailing everyone who emailed the bug report to make sure they all notice this, as well as Bccing everyone who emailed me privately, so that their email addresses are not exposed for spam purposes.) Hi all, I am extremely sorry that I have neglected this package for several years. The original reason I had packaged this went away, and I don't use it myself. Once enough time had gone by without any action being needed (about 3 years), I had become so disinterested already when the wishlist new-version bug was filed that I let the bug sit until I was too ashamed at my neglect to deal with it any time within the following 3 years. Even though I don't use this package anymore, it is a very low-maintenance package, and I now have both the time and motivation to return to my Debian packaging duties and give this package the minimal attention it needs. Spurred into action by Christoph Berg's recent orphaning of this package, I now have created a package that's fully up-to-date on both upstream and Debian Policy changes, have closed his orphaning wnpp bug, and am about to resume my maintainership by uploading the package to Debian. Rest assured I am now quite determined not to let this problem happen again for tolua or for any package I may maintain in the future. Again, please accept my apologies. The package I am about to upload is the official tolua, which is up to version 5.1 now (using Lua 5.1), not tolua++. Tolua++ could be packaged by someone else if they want, in a separate package. Also, the shared library is going away. Debian advises against having a shared library without upstream coordination, and even though upstream long ago acknowledged the patch I sent him to add a shared library, the versions he has released subsequently do not include a shared library, leaving me to conclude that at least for the time being he does not want a shared library. Thus the only binary package is libtolua-dev, containing a static library, a header file, and the binary tolua program for use at build time. - Jimmy Kaplowitz [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#119689: pam_mail standard message still missing space
found 119689 0.79-2 thanks This bug is definitely not fixed in 0.79-2, and probably wasn't fixed in 0.79-1 (though I haven't verified that). A demonstration session transcript illustrating the problem is included below. - Jimmy Kaplowitz [EMAIL PROTECTED] [EMAIL PROTECTED]:~# dpkg -l libpam-modules Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name VersionDescription +++-==-==- ii libpam-modules 0.79-2 Pluggable Authentication Modules for PAM [EMAIL PROTECTED]:~# grep pam_mail /etc/pam.d/login sessionoptional pam_mail.so standard dir=~Maildir [EMAIL PROTECTED]:~# /bin/login cato.kaplowitz.org login: jim Password: Last login: Sun Oct 2 16:02:49 2005 on pts/9 Linux cato.kaplowitz.org 2.4.27-2-k7 #1 Tue Aug 16 17:30:14 JST 2005 i686 GNU/Linux The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. You have newmail. [EMAIL PROTECTED]:~$ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#330001: gnupg2 upgrade needed for gpg-agent ssh support
Hi, I would like to second the request for GnuPG 1.9.19 in Debian. My reason for wanting it is that newer versions of gpg-agent have the ability to emulate ssh-agent, apparently forwarding gpg keys/subkeys across an ssh connection. This is important to me since I am migrating to an OpenPGP smartcard, yet want to be able to sign and decrypt with my smartcard subkeys on remote machines which do not have the smartcard hooked up to them. Here is some information on this feature: http://lists.gnupg.org/pipermail/gnupg-devel/2005-January/021792.html It was added less than a month after the last upstream change in 1.9.15-6's changelog.gz. I took a look at packaging 1.9.19, and most of the Debianization patch conflicts look like the type of thing that would be easy to resolve with some familiarity with the source tree. I will therefore defer to you as maintainer being more able to easily make the package, but if you are too busy right now, please let me know and I'll make an attempt. - Jimmy Kaplowitz [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#318501: no timezones in aptitude log file
Package: aptitude Version: 0.2.15.9-2 Severity: normal Hi Daniel, There are no timezones in /var/log/aptitude, which is annoying, say, when you travel between Brown University in the US and DebConf5 in Helsinki (to pick an obviously hypothetical example). Here is a two-line excerpt from that file on one of my machines which demonstrates this: Aptitude 0.2.15.9: log report Fri Jul 15 18:50:33 2005 I would suggest using the RFC 2822 timezone syntax, i.e. -0400 for US Eastern Daylight Time or +0300 for Helsinki's Eastern European Summer Time. This avoids ambiguous abbreviations such as EDT (which could refer to a US or Australian timezone). - Jimmy Kaplowitz [EMAIL PROTECTED] -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.4.27-2-k7 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages aptitude depends on: ii apt [libapt-pkg-libc6.3-5-3 0.5.28.6 Advanced front-end for dpkg ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an ii libgcc1 1:3.4.3-13 GCC support library ii libncurses5 5.4-4Shared libraries for terminal hand ii libsigc++-1.2-5c102 1.2.5-4 type-safe Signal Framework for C++ ii libstdc++5 1:3.3.6-5The GNU Standard C++ Library v3 -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
