Re: RFS: golang-github-pkg-diff/0.0~git20200914.5b29258-1 [ITP] -- go library used to create, modify, and print diffs
On Mon, Mar 8, 2021 at 6:50 AM Faustin Lammler wrote: > > Package: sponsorship-requests > Severity: normal > > Dear mentors, > > I am looking for a sponsor for my package "golang-github-pkg-diff": > > * Package name: golang-github-pkg-diff >Version : 0.0~git20200914.5b29258-1 >Upstream Author : Josh Bleecher Snyder > * URL : https://github.com/pkg/diff > * License : BSD-3-clause > * Vcs : > https://salsa.debian.org/go-team/packages/golang-github-pkg-diff >Section : golang > > It builds this library: > > golang-github-pkg-diff - go library used to create, modify, and print diffs > > To access further information about this package, please visit the following > URL: > > https://mentors.debian.net/package/golang-github-pkg-diff/ > > Alternatively, one can download the package with dget using this command: > > dget -x > https://mentors.debian.net/debian/pool/main/g/golang-github-pkg-diff/golang-github-pkg-diff_0.0~git20200914.5b29258-1.dsc > > Changes since the last upload: > > * Initial release (Closes: #982472) > > Regards, > > -- > Faustin Lammler > - > GPG: F652 BCD1 1AA8 8975 F010 48A5 390A 2F27 832A 5C79 Hello Faustin, Thank you for your great work! Were you able to find a sponsor for your golang-github-pkg-diff package? If not, I'd love to sponsor and upload it for you! Partly because I need that package too. :-) Even though I could no longer find the package at https://mentors.debian.net/package/golang-github-pkg-diff/, I am glad that you did push your work to https://salsa.debian.org/go-team/packages/golang-github-pkg-diff, from which I think I could try and sponsor your package. Is that OK with you? Please let me know! Cheers, Anthony
Bug#867544: RFS: golang-github-xiaq-persistent/0.0~git20170614.0.06adb7b-1 [ITP]
On Sun, Jul 9, 2017 at 9:05 PM, Shengjing Zhu wrote: > Thanks for review. > > On Mon, Jul 10, 2017 at 10:08:22AM +0800, ChangZhuo Chen wrote: >> * Please change the short name of Eclipse Public License 1.0 from >> `EPL-10` to `EPL-1.0` to avoid confusion. > > Changed, > https://anonscm.debian.org/cgit/pkg-go/packages/golang-github-xiaq-persistent.git/commit/?id=bf9c92d > >> * Please fix the following lintian warning. >> >> W: golang-github-xiaq-persistent source: unknown-testsuite >> autopkgtest-pkg-go > autopkgtest-pkg-go in d/control is generated by dh-make-golang, > https://github.com/Debian/dh-make-golang/pull/60 > I think we should keep it as is. I asked on #debian-golang whether we > should file a issue about lintian, but haven't got a reply. Hi! I am part of the pkg-go team, and am learning about the new "Testsuite: autopkgtest-pkg-go" myself. What I have learned thus far is that a senior member of the pkg-go team has set up some kind of CI server that would check for "Testsuite: autopkgtest-pkg-go" and automatically run the tests for it, so it is correct the way it is, and has made it into dh-make-golang. Of course, the documentation for Testsuite, as well as the corresponding Lintian test, will need to be updated. But for now, I wouldn't worry about this Lintian warning, as in personally I wouldn't even bother putting in a Lintian override for it. I'm sure the pkg-go team will deal with all these (Testsuite documentation and Lintian warning) soon enough. :-) > Best regards, > Shengjing Zhu Thank you for your contribution! :-) Cheers, Anthony
Re: RFS: mailscanner (updated package)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Simon, Simon Walter wrote: > Dear mentors, > > I am looking for a sponsor for the new version 4.68.8-1 > of my package "mailscanner". > > It builds these binary packages: > mailscanner - email gateway for virus scanning, spam and phishing detection > > The package appears to be lintian clean. > > The upload would fix these bugs: 469916, 472067, 472489, 472676 > > The package can be found on mentors.debian.net: > - URL: http://mentors.debian.net/debian/pool/main/m/mailscanner > - Source repository: deb-src http://mentors.debian.net/debian unstable main > contrib non-free > - dget > http://mentors.debian.net/debian/pool/main/m/mailscanner/mailscanner_4.68.8-1.dsc > > I would be glad if someone uploaded this package for me. > > Kind regards > Simon Walter I built your package with pdebuild and uploaded it too on April 5th at around 10 a.m. Beijing time, and apparently it is already in the mirrors. Next time I should try to announce it ASAP to avoid duplication of work. (Sorry, Noèl!) I do have a comment about your source mailscanner_4.68.8.orig.tar.gz though. The files therein are owned by thargor (your username right?), so I assume you have repackaged the upstream source tarball yourself. If I'm not mistaken, the original "pristine" upstream source is this: MailScanner-install-4.68.8/perl-tar/MailScanner-4.68.8-1.tar.gz from http://mailscanner.info/files/4/tar/MailScanner-install-4.68.8-1.tar.gz Since the contents within the upstream MailScanner-4.68.8-1.tar.gz and your repackaged mailscanner_4.68.8.orig.tar.gz are entirely identical, I think using pristine source is best practice. Please read "Section 6.7.8 Best practices for orig.tar.gz files" in the Debian Developer's Reference: http://www.debian.org/doc/developers-reference/ch-best-pkging-practices.en.html MailScanner-install-4.68.8/perl-tar/MailScanner-4.68.8-1.tar.gz file (at least for 4.68.8 version) fits the criteria for pristine upstream source, so instead of unpacking it and re-compressing it, I recommend simply copying or renaming MailScanner-4.68.8-1.tar.gz to mailscanner_4.68.8.orig.tar.gz . So yes, for your next upload of new upstream release, please try your best to use upstream pristine source. You may want to update debian/copyright a bit as well (e.g. change 2002-2007 to 2002-2008). Many thanks! :-) Anthony Fok -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH+PKZLa8qZm1n95ARAmVXAJ4lGpBafzBpM76gXWtDFlszyNNhpwCgkULB jopLGmVJFEMyVb5Go/8mnFs= =ZUfY -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: manpages-zh 1.5.1-1: chinese manual page
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Daobing, LI Daobing wrote: > Hello, > > I adopt manpages-zh from Carlos Z.F. Liu[1]. in this version, hunderds > of lintian warnings are all fixed[2]. and 3 of the 4 bugs[3] is > closes(one wishlist items left). please help check and upload manpage, > thanks. > > you can use following command to download the package: > 'dget > http://mentors.debian.net/debian/pool/main/m/manpages-zh/manpages-zh_1.5.1-1.dsc' > > [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=465552 > [2] http://lintian.debian.org/reports/maintainer/[EMAIL PROTECTED] > [3] http://bugs.debian.org/manpages-zh > Built with pdebuild and uploaded. Cheers, Anthony Fok -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH+N+KLa8qZm1n95ARAgDgAJ4sZEpAgqeptr9h4VGGr8gJJBbt/ACeKW0M EI9eeUn2jtxfnc5wCLXxo6o= =xxyB -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: lunar-applet
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Daobing! Thank you for contributing to Chinese i18n and Debian! LI Daobing wrote: > -- Forwarded message -- > From: LI Daobing <[EMAIL PROTECTED]> > Date: Aug 1, 2007 11:53 AM > Subject: RFS: lunar-applet > To: debian-mentors@lists.debian.org> > > Dear mentors, > > I am looking for a sponsor for my package "lunar-applet". I'd love to sponsor your package. I discovered your package by accident, and I'm enjoying it very much! Finally, an open-source calendar applet with Chinese lunar calendar! :-) Meanwhile, please note that even your package is Lintian free, I'd like to pay attention to the fine details including English. So, please don't mind me being really picky and requesting you to change a bunch of stuff before actually uploading your package to the Debian archive. :-) Also, the problems I point out below (e.g. English wording) are very common encountered by Chinese developers, so I hope this "critique" will be helpful for other new Chinese Debian maintainers too. :-) > * Package name: lunar-applet > Version : 1.5-1 I see that 1.6 is just out, so please package that and upload again. :-) > Upstream Author : Wu Xiaotian <[EMAIL PROTECTED]> > * URL : http://ftp.inlsd.org/lunar-applet/ > * License : GPL > Section : gnome > It builds these binary packages: > lunar-applet - A GNOME Timer applet replacement Issue 1. Revising the packaging description === This is *not* a GNOME Timer applet replacement. A "timer" is "计时器", not "时钟". Indeed, there is already a package called "timer-applet" which is "a countdown timer applet for the GNOME panel". (那是个倒计时器，不是日历。) lunar-applet is actually based on the GNOME Clock applet inside the Debian gnome-panel package. /usr/lib/gnome-panel/libclock-applet.so The fact that it replaces the GNOME Clock Applet is much less important than the fact that it supports the Chinese lunar calendar! And just so that the user doesn't guess wildly that it is a "lunar moon-phase applet" like "glunarclock" the GNOME Lunar Clock moon applet, or that it might be an Islamic lunar calendar applet, you'll make that very clear in the single-line synopsis. So, I'd suggest something like the following: GNOME Clock applet with added Chinese lunar calendar support As for the extended description: It provides the chinese traditional(lunar) calendar. . Homepage: http://dev.inlsd.org/projects/lunar-applet/wiki I have the following comments: 1. It is a little bit too short. Don't treat the single-line synopsis as part of the extended description. It is not. See the Debian Policy Manual section 3.4 and 3.4.2 for details. 2. The word "Chinese" is a "proper noun" (专有名词), or in this case, an adjective derived from the proper noun. Besides, we Chinese are great people! Be proud of ourselves and our heritage! :-) Always spell this word with a capital "C"! (必须首字大写) 3. Punctuation rule: Always add a space before the opening parenthesis to separate it from preceding text. (西文开括号和前文之间必须有空格) Here is my try at it: - lunar-applet displays the Chinese lunar calendar and the current date and time as an applet for the GNOME panel. It is based on the GNOME Clock Applet and may be used as a drop-in replacement. . Homepage: http://dev.inlsd.org/projects/lunar-applet/wiki - My English is not that good either, so I borrowed some phrasing from the glunarclock package description. :-) Note that I removed the word "traditional" because it seems that most English speaking people already know what the Chinese lunar calendar is. You may try a Google search on the three words: Chinese lunar calendar and you'll see what I mean. :-) Issue 2: Evolution support == I was intrigued by the GNOME Clock Applet replacement idea, so I ran both GNOME Clock Applet and lunar-applet side-by-side, and noticed that lunar-applet didn't display the Evolution Task/Todo list. --enable-edsEnable evolution-data-server dependencies So, I checked in configure.ac and found that the build process checks for the presence of libecal1.2-dev and libedataserverui1.2-dev. I'm not familiar with CDBS, so I checked the CDBS documentation and the rules from the gnome-panel Debian source package, and found something like the following in debian/rules: DEB_CONFIGURE_EXTRA_FLAGS += --disable-scrollkeeper ifneq ($(DEB_BUILD_GNU_SYSTEM),gnu) DEB_CONFIGURE_EXTRA_FLAGS += --enable-eds endif Issue 3: lunar-applet is derived from GNOME Panel and "lunar" Which is perfectly OK because both "gnome-panel" and "lunar" are GP
Re: Warning: Me, too! (was Re: NM : Dale Scheetz : is NM working
Hello Jim, On Tue, Jun 27, 2000 at 01:27:02PM -0700, Jim Westveer wrote: > Yes the New Maintainer process is alive and well. > [...] > There are currently 25+ voulenteers working as Application Managers (AM's) > working the applications, and as we get used to the processes that > have been set into place, things will hopefully go more quickly. > > Again, please be patient. This is a big task. That's great news, and thank you for all your hard work. :-) I hope I wasn't being too selfish for asking the Chinese developers to be given priority. :-) Nonetheless, your message gave me an idea: Would it be possible for me to volunteer as an Application Manager to process the three Chinese developers-to-be? Afterall, we've got to know each other quite well from discussions on the mailing list. :-) If it is okay, please give me a pointer (http://nm.debian.org/ ?) so I can get started. :-) Thanks, Anthony -- Anthony Fok Tung-LingCivil and Environmental Engineering [EMAIL PROTECTED], [EMAIL PROTECTED]University of Alberta, Canada Debian Chinese Project -- http://www.debian.org/international/chinese/ Come visit Our Lady of Victory Camp -- http://www.olvc.ab.ca/
Please process the Chinese new maintainers' application ASAP
Hello! I have been wondering: Could the Chinese new developers currently in the NM queue be given priority to be processed first? Specifically: Yu Guanghui(from China) Chuan-kai Lin (from Taiwan) Roger So (from Hong Kong) The reason is that, for the past few months, I have been the only official Debian developers to work on the Debian Chinese Project. While others have helped greatly, since they do not have access to Debian resources, their efforts are severely limited. As Debian 2.2 is to be released in July, I would really like to use this opportunity to help promote Debian in China, Taiwan, and Hong Kong, since the Chinese support in Debian 2.2 is much better than that in 2.1, where Chinese support was essentially non-existent. I am a Chinese Debian developer living in Canada, and there is currently no Debian developers from China or Taiwan. There is one in Hong Kong, Anthony Wong, but he is currently unavailable due to job commitments. That is one of the major reasons why Debian is used by so few people in Hong Kong and Taiwan, and even much less in Mainland China. I would really love to see more Chinese people using and enjoying Debian. I would really love to see Debian succeed in China, Taiwan and HK. But I can't do it alone. My skills and time are very limited indeed. Is there any possibility that Guanghui, Chuan-kai and Roger's new maintainer applications be processed as soon as possible? I would really love their help on integrating more Chinese support into the main Debian. I can personally testify their contributions: * Yu Guanghui is the upstream author of the Debian package "zh-autoconvert". He is also packaging some essential Chinese input software like ZhWinPro and Chinput. * Roger So: He has already packaged "locale-zh-hk" for testing. He is also the upstream author of the zh_HK.Big5HKSCS locale. As well, he packaged a commercial demo package "qcode" input method as a Debian package. (He wished he could have convinced his boss to release it as open source. :-) * Chuan-kai Lin: He has already translated the www.debian.org/Bugs web pages into Chinese, as well as refining other translated pages. He is also instrumental in providing part of a security patch for cce-0.36-1.1. (Also thanks to Fumitoshi UKAI-san who provided the main patch.) All three individuals are active participants on the Debian Chinese mailing list, and have contributed lots of valuable software, ideas and support. They have already proven themselves to be excellent future Debian developers. Let us work together to spread the gospel of Debian GNU/Linux to all corners of the earth. :-) Thank you for your considerations. Cheers, Anthony Fok <[EMAIL PROTECTED]> Debian developer, and Debian Chinese Project lead developer -- Anthony Fok Tung-LingCivil and Environmental Engineering [EMAIL PROTECTED], [EMAIL PROTECTED]University of Alberta, Canada Debian Chinese Project -- http://www.debian.org/international/chinese/ Come visit Our Lady of Victory Camp -- http://www.olvc.ab.ca/
Re: Warning: Me, too! (was Re: NM : Dale Scheetz : is NM working
Hello Jim, On Tue, Jun 27, 2000 at 01:27:02PM -0700, Jim Westveer wrote: > Yes the New Maintainer process is alive and well. > [...] > There are currently 25+ voulenteers working as Application Managers (AM's) > working the applications, and as we get used to the processes that > have been set into place, things will hopefully go more quickly. > > Again, please be patient. This is a big task. That's great news, and thank you for all your hard work. :-) I hope I wasn't being too selfish for asking the Chinese developers to be given priority. :-) Nonetheless, your message gave me an idea: Would it be possible for me to volunteer as an Application Manager to process the three Chinese developers-to-be? Afterall, we've got to know each other quite well from discussions on the mailing list. :-) If it is okay, please give me a pointer (http://nm.debian.org/ ?) so I can get started. :-) Thanks, Anthony -- Anthony Fok Tung-LingCivil and Environmental Engineering [EMAIL PROTECTED], [EMAIL PROTECTED]University of Alberta, Canada Debian Chinese Project -- http://www.debian.org/international/chinese/ Come visit Our Lady of Victory Camp -- http://www.olvc.ab.ca/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Please process the Chinese new maintainers' application ASAP
Hello! I have been wondering: Could the Chinese new developers currently in the NM queue be given priority to be processed first? Specifically: Yu Guanghui(from China) Chuan-kai Lin (from Taiwan) Roger So (from Hong Kong) The reason is that, for the past few months, I have been the only official Debian developers to work on the Debian Chinese Project. While others have helped greatly, since they do not have access to Debian resources, their efforts are severely limited. As Debian 2.2 is to be released in July, I would really like to use this opportunity to help promote Debian in China, Taiwan, and Hong Kong, since the Chinese support in Debian 2.2 is much better than that in 2.1, where Chinese support was essentially non-existent. I am a Chinese Debian developer living in Canada, and there is currently no Debian developers from China or Taiwan. There is one in Hong Kong, Anthony Wong, but he is currently unavailable due to job commitments. That is one of the major reasons why Debian is used by so few people in Hong Kong and Taiwan, and even much less in Mainland China. I would really love to see more Chinese people using and enjoying Debian. I would really love to see Debian succeed in China, Taiwan and HK. But I can't do it alone. My skills and time are very limited indeed. Is there any possibility that Guanghui, Chuan-kai and Roger's new maintainer applications be processed as soon as possible? I would really love their help on integrating more Chinese support into the main Debian. I can personally testify their contributions: * Yu Guanghui is the upstream author of the Debian package "zh-autoconvert". He is also packaging some essential Chinese input software like ZhWinPro and Chinput. * Roger So: He has already packaged "locale-zh-hk" for testing. He is also the upstream author of the zh_HK.Big5HKSCS locale. As well, he packaged a commercial demo package "qcode" input method as a Debian package. (He wished he could have convinced his boss to release it as open source. :-) * Chuan-kai Lin: He has already translated the www.debian.org/Bugs web pages into Chinese, as well as refining other translated pages. He is also instrumental in providing part of a security patch for cce-0.36-1.1. (Also thanks to Fumitoshi UKAI-san who provided the main patch.) All three individuals are active participants on the Debian Chinese mailing list, and have contributed lots of valuable software, ideas and support. They have already proven themselves to be excellent future Debian developers. Let us work together to spread the gospel of Debian GNU/Linux to all corners of the earth. :-) Thank you for your considerations. Cheers, Anthony Fok <[EMAIL PROTECTED]> Debian developer, and Debian Chinese Project lead developer -- Anthony Fok Tung-LingCivil and Environmental Engineering [EMAIL PROTECTED], [EMAIL PROTECTED]University of Alberta, Canada Debian Chinese Project -- http://www.debian.org/international/chinese/ Come visit Our Lady of Victory Camp -- http://www.olvc.ab.ca/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: version numbers
On Tue, May 11, 1999 at 11:10:26PM -0500, John Hasler wrote: > James Mastros writes: > > Package it as version 1:1.1; next time package as 1:2.0.2, which will > > give the ordering you're looking for. (The 1: is an "era"; it won't > > normaly get displayed. Made for just this sort of thing.) > > It's an "epoch", I believe. I know about epochs, but I've never seen > anyone suggest using them without meeting with cries of outrage. Thus I > would like to avoid them if at all possible. > > I am also just a bit astonished by the notion that 1.1 < 1.02. Yes, I got bitten by dpkg's logic too when I was packaging musixlyr. Old version: 1.02, new version: 1.1. Coincident? :-) Anyway, Brian White suggested me to use 1.10 instead of 1.1 in order to avoid the epoch. And lo and behold, it worked! :-) So, use two digits after the decimal from now on, until the upstream author releases version 2.x, then you can use the scheme "2.0.2" as suggested above. Not too pretty, but prettier than epoch. :-) Anthony -- Anthony Fok Tung-LingCivil and Environmental Engineering [EMAIL PROTECTED], [EMAIL PROTECTED]University of Alberta, Canada [EMAIL PROTECTED] Keep smiling! *^_^* Come visit Our Lady of Victory Camp -- http://www.olvc.ddns.org/ or http://www.ualberta.ca/~foka/OLVC/
Re: how do I create orig.tar.gz archive ?
On 29 Jan 1999, Peter Makholm wrote: > Anything special to do if it is impossible to use pristine sources? > > I have a packages where the source is distributed i zipfiles with only > one-case 8.3 filenames (yuck). Everything in the sources uses > filenames which differs in case. what shall I do? Try "unzip -La filename.zip". That can often change the case from upper to lower. :-) It also automatically detects text file and change the DOS CR/LF to Unix/Linux's LF (??). Have to watch to make sure unzip is not too overzealous in doing that though! :-) Hope this helps, Anthony -- Anthony Fok Tung-LingCivil and Environmental Engineering [EMAIL PROTECTED], [EMAIL PROTECTED]University of Alberta, Canada [EMAIL PROTECTED] Keep smiling! *^_^* Come visit Our Lady of Victory Camp -- http://www.olvc.ddns.org/ or http://www.ualberta.ca/~foka/OLVC/
Re: Bug#27050 (fdutils): A cause for security concern?
Hello Ben, Avery and Wichert!
On Wed, Jan 20, 1999 at 12:50:59AM +0100, Wichert Akkerman wrote:
> Previously Anthony Fok wrote:
> > As the Slink deep freeze and release are impending, I would like to ask your
> > advice: Should I follow the suggestion given by the bug reporter Thomas
> > Roessler?
>
> I think so. For people who want to mount floppies without being root
> you can also use a line in /etc/fstab like this:
>
> /dev/fd0 /floppyauto noauto,noexec,nodev,user 0 0
Yes, I already have something similar in my /etc/fstab. The problem is
that fdmount is independent of mount. It doesn't even touch
/etc/fstab.
Unfortunately, the suggestion "chown root.floppy" and "chmod [12]754"
won't work either because fdmount.c has this check in it:
if (geteuid()!=0)
die("Must run with EUID=root");
I am a little bit tempted to comment that line out, but it's probably
there for a reason, and I am definitely not qualified to hack
fdmount.c, so for now I should probably add a /usr/sbin/fdutilsconfig
as Thomas has suggested.
> fdmount should probably be audited so we really know if it's secure. You
> could submit it to the security-auditing list
> ([EMAIL PROTECTED]).
Thanks for the info!
> > If so, should I fix this bug before Slink is out?
>
> Yes. I would hate to discover a vulnerability and release an advisory
> days after we release slink..
Okay, I will try to do it soon then. Hopefully I will have my school
assignments finished before the end of the weekend. :-)
Thanks a lot for all your advice and suggestions!
Anthony
--
Anthony Fok Tung-LingCivil and Environmental Engineering
[EMAIL PROTECTED], [EMAIL PROTECTED]University of Alberta, Canada
[EMAIL PROTECTED] Keep smiling! *^_^*
Come visit Our Lady of Victory Camp -- http://www.olvc.ddns.org/
or http://www.ualberta.ca/~foka/OLVC/
Bug#27050 (fdutils): A cause for security concern?
Hello, I received the following bug report about fdutils a while ago, but haven't had time to deal with it yet. Basically, the bug reporter is concerned that the suid'ed fdmount could be insecure, because fdmount's manpage warns the user not to rely on it being secure. So far, my suid'ed fdmount hasn't given me any trouble, and the upstream defaults to suid'ing it, and I haven't heard any security warnings from CERT (?) etc. either. However, I have to admit that I do not know that much about security. As the Slink deep freeze and release are impending, I would like to ask your advice: Should I follow the suggestion given by the bug reporter Thomas Roessler? If so, should I fix this bug before Slink is out? I am kind of busy with school now and would like to put it off till the holiday, but if all of you experienced developers feel that it is urgent, I will try to fix it before Slink is released. Thanks again. :-) I have attached the bug report below. Cheers, Anthony Package: fdutils; Reported by: Thomas Roessler <[EMAIL PROTECTED]>; dated Thu, 24 Sep 1998 15:33:01 GMT; Maintainer for fdutils is Anthony Fok <[EMAIL PROTECTED]>. == Package: fdutils Version: 5.2pl4-3 [This is on a current hamm system.] Even fdmount's own manual page says that users should not rely on the program being secure. I consider it a bug that the fdutils package installs this program suid root regardless of this warning. Either you have checked the program's security - in this case you may install it suid root and remove the warning from the manual page. Or you didn't do the checks you should - in this case you should release a new package which installs the program mode 755 by default and tells the user that he can get full functionality only when registering it suid root. (gnuplot does something like this using suidmanager.) Regards, tlr -- System Information Debian Release: 2.0 Kernel Version: Linux sobolev 2.1.122 #43 SMP Thu Sep 17 14:24:19 MEST 1998 i586 unknown Versions of the packages fdutils depends on: ii libc6 2.0.7t-1 The GNU C library version 2 (run-time files) ii makedev 1.6-32 Creates special device files in /dev. -- Anthony Fok Tung-LingCivil and Environmental Engineering [EMAIL PROTECTED], [EMAIL PROTECTED]University of Alberta, Canada [EMAIL PROTECTED] Keep smiling! *^_^* Come visit Our Lady of Victory Camp -- http://www.olvc.ddns.org/ or http://www.ualberta.ca/~foka/OLVC/
Re: new .orig.tar.gz uploading - how??
On Fri, Mar 20, 1998 at 08:18:09AM -0600, Manoj Srivastava wrote: > Hi, > I have no idea how build works. Useing dpkg-buildpackage, you > can arrange to have the sources included in the new upload by saying > % dpkg-buildpackage -sa -rfakeroot (or -rsudo or what have you) > > Then the changes file so generated shall have the (NEW) > orig.tar.gz file. Just an addendum: build passes many command line options to dpkg-buildpackage and friends. To generate a new package with the source file, use the following command: $ build -sa -rfakeroot Cheers, Anthony -- Anthony Fok Tung-LingCivil and Environmental Engineering [EMAIL PROTECTED] University of Alberta, Canada [EMAIL PROTECTED] Keep smiling! *^_^* Come visit Our Lady of Victory Camp -- http://olvc.home.ml.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: how to provide pristine source package
On Mon, Mar 02, 1998 at 10:24:27PM +0100, Marcus Brinkmann wrote: > > Hello! > > I sometimes read something like "as we can now easily provide pristine > source packages...". > I wonder how I can provide the original tar ball if it > > a) has not the right name (ok, could rename it) Yes. That's no problem at all. :-) > b) does not extract in the right directory (for example, foo-version instead > foo-version.orig). That's no problem at all! :-) dpkg-source (?) is smart enough to handle that situation. As long as the files are all under one single directory, things will be fine. :-) Of course, some packages are just too awkward to provide pristine source (such as those that comes in multiple .zip files or has no directory structure what-so-ever), we will just have to tailor it for now. :-) Anthony
Re: gv depends on ghostscript, which depends on gsfonts
On Sat, Feb 28, 1998 at 05:31:51PM -0800, Karl M. Hegbloom wrote: > [ cc'd to _debian-mentors_. *Please advise*. > This is concerning: > http://www.debian.org/Bugs/db/18/18026.html> ] > > Please Cc: pertinent responses to [EMAIL PROTECTED] > > Checking, I find that `gs-aladdin 5.10-3' and `gs 3.33-6' both have > "Recommends:" dependencies on `gsfonts'. Perhaps these should be > "Requires:" rather than "Recommends:"? Why are they "Recommends:" > right now? Read the definitions of "Recommends:" and "Depends:" in the Debian Policy Manual and you will understand why.Recommends is correct, AFAIK. Cheers, Anthony
