Bug#1039898: broken in stable
severity 1039898 critical thanks This makes the package unusable in Debian 12, apparently People noticed in https://forums.debian.net/viewtopic.php?t=155302 -- Josip Rodin
Bug#197469: closed by Thorsten Alteholz (Re: gcal figures out the starting day incorrectly)
reopen 197469 thanks On Sat, Feb 28, 2009 at 03:03:02PM +, Debian Bug Tracking System wrote: > As I got no objection against the arguments in my last email three weeks > ago, I would like to declare this bug as an intentional feature and close > it. > > Feel free to reopen if needed. You sent that message to the bug address, which does NOT reach the submitter, so I'm reopening this out of principle. Please remember to actually contact the submitter next time you want to communicate something to them... But secondly, I'm reopening based on my response to that email which follows: > the author of gcal decided (according to general practice) to look for the > following environment variables: > $LANGUAGE > $LC_ALL > $LC_MESSAGES > $LANG > If one of those is defined, the value is further examined. There are only > two options: the value starts with "en_" or something different. > The first case means some kind of American style calendar where the days of > the week are written in a top row and the week starts with Sunday. > The second case means some kind of ISO calendar with days on the left side > and the week starts with Monday. So the logic of choosing is hardcoded into the program, even though it's initially based on locale data. It doesn't differentiate between en_US and en_UK, and I do seem to recall that US and UK differ in this matter in general practice. > According to ISO/IEC TR 14652 usage of $LC_TIME is problematic and might > result in unintended behaviour. I've googled that and found http://www.open-std.org/JTC1/SC22/WG20/docs/n972-14652ft.pdf There I see a detailed description of LC_TIME, including: first_weekday Define the first day to be displayed, for example in a calendar display utility. The operand is an integer specifying the day number (1 = first) according to the information specified with the "day" keyword. The keyword may be omitted, and then the value 1 is taken, corresponding to Sunday for a week beginning Sunday, or to Monday for a week beginning Monday. Granted, the section is marked with "(controversial)", and there are a few notes about problems, including: 7. The LC_TIME section includes some changes that are incompatible with POSIX.2. Some week definitions that have depended on Sunday being considered the first day of the week are changed in this TR to use Monday as the first day of the week. This would break existing implementations. However, I do not see exactly where the unintended behaviour would arise with regard to the issue of using this variable to determine the first day of the week - gcal already has its own logic of choosing, it's just the fine-grained variable choice that would be affected. Based on the description of that logic, I see two potential pitfalls: * American calendar users with (LANGUAGE|LC_ALL|LC_MESSAGES) = en_* and LC_TIME != en_* - if the logic was changed to cater to LC_TIME before LC_MESSAGES, they wouldn't get American calendar format if they didn't also have LANGUAGE or LC_ALL set to en_* * ISO calendar users with (LANGUAGE|LC_ALL|LC_MESSAGES) != en_* and LC_TIME = en_* - if the logic was changed to cater to LC_TIME before LC_MESSAGES, they wouldn't get ISO calendar format if they didn't also have LANGUAGE or LC_ALL set to something other than en_* Regarding our users, the description in locale(7) seems most pertinent LC_TIME changes the behavior of the strftime(3) function to display the current time in a locally acceptable form; for example, most of Europe uses a 24-hour clock versus the 12-hour clock used in the United States. I can't be sure, but I doubt that there are many users in any of the aforementioned two groups, because it would mean that: * they are an American calendar user with LC_TIME set so that local time shows European-style clock * they are an ISO calendar user with LC_TIME set so that local time shows US-style clock > Further it is correct to use $LC_MESSAGE to decide upon the language of > the output. Please keep in mind that gcal does not only output a calendar > but also holidays and events. That's fine, but I'm not talking about changing message handling, just the calendar (week) format handling. Don't you agree that calendar format is something different from normal message text? > In any case, if you want to avoide -s1, you could still set $LANGUAGE. I'm not sure to which value to set it if I don't want to alter the behaviour of LC_MESSAGES. locale(7) says: LC_MESSAGES changes the language messages are displayed in and what an affirmative or negative answer looks like. The GNU C-library contains the gettext(3), ngettext(3), and rpmatch(3) functions to ease the use of these information. The GNU gettext family of
Bug#554241: SVG support requires python-xml, but package has no dependency
Package: skencil Version: 0.6.17-16 Severity: minor Hi, I tried to open an SVG file with skencil, but then the program told me explicitly that I need to install the python-xml package to do that. Please add a Suggests or a Recommends relationship to facilitate that in the future. TIA. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#563270: grepmail: options to parse mbox in reverse order and to stop after a while
Package: grepmail Version: 5.3033-4 Severity: wishlist Hi, For date-based searches, if there was an option to search the input from bottom to top, and/or to stop after reaching a specified number of hits, it would be significantly faster than what we get now. For example: % ls -l randommbox -rw--- 1 joy joy 29640019 2010-01-01 12:32 randommbox % time grepmail -d 'since 5 days ago' randommbox | grep -c ^Date: 23 grepmail -d 'since 5 days ago' randommbox 14,88s user 0,31s system 99% cpu 15,201 total grep -c ^Date: 0,00s user 0,00s system 0% cpu 15,200 total % time tail -1 randommbox | grepmail -d 'since 5 days ago' | grep -c Date: 23 tail -1 randommbox 0,00s user 0,00s system 0% cpu 0,946 total grepmail -d 'since 5 days ago' 0,92s user 0,07s system 98% cpu 1,007 total grep -c Date: 0,00s user 0,00s system 0% cpu 1,005 total The trouble with the tail(1) above is that it's just a guess. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#571199: ships libdrvproxy.so, but doesn't really
Package: libiodbc2-dev Version: 3.52.6-4 Hi, % ls -l /usr/lib/libdrvproxy.so lrwxrwxrwx 1 root root 21 2009-11-23 20:20 /usr/lib/libdrvproxy.so -> libdrvproxy.so.2.1.18 % ls -l /usr/lib/libdrvproxy.so.2.1.18 ls: cannot access /usr/lib/libdrvproxy.so.2.1.18: No such file or directory % dpkg -S /usr/lib/libdrvproxy.so libiodbc2-dev: /usr/lib/libdrvproxy.so % dpkg -S /usr/lib/libdrvproxy.so.2.1.18 dpkg: /usr/lib/libdrvproxy.so.2.1.18 not found. This can't be right. Please fix it. TIA. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100224095738.ga6...@orion.carnet.hr
Re: Moving packages@qa.debian.org
On Sun, Dec 16, 2001 at 09:30:46PM +, Colin Watson wrote: > I'm told that debian-qa-packages has now been created. Could > [EMAIL PROTECTED] be pointed at that list instead of debian-qa, > please? I assume we have a consensus on this? (Have to check.) -- 2. That which causes joy or happiness.
Re: kde-i18n
On Sun, Dec 16, 2001 at 05:19:46PM -0700, Ivan E. Moore II wrote: > > I was wondering, how come there isn't a kde-i18n-* package for all available > > languages? I know that there are quite a bit of KDE translations for "hr", > > but there's no package for it that I can see... > > > > Not that I would use it :) but I have some clients that could be wondering > > about it. > > just to keep down on size. If there is no package for "hr" then the source > does not install any files for it. So how do I get KDE (on testing) to list "Croatian" in its language menu? (whatever that thing is called, I saw it after I first started it) -- 2. That which causes joy or happiness.
Re: Processed: done now
On Tue, Jan 01, 2002 at 03:33:09PM -0600, Debian Bug Tracking System wrote: > Processing commands for [EMAIL PROTECTED]: > > > tags 110331 + fixed > Bug#110331: libmicrowindows0-fb-dbg is not installable in unstable > Tags added: fixed Don't tag it fixed, either tag it pending (if it's in incoming) or close it. -- 2. That which causes joy or happiness.
Re: Processed: done now
On Tue, Jan 01, 2002 at 03:44:26PM -0800, Thomas Bushnell, BSG wrote: > > > Processing commands for [EMAIL PROTECTED]: > > > > > > > tags 110331 + fixed > > > Bug#110331: libmicrowindows0-fb-dbg is not installable in unstable > > > Tags added: fixed > > > > Don't tag it fixed, either tag it pending (if it's in incoming) or close it. > > Ok, I was trying to be conservative. > > Please clarify then: > > The normal rules for NMU's are that the bug is merely marked fixed, > right? > > Does that mean that QA uploads should not really be considered NMUs at > all? Yes. When you think about it, it's logical -- since you're doing this as a member of the QA group then the package is being uploaded by one of the maintainers :) > That's fine, but I thought I should err on the side of caution, not really > knowing which. No problem... we should probably document this somewhere. /me hides -- 2. That which causes joy or happiness.
Bug#129285: kde-i18n: possibly has a trademark issue
On Tue, Jan 15, 2002 at 12:06:13AM +0100, Martin Michlmayr wrote: > You're probably aware that SuSE was ordered for a short while to stop > shipping their Linux distribution because the krayon program clashed > with the "Crayon" trademark. (See > http://www.heise.de/english/newsticker/data/ray-09.01.02-000/ for the > full story.) As far as I understood the issue, it's essentially due to a weird German law that allows for extortion because of the long injunction. The trademark issue is frivolous. Unless they sue Debian mirror maintainers in Germany, there's nothing to worry about. Frankly, I doubt they would care to do that since our sponsors wouldn't be hurt by that (other than the fact they'd have to temporarily stop mirroring the package, and appear in court to say "they're nuts!"), but hey... -- 2. That which causes joy or happiness.
Bug#129285: kde-i18n: possibly has a trademark issue
On Tue, Jan 15, 2002 at 12:59:31PM +0100, Christian Kurz wrote: > > stop mirroring the package, and appear in court to say "they're nuts!"), but > > hey... > > No, it would be that only, they would also receive a fine which can > either be lots of money for them or even a term of imprisonment. How can you get fined if the suit is rebuffed in court? -- 2. That which causes joy or happiness.
Bug#129285: kde-i18n: possibly has a trademark issue
On Wed, Jan 16, 2002 at 01:32:54PM +0100, Martin Michlmayr wrote: > > How can you get fined if the suit is rebuffed in court? > > There only was an out-of-court agreement. That was because SuSE couldn't wait with their sales in Germany until they would win the suit, I thought. (cf. the Register article) -- 2. That which causes joy or happiness.
Bug#130084: german template file [playmidi 2.4-2]
On Sun, Mar 17, 2002 at 11:42:59AM +0100, Sebastian Feltel wrote: > at first: sorry for the delay; this is because I'm currenty serving at > the german federal armed forces :-( Can you PLEASE have your "I'm in the army" autoresponder ignore [EMAIL PROTECTED] and [EMAIL PROTECTED] It's causing a lot of spam for us. -- 2. That which causes joy or happiness.
Re: Trying to build Debian packages for KDE 3.0
On Fri, Apr 12, 2002 at 08:29:22PM -0700, Nick Garnett wrote: > Are you building KDE3.0 Debian packages? I think we need to make debian-kde@lists.debian.org the maintainer of the kde package. In the meantime, http://lists.debian.org/debian-qa-packages/2002/debian-qa-packages-200204/msg00068.html -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: libmusicbrainz
On Wed, May 29, 2002 at 10:20:00PM +1200, Andrew Hill wrote: > musicbrain isn't creating the correct symlinks in the /usr/lib directory > so it can't be correcktly linked to. > Applications that depend on libmusicbrain arn't working. > If you do a > ln -s /usr/lib/libmusicbrainz.so /usr/lib/libmusicbrainz.so.1.0.0 it > fixes the problem. apt-get install libmusicbrainz-dev # :) -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#170161: marked as done (nase-a60: Build-Depends on xlib6g*)
On Sun, Dec 01, 2002 at 05:33:20AM -0600, Debian Bug Tracking System wrote: > - /usr/doc/copyright/GPL has moved to /usr/share/common-licenses. Impressive. I don't believe I've seen one of these fixed since the last millenium... :) -- 2. That which causes joy or happiness.
Re: Bug#167886: marked as done (tux-aqfh-data: should replace older versions of tux-aqfh )
On Mon, Dec 02, 2002 at 12:15:37AM +, Colin Watson wrote: > In this case it's partly a Lintian bug. The link-to-undocumented-manpage > warning should be removed altogether, as policy has been amended to no > longer recommend the use of undocumented(7). Erm... isn't this exactly the reason to warn even more about having undocumented(7) symlinks? :) > > Overriding link-to-undocumented-manpage was acceptable: > > > > W: tux-aqfh: link-to-undocumented-manpage usr/share/man/man6/tux_aqfh.6.gz > > N: > > N: Symbolic links to the undocumented(7) manual page may be provided > > only > > N: when a bug has been filed that no manual page is available. If you > > N: like, you may report the bug yourself, and add an override for this > > N: warning in your package. > > N: > > Bleh, I disagree with that text. :-) Shaleh was generally consistent in > saying that overrides should only be used for cases where an exception > needs to be made to an otherwise correct general rule, and not to hide > Lintian bugs or package bugs. I don't know what Joy thinks, but this has > certainly been the guideline in the past. > > (I wonder if that text was my fault ... if so, oops.) I'm not sure where that description was going... I'll rephrase it to simply say that even if there's a undocumented(7) symlink, there's still no manual page and one should be written. Which reminds me, gotta fix the upgrading checklist, it says that not having manual pages has become a bug -- it's been a bug all along. -- 2. That which causes joy or happiness.
Bug#183985: kde: cannot dist-upgrade to KDE 3.1
On Sat, Mar 08, 2003 at 02:50:33PM -0500, Branden Robinson wrote: > Package: kde > Severity: important > Tags: sid > > GNOME 2.2 and KDE 3.1 seem to be fighting in some way. > > It should be possible to dist-upgrade GNOME and KDE without the user > having to "manually specify a solution". > > Marked as important because IMO we can't release sarge if people can't > dist-upgrade to sarge from woody. > > It's possible the problem is a bad Conflicts/Replaces/Provides in one of > the packages recompiled for the C++ ABI transition. Maybe libfam0? > Investigating kdelibs-bin > Package kdelibs-bin has broken dep on kdelibs3 > Considering kdelibs3 5 as a solution to kdelibs-bin 7 > Added kdelibs3 to the remove list > Considering kdelibs3 5 as a solution to kdelibs-bin 7 > Considering kdelibs3 5 as a solution to kdelibs-bin 7 > Considering kdelibs3 5 as a solution to kdelibs-bin 7 > Package kdelibs-bin has broken dep on kdelibs3-bin > Considering kdelibs3-bin 10 as a solution to kdelibs-bin 7 > Holding Back kdelibs-bin rather than change kdelibs3-bin > Investigating kdelibs4 > Package kdelibs4 has broken dep on kdelibs-bin > Considering kdelibs-bin 7 as a solution to kdelibs4 4 > Holding Back kdelibs4 rather than change kdelibs-bin > Investigating konqueror > Package konqueror has broken dep on kdelibs4 > Considering kdelibs4 4 as a solution to konqueror 0 > Removing konqueror rather than change kdelibs4 > The following packages will be REMOVED: > kdebase-libs kdelibs3 kdelibs3-bin konqueror libarts libarts-dev libfam0 > libkonq3 nas-lib > The following NEW packages will be installed: > kdelibs-data libarts1 libaudio2 libbonoboui2-0 libbonoboui2-common > libfam0c102 libgnome2-0 libgnomeui-0 libgnomevfs2-0 libgnomevfs2-common > libgsf-gnome-1 libqt3c102-mt > The following packages will be upgraded > gnumeric It looks that for some reason, kdelibs-bin doesn't obsolete kdelibs3-bin, which in turn gets konqueror removed. Maybe if kdelibs3-bin was completely removed, APT's logic would ignore it. I seem to have only Version: 4:2.2.2-13.woody.6 of that available, and I think that's from the security.d.o sources.list line, not from sid. -- 2. That which causes joy or happiness.
Bug#185442: sp: nsgmls dies with relocation error
Package: sp Version: 1.3.4-1.2.1-29 Severity: grave Hi, % debiandoc2html -c -l C developers-reference.sgml nsgmls: relocation error: nsgmls: undefined symbol: _ZTI9ParserApp make: *** [developers-reference.html] Error 127 -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux foo 2.4.20 #1 Pet Sij 3 17:02:50 CET 2003 i686 Locale: LANG=hr_HR, LC_CTYPE=hr_HR Versions of packages sp depends on: ii libc6 2.3.1-14 GNU C Library: Shared libraries an ii libgcc1 1:3.2.3-0pre5 GCC support library ii libsp11.3.4-1.2.1-28 Runtime library for James Clark's ii libstdc++51:3.2.3-0pre5 The GNU Standard C++ Library v3 ii sgml-base 1.17 utilities to maintain SGML catalog -- 2. That which causes joy or happiness.
Bug#185442: sp: nsgmls dies with relocation error
On Wed, Mar 19, 2003 at 01:14:05PM +0100, Josip Rodin wrote: > Package: sp > Version: 1.3.4-1.2.1-29 > Severity: grave > > Hi, > > % debiandoc2html -c -l C developers-reference.sgml > nsgmls: relocation error: nsgmls: undefined symbol: _ZTI9ParserApp > make: *** [developers-reference.html] Error 127 > > > > Versions of packages sp depends on: > ii libc6 2.3.1-14 GNU C Library: Shared libraries > an > ii libgcc1 1:3.2.3-0pre5 GCC support library > ii libsp11.3.4-1.2.1-28 Runtime library for James > Clark's > ii libstdc++51:3.2.3-0pre5 The GNU Standard C++ Library v3 > ii sgml-base 1.17 utilities to maintain SGML > catalog I've just upgraded to latest sid, and the above command works again! % dpkg -s libc6 libgcc1 libsp1 libstdc++5 sgml-base | grep Version Version: 2.3.1-15 Version: 1:3.2.3-0pre6 Version: 1.3.4-1.2.1-29 Version: 1:3.2.3-0pre6 Version: 1.17 Could it have been a glibc bug? (!) -- 2. That which causes joy or happiness.
Bug#327153: dosemu: fails to start
Hi, I also get a very similar error: % xdosemu ERROR: cpu exception in dosemu code outside of VM86()! trapno: 0x0e errorcode: 0x0005 cr2: 0xff8e eip: 0x69ee esp: 0xbfb5ffcc eflags: 0x00010246 cs: 0x0073 ds: 0x007b es: 0x007b ss: 0x007b Page fault: read instruction to linear address: 0xff8e CPU was in user mode Exception was caused by insufficient privilege ERROR: leavedos() called from within a signal context! I worked around the problem by downloading http://freedos.sourceforge.net/freecom/packages/082pl3/xmsswap.zip and using command.com from it as /usr/lib/dosemu/commands/comcom.com . -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#197469: closed by "Sandro Tosi" <[EMAIL PROTECTED]> (Re: gcal figures out the starting day incorrectly)
reopen 197469 thanks On Wed, Aug 13, 2008 at 05:33:03PM +, Debian Bug Tracking System wrote: > From: Sandro Tosi <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Re: gcal figures out the starting day incorrectly > > Version: 3.01.1-6 > > Here's what happen on my machine: > > $ locale > LANG=en_US.UTF-8 > LC_CTYPE="en_US.UTF-8" > LC_NUMERIC="en_US.UTF-8" > LC_TIME="en_US.UTF-8" > LC_COLLATE="en_US.UTF-8" > LC_MONETARY="en_US.UTF-8" > LC_MESSAGES="en_US.UTF-8" > LC_PAPER="en_US.UTF-8" > LC_NAME="en_US.UTF-8" > LC_ADDRESS="en_US.UTF-8" > LC_TELEPHONE="en_US.UTF-8" > LC_MEASUREMENT="en_US.UTF-8" > LC_IDENTIFICATION="en_US.UTF-8" > LC_ALL= > > $ LC_MESSAGES=hr_HR gcal > > August 2008 > > Monday 4 11 18 25 > Tuesday 5 12 19 26 > Wednesday 6 13 20 27 > Thursday7 14 21 28 > Friday 1 8 15 22 29 > Saturday 2 9 16 23 30 > Sunday 3 10 17 24 31 > [EMAIL PROTECTED]:/tmp$ gcal > > August 2008 > Su Mo Tu We Th Fr Sa > 1 2 > 3 4 5 6 7 8 9 > 10 11 12 13 14 15 16 > 17 18 19 20 21 22 23 > 24 25 26 27 28 29 30 > 31 > > $ LC_ALL=hr_HR gcal > > August 2008 > > Monday 4 11 18 25 > Tuesday 5 12 19 26 > Wednesday 6 13 20 27 > Thursday7 14 21 28 > Friday 1 8 15 22 29 > Saturday 2 9 16 23 30 > Sunday 3 10 17 24 31 > > I can conclude this bug is fixed. Feel free to reopen if needed. Well, all I can conclude is that you didn't actually read my bug report :) > Surely it should honor something like LC_NUMERIC or LC_TIME or even LANG > rather than LC_MESSAGES for the ordering issue? No other program forces me to set LC_ALL to hr_HR in order to get sensible behaviour, so gcal shouldn't, either. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#209477: The package description does not follow Debian policy
On Sun, Sep 14, 2003 at 08:51:04AM +0200, Christian Perrier wrote: > > May I suggest: > > > > Description: Color version of hextris > > Description: Color version of hextris May I suggest fixing that one as well? Something that would provide a better hint at what the hell the game is about? :) Description: stack colored hexagon shapes until you get a headache -- 2. That which causes joy or happiness.
