Re: [Bug-wget] wget alpha release 1.14.96-38327
On Tue, Jan 07, 2014 at 09:54:46PM +0530, Darshit Shah wrote: Anything still blocking the release? 12 month release cycle sounds good to me. I'm trying to replicate the aforementioned issues, but no luck still. wget still saves filenames in a buggy way: $ echo $LC_CTYPE en_US.UTF8 $ wget -r -np http://jinix.sourceforge.net/go/sgf/01.诘棋总动员/育苗工程手筋300题/index.html ... Total wall clock time: 42s Downloaded: 301 files, 106K in 0.2s (427 KB/s) $ ls jinix.sourceforge.net/go/sgf/01.诘棋总动员 ls: cannot access jinix.sourceforge.net/go/sgf/01.诘棋总动员: No such file or directory $ ls jinix.sourceforge.net/go/sgf 01.??%98??%8B?%80??%8A??%91%98 The filename here is strange and messy. It cannot be typed on this system: it is UTF-8 but in the middle of the UTF-8 characters some bytes have been escaped as if they were high ISO-8859-1 bytes. The result is valid in no character set. The only thing one can do is % rm -r jinix.sourceforge.net % wget --restrict-file-names=nocontrol ... throwing away this default wget output, finding the option wget needs to do the right thing, and starting all over again. $ ls jinix.sourceforge.net/go/sgf/01.诘棋总动员 育苗工程手筋300题 Now it works. Andries
Re: [Bug-wget] wget alpha release 1.14.96-38327
Hello, Am Dienstag, den 24.12.2013, 18:06 +0100 schrieb Giuseppe Scrivano: I could drop 3 documentation patches. The Debian bugtracker does not have additional patches. I don't track which wget upstream patch fixed which Debian bug if this is your request. would you mind to send the patches to the ML, either by git send-email or attaching the output git format-patch? It helps to get more eyes on them. Get these patches upstream will make things easier for you as well, you will have less stuff to rebase when a new version is out. Sure, but the 3 additional patches are included in 1.14.96-38327. wget release 1.14 in Debian is carrying the following patches: http://patch-tracker.debian.org/package/wget/1.14-5 and the 1.14.96-38327 reduces them by 3: http://patch-tracker.debian.org/package/wget/1.14.96.38327-2 They are only documentation patches. I hope I didn't misunderstand your request again. Maybe only a small documentation fix but its minor. https://savannah.gnu.org/bugs/index.php?33826 As a friend of release early and release often: Go for it;) and the wget user will get a lot of fixes from the 16 month of development. we definitely need a better model than let's release when we think it is ok :-) Should we move to a release every 3/6 months? 12 month would be fine too but I don't have a strong option on this. I don't think that doing it more often would make any sense, given the activity that usually wget has. ACK. -- Noël Köthe noel debian.org Debian GNU/Linux, www.debian.org signature.asc Description: This is a digitally signed message part
Re: [Bug-wget] wget alpha release 1.14.96-38327
Darshit Shah dar...@gmail.com writes: @Giuseppe: It's upto you to decide if #709637 should be a blocking bug. The logs do seem to show an error on Wget's part, but I haven't had a chance to create an isolated test case for it yet. With all the headers available, it shouldn't be too great an issue. Given that there is a workaround for it and that it is so difficult to reproduce, I wouldn't consider it as a blocking issue. I'll try to reproduce it on my machine now. Giuseppe
Re: [Bug-wget] wget alpha release 1.14.96-38327
Noël Köthe n...@debian.org writes: I could drop 3 documentation patches. The Debian bugtracker does not have additional patches. I don't track which wget upstream patch fixed which Debian bug if this is your request. would you mind to send the patches to the ML, either by git send-email or attaching the output git format-patch? It helps to get more eyes on them. Get these patches upstream will make things easier for you as well, you will have less stuff to rebase when a new version is out. If anything needs fixing, I'd like to help and ensure a new release ASAP. Maybe going through https://savannah.gnu.org/bugs/?group=wget in some spare time and comment, tag, close some bugs.:) e.g. bug #36580 just need a person with the right savannah account/permissions (nok does not have;)). I've delayed it since there were some new bug reports and I had no time to go trough all of them. From a first check, it seems there is nothing blocking a release, so I will probably do that in the next few days. Is there something we should absolutely consider for inclusion before we make a new release? Maybe only a small documentation fix but its minor. https://savannah.gnu.org/bugs/index.php?33826 As a friend of release early and release often: Go for it;) and the wget user will get a lot of fixes from the 16 month of development. we definitely need a better model than let's release when we think it is ok :-) Should we move to a release every 3/6 months? I don't think that doing it more often would make any sense, given the activity that usually wget has. Cheers, Giuseppe
Re: [Bug-wget] wget alpha release 1.14.96-38327
On Tue, Dec 24, 2013 at 10:36 PM, Giuseppe Scrivano gscriv...@gnu.orgwrote: Noël Köthe n...@debian.org writes: I could drop 3 documentation patches. The Debian bugtracker does not have additional patches. I don't track which wget upstream patch fixed which Debian bug if this is your request. would you mind to send the patches to the ML, either by git send-email or attaching the output git format-patch? It helps to get more eyes on them. Get these patches upstream will make things easier for you as well, you will have less stuff to rebase when a new version is out. I tried going through the Debian bugtracker just now. Didn't see any patches available which haven't already been applied. However there are a couple of bug reports on it that we must look into. I'll try and reproduce them if possible. Specifically, I'm looking at bug reports #701032 and #709637. @nok: It would be very nice of you if you could report these as bugs in the upstream bug tracker. I know they're both marked as non-reproducible in your system. While I'll attempt to reproduce #701032, there seems to be a definite bug in wget based on the extensive logs provided in #709637. @Giuseppe: It's upto you to decide if #709637 should be a blocking bug. The logs do seem to show an error on Wget's part, but I haven't had a chance to create an isolated test case for it yet. With all the headers available, it shouldn't be too great an issue. If anything needs fixing, I'd like to help and ensure a new release ASAP. Maybe going through https://savannah.gnu.org/bugs/?group=wget in some spare time and comment, tag, close some bugs.:) e.g. bug #36580 just need a person with the right savannah account/permissions (nok does not have;)). I don't have editing permissions on Savannah either. Giuseppe would have to do that. I've delayed it since there were some new bug reports and I had no time to go trough all of them. From a first check, it seems there is nothing blocking a release, so I will probably do that in the next few days. Is there something we should absolutely consider for inclusion before we make a new release? Maybe only a small documentation fix but its minor. https://savannah.gnu.org/bugs/index.php?33826 It's a documentation change that does look good. As a friend of release early and release often: Go for it;) and the wget user will get a lot of fixes from the 16 month of development. we definitely need a better model than let's release when we think it is ok :-) +1 Should we move to a release every 3/6 months? I don't think that doing it more often would make any sense, given the activity that usually wget has. I think we should have a 6 month release cycle. With 5 months open for submission of new features / patches, while the last month is only a alpha/beta testing phase. -- Thanking You, Darshit Shah
Re: [Bug-wget] wget alpha release 1.14.96-38327
Hello, Am Sonntag, den 22.12.2013, 13:21 +0100 schrieb Giuseppe Scrivano: @Noel: Could you please elaborate on the patches that fixes bugs in your bugtracker? Building this pre 1.15 wget with gnutls 3.2 fixes alot of https problems. In detail you can see the the fixed Debian bug list here: http://ftp-master.metadata.debian.org/changelogs/main/w/wget/experimental_changelog I could drop 3 documentation patches. The Debian bugtracker does not have additional patches. I don't track which wget upstream patch fixed which Debian bug if this is your request. If anything needs fixing, I'd like to help and ensure a new release ASAP. Maybe going through https://savannah.gnu.org/bugs/?group=wget in some spare time and comment, tag, close some bugs.:) e.g. bug #36580 just need a person with the right savannah account/permissions (nok does not have;)). I've delayed it since there were some new bug reports and I had no time to go trough all of them. From a first check, it seems there is nothing blocking a release, so I will probably do that in the next few days. Is there something we should absolutely consider for inclusion before we make a new release? Maybe only a small documentation fix but its minor. https://savannah.gnu.org/bugs/index.php?33826 As a friend of release early and release often: Go for it;) and the wget user will get a lot of fixes from the 16 month of development. Thanks for your work! Regards Noel -- Noël Köthe n...@debian.org Debian GNU/Linux, www.debian.org signature.asc Description: This is a digitally signed message part
Re: [Bug-wget] wget alpha release 1.14.96-38327
@Noel: Could you please elaborate on the patches that fixes bugs in your bugtracker? @Giuseppe: Do we have any blocking bugs that need fixing? If not, would it be possible to make a release before the end of the year? If anything needs fixing, I'd like to help and ensure a new release ASAP. On Thu, Nov 21, 2013 at 5:14 AM, Ray Satiro raysat...@yahoo.com wrote: hi , SSL autodetection (am I correct that is supposed to be the default?) doesn't seem to be working here in mingw, it tells me: configure: error: --with-ssl=gnutls was given, but GNUTLS is not available. I don't have GNUTLS so I expect it would use openssl. When I explicitly use --with-ssl=openssl that works. pthread lib detected but not included: checking for pthread.h... yes checking for pthread_kill in -lpthread... yes checking for multithread API to use... posix later: gcc -O2 -Wall -o wget.exe cmpt.o connect.o convert.o cookies.o ftp.o css_.o c ss-url.o ftp-basic.o ftp-ls.o hash.o host.o html-parse.o html-url.o http.o init. o log.o main.o netrc.o progress.o ptimer.o recur.o res.o retr.o spider.o url.o w arc.o utils.o exits.o build_info.o version.o ftp-opie.o mswindows.o openssl.o h ttp-ntlm.o ../lib/libgnu.a -liconv -lintl -leay32 -lz -lws2_32 -lssl32 ../lib/libgnu.a(regex.o):regex.c:(.text+0xa4f1): undefined reference to `__imp__ pthread_mutex_init' ../lib/libgnu.a(regex.o):regex.c:(.text+0xa92e): undefined reference to `__imp__ pthread_mutex_destroy' ../lib/libgnu.a(regex.o):regex.c:(.text+0xb146): undefined reference to `__imp__ pthread_mutex_lock' ../lib/libgnu.a(regex.o):regex.c:(.text+0xb214): undefined reference to `__imp__ pthread_mutex_unlock' ../lib/libgnu.a(regex.o):regex.c:(.text+0xb6fe): undefined reference to `__imp__ pthread_mutex_destroy' ../lib/libgnu.a(regex.o):regex.c:(.text+0xb78a): undefined reference to `__imp__ pthread_mutex_lock' ../lib/libgnu.a(regex.o):regex.c:(.text+0xb7d3): undefined reference to `__imp__ pthread_mutex_unlock' When I add -lpthread to LIBS that works. When wget is compiled using current versions of MinGW there is a problem because it will link to functions that do not exist in earlier versions of the crt, = Vista usually. I brought that up on their mailing list earlier this month, http://sourceforge.net/mailarchive/forum.php?thread_name=52796A9F.20905%40users.sourceforge.netforum_name=mingw-users No fix yet but a workaround would be to ignore ftelli64 and fseeki64 in crt. What is the version scheme? The last alpha build I have from earlier this year before 1.14.96-38327 is 1.14.128-something Excuse the weird formatting and lack of quoting I can't find a way to do some things in the new Yahoo mail. Thanks On Saturday, November 2, 2013 8:33 AM, Giuseppe Scrivano gscriv...@gnu.org wrote: Hi, I have just uploaded an alpha release for wget. If no blocking errors are found, then I will make an official release in the coming weeks (that is, wget 1.15). Please test it! :-) http://alpha.gnu.org/gnu/wget/wget-1.14.96-38327.tar.gz http://alpha.gnu.org/gnu/wget/wget-1.14.96-38327.tar.xz signatures, using key C03363F4: http://alpha.gnu.org/gnu/wget/wget-1.14.96-38327.tar.gz.sig http://alpha.gnu.org/gnu/wget/wget-1.14.96-38327.tar.xz.sig Thanks, Giuseppe -- Thanking You, Darshit Shah
Re: [Bug-wget] wget alpha release 1.14.96-38327
Darshit Shah dar...@gmail.com writes: @Noel: Could you please elaborate on the patches that fixes bugs in your bugtracker? @Giuseppe: Do we have any blocking bugs that need fixing? If not, would it be possible to make a release before the end of the year? If anything needs fixing, I'd like to help and ensure a new release ASAP. I've delayed it since there were some new bug reports and I had no time to go trough all of them. From a first check, it seems there is nothing blocking a release, so I will probably do that in the next few days. Is there something we should absolutely consider for inclusion before we make a new release? Giuseppe
Re: [Bug-wget] wget alpha release 1.14.96-38327
I can't think of any bug/feature request that we absolutely need to address in the next release. There is the new patch for adding a --start-pos command, but I would prefer to test it out first, before adding it as part of a new release. If anyone has any ideas / suggestions, lets please discuss them ASAP. On Sun, Dec 22, 2013 at 5:51 PM, Giuseppe Scrivano gscriv...@gnu.orgwrote: Darshit Shah dar...@gmail.com writes: @Noel: Could you please elaborate on the patches that fixes bugs in your bugtracker? @Giuseppe: Do we have any blocking bugs that need fixing? If not, would it be possible to make a release before the end of the year? If anything needs fixing, I'd like to help and ensure a new release ASAP. I've delayed it since there were some new bug reports and I had no time to go trough all of them. From a first check, it seems there is nothing blocking a release, so I will probably do that in the next few days. Is there something we should absolutely consider for inclusion before we make a new release? Giuseppe -- Thanking You, Darshit Shah
Re: [Bug-wget] wget alpha release 1.14.96-38327
Darshit Shah dar...@gmail.com writes: I can't think of any bug/feature request that we absolutely need to address in the next release. There is the new patch for adding a --start-pos command, but I would prefer to test it out first, before adding it as part of a new release. yes, it is too late to take a new feature that still has to be properly discussed. Giuseppe
Re: [Bug-wget] wget alpha release 1.14.96-38327
Hello, Am Samstag, den 02.11.2013, 13:32 +0100 schrieb Giuseppe Scrivano: I have just uploaded an alpha release for wget. If no blocking errors are found, then I will make an official release in the coming weeks (that is, wget 1.15). I uploaded this alpha to our experimental tree and it builds and works so far fine. https://buildd.debian.org/status/package.php?p=wgetsuite=experimental (to see details click in the Status row) I could removed 4 patches and it fixes 8 bugs in the Debian bugtracker. Maybe a low hanging fruit might be:) https://savannah.gnu.org/bugs/index.php?33826 -- Noël Köthe noel debian.org Debian GNU/Linux, www.debian.org signature.asc Description: This is a digitally signed message part
Re: [Bug-wget] wget alpha release 1.14.96-38327
Darshit Shah dar...@gmail.com writes: Simply need to add those to the EXTRA_DIST variable in Makefile.am. I've attached a patch for this. Thanks for your patch. I am going to push it. Giuseppe
Re: [Bug-wget] wget alpha release 1.14.96-38327
Simply need to add those to the EXTRA_DIST variable in Makefile.am. I've attached a patch for this. On Sun, Nov 3, 2013 at 9:21 PM, Andrea Urbani matfan...@mail.com wrote: Hi Giuseppe, the following files are missing: tests/Test-ftp-list-Multinet.px tests/Test-ftp-list-Unknown.px tests/Test-ftp-list-Unknown-a.px tests/Test-ftp-list-Unknown-hidden.px tests/Test-ftp-list-Unknown-list-a-fails.px tests/Test-ftp-list-UNIX-hidden.px Please, include them (you find them also attached here) Bye Andrea - Original Message - From: Giuseppe Scrivano Sent: 11/02/13 01:32 PM To: bug-wget@gnu.org Subject: [Bug-wget] wget alpha release 1.14.96-38327 Hi, I have just uploaded an alpha release for wget. If no blocking errors are found, then I will make an official release in the coming weeks (that is, wget 1.15). Please test it! :-) http://alpha.gnu.org/gnu/wget/wget-1.14.96-38327.tar.gz http://alpha.gnu.org/gnu/wget/wget-1.14.96-38327.tar.xz signatures, using key C03363F4: http://alpha.gnu.org/gnu/wget/wget-1.14.96-38327.tar.gz.sig http://alpha.gnu.org/gnu/wget/wget-1.14.96-38327.tar.xz.sig Thanks, Giuseppe -- Thanking You, Darshit Shah From febe1547001dc60e32177437ee9dfb25f4957962 Mon Sep 17 00:00:00 2001 From: Darshit Shah dar...@gmail.com Date: Mon, 4 Nov 2013 06:15:17 +0530 Subject: [PATCH] Add tests to EXTRA_DIST variable for distribution packaging --- tests/ChangeLog | 6 ++ tests/Makefile.am | 6 ++ 2 files changed, 12 insertions(+) diff --git a/tests/ChangeLog b/tests/ChangeLog index e1ef334..c8dc09d 100644 --- a/tests/ChangeLog +++ b/tests/ChangeLog @@ -1,3 +1,9 @@ +2013-11-04 Darshit Shah dar...@gmail.com + + * Makefile.am: Add new tests introduced in last commit to + EXTRA_DIST. + Reported by: Andrea Urbani matfan...@mail.com + 2013-10-17 Andrea Urbani matfan...@mail.com * FTPServer.pm (GetBehavior): new routine. diff --git a/tests/Makefile.am b/tests/Makefile.am index a494787..bea262e 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -82,6 +82,12 @@ EXTRA_DIST = FTPServer.pm FTPTest.pm HTTPServer.pm HTTPTest.pm \ Test-ftp-iri-fallback.px \ Test-ftp-iri-recursive.px \ Test-ftp-iri-disabled.px \ + Test-ftp-list-Multinet.px \ + Test-ftp-list-Unknown.px \ + Test-ftp-list-Unknown-a.px \ + Test-ftp-list-Unknown-hidden.px \ + Test-ftp-list-Unknown-list-a-fails.px \ + Test-ftp-list-UNIX-hidden.px \ Test-HTTP-Content-Disposition-1.px \ Test-HTTP-Content-Disposition-2.px \ Test-HTTP-Content-Disposition.px \ -- 1.8.4.2
