Bug#784854: RFS: gtk3-engines-unico/1.0.3+14.04.20140109+repack1-1 [ITA] [RC]
Hi Vincent, All right, thanks for the help too! Best, James On 16/06/2015 12:46 AM, Vincent Cheng wrote: On Mon, Jun 15, 2015 at 7:09 AM, James Lu glol...@hotmail.com wrote: Hi Vincent, Oops, I probably uploaded the wrong version. The get-orig-source target uses the date of the last debian/changelog entry to set timestamps, so I must've changed that without regenerating the tarball. Reuploaded, should be fixed now. Yep, looks good to me. Uploaded, thanks for your contribution to Debian! Regards, Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#784854: RFS: gtk3-engines-unico/1.0.3+14.04.20140109+repack1-1 [ITA] [RC]
Hi Vincent, Oops, I probably uploaded the wrong version. The get-orig-source target uses the date of the last debian/changelog entry to set timestamps, so I must've changed that without regenerating the tarball. Reuploaded, should be fixed now. Best, James On 14/06/2015 11:47 PM, Vincent Cheng wrote: Hi James, On Tue, Jun 9, 2015 at 4:55 PM, James Lu glol...@hotmail.com wrote: Hi Vincent, Wow, that's a lot of magic for one makefile target! I followed the guide, setting the file timestamps to the last changelog entry's date, and it works fine now. I've uploaded the newest version to mentors. Using your get-orig-source target, I still get an orig tarball with a different md5sum (178a964633a9ed23dad36bf2d6a5e9ef) compared to the tarball you've uploaded to mentors (d1ec1ce2db3cc38f89b07b643ad9d055). Regards, Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#784854: RFS: gtk3-engines-unico/1.0.3+14.04.20140109+repack1-1 [ITA] [RC]
Hi James, On Tue, Jun 9, 2015 at 4:55 PM, James Lu glol...@hotmail.com wrote: Hi Vincent, Wow, that's a lot of magic for one makefile target! I followed the guide, setting the file timestamps to the last changelog entry's date, and it works fine now. I've uploaded the newest version to mentors. Using your get-orig-source target, I still get an orig tarball with a different md5sum (178a964633a9ed23dad36bf2d6a5e9ef) compared to the tarball you've uploaded to mentors (d1ec1ce2db3cc38f89b07b643ad9d055). Regards, Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#784854: RFS: gtk3-engines-unico/1.0.3+14.04.20140109+repack1-1 [ITA] [RC]
Hi James, On Mon, Jun 8, 2015 at 5:51 PM, James Lu glol...@hotmail.com wrote: Hi Vincent, I've removed bzr from the build dependencies. After fiddling with the get-orig-source a bit, I realized that I can't get the same checksum either when running it multiple times. According to a 'diff' of 'tar -tvf' output, the only difference between these generated tarballs was the source files' timestamps. This is probably because bzr is used to fetch the sources every time get-orig-source is ran, and it saves the current time (of checkout) as the timestamp of the files, instead of the code's modification date. For this, there appears to be a wishlist bug filed: https://bugs.launchpad.net/bzr/+bug/245170 The reproducible builds team has a list of suggested workarounds for various causes of non-reproducibility, one of which is timestamps in generated tarballs. See [1] for a fairly simple way of making your get-orig-source target reproducible. Regards, Vincent [1] https://wiki.debian.org/ReproducibleBuilds/TimestampsInTarball -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#784854: RFS: gtk3-engines-unico/1.0.3+14.04.20140109+repack1-1 [ITA] [RC]
Hi Vincent, Wow, that's a lot of magic for one makefile target! I followed the guide, setting the file timestamps to the last changelog entry's date, and it works fine now. I've uploaded the newest version to mentors. James On 08/06/15 11:36 PM, Vincent Cheng wrote: Hi James, On Mon, Jun 8, 2015 at 5:51 PM, James Lu glol...@hotmail.com wrote: Hi Vincent, I've removed bzr from the build dependencies. After fiddling with the get-orig-source a bit, I realized that I can't get the same checksum either when running it multiple times. According to a 'diff' of 'tar -tvf' output, the only difference between these generated tarballs was the source files' timestamps. This is probably because bzr is used to fetch the sources every time get-orig-source is ran, and it saves the current time (of checkout) as the timestamp of the files, instead of the code's modification date. For this, there appears to be a wishlist bug filed: https://bugs.launchpad.net/bzr/+bug/245170 The reproducible builds team has a list of suggested workarounds for various causes of non-reproducibility, one of which is timestamps in generated tarballs. See [1] for a fairly simple way of making your get-orig-source target reproducible. Regards, Vincent [1] https://wiki.debian.org/ReproducibleBuilds/TimestampsInTarball -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#784854: RFS: gtk3-engines-unico/1.0.3+14.04.20140109+repack1-1 [ITA] [RC]
Hi Vincent, I've removed bzr from the build dependencies. After fiddling with the get-orig-source a bit, I realized that I can't get the same checksum either when running it multiple times. According to a 'diff' of 'tar -tvf' output, the only difference between these generated tarballs was the source files' timestamps. This is probably because bzr is used to fetch the sources every time get-orig-source is ran, and it saves the current time (of checkout) as the timestamp of the files, instead of the code's modification date. For this, there appears to be a wishlist bug filed: https://bugs.launchpad.net/bzr/+bug/245170 Best, James On 07/06/15 11:17 PM, Vincent Cheng wrote: Hi James, (Sorry for the late reply!) On Tue, May 19, 2015 at 11:28 AM, James Lu glol...@hotmail.com wrote: Hello Vincent, Okay, I've uploaded a newer version of the package that should fix the problems you mentioned. Earlier, I was trying to manually sync up both Karolina's and upstream's debian/ folders (they had different content, like build-dep versions, etc.), and I must have missed the watch file. I also added a get-orig-source to debian/rules, which pulls the revision from Launchpad bzr, removes the INSTALL symlink, and then repacks. debian/clean is removed and the changelog is also more verbose now. You don't need to declare a build-dep on bzr because it's only used by d/rules get-orig-source, not during the build itself (to be precise, Policy §7.7 specifies the specific d/rules targets in which the dependencies listed in various d/control fields must be satisfied to invoke them; get-orig-source is not one of these targets), so please remove bzr from your build-deps. The orig tarball you've uploaded to mentors seems to differ from a tarball that I've generated locally using your get-orig-source target (i.e. hashsums don't match). Regards, Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#784854: RFS: gtk3-engines-unico/1.0.3+14.04.20140109+repack1-1 [ITA] [RC]
Hi James, (Sorry for the late reply!) On Tue, May 19, 2015 at 11:28 AM, James Lu glol...@hotmail.com wrote: Hello Vincent, Okay, I've uploaded a newer version of the package that should fix the problems you mentioned. Earlier, I was trying to manually sync up both Karolina's and upstream's debian/ folders (they had different content, like build-dep versions, etc.), and I must have missed the watch file. I also added a get-orig-source to debian/rules, which pulls the revision from Launchpad bzr, removes the INSTALL symlink, and then repacks. debian/clean is removed and the changelog is also more verbose now. You don't need to declare a build-dep on bzr because it's only used by d/rules get-orig-source, not during the build itself (to be precise, Policy §7.7 specifies the specific d/rules targets in which the dependencies listed in various d/control fields must be satisfied to invoke them; get-orig-source is not one of these targets), so please remove bzr from your build-deps. The orig tarball you've uploaded to mentors seems to differ from a tarball that I've generated locally using your get-orig-source target (i.e. hashsums don't match). Regards, Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#784854: RFS: gtk3-engines-unico/1.0.3+14.04.20140109+repack1-1 [ITA] [RC]
Hello Vincent, Okay, I've uploaded a newer version of the package that should fix the problems you mentioned. Earlier, I was trying to manually sync up both Karolina's and upstream's debian/ folders (they had different content, like build-dep versions, etc.), and I must have missed the watch file. I also added a get-orig-source to debian/rules, which pulls the revision from Launchpad bzr, removes the INSTALL symlink, and then repacks. debian/clean is removed and the changelog is also more verbose now. Best, James On 18/05/2015 2:33 PM, Vincent Cheng wrote: Control: owner -1 ! On Sat, May 9, 2015 at 9:04 AM, James Lu glol...@hotmail.com wrote: Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package gtk3-engines-unico. This upload fixes an RC bug that caused GTK3 applications to crash with any theme that uses the Unico engine, along with some other graphics rendering bugs (tested with GTK 3.14). Ok, now that the package's orphaned status has been clarified, here's a more thorough review: Please be more verbose in d/changelog (w.r.t. your changes to d/control, e.g. like adding/removing build-deps/deps/pre-deps). debian/rules is missing a get-orig-source target, which is described in Policy §4.9 [1]. It's not mandatory as per Policy, but since you also aren't including a debian/watch file (BTW, why did you remove it?), it's harder for others to verify your orig tarball (and I consider one or the other mandatory when sponsoring packages). debian/clean should be redundant now. Regards, Vincent [1] https://www.debian.org/doc/debian-policy/ch-source.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#784854: RFS: gtk3-engines-unico/1.0.3+14.04.20140109+repack1-1 [ITA] [RC]
Control: owner -1 ! On Sat, May 9, 2015 at 9:04 AM, James Lu glol...@hotmail.com wrote: Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package gtk3-engines-unico. This upload fixes an RC bug that caused GTK3 applications to crash with any theme that uses the Unico engine, along with some other graphics rendering bugs (tested with GTK 3.14). Ok, now that the package's orphaned status has been clarified, here's a more thorough review: Please be more verbose in d/changelog (w.r.t. your changes to d/control, e.g. like adding/removing build-deps/deps/pre-deps). debian/rules is missing a get-orig-source target, which is described in Policy §4.9 [1]. It's not mandatory as per Policy, but since you also aren't including a debian/watch file (BTW, why did you remove it?), it's harder for others to verify your orig tarball (and I consider one or the other mandatory when sponsoring packages). debian/clean should be redundant now. Regards, Vincent [1] https://www.debian.org/doc/debian-policy/ch-source.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#784854: RFS: gtk3-engines-unico/1.0.3+14.04.20140109+repack1-1 [ITA] [RC]
Hello Vincent, I have uploaded a new manually packed tarball of the Bzr trunk, with version 1.0.3+bzr152-1 instead of the +14.04.20140109 Ubuntu had in its repository. I didn't make that clear, but a bad version number could accidentally replace the package they have AFAIK. As for the package truly being orphaned, I assume that the people who filed the report already knew what was going on. The LDAP database didn't find anything for Karolina Kalic or karol...@resenje.org, and the package has been orphaned for almost 2 years now. Two of their packages appear to have new maintainers already https://qa.debian.org/developer.php?login=karolina%40resenje.org (curtain and spotlighter). Either way, I'll Cc them on this conversation now. I'm not sure what has been done already, and what still has to be done. Best, James On 12/05/2015 1:09 AM, Vincent Cheng wrote: Control: tag -1 + moreinfo Hi James, On Sun, May 10, 2015 at 11:52 AM, James Lu glol...@hotmail.com wrote: Hi, Okay. Forget what I said about quilt, I don't think it'd fix this particular issue either. Right now, the problem is in the original source (aka the .orig.tar). The INSTALL file isn't even installed in the final binary, but just having a symlink in the original source is enough to make Lintian complain. Adding a debian/clean file only removes the INSTALL file from the extracted tree, but not the .orig.tar.gz. I could add a Lintian override if this is appropriate. Just from what you've said above, I'd ignore the lintian error entirely; if INSTALL is never used during the build process or installed into any of the binary packages produced by your source package, then source-contains-unsafe-symlink is quite harmless. It _is_ a valid lintian error though, since the orig tarball upstream presumably contains an INSTALL file symlinked above the root of the source package, and removing it via debian/clean doesn't change that. Where did you obtain this orig tarball? I can't seem to find a tarball versioned as 1.0.3+14.04.20140109 at [1]; if you actually are rolling your own tarball instead of using one provided upstream, then why not get rid of that symlink in your tarball? Also, this may seem to be a formality, but is this package actually orphaned? Neither the maintainer nor the MIA team filed #717044; a random user deciding to ITA the package out of the blue is more or less hijacking the package. Please follow the steps outlined in devref 5.9.4/5.9.5 [2] to properly orphan a package and adopt it. Regards, Vincent [1] https://launchpad.net/unico [2] https://www.debian.org/doc/manuals/developers-reference/pkgs.html#orphaning
Bug#784854: RFS: gtk3-engines-unico/1.0.3+14.04.20140109+repack1-1 [ITA] [RC]
Hi James, On Sun, May 17, 2015 at 5:13 PM, James Lu glol...@hotmail.com wrote: Hello Vincent, I have uploaded a new manually packed tarball of the Bzr trunk, with version 1.0.3+bzr152-1 instead of the +14.04.20140109 Ubuntu had in its repository. I didn't make that clear, but a bad version number could accidentally replace the package they have AFAIK. Ok, that works. BTW, I still don't see where you're getting this +14.04.20140109 tarball from. Ubuntu simply doesn't have this version packaged [1] in its repository (I haven't checked PPAs, but they aren't relevant to this discussion), so I'm afraid I don't understand why you're worried about a version number collision here. As for the package truly being orphaned, I assume that the people who filed the report already knew what was going on. The LDAP database didn't find anything for Karolina Kalic or karol...@resenje.org, and the package has been orphaned for almost 2 years now. Two of their packages appear to have new maintainers already (curtain and spotlighter). Either way, I'll Cc them on this conversation now. I'm not sure what has been done already, and what still has to be done. Again, please follow the instructions mentioned in devref 5.9.5, Adopting a package [2], i.e. contact the MIA team. Regards, Vincent [1] https://launchpad.net/ubuntu/+source/gtk3-engines-unico [2] https://www.debian.org/doc/manuals/developers-reference/pkgs.html#orphaning -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#784854: RFS: gtk3-engines-unico/1.0.3+14.04.20140109+repack1-1 [ITA] [RC]
Hi Dmitry, On Sun, May 17, 2015 at 9:29 PM, Dmitry Smirnov only...@debian.org wrote: and the package has been orphaned for almost 2 years now. Two of their packages appear to have new maintainers already https://qa.debian.org/developer.php?login=karolina%40resenje.org (curtain and spotlighter). It looks like she did not do anything about critical bug #706330 since 2013-07-17 which IMHO justifies takeover because she is obviously not active or at least appears to be not on top of her maintainer's duties... I would assign ITA bug to the package, express my intention to take over to the bug and to current maintainer, wait for some time and eventually proceed with upload (provided that everything is OK with packaging and there are no objections from maintainer). I'd argue that the right approach is still to contact the MIA team and ask them to investigate and reach out to the supposedly missing maintainer. The thing is, either way (MIA team involved, or not) you'd usually want to wait an indeterminate amount of time for the old maintainer to reply before giving up anyways, so you may as well just follow the devref guidelines. The MIA team is fairly active AFAIK, and it's just a matter of sending a brief email to m...@qa.debian.org to get the ball rolling. Regards, Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#784854: RFS: gtk3-engines-unico/1.0.3+14.04.20140109+repack1-1 [ITA] [RC]
Hi Vincent, On Sun, 17 May 2015 21:36:22 Vincent Cheng wrote: I'd argue that the right approach is still to contact the MIA team and ask them to investigate and reach out to the supposedly missing maintainer. The thing is, either way (MIA team involved, or not) you'd usually want to wait an indeterminate amount of time for the old maintainer to reply before giving up anyways, so you may as well just follow the devref guidelines. The MIA team is fairly active AFAIK, and it's just a matter of sending a brief email to m...@qa.debian.org to get the ball rolling. No objections from me. :) I just wanted to mention another approach to friendly takeover for unmaintained packages... As I recall it was discussed in debian-devel (and/or debian-qa) a while ago and I've seen it in practice. Of course contacting MIA team won't hurt. Thanks for reminding about it. -- Regards, Dmitry Smirnov. --- Success consists of going from failure to failure without loss of enthusiasm. -- Winston Churchill signature.asc Description: This is a digitally signed message part.
Bug#784854: RFS: gtk3-engines-unico/1.0.3+14.04.20140109+repack1-1 [ITA] [RC]
Hi James, I'm unable to review your packaging at this time. On Sun, 17 May 2015 17:13:34 James Lu wrote: As for the package truly being orphaned, I assume that the people who filed the report already knew what was going on. No he did not know. #717044 was filed by person who is not a Debian Developer and not even Debian Maintainer. Clearly he is not familiar with orphaning procedure... The LDAP database didn't find anything for Karolina Kalic or karol...@resenje.org, This is expected as she is also not a Debian Developer. Database is only for official members of Debian project and it does not list all contributors. However there is some scarce information here: https://contributors.debian.org/contributor/karolina-guest%40alioth and the package has been orphaned for almost 2 years now. Two of their packages appear to have new maintainers already https://qa.debian.org/developer.php?login=karolina%40resenje.org (curtain and spotlighter). It looks like she did not do anything about critical bug #706330 since 2013-07-17 which IMHO justifies takeover because she is obviously not active or at least appears to be not on top of her maintainer's duties... I would assign ITA bug to the package, express my intention to take over to the bug and to current maintainer, wait for some time and eventually proceed with upload (provided that everything is OK with packaging and there are no objections from maintainer). Either way, I'll Cc them on this conversation now. I'm not sure what has been done already, and what still has to be done. Good. -- Cheers, Dmitry Smirnov. --- Every decent man is ashamed of the government he lives under. -- H. L. Mencken signature.asc Description: This is a digitally signed message part.
Bug#784854: RFS: gtk3-engines-unico/1.0.3+14.04.20140109+repack1-1 [ITA] [RC]
Control: tag -1 + moreinfo Hi James, On Sun, May 10, 2015 at 11:52 AM, James Lu glol...@hotmail.com wrote: Hi, Okay. Forget what I said about quilt, I don't think it'd fix this particular issue either. Right now, the problem is in the original source (aka the .orig.tar). The INSTALL file isn't even installed in the final binary, but just having a symlink in the original source is enough to make Lintian complain. Adding a debian/clean file only removes the INSTALL file from the extracted tree, but not the .orig.tar.gz. I could add a Lintian override if this is appropriate. Just from what you've said above, I'd ignore the lintian error entirely; if INSTALL is never used during the build process or installed into any of the binary packages produced by your source package, then source-contains-unsafe-symlink is quite harmless. It _is_ a valid lintian error though, since the orig tarball upstream presumably contains an INSTALL file symlinked above the root of the source package, and removing it via debian/clean doesn't change that. Where did you obtain this orig tarball? I can't seem to find a tarball versioned as 1.0.3+14.04.20140109 at [1]; if you actually are rolling your own tarball instead of using one provided upstream, then why not get rid of that symlink in your tarball? Also, this may seem to be a formality, but is this package actually orphaned? Neither the maintainer nor the MIA team filed #717044; a random user deciding to ITA the package out of the blue is more or less hijacking the package. Please follow the steps outlined in devref 5.9.4/5.9.5 [2] to properly orphan a package and adopt it. Regards, Vincent [1] https://launchpad.net/unico [2] https://www.debian.org/doc/manuals/developers-reference/pkgs.html#orphaning -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#784854: RFS: gtk3-engines-unico/1.0.3+14.04.20140109+repack1-1 [ITA] [RC]
Hi, Okay. Forget what I said about quilt, I don't think it'd fix this particular issue either. Right now, the problem is in the original source (aka the .orig.tar). The INSTALL file isn't even installed in the final binary, but *just having a symlink in the original source is enough to make Lintian complain*. Adding a debian/clean file only removes the INSTALL file from the extracted tree, but not the .orig.tar.gz. I could add a Lintian override if this is appropriate. James On 09/05/2015 10:24 PM, Dmitry Smirnov wrote: On Sat, 9 May 2015 19:19:22 James Lu wrote: Hi, Did you try removing symlink from debian/clean file? debian/clean? I don't see that mentioned anywhere in the New Maintainers guide https://www.debian.org/doc/manuals/maint-guide/index.en.html. It is a part of debhelper suite. See dh_clean(1). What does it have to do with quilt? I was trying to use a quilt patch to replace the symlink with a copy of the regular file, but that didn't work. I don't know what the regular practice is for situations like this. I did not look into your packaging but why not just ignore symlink and install original file? Or replace symlink from override_dh_install? Repacking orig.tar to drop symlink in unnecessary...
Bug#784854: RFS: gtk3-engines-unico/1.0.3+14.04.20140109+repack1-1 [ITA] [RC]
On Sat, 9 May 2015 09:04:39 James Lu wrote: One small note: the tarball was repacked in order to remove the INSTALL symlink, which quilt didn't seem to handle properly (it just reported no files changed). Did you try removing symlink from debian/clean file? Wouldn't it be easier than repacking? What does it have to do with quilt? Thanks. -- Best wishes, Dmitry Smirnov signature.asc Description: This is a digitally signed message part.
Bug#784854: RFS: gtk3-engines-unico/1.0.3+14.04.20140109+repack1-1 [ITA] [RC]
Hi, Did you try removing symlink from debian/clean file? debian/clean? I don't see that mentioned anywhere in the New Maintainers guide https://www.debian.org/doc/manuals/maint-guide/index.en.html. What does it have to do with quilt? I was trying to use a quilt patch to replace the symlink with a copy of the regular file, but that didn't work. I don't know what the regular practice is for situations like this. Regards, James On 09/05/2015 6:40 PM, Dmitry Smirnov wrote: On Sat, 9 May 2015 09:04:39 James Lu wrote: One small note: the tarball was repacked in order to remove the INSTALL symlink, which quilt didn't seem to handle properly (it just reported no files changed). Did you try removing symlink from debian/clean file? Wouldn't it be easier than repacking? What does it have to do with quilt? Thanks.
Bug#784854: RFS: gtk3-engines-unico/1.0.3+14.04.20140109+repack1-1 [ITA] [RC]
On Sat, 9 May 2015 19:19:22 James Lu wrote: Hi, Did you try removing symlink from debian/clean file? debian/clean? I don't see that mentioned anywhere in the New Maintainers guide https://www.debian.org/doc/manuals/maint-guide/index.en.html. It is a part of debhelper suite. See dh_clean(1). What does it have to do with quilt? I was trying to use a quilt patch to replace the symlink with a copy of the regular file, but that didn't work. I don't know what the regular practice is for situations like this. I did not look into your packaging but why not just ignore symlink and install original file? Or replace symlink from override_dh_install? Repacking orig.tar to drop symlink in unnecessary... -- Cheers, Dmitry Smirnov. --- Not a lack of belief, but adherence to false knowledge is the enemy of progress. And certain that we have found everything worth searching for, we see no point in further search and inquiry. Believing what is unworthy of belief, believing falsehood as if it were incontrovertible truth, and sure that we know everything we will ever need to know, we are worse than ignorant. -- Chester Dolan, Blind Faith signature.asc Description: This is a digitally signed message part.
Bug#784854: RFS: gtk3-engines-unico/1.0.3+14.04.20140109+repack1-1 [ITA] [RC]
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package gtk3-engines-unico. This upload fixes an RC bug that caused GTK3 applications to crash with any theme that uses the Unico engine, along with some other graphics rendering bugs (tested with GTK 3.14). * Package name: gtk3-engines-unico Version : 1.0.3+14.04.20140109+repack1-1 Upstream Author : Ubuntu Core Developers ubuntu-devel-disc...@lists.ubuntu.com * URL : https://launchpad.net/unico * License : GNU LGPL v3 / 2.1?? (The Launchpad page says LGPL 3, but the source code still says LGPL 2.1, so I kept the latter in packaging) Section : x11 It builds those binary packages: gtk3-engines-unico - Unico Gtk+ 3 theme engine To access further information about this package, please visit the following URL: http://mentors.debian.net/package/gtk3-engines-unico Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/g/gtk3-engines-unico/gtk3-engines-unico_1.0.3+14.04.20140109+repack1-1.dsc More information about gtk3-engines-unico can be obtained from https://launchpad.net/unico. Changes since the last upload: gtk3-engines-unico (1.0.3+14.04.20140109+repack1-1) unstable; urgency=medium * New upstream snapshot, forked from Ubuntu (Closes: #671936, #690278, #695267). * New maintainer. (Closes: #717044) * Repack tarball in order to remove the INSTALL symlink in the root folder, fixing Lintian error unsafe-symlink-in-source. * Update Standards Version to 3.9.6. -- James Lu glol...@hotmail.com Fri, 08 May 2015 17:40:58 -0700 One small note: the tarball was repacked in order to remove the INSTALL symlink, which quilt didn't seem to handle properly (it just reported no files changed). Regards, James Lu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
