From jtaza at indeci.gob.pe Mon Mar 27 09:10:17 2017 From: jtaza at indeci.gob.pe (David Hale) Date: Mon, 27 Mar 2017 04:10:17 -0500 (PET) Subject: [3dprinter-general] Benefits Message-ID: <2079655944.6600925.1490605817653.JavaMail.zimbra@indeci.gob.pe> Hello, I had written to you initially about a deposit by a deceased customer(Anthony) of my bank. He passed declaring no account beneficiary. Kindly indicate your interest so i can give more info on the subject. Regards, David. -------------- next part -------------- An HTML attachment was scrubbed... URL: From onitake at gmail.com Mon Mar 27 23:42:04 2017 From: onitake at gmail.com (Gregor Riepl) Date: Tue, 28 Mar 2017 01:42:04 +0200 Subject: [3dprinter-general] Bug#706656: ITP: cura -- Controller for 3D printers In-Reply-To: <20161227222201.GC27540@spark.dtdns.net> References: <20160922060646.GB26553@spark.dtdns.net> <3235069.DrFnzR1Yx4@taki> <20160922145411.GD27433@spark.dtdns.net> <163868332.VA4DXPXECZ@taki> <20160923064505.GA18085@spark.dtdns.net> <1fe66ac7-090b-be80-92a3-dd02d22e95d4@gmail.com> <20161227222201.GC27540@spark.dtdns.net> Message-ID: Hi Bas, Here's some feedback to your previous comments. In general, I think some of the Lintian warnings seem overly picky. Many of them are warnings are of the 'I' class, and while it's good that they are logged, not all of them make sense. As for the 'W' and 'E' ones, most of them are addressed now. > All of them have "debian-changelog-line-too-long"; break the lines in > debian/changelog so they don't get too long. This should be fixed now. > Then there's "no-upstream-changelog", which is tricky: it seems there really > isn't a changelog file provided by upstream for libarcus and uranium. It's > probably a good idea to ask them about this. What's supposed to be in there? Can it be free-form? Cura has a ChangeLog.txt in their ChangeLogPlugin, perhaps this can be used. I haven't found anything of the sort for Arcus, Uranium and CuraEngine. CuraEngine has something, but it's sorely out of date. I can open bug reports on their repos, but really don't thing Ultimaker will maintain separate changelogs for all their components. > python3-arcus says "python" in the description; that should be "Python". My bad. Fixed. > Hardening seems to be disabled; the easiest way to fix that is setting the > debhelper compat level to 10, it automatically applies all hardening then. Done, for all packages. > "package-name-doesnt-match-sonames" on libarcus means that package should be > called "libarcus2" (the capital can be ignored, but the 2 is important to make > sure versioning works well). Don't change the name of the -dev package, just > the library's package itself. Since there is no conclusive response from upstream, I fixed this by naming the package libarcus3. The other packages have been kept as-is. > I'm not sure about "no-symbols-control-file"; it doesn't appear on my local > system when I build it, and the build output suggests that the symbols file is > generated, but I don't see it. Does anyone else on this list know about it? > Otherwise, ask on the mentors list, or #debian-mentors on irc. This is classified as 'I', and seems overly picky to me. But I don't fully understand the implications either, so it may need to be discussed with an expert. > debian-watch-file-is-missing is self-explanatory; adding a watch file is a good > idea, and there are many packages from github to use as an example for how to > write it. Added. Also, fixed the Vcs-* variables in debian/control so they point to my repositories. > quilt-patch-missing-description is about adding some documentation to the > patch; dpkg-source --commit adds templates for that automatically. It's a good > idea to add the information. I added a short description to each patch. > extended-description-is-probably-too-short is correct: you should add a few > lines to explain what the package does. Also, duplicate-long-description can > be easily fixed by adding a distinct line to each binary package saying what > its role in the system is ("This package contains the files needed for > compiling programs that use the library", etc). Added some marketing blurb from the Cura homepage. As I'm not a Cura author, I can only make something up, but I can't really speak on their behalf. May need a review. > CuraEngine has binary-without-manpage. The logical fix for that would be to > write a manual page. However, I think it is reasonable to consider CuraEngine > an implementation detail of cura. Such internal helper programs do not need a > manual page. They should also not be installed in the execution path. That > is, either write a manual page, or install the executable in > /usr/lib/cura-engine/ (or in a subdirectory of that). I generated a man page with help2man and edited it a bit. Maybe a fully autogenerated manpage is possible with proper parameters. Will look into this later. CuraEngine can be run manually, and it provides helpful output with the 'help' parameter, so a manpage makes sense here. > cura also has binary-without-manpage, and there's no other way to fix it than > by writing a manual page (because cura obviously is a program that the user > should run directly). It doesn't have to be very long, but please avoid "there > was no man page, so now there is"; that's less useful than no man page at all, > because it silences lintian without fixing the problem (missing documentation) > and thus hides the problem (which is against our social contract). This absolutely doesn't make sense to me. Cura doesn't accept any command line arguments as far as I can tell and is meant to be launched from a graphical desktop anyway. Why does it need a manpage? > font-in-non-font-package is also something that needs to be fixed. There > should be no fonts in any of your packages. It would be best if cura would > just look for fonts in /usr/share/fonts/; if that's too hard, add symlinks from > where it expects them to the fonts in there. You also need a dependency on the > package containing the fonts, of course. This one is a bit hard. The only Debian package containing Open Sans that I could find is texlive-fonts-extra, and that one is huge and doesn't even include them in TrueType format. Would you rather suggest I create a fonts-opensans package from upstream (Google in this case) first? Or would one specific to Cura be ok? > It looks like the problematic files that were in there when I was packaging it > are gone, so there is no need to repackage the source. That means the source > package will still contain the fonts, so the copyright file should still > contain the apache license for them (in other words, don't remove it from the > copyright file). Ok... > If you have any problems fixing those things, let me know. Once the remaining warnings (fonts and Cura manpage) are fixed, I will resubmit to debian-mentors, then prepare updated packages for 2.4.0. Best regards, Gregor -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From wijnen at debian.org Tue Mar 28 09:28:03 2017 From: wijnen at debian.org (Bas Wijnen) Date: Tue, 28 Mar 2017 09:28:03 +0000 Subject: [3dprinter-general] Bug#706656: ITP: cura -- Controller for 3D printers In-Reply-To: References: <20160922060646.GB26553@spark.dtdns.net> <3235069.DrFnzR1Yx4@taki> <20160922145411.GD27433@spark.dtdns.net> <163868332.VA4DXPXECZ@taki> <20160923064505.GA18085@spark.dtdns.net> <1fe66ac7-090b-be80-92a3-dd02d22e95d4@gmail.com> <20161227222201.GC27540@spark.dtdns.net> Message-ID: <20170328092803.GB16829@spark.dtdns.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, On Tue, Mar 28, 2017 at 01:42:04AM +0200, Gregor Riepl wrote: > In general, I think some of the Lintian warnings seem overly picky. > Many of them are warnings are of the 'I' class, and while it's good that they > are logged, not all of them make sense. That's possible. While it may be acceptable to leave them unfixed in that case, I still prefer to fix them as long as it doesn't make the program worse. > > Then there's "no-upstream-changelog", which is tricky: it seems there really > > isn't a changelog file provided by upstream for libarcus and uranium. It's > > probably a good idea to ask them about this. > > What's supposed to be in there? > Can it be free-form? Yes. But you can't make it up; upstream needs to write it. And I wouldn't want them to waste their time on reverse engineering their changelog. So I think this is something that may deserve a lintian override. > > "package-name-doesnt-match-sonames" on libarcus means that package should be > > called "libarcus2" (the capital can be ignored, but the 2 is important to make > > sure versioning works well). Don't change the name of the -dev package, just > > the library's package itself. > > Since there is no conclusive response from upstream, I fixed this by naming > the package libarcus3. The other packages have been kept as-is. Did you change any of the filenames? If not, did you check with piuparts that everything is cleaned up after install and remove? > > I'm not sure about "no-symbols-control-file"; it doesn't appear on my local > > system when I build it, and the build output suggests that the symbols file is > > generated, but I don't see it. Does anyone else on this list know about it? > > Otherwise, ask on the mentors list, or #debian-mentors on irc. > > This is classified as 'I', and seems overly picky to me. > But I don't fully understand the implications either, so it may need to be > discussed with an expert. Yes, it's fine to ignore it for now I suppose. I would be interested to know what's happening though. > > extended-description-is-probably-too-short is correct: you should add a few > > lines to explain what the package does. Also, duplicate-long-description can > > be easily fixed by adding a distinct line to each binary package saying what > > its role in the system is ("This package contains the files needed for > > compiling programs that use the library", etc). > > Added some marketing blurb from the Cura homepage. > As I'm not a Cura author, I can only make something up, but I can't really > speak on their behalf. May need a review. That's fine, as a packager you are an expert user and that should be good enough for writing this. I'll check them when you upload the new packages. > > CuraEngine has binary-without-manpage. The logical fix for that would be to > > write a manual page. However, I think it is reasonable to consider CuraEngine > > an implementation detail of cura. Such internal helper programs do not need a > > manual page. They should also not be installed in the execution path. That > > is, either write a manual page, or install the executable in > > /usr/lib/cura-engine/ (or in a subdirectory of that). > > I generated a man page with help2man and edited it a bit. > Maybe a fully autogenerated manpage is possible with proper parameters. > Will look into this later. Sounds good. > > cura also has binary-without-manpage, and there's no other way to fix it than > > by writing a manual page (because cura obviously is a program that the user > > should run directly). It doesn't have to be very long, but please avoid "there > > was no man page, so now there is"; that's less useful than no man page at all, > > because it silences lintian without fixing the problem (missing documentation) > > and thus hides the problem (which is against our social contract). > > This absolutely doesn't make sense to me. Cura doesn't accept any command line > arguments as far as I can tell and is meant to be launched from a graphical > desktop anyway. > > Why does it need a manpage? Every program in Debian that the user can run directly must have one. Programs that can be launched from a menu system can still also be lauched from the commandline. I use that all the time: I know the names of the programs I want to run, but don't know where to find them in the menu structure. So I open a terminal and type the name. If a program has its documentation in some other form (a website, or as part of the program), the manpage can just point to that. Having a manpage is useful anyway, because it makes the program show up when searching the man page directory (man -k keyword). In this case, it should probably contain the long description of the package, a statement that it doesn't accept any commandline arguments, and a pointer to the web site. > > font-in-non-font-package is also something that needs to be fixed. There > > should be no fonts in any of your packages. It would be best if cura would > > just look for fonts in /usr/share/fonts/; if that's too hard, add symlinks from > > where it expects them to the fonts in there. You also need a dependency on the > > package containing the fonts, of course. > > This one is a bit hard. > The only Debian package containing Open Sans that I could find is > texlive-fonts-extra, and that one is huge and doesn't even include them in > TrueType format. Hmm, it looks like this font is indeed not packaged: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=701478 > Would you rather suggest I create a fonts-opensans package from upstream > (Google in this case) first? > Or would one specific to Cura be ok? Creating a new package for it would be the way to go. The alternative would be to use a different font, but that would mean patching Cura, and I agree with you that that wouldn't be nice. > Once the remaining warnings (fonts and Cura manpage) are fixed, I will > resubmit to debian-mentors, then prepare updated packages for 2.4.0. Great, thanks for your work! Bas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJY2iyiAAoJEJzRfVgHwHE6UwkP/jPpE5moGGjbqbGW69fk/pi2 U5Xxh0MMLCGhPCL/AFlCXn+33dIC6LATrBCxaEE+PDTvuWW9rt+hxoFnBsQ8IOoh n99WnmWaSy6tH3E/JkegjPyF5rOLEFmNq6OqfkFaWVZouGhjKzBmESIRIMQWxxct 6yhCOO1WWA8bz0iGKkMSYiT/mrVVGQshzqxn5LUk9YUggBQbY+OCWXtVx4AnqbZc bJ5PD2yGGiJZHxhbtCI+/M7FXJ7ycbcmIBdvdYnoDBEw151JDfOvvrtQkMMiSCLJ UyBVzOKkGvyTnBWCfVCXrx/3FNw3QEonJTC5G5dGLgB45LMYgVXRYq2C4Xcp9eJM KhxqJ9+R1LJjWUwetxsuCCzkcPcrRP0j+68GkRsX/m9GKSDUlQWwJkfdmfi6OHUC kVtIJPBuxqCrIeRZsOc3vhkop9+Rszd63GWx7P5DYtGLFHq263aSlJKZyWMe8lks PP2x0s0AnT+oS6V508NmLNaHqSQwE8Hhonzcj8R7MxiqfGlYkvx2dfffp3YYKGT7 E73f9IXWVhiP1fzmPKIRGutvLuzFfrEjeCuukZE85za+FfwtZRN1iPb6eW1UQ7Fi I1ZBN4Qhg/OViDez7KnfUOlsBjIWbXsMeAXe1QwWI6V7ILBc2nsO1w4RK1YqJZP8 Bw0da3L5Y8yEdhv1aJ8D =CAfC -----END PGP SIGNATURE----- From onitake at gmail.com Tue Mar 28 17:51:59 2017 From: onitake at gmail.com (Gregor Riepl) Date: Tue, 28 Mar 2017 19:51:59 +0200 Subject: [3dprinter-general] Bug#706656: ITP: cura -- Controller for 3D printers In-Reply-To: <20170328092803.GB16829@spark.dtdns.net> References: <20160922060646.GB26553@spark.dtdns.net> <3235069.DrFnzR1Yx4@taki> <20160922145411.GD27433@spark.dtdns.net> <163868332.VA4DXPXECZ@taki> <20160923064505.GA18085@spark.dtdns.net> <1fe66ac7-090b-be80-92a3-dd02d22e95d4@gmail.com> <20161227222201.GC27540@spark.dtdns.net> <20170328092803.GB16829@spark.dtdns.net> Message-ID: >>> Then there's "no-upstream-changelog", which is tricky: it seems there really >>> isn't a changelog file provided by upstream for libarcus and uranium. It's >>> probably a good idea to ask them about this. > >> What's supposed to be in there? >> Can it be free-form? > > Yes. But you can't make it up; upstream needs to write it. And I wouldn't > want them to waste their time on reverse engineering their changelog. So I > think this is something that may deserve a lintian override. Ok. I will add the changelog file to Cura. This is a 'P' level warning, so I don't think an explicit override is required: https://lintian.debian.org/tags/no-upstream-changelog.html >>> "package-name-doesnt-match-sonames" on libarcus means that package should be >>> called "libarcus2" (the capital can be ignored, but the 2 is important to make >>> sure versioning works well). Don't change the name of the -dev package, just >>> the library's package itself. > >> Since there is no conclusive response from upstream, I fixed this by naming >> the package libarcus3. The other packages have been kept as-is. > > Did you change any of the filenames? If not, did you check with piuparts that > everything is cleaned up after install and remove? No, that isn't necessary when naming the binary package libarcus3. Lintian will pick up that the SONAME is libArcus.so.3, verify that the symlink is correct and that the package name contains the API version. Not ideal, because it will cause maintenance overhead when upstream increments the SOVERSION, but it won't require any source changes. >>> I'm not sure about "no-symbols-control-file"; it doesn't appear on my local >>> system when I build it, and the build output suggests that the symbols file is >>> generated, but I don't see it. Does anyone else on this list know about it? >>> Otherwise, ask on the mentors list, or #debian-mentors on irc. > >> This is classified as 'I', and seems overly picky to me. >> But I don't fully understand the implications either, so it may need to be >> discussed with an expert. > > Yes, it's fine to ignore it for now I suppose. I would be interested to know > what's happening though. I suppose this file will help with dependency autocalculation on shared libs. Since we're closely tying a certain libArcus to a certain Cura version, I believe it only has limited usefulness in our case. >> Added some marketing blurb from the Cura homepage. >> As I'm not a Cura author, I can only make something up, but I can't really >> speak on their behalf. May need a review. > > That's fine, as a packager you are an expert user and that should be good > enough for writing this. I'll check them when you upload the new packages. Thanks! >> Why does it need a manpage? > > Every program in Debian that the user can run directly must have one. Programs > that can be launched from a menu system can still also be lauched from the > commandline. I use that all the time: I know the names of the programs I want > to run, but don't know where to find them in the menu structure. So I open a > terminal and type the name. > > If a program has its documentation in some other form (a website, or as part of > the program), the manpage can just point to that. Having a manpage is useful > anyway, because it makes the program show up when searching the man page > directory (man -k keyword). In this case, it should probably contain the long > description of the package, a statement that it doesn't accept any commandline > arguments, and a pointer to the web site. Ok. I created such a manpage. It's unlikely that it will have to be changed often (except for the version, of course), so it won't be hard to maintain anyway. >>> font-in-non-font-package is also something that needs to be fixed. There >>> should be no fonts in any of your packages. It would be best if cura would >>> just look for fonts in /usr/share/fonts/; if that's too hard, add symlinks from >>> where it expects them to the fonts in there. You also need a dependency on the >>> package containing the fonts, of course. > >> This one is a bit hard. >> The only Debian package containing Open Sans that I could find is >> texlive-fonts-extra, and that one is huge and doesn't even include them in >> TrueType format. > > Hmm, it looks like this font is indeed not packaged: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=701478 Yes, I noticed that RFP too. >> Would you rather suggest I create a fonts-opensans package from upstream >> (Google in this case) first? >> Or would one specific to Cura be ok? > > Creating a new package for it would be the way to go. The alternative would be > to use a different font, but that would mean patching Cura, and I agree with > you that that wouldn't be nice. I don't think replacing the font is a good idea. Open Sans is released under APL-2.0, so should be fine in Debian. I already started working on a suitable package and will take the RFP shortly. Can you advise on how to generate and maintain the source tarball? Upstream (http://www.opensans.org) only distributes the file open-sans.zip, without any versioning. The fonts do contain a version in their metadata, however: It's "1.10" I haven't found a way to convince uscan to accept the file, so writing a working watch file and autogenerating fonts-open-sans-1.10_orig.tar.gz is a bit out of my league. Can you help? Thanks, Gregor -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From wijnen at debian.org Tue Mar 28 18:23:17 2017 From: wijnen at debian.org (Bas Wijnen) Date: Tue, 28 Mar 2017 18:23:17 +0000 Subject: [3dprinter-general] Bug#706656: ITP: cura -- Controller for 3D printers In-Reply-To: References: <20160922060646.GB26553@spark.dtdns.net> <3235069.DrFnzR1Yx4@taki> <20160922145411.GD27433@spark.dtdns.net> <163868332.VA4DXPXECZ@taki> <20160923064505.GA18085@spark.dtdns.net> <1fe66ac7-090b-be80-92a3-dd02d22e95d4@gmail.com> <20161227222201.GC27540@spark.dtdns.net> <20170328092803.GB16829@spark.dtdns.net> Message-ID: <20170328182317.GA25093@spark.dtdns.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, On Tue, Mar 28, 2017 at 07:51:59PM +0200, Gregor Riepl wrote: > This is a 'P' level warning, so I don't think an explicit override is > required: https://lintian.debian.org/tags/no-upstream-changelog.html Ah right. In that case it's fine to just ignore the message. > > Did you change any of the filenames? If not, did you check with piuparts that > > everything is cleaned up after install and remove? > > No, that isn't necessary when naming the binary package libarcus3. > > Lintian will pick up that the SONAME is libArcus.so.3, verify that the symlink > is correct and that the package name contains the API version. So now you have libArcus.so -> libArcus.so.3 -> libArcus.so.1.0.0? That's weird, but on my system I see libwt does the same thing, so I suppose it's not a problem... > Not ideal, because it will cause maintenance overhead when upstream increments > the SOVERSION, but it won't require any source changes. You have maintenance when that happens anyway. > >>> I'm not sure about "no-symbols-control-file"; it doesn't appear on my local > >>> system when I build it, and the build output suggests that the symbols file is > >>> generated, but I don't see it. Does anyone else on this list know about it? > >>> Otherwise, ask on the mentors list, or #debian-mentors on irc. > > > >> This is classified as 'I', and seems overly picky to me. > >> But I don't fully understand the implications either, so it may need to be > >> discussed with an expert. > > > > Yes, it's fine to ignore it for now I suppose. I would be interested to know > > what's happening though. > > I suppose this file will help with dependency autocalculation on shared libs. Yes, symbols files track version information about individual symbols in a library, which allows programs to depend on the lowest version that supports all the features, thus avoiding dependencies on new libraries, which makes it more likely that packages from sid work on stable unchanged (we don't support that, but that doesn't mean we have to break it), and it avoids problems with large transitions. > Since we're closely tying a certain libArcus to a certain Cura version, I > believe it only has limited usefulness in our case. Yes, I agree. My interest wasn't based on it being useful, but in the fact that I don't understand the error, or the messages I see when building the package (it says it's building the symbols file, but it doesn't seem to exist after the build). > I created such a manpage. It's unlikely that it will have to be changed often > (except for the version, of course), so it won't be hard to maintain anyway. Yes, that's the plan. I would personally leave out the version as well, because I'm very likely to forget to update it when a new version is released. > I already started working on a suitable package and will take the RFP shortly. Great! > Can you advise on how to generate and maintain the source tarball? > Upstream (http://www.opensans.org) only distributes the file open-sans.zip, > without any versioning. The fonts do contain a version in their metadata, > however: It's "1.10" Assuming they change that version whenever they do a new release, you can use it. For generating the tarball, just unzip it, then tar it and name it properly (opensans_0.10.orig.tar.gz). > I haven't found a way to convince uscan to accept the file, so writing a > working watch file and autogenerating fonts-open-sans-1.10_orig.tar.gz is a > bit out of my league. Can you help? I don't think uscan can handle that. It can transform filenames, but it will not download the file, so it cannot examine the metadata inside it. So that means you can't use a watch file in this case. Thanks, Bas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJY2qoUAAoJEJzRfVgHwHE6hFcP/2El/VQRkBPrtfy3xGxGQ3dU 3X9ITUqaJwJQRyNxV+ovMF3siOS0lmqY8A3ILmkm62g5XselFf9o/kuhFWFRQ9vh a8dPs3QyphSvn5qZKQUJ3dVPiJWZpOd0BgCt1PmOUyNp+/EKu5xFywZvvAdbS32E mTGbFGLSz9QwhYXM7o4mLpCOnmvjRhS00fazn7eTZzBMLveHL5su225AVkREr2IT eXOHYo3pTf6P3Ce8O48D8OL4GCsC00WjlSKtWP0NETnWTyf/ymd96Rl9gftWIolQ ERniVYPRHjrdEPCtQl8ZLRE6eRyLAs2ag2L+ZBCSZI/hobLbWvArJ/xbCN7BbSZs KHIl/QO/jwm1ZW0JhvSgHYDCKtLeZcnTctCPn8wn/72j/Mvy9h01oKFKs4SK9aBk 2QzUMW/JnswKwyybTBqeDCbHydlRW/pL5oeqinCAMPFQD7GJkr1kdmDLpGvjh6Te 2UOzy5l6J2hQYkwSSanVmKaLx2B5vtR6N6xhoeToojqyax9MayXSwb7bZHVSXeMD 6UqrsSMYjgO0DVCDaTj6nfVskzN5i34mkjqIjl3ZuOwk7aJoaMm1w/3+Z84GA45O e374N6FKhTrHyyxCXltLjA8OK2eYYM/fzpqp19pf3TEjIceI/bXjkivOBG3Hfoz0 6b+ZRwbOjGM4Yn2dTG3G =O3te -----END PGP SIGNATURE----- From draymndchx at yahoo.co.jp Tue Mar 28 20:00:05 2017 From: draymndchx at yahoo.co.jp (Fung) Date: Tue, 28 Mar 2017 21:00:05 +0100 Subject: [3dprinter-general] Business opportunity Message-ID: <1bab4b42e5bbbc46b97309113e1bbf96@babickindvor.sk> -- I am Vice Chairman of Hang Seng Bank, I have Important Matter to Discuss with you concerning my late client, Died without a NEXT OF KIN. Send me your private email for full details information. email me at chienkraymond at gmail.com Regards Dr.Raymond Chien Kuo Fung From onitake at gmail.com Tue Mar 28 20:39:44 2017 From: onitake at gmail.com (Gregor Riepl) Date: Tue, 28 Mar 2017 22:39:44 +0200 Subject: [3dprinter-general] Bug#706656: ITP: cura -- Controller for 3D printers In-Reply-To: <20170328182317.GA25093@spark.dtdns.net> References: <20160922060646.GB26553@spark.dtdns.net> <3235069.DrFnzR1Yx4@taki> <20160922145411.GD27433@spark.dtdns.net> <163868332.VA4DXPXECZ@taki> <20160923064505.GA18085@spark.dtdns.net> <1fe66ac7-090b-be80-92a3-dd02d22e95d4@gmail.com> <20161227222201.GC27540@spark.dtdns.net> <20170328092803.GB16829@spark.dtdns.net> <20170328182317.GA25093@spark.dtdns.net> Message-ID: <8f733622-1f09-1de2-4a35-610d7c19b228@gmail.com> > So now you have libArcus.so -> libArcus.so.3 -> libArcus.so.1.0.0? That's > weird, but on my system I see libwt does the same thing, so I suppose it's not > a problem... The situation is like this: libArcus.so.1.1.0 - shared lib file name libArcus.so.3 - the SONAME, this is what executables are linked against libArcus.so - this is how the linker finds what to link when you specify -lArcus The symlinks are like this: libArcus.so -> libArcus.so.1.1.0 libArcus.so.3 -> libArcus.so.1.1.0 The real confusion is between 1.1.0 and 2.3.1. Upstream said they want to change versioning and 1.1.0 is the _real_ release version of libArcus. 2.3.1 is the corresponding Cura release. Having a differing SOVERSION is fine, as long it is kept consistent (i.e. only increments on incompatible API changes, and no sudden decrements). >> Since we're closely tying a certain libArcus to a certain Cura version, I >> believe it only has limited usefulness in our case. > > Yes, I agree. My interest wasn't based on it being useful, but in the fact > that I don't understand the error, or the messages I see when building the > package (it says it's building the symbols file, but it doesn't seem to exist > after the build). Oh, that's interesting. I could look into this later. >> I created such a manpage. It's unlikely that it will have to be changed often >> (except for the version, of course), so it won't be hard to maintain anyway. > > Yes, that's the plan. I would personally leave out the version as well, > because I'm very likely to forget to update it when a new version is released. Is that ok? I'll remove it in this case. :) What about CuraEngine? > Assuming they change that version whenever they do a new release, you can use > it. For generating the tarball, just unzip it, then tar it and name it > properly (opensans_0.10.orig.tar.gz). Very good, thank you! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From onitake at gmail.com Wed Mar 29 07:10:41 2017 From: onitake at gmail.com (Gregor Riepl) Date: Wed, 29 Mar 2017 09:10:41 +0200 Subject: [3dprinter-general] Bug#706656: ITP: cura -- Controller for 3D printers In-Reply-To: <20170328182317.GA25093@spark.dtdns.net> References: <20160922060646.GB26553@spark.dtdns.net> <3235069.DrFnzR1Yx4@taki> <20160922145411.GD27433@spark.dtdns.net> <163868332.VA4DXPXECZ@taki> <20160923064505.GA18085@spark.dtdns.net> <1fe66ac7-090b-be80-92a3-dd02d22e95d4@gmail.com> <20161227222201.GC27540@spark.dtdns.net> <20170328092803.GB16829@spark.dtdns.net> <20170328182317.GA25093@spark.dtdns.net> Message-ID: <8d47dae2-e554-c8cc-7b20-33f9a007e490@gmail.com> > Yes, I agree. My interest wasn't based on it being useful, but in the fact > that I don't understand the error, or the messages I see when building the > package (it says it's building the symbols file, but it doesn't seem to exist > after the build). I think that the symbols file will only be generated for comparison. If debian/.symbols does not exist, it won't do anything. If it does, it will compare them and warn when symbols have changed. There's some instructions here: https://www.debian.org/doc/manuals/maint-guide/advanced.en.html#librarysymbols I used dpkg-gensymbols to generate a symbols file, I guess it will be useful to compare changes in the future. >> I already started working on a suitable package and will take the RFP shortly. > > Great! It's up here: https://mentors.debian.net/package/fonts-open-sans Excluding the font files from Cura seems to work fine, it's picking them up from the system automatically, as far as I can tell. And the updated packages are on Debian mentors now: https://mentors.debian.net/packages/uploader/onitake%40gmail.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From onitake at gmail.com Wed Mar 29 17:44:17 2017 From: onitake at gmail.com (Gregor Riepl) Date: Wed, 29 Mar 2017 19:44:17 +0200 Subject: [3dprinter-general] Bug#706656: ITP: cura -- Controller for 3D printers In-Reply-To: <20170329090249.GC25093@spark.dtdns.net> References: <20160922145411.GD27433@spark.dtdns.net> <163868332.VA4DXPXECZ@taki> <20160923064505.GA18085@spark.dtdns.net> <1fe66ac7-090b-be80-92a3-dd02d22e95d4@gmail.com> <20161227222201.GC27540@spark.dtdns.net> <20170328092803.GB16829@spark.dtdns.net> <20170328182317.GA25093@spark.dtdns.net> <8d47dae2-e554-c8cc-7b20-33f9a007e490@gmail.com> <20170329090249.GC25093@spark.dtdns.net> Message-ID: > You set the Debian Fonts Task Force as the maintainer. That seems reasonable, > but they should know about this: did you check with them that they will indeed > maintain the package? (Since you're set as uploader, you'll probably still be > doing it, but you're doing it in their name, so they should agree to it.) My bad, I copy-pasted that and didn't know what to do with it. I'll contact them ASAP. > The description feels like a marketing snippet with all the brand names. That > information is better placed in debian/copyright. Users reading the > description want to know what the package does and if they want to install it, > not who made it or paid for it. It's not always wrong to mention brands, and > in this case you could mention Google if you think people might be looking for > "that font from Google". Does this look better? Open Sans is a clean and modern sans-serif typeface designed by Steve Matteson and commissioned by Google. . This version contains the complete 897 character set, which includes the standard ISO Latin 1, Latin CE, Greek and Cyrillic character sets. . Open Sans was designed with an upright stress, open forms and a neutral, yet friendly appearance. It was optimized for print, web, and mobile interfaces, and has excellent legibility characteristics in its letterforms. . Both condensed and non-condensed typefaces are included with this package. Even if it doesn't seem very neutral, it's a good description of the font, its targeted usage and its look. Isn't that what users want to see? > You list unzip as a Build-Depends, but it's only needed for get-orig-source. I > don't think this is reason for a Build-Depends, but wasn't sure, so I checked > some documents. I didn't find much; the only thing I see is our policy manual, > section 7.7, which says what should be in Build-Depends and it doesn't mention > the get-orig-source target at all. It also doesn't say anything about "extra" > dependencies. In 4.2, in particular footnote 14, it does say that you should > only list packages that you use directly, but it doesn't say if optional > targets are reasons for listing packages. I think it's useful for users to be > able to run get-orig-source without manually figuring out the dependencies, but > if someone knows about different rules or conventions in Debian, please speak > up. All right, get-orig-source was a bit of mystery to me anyway. It looks like it works well with uscan, but uscan seems useless if you don't have a watch file. I'll remove the dependency. >> And the updated packages are on Debian mentors now: >> https://mentors.debian.net/packages/uploader/onitake%40gmail.com > > I'll look at them later today. I already noticed a potential problem - mentors warns that the watch file doesn't work, but I don't see any errors. Strange. Maybe some local testing is in order. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From fdelalamo at indeci.gob.pe Sat Apr 1 13:02:07 2017 From: fdelalamo at indeci.gob.pe (David Hale) Date: Sat, 1 Apr 2017 08:02:07 -0500 (PET) Subject: [3dprinter-general] Waiting Message-ID: <540023835.696092.1491051727276.JavaMail.zimbra@indeci.gob.pe> Hello, I had written to you initially about a deposit by a deceased customer(Anthony) of my bank. He passed declaring no account beneficiary. Kindly indicate your interest so i can give more info on the subject. Regards,David. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rasalinas at conacyt.gov.py Sat Apr 1 23:53:28 2017 From: rasalinas at conacyt.gov.py (Ms. Ella Golan) Date: Sun, 02 Apr 2017 00:53:28 +0100 Subject: [3dprinter-general] re Message-ID: <20170401235358.5FB963A74D96@correo.conacyt.gov.py> I am Ms.Ella Golan, I am the Executive Vice President Banking Division with FIRST INTERNATIONAL BANK OF ISRAEL LTD (FIBI). I am getting in touch with you regarding an extremely important and urgent matter. If you would oblige me the opportunity, I shall provide you with details upon your response. Faithfully, Ms.Ella Golan