cracklib-devel Mailing List for CrackLib
Brought to you by:
nneul
You can subscribe to this list here.
2005 |
Jan
|
Feb
(4) |
Mar
(22) |
Apr
(6) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(10) |
Oct
(6) |
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2006 |
Jan
|
Feb
|
Mar
(5) |
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
(5) |
Sep
|
Oct
|
Nov
|
Dec
(2) |
2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(10) |
Nov
|
Dec
|
2008 |
Jan
(9) |
Feb
(6) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(3) |
Oct
(5) |
Nov
|
Dec
|
2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(9) |
Nov
(3) |
Dec
|
2010 |
Jan
|
Feb
(3) |
Mar
(5) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(4) |
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
(1) |
Dec
|
2014 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
2015 |
Jan
|
Feb
|
Mar
|
Apr
(4) |
May
(1) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
2023 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Conservative N. S. <dai...@gm...> - 2023-03-21 13:18:34
|
Blank OFFICIAL TRB GOLD TOKEN -THE KEY TO SUCCESS-YOU CAN COUNT ON PRESIDENT TRUMP READ MORE ORDER 10, 20, 50 OR 125 TOKENS AND GET FREE BONUSES! WHAT ARE YOU WAITING FOR?READ MORE |
From: Living H. <dai...@gm...> - 2023-03-07 11:47:23
|
Blank Unlock Your Body's Ability to Eliminate Urine with This Nutrient Don't Be Part of the Statistics! 1of 3 Men are Lacking on This Essential Nutrient Scientists reveal an astonishing prostate enlargement discovery: Without this crucial prostate nutrient, your bodycannot eliminate urine completely. Shop Now Left untreated, this could lead to Acute Urinary Retention -when a person cannot urinate at all. This can cause sudden kidney failure, which is a very seriouspotential cause of death. Are you lacking the crucial prostate nutrient? Visit the link below to find out all about it: Shop Now |
From: xnob <li...@ro...> - 2021-11-25 17:32:34
|
From: <kol...@sy...> - 2016-09-30 16:33:20
|
Hello I am new to this project and I have a special request to all of you, who have contributed to this project. I am a researcher in the field of social science. My research interest is the developer community of free / open source projects in order to improve community building. I would like to learn something about your experiences in developing software within f/os-projects. If you are willing to participate, please contact me for more informations. Thanks Klasu |
From: Nathan N. <nn...@ne...> - 2015-08-18 19:36:08
|
New repository location: https://github.com/cracklib/cracklib Any distro maintainers, please update packaging to grab the tarball from the github releases URL. https://github.com/cracklib/cracklib/releases/tag/cracklib-2.9.6 -- Nathan ------------------------------------------------------------ Nathan Neulinger nn...@ne... Neulinger Consulting (573) 612-1412 |
From: Mark S. <ms...@is...> - 2015-05-15 06:11:41
|
I've just found and fixed a very long-standing bug in cracklib. Patches attached. EFFECTS: The standard distribution is allowing some passwords which are in the dictionary. Other distributions, such as the one that ships with Russ Allbery's krb5-strength-3.0, will end up disallowing many passwords that should be allowed, because it handles the case in FindPW() where GetPW() returns NULL differently. CAUSE: Cracklib zeroes in on the right entry in the dictionary using strcmp(), which assumes that the input is sorted in order. However, the dictionary is normally sorted with sort(1). Modern sort(1) is localized, and the default is usually UTF-8. In order to get it to output the results that strcmp() is expecting, sort(1) needs to be run in the C locale. DETECTION: To determine whether you're being bitten by this, try sorting your word list the way you do today before passing it into packer, then set LC_ALL=C and sort again. Compare the results. If there are any differences at all, you've got a problem. HISTORY: It appears that in the past this bug has caused crashes, and code was introduced in r12 (February 2005, for version 2.7 I believe) to debug and avoid these crashes, but it seems nobody got to the root cause. In the current distribution, see lines 571-576 in lib/packlib.c -- those are clearly designed to address a situation which should never arise. https://sourceforge.net/p/cracklib/code/HEAD/tree/trunk/cracklib/lib/packlib.c#l571 See also all the brute-force diagnostics wrapped with #if DEBUG to inspect the LWM and HWM. When the dictionary is out of order, sometimes the HWM will end up below the LWM, and it looks like someone had determined that this was happening and worked around it to avoid a crash, but never figured out why. That fix is incomplete. It addresses the crash and helps when the sort order problem is with the first character of two adjacent passwords, but doesn't help when the problem is anywhere other than the first character. As a result, it will sometimes fail to find a password that it should find, because it's looking in the wrong part of the dictionary. PATCHES: I've attached two patches. The first simply adds "export LC_ALL=C" to the util/cracklib-format script, which ensures that sort(1) will output in the correct order. (One might argue that the locale should only be set for the sort command, not for the entire script. I'll leave it to others to determine whether that matters.) The second adds a warning to util/packer.c so this can be detected as early as possible -- when building the dictionary. It only generates a warning because I didn't want to leave a half-built dictionary, but I could see doing more to raise the alarm. Mark -- Mark Sirota, Associate Director, Identity and Access Management University of Pennsylvania, Information Systems and Computing ms...@up..., +1 215 573 7214 |
From: Jan D. <ja...@di...> - 2015-04-12 20:38:47
|
On Sun, Apr 12, 2015 at 12:37:31PM +0300, Unik wrote: > В Вс, 12/04/2015 в 07:59 +0200, Jan Dittberner пишет: > > > I just missed the PyPI upload. I'll upload a new cracklib package to PyPI > > this evening or tomorrow. > > > > Thanks! I just uploaded cracklib 2.9.3 to PyPI, the binary eggs are build for Python 2.7 and Python 3.4. Other Python versions would require build environments that I don't have available currently. Best regards Jan Dittberner -- Jan Dittberner - Debian Developer GPG-key: 4096R/558FB8DD 2009-05-10 B2FF 1D95 CE8F 7A22 DF4C F09B A73E 0055 558F B8DD https://jan.dittberner.info/ |
From: Unik <un...@co...> - 2015-04-12 09:37:40
|
В Вс, 12/04/2015 в 07:59 +0200, Jan Dittberner пишет: > I just missed the PyPI upload. I'll upload a new cracklib package to PyPI > this evening or tomorrow. > Thanks! > Btw. there are Python 3 compatible Debian packages in Debian Jessie/Sid :-) > > I know. But my trouble is with virtualenv deployments without access to system "site-packages" dir (i.e. all modules straight from PyPI). > Best regards > Jan Dittberner > Once again, thank you. -- WBR, Unik |
From: Jan D. <ja...@di...> - 2015-04-12 06:19:43
|
On Sun, Apr 12, 2015 at 01:47:50AM +0300, Unik wrote: > Hello. > > What's the status of cracklib package on PyPI? I'm talking about this: > > https://pypi.python.org/pypi/cracklib > > It is currently 2.8.19, which doesn't work on python >= 3.2, and makes > deployment via virtualenv really cumbersome. I just missed the PyPI upload. I'll upload a new cracklib package to PyPI this evening or tomorrow. Btw. there are Python 3 compatible Debian packages in Debian Jessie/Sid :-) Best regards Jan Dittberner -- Jan Dittberner - Debian Developer GPG-key: 4096R/558FB8DD 2009-05-10 B2FF 1D95 CE8F 7A22 DF4C F09B A73E 0055 558F B8DD https://jan.dittberner.info/ |
From: Unik <un...@co...> - 2015-04-11 23:06:43
|
Hello. What's the status of cracklib package on PyPI? I'm talking about this: https://pypi.python.org/pypi/cracklib It is currently 2.8.19, which doesn't work on python >= 3.2, and makes deployment via virtualenv really cumbersome. I can lend a hand if needed. -- With best regards, Alex Unigovsky mailto:un...@co... Systems Administrator Maksim Co. Ltd. work: +7 495 981-0313 cell: +7 926 619-8997 23 Barishikha st. 125368 Moscow Russian Federation |
From: Jan D. <ja...@di...> - 2014-09-25 17:11:09
|
On Wed, Sep 24, 2014 at 10:43:15AM -0700, Pascal Muetschard wrote: > Hi cracklib-devel, > > I've found and fixed a bug in cracklib.py's string distance > calculation. See patch below: Hi Pascal, I just applied your patch to our SVN repository. Thanks Jan -- Jan Dittberner - Debian Developer GPG-key: 4096R/558FB8DD 2009-05-10 B2FF 1D95 CE8F 7A22 DF4C F09B A73E 0055 558F B8DD http://www.dittberner.info/ |
From: Pascal M. <pmu...@go...> - 2014-09-24 17:43:42
|
Hi cracklib-devel, I've found and fixed a bug in cracklib.py's string distance calculation. See patch below: Index: cracklib/python/cracklib.py =================================================================== --- cracklib/python/cracklib.py (revision 229) +++ cracklib/python/cracklib.py (working copy) @@ -58,7 +58,7 @@ else: cval = old[i - 1] - if j == 0 or len(new) <= i: + if j == 0 or len(new) <= j: dval = 0 else: dval = new[j - 1] -- Pascal Muetschard <pmu...@go...> |
From: Jan D. <ja...@di...> - 2014-02-04 20:34:43
|
On Tue, Feb 04, 2014 at 05:23:07PM +0000, Steve1 Chesney wrote: > I wish to build the cracklib-devel libraries from source on AIX. I have > found and built cracklib-2.9.0 from a tar.gz file but can't find > cracklib-devel source anywhere, just an RPM, which is not convenient, my > project requires me to compile everything. Can anybody give me a clue? I'm > probably being stupid and missing something obvious. Hello, the tar.gz file contains all the sources and headers to build whatever binary package you want. How to build something like -devel is operating system / distribution dependent. I maintain the Debian package for cracklib and use the Debian tools to build the binary packages. Maybe this [1] can give you some idea on how to do this. I'm sure there are similar things for other distributions (i.e. RPM spec files for RedHat or SuSE like systems). I don't know whether there is something similar available for AIX. [1] http://anonscm.debian.org/gitweb/?p=pkg-cracklib/pkg-cracklib.git Best regards, Jan Dittberner -- Jan Dittberner - Debian Developer GPG-key: 4096R/558FB8DD 2009-05-10 B2FF 1D95 CE8F 7A22 DF4C F09B A73E 0055 558F B8DD http://www.dittberner.info/ |
From: Steve1 C. <ste...@uk...> - 2014-02-04 17:23:30
|
Hi I wish to build the cracklib-devel libraries from source on AIX. I have found and built cracklib-2.9.0 from a tar.gz file but can't find cracklib-devel source anywhere, just an RPM, which is not convenient, my project requires me to compile everything. Can anybody give me a clue? I'm probably being stupid and missing something obvious. Best regards Steve Chesney SST Group, IBM CLS Project +44(0)2392 560542 ste...@uk... Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU |
From: Hubert K. <hk...@re...> - 2013-11-13 16:03:15
|
Anyone? I want do perform thorough testing of cracklib, but for that I need to know what is the expected behaviour. Now I see complex passwords rejected and simple passwords accepted. Am I doing something wrong or could this be a bug in cracklib? Regards, Hubert ----- Original Message ----- > From: "Hubert Kario" <hk...@re...> > To: cra...@li... > Cc: "Tomas Mraz" <tm...@re...> > Sent: Tuesday, 10 September, 2013 6:51:01 PM > Subject: [Cracklib-devel] Security baseline for cracklib (when passwords should be accepted or rejected?) > > Hi all! > > I've done some integration testing with cracklib and discovered > that the passwords are rejected or accepted quite arbitrarily. > At least I don't see any pattern in it. > > For example, using English word list, password "1winning1" will > be accepted as secure, but passwords ".):winning,!\" or > "*~[winning#>;" will be rejected as insecure. > > The word "winning" has about 10 bits of guessing entropy[1,2,3], > so the above passwords have at most 16 (more realistically 12), > 40 and 40 bits of guessing entropy respectively. That's a very > large gap between false positive (IMO) and false negative. > > What was the security level to be achieved? What is the > acceptable error from this baseline? > > NIST SP 800-63-1 allows for password based authentication with > passwords that have 14 or 20 bits of entropy (for systems > needing Level 1 or Level 2 security respectively). While making > it possible to check if a password has more entropy than that > would be nice, I think those two values would be a good starting > point. So, I think that adding a configuration file that allows > to set the desirable entropy of passwords would be a good new > feature. Adding a new API that allows the programmer to specify > the minimal amount of guessing entropy the password needs to > have would be a good addition to that. > > 1: NIST SP 800-63-1, section A.2.2 > 2: "Testing Metrics for Password Creation Policies by Attacking > Large Sets of Revealed Passwords" by Weir et al. (2010) > 3: "The science of guessing: analyzing an anonymized corpus of 70 > million passwords" by Joseph Bonneau > > -- > Regards, > Hubert Kario > Quality Engineer, QE BaseOS Security team > http://wiki.brq.redhat.com/hkario > Email: hk...@re... > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic > > ------------------------------------------------------------------------------ > How ServiceNow helps IT people transform IT departments: > 1. Consolidate legacy IT systems to a single system of record for IT > 2. Standardize and globalize service processes across IT > 3. Implement zero-touch automation to replace manual, redundant tasks > http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk > _______________________________________________ > cracklib-devel mailing list > cra...@li... > https://lists.sourceforge.net/lists/listinfo/cracklib-devel > -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team http://wiki.brq.redhat.com/hkario Email: hk...@re... Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic |
From: Hubert K. <hk...@re...> - 2013-09-10 16:51:08
|
Hi all! I've done some integration testing with cracklib and discovered that the passwords are rejected or accepted quite arbitrarily. At least I don't see any pattern in it. For example, using English word list, password "1winning1" will be accepted as secure, but passwords ".):winning,!\" or "*~[winning#>;" will be rejected as insecure. The word "winning" has about 10 bits of guessing entropy[1,2,3], so the above passwords have at most 16 (more realistically 12), 40 and 40 bits of guessing entropy respectively. That's a very large gap between false positive (IMO) and false negative. What was the security level to be achieved? What is the acceptable error from this baseline? NIST SP 800-63-1 allows for password based authentication with passwords that have 14 or 20 bits of entropy (for systems needing Level 1 or Level 2 security respectively). While making it possible to check if a password has more entropy than that would be nice, I think those two values would be a good starting point. So, I think that adding a configuration file that allows to set the desirable entropy of passwords would be a good new feature. Adding a new API that allows the programmer to specify the minimal amount of guessing entropy the password needs to have would be a good addition to that. 1: NIST SP 800-63-1, section A.2.2 2: "Testing Metrics for Password Creation Policies by Attacking Large Sets of Revealed Passwords" by Weir et al. (2010) 3: "The science of guessing: analyzing an anonymized corpus of 70 million passwords" by Joseph Bonneau -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team http://wiki.brq.redhat.com/hkario Email: hk...@re... Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic |
From: Mike F. <va...@ge...> - 2013-06-20 23:34:41
|
On Saturday 01 June 2013 22:02:40 Mike Frysinger wrote: > right union member. another idea (which also sucks, but maybe less so) is > to change the pointer type to void* (see below). i committed this -mike |
From: Jan D. <ja...@di...> - 2013-06-03 05:03:01
|
On Sat, Jun 01, 2013 at 10:02:40PM -0400, Mike Frysinger wrote: > the cracklib packer does things like: > #ifdef HAVE_ZLIB_H > if (pdesc.flags & PFOR_USEZLIB) > gzclose(pdesc.dfp); > else > #endif > fclose(pdesc.dfp); > > where dfp and such are FILE* pointers. with newer zlib, we see warnings like: > > packlib.c: In function 'PWOpen': > packlib.c:128:4: warning: passing argument 1 of 'gzclose' from incompatible > pointer type [enabled by default] > In file included from packlib.c:11:0: > /usr/include/zlib.h:1511:12: note: expected 'gzFile' but argument is of type > 'struct FILE *' > packlib.c:165:4: warning: passing argument 1 of 'gzclose' from incompatible > pointer type [enabled by default] > > this is because gzopen/gzclose use gzFile rather than FILE* > > one way to fix this would be to add (void*) casts to all zlib related funcs, > but that sucks. we could change these to unions like so: > typedef struct > { > union { > FILE *fp; > gzFile *gfp; > } dfp; > but that sucks because we'd have to update all the call points to use the > right union member. another idea (which also sucks, but maybe less so) is to > change the pointer type to void* (see below). > > thoughts ? all three of these ideas should not impact the ABI. I aggree with you that the third variant proposed (using a void* pointer) looks as it sucks the least. The second variant would more clearly express the intent of the pointer but I am not sure whether it is worth the trouble to change all FILE* pointers to the union type (I counted 90 appearances of FILE pointer uses throughout the cracklib2 codebase). Best regards Jan -- Jan Dittberner - Debian Developer GPG-key: 4096R/558FB8DD 2009-05-10 B2FF 1D95 CE8F 7A22 DF4C F09B A73E 0055 558F B8DD http://www.dittberner.info/ |
From: Mike F. <va...@ge...> - 2013-06-02 02:20:16
|
the cracklib packer does things like: #ifdef HAVE_ZLIB_H if (pdesc.flags & PFOR_USEZLIB) gzclose(pdesc.dfp); else #endif fclose(pdesc.dfp); where dfp and such are FILE* pointers. with newer zlib, we see warnings like: packlib.c: In function 'PWOpen': packlib.c:128:4: warning: passing argument 1 of 'gzclose' from incompatible pointer type [enabled by default] In file included from packlib.c:11:0: /usr/include/zlib.h:1511:12: note: expected 'gzFile' but argument is of type 'struct FILE *' packlib.c:165:4: warning: passing argument 1 of 'gzclose' from incompatible pointer type [enabled by default] this is because gzopen/gzclose use gzFile rather than FILE* one way to fix this would be to add (void*) casts to all zlib related funcs, but that sucks. we could change these to unions like so: typedef struct { union { FILE *fp; gzFile *gfp; } dfp; but that sucks because we'd have to update all the call points to use the right union member. another idea (which also sucks, but maybe less so) is to change the pointer type to void* (see below). thoughts ? all three of these ideas should not impact the ABI. --- lib/packer.h (revision 219) +++ lib/packer.h (working copy) @@ -52,9 +52,9 @@ struct pi_header typedef struct { - FILE *ifp; - FILE *dfp; - FILE *wfp; + void *ifp; + void *dfp; + void *wfp; uint32_t flags; #define PFOR_WRITE 0x0001 --- lib/packlib.c (revision 219) +++ lib/packlib.c (working copy) @@ -34,9 +34,9 @@ struct pi_header64 typedef struct { - FILE *ifp; - FILE *dfp; - FILE *wfp; + void *ifp; + void *dfp; + void *wfp; uint64_t flags; uint64_t hwms[256]; struct pi_header64 header; @@ -72,9 +72,9 @@ PWOpen(prefix, mode) char iname[STRINGSIZE]; char dname[STRINGSIZE]; char wname[STRINGSIZE]; - FILE *dfp; - FILE *ifp; - FILE *wfp; + void *dfp; + void *ifp; + void *wfp; if (pdesc.header.pih_magic == PIH_MAGIC) { -mike |
From: Nathan N. <nn...@ne...> - 2013-06-01 15:32:44
|
Backwards compatible, but adds new function to library. ----------------------- Added FascistCheckUser() to check arbitrary users cracklib did checks always against the currently logged in user, which effectively disables this functionality for use cases like web frontends testing the password strength. Patch adds a new FascistCheckUser() function which allows to specify an arbitrary username and gecos information. Rest of the public cracklib API stays unmodified. Patch does not use K&R syntax for new functions because they disable some diagnostic in gcc. Signed-off-by: Enrico Scholz enr...@in... ------------------------ -- ------------------------------------------------------------ Nathan Neulinger nn...@ne... Neulinger Consulting (573) 612-1412 |
From: Mike F. <va...@ge...> - 2012-05-18 18:45:15
|
Requires one less place to hardcode the version. Signed-off-by: Mike Frysinger <va...@ge...> --- cracklib/README-RELEASE | 12 ++++++++---- 1 files changed, 8 insertions(+), 4 deletions(-) diff --git a/cracklib/README-RELEASE b/cracklib/README-RELEASE index 5c894d2..6c26c3e 100644 --- a/cracklib/README-RELEASE +++ b/cracklib/README-RELEASE @@ -1,13 +1,17 @@ configure make dist +ver=$(head -1 NEWS) +ver=${ver#v} +echo "creating ${ver} release" + sftp nneul,cra...@fr... <<EOM cd /home/pfs/project/c/cr/cracklib/cracklib/ -mkdir 2.8.20 -cd 2.8.20 -mput cracklib-2.8.20.tar.gz +mkdir ${ver} +cd ${ver} +mput cracklib-${ver}.tar.gz exit EOM -svn copy -m "tag at 2.8.20" https://cracklib.svn.sourceforge.net/svnroot/cracklib/trunk/cracklib https://cracklib.svn.sourceforge.net/svnroot/cracklib/tags/cracklib-2.8.20 +svn copy -m "tag at ${ver}" https://cracklib.svn.sourceforge.net/svnroot/cracklib/trunk/cracklib https://cracklib.svn.sourceforge.net/svnroot/cracklib/tags/cracklib-${ver} -- 1.7.8.6 |
From: Nathan N. <nn...@ne...> - 2012-05-18 16:29:46
|
Added. 2.8.19 has been tagged, released, and added to the files area. -- Nathan On 05/18/2012 09:40 AM, Jan Dittberner wrote: > Hi Nathan, > > I ported the cracklib Python binding to Python3 and added a unit test > suite (already committed to svn). It is now possible to use cracklib > from both Python2 and Python3 using the same codebase. > > Would you please tag, build and upload a new cracklib release > (2.8.19) tarball? > > > Best regards > Jan > -- ------------------------------------------------------------ Nathan Neulinger nn...@ne... Neulinger Consulting (573) 612-1412 |
From: Jan D. <ja...@di...> - 2010-09-30 17:56:09
|
On Wed, Sep 29, 2010 at 06:28:49PM -0400, Mike Frysinger wrote: > since none of the other autotool packages keep their generated files in svn > (Makefile.in, configure, config.sub, etc...), is there a reason for keeping > the gettext files in there ? > > i propose we punt all of them, add `autopoint` to autogen.sh, and fix > configure.in so that `autoreconf` works: Thanks for your suggestion. I like the idea of removing the generated i18n and other files. Autogenerating them is way nicer from my distribution packager's point of view too. If there are no objections I'd like to have these changes in SVN and will commit them tomorrow. Regards Jan Dittberner > > --- a/cracklib/configure.in > +++ b/cracklib/configure.in > @@ -48,7 +48,7 @@ AC_CHECK_FUNCS(strdup) > AC_CHECK_FUNCS(getpwuid_r) > > dnl internationalization macros > -AM_GNU_GETTEXT_VERSION > +AM_GNU_GETTEXT_VERSION([0.17]) > AM_GNU_GETTEXT([external]) > > dnl Control default dictname > > files to punt: > m4/* > ABOUT-NLS > config.rpath > mkinstalldirs > po/ChangeLog > po/Makefile* > -mike -- Jan Dittberner - Debian Developer GPG-key: 4096R/558FB8DD 2009-05-10 B2FF 1D95 CE8F 7A22 DF4C F09B A73E 0055 558F B8DD http://www.dittberner.info/ |
From: Mike F. <va...@ge...> - 2010-09-29 22:45:13
|
since none of the other autotool packages keep their generated files in svn (Makefile.in, configure, config.sub, etc...), is there a reason for keeping the gettext files in there ? i propose we punt all of them, add `autopoint` to autogen.sh, and fix configure.in so that `autoreconf` works: --- a/cracklib/configure.in +++ b/cracklib/configure.in @@ -48,7 +48,7 @@ AC_CHECK_FUNCS(strdup) AC_CHECK_FUNCS(getpwuid_r) dnl internationalization macros -AM_GNU_GETTEXT_VERSION +AM_GNU_GETTEXT_VERSION([0.17]) AM_GNU_GETTEXT([external]) dnl Control default dictname files to punt: m4/* ABOUT-NLS config.rpath mkinstalldirs po/ChangeLog po/Makefile* -mike |
From: Mike F. <va...@ge...> - 2010-03-05 18:34:40
|
On Friday 05 March 2010 12:36:37 Neulinger, Nathan wrote: > Not that I'm aware of - I build the distro tarball on an i386 FC12 > system. rpm -q says python 2.6.2. yeah, so i'd use the sed hack ... perhaps stick it into autogen.sh -mike |