Bug#678100: ITP: salome-{kernel,gui,med,geom,paravis,..} -- integration platform for numerical simulation
Package: wnpp
Severity: wishlist
Owner: Julien Cristau
* Package name: salome-{kernel,gui,med,geom,paravis,..}
Version : 6.5.0
Upstream Author : CEA, EDF R&D, Open CASCADE
* URL : http://www.salome-platform.org/
* License : mostly LGPL
Programming Lang: C++, Python
Description : integration platform for numerical simulation
Salomé is a pre- and post-processor for numerical simulations. It can
import CAD files in IGES and STEP formats, facilitates component
integration in heterogeneous systems, and has a user-friendly GUI as
well as a Python console with all of the platform functionality.
An earlier version used to be in sid as the 'salome' source package, but
was removed early this year. I'm planning on reintroducing it in
smaller pieces in the hope it'll be more manageable.
Cheers,
Julien
--
Julien Cristau
Logilab http://www.logilab.fr/
Informatique scientifique & gestion de connaissances
--
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/20120619082917.ga16...@crater2.logilab.fr
Re: Malloc and security
On Mon, Jun 18, 2012 at 09:38:15PM +0100, Ben Hutchings wrote: > On Mon, Jun 18, 2012 at 09:25:51PM +0100, Jamie White wrote: > > Hiya > > > > Just a quick question, which malloc, is there anyway that this > > function (used in C) could allocate memory into already allocated > > memory, such as the stack - or code space! > > Assuming that the program uses memory correctly, no. But if the > program has a bug that causes it to write to unallocated memory, it > could corrupt the memory allocator's state so that malloc later > returns memory that has already been allocated. valgrind is a wonderful tool for debugging this kind of errors. -- I was born an ugly, dumb and work-loving child, then an evil midwife replaced me in the crib. signature.asc Description: Digital signature
Re: Announce: script to automatically restart services after update of dependencies
Tomas Pospisek writes: > On Mon, 18 Jun 2012 14:10:46 +0100, Ben Hutchings > wrote: >> On Mon, 2012-06-18 at 20:40 +0800, Paul Wise wrote: >>> On Mon, Jun 18, 2012 at 5:40 PM, Tomas Pospisek wrote: >>> >>> > I want to announce restart-services here [1][2]. It's a script >>> > that tries to restart all services that have had their >>> > dependency packages updated. This is primarily useful when >>> > security-relevant libraries get security releases. >>> > >>> > It's using checkrestart from the debian-goodies package to do >>> > most of its work. >>> > >>> > Together with the unattended-upgrades package it is saving me >>> > a lot of system maintenance time, thus I am announcing it here >>> > in the hope that it will save others a lot of time as well. >>> >>> Sounds useful, maybe put it in the debian-goodies package? > > I've proposed this to Javier [3] and it's been quite well received :-) > >> What, yet another feature reserved for those in the know? Surely we >> should be doing this by default. > > I agree. Could you suggest a way forward? Currently I'm aiming for > debian-goodies, however maybe unattended-upgrades would be a better fit. > However I think really it should go into apt-level inftrastructure. > > ? I want to automatically restart services so that / and /usr can be remounted read-only again. But I don't want unattended upgrades. So for me debian-goddies is a better fit. Easy enough to add it then to the apt config. >>> Also, please blacklist gdm3 and dbus since restarting them currently >>> kills GNOME sessions (and probably other user desktop sessions started >>> by gdm3). > > Noted. I'll discuss this with Javier. > > PS: Sorry Ben for also replying in private to you. I'll have to get used > to mailing lists (and my web mail client) again :-o > > [3] http://bugs.debian.org/676509 MfG Goswin -- 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/87r4tbd2ha.fsf@frosties.localnet
Re: Malloc and security
Ben Hutchings writes: > On Mon, Jun 18, 2012 at 09:25:51PM +0100, Jamie White wrote: >> Hiya >> >> Just a quick question, which malloc, is there anyway that this >> function (used in C) could allocate memory into already allocated >> memory, such as the stack - or code space! > > Assuming that the program uses memory correctly, no. But if the > program has a bug that causes it to write to unallocated memory, it > could corrupt the memory allocator's state so that malloc later > returns memory that has already been allocated. Actually I believe this is undefined in C. Malloc may verry well oveflow the heap region and run into the stack or code going by the C standard. But eglibc malloc uses sbrk() and mmap() to get memory from the kernel and those functions will not return space already allocated by the stack or code. That is probably true for every libc on every modern Unix system. MfG Goswin -- 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/87mx3zd24k.fsf@frosties.localnet
Re: Summary: Moving /tmp to tmpfs makes it useless
Wouter Verhelst writes: > On Wed, Jun 13, 2012 at 04:14:52AM +0300, Serge wrote: >> User cannot break the system filling /tmp on disk. But he can do that >> if he fills /tmp on tmpfs. So /tmp on tmpfs adds one more point of >> failure for servers. > > No, that's not true. The real danger in filling up /tmp is not that > other processes can't write temporary files anymore (causing a minority > of processes to hang or die; those who just happen to need temporary > storage at that point in time), but that no process can write any file > anymore (causing a significant majority of processes to hang or die). So tmpfs for /tmp increases the chance of accidentally filling up /tmp and causing a moderate failure but prevents malicious filling up of /tmp to cause wide spread failure. :) MfG Goswin -- 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/87ipend1nb.fsf@frosties.localnet
On the (ab)use of the Urgency field
Hi, I realise everyone's waiting for news of the freeze (we're working on it...) but please bear in mind that this is not an appropriate use of the Urgency field: * Urgency high to beat the freeze. As mentioned in the last mail we sent to d-d-a (and several at various points before that) if you have serious concerns that important updates to your package won't be included in the release, the correct approach is to talk to us, not try and work around us. The net effect of the above is more likely to be that the urgency will be overriden on the britney side as if the package had been uploaded with a lower urgency. Regards, Adam -- 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/381175f71668cfaf39ca8231141c2...@mail.adsl.funky-badger.org
Re: Announce: script to automatically restart services after update of dependencies
On Tue, 19 Jun 2012 12:23:45 +0200, Goswin von Brederlow wrote: > Tomas Pospisek writes: > >> On Mon, 18 Jun 2012 14:10:46 +0100, Ben Hutchings wrote: >>> On Mon, 2012-06-18 at 20:40 +0800, Paul Wise wrote: On Mon, Jun 18, 2012 at 5:40 PM, Tomas Pospisek wrote: > I want to announce restart-services here [1][2]. It's a script > that tries to restart all services that have had their > dependency packages updated. This is primarily useful when > security-relevant libraries get security releases. > > It's using checkrestart from the debian-goodies package to do > most of its work. > > Together with the unattended-upgrades package it is saving me > a lot of system maintenance time, thus I am announcing it here > in the hope that it will save others a lot of time as well. Sounds useful, maybe put it in the debian-goodies package? >> >> I've proposed this to Javier [3] and it's been quite well received :-) >> >>> What, yet another feature reserved for those in the know? Surely we >>> should be doing this by default. >> >> I agree. Could you suggest a way forward? Currently I'm aiming for >> debian-goodies, however maybe unattended-upgrades would be a better fit. >> However I think really it should go into apt-level inftrastructure. > > I want to automatically restart services so that / and /usr can be > remounted read-only again. But I don't want unattended upgrades. So for > me debian-goddies is a better fit. Easy enough to add it then to the > apt config. Point taken. However Ben argued, if I interpret him correctly, that services that depend on something (a library), should be restarted by default if that dependency gets updated and the user should not be required to install an "obscure" package to have that sane default behavior. This implies that an "apt-get install library" needs to trigger that restart. Which means that apt-get needs to depend on restart-services. So either restart-services and checkrestart should go into the apt package, or apt needs to depend on/recommend debian-goodies, which would currently pull in python, perl, curl, dialog and their respective dependencies. The later may be a technically working solution, but from a conceptual and a KISS point of view doesn't make sense to me. Is my conclusion correct so far? So if we want a "clean" solution, then checkrestart/restart-services would need to move into apt and get rid of the non-essential dependencies (get rewritten in shell or C). ? *t >> [3] http://bugs.debian.org/676509 -- 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/dd25736bb03f21cb838910bbfd35c...@mail.sp-metanet
Re: On the (ab)use of the Urgency field
[ > net effect of the above is more likely to be that the urgency will be > overriden on the britney side ... ?hmm? debian has a britney side? long blondish hair, well curved? niccce - *niie*--- :D *cough* freezes suck^^^ ] #hacky day folks ;) -- 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/4fe06e5f.4070...@gmx.net
Re: Announce: script to automatically restart services after update of dependencies
On Mon, 2012-06-18 at 23:47 +0200, Tomas Pospisek wrote: > On Mon, 18 Jun 2012 14:10:46 +0100, Ben Hutchings > wrote: > > On Mon, 2012-06-18 at 20:40 +0800, Paul Wise wrote: > >> On Mon, Jun 18, 2012 at 5:40 PM, Tomas Pospisek wrote: > >> > >> > I want to announce restart-services here [1][2]. It's a script > >> > that tries to restart all services that have had their > >> > dependency packages updated. This is primarily useful when > >> > security-relevant libraries get security releases. > >> > > >> > It's using checkrestart from the debian-goodies package to do > >> > most of its work. > >> > > >> > Together with the unattended-upgrades package it is saving me > >> > a lot of system maintenance time, thus I am announcing it here > >> > in the hope that it will save others a lot of time as well. > >> > >> Sounds useful, maybe put it in the debian-goodies package? > > I suggested that to Javier [3] and I think it was quite well received :-) > > > What, yet another feature reserved for those in the know? Surely we > > should be doing this by default. > > I agree. Can you recommend any way forward? Currently I'm aiming for > debian-goodies as Paul proposes. However there's also the > unattended-upgrades package, that'd maybe be an even better fit. > > However I think this really belongs somewhere on the level of apt? [...] I don't think this belongs in unattended-upgrades; whether you want services automatically restarted is orthogonal to whether you perform upgrades interactively or not. What I think would be most useful would be an APT hook (or built-in feature) enabled in a default installation that does: 1. Check for running processes that have the old libraries mapped 2. Depending on configuration, restart services (with the blacklist as suggested): - if set to always restart, then do - if set to never restart, then don't - if set to ask, then ask (through debconf) with a default of no (I think the default would be 'ask') 3. If not everything was restarted (e.g. gdm3 or non-service process), send mail to root saying what needs to be restarted later (How do you map from pid to service name when using sysvinit?) Also, the set of libraries to check could be restricted to those for which the upgrade had urgency=high. Ben. -- Ben Hutchings If more than one person is responsible for a bug, no one is at fault. signature.asc Description: This is a digitally signed message part
Re: Announce: script to automatically restart services after update of dependencies
Hello, On 2012-06-19 13:59, Tomas Pospisek wrote: > This implies that an "apt-get install library" needs to trigger that > restart. > Which means that apt-get needs to depend on restart-services. So either > restart-services and checkrestart should go into the apt package, or apt > needs > to depend on/recommend debian-goodies, which would currently pull in > python, > perl, curl, dialog and their respective dependencies. > > The later may be a technically working solution, but from a conceptual and > a > KISS point of view doesn't make sense to me. > > Is my conclusion correct so far? > > So if we want a "clean" solution, then checkrestart/restart-services would > need > to move into apt and get rid of the non-essential dependencies (get > rewritten in > shell or C). I believe this is a wrong layer for proposed functionality -- apt-get (libapt) is not the only high-level package manager for Debian. If I were you, I'd look into dpkg file triggers instead. Triggers will by the way automatically solve the problem that you don't restart a service 5 times if 5 libraries were upgraded. -- Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com C++ GNU/Linux developer, Debian Developer -- 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/20120619122924.GA20339@r500-debian
Re: new sections: education & metapackages
On Tue, Jun 19, 2012 at 12:55:42PM +0200, Jonas Smedegaard wrote: > On 12-06-19 at 08:48am, Andreas Tille wrote: > > > > I'm personally in favour of education because I assume that's where > > users might seek first. I have no idea whather I'm right with this > > assumption. > > > > BTW, did I said that Debian Edu packages need some more changes than > > just changing the section? > > I would say the opposite. Else "metapackages" would really mean > "metapackages of miscelanous topics not covered elsewhere" which I find > is not its purpose. > > If "metapackages" is nonsense specifically for educational stuff, then > I'd be happy to hear examples of when it is sensible. > > If, on the other hand, "metapackages" is generally considered nonsense > then I find it better to raise that discussion on debian-devel that by > discretely working against it. Fair point. My guess is that when the section was invented the Blends metapackages were not in the focus of the people inventing this. I'm basing my guess on the fact that they did not CCed debian-blends@l.d.o when deciding about this. So my plan was not to discretely working against the metapackages section but rather thinking that it is OK in the sense that "other types of metapackages" were just in mind. BTW, even if I'm not convinced about this specific section I would not have severe problems to move all metapackages into this section (besides changing debian-blends package quite short in time before freeze which is probably not a good idea). The rationale why I do not have a very strong opinion about this is, that I do not regard the section concept as very helpfull in the end and so I could live with any consistent structure. Actually one main reason for the Blends metapackages concept is to overcome the restrictions of the section concept. Kind regards Andreas. -- http://fam-tille.de -- 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/20120619123823.ge22...@an3as.eu
Re: On the (ab)use of the Urgency field
Adam D. Barratt writes ("On the (ab)use of the Urgency field"):
> I realise everyone's waiting for news of the freeze (we're working on
> it...) but please bear in mind that this is not an appropriate use of
> the Urgency field:
>
>* Urgency high to beat the freeze.
>
> As mentioned in the last mail we sent to d-d-a (and several at various
> points before that) if you have serious concerns that important updates
> to your package won't be included in the release, the correct approach
> is to talk to us, not try and work around us. The net effect of the
> above is more likely to be that the urgency will be overriden on the
> britney side as if the package had been uploaded with a lower urgency.
On previous occasions the release team have said that the freeze would
be applied with respect to the /upload/ date, rather than the
/migration/ date. Ie, packages uploaded before the freeze might
migrate afterwards unhindered, provided the other usual criteria were
satisfied.
Is this still the case ? If so then this kind of abuse of the Urgency
field is not just inappropriate but also pointless.
It would be nice if some of this kind of thing were documented in the
Developers' Reference or perhaps on the RM webpages.
Thanks,
Ian.
--
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/20448.30413.427373.68...@chiark.greenend.org.uk
Re: Announce: script to automatically restart services after update of dependencies
On Tue, 2012-06-19 at 15:29 +0300, Eugene V. Lyubimkin wrote: > Hello, > > On 2012-06-19 13:59, Tomas Pospisek wrote: > > This implies that an "apt-get install library" needs to trigger that > > restart. > > Which means that apt-get needs to depend on restart-services. So either > > restart-services and checkrestart should go into the apt package, or apt > > needs > > to depend on/recommend debian-goodies, which would currently pull in > > python, > > perl, curl, dialog and their respective dependencies. > > > > The later may be a technically working solution, but from a conceptual and > > a > > KISS point of view doesn't make sense to me. > > > > Is my conclusion correct so far? > > > > So if we want a "clean" solution, then checkrestart/restart-services would > > need > > to move into apt and get rid of the non-essential dependencies (get > > rewritten in > > shell or C). > > I believe this is a wrong layer for proposed functionality -- apt-get > (libapt) is not the only high-level package manager for Debian. > > If I were you, I'd look into dpkg file triggers instead. Triggers will > by the way automatically solve the problem that you don't restart > a service 5 times if 5 libraries were upgraded. But we still need one trigger per service? I don't think that's a good idea. Ben. -- Ben Hutchings If more than one person is responsible for a bug, no one is at fault. signature.asc Description: This is a digitally signed message part
Re: Announce: script to automatically restart services after update of dependencies
On 2012-06-19 14:01, Ben Hutchings wrote: > On Tue, 2012-06-19 at 15:29 +0300, Eugene V. Lyubimkin wrote: > > Hello, > > > > On 2012-06-19 13:59, Tomas Pospisek wrote: > > > This implies that an "apt-get install library" needs to trigger that > > > restart. > > > Which means that apt-get needs to depend on restart-services. So either > > > restart-services and checkrestart should go into the apt package, or apt > > > needs > > > to depend on/recommend debian-goodies, which would currently pull in > > > python, > > > perl, curl, dialog and their respective dependencies. > > > > > > The later may be a technically working solution, but from a conceptual and > > > a > > > KISS point of view doesn't make sense to me. > > > > > > Is my conclusion correct so far? > > > > > > So if we want a "clean" solution, then checkrestart/restart-services would > > > need > > > to move into apt and get rid of the non-essential dependencies (get > > > rewritten in > > > shell or C). > > > > I believe this is a wrong layer for proposed functionality -- apt-get > > (libapt) is not the only high-level package manager for Debian. > > > > If I were you, I'd look into dpkg file triggers instead. Triggers will > > by the way automatically solve the problem that you don't restart > > a service 5 times if 5 libraries were upgraded. > > But we still need one trigger per service? I don't think that's a good > idea. Not necessarily, I imagine there can be a package 'restart-services' which would declare a trigger on all dynamic libraries and then on trigger invocation it will check&restart needed services. That however indeed depends on some details of actual restart-services utilities and trigger processing which I don't know, so I'm just proposing that for evaluation. CC'ing debian-dpkg@ to hear an opinion of dpkg folks. Should that idea be not workable, I agree that using APT hooks might be a good alternative to hardcoding anything to libapt (which I object to). -- Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com C++ GNU/Linux developer, Debian Developer -- 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/20120619131348.GB20339@r500-debian
Re: On the (ab)use of the Urgency field
On Tue, 19 Jun 2012 14:19:43 +0200 marcel partap wrote: > [ > > net effect of the above is more likely to be that the urgency will be > > overriden on the britney side > ... ?hmm? debian has a britney side? long blondish hair, well curved? > niccce - *niie*--- :D > *cough* freezes suck^^^ ] > #hacky day folks ;) This kind of behaviour is obnoxious, sexist and repulsive. An apology on list is warranted and expected. If not, feel free not to bother with any involvement with Debian in the future. Debian is a diverse group, all of whom deserve your respect. "No matter how you identify yourself or how others perceive you: we welcome you. We welcome contributions from everyone as long as they interact constructively with our community." http://www.debian.org/intro/diversity Your comments above are destructive, not constructive. http://wiki.debian.org/AntiHarassment -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpzilNTARLPC.pgp Description: PGP signature
Lintian warning: hardening-no-fortify-functions & version numbering
Hi! I'm intending to package a new software for Debian [1]. I just completed most of the package work and have a lintian-error free package, but I still have a warning that is driving me crazy. I have read the output of lintian-info -t about hardening-no-fortify-functions, and it helps a lot. The software uses Cmake as build tool, and the "hardening-wrapper" solution solved some lintian warnings, but not the latest one. I have looked at the buld logs, and I can see that the CPPFLAGS "-D_FORTIFY_SOURCE=2" is included in all the compiler calls, but the warning is still present. What's the problem with this? My another question is about the version numbering: the software is still in development and they make a new minor version each week (approximately). Sometimes I need to package something that is in their repository but not still in a numbered version, so, I tried to use the latest known version and add a ~TIMESTAMPgit... to the minor version number, but debuild warns me about the version 0.1.0~2012..git-1 is less than 0.1.0. The latest thing is that I have seen several packages with ~TIMESTAMP (screen, by example): they add a alpha-numeric string after the "git" word... what does it mean? Where can I found some information about packaging directly from VCS? Best regard and thanks in advance -- José Luis Segura Lucas signature.asc Description: OpenPGP digital signature
Re: Lintian warning: hardening-no-fortify-functions & version numbering
On Tue, Jun 19, 2012 at 04:04:31PM +0200, José Luis Segura Lucas wrote: > I have read the output of lintian-info -t about > hardening-no-fortify-functions, and it helps a lot. The software uses > Cmake as build tool, and the "hardening-wrapper" solution solved some > lintian warnings, but not the latest one. Why do you need hardening-wrapper? You should use flags set by dpkg-buildflags. > I have looked at the buld logs, and I can see that the CPPFLAGS > "-D_FORTIFY_SOURCE=2" is included in all the compiler calls, but the > warning is still present. > > What's the problem with this? You should read http://bugs.debian.org/673112 mentioned in the lintian tag description and use hardening-check --verbose on binaries reported. If only memcpy and memmove are printed by hardening-check, you should ignore the warning. > My another question is about the version numbering: the software is > still in development and they make a new minor version each week > (approximately). Sometimes I need to package something that is in their > repository but not still in a numbered version, so, I tried to use the > latest known version and add a ~TIMESTAMPgit... to the minor version > number, but debuild warns me about the version 0.1.0~2012..git-1 is > less than 0.1.0. That's right, 0.1.0~2012..git-1 is less than 0.1.0. If you need versions that are greater than 0.1.0, use + instead of ~. > The latest thing is that I have seen several packages with ~TIMESTAMP > (screen, by example): they add a alpha-numeric string after the "git" > word... what does it mean? git-describe(1) > Where can I found some information about packaging directly from VCS? file:///usr/share/doc/git-buildpackage/manual-html/gbp.import.html#GBP.IMPORT.UPSTREAM-GIT (if you use git-buildpackage) -- WBR, wRAR signature.asc Description: Digital signature
Re: On the (ab)use of the Misogyny field
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dear Neil, Dear debian-devel list members, please accept my honest pardon for my infamous demeanor. It was meant as light-hearted joke, a mind fart - when I was done writing the three lines I almost ditched it, and obviously should have. After all, what does the one or two giggles it might have caused weigh against the affront inflicted on so many? Never again will I engage in activities that are > obnoxious, sexist and repulsive with regard to any form of public communication related to the Debian community - be it on- or offline! > Debian is a diverse group, all of whom deserve your respect. You are right, and that is why I truely love the project and endorse it whenever the opportunity arises. My intentions to become part of this powerful freedom force in the near future? Well, this may have been one lame joke too many - yet I still have some hope that may not be the case. Please except my sincere apology - especially the few brave and valuable developers of female gender, and those easily enraged - I meant no harm, and anyone offended is cordially invited to a beer, soft drink or chocolate bar at the very next occasion. If that does not go all the way, remaining debt will be repaid in code contributions. #Regards, Marcel. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJP4IlTAAoJEGXGsEqKOfvak9cQANGmNcdbTLC8BItjUDp5gpjZ EJhunbYIlIEA2c/TzZqKFsJLhsEDbSCFJ3qrj8Z2caqyGjyRTTnoj5ziObmkPmoQ cdqTfur5z5iRvktK7hkC/pSNbwUCShGPz7WZqz8hx7j8n6u/0rNL7jmnZ01BxsOP F10CzGIBNWzFR9AgzEEBahLf4yf3BDF1FiGb69IwzmQq4EYGR6sZb/SNhP7Y0dcR R2DOrUTXBuAA1SeuqD+t71//Krk96OKmkOxNAJMtuCcfJlKsBjGtnteWsVLmpX0Y tnIKmjzbNayq0tl6i7X7L0Tu2fhJzxihr9why020Xb1O1VcWzPMUBwSOLgXAK+so IsWTrkjujnV5Gpho2DQ846/xCek4tJCls3SvHyDpiwd7NhVBRaC3zh5+YFjSZAxf CbNZtWj4hHqjfs86bTjYQi60KHKhgr2+U0fyHkyK7UTbUaUPUItotaAj7oD6x6Mo KyNWFk6Ak6CA0s6Z0fEL2IQn7M24Z83vfXX7nblc+/eFlpA1exYTjsiQe9ldmCx1 Fy23yf4EKhc9l7e90wxuyvs7gi6JuxmtqJo2iFNdVs5QfJknoVOyvGlan3kPOGhb l/RKmZJIY9IXPBO9EtjrztMFmv+E0x/75I2TseSesnzA2wqqut4rG8mLM19HkBjZ ucXA6OkfuLz20oUnYpG5 =tZoL -END PGP SIGNATURE- -- 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/4fe0895d.6080...@gmx.net
Bug#678142: ITP: libiniparser -- stand-alone ini file parsing library
Package: wnpp Severity: wishlist Owner: Michael Stapelberg * Package name: libiniparser Version : 3.1 Upstream Author : Nicolas Devillard * URL : http://ndevilla.free.fr/iniparser/ * License : MIT/X11 Programming Lang: C Description : stand-alone ini file parsing library iniparser is a free stand-alone ini file parsing library. It is written in portable ANSI C and should compile anywhere. -- 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/20120619142023.30934.35182.report...@x200.zekjur.net
Build environment bug: 675125
Hi, I've an interesting problem: bug #675125. Its a grave bug against slang2, as it breaks jed, (and other things). slang2-2.2.14-12+ (in sid) breaks jed for certain locales (C is broken, *.UTF-8 look fine); but slang2_2.2.14-10 (in testing) looks fine. The trouble is, while downgrading to -10 fixes issues, _rebuilding_ -10 in sid results in a broken libslang2 ; i.e. the problem is not the slang2 package, but the build environment. So far i've tested with ncurses, locale from testing but haven't found the cause yet. While i'm still investigating, _something_ in the sid environment is the real culprit and I can't assign a bug to it yet until I pin it down. Has anyone seen a similar issue elsewhere, or got a hint as to how to handle it? I want to make sure we don't just freeze on the current slang but ship the broken environment. best regards Alastair -- Alastair McKinstry , , http://blog.sceal.ie Anyone who believes exponential growth can go on forever in a finite world is either a madman or an economist - Kenneth Boulter, Economist. -- 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/4fe08a9b.4090...@debian.org
Re: Lintian warning: hardening-no-fortify-functions & version numbering
El 19/06/12 16:10, Andrey Rahmatullin escribió: > Why do you need hardening-wrapper? You should use flags set by > dpkg-buildflags. Because that (http://wiki.debian.org/Hardening#Notes_for_packages_using_CMake), referred by lintian-info too. Using it I only need to define "export DEB_BUILD_HARDENING=1" on my debian/rules and it adds the CPPFLAGS to CFLAGS and CXXFLAGS (Cmake ignores CPPFLAGS). > You should read http://bugs.debian.org/673112 mentioned in the lintian tag > description and use hardening-check --verbose on binaries reported. If > only memcpy and memmove are printed by hardening-check, you should ignore > the warning. Done. I have emmove, memcpy and read... I will read this link to learn more about removing this warning. > That's right, 0.1.0~2012..git-1 is less than 0.1.0. If you need > versions that are greater than 0.1.0, use + instead of ~. Ok, thanks > git-describe(1) > > file:///usr/share/doc/git-buildpackage/manual-html/gbp.import.html#GBP.IMPORT.UPSTREAM-GIT > (if you use git-buildpackage) I don't use git-buildpackage and git describe on their repository returns a bit estrange string... $ git describe --tags v0.1.1-27-g55c0f4e Thanks for your quick help :-) -- José Luis Segura Lucas signature.asc Description: OpenPGP digital signature
Re: Lintian warning: hardening-no-fortify-functions & version numbering
On Tue, Jun 19, 2012 at 04:42:33PM +0200, José Luis Segura Lucas wrote: > > Why do you need hardening-wrapper? You should use flags set by > > dpkg-buildflags. > Because that > (http://wiki.debian.org/Hardening#Notes_for_packages_using_CMake), > referred by lintian-info too. Using it I only need to define "export > DEB_BUILD_HARDENING=1" on my debian/rules and it adds the CPPFLAGS to > CFLAGS and CXXFLAGS (Cmake ignores CPPFLAGS). I see several solutions there, and the hardening-wrapper one is in my opinion the worst one: it adds a build dependency and it uses own set of configuration variables, not compatible with dpkg-buildflags ones. > > file:///usr/share/doc/git-buildpackage/manual-html/gbp.import.html#GBP.IMPORT.UPSTREAM-GIT > > (if you use git-buildpackage) > I don't use git-buildpackage Then I don't understand what do you mean by "packaging directly from VCS". > and git describe on their repository > returns a bit estrange string... > > $ git describe --tags > v0.1.1-27-g55c0f4e I thought you've meant exactly the -27-g55c0f4e part. -- WBR, wRAR signature.asc Description: Digital signature
Re: Lintian warning: hardening-no-fortify-functions & version numbering
El 19/06/12 16:56, Andrey Rahmatullin escribió: > I see several solutions there, and the hardening-wrapper one is in my > opinion the worst one: it adds a build dependency and it uses own set of > configuration variables, not compatible with dpkg-buildflags ones. Yes, it adds a build-dependency... but it still use dpkg-buildflags, doesn't it? > Then I don't understand what do you mean by "packaging directly from VCS". I mean to package the software directly from a VCS version, instead for a tarball. Now, I'm getting the sources with git, generate a tarball myself with the appropriate name, put it in the parent directory and build the package. I think that it can be a way to avoid the manual tarball generation. I'm reading about git-buildpackage, because it can help. > > I thought you've meant exactly the -27-g55c0f4e part. > The problem are the "-", but I hope that when uploading to Debian they have a freeze stable version :-D -- José Luis Segura Lucas signature.asc Description: OpenPGP digital signature
Re: Lintian warning: hardening-no-fortify-functions & version numbering
On Tue, Jun 19, 2012 at 05:04:46PM +0200, José Luis Segura Lucas wrote: > > I see several solutions there, and the hardening-wrapper one is in my > > opinion the worst one: it adds a build dependency and it uses own set of > > configuration variables, not compatible with dpkg-buildflags ones. > Yes, it adds a build-dependency... but it still use dpkg-buildflags, > doesn't it? It uses dpkg-buildflags in addition to doing more or less the same in a different way. -- WBR, wRAR signature.asc Description: Digital signature
Re: Lintian warning: hardening-no-fortify-functions & version numbering
On Tue, Jun 19, 2012 at 04:04:31PM +0200, José Luis Segura Lucas wrote: > repository but not still in a numbered version, so, I tried to use the > latest known version and add a ~TIMESTAMPgit... to the minor version > number, but debuild warns me about the version 0.1.0~2012..git-1 is > less than 0.1.0. Use A~B only if this version should come before A - that is, for example, if you expect the next upstream release to be A. In your case, use A+B so the version comes after A in version order. > The latest thing is that I have seen several packages with ~TIMESTAMP > (screen, by example): they add a alpha-numeric string after the "git" > word... what does it mean? It's the beginning of the hash git uses to uniquely identify the version. You can see the full hash in, for example, git log, at the beginning of each patch: commit 2ff04fd5a95f36497bc8e8c6e44d70c474384ec2 Author: Antti-Juhani Kaijanaho Date: Mon Jun 18 23:26:59 2012 +0300 Add install-sh Signed-off-by: Antti-Juhani Kaijanaho In this case, the hash is the long string after the word "commit" on the first line, and I would use for example 2ff04 in the version number if I packaged this version as a git snapshot. > Where can I found some information about > packaging directly from VCS? git-buildpackage has excellent docs. You don't have to use the tools but they help. -- Antti-Juhani Kaijanaho, Jyväskylä, Finland http://antti-juhani.kaijanaho.fi/newblog/ http://www.flickr.com/photos/antti-juhani/ signature.asc Description: Digital signature
Bug#678168: ITP: python-astropy -- Core functionality for performing astronomy and astrophysics with Python
Package: wnpp Severity: wishlist Owner: Ole Streicher * Package name: python-astropy Version : 0.1 Upstream Author : Erik Tollerud * URL : http://astropy.org * License : BSD Programming Lang: Python, C Description : core functionality for performing astronomy and astrophysics with Python. The astropy package (alternatively known as the “core” package) contains various classes, utilities, and a packaging framework intended to provide commonly-used astronomy tools. It is expected to be extended by a number of "affilated packages" that are intended to work with the core package. The current release is a developer preview. Best Ole -- 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/4fe0c604.2020...@liska.ath.cx
Re: Build environment bug: 675125
Hi, > I've an interesting problem: bug #675125. > Its a grave bug against slang2, as it breaks jed, (and other things). > slang2-2.2.14-12+ (in sid) breaks jed for certain locales (C is broken, > *.UTF-8 look fine); > but slang2_2.2.14-10 (in testing) looks fine. > > The trouble is, while downgrading to -10 fixes issues, _rebuilding_ -10 > in sid results in a > broken libslang2 ; i.e. the problem is not the slang2 package, but the > build environment. > So far i've tested with ncurses, locale from testing but haven't found > the cause yet. > > While i'm still investigating, _something_ in the sid environment is the > real culprit and > I can't assign a bug to it yet until I pin it down. Has anyone seen a > similar issue elsewhere, > or got a hint as to how to handle it? I want to make sure we don't just > freeze on the current slang but ship the > broken environment. Try gcc/g++ 4.6 instead of 4.7. Maybe check if "S-Lang load path" (wherever that is stored) is initialized in a sane way. I had a similar issue where an integer was 0 all the time - although not being initialized with something useful - which changed with gcc 4.7, then it was just a random value :) -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- 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/4fe0e915.1090...@bzed.de
Re: Build environment bug: 675125
Hello, On Tue, 19 Jun 2012 23:03:17 +0200 Bernd Zeimetz wrote: > Try gcc/g++ 4.6 instead of 4.7. Maybe check if "S-Lang load > path" (wherever that is stored) is initialized in a sane way. I had a > similar issue where an integer was 0 all the time - although not > being initialized with something useful - which changed with gcc 4.7, > then it was just a random value :) By the way, it might be a good idea to fill .bss section with random values intentionally for debug builds to detect non-properly-initialised things more effectively :) -- WBR, Andrew signature.asc Description: PGP signature
Re: Build environment bug: 675125
Andrew Shadura wrote: > By the way, it might be a good idea to fill .bss section with random > values intentionally for debug builds to detect non-properly-initialised > things more effectively :) Variables in the .bss section will by definition get initialized to 0. For example, a C variable defined as "static typename varname;" must get initialized to 0, and the compiler and linker will stick it in the .bss section expecting that it will end up with a value of 0 at runtime. That represents a defined property of the standard, not an implementation quirk. So, the .bss section must get initialized to 0, not to random values, whether in a debug build or not. - Josh Triplett -- 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/20120619221131.GA27346@leaf
Report from the Bug Squashing Party in Salzburg
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 For those who do not read Planet Debian, here is the report from the Debian BSP in Salzburg (markdown/ikiwiki source, sorry for not re-formatting it :)) Participation and Results - --- - From June 15-17th we held a Debian BugSquashingParty in Salzburg, hosted and sponsored by [conova communications GmbH](http://www.conova.com/). It was a fun and busy weekend, with 15-17 people from 5 coutries being around, mainly working on RC bugs in Testing/Unstable. Gerfried Fuchs (rhonda) also worked on triaging the impact of RC bugs on the version in Squeeze, while Peter Palfrader (weasel) took care of Tor related things and Debian sysadmin work, including starting on the new bugs and udd hosts. Phillip Hug (hug) worked on the debian.ch infrastructure. Together with Miroslav Suchý from Red Hat Bernd Zeimetz (bzed) worked on the packaging of the necessary libraries and daemons to add (basic) Spacewalk client support to Debian. As soon as the packages passed NEW and [#677871](http://bugs.debian.org/677871) was applied (thanks to the APT guys for working on that already), managing Debian clients with Spacewalk should work out of the box. Of course we also had a little keysigning party :) Statistics - --- - - about 68 bugs in unstable/testing were triaged/patched/fixed or at least pinged - - 54 bugs were tagged to show if they affect Squeeze, several other bugs were pinged to retrieve necessary information or to trigger an update in the next stable pointrelease. - - 5 packages were introduced into Debian (still in NEW, though) - the Spacewalk client related packages and libapache2-mod-auth-memcookie. Accomodation - - Thanks to Debian funds we were able to provide accomodation for four participants in the JUFA youth hostel in Salzburg. We had paid in advance for eight, but changing to rooms with a higher category for only 4 people would have been equally or more expensive. Press/Media coverage - ---_- Additionally to being mentioned in the calendars on ProLinux and similar pages, we had some press coverage by the local newspaper and online magazines: - - [Scan of Salzburger Woche / Stadt Nachrichten](http://www.conova.com/fileadmin/user_upload/dl.php?file=files/Presse_Debian_Bug_Squashing_Party_Stadt_Nachrichten.pdf) - - [article on the Salzburger Nachrichten website](http://search.salzburg.com/news/artikel.html?uri=http%3A%2F%2Fsearch.salzburg.com%2Fnews%2Fresource%2Fsn%2Fnews%2Fst152700_15.06.2012_41-40204916) - - [meinbezirk.at](http://regionaut.meinbezirk.at/salzburg-stadt/leute/debian-bug-squashing-party-erstmals-in-salzburg-d194324.html/action/lesen/1/recommend/1/) - - [Salzburg Cityguide - Photogallery](http://www.salzburg-cityguide.at/de/partyzone/detail/debian-bug-squashing-party---conova_102492) Fun facts - - We consumed 2kg of Leberkas, a big plate of "Buchteln mit Vanillesosse", about 16000cm^2 of Pizza, about 80 litres of coke, juice, beer and whine and I guess we drank at least the same amount of water. We had coffee made of 1.5kg coffee beans and managed to empty the (formerly well filled) icemaker in the fridge. Also we had successful training sessions of a standard Debconf game (rules won't be explained here obviously). Maybe we even successfully spread the game to the employees of a commercial linux distribution ;) - -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIbBAEBCAAGBQJP4PysAAoJEOs2Fxpv+UNfedIP+LpbOOiIgbSOR95L+78kxzM1 AXr/eDEVv3uGpIslaQ2PIUaDGFiB0ecBxnloajrXBKoY46X/rLORQMBb6yyN/jHD L3HzZWU8tZyyvObFiedMsi/OwW/qALT/BXi3MAIIR8+Y8pMKUWCt0jWjCKr13QOC F/0ZFA47R7uFO2iQOgw6bkQp2NIBeh7PUX3TV/sK0AUwWt3e7LeVF4rU5nzDyzCu gACn4+jG7XwdTERT/3YMmMwhKOl7HLUBGMWNX6/JfFhj0xDxc9SXckpiZg+bk+xi Vp0yjwEkNd63GPk5032hqBa60yYlqJaJot1DVKKHbQSm1xPyXTn7NaLWvSxJCb5y 7NwyCGkQGnWGjQvxvy+22OsuYgWAc6GknQuMOCwX6l6bDIfbM013uXPmELi3m6Bj 5Y231jxa4HbZYuk5ZKSx1H7ktNE49dxyTHxa0T0pK97PDb0EpM4Uwp9iPkc1r5Bg feOee7QBotQEg/DFuRGNqylVsnWwxqtL+mmRIGPrfhvI3/41gt/Tm+yvm6bpPUGq DW68QTqhQBwLzcdMO4vYpAlFsR9Ggk1GQxF3hv7EyEPVeg3yHrpKVNocJbti0EIg wl6uSxlnVOIW2M1U5Ezo45yqy8tjx4FDp0QMgUpt0OwKxWH3Cwh86udQUOTRYPbf yHMWXVt2ordA5q7jCbc= =SpWN -END PGP SIGNATURE- -- 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/4fe0fcb3.3090...@bzed.de
Re: Why is irqbalance package so out of date?
On Mon, 18 Jun 2012 23:56:18 -0300 Henrique de Moraes Holschuh wrote: > On Mon, 18 Jun 2012, Stephen Hemminger wrote: > > I will be happy to get involved; upstream irqbalance is on my list > > of things that are broken and needs to be fixed. Will try and get a hold > > Could you elaborate on this? > > > of past contributors to figure out what is happening. I know there was > > talk of fixing it and integrating Holger's irqd logic. > > Don't cache topology and sibling relationship also play a role on maximum > PPS throughput NIC interrupt routing when assigning interrupts to proper > multiqueue NICs? Especially when Intel DCA is enabled? > > Although trying to route the packet while it is still cache-hot might as > well be a pipe dream... > I haven't looked in detail at current version. But the older versions had dynamic policy and depended on making assumptions about which device had which irq (by looking at /proc/interrupts), and polling for network activity. What it was trying to do might have been a good idea in old i386 days but was getting horribly confused with all the types of multiqueue drivers etc. The ideal program would be state driven, handle power management (use less cores when not busy), and be dynamically user configurable, and solve world hunger... -- 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/20120619153455.4fa54...@s6510.linuxnetplumber.net
Re: Build environment bug: 675125
Hello, On Tue, 19 Jun 2012 15:11:33 -0700 Josh Triplett wrote: > Variables in the .bss section will by definition get initialized to 0. > For example, a C variable defined as "static typename varname;" must > get initialized to 0, and the compiler and linker will stick it in > the .bss section expecting that it will end up with a value of 0 at > runtime. That represents a defined property of the standard, not an > implementation quirk. So, the .bss section must get initialized to 0, > not to random values, whether in a debug build or not. Oh, yes, indeed, though I see no such requirement to put initialise non-static variables in the standard, so static variables could just go to .data section, leaving .bss truly uninitialised. -- WBR, Andrew signature.asc Description: PGP signature
Bug#678218: ITP: ocamlrss -- RSS 2.0 parser and printer for OCaml
Package: wnpp Severity: wishlist Owner: Sylvain Le Gall * Package name: ocamlrss Version : 2.0 Upstream Author : Maxence Guesdon * URL : http://zoggy.github.com/ocamlrss/ * License : LGPL + BSD Programming Lang: OCaml Description : RSS 2.0 parser and printer for OCaml OCaml-RSS is a small OCaml library providing functions to parse and print RSS 2.0 files. The parser can also parse some RDF files, but some fields are not taken into account. There is still some work to do (add missing RSS 2.0 attributes, add convenient functions). OCaml-RSS was previously part of Cameleon but is now developed separately and is findlib compatible. -- 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/20120619230225.1367.42791.reportbug@localhost
Bug#678229: ITP: tilem -- GTK+ TI Z80 calculator emulator
Package: wnpp Severity: wishlist Owner: Albert Huang * Package name: tilem Version : 2.0.0 Upstream Author : TilEm2 * URL : http://lpg.ticalc.org/prj_tilem/ * License : GPL, LGPL, GFDL Programming Lang: C Description : GTK+ TI Z80 calculator emulator TilEm is an emulator and debugger for Texas Instruments' Z80-based graphing calculators. It can emulate any of the following calculator models: * TI-73 / TI-73 Explorer * TI-76.fr * TI-81 * TI-82 * TI-82 STATS / TI-82 STATS.fr * TI-83 * TI-83 Plus / TI-83 Plus Silver Edition / TI-83 Plus.fr * TI-84 Plus / TI-84 Plus Silver Edition / TI-84 pocket.fr * TI-85 * TI-86 TilEm fully supports all known versions of the above calculators (as of 2012), and attempts to reproduce the behavior of the original calculator hardware as faithfully as possible. In addition, TilEm can emulate the TI-Nspire's virtual TI-84 Plus mode. This is currently experimental, and some programs may not work correctly. . TilEm runs on the X Window System on GNU/Linux and other Unix-like platforms, as well as on Microsoft Windows, and any other platform supported by the GTK+ library. In addition to the emulation, TilEm 2 provide a lot of extra features, such as: * Fully featured debugger * Grabbing screenshots and recording gif (animations) * Virtual linking (through libticables) * Flash writing and erasing * Application and OS loading * Scripting using macros -- 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/20120620043840.27675.88838.reportbug@ubuntu
Re: Build environment bug: 675125
Le 19/06/2012 16:20, Alastair McKinstry a écrit : > While i'm still investigating, _something_ in the sid environment is the > real culprit and > I can't assign a bug to it yet until I pin it down. Has anyone seen a > similar issue elsewhere, > or got a hint as to how to handle it? I want to make sure we don't just > freeze on the current slang but ship the > broken environment. A hint: snapshot.debian.org. Cheers, -- Stéphane -- 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/4fe16530.2020...@debian.org
