Bug#877711: Latest upstream firmware resolves this issue
Hi, I can confirm that Brian Tarricone's solution also works for me, and the latest firmware resolves the issue: I.e. this commit from the 9th October: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware .git/commit/ath10k/QCA6174/hw3.0?id=96a7402d4172f4786ee93dd9f7cb3f76e1a 8025e "Update from a new firmware branch. This also fixes a regression with ath10k frequently disconnecting." Thanks, Andrew McMillan. -- -- https://google.com/+AndrewMcMillan Dublin, Ireland +353 (87) 372 7098 Whereof one cannot speak, thereon one must remain silent. -- Wittgenstein --
Bug#877711: firmware-atheros: Wifi connection becomes unreliable after upgrade to 20170823-1
Package: firmware-atheros Version: 20161130-3 Severity: important Tags: upstream After upgrading to firmware-atheros_20170823-1 my wifi becomes unreliable, working for approximately 5-15 minutes before stopping transporting packets to my access point. This issue is not sensitive to: - The model of access point I am connecting to (tested vs OpenWRT, Apple & Cisco) - The kernel version (tested vs 4.11, 4.12 & 4.13 kernels) I can unload the relevant modules and reload them and things work again... for another 5-15 minutes. The only sure-fire solution for me has been to downgrade to version 20161130-3, which seems to have no issues. Sometimes I see the following trace in dmesg: [ 2992.777128] [ cut here ] [ 2992.777139] WARNING: CPU: 7 PID: 0 at /build/linux- wJBo44/linux-4.13.4/net/core/dev.c:5504 net_rx_action+0x280/0x3c0 [ 2992.777140] Modules linked in: ath10k_pci ath10k_core ath rfcomm ipt_MASQUERADE nf_nat_masquerade_ipv4 nf_conntrack_netlink nfnetlink fuse xfrm_user xfrm_algo iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 xt_addrtype xt_conntrack nf_nat nf_conntrack br_netfilter bridge stp llc overlay ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter cpufreq_userspace cpufreq_conservative cpufreq_powersave ctr ccm cmac bnep binfmt_misc nls_ascii nls_cp437 vfat fat arc4 uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_core videodev btusb media btrtl joydev hid_multitouch snd_hda_codec_hdmi msr intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel dell_laptop dell_wmi i2c_designware_platform i2c_designware_core kvm dell_smbios snd_hda_codec_realtek dell_smm_hwmon [ 2992.777217] wmi_bmof dcdbas mxm_wmi snd_hda_codec_generic irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_intel rtsx_pci_ms hci_uart efi_pstore memstick btbcm nvidia_drm(O) snd_hda_codec intel_cstate mac80211 nvidia_modeset(O) btqca snd_hda_core intel_uncore pcspkr btintel snd_hwdep intel_rapl_perf bluetooth evdev snd_pcm cfg80211 serio_raw efivars snd_timer i915 snd iTCO_wdt soundcore iTCO_vendor_support drbg drm_kms_helper ansi_cprng idma64 mei_me drm processor_thermal_device ecdh_generic i2c_algo_bit mei sg shpchp intel_soc_dts_iosf intel_lpss_pci intel_pch_thermal battery rfkill intel_lpss_acpi dell_smo8800 intel_lpss wmi video acpi_als int3403_thermal kfifo_buf int3400_thermal int340x_thermal_zone acpi_thermal_rel industrialio intel_hid tpm_crb button acpi_pad ac sparse_keymap [ 2992.777295] tcp_bbr ib_iser rdma_cm iw_cm ib_cm ib_core configfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi nvidia_uvm(O) nvidia(O) elan_i2c parport_pc ppdev lp parport efivarfs ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 fscrypto ecb raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c crc32c_generic raid1 raid0 multipath linear md_mod sd_mod hid_generic usbhid rtsx_pci_sdmmc mmc_core crc32c_intel aesni_intel aes_x86_64 crypto_simd cryptd glue_helper ahci libahci xhci_pci libata xhci_hcd i2c_i801 rtsx_pci mfd_core scsi_mod usbcore usb_common thermal i2c_hid hid [last unloaded: ath] [ 2992.777374] CPU: 7 PID: 0 Comm: swapper/7 Tainted: G O 4.13.0-1-amd64 #1 Debian 4.13.4-1 [ 2992.777376] Hardware name: Dell Inc. XPS 15 9560/05FFDN, BIOS 1.1.3 01/18/2017 [ 2992.777378] task: 93262ce48040 task.stack: 9e7681974000 [ 2992.777383] RIP: 0010:net_rx_action+0x280/0x3c0 [ 2992.777385] RSP: 0018:93263f5c3ee0 EFLAGS: 00010293 [ 2992.777388] RAX: 0042 RBX: 0042 RCX: 93246e271e80 [ 2992.777390] RDX: 9321f64ad000 RSI: fe01 RDI: c1a62243 [ 2992.777392] RBP: 0040 R08: 000299c0db40 R09: 36f9 [ 2992.777394] R10: R11: 0002 R12: 012c [ 2992.777396] R13: 93246e277a40 R14: R15: [ 2992.777400] FS: () GS:93263f5c() knlGS: [ 2992.777402] CS: 0010 DS: ES: CR0: 80050033 [ 2992.777404] CR2: 7f15ac3f0ab8 CR3: 000141409000 CR4: 003406e0 [ 2992.777406] Call Trace: [ 2992.777411] [ 2992.777417] ? __do_softirq+0x105/0x293 [ 2992.777424] ? irq_exit+0xae/0xb0 [ 2992.777427] ? do_IRQ+0x4a/0xc0 [ 2992.777432] ? common_interrupt+0x82/0x82 [ 2992.777434] [ 2992.777440] ? cpuidle_enter_state+0x11f/0x2b0 [ 2992.777446] ? do_idle+0x188/0x1f0 [ 2992.777451] ? cpu_startup_entry+0x6f/0x80 [ 2992.777457] ? start_secondary+0x14f/0x190 [ 2992.777460] ? secondary_startup_64+0x9f/0x9f [ 2992.777463] Code: 5d 01 00 00 48 83 c4 40 5b 5d 41 5c 41 5d 41 5e 41 5f c3 89 ee 4c 89 ef 41 ff 55 20 89 c3 0f 1f 44 00 00 39 dd 0f 8d d6 fe ff ff <0f> ff 39 dd 0f 8f d4 fe ff ff 49 8b 45 10 a8 04 0f 85 da 00 00 [ 2992.777529] ---[ end trace 15d423f6ce84b6e8 ]--- That doesn't show up every time when the drivers stop though, so perhaps it is unrelated. Thanks, A
Bug#742498: I'm very happy to see a team maintaining this package
I'm totally happy to see the team take over responsibility for the Debian packaging (and upstream development :-) Cheers, Andrew. -- https://google.com/+AndrewMcMillan Porirua, New Zealand +64 (272) 332 426 Beware of a tall black man with one blond shoe. signature.asc Description: This is a digitally signed message part
Bug#703290: davical: possible code insertion or XSS
Also worth noting that there is a (non-default) configuration setting
that restricts the availability of setup.php to only administrators.
I guess I'm listed as 'upstream' for DAViCal as well as being the DD
responsible for the package. Unfortunately I have no time to do either
job for the foreseeable future.
So if people think this sort of thing is actually 'grave' then someone
other than me needs to step forward and apply the (presumably trivial)
fixes that resolve it. I guess that would be to htmlencode the response
from that URL, since making it 'SSL' (as far as I can see) would add
approximately 0.1% of additional security.
I note that 12 characters is precisely sufficient to contain 'script
src=' and no more.
Cheers,
Andrew.
On Mon, 2013-03-18 at 03:10 +0100, Christoph Anton Mitterer wrote:
Package: davical
Version: 1.1.1-1
Severity: grave
Tags: security upstream
Justification: user security hole
Hi.
Marking this as grave for now, so that the security team get's notified
and can have a look whether this is more serious.
I personally think it's not that serious and the checking security team
member can likley lower the severity. (thanks)
In Davical's /usr/share/davical/htdocs/setup.php there's code
that shows one whether the current version is used.
check_davical_version() does about this:
$url =
'http://www.davical.org/current_davical_version?v='.$c-version_string;
$version_file = @fopen($url, 'r');
if ( ! $version_file ) return new CheckResult( false, translate(Could not
retrieve) . '$url', 'dep_warning' );
$current_version = trim(fread( $version_file,12));
fclose($version_file);
$result = new CheckResult($c-version_string == $current_version);
if ( ! $result-getOK() ) {
if ( $c-version_string $current_version ) {
$result-setClass('dep_ok');
$result-setDescription( sprintf(i18n('Stable: %s, We have: %s !'),
$current_version, $c-version_string) );
}
else {
$result-setDescription( sprintf(i18n('Want: %s, Currently: %s'),
$current_version, $c-version_string) );^M
}
}
1) The URL is not SSL secure... but even if,... that wouldn't change anything
IMHO.
2) An attacker can possibly insert up to 12 characters into $current_version
which are then not checked for their content.
That 12 characters are subsequentally sprintf-ed into HTML which is set to
the user.
Well I don't know whether one can do any nasty things in 12 characters... but
there
are kinda freaks out there.
Workaround for now would be to set:
http://www.php.net/manual/en/filesystem.configuration.php#ini.allow-url-fopen
to On.
Cheers,
Chris.
--
andrew (AT) morphoss (DOT) com +64 (2) 7233 2426
Even a hawk is an eagle among crows.
signature.asc
Description: This is a digitally signed message part
Bug#703290: davical: possible code insertion or XSS
On Mon, 2013-03-18 at 18:46 +0100, Moritz Muehlenhoff wrote: On Mon, Mar 18, 2013 at 07:43:09PM +1300, Andrew McMillan wrote: I guess I'm listed as 'upstream' for DAViCal as well as being the DD responsible for the package. Unfortunately I have no time to do either job for the foreseeable future. Should we rather drop davical from Wheezy, then? We generally try to avoid shipping packages, where upstream is unavailable or inactive. Is there any way to do an XSS exploit in 12 characters? If not, then I don't think this is 'grave'. Cheers, Andrew. -- andrew (AT) morphoss (DOT) com +64 (2) 7233 2426 As a computer, I find your faith in technology amusing. signature.asc Description: This is a digitally signed message part
Bug#682469: libjaxe-java: Dependency on openoffice.org-java-common should change to libreoffice-java-common
Package: libjaxe-java Version: 3.5-2 Severity: minor Dear Maintainer, This dependency needs to change now that openoffice.org-java-common is a virtual dependency on libreoffice-java-common. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (950, 'unstable'), (150, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.5.0-rc5-dave (SMP w/8 CPU cores) Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libjaxe-java depends on: ii libavalon-framework-java 4.2.0-8 ii libbatik-java1.7+dfsg-3 ii libcommons-io-java 1.4-4 ii libcommons-logging-java 1.1.1-9 ii libcortado-java 0.6.0-1 ii libfop-java 1:1.0.dfsg2-6 ii libjazzy-java0.5.2-1 ii libjing-java 2009-5 ii liblog4j1.2-java 1.2.16-3 ii libxalan2-java 2.7.1-7 ii libxerces2-java 2.11.0-6 ii libxml-commons-external-java 1.4.01-2 ii libxml-commons-resolver1.1-java 1.2-7 ii libxmlgraphics-commons-java 1.4.dfsg-4 ii libxsltc-java2.7.1-7 pn openoffice.org-java-common none libjaxe-java recommends no packages. libjaxe-java suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#619477: Possible missing build-depends
This will be closed in the upcoming release, but a little more explanation is in order. Firstly, the extract script is removed and replaced by xgettext which supports PHP nowadays, which is why this bug can now be closed. The dependency on libawl-php is because the creation of full translation files for DAViCal depends on translating some strings which are present in the library - it's not needed for the execution of any code in this instance. Regards, Andrew McMillan. -- andrew (AT) morphoss (DOT) com+64(272)DEBIAN taxidermist, n.: A man who mounts animals. signature.asc Description: This is a digitally signed message part
Bug#638924: [nginx-extras] Description does not list all included modules
Package: nginx-extras Version: 1.1.0-1 Severity: minor It seems from the source and from the changelog that various new modules are included in -extras but they are not listed in the description. The http-push module is the one that I noticed in this regard but I think there could be others, as well. Regards, Andrew McMillan. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (950, 'unstable'), (150, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.0.1-dave (SMP w/8 CPU cores) Locale: LANG=en_NZ.utf8, LC_CTYPE=en_NZ.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages nginx-extras depends on: ii libc6 2.13-16Embedded GNU C Library: Shared lib ii libgd2-xpm2.0.36~rc1~dfsg-5.1+b1 GD Graphics Library version 2 ii libgeoip1 1.4.8+dfsg-1 non-DNS IP-to-country resolver lib ii liblua5.1-0 5.1.4-10 Shared library for the Lua interpr ii libpcre3 8.12-4 Perl 5 Compatible Regular Expressi ii libperl5.12 5.12.4-3 shared Perl library ii libssl1.0.0 1.0.0d-3 SSL shared libraries ii libxml2 2.7.8.dfsg-4 GNOME XML library ii libxslt1.11.1.26-8 XSLT 1.0 processing library - runt ii nginx-common 1.1.0-1small, but very powerful and effic ii perl 5.12.4-3 Larry Wall's Practical Extraction ii perl-base [perlap 5.12.4-3 minimal Perl system ii zlib1g1:1.2.3.4.dfsg-3 compression library - runtime nginx-extras recommends no packages. nginx-extras suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#89038: mime policy copying update-mime(8)
On Sun, 2011-04-03 at 20:44 -0700, Russ Allbery wrote: The bug: http://bugs.debian.org/89038 is still looking for two more seconds. This would allow us to retire the tiny separate mime-policy document. Could other folks take a look and confirm that all looks well? We separately should really include more documentation of this subsystem, but that can be handled separately and we seem to have gone many years without noticing a serious lack. Seconded. Cheers, Andrew. -- andrew (AT) morphoss (DOT) com+64(272)DEBIAN Some optional equipment shown. signature.asc Description: This is a digitally signed message part
Bug#548867: Proposed patch to update Debian Developer's Duties chapter
On Sun, 2011-03-13 at 10:05 +0100, Lucas Nussbaum wrote: Hi, As one of the (ex-)?dev-ref maintainers, I was also asked to comment by Raphael. Generally, I think that the patch goes in the right direction. I'd like to suggest changes to the last paragraph, though: Lack of attention to RC bugs is often interpreted by the QA team as a sign that the maintainer has disappeared without properly orphaning his package. -Don't be surprised if the MIA team enters in action and ends up orphaning -your packages (see xref linkend=mia-qa /). But you should really avoid -that situation in the first place and ensure that your packages get the attention -that they deserve. +The MIA team might enter in action, which could end up in your packages being +orphaned (see xref linkend=mia-qa /). (I find the last sentence useless as is.) The phrase enter in action sounds really weird. Is it supposed to mean something like also get involved, so perhaps more correct wording might be: +The MIA team might also get involved, which could result in your +packages being orphaned (see xref linkend=mia-qa /). Also, is it true that the MIA team would orphan all of your packages in this case, or just the one that had the unattended RC bug? If it would just be the one then we should say that. Regards, Andrew. -- andrew (AT) morphoss (DOT) com+64(272)DEBIAN I like being single. I'm always there when I need me. -- Art Leo signature.asc Description: This is a digitally signed message part
Bug#604990: clarify man page dates policy
On Thu, 2010-11-25 at 22:29 -0800, Russ Allbery wrote: jida...@jidanni.org writes: RA == Russ Allbery r...@debian.org writes: RA No, I don't believe that it should. I don't think this is something that RA we need to make technical Policy about. RA I'll leave this bug open for a bit before closing in case someone else RA disagrees. Well then please add in the manual that Debian officially has no opinion on dates on the man pages, and one is free to do as one feels fit on the matter. I don't see the need for Policy to say anything about this, personally. This seems rather cosmetic to be addressed in Policy. Seconded. Cheers, Andrew. -- andrew (AT) morphoss (DOT) com+64(272)DEBIAN Unnamed Law: If it happens, it must be possible. signature.asc Description: This is a digitally signed message part
Bug#593611: Clarify whose signature should go in debian/changelog (4.4)
On Sat, 2010-09-18 at 21:10 -0700, Russ Allbery wrote: Okay, here's new proposed wording that incorporates some of the discussion on this bug along with my personal opinion on the best wording. How does this look to everyone? diff --git a/policy.sgml b/policy.sgml index 642f672..314d5d0 100644 --- a/policy.sgml +++ b/policy.sgml @@ -1688,11 +1688,14 @@ p The maintainer name and email address used in the changelog - should be the details of the person uploading emthis/em - version. They are emnot/em necessarily those of the - usual package maintainer.footnote - If the developer uploading the package is not one of the usual - maintainers of the package (as listed in + should be the details of the person who prepared this release of + the package. They are emnot/em necessarily those of the + uploader or usual package maintainer.footnote + In the case of a sponsored upload, the uploader signs the + files, but the changelog maintainer name and address are those + of the person who prepared this release. If the preparer of + the release is not one of the usual maintainers of the package + (as listed in the qref id=f-MaintainerttMaintainer/tt/qref or qref id=f-UploadersttUploaders/tt/qref control fields of the package), the first line of the changelog is Seconded. And I don't understand Ben's objection, since I think you've nicely *avoided* using the word 'sign' in the sense of being recorded in the changelog entry. Cheers, Andrew. -- andrew (AT) morphoss (DOT) com+64(272)DEBIAN The truth about a woman often lasts longer than the woman is true. signature.asc Description: This is a digitally signed message part
Bug#550195: evolution: WebDAV contacts don't work
Hi, I previously used WebDAV contacts in the past, but they don't seem to work at all for me now. I have tested this with a new install of Squeeze into a 32-bit VM, and with my main laptop running 64-bit Sid. I have tried with, and without proxies operating, as suggested in an earlier message to this bug report. This is excessively vexatious for me as I just added CardDAV support to my CalDAV server and Evolution was *working* with this in the past (dammit :-) I have looked for traffic leaving Evolution with Wireshark, and as far as I can see it actually does not get as far as starting an HTTP connection, just sitting there with a spinner saying Loading Addressbook Summary... in the status bar while it says Searching for the Contacts... in the main panel. If you have any helpful suggestions for debugging this it would be appreciated, up to and including rebuilding Evolution or E-D-S, but just some information on how to get a few debugging messages out of the WebDAV contacts plugin would be much appreciated. Regards, Andrew McMillan. -- andrew (AT) morphoss (DOT) com+64(272)DEBIAN Confirmed bachelor: A man who goes through life without a hitch. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#588014: Documenting the DM-Upload-Allowed field.
On Sat, 2010-09-11 at 23:47 +0900, Charles Plessy wrote: Le Sat, Sep 11, 2010 at 04:15:15PM +0200, Emilio Pozuelo Monfort a écrit : Capitalization is inconsistent across the patch. I guess you should fix that. Ooops (correction attached). I support the change, with the correction. Cheers, Andrew. -- andrew (AT) morphoss (DOT) com+64(272)DEBIAN To communicate is the beginning of understanding. -- ATT -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#522776: debian-policy: mandate existence of a standardised UTF-8 locale
On Sat, 2010-09-04 at 16:08 +0200, Bill Allombert wrote: On Sat, Sep 04, 2010 at 12:37:07AM +0200, Samuel Thibault wrote: Aurelien Jarno, le Fri 03 Sep 2010 19:16:40 +0200, a écrit : On Fri, Sep 03, 2010 at 04:20:27PM +0200, Samuel Thibault wrote: Roger Leigh, le Fri 03 Sep 2010 14:52:39 +0100, a écrit : There were no objections to having a UTF-8 locale installed and available by default, just to it *being* the default. Taking this first small step is IMO important to do, preferably for squeeze if possible. Since it's a tiny one-liner change, this should be no trouble in getting this done. I believe so too, I just didn't want to push it too much, but yes, I believe that's something that shouldn't break Squeeze at all. That's not something allowed anymore at this period of the freeze, you will have to get an exception from the release team first. Ok. I don't feel any urgency so I won't ask for it myself. Well, the big advantage to have it in squeeze is that this allows squeeze+1 to rely on it without worrying with partial upgrades. For me, the fact that d-i already provides it is a major point in favor of C.UTF-8, because this show that this actually work and is useful. I agree. I think that the impact of having a guaranteed UTF-8 locale available is only positive. It may be that nothing presently depends on it, but for that very reason it should be fine to promote to the release team for a freeze exception. Regards, Andrew McMillan. -- andrew (AT) morphoss (DOT) com+64(272)DEBIAN Pyros of the world... IGNITE !!! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#595652: db packages failing to install...
On Sun, 2010-09-05 at 18:58 -0700, Russ Allbery wrote: Holger Levsen hol...@layer-acht.org writes: please clarify what the right behaviour should be and how failing to install without a local db should be treated. Thanks. I agree with jcristau; I think it's reasonable to have database servers be in Recommends, to have postinst prompt for what database to use, and if one choses a remote database that doesn't exist or if one has no database to choose, to have the package configuration fail. I don't think that we should *require* that behaviour, though possibly we can encourage it. Multiple server setups tend to be complex and idiosyncratic, and there may be good reasons why someone is configuring the software without access to a working database, such as when preparing a hot spare, for example, which might interact with the production database in interesting ways if it were to connect. In general I think providing an opt out option which does nothing and successfully configures the package is not harmful. While automation i nice, our own imagination can be limited in understanding the full range of possibilities and we should be careful not to over-guess what the user is trying to achieve by choosing such an option. I could probably come up with a long list of reasons why immediate database connectivity might not be available while I'm installing a package. A few that spring to mind are: * I'm on a ship(/island/branch office/mountain/...) and I'm installing this half of the package now, because I'm here and have the opportunity. I'll do the database bit when I get back to the office next week. * It's 4:35am and the earthquake just wiped out one of our server rooms. I'm trying to get this software running on some equipment in another city and fortunately I *do* have a backup of the configuration files which I plan to apply after installation. * This software is generally configured to run against PostgreSQL, but our organisation insists on running it against $EXPENSIVEDB, which it also supports, but which requires some special magic in the config. And so on. It's definitely worth talking about if the draft database policy says something else, as it appears to. My rationale is that the package setup may simply require a database; some packages don't have a meaningful stand-alone installation with no database support. I think it makes more sense to fail the configure step than it does to require that the user run dpkg --reconfigure later to re-run the package setup. Heh. Shouldn't that be dpkg-reconfigure :-) I know I'd be happier to know that the software was on there, and that if necessary I could run dpkg-reconfigure to use the 'standard' configuration method, but also to know that I had a way of opting out of that, and providing some kind of manual configuration. For those situations requiring more imaginative solutions. Cheers, Andrew. -- andrew (AT) morphoss (DOT) com+64(272)DEBIAN I have not seen high-discipline processes succeed in commercial settings. - Alistair Cockburn -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#578797: davical: Creating the Database fails
caught with an (eventually localisable) error message about what might not be working, but it won't change in the short term. Regards, Andrew McMillan. -- http://andrew.mcmillan.net.nz/ Porirua, New Zealand Twitter: _karora Phone: +64(272)DEBIAN Condense soup, not books! signature.asc Description: This is a digitally signed message part
Bug#594658: debian-policy: Add FHS exception for GNU/Hurd directories
On Wed, 2010-09-01 at 17:05 -0700, Russ Allbery wrote: Andrew McMillan and...@morphoss.com writes: I would change the text around a little to add that to the beginning of the paragraph, something like: On GNU/Hurd systems the file/hurd/file and file/servers/file directories are also allowed in the root filesystem. footnoteThese directories are used to store translators and as a set of standard names for mount points respectively./footnote Ordering the words in this way means the reader can decide it's applicability much faster. Perhaps splitting the footnote into two footnotes might help also: ... file/hurd/filefootnoteUsed to store translators./footnote and file/servers/filefootnoteUsed as a set of standard names for mount points./footnote ... Our footnote system is not great, so I'd keep it as one footnote. I agree with putting GNU/Hurd first, but I'd like to keep the structure of listing the exceptions after a colon to match the other item. So, how about: On GNU/Hurd systems, the following additional directories are allowed in the root filesystem: file/hurd/file and file/servers/file. footnote These directories are used to store translators and as a set of standard names for mount points, respectively. /footnote All good reasons so let's go with that one then. Cheers, Andrew. -- andrew (AT) morphoss (DOT) com+64(272)DEBIAN Water, taken in moderation cannot hurt anybody. -- Mark Twain signature.asc Description: This is a digitally signed message part
Bug#578797: davical: Creating the Database fails
severity 578797 wishlist tag 579797 +wontfix retitle 578797 DAViCal: UTF-8 capable PostgreSQL setup required for database creation thanks On Thu, 2010-08-26 at 08:43 +0200, Frank Hartmann wrote: Hi, I found a workaround/solution: postgres stores some information at install time about the locale: postgresql.conf:lc_messages = 'en_US.UTF-8' # locale for sys postgresql.conf:lc_monetary = 'en_US.UTF-8' # locale for mon postgresql.conf:lc_numeric = 'en_US.UTF-8' # locale for num postgresql.conf:lc_time = 'en_US.UTF-8' # locale for tim previously that was set to de_DE which is apparently not working in combination with davical. DAViCal creates the database with a UTF-8 encoding and PostgreSQL does not allow UTF-8 encodings to be created if the database was originally initialised with an incompatible encoding such as ISO-8859-15 etc. There's not really any way around this. I don't believe that the PostgreSQL folk will fix the issue - there are excellent performance reasons behind their decision. CalDAV specifies UTF-8 as the One True Encoding and so naturally DAViCal wants to store in a database that is capable of that. Possibly I could add a check during the installation, but it would say little more than the PostgreSQL error message did, and it would most likely say it in English, which would be a poor option indeed. Regards, Andrew. -- andrew (AT) morphoss (DOT) com+64(272)DEBIAN You tread upon my patience. -- William Shakespeare, Henry IV signature.asc Description: This is a digitally signed message part
Bug#594542: debian-policy: add descriptions for main, contrib, and non-free archive areas
On Mon, 2010-08-30 at 12:05 -0400, CJ Fearnley wrote: On Fri, Aug 27, 2010 at 10:38:14AM -0700, Russ Allbery wrote: CJ Fearnley c...@cjfearnley.com writes: 2.2.1 The main archive area The main archive area comprises the Debian GNU/Linux distribution; only the packages in this area are considered part of the distribution. None of the packages in the main archive area require software outside of that area to function. OK, how about this suggestion for a conclusion to Russ' text on the main archive area: Everyone (from end users to redistributors to derivatives) can be confident that they can use, share, modify and redistribute the software in the Debian main archive area freelyfootnoteSee http://www.debian.org/intro/free for more about what we mean by free software./footnote. It sounds a little My little pony-ish to me, but it's harmless enough. I think including a definition of 'Everyone in brackets potentially reduces the meaning of the word rather than enhances it. In some future time will someone say I'm not an end user, redistributor or derivative (deriver?) of Debian: am I part of 'Everyone'?. I'd prefer even more succinct brevity, along the lines of: Anyone may use, share, modify and redistribute the packages in the 'main' archive area freelyfootnoteSee http://www.debian.org/intro/free for more about what we mean by free software./footnote. software - packages, since not everything in 'main' is software. main - 'main' to make it clearer that it is a proper noun as capitalising it would not work. Other minor wording changes because it felt better to me that way, but I'm not wedded to them. Cheers, Andrew. and then going on to the language already there, which already requires that all the packages comply with the DFSG. 2.2.2 The contrib archive area The contrib archive area contains supplemental packages intended to work with the Debian GNU/Linux distribution, but which require software outside of the distribution to either build or function. Apart from this requirement, all software in the contrib archive area complies with the DFSG and with the policy requirements in this manual. 2.2.3 The non-free archive area The non-free archive area contains supplemental packages intended to work with the Debian GNU/Linux distribution that do not comply with the DFSG or have other problems that make their distribution problematic. They may not comply with all of the policy requirements in this manual due to restrictions on modifications or other limitations. I don't think any of the above changes anything normative, so once we reach consensus on the wording I can go ahead and apply this. -- We are on a spaceship; a beautiful one. It took billions of years to develop. We're not going to get another. Now, how do we make this spaceship work? -- Buckminster Fuller CJ Fearnley| Explorer in Universe c...@cjfearnley.com | Dare to be Naive -- Bucky Fuller http://www.CJFearnley.com | http://blog.remoteresponder.net/ -- andrew (AT) morphoss (DOT) com+64(272)DEBIAN Never be led astray onto the path of virtue. signature.asc Description: This is a digitally signed message part
Bug#593909: debian-policy: Clarifications about the syntax of Debian control files.
On Sun, 2010-08-29 at 04:17 -0700, PJ Weisberg wrote: On Sat, Aug 28, 2010 at 1:34 PM, Russ Allbery r...@debian.org wrote: Charles Plessy ple...@debian.org writes: Le Fri, Aug 27, 2010 at 10:24:57AM -0700, Russ Allbery a écrit : In fields where the value may not span multiple lines, the amount of whitespace in the field body is not significant. Any amount of whitespace is equivalent to a single space. Whitespace must not appear inside names (of packages, architectures, files, or anything else) or version numbers, or between the characters of multi-character version relationships. I still have difficulties to understand the meaning of this paragraph, and to what fields it applies. Is it just specifiying that the parser, in the case of fields that allow continuation lines, can be either instructed to replace all white spaces and newlines by single spaces, or to leave the value as it is, including the new lines? No, it's really trying to say that the amount of whitespace isn't significant. I'm not sure how else to explain it. That's one of those precise terms of art for which there isn't really an acceptable synonym, at least not that I can think of. Replacing all whitespace with a single space is one of the things that you can do *because* the amount of whitespace is not significant, but it's not an equivalent statement. It might be more *precise* to say that the field contains a series of whitespace-delimited tokens, but I don't know if that would be more *understandable*. Given the target audience (i.e. the ornery DD :-) it seems likely to me that they would then want to know if those tokens can be quoted strings. The above text seems to me to remove the possibility of that question :-) Sure it's maybe a little wordy, but it's explicit also,and not too unreadable. Cheers, Andrew. -- http://andrew.mcmillan.net.nz/ Porirua, New Zealand Twitter: _karora Phone: +64(272)DEBIAN Time to be aggressive. Go after a tattooed Virgo. signature.asc Description: This is a digitally signed message part
Bug#594542: debian-policy: add descriptions for main, contrib, and non-free archive areas
On Sat, 2010-08-28 at 07:35 -0400, CJ Fearnley wrote: I don't think CJ is advocating changing the DFSG, but rather is concerned that the way the DFSG is worded may not make it clear to people what the motivation is and what the implications are for users. In other words, a rephrasing or preamble, not any sort of normative modification, that says this means you can use the software for absolutely anything you want. I can see that point, although I'm not sure that it makes that much difference for Policy, since Policy is largely aimed at people who are reasonably familiar with Debian and are looking for technical guidance. I would tend to point people at http://www.debian.org/intro/free or some similar sort of place to explain the motivation and background for what Debian means by free. Russ' interpretation of my thinking is correct. I certainly don't want to change the DFSG. I'm thinking about a customer who is afraid of using Debian for some business purpose, for example. Their lawyers have spread fear and uncertainty: beware, the BSA[1] may come after you. They read the DFSG and they learn what we mean by freedom, but they still might not connect the dots to realize that Debian main is doing its best to effectively guarantee ... the four freedoms ... the best protection against BSA interference that a mere document can provide ... what we all know is our protected freedom. But I think we haven't said it directly enough. http://www.debian.org/intro/free is good for a footnote, but it also doesn't succinctly say that Debian main tries to ensure that it can be freely usable and redistributable (with the requisite freedom protections for your users too) by anyone for any purpose. Phew :-) I still think I side with Russ that Policy is for people who already understand this stuff, and we should have separate documents that provide the overview level. I also think that proper clarification on these points will ideally need a multi-lingual and multi-cultural dimension to capture the exact shades of meaning needed. Regards, Andrew. -- andrew (AT) morphoss (DOT) com+64(272)DEBIAN You've been leading a dog's life. Stay off the furniture. signature.asc Description: This is a digitally signed message part
Bug#594658: debian-policy: Add FHS exception for GNU/Hurd directories
On Sat, 2010-08-28 at 09:08 +0200, Guillem Jover wrote: Source: debian-policy Source-Version: 3.9.1.0 Severity: wishlist Tags: patch X-Debbugs-CC: debian-h...@lists.debian.org Hi! Here's a draft patch to add an FHS exception for the two top-level directories GNU/Hurd uses. Hi Guillem, I would change the text around a little to add that to the beginning of the paragraph, something like: On GNU/Hurd systems the file/hurd/file and file/servers/file directories are also allowed in the root filesystem. footnoteThese directories are used to store translators and as a set of standard names for mount points respectively./footnote Ordering the words in this way means the reader can decide it's applicability much faster. Perhaps splitting the footnote into two footnotes might help also: ... file/hurd/filefootnoteUsed to store translators./footnote and file/servers/filefootnoteUsed as a set of standard names for mount points./footnote ... It might make sense to merge with the /sys and /selinux paragraph, and the footnote might need to be clarified probably. It might, although I think starting the paragraph with On GNU/Hurd ... might make it clearer when it stands on it's own. Regards, Andrew McMillan. -- andrew (AT) morphoss (DOT) com+64(272)DEBIAN The difference between a crazy person and an intelligent one is that the crazy one doesn't realize what makes sense in the world. -- Linus Torvalds signature.asc Description: This is a digitally signed message part
Bug#106073: recommend to install package documentation into /usr/share/doc/package/
On Fri, 2010-08-27 at 10:16 -0700, Russ Allbery wrote: Andrew McMillan and...@morphoss.com writes: My personal preference would be to encourage -doc packages to install their files into /usr/share/doc/package/docs - including their internal administrivia. That would break Lintian, apt-listchanges, probably the DAK processing scripts, and anything else that looks at copyright and changelog in binary packages. I don't think it's worth it to make that change. While this is not current practice, I'm not convinced that current practice has evolved into what was suggested in 2003 either. Right now, I'm seeing a real mix of behavior, with some packages installing all the documentation into the -doc package's /usr/share/doc (probably in part because that's easier) and others installing it into the parent package, some with symlinks and some without. As a result, right now one cannot easily find the documentation in any standardized place. I also remember as a user hunting for these documents the first time or two when I had installed the -doc package and it slowly dawning on me that they weren't anywhere in /usr/share/doc/package, and I think that breaks the principal of least surprise, for everyone except long-time, hard-core Debianista. Yeah, that's what Ben's writeup would fix, and I agree that's worth fixing. Those points are justifications for both proposals, of course, and I guess that one reason for retaining the administrivia in /usr/share/doc/package-doc might be that there are tools that expect to find it there. Is that the case? Yup. I don't think I ever do more than refer to them by hand, and either proposed change can probably be codified in some small number of scripts. I don't think the change proposed here requires changing any scripts, although it will require changing a bunch of packages (and a change to debhelper to make it easier to install docs into the right place would be useful). In that case I support changing it the way Ben proposes. I can certainly see the value of standardising it, and doing it this way definitely improves the situation. Cheers, Andrew. -- andrew (AT) morphoss (DOT) com+64(272)DEBIAN I'll burn my books. -- Christopher Marlowe signature.asc Description: This is a digitally signed message part
Bug#594542: debian-policy: add descriptions for main, contrib, and non-free archive areas
On Fri, 2010-08-27 at 18:06 -0400, CJ Fearnley wrote: On Fri, Aug 27, 2010 at 12:17:16PM -0700, Russ Allbery wrote: CJ Fearnley c...@cjfearnley.com writes: However, I do wish that we could figure out how to write a minefield-avoiding third sentence for your paragraph on the main archive area that definitively asserts (what I believe we all know to be true) that Debian main is more or less a guarantee that the software therein is freely usable (and distributable) in the broadest sense. That is, that Debian main is unreservedly usable for personal, non-profit, for-profit, or, in short, for any purpose. But I'm blanking on text that would work. Isn't that basically what the DFSG says, though? At least, that was the logic that I was using. The DFSG defines freedom in software licenses, but doesn't provide a statement of assurance to users. Maybe a statement that Debian main supports the Four Freedoms[1][2] would turn the prescriptive DFSG into a qualitative benefits statement. Hi, I think that you're treading on thin ground pushing for that. The DFSG is a defining document in Debian, so if you want to narrow or broaden that coverage you should be doing so by promoting changes to that document - not to policy. Personally I'm happy with the freedoms described by the DFSG as it stands at present, but if you believe it is flawed you should argue those flaws in the wider arena of Debian via a GR or such. The clarifications Russ suggested definitely do seem worth including, and I would say it is especially because they refer out to that defining document that gives them their strength in policy. If they were to place additional constraints on what software was acceptable in main it would make policy more confusing, not less, and would undermine the DFSG as a decision-making tool. Regards, Andrew McMillan. -- andrew (AT) morphoss (DOT) com+64(272)DEBIAN A tall, dark stranger will have more fun than you. signature.asc Description: This is a digitally signed message part
Bug#593909: debian-policy: Clarifications about the syntax of Debian control files.
On Thu, 2010-08-26 at 10:05 +0900, Charles Plessy wrote: Le Sun, Aug 22, 2010 at 03:23:26PM +0900, Charles Plessy a écrit : I have been reading §5.1 (Syntax of control files) many times recently, and would like propose clarifications about a couple of points. If consensus emerges, I will write a patch. Non-wrappable field values Ordering of the paragraphs Line escape and paragraph separators Hi again, to this list I would like to add comment lines. Currently they are described in §5.2 (5.2 Source package control files -- debian/control), as an additional syntax, which strongly suggests that they are allowed in this file only. Independantly of whether this is confirmed or not, this syntactic information would rather belong to §5.1, that defines the syntax of the control files, instead of §5.2, which like the next chapters §5.3–6 lists the fields allowed in the different Debian control files. I would therefore propose to have in §5.1: Lines starting with # without any preceding whitespace are ‘comments lines’ and are ignored, even in the middle of continuation lines for a multiline field. They do not end a multiline field. If comment lines are only allowed in source package control files, we could add: The use of such comments must be allowed on a per-file basis. And then in §5.2: Comment lines are allowed. The benefit of this is that it concentrates in §5.1 all the instructions to write a basic parser for Debian control files. This seems sensible, and I think all of the clarifications you plan are in the same light, and I would certainly support a patch expressing this all more clearly. Cheers, Andrew. -- andrew (AT) morphoss (DOT) com+64(272)DEBIAN I have not seen high-discipline processes succeed in commercial settings. - Alistair Cockburn signature.asc Description: This is a digitally signed message part
Bug#594274: debian-policy: Don't track generated README documents in VCS
On Wed, 2010-08-25 at 14:28 +1000, Ben Finney wrote: On 25-Aug-2010, Ben Finney wrote: However, the VCS repository also contains the rendered documents themselves. Those should not be tracked in VCS; instead, they should be generated from source as needed. I couldn't find a way to tell Git “these files are removed from the repository, propagate that fact to other repositories”. (Git doesn't seem to track file removal as such, making me wonder if it's even possible to do this in a robust way with Git.) So attached is a Bazaar diff output, that hopefully contains enough information for someone more knowledgeable about Git to do the right thing. git rm directory/file.name git commit Of course if you've already removed the files it is less obvious. :-) Andrew. -- andrew (AT) morphoss (DOT) com+64(272)DEBIAN You will be traveling and coming into a fortune. signature.asc Description: This is a digitally signed message part
Bug#106073: recommend to install package documentation into /usr/share/doc/package/
On Wed, 2010-08-25 at 14:55 +1000, Ben Finney wrote: On 27-Sep-2003, Josip Rodin wrote: Some proposed mandating that -doc package contents is placed into /usr/share/doc/package/, and that the administrivia such as copyright and changelog stays in /usr/share/doc/package-doc/. This sounds good to me because it has a sort of an internal logic, the -doc suffix only exists because of packaging, it's actually the docs for package. Plus, it's shorter, less to type. There seems to be consensus on doing this, so I've made a patch (attached to this message) which implements that recommendation. Hi Ben, Thanks for the patch, but since that was from 2003 I wonder if it deserves a little more discussion now, before we apply it. My personal preference would be to encourage -doc packages to install their files into /usr/share/doc/package/docs - including their internal administrivia. While this is not current practice, I'm not convinced that current practice has evolved into what was suggested in 2003 either. While both proposals would move the package-doc content to under /usr/share/doc/package, I would prefer to see a reduction in the number of directories under /usr/share/doc - admittedly on my own system this would only be around 1% reduction. I also remember as a user hunting for these documents the first time or two when I had installed the -doc package and it slowly dawning on me that they weren't anywhere in /usr/share/doc/package, and I think that breaks the principal of least surprise, for everyone except long-time, hard-core Debianista. I think it particularly confuses people when the -doc package first splits out of the original package, since the docs get moved away at that point. Those points are justifications for both proposals, of course, and I guess that one reason for retaining the administrivia in /usr/share/doc/package-doc might be that there are tools that expect to find it there. Is that the case? I don't think I ever do more than refer to them by hand, and either proposed change can probably be codified in some small number of scripts. Cheers, Andrew McMillan. -- andrew (AT) morphoss (DOT) com+64(272)DEBIAN Change your thoughts and you change your world. signature.asc Description: This is a digitally signed message part
Bug#593533: debian-policy: Proposal to stop requesting to list initial Debian maintainers in debian/copyright
On Wed, 2010-08-18 at 19:10 -0700, Russ Allbery wrote: Charles Plessy ple...@debian.org writes: Information about the initial Debian maintainers partially overlaps the information in debian/changelog, and the copyright statements for the packaging work. Under normal circumstances, it always duplicates information in debian/changelog (there are some edge cases where it doesn't, but I think they're rare). diff --git a/policy.sgml b/policy.sgml index 9037de8..e924b5a 100644 --- a/policy.sgml +++ b/policy.sgml @@ -9554,9 +9554,8 @@ END-INFO-DIR-ENTRY p In addition, the copyright file must say where the upstream - sources (if any) were obtained. It should name the original - authors of the package and the Debian maintainer(s) who were - involved with its creation. + sources (if any) were obtained, and should name the original + authors. /p p Seconded. Seconded. While I understand Cate's point about recognition of Debian Developers, this is about removing the policy requirement that they be acknowledged in this way and leaving them the choice to be acknowledged. It seems to me that making the decision to be a decision of the maintainer is perfectly correct. Cheers, Andrew. -- andrew (AT) morphoss (DOT) com+64(272)DEBIAN Let me put it this way: today is going to be a learning experience. signature.asc Description: This is a digitally signed message part
Bug#593611: Acknowledgement (debian-policy: Clarify whose signature should go in debian/changelog (4.4))
On Thu, 2010-08-19 at 12:31 -0400, Felipe Sateler wrote: Argh, I misused reportbug, apparently. Here is the actual report: Policy 4.4 currently says: The maintainer name and email address used in the changelog should be the details of the person uploading this version. They are not necessarily those of the usual package maintainer. One person I'm sponsoring misread this and put my name in the changelog, since I'm the one actually doing the upload. I can't think of a better wording, though. Perhaps a footnote is enough? Hi Felipe, I would say that as the person sponsoring and signing the upload you are the person who is responsible for it, and the changelog should show your name. Perhaps the person who did the bulk of the work before you reviewed the package and uploaded it should put their name as a line in the changelog saying something like: * Packaging by Joe Cool j...@example.cool for sponsored upload. Regards, Andrew McMillan. -- andrew (AT) morphoss (DOT) com+64(272)DEBIAN What I tell you three times is true. -- Lewis Carroll signature.asc Description: This is a digitally signed message part
Bug#436105: suggestion to add GPL-1 as a common licence
On Mon, 2010-06-28 at 10:58 -0700, Russ Allbery wrote: Andrew McMillan and...@morphoss.com writes: On Fri, 2010-06-11 at 11:35 +0200, Santiago Vila wrote: Ok, I agree that it would a good idea to include GPL-1 in common-licenses because of the high number of packages still using it. I'm sorry, but I disagree, for the time being. I do not believe that large numbers of packages are deliberately using GPL v1, and I think that anyone who is needs to confirm that explicitly since (I hope) many of them have moved on to less broken licenses such as GPL3 or GPL2. Hi Andrew, Did the subsequent discussion resolve your concerns about including the GPL v1 in common-licenses? I do think there are a lot of packages that are explicitly distributed under GPL v1 or later due to the Perl licensing situation. I guess this is the status quo, so we should continue with it. The weight of opinion seems against me :-) Cheers, Andrew. -- andrew (AT) morphoss (DOT) com+64(272)DEBIAN Does the turtle move for you? www.kame.net signature.asc Description: This is a digitally signed message part
Bug#575639: Bug#567489: Clarify that Changed-By must have name and email address
On Sun, 2010-06-13 at 19:00 -0700, Russ Allbery wrote: Helps if I send this to the correct bug. Russ Allbery r...@debian.org writes: * maintainer-name-missing and uploader-name-missing are both automatic rejects in the ftp-master checks, which makes them automatically severity: serious in Lintian. That's not the specific one that you're asking about, but that's the rule that Changed-By references. * The Policy description for Changed-By says The name and email address of the person who changed the said package. That's not a should. That's a statement of what that field shall include, which means that if it doesn't have the name and e-mail address, it's a syntax error and therefore is a violation of an implicit must. I see where your reading is coming from, but suspect the best fix is to just change the Policy wording to make it clear that this is a must. There's really no reason to use a different format, and Debian elsewhere already requires names. Here's a proposed patch that cleans up the wording of Maintainer, Uploaders, and Changed-By to reflect current practice. There is another outstanding bug in this area to document further restrictions on Maintainer and Uploaders, but this is the easy part so I wanted to resolve this first. The following patch tightens the syntax of Maintainer to a must, tightens the use of comma as a separator in Uploaders to a must, permits people to use multi-line Uploaders fields (we were waiting for the lenny release), and is explicit that the syntax of Changed-By is the same as Maintainer and is a bit clearer about what goes into that field. Objections or seconds? diff --git a/policy.sgml b/policy.sgml index df6ae89..5a76cf3 100644 --- a/policy.sgml +++ b/policy.sgml @@ -2672,7 +2672,7 @@ Package: libc6 p The package maintainer's name and email address. The name - should come first, then the email address inside angle + must come first, then the email address inside angle brackets ttlt;gt/tt (in RFC822 format). Missing semicolon: brackets ttlt;gt;/tt (in RFC822 format). /p @@ -2690,17 +2690,16 @@ Package: libc6 sect1 id=f-Uploaders headingttUploaders/tt/heading - p -List of the names and email addresses of co-maintainers of -the package, if any. If the package has other maintainers -beside the one named in the -qref id=f-MaintainerMaintainer field/qref, their -names and email addresses should be listed here. The -format is the same as that of the Maintainer tag, and -multiple entries should be comma separated. Currently, -this field is restricted to a single line of data. This -is an optional field. - /p + p + List of the names and email addresses of co-maintainers of + the package, if any. If the package has other maintainers + beside the one named in the + qref id=f-MaintainerMaintainer field/qref, their names + and email addresses should be listed here. The format is the + same as that of the Maintainer tag, and multiple entries must + be comma separated. This is an optional field. + /p + p Any parser that interprets the Uploaders field in filedebian/control/file must permit it to span multiple @@ -2714,9 +2713,10 @@ Package: libc6 headingttChanged-By/tt/heading p - The name and email address of the person who changed the - said package. Usually the name of the maintainer. - All the rules for the Maintainer field apply here, too. + The name and email address of the person who prepared this + version of the package, usually a maintainer. The syntax is + the same as for the qref id=f-MaintainerMaintainer + field/qref. /p /sect1 Seconded. Presuming you've fixed the missing semicolon that Sean spotted :-) Cheers, Andrew. -- andrew (AT) morphoss (DOT) com+64(272)DEBIAN You are taking yourself far too seriously. signature.asc Description: This is a digitally signed message part
Bug#347581: debian-policy: Explicitly permit *-headers binary package created from library source package
On Sat, 2010-06-12 at 13:01 -0700, Russ Allbery wrote: For background here, this bug is about permitting the splitting of the architecture-independent headers for a library into a separate -headers package rather than requiring (which the current Policy wording implies) that they be in the usually architecture-dependent -dev package. Kevin B. McCarty kmcca...@princeton.edu writes: Chris Waters wrote: I would rather see that last sentence modified slightly to allow a little more flexibility. Perhaps changing placed in to placed in or installed by. Or something along those lines. Hmm, how about this? (I can't quite see how to keep it to a single sentence of reasonable length.) If there are development files associated to a shared library, the source package needs to generate a binary development package called librarynamesoversion-dev, or if you prefer only to support one development version at a time, libraryname-dev. Installing the development package must result in installation of all the development files. This change would leave the door open for development files to be split up into separate packages as needed, as long as libwhatever-dev depends upon all of them, either directly or indirectly. This looks good to me. Here's proposed wording. Objections or seconds? diff --git a/policy.sgml b/policy.sgml index 720150d..1e134bb 100644 --- a/policy.sgml +++ b/policy.sgml @@ -5163,11 +5163,20 @@ Replaces: mail-transport-agent headingDevelopment files/heading p - The development files associated to a shared library need to be - placed in a package called - packagevarlibraryname/varvarsoversion/var-dev/package, + If there are development files associated with a shared library, + the source package needs to generate a binary development package + named packagevarlibraryname/varvarsoversion/var-dev/package, or if you prefer only to support one development version at a - time, packagevarlibraryname/var-dev/package. + time, packagevarlibraryname/var-dev/package. Installing + the development package must result in installation of all the + development files necessary for compiling programs against that + shared library.footnote + This wording allows the development files to be split into + several packages, such as a separate architecture-independent + packagevarlibraryname/var-headers/package, provided that + the development package depends on all the required additional + packages. + /footnote /p p Seconded. Cheers, Andrew. -- andrew (AT) morphoss (DOT) com+64(272)DEBIAN Does the turtle move for you? www.kame.net signature.asc Description: This is a digitally signed message part
Bug#104373: Subdirectory under /usr/lib/cgi-lib should be explicitly allowed
On Sat, 2010-06-12 at 12:35 -0700, Russ Allbery wrote: Rémi Perrot remi.per...@torrep.org writes: In section 12.5 of the policy it like that it is not possible to put cgi script in /usr/lib/cgi-lib/package-name/cgi-name If this is true, we will have more and more file name conflict, and these conflict are quite hard to resolve due to link change across the application. These already many package that violate this rules. If this is false, please can we have more explanation in the policy. Despite its age, this bug is rather straightforward and is something we really should have fixed years ago. The current wording around locations of CGI programs implies that subdirectories of /usr/lib/cgi-bin may not be used, but of course this is very widely used in packages already in the archive and works with a typical web server configuration. Here is a patch that explicitly allows this. Objections or seconds? diff --git a/policy.sgml b/policy.sgml index 720150d..7dd0785 100644 --- a/policy.sgml +++ b/policy.sgml @@ -8184,11 +8184,13 @@ done example compact=compact /usr/lib/cgi-bin/varcgi-bin-name/var /example - and should be referred to as + or a subdirectory of that directory, and should be + referred to as example compact=compact http://localhost/cgi-bin/varcgi-bin-name/var /example - + (possibly with a subdirectory name + before varcgi-bin-name/var). /item item Seconded. Cheers, Andrew. -- andrew (AT) morphoss (DOT) com+64(272)DEBIAN Wrinkles should merely indicate where smiles have been. -- Mark Twain signature.asc Description: This is a digitally signed message part
Bug#555978: debian-policy: Forbid duplicate fields in control files
On Sat, 2010-06-12 at 18:18 +0900, Charles Plessy wrote: Le Fri, Jun 11, 2010 at 09:58:28AM -0700, Russ Allbery a écrit : diff --git a/policy.sgml b/policy.sgml index 87b9795..99ab0ff 100644 --- a/policy.sgml +++ b/policy.sgml @@ -2398,6 +2398,11 @@ Package: libc6 /p p + Each paragraph may contain at most one instance of a particular + field name. + /p + + p Many fields' values may span several lines; in this case each continuation line must start with a space or a tab. Any trailing spaces or tabs at the end of individual Hi Russ, as a non-native speaker, I have difficulties with the use of 'may' in your patch: if fields may be unique, they also may be not unique, so what is the message in this sentence? It does not give me the impression that the goal is to discourage the use of the same field name twice in the same paragraph. How about “A paragraph should not contain data fields having the same name.” Hi Charles, In this sense 'may' should be read as 'must', however I think that if it causes readability issues for non-native english speakers then the word 'must' should actually be used... Each paragraph must contain at most one instance of a particular field name. Is that clearer? Cheers, Andrew. -- andrew (AT) morphoss (DOT) com+64(272)DEBIAN Building more free and open source software for New Zealanders signature.asc Description: This is a digitally signed message part
Bug#436105: suggestion to add GPL-1 as a common licence
On Fri, 2010-06-11 at 11:35 +0200, Santiago Vila wrote: Ok, I agree that it would a good idea to include GPL-1 in common-licenses because of the high number of packages still using it. I'm sorry, but I disagree, for the time being. I do not believe that large numbers of packages are deliberately using GPL v1, and I think that anyone who is needs to confirm that explicitly since (I hope) many of them have moved on to less broken licenses such as GPL3 or GPL2. The blurb in debian/copyright has usually two parts. 'usually' is not sufficient. We need to explicitly know what the license is. Thus, I see no reason to use a versioned license when the license says version foo or later. Well, that's OK, perhaps, if you have confirmed that the software license of the upstream project has that text, except that *exactly* that text might be the *only* difference from the standard text. If we have a common license which is GPL-1-or-later in common licenses I would be OK with. I would not be ok with a common license of GPL-1 only, because (a) hopefully it is rare and (b) it is acknowledged to be old and broken, to some degree, and should be discouraged. Cheers, Andrew. -- andrew (AT) morphoss (DOT) com+64(272)DEBIAN Try to value useful qualities in one who loves you. signature.asc Description: This is a digitally signed message part
Bug#436105: suggestion to add GPL-1 as a common licence
On Fri, 2010-06-11 at 14:14 +0200, Giacomo A. Catenazzi wrote: Yes for new code, but old code cannot be relicensed easily: all authors should agree, but GPLv1 is very old, in periods where contribution did not have an email and fix (live-long) email address was not common. It is: (a) old code (b) not a common license Regardless of whether it may once have been. BTW unilaterally moving version 1 and any later versio to version 2 [or 3] and later later is against the GPL. Nobody is suggesting that code licensed under v1 can be moved to v2 (or later) without the authority of the author(s). So I think that GPLv1 will remain important for the time being, and I would include it in common-license. I think the project should actively rate it as 'unimportant', at least partly in order to draw attention to the fact that it is using an obsolete license. If the code is v1-or-later then a trivial fork (by the original developer) is able to relicense it as v2-or-later or v3-or-later. If the original developer is unhappy with doing that, then they do have uncommon licensing desires. Cheers, Andrew. -- andrew (AT) morphoss (DOT) com+64(272)DEBIAN Don't you feel more like you do now than you did when you came in? signature.asc Description: This is a digitally signed message part
Bug#224509: Don't require a TTY during maintainer script execution
On Thu, 2010-06-03 at 09:34 -0700, Russ Allbery wrote: The previous discussion on this bug didn't reach a final consensus on wording, but I still believe we have a consensus that this is the right general direction. Here's an updated patch that includes the permission suggested by Steve Langasek for maintainer scripts to abort for high-priority questions without a reasonable default, but with a caution against setting up that situation. I'm looking for seconds or further discussion if people don't believe that this is the right direction to go. diff --git a/policy.sgml b/policy.sgml index af00c0e..3f6b82d 100644 --- a/policy.sgml +++ b/policy.sgml @@ -3557,15 +3557,26 @@ Files: headingControlling terminal for maintainer scripts/heading p - The maintainer scripts are guaranteed to run with a - controlling terminal and can interact with the user. - Because these scripts may be executed with standard output - redirected into a pipe for logging purposes, Perl scripts - should set unbuffered output by setting tt$|=1/tt so - that the output is printed immediately rather than being - buffered. + Maintainer scripts are not guaranteed to run with a controlling + terminal and may not be able to interact with the user. They + must be able to fall back to noninteractive behavior if no + controlling terminal is available. Maintainer scripts that + prompt via a program conforming to the Debian Configuration + Management Specification (see ref id=maintscriptprompt) may + assume that program will handle falling back to noninteractive + behavior. + /p + + p + For high-priority prompts without a reasonable default answer, + maintainer scripts may abort if there is no controlling + terminal. However, this situation should be avoided if at all + possible, since it prevents automated or unattended installs. + In most cases, users will consider this to be a bug in the + package. /p /sect + sect id=exitstatus headingExit status/heading @@ -9537,9 +9548,9 @@ END-INFO-DIR-ENTRY /p p - The maintainer scripts are guaranteed to run with a - controlling terminal and can interact with the user. - See ref id=controllingterminal. + The maintainer scripts are not guaranteed to run with a + controlling terminal and may not be able to interact with + the user. See ref id=controllingterminal. /p /item Seconded. This is definitely in the right direction and I think the wording has enough of an escape clause in it, but with just the right amount of deterrent. Cheers, Andrew. -- andrew (AT) morphoss (DOT) com+64(272)DEBIAN Fine day for friends. So-so day for you. signature.asc Description: This is a digitally signed message part
Bug#530687: [PATCH] bug530687-srivasta: Support for architecture wildcards
On Thu, 2010-06-03 at 22:01 +0200, Guillem Jover wrote: Hi! On Thu, 2010-06-03 at 09:56:30 -0700, Russ Allbery wrote: Okay, here's another try at this patch that removes some extraneous information that it sounds like we shouldn't get into, from this message and your other message, and tries to simplify the wording to address the issue raised in the message whose URL is given above. Thanks! diff --git a/policy.sgml b/policy.sgml index af00c0e..36c7a1f 100644 --- a/policy.sgml +++ b/policy.sgml @@ -2735,41 +2735,62 @@ Package: libc6 ttArchitecture/tt field can include the following sets of values: list - itemA unique single word identifying a Debian machine - architecture as described in ref id=arch-spec. - itemttall/tt, which indicates an - architecture-independent package. - itemttany/tt, which indicates a package available - for building on any architecture. - itemttsource/tt, which indicates a source package. + item + A unique single word identifying a Debian machine + architecture as described in ref id=arch-spec. + /item + item + An architecture wildcard identifying a set of Debian + machine architectures, see ref id=arch-wildcard-spec. + ttany/tt matches all Debian machine architectures + and is the most frequently used. + /item + item + ttall/tt, which indicates an + architecture-independent package. + /item + item + ttsource/tt, which indicates a source package. + /item /list /p p In the main filedebian/control/file file in the source - package, this field may contain the special value - ttany/tt, the special value ttall/tt, or a list of - architectures separated by spaces. If ttany/tt or - ttall/tt appear, they must be the entire contents of the - field. Most packages will use either ttany/tt or - ttall/tt. Specifying a specific list of architectures is - for the minority of cases where a program is not portable or - is not useful on some architectures, and where possible the - program should be made portable instead. + package, this field may contain the special value ttall/tt + or a list of specific and wildcard architectures separated by + spaces. If ttall/tt appears, that value must be the + entire contents of the field. Most packages will use “any” must also only appear by itself (that got lost from the previous text). + either ttany/tt or ttall/tt. + /p + + p + Specifying a specific list of architectures indicates that the + source will build an architecture-dependent package only on + architectures included in the list. Specifying a list of + architecture wildcards indicates that the source will build an + architecture-dependent package on only those architectures + that match any of the specified architecture wildcards. + Specifying a list of architectures or architecture wildcards + other than ttany/tt is for the minority of cases where a + program is not portable or is not useful on some + architectures. Where possible, the program should be made + portable instead. /p p In the source package control file file.dsc/file, this - field may contain either the special value ttany/tt or a - list of architectures separated by spaces. If a list is given, - it may include (or consist solely of) the special value - ttall/tt. In other words, in file.dsc/file files - unlike the filedebian/control/file, ttall/tt may occur - in combination with specific architectures. The - ttArchitecture/tt field in the source package control file - file.dsc/file is generally constructed from the - ttArchitecture/tt fields in the - filedebian/control/file in the source package. + field may contain either the architecture + wildcard ttany/tt or a list of architectures and + architecture wildcards separated by spaces. If a list is + given, it may include (or consist solely of) the special + value ttall/tt. In other words, in file.dsc/file + files unlike the filedebian/control/file, ttall/tt may + occur in combination with specific architectures. + The ttArchitecture/tt field in the source package control + file file.dsc/file is generally constructed from + the ttArchitecture/tt fields in + the filedebian/control/file in the source package. /p p @@ -2789,23
Bug#569174: [PATCH] Correction of RFC number for date format -- bug #569174.
On Thu, 2010-06-03 at 18:31 -0700, Russ Allbery wrote: Charles Plessy ple...@debian.org writes: I also like the idea, so I prepared a patch (attached) Thank you! RFC 822 dates use only two digits for the years, but Debian changelogs described by this paragraph (§4.4 in Policy 3.8.4) use four digits. This patch replaces the reference to the RFC 822 by a specification that is compatible with its successors, RFC 2822 and RFC 5322, but does not use their full range of options. --- policy.sgml | 26 ++ 1 files changed, 22 insertions(+), 4 deletions(-) diff --git a/policy.sgml b/policy.sgml index af00c0e..5ba1980 100644 --- a/policy.sgml +++ b/policy.sgml @@ -1618,11 +1618,29 @@ /p p - The vardate/var must be in RFC822 formatfootnote + The vardate/var has the following formatfootnote This is generated by ttdate -R/tt. - /footnote; it must include the time zone specified - numerically, with the time zone name or abbreviation - optionally present as a comment in parentheses. + /footnote (compatible and with the same semantics of + RFC 2822 and RFC 5322): + exampleday-of-week, dd month hh:mm:ss +/example + where: + list compact=compact + itemday-of week is one of: Mon, Tue, Wed, Thu, Fri, Sat, Sun/item + itemdd is a one- or two-digit day of the month (01-31)/item + itemmonth is one of: Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec/item + item is the four-digit year (e.g. 2010)/item + itemhh is the two-digit hour (00-23/item + itemmm is the two-digit minutes (00-59)/item + itemss is the two-digit seconds (00-60)/item + item + + or - is the the time zone offset from Coordinated Universal + Time (UTC). + indicates that the time is ahead of (i.e., east of) UTC + and - indicates that the time is behind (i.e., west of) UTC. The + first two digits indicate the hour difference from UTC and the last + two digits indicate the number of additional minutes difference from + UTC. The last two digits must be in the range 00-59. + /item + /list /p p Seconded. Seconded. Cheers, Andrew. -- andrew (AT) morphoss (DOT) com+64(272)DEBIAN You're being followed. Cut out the hanky-panky for a few days. signature.asc Description: This is a digitally signed message part
Bug#569174: [PATCH] Correction of RFC number for date format -- bug #569174.
On Wed, 2010-06-02 at 14:59 +0200, Bill Allombert wrote: On Tue, Jun 01, 2010 at 10:47:18AM +0900, Charles Plessy wrote: RFC 822 dates use only two digits for the years, but Debian changelogs described by this paragraph (§4.4 in Policy 3.8.4) use four digits. This patch replaces the RFC 822 by its latest evolution, RFC 5322, that specifies a date format suitable for Debian changelogs. --- policy.sgml |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/policy.sgml b/policy.sgml index d16df70..7e2365e 100644 --- a/policy.sgml +++ b/policy.sgml @@ -1610,7 +1610,7 @@ /p p - The vardate/var must be in RFC822 formatfootnote + The vardate/var must be in RFC5322 formatfootnote This is generated by ttdate -R/tt. /footnote; it must include the time zone specified numerically, with the time zone name or abbreviation -- 1.6.5.7 What is the diffrence between RFC5322 and RFC2822 time format ? RFC 5322 was only released in 2008, so the standard that packages actually follow is clearly RFC2822. I would prefer if we keep a reference to RFC2822 because is is more well known than RFC5322 The 'date' utility denotes this format under 'RFC 2822': The option is named --rfc-2822 and the documentation list RFC 2822. I disagree: We should migrate our documentation to use the newest version of such standards when the standards body concerned updates them. In this case RFC2822 is superseded by RFC5322, and so we should reference the newer version. The new standard has been out for two years, and we haven't done it already!? This makes it a bug for things to be incompatible with the newer standard, which overall makes the adoption of the newer standard easier. I'd be surprised if it actually has an effect on Debian in this case, which is even more of a reason to use the newer standard. Moving everyone to the new standard is often difficult (how many times do we still hear of RFC822 being referred to?) and we should help grease the wheels as much as possible. Filing a bug against coreutils for the date option naming is probably a good idea too - it is hopefully trivial for them to allow the option to also be referenced as --rfc-5322. They appear to have made this change in the past, because the --rfc-822 option also works, though it is undocumented. Cheers, Andrew. -- andrew (AT) morphoss (DOT) com+64(272)DEBIAN Be cautious in your daily affairs. signature.asc Description: This is a digitally signed message part
Bug#580862: xmms2-client-nycli: Please include patch to extend command-line length
Package: xmms2-client-nycli Version: 0.7DrNo-6 Severity: normal The following patch from the XMMS tree extends the line length for the nycli from it's 80 character limit to 2048 or longer. http://git.xmms.se/?p=xmms2-devel.git;a=commitdiff;h=1684a99b911399fbf3c11ac7f8314bcbdd05c1ad This is mostly an issue for people who pipe the output of nycli into something else, although for those of us who do that it is a right pain :-) Thanks, Andrew McMillan. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (600, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.28-hoppy (PREEMPT) Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_NZ.UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages xmms2-client-nycli depends on: ii libc6 2.10.2-6 Embedded GNU C Library: Shared lib ii libglib2.0-0 2.24.1-1 The GLib library of C routines ii libreadline6 6.1-2 GNU readline and history libraries ii libxmmsclient60.7DrNo-6 XMMS2 - client library xmms2-client-nycli recommends no packages. Versions of packages xmms2-client-nycli suggests: ii xmms2-core0.7DrNo-6 XMMS2 - core package -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561288: davical: PAM auth: full name extraction is too generous
On Tue, 2009-12-15 at 23:27 +0100, gregor herrmann wrote:
Package: davical
Version: 0.9.7.6-0
Severity: minor
Hi Andrew,
when adding a user from the pam db the full name gets extracted in
drivers_squid_pam.php with:
$fullname = trim( exec(getent passwd | grep ^ . $username . | cut -d \:\
-f5), ' ,' );
When the fields in /etc/password contain a phone number this leads to
a nice full name like:
gre...@colleen:~$ getent passwd | grep ^gregoa | cut -d: -f5
gregor herrmann,,,+43 123 4567890
which is probaly not intended :)
Indeed :-)
Sorry for the missing patch cheers,
No problem.
I was considering something like this:
diff --git a/inc/drivers_squid_pam.php b/inc/drivers_squid_pam.php
index a4a0de7..d2cd862 100644
--- a/inc/drivers_squid_pam.php
+++ b/inc/drivers_squid_pam.php
@@ -67,7 +67,8 @@ function SQUID_PAM_check($username, $password ){
}
else {
dbg_error_log( PAM, user %s doesn't exist in local DB, we need to
create it,$usernam
- $fullname = trim( exec(getent passwd | grep ^ . $username . | cut -d
\:\ -f5), ' ,
+ $fullname = exec('getent passwd '.$username.'' );
+ $fullname = preg_replace( '{^[^:]+:[^:]+:\d+:\d+:([^:,]+)(,[^:]*):}',
'$1', $fullname );
$usr = (object) array(
'user_no' = 0,
'username' = $username,
Can you test for me if that works for you? If it's all good then I'll
include it in 0.9.8 which should be out this week, and which fixes your
other problem too.
Cheers,
Andrew.
andrew (AT) morphoss (DOT) com+64(272)DEBIAN
You will gain money by a speculation or lottery.
signature.asc
Description: This is a digitally signed message part
Bug#552690: mknod-in-maintainer-script postinst:39
Seconded. On Thu, 2009-11-12 at 13:29 -0800, Russ Allbery wrote: Manoj Srivastava sriva...@debian.org writes: On Thu, Oct 29 2009, Simon Horman wrote: Could you suggest a policy-compliant method of creating fifos for the package? At the time that I added mknod to the maintainer script the consensus that this was the best option available. You may use mkfifo instead of mknod, since there is no policy prohibition on mkfifo (and it can't be used to make special files). Perhaps we can add a footnote to policy mentioning mkfifo where the mknod prohibition is written? Policy currently isn't explicit about named pipes unless one considers them to be device files (which they sort of are and sort of aren't). I propose the following change to clarify this. I'm looking for seconds. commit 23cf3d94a253f1142fcd97d39320419b1014448d Author: Russ Allbery r...@debian.org Date: Thu Nov 12 13:26:50 2009 -0800 Clarify policy on named pipes in packages Make explicit the requirement that packages not include named pipes in addition to device files. State that named pipes must be created in postinst and removed in prerm or postrm as appropriate. Suggest in a footnote using mkfifo rather than mknod to avoid false positives from package checkers. diff --git a/policy.sgml b/policy.sgml index 9fcb660..34a45d5 100644 --- a/policy.sgml +++ b/policy.sgml @@ -7256,8 +7256,8 @@ ln -fs ../sbin/sendmail debian/tmp/usr/bin/runq headingDevice files/heading p - Packages must not include device files in the package file - tree. + Packages must not include device files or named pipes in the + package file tree. /p p @@ -7282,6 +7282,18 @@ ln -fs ../sbin/sendmail debian/tmp/usr/bin/runq file/dev/cu*/file devices should be changed to use file/dev/ttyS*/file. /p + + p + Named pipes needed by the package must be created in + the prgnpostinst/prgn scriptfootnote + It's better to use prgnmkfifo/prgn rather + than prgnmknod/prgn to create named pipes so that + automated checks for packages incorrectly creating device + files with prgnmknod/prgn won't have false positives. + /footnote and removed in + the prgnprerm/prgn or prgnpostrm/prgn script as + appropriate. + /p /sect sect id=config-files -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ andrew (AT) morphoss (DOT) com+64(272)DEBIAN Flexibility is overrated. Constraints are liberating. signature.asc Description: This is a digitally signed message part
Bug#553698: gwibber: New upstream version
Package: gwibber Version: 1.2.0+bzr358-1 Severity: wishlist I see that gwibber 2.0 has been released. It seems a significant upgrade and it would be nice to see it in Debian. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (999, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.32-rc5-happy (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages gwibber depends on: ii libjs-jquery 1.3.3-2JavaScript library for dynamic web ii python2.5.4-2An interactive high-level object-o ii python-dbus 0.83.0-1 simple interprocess messaging syst ii python-egenix-mxdatetime 3.1.2-1date and time handling routines fo ii python-feedparser 4.1-14 Universal Feed Parser for Python ii python-gconf 2.28.0-1 Python bindings for the GConf conf ii python-glade2 2.16.0-1 GTK+ bindings: Glade support ii python-gtk2 2.16.0-1 Python bindings for the GTK+ widge ii python-imaging1.1.6-3.1 Python Imaging Library ii python-mako 0.2.5-1fast and lightweight templating fo ii python-notify 0.1.1-2+b1 Python bindings for libnotify ii python-simplejson 2.0.9-1Simple, fast, extensible JSON enco ii python-support1.0.4 automated rebuilding support for P ii python-webkit 1.1.5-1WebKit/Gtk Python bindings ii python-xdg0.17-0.1 Python library to access freedeskt gwibber recommends no packages. gwibber suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#546470: whereami: Patch used in NMU version 0.3.34-0.2
On Sun, 2009-09-13 at 13:57 +0200, Petter Reinholdtsen wrote: Package: whereami Version: 0.3.34-0.2 Severity: wishlist Tags: patch This is the patch I used in my NMU. Hi Petter, Thanks for this. You don't want to take over as maintainer, do you? I haven't used the program in years... Cheers, Andrew. andrew (AT) morphoss (DOT) com+64(272)DEBIAN You will be given a post of trust and responsibility. signature.asc Description: This is a digitally signed message part
Bug#546389: gwibber: Unnecessary dependency on python-distutils-extra
Package: gwibber Version: 1.2.0+bzr355-2 Severity: minor Gwibber seems to run just fine without python-distutils-extra installed, which from it's description seems like it should be a build dependency rather than a package dependency. It would be nice to remove this particular dependency since it pulls in all sorts of build tools which may be inappropriate on many desktop setups. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (990, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.30-1-686 (SMP w/2 CPU cores) Locale: LANG=en_NZ.UTF-8, LC_CTYPE=POSIX (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages gwibber depends on: ii libjs-jquery 1.3.3-2JavaScript library for dynamic web ii python2.5.4-2An interactive high-level object-o ii python-dbus 0.83.0-1 simple interprocess messaging syst pn python-distutils-extranone (no description available) ii python-egenix-mxdatetime 3.1.2-1date and time handling routines fo ii python-feedparser 4.1-14 Universal Feed Parser for Python ii python-gconf 2.26.1-1 Python bindings for the GConf conf ii python-glade2 2.16.0-1 GTK+ bindings: Glade support ii python-gtk2 2.16.0-1 Python bindings for the GTK+ widge ii python-imaging1.1.6-3.1 Python Imaging Library ii python-mako 0.2.5-1fast and lightweight templating fo ii python-notify 0.1.1-2+b1 Python bindings for libnotify ii python-simplejson 2.0.9-1Simple, fast, extensible JSON enco ii python-support1.0.3 automated rebuilding support for P ii python-webkit 1.1.5-1WebKit/Gtk Python bindings ii python-xdg0.15-1.1 A python library to access freedes gwibber recommends no packages. gwibber suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#543417: README.source patch system documentation requirements considered harmful
On Mon, 2009-08-24 at 15:46 -0700, Russ Allbery wrote: Chris Lamb la...@debian.org writes: If the motivation behind README.source is to highlight non-trivial packaging, then many packages can be presented that are trivial dispite using a patch system. My own conclusion is that the adoption of dpatch or quilt is so common that the skills for it may be assumed. To get things rolling, I propose that we temper: | This explanation should include specific commands and mention any | additional required Debian packages. It should not assume familiarity | with any specific Debian packaging system or patch management tools. .. with something subjective like any non-standard Debian packaging system. This would still ask maintainers to document the parts of their packages that would be unfamiliar to most developers, whilst avoiding maintainers including essays on how to invoke pbuilder and other nonsense. Whilst using a subjective like this isn't desirable, it does avoid having to enumerate specific programs that are exempt from explanation, which doesn't really smell right for the Policy. I'm increasingly inclined to agree with this, but I'd like to specifically spell out what the exceptions are. I think the important exception would be that packages that use quilt or dpatch in the default mode, applying all patches in debian/patches/series debian/patches/00list before the build and removing them on clean, aren't required to have a README.source. That should get most of the cases where this is simple boilerplate, while still preserving the requirement for uses of quilt or dpatch in a non-standard way. The implication is that people will have to know how quilt and dpatch work, but anything else has to be explained. I think anyone doing substantial Debian work has probably encountered quilt and dpatch at some point anyway and is at least vaguely familiar, so I think that preserves the original goal. I don't know if we should include CDBS's basic patch system as well. I'm inclined to agree with Lamby also. Although specifying a worthwhile list of exceptions does seem likely to become a slippery slope. Should we also be excluding packaging done through VCS branches from this requirement, for example? Regards, Andrew. http://andrew.mcmillan.net.nz/ Porirua, New Zealand Twitter: _karora Phone: +64(272)DEBIAN You have an ability to sense and know higher truth. signature.asc Description: This is a digitally signed message part
Bug#224509: Don't require a TTY during maintainer script execution
On Fri, 2009-08-07 at 19:43 -0700, Russ Allbery wrote: I think at this point, now that debconf is mandatory for all but essential packages, removing the guarantee of a controlling terminal is uncontroversial. This bug has been open for a while and I'd like to put it to bed. Here's proposed wording. I'm looking for feedback or seconds. Seconded. Cheers, Andrew. diff --git a/policy.sgml b/policy.sgml index 27deaa7..bf99884 100644 --- a/policy.sgml +++ b/policy.sgml @@ -3529,15 +3529,17 @@ Package: libc6 headingControlling terminal for maintainer scripts/heading p - The maintainer scripts are guaranteed to run with a - controlling terminal and can interact with the user. - Because these scripts may be executed with standard output - redirected into a pipe for logging purposes, Perl scripts - should set unbuffered output by setting tt$|=1/tt so - that the output is printed immediately rather than being - buffered. + Maintainer scripts are not guaranteed to run with a controlling + terminal and may not be able to interact with the user. They + must be able to fall back to noninteractive behavior if no + controlling terminal is available. Maintainer scripts that + prompt via a program conforming to the Debian Configuration + Management Specification (see ref id=maintscriptprompt) may + assume that program will handle falling back to noninteractive + behavior. /p /sect + sect id=exitstatus headingExit status/heading @@ -9397,9 +9399,9 @@ END-INFO-DIR-ENTRY /p p - The maintainer scripts are guaranteed to run with a - controlling terminal and can interact with the user. - See ref id=controllingterminal. + The maintainer scripts are not guaranteed to run with a + controlling terminal and may not be able to interact with + the user. See ref id=controllingterminal. /p /item -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ andrew (AT) morphoss (DOT) com+64(272)DEBIAN Your nature demands love and your happiness depends on it. signature.asc Description: This is a digitally signed message part
Bug#534408: debian-policy: Installed-Size is defined as kilobytes but dpkg-gencontrol fills it in with kibibytes
On Mon, 2009-07-13 at 17:20 +0100, Julien Cristau wrote: On Mon, Jun 29, 2009 at 13:29:48 +0200, Bill Allombert wrote: I formally object to the part '(in other words, the size in kibibytes)'. (I believe this change is not informative and only serve the purpose of endorsing a standard which does not meet consensus in Debian.) It seems a sufficient quantity of people object to even the merest mention of 'kibibytes' as shorthand for 'bytes divided by 1024 and rounded' that only the fully expanded wording will be acceptable. The wording without it is unambiguous: The disk space is given as the integer value of the installed size in bytes divided by 1024 and rounded. I guess that perhaps the '-ibibytes' standard will eventually die, and everything will just become multiples of 1000, as it should be. In the meantime, regardless of the success of failure of the standard, this wording is at least correct for the current behaviour. My preferred wording would be to define it in terms of kibibytes, but include the explanation, since it seems it is an unfamiliar standard, as follows: The disk space is given as the integer value of the installed size in kibibytes (i.e. bytes divided by 1024). Cheers, Andrew. andrew (AT) morphoss (DOT) com+64(272)DEBIAN You will never know hunger. signature.asc Description: This is a digitally signed message part
Bug#508673: davical can't find the include file, AWLUtilities.php
On Thu, 2009-07-02 at 17:07 +0200, Leo 'costela' Antunes wrote: Hi Andrew, Did you have a chance to think about my proposed solution for this bug? Do you see any problem with it? I'm considering upgrading the severity to minor, since it does cause more annoyances than necessary during installation... The installation process is non-trivial, and something needs to be done about it in due course. I guess I'd also be happy for someone else to take over Debian packaging of AWL DAViCal, so I can concentrate on being upstream for them :-) I don't like the fact that if libawl-php added it's directory into the PHP search path that then DAViCal would be searching the normal PHP search path, since it only depends on AWL, and not on any other libraries that wouldn't be ideal either. I'm still not sure what the best approach is. None of the suggestions against this bug so far appeal to me. I guess my preference would be that on installation DAViCal actually constructed an Apache stanza in answer to some configuration questions, and that stanza would of course set the PHP include path in the manner currently recommended by the installation instructions. I'd be happy to see a patch for the postinst etc which did something along those lines. Cheers, Andrew. andrew (AT) morphoss (DOT) com+64(272)DEBIAN You will be given a post of trust and responsibility. signature.asc Description: This is a digitally signed message part
Bug#534408: debian-policy: Installed-Size is defined as kilobytes but dpkg-gencontrol fills it in with kibibytes
On Mon, 2009-06-29 at 09:42 -0700, Russ Allbery wrote: Bill Allombert bill.allomb...@math.u-bordeaux1.fr writes: On Tue, Jun 23, 2009 at 07:49:40PM -0700, Russ Allbery wrote: Agreed. At the time Policy was originally written, kilobyte nearly universally meant kibibyte in the industry. I'll change this to: The disk space is given as the integer value of the installed size in bytes divided by 1024 and rounded (in other words, the size in kibibytes). for the next release. (I believe this is an informative change that doesn't require seconds.) I formally object to the part '(in other words, the size in kibibytes)'. (I believe this change is not informative and only serve the purpose of endorsing a standard which does not meet consensus in Debian.) Okay. As previously mentioned, I disagree and would prefer to retain it, so I think at this point we need to hear more opinions to see how widespread the disagreement is. I'm happy with kibibytes, but on the other hand I'm also happy with kilobytes if the code is changed to actually report 1,000's of bytes. Cheers, Andrew. andrew (AT) morphoss (DOT) com+64(272)DEBIAN Questionable day. Ask somebody something. signature.asc Description: This is a digitally signed message part
Bug#530687: debian-policy: Please provide policy for architecture wildcards
On Wed, 2009-05-27 at 14:33 -0400, Andres Mejia wrote: Current policy has this wording and I didn't want to change that, so yes, it's on purpose. Not quite. Current policy says arch list or 'any' or 'all' and that's fine (at least for debian/control), because it wouldn't make sense for a binary package's Architecture field to be 'any' or 'all' *plus* an explicit list of architectures. (yes, .dsc might need different rules, but.) Ok, here's the wording current policy. one may specify a list of architectures separated by spaces, or the special values any or all. Here's part of my proposal. one may specify a list of architectures separated by spaces, a list of architecture wildcards separated by spaces, or the special values any or all. As a native english speaker that wording seems to me to imply (list of specific and/or wildcard architectures) or (any) or (all), which seems to be what you intend, but I guess it is open to possible misinterpretation in the manner Julien suggests. How about: ... a list of specific and wildcard architectures separated by spaces, or the special values 'any' or 'all'. Cheers, Andrew. Andrew @ McMillan .Net .NZ Porirua, New Zealand http://andrew.mcmillan.net.nz/Phone: +64(272)DEBIAN Open Source: the difference between trust and antitrust -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#530687: debian-policy: Please provide policy for architecture wildcards
://lists.debian.org/debian-devel/2009/02/msg00290.html -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.29-2-686 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash debian-policy depends on no packages. debian-policy recommends no packages. Versions of packages debian-policy suggests: ii doc-base 0.9.2 utilities to manage online documen -- no debconf information Andrew @ McMillan .Net .NZ Porirua, New Zealand http://andrew.mcmillan.net.nz/Phone: +64(272)DEBIAN Q: What lies on the bottom of the ocean and twitches? A: A nervous wreck. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#530378: debian-policy: allow /usr/share/doc/package to point to another indirectly-depended-upon package's dir
On Sun, 2009-05-24 at 16:07 +0200, Serafeim Zanikolas wrote: Policy allows a package's doc directory to be a symlink to another package's doc directory, as long as they are: - from the same source package and - the first package directly depends upon the second I propose that that the second requirement is relaxed to allow for an indirect dependency of the first package to the second (as long as all packages involved have the same source). Hi, I don't like the idea of muddying policy with this sort of convoluted exception, and I can't see the value of it from a technical perspective. Regards, Andrew McMillan. Andrew @ McMillan .Net .NZ Porirua, New Zealand http://andrew.mcmillan.net.nz/Phone: +64(272)DEBIAN Necessity is the mother of documentation -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#527871: Update information about DEB_*_ARCH variables
On Sat, 2009-05-09 at 06:45 +0200, Guillem Jover wrote: Package: debian-policy Version: 3.8.1.0 Severity: wishlist Tags: patch Hi! Recommend using the DEB_*_ARCH_CPU and DEB_*_ARCH_OS variables instead of the GNU style ones. And mention that the latter are mostly intended for use with upstream build systems, and not Debian packaging. Seconded. Regards, Andrew. andrew (AT) morphoss (DOT) com+64(272)DEBIAN Your step will soil many countries. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523551: Quanta 3.5.9 with kde4
Hi, While you're relaxing dependencies, it might as well to change the Suggests for kimagemapeditor at the same time. Regards, Andrew. andrew (AT) morphoss (DOT) com+64(272)DEBIAN I have not seen high-discipline processes succeed in commercial settings. - Alistair Cockburn -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#522776: debian-policy: mandate existence of a standardised UTF-8 locale
locale. No? so what it misses? - other alphabetic, numeric, currency, whitespace characters? But not UTF-8 local provides all characters: they define only the needed range for the language [see wikipedia, which should code UTF-8 as binary for this reason]. The C spoken language require only ASCII-7 (or maybe only a subrange of it). So why we need further characters? Note: whitespace are restricted in C locale by POSIX, in only two values We could use charset UTF-8 for C locale, declaring unused/illegal all c 127. Whould this solve the problems with mksh? I don't think so, so what you need in this C.UTF-8? I still think that en_US.UTF-8 is the right default (note: I'm not a US citizen, nor I speak English). Note that this proposal is not that we change the default sort ordering or character typing, which en_US *would* do (vs C). This proposal (if it were that strong) would be pushing for adoption of UTF-8 encoding as the default encoding. It isn't as strong as that, though. It is merely pushing for the *availability* of a UTF-8 locale on a default install. The installation will install the correct locale, so the en_US period is very short (we'll dominate them ;-) ). On debootstrap/pbuild/... things are different. But if it this the problem, let check a solution for building environment (and I still think that in this env en_US.UTF-8 could be nice. But I'll prefer a simple basic ASCII-7 C for basic/plain build, and only after packager thinks if it is a bug or a feature to have a specific build with UTF-8, it should manually set it. Why build need to depend to a locale? UNIX way is to allow to compile things for remote (maybe other OS, other arch) system. For testing? So why not test various locales (UTF-8, but also other non ascii based encodings) What environments people build or test in is a separate issue to what environments are available to them to build or test in, and indeed Steve Langasek has already suggested a seemingly reasonable workaround for the immediate problem which was, funnily enough, that mksh wants to have a UTF-8 locale *available* in order for it to *test the build*... So we could close this bug as 'why bother', really, but the discussion is much more important than that. Regards, Andrew McMillan. andrew (AT) morphoss (DOT) com+64(272)DEBIAN Does the turtle move for you? www.kame.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#522776: debian-policy: mandate existence of a standardised UTF-8 locale
On Wed, 2009-04-08 at 15:31 +0200, Giacomo A. Catenazzi wrote: We have the same objective, but two different ways. Indeed, but it seems to me that you are pushing for a much bigger change than I am. So the smallest step which is in the same direction both of us want to go, is for *a* UTF-8 locale to be *available* on all Debian systems, which is what is being proposed by this bug. Cheers, Andrew. andrew (AT) morphoss (DOT) com+64(272)DEBIAN Just to have it is enough. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#522776: debian-policy: mandate existence of a standardised UTF-8 locale
On Tue, 2009-04-07 at 22:32 +0200, Adeodato Simó wrote: It is my impression that more packages than mksh could use an UTF-8 locale at build time (I’m afraid I don’t have pointers, but I’m sure I’ve come across at least a couple). Wouldn’t it be just better to change Debian’s default to make an UTF-8 locale available by default, rather than to force all those packages to play tricks with LOCPATH? I too would really like to see a UTF-8 locale available by default, and would prefer to see this be the C.UTF-8 locale, which doesn't screw with the collation / character type settings like any other UTF-8 locale would. It seems to me that the consensus here is that having a UTF-8 locale available is a good idea and I don't hear any very strong argument against such a change. Consequently I think we should move on from the discussion and start working out a patch to resolve this in policy. Regards, Andrew. andrew (AT) morphoss (DOT) com+64(272)DEBIAN Time to be aggressive. Go after a tattooed Virgo. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#522364: debian-policy: Remove obsolete /var/mail transition requirement
On Thu, 2009-04-02 at 21:57 -0700, Russ Allbery wrote: Package: debian-policy Version: 3.8.1.0 Severity: minor This looks extremely obsolete. I think it can just be removed. Seconds? Seconded. Regards, Andrew. diff --git a/policy.sgml b/policy.sgml index 975df94..a5c9d13 100644 --- a/policy.sgml +++ b/policy.sgml @@ -5697,12 +5697,6 @@ rmdir /usr/local/share/emacs 2/dev/null || true by any particular mail agents. The use of the old location file/var/spool/mail/file is deprecated, even though the spool may still be physically located there. - To maintain partial upgrade compatibility for systems - which have file/var/spool/mail/file as their physical mail - spool, packages using file/var/mail/file must depend on - either packagelibc6/package (gt;= 2.1.3-13), or on - packagebase-files/package (gt;= 2.2.0), or on later - versions of either one of these packages. /p /sect1 /sect -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash debian-policy depends on no packages. debian-policy recommends no packages. Versions of packages debian-policy suggests: ii doc-base 0.9.1 utilities to manage online documen -- no debconf information andrew (AT) morphoss (DOT) com+64(272)DEBIAN The goal of good engineering is not to ask what if?, but to ask how do I make this work as well as possible. -- Linus Torvalds -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#521862: More info about the evolution startup crash
On Tue, 2009-03-31 at 12:05 +0200, Svante Signell wrote: I had the same problem and solved it by downgrading the sqlite3 packages (libsqlite3-0 and sqlite3) that were upgraded today. Paulo Silva p...@eurotux.com Eurotux Informática, S.A. Did not help: I downgraded to libsqlite3-0_3.6.11-3, still evolution does not start. However, another box that has this package installed and has not crashed (yet). There might be some other package involved too. Any dependencies that were recently upgraded (last two days)? OK, that was a help. While downgrading sqlite to any of 3.6.11-* didn't help me, downgrading to 3.5.9-6 did sort the problem out and I am now able to get back into my e-mail... Regards, Andrew McMillan. andrew (AT) morphoss (DOT) com+64(272)DEBIAN How can you govern a country that makes 365 different kinds of cheese? -- Charles de Gaulle -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#206684: mandatory use of debconf for user prompting a release goal for squeeze
On Thu, 2009-03-19 at 16:44 -0700, Russ Allbery wrote: Andrew McMillan and...@morphoss.com writes: Here's an updated patch to apply the following wording: Package maintainer scripts may prompt the user if necessary. Prompting must be done by communicating through a program, such as debconf, which conforms to the Debian Configuration Management Specification, version 2 or higher. Packages which are essential, or which are dependencies of essential packages, may fall back on another prompting method if no such interface is available when they are executed. Seconded. That seems to be accepted by everyone, so I've pushed it to policy now. I hope that's the right thing... Please tell me if I've done something the wrong way, or whatever. Cheers, Andrew. andrew (AT) morphoss (DOT) com+64(272)DEBIAN Courage is your greatest present need. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#206684: mandatory use of debconf for user prompting a release goal for squeeze
On Fri, 2009-03-20 at 23:43 +0100, Julien Cristau wrote: On Sat, 2009-03-21 at 10:27 +1300, Andrew McMillan wrote: That seems to be accepted by everyone, so I've pushed it to policy now. I hope that's the right thing... Please tell me if I've done something the wrong way, or whatever. It looks like you've modified the 3.8.1.0 changelog entry instead of 3.8.2 :) Gah! Sorry - fixed now. Cheers, Andrew. andrew (AT) morphoss (DOT) com+64(272)DEBIAN Open Source: the difference between trust and antitrust -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#452843: amavisd-new-milter init script needs love...
Hi, The location of the milter socket is not particularly helpful for postfix installations, and it would be great to be able to change it easily through an /etc/default/amavisd-new-milter file source in the initscript. If you need me to I will provide a patch to this bug report - just say the word... Also, the -D parameter is ignored, according to the command-line help, so you might as well remove it when you make that change too. Thanks, Andrew McMillan. andrew (AT) morphoss (DOT) com+64(272)DEBIAN You have the power to influence all with whom you come in contact. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#206684: mandatory use of debconf for user prompting a release goal for squeeze
On Wed, 2009-03-18 at 20:26 -0700, Russ Allbery wrote: Management Specification, version 2 or higher, unless no such interface is available when they are executed. Should we require that non-essential packages depend on debconf if they're going to do prompting? That wording implies to me that any package could check whether it was already installed (without a dependency) and fall back on non-debconf prompting, but I think that should only be permissible for essential packages. It seems to me that to mandate it that tightly is unnecessary. Surely it will be simpler for a maintainer who has added support for Debconf to just depend on it. Even if the maintainer does provide a workaround for an inessential package I can't see that it will matter to me: the important element is that they support the debconf interface, not to restrict what they might do in addition to that. The only other thing that I'm not sure about is what to do about preinst scripts. Are we requiring debconf for preinst prompting (and hence requiring a Pre-Depends) for non-essential packages? If a developer wants to prompt in their preinst (extremely rare, I believe, and explicitly recommended against in policy) then they certainly should either (a) pre-depend on debconf, or (b) provide a work-around solution for the case where debconf is not installed on the target system. The decision to pre-depend on debconf would seem like a no-brainer to the maintainer, I suspect. Since almost all packages *will* have situations where they are called when debconf is available they will (according to the wording above) all be required to use debconf. The fallback would only be chosen at execution time. Effectively I'm proposing that all packages needing user input must support debconf (or equivalent) - but also to recognise that some of them might be required to (install|configure|remove|...) with user input in it's absence and not to restrict them from Doing The Right Thing in that circumstance. Cheers, Andrew. andrew (AT) morphoss (DOT) com+64(272)DEBIAN You will gain money by a fattening action. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#206684: mandatory use of debconf for user prompting a release goal for squeeze
On Thu, 2009-03-19 at 10:55 -0700, Russ Allbery wrote: Packages that are essential or that are dependencies of essential packages may fall back on another prompting method if no such interface is available when they are executed. Since we're essentially saying that all packages must support debconf, why bother restricting the set of packages which are allowed to provide a fallback? From a maintainer's POV surely they will only be working to provide a fallback if they desire their package to be installable when debconf is not available. I don't think we should second-guess their reasons for doing so. Our motivation here should be simply to ensure that all packages support debconf (or a future replacement), not to over-control what they can do in addition to that. Cheers, Andrew. andrew (AT) morphoss (DOT) com+64(272)DEBIAN Your true value depends entirely on what you are compared with. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#206684: mandatory use of debconf for user prompting a release goal for squeeze
On Thu, 2009-03-19 at 13:59 -0700, Steve Langasek wrote: On Fri, Mar 20, 2009 at 09:13:19AM +1300, Andrew McMillan wrote: On Thu, 2009-03-19 at 10:55 -0700, Russ Allbery wrote: Packages that are essential or that are dependencies of essential packages may fall back on another prompting method if no such interface is available when they are executed. Since we're essentially saying that all packages must support debconf, why bother restricting the set of packages which are allowed to provide a fallback? Because the fallback is a worst case scenario, because testing for files on the filesystem is a poor proxy for determining whether the interface is in a usable state, and because adding the fallback code means duplicating logic in your maintainer script and making it way more complex than it needs to be. The fallback should only be permitted in Essential packages where it has to be there in order to avoid unbreakable loops; in all other cases, maintainers should properly declare their need for debconf and avoid making their maintainer scripts more clever and less robust. This also ensures that (assuming the maintainer is following policy) uses of debconf in preinsts are publically vetted by debian-devel before hitting the archive. OK, those are excellent reasons. Here's an updated patch to apply the following wording: Package maintainer scripts may prompt the user if necessary. Prompting must be done by communicating through a program, such as debconf, which conforms to the Debian Configuration Management Specification, version 2 or higher. Packages which are essential, or which are dependencies of essential packages, may fall back on another prompting method if no such interface is available when they are executed. Cheers, Andrew. andrew (AT) morphoss (DOT) com+64(272)DEBIAN Flexibility is overrated. Constraints are liberating. diff --git a/policy.sgml b/policy.sgml index df586d1..8f02c12 100644 --- a/policy.sgml +++ b/policy.sgml @@ -1218,17 +1218,16 @@ headingPrompting in maintainer scripts/heading p Package maintainer scripts may prompt the user if - necessary. Prompting should be done by communicating + necessary. Prompting must be done by communicating through a program, such as prgndebconf/prgn, which conforms to the Debian Configuration Management - Specification, version 2 or higher. Prompting the user by - other means, such as by handfootnote -From the Jargon file: by hand 2. By extension, -writing code which does something in an explicit or -low-level way for which a presupplied library -(emdebconf, in this instance/em) routine ought -to have been available. -/footnote, is now deprecated. + Specification, version 2 or higher. + /p + + p + Packages which are essential, or which are dependencies of + essential packages, may fall back on another prompting method + if no such interface is available when they are executed. /p p
Bug#206684: mandatory use of debconf for user prompting a release goal for squeeze
On Wed, 2009-03-18 at 14:42 -0700, Russ Allbery wrote: I'm not sure how many of these were false positives, but I'm fairly sure that at least some of them are real: http://lintian.debian.org/tags/read-in-maintainer-script.html Not all that many, and some will be false positives. I think we should go for it... Yes. I think there was some sort of essential package exception discussed earlier in the bug (although even essential packages should try debconf first and fall back if it's not available, I think). I'd be very happy to see a policy change for this, so long as it allowed that packages may fall back if debconf (or other alternative) is not available. The current relevant text is: Package maintainer scripts may prompt the user if necessary. Prompting should be done by communicating through a program, such as debconf, which conforms to the Debian Configuration Management Specification, version 2 or higher. Prompting the user by other means, such as by hand[9], is now deprecated. I think we should change that fairly simply to something like: Package maintainer scripts may prompt the user if necessary. Prompting must be done by communicating through a program, such as debconf, which conforms to the Debian Configuration Management Specification, version 2 or higher, unless no such interface is available when they are executed. This: (a) changes the 'should' to a 'must'; (b) gives an out for those situations where debconf is not installed; (c) narrowly focuses that 'out' only to apply during execution (d) seems to me to be a simpler and more elegant approach than other wording proposals against this bug. I've attached a patch to that effect. Cheers, Andrew. andrew (AT) morphoss (DOT) com+64(272)DEBIAN Don't go surfing in South Dakota for a while. diff --git a/policy.sgml b/policy.sgml index df586d1..342b6c4 100644 --- a/policy.sgml +++ b/policy.sgml @@ -1218,17 +1218,11 @@ headingPrompting in maintainer scripts/heading p Package maintainer scripts may prompt the user if - necessary. Prompting should be done by communicating + necessary. Prompting must be done by communicating through a program, such as prgndebconf/prgn, which conforms to the Debian Configuration Management - Specification, version 2 or higher. Prompting the user by - other means, such as by handfootnote -From the Jargon file: by hand 2. By extension, -writing code which does something in an explicit or -low-level way for which a presupplied library -(emdebconf, in this instance/em) routine ought -to have been available. -/footnote, is now deprecated. + Specification, version 2 or higher, unless no such + interface is available when they are executed. /p p
Bug#509732: marked as done (Debian Policy doesn't include directive for filing RC bugs against the Policy)
reopen 509732 thanks It is truly classic irony that we see this one getting closed by spammers :-) andrew (AT) morphoss (DOT) com+64(272)DEBIAN Executive ability is prominent in your make-up. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#470994: mail_spool default mode is 0660
On Sun, 2009-01-25 at 15:42 -0800, Russ Allbery wrote: This is a ping for this proposed change for additional seconds or objections. It would relax the requirement in Policy that mail spool files be mode 0660 and permit them to be mode 0600 if the MDA system used does deliveries as the user. --- a/policy.sgml +++ b/policy.sgml @@ -8062,12 +8062,27 @@ http://localhost/doc/varpackage/var/varfilename/var /p p - Mailboxes are generally mode 660 - ttvaruser/var:mail/tt unless the system - administrator has chosen otherwise. A MUA may remove a - mailbox (unless it has nonstandard permissions) in which - case the MTA or another MUA must recreate it if needed. - Mailboxes must be writable by group mail. + Mailboxes are generally either mode 600 and owned by + varuser/var or mode 660 and owned by + ttvaruser/var:mail/ttfootnote + There are two traditional permission schemes for mail spools: + mode 600 with all mail delivery done by processes running as + the destination user, or mode 660 and owned by group mail with + mail delivery done by a process running as a system user in + group mail. Historically, Debian required mode 660 mail + spools to enable the latter model, but that model has become + increasingly uncommon and the principle of least privilege + indicates that mail systems that use the first model should + use permissions of 600. If delivery to programs is permitted, + it's easier to keep the mail system secure if the delivery + agent runs as the destination user. Debian Policy therefore + permits either scheme. + /footnote. The local system administrator may choose a + different permission scheme; packages should not make + assumptions about the permission and ownership of mailboxes + unless required (such as when creating a new mailbox). A MUA + may remove a mailbox (unless it has nonstandard permissions) in + which case the MTA or another MUA must recreate it if needed. /p p I've read through the report in full and I'm happy to second this also. Regards, Andrew McMillan. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#508673: davical can't find the include file AWLUtilities.php
On Mon, 2008-12-15 at 23:53 +0530, Akarsh Simha wrote: Hi Thanks for the explanation. Could libawl-php be made to notify this in some form to the user? Should I file a wishlist against libawl-php? I left the bug open because I agree that something needs to be done (probably in DAViCal) to simplify the installation process. I don't think that the library should really do anything, although possibly it should add itself to the default PHP include path. I'm still thinking about what exactly to do though. Probably I should ask a question about whether the user wants a virtual host or a subdirectory installation, and then drop a file into /etc/apache2/somewhere which does the right thing. There are other issues around creating the database automatically and so forth, which need to be addressed using dbconfig-common. It would be nice if someone else took over these packaging issues from me and I could concentrate on adding more features to DAViCal, but I don't expect that to happen either. Greater automation of the installation process has always been on my roadmap, but it's at a priority level which suggests it might never get implemented because I'll be too busy doing other things! Regards, Andrew McMillan. andrew (AT) morphoss (DOT) com+64(272)DEBIAN You are capable of planning your future. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#508673: davical can't find the include file AWLUtilities.php
severity 508673 wishlist thanks That's certainly one way of achieving your goal, but it isn't the recommended approach, or the one documented in the installation instructions on the website. Alternative approaches might involve using an Alias or DocumentRoot to associate the DAViCal htdocs directory with a path. You assert that always.php was looking for AWLUtilities.php in /usr/share/inc but surely that is not the case. It is looking for it in the include path that PHP has set on your system. The only reasonable approaches for providing access to the AWL library are to set the PHP include_path in the Apache virtual host, or in the php.ini, not to change the code. I don't expect to change the packaging of either AWL or DAViCal to accommodate this. I certainly *won't* be changing the code for any part of DAViCal to explicitly refer to the path, as you have done in always.php (I doubt that it is sufficient to change it there - you'd need to do a global search and replace for the paths of lots of includes). Regardless of whether it's broken now, your installation *will* break on upgrade unless you fix the PHP include path. The recommended settings to put into the Apache virtual host for running DAViCal include the following: php_value include_path /usr/share/awl/inc php_value magic_quotes_gpc 0 php_value register_globals 0 php_value error_reporting E_ALL ~E_NOTICE Note that the *only* includes required by DAViCal are the AWL ones. Regards, Andrew McMillan. andrew (AT) morphoss (DOT) com+64(272)DEBIAN Necessity is the mother of documentation -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#504749: sarg.usertab fails for IPv6 addresses
Package: sarg Version: 2.2.5-1 Severity: important When using sarg with a Squid proxy supporting IPv6, sarg correctly displays the client IPv6 address in it's reports, however when I attempt to translate those IPv6 addresses into more meaningful names with an entry in the sarg usertab, the ':' in the IPv6 address is interpreted as a delimiter and the replaced name is given as the second part of the IP address, i.e.: If I have a usertab line like: 2404:130:b055:0:219:7eff:fec9:7bce mysterio then I see '130' in my report. Alternatively, if I have a usertab line like: [2404:130:b055:0:219:7eff:fec9:7bce] mysterio which is a common way of representing IPv6 addresses in order to handle situations like this, then the name is not replaced at all. Squid IPv6 support is in Squid 3.1, which is currently nearing release, and it is likely that people will use Squid as one of the technologies for mediating between IPv6 and IPv4 networks, so I have marked this bug as 'Important' even though there are no doubt very few users at present who will be encountering the problem. Regards, Andrew McMillan. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (600, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.27 (PREEMPT) Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_NZ.UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages sarg depends on: ii bash 3.2-4 The GNU Bourne Again SHell ii libc6 2.7-15GNU C Library: Shared libraries ii libgd2-noxpm 2.0.36~rc1~dfsg-3 GD Graphics Library version 2 (wit sarg recommends no packages. Versions of packages sarg suggests: ii apache2-mpm-prefork [httpd] 2.2.9-10 Apache HTTP Server - traditional n ii libapache2-mod-php5 5.2.6-5server-side, HTML-embedded scripti pn squid none (no description available) pn squidguardnone (no description available) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#504223: python-uniconvertor: Falis to find fonts
Package: python-uniconvertor Version: 1.1.3-2 Severity: normal When I try and run uniconvertor I get the following error messages: I can't find font Humnst777 BT. I'll use Slim instead I can't find font Slim. I'll use Slim instead Traceback (most recent call last): ... File /usr/lib/python2.5/site-packages/uniconvertor/app/plugins/Filters/svgloader.py, line 338, in startElement getattr(self, method)(attrs) File /usr/lib/python2.5/site-packages/uniconvertor/app/plugins/Filters/svgloader.py, line 904, in begin_text self.parse_style(style) File /usr/lib/python2.5/site-packages/uniconvertor/app/plugins/Filters/svgloader.py, line 384, in parse_style self.try_add_style(key, val) File /usr/lib/python2.5/site-packages/uniconvertor/app/plugins/Filters/svgloader.py, line 422, in try_add_style self.style.font = GetFont(str(val)) File /usr/lib/python2.5/site-packages/uniconvertor/app/Graphics/font.py, line 425, in GetFont return GetFont(config.preferences.fallback_font) File /usr/lib/python2.5/site-packages/uniconvertor/app/Graphics/font.py, line 426, in GetFont raise ValueError, 'Cannot find font %s.' % fontname ValueError: Cannot find font Slim. This is bad from two points. Firstly, it didn't find the font, which presumably means it is not looking in ~/.fonts - the standard place that non-root users have to install fonts. What is worse though, is that it is falling back to a non-existent font. Furthermore, the manpage gives no information on how one might be able to configure an existing font as the fallback, or add other directories to it's font search path, even though the error messages about config.preferences.fallback_font and so forth suggest that this might be possible. Thanks, Andrew McMillan. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (990, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.28-rc2-happy (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_NZ.UTF8, LC_CTYPE=POSIX (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages python-uniconvertor depends on: ii libc6 2.7-15 GNU C Library: Shared libraries ii python2.5.2-2An interactive high-level object-o ii python-central0.6.8 register and build utility for Pyt ii python-imaging1.1.6-3Python Imaging Library ii python-reportlab 2.2-2 ReportLab library to create PDF do python-uniconvertor recommends no packages. Versions of packages python-uniconvertor suggests: pn python-uniconvertor-dbg none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502273: sarg: Poor file location and naming
Package: sarg Version: 2.2.5-1 Severity: normal From the FHS: The /etc hierarchy contains configuration files. A configuration file is a local file used to control the operation of a program; it must be static and cannot be an executable binary sarg places the images which are to be referenced from the generated graphs into /etc/squid/images, but these are not conffiles and should be in /usr/share/images/sarg instead. Fonts, placed similarly in /etc/squid/fonts, should be moved to /usr/share/fonts - or better yet, an appropriate dependency introduced, and fonts from one of the plethora of Debian font packages should be used directly. In general the location and naming of files seems dodgy. Should the files in /etc not be in /etc/packagename: i.e. /etc/sarg rather than in /etc/squid. Fortunately for my personal case this directory is empty, as squid keeps it's configuration in /etc/squid3, but this will often not be the case and the mixing of configuration from two packages could cause confusion for the administrator. Further confusion could also be garnered from the naming of individual files. Three files in /etc/squid are called as follows: - sarg.exclude_codes - sarg.hosts - sarg.users In a nice trap for the unwary administrator, these three files are *all* exclude lists. Renaming them would seem an appropriate measure: - sarg.exclude_codes - sarg.exclude_hosts - sarg.exclude_users particularly as the file names would then match the names of the actual sarg configuration options! Thanks, Andrew McMillan. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (990, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.27-happy (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_NZ.UTF8, LC_CTYPE=POSIX (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages sarg depends on: ii bash 3.2-4 The GNU Bourne Again SHell ii libc6 2.7-14GNU C Library: Shared libraries ii libgd2-noxpm 2.0.36~rc1~dfsg-3 GD Graphics Library version 2 (wit sarg recommends no packages. Versions of packages sarg suggests: ii apache2-mpm-prefork [httpd] 2.2.9-10 Apache HTTP Server - traditional n ii libapache2-mod-php5 5.2.6-5server-side, HTML-embedded scripti pn squid none (no description available) pn squidguardnone (no description available) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#501266: [intl:fr] davical po templates translation
On Mon, 2008-10-06 at 09:14 +0200, Steve wrote: Package: davical Version: 0.9.5.3 Severity: wishist Tags: l10n Patch Hi, Please find attached the french debconf templates translation, proofread by the debian-l10n-french mailing list contributors. This file should be put as debian/po/fr.po in your package build tree. Hi, Thanks for this. Can you confirm that there should be a non-breaking space at the end of words and before an ! or ?, or is this a mistake and there should be no space at all? Also I have changed LIbreOccupé to LibreOccupé - presumably that was just a typo. Thanks, Andrew McMillan. andrew (AT) morphoss (DOT) com+64(272)DEBIAN Bruce Schneier can log into any computer just by staring down the prompt. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493687: two removal suggestions awl and gem
On Mon, 2008-09-01 at 21:06 +0200, Thomas Viehmann wrote: Hi, two removal suggestions for lenny: - awl: initial upload in mid-July, does not properly build from source, is RC-buggy (#493687). Hi, I'll fix the bugs in AWL this week but I'm happy for this, since the point of having it in is kind of lost without the other software it depends on which didn't make it into testing before the freeze. Cheers, Andrew. Andrew @ McMillan .Net .NZ Porirua, New Zealand http://andrew.mcmillan.net.nz/Phone: +64(272)DEBIAN You will live a long, healthy, happy life and make bags of money. signature.asc Description: This is a digitally signed message part
Bug#490872: New qlandkarte upstream release.
Package: qlandkarte Version: 0.7.2+svn20080629-1 Severity: wishlist Hi, I note that there is a new upstream release of qlandkarte available which adds some nice new features, and fixes a bunch of bugs. Thank you, Andrew McMillan. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (990, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.26-rc9-hippy (SMP w/2 CPU cores) Locale: LANG=en_NZ.UTF8, LC_CTYPE=POSIX (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages qlandkarte depends on: ii libc62.7-12 GNU C Library: Shared libraries ii libgcc1 1:4.3.1-6 GCC support library ii libqt4-network 4.4.0-4 Qt 4 network module ii libqt4-xml 4.4.0-4 Qt 4 XML module ii libqtcore4 4.4.0-4 Qt 4 core module ii libqtgui44.4.0-4 Qt 4 GUI module ii libstdc++6 4.3.1-6 The GNU Standard C++ Library v3 ii libusb-0.1-4 2:0.1.12-12 userspace USB programming library ii proj 4.6.0-1 Cartographic projection filter and qlandkarte recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490438: ITP: libawl-php -- Andrew's Web Libraries - PHP Utility Libraries
Package: wnpp Severity: wishlist Owner: Andrew McMillan [EMAIL PROTECTED] * Package name: libawl-php Version : 0.30 Upstream Author : Andrew McMillan [EMAIL PROTECTED] * URL : http://andrew.mcmillan.net.nz/projects/awl * License : GPL Programming Lang: PHP Description : Andrew's Web Libraries - PHP Utility Libraries This package contains Andrew's Web Libraries. This is a set of hopefully lightweight libraries for handling a variety of useful things for web programming, including: - Session management - User management - DB Records - Simple reporting - DB Schema Updating - iCalendar parsing -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (990, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.26-rc9-hippy (SMP w/2 CPU cores) Locale: LANG=en_NZ.UTF8, LC_CTYPE=POSIX (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490444: ITP: davical -- DAViCal CalDAV Server
Package: wnpp Severity: wishlist Owner: Andrew McMillan [EMAIL PROTECTED] * Package name: davical Version : 0.9.5.1 Upstream Author : Andrew McMillan [EMAIL PROTECTED] * URL : http://rscds.sf.net/ * License : GPL Programming Lang: PHP Description : DAViCal CalDAV Server The DAViCal CalDAV Server is designed to trivially store CalDAV calendars, such as those from Evolution, Sunbird/Lightning, Mulberry, iCal or SOHO Organizer, in a central location, providing shared calendars, free/busy publication and basic administration -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (990, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.26-rc9-hippy (SMP w/2 CPU cores) Locale: LANG=en_NZ.UTF8, LC_CTYPE=POSIX (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#481010: ircd-ircu: Incorrectly masks IPv6 addresses causing connection refusal
Package: ircd-ircu
Version: 2.10.12.10.dfsg1-1
Severity: normal
Tags: patch
We had a switch outage in the office today, causing many people to be
disconnected from IRC. When they attempted to reconnect, many clients
failed to connect, receiving the message:
ERROR :Your host is trying to (re)connect too fast -- throttled
I tracked the problem down to line 123 of IPcheck.c where the code makes
an unwarranted assumption that IPv6 addresses should be masked to /64
and IPv4 addresses (after conversion to 6to4 format) should be masked to
/48.
Neither assumption is correct. Our entire LAN is a /64, and this is not
unusual (at all), and indeed IPv6 address autoconfiguration is exactly
designed for multiple devices to coexist without collisions inside a
/64 subnet.
Furthermore, the assumption is not warranted for IPv4 addresses which
are canonicalised into 6to4 IPv6 addresses and then masked to /48. It is
*expected* that people will configure private networks behind 6to4
gateways, frequently using a /64 network with address autoconfiguration,
resulting in the same kind of issue with masking, and the daemon makes
no attempt to distinguish between an IPv4 address which *it* has
canonicalised, and one which is within the 6to4 address of a realio,
trulio, IPv6 gateway.
The attached patch fixes the problem by setting the mask to /128 when
performing this test at connection time. It is possible that this
assumption occurs in other places as well, but this is the one causing
us pain right now :-)
Regards,
Andrew McMillan.
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (990, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.25.1-hippy (SMP w/2 CPU cores)
Locale: LANG=en_NZ.UTF8, LC_CTYPE=POSIX (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash
Versions of packages ircd-ircu depends on:
ii libc6 2.7-10 GNU C Library: Shared libraries
ircd-ircu recommends no packages.
-- no debconf information
diff --git a/ircd/IPcheck.c b/ircd/IPcheck.c
index c3cb586..c05d104 100644
--- a/ircd/IPcheck.c
+++ b/ircd/IPcheck.c
@@ -108,8 +108,8 @@ static unsigned int ip_registry_hash(const struct irc_in_addr *ip)
}
/** Find an IP registry entry if one exists for the IP address.
- * If \a ip looks like an IPv6 address, only consider the first 64 bits
- * of the address. Otherwise, only consider the final 32 bits.
+ * We consider the full 128 bits of any address since there might
+ * potentially be many people on a LAN behind a 6to4 gateway.
* @param[in] ip IP address to search for.
* @return Matching registry entry, or NULL if none exists.
*/
@@ -120,8 +120,7 @@ static struct IPRegistryEntry* ip_registry_find(const struct irc_in_addr *ip)
ip_registry_canonicalize(canon, ip);
entry = hashTable[ip_registry_hash(canon)];
for ( ; entry; entry = entry-next) {
-int bits = (canon.in6_16[0] == htons(0x2002)) ? 48 : 64;
-if (ipmask_check(canon, entry-addr, bits))
+if (ipmask_check(canon, entry-addr, 128))
break;
}
return entry;
Bug#475790: coreutils: touch -d fails to parse ISO timestamps correctly
Package: coreutils Version: 6.10-3 Severity: normal [EMAIL PROTECTED]:~$ touch 20080412.gpx --date=2008-04-12T05:21:44Z touch: invalid date format `2008-04-12T05:21:44Z' [EMAIL PROTECTED]:~$ touch 20080412.gpx --date=2008-04-12T05:21:44 [EMAIL PROTECTED]:~$ ls -l 20080412.gpx -rw-rw-r-- 1 andrew andrew 232974 2008-04-12 10:21 20080412.gpx There are two problems here, one of which is covered by: http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=nobug=286201 The manpage for touch says: -d, --date=STRING parse STRING and use it instead of current time Since there is no mention of what format the STRING must be it seems to me very reasonable to assume that ISO date formats should be acceptable to it, at a minimum. The trailling Z on an ISO date indicates that the date has been canonicalised to UTC, and the 'T', of course, separates the date and time parts. It seems to me that this clearly violates the 'principal of least surprise'. Although I understand the importance of the need to remain backward- compatible with older methods of parsing dates we must be reaching a time where the likelihood of a string such as '2008-04-12T05:21:44' *not* being an ISO format date approaches zero. Regards, Andrew McMillan. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (990, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.25-rc8-hippy (SMP w/2 CPU cores) Locale: LANG=en_NZ.UTF8, LC_CTYPE=POSIX (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages coreutils depends on: ii libacl1 2.2.45-1 Access control list shared library ii libc6 2.7-9 GNU C Library: Shared libraries ii libselinux1 2.0.59-1 SELinux shared libraries coreutils recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#474175: IPv6 support works well
Hi, I managed to add --enable-ipv6 into the configure script for this and build it (on my Mips-based router with 32M RAM, running Debian from a USB stick, so that was a challenge in itself). The capture of IPv6 traffic is working just fine. so this really should be a trivial build change. Regards, Andrew McMillan. - Andrew @ Catalyst .Net .NZ Ltd, PO Box 11-053, Manners St, Wellington WEB: http://catalyst.net.nz/PHYS: Level 6, 150-154 Willis St DDI: +64(4)803-2201 MOB: +64(272)DEBIAN OFFICE: +64(4)499-2267 Bruce Schneier writes his books and essays by generating random alphanumeric text of an appropriate length and then decrypting it. - signature.asc Description: This is a digitally signed message part
Bug#474175: pmacct: Please enable IPv6 support
Package: pmacct Version: 0.11.4-1 Severity: normal According to the documentation, pmacctd supports reporting on IPv6 traffic, but it needs to be built with the --enable-ipv6 flag configured for this functionality to be included. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (990, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.25-rc8-hippy (SMP w/2 CPU cores) Locale: LANG=en_NZ.UTF8, LC_CTYPE=POSIX (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages pmacct depends on: ii iproute20080108-1Professional tools to control the ii libc6 2.7-9 GNU C Library: Shared libraries ii libmysqlclient15off5.0.51a-3 MySQL database client library ii libpcap0.8 0.9.8-3 system interface for user-level pa ii libpq5 8.3.1-1 PostgreSQL C client library ii libsqlite3-0 3.5.7-1 SQLite 3 shared library ii zlib1g 1:1.2.3.3.dfsg-11 compression library - runtime pmacct recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#471104: php5: Please rebuild against up to date timezone data
Package: php5 Version: 5.2.0-8+etch10 Severity: critical Justification: causes serious data loss The timezone data included in the current Etch build of PHP5 is out of date. This causes timezone related calculations to be incorrect for some parts of the world, notably (from 2:00am this morning) New Zealand. Thanks, Andrew McMillan. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.24.2-mousy Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_NZ.UTF-8) Versions of packages php5 depends on: ii libapache2-mod-php5 5.2.0-8+etch10 server-side, HTML-embedded scripti ii php5-common 5.2.0-8+etch10 Common files for packages built fr php5 recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#456634: closed by Bernd Zeimetz [EMAIL PROTECTED] (GSA sentences should be included since 2.36-1)
It is indeed working now, and gpsdrive correctly displays my altitude as a result. Thanks very much, Andrew McMillan. On Sun, 2008-01-13 at 11:15 +, Debian Bug Tracking System wrote: This is an automatic notification regarding your Bug report which was filed against the gpsd package: #456634: gpsd: Translated NMEA output does not include a GSA sentence It has been closed by Bernd Zeimetz [EMAIL PROTECTED]. Hi Andrew, gpsd should print GSA messages since 2.36-1. Since 2.36-2, which was uploaded a few seconds ago, the Garmin USB driver is supposed to work again, too. Could you please test if both bugs are really fixed and - if not - reopen them? Thanks, Bernd - Andrew @ Catalyst .Net .NZ Ltd, PO Box 11-053, Manners St, Wellington WEB: http://catalyst.net.nz/PHYS: Level 2, 150-154 Willis St DDI: +64(4)803-2201 MOB: +64(272)DEBIAN OFFICE: +64(4)499-2267 A gift of a flower will soon be made to you. - signature.asc Description: This is a digitally signed message part
Bug#460606: fbpanel: Allow option for multiple rows in tasklist / pager
Package: fbpanel Version: 4.12-1 Severity: wishlist Hi, The fbpanel tasklist and pager can only show the tasks / desktops in a single row. It would be nice to be able to configure these to have two or three rows, so that eight desktops could be 2 rows of four, or 9 could be 3 rows of three. I find that this approach justifies having a slightly taller panel that is still useful when I have many applications open and/or many desktops available. Thanks, Andrew McMillan. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (990, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.24-rc7-hippy (SMP w/2 CPU cores) Locale: LANG=en_NZ.UTF8, LC_CTYPE=POSIX (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages fbpanel depends on: ii libatk1.0-0 1.20.0-1 The ATK accessibility toolkit ii libc6 2.7-5 GNU C Library: Shared libraries ii libcairo2 1.4.12-2 The Cairo 2D vector graphics libra ii libfontconfig12.5.0-2generic font configuration library ii libglib2.0-0 2.14.4-2 The GLib library of C routines ii libgtk2.0-0 2.12.3-2 The GTK+ graphical user interface ii libpango1.0-0 1.18.3-1 Layout and rendering of internatio ii librsvg2-common 2.18.2-1 SAX-based renderer library for SVG ii libx11-6 2:1.1.3-1 X11 client-side library ii libxcursor1 1:1.1.9-1 X cursor management library ii libxext6 1:1.0.3-2 X11 miscellaneous extension librar ii libxfixes31:4.0.3-2 X11 miscellaneous 'fixes' extensio ii libxi62:1.1.3-1 X11 Input extension library ii libxinerama1 1:1.0.2-1 X11 Xinerama extension library ii libxmu6 1:1.0.3-1 X11 miscellaneous utility library ii libxrandr22:1.2.2-1 X11 RandR extension library ii libxrender1 1:0.9.4-1 X Rendering Extension client libra fbpanel recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#456634: gpsd: Translated NMEA output does not include a GSA sentence
This is a different problem entirely, I guess, but it means I can't test whether the GSA changes make any difference :-( Regards, Andrew McMillan. - Andrew @ Catalyst .Net .NZ Ltd, PO Box 11-053, Manners St, Wellington WEB: http://catalyst.net.nz/PHYS: Level 2, 150-154 Willis St DDI: +64(4)803-2201 MOB: +64(272)DEBIAN OFFICE: +64(4)499-2267 The difference between a crazy person and an intelligent one is that the crazy one doesn't realize what makes sense in the world. -- Linus Torvalds - signature.asc Description: This is a digitally signed message part
Bug#456149: gpsdrive: Doesn't display my altitude
Package: gpsdrive Version: 2.10~pre4-1 Severity: normal GPSDrive is not displaying any altitude reading from my GPS (a Garmin 60CSx). If I telnet to the gpsd port on my local machine I definitely do see my altitude coming through on the various data streams available. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (990, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.24-rc3-hippy (SMP w/2 CPU cores) Locale: LANG=en_NZ.UTF8, LC_CTYPE=POSIX (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages gpsdrive depends on: ii libart-2.0-22.3.19-3 Library of functions for 2D graphi ii libatk1.0-0 1.20.0-1 The ATK accessibility toolkit ii libboost-filesystem1.34 1.34.1-2 filesystem operations (portable pa ii libboost-thread1.34.1 1.34.1-2 portable C++ multi-threading ii libc6 2.7-3GNU C Library: Shared libraries ii libcairo2 1.4.10-1 The Cairo 2D vector graphics libra ii libfontconfig1 2.5.0-2 generic font configuration library ii libfreetype62.3.5-1+b1 FreeType 2 font engine, shared lib ii libgcc1 1:4.2.2-4GCC support library ii libglib2.0-02.14.4-2 The GLib library of C routines ii libgtk2.0-0 2.12.2-1 The GTK+ graphical user interface ii libmapnik1d 0.4.0-2+b1 C++/Python toolkit for developing ii libpango1.0-0 1.18.3-1 Layout and rendering of internatio ii libpcre37.3-2Perl 5 Compatible Regular Expressi ii libpng12-0 1.2.15~beta5-3 PNG library - runtime ii libstdc++6 4.2.2-4 The GNU Standard C++ Library v3 ii libx11-62:1.1.3-1X11 client-side library ii libxcomposite1 1:0.4.0-1X11 Composite extension library ii libxcursor1 1:1.1.9-1X cursor management library ii libxdamage1 1:1.1.1-3X11 damaged region extension libra ii libxext61:1.0.3-2X11 miscellaneous extension librar ii libxfixes3 1:4.0.3-2X11 miscellaneous 'fixes' extensio ii libxi6 2:1.1.3-1X11 Input extension library ii libxinerama11:1.0.2-1X11 Xinerama extension library ii libxml2 2.6.30.dfsg-3GNOME XML library ii libxrandr2 2:1.2.2-1X11 RandR extension library ii libxrender1 1:0.9.4-1X Rendering Extension client libra ii openstreetmap-map-icons 2.10~pre4-1 Collection of map icons ii openstreetmap-map-icons 2.10~pre4-1 Collection of map icons ii zlib1g 1:1.2.3.3.dfsg-7 compression library - runtime Versions of packages gpsdrive recommends: ii gpsd 2.34.dfsg-6 GPS (Global Positioning System) da ii gpsdrive-scripts 2.10~pre4-1 Various scripts for gpsdrive -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#456152: gpsdrive: Can't override window size
Package: gpsdrive Version: 2.10~pre4-1 Severity: normal According to the man page, gpsdrive has -s and -r options to override the autodetection. Since the autodetection doesn't notice the panels at the top and bottom of my screen I tried to use these options to set a saner resolution. It appears that the options simply do not work, whether supplied alone, or together. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (990, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.24-rc3-hippy (SMP w/2 CPU cores) Locale: LANG=en_NZ.UTF8, LC_CTYPE=POSIX (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages gpsdrive depends on: ii libart-2.0-22.3.19-3 Library of functions for 2D graphi ii libatk1.0-0 1.20.0-1 The ATK accessibility toolkit ii libboost-filesystem1.34 1.34.1-2 filesystem operations (portable pa ii libboost-thread1.34.1 1.34.1-2 portable C++ multi-threading ii libc6 2.7-3GNU C Library: Shared libraries ii libcairo2 1.4.10-1 The Cairo 2D vector graphics libra ii libfontconfig1 2.5.0-2 generic font configuration library ii libfreetype62.3.5-1+b1 FreeType 2 font engine, shared lib ii libgcc1 1:4.2.2-4GCC support library ii libglib2.0-02.14.4-2 The GLib library of C routines ii libgtk2.0-0 2.12.2-1 The GTK+ graphical user interface ii libmapnik1d 0.4.0-2+b1 C++/Python toolkit for developing ii libpango1.0-0 1.18.3-1 Layout and rendering of internatio ii libpcre37.3-2Perl 5 Compatible Regular Expressi ii libpng12-0 1.2.15~beta5-3 PNG library - runtime ii libstdc++6 4.2.2-4 The GNU Standard C++ Library v3 ii libx11-62:1.1.3-1X11 client-side library ii libxcomposite1 1:0.4.0-1X11 Composite extension library ii libxcursor1 1:1.1.9-1X cursor management library ii libxdamage1 1:1.1.1-3X11 damaged region extension libra ii libxext61:1.0.3-2X11 miscellaneous extension librar ii libxfixes3 1:4.0.3-2X11 miscellaneous 'fixes' extensio ii libxi6 2:1.1.3-1X11 Input extension library ii libxinerama11:1.0.2-1X11 Xinerama extension library ii libxml2 2.6.30.dfsg-3GNOME XML library ii libxrandr2 2:1.2.2-1X11 RandR extension library ii libxrender1 1:0.9.4-1X Rendering Extension client libra ii openstreetmap-map-icons 2.10~pre4-1 Collection of map icons ii openstreetmap-map-icons 2.10~pre4-1 Collection of map icons ii zlib1g 1:1.2.3.3.dfsg-7 compression library - runtime Versions of packages gpsdrive recommends: ii gpsd 2.34.dfsg-6 GPS (Global Positioning System) da ii gpsdrive-scripts 2.10~pre4-1 Various scripts for gpsdrive -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#456149: gpsdrive: Doesn't display my altitude
On Thu, 2007-12-13 at 22:50 +0100, Andreas Putzo wrote: Hi Andrew, thanks for reporting this bug. On Dec 13 21:59, Andrew McMillan wrote: Package: gpsdrive Version: 2.10~pre4-1 Severity: normal GPSDrive is not displaying any altitude reading from my GPS (a Garmin 60CSx). If I telnet to the gpsd port on my local machine I definitely do see my altitude coming through on the various data streams available. Does the GPS Status bar in the bottom right corner sometimes displays a 3D Fix which is needed to determine the altitude? The problem might be that gpsdrive switches to n/a in the altitude widget as soon as your gps device loses its 3D fix. If this happens frequently it might look as if there were no altitude information altogether. It would be helpful if you could provide a sample of collected nmea data for example by starting gpsd with -D2 or by reading nmea sentences directly from the device. GPSDrive *never* displays the altitude. It always displays n/a in this area. The GPS itself is a Garmin GPSMap 60 CSx which has a barometric altimeter, can see 10 satellites at the time and is itself displaying altitude and '3D' in it's own status. Here is a sample from connecting to gpsd now. Regards, Andrew McMillan. - Andrew @ Catalyst .Net .NZ Ltd, PO Box 11-053, Manners St, Wellington WEB: http://catalyst.net.nz/PHYS: Level 2, 150-154 Willis St DDI: +64(4)803-2201 MOB: +64(272)DEBIAN OFFICE: +64(4)499-2267 The difference between a crazy person and an intelligent one is that the crazy one doesn't realize what makes sense in the world. -- Linus Torvalds - GPSD,R=1 $GPGSV,3,1,11,03,38,124,20,27,68,214,17,23,17,007,34,13,48,341,24*75 $GPGSV,3,2,11,28,19,284,33,19,59,086,25,25,82,137,20,11,08,023,32*7B $GPGSV,3,3,11,08,41,232,00,10,06,236,00,16,01,114,00*45 $GPGGA,071043,4106.5372,S,17452.2855,E,1,11,,96.2,M,16.836,M,,*48 $GPRMC,071043,A,4106.5372,S,17452.2855,E,0.1166,173.500,141207,,*3F $GPGSV,3,1,11,03,38,124,20,27,68,214,16,23,17,007,34,13,48,341,24*74 $GPGSV,3,2,11,28,19,284,33,19,59,086,25,25,82,137,20,11,08,023,32*7B $GPGSV,3,3,11,08,41,232,00,10,06,236,00,16,01,114,00*45 $GPGGA,071044,4106.5375,S,17452.2858,E,1,11,,95.5,M,16.836,M,,*41 $GPRMC,071044,A,4106.5375,S,17452.2858,E,0.0389,180.080,141207,,*31 $GPGSV,3,1,11,03,38,124,20,27,68,214,16,23,17,007,34,13,48,341,24*74 $GPGSV,3,2,11,28,19,284,33,19,59,086,25,25,82,137,20,11,08,023,32*7B $GPGSV,3,3,11,08,41,232,00,10,06,236,00,16,01,114,00*45 $GPGGA,071045,4106.5373,S,17452.2858,E,1,11,,95.8,M,16.836,M,,*4B $GPRMC,071045,A,4106.5373,S,17452.2858,E,0.1555,136.260,141207,,*31 $GPGSV,3,1,11,03,38,124,20,27,68,214,16,23,17,007,34,13,48,341,24*74 $GPGSV,3,2,11,28,19,284,33,19,59,086,25,25,82,137,20,11,08,023,32*7B $GPGSV,3,3,11,08,41,232,00,10,06,236,00,16,01,114,00*45 $GPGGA,071046,4106.5372,S,17452.2858,E,1,11,,96.1,M,16.836,M,,*43 $GPRMC,071046,A,4106.5372,S,17452.2858,E,0.2721,134.620,141207,,*33 $GPGSV,3,1,11,03,38,124,20,27,69,214,16,23,17,007,34,13,48,341,24*75 $GPGSV,3,2,11,28,19,283,33,19,59,086,25,25,82,136,20,11,08,025,32*7B $GPGSV,3,3,11,08,41,232,00,10,06,236,00,16,01,114,00*45 $GPGGA,071047,4106.5372,S,17452.2858,E,1,11,,95.9,M,16.836,M,,*49 $GPRMC,071047,A,4106.5372,S,17452.2858,E,0.2721,133.420,141207,,*37 $GPGSV,3,1,11,03,38,124,20,27,69,214,16,23,17,007,34,13,48,341,24*75 $GPGSV,3,2,11,28,19,283,33,19,59,086,25,25,82,136,20,11,08,025,32*7B $GPGSV,3,3,11,08,41,232,00,10,06,236,00,16,01,114,00*45 $GPGGA,071048,4106.5367,S,17452.2857,E,1,11,,97.4,M,16.836,M,,*42 $GPRMC,071048,A,4106.5367,S,17452.2857,E,0.2138,140.790,141207,,*31 $GPGSV,3,1,11,03,38,124,20,27,69,214,16,23,17,007,34,13,48,341,24*75 $GPGSV,3,2,11,28,19,283,33,19,59,086,25,25,82,136,20,11,08,025,32*7B $GPGSV,3,3,11,08,41,232,00,10,06,236,00,16,01,114,00*45 $GPGGA,071049,4106.5365,S,17452.2854,E,1,11,,97.4,M,16.836,M,,*42 $GPRMC,071049,A,4106.5365,S,17452.2854,E,0.1749,138.280,141207,,*39 $GPGSV,3,1,11,03,38,124,20,27,69,214,16,23,17,007,34,13,48,341,24*75 $GPGSV,3,2,11,28,19,283,33,19,59,086,25,25,82,136,20,11,08,025,32*7B $GPGSV,3,3,11,08,41,232,00,10,06,236,00,16,01,114,00*45 $GPGGA,071050,4106.5369,S,17452.2855,E,1,11,,96.4,M,16.836,M,,*46 $GPRMC,071050,A,4106.5369,S,17452.2855,E,0.6220,145.120,141207,,*32 $GPGSV,3,1,11,03,38,124,20,27,69,214,16,23,17,007,34,13,48,341,24*75 $GPGSV,3,2,11,28,19,283,33,19,59,086,25,25,82,136,20,11,08,025,32*7B $GPGSV,3,3,11,08,41,232,00,10,06,236,00,16,01,114,00*45 $GPGGA,071051,4106.5374,S,17452.2859,E,1,11,,95.4,M,16.836,M,,*44 $GPRMC,071051,A,4106.5374,S,17452.2859,E,0.6609,165.830,141207,,*36 $GPGSV,3,1,11,03,38,124,20,27,69,214,16,23,17,007,34,13,48,341,24*75 $GPGSV,3,2,11,28,19,283,33,19,59,086,24,25,82,136,20,11,08,025,32*7A $GPGSV
Bug#452357: xserver-xorg-video-intel: 945GM always crashes within 10 seconds of login
On Sat, 2007-11-24 at 13:32 +0100, Brice Goglin wrote: Please try without the Virtual line above, or with = 2048 for each dimension. If it helps, it would be a duplicate of #451570, even if you're seeing the lockup 10s after startup while other people see it immediately. Seems like it is probably a dupe of #451570 then. I've attached a log of my Xserver crashing when I reinstate the Virtual line... Thanks, Andrew McMillan. - Andrew @ Catalyst .Net .NZ Ltd, PO Box 11-053, Manners St, Wellington WEB: http://catalyst.net.nz/PHYS: Level 2, 150-154 Willis St DDI: +64(4)803-2201 MOB: +64(272)DEBIAN OFFICE: +64(4)499-2267 You'll be sorry... - X.Org X Server 1.4.0 Release Date: 5 September 2007 X Protocol Version 11, Revision 0 Build Operating System: Linux Debian (xorg-server 2:1.4.1~git20071119-1) Current Operating System: Linux hippy 2.6.24-rc3-hippy #1 SMP Sat Nov 24 22:39:00 NZDT 2007 i686 Build Date: 20 November 2007 01:48:55AM Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/Xorg.0.log, Time: Tue Nov 27 07:14:47 2007 (==) Using config file: /etc/X11/xorg.conf (==) ServerLayout Default Layout (**) |--Screen Default Screen (0) (**) | |--Monitor Configured Monitor (==) No device specified for screen Default Screen. Using the first device section listed. (**) | |--Device Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (**) |--Input Device Generic Keyboard (**) |--Input Device Configured Mouse (**) |--Input Device Synaptics Touchpad (==) Automatically adding devices (==) Automatically enabling devices (==) No FontPath specified. Using compiled-in default. (WW) The directory /usr/share/fonts/X11/cyrillic does not exist. Entry deleted from font path. (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType (==) RgbPath set to /etc/X11/rgb (==) ModulePath set to /usr/lib/xorg/modules (II) Open ACPI successful (/var/run/acpid.socket) (II) Loader magic: 0x81d7500 (II) Module ABI versions: X.Org ANSI C Emulation: 0.3 X.Org Video Driver: 2.0 X.Org XInput driver : 2.0 X.Org Server Extension : 0.3 X.Org Font Renderer : 0.5 (II) Loader running on linux (II) LoadModule: pcidata (II) Loading /usr/lib/xorg/modules//libpcidata.so (II) Module pcidata: vendor=X.Org Foundation compiled for 1.4.0, module version = 1.0.0 ABI class: X.Org Video Driver, version 2.0 (--) using VT number 7 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 8086,27a0 card 103c,30aa rev 03 class 06,00,00 hdr 00 (II) PCI: 00:02:0: chip 8086,27a2 card 103c,30aa rev 03 class 03,00,00 hdr 80 (II) PCI: 00:02:1: chip 8086,27a6 card 103c,30aa rev 03 class 03,80,00 hdr 80 (II) PCI: 00:1b:0: chip 8086,27d8 card 103c,30aa rev 01 class 04,03,00 hdr 00 (II) PCI: 00:1c:0: chip 8086,27d0 card , rev 01 class 06,04,00 hdr 81 (II) PCI: 00:1d:0: chip 8086,27c8 card 103c,30aa rev 01 class 0c,03,00 hdr 80 (II) PCI: 00:1d:1: chip 8086,27c9 card 103c,30aa rev 01 class 0c,03,00 hdr 00 (II) PCI: 00:1d:2: chip 8086,27ca card 103c,30aa rev 01 class 0c,03,00 hdr 00 (II) PCI: 00:1d:3: chip 8086,27cb card 103c,30aa rev 01 class 0c,03,00 hdr 00 (II) PCI: 00:1d:7: chip 8086,27cc card 103c,30aa rev 01 class 0c,03,20 hdr 00 (II) PCI: 00:1e:0: chip 8086,2448 card , rev e1 class 06,04,01 hdr 01 (II) PCI: 00:1f:0: chip 8086,27b9 card 103c,30aa rev 01 class 06,01,00 hdr 80 (II) PCI: 00:1f:1: chip 8086,27df card 103c,30aa rev 01 class 01,01,8a hdr 00 (II) PCI: 00:1f:2: chip 8086,27c5 card 103c,30aa rev 01 class 01,06,01 hdr 00 (II) PCI: 02:06:0: chip 104c,8039 card 1400, rev 00 class 06,07,00 hdr 82 (II) PCI: 02:06:2: chip 104c,803b card 103c,30aa rev 00 class 01,80,00 hdr 80 (II) PCI: 02:06:3: chip 104c,803c card 103c,30aa rev 00 class 08,05,00 hdr 80 (II) PCI: 02:06:4: chip 104c,803d card 103c,30aa rev 00 class 07,80,00 hdr 80 (II) PCI: 02:0e:0: chip 14e4,169c card 103c,30aa rev 03 class 02,00,00 hdr 00 (II) PCI: 08:00:0: chip 8086,4222 card 103c,135d rev 02 class 02,80,00 hdr 00 (II) PCI: End of PCI scan (II) Intel Bridge workaround enabled (II) Host-to-PCI bridge: (II) Bus 0: bridge is at (0:0:0), (0,0,8), BCTRL: 0x0008 (VGA_EN
Bug#452357: xserver-xorg-video-intel: 945GM always crashes within 10 seconds of login
Package: xserver-xorg-video-intel Version: 2:2.1.1-4 Severity: important Note that the version above is given because I have had to downgrade this package to have a usable system. The problems are with version 2.2.0-1, which crashes about 10 seconds after I log in. To recover I am forced to downgrade the driver to 2.1.1-4 *and* to reboot the system. The logs that I have of the crash are, I think of the subsequent failures to start the X server after the original crash, rather than the crash itself. If it would be helpful I can try and get one of just the first crash and attach it. Thanks, Andrew McMillan. -- Package-specific info: /var/lib/x11/X.roster does not exist. /var/lib/x11/X.md5sum does not exist. X server symlink status: lrwxrwxrwx 1 root root 13 2007-09-04 07:26 /etc/X11/X - /usr/bin/Xorg -rwxr-xr-x 1 root root 1672732 2007-11-20 13:03 /usr/bin/Xorg Contents of /var/lib/x11/xorg.conf.roster: xserver-xorg VGA-compatible devices on PCI bus: 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) /etc/X11/xorg.conf does not match checksum in /var/lib/x11/xorg.conf.md5sum. Xorg X server configuration file status: -rw-r--r-- 1 root root 2202 2007-11-12 11:27 /etc/X11/xorg.conf Contents of /etc/X11/xorg.conf: # (xorg X Window System server configuration file) # # This file was generated by dexconf, the Debian X Configuration tool, using # values from the debconf database. # # Edit this file with caution, and see the manual page. # (Type man at the shell prompt.) # # This file is automatically updated on package upgrades *only* # if it has not been modified since the last upgrade of the # package. # # If you have edited this file but would like it to be automatically updated # again, run the following command: # sudo dpkg-reconfigure -phigh Section InputDevice Identifier Generic Keyboard Driver kbd Option CoreKeyboard Option XkbRules xorg Option XkbModel pc104 Option XkbLayout us Option XkbOptionsctrl:nocaps,altwin:meta_win EndSection Section InputDevice Identifier Configured Mouse Driver mouse Option Emulate3Buttons true Option CorePointer Option Device/dev/input/mice Option Protocol ImPS/2 EndSection Section InputDevice Identifier Synaptics Touchpad Driver synaptics Option SendCoreEventstrue Option Device/dev/psaux Option Protocol auto-dev # Option HorizScrollDelta 0 Option SHMConfig true EndSection Section Device Identifier Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller Driver intel BusID PCI:0:2:0 Option UseFBDev true EndSection Section Monitor Identifier Configured Monitor Option DPMS DisplaySize 304 228 EndSection Section Screen Identifier Default Screen Monitor Configured Monitor DefaultDepth24 SubSection Display Modes 1400x1050 Virtual 2880 2048 EndSubSection EndSection Section ServerLayout Identifier Default Layout Screen Default Screen InputDevice Generic Keyboard InputDevice Configured Mouse InputDevice Synaptics Touchpad EndSection Xorg X server log files on system: -rw-r--r-- 1 root root 72181 2007-08-30 20:31 /var/log/Xorg.1.log -rw-r--r-- 1 root root 36439 2007-10-23 18:05 /var/log/Xorg.20.log -rw-r--r-- 1 root root 33508 2007-11-22 17:49 /var/log/Xorg.0.log Contents of most recent Xorg X server log file /var/log/Xorg.0.log: X.Org X Server 1.4.0 Release Date: 5 September 2007 X Protocol Version 11, Revision 0 Build Operating System: Linux Debian (xorg-server 2:1.4.1~git20071119-1) Current Operating System: Linux hippy 2.6.24-rc2-hippy #1 SMP Wed Nov 14 21:48:02 NZDT 2007 i686 Build Date: 20 November 2007 01:48:55AM Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/Xorg.0.log, Time: Thu Nov 22 17:03:44 2007 (==) Using config file: /etc/X11/xorg.conf (==) ServerLayout Default Layout (**) |--Screen Default Screen (0) (**) | |--Monitor Configured Monitor (==) No device specified for screen Default Screen. Using
Bug#449059: whereami.pl missing from whereami
Hi Cord, I had thought that whereami.pl was removed from whereami a while ago, but perhaps not. Does it all work again if you delete that symlink and reinstall the package? The symlink shouldn't be there any longer. I've renamed the actual program to /usr/sbin/whereami instead. Regards Andrew McMillan. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#443547: libpoppler1: Problems rendering Porirua City overview map
Package: libpoppler1 Version: 0.5.4-6.1 Severity: normal The overview map for Porirua City Council takes over 90 seconds to render in Evince on my Core 2 Duo 2GHz laptop with 2G RAM, which is not swapping at the time. This seems beyond excessive for a single page PDF. The timing was taken on the third run, so almost all disk access should have been in cache. In addition to the rendering performance, the overlay of URL positions for the sub-maps linked from this map is rotated 90 degrees anti-clockwise, so as you mouseover random places in the map you will see links to things that should be 90 degrees clockwise from the position where they are being presented. The overall.pdf map is available from this URL: http://gis.pcc.govt.nz/encounter/street_maps/overall.pdf For comparison, on the same computer, Acrobat Reader takes less than 5 seconds, on the first run after a clean install. Including the time it took me to notice and click 'Accept' on the license agreement dialog. The various sub-map links are also overlaid in the correct positions. Thanks, Andrew McMillan. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (990, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.23-rc7-hippy (SMP w/2 CPU cores) Locale: LANG=en_NZ.UTF-8, LC_CTYPE=POSIX (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages libpoppler1 depends on: ii libc6 2.6.1-5 GNU C Library: Shared libraries ii libcairo2 1.4.10-1 The Cairo 2D vector graphics libra ii libfontconfig1 2.4.2-1.2generic font configuration library ii libfreetype62.3.5-1+b1 FreeType 2 font engine, shared lib ii libgcc1 1:4.2.1-5GCC support library ii libjpeg62 6b-14The Independent JPEG Group's JPEG ii libstdc++6 4.2.1-5 The GNU Standard C++ Library v3 ii zlib1g 1:1.2.3.3.dfsg-5 compression library - runtime libpoppler1 recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#443137: libpano12: New upstream version(s)
Package: libpano12 Version: 2.8.3-1 Severity: wishlist I note that there is a new upstream version of libpano12 (2.8.6) as well as an even more advanced release which is libpano13 version 2.9.12. It would be really nice to get these into Debian, along with the latest version of Hugin. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (990, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.22.1-hippy (SMP w/2 CPU cores) Locale: LANG=en_NZ.UTF-8, LC_CTYPE=POSIX (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#440143: network-manager: No applet = package is unusable
Package: network-manager Version: 0.6.5-1 Severity: grave Justification: renders package unusable I have recently upgraded to network-manager 0.6.5-1 and can no longer access any of my wireless networks. The package control file says Replaces: network-manager-gnome which appears to be a complete falsehood! There is no nm-applet in there at all, which the changelog also states. Unfortunately there is also no nm-applet anywhere else, as far as I can see. Even worse, I can't find any Debian source to build one from. In the interim I have reconstructed the network-manager-gnome 0.6.4-8 package in order to tell it that it's OK to install alongside network-manager (= 0.6.4) and have rebuild network-manager from source to tell it that it *does not* provide network-manager-gnome. Surprisingly, this approach works, and I can once more connect to my wireless networks. This suggests that one reasonable fix would be to release a new network-manager-gnome 0.6.4-9 (or so) which claims to work with network-manager (= 0.6.4-8) and a new network-manager co which doesn't make false claims about providing / conflicting with that. It seems fairly precipitate to have released this package into Sid without having a corresponding network-manager-gnome package to go with it, since the package is effectively useless without the UI required to prompt me for my keyring password. Regards, Andrew McMillan -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (990, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.22.1-hippy (SMP w/2 CPU cores) Locale: LANG=en_NZ.UTF-8, LC_CTYPE=POSIX (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages network-manager depends on: ii adduser 3.104add and remove users and groups ii dbus1.1.1-3 simple interprocess messaging syst ii dhcdbd 3.0-1D-Bus interface to the ISC DHCP cl ii hal 0.5.9.1-4Hardware Abstraction Layer ii ifupdown0.6.8high level tools to configure netw ii iproute 20070313-1 Professional tools to control the ii iputils-arping 3:20070202-2 Tool to send ICMP echo requests to ii libc6 2.6.1-1+v6 GNU C Library: Shared libraries ii libdbus-1-3 1.1.1-3 simple interprocess messaging syst ii libdbus-glib-1-20.74-1 simple interprocess messaging syst ii libgcrypt11 1.2.4-2 LGPL Crypto library - runtime libr ii libglib2.0-02.14.0-2 The GLib library of C routines ii libgpg-error0 1.4-2library for common error values an ii libhal1 0.5.9.1-4Hardware Abstraction Layer - share ii libiw29 29~pre22-1 Wireless tools - library ii libnl1-pre6 1.0~pre6-5 Library for dealing with netlink s ii libnm-util0 0.6.5-1 network management framework (shar ii lsb-base3.1-24 Linux Standard Base 3.1 init scrip ii wpasupplicant 0.6.0-3 Client support for WPA and WPA2 (I Versions of packages network-manager recommends: ii network-manager-gnome 0.6.4-8+b1awm1 network management framework (GNOM -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#440143: [Pkg-utopia-maintainers] Bug#440143: network-manager: No GNOME applet (yet)
On Thu, 2007-08-30 at 14:10 +0200, Michael Biebl wrote: As Cyril explained it already very accurately, the correct way (for users using network-manager-gnome) is simply to not force the upgrade until network-manager-applet has left NEW. The old 0.6.4 packages will then automatically be kept on hold. The default of apt-get and aptitude is, to not remove packages on upgrade (unless you do a dist-upgrade resp. full-upgrade). For the future, simply use apt-get upgrade or aptitude safe-upgrade. Otherwise you will hit the same problem on library transitions etc. That's all very fine, but it's fairly complicated to read the changelog in advance of installing the new version. When a new package comes along which says it Replaces an old package, and the old package is no longer available in the archive, then it is also quite easy to make the (mistaken in *this* case) assumption that the old package is no longer needed, and follow through the upgrade and removal. The package which truly replaces network-manager-gnome is network-manager-applet, not network-manager at all. In any case, I now understand what has happened and have a personal workaround until the applet package becomes visible somewhere so I can upgrade to it. There is also a visible bug report for others to follow if they find themselves in the same situation. Cheers, Amdrew McMillan. - Andrew @ Catalyst .Net .NZ Ltd, PO Box 11-053, Manners St, Wellington WEB: http://catalyst.net.nz/PHYS: Level 2, 150-154 Willis St DDI: +64(4)803-2201 MOB: +64(272)DEBIAN OFFICE: +64(4)499-2267 Necessity is the mother of documentation - signature.asc Description: This is a digitally signed message part
Bug#439908: singularity: Broken on upgrade
Package: singularity Version: 0.26a-1 Severity: grave Justification: renders package unusable When I upgraded to the new version of singularity just now, I can no longer run the program. Error output is included below: == [EMAIL PROTECTED]:~$ singularity open /dev/sequencer: No such file or directory Traceback (most recent call last): File singularity.py, line 146, in ? g.load_music() File /usr/share/games/singularity/code/g.py, line 146, in load_music makedirs(musicpath) File /usr/lib/python2.4/os.py, line 159, in makedirs mkdir(name, mode) OSError: [Errno 13] Permission denied: '../data/../music' == I am, of course, running the program as a normal user. Note that it has always said open /dev/sequencer: No such file or directory so that is not the problem. I'm not sure what is supposed to create a /dev/sequencer link and where it is supposed to point - possibly at /dev/snd/seq. Thanks, Andrew McMillan -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (690, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.22.1-hippy (SMP w/2 CPU cores) Locale: LANG=en_NZ.UTF-8, LC_CTYPE=POSIX (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages singularity depends on: ii python 2.4.4-6 An interactive high-level object-o ii python-pygame1.7.1release-4.1+b1 SDL bindings for games development ii python-support 0.6.4 automated rebuilding support for p ii ttf-bitstream-vera 1.10-7 The Bitstream Vera family of free Versions of packages singularity recommends: pn singularity-music none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
