Re: RFS: fritzing
hello enrique, i've just built fritzing from your package (fritzing_0.4.3b-4), but ran into problems as described in [#571640] (qmake build system can't be set to use qmake-qt3 or qmake-qt4). this typically happens on systems that have qt3-dev-tools installed; in that case, debhelper uses /usr/bin/qmake as it is currently configured in alternatives, which is qmake-qt3 by default. until that bug is closed, i suggest to add qt3-dev-tools to Build-Conflicts; this seems to be the best solution until #571640 is fixed. after removing qt-dev-tools, building and installing worked, and a quick functionality check didn't show noticable shortcomings. thanks for packaging fritzing chrysn [#571640] http://bugs.debian.org/571640 -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom signature.asc Description: Digital signature
Re: RFS: fritzing
2010/10/26 Scott Howard showard...@gmail.com 2010/10/24 Enrique Hernández Bello ehbe...@gmail.com: What is the next step? :) -- Enrique Hernández Bello Hi Enrique, I'm not a DD yet, but I learned a lot from sponsors being extremely picky about my packages. Here are some comments for you to consider: 1) instead of CDBS and explicitly using quilt, would you consider using source format 3.0 (quilt) and debhelper 7 [2]. It should make your debian/rules simpler. It appears that you are using source 3.0 (quilt), but you still have a debian/README.source and explicitly call quilt in your debian/rules. Both of those are probably unnecessary. CDBS is comfortable. Do you think that my debian/rules will be more simple without it? 2) in debian/rules you have this comment: # dh_fixperms and override_dh_fixperms didn't work. The reason it doesn't work is that you are not using debhelper 7 type build system, but CDBS. See [2] for how to make debhelper 7 type rules. CDBS helper calls to debhelper orders. I don't know why dh_fixperms does not work. 3) Consider reformatting your debian/copyright to DEP-5 [3] (this is nit-picking, but good form for a new package). 4) Consider formatting your patch descriptions to DEP-3 [4] (this too is nit-picking, but good form for a new package). DEP documents mentioned above are really nit-picking. Are they really useful? 5) Since this is the first debian release of your package, I would remove all your debian/changelog entries except for: fritzing (0.4.3b-1) unstable; urgency=low * Initial release (Closes: #601230) This is your first release, and version 0.4.3b-1 makes sense to me as the first debian packaging released. If I don't increment the release number, I can't upload it to mentors repository. What do you suggest? What is the common way to version a pre-release package? Perhaps adding a suffix like ~mentors1? 6) I like the control.in and debian/rules magic to have different dependencies between debian and ubuntu. I haven't seen that before, and it prevents a diff between the two. Thanks! ;) 7) $ lintian --pedantic -I is clean. Of the above comments, I think (5) is probably the most important. I suggest doing 1-4 as an exercise in good form [1] http://wiki.debian.org/Projects/DebSrc3.0 [2] http://www.debian.org/doc/maint-guide/ch-dreq.en.html#s-defaultrules [3] http://dep.debian.net/deps/dep5/ [4] http://dep.debian.net/deps/dep3/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikj7lzciqbq9kqdqj72bu+gdn77dztv7fje7...@mail.gmail.com -- Enrique Hernández Bello
Re: RFS: fritzing
Hi, 2010/10/31 Enrique Hernández Bello ehbe...@gmail.com: This is your first release, and version 0.4.3b-1 makes sense to me as the first debian packaging released. If I don't increment the release number, I can't upload it to mentors repository. What do you suggest? What is the common way to version a pre-release package? Perhaps adding a suffix like ~mentors1? Hmmm why can't you? I'm pretty sure I did that last time. Just dput, it'll overwrite whatever was there. Regards, -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimfni+p1qdikjszdv0zhqa6k3e2nvsh8zy30...@mail.gmail.com
Re: RFS: fritzing
2010/10/31 Fernando Lemos fernando...@gmail.com Hi, 2010/10/31 Enrique Hernández Bello ehbe...@gmail.com: This is your first release, and version 0.4.3b-1 makes sense to me as the first debian packaging released. If I don't increment the release number, I can't upload it to mentors repository. What do you suggest? What is the common way to version a pre-release package? Perhaps adding a suffix like ~mentors1? Hmmm why can't you? I'm pretty sure I did that last time. Just dput, it'll overwrite whatever was there. Regards, -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimfni+p1qdikjszdv0zhqa6k3e2nvsh8zy30...@mail.gmail.com I remembered problems overwriting uploads with the same release version but I'm confused. Maybe it was with launchpad, so I will try again. Thank you! -- Enrique Hernández Bello
Re: RFS: fritzing
Thanks for packaging fritzing, btw - it's a good tool to have in Debian. 2010/10/31 Enrique Hernández Bello ehbe...@gmail.com: 2010/10/26 Scott Howard showard...@gmail.com 2010/10/24 Enrique Hernández Bello ehbe...@gmail.com: 1) instead of CDBS and explicitly using quilt, would you consider using source format 3.0 (quilt) and debhelper 7 [2]. It should make your debian/rules simpler. It appears that you are using source 3.0 (quilt), but you still have a debian/README.source and explicitly call quilt in your debian/rules. Both of those are probably unnecessary. CDBS is comfortable. Do you think that my debian/rules will be more simple without it? CDBS is fine, it's just easier (for me) to figure out what is going wrong with builds using debhelper (since you were having a problem with dh_fixperms). You have the build working, so no need to mess with it. I would look into getting rid of the explicit quilt dependency since you are already using source 3.0 (quilt) format to clean up the rules (and eliminate one of the cdbs mk files, I believe) CDBS helper calls to debhelper orders. I don't know why dh_fixperms does not work. I not comfortable with CDBS, but I'm curious why it's happening. Does anyone else know? 3) Consider reformatting your debian/copyright to DEP-5 [3] (this is nit-picking, but good form for a new package). 4) Consider formatting your patch descriptions to DEP-3 [4] (this too is nit-picking, but good form for a new package). DEP documents mentioned above are really nit-picking. Are they really useful? My sponsors have made me use them in each of my uploads (even when adopting someone elses package I had to retroactively label each patch). They are just drafts as of now - but if it isn't much more work, why not do it? There is no drawback (except your time) and the benefit is machine parsing of your patches and copyright information by the debian QA team. If I don't increment the release number, I can't upload it to mentors repository. What do you suggest? What is the common way to version a pre-release package? Perhaps adding a suffix like ~mentors1? Mentors is unique in that they allow repeated uploads of the same version number for exactly this reason (that we are working on packages for the same debian release version). Regards, Scott -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktinoha_zoxixrfim1t0tgtk+pf+q7h1dy7ua8...@mail.gmail.com
Re: RFS: fritzing
On Thu, Oct 28, 2010 at 09:23:13PM +0200, Paul Gevers wrote: I like it too, therefore I had a very quick look at the package. I believe your package must build without internet connection. So I think you should change your rules logic and probably just include a upstream-changelog manually instead of creating it from the internet on build time. ---end quoted text--- Please note that autobuilder chroots have no internet access. -- أحمد المحمودي (Ahmed El-Mahmoudy) Digital design engineer GPG KeyID: 0xEDDDA1B7 GPG Fingerprint: 8206 A196 2084 7E6D 0DF8 B176 BC19 6A94 EDDD A1B7 signature.asc Description: Digital signature
Re: RFS: fritzing
6) I like the control.in and debian/rules magic to have different dependencies between debian and ubuntu. I haven't seen that before, and it prevents a diff between the two. I like it too, therefore I had a very quick look at the package. I believe your package must build without internet connection. So I think you should change your rules logic and probably just include a upstream-changelog manually instead of creating it from the internet on build time. Paul signature.asc Description: OpenPGP digital signature
Re: RFS: fritzing
2010/10/24 Enrique Hernández Bello ehbe...@gmail.com: What is the next step? :) -- Enrique Hernández Bello Hi Enrique, I'm not a DD yet, but I learned a lot from sponsors being extremely picky about my packages. Here are some comments for you to consider: 1) instead of CDBS and explicitly using quilt, would you consider using source format 3.0 (quilt) and debhelper 7 [2]. It should make your debian/rules simpler. It appears that you are using source 3.0 (quilt), but you still have a debian/README.source and explicitly call quilt in your debian/rules. Both of those are probably unnecessary. 2) in debian/rules you have this comment: # dh_fixperms and override_dh_fixperms didn't work. The reason it doesn't work is that you are not using debhelper 7 type build system, but CDBS. See [2] for how to make debhelper 7 type rules. 3) Consider reformatting your debian/copyright to DEP-5 [3] (this is nit-picking, but good form for a new package). 4) Consider formatting your patch descriptions to DEP-3 [4] (this too is nit-picking, but good form for a new package). 5) Since this is the first debian release of your package, I would remove all your debian/changelog entries except for: fritzing (0.4.3b-1) unstable; urgency=low * Initial release (Closes: #601230) This is your first release, and version 0.4.3b-1 makes sense to me as the first debian packaging released. 6) I like the control.in and debian/rules magic to have different dependencies between debian and ubuntu. I haven't seen that before, and it prevents a diff between the two. 7) $ lintian --pedantic -I is clean. Of the above comments, I think (5) is probably the most important. I suggest doing 1-4 as an exercise in good form [1] http://wiki.debian.org/Projects/DebSrc3.0 [2] http://www.debian.org/doc/maint-guide/ch-dreq.en.html#s-defaultrules [3] http://dep.debian.net/deps/dep5/ [4] http://dep.debian.net/deps/dep3/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikj7lzciqbq9kqdqj72bu+gdn77dztv7fje7...@mail.gmail.com
Re: RFS: fritzing
On Sun, Oct 24, 2010 at 10:14:04PM +0100, Enrique Hernández Bello wrote: Hi, I solved the remain problems. The ITP bug number is #601230. You can check the bugreport here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601230 What is the next step? :) ---end quoted text--- Close the ITP bug in the debian/changelog. For example you can have such an entry: * Initial release for Debian (Closes: #601230) -- أحمد المحمودي (Ahmed El-Mahmoudy) Digital design engineer GPG KeyID: 0xEDDDA1B7 GPG Fingerprint: 8206 A196 2084 7E6D 0DF8 B176 BC19 6A94 EDDD A1B7 signature.asc Description: Digital signature
Re: RFS: fritzing
[Please don't top post. Debian e-mail list prefer in-line and bottom posts.] I haven't looked at the package bug I try to help by commenting on your question 1) What is an ITP bug? why I must to open it to close after? An ITP bug is an Intent To Package bug against WNPP pseudo package in the Debian bug tracker [1], telling the community that you are working on a package. Relevant parties are subscribed to bugs for that package and can comment on things like description and possible license issues. You should look there first to see if somebody is already working on the same package to avoid duplicate work. The first and only line in your changelog should than be: Initial release (closes #xxx) 2) I don't know really, but I guess that empty directories are usefull to extend the electronic parts of the application by the user or other packages. Because that I decide keep them. Other packages should create their own directories if needed. What is the specific use case for the users, that they cannot create the directories. Paul [1] http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=wnpp signature.asc Description: OpenPGP digital signature
Re: RFS: fritzing
2010/10/24 Paul Gevers p...@climbing.nl [Please don't top post. Debian e-mail list prefer in-line and bottom posts.] I haven't looked at the package bug I try to help by commenting on your question 1) What is an ITP bug? why I must to open it to close after? An ITP bug is an Intent To Package bug against WNPP pseudo package in the Debian bug tracker [1], telling the community that you are working on a package. Relevant parties are subscribed to bugs for that package and can comment on things like description and possible license issues. You should look there first to see if somebody is already working on the same package to avoid duplicate work. The first and only line in your changelog should than be: Initial release (closes #xxx) 2) I don't know really, but I guess that empty directories are usefull to extend the electronic parts of the application by the user or other packages. Because that I decide keep them. Other packages should create their own directories if needed. What is the specific use case for the users, that they cannot create the directories. Paul [1] http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=wnpp Hi, I solved the remain problems. The ITP bug number is #601230. You can check the bugreport here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601230 What is the next step? :) -- Enrique Hernández Bello
Re: RFS: fritzing
Hello debian mentors! ;) I've recently uploaded my last version of Fritzing package. I've fixed all lintian errors and warnings and I've followed all recommendations except packaging this application under pkg-electronics team. I've suscribed to their list but I don't know what I must to do about. However I consider that my package is now suitable to get into the Debian world. I would like that somebody review my work and tell me the next step. Thank you. El 4 de octubre de 2010 15:10, أحمد المحمودي aelmahmo...@sabily.orgescribió: Hello, On Sun, Oct 03, 2010 at 05:42:48PM +0100, Enrique Hernández Bello wrote: It builds these binary packages: fritzing - Easy-to-use, electronic design software ---end quoted text--- * Please consider packaging it under pkg-electronics team [1]. * There are some lintian issues: W: fritzing source: unknown-field-in-dsc original-maintainer W: fritzing source: out-of-date-standards-version 3.8.4 (current is 3.9.1) I: fritzing: arch-dep-package-has-big-usr-share 57499kB 92% N: N:The package has a significant amount of architecture-independent data N:(over 4MB, or over 2MB and more than 50% of the package) in /usr/share N:but is an architecture-dependent package. This is wasteful of mirror N:space and bandwidth since it means distributing multiple copies of this N:data, one for each architecture. N: N:If the data in /usr/share is not architecture-independent, this is a N:Policy violation that should be fixed by moving the data elsewhere N:(usually /usr/lib). N: N:Refer to Debian Developer's Reference section 6.7.5 N:(Architecture-independent data) for details. N: N:Severity: wishlist, Certainty: certain N: W: fritzing: new-package-should-close-itp-bug W: fritzing: executable-not-elf-or-script ./usr/share/fritzing/parts/svg/core/icon/din-5_midi_connector.svg W: fritzing: executable-not-elf-or-script ./usr/share/fritzing/parts/svg/core/icon/7-segment display.svg W: fritzing: executable-not-elf-or-script ./usr/share/fritzing/parts/svg/core/breadboard/breadboard.svg W: fritzing: executable-not-elf-or-script ./usr/share/fritzing/parts/core/xbee.fzp W: fritzing: executable-not-elf-or-script ./usr/share/fritzing/parts/svg/core/icon/solenoid.svg W: fritzing: executable-not-elf-or-script ./usr/share/fritzing/parts/svg/core/icon/loudspeaker.svg W: fritzing: executable-not-elf-or-script ./usr/share/fritzing/parts/svg/core/icon/microphone.svg W: fritzing: executable-not-elf-or-script ./usr/share/fritzing/parts/svg/core/icon/16-segment display.svg W: fritzing: executable-not-elf-or-script ./usr/share/fritzing/parts/svg/core/icon/xbee.svg W: fritzing: executable-not-elf-or-script ./usr/share/fritzing/parts/svg/core/icon/infrared proximity sensor.svg W: fritzing: executable-not-elf-or-script ./usr/share/fritzing/parts/svg/core/schematic/infrared proximity sensor.svg W: fritzing: executable-not-elf-or-script ./usr/share/fritzing/parts/svg/core/schematic/schematic-arduino-diecimila_old.svg W: fritzing: executable-not-elf-or-script ./usr/share/fritzing/parts/svg/core/schematic/din-5_midi_connector.svg # This is because those files are marked as executable in upstream # tarball. Although dh_fixperms is run during build but it doesn't fix # those permissions, you can override dh_fixperms to fix those # permissions, also tell upstream about to fix that. I: fritzing: package-contains-empty-directory usr/share/fritzing/parts/contrib/ I: fritzing: package-contains-empty-directory usr/share/fritzing/parts/svg/contrib/breadboard/ I: fritzing: package-contains-empty-directory usr/share/fritzing/parts/svg/contrib/icon/ I: fritzing: package-contains-empty-directory usr/share/fritzing/parts/svg/contrib/schematic/ I: fritzing: package-contains-empty-directory usr/share/fritzing/parts/svg/user/breadboard/ I: fritzing: package-contains-empty-directory usr/share/fritzing/parts/svg/user/icon/ I: fritzing: package-contains-empty-directory usr/share/fritzing/parts/svg/user/pcb/ I: fritzing: package-contains-empty-directory usr/share/fritzing/parts/svg/user/schematic/ I: fritzing: package-contains-empty-directory usr/share/fritzing/parts/user/ N: N:This package installs an empty directory. This might be intentional but N:it's normally a mistake. If it is intentional, add a lintian override. N: N:If a package ships with or installs empty directories, you can remove N:them in debian/rules by calling: N: N: $ find path/to/base/dir -type d -empty -delete N: N:Severity: wishlist, Certainty: possible N: * Also please consider forwarding the .desktop manpage files you made to upstream. * Probably debian/dirs is not needed [1] http://wiki.debian.org/PkgElectronics -- أحمد المحمودي (Ahmed El-Mahmoudy) Digital design engineer GPG KeyID: 0xEDDDA1B7 GPG Fingerprint: 8206 A196 2084 7E6D 0DF8 B176 BC19 6A94 EDDD A1B7 -- Enrique
Re: RFS: fritzing
Hello! thanks for your reply. Answering you: 1) What is an ITP bug? why I must to open it to close after? 2) I don't know really, but I guess that empty directories are usefull to extend the electronic parts of the application by the user or other packages. Because that I decide keep them. El 23 de octubre de 2010 22:29, أحمد المحمودي aelmahmo...@sabily.orgescribió: On Sat, Oct 23, 2010 at 09:15:12PM +0100, Enrique Hernández Bello wrote: I've recently uploaded my last version of Fritzing package. I've fixed all lintian errors and warnings and I've followed all recommendations except packaging this application under pkg-electronics team. I've suscribed to their list but I don't know what I must to do about. ---end quoted text--- Just send an RFS to the pkg-electronics mailing list. I have added them to the CC. I have a couple of comments regarding your package: 1) I think it should still close an ITP bug. 2) Is there a reason to keep the empty directories ? -- أحمد المحمودي (Ahmed El-Mahmoudy) Digital design engineer GPG KeyID: 0xEDDDA1B7 GPG Fingerprint: 8206 A196 2084 7E6D 0DF8 B176 BC19 6A94 EDDD A1B7 -- Enrique Hernández Bello
Re: RFS: fritzing
On Sat, Oct 23, 2010 at 09:15:12PM +0100, Enrique Hernández Bello wrote: I've recently uploaded my last version of Fritzing package. I've fixed all lintian errors and warnings and I've followed all recommendations except packaging this application under pkg-electronics team. I've suscribed to their list but I don't know what I must to do about. ---end quoted text--- Just send an RFS to the pkg-electronics mailing list. I have added them to the CC. I have a couple of comments regarding your package: 1) I think it should still close an ITP bug. 2) Is there a reason to keep the empty directories ? -- أحمد المحمودي (Ahmed El-Mahmoudy) Digital design engineer GPG KeyID: 0xEDDDA1B7 GPG Fingerprint: 8206 A196 2084 7E6D 0DF8 B176 BC19 6A94 EDDD A1B7 signature.asc Description: Digital signature
Re: RFS: fritzing
Hello, On Sun, Oct 03, 2010 at 05:42:48PM +0100, Enrique Hernández Bello wrote: It builds these binary packages: fritzing - Easy-to-use, electronic design software ---end quoted text--- * Please consider packaging it under pkg-electronics team [1]. * There are some lintian issues: W: fritzing source: unknown-field-in-dsc original-maintainer W: fritzing source: out-of-date-standards-version 3.8.4 (current is 3.9.1) I: fritzing: arch-dep-package-has-big-usr-share 57499kB 92% N: N:The package has a significant amount of architecture-independent data N:(over 4MB, or over 2MB and more than 50% of the package) in /usr/share N:but is an architecture-dependent package. This is wasteful of mirror N:space and bandwidth since it means distributing multiple copies of this N:data, one for each architecture. N: N:If the data in /usr/share is not architecture-independent, this is a N:Policy violation that should be fixed by moving the data elsewhere N:(usually /usr/lib). N: N:Refer to Debian Developer's Reference section 6.7.5 N:(Architecture-independent data) for details. N: N:Severity: wishlist, Certainty: certain N: W: fritzing: new-package-should-close-itp-bug W: fritzing: executable-not-elf-or-script ./usr/share/fritzing/parts/svg/core/icon/din-5_midi_connector.svg W: fritzing: executable-not-elf-or-script ./usr/share/fritzing/parts/svg/core/icon/7-segment display.svg W: fritzing: executable-not-elf-or-script ./usr/share/fritzing/parts/svg/core/breadboard/breadboard.svg W: fritzing: executable-not-elf-or-script ./usr/share/fritzing/parts/core/xbee.fzp W: fritzing: executable-not-elf-or-script ./usr/share/fritzing/parts/svg/core/icon/solenoid.svg W: fritzing: executable-not-elf-or-script ./usr/share/fritzing/parts/svg/core/icon/loudspeaker.svg W: fritzing: executable-not-elf-or-script ./usr/share/fritzing/parts/svg/core/icon/microphone.svg W: fritzing: executable-not-elf-or-script ./usr/share/fritzing/parts/svg/core/icon/16-segment display.svg W: fritzing: executable-not-elf-or-script ./usr/share/fritzing/parts/svg/core/icon/xbee.svg W: fritzing: executable-not-elf-or-script ./usr/share/fritzing/parts/svg/core/icon/infrared proximity sensor.svg W: fritzing: executable-not-elf-or-script ./usr/share/fritzing/parts/svg/core/schematic/infrared proximity sensor.svg W: fritzing: executable-not-elf-or-script ./usr/share/fritzing/parts/svg/core/schematic/schematic-arduino-diecimila_old.svg W: fritzing: executable-not-elf-or-script ./usr/share/fritzing/parts/svg/core/schematic/din-5_midi_connector.svg # This is because those files are marked as executable in upstream # tarball. Although dh_fixperms is run during build but it doesn't fix # those permissions, you can override dh_fixperms to fix those # permissions, also tell upstream about to fix that. I: fritzing: package-contains-empty-directory usr/share/fritzing/parts/contrib/ I: fritzing: package-contains-empty-directory usr/share/fritzing/parts/svg/contrib/breadboard/ I: fritzing: package-contains-empty-directory usr/share/fritzing/parts/svg/contrib/icon/ I: fritzing: package-contains-empty-directory usr/share/fritzing/parts/svg/contrib/schematic/ I: fritzing: package-contains-empty-directory usr/share/fritzing/parts/svg/user/breadboard/ I: fritzing: package-contains-empty-directory usr/share/fritzing/parts/svg/user/icon/ I: fritzing: package-contains-empty-directory usr/share/fritzing/parts/svg/user/pcb/ I: fritzing: package-contains-empty-directory usr/share/fritzing/parts/svg/user/schematic/ I: fritzing: package-contains-empty-directory usr/share/fritzing/parts/user/ N: N:This package installs an empty directory. This might be intentional but N:it's normally a mistake. If it is intentional, add a lintian override. N: N:If a package ships with or installs empty directories, you can remove N:them in debian/rules by calling: N: N: $ find path/to/base/dir -type d -empty -delete N: N:Severity: wishlist, Certainty: possible N: * Also please consider forwarding the .desktop manpage files you made to upstream. * Probably debian/dirs is not needed [1] http://wiki.debian.org/PkgElectronics -- أحمد المحمودي (Ahmed El-Mahmoudy) Digital design engineer GPG KeyID: 0xEDDDA1B7 GPG Fingerprint: 8206 A196 2084 7E6D 0DF8 B176 BC19 6A94 EDDD A1B7 signature.asc Description: Digital signature
Re: RFS: fritzing
On Sun, Oct 03, 2010 at 05:42:48PM +0100, Enrique Hernández Bello wrote: Dear mentors, I am looking for a sponsor for my package fritzing. * Package name: fritzing Version : 0.4.3b-1 Upstream Author : Fritzing Developers i...@fritzing.org * URL : http://fritzing.org * License : GPLv3 CC:BY-SA Section : electronics It builds these binary packages: fritzing - Easy-to-use, electronic design software Is there really a need for the comma here? G'luck, Peter -- Peter Pentchev r...@space.bgr...@ringlet.netr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 If this sentence were in Chinese, it would say something else. signature.asc Description: Digital signature
RFS: fritzing
Dear mentors, I am looking for a sponsor for my package fritzing. * Package name: fritzing Version : 0.4.3b-1 Upstream Author : Fritzing Developers i...@fritzing.org * URL : http://fritzing.org * License : GPLv3 CC:BY-SA Section : electronics It builds these binary packages: fritzing - Easy-to-use, electronic design software My motivation for maintaining this package is: I want to collaborate with this project and I would like my package in official repos of Debian and Ubuntu. This is my second try and now I have a valid branch in launchpad. I will try to upload to REVU, too. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/f/fritzing - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/f/fritzing/fritzing_0.4.3b-1.dsc I would be glad if someone uploaded this package for me. Kind regards Enrique Hernández Bello -- Enrique Hernández Bello
Re: RFS: fritzing
You should avoid getting it into the Ubuntu repositories directly -- there is a sync every cycle, if it's uploaded to Debian, it will be in Ubuntu in time for the next release, try focusing on getting this RFS through the Debian system -- no need to use REVU for this. 2010/10/3 Enrique Hernández Bello ehbe...@gmail.com: Dear mentors, I am looking for a sponsor for my package fritzing. * Package name : fritzing Version : 0.4.3b-1 Upstream Author : Fritzing Developers i...@fritzing.org * URL : http://fritzing.org * License : GPLv3 CC:BY-SA Section : electronics It builds these binary packages: fritzing - Easy-to-use, electronic design software My motivation for maintaining this package is: I want to collaborate with this project and I would like my package in official repos of Debian and Ubuntu. This is my second try and now I have a valid branch in launchpad. I will try to upload to REVU, too. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/f/fritzing - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/f/fritzing/fritzing_0.4.3b-1.dsc I would be glad if someone uploaded this package for me. Kind regards Enrique Hernández Bello -- Enrique Hernández Bello -- All programmers are playwrights, and all computers are lousy actors. #define sizeof(x) rand() :wq -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlkti=njpnsvmuwo4fzarjmtuqcwhgh0vxhm=lxh...@mail.gmail.com
Re: RFS: fritzing
Hello, On Sun, Jun 27, 2010 at 02:27:16AM +0100, Enrique Hernández Bello wrote: * Package name: fritzing Version : 0.3.19b Upstream Author : Fritzing Developers * URL : http://fritzing.org * License : GPLv3 CC-BY-SA Section : electronics ---end quoted text--- I just looked at the intro video, I suggest that you package it under pkg-electronics team. Regarding the package, I am not a DD, yet I had a look at it. I wonder why did you package it as a native package ? -- أحمد المحمودي (Ahmed El-Mahmoudy) Digital design engineer GPG KeyID: 0xEDDDA1B7 GPG Fingerprint: 8206 A196 2084 7E6D 0DF8 B176 BC19 6A94 EDDD A1B7 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100629080119.ga14...@ants.dhis.net
Re: RFS: fritzing
2010/6/29 أحمد المحمودي aelmahmo...@sabily.org Hello, On Sun, Jun 27, 2010 at 02:27:16AM +0100, Enrique Hernández Bello wrote: * Package name: fritzing Version : 0.3.19b Upstream Author : Fritzing Developers * URL : http://fritzing.org * License : GPLv3 CC-BY-SA Section : electronics ---end quoted text--- I just looked at the intro video, I suggest that you package it under pkg-electronics team. Regarding the package, I am not a DD, yet I had a look at it. I wonder why did you package it as a native package ? -- أحمد المحمودي (Ahmed El-Mahmoudy) Digital design engineer GPG KeyID: 0xEDDDA1B7 GPG Fingerprint: 8206 A196 2084 7E6D 0DF8 B176 BC19 6A94 EDDD A1B7 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100629080119.ga14...@ants.dhis.net Yes... I didn't understand the native philosophy but now I'm splitting my Debian code of the upstream in my Launchpad branches. I'll release a new version with the changes soon. Thanks for your support ;) -- Enrique Hernández Bello
RFS: fritzing
Dear mentors, I am looking for a sponsor for my package fritzing. * Package name: fritzing Version : 0.3.19b Upstream Author : Fritzing Developers * URL : http://fritzing.org * License : GPLv3 CC-BY-SA Section : electronics It builds these binary packages: fritzing - Easy-to-use, electronic design software My motivation for maintaining this package because I packaged Fritzing for Ubuntu in Launchpad and I would like to reuse my code to contribute with the Debian community. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/f/fritzing - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/f/fritzing/fritzing_0.3.19b.dsc I would be glad if someone uploaded this package for me. Kind regards Enrique Hernández Bello -- Enrique Hernández Bello
Re: RFS: fritzing
Please don't use HTML email on Debian lists: http://www.debian.org/MailingLists/#codeofconduct -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktily9tgkjtd_qcaxkbg82rypkprz88wyph5yg...@mail.gmail.com
Re: RFS: fritzing
Paul Wise wrote: Please don't use HTML email on Debian lists: A text/plain version of the message was included, so it's not a case I would jump on. It's just a matter of disabling HTML emails (on both ends: writer and reader.) Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/i06khk$4j...@dough.gmane.org
