Re: Missing t64 transitions
ork5 > libqt5serviceframework5t64 > src:qtsystems-opensource-src libqt5systeminfo5 libqt5systeminfo5t64 > src:qttools-opensource-src libqt5designer5 libqt5designer5t64 > src:qttools-opensource-src libqt5designercomponents5 > libqt5designercomponents5t64 > src:qttools-opensource-src libqt5help5 libqt5help5t64 > src:qtwayland-opensource-src libqt5waylandclient5 libqt5waylandclient5t64 > src:qtwayland-opensource-src libqt5waylandcompositor5 > libqt5waylandcompositor5t64 > src:qtwebengine-opensource-src libqt5pdf5 libqt5pdf5t64 > src:qtwebengine-opensource-src libqt5pdfwidgets5 libqt5pdfwidgets5t64 > src:qtwebengine-opensource-src libqt5webengine5 libqt5webengine5t64 > src:qtwebengine-opensource-src libqt5webenginecore5 libqt5webenginecore5t64 > src:qtwebengine-opensource-src libqt5webenginewidgets5 > libqt5webenginewidgets5t64 For Qt we decided in Debian [1] that package name change is needed only for qtbase, since every other Qt library depends on libqt5core5 or libqt6core6. Probably this approach can be extended to the most of KDE stack. [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1062946#10 -- Dmitry Shachnev signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Symbols files for C++ libraries for Ubuntu main
Hi Sebastien!
On Fri, Jun 09, 2023 at 02:27:02PM +0200, Sebastien Bacher wrote:
> 1. We added a symbols to libcupsfilters as part of the MIR promotion
> https://git.launchpad.net/ubuntu/+source/libcupsfilters/commit/debian/libcupsfilters2.symbols?h=applied/ubuntu/devel=c5821fe0
>
> The build failed on armhf because dh_makeshlibs report symbols on armhf
> which do not existing on amd64
> https://launchpadlibrarian.net/647850924/buildlog_ubuntu-lunar-armhf.libcupsfilters_2.0~b2-0ubuntu4_BUILDING.txt.gz
>
> which also included those types of changes
>
> - _Znam@Base 2.0~b2-0ubuntu3
> + _Znaj@Base 2.0~b2-0ubuntu4
> +#MISSING: 2.0~b2-0ubuntu4# _Znam@Base 2.0~b2-0ubuntu3
>
> I personally don't understand why we have those symbols existing on armhf
> which don't exist on amd64. Nor why _Znam@Base is becoming _Znaj@Base nor
> how we are supposed to handle such cases
m vs. j is usually because of size_t type, which is equivalent to unsigned
long on 64-bit architectures and to unsigned int on 32-bit.
I can suggest using pkgkde-symbolshelper (adding ‘--with pkgkde_symbolshelper’
to dh and running ‘pkgkde-symbolshelper batchpatch *.build’). That tool will
automatically detect this difference, replace the symbol with _Zna{size_t},
and that will work on all architectures. See [1] for details.
[1]: https://qt-kde-team.pages.debian.net/symbolfiles.html
Alternatively, you can put this manually in your symbols file:
(arch-bits=64)_Znam@Base 2.0~b2
(arch-bits=32)_Znaj@Base 2.0~b2
--
Dmitry Shachnev
signature.asc
Description: PGP signature
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Ubuntu Focal update of broken Calibre package
Hi James! On Tue, Dec 22, 2020 at 06:11:15PM -0700, James Cuzella wrote: > Yes! Qt5 is indeed a very large project too! I'm sure there is a Lord of > the Rings meme that applies here like: "One does not simply backport Qt5" This is true :) > Simply using the backportpackage tool on qtwebengine-opensource-src started > a build dependency hunt that resulted in finding a massive set of Qt5 > packages that needed to be backported (without relaxing version > constraints). > A lot of these eventually resolved into being blocked on circular > dependency chains. > > I was able to spend a few hours on this to visually represent what I found > (See Gist linked below): > > https://gist.github.com/b005fa0ef6e600c6a6e0dfd22dd3e604 > > I'm not sure how the Debian or Ubuntu teams build and backport Qt5 packages > when so many build dependencies resolve circularly. > I suppose they must bootstrap this dependency chain somehow, but it seems > like more work than I have time to figure out at the moment. Yes, in Ubuntu we bootstrap the packages manually for every new Qt release. If you build packages locally, you can follow the instruction in qtbase's debian/README.source (I have just pushed a minor update for it): https://salsa.debian.org/qt-kde-team/qt/qtbase/-/blob/master/debian/README.source#L16 If you are pushing packages to a PPA, you can use the following procedure: - Push qtbase and qtdeclarative where the -doc and -doc-html packages, and also all Build-Depends-Indep are removed. - Push qttools with the same change, and additionally remove libqt5webkit5-dev build-dependency and make qwebview_archs empty in debian/rules. - Wait until qttools builds on amd64, then push the normal versions of all packages. In Debian this bootstrapping happens automatically because Debian does separate builds for "amd64" (arch-dependent) and "all" (arch-indep) architectures. Also keep in mind that if you update Qt, you will also need to do no-change rebuilds of packages that depend on qtbase-abi-5-x-y virtual package or on qtdeclarative-abi-5-x-y (usually these are packages that use private ABI). Otherwise they can stop working. -- Dmitry Shachnev signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Ubuntu on the M1 chip
On Fri, Dec 18, 2020 at 03:54:04PM -0700, Neal McBurnett wrote: > Is there any update on the prospects for native Linux on the M1, after > this article from the end of November? > > Linus Torvalds doubts Linux will get ported to Apple M1 hardware | Ars > Technica > https://arstechnica.com/gadgets/2020/11/__trashed-6/ Here is someone who started crowdfunding for porting Linux to M1 and already reached the kick-off goal: https://www.patreon.com/marcan https://twitter.com/marcan42 -- Dmitry Shachnev -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Ubuntu Focal update of broken Calibre package
Hi James! On Fri, Dec 11, 2020 at 08:43:16PM -0700, James Cuzella wrote: > I would appreciate any help with figuring out how to get that > last python3-pyqt5.qtwebengine package to be generated from the pyqt5 > source package. I'm assuming this is where it comes from, given that all > the other similarly named ones were generated from that one. Also, the > Debian package site shows this as the source package: > https://packages.debian.org/stretch/python3-pyqt5.qtwebengine It used to be built from pyqt5 source, but since then it got a new source package, pyqt5webengine: https://launchpad.net/ubuntu/+source/pyqt5webengine https://packages.debian.org/sid/source/pyqt5webengine -- Dmitry Shachnev signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Ubuntu Focal update of broken Calibre package
Hi Eli! On Wed, Oct 14, 2020 at 11:52:44AM -0400, Eli Schwartz wrote: > > This requires changes in many packages simultaneously: at least > > pyqt5, pyqt5charts, pyqt5webengine, qscintilla2, calibre, > > python-poppler-qt5, veusz, krita and qgis. > > > > I am planning to land this change early in Groovy+1 cycle. > > Just for the record, this is untrue. > > Arch Linux has built python3 PyQt5 using Sip 5 via /usr/bin/sip-build, > since Dec 13 18:01:34 2019 while continuing to build python2 PyQt5 using > Sip 4 via python2 configure.py > > This worked well enough that even though on Nov 24 20:33:38 2019 I began > shipping multiple repository packages for calibre -- one "calibre" > package built with python2 and one "calibre-python3" package built with > python3 -- both using Sip 4, they worked fine. The calibre-python3 > package was, as expected, buggy due to being beta quality, but it never > failed due to pyqt5/sip itself. > > There are still various packages in our distro archives building with > Sip 4 but successfully using the pyqt5 bindings built using Sip 5. > > Old versions of some of those packages (at least krita, qgis) did need > patches to change the location of the sip dir. > qscintilla2 did need to be rebuilt with no changes, then a week later > the 2.11.4 update moved to sip-build. > > It's plainly possible to mix them at least a little. From memory, we did > not even need to rebuild (most of) the packages. Most packages I mentioned will need a rebuild and a patch to use a different location for PyQt5 *.sip files. You can see this in Debian: after I uploaded new PyQt5 (built with SIP 5) to unstable, immediately some packages started to fail to build from source: - https://bugs.debian.org/971173 (krita) - https://bugs.debian.org/971217 (python-poppler-qt5) - https://bugs.debian.org/971172 (veusz) And packages that were not rebuilt got runtime errors: - https://bugs.debian.org/971538 (qgis) - https://bugs.debian.org/970921 (calibre) So what I said is true: this requires simultaneous changes in many packages, even if it's just a rebuild for some of them. > YMMV, but it should definitely be feasible to update pyqt5/sip5, test > everything that build-depends on them, and leave many of them alone if > they're not ready to move. Tomorrow is final freeze, so it is really bad timing for this. > not great, but workable: > > - Revert code in calibre to make it build with Sip 4 again, and package > calibre 5.2.0: > > https://github.com/kovidgoyal/calibre/commit/7a4b3f61ff24f8c39c8d5cf86c54da9de9267025 > > I suspect that last option would be the easiest resolution. It should work. That would be the easiest option, yes. I don't volunteer to work on this (no time, sorry), but I can sponsor an upload if someone gets a feature freeze exception for this and prepares/tests the upload. -- Dmitry Shachnev -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Ubuntu Focal update of broken Calibre package
Hi Norbert, Lukasz and all! On Wed, Oct 14, 2020 at 09:06:35AM +0900, Norbert Preining wrote: > Dear all, > > (please Cc) > > I am the Debian maintainer of Calibre, and unfortunately it seems that > for Focal Ubuntu has pulled a preliminary version of Calibre, which is > **seriously** broken and unusable, not even starting in most cases. > > We were forced by the Python3 transition to temporarily ship pre-release > versions of Calibre. In particular, Ubuntu Focal ships > 4.99.4+dfsg+really4.12.0-1build1 > which is version 4.12 with experimental Python3 patches on top of it. > This worked for a short time being until Calibre 5 was released with > proper Python3 support. > > Due to this unfortunate squeeze in release timing, Ubuntu Focal users > now have a seriously broken Calibre, and upstream is swamped with bug > reports. > > I would strongly suggest and support, and help preparing, an update to > Focal based on the current version in Debian/testing, 5.2.0+dfsg-1, > which has been out since quite some time and field-tested with Python3 > in various environments, due to upstream having switched to Py3, too. Unfortunately, Calibre 5.x requires SIP 5 and PyQt5 that is built against SIP 5. Moving PyQt5 to the new SIP is a major transition, that happened in Debian recently (two weeks ago) and did not happen in Ubuntu yet because of freeze. This requires changes in many packages simultaneously: at least pyqt5, pyqt5charts, pyqt5webengine, qscintilla2, calibre, python-poppler-qt5, veusz, krita and qgis. I am planning to land this change early in Groovy+1 cycle. > Is the above (update to 5.2.0) possible in Ubuntu Focal, and if yes, > what kind if steps are necessary? So for Focal and Groovy we need a version of Calibre that still uses SIP 4. Last such version in Debian was 4.99.12+dfsg+really4.23.0-1, Groovy already has that. If you know some specific fixes, maybe they can be applied on top of what Focal or Groovy has. -- Dmitry Shachnev signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Crash in Qt 5.12.2
Hi again Robert, On Fri, Oct 18, 2019 at 02:14:01PM +, Robert Loehning wrote: > Hi, > > every application based on Qt will crash when opening a crafted plain > text file. Could you please add the patch below to your builds to fix this? > > Thank you and have a nice weekend. Let me forward you a question I got on the bug: https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1848784/comments/1 This would appear to have security implications since I imagine if an email were sent to a KMail recipient which was crafted in this same way it would crash KMail? If this is likely true a CVE should be requested from MITRE via https://cveform.mitre.org/ so that other distros etc can ensure they ship this patch too. What do you think about this? -- Dmitry Shachnev -- 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: Crash in Qt 5.12.2
Hi Robert! On Fri, Oct 18, 2019 at 02:14:01PM +, Robert Loehning wrote: > Hi, > > every application based on Qt will crash when opening a crafted plain > text file. Could you please add the patch below to your builds to fix this? > > Thank you and have a nice weekend. Thanks for the heads up. I have just created a bug for this, and I will try to include this fix in my next upload for Ubuntu Bionic (18.04). https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1848784 Feel free to subscribe if you are interested in tracking the fix. -- Dmitry Shachnev signature.asc Description: PGP signature -- 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: arch triplet: "-" <> "_"
On Thu, Feb 28, 2019 at 03:11:35PM -0800, Steve Langasek wrote:
> No, since x86-64-linux-gnu is not a standard name for the architecture. I
> would suggest that you instead simply use the dh-exec substitution for the
> first part of the path, and a glob for the second:
>
> usr/lib/${DEB_HOST_MULTIARCH}/libpytalloc-util.cpython-37m-*.so.*
>
> That should minimize any false-positive matches of the glob.
I would suggest a correction that does not hardcode Python version (37m):
usr/lib/${DEB_HOST_MULTIARCH}/libpytalloc-util.cpython-3*.so.*
--
Dmitry Shachnev
signature.asc
Description: PGP signature
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: python3-numpy depending on *both* python 3.6 and 3.7
On Sun, Aug 26, 2018 at 10:01:38PM +1200, Michael Hudson-Doyle wrote: > So the problem is that python3-numpy contains a version of 'f2py' for each > supported version of Python. I guess the proper fix involves creating a > separate package for the each version of f2py? python3.6-f2py, > python3.7-f2py, and have python3-numpy depend on the one for the default > version of Python? This will mean having a new package name whenever we add a new supported Python version. It will be very inconvenient to maintain. Better remove the versioned scripts altogether and use “python3.x -m numpy.f2py” when one really needs a non-default Python version. -- Dmitry Shachnev signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Launchpad i386 build: Memory exhausted
On Wed, Mar 14, 2018 at 09:56:46AM +0100, Cesare Falco wrote: > I'm asking everyone for advice: assuming that no i386 build seems possible > any more, should I: > - stop maintaing Mame > - remove i386 from the supported archs > - ... (any suggestion is welcome here!) As Colin said, you should try to reduce memory usage by the linker. Try: - replacing -g with -g1 or maybe no debug symbols at all; - disabling caching of symbols tables (-Wl,--no-keep-memory); - adding -Wl,--reduce-memory-overheads. - switching to another linker (bfd vs. gold) if none of the above helps. Usually just using -g1 saves lots of memory. -- Dmitry Shachnev signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Resources on packaging.ubuntu.com getting 404 error
Hi all! Thanks to Simon Quigley, we now have the content of Ubuntu Packaging Guide cleaned and updated to the current development practices. However there is a problem with the index page, which is outside our control (not in Bzr). The problem is that the index page (http://packaging.ubuntu.com/) references many resources (CSS, JS, images) on http://developer.ubuntu.com/ which no longer exist there. Is it possible to make a 301 redirect from the index page to /html/ so that we can add all the needed information there? I think it would be the easiest solution. -- Dmitry Shachnev signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Status of Ubuntu Touch packages removal
On Tue, Jun 27, 2017 at 08:03:40AM -0400, Jeremy Bicha wrote: > Also see > https://code.launchpad.net/~xnox/ubuntu-seeds/unity8-removals/+merge/323615 As suggested by Michał Sawicz in that merge proposal, I tried to build qtbase with mirclient support. There is one problem with that: a circular dependency between qtbase and content-hub. I added libcontent-hub-dev to build-dependencies and that pulls in Qt packages. Does anyone know what was the plan to resolve this? -- Dmitry Shachnev signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Status of Ubuntu Touch packages removal
Hi all! Is it planned to remove Unity 8 and related packages (such as apps) from Artful, or the plan is to keep them in universe for some more time? We are currently working on updating Qt to 5.9 LTS, and two major things that concern us are: * ubuntu-ui-toolkit; * qtubuntu (the Qt MIR binding). Both of these packages are broken with Qt 5.9, and because they extensively use Qt private API, fixing them may be not easy. ubuntu-ui-toolkit is even in main because it is used by checkbox-converged. It would be really nice to get *at least* qtubuntu removed, if nobody is going to work on it. For ubuntu-ui-toolkit I guess the first step would be demoting it to universe by removing checkbox-converged from desktop (or porting it to some other toolkit like Qt Quick Controls 2). One more thing that concerns us is Oxide, but as I understand it is already getting removed as part of LP: #1688395. Any thoughts / comments / objections? -- Dmitry Shachnev signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Hanging builds on s390x
On Wed, Jun 21, 2017 at 08:03:31PM +0300, Dmitry Shachnev wrote: > Hi all, > > We noticed that some of the Qt packages hang when their tests are run on > s390x. This does not happen on other architectures, and this does not happen > on Debian s390x buildds (and I cannot reproduce it on zelenka.debian.org). > > Examples of hanging builds: > > - > https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2819/+build/12754612 > - > https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2819/+build/12758700 > - > https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2819/+build/12754642 > - > https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2819/+build/12784776 Small correction: third link in this list is a bad example (there is a real failure there). Links 1, 2 and 4 are good examples. -- Dmitry Shachnev signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Hanging builds on s390x
Hi all, Simon Quigley and I are currently working on Qt 5.9 transition in a PPA [1]. We noticed that some of the Qt packages hang when their tests are run on s390x. This does not happen on other architectures, and this does not happen on Debian s390x buildds (and I cannot reproduce it on zelenka.debian.org). Examples of hanging builds: - https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2819/+build/12754612 - https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2819/+build/12758700 - https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2819/+build/12754642 - https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2819/+build/12784776 The last one is still running, however the build log indicates that it hanged *after* the tests have finished, so it should not be a bug in Qt code. Has anybody else seen such issues? If no, maybe some buildd admin can investigate what happens there? [1]: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2819 -- Dmitry Shachnev signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Status of Ubuntu Packaging Guide
Hi all, There are many problems with the current state of our Packaging Guide [1]: * Half of it talks about Ubuntu Distributed Development, which is no longer a living thing. * Another part is a bit outdated, as it is mostly unmaintained, while our tools and methods continuously evolve. Also that other part is mostly redundant, as the Debian documentation talks about the same things. * There are 63 bugs [2] at the moment, and almost nobody looks at them. Daniel Holbach who was one of the main contributors, left Canonical [3] in December, and since then we had almost no changes apart from translations (except for two Laney’s fixes — thanks!). Unless someone wants to take this project over, I propose the following: * Remove ubuntu-packaging-guide package from Debian and Ubuntu archives. * Turn the current website into a collection of links to other resources (i.e. those from [4]). Opinions? [1]: http://packaging.ubuntu.com/html/ [2]: https://bugs.launchpad.net/ubuntu-packaging-guide [3]: https://daniel.holba.ch/blog/2016/12/taking-a-break/ [4]: http://packaging.ubuntu.com/html/#further-reading -- Dmitry Shachnev signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Keyboard layout switching in modern Ubuntus
On Wed, May 03, 2017 at 01:25:00AM +0300, Nrbrtx wrote: > > A better mailing list for questions related to GNOME Flashback sessions > > would be gnome-flashback-l...@gnome.org. But in this case I will help you > > here too. > > GNOME community seems to be unfriendly. No. At least not on that mailing list. > > It is possible. I have just tested the Ubuntu 16.04.2 live image and > > setting the “Switch to next source” to “Alt+Shift L” in > > unity-control-center works for me. > > It works in Unity session, but not in GNOME FlashBack. Shortcut is set, but > not usable. Have you set it like in my screenshot? There should be no differences between Unity and GNOME Flashback sessions in Ubuntu 16.04: both are using unity-settings-daemon, unity-control-center and indicator-keyboard. If there are differences for you, you must be doing something wrong. In particular, please make sure that gnome-settings-daemon is not running and “gsettings get org.gnome.gnome-flashback input-sources” is false. > > From testing the same Ubuntu 16.04.2 live image: if I type “apt-get install > > gnome-session-flashback”, nothing pulls in gnome-control-center. > > I tried from mini.iso. It seems that indicator-bluetooth requires > unity-control-center. > I just tried to install gnome-session-flashback on Ubuntu MATE 16.04. > It has both unity-control-center and gnome-control-center. I'm able to set > <Alt+Shift>, but it does not work. As I said: the GNOME Flashback packages do not pull in gnome-control-center on 16.04. You should be able so safely remove it. -- Dmitry Shachnev signature.asc Description: PGP signature -- 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: Keyboard layout switching in modern Ubuntus
Hi Norbert! On Tue, May 02, 2017 at 12:40:49AM +0300, Nrbrtx wrote: > Dear Ubuntu developers! > > I have just upgraded my machines from 12.04 to 14.04. You may want to upgrade further to 16.04 or 17.04 (if this is not a typo). > After upgrades I discovered that there are some issues with keyboard layout > switching. > I have two keyboard layouts - English and Russian. > I prefer to install GNOME FlashBack session into normal Ubuntu (Unity) > flavor. A better mailing list for questions related to GNOME Flashback sessions would be gnome-flashback-l...@gnome.org. But in this case I will help you here too. > [...] > My questions are: > 1. Is it possible to use <Alt+Shift> as keyboard layout switcher in GNOME > FlashBack sessions? It is possible. I have just tested the Ubuntu 16.04.2 live image and setting the “Switch to next source” to “Alt+Shift L” in unity-control-center works for me. > 2. Do you plan to fix <Ctrl+Shift+key> interference? It should be already fixed. Please test if it occurs in Ubuntu 17.04. > 3. Why we have both gnome-control-center and unity-control-center on simple > system with GNOME FlashBack? You do not need both. On Ubuntu 16.10 and older, the GNOME Flashback session is using unity-control-center. On Ubuntu 17.04 and newer, it is using gnome-control-center. From testing the same Ubuntu 16.04.2 live image: if I type “apt-get install gnome-session-flashback”, nothing pulls in gnome-control-center. > 4. What is the future of unity-control-center? I think it will receive only critical fixes, like Unity itself. Do not expect any new features there. -- Dmitry Shachnev signature.asc Description: PGP signature -- 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: pkgstripfiles killed during build
Hi Dann, On Mon, Mar 13, 2017 at 11:12:23AM -0600, dann frazier wrote: > Dmitry, > Just a guess - but maybe the build has exhausted the builder's > memory? If so, you might be able to workaround it by restricting the > parallel level. I can't offer an explanation as to why it started > occurring with this upload. Assuming nothing about the builder memory > config has changed, you might need to compare memory usage profiles w/ > an older build environment to look for red flags. Looks like you are right. I managed to reproduce this locally, and I get this: [15746515.856452] Out of memory: Kill process 2148 (sed) score 553 or sacrifice child [15746515.857476] Killed process 2148 (sed) total-vm:1180204kB, anon-rss:1167084kB, file-rss:0kB FWIW, the sed script is 2.6M and 13692 lines, and DEBIAN/md5sums is 3.2M and 29035 lines. However I do not understand what ‘parallel level’ you are talking about. If it is the package build parallel level, then it is unrelated — what gets killed is a single sed command (“sed -i -f $sedscript DEBIAN/md5sums”). The only workaround I can apply is disabling the PNGs compression by exporting NO_PNG_PKG_MANGLE=1. -- Dmitry Shachnev signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
pkgstripfiles killed during build
Hi all, I get a strange error with “mathjax” package on Ubuntu buildds. One of the binary packages (fonts-mathjax-extras) contains a lot of small PNG files. And with the last upload (2.7.0-2) I get this [1]: pkgstripfiles: Running PNG optimization (using 4 cpus) for package fonts-mathjax-extras ... [...] .o...o.o..o..ooo...o.ooo.o.oo.ooo..oo.....o...o..o...oo.o.ooo..oo.o..oo..oo..o.oo.o...o /usr/bin/pkgstripfiles: line 63: 21195 Killed sed -i -f $sedscript DEBIAN/md5sums dh_builddeb.pkgbinarymangler: dpkg-deb --build debian/fonts-mathjax-extras .. returned exit code 137 dpkg-genchanges --build=any,all -mLaunchpad Build Daemon <buildd@lgw01-10.buildd> >../mathjax_2.7.0-2_amd64.changes dpkg-genchanges: info: binary-only upload (no source code included) dpkg-genchanges: error: cannot fstat file ../fonts-mathjax-extras_2.7.0-2_all.deb: No such file or directory dpkg-buildpackage: error: dpkg-genchanges gave error exit status 2 I tried retrying the build a couple of times, it did not help. With the previous upload (2.7.0-1) it was fine [2], and the last upload did not make any changes to the PNG files. Does anybody know why this may be happening? [1] https://launchpad.net/ubuntu/+source/mathjax/2.7.0-2/+build/12082749 [2] https://launchpad.net/ubuntu/+source/mathjax/2.7.0-1/+build/11121087 -- Dmitry Shachnev signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Only one qt version on the Ubuntu Desktop iso?
On Fri, Mar 18, 2016 at 03:26:53PM -0400, Michael Hall wrote: > I know that appmenu-qt technically depends on qt4 being installed, but > if it will only be used by a qt4 app, and such an app would itself > depend on the qt4 packages, would there be any harm in making appmenu-qt > just *not* depend on qt4 packages itself? This will do the trick. But then we'll need to add this hack to both appmenu-qt and libdbusmenu-qt… Thinking more about it: sni-qt is quite critical because Unity has no fallback X11 tray, and thus apps that use QSystemTrayIcons will function improperly when sni-qt is not installed. But appmenu-qt is less critical, without it apps will just have in-window menu which is a slighly degraded experience, but will still work. So maybe we a Suggests for it will be enough (we can keep that Suggests on indicator-appmenu or move to libqtgui4, doesn't much matter). -- Dmitry Shachnev signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Only one qt version on the Ubuntu Desktop iso?
Hi, On Fri, Mar 18, 2016 at 06:21:04PM +0100, Sebastien Bacher wrote: > Hey there, > > The only reason the Xenial Ubuntu Desktop iso currently has qt4 still > included is because the "integration components for softwares using that > toolkit" are Recommends (appmenu-qt, sni-qt, fcitx-frontend-qt4). > > The default installation has no actual use for those but removing them > would mean that an Unity user installing some qt4 software wouldn't get > integrated menus/indicators/input method. > > We could make qt4 recommends them, but then they would be pulled in on > other desktops environment where they are not needed ... how would other > flavors feel about that? > If that's not an option does somebody have a better suggestion/idea how > we could get those installed for Unity users when required? > > Unsure if that's still something we might still want to do this cycle, > I'm at least mentioning it in case somebody feels like working on those > changes... sni-qt can definitely be a Recommends of libqtgui4, it is useful on other desktops too (i.e. Plasma or Xubuntu). fcitx-frontend-qt4: I don't think it has anything Unity-specific, and also most of the users don't need it, so can be a suggestion of libqtgui4. So we are down to appmenu-qt. It's tiny (the only non-Qt dependency is libdbusmenu-qt4) so probably it can be a recommendation of libqtgui4 too. -- Dmitry Shachnev signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Knocking Python 2 off the desktop iso
Hi Sebastien, On Tue, Mar 08, 2016 at 08:08:35PM +0100, Sebastien Bacher wrote: > Hey Barry, > > Le 08/03/2016 17:36, Barry Warsaw a écrit : > > I know this makes things less friendly for people who need Windows > > resources, > > but until Samba itself gets fully ported, our choices are rather limited: > > keep > > two Python stacks on the desktop image or provide a hook to install the > > required packages when needed. > > Do we plan to reduce/drop support for python2.7 if we get it out of the > iso? Or what's the direct result out of those efforts out of sending a > message and winning some CD space? In my opinion "sending a message" is a quite a big result. Currently even developers of new apps sometimes consider using Python 2 because it "works out of the box everywhere" unlike Python 3 (which may not be present on some old distros). If we ship LTS with Python 3 only, this will be no longer the case. I.e. it will make the world moving to Python 3 a bit faster. And the earlier the world moves to Python 3, the earlier we will be able to reduce/drop support for Python 2. -- Dmitry Shachnev signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Archive Reorg Episode VII: Follow Build-Depends
On Thu, Feb 11, 2016 at 12:36:27PM +0100, Matthias Klose wrote: > So an existing app package gains a new (universe) dependency on libfoo-dev. > Builds fine, maybe migrates, and then image builds fail because of the > libfoo1 component mismatch. Now you can either pre-promote the libfoo, or > re-upload app without the dependency (if that works). This probably will > lead to more pre-promotions, and looking at the current back-log of security > related MIRs the time between build and promotion will increase, making it > probably harder to revert such a change. Maybe we can teach Britney to not migrate the packages to release pocket if they are uninstallable within their component? This way almost nothing will change — just like now such packages will be stuck in proposed (the only difference is that they will build there). > I'm a bit worried that we'll then have to chase people to subscribe teams to > the new packages, write the MIR, ... We'll save some time by not processing > B-D only MIRs, but I think for the remaining MIRs we'll have to spend more > time. But on the other hand we'll have less MIRs for the build-dep-only stuff, which is quite common (i.e. the JS minifiers or documentation generators). > We unfortunately already have some kind of "dput and forget" attitude with > packages staying in -proposed. This change maybe will foster an > "pre-approve and forget" attitude. I think most of the packages stuck in proposed are auto-synced from Debian (I really hope that Ubuntu developers who upload their packages specifically to Ubuntu do care about the migration of them). In this case there is almost nothing we can do to improve that situation anyway… (maybe advertising the excuses page a bit more so that more people look at it?) In any case, I'm all for Dimitri's proposed change as it will allow us to get rid of lots of Debian delta and also stop doing strange tricks like one we did for jQuery to make it build. -- Dmitry Shachnev signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Launchpad invoking 64-bit programme in 32-bit build environment
On Tue, Feb 09, 2016 at 09:34:24AM -0500, Luís de Sousa wrote: > Build-Depends: debhelper (>= 8.0.0), cdbs, libpq-dev, libxml2-dev, clang, > qt5-qmake, qt5-default, qttools5-dev-tools, qt5-image-formats-plugins I haven't looked at the packaging, but please do not build-depend on qt5-default package. Export QT_SELECT=5 in debian/rules instead (as described in [1]). And the build-dependency on clang also looks strange to me. [1]: http://pkg-kde.alioth.debian.org/packagingqtbasedstuff.html -- Dmitry Shachnev signature.asc Description: OpenPGP digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Default languages strategy for Ubuntu desktop CD
Hi all, 2015-12-01 11:06 GMT+03:00 Didier Roche <didro...@ubuntu.com>: > 1. Install full language support for those shipped on xenial image. It means > that opening "language selector" won't request any additional package to > install[1]. If you are proceeding an online installation, additional > packages won't be downloaded to complete your language installation. If you > have done an offline one, you won't have the infamous after first boot > "Language support is not complete" dialog. Note that for now, we have no > complete language support on the live! For instance, in English, we have the > following missing packages that language-support will require to install (or > that ubiquity will download it for you if you are connected to the > Internet): > hyphen-en-us, mythes-en-us, mythes-en-au, hunspell-en-ca, myspell-en-au, > myspell-en-gb, myspell-en-za, libreoffice-help-en-gb, > libreoffice-l10n-en-za, firefox-locale-en, thunderbird-locale-en, > thunderbird-locale-en-gb, thunderbird-locale-en-us. > > 2. Based on popcon, number of native speaker and total number of speaker per > language, it seems that the following language selection makes sense for our > user base (more info on the language selection on > https://bugs.launchpad.net/ubuntu/+bug/1520278): > en, es, zh (simplified), pt, de, fr, it, ru In general I like this idea (especially when Russian is in the list of languages :)). Do we really need to include Chinese (simplified), provided that we have a separate spin (Ubuntu Kylin) for Chinese users anyway? Or are there use cases when one would prefer normal Ubuntu over Ubuntu Kylin? -- Dmitry Shachnev -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: gnupg 2.1.x by default
Hi Dimitri, On Sat, 11 Jul 2015 22:49:40 +0100, Dimitri John Ledkov wrote: I'd like to propose to switch to gnupg 2.1.x by default. [...] How does above plan sounds? Any comments / remarks / suggestions? I am now successfully running gpg2 by default on one of my laptops (first 2.0, then 2.1) for a couple of weeks. I fully support the switch because I got used to GNOME graphical password prompts, and they now no longer work with gpg 1.x. I had to fix some packages' configuration (mainly devscripts/debsign and git) because they use /usr/bin/gpg by default. python-gnupg does not currently support 2.1 (but supports 2.0), that is fixed in upstream hg and hopefully there will be a new release soon. -- Dmitry Shachnev signature.asc Description: OpenPGP digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: gnupg 2.1.x by default
Hi, On Thu, 20 Aug 2015 12:26:54 +0100, Dimitri John Ledkov wrote: cool, but it is feature freeze today. Yeah, I know that my reply was... a bit late :) So, i'll prepare a PPA for wily with 2.1 as default, and we will aim at 2.1 only for next cycle. This should give us plenty of time to prepare, and have e.g. gpg 2.1 as default at the Xanthous Xuangui opening. Sounds like a plan! We also have time to convince Debian maintainers for relevant packages to accept the gpg2-by-default switch. -- Dmitry Shachnev signature.asc Description: OpenPGP digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: libgit2
Hi, On Fri, 20 Feb 2015 12:00:17 +, Jonathan Riddell wrote: I'd say that makes it the responsibility of whatever team cares about libgit2-glib and gitg to sort. I'm happy to remove from the archive if that means we can get the newer version of libgit in. As far as I can see, both packages in question are coming unchanged from Debian. Have you tried contacting the respective maintainers in Debian? -- Dmitry Shachnev signature.asc Description: OpenPGP digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Qt 5.4 update (and call for testing), January 25
Hi Alberts, On Mon, 26 Jan 2015 09:33:54 +0100, Albert Astals Cid wrote: There's no unity8 bugs in that list, right? I mean I fixed all the ones that Timo found. Oh, you are right. I was confused by two bugs in qt5.4 list but they are Fix Committed, so should be no longer actual. -- Dmitry Shachnev signature.asc Description: OpenPGP digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Qt 5.4 update (and call for testing), January 25
Dear Ubuntuers, Today we have reached a point when our Qt 5.4 packages are finally built on all architectures — so I decided to post a quick update on the current Qt 5.4 status. Disclaimer: we are still far from “ready for being uploaded to vivid archive” state. That will happen only when Qt 5.4.1 packages are ready and all blocking bugs are fixed. Recent progress === * All the initial Qt 5.4 packaging was done by Timo Jyrinki. * qtwebsockets tests failure has been fixed, thanks to Helge Deller. * stellarium and qtserialport build failures have been fixed, thanks to Łukasz Zemczak. * some touch-related packages have been rebuilt against Qt 5.4 (Dmitry Shachnev, Łukasz Zemczak). * some Qt packages have been synced/merged from Debian experimental (Dmitry Shachnev). Known bugs == The full list of Qt 5.4 bugs is available at https://bugs.launchpad.net/ubuntu/+bugs?field.tag=qt5.4. The most important bugs are: * qtbase tests failures * ubuntu-ui-toolkit tests failures * unity8 behaviour bugs Help with dealing with all these bugs is always welcome. Updating to Qt 5.4 == The Qt 5.4 packages are available in ppa:ci-train-ppa-service/landing-005. These packages are unstable and may break your system. That PPA is regularly synced with archive, so that all packages there are re-built against Qt 5.4. Upgrade instructions for both mobile devices and desktop are available at https://wiki.ubuntu.com/Touch/QtTesting. Please test these packages and report any bugs you find (tagged with ‘qt5.4’ tag). -- Dmitry Shachnev signature.asc Description: OpenPGP digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: gnome-python - universe
Hi, On Sat, 6 Dec 2014 17:35:19 +, Dimitri John Ledkov wrote: Can we port compiz-gnome to using gsettings or something? Is it actually, in fact, use python-gconf? The only python code using gconf is migration scripts, and we can probably drop them as the gsettings migration happened in 2012. The truth is that ccsm still uses pygtk, but that is unrelated to your question. -- Dmitry Shachnev signature.asc Description: OpenPGP digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: QtWebSockets missing in Qt5.3
Hi, On Wed, Sep 17, 2014 at 3:53 PM, pwuertz pwue...@gmail.com wrote: Hi, I was looking forward to using the new QtWebSockets module included in the new Qt 5.3 release that is shipped in the upcoming Ubuntu 14.10 version. Unfortunately the QtWebSockets module is missing. Also the PyQt5.3.1 build in Ubuntu is missing websocket support. Is there any chance of getting a complete build of Qt5.3 for 14.10? Thanks I packaged qtwebsockets in Debian, and I think it may make sense to upload it to Utopic as well. I have filed a freeze exception bug at [1], and will upload this package if it is approved. [1]: https://bugs.launchpad.net/ubuntu/+bug/1370927 -- Dmitry Shachnev -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: How to promote package from proposed to release in utopic
Hi Cesare, On Fri, Aug 29, 2014 at 12:24 PM, Cesare Falco c.fa...@ubuntu.com wrote: Hello all, I uploaded the new version of Mame to utopic a couple of weeks ago, and still I can't see it in the release branch: https://launchpad.net/ubuntu/+source/mame (skip) - is the failing build on arm64 and ppc64el the issue? Yes, it is the issue, you need to fix the builds. You can always check what is the reason at http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html -- Dmitry Shachnev -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: What's the right way to get qmlscene to work out of the box?
I have a patch for this but it was not accepted upstream: https://codereview.qt-project.org/82702 Can you use absolute path to qmlscene? Or, better, to qml (which is a successor to qmlscene)? -- Dmitry Shachnev Am 23.06.2014 18:23 schrieb Sebastien Bacher seb...@ubuntu.com: Hey, Not sure if that has been discussed before, but current qmlscene doesn't work on our default installation. Just as an example; taking a trusty iso, enabling universe and installing ubuntu-ui-toolkit-examples leads to a non working gallery desktop entry ... the command is a qmlscene one, and running qmlscene returns an error about /usr/lib/.../qt4/qmlscene not existing. It's not because that binary is using qt5. That issue also leads to click packages to fail to run on the unity8-desktop iso, and I'm trying to see what's the right way to resolve it... I've discussed the topic a bit on IRC and the advices/replies include: - qmlscene is a dev tools and shouldn't be used by those applications - you should change the environment/export a variable to make qt5 the default (seems to be what ubuntu-touch does) - install qt5-default ... but that would bring some extra 50MB on the iso We could make unity8-desktop-session export the environment variable needed to have qt5 default, but that's a workaround and would mean those are still buggy. Is there any reason qtchooser doesn't check for available versions, and always prefer an installed one to the default if that one is not available? It feels like that would be the right way to handle the issue, but I might be overlooking something... One issue I can see, is that it would not resolve the case where qt4 binaries are installed but the application is a qt5 ... maybe it's a bug in the packaging of those applications and they should reference the qt5 binary rather than qtchooser un-versionned command? Opinions? Cheers, Sebastien Bacher -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Updating QtWebKit to 5.2
Hi all, I would very much like to update qtwebkit-opensource-src to version 5.2.0. It blocks syncs of other packages, like pyqt5, qtsensors-opensource-src and qtscript-opensource-src. It is also a prerequisite for updating Qt itself to version 5.3 (as qttools now depends on qtwebkit). According to Timo in https://code.launchpad.net/~mitya57/kubuntu-packaging/qtwebkit-merge-with-debian/+merge/216539: This looks it'd be great to have so I'm planning to build this for testing in addition to qtbase and qtdeclarative when U opens, but we need to check with webapps people (= dbarth, alex-abreu) on how they see this. I'm not clear on what's the schedule for full Oxide moving. In addition to touch also desktop is currently including libqt5webkit5 in default install still (checked with seeded-in-ubuntu qtwebkit-opensource-src). Does anybody know when it will be possible to upload this? I do not want to break Touch stuff, but I am already waiting for more than a month and don't want to wait more. -- Dmitry Shachnev -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Updating QtWebKit to 5.2
Hi Olivier, On Fri, May 30, 2014 at 2:26 PM, Olivier Tilloy olivier.til...@canonical.com wrote: As far as webbrowser-app is concerned, the transition to oxide is complete. The webapp-container still has a dependency on QtWebKit though, to catter for legacy webapps that use the 13.10 framework, as pointed out by Timo in the MR. I’d say all that’s needed is to thoroughly test existing webapps that still use QtWebKit. Is there a PPA we can use to test this new version? It is available in ppa:mitya57/test2 (for amd64 and i386). -- Dmitry Shachnev -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Point of reviews
On Fri, May 23, 2014 at 7:27 PM, Didier Roche didro...@ubuntu.com wrote: Since CI train packages are mostly Ubuntu specific (Qt5 is somewhat unique in this regard), I'd suggest those need review in New much more than the 75% of our packages we get from Debian unmodified that have already been through New there. This is the case since we had daily release and it's a bug/feature in Launchpad itself. Does this mean that anyone can bypass the NEW queue by uploading a package to any PPA and then copying it using copy-package? If yes, then I would consider it a security hole. -- Dmitry Shachnev -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Point of reviews
On Fri, May 23, 2014 at 8:01 PM, Scott Kitterman ubu...@kitterman.com wrote: Particularly since the list of people that can upload to the relevant PPAs is not constrained to Ubuntu developers. No, I meant: is it possible to bypass the queue with only relevant PPAs or with any PPA? -- Dmitry Shachnev -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Launchpad buildds and capabilities
On Sun, 9 Mar 2014 10:29:19 +, Colin Watson wrote: The plan is, and has been for some time, to convert the PPA builders to a specialised OpenStack cloud (scalingstack) rather than investing any more effort in the current setup. Quite a bit of work has gone into this by Canonical IS, but it's rather a complex project and is still in progress; I can't give an ETA, although we hope that we won't need to struggle along with our current setup for too much longer. In the long term, we'll probably end up with at least some of the distro builders moving into scalingstack as well, perhaps reducing the differences between the two pools. (After all, the builder pools are basically a rather stupid and not-very-scalable kind of cloud.) This won't happen until we've been running for a while with PPAs in the new system and are quite confident in it, though. Hi Colin, and thanks for the explanation. Is there any way to detect at build time if the builder supports capabilities, possibly in a way that will work with non-Launchpad setups? -- Dmitry Shachnev signature.asc Description: OpenPGP digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Patch pilot report [2014-03-12]
On Wed, 12 Mar 2014 16:05:19 +0100, Martin Pitt wrote: thanks to my fellow patch pilots the queue only had 37 items at the start of my shift today. So for the first time ever I was actually able to get done with the queue, there are now only 4 items left which are not actionable (FFE, needs fixing, or not uploadable by me). ♥ Thanks a lot for helping with the queue! -- Dmitry Shachnev signature.asc Description: OpenPGP digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Launchpad buildds and capabilities
On Sat, 8 Mar 2014 14:18:57 -0800, Steve Langasek wrote: You could help isolate whether this is a recent kernel/userspace compatibility regression by trying to build in your ppa for releases prior to saucy, which would have a different version of libcap-ng. Tried building on precise, got the same error: https://launchpad.net/~mitya57/+archive/test1/+build/5798722 -- Dmitry Shachnev signature.asc Description: OpenPGP digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Launchpad buildds and capabilities
Hi all, I am maintaining python-secretstorage package, and I would like to run gnome-keyring-daemon as part of the build process, to run the testsuite. However, I noticed that gnome-keyring-daemon fails to start in Launchpad buildd environment: gnome-keyring-daemon: error getting process capabilities, aborting This error message means that capng_have_capabilities() returns CAPNG_FAIL, which it turn likely means that the kernel has capabilities support disabled or broken. Is there any known workaround for that? Or, maybe, this can be fixed on Launchpad side? Note: I tried with PPA builders (elnath, marid and peryton to be specific), but I assume the archive builders behavior will be the same. -- Dmitry Shachnev signature.asc Description: OpenPGP digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Launchpad buildds and capabilities
On Sat, 8 Mar 2014 16:26:44 +, Dimitri John Ledkov wrote: You should convert the test to be an auto-package-test / dep8 test instead. This way it will not only run during build-time, but whenever any dependencies are updated. With dep8, it should be testing the system / as installed debs,binaries. Done, and it even works (except some random failure on ppc64el): https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-python-secretstorage/ I will consider the issue resolved now, though if someone comes up with a solution for running it during build, I will add build-time tests as well. Thanks, -- Dmitry Shachnev signature.asc Description: OpenPGP digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: On-demand starting/stopping of cups [was: [Blueprint client-1305-printing-stack-with-mobile-in-mind] Printing Stack with Mobile in Mind]
Hi, On Tue, Feb 4, 2014 at 2:18 PM, Oliver Grawert o...@ubuntu.com wrote: is it actually a less rare task on a desktop ? apart from a professional office desktop I'd say printing at home is nowadays nearly as rare from desktops as it might be from phones/tablets. I disagree, I print something from my (home) desktop every week. Also, for most printers you need to be connected with a wire to print something, which makes printing from phones/tablets quite difficult, if possible at all. -- Dmitry Shachnev -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: On-demand starting/stopping of cups [was: [Blueprint client-1305-printing-stack-with-mobile-in-mind] Printing Stack with Mobile in Mind]
On Tue, Feb 4, 2014 at 8:32 PM, Michał Sawicz mic...@sawicz.net wrote: Whoa now ;). This is a thread about CUPS, isn't it? It lets you do all that, and more. As long as you have the wire connected *somewhere* to CUPS (that something needs to be powered on to print, of course - not necessarily at the time of printing, though). That's why I said “difficult”, not “impossible”. To be honest, I know no people amongst my friends who do such things. But maybe that is because printing experience in Android/iOS is less optimal than in Ubuntu Touch :) -- Dmitry Shachnev -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: On-demand starting/stopping of cups [was: [Blueprint client-1305-printing-stack-with-mobile-in-mind] Printing Stack with Mobile in Mind]
On Feb 4, 2014 9:12 PM, Oliver Grawert o...@ubuntu.com wrote: so does every week mean once a week ? for that 10 mins you surely dont need to run the daemon for 7 days ... (even if you in summary spend 1h printing per week i would doubt it is worth running the daemon all the time) I meant at least once a week. i think it taking 30sec longer before it starts printing because the daemon startup takes that long is an acceptable thing unless the machine we talk about is a print server in an office where it should constantly run. Agreed. -- Dmitry Shachnev -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
qreal change in Qt 5.2
Hi, qreal is a Qt typedef that used to be defined as float on ARM and double on all other platforms. However, since Qt 5.2 release candidate 1, qreal is double everywhere (in Debian we are considering to keep it double on armel, but that isn’t relevant to Ubuntu). Please be prepared to update your packages if they rely on the old behaviour. We will probably need to do a transition (i.e. rebuild everything that has armhf binaries), however the problem is that upstream did not bump the SONAME of Qt libraries, so we are considering doing the bump as a Debian/Ubuntu-specific change. Feel free to express your opinion about (not) bumping the SONAME at http://bugs.debian.org/731261 (that bug also contains links to previous discussions on this subject). -- Dmitry Shachnev signature.asc Description: OpenPGP digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: qreal change in Qt 5.2
On Wed, 4 Dec 2013 13:58:49 +, Dmitrijs Ledkovs dmitrij.led...@ubuntu.com wrote: This has been discussed at the last vUDS: http://summit.ubuntu.com/uds-1311/meeting/21986/core-1311-qt5-versions-in-ubuntu/ https://blueprints.launchpad.net/ubuntu/+spec/core-1311-qt5-versions-in-ubuntu And it's agreed that we do want to take up the transition. My goal was to invite a broader set of people to that discussion (everybody who followed vUDS already knows about that). Also, IIRC, nothing was decided about the SONAME stuff (and I would really want if we got synchronized with Debian on (not)doing the bump). -- Dmitry Shachnev signature.asc Description: OpenPGP digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Giving developers access to requeue package imports [Was: Ubuntu Platform developers BOF session?]
Hi all, On Wed, Nov 13, 2013 at 9:39 PM, Andrew Starr-Bochicchio a.star...@gmail.com wrote: On Fri, Nov 8, 2013 at 1:33 PM, Andrew Starr-Bochicchio a.star...@gmail.com wrote: Though since we're talking about it, the one stop gap fix that would make me happy would be if all Ubuntu Developers could trigger the equivalent of the local 'requeue_package.py --full' command that UDD admins can run. Some history might get lost, but at least out of date branches could be made usable. This seems to have been the topic that has generated the most interest. It seems to be a bit of an overkill to have a vUDS session on it, especially if we don't have the right people in the room. So maybe we can try to hammer out the requirements here? Yes, that would be nice. For example, I think the only reason preventing me from doing a qt4-x11 merge is the non-working UDD branch for that package. -- Dmitry Shachnev -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Sponsoring: stagnating at 50
On Fri, 09 Aug 2013 17:43:35 +0200, Daniel Holbach wrote: It'd be fantastic if everybody with upload rights could go and have a look and either sponsor, review or reject some entries in there. If you need any decision making help, have a look at https://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews I've looked at most of the universe requests: lp:~vila/ubuntu/saucy/lxc/tyops: forwarded upstream lp:~redmar/ubuntu/saucy/unetbootin/fix-for-1206467: uploaded lp:~albertsmuktupavels/gnome-panel/fix-for-1196177: asked if that was forwarded upstream pad.lv/1208927: synced with additional change (ftbfs fix) pad.lv/1199037: already uploaded, unsubscribed sponsors Personally I would be very intersted if someone sponsored pad.lv/1180067. -- Dmitry Shachnev -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: non-Unity flavours and Mir
On Tue, 18 Jun 2013 00:28:49 -0400, Scott Kitterman wrote: I don't think there's anyone in the Kubuntu team with the skills to pick up on maintenance of the non-Mir display server stack [...] I think it is much easier to maintain Wayland stack in Ubuntu than port all DEs we support to Mir. As I can see from this thread, the “common” components used by flavors that will be patched to support Mir are Mesa, Upstart and LightDM. In Mesa, it will be just an addition of a new backend — that shouldn’t break anything. Speaking about Upstart, it should be able to start Wayland, Mir or X11 based on the system configuration — this is probably going to be implemented anyway to support two versions of Unity in Saucy. For LightDM, it will be more difficult to support running under different display servers, but given that KDE and GNOME have their own DMs, it shouldn’t be a problem. -- Dmitry Shachnev -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: xtables-addons 2.2-1 raring
Hi Pierre, On Sun, Jun 16, 2013 at 2:01 PM, Pierre Chifflier pol...@debian.org wrote: I'm sorry, but I am not the Ubuntu packager for xtables-addons (nor any other package, BTW). I see on [1] that my name appears, but in fact, I only upload to Debian, and somehow (?, cron job or whatever) and sometimes Ubuntu takes them. While I of course agree on the reuse of the Debian packaging, I would appreciate Ubuntu to change the name on the packages so my name does *not* appear. I think this is a bad thing, causing people to believe that I do not care of bug reports ([2] and others). As per the specification [1], we change the Maintainer: field for all packages that are changed in Ubuntu, but most of them come unchanged from Debian, and the original fields are used. We also encourage users to submit bugs to the BTS (probably we should do that better), but you can subscribe to bugs on a package page to receive bugs notifications — fixing bugs will make the package better in both Debian and Ubuntu. [1]: https://wiki.ubuntu.com/DebianMaintainerField [2]: https://wiki.ubuntu.com/StableReleaseUpdates -- Dmitry Shachnev -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: [Ubuntu-phone] Status of 100 scopes and touch landing to saucy
On Mon, Jun 10, 2013 at 10:19 AM, Robert Park robert.p...@canonical.com wrote: On Fri, Jun 7, 2013 at 10:35 AM, Stéphane Graber stgra...@ubuntu.com wrote: - MIR = Main Inclusion Request - Mir = The new display server I propose that we rename MIR to RIM: Request for Inclusion in Main. This will increase clarity. Please let’s not rename our procedures every time something with the same name is released. MIRing is used for a long time and documented in many places, and the Mir display server developers had plenty of time to choose a better name. -- Dmitry Shachnev -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: App installer design: only source packages or reproducible builds
On Sat, May 18, 2013 at 5:48 PM, Jeremy Bicha jbi...@ubuntu.com wrote: On 15 May 2013 16:41, Jos van den Oever j...@vandenoever.info wrote: 1) only ship source code and let the user compile Ubuntu is not Gentoo. Thanks, Jeremy I think most of Ubuntu Touch apps are supposed to be written in a language that doesn't require compilation, i.e. Qt Quick, or HTML+JS+CSS. In such case it may make sense to not distinguish between source and binary packages. -- Dmitry Shachnev -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Adding Spidermonkey 17esr to Raring
According to https://developer.mozilla.org/en-US/docs/SpiderMonkey, SpiderMonkey 1.8.5 is the most recent standalone source code release, and that's what we already have in Debian/Ubuntu (src:mozjs). I also don't see anything newer on their FTP. Are you sure there was a new *standalone* release? -- Dmitry Shachnev On 2/28/13, Tim t...@feathertop.org wrote: Hi, Finally after about 2 years Mozilla are releasing a version of the standalone spidermonkey engine. This release is based off the engine from Firefox 17esr. It has taken quite a long time to get to this stage, and I was hoping it would happen earlier in the cycle, but I would still like to get this into raring if at all possible. My motivation for this is the great improvements it brings to gnome-shell. This release fixes a number of high impact issues including greater performance, greatly reduces memory leaks, and finally solves the long standing and quite common issue with Garbage Collection deadlocks. I ported gjs to this engine a few months ago and while it hasnt landed upstream yet, the plan for 3.8 is to branch gjs and release 2 versions of gjs, one for each engine. This new gjs is API compatible with 3.6, and in fact works great with gnome-shell 3.6, so essentially it would be great to bring these improvements into raring. There are big API/ABI breaks in this release compared to previous 185 release. Currently none of the other rdepends have been ported as far as I know, and its probably not realistic to get all of them ported this cycle. Mostly the porting is easy enough, however it does result in quite large diff's so would really want to be done upstream, as it would probably be a nightmare to maintain these as Distro patches. Add to this CouchDB is fundamentally incompatible with this new release, due to their use of illegal javascript syntax (in 185 enforcement of this was optional) as a core feature of their user scripts. Given the above, replacing/upgrading the old package is simply not going to be feasible this cycle. I propose adding this new engine as an additional library, I discussed this on IRC a bit with seb128 and chriscoulson, however they were unsure about whether this is something that could want to go ahead and suggested that I raise it here for more widespread discussion. Main issues raised were overall its a low priority but also some security concerns. Hopefully now with all the patches on their way into the upstream mozilla code-base, future releases will be more regular, they will be tracking the firefox esr releases. Although not really guaranteed just yet, it is planned for some point releases over the life of each version. Probably issues with overlapping versions will continue to be a problem until the JS C API settles down, next release 24 will again break all rdepends. - Tim -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Adding Spidermonkey 17esr to Raring
Yes, a new source package (mozjs17) makes sense I think. As the current package is in sync with Debian, maybe it'll be a good idea to get the new one uploaded there, as well. -- Dmitry Shachnev On 3/6/13, Tim t...@feathertop.org wrote: Its currently at RC, due for release in the next few days. https://bugzilla.mozilla.org/show_bug.cgi?id=735599#c44 I have spent quite a bit of time, patching their build system etc, to make this happen, but still it has taken forever to get to this point. - Tim On 06/03/13 17:29, Dmitry Shachnev wrote: According to https://developer.mozilla.org/en-US/docs/SpiderMonkey, SpiderMonkey 1.8.5 is the most recent standalone source code release, and that's what we already have in Debian/Ubuntu (src:mozjs). I also don't see anything newer on their FTP. Are you sure there was a new *standalone* release? -- Dmitry Shachnev On 2/28/13, Tim t...@feathertop.org wrote: Hi, Finally after about 2 years Mozilla are releasing a version of the standalone spidermonkey engine. This release is based off the engine from Firefox 17esr. It has taken quite a long time to get to this stage, and I was hoping it would happen earlier in the cycle, but I would still like to get this into raring if at all possible. My motivation for this is the great improvements it brings to gnome-shell. This release fixes a number of high impact issues including greater performance, greatly reduces memory leaks, and finally solves the long standing and quite common issue with Garbage Collection deadlocks. I ported gjs to this engine a few months ago and while it hasnt landed upstream yet, the plan for 3.8 is to branch gjs and release 2 versions of gjs, one for each engine. This new gjs is API compatible with 3.6, and in fact works great with gnome-shell 3.6, so essentially it would be great to bring these improvements into raring. There are big API/ABI breaks in this release compared to previous 185 release. Currently none of the other rdepends have been ported as far as I know, and its probably not realistic to get all of them ported this cycle. Mostly the porting is easy enough, however it does result in quite large diff's so would really want to be done upstream, as it would probably be a nightmare to maintain these as Distro patches. Add to this CouchDB is fundamentally incompatible with this new release, due to their use of illegal javascript syntax (in 185 enforcement of this was optional) as a core feature of their user scripts. Given the above, replacing/upgrading the old package is simply not going to be feasible this cycle. I propose adding this new engine as an additional library, I discussed this on IRC a bit with seb128 and chriscoulson, however they were unsure about whether this is something that could want to go ahead and suggested that I raise it here for more widespread discussion. Main issues raised were overall its a low priority but also some security concerns. Hopefully now with all the patches on their way into the upstream mozilla code-base, future releases will be more regular, they will be tracking the firefox esr releases. Although not really guaranteed just yet, it is planned for some point releases over the life of each version. Probably issues with overlapping versions will continue to be a problem until the JS C API settles down, next release 24 will again break all rdepends. - Tim -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Let's Discuss Interim Releases (and a Rolling Release)
On Fri, Mar 1, 2013 at 11:08 AM, Stefano Rivera stefa...@ubuntu.com wrote:
Hi Scott (2013.03.01_06:55:18_+0200)
I fully agree, and this is not even limited to the kernel. There are
other kinds of major transitions like switching to a new X.org
server, preparing a new major Qt or GNOME release, new eglibc, etc. Or
we want to do a complex transition such as moving from ConsoleKit to
logind.
For those we'll need temporary staging areas which are not put into
the RR yet until they get a sufficient amount of testing; these could
be topic PPAs which interested people would enable and develop in,
which get landed into the RR when everything is ready?
For people or teams that are largely or entirely !canonical, this only works
if all you care about is x86 (i386/amd64). Anything for armhf (or powerpc)
would have to land untested since the PPAs that are available for !canonical
don't build these architectures.
It feels like an -experimental pocket would be the best solution here.
Which we would try to keep small, but could stage major transitions in.
SR
We must decide whether the rolling branch is for users/enthusiasts or
for developers only. If the latter (it's what most of us like), we are
*not* switching to rolling release model. We are just dropping non-LTS
releases.
In both cases, we should try to make it more stable than the current
raring is. My suggestions are:
- Auto-sync packages from Debian testing, not sid;
- Make -proposed → -release migration more clever (i.e. recursively
building all reverse dependencies, and running their autopkgtests, if
any) — not sure if it is already done;
- Create and use -experimental pocket (as suggested by Stefano) for
testing unstable changes and handling transitions;
- Maybe it'll make sense to freeze the archive for a couple of days
before every monthly snapshot (like we did for beta releases).
Also, if we are dropping non-LTS releases, we should make more use of
-backports. Some flavours ({K,L,X}ubuntu) may use it for providing the
latest stable versions of their desktops for LTS users, and other apps
that are not part of DE (from the USC top: Vlc, Clementine, Lightread)
should also be updated there. Core stuff like
GCC/Python/Glib/Gtk/kernel shouldn't be touched of course.
--
Dmitry Shachnev
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
PyBuild available in raring
Hi, I want to announce that my yesterday’s python3-defaults upload[1] made new “PyBuild” tool (developed by Piotr Ożarowski) available in raring. It allows one to easily build packages for both Python 2 and Python 3 (and also PyPy) by just passing `--buildsystem=pybuild` to debhelper commands, and is very configurable (it guesses supported interpreter versions by looking at Build-Depends). It also supports building extensions and can even run unit tests :) For details, please read Piotr’s original announcement[2] or the man page (HTML version is available at [3]). [1]: https://launchpad.net/ubuntu/+source/python3-defaults/3.3.0-2ubuntu5 [2]: http://lists.debian.org/debian-python/2013/01/msg9.html [3]: http://people.ubuntu.com/~mitya57/pybuild.html -- Dmitry Shachnev signature.asc Description: This is a digitally signed message part -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: PyBuild available in raring
Hi Colin, On Wed, Jan 25, 2013 14:45 +, Colin Watson wrote: This looks like a big improvement, thanks. However, is it intentional that it appears to install Python 3 modules to /usr/lib/python3.X/dist-packages/ by default, rather than /usr/lib/python3/dist-packages/? To reproduce, take germinate 2.12 and replace its debian/rules with: #! /usr/bin/make -f %: dh $@ --with python2,python3 --buildsystem=pybuild Then watch the build failure, preceded and caused by: dh_auto_install -O--buildsystem=pybuild ... running install running install_lib creating /«PKGBUILDDIR»/debian/tmp/usr/lib/python3.3 creating /«PKGBUILDDIR»/debian/tmp/usr/lib/python3.3/dist-packages According to Piotr, pybuild installs the files to /usr/lib/python3.*/, and then dh_python3 moves them to the usual location. So replacing `usr/lib/python3` with `usr/lib/python3*` in debian/python3-germinate.install should fix this issue. -- Dmitry Shachnev signature.asc Description: This is a digitally signed message part -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
