[done] Re: RFS: unetbootin (New upstream release)
Hi, On 2012-01-29 02:02, Muneeb Shaikh wrote: http://mentors.debian.net/debian/pool/main/u/unetbootin/unetbootin_568-1.dsc Uploaded. The Git repository is at: http://git.debian.org/?p=collab-maint/unetbootin.git;a=summary Btw, it doesn't work for me right now. P.S. You can me directly for subsequent upload requests. -- Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com C++/Perl developer, Debian Developer -- 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/20120129104130.GC900@r500-debian
Re: [done] Re: RFS: unetbootin (New upstream release)
On 01/29/2012 04:11 PM, Eugene V. Lyubimkin wrote: Hi, On 2012-01-29 02:02, Muneeb Shaikh wrote: http://mentors.debian.net/debian/pool/main/u/unetbootin/unetbootin_568-1.dsc Uploaded. Thanks. The Git repository is at: http://git.debian.org/?p=collab-maint/unetbootin.git;a=summary Btw, it doesn't work for me right now. I'm not sure, but git.debian.org seems to be down as of now. Alternative Git repo, if you want to check, is here: https://github.com/iammuneeb/unetbootin-debian P.S. You can me directly for subsequent upload requests. Sure, I'll keep that in mind from next time. :) -Muneeb -- 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/4f252606.1060...@gmail.com
Re: RFS: unetbootin
Hello Arno, On 2011-12-10 20:00, Arno Töll wrote: On 10.12.2011 19:19, Eugene V. Lyubimkin wrote: This is generally not a valid reason. For example, this makes it impossible to build the package on the system which has debhelper v7 installed, for no reason. Well, given that this requirement is fulfilled in Squeeze as is, and even newer backports are available to both, Squeeze and Lenny - despite of reaching end of life very soon for the latter that's not a strong argument. Yet this a regression, despite it's tiny size. It is perfectly fine for me if you require debhelper 7 as a personal requirement to sponsor packages No, I'm fine with debhelper v6 or v8 or whatever else remotely sane, given it's actually used for something. The change in question bumped the version without changing debian/rules and debian/compat. That's useless, isn't it? but I disagree with you if you claim that there would be no reason to use debhelper 8 at all. I didn't say so, see above. I fail to see why we would need to keep compatibility forever, if there is newer, better stuff available where some legacy problems can be avoided entirely or worked around (that's what debhelper's compat level is for, after all). If your package does not fail to build when using a modern, recommended compatibility level, why not use it? While I don't propose to use the same compatibility level forever, that sounds like oh nice, my package builds correctly with new shiny g++ 4.6, let's bump a build-dependency. Even if it builds fine with, say, g++ 4.2. One more example: -8- $ cupt depends akregator | grep libc6 Depends: libc6 (= 2.1.3) -8- Lenny has libc6 2.7. The idea of compatibility levels is to keep compatibility with old crap which is known to be broken. Not the other way around. Huh? So, packages which had a debhelper compat level of 7 in some Lenny/Squeeze development time were fine because 7 was the recommended compat level but they suddenly became old crap which is known to be broken now? For more background about that principle please refer to [1] [1] http://lists.debian.org/debian-mentors/2011/07/msg00194.html Oh, thanks for the link. I agree with the whole initial mail. Plus, let me quote Joey Hess [2] from that thread: | and | v8 This is the recommended mode of operation. | | This qualification is there mostly to avoid people using v9 before it's | complete; the only non-recommended compat levels are v4 and below, | which are deprecated. | | As a point of comparison, the compat histogram for packages I | co-maintain is: | | 124 7 | 65 | 38 | 24 | 19 | 16 [2] http://lists.debian.org/debian-mentors/2011/07/msg00228.html -- Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com C++/Perl developer, Debian Developer -- 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/20111211101141.GA3174@r500-debian
Re: RFS: unetbootin
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11.12.2011 11:11, Eugene V. Lyubimkin wrote: but I disagree with you if you claim that there would be no reason to use debhelper 8 at all. I didn't say so, see above. I'm sorry, you are right. One more example: -8- $ cupt depends akregator | grep libc6 Depends: libc6 (= 2.1.3) -8- Lenny has libc6 2.7. [..] Huh? So, packages which had a debhelper compat level of 7 in some Lenny/Squeeze development time were fine because 7 was the recommended compat level but they suddenly became old crap which is known to be broken now? you seem to misunderstand my argument. We have dependencies to express package relations. You (or dpkg-shlipdeps in this case) claims a program would need libc6 (= 2.1.3). It does so by determining the minimal version providing all symbols your program needs. That's all right and it would be an error to artificially raise any dependency without actual need to do so. Note, I was outlining debhelper's compatibility levels are a different case though. They aren't declaring any dependency - we already have a better method to express them, including build dependencies to a given debhelper version itself. Debhelper's compatibility level is an orthogonal approach. It's a promise that your build procedures do _not_ break when using certain features. If you are building a package with debhelper 8.9.something installed which has, say, debhelper compat 4, debhelper disables certain features, behaviors and so on it would use or enforce otherwise. It does not imply at all you would need debhelper 8.9.x to build it. Hence, I advertise people to use debhelper compat 8 in source packages where a package is known to work in that compatibility level. It does not mean Hey, my package needs debhelper 8.x, but My package is known to work with debhelper 8. For the same reason I discourage debhelper compatibility level 9 by the way. You can't guarantee your package won't break in that level as it is not finalized yet. In most cases you would still need to declare a build dependency for a given debhelper version because some features you use require it. That's not directly related to the compatibility levels though. The fact Lintian encourages you to raise the build depends of debhelper along your compatibility level is feasible, but not a real requirement in many cases. - -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJO5Mp0AAoJEMcrUe6dgPNtDTIQALNz/5oxasFGyt6MWkfPb3rF 1CgPhySQuJXtEZAGtcpcFYUH0oxhUfDih6zCp+p4tQ9EyvQGBomMlNEpPKREaoTl myixN0B4P04eoExj7hXxnbpRfRypCcGtM5SFfMoaqKTp1Jwv1RWRYd+sbLQ7dwQf ObU5laGnX+6WxeXmT7tlrGmHw0zX9D5fPTsTU/DisjUTqBppxNu71WLNUfZDFQSY 9sco8Qs/2BP6Rmx1nRC7KAC1iDGhwngVaW+G2afpZKI+e2k4LlKaoFRDNjiS44kt irGP2TjsIgEXocz2/8Kug5bm7yi23deXQXxS1Df433Q3FG8WUdAUJagLTkE/rU0V IDV8fF51r1Z7sn7ieGWeBP7qZPGW8S4N3hZu9OkIT0BRfDuoH8L7bfynv/8YER7q /gBELffzRxQqESD4xTHQdvihUpsdVgzp3Az4bd+xkYX43J2HN5ae17e80M0bgYIl ouYmcP2euwDzUThXNt3bHjjt7KjsRuJTavBEvpZ1rJJWj+mTYqqielwznHMBw9vM pp26hbMiM25v3nm+uT6s+S9A3G4xBTxLGSt97RMil0ixBOr+urMVxm6e5Jzt7zG4 khUde/yicPfQm0w44H1MOBmDUo0DXta09clvhs5UdOYvUEEe0QHGQvzv5XWsaOPh O+ssAsqM4OLW6tnS4aog =TPKP -END PGP SIGNATURE- -- 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/4ee4ca75.3080...@toell.net
bumping debhelper build-depends/compat (was: Re: RFS: unetbootin)
Hello, On 2011-12-11 16:21, Arno Töll wrote: Debhelper's compatibility level is an orthogonal approach. It's a promise that your build procedures do _not_ break when using certain features. If you are building a package with debhelper 8.9.something installed which has, say, debhelper compat 4, debhelper disables certain features, behaviors and so on it would use or enforce otherwise. [...] Right. Hence, I advertise people to use debhelper compat 8 in source packages where a package is known to work in that compatibility level. It does not mean Hey, my package needs debhelper 8.x, but My package is known to work with debhelper 8. [...] That's something I fine with, though didn't see such packages. But 'bumping a version in build-depends without bumping debian/compat and without using specific features in debian/rules' is another case. -- Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com C++/Perl developer, Debian Developer -- 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/20111211175904.GC3174@r500-debian
Re: RFS: unetbootin
Hi Muneeb, On 2011-12-08 03:50, Muneeb Shaikh wrote: dget -x http://mentors.debian.net/debian/pool/main/u/unetbootin/unetbootin_565-1.dsc 1) you bumped debhelper build-dependency version from 7 to 8, why? Also, changes like this should be always documented in debian/changelog. 2) you removed a build-dependency version of libqt4-dev (which was = 4.2). That's fine, but should me mentioned in the debian/changelog, preferrably with a short explanation why it should be safe. The Git repository us at: http://git.debian.org/?p=collab-maint/unetbootin.git;a=summary By the way, it's good you use a repository, but it's not good you merged all your debian/ changes into a single commit which is not easier to review than a .dsc. -- Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com C++/Perl developer, Debian Developer -- 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/20111210095304.GA6928@r500-debian
Re: RFS: unetbootin
On Sat, Dec 10, 2011 at 3:23 PM, Eugene V. Lyubimkin jac...@debian.org wrote: Hi Muneeb, On 2011-12-08 03:50, Muneeb Shaikh wrote: dget -x http://mentors.debian.net/debian/pool/main/u/unetbootin/unetbootin_565-1.dsc 1) you bumped debhelper build-dependency version from 7 to 8, why? Also, changes like this should be always documented in debian/changelog. Actually it's not required right away, but from future perspective I changed that. I was actually confused whether to include that in changelog. I'll do this from next releases. 2) you removed a build-dependency version of libqt4-dev (which was = 4.2). That's fine, but should me mentioned in the debian/changelog, preferrably with a short explanation why it should be safe. libqt4-dev doesn't need a version to be specified. So it was removed. Again due to confusion I didn't include. I'll take note of it. The Git repository us at: http://git.debian.org/?p=collab-maint/unetbootin.git;a=summary By the way, it's good you use a repository, but it's not good you merged all your debian/ changes into a single commit which is not easier to review than a .dsc. Actually I'm doing all the changes and testing in separate directory and if all works well, I apply those changes in Git repository. (it's fear of making mistake which restricts myself doing changes in Git repo ;) ) I'll try to commit changes as soon as I make some changes. I have made the changes according to the review and the new packages is at: http://mentors.debian.net/package/unetbootin The respective dsc file can be found at: http://mentors.debian.net/debian/pool/main/u/unetbootin/unetbootin_565-2.dsc The Git repository is at: http://git.debian.org/?p=collab-maint/unetbootin.git;a=summary -Muneeb -- 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/cafpklua7xkgx94wcnahcc1exledjdpd5yfm99ww0k14pzel...@mail.gmail.com
Re: RFS: unetbootin
Hi, The Git repository us at: http://git.debian.org/?p=collab-maint/unetbootin.git;a=summary By the way, it's good you use a repository, but it's not good you merged all your debian/ changes into a single commit which is not easier to review than a .dsc. Actually I'm doing all the changes and testing in separate directory and if all works well, I apply those changes in Git repository. (it's fear of making mistake which restricts myself doing changes in Git repo ;) ) Unlike Subversion `git commit` is local. You can do a lot of commits and changes in commits before push them into git server. For example: * you can edit commit (git commit --amend -a) if you think that it is bad * you can combine few commits * and etc... Moreover do not forget that you can have local and public branches. And this is the correct way of using git: master branch for completed things and temporary branches for working process. Git is very powerful. Just learn its features... Best regards, Boris -- 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/713131323527...@web85.yandex.ru
Re: RFS: unetbootin
On 12/10/2011 07:58 PM, Boris Pek wrote: Unlike Subversion `git commit` is local. You can do a lot of commits and changes in commits before push them into git server. For example: * you can edit commit (git commit --amend -a) if you think that it is bad * you can combine few commits * and etc... Moreover do not forget that you can have local and public branches. And this is the correct way of using git: master branch for completed things and temporary branches for working process. Git is very powerful. Just learn its features... Thanks Boris, Yes, Git is very powerful, I'm learning Git as well. I'm using branching, merging, rebasing features on my projects, but I'm just afraid of using them in unetbootin repo. But now I'll be trying to use these features. -Muneeb -- 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/4ee3791a.3020...@gmail.com
Re: RFS: unetbootin
On 2011-12-10 18:54, Muneeb Shaikh wrote: 1) you bumped debhelper build-dependency version from 7 to 8, why? Also, changes like this should be always documented in debian/changelog. Actually it's not required right away, but from future perspective I changed that. This is generally not a valid reason. For example, this makes it impossible to build the package on the system which has debhelper v7 installed, for no reason. In the changelog of 565-2 you wrote: Bumped debhelper version to 8 which should be required in future. Required by whom? In what future? I don't get what did you meant. Please explain (here in the list discussion). Or, alternatively, just revert this change. -- Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com C++/Perl developer, Debian Developer -- 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/20111210181916.GA10871@r500-debian
Re: RFS: unetbootin
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Eugene, On 10.12.2011 19:19, Eugene V. Lyubimkin wrote: This is generally not a valid reason. For example, this makes it impossible to build the package on the system which has debhelper v7 installed, for no reason. Well, given that this requirement is fulfilled in Squeeze as is, and even newer backports are available to both, Squeeze and Lenny - despite of reaching end of life very soon for the latter that's not a strong argument. In the changelog of 565-2 you wrote: Bumped debhelper version to 8 which should be required in future. Required by whom? In what future? I don't get what did you meant. Please explain (here in the list discussion). Or, alternatively, just revert this change. It is perfectly fine for me if you require debhelper 7 as a personal requirement to sponsor packages, but I disagree with you if you claim that there would be no reason to use debhelper 8 at all. We (and by we I mean I and some others) generally suggest people to use modern packaging styles when introducing new packages to Debian. And compat level 8 is what is recommended for new packages. I haven't looked at this package, so I don't know if there are actually any benefits to use 8 over 7, but that's not a reason not to do it. I fail to see why we would need to keep compatibility forever, if there is newer, better stuff available where some legacy problems can be avoided entirely or worked around (that's what debhelper's compat level is for, after all). If your package does not fail to build when using a modern, recommended compatibility level, why not use it? The idea of compatibility levels is to keep compatibility with old crap which is known to be broken. Not the other way around. For more background about that principle please refer to [1] [1] http://lists.debian.org/debian-mentors/2011/07/msg00194.html - -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJO46xUAAoJEMcrUe6dgPNtoOgP/Aj9czUZ3pALWNdy4P1u5bqO ia64ymob/ugTG3OC6rCLiJeabxGSXDOfIxDvpsn5X1W3sKHhUwgZEkx1gHGLB8Z7 vvT+eC/Oe1eXd8Nd7qLfh3J2RoH18m4szGRXD/ClcNNCdwqz0HB+7jef3zCzpUKP k/RRWYuoUzwsKs7Nhw2E5+Sskau6muno4g0PPZVF/CV+oeanzcstIHtg7N7z+PX7 /Kt3mJ75VwdLYGW8EbSvXk3/0yqzYlpOr7WwUP72c6FvOgl2ztlZYPmwgg1J+20a zSkYnZX9zIhfuhRuUjqDb2OtcFTNwubxCq077B9gQ/bB/4TePn8mm8C+8SETdTRC +2zYArrMCc4Iq2FHkv7OXNZcH1IHJTna5kPKkf9S1h1NqY+NvOZkiq9Bm7fGA+7H DPV8h/EvAZe4sv0rZQjqBWQs0ESGSQTNCHOXX2lF/bxAond0YeGlXF/yvJ+nEICh WXoYQOWZH2RS0dEGdB+l7Sxhmt3m0wNmCvntFmZQumvtw/Mvzt+/67AAQFxP+6gC aCil9+IbFv/rbcbMg5YaaGEeu7Jk5SxMvshb4LDTSGR2w0/4u0ymXp2iDPHqACtN 7O+tQ2uhrNcE7utcCiF2IznW4VLgfgQMasPNkNTgunw3MbvXEgeygb/AL4oHc9Sh JMPQclFzqk17dme5l81h =md5X -END PGP SIGNATURE- -- 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/4ee3ac54.3010...@toell.net
Re: RFS: unetbootin
On 12/10/2011 11:49 PM, Eugene V. Lyubimkin wrote: On 2011-12-10 18:54, Muneeb Shaikh wrote: 1) you bumped debhelper build-dependency version from 7 to 8, why? Also, changes like this should be always documented in debian/changelog. Actually it's not required right away, but from future perspective I changed that. This is generally not a valid reason. For example, this makes it impossible to build the package on the system which has debhelper v7 installed, for no reason. In the changelog of 565-2 you wrote: Bumped debhelper version to 8 which should be required in future. Required by whom? In what future? I don't get what did you meant. Please explain (here in the list discussion). Or, alternatively, just revert this change. Okay, According to the suggestion I have reverted back the change as it's not required. The new packages is at: http://mentors.debian.net/package/unetbootin The respective dsc file can be found at: http://mentors.debian.net/debian/pool/main/u/unetbootin/unetbootin_565-3.dsc The Git repository is at: http://git.debian.org/?p=collab-maint/unetbootin.git;a=summary -Muneeb -- 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/4ee3ef5b.5070...@gmail.com
[done] Re: RFS: unetbootin
On 2011-11-20 05:58, Muneeb Shaikh wrote: Point noted. I have bumped the debian revision, it's now 563-2. Uploaded. Thank you for the contribution. -- Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com C++/Perl developer, Debian Developer -- 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/2020090720.GA13146@r500-debian
Re: [done] Re: RFS: unetbootin
On Sun, Nov 20, 2011 at 2:37 PM, Eugene V. Lyubimkin jac...@debian.org wrote: On 2011-11-20 05:58, Muneeb Shaikh wrote: Point noted. I have bumped the debian revision, it's now 563-2. Uploaded. Thank you for the contribution. Thank you very much for sponsoring the package and getting it in debian. -- 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/CAFpKLuDqGCkqkN=enbngpq3mum6jxfysdo4viih3axq--5d...@mail.gmail.com
Re: RFS: unetbootin
Hi Muneeb, Here's my review: 1) debian/changelog should include the entry for already uploaded version 555-1; 2) you switched to a source format '3.0 (quilt)' but didn't mention this in the debian/changelog. I will upload the package if you fix these two. Note: I want a bumped Debian revision after an every review for packages that I sponsor. -- Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com C++/Perl developer, Debian Developer -- 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/2019165436.GH21037@r500-debian
Re: RFS: unetbootin
On Sat, Nov 19, 2011 at 10:24 PM, Eugene V. Lyubimkin jac...@debian.org wrote: Hi Muneeb, Hi Eugene, Here's my review: Thanks for the review. 1) debian/changelog should include the entry for already uploaded version 555-1; Oh sorry! I didn't notice the version in unstable. I just started working on the source from collab-maint thinking it as latest. Now added the entry from changelog of version 555-1 2) you switched to a source format '3.0 (quilt)' but didn't mention this in the debian/changelog. Fixed the changelog. I will upload the package if you fix these two. Note: I want a bumped Debian revision after an every review for packages that I sponsor. Point noted. I have bumped the debian revision, it's now 563-2. Package Information URL: http://mentors.debian.net/package/unetbootin Source Repository: http://anonscm.debian.org/gitweb/?p=collab-maint/unetbootin.git Please review the changes I have made. Thank you for your quick response. -Muneeb -- 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/CAFpKLuARaM6aT11k5n70FScOFoad4Nh=pv-r60tw2k19thp...@mail.gmail.com
[DONE] Re: RFS: unetbootin
Thanks for attention, I've found the sponsor. -- Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com Ukrainian C++ Developer, Debian APT contributor signature.asc Description: OpenPGP digital signature
