Re: GCC 4.2 transition
On Sat, 30 Jun 2007, Frans Pop wrote: > However, I'm not completely sure if that explanation actually matches what > I was seeing in practice and have not tried only using 'found' recently > (I've been using both reopen and found, just to be sure...). Heh. The explanation is the way it's *supposed* to work; if it doesn't, let me know, and I'll fix it. Don Armstrong -- Your village called. They want their idiot back. -- xkcd http://xkcd.com/c23.html http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.2 transition
On Saturday 30 June 2007 19:06, Frank Lichtenheld wrote:
> On Sat, Jun 30, 2007 at 07:11:36AM -0700, Don Armstrong wrote:
> > 1) found foobug fooversion; command to the BTS. If this version is
> > greater or equal to any other fixed version, or causes all fixed
> > versions to be removed ('cause they're equal to the found version),
> > the bug is reopened as well.
>
> Was there a time where this didn't reopen the bug? Since I'm pretty
> sure I tried that in the past and it didn't reopen the bug.
Yes, this confused me for a long time too.
IIUC from comments during DebConf, there was a bug that the BR was only
reopened if the 'found' version exactly matched the 'done' version. That
bug should now be fixed.
However, I'm not completely sure if that explanation actually matches what
I was seeing in practice and have not tried only using 'found' recently
(I've been using both reopen and found, just to be sure...).
Cheers,
FJP
pgpTgxhGow9aH.pgp
Description: PGP signature
Re: GCC 4.2 transition
On Sat, 30 Jun 2007, Frank Lichtenheld wrote:
> On Sat, Jun 30, 2007 at 07:11:36AM -0700, Don Armstrong wrote:
> > 1) found foobug fooversion; command to the BTS. If this version is
> > greater or equal to any other fixed version, or causes all fixed
> > versions to be removed ('cause they're equal to the found version),
> > the bug is reopened as well.
>
> Was there a time where this didn't reopen the bug? Since I'm pretty
> sure I tried that in the past and it didn't reopen the bug.
It only reopened the bug in the past if it was exactly equal to the
last entered fixed version; this changed recently because the current
logic makes more sense to me.
Don Armstrong
--
UF: What's your favourite coffee blend?
PD: Dark Crude with heavy water. You are understandink? "If geiger
counter does not click, the coffee, she is just not thick."
http://www.donarmstrong.com http://rzlab.ucr.edu
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.2 transition
On Sat, Jun 30, 2007 at 07:11:36AM -0700, Don Armstrong wrote:
> 1) found foobug fooversion; command to the BTS. If this version is
> greater or equal to any other fixed version, or causes all fixed
> versions to be removed ('cause they're equal to the found version),
> the bug is reopened as well.
Was there a time where this didn't reopen the bug? Since I'm pretty
sure I tried that in the past and it didn't reopen the bug.
Gruesse,
--
Frank Lichtenheld <[EMAIL PROTECTED]>
www: http://www.djpig.de/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.2 transition
On Fri, 29 Jun 2007, Daniel Schepler wrote:
> So my question remains: what's the officially sanctioned,
> nondeprecated way to revert the effects of a versioned message to
> [EMAIL PROTECTED]
There are three reasonable ways, depending on the effect you want to
have:
1) found foobug fooversion; command to the BTS. If this version is
greater or equal to any other fixed version, or causes all fixed
versions to be removed ('cause they're equal to the found version),
the bug is reopened as well.
2) notfixed foobug fooversion; command to the BTS. You do this if you
only want to remove the fixed version from the list, but do not want
to actually reopen the bug.
3) reopen foobug [fooversion]; command to the BTS. This clears the
fixed list and reopens the bug.
Don Armstrong
--
Guns Don't Kill People.
*I* Kill People.
http://www.donarmstrong.com http://rzlab.ucr.edu
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.2 transition
On Sat, Jun 30, 2007 at 11:56:56AM +0200, Frank Lichtenheld wrote: >> So my question remains: what's the officially sanctioned, nondeprecated way >> to >> revert the effects of a versioned message to [EMAIL PROTECTED] > reopen (I think that also clears the fixed list, don't tried it though, > so you might need notfixed, too) reopen clears the fixed list, yes. See http://wiki.debian.org/BugsVersionTracking . > The open/done status is independent of the found/fixed lists (which > is probably a bug, but that how it is atm). Note that it is only "independent" in the sense that it is ignored for most purposes if the fixed list is non-empty. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.2 transition
On Fri, Jun 29, 2007 at 12:48:53PM -0400, Daniel Schepler wrote: > I guess it does. But I thought reopen was deprecated since the versioning > stuff was added to the BTS. However, the "notfixed" command issued earlier > didn't completely remove the "done" status from the bug... (And I thought > I'd tried notfixed earlier -- how come it worked for Touko Korpela but not > for me when afaict I tried exactly the same command?) > > So my question remains: what's the officially sanctioned, nondeprecated way > to > revert the effects of a versioned message to [EMAIL PROTECTED] reopen (I think that also clears the fixed list, don't tried it though, so you might need notfixed, too) The open/done status is independent of the found/fixed lists (which is probably a bug, but that how it is atm). Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.2 transition
On Friday 29 June 2007 08:21:18 am Philippe Cloutier wrote: > > BTW: anybody more versed in the bts system than I am, how can I get > > #359634 marked as not actually being fixed? > > Does a simple reopen not work? I guess it does. But I thought reopen was deprecated since the versioning stuff was added to the BTS. However, the "notfixed" command issued earlier didn't completely remove the "done" status from the bug... (And I thought I'd tried notfixed earlier -- how come it worked for Touko Korpela but not for me when afaict I tried exactly the same command?) So my question remains: what's the officially sanctioned, nondeprecated way to revert the effects of a versioned message to [EMAIL PROTECTED] -- Daniel Schepler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Re: GCC 4.2 transition
BTW: anybody more versed in the bts system than I am, how can I get #359634 marked as not actually being fixed? Does a simple reopen not work? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.2 transition
* Daniel Schepler <[EMAIL PROTECTED]> [2007-06-28 17:09]: > So with your permission, I'd like to close those three bugs. At least jigdo builds fine here as well, so please feel free to close them. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.2 transition
* Kevin B. McCarty <[EMAIL PROTECTED]> [2007-06-28 08:40]: > Does this imply that all FORTRAN-using packages will need to move from > g77-3.4 to gfortran-4.2 in the near future? To my knowledge there has > been no mass rebuild of FORTRAN packages with gfortran yet to see how > smoothly this will work out... > > As I understand it the challenges involved in a mass switch to gfortran > are two-fold. First, gfortran and g77 by default produce code with > different ABIs (at least for functions that return REAL or COMPLEX; > possibly also in other cases?) so probably a transition plan for > libraries, similar to the C++ ABI change transitions, will be needed. > > Second, another complicating factor is that since gfortran is not going > to provide an f77 or g77 symlink (I understand this is because it is not > a complete standards-compliant implementation of a FORTRAN 77 compiler), > all the build infrastructures of FORTRAN packages will need to be > altered so that they call gfortran instead of f77 / g77 / $(FC) / $(F77). CCing Matthias who's the right person to answer this. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.2 transition
I've been unable to reproduce any of the "One Definition Rule" bugs you filed. Jigdo builds fine; apt builds successfully apart from #428623 (and #359634 on my local setup); and gnome-vfsmm2.6 is fine until it hits #422813. It looks like something was either fixed or reverted. I also tried compiling jigdo using the current gcc-snapshot, and it built fine after I added some missing #includes. So with your permission, I'd like to close those three bugs. BTW: anybody more versed in the bts system than I am, how can I get #359634 marked as not actually being fixed? My clumsy attempts just ended up making things more confused. -- Daniel Schepler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.2 transition
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2007-06-28 16:48]: > > default compiler in unstable for all architectures and for all > > languages with the exception of Java (which will follow later). > > This message describes the plan to make this transition possible. > > Could you say something about the state of play on arm and armel ? I compiled about 2000 packages on arm and didn't find any problems. I didn't test Java though. I also didn't test on armel. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.2 transition
On Thu, Jun 28, 2007 at 02:47:55PM +0200, Martin Michlmayr wrote: > GCC 4.2 was released on May 13 and has been in unstable since roughly > that time. The default version of gfortran was recently switched to > 4.2 and the Debian GCC maintainers would like to move to 4.2 as the > default compiler in unstable for all architectures and for all > languages with the exception of Java (which will follow later). > This message describes the plan to make this transition possible. Could you say something about the state of play on arm and armel ? Regards, Paddy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.2 transition
Martin Michlmayr wrote: > GCC 4.2 was released on May 13 and has been in unstable since roughly > that time. The default version of gfortran was recently switched to > 4.2 and the Debian GCC maintainers would like to move to 4.2 as the > default compiler in unstable for all architectures and for all > languages with the exception of Java (which will follow later). > This message describes the plan to make this transition possible. Hi Martin, Does this imply that all FORTRAN-using packages will need to move from g77-3.4 to gfortran-4.2 in the near future? To my knowledge there has been no mass rebuild of FORTRAN packages with gfortran yet to see how smoothly this will work out... As I understand it the challenges involved in a mass switch to gfortran are two-fold. First, gfortran and g77 by default produce code with different ABIs (at least for functions that return REAL or COMPLEX; possibly also in other cases?) so probably a transition plan for libraries, similar to the C++ ABI change transitions, will be needed. Second, another complicating factor is that since gfortran is not going to provide an f77 or g77 symlink (I understand this is because it is not a complete standards-compliant implementation of a FORTRAN 77 compiler), all the build infrastructures of FORTRAN packages will need to be altered so that they call gfortran instead of f77 / g77 / $(FC) / $(F77). best regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 signature.asc Description: OpenPGP digital signature
