Bug #47039: renaming slang.
I've been reviewing bugs in slang, and closing those that are fixed, and examining #47039. This requires/recommends that the package names be changed to policy standards: slang1 -> libslang1 slang1-dev -> libslang1-dev slang1-pic -> libslang1-pic slang1-utf8-dev - > libslang1-utf8-dev slang1a-utf8 -> libslang1-utf8 slang1-utf8-pic -> libslang1-utf8-pic slang1-utf8-dev -> libslang1-utf8-dev slang1a-utf8-udeb -> libslang1-utf8-udeb Doing this is straightforward, but will require work by others: the following packages (other than slang & newt, which I maintain), require changes as a result, according to apt-cache: (change Build-Depends, Depends and recompile): dosemu xjed xine-ui xaos ttv timidity ticker tasksel slsc slrnpull slrn slmon pdmenu most lpe libterm-slang-perl jed-common jed gstreamer-aa gphone gimp1.3 gimp fte-terminal francine bb aview asciijump aalib1 aalib-bin util-linux partimage-server partimage nano-tiny lokkit cfdisk-utf8 cdebconf finally, build-essential would need changing, as it lists slang, and it its change would need to be timed with libslang entering testing. This may be too drastic a change at this time. What do debian-devel, and particular the Release Manage, think? Regards, Alastair McKinstry Message sent using UebiMiau 2.7.2
Re: mpi-testsuite
On 2025-01-05 08:07, Drew Parsons wrote: On 2025-01-05 08:39, Alastair McKinstry wrote: Hi, I am thinking about re-instating mpi-testsuite, last in the archive in 2018. Any thoughts? Alastair I'd say it's a good idea. mpi4py has sort of been serving in the role of a test suite, but it annoys the mpi4py maintainer if we report a test failure as a bug in mpi4py rather than the MPI component triggering the bug. In that sense it'd be good to have more comprehensive testing. Drew The idea is that mpi-testsuite gets triggered by. autopkgtests for openmpi, mpich, pmix, ucx, etc. Some work (ahem) will be needed to set up an MPI configuration for Salsa / DebCI, particularly with GPU support. Alastair -- Alastair McKinstry, GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5 ph: +353 87 6847928 e: alast...@mckinstry.ie, im: @alastair:mckinstry.ie
Re: About valid and invalid user names
On Sath, 2005-02-05 at 13:38 +0100, Marc Haber wrote: > Hi, > > adduser has two bug reports open where people are asking for user name > rules to be relaxed. One report wants "." to be allowed in user names, > another wants usernames to start with numbers. > > May I ask for your opinion before denying or following the requests? > > Greetings > Marc The last time I looked, POSIX allowed '.' in usernames; it certainly works for me where I use it, and allows sensible names that scale. (fitting names like 'alastair.mckinstry' in ls -l is a different matter, but it makes for usable login names; I work for an ISP and our usernames and email names are 'firstname.lastname'; we don't give shell accounts, though. GNU chown has an extension of interpreting 'foo.bar' as username foo, group bar. This is problematic. Fortunately it also supports the Correct (TM) way of doing it, foo:bar . ':' is definitely not allowed in usernames in POSIX. I can dig out the actual spec, if necessary. Regards Alastair McKinstry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
#284724: Interpretation of NON-BREAK SPACE
Hi, I'm investigating #284724, which is about problems caused with NON-BREAK SPACE. This is a character (that can be typed as AltGr-Space in the French and some other keymaps) that looks like a space, but has the added semantics 'don't break a line here', in word processing and display software. This has uses in e.g. presenting code fragments in documents, where you want to guarantee that the line is displayed without being line-breaks. However if you cut-and-paste the code, the NBS character is not interpreted as a space, so 'ls a' is interpreted by e.g. bash as a single command, not a command and an argument. Does anyone have copies (or pointers to free versions of) SUS and any rulings on this matter? What are developers opinions on this: should this be treated as a shell (and other scripting language) bug, ie. should all characters in the class [:space:] be treated as a token seperator in shells/languages, or just the ASCII SPACE? Regards Alastair McKinstry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: #284724: Interpretation of NON-BREAK SPACE
On Sath, 2005-02-12 at 11:07 +0100, Giuseppe Sacco wrote: > Il giorno sab, 12-02-2005 alle 09:43 +0000, Alastair McKinstry ha > scritto: > [...] > > Does anyone have copies (or pointers to free versions of) SUS and any > > rulings on this matter? What are developers opinions on this: should > > this be treated as a shell (and other scripting language) bug, ie. > > should all characters in the class [:space:] be treated as a token > > seperator in shells/languages, or just the ASCII SPACE? > > I believe that non breaking space is just something related to the > layout of a document, so the semantic of a sentence or command including > such characters should just tread them as normal spaces. FWIW, I agree with this, but I think I should review all the unicode characters in the [:space:] class first. (e.g. ZERO WIDTH SPACE?) If standards are specific about 'space' being purely U+0020, then technically we could break some strange programs, but I doubt it. As this is not a shell-specific problem, I was really wondering if the scripting languages had encountered it, particularly the 'we support Unicode' ones... like Perl and Python... > Just my 0,02â, > Giuseppe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
>* Steve Langasek > >| If you are planning any other transitions that will affect a lot of >| packages, please let us know in advance. We will need to complete the >| larger transitions as fast as possible, to get testing back into a >| nearly releasable state quickly again after the release. > Whats a large transition? I'm working on slang1->slang2 in a private repository; around 20 or so packages depending on it. Currently slang2 is in pre-release; I'm working with upstream to merge Debian patches into it, and building all slang1 dependencies against it. Expect patches in BTS two weeks after sarge releases. Also, I am planning on obsoleting console-tools and console-data and transitioning to kbd; again, small but base change; see code ASAP to test for breakages. Regards Alastair McKinstry <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
>On Mon, Mar 14, 2005 at 09:23:54AM -0600, John Goerzen wrote: >> On Mon, Mar 14, 2005 at 12:47:58PM +0100, Julien BLACHE wrote: >> > Basically, you're just leaving a number of Debian users out in the >> > cold. Users who choose Debian because we were the only distribution >> > out of there to provide serious support for the architectures they >> > care for, for various reasons. >> >> Indeed. I am one such user. I have always felt fortunate that I don't >> have to really care what architecture a machine is, because "of course >> it runs Debian". I have run Debian on Alpha, x86, amd64, powerpc, and >> sarc systems, both as a desktop and a server environment on most of >> these. >> >I'm pretty amazed that people are saying that without being an FCC that their >arch will simply die. I don't understand why the porters, who've been so quick >to point out that they'll host and maintain buildd's, aren't willing to simply >track unstable and set up their own buildd network for their port. The m68k >guys did it. So did amd64. dak is now in the archive, and sbuild has been there >for ages. Quite frankly, I'll be shocked if m68k or anyone else doesn't make >their own etch release within days of the official one. The question is: how do you release a SCC arch, if at all? Its unlikely that producing an s390 (for example) release for etch is simply a matter of building the released etch on s390. It will probably take patches to the released packages for s390 to work. Is the s390 release etch+patches ? There would be version skew; will Security releases be available? Immediately post a release, there is likely to be a flood of RC-creating changes, as transitions that were postponed for the release are committed; indeed this is the recommended time to do them, in order to get as much time for stabilisation as possible, However under the proposal, any SCC architecture build comes from unstable; so, if s390 doesn't build a working release when FCC releases, then back to the bottom of the hill as ahuge pile of new RC bugs arrives; it sounds highly unlikely that the porters could get s390 unstable into a fit shape to release. I think the coupling between FCC and SCC architecture releases needs to be thought through, or at least explained, better. As it is, if I was an SCC arch maintainer, trying to remain in sync with FCC changes sounds impossible under this scheme; it will drive the SCC archs away from debian so that they have some time to themselves to stabilise. > - David Nusinow > > -Alastair McKinstry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Luan, 2005-03-14 at 16:16 +0100, David Schmitt wrote: > On Monday 14 March 2005 12:05, Robert Lemmen wrote: > > - there must be a way for a scc arch to get a stable release. why don't > > we either keep testing for scc archs but not do releases, so the > > porters can do their own stable releases of their arch or have > > per-arch testing? (the latter might lead to a source package explosion > > i think) > > AFAI can tell, anybody can host an archive of packages built from stable > sources for a scc or unofficial port. And - if I read the conditions on > becoming a fully supported Debian arch right - then having security support > for an external pool of this arch is a good indicator that it should be a > fully supported stable release (amongst other things). The plan as proposed is that the Debian scc ports are purely builds of unstable. Hence this build out of the last release (e.g. etch) becomes a subproject of a second-class project of Debian. It effectively has little credibility. > If on the other hand nobody can be found to recompile packages after DSAs are > released for this arch, I believe the arch shouldn't be released for Debian > as stable. This is the important part. The point of a release is that (1) it works (2) A promise that it _will be maintained_ ; that there will be security fixes, and eventually an upgrade path. For people to use a Debian port as a distribution they must have a degree of faith that there will be people willing and capable of doing timely security fixes for its lifetime: the size of the Debian Project promises that. While an individual would probably be able to take a working etch release and do the necessary fixes for e.g. s390 to release, more is required for people to place their trust in it as a server distribution. Then, what happens at End of Life? We must demonstrate that we also have a plan to transition from etch to what comes next for SCCs as well as i386; that s390 etch upgrades to s390 etch+1. In essence I agree with your proposition, though: I think we could release e.g. four architectures as Tier-1, with other architectures following later: these would involve some version skew, but kept minimal, so that 's390 etch' is etch+only necessary fixes. The degree of version skew would be reasonable and such that the s390 port team could keep s390 Debian maintained with security fixes. The challenge, however, is to do this _within Debian_, so that maintainers will apply patches to their packages that are required for minor ports, and keep version skew and hence complexity to a minimum. Hence we should do what we can to keep minor ports _within_ debian, even mostly symbolic gestures such as keeping Debian SCC ports in ftp.debian.org/ports rather than 'offsite' in scc.debian.org, etc. (Note: I agree that mirrors should be capable of doing partial mirrors, rather than having to mirror the whole of ftp.debian.org, though). Regards Alastair McKinstry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: post-sarge transitions: slang
On CÃad, 2005-03-16 at 02:33 -0800, Steve Langasek wrote: > Hi Alastair, > > On Mon, Mar 14, 2005 at 12:30:58PM +, Alastair McKinstry wrote: > > >* Steve Langasek > > > > > >| If you are planning any other transitions that will affect a lot of > > >| packages, please let us know in advance. We will need to complete the > > >| larger transitions as fast as possible, to get testing back into a > > >| nearly releasable state quickly again after the release. > > > Whats a large transition? I'm working on slang1->slang2 in a private > > repository; > > around 20 or so packages depending on it. > > > Currently slang2 is in pre-release; I'm working with upstream to merge > > Debian > > patches into it, and building all slang1 > > dependencies against it. > > > Expect patches in BTS two weeks after sarge releases. > > slang should, I hope, be a fairly small change; OTOH, we seem to still have > conflicting slang1 and slang1a-utf8 packages in the archive (conflicting > -dev packages at least), so it would certainly be nice to wrap this up and > only have to carry one version of this core library for etch. Yes. Upstream has rewritten slang's unicode support, so there will only be one slang2 package going forward. > > Also, I am planning on obsoleting console-tools and console-data and > > transitioning to kbd; again, small but base change; see code ASAP to test > > for breakages. > > Any chance of getting to see this in experimental first? Yes. > Thanks, -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to define a release architecture
On MÃirt, 2005-03-22 at 00:11 +0100, Peter 'p2' De Schrijver wrote: > > If Debian is keeping an arch alive so much that one can still buy it new, I > > certainly can't see why we should not continue releasing for that arch, > > however. So I'd say Matthew's explanation is not perfect. But the > > reasoning behind it is not difficult to spot. > > > > Throwing out this requirement makes sense, if and only if there is another > > way to get sure a released arch will not be left stranded. So, let's work > > on these alternate ways, so that this rule can be removed. > > > > It's not because you can't buy a new machine, the arch suddenly stops > being useful. I think the point of this requirement is to support it we need buildds in the future for security fixes. Hence while I might like my mips box, etc. it would be irresponsible for us to do a release that we could not support in e.g. two years time when the motherboards of our buildds die. Perhaps this clause could be refined, though: should it be a sub-arch requirement and not just an arch one; or could we specify that its OK to release if we have a given stock of replacement hardware available (e.g. given our good relationship with HP, its likely we could get sufficient Alpha hardware for several years after HP finally stop shipping Alphas). > Cheers, > > Peter (p2). Regards Alastair McKinstry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: Bringing volatile in shape for sarge
Another package for the 'volatile' or 'volatile-sloppy' list would be iso-codes. One purpose of the iso-codes package is to separate out data that would change over the course of a distribution, such as country and currency names, from applications that may use that data. Some applications may break if a new currency name, for example, appears. As iso-codes contains only the data and translations of the data, it should be safe by design to upgrade. Regards Alastair McKinstry On Tue, 2005-05-24 at 10:31 +0200, Andreas Barth wrote: > Hi, > > finally, sarge is about to release. As that happens, we had some more > discussions with people as volatile is going to be really live soon; > volatile is also mentioned in the release notes. > > Some topics have been brought to our attention, and we plan to solve them > all in May, so that we are ready when sarge is ready. > > > gaim, ...: volatile-sloppy > ~~ > Once again, we were asked whether we would accept updated gaim packages > during sarges lifetime. Gaim (and similar applications) are punished by > trying to support special protocolls like Yahoo messenger, which are broken > by purpose from time to time. As the only fix to get them life again is > usually to upgrade to a fairly recent version, this is not acceptable for > volatile in the stricter definition; however, we believe that enough people > want such a package so that it should be supported somehow. > > For that reason, we intend to add a second part to the archive, called > "sloppy" for now (but we're still open to any change in the name). The > relevant criterias for "sloppy" will be the same as for the normal > volatile, just that we are not as strict regarding function enhancements. > > Matching to that, we plan to create a Release-file that pins that archive > down in apt, so that any administrator need to decide for himself what to > take. Other suggestions for the name include current and HEAD. > > For packages even unfitting for that category, we might send out > recommendations to update that package, and identify where to get > updated package, like backports.org; but of course, this can even be > decided after sarge is out. > > > announcements > ~ > Of course, that brings us the next questions: We need a proper list for > announcements, and we plan to also add an RSS-feed with the updates. Any > ideas, recommendations etc are welcome. > > > archive structure > ~ > well, the basic question is, what should the users add to > /etc/apt/sources.list. We currently tend to something like > deb http://$mirror/debian-volatile sarge/volatile main and for sloppy > deb http://$mirror/debian-volatile sarge/volatile/sloppy (and for the > proposed updates deb http://$mirror/debian-volatile sarge/volatile/proposed). > > Of course, feel free to cluebat us if you have better ideas. > > > timeline > > We want to make all decisions till Thursday evening (UTC), and the > implementations should be done at least to the stage users can use that > sources-lines by Friday evening, so that we can have proper testing. > > > example packages > > For some packages, the discussions are nearly finished on getting them into > volatile-sarge soon: > > - clamav-data: this package is for people who want the anti-virus pattern > as debian package, and not use clamav-freshclam. We tend to give Marc > Haber as maintainer the possibility to update the package by himself, and > this will probably happen once a day. As very large exception, that > package won't create any of the usual announcements. > > - gaim. Well, see above. > > > So, that's for now. We appreciate your feedback. > > > Cheers, -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Mass bug-filing: slang2
Hi, Thanks to prompt action by the ftp-masters, the recently released slang2 is now in the archive. This mail is a request for maintainers of packages that use slang1 to recompile and test their packages against slang2; I intend to file patches against such packages over the next few days, barring objections. As slang is a required package, it would be good to complete this transition promptly and not have both versions in base, hence the bug filing. It would be especially good to have the changeover made in time for the planned release of the first debian-installer candidate for Etch, at the end of July. According to apt-cache, the affected packages are: aalib asc asciijump aview avifile bb cfdisk-utf8 drip francine freej fte gcompris gnome-lokkit gst-plugins gst-plugins0.8 jed kdeaddons libcaca libdv libterm-slang-perl lpe most nano newt partimage pdmenu pinball python-slang slang slmon slrn slsc tasksel ticker timidity util-linux vlc xaos xawtv xine-lib xine-ui (Please report any errors or omissions in the list). slang2 has full UTF8 support, replacing the split UTF8 / non-UTF8 libslang1 libraries; please test UTF8 support of your package. (Note: the current version of slang2 in the archive does not have fribidi support yet; I am porting that patch from slang1 forward to 2.0.4, the next release of slang2 due out this weekend). Regards Alastair McKinstry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: libslang2 breaks jed
Jörg Sommer wrote: > Hi, > > I've two problems with libslang2. The first is, the package libslang2 > includes a patch that changes the behaviour of a function. But jed > expects the function behaviour as given in the original slang2 library. > I've reported this bug #369152, 80 days ago, but the maintainer does not > react. The upstream maintainer (of jed and slang) John E. Davis is also > interested in what this patch should do. > > I apologize for this; I'd lost track of this particular bug (busy doing RL) and forgot to upload. Will do so today. > And the second problem is, the dependency version for libslang2 calcuated > by dh_shlibdeps is always 2.0.1-1 although the installed version is > newer. Why? How can I change this? There were bug fixes in libslang2 > since 2.0.1-1. I need a newer version than this. > > You should just be able to do libslang2 (>= 2.0.6-3) in jed to force dependencies on a late version. Nevertheless, as the behaviour of libslang has changed with the above change, I'll change the slib dependencies. > Thanks, Jörg. > Regards Alastair -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
static linking and opportunistic dynamic linking problem
Hi, I've an interesting bug scenario sent to me by someone trying to build partimage statically. The partimage build is being done to make a small minimal-environment binary (sort of boot-cd, etc.). partimage depends on libnewt, which I maintain. libnewt-dev ships libnewt.a. libnewt opportunistically links to libfribidi if it is present; it uses dlopen() to do so. However the partimage build fails when done with './configure --enable-all-static', as it (reasonably) does not link against libdl. /bin/sh ../../libtool --silent --mode=link g++ -g -O2 -o partimage -all-static netclient.o imagefile.o misc.o image_net.o buffer.o gui_text.o main.o imginfo.o cbitmap.o interface_base.o interface_newt.o interface_none.o mbr_backup.o -L/usr/lib -lslang fs/libfs.a ../shared/libshared.a -lcrypt -lz -lnewt -lbz2 -lpthread /usr/lib/libslang.a /usr/lib/libnewt.a /usr/lib/libssl.a /usr/lib/libcrypto.a -lcrypto -lssl netclient.o: In function `CNetClient::Connect(char*, unsigned short)': /home/alastair/tmp/partimage-0.6.4/src/client/netclient.cpp:71: warning: Using 'gethostbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/lib/libnewt.a(newt.o): In function `wchar_to_textmod_visual': (.text+0x14d4): undefined reference to `dlerror' /usr/lib/libnewt.a(newt.o): In function `wchar_to_textmod_visual': (.text+0x1502): undefined reference to `dlsym' /usr/lib/libnewt.a(newt.o): In function `wchar_to_textmod_visual': (.text+0x1825): undefined reference to `dlopen' /usr/lib/libnewt.a(newt.o): In function `wchar_to_textmod_visual': (.text+0x1838): undefined reference to `dlerror' /usr/lib/libnewt.a(newt.o): In function `wchar_to_textmod_visual': (.text+0x185d): undefined reference to `dlopen' /usr/lib/libnewt.a(newt.o): In function `wchar_to_textmod_visual': (.text+0x189f): undefined reference to `dlerror' Now, nm /usr/lib/libnewt.a | grep dlopen U dlopen So where do people think the bug lies? - Should libdl be compiled into libnewt.a ? - Should the static version of libnewt be built differently so as to not call dlopen()? - if so, any recommendations on how? - Is the bug in partimage? Regards Alastair McKinstry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: static linking and opportunistic dynamic linking problem
Goswin von Brederlow wrote: > [EMAIL PROTECTED] (Marco d'Itri) writes: > > >> On Dec 14, Alastair McKinstry <[EMAIL PROTECTED]> wrote: >> >> >>> So where do people think the bug lies? >>> - Should libdl be compiled into libnewt.a ? >>> >> Yes. >> > > Is there even a libdl.a? > > Yes, but its fairly strange, nm /usr/lib/libdl.a, to see what I mean; no dlerror(), all the other symbols resolve to 0, a stub, I think). > And what if I have libfoo.a libbar.a libblub.a all using dlopen? > Should they all have it linked in so I get 3 copies of the code? > > No, if static libs need other libs the aplication has to link them in > at the end. Likely as a result of *.la files. > > >>> - Should the static version of libnewt be built differently so as to >>> not call dlopen()? >>> >> Maybe. >> > > That would be an option. But then the static version would have less > features. > Differences in functionality between the dynamic and static approaches seems to be the least-pleasant solution. (both in runtime terms, not behaving as expected, and also in terms of _how_ to build it.) It looks like providing .la and pkg-config files to explain how to build it statically looks like necessary. newt doesn't ordinarily use libtool, so I need to generate a .la file and include it in the libnewt-dev. Currently testing this solution. >>> - if so, any recommendations on how? >>> >> Remove the feature? >> >> -- >> ciao, >> Marco >> > > MfG > Goswin > > >
Re: Getting rid of circular dependencies, stage 4
Bill Allombert wrote: Hello Debian developers, Here the lists of packages involved in circular dependencies listed by maintainers. Alastair McKinstry <[EMAIL PROTECTED]> console-common console-tools Ok, console-common will depend on ( kbd | console-tools) in the next release, and I will remove dependencies from console-tools. Will upload as soon as the phone company fixes my ASDL ... Regards Alastair -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debootstrap, Sid, and console-tools-libs
On Wed, 2003-07-02 at 02:57, Matthew P. McGuire wrote: > Hello all, > > Since sid's sysvinit was recently fixed I am able to try another chroot > install of sid per the Debain Reference directions. Sadly the following > command, > > debootstrap sid /sid-root http://ftp.debian.org/debian/ > > Creates the following error, > > E: Couldn't download console-tools-libs > console-tools-libs is no longer in sid; it was replaced with libconsole some weeks ago. I think you may have an obsolete copy of debootstrap: >From the debootstrap changelog: debootstrap (0.1.17.29) unstable; urgency=medium * [sid] libconsole has replaced console-tools-libs. (Closes: #195722) * [sarge] libperl5.6 has been replaced by libperl5.8 . (Closes: #195588) -- J.H.M. Dassen (Ray) <[EMAIL PROTECTED]> Mon, 2 Jun 2003 00:40:54 +0200 > The grumpy user might accuse console-tools-libs of being the problem, but I > decided to try another route. Install a chroot woody system, and upgrade that > chroot system to sid using apt. During that upgrade apt shows that > console-tools-libs will be removed. So I think the debootstrap script for sid > needs to be updated. I will be happy to report this as a bug, but I wasn't > sure which package to report on or if there was even a package or BTS > placeholder for this. Any info would be great. > > For the curious, the upgrade route failed as well, but on libpam0g not > console-tools-libs. Any work around would be appreciated. > > Thanks, > -- > Matthew P. McGuire 1024D/E21C0E88 > CB82 7859 26B2 95E3 1328 5198 D57A D072 E21C 0E88 > When choice matters, choose Debian. > > > -- Alastair McKinstry <[EMAIL PROTECTED]> GPG Key fingerprint = 9E64 E714 8E08 81F9 F3DC 1020 FA8E 3790 9051 38F4 He that would make his own liberty secure must guard even his enemy from oppression; for if he violates this duty he establishes a precedent that will reach to himself. - --Thomas Paine
Re: Current linux console screen blanking period?
On Thu, 2003-07-31 at 16:07, Petter Reinholdtsen wrote: > I know it is possible to use 'setterm -blank ' to change the > current screen saver timeout value in the linux console. But is it > possible to get the current value out of the console? > > I want to disable the screen saver while some task is being done, and > then enable it again with the original value when the task is done. > Is this possible? A quick look at the kernel (2.4.19 sources) appears to say no; its a pity that the ioctl call doesn't return the previous value. Within console tools, you could probably read the default from /etc/console-tools/config ; within d-i , I'd presume since we'd just assume the kernel value. Regards, Alastair -- Alastair McKinstry <[EMAIL PROTECTED]> GPG Key fingerprint = 9E64 E714 8E08 81F9 F3DC 1020 FA8E 3790 9051 38F4 He that would make his own liberty secure must guard even his enemy from oppression; for if he violates this duty he establishes a precedent that will reach to himself. - --Thomas Paine
Re: [PROPOSAL] Debian Release Plan
On Sat, 2003-08-02 at 04:51, Nathanael Nerode wrote: > Matt Zimmerman said: > > I do not think that version number milestones are important for a > > release. I think that having a well-integrated, high-quality > > distribution is important for a release, and this is not so easily > > monitored. > > Releasing with KDE 2.2, GNOME 1, and a default of GCC 2.95 would be just > plain pathetic. So sometimes, version number milestones *are* important > for a release. .. > I guess what really matters here is having versions which aren't > ludicrously out of date. Specifically, if something was released > upstream over a year ago, and Debian releases with an even *older* > version (without good reason), that's not good at all. > I disagree. We should ship ASAP despite, or even because of, older milestones. With RC bugs and d-i (as is) fixed, Sarge would still be an improvement on current stable, woody: the longer between releases the less useful the distro is, as it lacks modern drivers on the CDs. Already people are running into problems installing woody due to old drivers: eg new servers with gigabit NICs not supported in woody CDs make installing very painful. Secondly, we need to signal to upstream to fix up _their_ act, too. If we can't ship, for example the latest gcc because glibc isn't ISO C compliant and working with gcc-3.3 (see other thread), then others need to act: glibc maintainers (upstream). Why is it considered OK for other commercial distributions to ship shoddy software? Instead of being ashamed of shipping old versions, we should ship whats in testing, and let people ask questions as to why we're not shipping gcc 3.3. And answer them. regards, Alastair > -- > Nathanael Nerode > http://home.twcny.rr.com/nerode/neroden/fdl.html -- Alastair McKinstry <[EMAIL PROTECTED]> GPG Key fingerprint = 9E64 E714 8E08 81F9 F3DC 1020 FA8E 3790 9051 38F4 He that would make his own liberty secure must guard even his enemy from oppression; for if he violates this duty he establishes a precedent that will reach to himself. - --Thomas Paine
Re: vancouver revisited
Gustavo Noronha Silva wrote: Em Seg, 2005-08-22 às 00:34 +0300, Riku Voipio escreveu: jffs2 image, which is then flashed to a pile of devices. Walking through d-i every time would be very clumsy, so there is no use for a working installer for those systems. There's no use for a full-blown stable release for such things, most of the times, either. See ya, Yes, there is: one of the more frequent uses of minority architectures is diversity in internet-facing machines: I've run sparc, powerpc and MIPs machines in this role, and am currently running linksys (mips) box as my firewall / gateway / DMZ (doing more than that, of course). The security and stability of stable is whats important to me: it'll never run X or mozilla ;-) This is why (some) people find the 'second class' nature of the Vancouver proposal so disturbing: not just whats happening now, but its cutting off such futures that we are working towards. In my day job I am using Debian and openwrt (cut down Linux on linksys, etc) and with the resources on such boxes growing, and the ability to cut down linux (eg. replace glibc in base by ulibc, put base on a diet, etc.) we can forsee a time where Debian stable will run on such machines directly. However dropping Mips, etc. would cause a stagnation: just when you get the Debian base to fit on the machines, Debian stable is no longer supported on them. This is what we want to avoid. Hence its important to avoid this: while I appreciate the reluctance to have architectures with "no users" in the archive, its having Debian available on the arch that makes it feasible to use the arch in your next project, and bring the users. For this reason I think its important to work on the underlying _real_ techincal problem: some way of fixing the toolchain issues that make having the archs a problem. Solutions such as autobuilding the arch with upcoming toolchains in experimental, pulling more test suites into the build so that the packages are not just built but run on the archs, etc. Regards Alastair -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Standardizing ~/.cache/ and similar things.
On Mon, 2005-09-19 at 15:17 +0200, Eduard Bloch wrote:
> #include
> * Faré [Sun, Sep 18 2005, 07:43:43PM]:
> > Dear Debian developers,
> >
> > here is a proposal I submit for inclusion in the debian policy:
> >
> > PROPOSAL 1: ~/.cache/${package_name}/
>
> There is no point in moving everything to foo style names, it is
> just not worth the work. I like the current method used by autodevtools,
> I can set $HOME as prefix and just get _few_ additional and immediately
> visible dirs in my $HOME: bin, lib, share.
This is increasingly true, especially with naive users not using ~/ much
at all, but keeping any random files in ~/Desktop in Gnome, etc.
Unlike Marco, I do see a lot of value in reorganising at least _some_ of
the 'configuration' files of users: seperating out .mozilla web caches
and .evolution IMAP caches greatly relieves the size of backups of ~/
directories. If all caches were in one directory it would make it
possible to fit a slimmed /home on a single .iso to archive / backup,
for example, whereas now it takes 2 DVDs due to IMAP and web caches,
etc.
Also, if people do not like a prefix of $HOME because it places visible
names in $HOME, they could also use $HOME/.somename, etc.
Regards
Alastair
> Eduard.
> --
> Lennier: If you do not know the present, how can you claim to know the future?
> -- Quotes from Babylon 5 --
>
>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Standardizing ~/.cache/ and similar things.
Ron Johnson wrote:
On Mon, 2005-09-19 at 07:55 +0200, Sylvain LE GALL wrote:
Hello,
On Sun, Sep 18, 2005 at 07:43:43PM -0400, Faré wrote:
Dear Debian developers,
here is a proposal I submit for inclusion in the debian policy:
PROPOSAL 1: ~/.cache/${package_name}/
PROPOSAL 2: ~/.etc/${package_name}/
PROPOSAL 3: ~/.run/ ~/.lib/ ~/.share, etc.
I like your idea. But i think that i think it should be better
to follow base-dir specification from freedesktop.org. It gives exactly
the same kind of dirname, but in a more standardized way.
Take a look at:
http://www.freedesktop.org/wiki/Standards_2fbasedir_2dspec
Xhtml Design Guide?
I think the point was that you can set a XDG environmental variable to
spec ify a cache directory.
Interesting, but it doesn't solve the problem of telling a backup
program that a directory is a cache directory. e.g. telling a backup
program that is
backing up /home that _multiple_ directories are cache directories;
setting /home/*/.cache or /home/*/var/cache as directories to be
excluded
in a backup works.
Regards
Alastair
Re: Standardizing ~/.cache/ and similar things.
Marco d'Itri wrote: On Sep 19, Alastair McKinstry <[EMAIL PROTECTED]> wrote: Unlike Marco, I do see a lot of value in reorganising at least _some_ of the 'configuration' files of users: seperating out .mozilla web caches and .evolution IMAP caches greatly relieves the size of backups of ~/ directories. If all caches were in one directory it would make it What about http://www.brynosaurus.com/cachedir/spec.html ? tar supports it. Interesting, but very specific to the caching example. There are other useful parts of the proposal, too: e.g. if libraries are in ~/lib then its easy to have $LD_LIBRARY_PATH=$HOME/lib work on multiple applications; also for an installer to install an application into a users directory. For this reason I prefer $HOME/var , $HOME/lib, etc. to .lib, .cache, .bin, etc. possible to fit a slimmed /home on a single .iso to archive / backup, for example, whereas now it takes 2 DVDs due to IMAP and web caches, etc. It's not like it's an Herculean task to add a couple of directories to the exclude list of your backup program... This is the wrong way round, IMHO: rather than having to examine every new application I use to see what config files and caches it creates (and never be sure of that: what files in .evolution can I safely remove as caches, and what ones are essential config? is it safe to remove / not backup $HOME/.evolution/IMAP/* ? ), and add them to my backup program excludes list, I can just add /home/var/cache/* to my excludes list and change applications to use it. No need to keep a list of cache directories up-to-date. Regards Alastair -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: slgdbm_1.6-2_i386.changes is NEW
Rafael Laboissiere wrote: [Moving this discussion to debian-devel. The context is the recent upload of the slgdbm package, which is the fisrt package in Debian to provide an SLang2 module. Please, keep Cc: to [EMAIL PROTECTED] * G. Milde <[EMAIL PROTECTED]> [2005-09-27 08:19]: On 26.09.05, Paul Boekholt wrote: I should have brought this up sooner, but isn't slfoo too shortish for a debian package name? The perl policy says: ... naming convention for module Foo::Bar is libfoo-bar-perl. The Python naming scheme seems to be python-foo. I vote vor slang-foo. (Not only because I like python more than perl, but because this way slang modules will appear close to slang in an alphabetical listing (e.g. in aptitude or `ls /usr/share/doc/`). There is no policy in Debian regarding packages which provide SLang2 modules. Maybe we should write a draft and put it in one of the slang2 packages? Alastair, what do you think? My preference is for slang-foo, as it is more visible that it is a slang-related, rather than a generic DSO; slang-gdbm is more interesting to a slang developer than to a gdbm one, and this shows that. It appears php and common lisp, follow the $lang-foo naming scheme, with ruby going the perl direction. I can write up a short policy specifying it and include it in the next copy of slang2. Please CC: me on any relevant comments. Regards Alastair -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packages that need to be rebuilt agaisnt libssl0.9.8
On Thu, 2005-10-06 at 11:24 -0300, Henrique de Moraes Holschuh wrote: > Is there any chances of versioning openssl symbols properly? > > I am not asking for 0.9.7 and 0.9.8 to coexist (although versioned symbols > would make that trivial), but PLEASE version the symbols. > > Suggested version tag: OPENSSL_0_9_8 minor point, but in the name of consistency could we use version tags of the form OPENSSL_0.9.8, matching e.g. GLIBC_2.0 , etc. Regards Alastair > -- > "One disk to rule them all, One disk to find them. One disk to bring > them all and in the darkness grind them. In the Land of Redmond > where the shadows lie." -- The Silicon Valley Tarot > Henrique Holschuh > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
mail server broken: are debian reject messages logged ?
Hi, I've just returned from a two-week vacation during which time my mailserver at home was broken (ADSL line problems). In fact the DNS was also unreachable, so mail bounced badly. If you sent me a mail in the last two weeks, please resend. In particular, I had some packages uploaded to the NEW queue in this period, and they have disappeared: I think they must have been rejected. Are the ftp master messages logged anywhere ? I'd like to know why they were rejected. Regards Alastair McKinstry mckins...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#540182: ITP: libgctp -- General Cartographic Transformation Package Library
Package: wnpp Severity: wishlist Owner: Alastair McKinstry * Package name: libgctp Version : 1.0 Upstream Author : Abe_Taaheri abe_taah...@raytheon.com * URL : http://gcmd.nasa.gov/records/USGS-GCTP.html * License : Mixed public-domain and BSD Programming Lang: C Description : General Cartographic Transformation Package Library The General Cartographic Transformation Package (GCTP) is a system of software routines designed to permit the transformation of coordinate pairs from one map projection to another. The GCTP is the standard computer software used by the National Mapping Division for map projection computations. This library is used by hdf-eos4 and hdf-eos5, which have ITP's assigned, as well as libproj internally. The upstream author claified the license situation: The GCTP was originally developed by USGS. For EOS (funded by NASA) we took it and added a few more projections to be used by HDF-EOS. Any one can use it or modify it (both commercial and non-comercial) as long as it is acknowledged. If you want to use it please use the latest versions ( see download at http://newsroom.gsfc.nasa.gov/sdptoolkit/toolkit.html ). The source code is packaged with hdfeos and hdfeos5. -- System Information: Debian Release: 5.0.2 APT prefers stable APT policy: (500, 'stable') Architecture: powerpc (ppc) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#540545: ITP: grads -- Grid Analysis and Display System for earth science data
Package: wnpp Severity: wishlist Owner: Alastair McKinstry * Package name: grads Version : 2.0 Upstream Author : NASA Advanced Information Systems Research Program * URL : http://www.iges.org/grads/ * License : GPL Programming Lang: C Description : Grid Analysis and Display System for earth science data The Grid Analysis and Display System (GrADS) is an interactive desktop tool that is used for easy access, manipulation, and visualization of earth science data. The format of the data may be either binary, GRIB, NetCDF, or HDF-SDS (Scientific Data Sets). GrADS has been implemented worldwide on a variety of commonly used operating systems and is freely distributed over the Internet. GrADS uses a 4-Dimensional data environment: longitude, latitude, vertical level, and time. Data sets are placed within the 4-D space by use of a data descriptor file. GrADS interprets station data as well as gridded data, and the grids may be regular, non-linearly spaced, gaussian, or of variable resolution. Data from different data sets may be graphically overlaid, with correct spatial and time registration. Operations are executed interactively by entering FORTRAN-like expressions at the command line. A rich set of built-in functions are provided, but users may also add their own functions as external routines written in any programming language. Data may be displayed using a variety of graphical techniques: line and bar graphs, scatter plots, smoothed contours, shaded contours, streamlines, wind vectors, grid boxes, shaded grid boxes, and station model plots. Graphics may be output in PostScript or image formats. GrADS provides geophysically intuitive defaults, but the user has the option to control all aspects of graphics output. GrADS has a programmable interface (scripting language) that allows for sophisticated analysis and display applications. Use scripts to display buttons and dropmenus as well as graphics, and then take action based on user point-and-clicks. GrADS can be run in batch mode, and the scripting language facilitates using GrADS to do long overnight batch jobs. -- System Information: Debian Release: 5.0.2 APT prefers stable APT policy: (500, 'stable') Architecture: powerpc (ppc) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#541074: ITP: libdap -- Scientific Network Data Access Protocol library
Package: wnpp Severity: wishlist Owner: Alastair McKinstry * Package name: libdap Version : 3.9.3 Upstream Author : OpenDAP * URL : http://www.opendap.org * License : GPL, W3C Programming Lang: C++ Description : Scientific Network Data Access Protocol library OPeNDAP provides software that allows you to access data over the internet, from programs that weren't originally designed for that purpose, as well as some that were. While OPeNDAP is the original developer of the Data Access protocol which its software uses, many other groups have adopted DAP and provide compatible clients, servers and software development kits. . The DAP is a NASA community standard; here is the offical link to the specification. . With OPeNDAP software, you access data using a URL, just like a URL you would use to access a web page. However, before you request any data, you need to know how to request it in a form your browser can handle. OPeNDAP data is stored in binary form, and by default, it is transmitted that way, too. -- System Information: Debian Release: 5.0.2 APT prefers stable APT policy: (500, 'stable') Architecture: powerpc (ppc) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Recommendations for man pages in Debian (was: Debian Policy 3.8.3.0 released: localized manpages)
It's only unambiguous if you know the convention being adopted /is/ ISO-8601. In an ideal world, we could have a standardised date format which the man program can transform into the date representation of the user's locale thus satisfying all requirements. ??? Thats what ISO-8601 is. There is no other format that goes -YY-ZZ. (and if someone invents one they deserve to be larted quickly and harshly). - must be a year, as its four digits. YY-ZZ : Month, date, as no other format starts with the year. Unlike 03/04/2009 or even (shudder) 05/06/07 , you cannot confuse year, month, date. Thats the point. Now ISO-8601 may be _unusual_, in that many people have not seen it before, but thats true of _any_ replacement to the messy 03/04/05. But Unambigous it isn't. Regards Alastair Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http:// gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-i18n-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: ITP: liblocale-us-perl -- Module for United States state identification
Hi, A larger version of this idea exists in the iso-codes package, with the iso-code subdivision codes for all countries, see /usr/share/xml/iso-codes/iso_3166-2.xml For each US state it has the 2nd-level code , so US-MI is Michigan, for example. Similar 2nd-level codes exist for each country, so FR-75 is the French Department of Paris, IE-D is Dublin, Ireland, and GB-ESX is the English county of Essex. The iso-codes package provides translations for these lists. Perhaps generalizing this module might be a good idea ? Regards Alastair On 17 Nov 2007, at 18:51, Matt Brown wrote: On 11/17/07, Ron Johnson wrote: This Perl module provides methods allowing United States' two-letter state identification parsing from state code to state name and vice versa. Is a package really needed for something this simple? It might be obvious to a US native, but it's hardly simple or obvious to those of us outside America. MI is a prime example, does it refer to Michigan, Missouri, Mississippi or Minesota? The first two letters match all four. If you come across this every day you probably know the answer, but I just had to look it up again (Michigan) despite being caught out by this just the other week! -- Matt Brown m...@mattb.net.nz Mob +353 86 608 7117 www.mattb.net.nz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#546183: ITP: libsx -- Simple X library
Package: wnpp Severity: wishlist Owner: Alastair McKinstry * Package name: libsx Version : 2.05 Upstream Author : Jean-Pierre Demailly * URL : ftp://ftp.ac-grenoble.fr/ge/Xlibraries/ * License : GPL Programming Lang: C Description : Simple X library Libsx (the Simple X library) is a library of code that sits on top of and to the side of the Athena widget set. Its purpose is to make writing X applications *much* easier. libsx is a dependency of grads (ITP 540545) and present in Fedora / Redhat -- System Information: Debian Release: 5.0.2 APT prefers stable APT policy: (500, 'stable') Architecture: powerpc (ppc) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: embedded copies of Unicode data?
Hi, I'd like to point out we have a package unicode-data, which has the up-to-date unicode data files in it. I think we should file wishlist bugs against packages using their own copies of this data. Regards Alastair McKinstry > There are several copies of the Unicode data files in the archive, > examples: > > charmap.app: > /usr/lib/GNUstep/Applications/Charmap.app/Resources/UnicodeData.txt > charmap.app: /usr/share/doc/charmap.app/UnicodeData.txt.gz > clisp: /usr/lib/clisp-2.44.1/data/UnicodeDataFull.txt > gnulib: /usr/share/gnulib/tests/uniname/UnicodeDataNames.txt > libcamomile-ocaml-data: > /usr/share/doc/libcamomile-ocaml-data/UnicodeData.html > libopensrs-perl: /usr/share/opensrs/RACE/RACE/UnicodeData-Latest.txt > libsaxonb-java-doc: > /usr/share/doc/libsaxon8-java-doc/api/net/sf/saxon/codenorm/UnicodeData.html > moodle: /usr/share/moodle/lib/typo3/unidata/UnicodeData.txt > perl-modules: /usr/share/perl/5.10.0/unicore/UnicodeData.txt > pypy-dev: > /usr/share/pypy-1.0/pypy/module/unicodedata/UnicodeData-3.2.0.txt > pypy-dev: > /usr/share/pypy-1.0/pypy/module/unicodedata/UnicodeData-4.1.0.txt > pypy-dev: > /usr/share/pypy-1.0/pypy/module/unicodedata/UnicodeData-5.0.0.txt > rails: > /usr/share/doc/rails/html/classes/ActiveSupport/Multibyte/UnicodeDatabase.html > typo3-src-4.2: > /usr/share/typo3/typo3_src-4.2/t3lib/unidata/UnicodeData.txt > typo3-src-4.3: > /usr/share/typo3/typo3_src-4.3/t3lib/unidata/UnicodeData.txt > > In addition, some of the following packages appear to embed copies of > the Unicode data in their source code: > > http://source.debian.net/source/search?q=IMIFTHORON&defs=&refs=&path=&hist= > http://source.debian.net/source/search?q=LHAVIYANI&defs=&refs=&path=&hist= > > In addition, there is a copy of parts of the Unicode data in > fonttools, gucharmap, libuninameslist and probably others. > > I'm wondering what, if anything, Debian should do about this > situation. We generally don't like embedded code copies, but I'm not > sure if the same arguments apply to embedded data copies. > > Any thoughts? > > In addition, the CMap and AGLFN data are in similar situations, but I > think they are embedded in much fewer packages. > > -- > 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 > > -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#412488: ITP: midas -- the European Southern Observatory Munich Image Data Analysis System
Package: wnpp Severity: wishlist Owner: Alastair McKinstry <[EMAIL PROTECTED]> * Package name: midas Version : 2006.09 Upstream Author : The European Southern Observatory * URL : http://www.eso.org/projects/esomidas/ * License : GPL Programming Lang: C Description : the European Southern Observatory Munich Image Data Analysis System The ESO-MIDAS system provides general tools for image processing and data reduction with emphasis on astronomical applications including imaging and special reduction packages for ESO instrumentation at La Silla and the VLT at Paranal. In addition it contains applications packages for stellar and surface photometry, image sharpening and decomposition, statistics and various others. The official name, ESO-MIDAS, is a registered trademark. ESO-MIDAS is available under the GNU General Public License (GPL), and can be implemented on OpenVMS and UNIX (Linux) systems. -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.8-powerpc Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#414623: ITP: zope-ploneformgen -- A generic Plone form generator
Package: wnpp Severity: wishlist Owner: Alastair McKinstry <[EMAIL PROTECTED]> * Package name: zope-ploneformgen Version : 1.0.3 Upstream Author : Plone Collective * URL : http://plone.org/products/ploneformgen * License : GPL Programming Lang: Python Description : A generic Plone form generator This product provides a generic Plone form generator using fields, widgets and validators from Archetypes. It makes it possible to build simple contact, information-gathering or data-entry forms through Plone's interface. . To use it, create a form folder, then add form fields as contents. Individual fields can display and validate themselves for testing purposes. The form folder creates a form from all the contained field content objects. . Final disposition of form input is handled via plug in action products. Action adapters included with this release include a mailer and a save-data adapter that saves input in tab-separated format for later download. When you first add a form folder, it's configured as simple response form with input mailed to the owner. -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.8-powerpc Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to ga_IE.UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#414625: ITP: zope-cmfbibliographyat -- A Bibliography management product for Zope/CMF/Plone
Package: wnpp Severity: wishlist Owner: Alastair McKinstry <[EMAIL PROTECTED]> * Package name: zope-cmfbibliographyat Version : 0.8.0 Upstream Author : Raphael Ritz, <[EMAIL PROTECTED]> * URL : http://plone.org/products/cmfbibliographyat * License : GPL Programming Lang: Python Description : A Bibliography management product for Zope/CMF/Plone CMFBibliographyAT is the ArcheTypes based version of CMFBibliograhy. It enables handling of references to (scientific) publications in Plone. It provides a 'Bibliography Folder' content type dedicated to holding reference objects of various kinds, like for 'articles', 'books', 'preprints', 'techreports', contributions to collections, ... . The folder supports import/export of BibTeX formated files. In addition the package adds a 'bibliography' action to the portal tabs and it provides a BibliographyTool called 'portal_bibliography' through which you can manage the renderers and parsers for the import/export functionality. -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.8-powerpc Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to ga_IE.UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#414627: ITP: zope-atextensions -- Extensions to Archetypes in Zope
Package: wnpp Severity: wishlist Owner: Alastair McKinstry <[EMAIL PROTECTED]> * Package name: zope-atextensions Version : 0.8.0 Upstream Author : Raphael Ritz, <[EMAIL PROTECTED]> * URL : http://plone.org/products/atextensions * License : GPL Programming Lang: Python Description : Extensions to Archetypes in Zope This package provides some extensions to archetypes. . So far, there are only a few custom fields, widgets and validators, the Record(s)Field/Widget being the mosti generic components. Theses fields exploit the record and records packager directive of Zope's ZPublisher to effectively manage a dictionary (record) or list of dictionaries (records). The dictionary's keys and the data type of their values can be configured in the AT schema declaration. . To demonstrate their usage, there is a demo content type WorkingGroup. To enable it after install, go to portal types and make it implicitly addable or include it in some folderish type's allowed_content_types. . Future plans are to make this product obsolete by moving the Record(s)Field/Widget to Archetypes proper and the specific fields to More Fields and Widgets. -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.8-powerpc Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to ga_IE.UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#414628: ITP: zope-scriptablefields -- Zope tool bundle for working with component Logic
Package: wnpp Severity: wishlist Owner: Alastair McKinstry <[EMAIL PROTECTED]> * Package name: zope-scriptablefields Version : 1.0 Upstream Author : Sidnei da Silva, Daniel Nouri, Jens W. Klein * URL : http://plone.org/products/ploneformgen/scriptablefields/ * License : GPL Programming Lang: Python Description : Zope tool bundle for working with component Logic The bundle contains: . * TALESField A StringField like field you store a TALES expression in. It gets evaluated on get and the result is returned. * PythonField A TextArea like field where you can store a whole Script (Python) in. On get its evaluated and the result is returned. * DTMLField and ZPTField Both fields working like PythonField but the given text is evaluated as DTML or Zope Page-Template. -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.8-powerpc Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to ga_IE.UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
slang : sid transitions still frozen?
Hi, I'm the maintainer of slang2. I uploaded version 2.0.7 19 days ago, and according to http://ftp-master.debian.org/testing/update_excuses.html.gz#slang2 its blocked by the etch freeze... Is this still the case, or a false alarm? Regards Alastair McKinstry # slang2 (2.0.6-4 to 2.0.7-1) * Maintainer: Alastair McKinstry * 19 days old (needed 10 days) * Not touching package, as requested by freeze (contact debian-release if update is needed) * Not considered * Depends: slang2 glibc <http://ftp-master.debian.org/testing/update_excuses.html.gz#glibc> (not considered)
Re: ITP: liblocale-us-perl -- Module for United States state identification
Two data points for the discussion: (1) The data, and more useful data, is available in iso-codes. The iso-codes-3166-2 list contains the subdivision lists for not just the US but all countries. (In the US, its states, in the Ireland counties, German Lander, etc.), and their translations. (2) Not packaged, but available on the web, is a dataset of the postal formats for all countries. e.g Ireland does not have ZIP codes; different countries have standard formats for addresses. It might be worth packaging this for use with the subdivisions to give more useful web pages for entering addresses. Regards Alastair On 17 Nov 2007, at 18:51, Matt Brown wrote: On 11/17/07, Ron Johnson <[EMAIL PROTECTED]> wrote: This Perl module provides methods allowing United States' two-letter state identification parsing from state code to state name and vice versa. Is a package really needed for something this simple? It might be obvious to a US native, but it's hardly simple or obvious to those of us outside America. MI is a prime example, does it refer to Michigan, Missouri, Mississippi or Minesota? The first two letters match all four. If you come across this every day you probably know the answer, but I just had to look it up again (Michigan) despite being caught out by this just the other week! -- Matt Brown [EMAIL PROTECTED] Mob +353 86 608 7117 www.mattb.net.nz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] Regards, Alastair -- Alastair McKinstry , <[EMAIL PROTECTED]> http://blog.scealnetworks.com 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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#584636: ITP: cmor -- Climate Model Ouput Rewriter
Package: wnpp Severity: wishlist Owner: Alastair McKinstry * Package name: cmor Version : 2.0 Upstream Author : Charles Doutriaux * URL : http://www2-pcmdi.llnl.gov/cmor * License : "Unrestricted" (BSD-like ?) Programming Lang: C, python, fortran Description : Climate Model Ouput Rewriter The "Climate Model Output Rewriter" (CMOR, pronounced "Seymour") comprises a set of C-based functions, with bindings to both Python and FORTRAN 90, that can be used to produce CF-compliant netCDF files that fulfill the requirements of many of the climate community's standard model experiments. These experiments are collectively referred to as MIP's and include, for example, AMIP, CMIP, CFMIP, PMIP, APE, and IPCC scenario runs. The output resulting from CMOR is "self-describing" and facilitates analysis of results across models. Much of the metadata written to the output files is defined in MIP-specific tables, typically made available from each MIP's web site. CMOR relies on these tables to provide much of the metadata that is needed in the MIP context, thereby reducing the programming effort required of the individual MIP contributors. -- System Information: Debian Release: 5.0.4 APT prefers stable APT policy: (500, 'stable') Architecture: powerpc (ppc) -- 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/20100605082105.25291.75283.report...@ailm.sceal.ie
Bug#584637: ITP: cdat -- Climate Data Analysis Tools
Package: wnpp Severity: wishlist Owner: Alastair McKinstry * Package name: cdat Version : 5.2 Upstream Author : Dean Williams (william...@llnl.gov) * URL : http://www2-pcmdi.llnl.gov/cdat * License : BSD Programming Lang: python, c, fortran Description : Climate Data Analysis Tools CDAT makes use of an open-source, object-oriented, easy-to-learn scripting language (Python) to link together separate software subsystems and packages to form an integrated environment for data analysis. Outside collaborators work independently and contribute on an equal basis with PCMDI. -- System Information: Debian Release: 5.0.4 APT prefers stable APT policy: (500, 'stable') Architecture: powerpc (ppc) -- 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/20100605082600.25412.99791.report...@ailm.sceal.ie
Bug#587422: ITP: ferret-viz -- Interactive data visualization and analysis environment, for gridded and non-gridded climate data
Package: wnpp Severity: wishlist Owner: Alastair McKinstry * Package name: ferret-viz Version : 6.2 Upstream Author : NOAA * URL : http://ferret.pmel.noaa.gov/Ferret/home * License : Public Domain / Programming Lang: Fortran Description : Interactive data visualization and analysis environment, for gridded and non-gridded climate data Ferret is an interactive computer visualization and analysis environment designed to meet the needs of oceanographers and meteorologists analyzing large and complex gridded data sets. It runs on most Unix systems, and on Windows XP/NT/9x using X windows for display. It can transparently access extensive remote Internet data bases using OPeNDAP (formerly known as DODS); see http://www.unidata.ucar.edu/packages/dods/. Ferret was developed by the Thermal Modeling and Analysis Project (TMAP) at PMEL in Seattle to analyze the outputs of its numerical ocean models and compare them with gridded, observational data. The model data sets are generally multi-gigabyte in size with mixed 3 and 4-dimensional variables defined on staggered grids. Ferret offers a Mathematica-like approach to analysis; new variables may be defined interactively as mathematical expressions involving data set variables. Calculations may be applied over arbitrarily shaped regions. Fully documented graphics are produced with a single command. Many excellent software packages have been developed recently for scientific visualization. The features that make Ferret distinctive among these packages are Mathematica-like flexibility, geophysical formatting, "intelligent" connection to its data base, memory management for very large calculations, and symmetrical processing in 4 dimensions. Ferret is widely used in the oceanographic community to analyze data and create publication quality graphics. We have compiled an (incomplete) list of publications where the authors felt that the contribution of Ferret was sufficient to warrant an acknowledgment. We appreciate your acknowledgment of Ferret in your publications. -- System Information: Debian Release: 5.0.4 APT prefers stable APT policy: (500, 'stable') Architecture: powerpc (ppc) -- 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/20100628143745.27638.34979.report...@ailm.sceal.ie
Bug#587494: ITP: xgks -- X11 Graphical Kernel System
Package: wnpp Severity: wishlist Owner: Alastair McKinstry * Package name: xgks Version : 2.6 Upstream Author : UCAR/Unidata * URL : http://xgks.sourceforge.net/ * License : BSD Programming Lang: C, Fortran Description : X11 Graphical Kernel System XGKS is a level 2C implementation of the ANSI Graphical Kernel System (GKS) for use in a Unix environment with the X Window System. It supports the Fortran language binding and a C language binding based on the 1988 draft. XGKS is used in both the CDMS2 and FERRET climate tools which are currently being packaged for Debian. -- System Information: Debian Release: 5.0.4 APT prefers stable APT policy: (500, 'stable') Architecture: powerpc (ppc) -- 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/20100629094744.9221.21566.report...@ailm.sceal.ie
Problem with gfortran and pkg-config
Hi, I've a problem using pkg-config for Fortran programs. As shipped in sid (and squeeze), libnetcdf-dev includes a netcdf.pc and /usr/include/netcdf.mod Now, to compile a fortran90 program I need to include gfortran -I /usr/include foo.f90 to get netcdf.mod in the path. But pkg-config removes -I/usr/include from the Cflags line in pkg-config. Which is wrong, gfortran not reading /usr/include by default, or pkg-config for removing /usr/include from CFLAGS ? 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/4c516b80.7020...@ichec.ie
Bug#599747: ITP: SILO -- A mesh and field I/O library and scientific database
Package: wnpp Severity: wishlist Owner: Alastair McKinstry * Package name: SILO Version : 4.8 Upstream Author : LLNL * URL : https://wci.llnl.gov/codes/silo/ * License : BSD (3-clause) Programming Lang: C Description : A mesh and field I/O library and scientific database Silo is a library for reading and writing a wide variety of scientific data to binary, disk files. The files Silo produces and the data within them can be easily shared and exchanged between wholly independently developed applications running on disparate computing platforms. Consequently, Silo facilitates the development of general purpose tools for processing scientific data. One of the more popular tools that process Silo data files is the VisIt visualization tool. Silo supports gridless (point) meshes, structured meshes, unstructured-zoo and unstructured-arbitrary-polyhedral meshes, block structured AMR meshes, constructive solid geometry (CSG) meshes, piecewise-constant (e.g. zone-centered) and piecewise-linear (e.g. node-centered) variables defined on the node, edge, face or volume elements of meshes as well as the decomposition of meshes into arbitrary subset hierarchies including materials and mixing materials. In addition, Silo supports a wide variety of other useful objects to address various scientific computing application needs. Although the Silo library is a serial library, it has some key features which enable it to be applied quite effectively and scalable in parallel. Architecturally, the library is divided into two main pieces; an upper-level application programming interface (API) and a lower-level I/O implementation called a driver. Silo supports multiple I/O drivers, the two most common of which are the HDF5 (Hierarchical Data Format 5) and PDB (Portable Data Base) drivers. -- System Information: Debian Release: 5.0.5 APT prefers stable APT policy: (500, 'stable') Architecture: powerpc (ppc) -- 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/20101010191953.2902.92241.report...@ailm.sceal.ie
Bug#602285: ITP: spherepack -- Speherical math operations library for geophysics
Package: wnpp Severity: wishlist Owner: Alastair McKinstry * Package name: spherepack Version : 3.2 Upstream Author : John C. Adams and Paul N. Swarztrauber, UCAR.edu * URL : http://www.cisl.ucar.edu/css/software/spherepack/ * License : BSD Programming Lang: Fortran, python Description : Spherical math operations library for geophysics SPHEREPACK 3.2 is a collection of FORTRAN programs that facilitates computer modeling of geophysical processes. The package contains programs for computing certain common differential operators including divergence, vorticity, gradients, and the Laplacian of both scalar and vector functions. Programs are also available for inverting these operators. For example, given divergence and vorticity, the package can be used to compute the velocity components. The Laplacian can also be inverted and therefore the package can be used to solve both the scalar and vector Poisson equations. Its use in model development is demonstrated by a sample program that solves the time-dependent non-linear shallow-water equations. Accurate solutions are obtained via the spectral method that uses both scalar and vector spherical harmonic transforms that are available to the user. The package also contains utility programs for computing the associated Legendre functions, Gauss points and weights, and multiple fast Fourier transforms. Programs are provided for both equally-spaced and Gauss distributed latitudinal points as well as programs that transfer data between these grids. -- System Information: Debian Release: 5.0.6 APT prefers stable APT policy: (500, 'stable') Architecture: powerpc (ppc) -- 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/20101103102030.14906.75977.report...@ailm.sceal.ie
strange failures on lxdebian and asdfasdf.debian.net for cmor
Hi, I've a strange issue: I've a perfectly ordinary package, cmor, which fails to build on s390 and kfreebsd-amd64. In both cases it fails while trying to build a test executable, ipcc_test_code, in the test target, but with different errors in ld, segfault and abort. Now, outside the buildds (lxdebian and asdfasdf) the package builds fine on s390 and kfreebsd-amd64 (it fails on kfreebsd-i386, also in building ./ipcc_test_code, but that appears to be different. While I don't understand the failure yet, it is at least reproducible). I managed to get s390 uploaded by the simple expedient of building the last upload, 2.5.0-2, on s390 instead of my home machine. Is it possible to do an external build and upload (outside the buildd system)? how? And does anyone have any ideas why linking might be failing on lxdebian.debian.net and asdfasdf.debian.net? (but not zelenka or zandonai)? -- 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/4ce8463b.8050...@debian.org
Re: strange failures on lxdebian and asdfasdf.debian.net for cmor
On 2010-12-04 12:02, Michael Tautschnig wrote: Hi Alastair, I'm by no means a bsd expert and you actually might want to redirect your question to debian-...@l.d.o instead. I've a strange issue: I've a perfectly ordinary package, cmor, which fails to build on s390 and kfreebsd-amd64. In both cases it fails while trying to build a test executable, ipcc_test_code, in the test target, but with different errors in ld, segfault and abort. Now, outside the buildds (lxdebian and asdfasdf) the package builds fine on s390 and kfreebsd-amd64 (it fails on kfreebsd-i386, also in building ./ipcc_test_code, but that appears to be different. While I don't understand the failure yet, it is at least reproducible). [...] Could you maybe, as first measure, try to make the build (or the build of tests at least) way more verbose? Surely it's not ln -sf that aborts, but that is about all that can be found in the build logs. I guess it would be nice to see the full command line that is being executed such that precisely this step can be investigated in more detail. As the tests (once they run) seem to be very verbose, this should (a) help to nail down the error and (b) could possibly be some problem with the terminal!? (The latter is a wild guess as I have no idea what cmor really does.) Hope this helps, Michael Ok, I've enabled further debugging on these. Builds on s390 seem to be working fine; its now building on zandonai ; all previous failures appear to have been on lxdebian and i'm assuming issues there (memory, tmpfs, etc.). I'm down to a build issue on kfreebsd-i386, with an abort (Error 134). The FTBFS on kfreebsd-amd64 at the same point seems to have gone away (it was also an abort, error 134); Perhaps a different memory-related error? With debugging (gcc --verbose) the error looks like: ln -sf TestTables Tables rm -f ./ipcc_test_code ; gcc --verbose -lnetcdf -Iinclude -Iinclude/cdTime Test/ipcc_test_code.c -L/usr/lib -I/usr/include -L. -lcmor -lnetcdf -ludunits2 -lossp-uuid -I/usr/include/ossp -lm -o ipcc_test_code ; ./ipcc_test_code Using built-in specs. Target: i486-kfreebsd-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.5-10' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.4 --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=i486-kfreebsd-gnu --host=i486-kfreebsd-gnu --target=i486-kfreebsd-gnu Thread model: posix gcc version 4.4.5 (Debian 4.4.5-10) COLLECT_GCC_OPTIONS='-v' '-Iinclude' '-Iinclude/cdTime' '-L/usr/lib' '-I/usr/include' '-L.' '-I/usr/include/ossp' '-o' 'ipcc_test_code' '-mtune=generic' '-march=i586' /usr/lib/gcc/i486-kfreebsd-gnu/4.4.5/cc1 -quiet -v -Iinclude -Iinclude/cdTime -I/usr/include -I/usr/include/ossp Test/ipcc_test_code.c -quiet -dumpbase ipcc_test_code.c -mtune=generic -march=i586 -auxbase ipcc_test_code -version -o /tmp/cc2yyWnV.s ignoring nonexistent directory "/usr/local/include/i486-kfreebsd-gnu" ignoring nonexistent directory "/usr/lib/gcc/i486-kfreebsd-gnu/4.4.5/../../../../i486-kfreebsd-gnu/include" ignoring nonexistent directory "/usr/include/i486-kfreebsd-gnu" ignoring duplicate directory "/usr/include" as it is a non-system directory that duplicates a system directory #include "..." search starts here: #include<...> search starts here: include include/cdTime /usr/include/ossp /usr/local/include /usr/lib/gcc/i486-kfreebsd-gnu/4.4.5/include /usr/lib/gcc/i486-kfreebsd-gnu/4.4.5/include-fixed /usr/include End of search list. GNU C (Debian 4.4.5-10) version 4.4.5 (i486-kfreebsd-gnu) compiled by GNU C version 4.4.5, GMP version 4.3.2, MPFR version 3.0.0-p3. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: ac5ecb32b9a1ba1edd331ac3e5f20c5d COLLECT_GCC_OPTIONS='-v' '-Iinclude' '-Iinclude/cdTime' '-L/usr/lib' '-I/usr/include' '-L.' '-I/usr/include/ossp' '-o' 'ipcc_test_code' '-mtune=generic' '-march=i586' as -V -Qy -o /tmp/ccgbAyMN.o /tmp/cc2yyWnV.s GNU assembler version 2.20.1 (i486-kfreebsd-gnu) using BFD version (GNU Binutils for Debian) 2.20.1-system.20100303 COMPILER_PATH=/usr/lib/gcc/i486-kfreebsd-gnu/4.4.5/:/usr/lib/gcc/
Re: [console-data] upgrade problem in preconfigure
No, its a sign that the console-data maintainer (me) doesn't know what
is the best keymap for each of the given (human) languages/keymaps, and
needs help!
If you have one of these systems, your opinion would be invaluable.
{ I want to make this go away before Sarge is released).
Regards,
Alastair
On Fri, 2002-12-06 at 11:52, Arnaud Vandyck wrote:
> I just point my apt source list to test unstable and console-data does
> not like it!... Here is the message and dselect just stop (I have to
> C-c to get out):
>
> Preconfiguring packages ...
> No default for console-data/keymap/qwerty/brazilian/standard/keymap - picking
> one
> No default for console-data/keymap/qwerty/macedonian/standard/keymap -
> picking one
> No default for console-data/keymap/qwerty/latvian/standard/keymap - picking
> one
> No default for console-data/keymap/qwerty/ukrainian/standard/keymap - picking
> one
> No default for console-data/keymap/qwerty/lithuanian/standard/keymap -
> picking one
> No default for console-data/keymap/qwerty/russian/standard/keymap - picking
> one
> No default for console-data/keymap/qwerty/canadian/variant - picking one
> No default for console-data/keymap/qwerty/turkish/standard/keymap - picking
> one
> No default for console-data/keymap/fggiod/layout - picking one
> No default for console-data/keymap/fggiod/turkish/standard/keymap - picking
> one
> No default for console-data/keymap/dvorak/layout - picking one
> No default for console-data/keymap/qwertz/german/apple_usb/keymap - picking
> one
> No default for console-data/keymap/qwertz/swiss/variant - picking one
>
> If you have information about what choice should be the default for
> the above questions which gave warnings, please mail it to
> [EMAIL PROTECTED] Thanks for your help.
>
> Can some one tell me how to solve the problem? Is it a miss
> configuration from me?
>
> Thank you for your help,
>
> -- Arnaud Vandyck <http://vbstefi60.fapse.ulg.ac.be/~arnaud/>
>
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
>
--
Alastair McKinstry <[EMAIL PROTECTED]>
GPG Key fingerprint = 9E64 E714 8E08 81F9 F3DC 1020 FA8E 3790 9051 38F4
He that would make his own liberty secure must guard even his enemy from
oppression; for if he violates this duty he establishes a precedent that
will reach to himself.
- --Thomas Paine
signature.asc
Description: This is a digitally signed message part
Re: [console-data] upgrade problem in preconfigure
Oops. Yes, I did. I don't understand why it should hang; I'll log it as a bug and investigate. Might it be due to what you installed next? (I can't reproduce it yet; any further info would help). Regards, Alastair On Fri, 2002-12-06 at 22:16, Steve Greenland wrote: > (re-arranged a little) > > On Fri, 2002-12-06 at 11:52, Arnaud Vandyck wrote: > > > I just point my apt source list to test unstable and console-data does > > > not like it!... Here is the message and dselect just stop (I have to > > > C-c to get out): > > > > > On 06-Dec-02, 12:57 (CST), Alastair McKinstry <[EMAIL PROTECTED]> wrote: > > No, its a sign that the console-data maintainer (me) doesn't know what > > is the best keymap for each of the given (human) languages/keymaps, and > > needs help! > > Alastair, did you miss the "dselect just stop (I have to C-c to > get out)" part of Arnaud's message? Because you can't just hang an > installation run because you're having to guess a default. (I don't > think you are, actually, because I've seen the barrage of keymap > messages before, but never had a problem with it hanging.) > > Steve > > -- > Steve Greenland > > The irony is that Bill Gates claims to be making a stable operating > system and Linus Torvalds claims to be trying to take over the > world. -- seen on the net > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- Alastair McKinstry <[EMAIL PROTECTED]> GPG Key fingerprint = 9E64 E714 8E08 81F9 F3DC 1020 FA8E 3790 9051 38F4 He that would make his own liberty secure must guard even his enemy from oppression; for if he violates this duty he establishes a precedent that will reach to himself. - --Thomas Paine signature.asc Description: This is a digitally signed message part
Re: [desktop] Patched kernels
On Mon, 2003-04-14 at 00:39, David Nusinow wrote: > On Sun, Apr 13, 2003 at 11:11:27PM +0200, Tollef Fog Heen wrote: > > * Colin Walters > > > > | Anthony Towns has mentioned a few times that he thinks sarge will use > > | Linux 2.6, which comes with most of the goodies like preemption already > > | included. We'll probably just need a separate kernel-image-preempt > > | package or something that debian desktop can have installed by default. > > We may be a long way off having 2.6 ready for sarge. We would like to have a preview copy of sarge by the end of the month. 2.6 may not be ready _this_year_ . > > Nobody has even begun thinking about getting d-i to work with 2.5/2.6. > > Until that is tested and works this won't fly at all. (Yes, this is a > > ?somebody, please step forward and test/fix d-i with 2.5/2.6?) > Not quite true. Nobody _officially_ has begun testing with 2.5; unofficially at least I have. Nobody has put 2.5 kernel based images for public testing. Note that with IDE, etc badly broken in 2.5, at least until recently, Its not worth doing so unless you're lucky in your hardware. > How much is broken with 2.5 right now? Could someone who's familiar > with the issues give an approximation as to how much work it would take > to adapt d-i to 2.5? > > In addition, why does d-i have to run 2.6 at all? Couldn't it run 2.4, > and install a 2.6 kernel for normal use for those that want it? > There are some advantages; eg in the kbd-chooser, the new input API lists attached keyboards in /proc; I can ask / skip the keyboard question based on this, or autodetect better (eg present a list of PS2 or USB keyboards, or both, or neither .. - ). I've been testing 2.5 for this reason, as kbd-chooser maintainer. > - David -- Alastair McKinstry <[EMAIL PROTECTED]> GPG Key fingerprint = 9E64 E714 8E08 81F9 F3DC 1020 FA8E 3790 9051 38F4 He that would make his own liberty secure must guard even his enemy from oppression; for if he violates this duty he establishes a precedent that will reach to himself. - --Thomas Paine
Re: Accepted arcboot 0.3.6 (mips source)
Hi,
I'm looking at what needs to be be done for mips support in
debian-installer, and it appears we probably need arcboot support.
Currently the installers prepare the disk image, then present a menu
option to run lilo, or grub (which get run in a chroot of the target).
Would the same work for arcboot?
( I do not have a mips box to test, but could write the package for
testing).
Regards,
Alastair McKinstry
On Tue, 2003-04-29 at 09:17, Guido Guenther wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Format: 1.7
> Date: Sat, 26 Apr 2003 22:01:14 +0200
> Source: arcboot
> Binary: arcboot tip22
> Architecture: source mips
> Version: 0.3.6
> Distribution: unstable
> Urgency: low
> Maintainer: Guido Guenther <[EMAIL PROTECTED]>
> Changed-By: Guido Guenther <[EMAIL PROTECTED]>
> Description:
> arcboot- Bootloader for SGI/MIPS IP22 machines
> tip22 - Tftp boot image builder for SGI/MIPS IP22 machines
> Changes:
> arcboot (0.3.6) unstable; urgency=low
> .
>* fix command line handling, now things like
> boot linux root=/dev/sda1 single
> should work as expected, no need to mess with OSLoadPartition
>* fix booting arbitrary files
> boot /vmlinux root=/dev/sda1
> will now properly boot OSLoadPartition/vmlinux
>* search for OSLoadPartition if the envvar is bogus
>* add missing prototypes, cleanup printf length modifiers
>* move some common definitions to subarch.h
>* use gcc-2.95
>* adding other 32bit IPs to arcboot is now a two line change
> in common/subarch.h
>* arcboot script now prints what it's doing
>* postrm: silent grep on new installs
>* echo 4 > debian/compat
>* Build-Depend: on debhelper (>=4)
>* Bump Standards Version to 3.5.9
>* add ${misc:Depends}
> Files:
> 1e768fb6482e1baac30e6cff6423a3a8 532 admin optional arcboot_0.3.6.dsc
> e5672a5492a233f88ef7b991c66fb7f5 186831 admin optional arcboot_0.3.6.tar.gz
> d0a81c2e2ea4d2bb77a764cdb74da59a 31148 admin optional arcboot_0.3.6_mips.deb
> 40104eab58df0cb2debc0b291099b257 14464 admin optional tip22_0.3.6_mips.deb
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.2.1 (GNU/Linux)
>
> iD8DBQE+qx6nn88szT8+ZCYRAmqKAJ4r7wyNeJim4XA5WpfQBHL2B247TQCfRb55
> I+zwnx68KdiWXv09A/bbT1Y=
> =7TMm
> -END PGP SIGNATURE-
>
>
> Accepted:
> arcboot_0.3.6.dsc
> to pool/main/a/arcboot/arcboot_0.3.6.dsc
> arcboot_0.3.6.tar.gz
> to pool/main/a/arcboot/arcboot_0.3.6.tar.gz
> arcboot_0.3.6_mips.deb
> to pool/main/a/arcboot/arcboot_0.3.6_mips.deb
> tip22_0.3.6_mips.deb
> to pool/main/a/arcboot/tip22_0.3.6_mips.deb
>
Bug#522772: ITP: CDO -- Climate Data Operators
Package: wnpp Severity: wishlist Owner: Alastair McKinstry * Package name: CDO Version : 1.3.0 Upstream Author : Uwe Schulzweida uwe.schulzwe...@zmaw.de * URL : http://www.mpimet.mpg.de/fileadmin/software/cdo/ * License : GPL2 Programming Lang: C Description : Climate Data Operators - tools for climate data manipulation CDO is a collection of command line Operators to manipulate and analyse Climate model Data. Supported data formats are GRIB, netCDF, SERVICE, EXTRA and IEG. There are more than 400 operators available. The following table provides a brief overview of the main categories. -- System Information: Debian Release: 5.0 APT prefers stable APT policy: (500, 'stable') Architecture: powerpc (ppc) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#522775: ITP: EMOSLIB -- ECMWF Interpolation Library
Package: wnpp Severity: wishlist Owner: Alastair McKinstry * Package name: EMOSLIB Version : 000360 Upstream Author : European Centre for Medium-range Weather Forecasts * URL : http://www.ecmwf.int/products/data/software/interpolation.html * License : LGPL v2 Programming Lang: F, Fortran Description : ECMWF Interpolation Library The Interpolation library (EMOSLIB) includes Interpolation software and GRIB, BUFR, CREX encoding/decoding routines. It is used by the ECMWF meteorological archival and retrieval system (MARS) and also by the ECMWF graphics packag MetView. -- System Information: Debian Release: 5.0 APT prefers stable APT policy: (500, 'stable') Architecture: powerpc (ppc) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#522984: ITP: magics++ -- Meteorological plotting software
Package: wnpp Severity: wishlist Owner: Alastair McKinstry * Package name: magics++ Version : 2.6.4 Upstream Author : ECMWF * URL : http://www.ecmwf.int/products/data/software/magics++.html * License : Apache license, version 2. Programming Lang: C, Fortran Description : Meteorological plotting software Magics++ is the latest generation of the ECMWF's Meteorological plotting software MAGICS. Although completely redesigned in C++, it is intended to be as backwards-compatible as possible with the Fortran interface. Besides its programming interfaces (Fortran and C), Magics++ offers MagML, a plot description language based on XML aimed at automatic web production. . The library supports the plotting of contours, wind fields, observations, satellite images, symbols, text, axis and graphs (including boxplots). . Data fields to be plotted may be presented in various formats, for instance GRIB 1 and 2 code data, Gaussian grid, regularly spaced grid and fitted data. Input data can also be in BUFR and NetCDF format or retrieved from an ODB database. . The produced meteorological plots can be saved in various formats, such as PostScript, EPS, PDF, GIF, PNG, SVG and KML. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#529453: ITP: GeoNetwork -- Catalog application to manage spatially referenced resources through the web
Package: wnpp Severity: wishlist Owner: Alastair McKinstry * Package name: GeoNetwork Version : 2.2.0 Upstream Author : e.taffour...@brgm.fr * URL : http://geonetwork-opensource.org> * License : GPL Programming Lang: Java Description : Catalog application to manage spatially referenced resources through the web Network opensource is a standards based, Free and Open Source catalog application to manage spatially referenced resources through the web. It provides powerful metadata editing and search functions as well as an embedded interactive web map viewer. This website contains information related to the use of the software. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#530247: ITP: hdf-eos -- Extension to HDF4 to support Earth Observing System datatypes
Package: wnpp Severity: wishlist Owner: Alastair McKinstry * Package name: hdf-eos Version : 2.15v1.00 Upstream Author : Hughes and Applied Research Corporation * URL : http://hdfeos.org/software.php * License : BSD Programming Lang: C Description : Extension to HDF4 to support Earth Observing System datatypes HDF-EOS is a software library that is an extension of National Center for Supercomputing Applications (NCSA) HDF. The library supports the construction of new data structures: Grid, Point and Swath. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#531032: ITP: zygrib -- Weather data visualization: GRIB file viewer
Package: wnpp Severity: wishlist Owner: Alastair McKinstry * Package name: zygrib Version : 3.4.Â1 Upstream Author : Dominique Hausser * URL : http://www.zygrib.org/ * License : GPL-3 Programming Lang: C/C++ Description : Weather data visualization: GRIB file viewer This package is a program, written with the QT toolki, to enable: * Visualisation of meteo data from files in GRIB Format 1 * Automatic GRIB data download * Automatic Download from IAC (fleetcode) Data -- System Information: Debian Release: 5.0.1 APT prefers stable APT policy: (500, 'stable') Architecture: powerpc (ppc) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#531673: ITP: oasis3 -- Coupler for exchanging fields between components of Earth system models
Package: wnpp Severity: wishlist Owner: Alastair McKinstry * Package name: oasis3 Version : 3.3 Upstream Author : Sophie Valcke * URL : http://www.prism.enes.org/PAEs/coupling_IO/software_OASIS3.php * License : GPL-2 Programming Lang: Fortran Description : Coupler for exchanging fields between components of Earth system models OASIS3 is the direct evolution of the OASIS coupler developed since more than 10 years at CERFACS (Toulouse, France). Portability and flexibility are OASIS3 key design concepts. At run-time, OASIS3 acts as a separate mono process executable, which main function is to interpolate the coupling fields exchanged between the component models, and as a library linked to the component models, the OASIS3 PRISM Model Interface Library (OASIS3 PSMILe). OASIS3 supports 2D coupling fields only. To communicate with OASIS3, directly with another model, or to perform I/O actions, a component model needs to include few specific PSMILe calls. OASIS3 PSMILe supports in particular parallel communication between a parallel component model and OASIS3 main process based on Message Passing Interface (MPI) and file I/O using the GFDL mpp_io library. OASIS3 has been extensively used in the PRISM demonstration runs and is currently used by approximately 15 climate modelling groups in Europe, USA, Canada, Australia, India and Brazil. -- System Information: Debian Release: 5.0.1 APT prefers stable APT policy: (500, 'stable') Architecture: powerpc (ppc) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#531959: ITP: g2clib -- GRIB2 encoder/decoder library from NCEP
Package: wnpp Severity: wishlist Owner: Alastair McKinstry * Package name: g2clib Version : 1.1.8 Upstream Author : NCEP (National Centres for Environmental Protection) * URL : http://www.nco.ncep.noaa.gov/pmb/codes/GRIB2/ * License : Public Domain Programming Lang : C Description : GRIB2 encoder/decoder library from NCEP This library contains "C" decoder/encoder routines for GRIB edition 2. The user API for the GRIB2 routines is described in file "grib2c.doc". -- System Information: Debian Release: 5.0.1 APT prefers stable APT policy: (500, 'stable') Architecture: powerpc (ppc) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#531982: ITP: ncl -- NCAR Command Language and NCAR graphics
Package: wnpp Severity: wishlist Owner: Alastair McKinstry * Package name: ncl Version : 5.1.0 Upstream Author : NCA * URL : http://www.ncl.ucar.edu/overview.shtml * License : BSD + advertising clause Programming Lang: C + Fortran Description : NCAR Command Language and NCAR graphics NCAR Command Language and NCAR Graphics The NCAR Command Language (NCL) is a free interpreted language designed specifically for scientific data processing and visualization. NCL has robust file input and output. It can read and write netCDF-3, netCDF-4 classic (as of version 4.3.1), HDF4, binary, and ASCII data, and read HDF-EOS2, GRIB1 and GRIB2 (as of version 4.3.0). The graphics are world class and highly customizable. As of version 5.0.0, NCL and NCAR Graphics are released as one package. The software comes with a couple of useful command line tools: * ncl_filedump - prints the contents of supported files (netCDF, HDF, GRIB1, GRIB2, HDF-EOS2, and CCM History Tape) * ncl_convert2nc - converts one or more GRIB1, GRIB2, HDF and/or HDF-EOS files to netCDF formatted files. -- System Information: Debian Release: 5.0.1 APT prefers stable APT policy: (500, 'stable') Architecture: powerpc (ppc) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#532430: ITP: udunits -- Library for the programatic handling of units of physical quantities
Package: wnpp Severity: wishlist Owner: Alastair McKinstry * Package name: udunits Version : 2.1.7 Upstream Author : UCAR * URL : http://www.unidata.ucar.edu/software/udunits/ * License : BSD Programming Lang: DaCDaC(C, C++, C#, Perl, Python, etc.) Description : Library for the programatic handling of units of physical quantities The UDUNITS package supports units of physical quantities (e.g., meters, seconds). Specifically, it supports conversion between string and binary representations of units, arithmetic manipulation of units, and conversion of numeric values between compatible units. The package is written in the C programming language. -- System Information: Debian Release: 5.0.1 APT prefers stable APT policy: (500, 'stable') Architecture: powerpc (ppc) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#532858: ITP: vis5d+ -- Vis5d, a free OpenGL-based volumetric visualization program for scientific datasets in 3+ dimensions.
Package: wnpp Severity: wishlist Owner: Alastair McKinstry * Package name: vis5d+ Version : 1.2.0 Upstream Author : Bill Hibbard * URL : http://vis5d.sourceforge.net * License : GPL Programming Lang: C Description : Vis5d, a free OpenGL-based volumetric visualization program for scientific datasets in 3+ dimensions. Vis5d+ is intended as a central repository for enhanced versions and development work on Vis5d, a free OpenGL-based volumetric visualization program for scientific datasets in 3+ dimensions. This project started out, with the blessing of the original Vis5d developers, as a conversion of Vis5d's build process to use GNU autoconf and automake. (Inspired by the difficulty of getting Vis5d to compile on the author's LinuxPPC PowerBook.) It quickly became apparent that many other enhancements were possible, and were of wide interest to users. Moreover, a large number of enhanced versions to Vis5d exist that have not been merged into the original Vis5d sources, due to time and resource limitations of the original developers, or to differences of opinion about design directions. -- System Information: Debian Release: 5.0.1 APT prefers stable APT policy: (500, 'stable') Architecture: powerpc (ppc) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Maps within Debian
Hi, I am working on some packages for Debian Meteorology (http://wiki.debian.org/DebianScience/Meteorology): magics++ , a plotting / graphics library / scripting system , and zyGrib, a GRIB (met. format) file viewer. They both include some coastline maps from "gshhs" (http://www.ngdc.noaa.gov/mgg/shorelines/gshhs.html), the "Global Self-Consistent Heirarchical High-Resolution Shoreline database. This data is GPL'd, created by the same people as "gmt". zyGrib contains 23M of "low-res" maps, with an additional package of 101 MB optional high-res maps. magics++ has 21 MB in one file from this set; the files are in their own .b format. It makes sense to build these files into their own shared package. Now, it appears that these are the same data files in 'gmt' (Generic Mapping Tools) a lower-res version of the coast files are provided in netCDF format in gmt-coast-low (5.5 MB worth). There was a higher-resolution package gmt-coast-high, but this was removed as it took up too much space in Debian. Does anyone know this code? It appears as though the gmt-coast-low is not sufficient for zyGrib and magics++, and I'm not familiar with the history of "gmt" beyond the README. Any ideas or recommendations as to how to proceed? Regards Alastair McKinstry **
maps / coastline files within Debian
Hi, I am working on some packages for Debian Meteorology (http://wiki.debian.org/DebianScience/Meteorology): magics++ , a plotting / graphics library / scripting system , and zyGrib, a GRIB (met. format) file viewer. They both include some coastline maps from "gshhs" (http://www.ngdc.noaa.gov/mgg/shorelines/gshhs.html), the "Global Self-Consistent Heirarchical High-Resolution Shoreline database. This data is GPL'd, created by the same people as "gmt". zyGrib contains 23M of "low-res" maps, with an additional package of 101 MB optional high-res maps. magics++ has 21 MB in one file from this set; the files are in their own .b format. It makes sense to build these files into their own shared package. Now, it appears that these are the same data files in 'gmt' (Generic Mapping Tools) a lower-res version of the coast files are provided in netCDF format in gmt-coast-low (5.5 MB worth). There was a higher-resolution package gmt-coast-high, but this was removed as it took up too much space in Debian. Does anyone know this code? It appears as though the gmt-coast-low is not sufficient for zyGrib and magics++, and I'm not familiar with the history of "gmt" beyond the README. Any ideas or recommendations as to how to proceed? Regards Alastair McKinstry -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Unicode 7.0 released - some packages contain outdated embedded data copies
I updated unicode-data already to 7.0, so the data is present and packaged in Debian so there is no need to fetch via curl, etc. Build-Dep on unicode-data and then updates should simply be a binNMU ? regards Alastair On 18/06/2014 14:40, Paul Wise wrote: > On Wed, Jun 18, 2014 at 9:22 PM, Henrique de Moraes Holschuh wrote: > >> Make it generic, instead. You could just automatize the table update >> through a script, and allow it to either fetch the data over the network >> using curl/wget/whatever (default), or to get the data from a local file. > That would indeed be the best way to do it, some packages already do > IIRC. In any case the data shouldn't be embedded in the upstream > VCS/tarball since it is externally maintained and can therefore easily > get out of date. > -- Alastair McKinstry, , , https://diaspora.sceal.ie/u/amckinstry A decent provision for the poor is the true test of civilization. ~Samuel Johnson, Boswell: Life of Johnson -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53a1b163.8060...@sceal.ie
Re: MATE 1.8 has now fully arrived in Debian
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 26/06/2014 15:33, Marco d'Itri wrote: > On Jun 26, Thorsten Glaser wrote: > >> Yes, I fully agree. But _please_ also realise that there are people, >> a non-neglibile number of them, for whom these frameworks are not an >> improvement, and who wish to be not forced to use them. > A few people said this about udev as well. Now they use udev. ... and complain or suffer in silence. Don't take popcon as a measure of people being happy to use a critical dependency like udev. I've udev installed on some servers as a dependency of many packages, but udev itself is disabled in scripts as it keeps crashing on my hardware. (Old powerpc server). > > > -- > Alastair McKinstry, , , https://diaspora.sceal.ie/u/amckinstry > A decent provision for the poor is the true test of civilization. > ~Samuel Johnson, Boswell: Life of Johnson -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTrDUyAAoJEN9LdrZRJ3Qsm2oP/iyeqCgVYH5VaVLhNrCOZiPw H2Hoiy396dB0LXidHZS71Uq4U3NshIktuCVar6jz3dlWNCB2kQq4lASlcNNnDKBu RHtDKL9XF90YRooQU+E6HATGGokUbQFIEeDqQ5rl/2PUhgsaK1W3RFk35BHD4HAs 8+YQdBbkSG3sGdKIJu7mpY81AehV/syTqYY1q524h63ErdM7qeTo344h3Q7aneD4 DtVQ29S1cBApKo4J5knI+YvyQ942faxTAamrBi/tDKNG/riS9oiZ+W2XhWjCCWYf 7UFeWLecCK31nnSsgQWrvvAWqVQ1KCRwxHGmoGzLlsZwK4tLAd/9dyMDQJS0cS/U SWS1FZzOqDc3K1PV1V/D8LyaOyCbdffQjAX9M2Son2hrZhzaidkWzozEsF+vqBn3 urLrCjL2Hx5ZOtQ2zyJcOxEkmiflh+wGjCjiZkusuVJ5NjjYzva1BV7dmfdXwKNz kO/7phITNZ4PEPOtA07/z8CyTK91JGj5uSaTdVyh7Q/YxnHFOLE2mRmf0ptCrer3 SfOwN3KZK6qhBD+A0IWputnZPD+SEuIgA0hgskK/BfXPvtNF2pHg4UNmUmZT8s22 fGNpVOiq9IihPJgyzqXYX5ZSu39w6UixiJKW8hDWj7SLQafhTwEBi4POsYP6J2+F HkLnorBtNqqZDKA5nteZ =IOMt -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: https://lists.debian.org/53ac3532.1040...@debian.org
Re: MATE 1.8 has now fully arrived in Debian
On 26/06/2014 17:43, Paul Wise wrote: > On Thu, Jun 26, 2014 at 10:58 PM, Alastair McKinstry wrote: > >> udev itself is disabled in scripts as it keeps crashing >> on my hardware. (Old powerpc server). > Which bug number is this? > This is a bug that I _think_ (following the lists) has since been fixed upstream, but I am reluctant to test on an operational server with unusual hardware. In practice for my use case I can just ignore it; there are few event changes on the system and I can live with just disabling udev , killing it on reboot, but I can't remove it from the system as there are dependencies in other code on it. I will test again when updating to jessie, but until then I prefer to leave the server alone. udev has not really been a problem for me. My concern was using popcon as a measure of success of a package when its "required dependency" and lack of realistic alternatives is the crux of the argument. My fear is that systemd + friends are becoming a required framework, subverting the Unix ethos of a bunch of co-operating tools and libraries. It becomes increasing impossible to simply replace a component I might disagree with, or that breaks my use case, with one I develop because of all the cross-dependencies. While "if you disagree, write a replacement" is the traditional answer in Linux/Debian, we need to look out and make sure that remains possible. regards Alastair -- Alastair McKinstry, , , https://diaspora.sceal.ie/u/amckinstry -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53ad3255.4050...@sceal.ie
Re: MATE 1.8 has now fully arrived in Debian
My fear is that systemd + friends are becoming a required framework, subverting the Unix ethos of a bunch of co-operating tools and libraries. It becomes increasing impossible to simply replace a component I might disagree with, or that breaks my use case, with one I develop because of all the cross-dependencies. While "if you disagree, write a replacement" is the traditional answer in Linux/Debian, we need to look out and make sure that remains possible. regards Alastair > Wouldn't glibc then fall into the list of things you don't like as a > "required framework"? By that logic, all libraries must be hot-swappable > with no additional effort by the end-user. That's just not realistic. > > -Michael > A good example, but even in the case of key components like the kernel and libc, we've got drop-in replacements in Debian. This is in large part because there were well-defined APIs, dating to a project that (practically) predates Debian: POSIX. glibc basically implements POSIX + adds some functionality; creating a drop-in is/was possible as shown by BSD, eglibc, etc. Now Poettering (and others) has been dismissive of POSIX and sets out to effectively replace it with something more modern; arguably a good thing to do on technical grounds but changing the "ground rules" or assumptions we're used to. Another example is the shutdown/policykit discussion elsewhere in this thread. It looks like the functionality it offers is a good enhancement, but it pulls in the whole of systemd in practice, bringing along the baggage of 'no separate /usr', etc. design choices that I might disagree with. It _should_ be possible to write a libpolicykit-alt that provides a policykit API ( or dbus interface? i'm unfamiliar with how processes call policykit) but offers a possibly degraded functionality on systems where policykit is not present. But here i'm chasing systemd's taillights. I think that for fundamental changes such as systemd are implementing we need somehow to carefully write out an API such that it remains possible to do such things. We need to recognise that systemd is a major change, crossing a line compared to a usual package or set of packages (even big ones like KDE, GNOME) and apply a larger "design process" of some kind in Debian to enable us to make changes in the future. -- Alastair McKinstry, , , https://diaspora.sceal.ie/u/amckinstry A decent provision for the poor is the true test of civilization. ~Samuel Johnson, Boswell: Life of Johnson -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53ad4f1b.6040...@sceal.ie
Re: New dash in experimental
On 20/10/2014 13:50, Thorsten Glaser wrote: > sofia-sip 1.12.11+20110422.1-2 Failed [UNKNOWN] /bin/sh: 4: pushd: not > found >> bashism, you should reportbug that, RC severity (Policy 10.4) > hdf-eos4 2.19v1.00+dfsg.1-1 Failed [UNKNOWN] ../libtool: 1: eval: > base_compile+= -c: not found > libvisca 1.0.1-1 Failed [UNKNOWN] ../libtool: 1: eval: base_compile+= -c: not > found > ntop 3:5.0.1+dfsg1-2 Failed [UNKNOWN] ./libtool: 1: eval: base_compile+= -c: > not found >> (incidentally, all those += as well) This looks like a false positive in testing. hdf-eos4 at least uses the system libtool (which has moved from libtool to libtool-bin, leading to a FTBFS I need to fix). The system libtool has an explicit #!/bin/bash > To be completely fair, you should repeat the very same source package > builds, with the very same archive snapshot in use (actually, for > rebuilds like this, using snapshot.d.o as the *only* entry in > sources.list, for both deb and deb-src, is the way to go) as during > the initial rebuild against the new dash version, to diff failures. > (Or rebuild stock archive first, filter out failures, then rebuild > what built.) bye, //mirabilos -- Alastair McKinstry, , , https://diaspora.sceal.ie/u/amckinstry Software is like Poetry - most of it shouldn't have been written. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54452570.8030...@sceal.ie
Bug#668596: ITP: irods -- Data grid storage management system
Package: wnpp Severity: wishlist Owner: Alastair McKinstry * Package name: irods Version : 3.1 Upstream Author : DICE research group * URL : http://www.irods.org/ * License : BSD Programming Lang: C Description : Data grid storage management system iRODS, the Integrated Rule-Oriented Data System, is a data grid software system developed by the Data Intensive Cyber Environments research group (developers of the SRB, the Storage Resource Broker), and collaborators. The iRODS system is based on expertise gained through a decade of applying the SRB technology in support of Data Grids, Digital Libraries, Persistent Archives, and Real-time Data Systems. iRODS management policies (sets of assertions these communities make about their digital collections) are characterized in iRODS Rules and state information. At the iRODS core, a Rule Engine interprets the Rules to decide how the system is to respond to various requests and conditions. -- 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/20120413094422.25133.84455.report...@ailm.sceal.ie
Bug#668598: ITP: ecaccess -- clients to access ECMWF facilities
Package: wnpp Severity: wishlist Owner: Alastair McKinstry * Package name: ecaccess Version : 4.0.0 Upstream Author : laurent.goug...@ecmwf.int * URL : http://www.ecmwf.int/services/ecaccess * License : Perl Artistic License Programming Lang: Perl Description : clients to access ECMWF facilities ecaccess is a suite of client tools to enable access to the computing and data archive facilities of the European Centre for Medium-Range Forecasts (ECMWF). . Strict authentication is performed in a uniform way using SecurID cards and standard (X509) certificates. SSL is used to guarantee the integrity of the application data, the transferred jobs and the monitoring information. Ã -- 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/20120413100553.25449.66742.report...@ailm.sceal.ie
Bug#669260: ITP: pygrib -- python library for reading/writing GRIB files
Package: wnpp Severity: wishlist Owner: Alastair McKinstry * Package name: pygrib Version : 1.9.3 Upstream Author : Jeff Whittaker * URL : https://pygrib.googlecode.com/svn/trunk/docs/index.html * License : BSD Programming Lang: Python Description : python library for reading/writing GRIB files Python module for reading and writing GRIB (editions 1 and 2) files. GRIB is the World Meterological Organization standard for distributing gridded data. The module is a python interface to the GRIB API C library from the European Centre for Medium-Range Weather Forecasts (ECMWF). -- 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/20120418141137.12432.27567.report...@ailm.sceal.ie
console-tools removal from sid / wheezy?
Hi, Ok, might we proceed with the console-tools removal for wheezy? Bugs have been filed against the following packages: #645937 goto-fai #671079 hotkey-setup #671081 hibernate #671082 gcpegg to move to kbd rather than console-tools. regards Alastair On 2011-10-19 16:37, Sven Joachim wrote: > On 2011-10-19 14:35 +0200, Alastair McKinstry wrote: > >> I propose to remove console-tools from sid, in favour of kbd. >> This is long planned: console-tools has been dead upstream for many >> years, with only Debian and derivatives >> still using it; For squeeze, kbd was made priority: optional and >> console-tools priority: extra >> (both provide virtual console-utilities). >> >> Does anyone have any objections? > There seem to be a few packages which still depend on console-tools > without an alternative dependency on kbd or console-utilities, e.g. > goto-fai or gcpegg. You probably want to file bugs against those. > > Otherwise, removing console-tools is a good idea IMO. > > Cheers, >Sven > > -- 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/4fa13804.9090...@debian.org
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
Bug#679237: ITP: ecflow -- Work flow controller for running programs based on time or dependencies
Package: wnpp Severity: wishlist Owner: Alastair McKinstry * Package name: ecflow Version : 2.0.30 Upstream Author servic...@ecmwf.int * URL : http://software.ecmwf.int/wiki/display/ECFLOW/Home * License : Apache Programming Lang: python, C++ Description : Work flow controller for running programs based on time or dependencies ecFlow is a work flow package that enables users to run a large number of programs ( with dependencies on each other and on time) in a controlled environment. It provides reasonable tolerance for hardware and software failures, combined with good restart capabilities. ecFlow submits tasks(jobs) and receives acknowledgements from tasks when they change status and when they send events, using child commands embedded in the scripts. ecflow stores the relationship between tasks, and is able to submit tasks dependent on triggers. -- 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/20120627111609.21401.26379.report...@ailm.sceal.ie
Re: versioned dependency on the libhdf5-7 virtual package
For libhe5-hdfeos0, i'm working on this.
One thing I need to check is HDF5 dependencies. he5-hdfeos0 was built
and tested
against HDF5 1.8.7. Since then HDF5 has a new version 1.8.8 with some
significant
changes; a new HDFEOS5 upstream was released to use it (5.1.14).
HDF5 1.8.8 is in Debian. I need to confirm the old HDFEOS5 works with
the new HDF5,
if not i'll have to bump to the latest HDFEOS5 upstream (which I don't
want to do
unnecessarly in wheezy, because of the freeze).
So, the plan is to:
* rebuild hee5-hdfeos50 against hdf5 1.8.8 and fix the dependencies as
described.
If this works, fine.
* If not, build the new he5-hdfeos0 and ask the release admins nicely.
regards
Alastair
On 2012-09-13 14:07, Ivan Shmakov wrote:
> This issue was already discussed [1], and I've filed the
> respective bug report [2] (to which there was no reply so far,
> though), but now I see that there's a few more packages in
> Wheezy with a dependency on libhdf5-7. Consider, e. g.:
>
> $ bzcat \
> < http.debian.net/debian/dists/wheezy/main/binary-amd64/Packages.bz2 \
> | gawk '/^Package: / { pkg = $2; } /Version: / { vers = $2; }
> / libhdf5-7 \(/ { printf("%-23s %s\n", pkg, vers); }'
> libhe5-hdfeos0 5.1.13.dfsg.1-3
> libhdf5-7-dbg 1.8.8-9
> libhdf5-dev 1.8.8-9
> cgns-convert3.1.3.4-1
> libnexus0 4.2.1-svn1614-1+b1
> libnexus0-java 4.2.1-svn1614-1+b1
> nexus-tools 4.2.1-svn1614-1+b1
> r-cran-hdf5 1.6.10-1
> tessa 0.3.1-6
> tessa-mpi 0.3.1-6
> udav0.7.1.2-3
> $
>
> Any chance this issue will be rectified? (Or should I file bug
> reports against these packages?)
>
> TIA.
>
> [1] news:udlvci28as8@dr-wily.mit.edu
> http://permalink.gmane.org/gmane.linux.debian.science/5353
> [2] http://bugs.debian.org/680400
>
--
Alastair McKinstry , Computational Scientist
ICHEC, Room 301, IT Building NUI Galway, Galway , Ireland
tel: +353 91 495946
--
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/50530b92.4000...@ichec.ie
Bug#709631: ITP: cdftools -- A fortran package for diagnostics of ocean model output
Package: wnpp Severity: wishlist Owner: Alastair McKinstry * Package name: cdftools Version : 3.0 Upstream Author : Jean-Marc.Molines * URL : http://servforge.legi.grenoble-inp.fr/projects/CDFTOOLS * License : GPL Programming Lang: Fortran Description : A fortran package for diagnostics of ocean model output CDFTOOLS is a diagnostic package written in fortran 90 for the analysis of NEMO model output in the frame of the DRAKKAR project. NEMO (Nucleus for European Modelling of the Ocean) is a state-of-the-art modeling framework for oceanographic research, operational oceanography seasonal forecast and climate studies. -- 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/20130524150339.29485.98637.report...@ailm.sceal.ie
gfortran: binNMU needed?
Hi, With gcc-4.8, gfortran has (again) changed the format for its .mod files. The result of this is that it is no longer possible to use fortran modules in sid, in at least 2 packages: Fatal Error: Cannot read module file 'grib_api.mod' opened at (1), because it was created by a different version of GNU Fortran Known packages: netcdf, grib-api I think these can be fixed with a simple binNMU; is one planned? More long-term, is there anything we can do about this? A more stable version of the 'mod' file? Best regards Alastair -- Alastair McKinstry , , http://diaspora.sceal.ie/u/amckinstry 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/51d9a98d.3010...@debian.org
Bug#644096: ITP: vistrails -- Scientific visualisation workflow tool
Package: wnpp Severity: wishlist Owner: Alastair McKinstry * Package name: vistrails Version : 2.0.alpha Upstream Author : U. of Utah * URL : http://www.vistrails.org * License : BSD Programming Lang: python Description : Scientific visualisation workflow tool VisTrails is an open-source scientific workflow and provenance management system developed at the University of Utah that provides support for data exploration and visualization. Whereas workflows have been traditionally used to automate repetitive tasks, for applications that are exploratory in nature, such as simulations, data analysis and visualization, very little is repeated---change is the norm. As an engineer or scientist generates and evaluates hypotheses about data under study, a series of different, albeit related, workflows are created while a workflow is adjusted in an interactive process. VisTrails was designed to manage these rapidly-evolving workflows. -- 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/20111002190205.21529.8880.report...@ailm.sceal.ie
Re: Bits from dpkg developers - dpkg 1.16.1
On 2011-10-02 23:08, Henrique de Moraes Holschuh wrote: On Sun, 02 Oct 2011, Florian Weimer wrote: Couldn't we get rid of static libraries altogether, replacing static linking with ahead-of-time dynamic linking? [1] but I don't feel strong enough about it to get in the way if we do decide to drop static libs. I would defend static libs for scientific apps. Static libs show a significant performance benefit (2-40%, median around 5-10% but sometimes far more with C++ apps) and so are standard in HPC still; so I ship them in my packages even though they are not used much within the software shipped _by_ debian, but are used by our users. Note: this is for static libs without -fPIC. I'm not sure there is much benefit in shipping PIC static libs, (or potentially PIE codes); they are also highly unlikely to be used in 'web-facing' environments, and be security-sensitive; they are likely to be built by the user, used by that particular user alone, and hence should not be built with any security features( eg PIE) that cause performance degradation. -- 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/4e898c5b.4010...@sceal.ie
A Common cmake config directory
Hi, I have a package that installs cmake configuration files, xdmf. This seems to be a growing trend: at the moment it installs: amckinstry@debian:/usr/lib/XdmfCMake$ ls -l total 12 -rw-r--r-- 1 root root 651 Jul 15 14:02 XDMFBuildSettings.cmake -rw-r--r-- 1 root root 2724 Jul 15 14:02 XDMFConfig.cmake -rw-r--r-- 1 root root 1867 Jul 15 14:02 XDMFLibraryDepends.cmake These are arch-dependent and will need their own new directory under multiarch. Are there any standards yet (or planned) for such files? /usr/lib/$(DEB_HOST_MULTIARCH)/cmake ? -- 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/4e8c31b2.2090...@debian.org
Bug#644586: ITP: exodusII -- Finite element analysis storage library
Package: wnpp Severity: wishlist Owner: Alastair McKinstry * Package name: exodusII Version : 5.1 Upstream Author : Gregory Sjaardema * URL : http://sourceforge.net/projects/exodusii/ * License : BSD Programming Lang: C Description : Finite element analysis storage library EXODUS II is a model developed to store and retrieve transient data for finite element analyses. It is used for preprocessing, postprocessing, as well as code to code data transfer. ExodusII is based on netcdf. Includes the nemesis parallel extension. -- 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/20111007080348.32380.81086.report...@ailm.sceal.ie
Re: Coinstallability of Fortran libraries built with different compilers
Cross-posting this to debian-devel for greater visibility on multiarch, On 2011-10-20 17:30, Enrico Zini wrote: Hello, another issue caused by a lack of standards for Fortran .mod files is that one cannot use, say, gfortran, to link to a library built with another compiler like ifort. We are starting to need to install development systems that would allow both a gfortran toolchain and an ifort toolchain. That would mean having to compile all libraries twice, and installing them twice in the system. I have been experimenting with hacks like installing gfortran files in /usr/include and /usr/lib and ifort files in /usr/include/ifort and /usr/lib/ifort, and with a bit of insisting, things can be made to work. That has also the nice property that standard Debian packages, that are built with gfortran, fit normally in the system. Is that a solution as good as anything, or are you doing something better? One point to think of is how this works with multiarch, which is being introduced in Debian. Instead of 'ifort' should we use the architecture triplet, eg. i386-linux-intel instead ? Then the libraries go in i386-linux-intel rather than i386-linux-gnu for gfortran; ditto for the .mod files in /usr/include/i386-linux-intel I'd avoid /usr/include/ifort as it looks too much like a subdirectory used by package ifort, rather than somewhere netcdf would expect to find its stuff, etc. Following the multiarch pattern means we can use pkg-config correctly for Intel compilers; e.g. /usr/lib/i386-linux-intel/pkgconfig contains the .pc files for the Intel versions; we can either then set the PKG_CONFIG_PATH or use the 'cross-compiler pkgconfig' to get pkg-config to Do The Right Thing. Regards Alastair Ciao, Enrico -- 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/4ea13b20.7060...@sceal.ie
Re: Coinstallability of Fortran libraries built with different compilers
On 2011-10-23 08:45, Enrico Zini wrote: On Sat, Oct 22, 2011 at 04:24:23PM -0700, Steve Langasek wrote: One point to think of is how this works with multiarch, which is being introduced in Debian. Instead of 'ifort' should we use the architecture triplet, eg. i386-linux-intel instead ? Then the libraries go in i386-linux-intel rather than i386-linux-gnu for gfortran; ditto for the .mod files in /usr/include/i386-linux-intel i386-linux-intel does not yet officially exist. Where are the triplets specified? I was using this as an example. Similar issues exist with other (proprietary) compilers. I'm not familiar with this i386-linux-intel triplet. Is this a triplet targeted by the toolchain? Does software built for this target not use GNU libc? (I guess I can't presume that it uses any libc at all, since we're speaking specifically of fortran here.) I'm not sure about libc dependencies of fortran binaries, I'll leave Alastair to answer that bit. My understanding on library use and ABI compatibilities is that the critical point are .mod files in /usr/include, whereas .a or .so files are perfectly reusable across compilers. Yes, the problem is that .mod files are architecture and compiler dependent. Hence it is important that the discovery path for them is not arch. and compiler dependent too: e.g. pkg-config needs to be used accordingly to discover the appropriate path (use pkg-config --variable=fflags rather than --cflags, which returns -I or -M for the appropriate compiler, for the appropriate path). I believe that, as of current versions, intel compilers icc and ifort generate .a and .so files that are perfectly reusable. This has not been guaranteed with compiler and version, though: some have (had) incompatible extensions so that while they link with GNU libc, the reverse was is not true. This is similar in concept to i386 / amd64 only being backward compatible, etc. Hence the usefulness of the multiarch concept in this case. That means that fortran binaries compiled with any compiler are free to depend on C libraries built with any compiler. For example, /usr/lib/libnetcdff.so links with curl, libm, libc, libhdf5, and plenty others according to ldd. Ideally one would want to have parallel, per-compiler versions of fortran libraries, because of the different .mod file formats, and then share all the chain of C dependencies. Ciao, Enrico -- 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/4ea3dce2.8020...@sceal.ie
Bug#646433: ITP: gadap -- GrADS support package for access to OpenDAP station data
Package: wnpp Severity: wishlist Owner: Alastair McKinstry * Package name: gadap Version : 2.0 Upstream Author : Institute of Global Environment and Society (IGES) * URL : http://www.iges.org/grads/gadoc/supplibs.html * License : GPL Programming Lang: C++ Description : GrADS support package for access to in-situ OpenDAP data This package enables access to OpenDAP data via OpeNDAP for the GrADS climate data analysis package. -- 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/20111024091710.30317.45365.report...@ailm.sceal.ie
Bug#649074: ITP: drslib -- python library for processing climate data with the Data Reference Syntax
Package: wnpp Severity: wishlist Owner: Alastair McKinstry * Package name: drslib Version : 0.3.0a3 Upstream Author : Stephen Pascoe * URL : http://esgf.org/esgf-drslib-site/ * License : BSD Programming Lang: Python Description : python library for processing climate data with the Data Reference Syntax Drslib is a Python library for processing the 5th Climate Model Intercomparison Project (CMIP5) Data Reference Syntax (DRS). It includes API-level code for working with DRS components, algorithms for decuding DRS components from incomplete information and a command-line tool for manipulating data files into the recommended DRS directory structure. It has been developed by the Centre for Environmental Data Archival as part of the ESG Federation. -- 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/2017103315.9145.81739.report...@ailm.sceal.ie
Bug#649690: ITP: metaconfig -- python ConfigParser bootstraping library
Package: wnpp Severity: wishlist Owner: Alastair McKinstry * Package name: metaconfig Version : 0.1.4a1 Upstream Author : Stephen Pascoe * URL : http://pypi.python.org/pypi/metaconfig * License : BSD Programming Lang: Python Description : python ConfigParser bootstraping library Metaconfig is a library for centralising Python's ConfigParser files. It is inspired by the logging module where it is increadibly easy to start writing code that depends on logging whilst deferring how log messages will be handled until later. -- 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/2023090511.21614.51443.report...@ailm.sceal.ie
Bug#650261: ITP: thredds -- Data server (middleware) for scientific data
Package: wnpp Severity: wishlist Owner: Alastair McKinstry * Package name: thredds Version : 4.2.9 Upstream Author : UCAR * URL : http://www.unidata.ucar.edu/software/tds/ * License : MIT Programming Lang: Java Description : Data server (middleware) for scientific data The THREDDS Data Server (TDS) is a web server that provides metadata and data access for scientific datasets, using OPeNDAP, OGC WMS and WCS, HTTP, and other remote data access protocols. -- 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/2028104337.19678.78864.report...@ailm.sceal.ie
New version of newt in experimental
Hi, I've uploaded a new version of newt, 0.52.14, to experimental. While it has minor changes in the upstream version, the debian version has some big changes, including moving from dbs to dh + quilt (source format 3), dh_python2, and others. So I would appreciate some testing before uploading to unstable. In particular, the bits i'm not confident of my own testing are: * cross-compiling. Are there regressions in cross-compiling, non-intel platforms * installation: I've removed conflicts / dependencies on packages from before oldstable. This should be safe, but those are famous last words * BIDI: I've had to refresh this patch, and fix a crash in it. I don't know and LTR languages. Regards Alastair McKinstry -- 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/4edcaa3b.2090...@debian.org
Porter help needed: CCSEapps
Hi,
I have a package CCSEapps that needs a quick look at by porters.
/
// TODO -- add more machine descriptions.
//
#if !(defined(__alpha)|| \
defined(_CRAY1) || \
defined(_CRAYT3E) || \
defined(__sgi) || \
defined(__sun) || \
defined(__i486__) || \
defined(i386) || \
defined(__i386__) || \
defined(__ia64__) || \
defined(__x86_64__) || \
defined(__hpux) || \
defined(_MSC_VER) || \
defined(_AIX))
#error We do not yet support FAB I/O on this machine
#endif
basically its only one file: CCSEApps/BoxLib/FPC.cpp
containing a bunch of stuff like:
const
IntDescriptor&
FPC::NativeLongDescriptor ()
{
#if defined(__alpha) || defined(__i486__) || defined(WIN32) ||
defined(i386) || defined(__i386__) || defined(__ia64__) ||
defined(__x86_64__)
static const IntDescriptor nld(sizeof(long),
IntDescriptor::ReverseOrder);
#endif
#ifdef _CRAY1
static const IntDescriptor nld(sizeof(long),
IntDescriptor::NormalOrder);
#endif
#if defined(__sgi) || \
defined(__sun) || \
defined(_AIX) || \
defined(_CRAYT3E) || \
defined(__hpux)
static const IntDescriptor nld(sizeof(long),
IntDescriptor::NormalOrder);
#endif
return nld;
}
ie. whether the arch is little / big endian, supports IEEE arithmetic, etc.
Can anyone help?
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.
Re: severity for bugs in ignoring TMP/TMPDIR?
On 2012-02-05 11:04, Sune Vuorela wrote: > On 2012-02-05, Paul Wise wrote: >> If I notice that software in Debian is ignoring TMP/TMPDIR (since I use >> libpam-tmpdir), what severity should I file the resulting bugs at? > wishlist? > > /Sune > Depends on how bit the files it uses in tmpdir. I've a bug in some code i'm using ( a FUSE filesystem that uses a cache in /tmp) that runs as root, that at times places arbitrarily large files (in my workflow, 5-100 GB) in /tmp, which is on the root filesystem. When a process accesses a 100 GB file it overflows / . So I needed to get it to use an alternate $TMPDIR. Ignoring $TMPDIR is a critical severity bug for me. - 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/4f2e6676.8020...@sceal.ie
Re: Bug#657949: Cannot install libhdf5-mpi-dev and libnetcdf-dev
On 2012-02-02 01:43, Steve M. Robbins wrote:
> Hi,
>
> I'd like to contribute towards a solution for this. I'm forwarding to
> debian-devel to get some others' ideas.
> Naively, I don't understand why netcdf can't offer multiple variants,
> just as hdf5 does. Or, at least, one package libnetcdf-mpi-dev that
> links with the "default" MPI implementation.
>> I am not involved in the netcdf. You should report a bug on this
>> package.
> I'm prepared to do so, but I'd first like to get agreement that
> netcdf is where the problem lies. Netcdf maintainers, please
> chime in!
>
>
> I think we can no longer live in the status quo (see all the blockers
> of #631019), so something has to give. Even if it is painful, perhaps
> Debian could pioneer something and pass patches back to upstream?
>
> Thoughts?
>
> -Steve
>
As of now, I have several packages (eg ADIOS, CDO) that used to build
against netcdf and libhdf5-mpi-dev
that don't. Without fixes to netCDF (I appreciate what Francesco says
about netcdf upstream
not giving the libraries proper names), there needs to be a regression:
either the packages
build with netcdf but no MPI, or MPI but no netcdf.
I could split the package, and provide two versions, eg. adios-mpi and
adios-serial, but this to me is going backwards.
In an increasingly parallel world, we need binaries that will run in
parallel when its available. eg. detect
an MPI environmnent, and if so, use the parallel version of libraries.
Do others think this is the way to go, or that way lies madness?
That is, can we work out the details of what would be needed for
"automatic parallelism",
what we can do and what upstream changes might be needed?
e.g. we might add some shim code at the start of programs that do:
if (mpi_detected || ($ENV{NETCDF_SERIAL_WANTED})
dlopen(netcdf_mpi_version)
else
dlopen(netcdf_serial_version)
(Some netCDF programs, even running under MPI, might run in serial mode
in order to use
features such as compression that don't work in parallel netcdf).
We need to come up with:
(1) A bigger picture of where we want Debian to go (may involve upstream
changes)
(2) A plan for that we can do for the next release.
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/4f30eea0.7030...@debian.org
Re: Bug#657949: Cannot install libhdf5-mpi-dev and libnetcdf-dev
Hi Francesco, Do you recommend that we build the next NetCDF from 4.1.1 or should we use the 4.1.3 from experimental as the base? Regards Alastair On 2012-02-07 13:17, Francesco P. Lovergine wrote: > On Tue, Feb 07, 2012 at 09:28:00AM +0000, Alastair McKinstry wrote: >> On 2012-02-02 01:43, Steve M. Robbins wrote: >>> Hi, >>> >>> I'd like to contribute towards a solution for this. I'm forwarding to >>> debian-devel to get some others' ideas. >>> Naively, I don't understand why netcdf can't offer multiple variants, >>> just as hdf5 does. Or, at least, one package libnetcdf-mpi-dev that >>> links with the "default" MPI implementation. >>>> I am not involved in the netcdf. You should report a bug on this >>>> package. >>> I'm prepared to do so, but I'd first like to get agreement that >>> netcdf is where the problem lies. Netcdf maintainers, please >>> chime in! >>> >>> >>> I think we can no longer live in the status quo (see all the blockers >>> of #631019), so something has to give. Even if it is painful, perhaps >>> Debian could pioneer something and pass patches back to upstream? >>> >>> Thoughts? >>> >>> -Steve >>> >> As of now, I have several packages (eg ADIOS, CDO) that used to build >> against netcdf and libhdf5-mpi-dev >> that don't. Without fixes to netCDF (I appreciate what Francesco says >> about netcdf upstream >> not giving the libraries proper names), there needs to be a regression: >> either the packages >> build with netcdf but no MPI, or MPI but no netcdf. >> > The problem is the following: with latest update to hdf5, the chain of > dependencies changed, so that now libnetcdf6 depends on the pure serial > version of hdf5, while the previous one depended on serial or parallel: > > Version: 1:4.1.1-6+b1 > Depends: libc6 (>= 2.7), libcurl3-gnutls (>= 7.16.2), libgcc1 (>= 1:4.1.1), > libgfortran3 (>= 4.3), libhdf5-7 (>= 1.8.7), libquadmath0 (>= 4.6), > libstdc++6 (>= 4.4.0) > > Version: 1:4.1.1-6 > Depends: libc6 (>= 2.7), libcurl3-gnutls (>= 7.16.2-1), libgcc1 (>= 1:4.1.1), > libgfortran3 (>= 4.3), libhdf5-serial-1.8.4 | libhdf5-1.8.4, libquadmath0 (>= > 4.6), libstdc++6 (>= 4.4.0) > > So at least at packaging level, that should be fixed to follow the previous > criteria. > > That said, indeed NetCDF provides nc_create_par and nc_open_par in both serial > and parallel versions, but needs to be built with --enable-parallel to take > advantage of parallel I/O in HDF5, else it works in pure serial mode. > -- 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/4f328767.1060...@debian.org
Bug#660347: ITP: python-cdo -- python wrapper for CDO climate Data Operators
Package: wnpp Severity: wishlist Owner: Alastair McKinstry * Package name: python-cdo Version : 1.5.4 Upstream Author : uwe.schulzwe...@zmaw.de * URL : https://code.zmaw.de/projects/cdo * License : GPL Programming Lang: python Description : python wrapper for CDO climate Data Operators Climate Data Operators are a collection of command line Operators to manipulate and analyse Climate model Data. Supported data formats are GRIB, netCDF, SERVICE, EXTRA and IEG. There are more than 400 operators available. This package provides a Python interface to CDO. -- 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/20120218134559.28490.65199.report...@ailm.sceal.ie
Bug#693829: ITP: python-iapws -- Python implementation of the international APWS-IF97 steam tables
Package: wnpp Severity: wishlist Owner: Alastair McKinstry * Package name: python-iapws Version : 1.0.0 Upstream Author : jjgomera * URL : http://pypi.python.org/pypi/iapws * License : GPL Programming Lang: Python Description : Python implementation of the international APWS-IF97 steam tables This is a python class to model a state for liquid water or steam with the Industrial Formulation IAPWS-IF97. . Further information on the standard is available at http://www.iapws.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/20121120194206.20690.14758.report...@ailm.sceal.ie
Bug#693831: ITP: flextra -- Trajectory model for tracing air transport phenomena
Package: wnpp Severity: wishlist Owner: Alastair McKinstry * Package name: flextra Version : 5.0 Upstream Author : Andreas Stohl * URL : http://transport.nilu.no/flexpart * License : GPL Programming Lang: Fortran Description : Trajectory model for tracing air transport phenomena Trajectory models are important tools for studying transport phenomena in the atmosphere. In the environmental sciences, they are often used to establish source-receptor relationships of air pollutants. . FLEXTRA can be used to calculate different types of forward or backward trajectories, and has facilities to estimate the uncertainty of trajectories. It is specifically designed to compute long time sequences of trajectories for many receptor locations. . FLEXTRA may be used with the Metview meteorological workstation to visualize trajectories. -- 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/20121120195100.20754.61898.report...@ailm.sceal.ie
Bug#693833: ITP: flexpart -- Particle Dispersion model for tracing air transport phenomena
Package: wnpp Severity: wishlist Owner: Alastair McKinstry * Package name: flexpart Version : 90.02 Upstream Author : Andreas Stohl * URL : http://transport.nilu.no/flexpart * License : GPL Programming Lang: Fortran Description : Particle Dispersion model for tracing air transport phenomena The FLEXPART model is a Lagrangian Particle Dispersion Model developed at the Norwegian Institute for Air Research in the Department of Atmospheric and Climate Research. The model development team consists of Andreas Stohl (who originally wrote FLEXPART), Sabine Eckhardt, Harald Sodemann, and John Burkhart. -- 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/20121120200939.20865.68819.report...@ailm.sceal.ie
Bug#693834: ITP: metview -- Interactive data visualization and analysis environment
Package: wnpp Severity: wishlist Owner: Alastair McKinstry * Package name: metview Version : 4.3.4 Upstream Author : ECMWF http://www.ecmwf.int * URL : https://software.ecmwf.int/wiki/display/METV/Home * License : Apache Programming Lang: C++ Description : Interactive data visualization and analysis environment Metview has been designed as a flexible, modular and extendible system able to accommodate the evolving needs of the user. The system is based on the ECMWF standards for graphics (Magics) and data access (MARS) but can also access locally stored data. The user interface is based on Motif and Qt. Metview is a fully distributed system where modules can run on different workstations and servers. . Metview is a cooperative project between ECMWF and INPE/CPTEC, Brazil. ECMWF has also been assisted by a staff member of Météo-France. -- 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/20121120201915.20930.7457.report...@ailm.sceal.ie
