Re: [Emc-developers] Merge 2.9 to master
Now that master is very active again, this will continue to be a problem There is really no good clean solution to the problem as our process is now: If you expect pull request mergers to also merge branch to branch then they will be less apt to approve pull requests. (thought this is the good compromise in the mean time) If you expect pull request makers to do it, you won't get pull requests. We don't have enough developers with enough experience to do this - and it's a pain for those few that do. If we wait and do it time to time (as we do) it become a huge problem. Is there a way to do partial merges? so merge the work you are familiar with? Is there another process that is less painful for our devs to work with? Doing the same thing over and over is not going to fix the problem! Chris From: Hans Unzner Sent: December 31, 2023 1:23 PM To: emc-developers@lists.sourceforge.net Subject: Re: [Emc-developers] Merge 2.9 to master Am 31.12.23 um 13:29 schrieb andy pugh: > On Sun, 31 Dec 2023 at 12:14, Hans Unzner wrote: > >> You mean via Github by the author of the PR? Not sure if that will work. >> Better that the person who merges it keep track of it. > That assumes that the person who accepts the merge understands the > code as well as the one creating the code, which is rarely likely to > be the case? > I hope that the person who merges the PR have at least a rough idea what the change is about. Otherwise how could this person judge if this PR is good or bad? ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Merge 2.9 to master - Partially completed
Looks good to me Andy. Thank you. From: andy pugh Sent: December 31, 2023 11:58 AM To: EMC developers Subject: Re: [Emc-developers] Merge 2.9 to master - Partially completed Chris M: Can you look at linuxcnc/lib/python/qtvcp/qt_pstat.py? Based on commit dates I think you probably wanted both sets of changes in? (functions mportDefaultHandler from 2.9 and isUsingDefaultHandler + getQSSPaths from master? Håvard F. Aasen: Can you take a look at emcrsh.cc lines 573-584 & 1246-1253,? Your commit 18f0295 changed the handling of some string checks, but master was already significantly changed by https://github.com/LinuxCNC/linuxcnc/commit/8b91f27d5f9c2523e4e4350efa38e5264aa51280 using rtapi_strlcpy, which I think is maybe better? I have kept the master version. -- atp "A motorcycle is a bicycle with a pandemonium attachment and is designed for the especial use of mechanical geniuses, daredevils and lunatics." — George Fitch, Atlanta Constitution Newspaper, 1912 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RPi5 + Raspbian + LinuxCNC latency tests - first impressions
Hi guys, I've sent new images for the Pi 4b and Pi 5 to Andy for testing, with a view that they be deployed on the downloads page. These both use the 6.1.69 kernel which is the very first version where the Raspberry Kernel and the PREEMPT_RT patch align perfectly. Hopefully over the last 6 weeks, the pi5 is better supported now. *Raspberry Pi 4b/400* https://drive.google.com/file/d/1Bzx_PqRqdJVTMPlNMEG7z_RjJHf7QcDX/view?usp=sharing *Raspberry PI 5* https://drive.google.com/file/d/1HBXliMQE-OvU0PQPYEOK3OqJz0-CTO5K/view?usp=sharing For initial login credentials, and initial configuration, please refer to the download page https://linuxcnc.org/downloads/ Rod Webster *1300 896 832* +61 435 765 611 Vehicle Modifications Network www.vehiclemods.net.au On Sun, 31 Dec 2023 at 01:35, Steffen Möller via Emc-developers < emc-developers@lists.sourceforge.net> wrote: > Rod, > > Thank you for your kind and swift reply. > HDMI sound works perfectly with the Raspbian default. Also, I think this > would find quite some user base, since anyone reusing an old TV or a > feature-rich monitor with the RPi would immediately benefit. I also > mentioned games before :) > > The RPi image we come up with does not need to be perfect. Our users > should just not be surprised with anythin when using it. My wishlist would > be > * A pointer to our manual at all the places where the image could be > downloaded > * The manual describing >- how the image is created so they can contribute >- what not to do with that image > > On a sidenote, please have a look at http://raspi.debian.net/. Nothing on > the RPi5, though maybe this resonates somehow with what we are after. > > Best, > Steffen > > > Gesendet: Samstag, 30. Dezember 2023 um 14:16 Uhr > > Von: "Rod Webster" > > An: "EMC developers" > > Betreff: Re: [Emc-developers] RPi5 + Raspbian + LinuxCNC latency tests - > first impressions > > > > Steffen, > > > > Some good feedback thanks. > > I'm really not surprised things broke on an update because we compile the > > kernel from the Raspberry sources at a specific point in the commit tree. > > It's not a generic Debian build by any means. LIkewise installing a > > different desktop is also asking for trouble. > > > > Having no sound is also not surprising because in the absence of an audio > > jack you are dependent on HDMI and I know other SBC's have issues with > HDMI > > sound. If someone has a solution please let me know > > > > Please bear in mind that this image is over 6 weeks old and there have > been > > several kernel releases and countless commits to the raspberry pi kernel > > since then. > > > > But for me, the main thing is that it's only in the last few days that > the > > kernel version and the PREEMPT_RT patch align perfectly so I am hoping my > > next version is more robust. That has never happened in the life of the > pi5 > > before. > > > > To test latency on the console, you can install the debian rt-tests > > package. I have found that our latency-histogram yields similar results. > > > > I don't think a single 400 usec spike when opening a browser is of > concern. > > Thats not something you do when running a gcode program. > > > > Hopefully I will have some peace and quiet over the weekend to build a > new > > version. > > > > Rod Webster > > *1300 896 832* > > +61 435 765 611 > > Vehicle Modifications Network > > www.vehiclemods.net.au > > > > > > On Sat, 30 Dec 2023 at 21:58, Steffen Möller via Emc-developers < > > emc-developers@lists.sourceforge.net> wrote: > > > > > Heya, > > > > > > Not only that we have a RPi4/5 confusion, you managed to add a Rod/b > one. > > > > > > So, the image Andy pointed to (which I understand has its roots with > Rod) > > > works very nicely. While idle latencies did not exceed 12µs, mostly > below > > > 10. That was truly impressive. Once I got wifi up and initiated some > > > downloads, it doubled to 24µs, much like the value Andy got. When I > started > > > up firefox and selected youtube, I got a single value of 400µs, though. > > > > > > A complaint I have is that there was no sound in the default > installation. > > > The 400µs I like to speculate may be associated with the failed > attempt to > > > perform the respective initialisations. > > > > > > Another complaint is that the image is not stable when it comes to > > > updates. I was curious on the effect that the installation of KDE would > > > have on the latencies, and if the missing sound would install with it. > So I > > > installed the package "task-desktop-kde" with debfoster. That ruined > the > > > reboot since the expected kernel image was no longer found. I made a > > > screenshot with my phone and send it to whoever is interested, but my > hunch > > > is that Rod's new image if depending more on Debian's installation will > > > likely solve such inconsistency issues. > > > > > > Do we have any latency tools that would run without X, so we get a > > > baseline of what software layer is costing
Re: [Emc-developers] Linuxcnc 2.10pre with glade
Hi It work fine I can use my updated interface with linuxcnc 2.10pre ! Thanks for your help! I had made some modification on dxf2gcode as well to change all arc into segment with a settable value Estimation time as well etc... Once I will finish the custom entry and exit on a shape I will share the source. My machine is a 2 axis rotating table with Y axis and a diamond wire cable as tool My target was to transform the standard kinematic (XY) to (AY) . And Happy new year! Cordialement, Moustapha Elhima P Penser à préserver l'environnement avant d'imprimer ce message. Merci De : Steffen Möller via Emc-developers Envoyé : dimanche 31 décembre 2023 08h42 À : emc-developers@lists.sourceforge.net Cc : Steffen Möller Objet : Re: [Emc-developers] Linuxcnc 2.10pre with glade Hello, Once you have integrated your changes with the latest version I expect that you can run this all through Glade again. If not then something was broken in that process, I presume. But I am no expert on what Gmoccapy is doing or on how to modify it - my answer was only on how to use a recursive diff and transition that to the master branch. Good luck! Steffen > Hi SteffenOk I see, so no way to edit the file with glade?Gmoccapy was > created with witch version?Thanks again for your helpCordialement,Moustapha > ElhimaPenser à préserver l'environnement avant d'imprimer ce message. Merci > Message d'origine De : Steffen Möller via Emc-developers > Date : 30/12/2023 22:10 (GMT+01:00) > À : emc-developers@lists.sourceforge.net Cc : Steffen Möller > , emc-developers@lists.sourceforge.net Objet : Re: > [Emc-developers] Linuxcnc 2.10pre with glade Well, there may be another > option if you still have (or can still retrieve) the tarball from which you > started.It is three steps:1. Rename your current source tree to avoid > overwriting it, call it "mywork"2. Unpack the original tarball of LinuxCNC of > version 2.8 that you edited.3. Create a diff of the two and redirect that > into a file: diff -r original mywork > whateverpathto/mywork.patch4. Clone > the current master branch of LinuxCNC5. patch it with what you saved in > mywork.patch: patch -p1 < whateverpathto/mywork.patchNot all hunks of that > patch will work, but many will be just fine.Good luck!Steffen> Gesendet: > Samstag, 30. Dezember 2023 um 16:55 Uhr> Von: "Hans Unzner" > > An: emc-developers@lists.sourceforge.net> Betreff: > Re: [Emc-developers] Linuxcnc 2.10pre with glade>> I'm afraid but I think you > have to do your modifications once more for > LinuxCNC 2.9/2.10. There have > been so many changes during the upgrade > from Python2 to Python3 and Gtk2 to > Gtk3, which make it almost > impossible to merge from 2.8, especially the > glade file. Also a huge > number of deprecated widgets have been replaced in > Gmoccapy for > LinuxCNCN 2.9.> So I would recommend to just do it again for > the current version. Sorry.> > Hans> > Am 30.12.23 um 15:08 schrieb ELHIMA > Moustapha via Emc-developers:> > Hi guy's> >> > Houston I have a problem... I > project to use the mesa 5i25T instead off the 5i25 ( was good for me)> > For > the I need at list the linuxcnc2.10pre version> >> > I had customized the > gmoccapy interface (gmoccapy.glade) to get some other functionality and work > also on the bin file of it> > After few hours of work... I get the suprise to > had made all of this stuff on the 2.8 version of linuxcnc.> >> > I said " > ok lets spend again a part of your life time again...". So I decided to merge > to the buster version and install linuxcnc from the biuldbot.> > > Linuxcnc2.10pre and the mesa 5i25T working fine.> > So 2nd step was to make > the same modification on the gmoccapy interface and I get a terrible > headache.> > Python need to be version 3 instead off 2 for linuxcnc2.8 > but ok no problem for that ( or maybe there is a script to merge python 2 to > 3?)> > For Glade I had installed v3.40 and no way to get the hal library and > gladevcp.> >> > Is it possible to get the right way to update gmoccapy on > linuxcnc 2.10pre???> >> > Thanks for your help> >> > Cordialement,> >> > > Moustapha Elhima> > ELMO - machines outils> > +33 6 09 99 21 97> >> > P > Penser à préserver l'environnement avant d'imprimer ce message. Merci> >> > > ___> > Emc-developers mailing > list> > Emc-developers@lists.sourceforge.net> > > https://lists.sourceforge.net/lists/listinfo/emc-developers> > > > > ___> Emc-developers mailing list> > Emc-developers@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/emc-developers>___Emc-developers > mailing > listEmc-developers@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/emc-developers > ___ > Emc-developers mailing list >
[Emc-developers] linuxcnc2.10pre and glade
Hi guy's Houston I have a problem... I project to use the mesa 5i25T instead off the 5i25 ( was good for me) For the I need at list the linuxcnc2.10pre I had customized the gmoccapy interface (gmoccapy.glade) to get some other functionality and work also the bin file of it After few hours of work... I get the suprise to had made all of this stuff on the 2.8 version of linuxcnc. I said " ok lets spend again a part of your life time again...". So I decided to merge to the buster version and install linuxcnc from the biuldbot. Linuxcnc2.10pre and the mesa 5i25T working fine. So 2nd step was to make the same modification on the gmoccapy interface and I get a terrible headache. Python need to be version 3 instead off 2 for linuxcnc2.8 but ok no problem for that ( or maybe there is a script to merge python 2 to 3?) For Glade I had installed v3.40 and no way to get the hal library and gladevcp. Is it possible to get the right way to update gmoccapy on linuxcnc 2.10pre??? Thanks for your help Cordialement, P Penser à préserver l'environnement avant d'imprimer ce message. Merci ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Linuxcnc 2.10pre with glade
Hello, Once you have integrated your changes with the latest version I expect that you can run this all through Glade again. If not then something was broken in that process, I presume. But I am no expert on what Gmoccapy is doing or on how to modify it - my answer was only on how to use a recursive diff and transition that to the master branch. Good luck! Steffen > Hi SteffenOk I see, so no way to edit the file with glade?Gmoccapy was > created with witch version?Thanks again for your helpCordialement,Moustapha > ElhimaPenser à préserver l'environnement avant d'imprimer ce message. Merci > Message d'origine De : Steffen Möller via Emc-developers > Date : 30/12/2023 22:10 (GMT+01:00) > À : emc-developers@lists.sourceforge.net Cc : Steffen Möller > , emc-developers@lists.sourceforge.net Objet : Re: > [Emc-developers] Linuxcnc 2.10pre with glade Well, there may be another > option if you still have (or can still retrieve) the tarball from which you > started.It is three steps:1. Rename your current source tree to avoid > overwriting it, call it "mywork"2. Unpack the original tarball of LinuxCNC of > version 2.8 that you edited.3. Create a diff of the two and redirect that > into a file: diff -r original mywork > whateverpathto/mywork.patch4. Clone > the current master branch of LinuxCNC5. patch it with what you saved in > mywork.patch: patch -p1 < whateverpathto/mywork.patchNot all hunks of that > patch will work, but many will be just fine.Good luck!Steffen> Gesendet: > Samstag, 30. Dezember 2023 um 16:55 Uhr> Von: "Hans Unzner" > > An: emc-developers@lists.sourceforge.net> Betreff: > Re: [Emc-developers] Linuxcnc 2.10pre with glade>> I'm afraid but I think you > have to do your modifications once more for > LinuxCNC 2.9/2.10. There have > been so many changes during the upgrade > from Python2 to Python3 and Gtk2 to > Gtk3, which make it almost > impossible to merge from 2.8, especially the > glade file. Also a huge > number of deprecated widgets have been replaced in > Gmoccapy for > LinuxCNCN 2.9.> So I would recommend to just do it again for > the current version. Sorry.> > Hans> > Am 30.12.23 um 15:08 schrieb ELHIMA > Moustapha via Emc-developers:> > Hi guy's> >> > Houston I have a problem... I > project to use the mesa 5i25T instead off the 5i25 ( was good for me)> > For > the I need at list the linuxcnc2.10pre version> >> > I had customized the > gmoccapy interface (gmoccapy.glade) to get some other functionality and work > also on the bin file of it> > After few hours of work... I get the suprise to > had made all of this stuff on the 2.8 version of linuxcnc.> >> > I said " > ok lets spend again a part of your life time again...". So I decided to merge > to the buster version and install linuxcnc from the biuldbot.> > > Linuxcnc2.10pre and the mesa 5i25T working fine.> > So 2nd step was to make > the same modification on the gmoccapy interface and I get a terrible > headache.> > Python need to be version 3 instead off 2 for linuxcnc2.8 > but ok no problem for that ( or maybe there is a script to merge python 2 to > 3?)> > For Glade I had installed v3.40 and no way to get the hal library and > gladevcp.> >> > Is it possible to get the right way to update gmoccapy on > linuxcnc 2.10pre???> >> > Thanks for your help> >> > Cordialement,> >> > > Moustapha Elhima> > ELMO - machines outils> > +33 6 09 99 21 97> >> > P > Penser à préserver l'environnement avant d'imprimer ce message. Merci> >> > > ___> > Emc-developers mailing > list> > Emc-developers@lists.sourceforge.net> > > https://lists.sourceforge.net/lists/listinfo/emc-developers> > > > > ___> Emc-developers mailing list> > Emc-developers@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/emc-developers>___Emc-developers > mailing > listEmc-developers@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/emc-developers > ___ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers > ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Merge 2.9 to master
My (perhaps unsolicited) opinion is that the person who merges the PR/commits their own changes should carry it through to the upstream branch(es). That way it's always tidy and there's no questions when the next person goes to merge changes to code they're familiar with. I generally try to do that, however sometimes find that I have to "leave it for someone else" when there's a pile of unmerged items with conflicts I'm ignorant to resolving. There would be less of this if the above were the rule. It also helps when things get messy. Recently I worked with a member who created a PR against master that applied to 2.9. I tried unsuccessfully to get them to make the PR against 2.9 instead so I could merge it upstream. In an effort to not discourage collaboration, and after talking with Andy offline, I ended up recreating it in 2.9 on their behalf. There was a pile of unmerged commits at the time, so I didn't clean up after myself. I am also by no means a git expert, so I'm alway open to learn/correct anything I'm doing incorrectly. Happy New Year all! -Greg On Sun, Dec 31, 2023 at 7:14 AM Hans Unzner wrote: > > > Am 31.12.23 um 13:01 schrieb andy pugh: > > On Sun, 31 Dec 2023 at 11:50, Hans Unzner wrote: > > > >>> Is it the job of the person who accepts the PR to merge it upstream? > >>> Or a secondary task for the Pull Requestor? > >>> > >> I think it would be the best if the person who accepts the PR or the > >> persons who makes changes which could cause conflicts merge the branch > >> upwards. > > Yes, so do I. I was asking which it should be. > > > > Maybe PRs to 2.9 (and earlier) should also be presented with a > > merge-PR to upstream branches? > You mean via Github by the author of the PR? Not sure if that will work. > Better that the person who merges it keep track of it. > > > ___ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers > ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Merge 2.9 to master
Am 31.12.23 um 13:29 schrieb andy pugh: On Sun, 31 Dec 2023 at 12:14, Hans Unzner wrote: You mean via Github by the author of the PR? Not sure if that will work. Better that the person who merges it keep track of it. That assumes that the person who accepts the merge understands the code as well as the one creating the code, which is rarely likely to be the case? I hope that the person who merges the PR have at least a rough idea what the change is about. Otherwise how could this person judge if this PR is good or bad? ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Merge 2.9 to master
On Sun, 31 Dec 2023 at 12:14, Hans Unzner wrote: > You mean via Github by the author of the PR? Not sure if that will work. > Better that the person who merges it keep track of it. That assumes that the person who accepts the merge understands the code as well as the one creating the code, which is rarely likely to be the case? -- atp "A motorcycle is a bicycle with a pandemonium attachment and is designed for the especial use of mechanical geniuses, daredevils and lunatics." — George Fitch, Atlanta Constitution Newspaper, 1912 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Merge 2.9 to master
Am 31.12.23 um 13:01 schrieb andy pugh: On Sun, 31 Dec 2023 at 11:50, Hans Unzner wrote: Is it the job of the person who accepts the PR to merge it upstream? Or a secondary task for the Pull Requestor? I think it would be the best if the person who accepts the PR or the persons who makes changes which could cause conflicts merge the branch upwards. Yes, so do I. I was asking which it should be. Maybe PRs to 2.9 (and earlier) should also be presented with a merge-PR to upstream branches? You mean via Github by the author of the PR? Not sure if that will work. Better that the person who merges it keep track of it. ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Merge 2.9 to master
On Sun, 31 Dec 2023 at 11:50, Hans Unzner wrote: > > Is it the job of the person who accepts the PR to merge it upstream? > > Or a secondary task for the Pull Requestor? > > > I think it would be the best if the person who accepts the PR or the > persons who makes changes which could cause conflicts merge the branch > upwards. Yes, so do I. I was asking which it should be. Maybe PRs to 2.9 (and earlier) should also be presented with a merge-PR to upstream branches? -- atp "A motorcycle is a bicycle with a pandemonium attachment and is designed for the especial use of mechanical geniuses, daredevils and lunatics." — George Fitch, Atlanta Constitution Newspaper, 1912 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Merge 2.9 to master - Partially completed
Chris M: Can you look at linuxcnc/lib/python/qtvcp/qt_pstat.py? Based on commit dates I think you probably wanted both sets of changes in? (functions mportDefaultHandler from 2.9 and isUsingDefaultHandler + getQSSPaths from master? Håvard F. Aasen: Can you take a look at emcrsh.cc lines 573-584 & 1246-1253,? Your commit 18f0295 changed the handling of some string checks, but master was already significantly changed by https://github.com/LinuxCNC/linuxcnc/commit/8b91f27d5f9c2523e4e4350efa38e5264aa51280 using rtapi_strlcpy, which I think is maybe better? I have kept the master version. -- atp "A motorcycle is a bicycle with a pandemonium attachment and is designed for the especial use of mechanical geniuses, daredevils and lunatics." — George Fitch, Atlanta Constitution Newspaper, 1912 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Merge 2.9 to master
Am 31.12.23 um 12:21 schrieb andy pugh: On Sun, 31 Dec 2023 at 10:58, Hans Unzner wrote: It's been a while since 2.9 was merged to master (almost 3 months). I suppose that's one of the drawbacks of working through pull-requests. Is it the job of the person who accepts the PR to merge it upstream? Or a secondary task for the Pull Requestor? I think it would be the best if the person who accepts the PR or the persons who makes changes which could cause conflicts merge the branch upwards. ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Merge 2.9 to master
On Sun, 31 Dec 2023 at 10:58, Hans Unzner wrote: > > It's been a while since 2.9 was merged to master (almost 3 months). I suppose that's one of the drawbacks of working through pull-requests. Is it the job of the person who accepts the PR to merge it upstream? Or a secondary task for the Pull Requestor? -- atp "A motorcycle is a bicycle with a pandemonium attachment and is designed for the especial use of mechanical geniuses, daredevils and lunatics." — George Fitch, Atlanta Constitution Newspaper, 1912 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] Merge 2.9 to master
It's been a while since 2.9 was merged to master (almost 3 months). Like expected some merge conflicts popped up. So I would please some of the more experienced users to do that merge. Thanks! ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
