== Dev Week -- Packaging Mono for the great good -- directhex -- Mon, Jul 11th, 2011 == {{{#!irc [19:01] Logs for this session will be available at http://irclogs.ubuntu.com/2011/07/11/%23ubuntu-classroom.html following the conclusion of the session. [19:01] righty then. thanks to seb128 for his session there. [19:01] I'd like to apologise in advance if I appear to become unresponsive during this, as if my internet connection has dropped. it'll be because my internet connection has dropped. yay, adsl, etc. [19:02] my intention is to spend a few minutes first discussing mono and how it relates to ubuntu, in packaging terms. then ill go through a couple of example packages (sparkleshare, docky and keepass2 are my example packages, try to ensure you have the source packages and build-deps available if you want to follow along) [19:02] then end with a Q&A session [19:03] so. first things first. mono's a framework for developing apps in the same format as microsoft.net. same bytecode format, same class libraries, etc. this is possible because the bytecode and basic class libraries are an ISO standard that anyone can read through [19:04] mono packages have been available in ubuntu since forever. mono apps have been in the default ubuntu install for about five years - tomboy pretty much every time, and varyingly since then f-spot, gbrainy, and banshee. [19:05] there are about 120 packages in ubuntu which use mono in one form or another - about 40-50 applications, written in c#, and the rest are usually libraries (or C-based libraries offering a Mono interface, such as libubuntuone) [19:06] i'm one of the mono packagers in debian, and i also carry some responsibility for it in ubuntu - we try as far as humanely possible to do mono-related work in debian, then let that work trickle down into ubuntu, minimizing duplicated wotk [19:06] i also wrote the first version of the banshee plugin to access the ubuntu one music store (this has since been adopted by canonical developers) [19:07] why mono? because c# is a very easy language to develop with, whilst still reasonably performant - and it's also pretty lightweight compared to some of the competition. this makes it well positioned to offer an alternative to C, Python, Java, etc [19:08] and you'd be hard pressed to tell the difference between a Mono app written in C#, and a Python or C app, if nobody told you - when an app uses the GTK# framework for designing a GUI, it feels entirely "native", despite the app technically being a .exe file [19:09] note that mono (and .net) .exe files aren't windows (or wine) .exe files. microsoft just weren't bright enough to use a different file type when they wrote the standard. go figure. [19:09] hopefully people have already downloaded some or all of the example apps i mentioned on the UDW wiki - three apps you may or may not have heard off called docky, sparkleshare, and keepass2 [19:10] i think sparkleshare is in oneiric but not natty - don't worry about that one if you're not in oneiric [19:10] if you don't have them, remember you use "apt-get source packagename" to download and extract a source package to the current folder [19:11] and "apt-get build-dep packagename" to install the packages you need in order to compile that package [19:11] if you don't want to use a local install, let me grab a web link for the source packages [19:12] http://anonscm.debian.org/gitweb/?p=pkg-cli-apps/packages/sparkleshare.git;a=tree [19:12] http://anonscm.debian.org/gitweb/?p=pkg-cli-apps/packages/docky.git;a=tree [19:12] http://anonscm.debian.org/gitweb/?p=pkg-cli-apps/packages/keepass2.git;a=tree [19:13] there's the browsable sources for the three packages we're using, if you prefer a web browser [19:14] so, let's start things off by looking at docky. docky is an app providing a macos-style dock, for launching applications. it's a c# app, which began life as part of the gnome-do launcher, before being spun off as an independent project [19:14] as with any package, the structure is the same. the upstream source tarball, with an added "debian/" folder containing all the packaging metadata. take a look in debian/ [19:15] there are all the simple basic files in here. "compat" specifies the compatibility version which the debhelper package should use for package building commands (we use debhelper 7 extensively in the mono team) [19:16] watch is used for automatically scanning remote servers for package updates. the package maintainer gets an email when the watch file reports on new things. the "uscan" command uses the watch file - e.g. "uscan --report-status" tells me that "Newest version on remote site is 2.1.3, local version is 2.1.2" [19:16] so i guess i've got some work to do. or delegate to someone else, anyway. [19:17] copyright is what it sounds like. the changelog is what it sounds like, requiring standard debian packaging format changelogs. the dch command lets you edit changelogs (e.g. dch -i adds a new changelog entry) [19:18] the source/ folder contains a single file, format, which specifies the debian source format used by the package. we use "3.0 (quilt)" here, which automatically handles the content of the patches/ folder [19:19] and on a related note, patches/ contains changes to the upstream source which are required for the package to work (or make it work better). we have one minor fix, which ricotz probably rolled into 2.1.3, but we don't have her in 2.1.2 [19:19] this leaves the two most important files in a debian source package: control and rules. [19:20] control contains the package descriptions, including the dependencies and build-dependencies of the package. docky has quite a lot of build-dependeicies, as it uses a lot of gnome technologies. [19:21] if you look at the package dependencies section, around line 36, you'll see we only have on real dependency, on librsvg2-common [19:21] the rest are "substvars", i.e. when the package is compiled, they will be filled in with real values [19:22] so ${cli:Depends} is filled in by the dh_clideps command, which is executed during package compilation [19:23] which brings me to the final file, rules. debian/rules is a Makefile, which is called by the build commands run on the build servers, in order to build a package [19:24] we use the debhelper 7 format, which allows us to skip the "boring" parts of the file (these boring parts are automatically filled in by the "dh $@" lines at the bottom [19:24] we only do three things here which are any different from a C or C++ app using normal ./confgure and make [19:25] first, we have a line "include /usr/share/cli-common/cli.make" - this tells debhelper to read in the file /usr/share/cli-common/cli.make, which tells it to make changes to the normal sequence of events, and insert some extra ones, such as dh_clideps which builds dependencies on Mono libraries [19:26] look at /usr/share/perl5/Debian/Debhelper/Sequence/cli.pm to see how that happens [19:27] second, we override the "dh_auto_configure" command, and substitute our own version. our version adds an extra variable, redefining MCS. in this package, MCS is the C# compiler program's path. we override this, so we can easily change the c# compiler used (mono-csc is a symbolic link to the distro default compiler) [19:28] that way, if ./configure is searching for "gmcs" or "csc", it accepts our new truth and uses mono-csc instead. [19:29] third, we override dh_makeclilibs, the command which mono library packages use to say "i am a library, packages using me need to do XYZ", and tell it to exclude the usr/lib/docky folder. this is because docky isn't a library, and we don't want its own internal files being treated as distriwide libraries. [19:29] so, that's the whole package. if you run dpkg-buildpackage in there, it'll make a fresh .deb [19:30] if you have the sparkleshare source package, you'll see it looks exactly like docky - simple debhelper 7 format, using ${cli:Depends} for dependencies, etc. simple mono apps. [19:30] now, the last example is a complicated example. keepass2. [19:31] this is originally a Windows app - but its developers wrote it in such a way that it also works on Mac OS X and on Linux, via Mono. bug because it's a Windows app, its developers don't have linuxy things like ./confgure and make - instead, it uses Visual Studio.NET project files, and needs some manual cleaning up [19:32] if you look in the debian/patches folder for keepass2, you'll see a LOT of patches, doing various things - little tweaks here and there to make it behave better on Ubuntu [19:33] the debian/rules file is also much more complicated, as many steps usually handled by an automake makefile are done manually - e.g. putting an executable in /usr/bin or icons in the right places [19:33] rather than "make", we use "xbuild", which is a command to compile Visual Studio.NET project and solution files [19:34] we have a "install" file in debian/, which lists the files produced by the compilation, and where they should be installed to inside the package [19:35] since there's no "make install" to do it for us, it's done semi-manually via these files [19:36] the end result is a package whose contents are laid out in a "native" way - however, because keepass2 uses the System.Windows.Forms GUI toolkit rather than GTK#, it looks a bit pooey. [19:36] i guess that's the packaging walkthrough done. if you're in here, then you probably aren't ready to do a library package (those are more complicated to do) [19:37] and generally speaking, the right place to come and offer assistance is #debian-cli on OFTC, where we do packaging related discussion, including for ubuntu [19:37] now i'm going to open up the Q&A. bear with me whilst i try and wrangle classbot [19:38] sera asked: Which version of Mono will be available in Oneiric? [19:38] Oneiric will ship with Mono 2.10.1. [19:39] we're also taking the opportunity to rebuild the entire world using the 4.0 class library (.NET 4.0), replacing the 2.0 class library (.NET 2.0 -> 3.5) that's served us for the last few years [19:39] we always have only one "supported" runtime in releases, because otherwise the package dependency chain for high-level apps like banshee bloats up [19:40] once the transition is over, only 4.0 libraries will be installed by default, not a mix of 2.0 and 4.0 - and older apps are simply rebuilt for 4.0 (we even have old 1.0 apps that we;ve been rebuilding as 2.0 for a while) [19:40] .net generally has major class library versions - they avoid changing (and breaking) it, unless there's a real breaking change. they've only broken it twice so far - 2.0 and 4.0 [19:41] monodevelop will also default to 4.0 for new projects, in oneiric (barring an annoying bug i haven't found, which means the first time you run it, it defaults to 2.0). existing projects will cease to compile, unless you change the target framework version to 4.0, as the libraries you use like gtk# will also be 4.0-only [19:41] monodevelop 2.6 beta 3 is already in oneiric [19:42] okay, next [19:42] dell asked: please can you give the package name. I did not find it in UDW page [19:43] "docky", "sparkleshare" and "keepass2". sparkleshare is oneiric-only, don't worry about it if you're not on oneiric (or debian, i guess). keepass2 is in natty-backports, if memory serves. [19:43] bullgard4 asked: The Ubuntu programm is called KeePassX. Why do you call it »keepass2«? [19:44] KeePassX is a Qt (i think?) reimplementation of the original Keepass 1. Keepass 2 in Ubuntu is the "real" keepass2, as found on Windows, which is a .NET app. the packaging for this is done by jtaylor. [19:44] users are free to use their preferred app - i believe keepass2 has more features than keepassx, but looks kinda bad due to being a SWF app [19:44] bullgard4 asked: What does mean the phrase »for the greater good« in the headline: "Packaging Mono for the greater good"? [19:45] there are a few mono apps out there on the web, with home-grown packaging (i.e. which don't follow the packaging best practices from this talk). those packages tend to suffer somewhat as a result. the universe will be just that little bit better if more mono apps are packaged *well* [19:46] matteonardi asked: do you know if MonoDevelop is "good enough" for auto-generating autotools setups for simple projects? (I'm developing a simple checkers game with mono.. and after taking a look at autotools, I'd rather avoid them if possible!) [19:47] honestly, I don't know. i haven't used the autofoo integration much. from a packaging perspective, i know sources produced this way have some issues, which we need to patch in the packages. [19:48] given the maturity of xbuild, and that MD uses VS.NET project format as its own data format, i'd be inclined to use that - it also invites contributions from windows-based developers, since the same source can be compiled on windows easily, in vs.net or monodevelop or sharpdevelop, without needing cygwin or mingw [19:48] when i started using mono, we had neither autofoo integration nor xbuild. it was all manual. and all this was green fields ;) [19:48] bullgard4 asked: '/usr/local/src$ sudo apt-getsource keepassx; gpgv: Unterschrift kann nicht geprüft werden. Öffentlicher Schlüssel nicht gefunden.' Why can apt-get source not find the public key? [19:49] "apt-get source" uses your personal gpg keyring for verifying downloads. if you don't have the key in question in your personal keyring, then it'll throw an error. you can use "gpg --recv-key ABCDABCD" for the key id in question, to download & add it [19:50] bullgard4 asked: Why did you write the 1st version of the Banshee plugin to access the Ubuntu One music store in Mono and not in Python? [19:50] because banshee is a mono app - it made sense to make a mono app plugin in c# [19:50] There are 10 minutes remaining in the current session. [19:51] as it happens, most of the heavy lifting in that plugin is done by libubuntuone, which is a C library - but it offers a C# binding (i might have done that too, i don't remember). the only parts written in c# are linking the gtk+ events into banshee, and handling the library adding for downloading tracks [19:52] coalitians asked: I ram dpkg --build docky-2.1.2 but i get this error [19:52] dpkg-deb: error: failed to open package info file `docky-2.1.2/DEBIAN/control' for reading: No such file or directory [19:52] try dpkg-buildpackage. "dpkg --build" does something subtly different [19:53] sera asked: Are the difficulties in packaging Mono over? i.e. will we get Mono 2.12 in 12.04? [19:53] I can't make promises given 2.12 doesn't exist yet... i can say that uploads involving a transition (e.g. this 4.0 transition which is currently ongoing and about half complete) take MUCH longer than those without [19:54] mono's source package builds over a hundred binary packages - that's a lot of manual checking to do [19:54] there's also the time taken to make mono build on multiple architectures, update our ports (e.g. kfreebsd-amd64 in debian), and so on. it takes time [19:55] we have a new workflow which should allow for faster, more frequent uploads of new mono releases, but it's still largely dependent upon one person, who does this work in his spare time (and therefore it isn't reasonable to *demand* things from him). [19:55] There are 5 minutes remaining in the current session. [19:56] in my experience, a visit to the team's donations page (http://wiki.debian.org/Teams/DebianMonoGroup/DonationRegistry) and a donation to Mirco Bauer are an excellent way to get updates to Mono itself. although i think 2.10.1 is pretty final for oneiric (no 2.10.2, not worth it at this point) [19:56] bullgard4 asked: What IRC channel do you frequent? I am asking for the case that I have additional questions after having studied in full your lession. [19:57] #debian-cli on irc.oftc.net is the best bet. that's where mono-related things happen. [19:57] !q [19:57] bah. anyway, no questions in the queue? [19:57] 3 minutes remaining. ask anything [19:58] rww asked: What's your favorite colour? [19:58] bloo! [19:58] john_g asked: Maybe I missed this. What does cli mean in this context? [19:59] Common Language Infrastructure. it's a term used in the .NET standards documentation, without the trademark associations of "microsoft .net" [19:59] grungekid_ asked: What are the advantages of using mono over other languages such as python? Why do you choose to use it? [20:00] i personally deeply dislike python syntax - and c# tends to perform MUCH faster than python. it's good if you have a java background, syntacically [20:00] and i'm out of time. i'll finish questions in #ubuntu-classroom-chat [20:00] next up is... barry i think? [19:01] Logs for this session will be available at http://irclogs.ubuntu.com/2011/07/11/%23ubuntu-classroom.html following the conclusion of the session. [19:01] righty then. thanks to seb128 for his session there. [19:01] I'd like to apologise in advance if I appear to become unresponsive during this, as if my internet connection has dropped. it'll be because my internet connection has dropped. yay, adsl, etc. [19:02] my intention is to spend a few minutes first discussing mono and how it relates to ubuntu, in packaging terms. then ill go through a couple of example packages (sparkleshare, docky and keepass2 are my example packages, try to ensure you have the source packages and build-deps available if you want to follow along) [19:02] then end with a Q&A session [19:03] so. first things first. mono's a framework for developing apps in the same format as microsoft.net. same bytecode format, same class libraries, etc. this is possible because the bytecode and basic class libraries are an ISO standard that anyone can read through [19:04] mono packages have been available in ubuntu since forever. mono apps have been in the default ubuntu install for about five years - tomboy pretty much every time, and varyingly since then f-spot, gbrainy, and banshee. [19:05] there are about 120 packages in ubuntu which use mono in one form or another - about 40-50 applications, written in c#, and the rest are usually libraries (or C-based libraries offering a Mono interface, such as libubuntuone) [19:06] i'm one of the mono packagers in debian, and i also carry some responsibility for it in ubuntu - we try as far as humanely possible to do mono-related work in debian, then let that work trickle down into ubuntu, minimizing duplicated wotk [19:06] i also wrote the first version of the banshee plugin to access the ubuntu one music store (this has since been adopted by canonical developers) [19:07] why mono? because c# is a very easy language to develop with, whilst still reasonably performant - and it's also pretty lightweight compared to some of the competition. this makes it well positioned to offer an alternative to C, Python, Java, etc [19:08] and you'd be hard pressed to tell the difference between a Mono app written in C#, and a Python or C app, if nobody told you - when an app uses the GTK# framework for designing a GUI, it feels entirely "native", despite the app technically being a .exe file [19:09] note that mono (and .net) .exe files aren't windows (or wine) .exe files. microsoft just weren't bright enough to use a different file type when they wrote the standard. go figure. [19:09] hopefully people have already downloaded some or all of the example apps i mentioned on the UDW wiki - three apps you may or may not have heard off called docky, sparkleshare, and keepass2 [19:10] i think sparkleshare is in oneiric but not natty - don't worry about that one if you're not in oneiric [19:10] if you don't have them, remember you use "apt-get source packagename" to download and extract a source package to the current folder [19:11] and "apt-get build-dep packagename" to install the packages you need in order to compile that package [19:11] if you don't want to use a local install, let me grab a web link for the source packages [19:12] http://anonscm.debian.org/gitweb/?p=pkg-cli-apps/packages/sparkleshare.git;a=tree [19:12] http://anonscm.debian.org/gitweb/?p=pkg-cli-apps/packages/docky.git;a=tree [19:12] http://anonscm.debian.org/gitweb/?p=pkg-cli-apps/packages/keepass2.git;a=tree [19:13] there's the browsable sources for the three packages we're using, if you prefer a web browser [19:14] so, let's start things off by looking at docky. docky is an app providing a macos-style dock, for launching applications. it's a c# app, which began life as part of the gnome-do launcher, before being spun off as an independent project [19:14] as with any package, the structure is the same. the upstream source tarball, with an added "debian/" folder containing all the packaging metadata. take a look in debian/ [19:15] there are all the simple basic files in here. "compat" specifies the compatibility version which the debhelper package should use for package building commands (we use debhelper 7 extensively in the mono team) [19:16] watch is used for automatically scanning remote servers for package updates. the package maintainer gets an email when the watch file reports on new things. the "uscan" command uses the watch file - e.g. "uscan --report-status" tells me that "Newest version on remote site is 2.1.3, local version is 2.1.2" [19:16] so i guess i've got some work to do. or delegate to someone else, anyway. [19:17] copyright is what it sounds like. the changelog is what it sounds like, requiring standard debian packaging format changelogs. the dch command lets you edit changelogs (e.g. dch -i adds a new changelog entry) [19:18] the source/ folder contains a single file, format, which specifies the debian source format used by the package. we use "3.0 (quilt)" here, which automatically handles the content of the patches/ folder [19:19] and on a related note, patches/ contains changes to the upstream source which are required for the package to work (or make it work better). we have one minor fix, which ricotz probably rolled into 2.1.3, but we don't have her in 2.1.2 [19:19] this leaves the two most important files in a debian source package: control and rules. [19:20] control contains the package descriptions, including the dependencies and build-dependencies of the package. docky has quite a lot of build-dependeicies, as it uses a lot of gnome technologies. [19:21] if you look at the package dependencies section, around line 36, you'll see we only have on real dependency, on librsvg2-common [19:21] the rest are "substvars", i.e. when the package is compiled, they will be filled in with real values [19:22] so ${cli:Depends} is filled in by the dh_clideps command, which is executed during package compilation [19:23] which brings me to the final file, rules. debian/rules is a Makefile, which is called by the build commands run on the build servers, in order to build a package [19:24] we use the debhelper 7 format, which allows us to skip the "boring" parts of the file (these boring parts are automatically filled in by the "dh $@" lines at the bottom [19:24] we only do three things here which are any different from a C or C++ app using normal ./confgure and make [19:25] first, we have a line "include /usr/share/cli-common/cli.make" - this tells debhelper to read in the file /usr/share/cli-common/cli.make, which tells it to make changes to the normal sequence of events, and insert some extra ones, such as dh_clideps which builds dependencies on Mono libraries [19:26] look at /usr/share/perl5/Debian/Debhelper/Sequence/cli.pm to see how that happens [19:27] second, we override the "dh_auto_configure" command, and substitute our own version. our version adds an extra variable, redefining MCS. in this package, MCS is the C# compiler program's path. we override this, so we can easily change the c# compiler used (mono-csc is a symbolic link to the distro default compiler) [19:28] that way, if ./configure is searching for "gmcs" or "csc", it accepts our new truth and uses mono-csc instead. [19:29] third, we override dh_makeclilibs, the command which mono library packages use to say "i am a library, packages using me need to do XYZ", and tell it to exclude the usr/lib/docky folder. this is because docky isn't a library, and we don't want its own internal files being treated as distriwide libraries. [19:29] so, that's the whole package. if you run dpkg-buildpackage in there, it'll make a fresh .deb [19:30] if you have the sparkleshare source package, you'll see it looks exactly like docky - simple debhelper 7 format, using ${cli:Depends} for dependencies, etc. simple mono apps. [19:30] now, the last example is a complicated example. keepass2. [19:31] this is originally a Windows app - but its developers wrote it in such a way that it also works on Mac OS X and on Linux, via Mono. bug because it's a Windows app, its developers don't have linuxy things like ./confgure and make - instead, it uses Visual Studio.NET project files, and needs some manual cleaning up [19:32] if you look in the debian/patches folder for keepass2, you'll see a LOT of patches, doing various things - little tweaks here and there to make it behave better on Ubuntu [19:33] the debian/rules file is also much more complicated, as many steps usually handled by an automake makefile are done manually - e.g. putting an executable in /usr/bin or icons in the right places [19:33] rather than "make", we use "xbuild", which is a command to compile Visual Studio.NET project and solution files [19:34] we have a "install" file in debian/, which lists the files produced by the compilation, and where they should be installed to inside the package [19:35] since there's no "make install" to do it for us, it's done semi-manually via these files [19:36] the end result is a package whose contents are laid out in a "native" way - however, because keepass2 uses the System.Windows.Forms GUI toolkit rather than GTK#, it looks a bit pooey. [19:36] i guess that's the packaging walkthrough done. if you're in here, then you probably aren't ready to do a library package (those are more complicated to do) [19:37] and generally speaking, the right place to come and offer assistance is #debian-cli on OFTC, where we do packaging related discussion, including for ubuntu [19:37] now i'm going to open up the Q&A. bear with me whilst i try and wrangle classbot [19:38] sera asked: Which version of Mono will be available in Oneiric? [19:38] Oneiric will ship with Mono 2.10.1. [19:39] we're also taking the opportunity to rebuild the entire world using the 4.0 class library (.NET 4.0), replacing the 2.0 class library (.NET 2.0 -> 3.5) that's served us for the last few years [19:39] we always have only one "supported" runtime in releases, because otherwise the package dependency chain for high-level apps like banshee bloats up [19:40] once the transition is over, only 4.0 libraries will be installed by default, not a mix of 2.0 and 4.0 - and older apps are simply rebuilt for 4.0 (we even have old 1.0 apps that we;ve been rebuilding as 2.0 for a while) [19:40] .net generally has major class library versions - they avoid changing (and breaking) it, unless there's a real breaking change. they've only broken it twice so far - 2.0 and 4.0 [19:41] monodevelop will also default to 4.0 for new projects, in oneiric (barring an annoying bug i haven't found, which means the first time you run it, it defaults to 2.0). existing projects will cease to compile, unless you change the target framework version to 4.0, as the libraries you use like gtk# will also be 4.0-only [19:41] monodevelop 2.6 beta 3 is already in oneiric [19:42] okay, next [19:42] dell asked: please can you give the package name. I did not find it in UDW page [19:43] "docky", "sparkleshare" and "keepass2". sparkleshare is oneiric-only, don't worry about it if you're not on oneiric (or debian, i guess). keepass2 is in natty-backports, if memory serves. [19:43] bullgard4 asked: The Ubuntu programm is called KeePassX. Why do you call it »keepass2«? [19:44] KeePassX is a Qt (i think?) reimplementation of the original Keepass 1. Keepass 2 in Ubuntu is the "real" keepass2, as found on Windows, which is a .NET app. the packaging for this is done by jtaylor. [19:44] users are free to use their preferred app - i believe keepass2 has more features than keepassx, but looks kinda bad due to being a SWF app [19:44] bullgard4 asked: What does mean the phrase »for the greater good« in the headline: "Packaging Mono for the greater good"? [19:45] there are a few mono apps out there on the web, with home-grown packaging (i.e. which don't follow the packaging best practices from this talk). those packages tend to suffer somewhat as a result. the universe will be just that little bit better if more mono apps are packaged *well* [19:46] matteonardi asked: do you know if MonoDevelop is "good enough" for auto-generating autotools setups for simple projects? (I'm developing a simple checkers game with mono.. and after taking a look at autotools, I'd rather avoid them if possible!) [19:47] honestly, I don't know. i haven't used the autofoo integration much. from a packaging perspective, i know sources produced this way have some issues, which we need to patch in the packages. [19:48] given the maturity of xbuild, and that MD uses VS.NET project format as its own data format, i'd be inclined to use that - it also invites contributions from windows-based developers, since the same source can be compiled on windows easily, in vs.net or monodevelop or sharpdevelop, without needing cygwin or mingw [19:48] when i started using mono, we had neither autofoo integration nor xbuild. it was all manual. and all this was green fields ;) [19:48] bullgard4 asked: '/usr/local/src$ sudo apt-getsource keepassx; gpgv: Unterschrift kann nicht geprüft werden. Öffentlicher Schlüssel nicht gefunden.' Why can apt-get source not find the public key? [19:49] "apt-get source" uses your personal gpg keyring for verifying downloads. if you don't have the key in question in your personal keyring, then it'll throw an error. you can use "gpg --recv-key ABCDABCD" for the key id in question, to download & add it [19:50] bullgard4 asked: Why did you write the 1st version of the Banshee plugin to access the Ubuntu One music store in Mono and not in Python? [19:50] because banshee is a mono app - it made sense to make a mono app plugin in c# [19:51] as it happens, most of the heavy lifting in that plugin is done by libubuntuone, which is a C library - but it offers a C# binding (i might have done that too, i don't remember). the only parts written in c# are linking the gtk+ events into banshee, and handling the library adding for downloading tracks [19:52] coalitians asked: I ram dpkg --build docky-2.1.2 but i get this error [19:52] dpkg-deb: error: failed to open package info file `docky-2.1.2/DEBIAN/control' for reading: No such file or directory [19:52] try dpkg-buildpackage. "dpkg --build" does something subtly different [19:53] sera asked: Are the difficulties in packaging Mono over? i.e. will we get Mono 2.12 in 12.04? [19:53] I can't make promises given 2.12 doesn't exist yet... i can say that uploads involving a transition (e.g. this 4.0 transition which is currently ongoing and about half complete) take MUCH longer than those without [19:54] mono's source package builds over a hundred binary packages - that's a lot of manual checking to do [19:54] there's also the time taken to make mono build on multiple architectures, update our ports (e.g. kfreebsd-amd64 in debian), and so on. it takes time [19:55] we have a new workflow which should allow for faster, more frequent uploads of new mono releases, but it's still largely dependent upon one person, who does this work in his spare time (and therefore it isn't reasonable to *demand* things from him). [19:56] in my experience, a visit to the team's donations page (http://wiki.debian.org/Teams/DebianMonoGroup/DonationRegistry) and a donation to Mirco Bauer are an excellent way to get updates to Mono itself. although i think 2.10.1 is pretty final for oneiric (no 2.10.2, not worth it at this point) [19:56] bullgard4 asked: What IRC channel do you frequent? I am asking for the case that I have additional questions after having studied in full your lession. [19:57] #debian-cli on irc.oftc.net is the best bet. that's where mono-related things happen. [19:57] !q [19:57] bah. anyway, no questions in the queue? [19:57] 3 minutes remaining. ask anything [19:58] rww asked: What's your favorite colour? [19:58] bloo! [19:58] john_g asked: Maybe I missed this. What does cli mean in this context? [19:59] Common Language Infrastructure. it's a term used in the .NET standards documentation, without the trademark associations of "microsoft .net" [19:59] grungekid_ asked: What are the advantages of using mono over other languages such as python? Why do you choose to use it? [20:00] i personally deeply dislike python syntax - and c# tends to perform MUCH faster than python. it's good if you have a java background, syntacically [20:00] and i'm out of time. i'll finish questions in #ubuntu-classroom-chat [20:00] next up is... barry i think? }}}