Re: binNMU order of ObjC/GNUstep packages
On 08/23/2010 08:33 PM, Yavor Doganov wrote: > Mehdi Dogguy wrote: >> That said, you could also set "good" dependencies like what has >> been done for OCaml packages for instance and make them not >> installable if it doesn't match your criteria > > Interesting. Is dh-ocaml the right package to look at? If it's not > too hard, it'll be nice to implement this for GNUstep packages too > (in squeeze+1, now it's too late for surgeries). > Yes, it's dh-ocaml. If you need more details about how it works, I'll be glad to help (privately… no need to bother the list). Regards, -- Mehdi Dogguy مهدي الدڤي http://dogguy.org/ -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c72cfb0.6080...@dogguy.org
Re: binNMU order of ObjC/GNUstep packages
Mehdi Dogguy wrote: > That said, you could also set "good" dependencies like what has been > done for OCaml packages for instance and make them not installable > if it doesn't match your criteria Interesting. Is dh-ocaml the right package to look at? If it's not too hard, it'll be nice to implement this for GNUstep packages too (in squeeze+1, now it's too late for surgeries). > (which is way better than errors at runtime or hidden breakages). Undoubtedly. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87pqx9xjpe.gnus_not_unix!%ya...@gnu.org
Re: binNMU order of ObjC/GNUstep packages
On 08/23/2010 10:34 AM, Yavor Doganov wrote: > В Mon, 23 Aug 2010 07:55:44 +0200, Mehdi Dogguy написа: >> The transition monitor shows that order. If the order inferred from >> the build-dependencies is incorrect, then there is a problem in >> your packages. > > There is no problem with the build-dependencies. The only problem is > when a package gets uploaded before its dependency is binNMUed, and > we forget to rebuild it afterwards. The transition monitor does not > show such cases. > That's right. I spotted them because I've analysed the set of packages before starting binNMU'ing. That said, you could also set "good" dependencies like what has been done for OCaml packages for instance and make them not installable if it doesn't match your criteria (which is way better than errors at runtime or hidden breakages). Regards, -- Mehdi Dogguy مهدي الدڤي http://dogguy.org/ -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c72414f.3030...@dogguy.org
Re: binNMU order of ObjC/GNUstep packages
В Mon, 23 Aug 2010 07:55:44 +0200, Mehdi Dogguy написа: > The transition monitor shows that order. If the order inferred from > the build-dependencies is incorrect, then there is a problem in your > packages. There is no problem with the build-dependencies. The only problem is when a package gets uploaded before its dependency is binNMUed, and we forget to rebuild it afterwards. The transition monitor does not show such cases. > The last one is the only one "affected". I'll schedule the necessary > binNMU request. Thanks. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/i4tbr0$pc...@dough.gmane.org
Re: binNMU order of ObjC/GNUstep packages
On 08/23/2010 12:34 AM, Yavor Doganov wrote: > [CCing -release because this is a FAQ during GNUstep transitions; > hope you don't mind.] If you want… > > [...] > I usually schedule binNMUs according to a topological order computed from build-dependencies informations. The transition monitor shows that order. If the order inferred from the build-dependencies is incorrect, then there is a problem in your packages. Now, from all involved packages, there are a few that I hadn't binNMUed: adun.app, gnustep-back and talksoup.app. The first two compiled with new versions and there is no need to re-schedule them. The last one is the only one "affected". I'll schedule the necessary binNMU request. Regards, -- Mehdi Dogguy مهدي الدڤي http://dogguy.org/ -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c720d60.3020...@dogguy.org
binNMU order of ObjC/GNUstep packages
[CCing -release because this is a FAQ during GNUstep transitions; hope
you don't mind.]
Mehdi Dogguy wrote:
> On 08/21/2010 05:28 PM, Yavor Doganov wrote:
> > BTW, talksoup.app must be binNMUed on all archs once a binNMUed
> > gnustep-netclasses is available everywhere.
>
> I'll schedule the necessary binNMUs. I saw it green on my monitor
> because it depends on new gnustep libs, but has been compiled with
> pre-binNMU gnustep-netclasses. I didn't really test… but is the version
> currently in the archive broken? (can be tested on amd64 and i386).
AFAICT it works, but usually these breakages are discovered
post-factum.
The reason why we insist all apps depending on additional ObjC
libraries to be rebuilt against the *binNMUed* lib is because of the
way ObjC subclassing works.
/* Pseudo code. */
/* Public class in gnustep-netclasses. */
@interface IRC : NSString
{
@private
int _net_ivar;
}
@end
/* Class in the application. */
@interface TalkSoup : IRC
{
NSString *soup_ivar;
}
- (void) setNick: (NSString *) nick
@end
Now, consider that NSString in gnustep-base/1.19.3 has 2 ivars, but
the ivar layout is changed in 1.20.x, adding another one (which is not
unusual at all):
@interface NSString : NSObject
{
unsigned char *_ivar1;
NSUinteger _ivar2;
+ CGFloat _ivar3;
}
@end
When the app is being run, and new instances of the TalkSoup class are
created, the ObjC runtime determines the size of the class in order to
allocate it. The size of the class is the size of the ivars of the
root class NSObject (the so called "isa" pointer) plus the size of the
ivars of NSString (_ivar1, _ivar2, _ivar3), plus the size of the ivars
of the IRC class (_net_ivar), plus the size of TalkSoup's own ivars
(soup_ivar). The overall size may grow or shrink depending on the
changes in the ivar layout throughout the class hierarchy. That's the
main reason for the frequent GNUstep transitions we have in Debian;
it's very easy to break the ABI of an Objective-C library.
When the application code then invokes the -[TalkSoup setNick:] method
on the newly created instance, it attempts to assign a valid NSString
value to its soup_ivar instance variable, but it was compiled with the
assumption that the ivar layout is
{
Class isa;
unsigned char *_ivar1;
NSUinteger _ivar2;
int _net_ivar;
NSString *soup_ivar;
}
but the actual layout at runtime is
{
Class isa;
unsigned char *_ivar1;
NSUinteger _ivar2;
CGFloat _ivar3;
int _net_ivar;
NSString *soup_ivar;
}
because of NSString's newly added ivar. The assignment would
overwrite _net_ivar, leading to obvious problem at runtime (which may
be grave and apparent, or, depending on the case, not at all obvious,
but causing some other harm to the user or user's data, or simply
unnoticed bug leading to irrational program behavior under certain
circumstances -- it entirely depends on the specific case/code).
Errors like these are extremely hard to track down and analyze; they
lead to memory clobbering and allocation failures which flow down to
libc (through libobjc). Back in the dark times, before binNMUs were
possible, I remember I spent literally weeks in a debugger trying to
"fix" such a problem. When I rebuilt the app with debugging symbols
to obtain a meaningful backtrace, the issue was magically gone, so my
only sensible conclusion (completely wrong, of course) at that time
was that something was messy in the environment of the DD who uploaded
the package.
Thinking aloud, some classes are almost never subclassed. It doesn't
make sense to subclass some library classes (like renaissance), so
this particular issue is more or less rare. It's possible that
talksoup.app does not subclass any of gnustep-netclasses' classes, in
which case there is no problem. But because it is not feasible to
maintain up-to-date information for every affected app (redoing the
audit of the code at every new release), it is simpler and easier to
require rebuilds, even if they are not actually necessary in many
situations. The extra time spent by the buildds is certainly less
(and less costly) than developers' time when analyzing any eventual
problems.
This is also the reason why all non-core GNUstep libraries have
patches to link against -base and/or -gui, enabling the release team
to determine the correct dependency information (in the past, we used
to spell explicitly the order how binNMUs should be scheduled).
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87wrrixonm.gnus_not_unix!%ya...@gnu.org
Re: new upstream GNUstep packages (yet another transition)
On Wed, Mar 15, 2006 at 07:47:14PM -0700, Hubert Chan wrote: > On Wed, 15 Mar 2006 10:20:32 +0100, Christoph Berg <[EMAIL PROTECTED]> said: > > Re: Hubert Chan 2006-03-15 <[EMAIL PROTECTED]> > >> Adam released a new version of GNUstep Make and Base today that bumps > >> the soversion of -base. That means yet another GNUstep library > >> transition. argh. Hopefully this transition will go much smoother > >> than the last one (although we're still waiting on a few things in > >> NEW). > > Hrm. Can we at least try to have the current gnustep in etch before > > starting over again? > Hmm. I suppose you're right, since we're close to being there. > Can someone enlighten me as to some details about migration to testing? > e.g. If the new gnustep-gui moves to testing, that will break, for > example, the version of affiche that is in testing, and the version of > affiche that is in unstable can't move to testing until the new > gnustep-gui goes into testing. When gnustep-gui is ready to migrate to > testing, once all the other packages that depend on it are rebuilt, will > everything go in automatically, or will I need to bug someone to > override something? A hint is in place and waiting for all dependent packages to be ready since Feb. 10. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: new upstream GNUstep packages (yet another transition)
On Wed, 15 Mar 2006 10:20:32 +0100, Christoph Berg <[EMAIL PROTECTED]> said: > Re: Hubert Chan 2006-03-15 <[EMAIL PROTECTED]> >> Adam released a new version of GNUstep Make and Base today that bumps >> the soversion of -base. That means yet another GNUstep library >> transition. argh. Hopefully this transition will go much smoother >> than the last one (although we're still waiting on a few things in >> NEW). > Hrm. Can we at least try to have the current gnustep in etch before > starting over again? Hmm. I suppose you're right, since we're close to being there. Can someone enlighten me as to some details about migration to testing? e.g. If the new gnustep-gui moves to testing, that will break, for example, the version of affiche that is in testing, and the version of affiche that is in unstable can't move to testing until the new gnustep-gui goes into testing. When gnustep-gui is ready to migrate to testing, once all the other packages that depend on it are rebuilt, will everything go in automatically, or will I need to bug someone to override something? Thanks -- Hubert Chan - email & Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: new upstream GNUstep packages (yet another transition)
Re: Hubert Chan 2006-03-15 <[EMAIL PROTECTED]> > Adam released a new version of GNUstep Make and Base today that bumps > the soversion of -base. That means yet another GNUstep library > transition. argh. Hopefully this transition will go much smoother than > the last one (although we're still waiting on a few things in NEW). Hrm. Can we at least try to have the current gnustep in etch before starting over again? Christoph -- [EMAIL PROTECTED] | http://www.df7cb.de/ signature.asc Description: Digital signature
new upstream GNUstep packages (yet another transition)
Adam released a new version of GNUstep Make and Base today that bumps the soversion of -base. That means yet another GNUstep library transition. argh. Hopefully this transition will go much smoother than the last one (although we're still waiting on a few things in NEW). New packages will probably not be ready for a little while (I hope to have preliminary versions by the end of the week) and I'll wait a little while too to see if Adam also releases new versions of -gui and -back that also bump the soversion -- might as well do a rebuild just once. But I thought I would give everyone the heads up so that you all know what's going on. -- Hubert Chan - email & Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GNUstep packages
Colin Watson wrote: On Wed, Jan 05, 2005 at 06:21:01PM +0100, Eric Heintzmann wrote: Currently, latest GNUstep packages cannot enter in sarge. (soname change and nearly all packages have been renamed) One package is not a valid candidate : gnustep-antlr (Cannot be built on arm) gnustep-antlr/arm is in incoming. There's also charmap.app/hppa; LaMont is looking at this. But all the 53 others GNUstep packages are valid candidates and cannot enter in sarge. Please, is it possible to push them in sarge ? The hints are already in place, and should take effect tonight or tomorrow if charmap.app/hppa succeeds. If it doesn't, we'll probably just temporarily remove charmap.app. If it helps, you can also remove definitly the old charmap source package (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=287531) same for lusenet, viewpdf and gnustep-imagekits (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=287532 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=287530 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=285516) Eric
Re: GNUstep packages
On 2005-01-05 19:00:24 +0100 Kurt Roeckx <[EMAIL PROTECTED]> wrote: On Wed, Jan 05, 2005 at 06:21:01PM +0100, Eric Heintzmann wrote: Hi, Currently, latest GNUstep packages cannot enter in sarge. (soname change and nearly all packages have been renamed) One package is not a valid candidate : gnustep-antlr (Cannot be built on arm) There is 1 other package that is required for it to transition. charmap.app is not yet build on hppa. right. Note that this isn't showing up in as "out-of-date" because it comes from an other source package. Yes. charmap.app was never built on hppa. And charmap should be removed from sid and sarge (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=287531) Eric
Re: GNUstep packages
On Wed, Jan 05, 2005 at 06:21:01PM +0100, Eric Heintzmann wrote: > Hi, > > Currently, latest GNUstep packages cannot enter in sarge. > (soname change and nearly all packages have been renamed) > > One package is not a valid candidate : gnustep-antlr (Cannot be built > on arm) There is 1 other package that is required for it to transition. charmap.app is not yet build on hppa. Note that this isn't showing up in as "out-of-date" because it comes from an other source package. Kurt
Re: GNUstep packages
On Wed, Jan 05, 2005 at 06:21:01PM +0100, Eric Heintzmann wrote: > Currently, latest GNUstep packages cannot enter in sarge. > (soname change and nearly all packages have been renamed) > > One package is not a valid candidate : gnustep-antlr (Cannot be built > on arm) gnustep-antlr/arm is in incoming. There's also charmap.app/hppa; LaMont is looking at this. > But all the 53 others GNUstep packages are valid candidates and cannot > enter in sarge. > Please, is it possible to push them in sarge ? The hints are already in place, and should take effect tonight or tomorrow if charmap.app/hppa succeeds. If it doesn't, we'll probably just temporarily remove charmap.app. Cheers, -- Colin Watson [EMAIL PROTECTED]
GNUstep packages
Hi, Currently, latest GNUstep packages cannot enter in sarge. (soname change and nearly all packages have been renamed) One package is not a valid candidate : gnustep-antlr (Cannot be built on arm) But all the 53 others GNUstep packages are valid candidates and cannot enter in sarge. Please, is it possible to push them in sarge ? Eric P.S. The full list of packages that should be pushed into sarge: gworkspace addresses-for-gnustep gnumail gnustep-examples meta-gnustep aclock.app agenda.app camera.app cenon.app charmap.app connect.app cynthiune.app displaycalibrator.app easydiff.app edenmath.app gnuwash.app gomoku.app gridlock.app helpviewer.app latex.service lusernet.app meta-gnustep mines.app mknfonts.tool mpdcon.app plopfolio.app poe.app preferences preview.app price.app shisen.app stepbill.app stepulator.app talksoup.app textedit.app viewpdf.app volumecontrol.app waiho.app wildmenus.bundle zipper.app gorm imageviewer projectcenter terminal gnustep-dl2 gnustep-gd gnustep-netclasses renaissance steptalk
