Re: Bug#453680: ITP: djbdns -- Replacement for BIND, written by Dan Bernstein
On 11/30/2007 11:51 AM, Milan P. Stanic wrote: > Are you sure that the complete package is in the public domain? > Some files are, but not all of them, AFAIK. There has been some additional discussion on this topic in BTS, as well as some other places. http://bugs.debian.org/453680 http://linux.slashdot.org/article.pl?sid=07/11/30/0430201 http://video.google.com/videoplay?docid=-3147768955127254412 -- Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFH: How to debug FTBFS of erlang on sparc (UltraSPARC III)?
On 01/08/2008 09:51 AM, Sergei Golovan wrote: Which kernel version do you have installed? But anyway, if the build is successful then this machine is useless for me :) It is an Etch scratch box running 2.6.18-5-sparc64. You could certainly upgrade/install anything on the box you would like to try to recreate the problem - it's all just 1's and 0's ;) -- Kind Regards, Michael Shuler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFH: How to debug FTBFS of erlang on sparc (UltraSPARC III)?
On 01/07/2008 04:29 PM, Sergei Golovan wrote: I can't build it on UltraSPARC III because I don't have an access to it. Have you gotten access to a machine, Sergei? If not, let me know, I would be happy to give you a login. I successfully (slowly) built erlang_11.b.5dfsg-12 last night with pbuilder on my SunFire V120. -- Kind Regards, Michael Shuler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Xen - Source?
On 06/09/2009 11:49 AM, Andreas wrote: > Installing it (make), it downloads the binary of the hypervisor! > "Cloning http://xenbits.xensource.com/linux-2.6.18-xen.hg " # > (downloading) This is an incorrect understanding of that download step - it is a *source* download from the upstream mercurial repository: mshu...@aineko:~/src/repos/hg$ hg clone http://xenbits.xensource.com/linux-2.6.18-xen.hg destination directory: linux-2.6.18-xen.hg requesting all changes adding changesets adding manifests adding file changes added 899 changesets with 23501 changes to 20928 files updating working directory 20905 files updated, 0 files merged, 0 files removed, 0 files unresolved mshu...@aineko:~/src/repos/hg$ > So where do I find the source of the xen-Hypervisor? Right where you found it ;) You can also download tarballs from the parent web site, if you wish. -- Kind Regards, Michael -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Xen - Source?
On 06/09/2009 02:59 PM, David Claughton wrote: > Michael Shuler wrote: >> On 06/09/2009 11:49 AM, Andreas wrote: >>> Installing it (make), it downloads the binary of the hypervisor! >>> "Cloning http://xenbits.xensource.com/linux-2.6.18-xen.hg " # >>> (downloading) >> This is an incorrect understanding of that download step - it is a >> *source* download from the upstream mercurial repository: > > Are you saying the source package does not actually contain the source > code, but is just a framework for downloading the actual source? > > If so, this seems unusual to me. AIUI it's normal practice for a source > package to contain a local copy of the source tree because Debian cannot > make the assumption that xenbits.xensource.com will always be there. You're right. Ben pointed to the xen patch directory in the linux-2.6 source package in his reply - the package build should not fetch the repo. I just spoke up (probably incorrectly, without asking for more info) to help with what I thought he was seeing. Kind Regards, Michael -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Modified http://wiki.debian.org/DebianDeveloper to mention non-packagers (Re: [CTTE #614907] Resolution of node/nodejs conflict)
On 07/26/2012 08:37 AM, The Fungi wrote: > On 2012-07-26 14:29:14 +0100 (+0100), Ian Jackson wrote: > [...] >> We also need a general word for "someone involved with Debian in a >> positive way". "Participant" is clumsy; "member of the community" >> even more so. "Person" might do but word with a more positive spin >> would be nice. > > As a long-time participant and non-DD, I've always liked the term > "contributor" in that context. Although it is likely to not stay this way forever, this is exactly how I describe my participation - Debian Contributor -- Kind regards, Michael -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/501149b5.3020...@pbandjelly.org
Bug#538761: ITP: libnet-mosso-cloudfiles-perl -- Perl interface to Mosso CloudFiles service
Package: wnpp Severity: wishlist Owner: Michael Shuler * Package name: libnet-mosso-cloudfiles-perl Version : 0.43 Upstream Author : Léon Brocard * URL : http://search.cpan.org/dist/Net-Mosso-CloudFiles/ * License : Perl (Artistic and GPL) Programming Lang: Perl Description : Perl interface to Mosso CloudFiles service Net::Mosso::CloudFiles provides a simple interface to the Mosso Cloud Files service. "Cloud Files is reliable, scalable and affordable web-based storage for backing up and archiving all your static content". Find out more at <http://www.mosso.com/cloudfiles.jsp>. To use this module you will need to sign up to Mosso Cloud Files and provide a "user" and "key". If you use this module, you will incurr costs as specified by Mosso. Please check the costs. If you use this module with your user and key you will be responsible for these costs. (This module will be maintained under the Debian Perl Group) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#543118: ITP: python-cloudfiles -- Python interface to Rackspace CloudFiles service
Package: wnpp Severity: wishlist Owner: Michael Shuler Package name: python-cloudfiles Version : 1.4.0 Upstream Author : Cloud Files URL : http://github.com/rackspace/python-cloudfiles/ License : MIT Programming Lang: Python Description : Python interface to Rackspace Cloud Files service python-cloudfiles provides a simple interface to the Rackspace Cloud Files service. "Cloud Files is reliable, scalable and affordable web-based storage for backing up and archiving all your static content". Find out more at <http://www.rackspacecloud.com/cloud_hosting_products/files>. To use this module you will need to sign up to Rackspace Cloud Files and provide a "user" and "key". If you use this module, you will incurr costs as specified by Rackspace. Please check the costs. If you use this module with your user and key you will be responsible for these costs. (This module will be maintained under the Debian Python Modules Team) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [Bug-wget] certificate revocation lists (CRLs) #43501
On 11/05/2014 06:51 AM, Noël Köthe wrote: Hello Debian,;) wget developers are working on CRL support and raised the following questions which somebody of you guys have a better answer: Am Mittwoch, den 05.11.2014, 12:48 +0100 schrieb Tim Ruehsen: BTW, does Debian meanwhile has a CRL infrastructure (something like /etc/ssl/certs/) or is planning something like it ? I'm aware of fetch-crl https://packages.debian.org/unstable/main/fetch-crl but maybe there is more anything planed like CRL support for the ca-certificates package? Patches welcomed! :) -- Kind regards Michael -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/545a5108.1070...@pbandjelly.org
Re: Bug#685038: ITP: mailscanner -- email gateway for virus scanning, spam and phishing detection
On 08/15/2012 07:35 PM, Aaron Schrab wrote: > Package: wnpp > Severity: wishlist > Owner: Aaron Schrab > > * Package name: mailscanner You may wish to contact the previous mailscanner maintainer [0][1] and dig through all the existing/archived bugs [2] to find out why it was removed from the archive post-squeeze, and if it may be suitable for debian in the future. [0] http://packages.debian.org/search?keywords=mailscanner [1] http://packages.qa.debian.org/m/mailscanner.html [2] http://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=both;src=mailscanner -- Kind regards, Michael Shuler -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/502cfdd0.8040...@pbandjelly.org
Re: Unreleased libraries
On 02/07/2014 10:25 AM, Pau Garcia i Quiles wrote: Is there a policy on how to package software that does not make releases? A version similar to skia_0.0-1~svnr1234 would allow an upstream version of i.e. 0.1 (if they ever release) to supersede your packaged version. It should also allow you to upgrade via new svn version (0.0-1~svnr1235), as well as new packaging of same svn version (0.0-2~svnr1234). Please, correct me, if there is a better method, here! -- Kind regards, Michael -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52f50cd4.90...@pbandjelly.org
Re: Unreleased libraries
On 02/08/2014 05:55 AM, Andreas Beckmann wrote: On 2014-02-08 10:01, Tzafrir Cohen wrote: On Fri, Feb 07, 2014 at 10:41:56AM -0600, Michael Shuler wrote: On 02/07/2014 10:25 AM, Pau Garcia i Quiles wrote: Is there a policy on how to package software that does not make releases? A version similar to skia_0.0-1~svnr1234 would allow an upstream version of i.e. 0.1 (if they ever release) to supersede your packaged version. It should also allow you to upgrade via new svn version (0.0-1~svnr1235), as well as new packaging of same svn version (0.0-2~svnr1234). Please, correct me, if there is a better >>> method, here! Please do not abuse the Debian revision for including upstream version information! Indeed, I was incorrect - thanks for the clarification. One other thing to keep in mind: what if they switch to git? If you expect this, start with 0~~svn12345-1 and switch to 0~git$whatever-1 later on. I think your detailed reply [0] was most helpful. Using a dated version would probably be the best method, in my opinion - anything after that is easily overridden. Epochs should be an avenue of last resort. [0] http://lists.debian.org/52f50f53.3090...@debian.org -- Michael -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52f648f2.6030...@pbandjelly.org
Re: ca-certificates: no more cacert.org certificates?!?
On 04/02/2014 04:43 AM, Bas van den Dikkenberg wrote: The only things states in RDL that user has to be informed about the copyright I find this, perhaps, the most interesting and on-topic comment in this thread. -- Kind regards, Michael -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/533c81d5.3060...@pbandjelly.org
Re: How is the stable version of Chrome tracked for chromium-browser?
On 07/06/2011 08:52 PM, Aaron Toponce wrote: > I would like to mimic the build process of the chromium-browser as closely > as possible on a development system, but I am unaware of the process that > the Debian Chromium Package Maintainers use. I'm not as interested as > building the .deb, as I am grabbing the right upstream source that matches > the latest stable release of Chrome. > > Any help? You might wish to ask the package team: Debian Chromium Maintainers and dig around the Alioth project's bzr repo: https://alioth.debian.org/projects/pkg-chromium/ -- Kind regards, Michael -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e151868.6040...@pbandjelly.org
Re: Looking for seconds to add the Amazon EC2 public certificate in ca-certificates.
On 08/22/2011 10:56 PM, Russ Allbery wrote: > Charles Plessy writes: > >> as per /usr/share/doc/ca-certificates/README.Debian, I am looking for >> additional signed recommendations for the addition of the Amazon Elastic >> Computer Cloud (EC2) public certificate to the ca-certificates packages. > > As someone not particularly familiar with the details of how certs work > inside EC2, my main question would be: what's the signing policy used by > the holder of the private key for this certificate? This is also my question - is this a CA that will be verifying and signing other certs? (I'll try to dig on the same info, as well) For the record, I intend to adopt ca-certificates relatively soon, as I have not heard back from the previous ITA poster in a few weeks. The package needs some TLC and I have some updates already queued up, but not pushed to my git repo, yet :-) -- Kind regards, Michael signature.asc Description: OpenPGP digital signature
Re: debian/copyright, DEP5 and SPDX
On 12/13/2011 09:17 AM, Simon Josefsson wrote: > Possibly DEP5-compliant files could be generated from SPDX files. This has come up in several DEP5 discussions over the past ~year, as well as several recent mentions: https://www.google.com/search?q=spdx+site%3Alists.debian.org -- Kind regards, Michael -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ee77f75.9090...@pbandjelly.org
Re: Planning the removal of c_rehash | mass bug filling
On 04/05/2018 05:22 PM, Sebastian Andrzej Siewior wrote: > Hi, > > the openssl package provides the c_rehash script which creates the links > from .Y to the actual certificate in /etc/ssl/certs/. During the > transition from 0.9.8 to 1.0.0 the hash (for the X part) changed from > md5 to sha1. Since that transition in Debian the c_rehash script > provides both symlinks: the old hash (md5) and the new (sha1) one. > > The c_rehash script is considered by upstream as a fallback script and > will disappear at some point. The recommended way is to use the "openssl > rehash" command instead which appeared in 1.1.0. This command creates > half that many symlinks (one per certificate instead of two) because it > uses only the sha1 hash. There is also the -compat option which creates > both symlinks (and behaves like c_rehash currently does) but as > explained above it should not be required to use it. > > I am planning to fill bugs against 23 packages which use "c_rehash" to > use "openssl rehash" instead. Here is the dd-list of packages I > identified: <...> > Michael Shuler >ca-certificates Thanks for the heads up! If you could go ahead and file this bug for ca-certificates, I'd like to include the bug number in the changelog for this commit on the next upload, which should be soon. https://salsa.debian.org/debian/ca-certificates/commit/1bc87e0b41a04551a93d4e784e158b044c18792a -- Kind regards, Michael
Re: Planning the removal of c_rehash | mass bug filling
On 04/09/2018 03:21 PM, Sebastian Andrzej Siewior wrote: > On 2018-04-06 10:05:35 [-0500], Michael Shuler wrote: >> If you could go ahead and file this bug for ca-certificates, I'd like to >> include the bug number in the changelog for this commit on the next >> upload, which should be soon. >> >> https://salsa.debian.org/debian/ca-certificates/commit/1bc87e0b41a04551a93d4e784e158b044c18792a > > out of sheer curiosity: do you intend to keep this -compat mode (old & > new symlinks) or is it just a carefull first step to ensure that nothing > breaks while the tool for the job is changed? It was purely a conservative duplication of existing symlinks. I can drop the old md5 symlinks, if there's a consensus that they are no longer needed in unstable. I could also include -compat for both symlinks, if this needs to go in a stable update, just to be sure we're not making a breaking change for users in Stretch. -- Kind regards, Michael
Re: Planning the removal of c_rehash | mass bug filling
On 04/09/2018 05:34 PM, Sebastian Andrzej Siewior wrote: > On 2018-04-09 15:55:14 [-0500], Michael Shuler wrote: >> It was purely a conservative duplication of existing symlinks. I can >> drop the old md5 symlinks, if there's a consensus that they are no >> longer needed in unstable. > > Based on my research I think you can drop the old links since they were > only required until everything was rebuilt and the symlinks were > re-created during the 0.9.8 -> 1.0.0 transition. We are past that point > now. > >> I could also include -compat for both >> symlinks, if this needs to go in a stable update, just to be sure we're >> not making a breaking change for users in Stretch. > > There is no need to push this stable. There is nothing wrong with it as > far as I can tell. > Upstream considers that script as legacy (and it not part of the > testsuite) and I just wanted to make sure that we are ready to drop that > script once upstream decides to remove it. Also not to be part of any > further fallout. Thanks for the help, Sebastian. I've dropped the -compat flag for the next upload to unstable and won't worry about this for stable. -- Kind regards, Michael
Re: Pimp your shell - Debian developer tips?
On 6/3/20 7:30 PM, Gunnar Wolf wrote:
Like Paul said in his reply, I also have a "bash monstrosity" as a
Bash prompt.
For many years, I have taken a different approach; use the default and
add only a few minor changes. Each stable update, I use
/etc/skel/.bashrc and edit/add in my little bits.
Other than uncommenting a few existing color & alias configs in the
default file, I configure history to allow .bash_history grep from any
open shell session, and keep a lot more:
# save every command, as opposed to only at the end of the session
export PROMPT_COMMAND='history -a'
# for setting history length see HISTSIZE and HISTFILESIZE in bash(1)
HISTSIZE=2
HISTFILESIZE=4
# Useful to know where we stand while using different version control systems
parse_git_branch() {
# Yes, temporary, dirty, yada yada yada. Works for me™.
# --exclude-standard does not exist on git <= 1.5
git_opts='--exclude-standard'
branch=`git branch 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/\1/'`
if [ ! -z "$branch" ]
then
clean=`git status --porcelain`
if [ ! -z "$clean" ]
then
branch="${branch}*"
new=`git ls-files -o $git_opts|wc -l`
del=`git ls-files -d $git_opts|wc -l`
mod=$(( `git ls-files -m $git_opts|wc -l` - $del ))
if [ $mod != 0 ]; then branch="${branch}${mod}M"; fi
if [ $new != 0 ]; then branch="${branch}${new}N"; fi
if [ $del != 0 ]; then branch="${branch}${del}D"; fi
fi
fi
echo $branch
}
Gunnar's git branch foo is what really lead me to post my default
.bashrc change strategy. I also depend on knowing branch name and repo
status state and use this PS1 config:
# adapted from
http://people.planetpostgresql.org/dfetter/index.php?/archives/53-Git-+-bash-win.html
#
https://web.archive.org/web/2016101348/http://www.bramschoenmakers.nl/en/node/624
if [ -f /usr/bin/git ]; then
export GIT_PS1_SHOWDIRTYSTATE=1
PSGIT='\[\033[01;31m\]$(__git_ps1 "(%s)")\[\033[00m\]'
PS1="$PSGIT$PS1"
fi
--
Kind regards,
Michael
Re: xz backdoor
On 4/5/24 10:30, Pierre-Elliott Bécue wrote: Pierre-Elliott Bécue wrote on 31/03/2024 at 14:31:37+0200: Wookey wrote on 31/03/2024 at 04:34:00+0200: On 2024-03-30 20:52 +0100, Ansgar 🙀 wrote: Yubikeys, Nitrokeys, GNUK, OpenPGP smartcards and similar devices. Possibly also TPM modules in computers. These can usually be used for both OpenPGP and SSH keys. Slightly off-topic, but a couple of recent posts have given me the same thought: Can someone point to good docs on this? I've had a yubikey for 3/4 of a year now but have not yet worked out how I put my GPG key in it. (or if it should be another key, or a subkey, or whatever). So I'm not actually using it yet. PEB also described what sounded like a very sensible way to manage keys (using subkeys) in one of these threads but I don't know how to do that myself. I have started (and never finished) a blog article on how I use my YubiKey and what config I put in it. I'll definitely try to get it out before the end of next week. I'll probably extend it to mention the creation of GPG subkeys etc. I would also be happy if it helps my fellow DDs to try making an article about some basic crypto concepts regarding PGP, RSA et al. But not in the same piece I guess. Hello, For those interested in: I've published two articles: 1. One on PGP subkeys https://pe.becue.phd/openpgp-subkeys 2. One on the OpenPGP module of YubiKeys: https://pe.becue.phd/yubikey-workfow-openpgp I'm happy to receive any kind of constructive feedback. Thank you so much for working on these. I last-minute cobbled together a BOF on GPG Key Best Practices at Columbia in 2010, since the topic came up in another talk. I was blown away at how much I did not know, the complexity, as well as how many people crammed in that room - definitely there are interested people (I think Wookey was there, too?). I include myself in each of the things others mentioned, that I should have been doing since then, but just never got around to.. At least I now have a fist full of Yubikeys to play with, as we use them at work, so thanks for your work. I appreciate it, and I'm guessing there's a rather large, quiet group of people thinking the same. Kind regards, Michael
