Bug#711477: general: Videos are not visible in VMware Workstation

[Nikos Chantziaras]

Package: general
Severity: normal

Dear Maintainer,

I've installed Debian 7 as a guest OS in VMware 9.0.2, which is running in a
Gentoo Linux AMD64 host. Trying to play videos in any software that uses
GStreamer results in the audio being played normally, but the video is not
visible. Instead, a dark gray area is displayed. This happens with Totem Movie
Player, but also with my own software which also uses GStreamer (utilizing the
playbin2 element).

This happens with all videos, regardless of video format. I should mention that
this happens with both instances of Debian 7 I've installed: x86 and x86-64.
Also, these are fresh installations and I didn't change any system settings or
added third-party repositories, with the exception of having installed VMware
Tools.

I am able to play video normally in my openSUSE, Fedora and Ubuntu guests.



-- System Information:
Debian Release: 7.0
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130607071253.4300.34685.reportbug@debian7-64

Re: How should we do for font-adobe-copyrighted-fragment error?

[Atsuhito Kohda]

On Thu, 6 Jun 2013 10:21:05 +0200, Bastien ROUCARIES wrote:

> I have contacted adobe and they are willing to relicense see main bug
> report.

It seems it will happen not so soon.

> From my point of view the second one should be corrected and is serious and
> render the package even non suitable for non free.  We are violating the
> license from adobe...

Hmm, I'm not sure if I can correct the problem soon.

Furthere, under the hypothesis that adobe will relicense,
we can upload the package when we correct the problem?

Thanks for your advice.
Best regards,   2013-6-7(Fri)

-- 
 Debian Developer - much more I18N of Debian
 Atsuhito Kohda 
 Department of Math., Univ. of Tokushima


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130607.162413.1798446560061322549.atsuhito@at-SVT

Re: How should we do for font-adobe-copyrighted-fragment error?

[Atsuhito Kohda]

Hi all,

On Thu, 6 Jun 2013 11:24:57 +0200, Holger Levsen wrote:

>> I remembered that there were discussions about proprietry
>> code of adobe in Nov. 2012 but don't understand the conclusion.
> 
> #694308 is the bug tracking this, which should also have more info.

Yes, but it looks to me there is not practical information.

Thanks for your advice.
Best regards,   2013-6-7(Fri)

-- 
 Debian Developer - much more I18N of Debian
 Atsuhito Kohda 
 Department of Math., Univ. of Tokushima


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130607.162827.351644749507448954.atsuhito@at-SVT

Re: default MTA

[Jonathan Dowland]

On Thu, Jun 06, 2013 at 11:36:21PM +0800, Thomas Goirand wrote:
> Well, in that case, it failed to be as simple to configure as qmail.

Is ease of configuration an important criteria for default MTA? More
important than sensible-default?


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130607084341.GB6619@debian

Processed: Re: Bug#711477: general: Videos are not visible in VMware Workstation

[Debian Bug Tracking System]

Processing control commands:

> tag -1 + moreinfo
Bug #711477 [general] general: Videos are not visible in VMware Workstation
Added tag(s) moreinfo.

-- 
711477: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=711477
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/handler.s.b.137059547428020.transcr...@bugs.debian.org

Bug#711477: general: Videos are not visible in VMware Workstation

[Bastien ROUCARIES]

Control: tag -1 + moreinfo

What is your x server ?
Le 7 juin 2013 09:15, "Nikos Chantziaras"  a écrit :

> Package: general
> Severity: normal
>
> Dear Maintainer,
>
> I've installed Debian 7 as a guest OS in VMware 9.0.2, which is running in
> a
> Gentoo Linux AMD64 host. Trying to play videos in any software that uses
> GStreamer results in the audio being played normally, but the video is not
> visible. Instead, a dark gray area is displayed. This happens with Totem
> Movie
> Player, but also with my own software which also uses GStreamer (utilizing
> the
> playbin2 element).
>
> This happens with all videos, regardless of video format. I should mention
> that
> this happens with both instances of Debian 7 I've installed: x86 and
> x86-64.
> Also, these are fresh installations and I didn't change any system
> settings or
> added third-party repositories, with the exception of having installed
> VMware
> Tools.
>
> I am able to play video normally in my openSUSE, Fedora and Ubuntu guests.
>
>
>
> -- System Information:
> Debian Release: 7.0
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
> Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive:
> http://lists.debian.org/20130607071253.4300.34685.reportbug@debian7-64
>
>

Re: On accepting pre-generated doc from upstream

[Charles Plessy]

[Dropping debian-legal as it is not a legal issue.]

Le Fri, Jun 07, 2013 at 07:40:35AM +0200, olivier sallou a écrit :
> 
> Though packager should at least build the doc himself, locally to be sure
> doc can indeed be generated.

Hello everybody,

how about implementing this verification with autopkgtest (DEP 8) for instance ?

Have a nice week-end,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130607094814.gb7...@falafel.plessy.net

Re: x32 “half”arrived… now what?

[Thorsten Glaser]

Russ Allbery  debian.org> writes:

> Be aware that x32 has sizeof(time_t) > sizeof(long), so you should expect

So has MirBSD/i386 (since 2004-06-19) and NetBSD (since roughly a year).

Most frequent thing is format specifiers when struct tm.tm_year is time_t
instead of long (which is a requirement for time_t to be able to round-trip
through struct tm, which is required by quite some software).

I did lose one of my PGP keys though – pgp-2.6.3in didn’t cope with the
change and had the binary keyring format differ (and I haven’t found the
floppy on which the backup was). Other than that, most things work.

@Philipp: true about the stability-before-inclusion statement, but if
I get x32 ldconfig run on an i386 system (not all of these run amd64
kernels anyway), things could use some polishing. The kernel thing…
I guess the option just needs to be enabled at some point, though x32
*is* on dpo already, and the other dpo architectures are also supported…
but the main “weird” thing right now is the presence of x32 stuff on a
pure i386 system.

bye,
//mirabilos


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/loom.20130607t114138-...@post.gmane.org

Re: NDEBUG when building packages?

[Mathieu Malaterre]

On Sat, Feb 23, 2013 at 11:09 AM, Vincent Cheng  wrote:
> On Sat, Feb 23, 2013 at 1:39 AM, Mathieu Malaterre  wrote:
>> On Fri, Feb 22, 2013 at 9:52 PM, Russ Allbery  wrote:
>>> Ian Jackson  writes:
 Mathieu Malaterre writes ("Re: NDEBUG when building packages?"):
>>>
> In that case, this should really be clarified. A lot of debian/cmake
> packages are actually doing:
>>>
> -DCMAKE_BUILD_TYPE:STRING=Release
>>>
> within there debian/rules files. This settings by default compiles
> with: `-O3 -DNDEBUG`
>>>
 OMG WTF BBQ
>>>
 Certainly -DNDEBUG should never be used unless upstream explicitly say
 that it's intended to be supported, and usually not even then.
>>>
>>> Also, -O3 is generally considered rather iffy.  It's not very well-tested
>>> and in various versions of GCC it tended to make the code slower, not
>>> faster (usually because it unrolled loops too far and blew the CPU cache).
>>> It's also had various code generation bugs from time to time.
>>>
>>> I wouldn't use -O3 without benchmarking of that specific code to confirm
>>> that it really improves matters.
>>
>> Seems like everyone agreed. I'll report a bug to lintian package to
>> have it check for this string in d/rules:
>>
>> http://codesearch.debian.net/search?q=DCMAKE_BUILD_TYPE:STRING%3DRelease
>
> We should also suggest that packages use
> -DCMAKE_BUILD_TYPE=RelWithDebInfo instead (-g -O2). In fact, I think
> that this would be a sensible default for packages using debhelper's
> cmake integration. Sounds like another wishlist bug for debhelper...

cmake from sid makes it even harder. RelWithDebInfo now contains
-DNDEBUG ... I have to source-upload all my packages :(

$ grep NDEBUG ChangeLog.manual
  Add -DNDEBUG to RelWithDebInfo flags where where Release flags had it.


The solution (backward compat) is now:

Either do *not* define CMAKE_BUILD_TYPE, or define CMAKE_BUILD_TYPE to
Debug (and hope -DNDEBUG does not creep in ever)

2cts


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CA+7wUsx-La707opCh_HrcrAjUQw7DdAkTAa4HXov8Vfp=mx...@mail.gmail.com

Re: Why not to let all DDs to execute "gb"-command

[Philipp Kern]

On 2013-06-06 21:42, Paul Tagliamonte wrote:
Well, I don't think adding more kruft to dak is a great idea (I mean, 
if

it has to happen, it has to happen), but this really shows that we need
a unified way of passing machine-readable messages between services.

Let's see how the GSoC project turns out; I'm willing to bet even a
proof of concept would be useful to services that interdepend so
closely.

I mean, not to play the "UNIX" card, but one thing well, you know? 
Let's

just aid in the code talking to each other better.


Oh yeah, if you give us secure and reliable(!) messaging over unreliable 
and untrusted networks, in way that DSA accepts, I would be very happy. 
;-)


buildd could use it instead of throwing away calls when the main host is 
temporarily unreachable.


Kind regards
Philipp Kern


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/0dee130e32d02efca9939545151d6...@hub.kern.lc

Re: default MTA

[Marc Haber]

On Thu, 6 Jun 2013 14:07:38 +0100, Jonathan Dowland 
wrote:
>On Thu, May 30, 2013 at 06:38:52PM +0200, Marc Haber wrote:
>> On Thu, 30 May 2013 16:53:56 +0200, m...@linux.it (Marco d'Itri) wrote:
>> >I think that ease of configurability is a major plus for Postfix when 
>> >compared to Exim, since a common configurations is just a few lines long.
>> 
>> How many lines does an average update-exim4.conf.conf have?
>
>You're right, in that the "interface" that a user has to exim-on-debian is
>update-exim4.conf.conf, rather than exim4's configuration directly; however,
>length aside, I don't see this as a strength, but a serious source of
>confusion.

Sendmail has just one more layer of indirection by virtue of the m4
macros. Postfix has most of its behavior hard coded in the C sources,
while exim's behavior can be controlled by run-time configuration if
an advanced user wants to do things that Debian's abstraction layer
was not designed to handle.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1ukuan-0002iq...@swivel.zugschlus.de

Re: default MTA

[Marc Haber]

On Thu, 6 Jun 2013 20:06:56 -0400, Chris Knadle
 wrote:
>On Thursday, June 06, 2013 16:30:48, Roger Lynn wrote:
>> The smarthosts run by ISPs that most people will be using by default have
>> to accept mail direct from MUAs such as Outlook and Thunderbird which will
>> often be unable to generate compliant greetings. The pickier settings are
>> more often used on incoming servers which expect to have proper SMTP
>> servers speaking to them.
>
>I think that's true, however I'd still rather not _count on_ that always being 
>the case.

I have not seen an ISP smarthost that didn't accept any rubbish in the
EHLO string in years. Smarthosts can be configured to be even more
forgiving on Port 587.

For example, Debian's default exim configuration is configured to not
do recipient verification if the message comes in from a host for
which we are a smarthost (by virtue of being listed in
relay_from_hosts or by successful authentication) since we assume that
MUAs might hide SMTP error messages from the user. Exim, in this case,
will create a regular bounce for messages for non-existing recipients
instead of rejecting it at SMTP time which is the normal mode of
operation.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1ukuf3-0002m4...@swivel.zugschlus.de

Re: NDEBUG when building packages?

[Kumar Appaiah]

On Fri, Jun 07, 2013 at 11:54:49AM +0200, Mathieu Malaterre wrote:
> cmake from sid makes it even harder. RelWithDebInfo now contains
> -DNDEBUG ... I have to source-upload all my packages :(
> 
> $ grep NDEBUG ChangeLog.manual
>   Add -DNDEBUG to RelWithDebInfo flags where where Release flags had it.
> 
> 
> The solution (backward compat) is now:
> 
> Either do *not* define CMAKE_BUILD_TYPE, or define CMAKE_BUILD_TYPE to
> Debug (and hope -DNDEBUG does not creep in ever)

While we're at it, could you please let me know what is the best
practice for package builds that generate debug symbol packages?
Ideally, I would hapve to rebuild the whole package TWICE, once with
-O0 -g, and the other time with -O2, right?

Currently, I don't bother with this, since the the debug library with
-O2 is still useful, other than the odd "optimized out" messages. In
addition, I don't want to add an additional burden to the buildds for
this, since the package is probably never used on architectures other
than i386/amd64.

Thanks.

Kumar

-- 
mar...@bdsi.com (no longer valid - where are you now, Martin?)
-- from /usr/src/linux/drivers/cdrom/mcd.c


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130607113421.ga14...@bluemoon.alumni.iitm.ac.in

Re: NDEBUG when building packages?

[Stephen M. Webb]

On 06/07/2013 07:34 AM, Kumar Appaiah wrote:
> 
> While we're at it, could you please let me know what is the best
> practice for package builds that generate debug symbol packages?
> Ideally, I would hapve to rebuild the whole package TWICE, once with
> -O0 -g, and the other time with -O2, right?

Having debug symbols not matching the runtime would cause a great deal of 
trouble.  If you're expecting a lot of
debugging, try the new -Og switch.

One build pass and let dh_strip create the debug symbols package for you.  
Unless you're not using dh, in which case
your build system is probably already broken and needs to get fixed first.

-- 
Stephen M. Webb  



signature.asc
Description: OpenPGP digital signature

Re: Why not to let all DDs to execute "gb"-command

[Nicolas Dandrimont]

* Philipp Kern  [2013-06-07 12:26:37 +0200]:

> On 2013-06-06 21:42, Paul Tagliamonte wrote:
> >Well, I don't think adding more kruft to dak is a great idea (I
> >mean, if
> >it has to happen, it has to happen), but this really shows that we need
> >a unified way of passing machine-readable messages between services.
> >
> >Let's see how the GSoC project turns out; I'm willing to bet even a
> >proof of concept would be useful to services that interdepend so
> >closely.
> >
> >I mean, not to play the "UNIX" card, but one thing well, you know?
> >Let's
> >just aid in the code talking to each other better.
> 
> Oh yeah, if you give us secure and reliable(!) messaging over
> unreliable and untrusted networks, in way that DSA accepts, I would
> be very happy. ;-)

Hi,

Secure should be pretty straightforward as every message is already
cryptographically signed. I think most of the work (save from packaging) will
be on the reliability side, as Fedora's infrastructure is more tightly
integrated than ours.

The "accepted by DSA part" is a bit complicated. We didn't really want to
bother one of the busiest teams in Debian when the software wasn't even
packaged, and, when it came up, I felt that the reception of the idea of
using fedmsg was a bit lukewarm. I think we should be able to work things out
when and if we have a working proof of concept.

> [snip]

Cheers,
-- 
Nicolas Dandrimont

BOFH excuse #88:
Boss' kid fucked up the machine


signature.asc
Description: Digital signature

Re: On accepting pre-generated doc from upstream

[Lisandro Damián Nicanor Pérez Meyer]

On Friday 07 June 2013 08:31:22 Bastien ROUCARIES wrote:
> Le 7 juin 2013 05:18, "Paul Wise"  a écrit :
> > I would suggest the approach taken by the recent GSoC projects related
> > to bootstrapping new ports. Multi-stage builds. First stage without
> > docs and second stage with docs. Only the second stage gets uploaded
> > to Debian.
> > 
> > http://wiki.debian.org/DebianBootstrap
> 
> Moreover I suppose doc is arch all? And thus staging need to be done only
> once.

This could work as long as we don't discard the generated binaries on upload.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.

Re: NDEBUG when building packages?

[Jonas Smedegaard]

Quoting Stephen M. Webb (2013-06-07 14:29:52)
> On 06/07/2013 07:34 AM, Kumar Appaiah wrote:
> > 
> > While we're at it, could you please let me know what is the best
> > practice for package builds that generate debug symbol packages?
> > Ideally, I would hapve to rebuild the whole package TWICE, once with
> > -O0 -g, and the other time with -O2, right?
> 
> Having debug symbols not matching the runtime would cause a great deal 
> of trouble.  If you're expecting a lot of debugging, try the new -Og 
> switch.
> 
> One build pass and let dh_strip create the debug symbols package for 
> you.  Unless you're not using dh, in which case your build system is 
> probably already broken and needs to get fixed first.

Fud!

Please support your "dh is a silver bullet" meme with some concrete 
references.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: On accepting pre-generated doc from upstream

[Marco d'Itri]

On Jun 07, Lisandro Damián Nicanor Pérez Meyer  wrote:

> - We do have the source code for generating it (preferred form of 
> modification).
> 
> - We can build it, but it requires lot of work... and avoid FTBFSs while 
> bootstrapping ;)
> 
> So, could we accept pre-generated documentation in this case?
Yes, this is a well established case.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: x32 “half” arrived… now what?

[Daniel Schepler]

(Sorry about the lack of threading... for some reason I'm unable to find the 
links to download mbox archives for replying to the messages.)

In response to Adam's comments about debootstrap not working because findutils 
FTBFS: Yes, I'm aware of that, and for now you have to include "unreleased" as 
well using multistrap with the instructions at http://wiki.debian.org/X32Port 
.  (And apologies for the inconvenience...  That will also get you a newer 
version of binutils:x32 which makes elf32_x86_64 the default target -- which 
is really only important if your source package is using "ld -r" or otherwise 
running ld manually.)

For the reason we still have multilib packages instead of relying on 
multiarch, see the thread starting at
http://lists.debian.org/debian-devel/2013/05/msg00692.html .  (The one good 
argument there IMO is that dropping libc6-i386 in favor of libc6:i386 could 
cause difficulties autobuilding gcc-multilib when e.g. libgcc1:i386 and 
libgcc1:amd64 get out of sync because of buildd delays.  I still don't see any 
good reason to keep the other multilib packages like lib32gmp10.)

In answer to Russ's concerns about sizeof(time_t) > sizeof(long): that hasn't 
really been a major concern in my experience (the biggest impact is that it 
causes gobject-introspection to FTBFS -- #699024).  The bigger porting 
concerns are code using x86_64 asm, and the fact that x32 doesn't support the 
sysctl(2) interface.  On the latter point, I get the feeling that might be a 
result of another of Linus' decrees ("new architectures shall not support this 
interface which was obsolete from the moment it was introduced"), though 
that's just a pure guess.  Oh, and then there's the multitude of build 
failures because of the package's copy of libtool being out of date.
-- 
Daniel Schepler


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2694027.5QWCrBo70u@frobozz

DebianBootstrap supported in which Debian suites?

[Jonas Smedegaard]

Quoting Paul Wise (2013-06-07 05:17:46)
> I would suggest the approach taken by the recent GSoC projects related 
> to bootstrapping new ports. Multi-stage builds. First stage without 
> docs and second stage with docs. Only the second stage gets uploaded 
> to Debian.
> 
> http://wiki.debian.org/DebianBootstrap

Above wiki page seems to recommend using  syntack in 
Build-depends: lines which I believe is not supported as far back as 
oldstable (if in any official Debian suite at all), and references 
bug#661538 and #661537 still open.

What to do *today* to express bootstrapping alternatives to circumvent 
circular build-dependencies?

My concrete need is simpler than some, as it needs no special flags at 
build-time: I want librdf-trine-perl to enable most possible optional 
parts of its testsuite, including some parts which themselves 
build-depend on librdf-trine-perl.

What I will do for now is to just add those extra build-dependencies and 
add a note to README.source which build-dependencies can be manually 
dropped in a custom bootstrap build.  I realize how painful it is for 
those needing to bootstrap, but sadly neither DebianBootstrap nor 
CircularBuildDependencies provide concrete help for package developers 
at the moment, it seems.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: How should we do for font-adobe-copyrighted-fragment error?

[Bastien ROUCARIES]

Le 7 juin 2013 09:24, "Atsuhito Kohda"  a
écrit :
>
> On Thu, 6 Jun 2013 10:21:05 +0200, Bastien ROUCARIES wrote:
>
> > I have contacted adobe and they are willing to relicense see main bug
> > report.
>
> It seems it will happen not so soon.
>
> > From my point of view the second one should be corrected and is serious
and
> > render the package even non suitable for non free.  We are violating the
> > license from adobe...
>
> Hmm, I'm not sure if I can correct the problem soon.
>
> Furthere, under the hypothesis that adobe will relicense,
> we can upload the package when we correct the problem?

The second point is not about adobe the second point is about copying code
without credit and when that code is not public domain. And even into the
public domain case at least in Europe due to moral right you should credit
the original author.

So you need to correct the no credit part even if the code if the resulting
code is non free.

After release team or ftpmaster decide

>
> Thanks for your advice.
> Best regards,   2013-6-7(Fri)
>
> --
>  Debian Developer - much more I18N of Debian
>  Atsuhito Kohda 
>  Department of Math., Univ. of Tokushima
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
listmas...@lists.debian.org
> Archive:
http://lists.debian.org/20130607.162413.1798446560061322549.atsuhito@at-SVT
>

Re: How should we do for font-adobe-copyrighted-fragment error?

[Bastien ROUCARIES]

Le 7 juin 2013 09:28, "Atsuhito Kohda"  a
écrit :
>
> Hi all,
>
> On Thu, 6 Jun 2013 11:24:57 +0200, Holger Levsen wrote:
>
> >> I remembered that there were discussions about proprietry
> >> code of adobe in Nov. 2012 but don't understand the conclusion.
> >
> > #694308 is the bug tracking this, which should also have more info.
>
> Yes, but it looks to me there is not practical information.

Did you see the wiki?
>
> Thanks for your advice.
> Best regards,   2013-6-7(Fri)
>
> --
>  Debian Developer - much more I18N of Debian
>  Atsuhito Kohda 
>  Department of Math., Univ. of Tokushima
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
listmas...@lists.debian.org
> Archive:
http://lists.debian.org/20130607.162827.351644749507448954.atsuhito@at-SVT
>

Re: DebianBootstrap supported in which Debian suites?

[Wookey]

+++ Jonas Smedegaard [2013-06-07 17:24 +0200]:
> Quoting Paul Wise (2013-06-07 05:17:46)
> > I would suggest the approach taken by the recent GSoC projects related 
> > to bootstrapping new ports. Multi-stage builds. First stage without 
> > docs and second stage with docs. Only the second stage gets uploaded 
> > to Debian.
> > 
> > http://wiki.debian.org/DebianBootstrap
> 
> Above wiki page seems to recommend using  syntack in 
> Build-depends: lines which I believe is not supported as far back as 
> oldstable (if in any official Debian suite at all), and references 
> bug#661538 and #661537 still open.

Correct. It is not supported in any debian suite yet. We do expect it
to be supported in jessie, but probably with a revised syntax. (See
http://debian.2.n7.nabble.com/build-profile-syntax-ideas-td2918264.html)
We are trying to finalise this now (stalled on me currently for which
I apologise to those with an interest).

> What to do *today* to express bootstrapping alternatives to circumvent 
> circular build-dependencies?

You might be able to use alternative B-Ds:
Build-depend: foo | foo-minimal
but this only covers some cases.

In general we don't have a mechanism to do this _in the archive_ until
build-profiles are supported (or at least ignored by B-D parsing tools)

You can bootstrap happily using local builds and local tools that
support profile builds. Existing patches here:
http://people.debian.org/~wookey/bootstrap/patches/profiles/

Then just upload the final builds, and sources with the profile info
only encoded as comments.

> My concrete need is simpler than some, as it needs no special flags at 
> build-time: I want librdf-trine-perl to enable most possible optional 
> parts of its testsuite, including some parts which themselves 
> build-depend on librdf-trine-perl.
> 
> What I will do for now is to just add those extra build-dependencies and 
> add a note to README.source which build-dependencies can be manually 
> dropped in a custom bootstrap build.  I realize how painful it is for 
> those needing to bootstrap, but sadly neither DebianBootstrap nor 
> CircularBuildDependencies provide concrete help for package developers 
> at the moment, it seems.

Agreed. And comments in the control file about this are _extremely_
helpful to people doping this work who are clueless about the details
of the package in question.

Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130607155548.gw14...@stoneboat.aleph1.co.uk

Re: NDEBUG when building packages?

[Hendrik Sattler]

Mathieu Malaterre  schrieb:

>On Sat, Feb 23, 2013 at 11:09 AM, Vincent Cheng
> wrote:
>> On Sat, Feb 23, 2013 at 1:39 AM, Mathieu Malaterre 
>wrote:
>>> On Fri, Feb 22, 2013 at 9:52 PM, Russ Allbery 
>wrote:
 Ian Jackson  writes:
> Mathieu Malaterre writes ("Re: NDEBUG when building packages?"):

>> In that case, this should really be clarified. A lot of
>debian/cmake
>> packages are actually doing:

>> -DCMAKE_BUILD_TYPE:STRING=Release

>> within there debian/rules files. This settings by default
>compiles
>> with: `-O3 -DNDEBUG`

> OMG WTF BBQ

> Certainly -DNDEBUG should never be used unless upstream explicitly
>say
> that it's intended to be supported, and usually not even then.

 Also, -O3 is generally considered rather iffy.  It's not very
>well-tested
 and in various versions of GCC it tended to make the code slower,
>not
 faster (usually because it unrolled loops too far and blew the CPU
>cache).
 It's also had various code generation bugs from time to time.

 I wouldn't use -O3 without benchmarking of that specific code to
>confirm
 that it really improves matters.
>>>
>>> Seems like everyone agreed. I'll report a bug to lintian package to
>>> have it check for this string in d/rules:
>>>
>>>
>http://codesearch.debian.net/search?q=DCMAKE_BUILD_TYPE:STRING%3DRelease
>>
>> We should also suggest that packages use
>> -DCMAKE_BUILD_TYPE=RelWithDebInfo instead (-g -O2). In fact, I think
>> that this would be a sensible default for packages using debhelper's
>> cmake integration. Sounds like another wishlist bug for debhelper...
>
>cmake from sid makes it even harder. RelWithDebInfo now contains
>-DNDEBUG ... I have to source-upload all my packages :(
>
>$ grep NDEBUG ChangeLog.manual
> Add -DNDEBUG to RelWithDebInfo flags where where Release flags had it.
>
>
>The solution (backward compat) is now:
>
>Either do *not* define CMAKE_BUILD_TYPE, or define CMAKE_BUILD_TYPE to
>Debug (and hope -DNDEBUG does not creep in ever)
>
>2cts

Or just define CMAKE_C_FLAGS properly and don't rely on the default values. 
It's not that hard, actually.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/4965467d-46cf-4b56-979c-480b84403...@email.android.com

Re: On accepting pre-generated doc from upstream

[Don Armstrong]

On Thu, 06 Jun 2013, Lisandro Damián Nicanor Pérez Meyer wrote:
> Building the full doc could be done in two ways:
> 
> - Using the full source tarball. Saddly this means having to compile most of 
> it in order to get the tools for building the doc, or hacking far too much 
> the 
> build system to do something else.
> 
> - Build each submodule's doc.

The problem with using the pre-packaged documentation instead of
building it, however, is that you'll have to constantly check that the
pre-packaged documentation actually matches the source that Debian is
distributing.

Not to mention the fact that it makes it far more difficult to accept
Debian-specific packages (or upstream patches) to the documentation if
the packages do not actually build the documentation.

-- 
Don Armstrong  http://www.donarmstrong.com

I learned really early the difference between knowing the name of
something and knowing something
 -- Richard Feynman "What is Science" Phys. Teach. 7(6) 1969


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130607181701.gt26...@rzlab.ucr.edu

Re: NDEBUG when building packages?

[Russ Allbery]

Jonas Smedegaard  writes:
> Quoting Stephen M. Webb (2013-06-07 14:29:52)

>> Having debug symbols not matching the runtime would cause a great deal 
>> of trouble.  If you're expecting a lot of debugging, try the new -Og 
>> switch.

>> One build pass and let dh_strip create the debug symbols package for
>> you.  Unless you're not using dh, in which case your build system is
>> probably already broken and needs to get fixed first.

> Fud!

> Please support your "dh is a silver bullet" meme with some concrete 
> references.

I'm pretty sure Stephen just meant "debhelper" where he said "dh".  No
need to get excited.  :)  CDBS of course also uses debhelper, and hence
has the same capability.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87sj0tbwqj@windlord.stanford.edu

Re: Why not to let all DDs to execute "gb"-command

[Tollef Fog Heen]

]] Nicolas Dandrimont 

> The "accepted by DSA part" is a bit complicated. We didn't really want to
> bother one of the busiest teams in Debian when the software wasn't even
> packaged, and, when it came up, I felt that the reception of the idea of
> using fedmsg was a bit lukewarm. I think we should be able to work things out
> when and if we have a working proof of concept.

>From what I remember, we did have some questions about how some unique
challenges in Debian's infrastructure will be solved, yes.  I don't
think I've seen completely satisfactory answers about it yet either, but
I'd need to go digging to be entirely sure.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87k3m5sqgq@xoog.err.no

Re: NDEBUG when building packages?

[Jonas Smedegaard]

Quoting Russ Allbery (2013-06-07 20:29:24)
> Jonas Smedegaard  writes:
> > Quoting Stephen M. Webb (2013-06-07 14:29:52)
> 
> >> Having debug symbols not matching the runtime would cause a great 
> >> deal of trouble.  If you're expecting a lot of debugging, try the 
> >> new -Og switch.
> 
> >> One build pass and let dh_strip create the debug symbols package 
> >> for you.  Unless you're not using dh, in which case your build 
> >> system is probably already broken and needs to get fixed first.
> 
> > Fud!
> 
> > Please support your "dh is a silver bullet" meme with some concrete 
> > references.
> 
> I'm pretty sure Stephen just meant "debhelper" where he said "dh".  No 
> need to get excited.  :) CDBS of course also uses debhelper, and hence 
> has the same capability.

Hmm, right - point taken.  I read it as "if you're not leaving it to dh 
sequencer to stitch things automagically together..." but that sure 
isn't what is quoted above, nor the only possible interpretation, so 
I'll lean back in my couch and think of nicer alternatives :-)

...and for the record, CDBS only *optionally* uses debhelper, leaving 
plenty of room for shooting oneself in the foot if that's desired. ;-)


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#711554: ITP: pyhst -- High Speed Tomographic reconstruction controled from Python

[Jerome Kieffer]

Package: wnpp
Severity: wishlist
Owner: Jerome Kieffer 

  Package name: pyhst
  Version : 2.0.
  Upstream Author : Alessandro Mirone 
  URL : https://forge.epn-campus.eu/projects/pyhst2
  License : GPL
  Programming Lang: C, Python, CUDA
  Description : High Speed Tomographic reconstruction controled from Python
The PyHST2 code is in service at ESRF for phase-contrast and absorption
tomography. This code has been engineered to sustain the high data flow typical
of the third generation synchrotron facilities by adopting a distributed and
pipelined architecture. The code implements, beside a default filtered
backprojection reconstruction, iterative reconstruction techniques with
a-priori knowledge. These latter are used to improve the reconstruction quality
or in order to reduce the required data volume and reach a given quality goal.
The implemented a-priori knowledge techniques are based on the total variation
penalisation and a new recently found convex functional which is based on
overlapping patches.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130607202436.19141.38328.report...@patagonia.fournet.lan

Re: NDEBUG when building packages?

[Kurt Roeckx]

On Fri, Jun 07, 2013 at 07:34:21AM -0400, Kumar Appaiah wrote:
> On Fri, Jun 07, 2013 at 11:54:49AM +0200, Mathieu Malaterre wrote:
> > cmake from sid makes it even harder. RelWithDebInfo now contains
> > -DNDEBUG ... I have to source-upload all my packages :(
> > 
> > $ grep NDEBUG ChangeLog.manual
> >   Add -DNDEBUG to RelWithDebInfo flags where where Release flags had it.
> > 
> > 
> > The solution (backward compat) is now:
> > 
> > Either do *not* define CMAKE_BUILD_TYPE, or define CMAKE_BUILD_TYPE to
> > Debug (and hope -DNDEBUG does not creep in ever)
> 
> While we're at it, could you please let me know what is the best
> practice for package builds that generate debug symbol packages?
> Ideally, I would hapve to rebuild the whole package TWICE, once with
> -O0 -g, and the other time with -O2, right?
> 
> Currently, I don't bother with this, since the the debug library with
> -O2 is still useful, other than the odd "optimized out" messages.

As I understand it, with dwarf 4 you should see less problems
trying to debug optimised programs.  Dwarf 4 is enabled by default
in gcc 4.8 and supported by gdb 7.5.


Kurt


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130607211252.ga8...@roeckx.be

Re: x32 "half"arrived... now what?

[Kurt Roeckx]

On Fri, Jun 07, 2013 at 09:49:00AM +, Thorsten Glaser wrote:
> Russ Allbery  debian.org> writes:
> 
> > Be aware that x32 has sizeof(time_t) > sizeof(long), so you should expect
> 
> So has MirBSD/i386 (since 2004-06-19) and NetBSD (since roughly a year).
> 
> Most frequent thing is format specifiers when struct tm.tm_year is time_t
> instead of long (which is a requirement for time_t to be able to round-trip
> through struct tm, which is required by quite some software).

tm_year should be an int, not a time_t or long.  Note that it
counts in years, and so even a 16 bit int isn't going to cause
much problems for tm_year.


Kurt


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130607212217.gb8...@roeckx.be

Re: x32 "half"arrived... now what?

[Thorsten Glaser]

Kurt Roeckx dixit:

>tm_year should be an int, not a time_t or long.  Note that it

POSIX says it “must” be a long…

>counts in years, and so even a 16 bit int isn't going to cause
>much problems for tm_year.

… but I disagree. All time_t seconds-since-the-epoch values
need (in practice) to round-trip through “struct tm”, which
requires tm_year to be of a type of the magnitude time_t has:

tg@blau:~ $ cat x.c
#include 
#include 
#include 
int main(void) { struct tm *tm; time_t tmax = LLONG_MAX; tm = gmtime(&tmax); 
printf("%lld\n", (long long)tm->tm_year); return (0); }
tg@blau:~ $ ./a.out
292277024696

This (0x44.0D11.77B8) doesn’t fit into 32 bits any more.

bye,
//mirabilos
-- 
17:08⎜«Vutral» früher gabs keine packenden smartphones und so
17:08⎜«Vutral» heute gibts frauen die sind facebooksüchtig
17:10⎜«Vutral» aber auch traurig; früher warst du als nerd voll am arsch
17:10⎜«Vutral» heute bist du als nerd der einzige der wirklich damit klarkommt


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/pine.bsm.4.64l.1306072129560.3...@herc.mirbsd.org

Re: DebianBootstrap supported in which Debian suites?

[Johannes Schauer]

Hi,

I talked with Lisandro off-list. Apparently my idea applies to this problem so
I'm sharing it here for everybody. :)

Quoting Wookey (2013-06-07 17:55:48)
> In general we don't have a mechanism to do this _in the archive_ until
> build-profiles are supported (or at least ignored by B-D parsing tools)
> 
> You can bootstrap happily using local builds and local tools that
> support profile builds. Existing patches here:
> http://people.debian.org/~wookey/bootstrap/patches/profiles/
> 
> Then just upload the final builds, and sources with the profile info
> only encoded as comments.

As *-doc packages are arch:all you can also move the dependencies needed to
build the doc packages to Build-Depends-Indep.

One kind of build dependency which can be "dropped" in most cases to break
build dependency cycles are those build dependencies which only facilitate
building the documentation. But since binary packages containing documentation
packages are mostly arch:all, no build profiles and therefore no unsupported
 syntax is needed for this case. Adding the respective build
dependencies to Build-Depends-Indep solves the problem just as well. Using the
(yet unsupported and undecided upon) build profile syntax should be avoided if
the problem can also be solved by moving build dependencies to
Build-Depends-Indep.

So one thing every maintainer can do to help making bootstrapping of Debian
more simple is to make sure that all build dependencies which can go to
Build-Depends-Indep are also listed there. During bootstrapping we discard the
contents of the Build-Depends-Indep field as we are only interested in building
architecture dependent binary packages.

cheers, josch


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130607214206.3820.15475@hoothoot

Re: Why not to let all DDs to execute "gb"-command

[Matthias Klumpp]

2013/6/7 Tollef Fog Heen :
> ]] Nicolas Dandrimont
>
>> The "accepted by DSA part" is a bit complicated. We didn't really want to
>> bother one of the busiest teams in Debian when the software wasn't even
>> packaged, and, when it came up, I felt that the reception of the idea of
>> using fedmsg was a bit lukewarm. I think we should be able to work things out
>> when and if we have a working proof of concept.
>
> >From what I remember, we did have some questions about how some unique
> challenges in Debian's infrastructure will be solved, yes.  I don't
> think I've seen completely satisfactory answers about it yet either, but
> I'd need to go digging to be entirely sure.
At the Tanglu Debian derivative (which is just in formation right now)
we build packages using Jenkins CI at the moment, due to this issue
and wanna-build having problems to build source-only packages and a
few other issues (difficult to set-up, weird handling of buildlogs and
some other related issues)
Jenkins isn't perfect either, so I am currently aiming to adjust
buildbot for our needs, which might be a solution (and it easier to
handle than a wb infrastructure, and can be integrated with the
existing Python tools).
Using Debian infrastructure outside of Debian is really difficult
sometimes, because it grew with Debian and many parts of it are
designed with a different image of Debian in mind, when it was much
smaller. But there is great work going on in maintaining and improving
infrastructure :-) (after digging into it, appreciate the work all the
teams do even more!)
In terms of infrastructure, IMHO Ubuntu did really well with the idea
of Launchpad as integrated solution. I also like the messaging idea
for Debian, but it might need some plan which parts of the
infrastructure it will cover and how implementation could happen
without too much extra work for the DSA.
Wasn't there a GSoC project about it, or did I misread that?
Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAKNHny8d7B=voynxj75u1k_vpvw_s8is2kzyefk__oodvtc...@mail.gmail.com

Re: x32 "half"arrived... now what?

[Kurt Roeckx]

On Fri, Jun 07, 2013 at 09:37:45PM +, Thorsten Glaser wrote:
> Kurt Roeckx dixit:
> 
> >tm_year should be an int, not a time_t or long.  Note that it
> 
> POSIX says it "must" be a long...

It doesn't say so here.  It has it as an int.

Also note that time_t didn't have a requirement to be an integer
type, but as far as I know it does now.  And you really want an
integer type for the values in struct tm.

> >counts in years, and so even a 16 bit int isn't going to cause
> >much problems for tm_year.
> 
> ... but I disagree. All time_t seconds-since-the-epoch values
> need (in practice) to round-trip through "struct tm", which
> requires tm_year to be of a type of the magnitude time_t has:

If you add that requirement, it can be upto 24 bit smaller than
time_t.  But as far as I know, there is no such requirement.  In
fact POSIX defines an error code for that case.

> tg@blau:~ $ cat x.c
> #include 
> #include 
> #include 
> int main(void) { struct tm *tm; time_t tmax = LLONG_MAX; tm = gmtime(&tmax); 
> printf("%lld\n", (long long)tm->tm_year); return (0); }
> tg@blau:~ $ ./a.out
> 292277024696

tm should be NULL in this case, an errno EOVERFLOW.  If that's not
the case I suggest you file a bug against libc.  It's at least
what I get here.


Kurt


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130607220656.ga12...@roeckx.be

Bug#711570: ITP: libsdl2-mixer -- Mixer library for SDL2

[Manuel A. Fernandez Montecelo]

Package: wnpp
Severity: wishlist
Owner: Debian SDL packages maintainers 


* Package name: libsdl2-mixer
  Version : 2.0.0~rc1
  Upstream Author : Sam Lantinga 
* URL : http://www.libsdl.org/tmp/SDL_mixer/
* License : zlib/linpng
  Programming Lang: C
  Description : Mixer library for SDL2

 SDL_mixer is a sample multi-channel audio mixer library.  It supports any
 number of simultaneously playing channels of 16 bit stereo audio, plus a single
 channel of music, mixed by the popular FLAC, MikMod MOD, Timidity MIDI, Ogg
 Vorbis, and SMPEG MP3 libraries.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130607223302.16014.514.report...@lugh.itsari.org

Bug#711571: ITP: libsdl2-net -- Network library for SDL2

[Manuel A. Fernandez Montecelo]

Package: wnpp
Severity: wishlist
Owner: Debian SDL packages maintainers 


* Package name: libsdl2-net
  Version : 2.0.0~rc1
  Upstream Author : Sam Lantinga 
* URL : http://www.libsdl.org/tmp/SDL_net/
* License : zlib/linpng
  Programming Lang: C
  Description : Network library for SDL2

 This is a small, low-level, cross-platform networking library, that can be used
 with the Simple DirectMedia Layer library.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130607223614.16117.8110.report...@lugh.itsari.org

Re: x32 "half"arrived... now what?

[Thorsten Glaser]

Kurt Roeckx dixit:

>If you add that requirement, it can be upto 24 bit smaller than
>time_t.  But as far as I know, there is no such requirement.  In

Sure. As I was saying, software in practice wants that,
such as the mktime test from gnulib.

bye,
//mirabilos
-- 
“It is inappropriate to require that a time represented as
 seconds since the Epoch precisely represent the number of
 seconds between the referenced time and the Epoch.”
-- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/pine.bsm.4.64l.1306072241120.3...@herc.mirbsd.org

Re: x32 "half"arrived... now what?

[Ben Hutchings]

On Fri, 2013-06-07 at 22:41 +, Thorsten Glaser wrote:
> Kurt Roeckx dixit:
> 
> >If you add that requirement, it can be upto 24 bit smaller than
> >time_t.  But as far as I know, there is no such requirement.  In
> 
> Sure. As I was saying, software in practice wants that,
> such as the mktime test from gnulib.

That is not software in practice, that is an incorrect test case.

Ben.

-- 
Ben Hutchings
Theory and practice are closer in theory than in practice.
- John Levine, moderator of comp.compilers


signature.asc
Description: This is a digitally signed message part

Re: DebianBootstrap supported in which Debian suites?

[Lisandro Damián Nicanor Pérez Meyer]

On Friday 07 June 2013 23:42:06 Johannes Schauer wrote:
> Hi,
> 
> I talked with Lisandro off-list. Apparently my idea applies to this problem
> so I'm sharing it here for everybody. :)

As a follow-up, in the specific of Qt5, I'm doing the following:

- I build arch: all packages from qtbase and qttools and push them to a 
private repo.
- I re build qtbase and qttools, this time with arch: all packages too, 
sourcing the private repo (maybe I can just go for arch: all). I push them to 
the private repo.
- I build every other Qt package with their docs. But as docs are linked 
between them, I push them to the private repo and...
- I finally build all the packages again, upload.

I have not yet fully implemented the two last steps, but according to my tests 
it will work :)

This should be really necessary on every minor (not patch) upstream release.

Kinds regards, Lisandro.

-- 
Si vives cada día de tu vida como si fuera el último,
algún día realmente tendrás razón.
  Steve Jobs

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.

Re: NDEBUG when building packages?

[Kumar Appaiah]

On Fri, Jun 07, 2013 at 08:29:52AM -0400, Stephen M. Webb wrote:
> Having debug symbols not matching the runtime would cause a great deal of 
> trouble.  If you're expecting a lot of
> debugging, try the new -Og switch.
> 
> One build pass and let dh_strip create the debug symbols package for you.  
> Unless you're not using dh, in which case
> your build system is probably already broken and needs to get fixed first.

I see your point. I already use dh_strip, but I think I'll stick with -O2.

Kumar
-- 
Whoa...I did a 'zcat /vmlinuz > /dev/audio' and I think I heard God...
-- mikecd on #Linux


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130608050446.gb...@bluemoon.alumni.iitm.ac.in

Re: NDEBUG when building packages?

[Kumar Appaiah]

On Fri, Jun 07, 2013 at 11:12:52PM +0200, Kurt Roeckx wrote:
> > Currently, I don't bother with this, since the the debug library with
> > -O2 is still useful, other than the odd "optimized out" messages.
> 
> As I understand it, with dwarf 4 you should see less problems
> trying to debug optimised programs.  Dwarf 4 is enabled by default
> in gcc 4.8 and supported by gdb 7.5.

Thanks. This is useful to know!

Kumar
-- 
It's computer hardware, of course it's worth having 
-- Espy on #Debian


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130608050352.ga...@bluemoon.alumni.iitm.ac.in

Re: x32 “half” arrived… now what?

[Paul Wise]

On Fri, Jun 7, 2013 at 11:03 PM, Daniel Schepler wrote:

> (Sorry about the lack of threading... for some reason I'm unable to find the
> links to download mbox archives for replying to the messages.)

The Debian HTML archives list message-ids and have mailto: reply links
that include References/In-Reply-To headers that include them. So,
just click the appropriate reply link and it will work fine as long as
you have an MUA that supports mailto: links.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caktje6ghtphvftgfey+-kwz8-r2zafdsm2rpokzfzxve6bj...@mail.gmail.com