, now we finally get somewhere. All of this is about non-Debian.
Breaking "cross-compiling with debian tools on debian" is
significant. It's not helpful to characterise that as
'non-Debian'. It's something we've done well for a long time, and is
the reason some
done by engaging further. Yes it
will be hard work, but if it's not done we are just stuck.
Wookey
--
Principal hats: Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
and often stale).
I'm sure Ian is right that there is a trend towards git from tarballs
and dscs, but I just question whether we know it is 'the vast
majority'? Are there really now very few maintainers using the
'classic tooling'? How do we know?
Wookey
--
Principal hats:
On 2021-10-24 19:08 +, Clint Adams wrote:
> On Sun, Oct 17, 2021 at 02:33:44PM +0100, Wookey wrote:
> > I think causing build failures is enough reason to say this. I don't
> > suppose that mine is the only one. Yes those builds are buggy and
> > should not do this,
om one package to another does not need to be printed on
every usage of that binary. Indeed it is actively unhelpful to do so.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
ch is in use. (The only good
thing about this whole thing has been the opportunity for whichy
wordplay :-)
Cheers
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
t to add pile of verbiage here, but I'd just like to say
that everything Wouter said makes a whole lot of sense to me.
We know how to do this sort of transition, and yes it takes some time,
but that's OK. Using usrmerge to try and shortcut this, producing the
awkward 'dual-state
r bad (self-dependency at the same version is much more of a
problem than self-dependency at older versions).
Anyway, Pirate - I suggest you ask about this on debian-devel where we
can have a pulic discussion about policy and whether there is anything
special about this case which makes it not su
- Option A - Reaffirm Ron Lee as 'global' maintainer (§6.1.2)
> > - Option B - Declare Wookey as 'global' maintainer (§6.1.2)
> > - Option C - Decline to rule, consider case closed
> > - Option FD - Further discussion
The package was offered for adoption, and
rs. Warm potato accepted :-)
> Wookey: if you want the complete git history, right back to the very first
> package in 1999, you can grab it from the Vcs-Git URL in the sid package.
> I'm not going to go Full Bruce and rage delete it, but eventually I should
> decruft alioth and re
On 2016-12-08 17:03 +0100, Didier 'OdyX' Raboud wrote:
Sorry missed this in all yesterday's mail.
> Wookey, Vincent, Punit: would any of you be willing to receive the 'global'
> package maintainer hat? (which would of course come with the possibility to
> shar
On 2016-12-08 17:33 +, Wookey wrote:
> On 2016-12-08 23:32 +1030, Ron wrote:
> > But it also outputs a .htaccess enabling execution in the directory
> > where the output is generated, whether you want to use it from there
> > or not (and adds a second CGI, and a bunch of
On 2016-12-09 11:58 +0900, Shigio YAMAGUCHI wrote:
> Hello all,
> 2016 19:05:55 +, Wookey wrote:
> > The .cgi scripts are generated from .in files which are correctly
> > parameterised with @PERLPATH@ and @GLOBALPATH@ etc. Upstream
> > unhelpfully ships pre-generated
for debian, which
> brings us back to exactly where we are - unless we just remove it all.
> But that would need Time, whoever does it.
I have not grokked why the shoddy code in 5.7.1 is safe but the same
shoddy code in v6 cannot be let out. Did htmake+htconfig stop people
entering $patte
e we are - unless we just remove it all.
> But that would need Time, whoever does it.
I have not grokked why the shoddy code in 5.7.1 is safe but the same
shoddy code in v6 cannot be let out. Did htmake+htconfig stop people
entering $pattern in the form?
> It is what we now have enabled i
On 2016-12-01 22:56 +0100, Philip Hands wrote:
> Wookey writes:
> > On 2016-11-30 16:56 +, Ian Jackson wrote:
> >
> >> > And this last bit (integration with system web server) is the
> >> > functionality that had security concerns raised by Ron [etc.]
y that had security concerns raised by Ron [etc.]
>
> So, to be clear, it is this functionality which is dropped in the
> package that you and Wookey uploaded to experimental/delayed ?
Said package is available as of today:
https://buildd.debian.org/status/package.php?p=global&suite=exper
stream no longer
attempts to do such a thing there is a good argument that the debian
packaging shouldn't either.
I certainly don't think that the fact that this was done once is a
good reason to stop packaging new releases.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digital signature
t, but it is current with updated
packaging. I'll include details of the known issues in one of the
'please can we have a new version' bugs. I think it's more useful to
have the current state of play avalable than for me to keep messing
with it privately.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digital signature
about a single binary package without
> reverse dependencies. I'm really afraid that a side-effect of the TC
> discussion will be yet-another release without an up-to-date src:global.
Thank you for some sanity on this matter.
Wookey
--
Principal hats: Linaro, Debian, Wookware,
On 2016-11-16 06:02 +1030, Ron wrote:
> On Mon, Nov 14, 2016 at 04:55:06PM +0000, Wookey wrote:
> > On 2016-10-25 07:29 +0200, Tollef Fog Heen wrote:
> > >
> > > FWIW, it worked fine in a test run I just did (on linux-4.9 rc 1), and
> > > last time I used it
GSYMS not found.
only 2 files generated:
GPATH
GTAGS
global 6.5.4 (upstream release) works on both.
( I also found 844330 in the process, which is just a packaging update issue )
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digital signature
7;). Debian used to have a (largely deserved) reputation as an
unpleasant project to work in. We've done a lot in the last few years
to improve that situation. I invite the TC to reflect on how this
would have played out if global had had a different maintainer. This
is (or should be) about a
e would
have something to work with, but asking the TC to rule seems like a
more correct way to try and unbung this situation.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digital signature
+++ Don Armstrong [2015-09-10 09:57 -0500]:
> On Wed, 09 Sep 2015, Wookey wrote:
> > Well, maybe. Maybe there were discussions to that effect I didn't see.
> > In that case fair enough. The impression given was of a somewhat slow
> > process and members not having time t
+++ Steve Langasek [2015-09-09 12:17 -0700]:
> On Wed, Sep 09, 2015 at 05:30:03PM +0100, Wookey wrote:
>
> > So what I learned from this is that, as currently operating, the
> > committee is incapable of making quick 'overrule unreasonableness'
> > decisions.
or not - you probably knew all that,
but hopefully it gives a little external perspective.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
+++ Ben Longbons [2014-12-18 12:23 -0800]:
> On Thu, Dec 18, 2014 at 8:36 AM, Wookey wrote:
> > MA-built vs in-arch
> > ---
> > I guess an interesting question is 'what does the cross-compiler
> > actually _use_ the foreign arch libc for'? Does
e is volunteering to maintain, and no-one is
volunteering to maintain the former (yet?). The simple ones can evolve
and, in the way of things, are likely to become more capable and
complicated over time. But what is the point of vetoing them,
especially when we _know_ that such simpler cross-toocha
+++ Matthias Klose [2014-12-04 20:41 +0100]:
> So in the last email Wookey enumerates a lot of things what he did
> during the last months. Maybe he should have mentioned his
> ballerina lessons used for his performances during the DebConf talks
> too. However ever all of these ha
derstanding the existing binutils and GCC packaging,
> nor willing to understand it, and still claiming that he is able to
> "simplify" it.
I'm not sure who you are referring to here, but just to clarify: the
mentors for that project were Hector Oron and Marcin Juszkiewicz, not
sbuild. Including cross-gcc-defaults
to add the wanted symlinks for all arches except mips (because mips
was lagging badly at the time of the original upload so I missed that
one out - this has just been corrected in cross-gcc-defaults 0.4,
currently in NEW).
They work to build all (most?) o
At least 3 of us are prepared to maintain the with-deps packaging
rules. IMHO it makes a lot more sense to maintain it in gcc packagig
where it already is rather than do it outside as a big quilt stack,
but that won't work if the maintainer doesn't apply patches. I
just filed 770413,
ue of this
bug was not the only problem there: missing work on britney and
wanna-build means they wouldn't have migrated in time independently of
this issue and I was not able to persuade the release team to make a
special exception on 'release goal' grounds.
Wookey
--
Principal hat
dd the "override"
> directive; the make documentation explicitly says that it "was not
> invented for escalation in the war between makefiles and command
> arguments".)
The 4.9.2-1 gcc 4.9 upload adds the override directive.
Wookey
--
Principal hats: Linaro, Emdebian, Wook
+++ Helmut Grohne [2014-11-01 10:38 +0100]:
> On Sat, Nov 01, 2014 at 01:46:48AM +0000, Wookey wrote:
> > To me that sounds like this method is actually the
> > current de-facto default in Debian - it is certainly at least on a par.
>
> I don't think that a feature b
ack uploads in order to keep the
cross-binutils and cross-gcc packages in sync.
> > these bugs ? It seems to me that it would be easy to come up with a
> > workflow that allowed Matthias to usertag these kind of bugs and hand
> > them over to the cross teams.
>
> Sounds rea
would be a lot less
resistance to dropping the other one, although I don't actually think
that's a good idea either.
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/
--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with
38 matches
Mail list logo
