Re: Bug#729595: expect-lite: Please add expect-lite package to Squeeze & Wheezy
Control: reassign -1 wnpp Control: retitle -1 ITP: expect-lite -- easy to use version of expect Control: owner -1 Craig Miller On Jo, 14 nov 13, 12:39:04, Craig Miller wrote: > Package: expect-lite > Severity: normal > > Dear Maintainer, > > Please add expect-lite package to Squeeze & Wheezy > > Expect-lite is build on expect and basic expect-lite scripts can be created by > simply cutting and pasting text from a terminal window into a script, and > adding '>' '<' characters. > > This package is already part of the Ubuntu and Gentoo distros. > > Additionally, Sergei Golovan, the maintainer of expect, has agreed to upload > the package. > > I (the author and maintainer of expect-lite) will continue to maintain the > package. Since you will be the Maintainer of the package I think you wanted to file an ITP (Intent to Package) and not an RFP (Request to package). Please provide also the other informations usually included in an ITP (see http://www.debian.org/devel/wnpp/#l2 ) Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: MIPS64EL rootfs available for use and test
On 14 November 2013 18:25, YunQiang Su wrote: > Anybody can help to test whether the out current webkit workable? > > Maybe by install epiphany-browser and use it? > > All of my board/laptops are working as build nodes. > > We'll see if we can run it up on our 3A laptop today. We've not modified the laptop from production installation yet, so it may take us a little bit to get up to speed with the process. > If it work, can you reply to > https://bugs.webkit.org/show_bug.cgi?id=124370 > and > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729572 > ? > > OK, will do. I'll let you know how we get on. If somebody else is/was thinking of trying it out then please still do :-) Graham > On Thu, Nov 14, 2013 at 7:31 PM, Graham Whaley > wrote: > > > > On 14 November 2013 00:46, David Daney > wrote: > >> > >> On 11/13/2013 04:32 PM, YunQiang Su wrote: > >>> > >>> On Thu, Nov 14, 2013 at 8:03 AM, David Daney < > dda...@caviumnetworks.com> > >>> wrote: > > On 11/11/2013 09:57 AM, YunQiang Su wrote: > > > > > > Hi, folks, > > > > In the recent days, I figure out the mips64el rootfs and test it on > > Loongson 3A platform. > > It works well in general, it's time to release it. > > > > It can be download from: > > http://mips64el.debian.net/debian/rootfs/ > > > > Nice! > > I tested it on our OCTEON boards. Seems to be working. I had to > enable > CONFIG_DEVTMPFS and CONFIG_DEVTMPFS_MOUNT in my kernel and edit > /etc/inittab > to put gettys on my serial ports, and set the root password. But > after > that, it works seemingly without a hitch. > >>> > >>> Great news, while wait... does OCTEON support little endian? > >> > >> > >> Yes. The kernel.org kernel doesn't yet contain full little-endian > >> support, but getting little-endian support merged is on our list of > things > >> to do. > >> > > Hi David, > > out of interest, do you know if there are any commercially (ideally > easily > > and cheaply ;-) available boards out there that can run Octeon little > > endian? afaik things like the CN5020 based boards like the Erlite-3 and > > CAM-0100 only do big, and afaik there is no (documented) way to jumper > them > > differently. > > My presumption is that the Cavium Octeon devboards from Cavium > themselves > > (available I believe, but not too cheap) can do both? > > > > Graham > > > >> > >> David Daney > >> > >> > >> > > > > > To install it, what you need to do is just unpack it to a partition > > and configure kernel/bootloader/fstab by yourself. > > > > This is a more detailed instruction for Loongson 3A users: > > http://mips64el.debian.net/debian/rootfs/README > > > > Know issues: > > 1. MIPS64r2 ISA is required, > >while we have made a agree to downgrade the requirement to > > mips3 in future. > > 2. The permission is of /usr/bin/crontab is not correct, so you > > need > > to: > >apt-get install cron --reinstall > > 3. some files in /var/cache/man are not correct, you need to: > > rm -rf /var/cache/man/* ; mandb > > > > PS: we have 8500+ packages built now. > > > > Happy hacking, and I am wishing your feedback. > > > > >>> > >>> > >>> > >> > >> > >> -- > >> To UNSUBSCRIBE, email to debian-mips-requ...@lists.debian.org > >> with a subject of "unsubscribe". Trouble? Contact > >> listmas...@lists.debian.org > >> Archive: http://lists.debian.org/52841d71.3090...@caviumnetworks.com > >> > > > > > > -- > YunQiang Su >
Re: MIPS64EL rootfs available for use and test
On 14 November 2013 18:54, David Daney wrote: > On 11/14/2013 03:31 AM, Graham Whaley wrote: > [...] > > Hi David, >> out of interest, do you know if there are any commercially (ideally >> easily and cheaply ;-) available boards out there that can run Octeon >> little endian? >> > > I don't know... > > > afaik things like the CN5020 based boards like the >> Erlite-3 and CAM-0100 only do big, and afaik there is no (documented) >> way to jumper them differently. >> > > On OCTEON, the endianess is under software control, it is *not* a hardware > strapping option. With a suitable bootloader, we still start the system in > big endian mode, but if a little-endian ELF image is loaded, we note the > endianness, and switch to little endian mode as control is passed to the > program entry point. > > It has only really been validated on OCTEON II and OCTEON III devices > (cn6xxx and cn7xxx). Certianly the CPU cores on the cn5020 are capable of > little endian operation. The I/O blocks on the other hand have not been > validated for little endian operation on that part. > > It is known that the bootbus (where the NOR boot flash is connected) has > problems in little endian mode on cn5020, so you probably wouldn't be able > to use that from Linux. Also the USB controller on cn5020 has not been > adapted and validated for little endian use, so there would be work there. > > >My presumption is that the Cavium Octeon devboards from Cavium >> themselves (available I believe, but not too cheap) can do both? >> > > As I said above, it is under software control, so any board should be able > to do it (given the proper software). Thanks David - that was all something I'd not come across before with Octeon. Is this functionality available in any of the open bootloaders (u-boot etc.), or are there any references I can peek at (docs, wiki etc.) ? Graham > > > David Daney >
Subversion 1.8.4
Hello everyone! As the latest packaged Subversion in Debian is now 1.8.4 and it seems that the maintainer doesn't care updating it by now (see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725787), I've recently packaged svn 1.8.4 and serf 1.3.2 (which is needed by svn) by myself. I've never tried to perform any package maintenance, but I would be very happy to contribute these packages to Debian... (NMU?) What are the next steps for it? Should someone (some maintainer?) review it? Source and binary packages are here (add to /etc/apt/sources.list): deb http://vmx.yourcmc.ru/var/debian/ unstable/ deb-src http://vmx.yourcmc.ru/var/debian/ unstable/ The public key for my mini-archive can be taken here (run as command): apt-key adv --keyserver pgp.mit.edu --recv c9d991da5f98c882 I've taken the 1.7 debian package as a base and removed/added/adjusted some patches. Most tests pass... sqlite query plan tests with sqlite 3.8 were a tricky part, I've added a patch which loads correct index statistics in every SVN working copy database (without that SQLite 3.8 with NGQP didn't want to use indexes correctly)... Bug 722233 may be related to it (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=722233) Yet "most tests" doesn't mean "all", and I don't know how to correctly fix those that don't pass - it seems they're not related to build environment (and there are comments like "these values pass, but I don't know if they are correct" in the code). So I've built them with: DEB_BUILD_OPTIONS="nocheck" dpkg-buildpackage (Although, Dominik Stadler said in the bug 725787 that all tests passed in his Ubuntu PPA build based on mine one)
Re: Bug#729595: expect-lite: Please add expect-lite package to Squeeze & Wheezy
On 2013-11-15 8:32, Andrei POPESCU wrote:
On Jo, 14 nov 13, 12:39:04, Craig Miller wrote:
Please add expect-lite package to Squeeze & Wheezy
[...]
Since you will be the Maintainer of the package I think you wanted to
file an ITP (Intent to Package) and not an RFP (Request to package).
Please provide also the other informations usually included in an ITP
(see http://www.debian.org/devel/wnpp/#l2 )
For reference, the package will also _not_ be in squeeze or wheezy, as
they are both already released.
It could, of course, be provided via {squeeze,wheezy}-backports once
the package makes it as far as testing.
Regards,
Adam
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/0d9b72b389f062e1df750cc49d058...@mail.adsl.funky-badger.org
Re: Cross-directory hard links in Debian packages
On Wed, Nov 13, 2013 at 12:11:27PM +0100, Adam Borowski wrote: > So you save a small number of inodes, and get problems if the filesystem's > layout is unconventional. Such savings don't seem to be worth the trouble > to me. I was questioning the existence of said trouble. I still do that. If the number of affected users is small, then ignoring those few is a sensible thing to do. For instance the publican package saved 3/4 of its binary package size. If this were a problem, then maybe we should have seen a bug report. > You don't know what directory resides on what filesystem. While splitting > up /usr tends to be trouble, it is not unusual. For example Maemo has: > > /opt/pymaemo/usr/lib/python2.5 on /usr/lib/python2.5 type bind (bind,rbind) > /opt/pymaemo/usr/share/pyshared on /usr/share/pyshared type bind (bind,rbind) > /opt/pymaemo/usr/lib/pyshared on /usr/lib/pyshared type bind (bind,rbind) > /opt/pymaemo/usr/share/python-support on /usr/share/python-support type bind > (bind,rbind) > /opt/pymaemo/usr/lib/python-support on /usr/lib/python-support type bind > (bind,rbind) These cases would not be problematic for my proposal. I was suggesting to explicitly allow cross-directory hard links within any of these locations, but not crossing each other. > So I'd keep this requirement as is. There is no requirement besides conffiles not being hard links. Having hard links that cross /usr/share/pyshared and /usr/lib/pyshared is not a policy violation. Hence I was suggesting to clarify the policy on this aspect. Helmut -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131115101619.ga2...@alf.mars
Re: Subversion 1.8.4
On Fri, Nov 15, 2013 at 01:39:07PM +0400, Виталий Филиппов wrote: > I've never tried to perform any package maintenance, but I would be very > happy to contribute these packages to Debian... (NMU?) > > What are the next steps for it? Should someone (some maintainer?) review > it? Yes, someone needs to review it, but before that the package tests need to be fixed so they a) run and b) pass, reliably and repeatably. After that, either get the package maintainers to discuss the new version, or find someone to take over the package if they no longer want to or can maintain it. Doing an NMU for a package to upgrade it to new upstream release should be done very carefully, and it should avoid to override the maintainers unless it's critical. -- http://www.cafepress.com/trunktees -- geeky funny T-shirts http://gtdfh.branchable.com/ -- GTD for hackers -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131115110742.GB4590@holywood
Bug#729659: general: problem with laptop suspend after dist-upgrade
Package: general Severity: normal Dear Maintainer, After running apt-get dist-upgrade, my laptop does not suspend properly: Problems: 1) key shortcut - used to work (standard shortcut, worked out of the box), now instead suspending, it causes screen lock 2) menu option - used to be above power off option (in gnome menu, this in top right), now disapeared 3) closing lid - does nothing, used to suspend when I type some magical command (found on http://askubuntu.com/questions/1792 /how-can-i-suspend-hibernate-from-command-line): dbus-send --system --print-reply \ --dest="org.freedesktop.UPower" \ /org/freedesktop/UPower \ org.freedesktop.UPower.Suspend system suspends propperly laptop: Lenovo thinkpad t61p Chears, Kuba -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.11-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131115114716.24637.55109.reportbug@floydd
Processed: Re: Bug#729659: general: problem with laptop suspend after dist-upgrade
Processing commands for cont...@bugs.debian.org: > affects 729659 upower Bug #729659 [general] general: problem with laptop suspend after dist-upgrade Added indication that 729659 affects upower > End of message, stopping processing here. Please contact me if you need assistance. -- 729659: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729659 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.138451677427851.transcr...@bugs.debian.org
Bug#729660: ITP: xemacs21 -- highly customizable text editor
Package: wnpp Severity: wishlist Owner: Mark Brown * Package name: xemacs21 Version : 21.4.22 Upstream Author : XEmacs development team URL : http://www.xemacs.org/ License : GPL Programming Lang: C, elisp Description : highly customizable text editor XEmacs is a full fledged programming language with a mail reader, news reader, info browser, web browser, calendar, specialized editor for more programming languages and other formats than most people encounter in a lifetime, and much more. While develoment on xemacs is very slow these days I find it much more visually pleasing than GNU emacs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131115120218.16184.65842.reportbug@finisterre
Re: Bug#729660: ITP: xemacs21 -- highly customizable text editor
On Fri, Nov 15, 2013 at 12:02:18PM +, Mark Brown wrote: > * Package name: xemacs21 > Version : 21.4.22 Wasn't this removed just one month ago? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725883 Berto -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131115122950.ga12...@igalia.com
Re: Cross-directory hard links in Debian packages
Hello, On Wed, 13 Nov 2013 10:19:17 +0100 Helmut Grohne wrote: > The tar file format supports hard links. Thus technically Debian > packages can contain hard links. A significant number of packages > including key packages such as bzip2, gzip, and ifupdown use this > technique. While same-directory hard links are an established > practise, the same is not so true for cross-directory hard links. Isn't there a mistake? I can't remember having hard links in ifupdown. -- Cheers, Andrew signature.asc Description: PGP signature
Re: Cross-directory hard links in Debian packages
Hello, On Fri, 15 Nov 2013 13:42:18 +0100 Andrew Shadura wrote: > > The tar file format supports hard links. Thus technically Debian > > packages can contain hard links. A significant number of packages > > including key packages such as bzip2, gzip, and ifupdown use this > > technique. While same-directory hard links are an established > > practise, the same is not so true for cross-directory hard links. > Isn't there a mistake? I can't remember having hard links in ifupdown. Huh, it seems you're right. Upon inspection, I've noticed ifdown is hardlinked with ifup, and I have not a slightest idea why, as it was supposed to be a symlink. -- Cheers, Andrew signature.asc Description: PGP signature
Re: Cross-directory hard links in Debian packages
On Fri, Nov 15, 2013 at 11:16:19AM +0100, Helmut Grohne wrote: > For instance the publican package saved 3/4 of its binary package > size. If this were a problem, then maybe we should have seen a bug > report. I'm not sure that making a general rule based on an edge-case is a good idea. Publican is not very popular at all, it's quite likely that none of the 70 or so people who have installed it have done anything unusual with mounts around /usr. Looking at publican a number of questions occur to me * why hardlink all of the contents of /usr/share/doc/publican/Users_Guide/desktop/$LOCALE/Common_Content together rather than symlink them to some common directory like /usr/share/publican/Common_Content? Is it because there might be additions or omissions across locales? * Can/should that not be handled within the tool itself (implement a multi-directory lookup process) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131115135005.gb8...@bryant.redmars.org
Re: Subversion 1.8.4
On Fri, Nov 15, 2013 at 01:39:07PM +0400, Виталий Филиппов wrote: > As the latest packaged Subversion in Debian is now 1.8.4 and it seems > that the maintainer doesn't care updating it by now (see > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725787), A little over a month ago is not long enough to consider the maintainer to either not care or to be MIA. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131115135121.gc8...@bryant.redmars.org
Re: Bug#729595: expect-lite: Please add expect-lite package to Squeeze & Wheezy
On Fri, Nov 15, 2013 at 5:05 AM, Adam D. Barratt
wrote:
> On 2013-11-15 8:32, Andrei POPESCU wrote:
>
>> On Jo, 14 nov 13, 12:39:04, Craig Miller wrote:
>>
>>> Please add expect-lite package to Squeeze & Wheezy
>>>
>> [...]
>
> Since you will be the Maintainer of the package I think you wanted to
>> file an ITP (Intent to Package) and not an RFP (Request to package).
>> Please provide also the other informations usually included in an ITP
>> (see http://www.debian.org/devel/wnpp/#l2 )
>>
>
> For reference, the package will also _not_ be in squeeze or wheezy, as
> they are both already released.
>
> It could, of course, be provided via {squeeze,wheezy}-backports once the
> package makes it as far as testing.
>
> Regards,
>
> Adam
>
Thanks Adam,
Yes, I am hoping to get the expect-lite package added as backports to the
already released versions of Debian.
thanks,
Craig...
Re: Bug#729660: ITP: xemacs21 -- highly customizable text editor
On Fri, Nov 15, 2013 at 01:29:50PM +0100, Alberto Garcia wrote: > On Fri, Nov 15, 2013 at 12:02:18PM +, Mark Brown wrote: > > * Package name: xemacs21 > > Version : 21.4.22 > Wasn't this removed just one month ago? Yes, this is why I'm ITPing it. signature.asc Description: Digital signature
Re: Bug#729660: ITP: xemacs21 -- highly customizable text editor
Out of curiosity, how do you plan on solving it's six rc bugs? On Nov 15, 2013 9:10 AM, "Mark Brown" wrote: > On Fri, Nov 15, 2013 at 01:29:50PM +0100, Alberto Garcia wrote: > > On Fri, Nov 15, 2013 at 12:02:18PM +, Mark Brown wrote: > > > > * Package name: xemacs21 > > > Version : 21.4.22 > > > Wasn't this removed just one month ago? > > Yes, this is why I'm ITPing it. >
Re: Bug#729660: ITP: xemacs21 -- highly customizable text editor
On Fri, Nov 15, 2013 at 09:17:34AM -0500, Paul R. Tagliamonte wrote: Don't top post. > Out of curiosity, how do you plan on solving it's six rc bugs? Yes, of course. Well, the one that was there when I looked is fixed, I'll see if the BTS tells me about any open ones after the reupload. signature.asc Description: Digital signature
Re: Bug#729660: ITP: xemacs21 -- highly customizable text editor
On Fri, Nov 15, 2013 at 03:01:46PM +, Mark Brown wrote: > On Fri, Nov 15, 2013 at 09:17:34AM -0500, Paul R. Tagliamonte wrote: > > Don't top post. I was on my phone, thanks for the advice. > > Out of curiosity, how do you plan on solving it's six rc bugs? > > Yes, of course. Well, the one that was there when I looked is fixed, > I'll see if the BTS tells me about any open ones after the reupload. No, I don't think it's wise to let this back in the archive before you know how you're going to deal with *why* it was removed. God knows we the ftpteam doesn't need more work (processing this from NEW to only rm it a few short weeks later). Before you put this in NEW, how do you plan on fixing the outstanding RC bugs? Cheers, Paul -- .''`. Paul Tagliamonte : :' : Proud Debian Developer `. `'` 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `- http://people.debian.org/~paultag signature.asc Description: Digital signature
Re: Bug#729660: ITP: xemacs21 -- highly customizable text editor
On Fri, Nov 15, 2013 at 10:06:37AM -0500, Paul Tagliamonte wrote: > Before you put this in NEW, how do you plan on fixing the outstanding RC > bugs? By making changes to the software. signature.asc Description: Digital signature
Re: Bug#729660: ITP: xemacs21 -- highly customizable text editor
On Fri, Nov 15, 2013 at 03:25:16PM +, Mark Brown wrote: > On Fri, Nov 15, 2013 at 10:06:37AM -0500, Paul Tagliamonte wrote: > > > Before you put this in NEW, how do you plan on fixing the outstanding RC > > bugs? > > By making changes to the software. No need to CC me, I'm subscribed. This doesn't fill me with confidence that any of the reasons that it was removed will be fixed. I'd have to look at the RC bugs, but it's not out of the question that would get xemacs a REJECT from NEW if they're not handled. At first glance, #695799 appears to be one such bug. so, again, how will you fix the open bugs before you upload to NEW? Which bugs are you planning to fix? I'm looking for a hard commitment here, Mark. Cheers, Paul -- .''`. Paul Tagliamonte : :' : Proud Debian Developer `. `'` 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `- http://people.debian.org/~paultag signature.asc Description: Digital signature
Re: Bug#729660: ITP: xemacs21 -- highly customizable text editor
On Fri, Nov 15, 2013 at 03:25:16PM +, Mark Brown wrote: > On Fri, Nov 15, 2013 at 10:06:37AM -0500, Paul Tagliamonte wrote: > > > Before you put this in NEW, how do you plan on fixing the outstanding RC > > bugs? > > By making changes to the software. This discussion is getting a tad too antagonistic, maybe? May I suggest someting? * The FTP team has valid concerns about re-introducing a package that's already been removed, partly due to not being maintained well by a previous maintainer. * Mark's a long-time Debian developer. We can expect him to do his best to fix the package before uploading, without interrogating him on the details at ITP time. * Backups are tasty snacks. Let's all run a backup now. -- http://www.cafepress.com/trunktees -- geeky funny T-shirts http://gtdfh.branchable.com/ -- GTD for hackers -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131115154543.GG8314@holywood
Re: Bug#729660: ITP: xemacs21 -- highly customizable text editor
On Fri, Nov 15, 2013 at 10:06:37AM -0500, Paul Tagliamonte wrote: > I was on my phone, thanks for the advice. I laboriously quote-post from my phone all the time. Emails should be optimised for the reader, rather than the writer. > No, I don't think it's wise to let this back in the archive before you > know how you're going to deal with *why* it was removed. God knows we > the ftpteam doesn't need more work (processing this from NEW to only rm > it a few short weeks later). There were four stated reasons for its removal, and RC-buggy was just one. Unmaintained was another, and lack of maintenance is one sure fire way to make sure that RC bugs aren't fixed. One that Mark is proposing to address by maintaining the package. > Before you put this in NEW, how do you plan on fixing the outstanding RC > bugs? Technically, there are no outstanding RC bugs, all bugs were closed when it was removed. Practically, of course there are likely to be issues that were opened against the old package which will apply to the new one. But how did you get to the figure 6 (elsewhere?) Is that Moritz's count from #725883? How do you know which of those 6 are problems in the source, rather than problems in the packaging (which may not be inherited by Mark's packaging efforts?) Furthermore, is it not usual practice for ftp master to comment on actual packages, rather than theoretical ones? an ITP is "intent to package". There's no package to critique yet! -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131115170531.ga13...@bryant.redmars.org
Re: Bug#729660: ITP: xemacs21 -- highly customizable text editor
On Fri, Nov 15, 2013 at 10:39:46AM -0500, Paul Tagliamonte wrote: > On Fri, Nov 15, 2013 at 03:25:16PM +, Mark Brown wrote: > > On Fri, Nov 15, 2013 at 10:06:37AM -0500, Paul Tagliamonte wrote: > > > Before you put this in NEW, how do you plan on fixing the outstanding RC > > > bugs? > > By making changes to the software. > No need to CC me, I'm subscribed. Seems to be due to you setting Reply-To. > This doesn't fill me with confidence that any of the reasons that it was > removed will be fixed. > I'd have to look at the RC bugs, but it's not out of the question that > would get xemacs a REJECT from NEW if they're not handled. At first > glance, #695799 appears to be one such bug. That's a bug in a different package which I didn't ITP (or look at) yet, it's just GFDL docs so the simple fix would obviously be to remove the offending files. There's only one RC bug in xemacs21 itself which I've been able to see (a build fail with texinfo5) which is just a matter of typing to fix. > so, again, how will you fix the open bugs before you upload to > NEW? Which bugs are you planning to fix? > I'm looking for a hard commitment here, Mark. My general approach to these things is to fix bugs as I go. I don't have any particular plan for how I'm going to fix things I've not even looked at or looked for yet but given the lack of either development or massive changes in the underlying platform I would be astonished if there were anything insurmountable - the thing that was causing issues before was that Ohura-san wasn't spending time on the package. It's going to be quicker and simpler to actually fix the problems than to go through and make an exhaustive list and analyse them, as Lars suggested please do assume I'm going to make some reasonable effort to not upload obviously broken stuff. signature.asc Description: Digital signature
Processed: Re: Processed: Re: Bug#729659: general: problem with laptop suspend after dist-upgrade
Processing commands for cont...@bugs.debian.org: > reassign 729659 upower Bug #729659 [general] general: problem with laptop suspend after dist-upgrade Bug reassigned from package 'general' to 'upower'. Ignoring request to alter found versions of bug #729659 to the same values previously set Ignoring request to alter fixed versions of bug #729659 to the same values previously set > # if it affects upower those maintainer know better than the '"general" > # maintainers' what to do with this bug... > thanks Stopping processing here. Please contact me if you need assistance. -- 729659: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729659 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.138453914815331.transcr...@bugs.debian.org
Bug#729659: Processed: Re: Bug#729659: general: problem with laptop suspend after dist-upgrade
reassign 729659 upower # if it affects upower those maintainer know better than the '"general" # maintainers' what to do with this bug... thanks signature.asc Description: This is a digitally signed message part.
Re: Cross-directory hard links in Debian packages
On Fri, 15 Nov 2013, Jonathan Dowland wrote: > Looking at publican a number of questions occur to me > > * why hardlink all of the contents of >/usr/share/doc/publican/Users_Guide/desktop/$LOCALE/Common_Content >together rather than symlink them to some common directory like >/usr/share/publican/Common_Content? Is it because there might be >additions or omissions across locales? An HTML book generated by Publican is supposed to be self-contained. That way it can be served by a webserver without any special configuration. It can also be copied without troubles. >* Can/should that not be handled within the tool itself (implement > a multi-directory lookup process) In web browsers? Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131115201023.ga15...@x230-buxy.home.ouaza.com
Re: Cross-directory hard links in Debian packages
On Fri, Nov 15, 2013 at 01:50:05PM +, Jonathan Dowland wrote: > I'm not sure that making a general rule based on an edge-case is a > good idea. Publican is not very popular at all, it's quite likely > that none of the 70 or so people who have installed it have done > anything unusual with mounts around /usr. publican is just an example. You can find more packages employing the same technique at http://lintian.debian.org/tags/package-contains-hardlink.html. But we should not only look at packages doing this, but packages that are wasting precious mirror and disk space[1]: binary package #files #bytes wims-extra-all 11057 44415092 mixxx-data 73028055125 widelands-data 669212953306 code-aster-test 322559938595 sofia-sip-doc 31466848743 mailman 17452007439 texlive-lang-cjk16194986872 spikeproxy 16025934959 acl2-doc15987209512 freefoam-dev-doc14953145120 wims14582125970 triplea 13408641063 libqt4-dev 13375003042 libboost1.54-doc12404131392 libgrib-api-1.10.4 12101678922 lazarus-doc-1.0.10 117410734571 python-matplotlib-doc 117224691971 fonts-mathjax-extras1136141683 libboost1.53-doc10973717938 dotlrn 10965046637 libboost1.49-doc10913578000 gnat-4.4108310643007 openclipart2-libreoffice10462142208 sql-ledger 10419248930 esys-particle 10258243181 typo3-src-4.5 10191528729 texlive-fonts-extra 998 4687576 moodle 959 6392249 openbox-themes 926 200312 xfwm4-themes890 412192 grass-dev-doc 832 1124116 phpbb3-l10n 825 623634 fillets-ng-data 818 2712929 tuxpaint-stamps-default 813 2824876 optgeo 793 2681882 libbcel-java-doc760 17640174 publican750 5283082 msp430mcu 737 14475576 freegish-data 691 1252457 collabtive 687 1419645 fp-docs-2.6.2 683 2111629 libmapi-dev 681 31188 libnb-platform13-java-doc 678 1349378 murrine-themes 656 255650 ctpp2-doc 642 699880 fvwm-crystal634 800295 pacemaker-dev 628 1399352 libknopflerfish-osgi-java-doc 598 4134711 libreoffice-dmaths 588 905010 freefoam-user-doc 587 883850 The numbers above are the achievable savings by using links. A few of those files will not be hard linkable for crossing popular file system boundaries. Still the projected savings are significant. Clearly, a generic solution is desirable. If you are interested in details on the savings of a particular package, visit http://dedup.debian.net/compare//. Roughly every 25th file in the archive is duplicated within the same package. That's almost 1% of the uncompressed archive size. > Looking at publican a number of questions occur to me > > * why hardlink all of the contents of >/usr/share/doc/publican/Users_Guide/desktop/$LOCALE/Common_Content >together rather than symlink them to some common directory like >/usr/share/publican/Common_Content? Is it because there might be >additions or omissions across locales? Because it is more work to do so. One of the big advantages of using hard links is that you don't have to choose a "primary location". These hard links are generated at package build time. >* Can/should that not be handled within the tool itself (implement > a multi-directory lookup process) Again this is more work. It might be possible in the case of publican, but if you look at the list above, you'll quickly notice that this approach doesn't scale. Is there any technical reason for rejecting the usage of hard links in binary packages besides common file system boundaries? In any case clarifying and documenting whether cross-directory hard links are a tool to be used seems worthwhile to me. * Either they are to be avoided at all costs, then we have a hand full of violations to be fixed, * or they are a tool that can be used to significantly shrink mirror and installation size at very little effort. Helmut [1] ssh delfin.debian.org sqlite3 /srv/dedup.debian.org/dedup.sqlite3 '"SELECT package.name, sharing.files, sharing.size FROM package JOIN sharing JOIN function WHERE sharing.p
Re: Bug#729660: ITP: xemacs21 -- highly customizable text editor
On 15 November 2013 12:02, Mark Brown wrote: > Package: wnpp > Severity: wishlist > Owner: Mark Brown > > * Package name: xemacs21 > Version : 21.4.22 > Upstream Author : XEmacs development team > URL : http://www.xemacs.org/ > License : GPL > Programming Lang: C, elisp > Description : highly customizable text editor > > XEmacs is a full fledged programming language with a mail reader, > news reader, info browser, web browser, calendar, specialized editor > for more programming languages and other formats than most people > encounter in a lifetime, and much more. > > While develoment on xemacs is very slow these days I find it much more > visually pleasing than GNU emacs. > Why should Debian carry this package? Which virtual packages are you planning to provide? Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANBHLUh4fa7+kwoYBtNyw_FOvKEuCBNxBRS9d-ThL=WX6cg=g...@mail.gmail.com
Re: Bug#729660: ITP: xemacs21 -- highly customizable text editor
Le Fri, Nov 15, 2013 at 10:39:46AM -0500, Paul Tagliamonte a écrit : > > I'd have to look at the RC bugs. > > I'm looking for a hard commitment here Hi Paul, I think that if you focused on the compliance with the DFSG, then the NEW queue could empty quicker. It is a big problem, and it is also a problem of commitment, of doing one task well instead of accepting too many responsibilities at the same time. The FTP team is not able to review packages as efficiently as it did in 2011-2012, please take action by searching for more volunteers or reforming the system, instead of loading yourself with extra work. I know that other developers support the idea of having the FTP team doing more checks, but looking at the backlog, this in practice is only wishful thinking, that boils down to "I am happy that somebody else does the work". This at the moment does not work, therefore a different strategy is needed. Have a nice week-end, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131116004451.ga11...@falafel.plessy.net
wxWidgets 3.0 - espeakedit fixes
Hi,
I have attached two patches for espeakedit:
0001-*.patch -- This makes espeakedit compile.
0002-*.patch -- This fixes a segfault when constructing the wxFont
objects for SpectFrame. These were being constructed in the global
namespace. With wxWidgets 3.0, it now requires a gtk+ window when
constructing a wxFont. The change moves creation of the fonts to the
SpectFrame constructor, so a SpectFrame object holds them internally.
I have also removed FONT_NORMAL as this was not used in the code.
These are also available on my espeak github repository at
https://github.com/rhdunn/espeak on the master branch.
NOTE: These changes should be backward compatible with wxWidgets 2.8.
Now when I try and run espeakedit I get:
-
ASSERT INFO:
../src/gtk/font.cpp(337): assert "IsOk()" failed in GetPointSize(): invalid font
BACKTRACE:
[1] wxFont::GetPointSize() const
[2] wxObject::operator=(wxObject const&) /usr/include/wx-3.0/wx/object.h:374
[3] MyFrame::MyFrame(wxWindow*, int, wxString const&, wxPoint const&,
wxSize const&, long) .../espeak/src/espeakedit.cpp:279
[4] MyApp::OnInit() .../espeak/src/espeakedit.cpp:178
[5] wxEntry(int&, wchar_t**)
[6] main .../espeak/src/espeakedit.cpp:99
[7] __libc_start_main
[8] _start
-
This is on the src/espeakedit.cpp line:
notebook->AddPage(transldlg,_T("Text"),TRUE);
any ideas?
NOTE: Pressing 'Continue' on the dialog causes espeakedit to open and
display correctly. I haven't done any major testing, just fixed the
compilation and ensured it started correctly.
Thanks,
Reece H. Dunn (Cainteoir Technologies) [http://www.reecedunn.co.uk]
From fdf52edf89303bb25c15a114ed084f4c526a7e2c Mon Sep 17 00:00:00 2001
From: "Reece H. Dunn"
Date: Sat, 16 Nov 2013 00:49:45 +
Subject: [PATCH 1/2] wxwidgets 3.0: make espeakedit compile
---
src/compiledata.cpp | 5 +
src/espeakedit.cpp | 7 +--
src/extras.cpp | 5 +
src/spectdisplay.cpp | 8
src/spectseq.cpp | 5 +
src/transldlg.cpp| 6 ++
src/vowelchart.cpp | 5 +
7 files changed, 39 insertions(+), 2 deletions(-)
diff --git a/src/compiledata.cpp b/src/compiledata.cpp
index 09645c3..4e22e81 100644
--- a/src/compiledata.cpp
+++ b/src/compiledata.cpp
@@ -1,6 +1,7 @@
/***
* Copyright (C) 2005 to 2013 by Jonathan Duddington *
* email: jo...@users.sourceforge.net*
+ * Copyright (C) 2013 by Reece H. Dunn *
* *
* This program is free software; you can redistribute it and/or modify *
* it under the terms of the GNU General Public License as published by *
@@ -42,6 +43,10 @@
#include
#endif
+#if wxCHECK_VERSION(3, 0, 0)
+#define wxOPEN wxFD_OPEN
+#endif
+
extern void FindPhonemesUsed(void);
extern void DisplayErrorFile(const char *fname);
extern int utf8_in(int *c, const char *buf);
diff --git a/src/espeakedit.cpp b/src/espeakedit.cpp
index e632c5a..4980e41 100644
--- a/src/espeakedit.cpp
+++ b/src/espeakedit.cpp
@@ -43,7 +43,10 @@
#include "translate.h"
#include "prosodydisplay.h"
-
+#if wxCHECK_VERSION(3, 0, 0)
+#define wxOPEN wxFD_OPEN
+#define wxSAVE wxFD_SAVE
+#endif
static const char *about_string2 = "espeakedit: %s\nAuthor: Jonathan Duddington (c) 2009\n\n"
"Licensed under GNU General Public License version 3\n"
@@ -123,7 +126,7 @@ bool MyApp::OnInit(void)
{//=
int j;
-wxChar *p;
+const wxChar *p;
char param[80];
diff --git a/src/extras.cpp b/src/extras.cpp
index fa6ac3b..2141a6e 100644
--- a/src/extras.cpp
+++ b/src/extras.cpp
@@ -1,6 +1,7 @@
/***
* Copyright (C) 2006 to 2011 by Jonathan Duddington *
* email: jo...@users.sourceforge.net*
+ * Copyright (C) 2013 by Reece H. Dunn *
* *
* This program is free software; you can redistribute it and/or modify *
* it under the terms of the GNU General Public License as published by *
@@ -35,6 +36,10 @@
#include "translate.h"
#include "options.h"
+#if wxCHECK_VERSION(3, 0, 0)
+#define wxOPEN wxFD_OPEN
+#endif
+
extern char word_phonemes[N_WORD_PHONEMES];// a word translated into phoneme codes
extern int __cdecl string_sorter(char **a, char **b);
diff --git a/src/spectdisplay.cpp b/src/spectdisplay.cpp
index efeb897..0904547 100644
--- a/src/spectdisplay.cpp
+++ b/src/spectdisplay.cpp
@@ -1,6 +1,7 @@
/***
* Copyright (C) 2005 to 2007 by Jonathan Duddington *
* email: jo...@users.sourceforge.net*
+ * Copyright (C) 2013 by Reece H. Dun
Re: Bug#729660: ITP: xemacs21 -- highly customizable text editor
There was a nice bunch of (5-digit) bugs being closed with the removal, they should be unarchived, reopened and handled properly if xemacs comes back. from https://ftp-master.debian.org/removals.txt: = [Date: Sun, 13 Oct 2013 09:51:22 +] [ftpmaster: Ansgar Burchardt] Removed the following packages from unstable: [...] xemacs21-packages | 2009.02.17.dfsg.1-1 | source Closed bugs: 726023 --- Reason --- RoQA; RC-buggy, unmaintained, dead upstream, not in stable -- Also closing bug(s): 46985 54387 56180 62287 63340 64290 64723 65469 74787 76139 76938 79127 82417 87623 87723 92073 95825 113489 113598 113599 116355 120985 123882 132544 133894 134426 137251 143163 143363 145279 146844 153113 154971 160740 162587 163957 163958 163961 163962 171150 183004 231059 236070 246638 248545 277451 281891 318020 320339 326783 327259 399483 403611 403771 440460 513574 522670 527389 609603 665253 683700 695799 699543 709501 712316 Also closing WNPP bug(s): = = [Date: Sun, 13 Oct 2013 09:52:05 +] [ftpmaster: Ansgar Burchardt] Removed the following packages from unstable: xemacs21 | 21.4.22-4 | source, all [...] Closed bugs: 725883 --- Reason --- RoQA; RC-buggy, unmaintained, dead upstream, not in stable -- Also closing bug(s): 39667 40202 40203 42457 47287 47515 49056 50712 51542 54069 54857 55892 56542 57468 60974 61132 61355 61665 62005 63285 63476 63697 63707 63744 64058 64513 64835 65494 66408 67045 67386 68017 72210 74084 74104 75456 75920 75998 76992 77372 77558 78446 78447 79144 80280 81915 83610 85817 88953 90542 92310 94623 98489 98501 99501 100956 101759 102513 104211 104213 104758 105928 106146 107168 107472 107776 108633 109032 109187 109738 110584 110646 110778 110976 112894 113368 113491 113585 114693 114797 117731 118828 122992 126074 126298 126773 128065 133822 134172 134689 135362 135805 142197 142555 143039 143107 143231 143915 144096 144413 145799 145847 146542 14 147171 147426 147556 147830 148750 150692 152878 153224 153778 154725 155424 155740 156144 156513 156515 156874 157858 158314 158573 160377 163219 164734 165503 167335 169016 171263 171433 171824 171830 173557 174489 175050 175234 177269 179649 180895 181129 182062 183119 183866 184197 186294 187609 187999 190163 192072 192075 194161 196524 196870 197301 198485 200717 200781 203879 204817 204852 206118 206381 206530 209157 209594 214638 216775 217341 219098 219809 224373 226734 229822 230792 234193 234204 234392 243683 245389 250314 254734 258572 268832 268833 268835 269244 272243 272452 273817 282275 282610 283159 283415 283569 285990 292438 296339 297916 301750 301752 304800 307617 309747 310799 312919 317725 331315 333845 334830 336445 338066 341005 343083 343330 343663 350003 350081 353077 355026 355348 355349 356584 357045 364433 365927 374198 374808 377962 382427 382434 395209 398756 399269 400859 403425 403877 410482 419922 422731 431252 431910 434468 438513 442428 444614 446137 446889 449294 463684 477623 485736 497262 507866 527966 528900 529607 539834 542492 563714 576747 580611 586785 589138 598320 608691 619367 634666 649686 650581 662557 681407 696146 712355 Also closing WNPP bug(s): = Andreas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5286cb0c.9010...@debian.org
wxWidgets 3.0 - espeakedit fixes
Hi,
I have attached two patches for espeakedit:
0001-*.patch -- This makes espeakedit compile.
0002-*.patch -- This fixes a segfault when constructing the wxFont
objects for SpectFrame. These were being constructed in the global
namespace. With wxWidgets 3.0, it now requires a gtk+ window when
constructing a wxFont. The change moves creation of the fonts to the
SpectFrame constructor, so a SpectFrame object holds them internally.
I have also removed FONT_NORMAL as this was not used in the code.
These are also available on my espeak github repository at
https://github.com/rhdunn/espeak on the master branch.
NOTE: These changes should be backward compatible with wxWidgets 2.8.
Now when I try and run espeakedit I get:
-
ASSERT INFO:
../src/gtk/font.cpp(337): assert "IsOk()" failed in GetPointSize(): invalid font
BACKTRACE:
[1] wxFont::GetPointSize() const
[2] wxObject::operator=(wxObject const&) /usr/include/wx-3.0/wx/object.
h:374
[3] MyFrame::MyFrame(wxWindow*, int, wxString const&, wxPoint const&,
wxSize const&, long) .../espeak/src/espeakedit.cpp:279
[4] MyApp::OnInit() .../espeak/src/espeakedit.cpp:178
[5] wxEntry(int&, wchar_t**)
[6] main .../espeak/src/espeakedit.cpp:99
[7] __libc_start_main
[8] _start
-
This is on the src/espeakedit.cpp line:
notebook->AddPage(transldlg,_T("Text"),TRUE);
any ideas?
NOTE: Pressing 'Continue' on the dialog causes espeakedit to open and
display correctly. I haven't done any major testing, just fixed the
compilation and ensured it started correctly.
Thanks,
Reece H. Dunn (Cainteoir Technologies) [http://www.reecedunn.co.uk]
From fdf52edf89303bb25c15a114ed084f4c526a7e2c Mon Sep 17 00:00:00 2001
From: "Reece H. Dunn"
Date: Sat, 16 Nov 2013 00:49:45 +
Subject: [PATCH 1/2] wxwidgets 3.0: make espeakedit compile
---
src/compiledata.cpp | 5 +
src/espeakedit.cpp | 7 +--
src/extras.cpp | 5 +
src/spectdisplay.cpp | 8
src/spectseq.cpp | 5 +
src/transldlg.cpp| 6 ++
src/vowelchart.cpp | 5 +
7 files changed, 39 insertions(+), 2 deletions(-)
diff --git a/src/compiledata.cpp b/src/compiledata.cpp
index 09645c3..4e22e81 100644
--- a/src/compiledata.cpp
+++ b/src/compiledata.cpp
@@ -1,6 +1,7 @@
/***
* Copyright (C) 2005 to 2013 by Jonathan Duddington *
* email: jo...@users.sourceforge.net*
+ * Copyright (C) 2013 by Reece H. Dunn *
* *
* This program is free software; you can redistribute it and/or modify *
* it under the terms of the GNU General Public License as published by *
@@ -42,6 +43,10 @@
#include
#endif
+#if wxCHECK_VERSION(3, 0, 0)
+#define wxOPEN wxFD_OPEN
+#endif
+
extern void FindPhonemesUsed(void);
extern void DisplayErrorFile(const char *fname);
extern int utf8_in(int *c, const char *buf);
diff --git a/src/espeakedit.cpp b/src/espeakedit.cpp
index e632c5a..4980e41 100644
--- a/src/espeakedit.cpp
+++ b/src/espeakedit.cpp
@@ -43,7 +43,10 @@
#include "translate.h"
#include "prosodydisplay.h"
-
+#if wxCHECK_VERSION(3, 0, 0)
+#define wxOPEN wxFD_OPEN
+#define wxSAVE wxFD_SAVE
+#endif
static const char *about_string2 = "espeakedit: %s\nAuthor: Jonathan
Duddington (c) 2009\n\n"
"Licensed under GNU General Public License version 3\n"
@@ -123,7 +126,7 @@ bool MyApp::OnInit(void)
{//=
int j;
-wxChar *p;
+const wxChar *p;
char param[80];
diff --git a/src/extras.cpp b/src/extras.cpp
index fa6ac3b..2141a6e 100644
--- a/src/extras.cpp
+++ b/src/extras.cpp
@@ -1,6 +1,7 @@
/***
* Copyright (C) 2006 to 2011 by Jonathan Duddington *
* email: jo...@users.sourceforge.net*
+ * Copyright (C) 2013 by Reece H. Dunn *
* *
* This program is free software; you can redistribute it and/or modify *
* it under the terms of the GNU General Public License as published by *
@@ -35,6 +36,10 @@
#include "translate.h"
#include "options.h"
+#if wxCHECK_VERSION(3, 0, 0)
+#define wxOPEN wxFD_OPEN
+#endif
+
extern char word_phonemes[N_WORD_PHONEMES];// a word translated into
phoneme codes
extern int __cdecl string_sorter(char **a, char **b);
diff --git a/src/spectdisplay.cpp b/src/spectdisplay.cpp
index efeb897..0904547 100644
--- a/src/spectdisplay.cpp
+++ b/src/spectdisplay.cpp
@@ -1,6 +1,7 @@
/***
* Copyright (C) 2005 to 2007 by Jonathan Duddington *
* email: jo...@users.sourceforge.net*
+ * Copyright (C) 2013 by Reece H.
Re: Bug#729660: ITP: xemacs21 -- highly customizable text editor
On Sat, Nov 16, 2013 at 09:44:51AM +0900, Charles Plessy wrote: > Le Fri, Nov 15, 2013 at 10:39:46AM -0500, Paul Tagliamonte a écrit : > > I'd have to look at the RC bugs. > > > > I'm looking for a hard commitment here > > Hi Paul, > > I think that if you focused on the compliance with the DFSG, then the NEW > queue > could empty quicker. My comments, unless otherwise noted, are those of me, Paul, *not* the ftpteam. I wasn't speaking for them, and I surely wouldn't do so without saying I was. This is my concern, as a DD, about an old fork, who's utility has been superseded (IMVHO), and had many open bugs (as anbe points out), being re-introduced (with nothing but good intentions) only to be removed again, due to a dead upstream and tons of issues piling up. I don't question the motives, nor intentions - just the workload in maintaining something like this. I'm not going to bother continuing to push this argument, since it's none of my damn business, I was just trying to feel better about it. For the record, I'd never abuse my role in the ftpteam to threten REJECT to win an argument. That would be extremely scummy behavior, and I'm not doing that now. Never have, never will. As jmtd points out, I don't even have a package in front of me, so I really can't comment yet. I'll let this work it's self out, don't worry about me. Much love, Paul -- .''`. Paul Tagliamonte : :' : Proud Debian Developer `. `'` 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `- http://people.debian.org/~paultag signature.asc Description: Digital signature
