Thank you for the reply. I will take a look at those bugs. AFAIU "bug #23065: -daystart measures from start of tomorrow - manual incorrect" is not blocking the release. That leaves "bug #45062: Enabling CACHE_IDS causes segfaults" and "bug #30526: No match with a file with modified n days ago in "-mtime"".
Is there anything special I need to do regarding the copyright if I do the work on my own time? Maybe there is a page with the copyright FAQ for the project? Thanks, Ilya On Fri, Jun 19, 2015 at 7:15 AM, James Youngman <j...@gnu.org> wrote: > There are two reelase-blocking bugs preventing 4.5.x being released as > stable: > > https://savannah.gnu.org/bugs/index.php?go_report=Apply&group=findutils&func=browse&set=custom&msort=0&report_id=101&advsrch=0&status_id=1&resolution_id=0&submitted_by=0&assigned_to=0&category_id=0&bug_group_id=0&severity=8&summary=&details=&sumORdet=0&history_search=0&history_field=severity&history_event=modified&history_date_dayfd=19&history_date_monthfd=6&history_date_yearfd=2015&chunksz=50&spamscore=5&boxoptionwanted=1#options > > If someone would like to volunteer to work on these (and make > copyright assignments for any needed code changes), that would be very > helpful. > > However, 4.5.x is different enough to 4.4.x that the success of a > backport for the bugfix you're referring to is uncertain. > > Thanks, > James. > > > On Thu, Jun 18, 2015 at 2:27 AM, Ilya Bobyr <ilya.bo...@gmail.com> wrote: > > Hi everyone, > > > > I am new to this list, so I am sorry if I am asking something that was > > already asked. > > > > I am using find on Ubuntu 15.04 and hit a bug. It is related to -fstype > - > > sometimes nfs or cifs is identified as ext4. > > > > It appears the bug is already fixed in the current development branch > 4.5. > > I think this is the fix: > > > > Take the last matching entry in /etc/mtab, not the first. > > * find/fstype.c (file_system_type_uncached): Instead of taking the > > first match, take the last match. This deals better with mtab > > implementations in which there can be duplicate entries, for > > example Linux-based systems in which /etc/mtab is a symlink to > > /proc/mounts) can have duplicate entries in the file system list. > > This happens most frequently for /. > > * NEWS: Mention this change. > > > > author James Youngman <j...@gnu.org> 2011-06-01 10:11:20 (GMT) > > committer James Youngman <j...@gnu.org> 2011-06-03 23:17:58 > (GMT) > > commit 1d37a22a7f1d3b08c086430b96071c293c02e6d0 (patch) > > (side-by-side diff) > > tree 176cda8518b5d3f41752ab00fda4bf21ff3fef98 > > parent f3d4ac9bb470775df8ceb371b689825a69d8a7fb (diff) > > > > > http://git.savannah.gnu.org/cgit/findutils.git/commit/?id=1d37a22a7f1d3b08c086430b96071c293c02e6d0 > > > > But all the releases on the 4.5 branch comes with this warning: > > > > "This is a "development" release of findutils." > > > > At the same time the latest release on the 4.4 branch is 6 years old: > > > > From: James Youngman > > Subject: GNU findutils version 4.4.2 is released > > Date: Sat, 6 Jun 2009 15:47:38 +0100 > > https://lists.gnu.org/archive/html/info-gnu/2009-06/msg00001.html > > > > I am wondering what would be the best approach to have that bug fixed in > > the find used by Ubuntu. > > I just asked on the Ubuntu mailing list for the findutils package and was > > told that generally Ubuntu takes stable releases. > > > > So now I am wondering what is the findutils policy on releases and > bugfixes. > > If the bug fix is backported to 4.4 would it be possible to have a new > 4.4 > > release? > > Or 4.5 is actually stable enough and Ubuntu should just switch to it? > > > > Thank you, > > Ilya Bobyr > > > > -- > -- > This email is intended solely for the use of its addressee, sender, > and any readers of a mailing list archive in which it happens to > appear. If you have received this email in error, please say or type > three times, "I believe in the utility of email disclaimers," and then > reply to the author correcting any spellings (and, optionally, any > incorrect spellings), accompanying these with humorous jests about the > author's parentage. If you are not the addressee, you are > nevertheless permitted to both copy and forward this email since > without such permissions email systems are unable to transmit email to > anybody, intended recipient or not. To those still reading by this > point, the author would like to apologise for being unable to maintain > a consistent level of humour throughout this disclaimer. Contents may > settle during transit. Do not feed the animals. >
