Bug#808234: signify: Depends on virtual package "perl5" which is gone with perl/5.22
Thanks. I no longer have a Debian development machine. -- Brian On Thu, Dec 17, 2015 at 9:16 AM, Dominic Hargreaves wrote: > Package: signify > Version: 1.14-1 > Severity: serious > Justification: package uninstallable > Tags: sid pending > User: debian-p...@lists.debian.org > Usertags: perl-5.22-transition > > The perl 5.22 transition just started (see > https://lists.debian.org/debian-devel-announce/2015/12/msg5.html) > and we seem to have missed that this package depends on the deprecated > virtual package "perl5" like some other packages did. > > The perl 5.22 packages don't provide perl5, making this package > uninstallable. > > I'll do a QA upload shortly. > > Cheers, > Dominic. > -- Brian bcwh...@pobox.com -- *Treat someone as they are and they will remain that way.Treat someone as they can be and they will become that way.*
Bug#658139: Collaborative maintenance of mime-support (was Re: Using FreeDesktop MIME entries directly in mime-support).
> > Lastly, I would like to thank Brian for his impressively 16-years long > work on > mime-support. Brian, feel free to stay among the uploaders ! > Thanks. I wish I had the energy to make some of the much-needed changes but I'm just not involved with the project enough these days to have a good feel for how it should be improved. Make it great! Brian bcwh...@pobox.com -- *Treat someone as they are and they will remain that way. Treat someone as they can be and they will become that way.*
Bug#674089: mime-support: removed application/x-httpd-* can lead to immense security problems
> > In 3.52-1 you removed application/x-httpd-* to close #589384. > I have no preference to it being present or not. It was marked as "release critical" by the Apache/PHP folks. Decide among yourselves what is correct and I'll make it that way. -- Brian > > This happened without any notice to the NEWS files and I really > wonder whether any though has been spent on which tremendous > security effects this can have. > > Given that most people (reasonably) rely on /etc/mime.types > to determine the MIME type for files e.g. with Apache removal > of the above means e.g. that php scripts are no longer determined > as such, but now diretcly shown as text files. > > With all secruity effects you can think of and all you even can't > think of. > And of course it breaks countless of working installations > using e.g. php. > > > a) If you make such a tremendous change you have to announce it > in the release file. > > > b) Removing the type is definitly the wrong decision. > Apache provides many means to change the handlers and if all that > shouldn't work (which I doubt) on can simply disable the use of > /etc/mime.types. > It's not the business of mime.type to please any specifc user,... > like it seems to me with the aforementioned bug. > Nor should it be mime.type's business to please any software if that > was borken (but as said, apache is not). > > > > Obviously application/x-* are not official flags, but if that was > the reason we'd have to remove much more than just the php ones. > > > > Cheers, > Chris. > > > -- System Information: > Debian Release: wheezy/sid > APT prefers unstable > APT policy: (500, 'unstable') > Architecture: amd64 (x86_64) > > Kernel: Linux 3.2.17-heisenberg (SMP w/2 CPU cores; PREEMPT) > Locale: LANG=en_DE.UTF-8, LC_CTYPE=en_DE.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > > mime-support depends on no packages. > > Versions of packages mime-support recommends: > ii file 5.11-1 > > mime-support suggests no packages. > > -- no debconf information > >
Bug#458691: mime-support should not register a "view" alternative at any priority
severity 458691 wishlist tag 458691 wontfix -- mime-support does not provide "the same functionality but different implementations". It provides a program "with different functionality but the same filename". That does not represent an appropriate use of the alternatives mechanism. Sure it does. It views a file without changing it. Not all web browsers provide identical functionality and yet they're considered the same. Heck, not even all vi instances provide identical functionality. -- Brian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#458691: mime-support: diff for NMU version 3.40-1.1
Brian, any particular reason why you didn't include this patch in your subsequent uploads, or did you just miss it? This bug is release-critical, was filed in January and has no comment from you... Your latest uploads of mime-support still install the /usr/bin/view alternative, and don't clean it up in prerm. I just missed it, which is odd since I specifically looked for it. Sorry. I'll take care of it. -- Brian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#480374: Update
-rw-r--r-- 1 debmirror debmirror 419 2008-05-26 15:17 rfc1522.txt -rw-r--r-- 1 debmirror debmirror 22502 1993-09-23 01:08 rfc1522.txt~ -rw-r--r-- 1 debmirror debmirror 393 2008-05-26 15:17 rfc1523.txt -rw-r--r-- 1 debmirror debmirror 32691 1993-09-23 01:10 rfc1523.txt~ -rw-r--r-- 1 debmirror debmirror 393 2008-05-26 15:18 rfc1524.txt -rw-r--r-- 1 debmirror debmirror 26464 1993-09-23 01:11 rfc1524.txt~ Oh! The ~ files got included. I'll fix that. -- Brian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#454520: jukebox-mercury: should this package be removed?
severity 454520 normal reassign 454520 ftp.debian.org retitle 454520 RM: jukebox-mercury -- not supported -- While reviewing some packages, your package came up as a possible candidate for removal from Debian, because: * several RC bugs * long since last maintainer upload, last NMU in 2003 * low popcon If you think that it should be orphaned instead of being removed from Debian, please reply to this bug and tell so. I'm not supporting it. Do with it what you will. -- Brian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#367727: jukebox-mercury: must use invoke-rc.d
tags 367727 +patch thanks On 06/05/18 00:21 +0300, Lars Wirzenius said ... As of Debian Policy Manual version 3.7.2, the use of invoke-rc.d to run init.d scripts has been made mandatory. Earlier, its use was I no longer have the Mercury box I used to originally play with this. If you're using it, why not take over the package? -- Brian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#408252: jukebox-mercury is not suitable for a stable release
On 24/01/07 at 11:05 -0500, Brian White wrote: It's in "experimental". It's not supposed to be considered stable. No, it's in sarge, etch and sid, according to http://packages.qa.debian.org/j/jukebox-mercury.html Hmmm... Then somebody moved it. Do you know the steps required to remove it? -- Brian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#325441: remove from debian
Brian said that he was going to rename it, but that was a year ago.
Unless there's some plan to fix it RSN, I think we should remove it from
the archive in the meantime.
I tried to rename it but it was rejected as being a "new package" and I
just haven't had the time/will/desire to follow through.
Brian
( [EMAIL PROTECTED] )
---
When you love someone, you're always insecure. ("Tell Her About It" --
B.Joel)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#349745: squid-prefetch: Crashes every few minutes
Not necessarily. 127.0.0.1 is the network loopback device, so *any* program on that machine which accesses the outside world via squid will show as 127.0.0.1 in the squid log, not just squid-prefetch as you imply. True. I don't use the loopback interface for connecting to squid from user clients, so I don't have that ambiguity. You can usually differentiate between clients and squid-prefetch by the log line itself. The first access by squid-prefetch will always be a TCP_HIT/200 or TCP_MISS/504 (I think it's 504). After that will be the prefetches. Or... just run it from the command line so you can see STDOUT. Brian ( [EMAIL PROTECTED] ) --- There's no healthy way to mess with the line between wrong and right. oel) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#349745: squid-prefetch: Crashes every few minutes
I now stays up thanks, though I can't work out how to be sure it's doing anything since it doesn't have a log file. Check out Squid's log file. Accesses from 127.0.0.1 will be from the prefetch. Brian ( [EMAIL PROTECTED] ) --- Idleness, indifference & irresponsibility are healthy responses to absurd work. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#325441: Violates trademark
Using the name "Scrabble" for a game is a clear trademark violation; using something *remotely* similar to "Scrabble" is *not* a "clear" trademark violation. The standard in the US, and I believe in Europe as well, is that you must not use *confusingly* similar names. I'm renaming it to "Scribble". Since that's a real English word, you can't use it as a trademark. Hasbro also claims rights on the rules, I have no idea whether that is valid, It is not valid. In the US and Europe, game authors have no ownership rights on game rules. Oh well; my rules are slightly different anyway. Obviously, you can't challenge the computer (it's always right) and it won't make you lose your turn if you try a bad word. but it seems like a very good idea to have the rules be nonequal to Hasbro's, by changing the bonus layout or something. I think it's a bad idea to cave to pressure from unethical corporations trying to throw their weight around. It is. Unfortunately, it can be costly to stand up to them, especially when they are right on at least one case (using the name "Scrabble"). I don't think it's good for Debian to be the one to have to face them, either. My code has been released in the public domain, so there is nothing they can do to stop it. Brian ( [EMAIL PROTECTED] ) --- Successful is the person who has lived well, laughed often and loved much, who has gained the respect of children, who leaves the world better than they found it, who has never lacked appreciation for the Earth's beauty, who never fails to look for the best in others or give the best of themselves. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#294404: udev does not create /dev/md* devices at boot-up
> Therefore, I'm reassigning to mdadm -- which is the package failing to > start on missing md* nodes. I think that since this bug is hard to solve > in udev (should it create md* always, even if one hasn't RAID at all?) > or the kernel (autostarting simply isn't possible in modular md, it > seems), it would be appropriate for mdadm to while scanning partitions > for RAID parts to assamble, to create md device nodes as needed, in > stead of failing on the non-exitance of them. I tried doing a manual "./MAKEDEV md" and even an explicit "mknode" on /dev/md to try to mount the arrays manually, but it always failed without any error message. Perhaps I was doing something wrong or it may be necessary to have udev do the creation of the nodes. Brian ( [EMAIL PROTECTED] ) --- Touch passion when it comes your way. It's rare enough as it is. Don't walk away when it calls you by name. -- Marcus (Babylon 5) --- ( Couldn't verify my signature? Use http://www.precidia.com/precidia.crt ) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#294404: udev does not create /dev/md* devices at boot-up
reopen 294404 reassign 294404 kernel-image-2.6-686 -- > This is a kernel bug. > There is already a bug open against the kernel. > I have seen no progress on its resolution. I couldn't find the bug number, so I just reassigned this to the base kernel I'm using. Somebody else will have to merge it. Brian ( [EMAIL PROTECTED] ) --- Sticks and stones may break bones, but words will shatter the soul. --- ( Couldn't verify my signature? Use http://www.precidia.com/precidia.crt ) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#294404: udev does not create /dev/md* devices at boot-up
Package: udev Version: 0.050-6 Severity: critical When I installed my new system last month, I used the latest "testing" install CD and created RAID systems for /usr and /var (RAID1 and RAID0, respectively). I then installed the stock 2.6.8 kernel and later the 2.6.10 kernel. So far, so good. Yesterday I installed "udev" (and "hotplug") to access by USB camera and "bad things"(tm) happened. The system ran fine until a reboot and then it failed to mount the RAID partitions. Some investigation showed that /dev/md0 and /dev/md1 did not exist. Luckily, I still had the original 2.4 kernel and could boot with that and "dpkg --purge udev". After that, the system booted normally again. Brian ( [EMAIL PROTECTED] ) --- You can't talk yourself out of problems you behave yourself into. --- ( Couldn't verify my signature? Use http://www.precidia.com/precidia.crt ) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
