Proposed new requirements for emacsen add-on packages
Recently I've been fixing some non-trivial problems I introduced in emacsen-common 2.0.0 -- and to finish fixing them it looks like it may be best to change (and augment) some of the add-on package requirements. Originally, I'd really tried to make it so that as of emacsen-common 2.*, add-on packages didn't have to depend on *anything*, but that's proving difficult to unworkable, so I'm leaning toward adding a requirement that add-on packages depend on "emacsen-common >= 2.0.8". If it helps, emacsen-common is only about 140k installed. Here's what I have so far from the hypothetical 2.0.8 changelog: Require add-on packages to depend on emacsen-common >= 2.0.8. This should be simpler and safer, and emacsen-common is only ~140k, which shouldn't be too big a burden. One specific problem this solves is the handling of /var/lib/emacsen-common -- in particular /var/lib/emacsen-common/state/package/installed/* if/when emacsen-common is purged. Without the dependency, emacsen-common can't remove the tree without clobbering the state for every add-on, but if emacsen-common can't remove it, who can? It seems better to add this requirement for now (which should also simplify the emacsen infrastructure in general), than to have every add-on try to decide when it's safe to remove /var/lib/emacsen-common/state/package (i.e. when they're the last add-on being removed from the system). This release changes the following requirements for add-on packages (see debian-emacs-policy for the details): - They must now depend on emacsen-common >= 2.0.8. - They don't need to conflict with emacsen-common anymore. - They don't need to guard their calls to emacs-install-package. - They don't need to guard their calls to emacs-remove-package. - They should no longer manage their package/installed/ file directly. In addition emacsen flavor packages should now depend on emacsen-common >= 2.0.8. Thoughts? Strong objections? (And for whatever it's worth, I've been posting some relevant bits to debian-emac...@lists.debian.org lately, but I imagined that many/most of you aren't subscribed.) Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 -- 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/87d2jnwhuh@trouble.defaultvalue.org
Re: Proposed new requirements for emacsen add-on packages
[Apologies for any duplication: resending because the previous cc list had been truncated.] Modestas Vainius writes: > I suggest that you bump policy version to 3 since current policy is probably > going to be nothing like v2. We could, though I hadn't been planning on it since these changes only fix the current policy to work as I'd originally intended (i.e. correctly). I think the 2.* policy before these changes is likely just broken. Along those same lines, I wasn't planning to change the compat version requirement (i.e. from 0 to 1) because at the moment, I haven't thought of any way that would help us -- i.e. I can't think of any decisions that emacsen-common could make that would help, based on that number. > However, it's really unfortunate that emacsen-common dependency is needed > again. I know nothing about emacsen-common internals but it's kind of weird > that the problem cannot be solved with dpkg triggers. 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.*. The problem I have with triggers to date is that I haven't yet been able to convince myself that they're flexible enough to handle all of our (potential) cases. For example, with triggers, can we arrange it so that every add-on (or flavor) gets a chance to "remove" itself while still fully configured? And if not, do we think that we can change policy in a way that will still accommodate the needs of all add-ons (i.e. would some kind of generic removal be sufficient in all cases)? Another question -- assuming triggers run "later", can all all-on packages be adjusted to behave "sanely enough" in the window between when they're postinst fires, and when the triggers eventually run? > In my cmake case, the package just ships syntax highlighting for emacs > and some users have complained about cmake pulling in anything emacs > related just because of this. Understood -- one of the main points of 2.* was to remove the dependencies, but it looks like that just may not be workable with the current strategy (though I'd be happy to figure out I'm wrong). That said, an emacsen-common dependency should still be much better than what we required before, since emacsen-common is vastly smaller than any of the flavors. Ideally, the dependency requirement, assuming we decide that it's necessary, will turn out to be a temporary addition -- until we figure out how to remove it again (perhaps with triggers, or some other approach). But in the very short term, I'm just hoping to unbreak 2.*. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 -- 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/8738kfzz0y@trouble.defaultvalue.org
Bug#746012: graphviz: please migrate to guile-2.0
Package: graphviz I'm planning to have guile-1.8 removed from unstable before the freeze; please migrate to guile-2.0 as soon as possible. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140426231006.eb5c614e...@trouble.defaultvalue.org
Bug#746000: gnurobots: please migrate to guile-2.0
Package: gnurobots I'm planning to have guile-1.8 removed from unstable before the freeze; please migrate to guile-2.0 as soon as possible. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140426225126.9daf214e...@trouble.defaultvalue.org
Bug#746012: closed by Matthias Klose (Bug#746012: fixed in graphviz 2.38.0-1)
reopen 746012 thanks Debian Bug Tracking System writes: > This is an automatic notification regarding your Bug report > which was filed against the graphviz package: > > #746012: graphviz: please migrate to guile-2.0 > > It has been closed by Matthias Klose . It looks like there's one more vestigial bit, i.e. the libltdl-dev dependency in the control file. That's from guile-1.8, not 2.0, and should no longer be necessary. # Broken Build-Depends: ... graphviz: guile-1.8-dev ... Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87tx3mmckm@trouble.defaultvalue.org
Bug#746012: closed by Matthias Klose (Bug#746012: fixed in graphviz 2.38.0-1)
Matthias Klose writes: > this is hardly release critical. Please set severities correctly when > reopening > issues. Actually, I was explicitly told to raise all the guile-2.0 migration bugs to be RC as we approched the freeze, since guile-1.8 really shouldn't be in jessie. (Though it may turn out that we have to keep guile-1.8, and so I'd lower them back down. As I mentioned I was planning to have that discussion and make that decision in about a week.) Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/877g0byj0u@trouble.defaultvalue.org
Bug#746012: closed by Matthias Klose (Bug#746012: fixed in graphviz 2.38.0-1)
Matthias Klose writes: > so what exactly is release critical in the current package? A long while back I wanted to remove 1.8 from jessie, so I was told to first file bugs, then file an RM/ROM, and then, after a while, upgrade any remaining bugs to serious. The reason I want to remove 1.8 is that it's been unmaintained upstream since about 2010, and we'd be substantially better off if we didn't carry it for another couple of years -- but we (I) can and will carry it if we have to. (I'll be happy enough that we we've finally been able to drop 1.6.) In any case I've been keeping track of the status of various significant rdepends (and talking to the maintainers) in order to keep track of where we stand. Right now it looks like I'll probably be downgrading all the bugs next week, and letting 1.8 go for another release. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87zjd7x23x@trouble.defaultvalue.org
Bug#746012: closed by Matthias Klose (Bug#746012: fixed in graphviz 2.38.0-1)
Matthias Klose writes: > no, 1.8 shouldn't be shipped in jessie (I removed 1.8 from Ubuntu some months > before). I think you take the wrong approach. I think a lot of bug reports, > including this one, are handled wrong. I'm asking you why you think this > issue > prevents removal of 1.8? You didn't explain that. Oh, it doesn't necessarily. That's something I was planning for us to decide in a week or so (i.e. do we remove 1.8, or all the remaining rdepends). -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87wq8bwzhy@trouble.defaultvalue.org
Bug#745989: Bug#760986: RM: guile-1.8 -- ROM; replaced by guile-2.0
Luca Falavigna writes: > These are the reverse dependencies to be fixed before removing this > package: Right -- I was hoping to try to reach a decision this week with respect to jessie. Here's what I hope is a reasonably accurate summary of the situation. As a general comment, people on #guile (including one of the upstream Guile maintainers) have said that at this point, they would prefer that we remove packages from jessie that support Guile 2.0 upstream, but still depend on 1.8 in Debian (though we might or might not keep them in unstable). This was mentioned in particular, with respect to g-wrap, guile-cairo, and guile-gnome-platform. As an overall summary: - There are a few packages that we might want to remove from jessie for now (but they're likely to return later if/when they have an active maintainer -- guile-cairo, etc.[1]). - There's at least one package that has an active maintainer, and is actively being ported upstream, but that probably won't be ready for jessie (lilypond). - There are a number of packages that are more or less unmaintained, or may otherwise be unsuitable for continued inclusion in Debian. - Guile 1.8 is no longer maintained upstream, and hasn't been since 2010. [1] Though apparently g-wrap, guile-cairo, and guile-gnome-platform may be easy to NMU for 2.0 -- if I get enough time *immediately*, I might try to help there. Anyone else interested should talk to Mark (cc'ed above). In the end, the question is whether or not, on balance, we're better off with or without guile-1.8 in jessie. > anubis No response wrt 2.0: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=745989 Last non-NMU: 2009-09 > beast No response wrt 2.0: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=745991 Last non-NMU: 2013-02 > drgeo Some response from the maintainer in May, but nothing since: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=707903 Last non-NMU appears to be 2012-05 I've also been told that drgeo no longer uses Guile upstream. > freetalk No response wrt 2.0: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=745997 Last non-NMU: 2012-06 > g-wrap [1] Only response wrt 2.0 is a mention of an upload that's been in experimental for two years, but no response from the maintainer: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761210 Last non-experimental upload: 2012-05 > guile-cairo [1] Looks like this may just be waiting on a testing transition, which may have been blocked by a (now fixed) problem with guile-2.0 on arm*. If so, it should just need a rebuild on arm*. Though #guile warned that this NMU may or may not play nice with the current guile-gnome-platform (below), depending on exactly how the NMU was handled, > guile-gnome-platform [1] No response wrt 2.0: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761211 Last non-NMU: 2012-06 > gwave This may be dependent on the guile-cairo update. > lilypond Upgrade to 2.0 won't be ready upstream in time for jessie, so removing guile-1.8 would imply removing lilypond. > texmacs Last information was that upstream doesn't support 2.0 yet https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731787 but texmacs may also not be currently suitable for Debian for other reasons? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=711383 > trackballs No response wrt 2.0: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746011 Last non-NMU: 2007-12 > swig2.0 I'm probably just missing something obvious, but I'm not sure why this is still listed -- 2.0.12-1 appears to be in testing, and it is supposed to have migrated to guile-2.0. Looking in the control file I also don't see any obvious guile-1.8 deps... > graphviz Hmm, "dak ... -s testing -Rn guile-1.8" doesn't list it, but maybe "-s testing" isn't working right? In any case, I imagine it's the swig dep above. > guile-1.8-non-dfsg/non-free Should be removed iff guile-1.8 is. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87y4skhecf@trouble.defaultvalue.org
Re: Processed: Re: RM: emacs23 -- ROM; replaced by emacs24
It looks like this might be possible now. $ ssh mirror.ftp-master.debian.org dak rm -Rn emacs23 Will remove the following packages from unstable: emacs23 | 23.4+1-4.1 | source emacs23 | 23.4+1-4.1+b1 | amd64, armel, armhf, i386, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390x, sparc emacs23-bin-common | 23.4+1-4.1+b1 | amd64, armel, armhf, i386, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390x, sparc emacs23-common | 23.4+1-4.1 | all emacs23-el | 23.4+1-4.1 | all emacs23-lucid | 23.4+1-4.1+b1 | amd64, armel, armhf, i386, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390x, sparc emacs23-nox | 23.4+1-4.1+b1 | amd64, armel, armhf, i386, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390x, sparc Maintainer: Rob Browning --- Reason --- -- Checking reverse dependencies... No dependency problem found. Thanks to everyone for the help. -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87lho9mqn1@trouble.defaultvalue.org
Bug#885194: gnubik: please migrate to guile-2.2
Source: gnubik Severity: normal I'd like to remove guile-2.0 before the buster release, so please migrate to guile-2.2 when you can. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#885206: guile-gnome-platform: please migrate to guile-2.2
Source: guile-gnome-platform Severity: normal I'd like to remove guile-2.0 before the buster release, so please migrate to guile-2.2 when you can. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Transitioning to guile 1.6
Howdy. If you're receiving this mail, it's because from an initial glance at "apt-get rdepends libguile9", it looked like your packages might be affected by removing guile1.4 from unstable (and eventually testing), and that's something I've been thinking about lately. In some cases, like Mikael and goops, I suspect the only action needed would be to remove goops from Debian too (since guile-1.6 supercedes it). In other cases, the packages may just need a re-build and adjustment of their depdends, but of course that's hard to tell for sure since there could still be scheme level incompatibilities. Anyway, I just wanted to check and see what you thought about the possibility of migration. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
