Re: Wget failures connecting to GitHub on Ubuntu 20

2021-09-18 Thread Colin Watson
On Fri, Sep 17, 2021 at 09:15:12PM -0400, Jeffrey Walton wrote:
> This caught me by surprise today:
> 
> $ lsb_release -a
> No LSB modules are available.
> Distributor ID: Ubuntu
> Description:Ubuntu 20.04.3 LTS
> Release:20.04
> Codename:   focal
> 
> $ wget -O main.cxx
> https://raw.githubusercontent.com/austin-clifton/cryptopp-chacha-asm-test/main/src/main.cpp

This works fine for me on 20.04; perhaps the relevant DigiCert CA is
disabled on your system.  Try "sudo dpkg-reconfigure ca-certificates"
and make sure it's enabled.

-- 
Colin Watson (he/him)  [cjwat...@ubuntu.com]

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


Re: SBCL : building : Makefile : where to find?

2021-07-15 Thread Colin Watson
On Tue, Jul 13, 2021 at 01:20:33PM +0200, em...@kathe.in wrote:
> Where should I look to find the process (Makefile) used to build SBCL under 
> Ubuntu?
> I tried look under http://in.archive.ubuntu.com/ubuntu but got disoriented 
> quite quickly.

"apt source sbcl" and look in debian/rules.  (dpkg-buildpackage calls
debian/rules with various arguments to build binary packages from a
source package.)

-- 
Colin Watson (he/him)  [cjwat...@ubuntu.com]

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


Re: Quick Question

2021-06-27 Thread Colin Watson
[Please use more informative subject lines if possible.]

On Sat, Jun 26, 2021 at 09:06:15PM -0400, Drew Howden Tech wrote:
> Quick question: if I create a new package to resolve a 'needs-packaging'
> bug, should I put my name in the maintainer field of the control file, or
> 'Ubuntu Developers'?

It doesn't matter much.  I lean towards your own.

> Also, when patching/upgrading a package (to resolve a bug) should I
> submit all the files (source package, resulting binary, etc.), or just
> the debdiff/diff.gz?

The debdiff (*not* just the .diff.gz - they aren't the same thing) is
normally sufficient, although some reviewers may find it convenient to
have a complete source package to download and perhaps sign/upload.  If
the fix involves a new upstream version then you should submit the full
source package.

It isn't generally necessary to submit binaries unless a reviewer
specifically asks for them, and they wouldn't be used anyway, although
of course you should have test-built your fix and confirmed that it
actually works.

-- 
Colin Watson (he/him)  [cjwat...@ubuntu.com]

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


Re: dbgsym missing for focal-updates

2021-03-30 Thread Colin Watson
On Tue, Mar 30, 2021 at 12:04:05PM -0400, Jesse Schwartzentruber wrote:
> I noticed that the -dbgsym package versions lag behind what's available from
> focal-updates.
> 
> In particular, for libgtk 3.24 I see (from
> http://ddebs.ubuntu.com/ubuntu/pool/main/g/gtk+3.0/):
> 
> [ ]    libgtk-3-0-dbgsym_3.24.18-1ubuntu1_amd64.ddeb 2020-04-19 13:50    
> 8.0M
> [ ]    libgtk-3-0-dbgsym_3.24.23-1ubuntu1_amd64.ddeb    2020-09-11 18:42    
> 8.2M
> [ ]    libgtk-3-0-dbgsym_3.24.25-1ubuntu3_amd64.ddeb    2021-03-25 16:44    
> 8.5M
> 
> These correspond to the latest releases for focal, groovy, and hirsute. The
> latest for focal-updates is 3.24.20-0ubuntu1 and doesn't appear to be
> present at ddebs.
> 
> Is focal-updates supposed to have dbgsyms available?

Yes.

> Is there an expected time delay between version update and dbgsym
> availability?

There's a short expected time delay, but in this case the service is
generally operating normally and gtk+3.0 3.24.20-0ubuntu1 was published
nine months ago or so, so something is clearly wrong; our logs don't go
back far enough to make it clear exactly what, though.  Could you please
file a bug on https://bugs.launchpad.net/ddeb-retriever/+filebug to
remind us to look into it?

-- 
Colin Watson (he/him)  [cjwat...@ubuntu.com]

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


Re: Found in https://packages.ubuntu.com/focal/i386/libasound2-dev/download

2021-03-28 Thread Colin Watson
On Fri, Mar 26, 2021 at 10:43:41PM -0400, Tyler Foster wrote:
> Package: libasound2-dev
> Status: install ok installed
> Priority: optional
> Section: libdevel
> Installed-Size: 660
> Maintainer: Ubuntu Developers 
> Architecture: i386
> Multi-Arch: same
> Source: alsa-lib
> Version: 1.2.2-2.1
> Provides: libasound-dev
> Depends: libasound2 (= 1.2.2-2.1)
> Suggests: libasound2-doc
> Description: shared library for ALSA applications -- development files
>  This package contains files required for developing software
>  that makes use of libasound2, the ALSA library.
> 
> 
> *Value should be 1.2.2-2.1ubuntu2.3 .*

1.2.2-2.1 was the version of that package in 20.04 at the time it
released; we don't update what shows up in the unadorned "focal" suite
after release.  1.2.2-2.1ubuntu2.3 was a post-release update, so that
would be in the "focal-updates" suite
(https://packages.ubuntu.com/focal-updates/i386/libasound2-dev/download)
instead.

packages.ubuntu.com is a very cumbersome way to actually fetch
individual packages rather than just searching and browsing around
though; you should instead use tools such as apt that will deal with
resolving dependencies and fetching the correct version of the package
for you.

-- 
Colin Watson (he/him)  [cjwat...@ubuntu.com]

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


Re: Create a binary Debian package

2021-01-25 Thread Colin Watson
On Mon, Jan 25, 2021 at 11:38:47AM -0800, Alex Chen wrote:
> Thanks for the information Colin.  However, this is a binary package built 
> from proprietary cross-platform source code.  
> It is not open-source nor free software.  There is no up-stream source 
> package.

That doesn't matter for the purposes of my reply.

> > On Jan 25, 2021, at 6:51 AM, Colin Watson  wrote:
> > On Sun, Jan 24, 2021 at 11:21:01PM -0800, Alex Chen wrote:
> >>   I am trying to create a Debian package, i.e. a .deb file, that can 
> >> install  software in Ubuntu. I put a the following files under the build 
> >> directory:
> >> 
> >> build_dir/DEBIAN/control - Package configuration
> >> build_dir/DEBIAN/md5sums - MD5 checksums of every files to be installed.
> >> build_dir/DEBIAN/preinst postinst  prerm postrm - Pre/Post installation 
> >> and pre/post uninstallation scripts.
> > 
> > You should never create files under DEBIAN/ directly.  Build a proper
> > source package instead with the appropriate files under debian/, and
> > build binary packages from it using debuild.  See for instance
> > https://wiki.debian.org/Packaging/Intro.
> 
> It is not built from with 'configure' and 'make' from the source. The 
> standard Linux build configuration does not apply.
> It is packaged with a script following the descriptions in 
> https://www.debian.org/doc/debian-policy/ch-binary.html#binary-packages 
> <https://www.debian.org/doc/debian-policy/ch-binary.html#binary-packages>

Source packages don't require the "standard Linux build configuration"
(there isn't really such a thing anyway, but rather a variety of common
build systems).  They don't require configure or make, or indeed any
other build step.  It's perfectly possible and commonplace to have a
source package that simply copies a bunch of prebuilt files into place,
or that runs pretty much whatever script you like.

None of this is a reason to construct the .deb by hand by poking into
DEBIAN/, and you'll just make trouble for yourself by doing so - you can
and should still use the normal packaging toolchain.

Also, another thing I just noticed: for dependencies on shared
libraries, you should normally use ${shlibs:Depends} in debian/control
rather than writing those exact dependencies out by hand.  This makes it
easier to update the package to build correctly on newer versions of the
OS.  You can't do this if you're building DEBIAN/control by hand - it's
a facility provided by the packaging toolchain.

> >> This what I have in the 'control' file
> >> =
> >> Package: test-package
> >> Version: 1.0.0
> >> Architecture: amd64
> >> Pre-Depends: coreutils, libicu60, libfontconfig1, firewalld, unzip, zip, 
> >> curl, lapache2, apache2-bin
> >> ==
> >> 
> >> I thought packages listed in Pre-Depends field of a control file are 
> >> supposed to be installed by the system before it process the package 
> >> itself, according to this document: 
> >> https://www.debian.org/doc/debian-policy/ch-relationships.html#binary-dependencies-depends-recommends-suggests-enhances-pre-depends
> >>  
> >> <https://www.debian.org/doc/debian-policy/ch-relationships.html#binary-dependencies-depends-recommends-suggests-enhances-pre-depends>
> > 
> > Pre-Depends should only be used in rare circumstances.  You should
> > normally use Depends instead.  You also don't need to (and shouldn't)
> > explicitly depend on coreutils, since it's an essential package.
> 
> In order for our software to function, several packages not usually present 
> in a base system need to be installed first and according to the definition 
> of 'Depends' and 'Pre-Depends', 'Pre-Depends' seems to be what is needed.
> 
> Depends -  Requires other packages it depends on to be 'unpackaged' or 
> 'configured',
> 'Pre-Depends' - Requires 'dpkg' to complete 'installation' of these packages 
> before event installing the package itself.

In general, the only reason you need Pre-Depends is if you're using the
dependency in question in your package's preinst script, and even that
is often a mistake that can be avoided.  (There are occasional other
cases that really only come up if you're maintaining something that's a
core part of the OS itself.  I'm familiar with what the Debian policy
manual says, and am summarising the essential points here since it's
often misunderstood.)

The Debian policy manual says "You should not specify a Pre-Depends
entry for a package before this has been discussed on the debian-devel
mailing list and a consensus about doing that has been reached", not
because of some kind of gatekeeping, but because Pre-Depends imposes
stronger constra

Re: Create a binary Debian package

2021-01-25 Thread Colin Watson
On Sun, Jan 24, 2021 at 11:21:01PM -0800, Alex Chen wrote:
>I am trying to create a Debian package, i.e. a .deb file, that can install 
>  software in Ubuntu. I put a the following files under the build directory:
> 
> build_dir/DEBIAN/control - Package configuration
> build_dir/DEBIAN/md5sums - MD5 checksums of every files to be installed.
> build_dir/DEBIAN/preinst postinst  prerm postrm - Pre/Post installation and 
> pre/post uninstallation scripts.

You should never create files under DEBIAN/ directly.  Build a proper
source package instead with the appropriate files under debian/, and
build binary packages from it using debuild.  See for instance
https://wiki.debian.org/Packaging/Intro.

> This what I have in the 'control' file
> =
> Package: test-package
> Version: 1.0.0
> Architecture: amd64
> Pre-Depends: coreutils, libicu60, libfontconfig1, firewalld, unzip, zip, 
> curl, lapache2, apache2-bin
> ==
> 
> I thought packages listed in Pre-Depends field of a control file are supposed 
> to be installed by the system before it process the package itself, according 
> to this document: 
> https://www.debian.org/doc/debian-policy/ch-relationships.html#binary-dependencies-depends-recommends-suggests-enhances-pre-depends
>  
> <https://www.debian.org/doc/debian-policy/ch-relationships.html#binary-dependencies-depends-recommends-suggests-enhances-pre-depends>

Pre-Depends should only be used in rare circumstances.  You should
normally use Depends instead.  You also don't need to (and shouldn't)
explicitly depend on coreutils, since it's an essential package.

> I was able create the package with 'dpkg-deb --build build_dir' command 
> successfully, however I got the following dependency errors when I tried to 
> install the package in an Ubuntu server
> 
> ===
> $ sudo dpkg -i test-package_1.0.0_amd64.deb 
> [sudo] password for tester
> dpkg: regarding test-package_1.0.0_amd64.deb containing test-package, 
> pre-dependency problem:
>  test-package pre-depends on libfontconfig1
>   libfontconfig1 is not installed.

dpkg -i won't acquire or install dependencies that aren't yet installed;
it only processes the files you give it.  You can use this instead,
which knows how to acquire and install dependencies as well as the
specific file you give it (note that the "./" is important so that apt
knows that you're talking about a file name rather than a package name):

  sudo apt install ./test-package_1.0.0_amd64.deb

-- 
Colin Watson (he/him)  [cjwat...@ubuntu.com]

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


Re: Cfengine package

2020-10-06 Thread Colin Watson
On Wed, Sep 30, 2020 at 09:39:09PM -0400, Kristopher Fisher wrote:
> In the never ending attempt to harden my system security, I ran the
> program Lynis, which instructed me to install a package called
> CFEngine.  In the process of installing this package, I couldn't help
> bu notice that Ubuntu has the package's homepage listed as
> http://www.cfengine.org, yet while trying to learn more before
> installing, the only package I have been able to find via all search
> engines, including Google , is page http://www.cfengine.com.

Ubuntu's current packaging comes unmodified from Debian, and it looks as
though Debian fixed this a little while back:

  
https://salsa.debian.org/cfengine-team/cfengine3/-/commit/12c7780fd375b8651631afd179e45b67d1a8b8a6

So this is already fixed for the upcoming Ubuntu 20.10.

Thanks,

-- 
Colin Watson (he/him)  [cjwat...@ubuntu.com]

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


Re: and autopkgtest hangs? Re: Build failures without a build log

2020-08-20 Thread Colin Watson
On Wed, Aug 19, 2020 at 06:44:19PM +0100, Rebecca N. Palmer wrote:
> Thanks - the retry worked for pandas and theano.
> 
> statsmodels failed because it was temporarily BD-Uninstallable - this should
> now be fixed, so please retry it if that doesn't happen automatically.

Those particular kinds of failures aren't detectable automatically by
the usual retry-depwait mechanism.  I've retried them.

> Could this have also affected autopkgtests?  pandas is now being held in
> -proposed because a snakemake autopkgtest hung:
> https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#pandas
> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/amd64/s/snakemake/20200817_223057_9ce51@/log.gz

I don't think so, but an autopkgtest person should probably have a look.
(autopkgtest and Launchpad shares cloud infrastructure, but Launchpad
doesn't operate autopkgtest as such.)

-- 
Colin Watson (he/him)  [cjwat...@ubuntu.com]

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


Re: Build failures without a build log

2020-08-19 Thread Colin Watson
On Tue, Aug 18, 2020 at 08:42:48AM +0100, Rebecca N. Palmer wrote:
> (If this is an already known problem, where should I have checked before
> reporting it?  If it should be a bug report, against what?)
> 
> Several packages say they failed to build, but do not have the build log
> that would normally accompany this.
> 
> Of the ones I uploaded recently (pandas, snakemake, statsmodels, theano):
> pandas/arm64, armhf, ppc64el (with roughly the normal build duration)
> statsmodels/armhf, ppc64el, s390x (s390x with an unusually long build
> duration)
> theano/ppc64el, s390x (with short build durations)
> The same packages built successfully on Debian, but theano appears to be
> BD-Uninstallable on Ubuntu.
> 
> From the excuses "missing build" list:
> dochelp/ppc64el
> h5py/ppc64el
> mate-applets/s390x
> ghc/armhf
> These are all less than 24 hours old (the builds, the ghc package is older);
> I didn't find any older ones but I didn't check every entry.

This was a Launchpad infrastructure issue; exact cause not completely
clear but it looks like it was a networking problem in one of our
datacentres.  I've retried the affected builds now.

-- 
Colin Watson (he/him)  [cjwat...@ubuntu.com]

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


Re: Dependencies of ubuntu-desktop

2020-07-26 Thread Colin Watson
On Tue, Jul 14, 2020 at 05:16:20AM +0200, Andrei Rybak wrote:
> Could someone please clarify why don't the packages ubuntu-desktop and
> ubuntu-desktop-minimal depend on ubuntu-minimal?

It's been a while, but IIRC we considered that many years ago and found
that it seemed too annoying to do that in practice; it meant that if you
were intentionally diverging from one part of the prescribed default
system in such a way that required removing a lower metapackage, you
ended up removing all the upper metapackages as well, and that ended up
being rather a hassle.

-- 
Colin Watson (he/him)  [cjwat...@ubuntu.com]

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


Re: Request: snap updating in Software Updater app

2020-06-11 Thread Colin Watson
On Mon, Jun 08, 2020 at 12:52:55PM +0200, Bill Dietrich wrote:
> In the Software Updater application, while checking/updating
> snaps:
> 
> - the Details button does not work
> 
> - there is no percent-progress indicator shown
> 
> Could someone please fix/improve these ?
> 
> Should I file a feature-request somewhere, or is this
> mailing list the only channel for that ?

You can file bug reports (which include feature requests) for that
application using "ubuntu-bug update-manager".

-- 
Colin Watson (he/him)  [cjwat...@ubuntu.com]

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


Re: When will PHP be upgraded to 7.4.5 for focal?

2020-05-31 Thread Colin Watson
On Tue, May 26, 2020 at 08:49:58PM -0300, Elias Soares wrote:
> Can someone tell me when php releases are released to official repository
> for focal? PHP 7.4.4 is out few a few months and is not available yet for
> ubuntu 20.04 lts

In general, stable releases of Ubuntu only get individually-selected bug
fixes, rather than whole new releases.  There are some exceptions, but I
don't believe PHP is among them.  See:

  https://wiki.ubuntu.com/StableReleaseUpdates

If there's a specific high-impact bug that was fixed in this newer
upstream release, please make sure it's filed in Launchpad.

-- 
Colin Watson (he/him)  [cjwat...@ubuntu.com]

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


Re: PT-BR translation

2020-04-14 Thread Colin Watson
On Tue, Apr 14, 2020 at 09:13:48PM +0100, Colin Watson wrote:
> On Sun, Apr 12, 2020 at 12:54:07PM -0400, Kinder wrote:
> > How do I contribute to the ubuntu PT-BR translation? preferably the command
> > "man"?
> 
> Speaking as the upstream maintainer of man, the most long-term-effective
> way to do this is to work with the Translation Project and thus
> contribute the translations upstream
> (https://translationproject.org/html/welcome.html).  This work will be
> shared with other distributions.

Oh, this applies if you're talking about the localisation of the "man"
command itself or the manual pages that are part of the man-db package.
It doesn't necessarily apply if you're talking about other manual pages
that you access using the "man" command.

> The Ubuntu translation system mentioned by Gunnar allows for getting
> translations into Ubuntu on a shorter timescale, and doing translation
> work across the whole distribution in one place.  It usually doesn't
> result in translations being shared with other distributions.

... and if you're talking about other manual pages that you access using
the "man" command, I don't think translations of those can in general be
handled using Ubuntu's normal translation system.  You'd need to work
with individual upstream projects on that.

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: PT-BR translation

2020-04-14 Thread Colin Watson
On Sun, Apr 12, 2020 at 12:54:07PM -0400, Kinder wrote:
> How do I contribute to the ubuntu PT-BR translation? preferably the command
> "man"?

Speaking as the upstream maintainer of man, the most long-term-effective
way to do this is to work with the Translation Project and thus
contribute the translations upstream
(https://translationproject.org/html/welcome.html).  This work will be
shared with other distributions.

The Ubuntu translation system mentioned by Gunnar allows for getting
translations into Ubuntu on a shorter timescale, and doing translation
work across the whole distribution in one place.  It usually doesn't
result in translations being shared with other distributions.

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: State of libeigen3-dev in Ubuntu Focal

2020-02-25 Thread Colin Watson
On Tue, Feb 25, 2020 at 03:48:14PM -0500, Mike Purvis wrote:
> As far as launchpad engagement, it looks like this would be the page for
> that, but the bugtracker isn't active on it:
> https://launchpad.net/debian/+source/eigen3

No, if you're filing bugs on Ubuntu, you should use /ubuntu, not
/debian, so https://launchpad.net/ubuntu/+source/eigen3.
(https://launchpad.net/debian exists mainly as a convenience and as a
by-product of the way we sync changes from Debian; it's not part of
Debian's development workflow.)

The simplest thing would be to run "ubuntu-bug eigen3".

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: State of libeigen3-dev in Ubuntu Focal

2020-02-25 Thread Colin Watson
On Tue, Feb 25, 2020 at 02:38:54PM -0600, Richard Laager wrote:
> Without knowing the specifics of the patch, most likely. But you're
> running out of time. At this point, it's too late to get something into
> Debian testing and have it migrate to Focal. (I think Focal is syncing
> from Debian testing. If it's syncing from Debian unstable, then you have
> like 24 hours.)

focal syncs from unstable, not testing.

> So it'd need to be a patch that goes direct into Ubuntu.

Not necessarily.  After automatic syncs stop on Thursday, we can still
sync uploads from Debian as long as they meet the criteria for feature
freeze (which it sounds like this would, as long as it doesn't come with
other changes); it just has to be something that an Ubuntu developer
does manually rather than something that will happen without human
intervention.

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: Memory Leak proftpd-basic Version 1.3.5e-1build1

2019-12-11 Thread Colin Watson
On Sun, Dec 08, 2019 at 05:39:53PM +, Niklas Brückelmayer wrote:
> I want to report a bug in proftpd-basic.

Bug reports go in Launchpad, not here.  However ...

> I installed this software thru "apt install proftpd-basic" and got
> verion 1.3.5e-1build1
> 
> In this version there is a memory leak because when I transfer huge
> amounts of data (in my example approx. 500GB) all available RAM got
> "cached" and Linux starts to use swap!

Cached data in RAM is good (it means your system is keeping things in
RAM when it might possibly save it from rereading them more slowly from
disk), and using swap isn't necessarily bad.  If your system can make
better use of the available RAM than by using it to keep bits of running
but rarely-used processes in memory, then it may decide to swap out
parts of those processes, and this is fine.

Swap *thrashing* (being so RAM-constrained that your system ends up
spending too long swapping pages of memory back and forward between RAM
and disk, at the cost of getting anything useful done) is bad.  Merely
using swap at all is not bad: it just indicates that your system is
taking advantage of having a couple of different tiers of virtual memory
with different performance characteristics, and is moving rarely-used
things to the slower tier.

In order to show evidence of a memory leak in proftpd, you would need to
show that the proftpd process itself is growing.  But that's not what
memory that you see as "buff/cache" in top(1) or free(1) output is, and
what you've described so far sounds like normal behaviour to me.

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: ZFS feature flags

2019-10-19 Thread Colin Watson
I don't have much to say about most of this, but noticed this bit:

On Thu, Oct 17, 2019 at 09:48:42PM -0500, Richard Laager wrote:
> The same implementation could (and if I have my way, will) be used to
> provide a features=grub mask. This would be used for the boot pool
> (bpool) to limit it to the features supported by GRUB. This would avoid
> the dangerous message in "zpool status" which tells you to run "zpool
> upgrade" on your bpool which would then break booting from it.

Isn't that a dubious and confusing way to spell it?  After all, like any
other ZFS implementation, GRUB's ZFS implementation has gained features
over time, and it wouldn't surprise me if it continued to do so.  It
sounds like you'd need a set of versioned features for this as well as
for features=portable; but it's not clear how the decision of when to
promote a feature set to the unversioned level would be made,
particularly given GRUB's rather slow and unpredictable release cycle
and the widespread practice of backporting features by distribution
maintainers.

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: Question on apt-get update

2019-09-26 Thread Colin Watson
On Wed, Sep 25, 2019 at 05:40:13PM -0700, Dan Kegel wrote:
> On Wed, Sep 25, 2019 at 6:19 AM kavitha R  wrote:
> > Why do we store the package full description in a different file?
> 
> Possibly because apt was written in 1998 and it seemed like a good
> idea at the time?

Separating out descriptions was in fact done later: it saves a fair
chunk of disk space if you're using multiarch, in which you have (e.g.)
both amd64 and i386 Packages files, but the descriptions are large and
mostly shared between them.

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: Dead acute + c still produces ć instead of the more widely used ç

2019-08-05 Thread Colin Watson
On Mon, Aug 05, 2019 at 11:07:08AM +0200, Nilson Santos Figueiredo Jr. wrote:
> I just got a new laptop and installed the newest LTS Ubuntu version.
> To my surprise, Ubuntu still cannot produce ç properly out-of-the-box in
> the regular way when using the "US international with dead keys" layout.

I believe that this behaviour is defined by libx11
(https://gitlab.freedesktop.org/xorg/lib/libx11) and it isn't as simple
as saying that it always produces ć: it's supposed to depend on your
locale.  A grep should make the intent clear:

  $ git grep 
'^ ' nls
  nls/en_US.UTF-8/Compose.pre: : "ć"   U0107 
# LATIN SMALL LETTER C WITH ACUTE
  nls/fi_FI.UTF-8/Compose.pre: :  "ć"  
U0107  #  LATIN SMALL LETTER C WITH ACUTE
  nls/iso8859-1/Compose.pre:   : "\347"  
  ccedilla
  nls/iso8859-13/Compose.pre:  : "\343"  
  cacute
  nls/iso8859-15/Compose.pre:  : "\347"  
  ccedilla
  nls/iso8859-2/Compose.pre:   : "\346"  
  cacute
  nls/pt_BR.UTF-8/Compose.pre: : "ç" 
ccedilla  # LATIN SMALL LETTER C WITH CEDILLA
  nls/pt_PT.UTF-8/Compose.pre: : "ç" ccedilla # LATIN SMALL 
LETTER C WITH CEDILLA

I hope this will help you narrow down where the problem is: either the
compose definitions aren't taking effect, in which case you'd need to
track down what's supposed to be applying them and isn't, or the compose
definitions are wrong, in which case you would be best off taking this
up with X11 upstream.

(That said, while I don't use dead-key layouts myself, I seem to get ç
when I type Compose ' c even though that isn't what the Compose file
says I should get.  Not quite sure what's going on there.)

> "Ć" is a character that is used in Polish (38.5 million speakers) and
> apparently also Croatian (6 millions speakers) and some related languages
> when using loanwords.
> "Ç" on the other hand, is used by Portuguese (215-260 million speakers),
> French (80 million native, 270 million total speakers), Turkish (75
> million), Catalan (4-10million), Albanian (5 million), Azerbaijani (23
> million), plus at least Tatar, Turkmen, Kurdish and Zazaki, Friulian,
> Ligurian and Occitan.

Given that this is (as far as I can tell) supposed to depend on the
locale, there should be no need to play off different groups of people
against each other like this.

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: dmeventd Changes Not Available

2019-07-26 Thread Colin Watson
On Wed, Jul 24, 2019 at 10:58:53AM -0400, Matthew Rubenstein wrote:
>   Hello. In my Ubuntu 18.04.2 LTS host the system-update
> application has been offering for several weeks to upgrade 4 dmeventd
> packages: dmeventd , libdevmapper-event1.02.1 , libdevmapper1.02.1 ,
> dmsetup but the Technical description / Changes GUI says "The list of
> changes is not available yet." Further, the URL offered in that GUI as
> an alternate source of changes info leads to an invalid page:
> 
> http://launchpad.net/ubuntu/+source/lvm2/2%3A1.02.145-4.1ubuntu3.18.04.1/+changelog

This is
https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/655917.
I've fixed it in 19.04 and above, but the fix hasn't (yet?) been
backported to 18.04.

The bug is purely in update-manager, and doesn't have any bearing on the
safety of the upgrade.

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: grub2 package is still on version 2.02, although version 2.04 solves a big bug

2019-07-16 Thread Colin Watson
On Sat, Jul 13, 2019 at 12:51:11PM +0200, Oskar Roesler wrote:
> grub2 (and therefore, Ubuntu) can't be installed on some UEFIs because
> of this bug: http://wiki.linuxfromscratch.org/lfs/ticket/4354
> 
> The bugfix
> <http://git.savannah.gnu.org/cgit/grub.git/commit/util?id=842c390469e2c2e10b5aa36700324cd3bde25875>
> is already there for over a half year, but even though this bug is that
> big, you still have to build the fixed grub version manually.
> 
> Debian has version 2.04 still in sid, but I would consider to jump to
> 2.04 earlier, to make installing Ubuntu on those problematic UEFIs
> possible for unexperienced users again.

Upgrading stable releases to 2.04 is extremely unlikely, but the Ubuntu
grub2 maintainers can and do cherry-pick individual fixes instead.  I
suggest filing a bug against the Ubuntu grub2 package to request that.

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: I would like to contribute to debianutils

2019-07-06 Thread Colin Watson
On Thu, Jul 04, 2019 at 06:48:27PM +0200, Erik Gustafsson wrote:
> The "which" command is part of debianutils. On BSD and Mac, this
> command on Mac/BSD has a -s flag, which is basically, silent, and
> return 0 if program found in $PATH or 1 otherwise

I've only ever seen the convention of redirecting output to /dev/null,
which I would assume could also be done in a way that's compatible
between Debian and the BSDs.  An -s option seems like a reasonable
enough thing to have, though.

> The current version of "which" supplied with Debian is written in shellscript
> https://salsa.debian.org/debian/debianutils/blob/master/which

Yes, it's descended from a version I wrote many years ago. :-)  (I
haven't been responsible for maintaining it for a long time, though.)

> To make my Debian installation compatible with "which -s" in
> shellscripts I would like to contribute the -s flag to debianutils. I
> have already made a working implementation, which I am happy to
> improve on as needed. (attach with this email)

As general advice, almost nobody will ever want to review something sent
in the form of "here is a complete new version of the code".  The
baseline standard in free software development is to send patches
instead that express the difference between the current and proposed
versions, which were traditionally produced using "diff -u" but nowadays
are more usually produced by something like "git format-patch".

(In many cases, of course, this is all wrapped up in something like a
"pull request" or "merge request" or whatever individual sites call it,
where you push git commits to a branch somewhere and then fill in some
kind of form which asks the maintainer to merge stuff from your branch.
It's still useful to be familiar with working with patches, since that's
still what the maintainer will be looking at when deciding whether or
not to merge your changes.)

> How can I get started to contribute to debianutils? Should I have an account 
> on
> https://salsa.debian.org/debian/debianutils ?

It would probably be best to create a Salsa account, fork that
repository, commit your changes, and send a merge request, yes.

You could also send a patch as a Debian bug report against debianutils,
which is done by sending an email in the right format to a special
address (see https://www.debian.org/Bugs/Reporting).

> Can someone else contribute this code for me, once I get it to reach a
> good quality level of code and documentation?

It's really best if you can make the contribution directly yourself.
Going through somebody else is possible but it's more cumbersome, since
it means that if the maintainer has any questions then they have to be
relayed through somebody else too.

> I found this email address by typing
> apt-cache show debianutils , in the Maintainer field

Ubuntu overrides the Maintainer address of most packages to this list to
avoid being responsible for too much noise sent to Debian maintainers
for packages that they didn't prepare.  However, in this case our
version of debianutils is an unmodified copy of the one in Debian, and
it would be very much better for this sort of change not to be specific
to Ubuntu, so for this sort of thing you should work directly with the
Debian maintainer.

Thanks,

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: anyone still use 'import-bug-from-debian'?

2019-02-13 Thread Colin Watson
On Wed, Feb 13, 2019 at 08:40:39AM -0500, Dan Streetman wrote:
> As far as I can tell, this hasn't been used by anyone in a long time,
> or at least only a small number of times.
> 
> Can anyone who uses it let me know?

If it's helpful, there are 409 bugs in Launchpad whose description
starts with the string "Imported from Debian bug"; the most recent one
(https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1694425) was
created on 2017-05-30.  It was quite heavily used up to 2015 or so; my
general impression is that it's a slightly obscure tool so not widely
used, but probably used enough to justify keeping it around.

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: dpkg-query --load-avail not working?

2018-05-28 Thread Colin Watson
On Sun, May 27, 2018 at 03:42:26PM -0400, Tong Sun wrote:
> If so, then somehow dpkg-query --load-avail is not working:
> 
> $ dpkg-query --load-avail --list 'golang-github-*'
> dpkg-query: no packages found matching golang-github-*

It'll work if /var/lib/dpkg/available is being kept up to date, which
apt doesn't do by default.  You can use "dselect update" in place of
"apt update" to update the available file as well as doing the other
index-update tasks.

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: Proposal: Let's drop i386

2018-05-13 Thread Colin Watson
On Sun, May 13, 2018 at 08:42:49PM +0200, Ole Streicher wrote:
> Henri Sivonen <hsivo...@hsivonen.fi> writes:
> > If 32-bit x86 support becomes mainly a thing that's run on x86_64
> > hardware as a compatibility measure for things like Wine, it would
> > make sense to bring the instruction set baseline to the x86_64 level.
> > Specifically, it would make sense to compile the 32-bit x86 packages
> > with SSE2 unconditionally enabled.
> 
> There is already an x32 ABI port in Debian (and I thought it also was in
> Ubuntu at some time?)

x32 has never been in Ubuntu.  But in any case x32 is an entirely
different ABI, which is unrelated to the ISA baseline selected for i386.

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: Proposal: Let's drop i386

2018-05-13 Thread Colin Watson
On Sun, May 13, 2018 at 02:33:08PM -0400, Jeremy Bicha wrote:
> On Sun, May 13, 2018 at 1:57 PM, Colin Watson <cjwat...@ubuntu.com> wrote:
> > IIRC Steam is also relevant, and I guess that would involve talking to
> > Valve?
> 
> I think our users would be better served by Steam becoming a Snap. I
> have more explanation at https://launchpad.net/bugs/1759715
> 
> I suppose that could be done for Wine too although Wine doesn't
> currently have the unsolved maintenance challenges that Steam does.

Would this involve building with -m32 rather than shipping copies of
i386 packages from the archive?  (If the former, I agree that that would
help with this class of problem.  If the latter, it would at best defer
the problem for a few years.)

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: Proposal: Let's drop i386

2018-05-13 Thread Colin Watson
On Thu, May 10, 2018 at 04:25:25PM -0400, Thomas Ward wrote:
> However, killing i386 support globally could introduce issues, including
> but not limited to certain upstream softwares having to go away
> entirely, due to the interdependency or issues with how certain apps
> work (read; Wine, 32-bit support, 64-bit support being flaky, and
> Windows apps being general pains in that they work on 32bit but not
> always on 64-bit).

Is there any possibility of building this kind of thing in biarch style
(i.e. on the amd64 architecture, but with -m32 or similar)?  I know that
may well involve building some more biarch libraries along the way, but
it would give us an exit strategy that doesn't involve dropping things
like Wine.

IIRC Steam is also relevant, and I guess that would involve talking to
Valve?

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: Ubuntu packaging: package libxcomposite-dev

2018-05-07 Thread Colin Watson
On Fri, May 04, 2018 at 09:11:14PM +0300, Lapshin Dmitry wrote:
> I have found out that libxcomposite-dev in Bionic depends on
> transitional package x11proto-composite-dev (that depends on
> x11proto-dev solely). Should the dependency be fixed?

Possibly; but this is true in Debian unstable as well, so it would be
best to report it there first and then it can trickle down.  (A minor
problem like this wouldn't meet the criteria for stable updates, but it
could be fixed for later releases.)

Thanks,

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: extlinux dependent issue

2018-04-28 Thread Colin Watson
On Sat, Apr 28, 2018 at 05:55:44PM +0200, Ralf Mardorf wrote:
> I'm surprised that "syslinux{,-common}" are in "main", see
> https://packages.ubuntu.com/bionic/syslinux{,-common} and "extlinux" is
> in "universe", see https://packages.ubuntu.com/bionic/extlinux, while
> all belongs to the same upstream source.

This is routine when only some of the binaries are actually used for
main-like purposes.  (syslinux is used for Ubuntu ISO images when
booting in BIOS mode.)

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: Ubuntu-devel-discuss Digest, Vol 135, Issue 11

2018-02-11 Thread Colin Watson
On Sun, Feb 11, 2018 at 09:56:18AM -0500, Technical Clarity wrote:
> Sorry, Canonical has UbuntuOne accounts, can Ubiquity pare with UbuntuOne
> and through its UbuntuOne and it's derivatives should have access, how much
> can we extend in UbuntuOne features

The remaining piece of Ubuntu One is login.ubuntu.com, providing account
management and single sign-on to a number of sites.  It has basically no
bearing on cross-distribution installation/upgrade.

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: debmirror compatibility with Kali

2018-01-18 Thread Colin Watson
On Tue, Jan 16, 2018 at 06:54:38PM -0500, Derek Murphy wrote:
> I'm having a few issues with debmirror working with the Kali repo. We are
> using this for offline networks at work and I have ubuntu and debian both
> working stably. My issue is with the size error messages.
> 
> Please let me know what you think.
> 
> user@nodata-gaming:/mnt/d/Linux_Repo# ./mirrorbuild_kali.sh

I don't think this is something I've fixed in later versions, but I'd
need to dig.  Could you please file a Debian bug against debmirror
(https://www.debian.org/Bugs/Reporting) containing:

 * the version of debmirror you have installed
 * the full contents of the debmirror wrapper script you're running
   (editing out any secrets if necessary, but there probably aren't any)

-- 
Colin Watson   [cjwat...@debian.org]

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


Re: On Lists and Iterables

2017-12-17 Thread Colin Watson
On Sun, Dec 17, 2017 at 12:22:20PM +0100, Xen wrote:
> Neal McBurnett schreef op 16-12-2017 18:16:
> > For more on the rationale for changes related to iterators see
> > http://portingguide.readthedocs.io/en/latest/iterators.html
> 
> That entire rationale is only explained with one word "memory consumption".
> 
> So now you are changing the design of your _grammar_ just so that the
> resulting code will use less memory.
> 
> That is the job of the compiler, not the developer.

I don't think the document above does a particularly good job of
explaining it, and I think you've fundamentally misunderstood things,
perhaps by extrapolating too much from toy examples.

zip() takes iterables as its inputs; concrete lists are only one kind of
iterable.  Iteration constructs are very widespread in non-trivial
Python code, and it's common to make use of iterators to express
constructions where you can cheaply extract a few elements but it would
be expensive to extract them all.

For example, I spend most of my time working on database-backed web
applications, which is a very popular application for Python.  In that
context, it's commonplace to make database queries via functions that
return iterators and do lazy loading of results.  You then iterate over
these to build a page of results (which can use things like LIMIT and
OFFSET when compiling its SQL queries), and you render and return that.
If you accidentally call something that consumes the whole input
iterable in the process, then it's going to do a *lot* of database
traffic for some queries, and it doesn't take much of that to utterly
destroy the performance of your application.

This is not something that the compiler can optimise, because the
*contract* of zip et al in Python 2 was that it would consume the entire
inputs (up to the shortest one in the case of zip, anyway); iteration is
visible to the program and can have external side-effects, and it's not
something that can be quietly optimised out given the design of the
language.  Talking about memory consumption of the result is relevant in
some cases, sure, but it's certainly not the whole story; what often
matters is the work involved in materialising the whole iterable, and
that can be very significant indeed.

In Python 2, there were many functions that took iterables as input and
returned concrete lists, consuming the entire inputs in the process.  In
most cases there were versions of these that operated in a lazy fashion
and returned iterables instead, but they were generally hidden off in
the itertools module and less obvious compared to the built-in versions.
Effectively, the language did the wrong thing by default.

Python 3 changes these around to give preference to the versions that
take iterables as input and return iterables as output, and says that if
you want a list then you have to use list() or similar to get one.  This
reduces the cognitive load of the language, because now instead of
remembering the different names for the list-returning and
iterable-returning versions of various things, you only have to remember
one version and the general rule that you use list() to materialise a
whole iterable into a list (which was already useful for other things
even in Python 2).  It makes the language simpler to learn, because
there are fewer rules and they compose well; and it makes it easier to
do what's usually the right thing.  This comes at the cost of a bit of
porting effort for some code that started out in Python 2, of which
there'll be less and less as time goes on.

To put it another way: "don't perform operations on collections of
unbounded size" is pretty much the number one rule for webapps that I've
picked up over the last few years, and Python 3 takes this lesson and
applies it to the core language.

Toy examples involving zip([1, 2], [3, 4]) and the like miss the point
because they simplify too much.  This family of functions is almost
always used in iteration constructs, usually "for ... in" or a
comprehension, and in those common cases the programmer doesn't have to
change anything at all.  In cases where they do need to change
something, it has the useful effect of highlighting that something a
little unusual may be going on, rather than hiding behaviour that's
potentially catastrophic at scale behind an innocuous-looking built-in
function.

> Meanwhile Python 3.4 can be excessively slower than 2.7. SO WHERE'S THE
> GAIN?

It will no doubt depend on the benchmark, and rather than cherry-picking
a single one it's likely more interesting to look at either a wide range
of benchmarks, or at the specific application in question.
Counterpoint, which also links to much more data:

  https://lwn.net/Articles/725114/

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: On Lists and Iterables

2017-12-17 Thread Colin Watson
on in saying that he would have
> preferred a 'legacy' mode for the interpreter.

I've explained already why I don't think it's particularly forced, and
I'd also add that I do recognise that such a "legacy" mode would have
been extremely difficult to build - retaining the ability to execute
Python 2 code is one thing, but in practice you'd need to be able to
pass data between the two worlds and to say the least it's not at all
obvious how that could work (Perl 5 vs. 6 doesn't have this problem).
Anyway, it's the nature of things that older versions of software are
rarely maintained in perpetuity, so I find it pretty hard to get worked
up about it.

(Incidentally, I find it pretty weird when anyone who isn't, say, my
bank manager or something refers to me using a title.  You don't seem to
do that for other people in general, so I assume you're trying to make
some kind of point, but I'm afraid it escapes me.)

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: Python2 demotion (moving from main to universe) in progress

2017-12-15 Thread Colin Watson
On Fri, Dec 15, 2017 at 03:38:20AM +0100, Xen wrote:
> Colin Watson schreef op 09-12-2017 13:51:
> > Even as somebody generally very sympathetic to the needs of
> > localisation, I've got this wrong because Python 2 had just too many
> > ways to make mistakes in this area.
> 
> So you are basically saying that you still don't agree but you have somehow
> accepted your own fallibility in that something you like is wrong and
> something you dislike is right.

No - you're putting words in my mouth that are the opposite of what I'm
saying.  Kindly don't reply to try to convince me otherwise.

In general, I dislike programming idioms that are too easy to get wrong.

> I happen to know the % operator ;-).
> 
> It is ridiculous that you cannot use it for binary-only text, or what I
> would call just byte strings.

You can use the % operator on bytes, as of Python 3.5.  Please spend
more time checking the assertions you make.  It's the much newer
"format" method that still isn't supported on bytes, and from
https://bugs.python.org/issue3982#msg268160 it sounds like that's
intentional and well-founded.

  https://docs.python.org/3/whatsnew/3.5.html#whatsnew-pep-461

(Python 3.5 is in Ubuntu 16.04; while some people may care, I'm not
personally especially interested in earlier versions of Python 3 at this
point, although I've been using it on and off since 3.2 or so.)

While I know there are exceptions, some mentioned in that issue link
above, on the whole my impression is that old Python code isn't likely
to be using str.format very much anyway, since it's a relatively modern
innovation compared to Python 2; it was introduced in 2.6.

> This example really says it all:
> 
> Python 2: b'Content-length: {}\r\n'.format(length)
> 
> Python 3: b''.join([b'Content-length: ', (bytes if bytes is str else
> str)(length).encode('ascii'), b'\r\n'])
> 
> Or well, that is 2<>3 compatible code.

Sure, if you work at it you can always construct unnecessarily
complicated examples.  "bytes if bytes is str else str" is strictly
identical to "str", on both Python 2 and 3.  (Glyph is an extremely
experienced and competent developer, so I'm sure this was just an
oversight.)

But you can just do this instead, which in fact is roughly what Twisted,
the source of the above comment, now does:

  Python 2/3: b'Content-Length: %d\r\n' % length

(As mentioned above, str.format was new in Python 2.6, so this is just a
return to the status quo ante for bytes.)

> So if this person does keep maintaining this project and it gets some
> traction, you could have a 'supported' python 2 interpretor being callable
> by "python2" or "python2.7" or even "python2.8" for some time to come.
> 
> If more people rally around that you could even have an unofficial
> 'official' Python 2.8 specification ;-).
> 
> Of which Tauthon would then be one interpreter ;-).
> 
> You could then move Tauthon (package "tauthon") to universe around the time
> that you would move python 2.7 out of it.

If it turns out that the maintainer of Tauthon builds a sustained track
record of doing a good job with it, then I'd support it being available
in Ubuntu.  There's still quite a while until Python 2.7 is in any
danger of being removed from Ubuntu, so there's time for them to develop
such a track record.

(I don't think we should hold back other packaged libraries to support
it, though; for example, Django 2.0 dropped support for Python 2.  So it
might be that Tauthon users would end up in practice with an
Ubuntu-packaged interpreter and then using packages from PyPI in a
virtualenv for most things that aren't in the standard library, or
something like that.  That would possibly work well enough; the audience
for something like Tauthon probably also wants to stick with old library
versions as well, at least until they can upgrade in a
tightly-controlled fashion.)

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: Cannot find required packages

2017-12-13 Thread Colin Watson
On Wed, Dec 13, 2017 at 04:55:05PM +, Edmond Condillac wrote:
> I'm trying to get started as an editor for the Ubuntu Manual Project
> on the version 18.04 LTS (Bionic beaver).  During installation of the
> upstream version of TeX Live to compile the manual successfully, the
> terminal command ~/Projects/ubuntu-manual-bionic/pkgs/install-pkgs.sh
> gives the error output as follows:
> 
> Require package list is:
> 
> ttf-arabeyes
> 
> ttf-kacst
> 
> Kindly advise, if possible, how I may obtain these required missing packages, 
> please.

Nowadays these are fonts-arabeyes and fonts-kacst respectively.  The
script in question should be updated to refer to the new names (which
have existed for some years, so it should be an easy change to make).

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: Python2 demotion (moving from main to universe) in progress

2017-12-09 Thread Colin Watson
On Sat, Dec 09, 2017 at 12:47:28PM +0100, Xen wrote:
> Colin Watson schreef op 09-12-2017 0:24:
> > there are good reasons behind many of the changes in Python 3
> 
> You know, an appeal to "good reasons" is really a blanket statement that
> betrays the absence of any good reasons.

No, it betrays limited time to write.  To take just one example, Python
2's willingness to mix Unicode and binary types provided that the binary
strings were limited to 7-bit ASCII was the cause of a large number of
bugs over the years, which Anglophones tended to overlook and allow to
reach production code because they rarely use characters outside ASCII.
Even as somebody generally very sympathetic to the needs of
localisation, I've got this wrong because Python 2 had just too many
ways to make mistakes in this area.  In Python 3 you have to confront
the distinction earlier and have a much better chance of getting it
right.  You can certainly begin to make the distinction in Python 2
code, but adding the extra type-safety required a breaking change.

I'm not going to continue to spend time explaining the underlying
reasons in response to vague insinuations, though.  If there are some
particular changes in Python 3 that you think weren't well-founded, name
them.  This is a list for developers; we can be specific.

> So you go on to detail the similarities with C but with C there never was
> one breaking point, just incremental changes.

There have been many breaking changes in C over the years, though since
it's an essentially smaller language most of those changes (not all!)
have been at the runtime or library levels.  Small consolation if that's
what breaks your code, of course.

But you seem to be under the impression that moving from Python 2 to
Python 3 requires non-incremental changes: i.e. a flag day where your
code stops working on Python 2 and starts working on Python 3.  This
isn't so.  There's a large subset that works fine in both: nearly all
the code I write these days is "bilingual" in this way, and the obvious
porting strategy for most code involves making it be this way, so at the
end all you have to do is flip to the newer interpreter after your tests
pass.

I would rather that Python 3 had taken the Perl 6 approach of having the
newer interpreter be able to execute older code in a special
compatibility mode, so that we could mix-and-match more freely and the
transition would have been easier.  On the other hand, it's not at all
obvious how text/bytes types would have worked across the boundary.
(And, much though I like Perl, Perl 6 has taken even longer to get into
typical developers' hands than Python 3 has, so ...)

> The work of "God" (unfortunate events) should not be willfully perpetrated
> by humans on one another on purpose.

What is your *concrete* proposal here?  Bear in mind that we don't have
the resources to maintain Python 2 indefinitely; if that's your
proposal, it's going to run up against real-world constraints.  But
there may be other things we can do to make it easier for people.  Do
you have some specific projects that are troublesome?

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: Python2 demotion (moving from main to universe) in progress

2017-12-08 Thread Colin Watson
On Fri, Dec 08, 2017 at 09:51:00PM +0100, Xen wrote:
> It was pushed upon an unwilling community

Oh, please.  I don't think anyone's going to argue that it's been the
best-managed transition in the history of ever: it's true that it
effectively split the community for a while, a lot of work has had to be
put into porting work that might otherwise have been spent on other
things, and we're still in a situation where many newer facilities have
remained inaccessible to developers of older projects for longer than
they ordinarily would have done.  None of these things is anything like
ideal.  But framing it as a dichotomy between those nasty developers and
an unwilling community of consumers is facile; it is by no means that
simple.  Plenty of folks in the Python community have recognised that,
even if it isn't an ideal situation, there are good reasons behind many
of the changes in Python 3 and they've put lots of energy into helping
out.

In any case, there is really very little point in tilting at this
windmill now, unless your goal is to expend further energy.

> But I was going to say 2 years might seem like a lot, or 3 years, but it is
> nothing.

It's been obvious for nearly ten years now that Python 2 was going to
reach the end of the road eventually; once the incompatible changes to
the language landed, it was naïve to expect that Python 2 would continue
to be maintained indefinitely.  Anybody who's only suddenly noticing it
really hasn't been paying attention at all.

> Meanwhile we can still run C programs from 1980, basically.
> 
> Or whereabouts, at least.

Interesting you should say that, because (just to take one example) the
attitude to undefined behaviour in compilers has changed a great deal
since 1980.  Your C program written back then may still manage to
compile with sufficient "please run in ancient mode" compiler options,
but will it behave as expected if nobody has maintained it in nearly 40
years?  Who can say, but probably only if it's very simple and you're
quite lucky.  And in fact unless it's the simplest possible kind of
program with almost no system dependencies, you'll probably have to
spend at least some effort bringing it up to date with post-Neolithic
header names and function signatures.

Admittedly I only have experience of maintaining moderate-sized C
programs that hailed from the 1990s rather than the 1980s, but in my
experience the work involved in keeping that sort of thing up to date
isn't significantly different from the work involved in doing the same
for similarly-sized Python projects.  (That is, if it's more than a
couple of thousand lines or so then somebody probably needs to be
actively maintaining the thing even if its basic functionality is
static, and you're going to have to occasionally deal with changes in
the language or its runtime facilities, changes in your dependencies,
and stuff you just missed.)

> I think you can definitely find a way to compile most programs from 1990...

Similarly, I'm sure it will remain possible to dig up Python 2 and
continue to use it for many years to come, even after it's no longer
supported upstream and no longer in Ubuntu.

Whether that's a good idea after nobody is taking responsibility for
security updates to the core language or the standard library, and after
the libraries you depend on have dropped Python 2 support so you're
stuck on older versions, is up to you to decide.  If it's at all
network-facing, then anyone with a reasonable sense of responsibility
realised some time ago that they need to keep their dependencies up to
date.  If it's entirely self-contained, then maybe it's fine; to save on
maintaining your own Python build, you could perhaps run it in a
container running an older version of the OS.  Or if the program is
simple you may well just be able to run 2to3 over it and at least get
most of the way there.

But unless it's really enormous, it's probably not all that hard to port
anyway.  Putting a clear bytes/text distinction in place if you didn't
have one already can be tedious, sure, but it generally makes things
better; most of the rest is easy by comparison; and nowadays there are
several good libraries and strategies to help.

Lest anyone think I'm casually underestimating the work involved, I'm
speaking here as a Launchpad developer: three-quarters of a million
lines of Python code, and a couple of hundred dependencies.  Sure, we're
still on Python 2, which is a problem: other projects have generally
taken precedence and porting has been a back-burner task.  But a large
part of the work we need to do is work we'd have needed to do anyway,
such as bringing many of those dependencies up to date or finding
better-maintained versions of some of them, and we have at least the
skeleton of a plan.  I feel quite safe in saying that for most Python
programs it would be a great deal easier than this.

-- 
Colin Watson   [cjwat...@ubuntu

Re: Bug#881692: command-not-found: I re-wrote command-not-found

2017-11-16 Thread Colin Watson
On Thu, Nov 16, 2017 at 05:10:19PM -0800, Shawn Landden wrote:
> On Mon, Nov 13, 2017 at 11:50 PM, Julian Andres Klode <j...@debian.org>
> wrote:
> > * It needs to be translated - also very important.
> 
> I made a pot file and used translations from the python version, but I
> can't get my app to look for translations (as examined through strace). I
> read the gettext manual and do not know what I am doing wrong.

Looking at
https://github.com/shawnl/command-not-found/blob/master/command-not-found.c,
your problem appears to be that you aren't calling setlocale().  You
should normally call this before calling bindtextdomain() and
textdomain():

  setlocale(LC_ALL, "");

(The gettext manual does cover this, but possibly you were looking at
some different bit of it.)

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: aptitude's libicu56 dependency

2017-10-04 Thread Colin Watson
On Mon, Sep 25, 2017 at 10:58:05AM +, Brian Haslett wrote:
> I was cleaning out my system of orphaned packages the other day and I
> couldn't help but notice that aptitude is linked with libicu56
> libraries but doesn't list the package as a dependency.  I'm using the
> "artful" flavor of ubuntu.

I've just checked, and aptitude doesn't appear to be linked with
libicu56 in artful.  Exactly what command are you running that shows
that this linkage exists?

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: Launchpad builder changes: schroot and LXD

2017-09-06 Thread Colin Watson
On Wed, Sep 06, 2017 at 01:36:46PM +0100, Colin Watson wrote:
> No thanks - I already have fixes for both the powerpc and CPC cases
> working their way through the deployment pipeline.

... and these are now fixed on production.

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: Launchpad builder changes: schroot and LXD

2017-09-06 Thread Colin Watson
On Wed, Sep 06, 2017 at 12:59:00PM +0100, Dimitri John Ledkov wrote:
> There have been, at least in the past, packages in ubuntu that do rely
> on HOME being a real directory and would FTBFS locally when HOME
> pointed to non-existant directory, but would build fine in launchpad.
> 
> Hence I have 'HOME' => '/build/' in my ~/.sbuildrc. I shall drop that
> now, to match launchpad's new behavior.
> 
> But something to be aware of.

Indeed.  I've also seen this in the past, but since Debian's builders
point HOME to a nonexistent directory nowadays I expect it's getting
rarer and should generally be considered a bug.

> >  * Snaps and live filesystems are now built in LXD containers rather
> >than in chroots, laying the groundwork for them to be able to install
> >snaps as build-dependencies.
> >
> > At the moment the only known regressions from this are in some corner
> > cases of live filesystem building (powerpc and CPC).  Let us know if you
> > see anything else amiss, although as usual please try to reproduce
> > problems locally before attributing them to the build environment.
> 
> This has been noticed for the CPC case, and is trivially reporducible
> with lxd and the OddBloke's cloud builder. I had an updated lxd
> profile from steve that supposedly does work, shall I test that, and
> do you need the updated (less restrictive) lxd profile for the devirt
> CPC livecd builds? A priviledged lxd container alone is not enough
> there.

No thanks - I already have fixes for both the powerpc and CPC cases
working their way through the deployment pipeline.

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: What happened to the *-dbg packages in Ubuntu 17.04?

2017-04-07 Thread Colin Watson
On Fri, Apr 07, 2017 at 08:45:09PM +0200, Mattia Rizzolo wrote:
> I know a little work happened to make Ubuntu build debug packages as
> does Debian now, I guess this work will (very) slowly make them
> converge.

Kind of.  I think you're referring to:

  https://bugs.launchpad.net/bugs/1623256

So there is a bit of convergence, although I don't believe Ubuntu's
debhelper has yet gained the changes to take advantage of my
launchpad-buildd tweak.  I imagine that will happen at some point
though; converging debhelper where possible is generally worthwhile.

Debian uses the .deb extension rather than .ddeb, and switching to that
would be a rather more complex endeavour.  Personally I think this was a
mistake and argued that at the time, but I didn't succeed.  At any rate,
it would require some probably-possible but rather complex changes to
Launchpad's upload processor to make it able to handle using the same
extension for both.

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: git workflows for general Ubuntu development

2016-11-14 Thread Colin Watson
On Mon, Nov 14, 2016 at 04:58:44PM -0800, Nish Aravamudan wrote:
> 2) dgit does not fully meet our needs at this time. It's going to be
> something Robie covers in more detail in the UOS session, but hopefully
> he'll be able to respond here, as well.

I think there's the follow-up question here of "why not improve dgit to
meet our needs?".  That was certainly always what I envisioned happening
when I was sketching out preparatory work for this on the Launchpad
side; I'd already done some initial preparation to get it working for
us; and there are some problems (perhaps not fatal, but not necessarily
trivial) associated with having more than one potential importer, not to
mention the duplicated effort.

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: gdlib-config command missing in yakkety

2016-11-04 Thread Colin Watson
On Fri, Nov 04, 2016 at 11:20:01AM +0100, Vincent Gerris wrote:
> I noticed when trying to install GD-2.53 with perl, that the gdlib-config
> command seems to be missing, which was there in :
> packages.ubuntu.com/xenial/libgd-dev
> 
> Can you explain what happened?

It was removed upstream of us by Debian a little while back:

  https://tracker.debian.org/news/770159

I believe you're supposed to use pkg-config instead nowadays.

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: Future and impact of ongoing projects in Linux world

2016-10-05 Thread Colin Watson
On Wed, Oct 05, 2016 at 04:23:38PM +0200, Xen wrote:
> Oliver Grawert schreef op 05-10-2016 14:41:
> >along with that click packages are user packages and being used in
> >ubuntu products on sale since 2015 (snaps will replace them
> >eventually).
> 
> That just means a user can install them, not that they are installed
> specifically for a user?

Not so; click packages may be installed (technically, "registered")
specifically for one or more users.  The process is mediated by a system
facility, certainly, but it can be per-user.  (It's also possible to
register them for use by all users, which is roughly equivalent to a
system-wide installation.)

The reason for it to be mediated by a system facility was so that ten
users all installing the same click package don't end up using ten times
the storage.  Not very interesting on a single-user phone, but
potentially interesting on e.g. a multi-user tablet and would have been
pretty important if click packages had ever made it to the desktop in a
big way.

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: gimp cage tool - fix in 16.04?

2016-09-26 Thread Colin Watson
On Mon, Sep 26, 2016 at 05:28:26PM -0500, Simon Quigley wrote:
> Hello Robert,
> 
> I'm doing some casual poking around at the moment to see how easy it
> would be for this patch to be applied.
> 
> > The cage tool in 2.8.16-1ubuntu1.1 is broken. Details can be found here:
> > https://bugzilla.gnome.org/show_bug.cgi?id=678085
> > 
> > If I am not mistaken 2.8.18 does not fix the issue. At least the
> > changelog at [1] does not indicate anything about a fix and target
> > milestone of the bug is 2.10. Do you see any chance that the fix for
> > this issue will be made available via patch in 16.04?
> 
> I think otherwise. Look at when this Git tag was set upstream:
> https://git.gnome.org/browse/gimp/tag/?h=GIMP_2_8_18
> 
> tag date  2016-07-13 20:27:19 (GMT)
> 
> This is the date for 2.8.16:
> 
> tag date  2015-11-21 18:04:13 (GMT)
> 
> Let's look at the timestamps on the two commits that were done to fix
> this problem:
> 
> 2016-02-02 11:21:15 (GMT)
> 
> 2016-02-07 17:50:11 (GMT)
> 
> So unless there is some magical way to ensure commits don't land in a
> Git tag (which I highly doubt they would even WANT to do either way), it
> should be fixed.

That isn't quite how it works: it depends on which branch the tag was
made from.  A more accurate approach is to clone the repository and use
"git describe --contains":

  $ git describe --contains b5546ac0ac4a30bfd31ccc75c22f722a1c38dee1
  GIMP_2_9_4~880

In other words, it was only committed to master after the gimp-2-8
branch was made; and there's no evidence that this was cherry-picked
onto the gimp-2-8 branch (from a quick log inspection).  It indeed does
not appear that this commit is in 2.8.18, although it should be in 2.9.4
(an unstable-series release).  It might be worth asking upstream whether
it can be fixed in the 2.8 series.

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: Changes missing from yakkety-changes list?

2016-06-16 Thread Colin Watson
On Thu, Jun 16, 2016 at 11:50:16AM +0100, J Fernyhough wrote:
> It seems that there are changes to packages in Yakkety that are not
> included in the changes mailing list. For example, VLC is at 2.2.4 [1]
> but the mailing list [2] only has 2.2.2:

Auto-syncs from Debian aren't mailed to -changes lists, only changes
that are explicitly uploaded to Ubuntu.  While it's true that a small
number of people might be interested, it would be extremely noisy and
we've generally felt that it isn't worth the noise.

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: Unable to apt-get changelog on ubuntu because changelog.ubuntu.com is down

2016-04-13 Thread Colin Watson
On Wed, Apr 13, 2016 at 01:45:51PM +0900, kanbe kota wrote:
> It seems http://changelogs.ubuntu.com/changelogs is down now.

Yes, it suffered a catastrophic disk failure.  Our sysadmins are working
on restoring service.

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: deboostrap eg : 14.04.1

2016-03-09 Thread Colin Watson
On Wed, Mar 09, 2016 at 03:11:49PM +0100, Master wrote:
> First thing is when I use two live installer for 14.04.1 and 14.04.2,
> later on during updates/upgrades, does my two installation 14.04.1 and
> 14.04.2 diverge or converge?Does installed 14.04(.x) end up being all
> the sames after packages apt-get update/(dist?-)upgrade?

Almost.  The exception is that you may remain on an older hardware
enablement stack until you take explicit action:

  https://wiki.ubuntu.com/Kernel/LTSEnablementStack

> What I mean is the DISTRIB_DESCRIPTION of /etc/lsb-release remains
> 14.04.1 for one and 14.04.2 for the other.So does the packages level
> also remains 'in-line' with that support release version?

No, this has nothing to do with the enablement stack stuff.  If you
aren't seeing /etc/lsb-release being brought up to date, then your
upgrades aren't actually happening and you need to investigate why.

> Because my second things is that I am trying to debootstrap a specific
> ubuntu version eg : 14.04.1 for testing purposes.But I am not sure how
> to accomplish that, if even possible.

In general that's not possible, because not all the packages from older
point releases remain available from the networked archive.  To install
an older point release, you need to install from corresponding
installation media.

> I always get DISTRIB_DESCRIPTION at 14.04 and I am not sure if it
> means 14.04(.0) or 14.04(.4 latest?)?

debootstrap will bootstrap from trusty without trusty-updates, which
corresponds to 14.04(.0).  You can then apply updates on top of that,
which will get you to whatever is latest (not necessarily the latest
point release, but rather rolling stable updates).  You can't get to a
specific point release this way.

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: Re: about upstart

2016-01-06 Thread Colin Watson
On Thu, Jan 07, 2016 at 09:04:59AM +0800, yan...@iscas.ac.cn wrote:
> Thank you Martin.There is also a doubt: how the lightdm starts
> upstart? I can not find anything useful  in unit files ? 

It's hooked up via Xsession configuration, in
/etc/X11/Xsession.d/00upstart and /etc/X11/Xsession.d/99upstart.

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: systemd-fsck@.service

2015-12-02 Thread Colin Watson
On Mon, Nov 30, 2015 at 05:29:35PM +0200, Tom H wrote:
> 1) How does the unit now what "%f" is?

See the "SPECIFIERS" section of the systemd.unit(5) manual page.

> 2) "%i" is, in the case that I set up a few weeks ago,
> "sys-devices-pci:00-:00:0d.0-ata4-host3-target3:0:0-3:0:0:0-block-sdb-sdb1".
> Should it have "sdb" in it since it's supposed to be an unstable name?

There doesn't seem any particular reason for the various %i.device units
that this particular service is bound to to need stable names.  The
purpose of systemd-fsck@.service is just to run fsck on all your block
devices; it doesn't much matter what they're called.

Jobs that need to run on only particular block devices would typically
be udev rules rather than systemd units, I think; but if need be a
systemd unit could always use udevadm to inspect the udev database for
information about a particular device.  (There may be some better way.)

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: Last minute sync of a new Debian package

2015-10-18 Thread Colin Watson
On Sun, Oct 18, 2015 at 11:13:52PM +0300, Zeev Pekar wrote:
> So I'm turning on you in this informal way asking to sync the package
> before the final 15.10 release. It should work smoothly as indicated
> here:
> https://lists.ubuntu.com/archives/ubuntu-users/2015-October/282768.html

I agree that this seems unlikely to pose a problem.  I've synced it.

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: Fwd: user space probe in ubuntu 14.04

2015-09-15 Thread Colin Watson
On Tue, Sep 15, 2015 at 10:52:57PM +0800, Gareth wrote:
> I'm systemtap users on ubuntu. Here is an issue about mysql dbgsym
> package. Below are some details
> 
> ps:
> 
> http://paste.openstack.org/show/462299/ some bash history
> http://paste.openstack.org/show/462471/ the packages I have installed
> 
> -- Forwarded message --
> From: Frank Ch. Eigler <f...@redhat.com>
> Date: Tue, Sep 15, 2015 at 10:35 PM
> Subject: Re: user space probe in ubuntu 14.04
> To: Gareth <academicgar...@gmail.com>
> Cc: David Smith <dsm...@redhat.com>, system...@sourceware.org
[...]
> These ubuntu 14 builds of mysql did not include the sys/sdt.h markers
> necessary for use of the .mark() probes.  "readelf -n /usr/sbin/mysqld"
> fails to show any NT_STAPSDT notes.

(Please note that "Ubuntu 14" isn't a thing; it's 14.04, and the 14 is a
truncated year not a major version.  Otherwise, this is outside my
expertise.)

> If you installed mysql-{client,server}-5.5-dbgsym, you should be
> able to use .function() etc. probes ... but something's broken in the
> ubuntu build system:
> 
> % dpkg -l 'mysql-server-5.5*'
> ii  mysql-server-5.5   5.5.44-0ubuntu0.14.04.1
>amd64  MySQL database server binaries and
> system database setup
> ii  mysql-server-5.5-dbgsym5.5.44-0ubuntu0.14.04.1
>amd64  debug symbols for package
> mysql-server-5.5
> 
> % stap -L 'process("/usr/sbin/mysqld").function("*")'
> [empty!]
> 
> % readelf -n /usr/sbin/mysqld
> [...]
> Build ID: 7c5b991d6ba0d7722a41f9a39e2915f6a354a1c7
> 
> % dpkg -L mysql-server-5.5-dbgsym | grep 5b99
> [empty!]
> 
> So the dbgsym package doesn't contain debuginfo for that actual build,
> despite the identical version numbers.  Please raise this problem with
> ubuntu.

This is a mistaken analysis.  /usr/sbin/mysqld is in
mysql-server-core-5.5, not mysql-server-5.5, and therefore its debugging
symbols are in mysql-server-core-5.5-dbgsym:

  $ dpkg -c mysql-server-core-5.5-dbgsym_5.5.44-0ubuntu0.14.04.1_amd64.ddeb | 
grep 5b99
  -rwxrwxr-x root/root  48818397 2015-07-16 23:50 
./usr/lib/debug/.build-id/7c/5b991d6ba0d7722a41f9a39e2915f6a354a1c7.debug

(The debugging packages are automatically generated and their
dependencies do not necessarily correspond to those of the runtime
packages, so you can't just go "oh, I installed mysql-server-5.5 and got
mysqld, mysql-server-5.5-dbgsym must be good enough", you have to check
the actual package name with "dpkg -S".)

The information that Gareth provided indicated that they already had
mysql-server-core-5.5-dbgsym installed, so perhaps this problem is
entirely explained by the NT_STAPSDT bit above.

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: problems about dependency of mysql-server-5.5-dbgsym

2015-09-15 Thread Colin Watson
On Tue, Sep 15, 2015 at 05:11:01PM +0800, Gareth wrote:
> I know this. But at the first time I enabled ddebs' trusty only (no
> trusty-updates yet), I got errors from running apt-get install this
> package. Because the mysql-server's latest version is
> 5.5.44-0ubuntu0.14.04.1, and the dbgsym package from trusty repo is
> 5.5.35+dfsg-1ubuntu1. After enabling trusty-updates, I got what I
> need, the dbgsym package with 5.5.44-0ubuntu0.14.04.1

Right, but the version of mysql-server-5.5 in trusty (not
trusty-updates) was 5.5.35+dfsg-1ubuntu1, so this is consistent.  If
you're going to enable ddeb repositories, you need to enable a set of
them that matches the ordinary binary repositories you're using.

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: Kernel install in boot with GRUB

2015-07-14 Thread Colin Watson
On Tue, Jul 14, 2015 at 01:22:17PM +0100, jason.mor...@aveillant.com wrote:
 Can anybody recall the purpose behind the 'historical compatibility' , is 
 there a previous bug that I can reference in our documentaiton?

One problem is that the default lilo configuration had problems with it
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=329994).  I'd like to
see everything collected in /boot, indeed, but somebody is going to need
to go through base-installer and kernel packaging revision history in
some detail to work out all of the ramifications.

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: Kernel install in boot with GRUB

2015-07-14 Thread Colin Watson
On Tue, Jul 14, 2015 at 10:51:21AM +0100, jason.mor...@aveillant.com wrote:
 If the installer were to simply add the symlinks /boot/vmlinuz and 
 /boot/inirtd.img, pointing to the latest kernel things would be much 
 simpler.
 It already adds symlinks in /, so placing them in /boot is trivial.

There's support for this, but it's disabled by default, I think for
historical compatibility of some kind.  Preseeding
base-installer/kernel/linux/link_in_boot=true should enable it, though.

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: Kernel install in boot with GRUB

2015-07-14 Thread Colin Watson
On Tue, Jul 14, 2015 at 02:26:51PM +0100, jason.mor...@aveillant.com wrote:
 That sounds like a knotty task. Is lilo not yet deprecated for Ubuntu 
 12.04+ on all platforms?

One of the tasks of whoever takes this on (not me; I'm not routinely
working on the installer any more) would be to work out whether there
are any stragglers who would be affected by this, what the upgrade
considerations would be, etc.

 What if the added symlinks were only done for Grub, or can't the installer 
 work out what the bootloader is?

At the time when link_in_boot is set, the installer hasn't yet got to
the point of selecting a boot loader.

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: Building against libsmbclient-dev:armhf

2015-06-11 Thread Colin Watson
On Tue, Jun 09, 2015 at 11:31:32AM +0100, Alan Pope wrote:
 # Get source to build
 bzr branch lp:ubuntu-filemanager-app
 
 # Build it
 Using this script http://paste.ubuntu.com/11667958/ to build
 armhf/amd64/i386 fat package. Fails at first hurdle, the armhf build:-
 
 http://paste.ubuntu.com/11669092/

ubuntu-filemanager-app is doing a ton of manual work to find
libsmbclient, and the manual work it's doing doesn't look very
multiarch-friendly to me:

  ## samba requires libsmbclient
  find_path(SAMBA_INCLUDE_DIR 
NAMES libsmbclient.h 
HINTS /usr/include/smbclient /usr/include/samba 
/usr/include/samba-3.0 /usr/include/samba-4.0
)
  find_library(SAMBA_LIBRARIES NAMES smbclient )
  message(STATUS samba include=${SAMBA_INCLUDE_DIR})
  message(STATUS samba lib=${SAMBA_LIBRARIES}=${SAMBA_LIBRARIES})
  
  if(SAMBA_INCLUDE_DIR AND SAMBA_LIBRARIES)
 message(STATUS Found samba: include=${SAMBA_INCLUDE_DIR}  
library=${SAMBA_LIBRARIES})
 INCLUDE_DIRECTORIES(${SAMBA_INCLUDE_DIR})
 TARGET_LINK_LIBRARIES(nemofolderlistmodel ${SAMBA_LIBRARIES})
  else(SAMBA_INCLUDE_DIR AND SAMBA_LIBRARIES)
 message(FATAL_ERROR Could not find Samba libsmbclient)
  endif(SAMBA_INCLUDE_DIR AND SAMBA_LIBRARIES)
  mark_as_advanced(SAMBA_INCLUDE_DIR SAMBA_LIBRARIES)
  ## end samba confiuration

I suspect this would work fine if it did something based on cmake's
pkg-config support instead.

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: Anti-feature: installing and replacing applications on update

2015-01-29 Thread Colin Watson
On Mon, Jan 26, 2015 at 04:29:12PM +, Bernie wrote:
 I think there is a development issue here. I ran:
 
 $ aptitude why nautilus
 i   accountsservice   Suggests gnome-control-center
 i A gnome-control-center  Depends  gnome-settings-daemon (= 3.7.91)
 i A gnome-settings-daemon Depends  nautilus-data (= 2.91.3-1)
 i A nautilus-data Suggests nautilus
 
 (I already uninstalled nautilus, so it stops there.)
 
 The development issue, as I see it, is that accountsservice suggests
 gnome-control-center on a system which doesn't have gnome installed. This
 is the first time I've read `aptitude why` output so I could be wrong but
 it seems  that Ubuntu is somewhat too eager to install auxiliary packages.

Suggests never cause packages to be installed by default.  They're
essentially informational.

 PS why does nautilus-data suggest nautilus? Isn't that like feet suggesting
 legs?

Enhances would probably be a marginally better field to use, but since
it's informational it doesn't really matter that much.

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: Bug #518056 in Launchpad

2015-01-24 Thread Colin Watson
On Sat, Jan 24, 2015 at 12:04:18PM -0200, Raphael Calvo wrote:
 I made a brief research through Ubuntu's documentation and I think the
 affected packages are:
 ubuntu-keyboard-portuguese
 ubuntu-keyboard-spanish
 ubuntu-keyboard-english
 ubuntu-keyboard-french

This seems unlikely, as those packages are on-screen keyboard packages
specific to the Unity 8 desktop and are probably not installed on your
system.

The bug was formerly marked as affecting gtk+2.0, but was changed to
just Ubuntu without an explanation of why in the accompanying comment
#38.  I've reverted that change.

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: dpkg packaging problems

2015-01-02 Thread Colin Watson
On Fri, Jan 02, 2015 at 06:16:17PM +0100, Enrico Weigelt, metux IT consult 
wrote:
 On 02.01.2015 17:08, Martin Pitt wrote:
  Yes, man dh_fixperms. Shared libraries don't need to and should not be
  executable. 
 
 Oh, wasn't aware of that. Just used to that as gcc sets that flag.
 Is it a bug in gcc, or are there platforms where +x is required ?

https://unix.stackexchange.com/questions/40587/why-are-shared-libraries-executable
reports it as being necessary on HP-UX.  It's indeed not needed on Linux
except for the odd special case, though.

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: ASUS T100 with 64-bit Ubuntu

2014-11-19 Thread Colin Watson
On Tue, Nov 11, 2014 at 12:55:34PM +, Matt Fleming wrote:
 Has anyone looked into enabling CONFIG_EFI_MIXED for 64-bit kernels?

This is already enabled in our current kernels.  (And thanks for adding
this option!)

 This kernel config option allows CPUs that support 64-bit long mode but
 ship with a 32-bit UEFI firmware (such as the ASUS T100) to run a 64-bit
 kernel, with the necessary thunking taken care of whenever firmware
 calls are required.
 
 To get this working out of the box, it'd be necessary to ship a 32-bit
 EFI boot loader as part of the 64-bit installation media. Apart from
 that, once the kernel is booted, the existing 64-bit userspace should
 work fine.

I posted a list of what I think we need to do here:

  https://bugs.launchpad.net/ubuntu-cdimage/+bug/102/comments/86

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: root and capabilities list

2014-10-19 Thread Colin Watson
On Wed, Oct 15, 2014 at 05:11:47AM +0400, ds wrote:
 Anyway, there is another part, reading the msr and cpuid. For that,
 it seems to be really beneficial, to make it available to everyone.
 So the process which needs it, can only live with limited
 CAP_SYS_RAWIO powers.

CAP_SYS_RAWIO is somewhat scary on its own, of course, because it's used
in all kinds of places.  Here's a pretty good summary:

  https://lwn.net/Articles/542327/

 It seem to me, that the root rights are there only because the
 capability system was introduced only a couple of years ago,

I think the more clearly-limited capabilities have slightly better
take-up in userspace than the very diffuse ones, although even then
there tend to be obstacles such as not quite all filesystems supporting
them, so in practice everyone ends up having to cope with both methods
of escalating privileges anyway.

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: root and capabilities list

2014-10-14 Thread Colin Watson
On Tue, Oct 14, 2014 at 10:44:26PM +0400, ds wrote:
 On 14.10.2014 22:37, Martin Pitt wrote:
 Note that at least CAP_SYS_MODULE is equivalent to root (as you can
 load any local .ko which can then provide you with a backdoor into
 the kernel),
 
 I guess you have to put the .ko file at a protected place of
 filesystem for it to get loaded.

No, the init_module(2) syscall takes the module image as a buffer in
memory, and you can use that syscall if you have CAP_SYS_MODULE.

 And maybe it would even require recompiling kernel with your .ko in
 mind.

It is very unlikely that one would not be able to find some way to
escalate to root given the ability to construct an arbitrary kernel
module, without needing to recompile the kernel.  In general, once an
attacker can load kernel modules, you've already lost.  Martin's right -
CAP_SYS_MODULE is functionally equivalent to root.

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: Ubiquity Crashing with non-English Language Selections

2014-08-11 Thread Colin Watson
On Fri, Aug 08, 2014 at 02:35:23PM -0500, Jeff Hoogland wrote:
 We use the Ubiquity GTK frontend with my Ubuntu derivative Bodhi Linux.
 With the version of Ubiquity that ships with 14.04, we are currently having
 an issue where the installer randomly crashes when non-English languages
 are selected at the first screen.
 
 Does anyone have any idea how to:
 
 1.) Correct this issue (ideal)

Do you have crash logs?

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: Please somebody remove skype from partner repository, aka Bug 1280109

2014-08-10 Thread Colin Watson
On Sun, Aug 03, 2014 at 08:40:30AM +0200, T. Prost wrote:
 I'm stil on 4.0.0.8 but now wondering what stopped working - mine is
 still working. What parts of the protocol were updated ?

The old protocol was proprietary and unpublished, so you shouldn't
really expect us to be able to know details here, although it looks as
though the new protocol may be in a better state.
https://en.wikipedia.org/wiki/Skype_protocol appears to have some
details on this.

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: Please somebody remove skype from partner repository, aka Bug 1280109

2014-08-02 Thread Colin Watson
On Sat, Aug 02, 2014 at 08:50:05AM +0100, Gianfranco Costamagna wrote:
 I'll keep the question as simple as it is:
 skype stopped working because of some protocol updates, and needs an update.
 
 Nobody took care of updating it since 5 months.

It was in fact updated the day before you sent this mail.

  https://launchpad.net/ubuntu/+source/skype/4.3.0.37-0ubuntu0.12.04.1

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: Bash man page typo

2014-06-25 Thread Colin Watson
On Wed, May 28, 2014 at 09:11:54AM -0700, Evan Ostroski wrote:
 Sorry if this isn't the place for this, wasn't sure where to send
 this, and this list is listed as the package maintainer for bash in
 Ubuntu.

It would be best to file this as a bug report.  You can use ubuntu-bug
bash, or (since it probably doesn't need any particular system-specific
information) you could use this link:

  https://bugs.launchpad.net/ubuntu/+source/bash/+filebug?no-redirect

Thanks,

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: Launchpad Package Maintainer change

2014-04-16 Thread Colin Watson
On Wed, Apr 16, 2014 at 09:51:55AM +0200, Lanoxx wrote:
 who do I have to ask if I want to change the maintainer of a package
 that is registered in launchpad.
 
 The package in question is tilda:
 
 https://launchpad.net/tilda
 
 The registered maintainer is Ira Snyder who has not been maintaining
 the package for several years. I am the current debian maintainer and
 would like to take over the package.

https://answers.launchpad.net/launchpad can deal with reassigning
Launchpad projects.

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: GHC haskell support for arm64 and ppc64el

2014-04-05 Thread Colin Watson
On Fri, Apr 04, 2014 at 05:04:18PM +0100, Colin Watson wrote:
 At this point there is a pretty good chance that I'll be able to get
 arm64 GHC bootstrapped in the archive in time for 14.04.

  $ rmadison -s trusty ghc
   ghc | 7.6.3-9 | trusty/universe | source, amd64, arm64, armhf, i386, powerpc

The rest of the stack is building now; it'll fail on anything that
requires GHCi, of course, but that's a minority.  Thanks everyone
(especially Karel) for your help!

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: GHC haskell support for arm64 and ppc64el

2014-03-27 Thread Colin Watson
On Wed, Mar 26, 2014 at 10:34:04AM +, Gianfranco Costamagna wrote:
Seems that fedora is bootstrapping ghc for ppc64
http://pkgs.fedoraproject.org/cgit/ghc.git/log/?h=epel7
 
Revert bootstrap from ghc-7.4.2-11.2.fc19 x86_64 and ppc64epel7
use cpio --make-directories
install ghc-base.ppc64 on ppc64
bootstrap from ghc-7.4.2-11.2.fc19 x86_64 and ppc64
do you think it is enough for trying in ubuntu?

ppc64 (i.e. big-endian) isn't the same as ppc64el (i.e. little-endian).
The architecture isn't endian-switchable in userspace.  So no, I'm
afraid that doesn't help much; it still leaves us bootstrapping from
scratch.

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: GHC haskell support for arm64 and ppc64el

2014-03-06 Thread Colin Watson
On Wed, Mar 05, 2014 at 05:18:16PM +, Colin Watson wrote:
 The best information I can find is in
 https://ghcarm.wordpress.com/2014/01/18/unregisterised-ghc-head-build-for-arm64-platform/,
 which does suggest that there might be some hope, but it's not at all
 clear whether GHC will get beyond stage1 - it'll still have to go round
 some more to rebuild itself and we'd have to confirm that it can build
 other Haskell packages as well before uploading it.  To get started,
 I've uploaded an llvm-toolchain-3.4 change with the patch from LLVM HEAD
 referred to in that post, and then I suppose I can see if I can get our
 current package to bootstrap.

OK, I tried this.  The author of that post is evidently using something
newer than GHC 7.6, as the --enable-unregisterised configure option
doesn't exist in 7.6.  When I adjust for that, I quickly get:

  Unknown CPU aarch64

Looking at git master, even the GHC_CONVERT_CPU macro there doesn't
support aarch64 (== arm64).  So the author of that post is evidently
working with at least some patches that aren't in master yet.  After I
adjust for all that, I do get a ghc-stage1, but the build stops right
after that with:

  CROSS_COMPILE=aarch64-unknown-linux-gnu- inplace/bin/ghc-cabal configure 
--with-ghc=/home/cjwatson/ghc-arm64/inplace/bin/ghc-stage1 
--with-ghc-pkg=/home/cjwatson/ghc-arm64/inplace/bin/ghc-pkg 
--flag=include-ghc-prim --disable-library-for-ghci 
--with-hscolour=/usr/bin/HsColour --configure-option=CFLAGS= 
-fno-stack-protector--configure-option=LDFLAGS= -Wl,--hash-size=31 
-Wl,--reduce-memory-overheads   --configure-option=CPPFLAGS=
--with-gcc=/home/cjwatson/aarch64-linux-gnu-gccsysroot 
--configure-option=--with-cc=/home/cjwatson/aarch64-linux-gnu-gccsysroot 
--with-ar=/usr/bin/ar --with-ranlib=true --with-alex=/usr/bin/alex 
--with-happy=/usr/bin/happy -- dist-install libraries/ghc-prim
  Configuring ghc-prim-0.3.0.0...
  ghc-cabal: /tmp/28824.o: does not exist

And the suggested hello world test fails with:

  $ ../inplace/bin/ghc-stage1 --make HelloWorld.lhs
  
  HelloWorld.lhs:1:1:
  Could not find module `Prelude'
  Use -v to see a list of the files searched for.

I've left a comment on the ghcarm blog asking for more information on
the patch set they used.

I suspect this is doomed until upstream has better support, and in any
case the bootstrap is likely to be very painful until we're on 7.8
(which won't be until trusty+1) - I found with my abortive ppc64el
attempt that even getting the initial cross-build working was quite a
laborious exercise because of various errors in 7.6's build system.

This sort of thing is a real time-sink; it's a great way to heat my
study, but realistically I don't think it's really achieving a whole
lot.  I understand that you're enthusiastic about this, and thank you
for that, but please don't ask for GHC bootstrapping again unless you
can supply a tested recipe for getting to at least somewhat working
cross-compiled binaries, or can point to ghc binaries that other
distributions have got working on these architectures.  It's unlikely
that simply asking us to try again is going to help at this point.

Cheers,

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: GHC haskell support for arm64 and ppc64el

2014-03-05 Thread Colin Watson
On Wed, Mar 05, 2014 at 01:24:43PM +, Gianfranco Costamagna wrote:
 I write here to ask if is it possible to have haskell also in arm64
 and ppc64el
 
 the new 7.6.3-8 release should fix a random build failure on 64 bit
 architectures that was preventing ghc to build on s390x and similar.
 
 Now that this bug is fixed, is anybody planning to upload on those two
 archs?

That upload makes no difference.  It only affects *big-endian*
architectures, and both arm64 and ppc64el are little-endian.

I spent considerable time a while back trying to bootstrap ghc on
ppc64el and I'm afraid I got nowhere.  Realistically, in the absence of
a real Haskell expert interested in Ubuntu with access to this hardware,
the best bet may be to wait for some other distribution to bootstrap ghc
and then use their binaries to get started.  If you can find such
binaries lying around then please do let me know.

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: GHC haskell support for arm64 and ppc64el

2014-03-05 Thread Colin Watson
On Wed, Mar 05, 2014 at 04:55:08PM +, Gianfranco Costamagna wrote:
 Il Mercoledì 5 Marzo 2014 17:47, Colin Watson cjwat...@ubuntu.com ha 
 scritto:
 I spent considerable time a while back trying to bootstrap ghc on
 ppc64el and I'm afraid I got nowhere.  Realistically, in the absence of
 a real Haskell expert interested in Ubuntu with access to this hardware,
 the best bet may be to wait for some other distribution to bootstrap ghc
 and then use their binaries to get started.  If you can find such
 binaries lying around then please do let me know.
 
 Don't know, maybe the debian maintainer can help?

Kind of unlikely given that neither arm64 nor ppc64el exists in Debian
yet.  If it were bootstrapped in Debian then of course I'd have used
their binaries to get started.

 I was thinking more about arm64, is it difficult to bootstrap here?
 there was already support for armel and armhf, I don't think it is
 impossible to find a binary for it...

Really?  If you can find a binary then please do point me at it.
https://ghc.haskell.org/trac/ghc/ticket/7942 is still open upstream, and
I don't see anything in the usual candidates for this sort of thing
(Fedora, openSUSE, Gentoo).

The best information I can find is in
https://ghcarm.wordpress.com/2014/01/18/unregisterised-ghc-head-build-for-arm64-platform/,
which does suggest that there might be some hope, but it's not at all
clear whether GHC will get beyond stage1 - it'll still have to go round
some more to rebuild itself and we'd have to confirm that it can build
other Haskell packages as well before uploading it.  To get started,
I've uploaded an llvm-toolchain-3.4 change with the patch from LLVM HEAD
referred to in that post, and then I suppose I can see if I can get our
current package to bootstrap.

I'm not promising anything, though; ghc is one of the most difficult
packages in the archive to bootstrap from scratch.

Cheers,

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: Those extra packages on the live CD

2014-02-17 Thread Colin Watson
On Mon, Feb 17, 2014 at 04:26:26PM -0500, Tong Sun wrote:
 I have never taken a closer look at what's inside the Lubuntu CD, until now
 when I discovered that there is bunch of packages on the CD that is not
 packed in the filesystem.squashfs file. There are *quite* a few of them
 (ref 1).
 
 What's the purpose of having those packages loose on the disk instead of
 installing them and have them in compressed squashfs file?

They're installed conditionally depending on exactly what the installer
needs to do.

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: apt and pdiff files

2014-02-17 Thread Colin Watson
On Mon, Feb 17, 2014 at 09:10:52PM +0100, Mattia Rizzolo wrote:
 2) maybe we can change dinstall crontab to run every 2 hours, it's not
 such a loss from my point of view

Um, no.  We're trending towards making the publisher more frequent, not
less; it's incredibly useful when you're trying to iterate quickly on
deep build stacks and suchlike.

I'd like us to do pdiffs, but there's a bit of a shortage of
implementation time in the Launchpad team.

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: apt and pdiff files

2014-02-17 Thread Colin Watson
On Mon, Feb 17, 2014 at 10:52:04PM +0200, Marius Gedminas wrote:
 There are claims (from 2008!) that pdiffs only make things slower:
 http://blog.ganneff.de/blog/2008/09/01/pdiffs-1.html

apt recently saw some significant improvements to pdiff performance.
Posts from 2008 are unlikely to be applicable now.

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: GHC on ubuntu arm64 and ppc64el

2013-12-17 Thread Colin Watson
On Tue, Dec 17, 2013 at 10:34:52AM +, Gianfranco Costamagna wrote:
 I'm a little bit worried about arm64 and ppc64el because ghc is not
 built for them, since the package depends from itself and I think
 wihout any manual hint it will never be automatically built.
 
 I think you did something similar for gcc, since it should depend on
 itself too, anyway I don't know how to fix it, or how to help in
 fixing it.
 
 (should you copy the binary from a similar architecture or build a
 prior release before?)

We can manually bootstrap packages - that's not a problem.  However, GHC
hasn't yet been ported to arm64 upstream:

  https://ghc.haskell.org/trac/ghc/ticket/7942

ppc64el may be easier as GHC does have a port for ppc64, so it's
hopefully just a small tweak to handle the endian switch.  I'll worry
about that when the port has been alive for slightly longer than a
couple of days in Launchpad!

Cheers,

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: Ubuntu 14.04 LTS and wxwidgets3.0

2013-11-21 Thread Colin Watson
On Wed, Nov 20, 2013 at 10:50:21PM +, Gianfranco Costamagna wrote:
 I write here since wxwidgets3.0 has been released days ago, and it has
 been packaged and accepted in debian/new and unstable 4 days ago.
 http://packages.qa.debian.org/w/wxwidgets3.0.html
 
 Shouldn't it be automatically imported in ubuntu?

It hasn't been automatically imported because it takes over the
wx-common binary from wxwidgets2.8, which has Ubuntu-specific
modifications:

wxwidgets2.8 (2.8.12.1-14ubuntu2) trusty; urgency=low

  * disable disable_media_python.patch to add wx.media to python-wxgtk2.8
(LP: #1224528)

 -- Fabrice Coutadeur fabric...@ubuntu.com  Fri, 18 Oct 2013 20:29:34 +0200

wxwidgets2.8 (2.8.12.1-14ubuntu1) saucy; urgency=low

  * Merge from Debian unstable, remaining change:
- Disable bp-menubar-fix.patch.
  * All other changes have been applied in Debian.

 -- Dmitry Shachnev mity...@ubuntu.com  Fri, 23 Aug 2013 21:32:13 +0400

This means that a developer needs to resolve this situation manually,
either by uploading a version of wxwidgets3.0 with the necessary Ubuntu
changes applied, or by determining that all these changes have been
merged and performing a manual sync.

 Do you have any particular policy about LTS and/or new packages?

No; new packages that don't have a problem such as the above are
imported automatically.

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: Planning to create a new distro of Ubuntu.

2013-11-07 Thread Colin Watson
On Wed, Nov 06, 2013 at 02:13:21PM +0800, Ben Tinner wrote:
 On Mon Nov 4 12:41:29 UTC 2013, Daniel Holbach wrote:
 Are you planning to get the necessary packages into Ubuntu itself? That
 might help make maintenance a lot easier.
 
 The guys at MATE are currently attempting to upload the packages to Debian 
 but as of now there is little progress into it.
 
 The MATE repository have MATE packages for Ubuntu available, so I included 
 the MATE repo for the packages.
 
 Shall we pull all the MATE packages into the Ubuntu repo directly or we build 
 the sources ourselves?

It would be far superior to fix the problem with uploading to Debian
rather than working around it by uploading directly to Ubuntu or by
maintaining a separate repository.  Unless there is a *lot* of effort
available to deal with Ubuntu-local packaging, having the packages in
Debian as well generally yields better results.

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: dip: unused group but still available.

2013-09-12 Thread Colin Watson
On Thu, Sep 12, 2013 at 04:35:16PM +0200, Daniel Curtis wrote:
 It's very interesting, because on mentioned Wiki page we could
 read, that 'dip' group is unused in Ubuntu.
 
 * dip: Unused in Ubuntu, should just go away completely.

Groups in the global static range (0-99) are permanently allocated and
can never be removed, although of course we can stop using them.

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: Confusing about building OpenStack Packages?

2013-09-06 Thread Colin Watson
On Wed, Sep 04, 2013 at 11:23:13PM +0800, Ray Sun wrote:
1. In step 5, we already can generate the deb packages without '-S', but
why we finally use 'sbuild' to generate it? Is this only for signature?
2. What's the difference between 'bzr builddeb' and 'sbuild'?

The answer to both of these is the same: sbuild builds the package in a
clean environment with only the necessary build-dependencies installed,
which is much safer.  It also makes it feasible to build packages for an
Ubuntu release that doesn't match the one you're running on your
development environment.

I found the build scripts which jenkins used is located here:
~openstack-ubuntu-testing/openstack-ubuntu-testing, but when I try to run
any commands under bin, I always get:
 
root@demo:~/openstack-ubuntu-testing/bin# ./build-package
Traceback (most recent call last):
  File ./build-package, line 14, in module
from openstack_ubuntu_testing.build.component_build import 
 ComponentBuild
  File 
 /home/sysadmin/openstack-ubuntu-testing/bin/openstack_ubuntu_testing/build/component_build.py,
 line 11, in module
from schroot.executor import SchrootExecutor
ImportError: No module named schroot.executor

Good question.  I've been entirely unable to find this.  Adam, can you
clarify where this module comes from?

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: Reporting bugs directly to Launchpad?

2013-08-02 Thread Colin Watson
On Sat, Aug 03, 2013 at 12:17:23AM +0300, Simos Xenitellis wrote:
 On Sat, Aug 3, 2013 at 12:06 AM, Patrick Goetz pgo...@mail.utexas.eduwrote:
  I must have missed some new revision, as I no longer seem to be able to
  post bugs directly to launchpad.  I go to
 
 
  https://bugs.launchpad.net/**ubuntu/saucyhttps://bugs.launchpad.net/ubuntu/saucy
 
  and click on Report a bug on the top right hand side of the page. Rather
  than taking me to a bug report screen, this now takes me to an Ubuntu
  Documentation page 
  (https://help.ubuntu.com/**community/ReportingBugshttps://help.ubuntu.com/community/ReportingBugs
  ).
 
 The link for Report a bug takes you to
 https://bugs.launchpad.net/ubuntu/saucy/+filebug which then redirects to
 https://help.ubuntu.com/community/ReportingBugs
 It is obviously some bug or usability change.

This was changed years ago, with the aim of encouraging people to use
the ubuntu-bug tool.  There's documentation buried in ReportingBugs for
the rare cases where ubuntu-bug can't be used for whatever reason, but
if it's at all possible for you to use ubuntu-bug which attaches more
information for us, please do.

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: Launchpad builders problem

2013-06-25 Thread Colin Watson
On Thu, Mar 28, 2013 at 12:56:21PM +, Gianfranco Costamagna wrote:
 Hi all, I have already reported an issue with the builders page a
 while ago, the issue was intermittent, so nobody took care of it
 because it wasn't reproducible easily.
 
 From some hours the launchpad builders page says Forbidden
 https://launchpad.net/builders/
 
 Not allowed here
 Sorry, you don't have permission to access this page or the information in 
 this page is not shared with you. 
 You are logged in as LocutusOfBorg. 

I tracked down the underlying cause of this, and it should now be fixed
for good.

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: kexec and Grub

2013-02-06 Thread Colin Watson
On Tue, Feb 05, 2013 at 04:07:58PM -0500, John Moser wrote:
 Has anyone gotten Grub2 to load via Linux Kexec?  It used to be
 possible to kexec grub.exe for some reason.

kexec can boot multiboot images, according to kexec(8); so you should be
able to kexec core.img, which has a multiboot header.  I suggest trying
it first on a non-production system. :-)

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: APT and dpkg Translations

2013-02-04 Thread Colin Watson
On Tue, Jan 29, 2013 at 10:18:56AM +, Dmitrijs Ledkovs wrote:
 On 29 January 2013 10:00, Volkan Gezer vlkn...@gmail.com wrote:
  Should APT and DPKG translations be done from Debian or Launchpad?
 
 In Ubuntu it's part of the language packs.

No, apt and dpkg are explicitly excluded from language packs (see
pkgbinarymangler/striptranslations.blacklist) because their strings are
needed in the installer before language packs are installed.  Thus
translating them in Launchpad is effectively useless.

If you want translations for these packages to have any effect, they
should be done in Debian, even though there'll be some propagation time.

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: man types.h

2013-01-18 Thread Colin Watson
On Thu, Jan 17, 2013 at 02:05:47PM +0100, Lanoxx wrote:
 On 17/01/13 13:40, Oliver Grawert wrote:
 Am Donnerstag, den 17.01.2013, 13:11 +0100 schrieb Lanoxx:
 it seems that for solaris there exists a man page for types.h [1] but I
 could not find such a man page on ubuntu. Could someone give me a hint,
 why it does not exist or is the man page name just different on ubuntu?
 
 the manpage for types.h is in the manpages-posix-dev package, note that
 we dont install devleoper documentation by default ...
 
 Thanks, that was what I was looking for. Maybe you can make
 manpages-dev recommend this package, so it is automatically
 installed if developer manpages are installed?

The one in manpages-posix-dev is not really quite the same.  What that
documents is what POSIX guarantees of sys/types.h, not what the system
provides; so it won't tell you about any system-specific extensions,
some of which might be very important to you (e.g. large file support).

I think manpages-posix(-dev) are useful packages and I'm glad they
exist; but I also think they should only be installed when people
explicitly ask for them, because it's quite easy to miss the fact that
you're looking at a manual page which documents POSIX guarantees rather
than your actual system.

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: Discovering the package of an open window

2013-01-18 Thread Colin Watson
On Fri, Jan 18, 2013 at 11:32:16AM -0600, Michael Spencer wrote:
 Okay, that makes sense. What I'm trying to do is identify the package
 and then access the Launchpad entry for the package. But for example,
 Libreoffice seems to lump all the libreoffice packages into one
 Launchpad entry, https://launchpad.net/ubuntu/+source/libreoffice. Is
 there an easy way to find the Launchpad entry for a particular package?

Launchpad generally organises binary packages (e.g. libreoffice-core,
etc.) by the source package that built them (e.g. libreoffice).  The
Package: line of 'apt-cache showsrc BINARY-PACKAGE-NAME' shows you the
source package name.

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: man types.h

2013-01-17 Thread Colin Watson
On Thu, Jan 17, 2013 at 01:11:49PM +0100, Lanoxx wrote:
 it seems that for solaris there exists a man page for types.h [1]
 but I could not find such a man page on ubuntu. Could someone give
 me a hint, why it does not exist or is the man page name just
 different on ubuntu?

We don't tend to have manual pages for header files, only for the
functions they contain.  This is arguably a bit awkward for
sys/types.h which doesn't actually contain any functions.

I don't think it's a huge problem, though, since the dominating reason
why you might choose any given type from that header over any other one
would be because of its use in a library function, and there should be
manual pages for all the standard library functions which document the
types they're intended to take.

For documentation of the various system-specific conditional macros used
in sys/types.h, I recommend feature_test_macros(7) (or ftm(7) for
short).

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: auto generated menu.lst file contents

2013-01-07 Thread Colin Watson
On Fri, Jan 04, 2013 at 10:54:10PM +0500, Saqlain Abbas wrote:
 Alexander, once again thank you! You guided me to a new world :-), i
 download grub source code and update-grub command script tells whole story
 ;)
 
 # Title
 title=$(lsb_release --short --description 2/dev/null) || title=Ubuntu

Well, no, it doesn't tell the whole story regarding your question.  That
command says use what lsb_release --short --description says, and if it
returns an error then fall back to Ubuntu.  It does not explain why
you're getting Ubuntu after configuring lsb_release to say something
else.

I suppose it's possible that you could have misconfigured
/etc/lsb-release such that the lsb_release command fails with an error.

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: auto generated menu.lst file contents

2013-01-04 Thread Colin Watson
On Fri, Jan 04, 2013 at 02:10:55PM +0500, Saqlain Abbas wrote:
 I have customized Ubuntu distribution, along with several customization i
 have also changed distribution name, it works well. Currently I use this
 cutomized distro rootfs with Linux kernel  but whenever i do update-grub,
 the auto-generated menu.lst file do have original distro name, My question
 is grub read which file to determine distro name, as i want to customize it
 completely.

The very old version of update-grub you're using hardcodes it, so you'd
have to edit the update-grub script directly to fix this.  More recent
versions (anything from Ubuntu 7.10 onwards) pick up the title from
lsb_release.

 Sample snippet from auto-generated menu.lst file
 
 title Ubuntu, kernel 2.6.17-10-generic
 root (hd0,4)
 kernel /boot/vmlinuz-2.6.17-10-generic root=/dev/sda5 ro quiet splash
 initrd /boot/initrd.img-2.6.17-10-generic

You are using a dangerously old version of Ubuntu; that looks like
Ubuntu 6.10, which has been out of security support for nearly five
years and by now is very likely to be full of vulnerabilities.  Even the
version of Ubuntu that fixed the bug of not using lsb_release here has
itself been out of security support for nearly four years!  You should
upgrade to something very much newer at the earliest opportunity.

Cheers,

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: ubuntu core - kernel installation question

2013-01-04 Thread Colin Watson
On Wed, Jan 02, 2013 at 03:47:57PM +, Tim Verstraete wrote:
 I am evaluating ubuntu core 12.10 (this version because of touch
 screen support) and I am following
 https://wiki.ubuntu.com/Core/InstallationExample and up until the
 installation of the kernel everything is working (if I reuse a kernel
 installation from previous builds (my own builds) everything is fine)
 BUT when I want to install a .deb with the kernel selected from the
 packages list I get:
 
 root@ubuntu:/tmp# dpkg -i --force-all 
 linux-image-3.5.0-21-generic_3.5.0-21.32_amd64.deb

Never use --force-all.  It is very dangerous and is entirely capable of
accidentally trashing large swathes of your filesystem when a less
cavalier set of options would have produced a sensible error messages.
All the reasonable things you might want to force have much safer
alternatives.

[...]
 grep: /proc/cpuinfo: No such file or directory
[...]
 This is normal since we have no proc/cpuinfo ... how can I overrule
 this check on cpuinfo?

Is there any reason not to bind-mount /proc into your chroot?  We don't
support running very much without /proc in place, and certainly not
installing packages in general.

Cheers,

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: EFF Privacy; hopefully Ubuntu will listen to users

2012-11-07 Thread Colin Watson
On Mon, Nov 05, 2012 at 03:28:44PM +, J Fernyhough wrote:
 I'm currently looking into how Ubuntu meets the provisions of the Data
 Protection Act 1998, and more crucially what would need to be done to
 meet the requirements, so that I have some base of evidence and legal
 reasoning to put forward (for example, at no point in the download or
 installation process is it identified which information is being
 gathered, how it will be stored, by whom, how it will be used, or who
 to contact).

Not during installation, but I believe I've seen a Legal notice link
displayed somewhere in the Unity UI which has that information.
(Apologies for vagueness; I don't work on this stuff myself.)

 (As an aside, it appears that being only enthusiastic about Ubuntu and
 all decisions, or at least getting in line, is a requisite for
 employment there.)

I can only speak for myself and I don't do very much hiring nowadays
since I quit management, but this is certainly not true of the hiring
decisions I've made.  One of my routine interview questions is along the
lines of asking what we are doing wrong and how we could improve it, and
I give considerable weight to non-trivial answers; I've never been
interested in hiring yes-men, and I would probably mark somebody *down*
for being too uncritically enthusiastic (if we're so perfect, what are
you going to do for us then ...).

Of course, the how we could improve it bit is important; employees
need to achieve goals which often implies being pragmatic about how they
approach problems, and they don't necessarily have the luxury of going
in all guns blazing all the time.

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: DNS caching disabled for 12.10...still

2012-10-17 Thread Colin Watson
On Sun, Oct 07, 2012 at 01:13:14PM -1000, Paul Graydon wrote:
 If DNS caching is being disabled in dnsmasq, what value is being had
 from using dnsmasq by default with network connections?  Seems like
 it just presents another potential failure point.

For example, it allows changing nameservers reliably without having to
restart applications, and allows us to dispatch DNS queries on different
links depending on the domain (consider VPNs).

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: Why are there dependencies that aren't actually dependencies on some packages?

2012-10-04 Thread Colin Watson
On Tue, Aug 21, 2012 at 12:15:06AM -0500, Jordon Bedwell wrote:
 Since when does Brasero or other packages need/require
 liblaunchpad-integration-common to work properly, or they will
 suddenly fall to the ground and never work again.

Jeremy has already given you an answer that will probably be more to
your liking.  However, I'd like to point out that this aspect of the
package dependencies in precise is precisely correct given how the
binary is built.  Looking at /usr/bin/brasero in precise with 'objdump
-p', I see:

Dynamic Section:
...
  NEEDED   liblaunchpad-integration-3.0.so.1

Since this is a normal straightforward dynamic link, the binary
literally will not start without that library being present.  So feel
free to complain about the binary being built such that it's linked
against that library (and Jeremy's post completely addresses that for
12.10), but given that linkage the dependency is absolutely correct.

While it's possible to arrange things such that dynamically-linked
libraries are loaded conditionally at run-time, it's a fair bit of work,
rather cumbersome, and can often end up introducing bugs.  So, in the
case of a library whose total .deb size (liblaunchpad-integration1 +
liblaunchpad-integration-common) weighs in under 16KiB, we often don't
feel that it's worth making that kind of thing optional.  Of course I'm
glad to see it go since it makes it easier to stay in sync with Debian
and thus makes the system as a whole that bit easier to maintain.

Cheers,

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: Linux (or Ubuntu specific) tools to measure number of page faults

2012-05-02 Thread Colin Watson
On Tue, May 01, 2012 at 10:04:47PM -0400, Phillip Susi wrote:
 Note that you need to explicitly specify /usr/bin/time to prevent the
 shell builtin time command from being used, which is more limited.

Or 'command time'.

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: Recent OpenSSL update that breaks cloudfront and rubygems.org?

2012-04-20 Thread Colin Watson
On Fri, Apr 20, 2012 at 12:06:12PM -0500, Jordon Bedwell wrote:
 The recent update to OpenSSL in Precise has rendered cloudfront.com
 unusable (as well as several other hosts which people have noted
 throughout other various bugs -- the one I discovered was
 https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/986147).

I'm basically despairing about this since every time I touch OpenSSL to
try to fix one set of bugs it appears to break something else (and I
should add that I haven't been getting creative, and very much want
*not* to get creative, I've just been applying fixes from upstream).
Since I'm about to be diving head-first into release chaos, I strongly
encourage anyone who can to try to figure out a fix that doesn't cause
connection to the other sites we just fixed to regress!

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


Re: ld changed linking behaviour in precise?

2012-04-18 Thread Colin Watson
On Wed, Apr 18, 2012 at 04:29:15PM +0200, Stefano Rivera wrote:
 Hi Christoph (2012.04.18_16:18:18_+0200)
  The default of the linker flag --as-needed seems to be different
  compared to lucid and precise a few days ago.
 ...
  Assuming I diagnosed this correctly, was this change intentional?
 
 Yes, see
 https://wiki.ubuntu.com/OneiricOcelot/ReleaseNotes#GCC_4.6_Toolchain

... but not compared to precise a few days ago, as Christoph said.  As
far as I know, --as-needed has been in place for the lifetime of
precise.

-- 
Colin Watson   [cjwat...@ubuntu.com]

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


  1   2   >