Re: Proposed new requirements for emacsen add-on packages
On Wed, Jan 22, 2014 at 12:39:27PM -0600, Rob Browning wrote: > Agustin Martin writes: > > > Did not test in depth, but I think the add-on state files state files > > could be recreated from /usr/lib/emacsen-common/packages/install in > > case emacsen-common is installed for the first time (i.e., not > > upgraded). Since emacs flavours depend on emacsen-common they should > > byte compile things when configured. > > I may be misunderstanding, but if not, I think the problem there is > simultaneous installs (which are our primary complication in general), > > i.e. most of the complexity we have comes from the fact that we're > operating outside dpkg's dependency system (to avoid add-on deps), and > so we have no ordering guarantees. > > That's why I added the state/package/installed infrastructure, but I'm > beginning to think that this approach may just be insufficient. The > original idea was that the state files would allow add-ons to signal > that they're "ready to go" with respect to emacsen-common install/remove > calls. > > For example, consider the case where no emacsen-related packages are > installed and someone runs this: > > apt-get install emacs24 add-on-1 > > Because there are no relevant dpkg deps, the packages' maintainer > scripts can fire in any relative order, and if emacs24's postinst fires > before add-on-1's, it can know to skip installing add-on-1 because > package/installed/add-on-1 doesn't exist. But emacs24 *will* create > flavor/installed/emacs24, so that when add-on-1's postinst fires, its > install script will be run for emacs24. Of course, something reasonable > should also happen if the order is reversed. > > However, to demonstrate why I'm beginning to think the current approach > may be unworkable, consider the case where no emacsen-related packages > are installed and someone runs this: > > apt-get install emacs24 add-on-depending-on-add-on-1 add-on-1 Hi, I may be wrong, but if add-on-depending-on-add-on-1 depends on add-on-1 dpkg should care of configuring add-on-1 first. However, there is no warranty about unpack ordering. > I begin to suspect that up to now, we may have just been fairly lucky, > and that the current approach is may just be broken for any number of > cases like this. And unfortunately, adding the emacsen-common > dependency won't help. > > Another reason why I keep wondering about the possibility of using > triggers is that even if we addressed some of the above issues, the > current approach will still probably result in redundant installs from > time to time. Even if you want to be conservative and expect to > reinstall an add-on whenever it's upgraded, or any flavor is upgraded, > consider the previous example, but assume that all of the packages are > already installed (just being upgraded): > > apt-get install emacs24 add-on-depending-on-add-on-1 add-on-1 > > Currently, the emacs24 postinst will install both of the add-ons, and > then each add-on will install itself, and add-on-depending-on-add-on-1 > will also reinstall add-on-1 again. With a triggers-based approach > you'd hope that we could coordinate better, and only run each install > once. Some add-ons do a check to avoid that, check that .elc for last byte-compiled file is present. If so, it is already done, otherwise byte-compile. But is way better if is emacsen-common who cares about that. > So, generally speaking, unless we come up with alternatives, I'm > beginning to wonder if triggers may be our best option, assuming we can > shoehorn all add-ons into accommodating the attendant restrictions > (whatever they end up being). I think you are right, they may be the best option, but some ellaboration is needed to properly evaluate that possibility, before going further into it. In a quick proposal, I'd think about emacs-install and emacs-package-install just touching action flags like $flavour___$package when run under dpkg control and not triggered and also enable the common emacsen-common trigger. If run from the command line or from dpkg-reconfigure (that is, not under dpkg control) they should do their usual current work and remove/update flags as needed in success. When the trigger is run, some script runs emacs-package-install as --triggered, old .elc files removed, byte-compilation done after flags and flag removed on success. I wrote some code to deal with aspell and ispell dictionaries automatic hash rebuild from dictionaries-common triggers that may be useful here (perl is also used). > I'm not sure if I already mentioned it here, but I'm not opposed to > triggers. Though if we made a change that substantial, we probably > *would* want to move to emacsen-common 3.*. In package version yes, but there is no need to change compatibility level unless maintainers need to do something in their packages to accomodate for the new system. > The problem I have with triggers to date is that I haven't yet been able > to convince myself that they're flexi
Bug#689997: iconv: illegal input sequence at position 86 ERROR: Conversion of /usr/share/hunspell/hu_HU_u8.aff failed
tags upstream 689997 thanks Hi Daniel, On 10/08/2012 11:01 PM, Daniel Kahn Gillmor wrote: > Package: myspell-hu > Version: 1.2+repack-2 > Severity: normal > Control: affects -1 postgresql-common > > Hi myspell-hu maintainer! > > it seems that there is non-u8 data in /usr/share/hunspell/hu_HU_u8.aff > -- it causes an error message to be emitted in pg_updatedicts when it is > converted to the postgres form (see transcript below). > > It appears to be due (at least) to ISO-8859-1 characters in the > comments in an otherwise-UTF-8 file: Thank you for the report, it will be fixed in next upstream release. Cheers, Balint signature.asc Description: OpenPGP digital signature
Le gouvernement ukrainien promet d’amender les lois anti-manifestations
Se désinscrire de la liste: http://link.email.wib.me/u/443/f0276804584f2380b5a80a0092bed0ae9d56c23d08fd92d3
Bug#568322: marked as done (magyarispell: please package new upstream version (1.5))
Your message dated Fri, 24 Jan 2014 17:49:11 + with message-id and subject line Bug#568322: fixed in magyarispell 1.6.1-1 has caused the Debian Bug report #568322, regarding magyarispell: please package new upstream version (1.5) to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 568322: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=568322 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: magyarispell Version: 0.99.4-1.2 Severity: wishlist Please package the new upstream version 1.5. Note that upstream has moved to a new location: http://magyarispell.sourceforge.net/ Thanks, Chris Cheney --- End Message --- --- Begin Message --- Source: magyarispell Source-Version: 1.6.1-1 We believe that the bug you reported is fixed in the latest version of magyarispell, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 568...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Balint Reczey (supplier of updated magyarispell package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Fri, 24 Jan 2014 00:52:19 +0100 Source: magyarispell Binary: ihungarian myspell-hu Architecture: source all amd64 Version: 1.6.1-1 Distribution: unstable Urgency: low Maintainer: Balint Reczey Changed-By: Balint Reczey Description: ihungarian - Hungarian dictionary for ispell myspell-hu - Hungarian dictionary for myspell Closes: 568322 568328 Changes: magyarispell (1.6.1-1) unstable; urgency=low . * New upstream release (Closes: #568322) * Adopt the package (Closes: #568328) Checksums-Sha1: 0106c69fbc805aca0517659a4dc2b9a829ff4644 1993 magyarispell_1.6.1-1.dsc 63923a4dec026189dc97093bac7f853049a0c83d 783712 magyarispell_1.6.1.orig.tar.xz 8072daa4953589b830f14a8d2d90067b0b81 13612 magyarispell_1.6.1-1.debian.tar.xz fc5114064a3f2539751635369d0d32e58e22594d 168646 myspell-hu_1.6.1-1_all.deb 57cddfd17db0aa98c044b23aa0515d3d9f817c9f 843382 ihungarian_1.6.1-1_amd64.deb Checksums-Sha256: 91494d20d8400089272b91cb68ed2e3785db35b002597e7c73ec6aa4cdd4caad 1993 magyarispell_1.6.1-1.dsc 4949176492f98664df0f46247c3eb4493dbacb0c45ee74581ede3be488042429 783712 magyarispell_1.6.1.orig.tar.xz 50a3eda768d718033ba453741ecb9adcf783e6bbf0a7b263a0a13b3a27a9cc50 13612 magyarispell_1.6.1-1.debian.tar.xz 6d53e38ec7345b809aac83e845bd993a5ec7458ae8f1f5a9113be8d72ea39ebc 168646 myspell-hu_1.6.1-1_all.deb 3b7cf75655feee55b274352476d5602322f051990844c5f31287092c0d7adcb0 843382 ihungarian_1.6.1-1_amd64.deb Files: 904a8866ec7e5c505f7b2092b058248a 1993 text optional magyarispell_1.6.1-1.dsc 57ba750711a9cf295c53d169508325c0 783712 text optional magyarispell_1.6.1.orig.tar.xz b8244093dd90982f6b7bd68360392b2d 13612 text optional magyarispell_1.6.1-1.debian.tar.xz dade113f2062be834128ac709a4deefd 168646 text optional myspell-hu_1.6.1-1_all.deb 1db7bd6b660c7f85bc7b7aa57fee9be2 843382 text optional ihungarian_1.6.1-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJS4qUsAAoJEPZk0la0aRp9HdQP/3WNWWu2ZLS+qsm5trJwzb3G IcaVp5T6I3f5cKE9+JwlzciGSork3lNZ4sR8KbO/aYaX/yznmls5GMkWrupGEf1V VvCZXMWbzwzaOWOYGlp7NkPTX/3bw7JelB9W3Js/a73Laqu98BCS2xIDG5YqLMQJ k4z58no7XnUO48OscQ4u1kSEOI6pBmkpS+jiFFx17ptp6sWk6t+y9L9DZSJ8Lywk NIq1LbxuOntRIX8BdbQw43K79zDwA8qMMcpgrDCwZic9a0RJmwPY49vqY62zFXNo 8IA7W8CQtQXXLzCRKB1+QyZi4UwQ+ym6jAcPcPYaF7K4BnXXdKT6K+0JdZWO7FdW bnC/wG/8LtNDIMPdIDNkfzvA7I8KWE4Sd0ucHuyGEMYV/dV9L2Sei1S6us52LS+U wW/fc2Pg9CbsR0sLXjwIg7T02oEDEgm9H+USGIRqAzuon6VWx8029c+19u3WC7Zh RKkPXIUnrFyrG5CHbDXjCyjKi9M7akgy1OEHB12CcMHA+dVKYcQnrCN0nG566s1v fh6zlJo/TRrrly2HH0Q9Ono5Ey/4SyvTlwvhmkWQCtcbBllw8X0iPWh/wFH63xih TuRa5rCUt/HaOeeX7laskrd5FBo+4nfbbJThkWCGjBvyMCvdIBnRe0sqWwGnyEOY 6eJ33SmgLY87ZeRSP67a =ILI8 -END PGP SIGNATURE End Message ---
Processed: .
Processing commands for cont...@bugs.debian.org: > tags 689997 upstream Bug #689997 [myspell-hu] iconv: illegal input sequence at position 86 ERROR: Conversion of /usr/share/hunspell/hu_HU_u8.aff failed Added tag(s) upstream. > thanks Stopping processing here. Please contact me if you need assistance. -- 689997: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=689997 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.139059340529850.transcr...@bugs.debian.org
Bug#736567: libdumbnet should be multiarch
Package: libdumbnet Version: 1.12-4 Severity: normal libdumbnet is not multiarch compliant, it should be -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140125002313.18112.57821.reportbug@padfoot
