Lang.NET 2008/Wednesday
From Wiki
Contents |
[edit]
Debian package
[edit]
TODO
-
Change license of debian/ directory content from Ms-PL to GPL - make use of dh_cli* helpers
- read appendix of CLI Policy for docs on using Debhelper
- remove extra cruft from rules
- look at mysql-net-connector-5.0
- fix the .pc file
- path is incorrect
- name should be something like cli-dlr.pc instead of Microsoft.Scripting.pc
[edit]
IRC log
21:32 < cj> alrighty... what is wrong with this package? :)
21:32 < cj> http://colliertech.org/downloads/DLR/
Day changed to 30 Jan 2008
02:09 < meebey> cj: mono 1.2.6 is not enough?
02:10 < meebey> +The Debian packaging is (C) 2008, C.J. Adams-Collier
<cjac@colliertech.org> and
02:10 < meebey> +is licensed under the Ms-PL.
02:10 < meebey> judas!
02:10 < meebey> :-P
02:11 < meebey> use GPL for deb packages
08:40 < cj> meebey: oh, alright. I thought it implied the packaged content was
under the Ms-PL
02:12 < meebey> cj: at a first glance, it looks pretty good.. errr no, I just
noticed you didn't use any dh_cli* helpers
02:13 < meebey> thus you dont get any automatic dependencies etc
02:13 < meebey> cj: check the appendix of the CLI Policy about Debhelper
02:13 < meebey> cj: and remove unneeded cruft (comments) from rules and thanks
for using native debhelper instead of CDBS
02:14 < meebey> cj: for your first package it looks pretty good :)
02:15 < meebey> cj: if you want a good source package example for CLI packages,
check mysql-net-connector-5.0
02:15 < meebey> cj: its in pkg-cli-libs SVN repo
02:15 < meebey> cj: that one is the latest sexiest state of the art CLI lib
package
02:20 < meebey> cj: the .pc file is broken btw (wrong path), and for the sake
of consistency please use lower case name
02:20 < meebey> cj: cli-dlr.pc or just dlr.pc might be better than using the
assembly name
08:39 < cj> meebey: thanks for the pointers
[edit]
Spec file deb package generation
- Miguel would like to generate debian/ directories from the RPM spec files in the OpenSuSE build system
- build.opensuse.org
- Community:
[edit]
IRC logs
09:04 <@cj> meebey: miguel wants us to use Novell's RPM spec files to give us
hints on how to generate debian/ and how to split up packages
09:05 <@meebey> cj: if mono wants to be incompatible with all existing
packages, thats no problem
09:05 <@cj> er, sorry... he wants to be able to generate Novell-specific .deb
packages from the spec files
09:05 <@cj> Seo is sitting next to me and correcting my ignorance :)
09:06 <@meebey> cj: thats what you get then, current packages that cant be used
with any CLI package in debian
09:07 <@meebey> cj: btw only ubuntu [lacgs] behind [in] regards [to] being current,
backports.org has mono 1.2.6 for debian/stable
09:07 < sanxiyn> meebey: Hi, I'm with cj here.
09:07 <@meebey> cj: so debian users are happy as always being up 2 date
09:07 < ben> cj: I'm using hardy and 1.2.6 is default here. works great
09:07 < sontek> SUSE doesn't have 1.2.6 in official repos I don't think, I
think its only in the build service
09:07 < sanxiyn> meebey: Yeah, I perfectly understand that (and I expected your
reply)
09:07 < sontek> SUSE has 1.2.5 as the official release
09:07 <@meebey> yeah they synced my packages the day I uploaded them to debian
:)
09:07 <@meebey> ben
09:08 < ben> meebey
09:08 <@meebey> sanxiyn: the only piece that is missing, are ubuntu backports
09:08 <@meebey> sanxiyn: for the current official ubuntu version
09:08 < sanxiyn> I'm not interested in Ubuntu since I don't use it :)
09:08 < evarlast> that spec->debian is interesting. Fink on OSX used to have an
input file very similar to spec which would then be used to
create debian/ and build debs.
09:08 < sanxiyn> meebey: You are providing valuable service to .deb users, but
Miguel's idea is that he wants to produce (say) nightly .deb
from the same specification .rpm is built, on (say) OpenSuse
build service.
09:08 <@meebey> then use the official backports from debian :)
09:09 < sanxiyn> meebey: I'm a Sid user.
09:09 <@meebey> sanxiyn: hm ic, but the generated packages will be kinda
useless besides for users that run business applications
09:09 <@meebey> sanxiyn: which are not part of debian
09:09 <@meebey> sanxiyn: ISV apps
09:09 < sanxiyn> meebey: It could install to /opt/mono or whatever.
09:10 < evarlast> so what would it take to make the backports? grab the source
debs from backports.org and build?
09:10 <@sanxiyn> meebey: The point is to let people test the nightly build by
installing the package, without compiling the source.
09:10 <@meebey> evarlast: right
09:10 <@sanxiyn> evarlast: Mostly, yes.
09:10 < evarlast> I should try that and place it on my PPA.
09:11 <@meebey> sanxiyn: like said, that will work good for non-deb
applications
09:11 <@meebey> sanxiyn: if thats the desired goal. its allright
09:11 <@sanxiyn> meebey: Say, someone is trying to port his mega-app from .NET
to Mono. He got (say) Ubuntu VMware box. And reports bugs.
Bugs are fixed in SVN. And currently one needs to say "this is
how you build from SVN..."
09:11 <@meebey> sanxiyn: hm ic
09:11 <@sanxiyn> meebey: That's no good. "Install nightly build and run tests
again..." is much better.
09:11 <@meebey> sanxiyn: for that scenario that, the proposed solution sounds
best I guess
09:12 <@kangaroo> in fact I think we would want to install to /opt/mono
09:12 <@kangaroo> so as to not break banshee; fspot; beagle; etc; etc; etc
09:12 <@meebey> sanxiyn: but getting the environment to use the right mono is
afaik not that simple, depending on the application, no? :)
09:12 <@cj> now... where are those spec files?
09:13 <@meebey> sanxiyn: right in that case means /opt/mono mono
09:13 <@meebey> cj: the mono's SVN
09:13 <@meebey> cj: release/ or something
09:13 <@cj> meebey: miguel suggested that the ones used to build the nightly
bits are elsewhere...
09:14 <@meebey> cj: hm didnt know
09:14 < evarlast> i'd rather have it replace ubuntu mono, but that is just me.
09:14 < evarlast> for /opt/mono you can just download the binary tarball and
extract it anywhere you want.
09:15 <@sanxiyn> evarlast: Eh, if it doesn't break depending packages.
09:16 <@dmoonfire> Does alien work for the RPM's?
09:22 <@meebey> dmoonfire: it converts rpm to deb, as an archive convert
09:22 <@dmoonfire> Yeah, but would it work for a bleeding edge release in
/opt/mono?
09:23 <@dmoonfire> You know, that doesn't use the Debian rules and regulations.
09:23 <@meebey> dmoonfire: I guess so, it doesnt need anything special
09:23 <@meebey> dmoonfire: thats what /opt is for, for broken software
09:23 * meebey hides
09:23 * dmoonfire grins.
09:23 <@dmoonfire> Well, in this case, software that doesn't [conform] to the
Debian Collective.
09:23 <@meebey> it really is, I had to unfuck f-secure for last week already
09:24 <@meebey> one package created an user while the other not, and that was
called .deb :)
09:24 <@meebey> IHMO mono should provide binary tarballs
09:24 <@meebey> as snapshots
09:24 <@dmoonfire> Another approach is just to write a little script that uses
the Debian mono package, and basicall does a uupdate and see
if it works.
09:24 <@meebey> not as distribution packages
09:25 <@meebey> as it will not integrate with the distribution anyhow
09:25 <@meebey> .tar.gz would work everywhere
09:25 <@dmoonfire> You could script that would mostly conform, let you mark it
as "mono-runtime-1.0-svn" or something and have it conflict
with the sid packages.
09:25 <@meebey> using static linked libc6 etc
09:26 <@sanxiyn> meebey: There's nothing wrong with .tar.gz. There's nothing
wrong with binary .zip on Windows too.
09:26 <@meebey> sanxiyn: so what about provinding statically linked mono
binaries?
09:26 <@sanxiyn> meebey: But you know why people insist on fancy .exe
installers. (I don't, but...)
09:27 <@meebey> sanxiyn: something like the mono-installer for linux but less
fancy and for nightly builds
09:27 <@meebey> sanxiyn: that would give users an better experience than
inproper packages
09:27 <@sanxiyn> ok, mail that to miguel :)
09:28 <@meebey> sanxiyn: of course you need a 32bit/64bit build, but then you
can serve it to all distris
09:28 <@meebey> and maybe other archs if needed
09:30 <@dmoonfire> Eh, I'd go the automated package script, with you having
control to update it to match. But, that's me.
09:30 <@meebey> I am checking if patches are needed for mono, as debian/ubuntu
dont have .so symlinks in runtime packages
[edit]
Perl6 module import
I am unclear on how Perl6 will do the following when a module exists both in the perl6 library search path and the CLI library search path:
- decide which to use
- allow developer to over-ride perl6's decision
Some of the docs that describe the current module import syntax:
General spec docs
[edit]
IRC logs
09:09 < cj> @tell TimToady how do you want to handle inclusion of CLI libraries
when their namespace is defined in the CPAN for instance?
09:41 <@TimToady> cj: see S11:391 for syntax of importing from foreign
namespaces
09:48 < cj> TimToady: danke
09:49 < cj> TimToady: where is the canonical textual representation of that
synopsis located?
09:49 <@moritz_> the "canonical" HTML is at http://perlcabal.org/syn/
09:49 < lambdabot> Title: Official Perl 6 Documentation
09:50 <@moritz_> the POD is at http://svn.pugscode.org/pugs/docs/Perl6/Spec and
... uhm... I forgot the second URL
09:50 < lambdabot> Title: Revision 19755: /docs/Perl6/Spec
09:50 < cj> thanks, moritz_
09:51 <@moritz_> http://svn.perl.org/perl6/doc/trunk/design/syn/ # that's the
second
09:51 < lambdabot> Title: Revision 14496: /doc/trunk/design/syn
10:09 < cj> Hurm... I haven't finished reading the spec yet... I'm about half
way through, but it occurs to me that there seems to be the
assumption that modules will be imported from a single external
location, and there is probably no concept of libraries defined by
the underlying VM, vs. libraries defined in .pm files in the
library search path
10:10 < [particle]> cj: no, there's an :auth<> attribute, which allows you to
specify the authority (from which the module was downloaded)
10:11 < [particle]> well, not 'downloaded' but i think you get the point
10:11 < cj> the specific question I am asking is this: when a module is defined
by a library source known to the underlying VM, and there exists a
library in the filesystem search path which duplicates the
namespace / module name, a) how does perl6 decide which to use and
b) how does the user over-ride the default decision?
10:12 < [particle]> as yet undefined
10:12 < [particle]> we'll need some kind of module registry
10:13 < cj> it seems to me that the perlish way to do it would be to default to
the perl6 version, requiring intervention in order to use the
VM-supplied thinger
