Re: [OE-core] [PATCH 08/11] lrzsz: remove the recipe
On Wed, Nov 27, 2019 at 02:32:46PM +, Ross Burton wrote: > On 26/11/2019 11:59, Phil Blundell wrote: > > On Mon, Nov 25, 2019 at 12:07:25PM +, Ross Burton wrote: > > > If you can send a patch sooner rather than later for lrzsz to fix the > > > build > > > with modern gettext then that would be *awesome*, as this recipe is the > > > sole > > > blocker. > > We run autoreconf as part of do_configure, so why is this patch shipping > replacement aclocal/configure/etc files that are going to be overwritten? Because you said you wanted the patch sooner rather than later, and the easiest way to do that was to update the whole package to use modern autotools, generate a new tarball with "make dist", and then just generate a diff between the old and new tarballs. If what you actually want is a minimal patch, I can do that but it will take longer. p. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 08/11] lrzsz: remove the recipe
On 26/11/2019 11:59, Phil Blundell wrote: On Mon, Nov 25, 2019 at 12:07:25PM +, Ross Burton wrote: If you can send a patch sooner rather than later for lrzsz to fix the build with modern gettext then that would be *awesome*, as this recipe is the sole blocker. We run autoreconf as part of do_configure, so why is this patch shipping replacement aclocal/configure/etc files that are going to be overwritten? Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 08/11] lrzsz: remove the recipe
On 26/11/2019 12:06, Phil Blundell wrote:
On Tue, Nov 26, 2019 at 12:59:54PM +0100, Phil Blundell wrote:
On Mon, Nov 25, 2019 at 12:07:25PM +, Ross Burton wrote:
If you can send a patch sooner rather than later for lrzsz to fix the build
with modern gettext then that would be *awesome*, as this recipe is the sole
blocker.
This works for me and should resolve your immediate issue. We can think about
a better long-term solution separately.
Incidentally, "gettextize -f" would have taken care of the majority of this. In
autotools.bbclass we have:
elif [ "${BPN}" != "gettext" ] && grep -q
"^[[:space:]]*AM_GNU_GETTEXT" $CONFIGURE_AC; then
# We'd call gettextize here if it wasn't so broken...
and we then proceed to do a slightly half-baked partial version of what
gettextize would have done. This results in using the Makefile.in.in from
the version of gettext that's in the sysroot, but without any of the other
bits that gettextize would have copied and this is arguably the worst of
all possible outcomes. Actually running gettextize is indeed problematic
because it has a tendency to require you to press RETURN on the terminal
(and it reads from /dev/tty to avoid any attempt to subvert this check
by redirecting stdin!) but I think one could argue that if we can't/won't
run the full gettextize then we oughtn't to be messing around with any
of the files that it installs and we should rely on the ones that the
upstream package shipped. That may not always work either, but I have at
least half a suspicion that the current autotools.bbclass behaviour is
creating as many problems as it solves.
gettextize is dead, autopoint is the glorious future, and I've a branch
that is practically complete implementing that (ross/autopoint).
Ross
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 08/11] lrzsz: remove the recipe
On Tue, Nov 26, 2019 at 12:59:54PM +0100, Phil Blundell wrote:
> On Mon, Nov 25, 2019 at 12:07:25PM +, Ross Burton wrote:
> > If you can send a patch sooner rather than later for lrzsz to fix the build
> > with modern gettext then that would be *awesome*, as this recipe is the sole
> > blocker.
>
> This works for me and should resolve your immediate issue. We can think about
> a better long-term solution separately.
Incidentally, "gettextize -f" would have taken care of the majority of this. In
autotools.bbclass we have:
elif [ "${BPN}" != "gettext" ] && grep -q
"^[[:space:]]*AM_GNU_GETTEXT" $CONFIGURE_AC; then
# We'd call gettextize here if it wasn't so broken...
and we then proceed to do a slightly half-baked partial version of what
gettextize would have done. This results in using the Makefile.in.in from
the version of gettext that's in the sysroot, but without any of the other
bits that gettextize would have copied and this is arguably the worst of
all possible outcomes. Actually running gettextize is indeed problematic
because it has a tendency to require you to press RETURN on the terminal
(and it reads from /dev/tty to avoid any attempt to subvert this check
by redirecting stdin!) but I think one could argue that if we can't/won't
run the full gettextize then we oughtn't to be messing around with any
of the files that it installs and we should rely on the ones that the
upstream package shipped. That may not always work either, but I have at
least half a suspicion that the current autotools.bbclass behaviour is
creating as many problems as it solves.
p.
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 08/11] lrzsz: remove the recipe
On 21/11/2019 13:59, Phil Blundell wrote: I also have at least a passing fondness for lrzsz and if a small amount of maintenance now will suffice to keep it working for another 21 years then I think I would consider that a good outcome. I will have a quick look at the code and see if I can fix whatever is apparently problematic about it. If you can send a patch sooner rather than later for lrzsz to fix the build with modern gettext then that would be *awesome*, as this recipe is the sole blocker. Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 08/11] lrzsz: remove the recipe
On 21/11/2019 13:59, Phil Blundell wrote: Now, I am happy to accept that building it inside oe-core is somewhat more difficult, and regenerating the autotools bits using modern tools does look like it will require some patching, but I don't think we should exaggerate the extent to which "old code" equals "problematic code". Yes, the pain is entirely in the autoreconf step. It's not a huge job, and it's probably easier to just delete it all and start again from scratch... I also have at least a passing fondness for lrzsz and if a small amount of maintenance now will suffice to keep it working for another 21 years then I think I would consider that a good outcome. I will have a quick look at the code and see if I can fix whatever is apparently problematic about it. Please do! Debian has a pile of patches too: https://sources.debian.org/patches/lrzsz/0.12.21-10/ All hail the new maintainer of lrzsz. :) Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 08/11] lrzsz: remove the recipe
On Thu, 2019-11-21 at 17:36 +0200, Adrian Bunk wrote: > There are also two higher level topics that should be discussed: > > 1. Removal of maintainers.inc > There is some nitpicking that every recipe needs a maintainer. > For the package in question the maintainer is not involved in the > discussion, and doesn't seem to have been asked for support or > asked regarding the suggested removal. There are pros and cons to having it. Having people who help look after specific recipes is appreciated. Some maintainers are more active than others and people's free time varies. We found one of the corner cases here, the fact there are some surprises no one. If we remove it does the situation improve? I'd say not. FWIW the number of recipes up to date has improved recently (or feels to have) and the process does encourage people to send updates. Reality is there are shades of grey. By that I mean that we are never going to have a 100% definitive/defined process which works all of the time in every case. We're doing the best we can and I'm not sure this discussion is going to be productive as I don't see a path where this discussion improves things. > 2. Who is responsible for fixing gettext breakages in meta-oe? > Alexander or Khem? or the wider community? They can certainly help. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 08/11] lrzsz: remove the recipe
On Thu, Nov 21, 2019 at 09:24:34AM +, Ross Burton wrote: >... > So, if zmodem is still a useful feature to have in core, then is anyone > willing to step up and either: > 1) maintain the recipe. I'd love someone who uses lrzsz to put a fork up on > github, integrate all of our patches, and start maintaining it. Maybe then > other distributions who still ship it will join in too. >... In embedded development there are some usecases left for this codebase from the 1980s that implements protocols that were widely popular in the 1980s and early 1990s. Ancient code implementing obsolete ancient stuff is not fun to maintain. There are also two higher level topics that should be discussed: 1. Removal of maintainers.inc There is some nitpicking that every recipe needs a maintainer. For the package in question the maintainer is not involved in the discussion, and doesn't seem to have been asked for support or asked regarding the suggested removal. 2. Who is responsible for fixing gettext breakages in meta-oe? Alexander or Khem? > Ross cu Adrian -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 08/11] lrzsz: remove the recipe
On Thu, Nov 21, 2019 at 10:10:30AM +, Richard Purdie wrote: > On Thu, 2019-11-21 at 09:24 +, Ross Burton wrote: > > 2) the source is positively ancient and building it on modern linux is > > getting harder over time Just to put this in perspective, I tried fetching lrzsz-1.20.0.tar.gz from the upstream site, unpacked it on my Debian "buster" host, did "./configure && make" without modifying any files, and it built absolutely fine using gcc-8.3.0. There were a few compiler warnings but nothing worse than that. Now, I am happy to accept that building it inside oe-core is somewhat more difficult, and regenerating the autotools bits using modern tools does look like it will require some patching, but I don't think we should exaggerate the extent to which "old code" equals "problematic code". > I just wanted to highlight that the way things are trending, its likely > we'll end up with Linux builds alongside RTOS builds with multiconfig. > These will likely need to communicate and the mechanism(s) for that > remain to be seen. meta-oe has a recipe for kermit... :-} > over into Linux. I therefore have a slight inclination to try and keep > this around if we can. > > I do take the point about needing work to keep it maintained/working > though :(. I also have at least a passing fondness for lrzsz and if a small amount of maintenance now will suffice to keep it working for another 21 years then I think I would consider that a good outcome. I will have a quick look at the code and see if I can fix whatever is apparently problematic about it. I have no particular opinion as to whether it ought to stay in oe-core or move into some sort of meta-retrocomputing layer. p. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 08/11] lrzsz: remove the recipe
On Thu, 2019-11-21 at 09:24 +, Ross Burton wrote: > On 20/11/2019 23:18, Adrian Bunk wrote: > > On Wed, Nov 20, 2019 at 11:56:38PM +0100, Alexander Kanavin wrote: > > > On Wed, 20 Nov 2019 at 23:32, Phil Blundell wrote: > > > > > > > However, I think the point still stands that the commit message needs to > > > > provide a better description of why the package is being removed. If > > > > you > > > > think it represents an ongoing maintenance headache that's already bad > > > > and > > > > only going to get worse, and this now outweighs its usefulness, let's > > > > just > > > > say that. Not all old software is problematic, and not all problematic > > > > software is old; the fact that the last release was 20 years ago is an > > > > interesting fact but in isolation that doesn't represent a problem. > > > > Indeed, compared to some other packages in oe-core, eight patches in > > > > total over a 20-year period doesn't seem like that bad of an average. > > > > > > > > > > Fair enough, I wrote a hasty commit message. Mistakes happen. > > > > > > Can I say what my problem is? Here goes: so far, no one in this discussion > > > offered actual help with the actual issue. If you need this or that > > > functionality from Yocto, please try to place help ahead of complaints and > > > criticism. > > > > No, your problem is your way of communication. > > > > It is a very unfriendly way of communication to request help in the form > > patch aiming at immediate removal. > > Hopefully everyone has calmed down overnight and we can continue this > discussion politely? Agreed, lets keep this level headed! > Yes, Alex's commit message should have spelt out that both: > 1) there are doubts anyone is actually using zmodem still (he did this) > 2) the source is positively ancient and building it on modern linux is > getting harder over time (this was implied by being in a series that > upgraded gettext and fixed other recipes, instead of being spelt out). > > So, if zmodem is still a useful feature to have in core, then is anyone > willing to step up and either: > 1) maintain the recipe. I'd love someone who uses lrzsz to put a fork > up on github, integrate all of our patches, and start maintaining it. > Maybe then other distributions who still ship it will join in too. > 2) provide an alternative. I just wanted to highlight that the way things are trending, its likely we'll end up with Linux builds alongside RTOS builds with multiconfig. These will likely need to communicate and the mechanism(s) for that remain to be seen. I know I've personally implemented xmodem and then ymodem as a way of dumping data out a microcontroller on a small project before, it makes for a simple/effective way of getting data over into Linux. I therefore have a slight inclination to try and keep this around if we can. I do take the point about needing work to keep it maintained/working though :(. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 08/11] lrzsz: remove the recipe
On 20/11/2019 23:18, Adrian Bunk wrote: On Wed, Nov 20, 2019 at 11:56:38PM +0100, Alexander Kanavin wrote: On Wed, 20 Nov 2019 at 23:32, Phil Blundell wrote: However, I think the point still stands that the commit message needs to provide a better description of why the package is being removed. If you think it represents an ongoing maintenance headache that's already bad and only going to get worse, and this now outweighs its usefulness, let's just say that. Not all old software is problematic, and not all problematic software is old; the fact that the last release was 20 years ago is an interesting fact but in isolation that doesn't represent a problem. Indeed, compared to some other packages in oe-core, eight patches in total over a 20-year period doesn't seem like that bad of an average. Fair enough, I wrote a hasty commit message. Mistakes happen. Can I say what my problem is? Here goes: so far, no one in this discussion offered actual help with the actual issue. If you need this or that functionality from Yocto, please try to place help ahead of complaints and criticism. No, your problem is your way of communication. It is a very unfriendly way of communication to request help in the form patch aiming at immediate removal. Hopefully everyone has calmed down overnight and we can continue this discussion politely? Yes, Alex's commit message should have spelt out that both: 1) there are doubts anyone is actually using zmodem still (he did this) 2) the source is positively ancient and building it on modern linux is getting harder over time (this was implied by being in a series that upgraded gettext and fixed other recipes, instead of being spelt out). So, if zmodem is still a useful feature to have in core, then is anyone willing to step up and either: 1) maintain the recipe. I'd love someone who uses lrzsz to put a fork up on github, integrate all of our patches, and start maintaining it. Maybe then other distributions who still ship it will join in too. 2) provide an alternative. Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 08/11] lrzsz: remove the recipe
On Wed, Nov 20, 2019 at 11:56:38PM +0100, Alexander Kanavin wrote: > On Wed, 20 Nov 2019 at 23:32, Phil Blundell wrote: > > > However, I think the point still stands that the commit message needs to > > provide a better description of why the package is being removed. If you > > think it represents an ongoing maintenance headache that's already bad and > > only going to get worse, and this now outweighs its usefulness, let's just > > say that. Not all old software is problematic, and not all problematic > > software is old; the fact that the last release was 20 years ago is an > > interesting fact but in isolation that doesn't represent a problem. > > Indeed, compared to some other packages in oe-core, eight patches in > > total over a 20-year period doesn't seem like that bad of an average. > > > > Fair enough, I wrote a hasty commit message. Mistakes happen. > > Can I say what my problem is? Here goes: so far, no one in this discussion > offered actual help with the actual issue. If you need this or that > functionality from Yocto, please try to place help ahead of complaints and > criticism. No, your problem is your way of communication. It is a very unfriendly way of communication to request help in the form patch aiming at immediate removal. It comes across as if you were just too lazy to even try to fix something another patch you are submitting is breaking. You would have received more constructive answers if you would have started with an email describing the non-trivial technical problem where you need assistance. > Alex cu Adrian -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 08/11] lrzsz: remove the recipe
On Wed, 20 Nov 2019 at 23:32, Phil Blundell wrote: > However, I think the point still stands that the commit message needs to > provide a better description of why the package is being removed. If you > think it represents an ongoing maintenance headache that's already bad and > only going to get worse, and this now outweighs its usefulness, let's just > say that. Not all old software is problematic, and not all problematic > software is old; the fact that the last release was 20 years ago is an > interesting fact but in isolation that doesn't represent a problem. > Indeed, compared to some other packages in oe-core, eight patches in > total over a 20-year period doesn't seem like that bad of an average. > Fair enough, I wrote a hasty commit message. Mistakes happen. Can I say what my problem is? Here goes: so far, no one in this discussion offered actual help with the actual issue. If you need this or that functionality from Yocto, please try to place help ahead of complaints and criticism. Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 08/11] lrzsz: remove the recipe
On Wed, Nov 20, 2019 at 11:12:37PM +0100, Alexander Kanavin wrote: > The gettext problem is the immediate reason, but the broader reason is that > the code is not maintained, and we should try to avoid burdening the > project with unmaintained code. There's already 8 custom patches fixing > issues caused by lack of upstream maintenance, and the gettext certainly > won't be the last required fix. I have no interest in zmodem transfers, > thus I opted for recipe removal. I don't in general buy the line of argument that "I have no interest in X, and I want to make some change that happens to break X, ergo X should be removed", but in this particular case it probably is true that lrzsz has few enough users that it wouldn't qualify for inclusion in oe-core if someone were trying to add it nowadays. So if it represents a net maintenance burden then, although I do still use it myself from time to time, I would be OK with it being removed from oe-core. However, I think the point still stands that the commit message needs to provide a better description of why the package is being removed. If you think it represents an ongoing maintenance headache that's already bad and only going to get worse, and this now outweighs its usefulness, let's just say that. Not all old software is problematic, and not all problematic software is old; the fact that the last release was 20 years ago is an interesting fact but in isolation that doesn't represent a problem. Indeed, compared to some other packages in oe-core, eight patches in total over a 20-year period doesn't seem like that bad of an average. p. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 08/11] lrzsz: remove the recipe
On Wed, 20 Nov 2019 at 22:38, Phil Blundell wrote: > If this is the actual reason for removing lrszsz, the commit message should > say so. As it stands, this patch provides no meaningful justification for > why the package should be removed, it just contains a statement about the > last release having been a long time ago (which may be true, but isn't > obviously relevant) and some vague sneering about "proper networking" > which doesn't seem to be helpful either. > The gettext problem is the immediate reason, but the broader reason is that the code is not maintained, and we should try to avoid burdening the project with unmaintained code. There's already 8 custom patches fixing issues caused by lack of upstream maintenance, and the gettext certainly won't be the last required fix. I have no interest in zmodem transfers, thus I opted for recipe removal. When the last release was is quite relevant from that perspective. Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 08/11] lrzsz: remove the recipe
On Wed, Nov 20, 2019 at 09:00:28PM +0100, Alexander Kanavin wrote: > Do you want to maintain it? Protocols are not changing, but the software > that lrzsz depends on is changing. > > Your first task would be making it build with the latest version of > gettext, the branch containing that is here: If this is the actual reason for removing lrszsz, the commit message should say so. As it stands, this patch provides no meaningful justification for why the package should be removed, it just contains a statement about the last release having been a long time ago (which may be true, but isn't obviously relevant) and some vague sneering about "proper networking" which doesn't seem to be helpful either. p. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 08/11] lrzsz: remove the recipe
On Wed, 20 Nov 2019 at 21:17, Adrian Bunk wrote: > > Do you want to maintain it? > > Did you already contact the maintainer whose name your patch removes > from maintainers.inc? > Most entries in oe-core's maintainers.inc do not carry any real responsibility or commitment; they're there mostly so that monthly emails from auto upgrade helper end up with someone. Actual maintenance comes from those who use and need the components. I can certainly ask Anuj, but I bet he has no interest in lrzsz whatsoever. Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 08/11] lrzsz: remove the recipe
On Wed, Nov 20, 2019 at 09:00:28PM +0100, Alexander Kanavin wrote: > On Wed, 20 Nov 2019 at 20:49, Adrian Bunk wrote: > > > > Using serial lines for console work may have its uses, > > > but for transferring files please set up proper networking. > > >... > > > > I've had several recent embedded experiences where this was impossible, > > and lrzsz was extremely useful. > > > > Do you want to maintain it? >... Did you already contact the maintainer whose name your patch removes from maintainers.inc? > Alex cu Adrian -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 08/11] lrzsz: remove the recipe
On Wed, 20 Nov 2019 at 20:49, Adrian Bunk wrote: > > Using serial lines for console work may have its uses, > > but for transferring files please set up proper networking. > >... > > I've had several recent embedded experiences where this was impossible, > and lrzsz was extremely useful. > Do you want to maintain it? Protocols are not changing, but the software that lrzsz depends on is changing. Your first task would be making it build with the latest version of gettext, the branch containing that is here: http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=akanavin/package-version-updates Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 08/11] lrzsz: remove the recipe
On Wed, Nov 20, 2019 at 02:44:52PM +0100, Alexander Kanavin wrote: > This is 2019; last release of lrzsz was in 1998. The protocols are not changing. > Using serial lines for console work may have its uses, > but for transferring files please set up proper networking. >... I've had several recent embedded experiences where this was impossible, and lrzsz was extremely useful. cu Adrian -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
