Re: How to put our new package (for free) into Karmic 9.10

2009-07-27 Thread Christopher James Halse Rogers
On Mon, 2009-07-27 at 12:10 +0200, Ilgis Ibragimov wrote:
> Hi,
> 
> thank you for your kind answers. Please, see my answer below.
> 
> Max Bowsher wrote: 
> > Jonathan Carter (highvoltage) wrote:
> >   
> > > Hi Ilgis
> > > 
> > > Ilgis Ibragimov wrote:
> > > 
> > > > One small question regarding to our package. We have it right now as
> > > > sources, and we can provide as sources. However, it is highly desirable
> > > > to build many (about 10) different libraries for different platforms,
> > > > for example:
> > > > 1. CPU AMD 32bit,
> > > > 2. CPU AMD 64bit,
> > > > 3. CPU Intel 32bit,
> > > > 4. CPU Inter 64bit,
> > > > 5. GPU NVIDIA 8xxx,
> > > > 6. GPU NVIDIA 9xxx,
> > > > 7. GPU NVIDIA 2xxx,
> > > > and probably some other minor things depending on amount of Cores in 
> > > > CPU.
> > > > 
> > > > We can provide binaries as well. Would you please, to tell me is the
> > > > REVU is the right place where I get an information how to organize the
> > > > package so that it provide only the best suitable version for user?
> > > >   
> > > I believe you will only need to upload the source package to REVU, from
> > > there the build server(s) should be able to build the the binary
> > > packages.
> > > 
> > 
> > REVU is a tool for publishing proposed source packages for review by
> > MOTUs and the community - no automatic builds are performed on REVU uploads.
> > 
> > REVU is definitely the right place to be publishing a new source package
> > you would like advice and comments on, but asking specific questions
> > either on this mailing list or on the #ubuntu-motu IRC channel is also
> > advisable.
> > 
> > In particular, why does your package need so many platform-variant
> > builds? Mostly Ubuntu only differentiates between x86 and x86_64 CPU
> > architectures.
> >   
> Our package is very processor dependent. It means we have several
> different algorithms depending on amount of CPU cores, or processor
> core and on the amount of L1/L2/L3 cache. It is really highly
> commercially tuned. We decide to share it in Ubuntu community, so, it
> is the main reason why we should build several versions depending on
> hardware. We may install CPU detector in sources, but it will force
> user to compile this package, that might be not very convenient.

I presume this detection isn't done at run-time for performance reasons?
I would naively expect the library to perform this detection once at
initialisation and from then on call into the appropriate
system-specific code, but there's probably a reason you aren't already
doing this.

As long as all these different build configurations can be manually
configured (ie: don't automatically tune for the system they're being
built on) it would be possible to build all these different binary
packages; it'll just be a bit of a pain.  Both for the packaging and for
the users.


signature.asc
Description: This is a digitally signed message part
-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu


Dropping off the Internet

2009-02-26 Thread Christopher James Halse Rogers
Hello all,

I'm moving this weekend, and I'm unsure when my internet connection will
be re-established - it could be up to a month away, apparently.  I'll
probably get intermittent internet access during this time, but I won't
be around dependably and will be unable to do much work.  Please don't
block on me!

I don't think this should disrupt anybody too much: the work for the
mono 2.0 transition and evolution-sharp transition is done, and Iain
Lane (Laney) and Jo Shields (directhex) should be your go-to people for
anything new mono related.  Iain has acquired TIL status on Miro, and
has worked with the Debian maintainer to turn this into a sync.  There
should be a new gnome-do release soon, and this might be worth a FFe as
there are a bunch of bugfixes, performance improvements, and more
fleshed-out features, particularly for the dock interface.  I've sounded
Iain out for this.

The only other thing I touch particularly is the nouveau drivers.  Once
the next libdrm upload goes through, they should be syncable from Debian
experimental, as long as someone updates the nouveau-kernel-source
package.  If I were more confident in my net access, I'd ask for a
standing FFe for xserver-xorg-video-nouveau and nouveau-kernel-source,
but if no one else feels like keeping this up to date it won't be much
of a loss.

Thanks everyone, and I hope to be back online and working soon.


-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu


Re: Web view of debian/changelog

2007-07-15 Thread Christopher James Halse Rogers
On Sun, 2007-07-15 at 19:11 -0400, Scott Kitterman wrote:
> Is there an Ubuntu equivalent of packages.debian.org's web display of each 
> package's debian/changelog, e.g.:
> 
Yes; for python-dns the url is:
https://launchpad.net/ubuntu/gutsy/+source/python-dns/+changelog

In general, LP->source package->overview tab->gutsy->view changelog (in
lefthand sidebar).

Chris Halse Rogers


-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu